linux-kernel - Re: [PATCH 03/10] coda: honor AT_STATX_DONT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOssrKfq_psse+sY7kZjNiJa6QeiMW8FSUZN9xh38+ROCtzHrQ@mail.gmail.com>
Date:   Thu, 21 Sep 2017 14:45:30 +0200
From:   Miklos Szeredi <mszeredi@...hat.com>
To:     Jan Harkes <jaharkes@...cmu.edu>
Cc:     linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        David Howells <dhowells@...hat.com>
Subject: Re: [PATCH 03/10] coda: honor AT_STATX_DONT_SYNC

On Wed, Sep 20, 2017 at 10:04 PM, Jan Harkes <jaharkes@...cmu.edu> wrote:
> On Wed, Sep 20, 2017 at 10:39:58AM +0200, Miklos Szeredi wrote:
>> The description of this flag says "Don't sync attributes with the server".
>> In other words: always use the attributes cached in the kernel and don't
>> send network or local messages to refresh the attributes.
>
> What is the use case for this AT_STATX_DONT_SYNC flag?
>
> I'm asking because the Coda userspace client potentially has attributes
> that are not cached in the kernel but can be (re-)validated without
> network communication. So if we just care about avoiding network
> traffic we could propagate the flag up to userspace. If we want to avoid
> context switches, disk I/O and only check on what happens to be cached
> in the kernel the current approach works fine.

It's an interesting question, "server" could mean several different
things depending on the context.  I interpreted it as "any entity
outside the kernel the filesystem resides in", mainly because it's the
simplest interpretation.

Thanks,
Miklos


>> Signed-off-by: Miklos Szeredi <mszeredi@...hat.com>
>> Cc: Jan Harkes <jaharkes@...cmu.edu>
>> ---
>>  fs/coda/inode.c | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/coda/inode.c b/fs/coda/inode.c
>> index 6058df380cc0..734672b2cbdc 100644
>> --- a/fs/coda/inode.c
>> +++ b/fs/coda/inode.c
>> @@ -255,7 +255,10 @@ static void coda_evict_inode(struct inode *inode)
>>  int coda_getattr(const struct path *path, struct kstat *stat,
>>                u32 request_mask, unsigned int flags)
>>  {
>> -     int err = coda_revalidate_inode(d_inode(path->dentry));
>> +     int err = 0;
>> +
>> +     if (!(flags & AT_STATX_DONT_SYNC))
>> +             err = coda_revalidate_inode(d_inode(path->dentry));
>>       if (!err)
>>               generic_fillattr(d_inode(path->dentry), stat);
>>       return err;
>> --
>> 2.5.5
>>
>>