linux-kernel - Re: [jffs2] [rfc] fix write deadlock regression

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]

Message-Id: <1188749726.3834.30.camel@shinybook.infradead.org>
Date:	Sun, 02 Sep 2007 17:15:26 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Nick Piggin <npiggin@...e.de>
Cc:	Jason Lunz <lunz@...ooley.org>,
	lkml <linux-kernel@...r.kernel.org>, jffs-dev@...s.com,
	Hugh Dickins <hugh@...itas.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [jffs2] [rfc] fix write deadlock regression

On Sun, 2007-09-02 at 16:17 +0200, Nick Piggin wrote:
> On Sun, Sep 02, 2007 at 02:48:04PM +0100, David Woodhouse wrote:
> > On Sun, 2007-09-02 at 15:20 +0200, Nick Piggin wrote:
> > > OK, but then hasn't the patch just made the deadlock harder to hit,
> > > or is there some invariant that says that readpage() will never be
> > > invoked if gc was invoked on the same page as we're commit_write()ing?
> > 
> > > The Q/A comments aren't very sure about this. I guess from the look
> > > of it, prepare_write/commit_write make sure the page will be uptodate
> > > by the start of commit_write, 
> > 
> > That's the intention, yes.
> > 
> > > and you avoid GCing the page in
> > > prepare_write because your new page won't have any nodes allocated
> > > yet that can possibly be GCed?
> > 
> > We _might_ GC the page -- it might not be a new page; we might be
> > overwriting it. But it's fine if we do. Actually it's slightly
> > suboptimal because we'll write out the same data twice -- once in GC and
> > then immediately afterward in the write which we were making space for.
> 
> But doesn't GC only happen in prepare_write in the case that the
> i_size is being extended into a new page?

Ah, yes. I was thinking of commit_write, and it had temporarily escaped
my notice that we also write in prepare_write, to extend the file.

So yes, you're probably right that it doesn't matter; in any GC
triggered from _prepare_write_ we avoid GCing the page in question
because it by definition doesn't exist.

-- 
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/