Cap IOSIZE_MAX to INT_MAX for 32-bit processes.

[jhb]

Summary

Cap IOSIZE_MAX to INT_MAX for 32-bit processes.

Test Plan

• 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).

[kib]

sys/fs/devfs/devfs_vnops.c

62

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.

[jhb]

sys/fs/devfs/devfs_vnops.c

62

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.

[kib]

sys/fs/devfs/devfs_vnops.c

62

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 ?

[jhb]

sys/fs/devfs/devfs_vnops.c

62

Yes, it would still be a function.

[jhb]

• Use functions for DEVFS_IOSIZE_MAX and IOSIZE_MAX if LP64.
• Drop sysent includes.

[kib]

sys/kern/sys_generic.c

94 ↗

(On Diff #14797)

So you are making the sysctl instantiated on 64bit hosts only. Strange, but it is fine.

172 ↗

(On Diff #14797)

I would use ?: there, it saves 2-3 lines.

[jhb]

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)

[jhb]

• Use ?: to trim code size.