Possible MTD bug in 2.6.15

[Jim Ramsay]

We have an interesting problem with MTD and a flash chip on an
embedded board.  The problem stems from the fact that due to hardware
constraints we can only access up to 32M of address space on an
attached flash device.  However, the actual part attached to the board
is 64M.  Yes, I know this is not likely to happen, but it points at a
kernel bug which will happen if you ever specify a MTD map->size which
is less than the actual size of the CFI flash chip.

When we specify the map->size as 32M (0x02000000) and do the CFI
probe, the chip is properly detected, but then in gen_probe.c the
following happens:

- genprobe_ident_chips is run
  - It sets cfi.chipshift based on the cfi.cfiq->DevSize, which gets
properly set to 0x1a (64M flash chip).
  - It then sets the local "max_chips" variable by shifting down
map->size by this chipshift, which shifts our size (0x02000000 = 32M)
down all the way to 0.
  - Since 'max_chips' is zero, no memory is allocated for this chip,
and the waitqueue is not initialized.  The will cause a kernel panic
later, if you ever try to read from this chip.

The routine completes and you are left with a seemingly valid MTD
device.  However, if you ever try to read or write this device, the
waitqueue is uninitialized, which causes a nasty kernel panic.

My proposed fix is attached (a patch against 2.6.15).  After shifting
the map->size down by cfi.chipshift, I just ensure that max_chips is
at least one.  Does this seem like a reasonable fix?

Note: Please CC my email address in reply, as I am not currently
subscribed to the linux-kernel list.

--
Jim Ramsay
"Me fail English?  That's unpossible!"

Attachment: mtd_wrong_size_bug.patch
Description: Binary data