linux-kernel - Re: [PATCH 06/11] pipe: no need to confirm page cache buf

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]

Date:   Tue, 27 Sep 2016 04:40:35 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Miklos Szeredi <mszeredi@...hat.com>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jens Axboe <axboe@...nel.dk>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 06/11] pipe: no need to confirm page cache buf

On Wed, Sep 14, 2016 at 10:37:11AM +0200, Miklos Szeredi wrote:

> Things could happen to that page that make it not uptodate while sitting in
> the pipe, but it's questionable whether we should care about that.
> Checking for being uptodate in the face of such page state change is always
> going to be racy.

I'm not sure it's the right thing to do here; that area looks like a victim
of serious bitrot - once upon a time it was ->map(), which used to lock
page, verity that it's valid, and kmap it.  ->unmap() did kunmap + unlock.

Then the validate part got split off (->pin(), later renamed to ->confirm()),
with lock _not_ held over the kmap/kunmap.  That's the point when it got racy,
AFAICS.  OTOH, I would really hate to hold a page locked over e.g. copying to
userland - too easy to get deadlocks that way.

Jens, could you comment?  Pages definitely shouldn't be getting into pipe
without having been uptodate; the question is what (if anything) should be
done about having a page go non-uptodate (on truncate, hole-punching, etc.)
while a reference to it is sitting in a pipe buffer.