> On Oct 24, 2018, at 8:46 PM, NeilBrown <neilb@xxxxxxxx> wrote: > >> On Wed, Oct 24 2018, Theodore Y. Ts'o wrote: >> >>> On Wed, Oct 24, 2018 at 12:47:57PM +1100, NeilBrown wrote: >>> >>> I doubt it was copied - more likely independent evolution. >>> But on reflection, I see that it is probably reasonable that it >>> shouldn't be used this way - or at all in this context. >>> I'll try to understand what the issues really are and see if I can >>> find a solution that doesn't depend on this interface. >>> Thanks for your help. >> >> At least for ext4, the primary problem is that we want to use a 64-bit >> telldir/seekdir cookie if all 64-bits will make it to user space, and >> a 32-bit telldir cookie if only 32 bits will make it userspace. This >> impacts NFS as well because if there are people who are still using >> NFSv2, which has 32-bit directory offsets, we need to constrain the >> telldir/seekdir cookies we give to NFS to be a 32 has as opposed to a >> 64-bit hash. > > NFSd uses FMODE_32BITHASH or FMODE64BITHASH to allow ext4 to do the > right thing. FMODE_32BITHASH is set for NFSv2 only. > > Maybe sys_getdents needs to set FMODE_32BITHASH, and sys_getdent64 needs > to set FMODE_64BITHASH - or something like that. It’s possible for a 32-bit process and a 64-bit process to share a directory fd, so I don’t think it’s quite that simple. One option would be to add .llseek and .getdents flags or entire new compat operations to indicate that the caller expects 32-bit offsets. I wonder how overlayfs interacts with this whole mess.
|