Thread (19 messages) 19 messages, 5 authors, 2018-11-06

Re: [PATCH v2 5/5] nfs: don't clear STATX_ATIME from result_mask

From: Miklos Szeredi <miklos@szeredi.hu>
Date: 2018-10-20 04:56:19
Also in: linux-fsdevel, lkml

On Fri, Oct 19, 2018 at 8:14 PM, Trond Myklebust
[off-list ref] wrote:
On Fri, 2018-10-19 at 19:46 +0200, Miklos Szeredi wrote:
quoted
How is it then that only STATX_ATIME is cleared and not the other
fields?
It isn't just the atime. We can also fail to revalidate the ctime and
mtime if they are not being requested by the user.
quoted
Note: junk != stale.  The statx definition doesn't talk about the
fields being up-to-date, except for AT_STATX_FORCE_SYNC, so stale
attributes are okay, and do not warrant clearing the result_mask.
I disagree. stale == junk here, because the default of
AT_STATX_SYNC_AS_STAT is described by the manpage as "Do  whatever
stat(2) does." which this is not.
Ah, you are talking about this:

    /* Is the user requesting attributes that might need revalidation? */
    if (!(request_mask & (STATX_MODE|STATX_NLINK|STATX_ATIME|STATX_CTIME|
                    STATX_MTIME|STATX_UID|STATX_GID|
                    STATX_SIZE|STATX_BLOCKS)))
        goto out_no_update;

Well, if this is triggered for statx(...,  STATX_ATIME,
AT_STATX_SYNC_AS_STAT) and MNT_NOATIME, then yes, result will be junk.
Which means that the code is wrong, it shouldn't do that.

Otherwise (if something other than STATX_ATIME or STATX_INO or
STATX_TYPE is given as well) it *will* do the same thing as what
stat(2) does, so in that case STATX_ATIME should not  be cleared (yet
it is cleared).

I can do a patch, but not tonight...

Thanks,
Miklos


Thanks,
Miklos
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help