From: David Woodhouse <dwmw2@infradead.org>
To: amul.saha@samsung.com
Cc: linux-mtd@lists.infradead.org
Subject: Re: JFFS2 : non-existent inode
Date: Mon, 09 Mar 2009 13:51:06 +0000 [thread overview]
Message-ID: <1236606666.572.178.camel@macbook.infradead.org> (raw)
In-Reply-To: <12102132.458451236145386653.JavaMail.weblogic@epml05>
On Wed, 2009-03-04 at 05:43 +0000, AMUL KUMAR SAHA wrote:
> Hello David,
>
> Environment : Flex-OneNAND 8Gb, Apollon Board, linux-2.6.26
>
> I have just started with JFFS2 .
>
> We were running fsstress on 5 Boards for 5 Days .
> On 2 out of 5 boards, we observed the message "requestied to read an nonexistent ino",
> On Repetition, the BUG seems to be random.
>
> Dwelled inside the code and thought of a possible scenario for the occurence.
> I found the following explanation to it, appropriate; to my minimal knowledge :
>
> 1) 2 or more processes(say, P1 and P2) handling
> GC(jffs2_gc_fetch_inode) enter the function jffs2_iget almost
> together, before getting a mutex_lock.
They shouldn't be very close together -- GC is protected by the
alloc_sem mutex, and shouldn't be happening concurrently at all. But
maybe it's one thread doing GC while another thread is actually trying
to open the inode in question for real?
> 2) When a request for a lock is raised, one of the processes(P1) gets
> the mutex_lock(&f->sem) and the other one waits.
It uses iget_locked(). The first caller will get a _locked_ inode with
the I_NEW bit set. It will go ahead and fill in the inode appropriately,
then call unlock_new_inode() to clear the I_NEW bit and unlock the
inode.
Then the second caller will return from iget_locked(). The I_NEW bit
won't be set, and it'll return immediately. So I don't think your
scenario is possible.
> 3) P1 deletes the inode-cache(f->inocache), and releases the lock.
Why would it delete the inode-cache? Doesn't that only ever happen in GC
when the final physical node of the inode has been deleted from the
medium?
> 4) Now, when P2 ends up calling jffs2_do_read_inode with 'inode->ino'
> available locally in that function (unaware of the fact that, this
> particular inode was just destroyed).
> 5) JFFS2-Error with the message "requestied to read an nonexistent
> ino" is displayed.
Hm, can you make that a WARN() and show the backtrace?
> In the mean time, I have come up with my own fix to this situation.
> Just wanting to know if my explanation makes sense, so that I can go
> ahead with posting the patch in mailing-list.
You might be close, but I'm not convinced you have it exactly right.
--
dwmw2
next prev parent reply other threads:[~2009-03-09 13:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-04 5:43 JFFS2 : non-existent inode AMUL KUMAR SAHA
2009-03-09 13:51 ` David Woodhouse [this message]
2009-03-11 15:10 ` Amul Kumar Saha
2009-03-11 15:18 ` David Woodhouse
-- strict thread matches above, loose matches on Subject: below --
2012-02-12 19:24 geraldwalden
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=1236606666.572.178.camel@macbook.infradead.org \
--to=dwmw2@infradead.org \
--cc=amul.saha@samsung.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