Message-ID: <20040904183333.A26720@castle.nmd.msu.ru>
Date: Sat, 4 Sep 2004 18:33:33 +0400
From: Andrey Savochkin <saw@saw.sw.com.sg>
To: Chris Mason <mason@suse.com>
Cc: Andrea Arcangeli <andrea@suse.de>, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org
Subject: Re: EXT3: problem with copy_from_user inside a transaction
References: <20040903150521.B1834@castle.nmd.msu.ru> <20040903123541.GB8557@x30.random> <1094213179.16078.19.camel@watt.suse.com> <20040903175728.C1834@castle.nmd.msu.ru> <1094284064.6301.25.camel@watt.suse.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <1094284064.6301.25.camel@watt.suse.com>; from "Chris Mason" on Sat, Sep 04, 2004 at 03:47:44AM
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1617
Lines: 38

On Sat, Sep 04, 2004 at 03:47:44AM -0400, Chris Mason wrote:
> On Fri, 2004-09-03 at 09:57, Andrey Savochkin wrote:
> 
> > > This would mean that all the work is done during the commit_write
> > > stage.  The trick is that we would have to handle -ENOSPC since we might
> > > not know we've run out of room until after the data has been copied from
> > > userland.
> > 
> > What is the problem -ENOSPC?
> > Do you think about the problem of the page existing before this write, it's
> > content overwritten, but the filesystem being unable to commit that write
> > because it needs more space?
> 
> Exactly.  In this case, we've effectively corrupted the page cache. 
> We've copied data in that isn't (and never will be) reflected on disk. 
> It isn't a horribly difficult case, we just need to overwrite the data
> with zeros, making sure to only overwrite the data corresponding to the
> -ENOSPC error.

Zeroing not mapped buffers in case of error is not difficult, indeed.

I was speaking about the following case:
 - one page of a file is dirtied through a userspace mapping,
 - the page doesn't have disk mapping yet (a hole),
 - someone issues write() to this page,
 - the space allocation fails in commit_write(), when the page content has
   already been overwritten with the new data.

Any holes in this scenario? :)

How to handle -ENOSPC in this case?

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