From: "Artem B. Bityuckiy" <abityuckiy@yandex.ru>
To: Ferenc Havasi <havasi@inf.u-szeged.hu>
Cc: linux-mtd@lists.infradead.org
Subject: Re: JFFS2 bugfix
Date: Mon, 18 Oct 2004 16:16:04 +0400 [thread overview]
Message-ID: <4173B404.6040100@yandex.ru> (raw)
In-Reply-To: <4173AFAE.6060303@inf.u-szeged.hu>
Hello Ferenc,
Ferenc Havasi wrote:
> Hi Artem,
>
> I tried reproduce your bug:
>
> > I've found bug in JFFS2. When there is no free space left on JFFS2
> > file system, and somebody for example tries to creade new directory,
> > JFFS2 frees memory twice.
> >
> > See dir.c, jffs2_create(), line 216.
> >
> > jffs2_do_create returns error.
> > jffs2_clear_inode(inode) is called and frees the jffs2_sb_info,
> > jffs2_full_dnode, etc.
> > iput(inode) is called, calling in turn the jffs2_clear_inode, and the
> > same structures are freed for the second time. This leads to the slab
> > cache corruption.
>
> I was not successful. I write JFFS2 to full (there was no left space),
> than I tried to mkdir, but there was no slab cache corruption.
Did you see system message "No space left on device"?
How did you see that slab is OK? I've found this when I've enabled the
correspondent option in "Linux Hacking" (no sure, possibly
CONFIG_DEBUG_SLAB).
>
> > --- dir.c 2004-10-16 21:02:22.886276648 +0400
> > +++ dir_corrected.c 2004-10-16 21:03:10.843766654 +0400
> > @@ -217,7 +217,6 @@
> > dentry->d_name.name, dentry->d_name.len);
> >
> > if (ret) {
> > - jffs2_clear_inode(inode);
> > make_bad_inode(inode);
> > iput(inode);
> > jffs2_free_raw_inode(ri);
>
> If I know well now jffs2_clear_inode only try to free only the fragtree,
> its dirents... but the inode is still present, and need to handle.
Yes, it does. But after this the iput() function is called. The iput()
calls jffs2_clear_inode too. And the same data structures (fragtrees
with full_dnodes, direntries) are freed one more time. This is not good :-)
>
> Maybe I am wrong. I am not very familiar with this part of JFFS2.
> Are you sure that this is really a bug?
Hmm. Yes, I think so... May be small one :-)
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
next prev parent reply other threads:[~2004-10-18 12:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-16 17:14 JFFS2 bugfix Artem B. Bityuckiy
2004-10-18 11:57 ` Ferenc Havasi
2004-10-18 12:16 ` Artem B. Bityuckiy [this message]
2004-10-19 7:57 ` Ferenc Havasi
2004-10-19 8:06 ` Artem B. Bityuckiy
2004-10-19 9:16 ` David Woodhouse
[not found] ` <4174D508.8050508@yandex.ru>
2004-10-19 10:09 ` JFFS2 compression Ferenc Havasi
2004-10-19 10:14 ` David Woodhouse
2004-10-20 9:16 ` Ferenc Havasi
2004-10-20 9:16 ` David Woodhouse
2004-10-20 11:13 ` Artem B. Bityuckiy
2004-10-20 11:53 ` Ferenc Havasi
2004-10-20 12:06 ` Artem B. Bityuckiy
2004-10-19 10:48 ` Artem B. Bityuckiy
2004-10-19 12:06 ` Ferenc Havasi
2004-10-19 12:19 ` Artem B. Bityuckiy
2004-10-19 13:43 ` David Woodhouse
2004-10-19 14:07 ` Ferenc Havasi
2004-10-19 14:08 ` David Woodhouse
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=4173B404.6040100@yandex.ru \
--to=abityuckiy@yandex.ru \
--cc=havasi@inf.u-szeged.hu \
--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