User Details
- User Since
- May 9 2014, 11:04 PM (499 w, 2 d)
Fri, Dec 1
Thu, Nov 30
Wed, Nov 29
Tue, Nov 28
Tue, Nov 21
Thu, Nov 16
ping @jrtc27 does the latest version look better to you?
Wed, Nov 15
LGTM. But under what circumstances can mp be NULL? We should probably add a regression test for that.
- style fixup to "libc/libc/rpc: refactor some global variables"
- fixup to "rpc: Replace per-fd condvars with mutexes in clnt_{vc,dg}.c"
Tue, Nov 14
- style change to dg_fd_find and vc_fd_find
- rpc: Replace per-fd condvars with mutexes in clnt_{vc,dg}.c
- Respond to kib's comments.
Oct 24 2023
This latest version fixes the script with UFS, and makes the bootconfig script less ZFS-specific.
- Add ESP to all ZFS boot disks, pretty edition
Oct 21 2023
Oct 15 2023
Oct 14 2023
Oct 10 2023
Oct 7 2023
Oct 6 2023
- Restore the original behavior in vfs_lookup
Approved, but please note in the commit message that this condition can only occur due to FPU rounding error.
@markj I've moved the check into namei_follow_link . Do you like this version better? I could also have it print some kind of warning to dmesg, subject to INVARIANTS, if you would prefer. Or I could remove it entirely and restore the panic, if you prefer. The problem with doing the check in namei_follow_link is that it causes an extra scan through the string, rather than piggy backing on the scan that already takes place in vfs_lookup.
If we were computing with real numbers, then it should be impossible for vari to ever be negative. And in fact, all of the failing tests use -t 1, which means that n will be 1, so vari should always be exactly zero. So the fact that you're seeing these errors must mean that we're hitting some kind of floating point round-off error. Your patch will work, but it begs the question: why print min/avg/max/stddev when there is only one datapoint? I think that we should only print those things when n > 1. In fact, the standard deviation isn't really meaningful when n == 2, but it probably wouldn't hurt to print it, if that makes the code more readable.
- Move the nul check into namei_follow_link
You could add something to namei_follow_link(), where VOP_READLINK is actually called during name resolution. But I also want to ask, why is not sufficient to modify fuse alone? How would other filesystems allow this situation to occur, barring corruption of on-disk data?
Oct 5 2023
Oct 4 2023
Sorry, @mjg . Good luck with your next project.
- Restrict the new fusefs warning to INVARIANTS
Oct 3 2023
Sep 27 2023
Sep 25 2023
Let me see if I understand this dlopen business correctly. Your plan is that if you create a separate .c file containing "test_strcmp" and link it to t_strcmp.o, then the test will operate on that function. Otherwise, it will operate on the standard strcmp?
Sep 24 2023
In its current state, the "base" test doesn't pass. It seems like the expected_value variable isn't getting correctly expanded. Its value is just the name of the variable. Could you please fix that?
Sep 23 2023
Sep 22 2023
Ok, I've commited to stable/14 now.
Sep 21 2023
If the caller provides insufficient space for the entire structure, will the kernel fail the ioctl or copy as much as it can? It looks to me like it will do the latter. That also provides backwards compatibility, as long as we don't move or delete fields. @tuexen do you accept @glebius's suggestion to directly commit to stable/14? I would like to do that because it improves the Rust story. The Rust community still has not accepted that some APIs change between versions, like 64-bit inodes. Pushing the tcp_info compatibility break to FreeBSD 15 instead of 14 will give Rust some more time to come to terms.
Looks like this review got away from me. Oops. I'll rebase, test, and hopefully commit today.
Sep 20 2023
Sep 17 2023
Note that I have no way to test this change.