From: Eric Sandeen <sandeen@sandeen.net>
To: Jan Kara <jack@suse.cz>
Cc: Eric Sandeen <esandeen@redhat.com>,
Badari Pulavarty <pbadari@us.ibm.com>,
Dave Jones <davej@redhat.com>, Andrew Morton <akpm@osdl.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.18 ext3 panic.
Date: Thu, 12 Oct 2006 08:20:59 -0500 [thread overview]
Message-ID: <452E413B.10002@sandeen.net> (raw)
In-Reply-To: <20061012122820.GK9495@atrey.karlin.mff.cuni.cz>
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
next prev parent reply other threads:[~2006-10-12 13:21 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-02 19:47 2.6.18 ext3 panic Dave Jones
2006-10-03 5:22 ` Dave Jones
2006-10-03 5:43 ` Eric Sandeen
2006-10-03 6:19 ` Andrew Morton
2006-10-03 6:40 ` Dave Jones
2006-10-03 16:45 ` Dave Jones
2006-10-09 19:46 ` Eric Sandeen
2006-10-09 19:59 ` Eric Sandeen
2006-10-09 21:59 ` Badari Pulavarty
2006-10-09 22:50 ` Dave Jones
2006-10-10 14:11 ` Jan Kara
2006-10-10 18:42 ` Andrew Morton
2006-10-10 22:03 ` Eric Sandeen
2006-10-10 22:25 ` Badari Pulavarty
2006-10-11 1:43 ` Eric Sandeen
2006-10-11 10:33 ` Jan Kara
2006-10-11 13:44 ` Eric Sandeen
2006-10-11 14:22 ` Jan Kara
2006-10-11 17:54 ` Badari Pulavarty
2006-10-12 2:36 ` Eric Sandeen
2006-10-12 4:34 ` John Wendel
2006-10-12 6:57 ` Jan-Benedict Glaw
2006-10-12 12:28 ` Jan Kara
2006-10-12 13:20 ` Eric Sandeen [this message]
2006-10-12 16:40 ` Andrew Morton
2006-10-12 16:44 ` Eric Sandeen
2006-10-12 20:07 ` Eric Sandeen
2006-10-12 21:55 ` Badari Pulavarty
2006-10-12 21:57 ` Eric Sandeen
2006-10-12 22:34 ` Badari Pulavarty
2006-10-13 7:56 ` Jan Kara
2006-10-13 16:08 ` Eric Sandeen
2006-10-16 16:54 ` Jan Kara
2006-10-16 16:56 ` Eric Sandeen
2006-10-09 22:40 ` Jan-Benedict Glaw
2006-10-10 13:16 ` Jan Kara
2006-10-10 16:39 ` Jan-Benedict Glaw
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=452E413B.10002@sandeen.net \
--to=sandeen@sandeen.net \
--cc=akpm@osdl.org \
--cc=davej@redhat.com \
--cc=esandeen@redhat.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=pbadari@us.ibm.com \
/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.