Cap IOSIZE_MAX to INT_MAX for 32-bit processes.
Details
- Reviewers
kib - Commits
- rS297493: Cap IOSIZE_MAX to INT_MAX for 32-bit processes.
- Run the recently added 'large_file_test' from an i386 aio_test under amd64. It is able to do a INT_MAX + 1 sized aio_read without this fix (when that should be failing). This test now properly fails after this fix (regardless of the 'clamp' setting on the host).
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
sys/fs/devfs/devfs_vnops.c | ||
---|---|---|
62 ↗ | (On Diff #14755) | I think this is good enough reason to define *IOSIZE_MAX as calls to external function. Also, it would allow to avoid harmless but useless SV_ILP32 checks in ILP32 arches. |
sys/fs/devfs/devfs_vnops.c | ||
---|---|---|
62 ↗ | (On Diff #14755) | Mm, ok. BTW, I figured the compiler would be smart enough to reduce 'x ? INT_MAX : INT_MAX' to just remove the 'x' test entirely and substitute 'INT_MAX', so I assumed it would DTRT on 32-bit platforms (those don't need the clamping at all even) We could do: #ifdef __ILP32__ #define IOSIZE_MAX SSIZE_MAX #else #define IOSIZE_MAX iosize_max() #endif since making it a function means the compiler won't inline it anymore. |
sys/fs/devfs/devfs_vnops.c | ||
---|---|---|
62 ↗ | (On Diff #14755) | I was more about the sys/sysent.h contamination of the devfs and other unrelated sources. For your proposal, iosize_max() would be still a function for LP64, or did I misunderstood ? |
sys/fs/devfs/devfs_vnops.c | ||
---|---|---|
62 ↗ | (On Diff #14755) | Yes, it would still be a function. |
sys/kern/sys_generic.c | ||
---|---|---|
94 ↗ | (On Diff #14797) | It wouldn't be used otherwise (even before it was effectively a no-op since INT_MAX == SSIZE_MAX on 32-bit platfoms) |