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 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, 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, 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 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, 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 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 +
15 matches
Mail list logo
