Thanks. But while we're here, shouldn't it wait for D47956 as well? Going to update it in a short while to separate the change of switching the generation number to 32 bits to another revision so that the rest can be reviewed and hopefully approved/committed shortly.

In D47879#1096174, @markj wrote:

https://reviews.freebsd.org/D48093

Apply suggestions.

In D47879#1093639, @rmacklem wrote:

Just fyi, whenever the "struct fid" changes,
(snip)
RELNOTES entry is needed.

Apply (most) suggestions. Tiny word additions to HISTORY and SECURITY CONSIDERATIONS.

Fix compilation of atomic_load_acq_64_i586(). Expand commit message.

unsigned int => uint32_t as suggested.

In D47956#1093749, @rmacklem wrote:

Btw, I replaced "sizeof(struct fid)" with MAXFIDSZ in the _Static_assert()
and it passed (at least for amd64).

In D47956#1093709, @rmacklem wrote:

I'll leave it someone familiar with tmpfs to decide if having
tn_gen wrap around to zero is a real concern.

In D47879#1093088, @markj wrote:

In D47879#1093063, @olce wrote:

Leaving the layout completely to the filesystem means we could get rid of fid_len. I'm not completely sure if we really want to be doing so. fid_len could serve the purpose of limiting which bytes are actually compared to determine which handles are the same (which needs a slight amendment to tmpfs or zfs, as they are not consistent with what they store into fid_len), possibly avoiding problems with uninitialized bits. It could also be handy if we decided to switch to dynamic allocation (just saying; I'm not aware of an actual need to do that).

Unless you think it would be preferable to remove fid_len entirely, I'll draft some concrete changes giving fid_len a standard meaning.

What changes do you propose?

In D47879#1091962, @markj wrote:

In D47879#1091930, @olce wrote:

That doesn't seem possible as len and pad must stay first.

As far as I can see, this isn't true - the layout is up to the filesystem.

In D47879#1091933, @emaste wrote:

I think more relevant question there are compilers generate proper code to access unaligned ifid_ino and ifid_start on sensitive arches.

I mentioned in a secteam chat that we should have a comment about unaligned access in arch(7). (The only comment we have right now is Most ILP32 ABIs, except arm, require only 4-byte alignment for 64-bit integers.)

Impacts of some setcred() changes.

Remove from the diff small pieces that did not belong here but to an earlier revision.