From: Andrea Arcangeli <andrea@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: vrajesh@umich.edu, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix
Date: Wed, 31 Mar 2004 17:07:18 +0200 [thread overview]
Message-ID: <20040331150718.GC2143@dualathlon.random> (raw)
In-Reply-To: <20040329144243.393d21a8.akpm@osdl.org>
On Mon, Mar 29, 2004 at 02:42:43PM -0800, Andrew Morton wrote:
> diff -puN mm/page_io.c~rw_swap_page_sync-fix mm/page_io.c
> --- 25/mm/page_io.c~rw_swap_page_sync-fix Mon Mar 29 14:41:08 2004
> +++ 25-akpm/mm/page_io.c Mon Mar 29 14:41:28 2004
> @@ -139,7 +139,7 @@ struct address_space_operations swap_aop
>
> /*
> * A scruffy utility function to read or write an arbitrary swap page
> - * and wait on the I/O.
> + * and wait on the I/O. The caller must have a ref on the page.
> */
> int rw_swap_page_sync(int rw, swp_entry_t entry, struct page *page)
> {
> @@ -151,8 +151,7 @@ int rw_swap_page_sync(int rw, swp_entry_
> lock_page(page);
>
> BUG_ON(page->mapping);
> - page->mapping = &swapper_space;
> - page->index = entry.val;
> + add_to_page_cache(page, &swapper_space, entry.val, GFP_NOIO);
>
> if (rw == READ) {
> ret = swap_readpage(NULL, page);
> @@ -161,7 +160,12 @@ int rw_swap_page_sync(int rw, swp_entry_
> ret = swap_writepage(page, &swap_wbc);
> wait_on_page_writeback(page);
> }
> - page->mapping = NULL;
> +
> + lock_page(page);
> + remove_from_page_cache(page);
> + unlock_page(page);
> + page_cache_release(page); /* For add_to_page_cache() */
> +
> if (ret == 0 && (!PageUptodate(page) || PageError(page)))
> ret = -EIO;
> return ret;
I checked this into CVS last night and today I got this new oops in
bugzilla:
hda: completing PM request, resume
Writing data to swap (18536 pages): .<1>Unable to handle kernel NULL pointer dereference at virtual address 00000004
printing eip:
c01daf24
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c01daf24>] Tainted: P
EFLAGS: 00010082 (2.6.4-40.3-default)
EIP is at radix_tree_delete+0x14/0x160
eax: 00000004 ebx: c16b6880 ecx: 00000016 edx: 00001d69
esi: 00001d69 edi: 00000010 ebp: 000011ae esp: f7329e1c
ds: 007b es: 007b ss: 0068
Process powersaved (pid: 4216, threadinfo=f7328000 task=f751f250)
Stack: 00000000 f51b6e00 00000004 00000006 f6326200 f63262bc 0000002e c0108d48
c041f4c0 00000000 000003fd 000026cd c041f4c0 c03ffd45 00000320 0000007b
0000007b ffffff00 c021b78e c16b6880 c0342d60 000011ae 000011ae 000011ae
Call Trace:
[<c0108d48>] common_interrupt+0x18/0x20
[<c021b78e>] serial_in+0x1e/0x40
[<c0150f2c>] swap_free+0x1c/0x30
[<c0152897>] remove_exclusive_swap_page+0x97/0x155
[<c013be2f>] __remove_from_page_cache+0x3f/0xa0
[<c013beab>] remove_from_page_cache+0x1b/0x27
[<c014fe5c>] rw_swap_page_sync+0x9c/0x1b0
[<c0135a9d>] do_magic_suspend_2+0x27d/0x7d0
[<c0125fb0>] process_timeout+0x0/0x10
[<c011ad1e>] __wake_up+0xe/0x20
[<f952be8d>] snd_intel8x0_suspend+0x1d/0x40 [snd_intel8x0]
[<c01e3586>] pci_device_suspend+0x16/0x20
[<c027701d>] do_magic+0x4d/0x130
[<c0135520>] software_suspend+0xd0/0xe0
[<c01fc176>] acpi_system_write_sleep+0xb5/0xd2
[<c01fc0c1>] acpi_system_write_sleep+0x0/0xd2
[<c015514e>] vfs_write+0xae/0xf0
[<c015522c>] sys_write+0x2c/0x50
[<c0107dc9>] sysenter_past_esp+0x52/0x79
Code: 8b 28 8d 7c 24 10 3b 14 ad a0 b9 41 c0 0f 87 18 01 00 00 8d
the oops is in a different place. It seems to bomb in
__remove_from_page_cache while calling radix_tree_delete like if the
radix_tree_insert didn't work out. I believe it's because you're not
checking for the retval of add_to_page_cache, if it runs oom in the
radix tree insert it will crash. You used GFP_NOIO, that's wrong, it
should be GFP_KERNEL to guarantee allocation. There's no reason to use
GFP_NOIO as far as I can tell.
Furthermore I was thinking your patch is still too lowlevel, it's better
to use the swapcache entry/exit points that already do the hardness
checks and page_cache_release automatically plus it pins the swap page
so there's no risk of disk corruption etc...
So I rewritten the fix this way:
diff -urNp --exclude CVS --exclude BitKeeper --exclude {arch} --exclude .arch-ids x-ref/mm/page_io.c x/mm/page_io.c
--- x-ref/mm/page_io.c 2004-03-31 16:57:25.505978008 +0200
+++ x/mm/page_io.c 2004-03-31 17:06:07.028694504 +0200
@@ -139,7 +139,7 @@ struct address_space_operations swap_aop
/*
* A scruffy utility function to read or write an arbitrary swap page
- * and wait on the I/O.
+ * and wait on the I/O. The caller must have a ref on the page.
*/
int rw_swap_page_sync(int rw, swp_entry_t entry, struct page *page)
{
@@ -149,10 +149,9 @@ int rw_swap_page_sync(int rw, swp_entry_
};
lock_page(page);
-
- BUG_ON(page->mapping);
- page->mapping = &swapper_space;
- page->index = entry.val;
+ ret = add_to_swap_cache(page, entry);
+ if (unlikely(ret))
+ goto out_unlock;
if (rw == READ) {
ret = swap_readpage(NULL, page);
@@ -161,7 +160,12 @@ int rw_swap_page_sync(int rw, swp_entry_
ret = swap_writepage(page, &swap_wbc);
wait_on_page_writeback(page);
}
- page->mapping = NULL;
+
+ lock_page(page);
+ delete_from_swap_cache(page);
+ out_unlock:
+ unlock_page(page);
+
if (ret == 0 && (!PageUptodate(page) || PageError(page)))
ret = -EIO;
return ret;
I hope this will work (untested).
WARNING: multiple messages have this Message-ID (diff)
From: Andrea Arcangeli <andrea@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: vrajesh@umich.edu, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix
Date: Wed, 31 Mar 2004 17:07:18 +0200 [thread overview]
Message-ID: <20040331150718.GC2143@dualathlon.random> (raw)
In-Reply-To: <20040329144243.393d21a8.akpm@osdl.org>
On Mon, Mar 29, 2004 at 02:42:43PM -0800, Andrew Morton wrote:
> diff -puN mm/page_io.c~rw_swap_page_sync-fix mm/page_io.c
> --- 25/mm/page_io.c~rw_swap_page_sync-fix Mon Mar 29 14:41:08 2004
> +++ 25-akpm/mm/page_io.c Mon Mar 29 14:41:28 2004
> @@ -139,7 +139,7 @@ struct address_space_operations swap_aop
>
> /*
> * A scruffy utility function to read or write an arbitrary swap page
> - * and wait on the I/O.
> + * and wait on the I/O. The caller must have a ref on the page.
> */
> int rw_swap_page_sync(int rw, swp_entry_t entry, struct page *page)
> {
> @@ -151,8 +151,7 @@ int rw_swap_page_sync(int rw, swp_entry_
> lock_page(page);
>
> BUG_ON(page->mapping);
> - page->mapping = &swapper_space;
> - page->index = entry.val;
> + add_to_page_cache(page, &swapper_space, entry.val, GFP_NOIO);
>
> if (rw == READ) {
> ret = swap_readpage(NULL, page);
> @@ -161,7 +160,12 @@ int rw_swap_page_sync(int rw, swp_entry_
> ret = swap_writepage(page, &swap_wbc);
> wait_on_page_writeback(page);
> }
> - page->mapping = NULL;
> +
> + lock_page(page);
> + remove_from_page_cache(page);
> + unlock_page(page);
> + page_cache_release(page); /* For add_to_page_cache() */
> +
> if (ret == 0 && (!PageUptodate(page) || PageError(page)))
> ret = -EIO;
> return ret;
I checked this into CVS last night and today I got this new oops in
bugzilla:
hda: completing PM request, resume
Writing data to swap (18536 pages): .<1>Unable to handle kernel NULL pointer dereference at virtual address 00000004
printing eip:
c01daf24
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c01daf24>] Tainted: P
EFLAGS: 00010082 (2.6.4-40.3-default)
EIP is at radix_tree_delete+0x14/0x160
eax: 00000004 ebx: c16b6880 ecx: 00000016 edx: 00001d69
esi: 00001d69 edi: 00000010 ebp: 000011ae esp: f7329e1c
ds: 007b es: 007b ss: 0068
Process powersaved (pid: 4216, threadinfo=f7328000 task=f751f250)
Stack: 00000000 f51b6e00 00000004 00000006 f6326200 f63262bc 0000002e c0108d48
c041f4c0 00000000 000003fd 000026cd c041f4c0 c03ffd45 00000320 0000007b
0000007b ffffff00 c021b78e c16b6880 c0342d60 000011ae 000011ae 000011ae
Call Trace:
[<c0108d48>] common_interrupt+0x18/0x20
[<c021b78e>] serial_in+0x1e/0x40
[<c0150f2c>] swap_free+0x1c/0x30
[<c0152897>] remove_exclusive_swap_page+0x97/0x155
[<c013be2f>] __remove_from_page_cache+0x3f/0xa0
[<c013beab>] remove_from_page_cache+0x1b/0x27
[<c014fe5c>] rw_swap_page_sync+0x9c/0x1b0
[<c0135a9d>] do_magic_suspend_2+0x27d/0x7d0
[<c0125fb0>] process_timeout+0x0/0x10
[<c011ad1e>] __wake_up+0xe/0x20
[<f952be8d>] snd_intel8x0_suspend+0x1d/0x40 [snd_intel8x0]
[<c01e3586>] pci_device_suspend+0x16/0x20
[<c027701d>] do_magic+0x4d/0x130
[<c0135520>] software_suspend+0xd0/0xe0
[<c01fc176>] acpi_system_write_sleep+0xb5/0xd2
[<c01fc0c1>] acpi_system_write_sleep+0x0/0xd2
[<c015514e>] vfs_write+0xae/0xf0
[<c015522c>] sys_write+0x2c/0x50
[<c0107dc9>] sysenter_past_esp+0x52/0x79
Code: 8b 28 8d 7c 24 10 3b 14 ad a0 b9 41 c0 0f 87 18 01 00 00 8d
the oops is in a different place. It seems to bomb in
__remove_from_page_cache while calling radix_tree_delete like if the
radix_tree_insert didn't work out. I believe it's because you're not
checking for the retval of add_to_page_cache, if it runs oom in the
radix tree insert it will crash. You used GFP_NOIO, that's wrong, it
should be GFP_KERNEL to guarantee allocation. There's no reason to use
GFP_NOIO as far as I can tell.
Furthermore I was thinking your patch is still too lowlevel, it's better
to use the swapcache entry/exit points that already do the hardness
checks and page_cache_release automatically plus it pins the swap page
so there's no risk of disk corruption etc...
So I rewritten the fix this way:
diff -urNp --exclude CVS --exclude BitKeeper --exclude {arch} --exclude .arch-ids x-ref/mm/page_io.c x/mm/page_io.c
--- x-ref/mm/page_io.c 2004-03-31 16:57:25.505978008 +0200
+++ x/mm/page_io.c 2004-03-31 17:06:07.028694504 +0200
@@ -139,7 +139,7 @@ struct address_space_operations swap_aop
/*
* A scruffy utility function to read or write an arbitrary swap page
- * and wait on the I/O.
+ * and wait on the I/O. The caller must have a ref on the page.
*/
int rw_swap_page_sync(int rw, swp_entry_t entry, struct page *page)
{
@@ -149,10 +149,9 @@ int rw_swap_page_sync(int rw, swp_entry_
};
lock_page(page);
-
- BUG_ON(page->mapping);
- page->mapping = &swapper_space;
- page->index = entry.val;
+ ret = add_to_swap_cache(page, entry);
+ if (unlikely(ret))
+ goto out_unlock;
if (rw == READ) {
ret = swap_readpage(NULL, page);
@@ -161,7 +160,12 @@ int rw_swap_page_sync(int rw, swp_entry_
ret = swap_writepage(page, &swap_wbc);
wait_on_page_writeback(page);
}
- page->mapping = NULL;
+
+ lock_page(page);
+ delete_from_swap_cache(page);
+ out_unlock:
+ unlock_page(page);
+
if (ret == 0 && (!PageUptodate(page) || PageError(page)))
ret = -EIO;
return ret;
I hope this will work (untested).
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2004-03-31 15:07 UTC|newest]
Thread overview: 190+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.44.0403150527400.28579-100000@localhost.localdomain>
2004-03-21 22:10 ` [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix Rajesh Venkatasubramanian
2004-03-21 22:10 ` Rajesh Venkatasubramanian
2004-03-21 22:12 ` [RFC][PATCH 2/3] Dave & Hugh's objrmap patch Rajesh Venkatasubramanian
2004-03-21 22:12 ` Rajesh Venkatasubramanian
2004-03-21 22:13 ` [RFC][PATCH 3/3] Covert objrmap to use prio_tree Rajesh Venkatasubramanian
2004-03-21 22:13 ` Rajesh Venkatasubramanian
2004-03-21 22:26 ` URL typo Rajesh Venkatasubramanian
2004-03-21 22:26 ` Rajesh Venkatasubramanian
2004-03-22 0:46 ` [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix Andrea Arcangeli
2004-03-22 0:46 ` Andrea Arcangeli
2004-03-22 2:32 ` Rik van Riel
2004-03-22 2:32 ` Rik van Riel
2004-03-22 3:49 ` Rajesh Venkatasubramanian
2004-03-22 3:49 ` Rajesh Venkatasubramanian
2004-03-22 4:02 ` Rik van Riel
2004-03-22 4:02 ` Rik van Riel
2004-03-22 4:21 ` put_super for proc Abhishek Rai
2004-03-22 12:04 ` Maneesh Soni
2004-03-25 22:59 ` [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix Andrea Arcangeli
2004-03-25 22:59 ` Andrea Arcangeli
2004-03-26 4:06 ` Rajesh Venkatasubramanian
2004-03-26 4:06 ` Rajesh Venkatasubramanian
2004-03-26 7:53 ` Andrea Arcangeli
2004-03-26 7:53 ` Andrea Arcangeli
2004-03-26 15:43 ` Rajesh Venkatasubramanian
2004-03-26 15:43 ` Rajesh Venkatasubramanian
2004-03-26 17:58 ` Andrea Arcangeli
2004-03-26 17:58 ` Andrea Arcangeli
2004-03-27 19:51 ` Rajesh Venkatasubramanian
2004-03-27 19:51 ` Rajesh Venkatasubramanian
2004-03-29 17:22 ` Andrea Arcangeli
2004-03-29 17:22 ` Andrea Arcangeli
2004-03-29 17:50 ` Rajesh Venkatasubramanian
2004-03-29 17:50 ` Rajesh Venkatasubramanian
2004-03-29 18:01 ` Andrea Arcangeli
2004-03-29 18:01 ` Andrea Arcangeli
2004-03-29 20:40 ` Andrew Morton
2004-03-29 20:40 ` Andrew Morton
2004-03-29 22:24 ` Hugh Dickins
2004-03-29 22:24 ` Hugh Dickins
2004-03-29 22:54 ` Andrea Arcangeli
2004-03-29 22:54 ` Andrea Arcangeli
2004-03-29 23:08 ` William Lee Irwin III
2004-03-29 23:08 ` William Lee Irwin III
2004-03-29 22:39 ` Andrea Arcangeli
2004-03-29 22:39 ` Andrea Arcangeli
2004-03-29 22:42 ` Andrew Morton
2004-03-29 22:42 ` Andrew Morton
2004-03-31 15:07 ` Andrea Arcangeli [this message]
2004-03-31 15:07 ` Andrea Arcangeli
2004-03-31 15:26 ` Andrea Arcangeli
2004-03-31 15:26 ` Andrea Arcangeli
2004-03-31 16:45 ` Hugh Dickins
2004-03-31 16:45 ` Hugh Dickins
2004-03-31 17:28 ` Andrea Arcangeli
2004-03-31 17:28 ` Andrea Arcangeli
2004-04-01 0:45 ` Andrea Arcangeli
2004-04-01 0:45 ` Andrea Arcangeli
2004-04-01 1:22 ` Andrew Morton
2004-04-01 1:22 ` Andrew Morton
2004-04-01 1:26 ` Andrea Arcangeli
2004-04-01 1:26 ` Andrea Arcangeli
2004-04-01 1:51 ` Andrew Morton
2004-04-01 1:51 ` Andrew Morton
2004-04-01 2:01 ` Andrea Arcangeli
2004-04-01 2:01 ` Andrea Arcangeli
2004-04-01 5:05 ` Hugh Dickins
2004-04-01 5:05 ` Hugh Dickins
2004-04-01 13:35 ` Andrea Arcangeli
2004-04-01 13:35 ` Andrea Arcangeli
2004-04-01 15:09 ` Andrea Arcangeli
2004-04-01 15:09 ` Andrea Arcangeli
2004-04-01 15:15 ` Andrea Arcangeli
2004-04-01 15:15 ` Andrea Arcangeli
2004-04-02 0:15 ` Andrea Arcangeli
2004-04-02 0:15 ` Andrea Arcangeli
2004-04-02 0:52 ` Andrew Morton
2004-04-02 0:52 ` Andrew Morton
2004-04-02 1:06 ` Andrea Arcangeli
2004-04-02 1:06 ` Andrea Arcangeli
2004-04-02 1:03 ` Hugh Dickins
2004-04-02 1:03 ` Hugh Dickins
2004-04-02 1:16 ` Andrea Arcangeli
2004-04-02 1:16 ` Andrea Arcangeli
2004-04-02 1:36 ` Andrew Morton
2004-04-02 1:36 ` Andrew Morton
2004-04-02 2:00 ` Andrea Arcangeli
2004-04-02 2:00 ` Andrea Arcangeli
2004-04-02 2:08 ` Andrew Morton
2004-04-02 2:08 ` Andrew Morton
2004-04-02 2:22 ` Andrea Arcangeli
2004-04-02 2:22 ` Andrea Arcangeli
2004-04-02 6:05 ` Christoph Hellwig
2004-04-02 6:05 ` Christoph Hellwig
2004-04-02 7:07 ` Paul Mackerras
2004-04-02 7:07 ` Paul Mackerras
2004-04-02 7:11 ` Christoph Hellwig
2004-04-02 7:11 ` Christoph Hellwig
2004-04-02 15:28 ` Andrea Arcangeli
2004-04-02 15:28 ` Andrea Arcangeli
2004-04-02 15:22 ` Andrea Arcangeli
2004-04-02 15:22 ` Andrea Arcangeli
2004-04-02 15:27 ` Christoph Hellwig
2004-04-02 15:27 ` Christoph Hellwig
2004-04-02 15:38 ` Andrea Arcangeli
2004-04-02 15:38 ` Andrea Arcangeli
2004-04-02 15:45 ` Andrea Arcangeli
2004-04-02 15:45 ` Andrea Arcangeli
2004-04-02 9:43 ` Christoph Hellwig
2004-04-02 9:43 ` Christoph Hellwig
2004-04-02 10:21 ` Marc-Christian Petersen
2004-04-02 10:21 ` Marc-Christian Petersen
2004-04-02 10:55 ` Hugh Dickins
2004-04-02 10:55 ` Hugh Dickins
2004-04-02 16:46 ` Andrea Arcangeli
2004-04-02 16:46 ` Andrea Arcangeli
2004-04-02 18:59 ` Christoph Hellwig
2004-04-02 18:59 ` Christoph Hellwig
2004-04-02 19:29 ` Andrea Arcangeli
2004-04-02 19:29 ` Andrea Arcangeli
2004-04-02 19:54 ` Christoph Hellwig
2004-04-02 19:54 ` Christoph Hellwig
2004-04-02 20:35 ` Andrea Arcangeli
2004-04-02 20:35 ` Andrea Arcangeli
2004-04-03 8:40 ` Christoph Hellwig
2004-04-03 8:40 ` Christoph Hellwig
2004-04-03 15:20 ` Andrea Arcangeli
2004-04-03 15:20 ` Andrea Arcangeli
2004-04-03 15:59 ` Andrea Arcangeli
2004-04-03 15:59 ` Andrea Arcangeli
2004-04-03 17:02 ` Andrea Arcangeli
2004-04-03 17:02 ` Andrea Arcangeli
2004-04-05 9:59 ` Christoph Hellwig
2004-04-05 9:59 ` Christoph Hellwig
2004-04-05 12:11 ` Christoph Hellwig
2004-04-05 12:11 ` Christoph Hellwig
2004-04-05 16:08 ` Andrea Arcangeli
2004-04-05 16:08 ` Andrea Arcangeli
2004-04-06 4:22 ` Andrea Arcangeli
2004-04-06 4:22 ` Andrea Arcangeli
2004-04-06 4:43 ` Andrew Morton
2004-04-06 4:43 ` Andrew Morton
2004-04-06 5:14 ` Christoph Hellwig
2004-04-06 5:14 ` Christoph Hellwig
2004-04-06 21:54 ` Andrea Arcangeli
2004-04-06 21:54 ` Andrea Arcangeli
2004-04-07 1:39 ` Nathan Scott
2004-04-07 1:39 ` Nathan Scott
2004-04-06 5:16 ` Christoph Hellwig
2004-04-06 5:16 ` Christoph Hellwig
2004-04-06 16:01 ` Andrea Arcangeli
2004-04-06 16:01 ` Andrea Arcangeli
2004-04-07 1:33 ` Nathan Scott
2004-04-07 1:33 ` Nathan Scott
2004-04-03 17:40 ` Andrea Arcangeli
2004-04-03 17:40 ` Andrea Arcangeli
2004-04-03 20:02 ` Andrew Morton
2004-04-03 20:02 ` Andrew Morton
2004-04-03 23:27 ` Andrea Arcangeli
2004-04-03 23:27 ` Andrea Arcangeli
2004-04-03 23:46 ` Andrew Morton
2004-04-03 23:46 ` Andrew Morton
2004-04-04 0:40 ` Andrea Arcangeli
2004-04-04 0:40 ` Andrea Arcangeli
2004-04-08 19:10 ` Bill Davidsen
2004-04-20 22:29 ` Pavel Machek
2004-04-02 20:13 ` Pavel Machek
2004-04-02 20:13 ` Pavel Machek
2004-04-02 21:42 ` Andrea Arcangeli
2004-04-02 21:42 ` Andrea Arcangeli
2004-04-02 21:45 ` Pavel Machek
2004-04-02 21:45 ` Pavel Machek
2004-04-02 21:49 ` Andrea Arcangeli
2004-04-02 21:49 ` Andrea Arcangeli
2004-03-29 18:12 ` Hugh Dickins
2004-03-29 18:12 ` Hugh Dickins
2004-03-29 18:20 ` Andrea Arcangeli
2004-03-29 18:20 ` Andrea Arcangeli
2004-03-29 18:38 ` Christoph Hellwig
2004-03-29 18:38 ` Christoph Hellwig
2004-03-29 21:30 ` 2.6.5-rc2-aa5 Rajesh Venkatasubramanian
2004-03-29 22:50 ` 2.6.5-rc2-aa5 Andrea Arcangeli
2004-04-05 3:14 ` [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix Rajesh Venkatasubramanian
2004-04-05 3:14 ` Rajesh Venkatasubramanian
2004-04-05 4:42 ` Andrea Arcangeli
2004-04-05 4:42 ` Andrea Arcangeli
2004-03-26 12:26 ` William Lee Irwin III
2004-03-26 12:26 ` William Lee Irwin III
2004-03-26 19:18 ` Andrea Arcangeli
2004-03-26 19:18 ` Andrea Arcangeli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040331150718.GC2143@dualathlon.random \
--to=andrea@suse.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=vrajesh@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.