lkml.org 
[lkml]   [2006]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.18 ext3 panic.
Jan Kara wrote:

>> Talking with Stephen, it seemed like the page lock should synchronize these
>> threads, but I've found that we can get to journal_dirty_data acting on the
>> buffer heads w/o having the page locked...
> Yes, PageLock should protect us. Where can we call
> journal_dirty_data() without PageLock? I see the following callers:
> ext3_ordered_commit_write - should have PageLock
> ext3_ordered_writepage - has PageLock
> ext3_block_truncate_page - has PageLock
>
> And that are all callers from ext3. Am I missing something?
>
> Honza

I put an assert about the page being locked in journal_dirty_data, and hit it
right away. I'll look a bit more but I think this is how I got there:


ext3_ordered_writepage <-- assert PageLocked
...
block_write_full_page
__block_write_full_page
unlock_page()
...
walk_page_buffers
journal_dirty_data_fn
ext3_journal_dirty_data
journal_dirty_data <-- find page unlocked

there's a comment in ext3_ordered_writepage:

/*
* The page can become unlocked at any point now, and
* truncate can then come in and change things. So we
* can't touch *page from now on. But *page_bufs is
* safe due to elevated refcount.
*/

-Eric
-
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/

\
 
 \ /
  Last update: 2006-10-12 15:23    [W:0.084 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site