[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YMauEdVL/RoycCPS@zeniv-ca.linux.org.uk>
Date: Mon, 14 Jun 2021 01:17:05 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Kees Cook <keescook@...omium.org>
Cc: Christoph Hellwig <hch@....de>, axboe@...nel.dk, anton@...msg.org,
ccross@...roid.com, tony.luck@...el.com, gmpy.liaowx@...il.com,
linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mark pstore-blk as broken
On Tue, Jun 08, 2021 at 10:34:29AM -0700, Kees Cook wrote:
> > diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
> > index 8adabde685f1..328da35da390 100644
> > --- a/fs/pstore/Kconfig
> > +++ b/fs/pstore/Kconfig
> > @@ -173,6 +173,7 @@ config PSTORE_BLK
> > tristate "Log panic/oops to a block device"
> > depends on PSTORE
> > depends on BLOCK
> > + depends on BROKEN
> > select PSTORE_ZONE
> > default n
> > help
> > --
> > 2.30.2
> >
>
> NAK, please answer my concerns about your patches instead:
> https://lore.kernel.org/lkml/202012011149.5650B9796@keescook/
How about concerns about the code in question having gotten
into the kernel in the first place? Quality aside (that's a separate
conversation, probably for tomorrow), just what happens if that thing
is triggered by the code that happens to hold a page on block device
locked? AFAICS, __generic_file_write_iter() will cheerfully deadlock...
Kees, may I ask you where had that thing been discussed back
then? All I can see is linux-kernel, and that's "archived by", not
"discussed on"...
Powered by blists - more mailing lists