Highmem issues with MMC filesystem

[Nicolas Pitre]

On Thu, 18 Mar 2010, Russell King - ARM Linux wrote:

> On Thu, Mar 18, 2010 at 12:17:50PM -0400, Nicolas Pitre wrote:
> > On Thu, 18 Mar 2010, Russell King - ARM Linux wrote:
> > > What exactly is the problem that we're discussing?  Is it that the data
> > > on the block device is becoming corrupted, or is the data being read off
> > > the block device corrupted?
> > 
> > Data read from a DMA based block device is corrupted in memory and 
> > causing all sorts of misbehavior such as segmentation faults in user 
> > space, or EXT2 complaining about broken filesystem metadata.
> 
> Isn't ext2 metadata read into lowmem pages?

Possible.  I've not looked at it closely enough to know for sure.

> The ext2 bitmap code sources its backing store from the old fs buffercache
> code, which can only use lowmem - so the ext2 bitmaps are in lowmem (see
> set_bh_page).  The superblock comes from the buffercache (grep for sb_bread)
> as well, so that's lowmem, and it looks to me like inode reading also
> comes via the buffercache.
> 
> It seems that all ext2 metadata is in lowmem, so I don't get the highmem
> interaction causing ext2 fs metadata corruption.

Well, some EXT2 errors appear randomly through the kernel console output 
and get mixed with all the avalenge of user space processes crashing due 
to strange errors or simply segfaulting during a boot.  Luckily when 
that happens the user space wasn't even able to remount the root fs 
read-write, so performing a fsck after a reboot (without highmem pages) 
reveals a sane and clean filesystem.


Nicolas