Deadlock while accessing mtdchar device while erase in progress

Deadlock while accessing mtdchar device while erase in progress

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]

Hi everybody,

I'm having troubles fixing an MTD-related deadlock. I'm not sure if the 
problem comes from an MTD and/or JFFS2 kernel bug, or from some userspace 
operation performed as root that I shouldn't have started in the first place. 
I'd appreciate if someone could share his thoughts (and experience :-)) about 
this.

Some background.

My embedded system has a single NOR flash chip (cfi_cmdset_0002 driver) with 
128kB sectors. Flash space is divided in 4 partitions, the last one used with 
a JFFS2 filesystem.

A userspace process run as root sets its scheduling policy to SCHED_RR. It 
writes 400kB of data to the JFFS2 filesystem and restarts by exec()ing 
itself, inheriting the SCHED_RR policy.

Soon after being restarted, it opens /dev/mtd0 (boot loader partition) and 
reads a few bytes of data. It then close() /dev/mtd0, at which point the 
kernel deadlocks.

I added debugging messages to the MTD subsystem and it turned out my process 
blocks in cfi_amdstd_sync (drivers/mtd/chips/cfi_cmdset_0002.c). chip->state 
is set to FL_ERASING, and the kernel keeps scheduling in the default case.

I'm not sure what goes wrong. I expect the JFFS2 garbage collector to have 
kicked in. It might be erasing sectors when I close() /dev/mtd0, at which 
point the mtdchar driver tries to sync() the flash and locks in 
cfi_amdstd_sync because my process, being scheduled with a SCHED_RR policy, 
never gives the JFFS2 garbage collector a chance to run. That's just a wild 
guess though.

Any help regarding how to better diagnose the problem (to confirm or reject 
the above suspicion) will be appreciated. A fix would be even more 
welcome :-)

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Deadlock while accessing mtdchar device while erase in progress

[Laurent Pinchart]

Hi everybody,

I sent a mail two weeks ago about an MTD-related deadlock. I haven't received 
any answer so far, so I'm pinging the list just in case the message was 
missed. Here's the original mail.

I'm having troubles fixing an MTD-related deadlock. I'm not sure if the 
problem comes from an MTD and/or JFFS2 kernel bug, or from some userspace 
operation performed as root that I shouldn't have started in the first place. 
I'd appreciate if someone could share his thoughts (and experience :-)) about 
this.

Some background.

My embedded system has a single NOR flash chip (cfi_cmdset_0002 driver) with 
128kB sectors. Flash space is divided in 4 partitions, the last one used with 
a JFFS2 filesystem.

A userspace process run as root sets its scheduling policy to SCHED_RR. It 
writes 400kB of data to the JFFS2 filesystem and restarts by exec()ing 
itself, inheriting the SCHED_RR policy.

Soon after being restarted, it opens /dev/mtd0 (boot loader partition) and 
reads a few bytes of data. It then close() /dev/mtd0, at which point the 
kernel deadlocks.

I added debugging messages to the MTD subsystem and it turned out my process 
blocks in cfi_amdstd_sync (drivers/mtd/chips/cfi_cmdset_0002.c). chip->state 
is set to FL_ERASING, and the kernel keeps scheduling in the default case.

I'm not sure what goes wrong. I expect the JFFS2 garbage collector to have 
kicked in. It might be erasing sectors when I close() /dev/mtd0, at which 
point the mtdchar driver tries to sync() the flash and locks in 
cfi_amdstd_sync because my process, being scheduled with a SCHED_RR policy, 
never gives the JFFS2 garbage collector a chance to run. That's just a wild 
guess though.

Any help regarding how to better diagnose the problem (to confirm or reject 
the above suspicion) will be appreciated. A fix would be even more 
welcome :-)

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75