Messages in this thread Patch in this message | | | Date | Fri, 12 Mar 2004 12:03:22 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] per-backing dev unplugging #2 |
| |
Chris Mason <mason@suse.com> wrote: > > During a mixed load test including fsx-linux and a bunch of procs > running cp/read/rm loops, I got a null pointer deref with the call > trace: > > __lock_page->sync_page->block_sync_page > > I don't see how we can trust page->mapping in this path, can't it > disappear? If so, it would be a bug without Jens' patch too, just > harder to hit.
yup. I wonder why you hit it now.
diff -puN fs/buffer.c~per-backing_dev-unplugging-block_sync_page-fix fs/buffer.c --- 25/fs/buffer.c~per-backing_dev-unplugging-block_sync_page-fix Fri Mar 12 11:59:37 2004 +++ 25-akpm/fs/buffer.c Fri Mar 12 12:00:20 2004 @@ -2928,7 +2928,10 @@ EXPORT_SYMBOL(try_to_free_buffers); int block_sync_page(struct page *page) { - blk_run_address_space(page->mapping); + struct address_space *mapping = page->mapping; + + if (mapping) + blk_run_address_space(mapping); return 0; } This should be sufficient. All callers of lock_page() should have a ref on the inode so ->mapping should be stable even if truncate whips the page off the inode.
page reclaim doesn't take an inode ref, but it doesn't perform synchronous lock_page() either.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |