public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Adrian Hunter <ext-adrian.hunter@nokia.com>
To: dwmw2@infradead.org
Cc: "Bityutskiy Artem \(Nokia-M/Helsinki\)"
	<Artem.Bityutskiy@nokia.com>,
	linux-mtd@lists.infradead.org
Subject: JFFS2 deadlock in erase callback
Date: Mon, 08 Oct 2007 10:43:10 +0300	[thread overview]
Message-ID: <4709DF8E.1030707@nokia.com> (raw)

Hi

We were planning to revert the following:

    commit d364fb18cd991734eb54aa8840e70030b0c9f699
    Author: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
    Date:   Wed Jun 27 01:24:09 2007 +0200

       [JFFS2] Reduce time for which erase_free_sem is held during erase.
    
       With current desing erase_free_sem is locked every time the flash
       block is being erased. For NOR flashes - ~1 second is needed to erase
       single flash block. In the worst case scenario erase_free_sem may be
       locked for a couple of seconds when the number of blocks is being
       erased (e.g. after large file was removed). When erase_free_sem is
       locked all read/write operations for given JFFS2 partition are locked
       too - in effect from time to time access to the JFFS2 partition is
       locked for a number of seconds. This fix makes critical section in
       flash erasing procedure shorter - now erase_free_sem is locked around
       erase_completion_lock spinlock only.
    
       Originally from Radoslaw Bisewski
       Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
       Signed-off-by: David Woodhouse <dwmw2@infradead.org>


because of the deadlock it caused via the erase callback.  Artem, who is away, said you were against moving the callback, but I see you have now done that with the following patch:

    commit 49defc015ff58fda46a3afa3462dfdfa69bc8401
    Author: David Woodhouse <dwmw2@infradead.org>
    Date:   Sat Oct 6 15:01:59 2007 -0400

        [MTD] [NAND] Avoid deadlock in erase callback; release chip lock first.
    
        When the erase callback performs some other action on the flash, it's
        highly likely to deadlock unless we actually release the chip lock
        before calling it.
    
        Signed-off-by: David Woodhouse <dwmw2@infradead.org>


Can you confirm, that adding the "Avoid deadlock..." patch is better than reverting "Reduce time..." patch.

Note the "Avoid deadlock..." change is needed for OneNAND also.


Regards
Adrian Hunter

             reply	other threads:[~2007-10-08  7:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-08  7:43 Adrian Hunter [this message]
2007-10-10 19:51 ` JFFS2 deadlock in erase callback Thomas Gleixner

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=4709DF8E.1030707@nokia.com \
    --to=ext-adrian.hunter@nokia.com \
    --cc=Artem.Bityutskiy@nokia.com \
    --cc=dwmw2@infradead.org \
    --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