From: Andreas Dilger <adilger@sun.com>
To: Mingming Cao <cmm@us.ibm.com>
Cc: Badari Pulavarty <pbadari@gmail.com>,
Girish Shilamkar <girish@clusterfs.com>,
Avantika Mathur <mathur@linux.vnet.ibm.com>,
ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH][RFC]JBD2: Fix journal checksum kernel oops on NUMA
Date: Tue, 6 Nov 2007 09:33:38 +0800 [thread overview]
Message-ID: <20071106013338.GC3900@webber.adilger.int> (raw)
In-Reply-To: <1194304896.3987.27.camel@localhost.localdomain>
On Nov 05, 2007 15:21 -0800, Mingming Cao wrote:
> On Mon, 2007-11-05 at 10:07 -0800, Badari Pulavarty wrote:
> > On Tue, 2007-11-06 at 00:15 +0800, Andreas Dilger wrote:
> > > My point is that there is a LOT of code in ext[234] that dereferences
> > > bh->b_data without kmap() (e.g. group descriptors, bitmaps, superblock,
> > > inode tables, etc). Does that imply that something is forcing those
> > > bh pages into lowmem, or is the journal bh page in question being
> > > allocated in some different way that allows it to be in highmem?
> >
> > Yes. You are right. Its been a while since I had to deal with HIGHMEM.
> > All the meta-data should be in LOWMEM. I asked Mingming to verify
> > what the buffer-head is pointing to when it has HIGHMEM page.
> >
>
> The buffer_heads with NULL bh->b_data(under the "start_journal_io"
> branch in jbd2_journal_commit_transaction() code) is created by
> jbd2_journal_write_metadata_buffer().
>
> Noticed that in jbd2_journal_write_metadata_buffer(), there are
> multiple places which do kmap_atomic() to access the journal bh page
> (new_page). In the normal case the new_page is pointing to the bh
> pages, which(the page) was initially allocated by _page_cache_alloc()
> (sb_bread->__bread()->_...>find_or_create_page()->_page_cache_alloc()
>
> In the case it need a data copy (the buffer start with the
> JBD2_MAGIC_NUMBER?), a new page is allocated by by
> __get_free_pages()(via jbd2_alloc, which is possible allocated in
> highmem. __get_free_pages calls alloc_pages() directly, doesn't seem to
> have highmem handling like __page_cache_alloc().
So long as there is a good explanation, and the code in jbd is expecting
to kmap() the b_data pages always then I have no objection to the patch.
I was just worried there was some other kind of bug involved here and
wanted to ensure that the root cause was understood. It might be prudent
to grep for b_data in the jbd2 code to verify there are no other places
that dereference the bh page without kmap first.
Thanks for the investigation Mingming.
Girish, can you please include this fix into our patch series.
Cheers, Andreas
--
Andreas Dilger
Sr. Software Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
prev parent reply other threads:[~2007-11-06 1:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-30 18:16 jbd2_journal_commit_transaction oops Avantika Mathur
2007-08-31 9:21 ` Girish Shilamkar
2007-08-31 21:32 ` Avantika Mathur
2007-09-13 9:49 ` Girish Shilamkar
2007-11-02 0:40 ` [PATCH][RFC]JBD2: Fix journal checksum kernel oops on NUMA Mingming Cao
2007-11-02 5:20 ` Andreas Dilger
2007-11-02 16:31 ` Badari Pulavarty
2007-11-03 1:36 ` Andreas Dilger
2007-11-05 16:04 ` Badari Pulavarty
2007-11-05 16:15 ` Andreas Dilger
2007-11-05 18:07 ` Badari Pulavarty
2007-11-05 23:21 ` Mingming Cao
2007-11-06 1:33 ` Andreas Dilger [this message]
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=20071106013338.GC3900@webber.adilger.int \
--to=adilger@sun.com \
--cc=cmm@us.ibm.com \
--cc=girish@clusterfs.com \
--cc=linux-ext4@vger.kernel.org \
--cc=mathur@linux.vnet.ibm.com \
--cc=pbadari@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).