[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061014043041.GC14467@wotan.suse.de>
Date: Sat, 14 Oct 2006 06:30:41 +0200
From: Nick Piggin <npiggin@...e.de>
To: Andrew Morton <akpm@...l.org>
Cc: Linux Memory Management <linux-mm@...ck.org>,
Neil Brown <neilb@...e.de>,
Anton Altaparmakov <aia21@....ac.uk>,
Chris Mason <chris.mason@...cle.com>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [patch 6/6] mm: fix pagecache write deadlocks
On Sat, Oct 14, 2006 at 06:19:27AM +0200, Nick Piggin wrote:
> On Fri, Oct 13, 2006 at 03:14:57PM -0700, Andrew Morton wrote:
> > On Fri, 13 Oct 2006 18:44:52 +0200 (CEST)
> > Nick Piggin <npiggin@...e.de> wrote:
> > >
> > > - This also showed up a number of buggy prepare_write / commit_write
> > > implementations that were setting the page uptodate in the prepare_write
> > > side: bad! this allows uninitialised data to be read. Fix these.
> >
> > Well. It's non-buggy under the current protocol because the page remains
> > locked throughout. This patch would make these ->prepare_write()
> > implementations buggy.
>
> But if it becomes uptodate, then do_generic_mapping_read can read it
> without locking it (and so can filemap_nopage at present, although it
> looks like that's going to take the page lock soon).
So the simple_prepare_write bug is an uninitialised data loeak. If
you read the part of the file which is about to be written to (and thus
does not get memset()ed), you can read junk.
I was able to trigger this with a simple test on ramfs.
-
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/
Powered by blists - more mailing lists