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, 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
and some
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
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:
> > >
> > > >
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
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,
> >
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
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 page
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,
we could
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 after my
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:
They're not
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 kernel gets
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 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:
> > > >
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
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
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:
> > > >
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
> >
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
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
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
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
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
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.
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.
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 with
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 source page
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 that
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 it (this
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, 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_pages)
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.
That won't
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
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:
The write path
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
could be
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:
On Sun, 4 Feb
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{,_iovec}() do
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:
If that
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 destination page is
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:
On Sun, 4 Feb
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
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.
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.
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 different
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.
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.
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 +
54 matches
Mail list logo