[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1194286053.17333.14.camel@dyn9047017100.beaverton.ibm.com>
Date: Mon, 05 Nov 2007 10:07:33 -0800
From: Badari Pulavarty <pbadari@...il.com>
To: Andreas Dilger <adilger@....com>
Cc: Mingming Cao <cmm@...ibm.com>,
Girish Shilamkar <girish@...sterfs.com>,
Avantika Mathur <mathur@...ux.vnet.ibm.com>,
ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH][RFC]JBD2: Fix journal checksum kernel oops on NUMA
On Tue, 2007-11-06 at 00:15 +0800, Andreas Dilger wrote:
> On Nov 05, 2007 08:04 -0800, Badari Pulavarty wrote:
> > On Sat, 2007-11-03 at 09:36 +0800, Andreas Dilger wrote:
> > > But... this implies that every user of bh->b_data needs to kmap, and I
> > > don't see that in the code anywhere else. That makes me think something
> > > else is going wrong here.
> >
> > Most cases, this is handled in ll_rw_block() code - when we submit the
> > buffer head for IO. If the page is in highmem, we will end up creating
> > a bounce bufer for it.
> >
> > In our case, JBD code is trying to look at the data to do checksum
> > on it. Thats why we have to kmap() the page before looking.
>
> 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.
Thanks,
Badari
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists