linux-kernel - Re: [PATCH 1/6] seq_file: add seq_read

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, 8 Dec 2020 20:53:21 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Christoph Hellwig <hch@....de>,
        Nathan Chancellor <natechancellor@...il.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Alexey Dobriyan <adobriyan@...il.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kys@...rosoft.com, haiyangz@...rosoft.com,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Wei Liu <wei.liu@...nel.org>, linux-hyperv@...r.kernel.org
Subject: Re: [PATCH 1/6] seq_file: add seq_read_iter

On Tue, Dec 08, 2020 at 12:25:55PM -0800, Linus Torvalds wrote:
> On Tue, Dec 8, 2020 at 11:49 AM Al Viro <viro@...iv.linux.org.uk> wrote:
> >
> > Said that, it does appear to survive all beating, and it does fix
> > a regression introduced in this cycle, so, provided that amount of
> > comments in there is OK with you...
> 
> Ok, considering Greg's note, I've pulled it. It's early in the last
> week, if something comes up we can still fix it.
> 
> That said, considering that I think the only use-case was that odd
> /proc splice use, and the really special WSL2 thing, and both of those
> are verified, it does sound safe to pull.
> 
> Famous last words...
> 
> Al, since you're around, would you mind looking at the two
> DCACHE_DONTCACHE patches too? Honestly, since they seem to be an issue
> only for DAX, and only for DAX policy changes, I don't consider them
> critical for 5.10, but they've been around for a while now.

Umm...  I've got
fs: Handle I_DONTCACHE in iput_final() instead of generic_drop_inode()
and
fs: Kill DCACHE_DONTCACHE dentry even if DCACHE_REFERENCED is set
in "to apply" pile; if that's what you are talking about, I don't
think they are anywhere critical enough for 5.10-final, but I might
be missing something...

Al, still buried under piles of email ;-/