On Tue, Oct 30, 2012 at 2:21 AM, Jacob Burkholder
[off-list ref] wrote:

Greetings!

We are having an issue with linux 3.6.3 on mips64 with mtd and jffs2.
The platform is a custom Broadcom XLS board.  The issue occurs when a
jffs2 is unmounted.  It does not occur with ubifs for what its worth.

What happens is the bdi-default thread gets an unaligned kernel access
exception.  The unaligned exception is a red herring, the address is
aligned but it is a bad address.  A boot log and stack trace from the
bdi-default thread is included below as well as some gdb debugging
output.  I tracked this down to the backing_dev_info structures that
are used with mtd devices, mtd_bdi_unmappable, mtd_bdi_ro_mappable,
mtd_bdi_rw_mappable, in mtdcore.c around line 338.  The mtd device in
question is nand so uses the mtd_bdi_unmappable backing_dev_info is
used.  When the jffs2 is unmounted the the bdi_forker_thread gets a
KILL_THREAD signal and calls bdi_clear_pending on the backing_dev_info
structure mentioned above.  This is turn calls
wake_up_bit(&bdi->state, BDI_pending);, wake_up_bit looks up the zone
for the page that the passed address is in and this seems to be the
problem.  The backing_dev_info structures are statically allocated in
the kernel data section and these addresses don't seem to have a vm
zone structure.  I set a breakpoint in wake_up_bit and can that it gets
called on other addresses which all start with 0xa8000000, finally it
gets passed the address in the mtd_bdi_unmappable structure and then
crashes.  I changed the backing_dev_info structures to be allocated
with kzalloc and the problem goes away and jffs2 generally works.
We link our kernel at address 0xffffffff80100000 and this is what our
bootloader expects.  I tried to change this to link at 0xa800000001000000,
which would seem to put the kernel data section where the bdi thread
expects its backing_dev_info structures to be allocated, but our
bootloader won't boot the image and I don't know if its the correct way
to deal with the problem.  I don't think this is an mtd problem since
other platforms use these files unmodified, so not sure where to start.

Thanks for any hints.

We had seen the same issue here, and worked around it the same way
(i.e use dynamic allocation for the backing dev structures).

I ran across a similar issue in using built-in DTB (basically, kernel
data address does not work for virt_to_phys/phys_to_virt in 64-bit
when the load address is in CKSEG0).  There I did something like this:

ptr = phys_to_virt(__pa(kernel_data_ptr));

This works since __pa knows about CKSEG0 addresses in 64bit.


JC.