Hi,
I answered my own question. It looks like we could have pages
with buffers without page->mapping. In such cases, we shouldn't
de-ref page->mapping in drop_buffers(). Here is the trivial
patch to fix it.
Thanks,
Badari
On Wed, 2005-04-27 at 16:38, Badari Pulavarty wrote:
> Hi Andrew,
>
> We ran into a panic in drop_buffers() while running some networking
> tests and I am wondering if this a valid case. try_to_free_buffers()
> seems to call drop_buffers() even if the mapping is NULL. drop_buffers()
> seems to de-ref the mapping. This is causing NULL pointer deref.
>
> But, is "mapping == NULL" still valid case here ? Can we be in the
> code to drop buffers and have mapping NULL ? We would be in this
> code only if PagePrivate() is set. Can we have page private with
> out a valid mapping ?
>
> Thanks,
> Badari
>
> int try_to_free_buffers(struct page *page)
> {
> struct address_space * const mapping = page->mapping;
> ....
>
> if (mapping == NULL) { /* can this still happen? */
> ret = drop_buffers(page, &buffers_to_free);
> goto out;
> }
> }
>
> drop_buffers(struct page *page, struct buffer_head **buffers_to_free)
> {
> ....
> if (buffer_write_io_error(bh))
> set_bit(AS_EIO, &page->mapping->flags); <<<<<<
> ...
> }
>
> 1:mon> e
> cpu 0x1: Vector: 300 (Data Access) at [c00000007ff4b620]
> pc: c0000000000bd524: .drop_buffers+0x40/0xcc
> lr: c0000000000bd614: .try_to_free_buffers+0x64/0xf4
> sp: c00000007ff4b8a0
> msr: 8000000000009032
> dar: 60
> dsisr: 40000000
> current = 0xc00000000fe7e040
> paca = 0xc0000000003da800
> pid = 40, comm = kswapd1
>
> 1:mon> t
> [c00000007ff4b920] c0000000000bd614 .try_to_free_buffers+0x64/0xf4
> [c00000007ff4b9c0] c0000000000baadc .try_to_release_page+0x88/0x9c
> [c00000007ff4ba40] c000000000099418 .shrink_list+0x3a0/0x608
> [c00000007ff4bb90] c000000000099a04 .shrink_cache+0x384/0x610
> [c00000007ff4bcd0] c00000000009a4d4 .shrink_zone+0x104/0x140
> [c00000007ff4bd70] c00000000009aaf0 .balance_pgdat+0x270/0x448
> [c00000007ff4be90] c00000000009ade4 .kswapd+0x11c/0x120
> [c00000007ff4bf90] c000000000018ad0 .kernel_thread+0x4c/0x6c
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Signed-off-by: Badari Pulavarty <[email protected]>
--- linux-2.6.12-rc2.org/fs/buffer.c 2005-04-27 07:19:44.000000000 -0700
+++ linux-2.6.12-rc2/fs/buffer.c 2005-04-27 07:20:34.000000000 -0700
@@ -2917,7 +2917,7 @@ drop_buffers(struct page *page, struct b
bh = head;
do {
- if (buffer_write_io_error(bh))
+ if (buffer_write_io_error(bh) && page->mapping)
set_bit(AS_EIO, &page->mapping->flags);
if (buffer_busy(bh))
goto failed;
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]