Page MenuHomeFreeBSD

Add additional EINVAL information about wrong block size to read(2)/write(2)
ClosedPublic

Authored by bcr on Apr 29 2020, 3:05 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Dec 9, 2:18 PM
Unknown Object (File)
Oct 19 2024, 9:36 AM
Unknown Object (File)
Oct 1 2024, 5:03 PM
Unknown Object (File)
Sep 30 2024, 3:19 AM
Unknown Object (File)
Sep 28 2024, 4:31 PM
Unknown Object (File)
Sep 26 2024, 3:46 PM
Unknown Object (File)
Sep 23 2024, 9:13 AM
Unknown Object (File)
Sep 23 2024, 3:14 AM

Details

Summary

This is an attempt at PR91149. I just added an additional EINVAL entry below the exitsing ones. I'm not sure about the position within the ERRORS section though. Does this happen for

  • read(), readv(), pread() and preadv(),
  • readv() and preadv(), or
  • pread() and preadv()?

(same for write.2)

Where could I look that up (I' new to this part of the tree, ENOSRCCOMMITTER)?

Test Plan
  1. Apply the patch to the head of a 13-CURRENT tree

2a) run ./man /lib/libc/sys/read.2
or
2b) run ./man /lib/libc/sys/write.2

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

bcr requested review of this revision.Apr 29 2020, 3:05 PM

Thanks for starting to work on this. I mostly like it, however, do we need to elaborate a bit on the block size meaning? Is it the value as returned by the DIOCGSECTORSIZE ioctl(2)? Probably need to check with the corresponding kernel source code.

Loop in the voices from the original PR.

Don't forget .Dd :-)

I see what you did there. ;-)

Should be okay. Did you have any opinion about the comments from @danfe ?

Block size is a well enough understood term that we needn't define it here. It is what danfe says. At most we should reference disk(4). But I need to get that committed.

This revision is now accepted and ready to land.Nov 19 2020, 4:55 PM

I've just committed disk(4), so it's safe to reference it now. It also obliquely talks about this, but with enough detail that taken together people will know what's going on.

Having this kind of possibly mysterious errors documented is very useful.

The text gives the impression that it is acceptable, for example, to read one byte at an offset that is a multiple of the block size. In fact, the size of the request must also be a multiple of the block size. Also, there should be some clarification that this error only applies to block devices (disk(4)).

So for example:

The
.Fa fd
argument refers to a block device,
and the position or the size of the request
is not a multiple of the block size.

The word "position" refers to the file offset for read()/readv()/write()/writev() and the offset argument for pread()/preadv()/pwrite()/pwritev().

This text assumes that it is acceptable to use readv()/preadv()/writev()/pwritev() with multiple areas whose size is not a multiple of the block size but whose total size is, for example an area of 2047 bytes and an area of 2049 bytes on a device with blocks of 4096 bytes.