linux-kernel - Re: [PATCH 0/5] orangefs: misc attribute fixes

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] [day] [month] [year] [list]

Date:   Tue, 28 Nov 2017 16:02:35 -0500
From:   martin@...ibond.com
To:     hubcap@...ibond.com, devel@...ts.orangefs.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] orangefs: misc attribute fixes

On Tue, Nov 28, 2017 at 03:21:56PM -0500, Martin Brandenburg wrote:
> Mike,
> 
> Here's a few fixes for OrangeFS.
> 
> Most important is to run getattr for size during a mmap page fault.  
> 
> I have also found a bug in d_revalidate.  The test is backwards.
> However I haven't found a test that demonstrates that it is wrong, which
> makes me doubt that all the code here is completely optimal.

The reason I can't find a test is because this code only gets run
if the inode being tested has the same handle as the inode in the
dcache.  Of course this happens all the time (it wasn't changed).  We
would return that it was not valid even though it was, which didn't
affect correctness but caused OrangeFS to perform extra round-trips with
the server.

We would return that it was valid even though it wasn't when an inode
is deleted and re-created on the server as a different type or different
symlink target AND has the same handle as the one in the cache.  This
practically never happens.

Martin