On Tue, 2007-02-06 at 03:09 +0100, Nick Piggin wrote:
> On Sun, Feb 04, 2007 at 05:40:35PM +, Anton Altaparmakov wrote:
> > On Sun, 4 Feb 2007, Andrew Morton wrote:
> > > truncate's OK: we're holding i_mutex.
> >
> > How about excluding readpage() (in addition to truncate if Nick is right
>
On Tue, Feb 06, 2007 at 06:49:05AM +0100, Nick Piggin wrote:
> > - If the get_user() doesn't fault, and if we're copying from and to the
> > same page, we know that we've locked it, so nobody will be able to unmap
> > it while we're copying from it.
> >
> > Close, but no cigar! This is still
On Mon, Feb 05, 2007 at 09:30:06PM -0800, Andrew Morton wrote:
> On Tue, 6 Feb 2007 05:41:46 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> > >
> > > Not necessarily -- they could read from one part of a page and write to
> > > another. I see this as the biggest data corruption problem.
>
> The k
On Tue, 6 Feb 2007 05:41:46 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 06, 2007 at 03:25:49AM +0100, Nick Piggin wrote:
> > On Sun, Feb 04, 2007 at 10:36:20AM -0800, Andrew Morton wrote:
> > > On Sun, 4 Feb 2007 16:10:51 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> > >
> > > > T
On Tue, Feb 06, 2007 at 03:25:49AM +0100, Nick Piggin wrote:
> On Sun, Feb 04, 2007 at 10:36:20AM -0800, Andrew Morton wrote:
> > On Sun, 4 Feb 2007 16:10:51 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > > They're not likely to hit the deadlocks, either. Probability gets more
> > > likely a
On Sun, Feb 04, 2007 at 10:36:20AM -0800, Andrew Morton wrote:
> On Sun, 4 Feb 2007 16:10:51 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > They're not likely to hit the deadlocks, either. Probability gets more
> > likely after my patch to lock the page in the fault path. But practially,
> > w
On Sun, Feb 04, 2007 at 05:40:35PM +, Anton Altaparmakov wrote:
> On Sun, 4 Feb 2007, Andrew Morton wrote:
> > truncate's OK: we're holding i_mutex.
>
> How about excluding readpage() (in addition to truncate if Nick is right
> and some cases of truncate do not hold i_mutex) with an extra pa
On Sun, 4 Feb 2007 16:10:51 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 04, 2007 at 03:15:49AM -0800, Andrew Morton wrote:
> > On Sun, 4 Feb 2007 12:03:17 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > > On Sun, Feb 04, 2007 at 02:56:02AM -0800, Andrew Morton wrote:
> > > > O
On Sun, 4 Feb 2007, Andrew Morton wrote:
> On Sun, 4 Feb 2007 10:59:58 + (GMT) Anton Altaparmakov <[EMAIL
> PROTECTED]> wrote:
> > On Sun, 4 Feb 2007, Andrew Morton wrote:
> > > On Sun, 4 Feb 2007 09:51:07 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]>
> > > wrote:
> > > > 2. If we find the de
On Sun, Feb 04, 2007 at 03:15:49AM -0800, Andrew Morton wrote:
> On Sun, 4 Feb 2007 12:03:17 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > On Sun, Feb 04, 2007 at 02:56:02AM -0800, Andrew Morton wrote:
> > > On Sun, 4 Feb 2007 11:46:09 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> > >
> > >
On Sun, Feb 04, 2007 at 03:10:39AM -0800, Andrew Morton wrote:
> On Sun, 4 Feb 2007 10:59:58 + (GMT) Anton Altaparmakov <[EMAIL
> PROTECTED]> wrote:
> >
> > How about leaving the existing code with the following minor
> > modifications:
> >
> > Instead of calling filemap_copy_from_user{,_io
On Sun, 4 Feb 2007 12:03:17 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 04, 2007 at 02:56:02AM -0800, Andrew Morton wrote:
> > On Sun, 4 Feb 2007 11:46:09 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > > On Sun, Feb 04, 2007 at 02:30:55AM -0800, Andrew Morton wrote:
> > > > O
On Sun, 4 Feb 2007 10:59:58 + (GMT) Anton Altaparmakov <[EMAIL PROTECTED]>
wrote:
> On Sun, 4 Feb 2007, Andrew Morton wrote:
> > On Sun, 4 Feb 2007 09:51:07 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]>
> > wrote:
> > > 2. If we find the destination page is non uptodate, unlock it (this
> >
On Sun, Feb 04, 2007 at 02:56:02AM -0800, Andrew Morton wrote:
> On Sun, 4 Feb 2007 11:46:09 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > On Sun, Feb 04, 2007 at 02:30:55AM -0800, Andrew Morton wrote:
> > > On Sun, 4 Feb 2007 11:15:29 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> > >
> > >
On Sun, 4 Feb 2007, Andrew Morton wrote:
> On Sun, 4 Feb 2007 09:51:07 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]>
> wrote:
> > 2. If we find the destination page is non uptodate, unlock it (this could
> > be
> > made slightly more optimal), then find and pin the source page with
> > ge
On Sun, 4 Feb 2007 11:46:09 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 04, 2007 at 02:30:55AM -0800, Andrew Morton wrote:
> > On Sun, 4 Feb 2007 11:15:29 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > > The write path is broken. I prefer my kernels slow, than buggy.
> >
> >
On Sun, Feb 04, 2007 at 11:46:09AM +0100, Nick Piggin wrote:
>
> > It's better than taking mmap_sem and walking pagetables...
>
> I'm not convinced.
Though I am more convinced that looking at mm *at all* (either to
take the mmap_sem and find the vma, or to take the mmap_sem and
run get_user_page
On Sun, Feb 04, 2007 at 02:30:55AM -0800, Andrew Morton wrote:
> On Sun, 4 Feb 2007 11:15:29 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > The write path is broken. I prefer my kernels slow, than buggy.
>
> That won't fly.
What won't fly?
>
> > > There's a build error in filemap_xip.c btw
On Sun, 4 Feb 2007 11:15:29 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 04, 2007 at 01:44:45AM -0800, Andrew Morton wrote:
> > On Sun, 4 Feb 2007 09:51:07 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]>
> > wrote:
> >
> > > 2. If we find the destination page is non uptodate, unlock
On Sun, Feb 04, 2007 at 11:15:29AM +0100, Nick Piggin wrote:
> Cool, a kernel thread is calling sys_write. Fun.
There are tons of places where we possible call into ->write from
either kernel threads or at least with a kernel pointer and set_fs/set_ds
magic. Anything in the buffer write path tha
On Sun, Feb 04, 2007 at 01:44:45AM -0800, Andrew Morton wrote:
> On Sun, 4 Feb 2007 09:51:07 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]>
> wrote:
>
> > 2. If we find the destination page is non uptodate, unlock it (this could
> > be
> > made slightly more optimal), then find and pin the so
On Sun, 4 Feb 2007 09:51:07 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]> wrote:
> 2. If we find the destination page is non uptodate, unlock it (this could be
> made slightly more optimal), then find and pin the source page with
> get_user_pages. Relock the destination page and continue w
Modify the core write() code so that it won't take a pagefault while holding a
lock on the pagecache page. There are a number of different deadlocks possible
if we try to do such a thing:
1. generic_buffered_write
2. lock_page
3.prepare_write
4. unlock_page+vmtruncate
5. copy_from_u
On Fri, Feb 02, 2007 at 03:53:11PM -0800, Andrew Morton wrote:
> On Mon, 29 Jan 2007 11:33:03 +0100 (CET)
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Modify the core write() code so that it won't take a pagefault while
> > holding a
> > lock on the pagecache page. There are a number of differe
On Mon, 29 Jan 2007 11:33:03 +0100 (CET)
Nick Piggin <[EMAIL PROTECTED]> wrote:
> Modify the core write() code so that it won't take a pagefault while holding a
> lock on the pagecache page. There are a number of different deadlocks possible
> if we try to do such a thing:
>
> 1. generic_buffere
On Mon, Jan 29, 2007 at 11:33:03AM +0100, Nick Piggin wrote:
> + } else {
> + char *src, *dst;
> + src = kmap(src_page);
> + dst = kmap(page);
> + memcpy(dst + offset,
> + src + (
Modify the core write() code so that it won't take a pagefault while holding a
lock on the pagecache page. There are a number of different deadlocks possible
if we try to do such a thing:
1. generic_buffered_write
2. lock_page
3.prepare_write
4. unlock_page+vmtruncate
5. copy_from_u
27 matches
Mail list logo
