My 13th gen Framework 13 laptop works ok with or without this patch.

Closing in favor of https://reviews.freebsd.org/D52780

You must also update the test cases in tests/sys/fs/fusefs/fallocate.cc . In particular, I think that the PosixFallocate.eopnotsupp will fail now, unless you update it.

LGTM. Thanks for the contribution, Juraj.

Thanks for doing this. I think it will be a good addition. But I'm curious: why did you choose -F? Obviously -u and -U were already taken.

In D53080#1217336, @guest-svmhdvn wrote:

@asomers As of f4f638eb23d770e19ede167908d8145b8851f835, this test is still failing intermittently in CI as seen here on aarch64: https://ci.freebsd.org/view/Test/job/FreeBSD-main-aarch64-test/1801/testReport/junit/sys.fs.fusefs/bad_server/main.

This seems to also be reproducible locally on amd64 with more than 20+ minutes of testing (very intermittent, but becomes clear when running on slower platforms). I'm not sure this fix is comprehensive, although it did certainly help reduce the intermittency.

Thanks for getting this fixed, @arrowd .

@arrowd now that you've committed the main bmap patch, are you ok with this test?

That explains it. I was never testing with SCTP, and I doubt that Damin was, either.

Can you give an example of the incorrect output? Does it matter whether "-q" is in use?

LGTM

Looks like a good start.

You need to wrap that long line to 80 cols, but otherwise it LGTM.

I have two comments in addition to the inline ones:

In D53079#1212648, @glebius wrote:

I trust Alan's expertise here. IMHO, given that this patch is analog to fusefs one, should be fine. But not expert in the area.

I too am confused by the commit message. Won't the column always be shown in json and xml output, if "-s" is used?

Could you please give an example of the before and after output?

Could you give an example of what the output looks like before and after?

In D52914#1209926, @olivier wrote:

In D52914#1209913, @asomers wrote:

The MD_LEN variable is now badly named. I think it's ok to leave its value the same. Most test cases don't require 1 MB of I/O. But you should at least change that name.

So, let’s use DEVICE_IO_LEN then (to clarifies that this constant represents the I/O buffer length used for device tests (16 KB), not the size of the MD device itself which is now 1 MB) ?

The MD_LEN variable is now badly named. I think it's ok to leave its value the same. Most test cases don't require 1 MB of I/O. But you should at least change that name.

After seeing this code in practice it seems quite complicated. I do think that the kernel based approach would be simpler. But an important question is: what file systems already use this option on Linux? How many of them would work with either this implementation, or the hypothetical kernel-based one?

So is -1 being cast to true? Thank you GCC for telling us that. If so, I think we should replace ATF_REQUIRE_MSG with ATF_REQUIRE_EQ_MSG. I think that would be more clear.

What's the problem? Under what conditions is the current code incorrect?

I have a few thoughts:

In D52625#1202173, @markj wrote:

I'm sure this will fix the panic, but I can't easily see if it's correct. For instance, if the unix domain socket code does asynchronous fd reclamation using unp_gc_task, the current thread will be some taskqueue thread. Its PID will probably be zero (but this is an implementation detail). I see some special handling for PID 0 e.g. in fuse_filehandle_get_anyflags(). Will this work the way you want in that case?

• Also add a test case for writes to a file that lies in a sockbuf

What bug exactly does this "fix"? Did you encounter a bug in your work, or did you just discover this problem by inspection? If the former, we should add a test case to tests/sys/fs/fusefs.

In D50826#1193323, @arrowd wrote:

Is this going to be landed?

@arrowd I agree with your change. The only thing I wanted different is a more detailed commit message. Of course, Mark might disagree.