On Wed, Mar 08, 2017 at 09:41:00AM +0000, David Howells wrote: > > > > This example is confusing because chmod() doesn't change st_uid, and chown() > > doesn't ordinarily change st_mode. > > Doesn't chown() clear the S_ISUID and S_ISGID flags? > It can, but it's not a straightforward example. > > No, it's not a bug, exactly. It's a design decision. It might be worth > adding an AT_STAT_LOCK flag to synchronise against attribute setting, but it > will cost you something in terms of performance - and even then, over a > network filesystem it might not achieve anything. > Well, regardless of whether people want to fix it or not, I do think it's a bug. Currently even the update of a timestamp is non-atomic, since that involves updating both tv_sec and tv_nsec. Therefore, stat() might return the new tv_sec along with the old tv_nsec, or vice versa. This can cause some very strange behavior, such as two successively observed timestamps going backwards in time. I expect that historically people haven't complained enough for this to be worthwhile to fix. But in theory I think it could be fixed with little performance loss by protecting all the stat data with a sequence count, similar to how reads of i_size are made atomic on 32-bit platforms by using i_size_seqcount. > > Good point. Should I reject AT_EMPTY_PATH, AT_NO_AUTOMOUNT and > AT_SYMLINK_NOFOLLOW if pathname is NULL, I wonder? > It could be argued either way, but I was thinking those particular flags should just be ignored, as they have known meanings but simply aren't relevant. It could also cause confusion for statx(dfd, "", AT_EMPTY_PATH, 0, buffer) to succeed but for statx(dfd, NULL, AT_EMPTY_PATH, 0, buffer) to fail (for example). - Eric -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
