public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurentp@cse-semaphore.com>
To: linux-mtd@lists.infradead.org
Subject: Deadlock while accessing mtdchar device while erase in progress
Date: Fri, 28 Dec 2007 11:04:26 +0100	[thread overview]
Message-ID: <200712281104.27663.laurentp@cse-semaphore.com> (raw)

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

             reply	other threads:[~2007-12-28 10:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-28 10:04 Laurent Pinchart [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-12-17 10:12 Deadlock while accessing mtdchar device while erase in progress Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200712281104.27663.laurentp@cse-semaphore.com \
    --to=laurentp@cse-semaphore.com \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox