> Fixed size structs are much nicer to deal with, and most of the fields > we're talking about don't change ofetn enough to make trying to strive > for perfect atomicity worthwhile. I think we can live with mnt_root and mnt_mountpoint in struct statmnt if we add a length field for both them and make them __u64 pointers. That's what we did in clone3() for the pid array and bpf is doing that as well for log buffers and pathnames. So if Miklos is fine with that then I'm happy to compromise. And I think that's all the variable length data we want in struct statmount anyway. > ...and then if the mnt_change_cookie hasn't changed, you know that the > string option was stable during that window. Meh, I would really like to sidestep this and keep it as simple as we can. I like the proposal overall I just don't want it to get diluted too much by exploding into another overly broad solution.
