linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Artem B. Bityuckiy" <dedekind@infradead.org>
To: linux-fsdevel@vger.kernel.org
Cc: viro@math.psu.edu
Subject: Re: [JFFS2 & UMOUNT/VFS] is it safe to iget() during unmount?
Date: Tue, 28 Dec 2004 18:45:08 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.58.0412281843350.7187@phoenix.infradead.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0412161038330.8020@phoenix.infradead.org>

Hello, no suggestion? Al, could you please comment?

On Thu, 16 Dec 2004, Artem B. Bityuckiy wrote:

> Hello.
> 
> I've hit on one problem with JFFS2. In JFFS2 there is a kernel thread 
> (called GC thread)
> which just performs the background auxiliary job. This thread may issue 
> the iget() call to obtain inodes.
> 
> On JFFS2 unmount, the GC thread is killed in put_super() call. The 
> following are some extracts from fs/jffs2/super.c code:
> 
> /* The put_super VFS callback */
> static void jffs2_put_super (struct super_block *sb)
> {
>   ... bla ... bla ...
>   jffs2_stop_garbage_collect_thread(c); /* KILL GC thread */
>   ... other bla bla bla ...
> }
> 
> /* The kill_sb VFS callback */
> static void jffs2_kill_sb(struct super_block *sb)
> {
>   .. bla ...
>   generic_shutdown_super(sb);
>   .. bla ...
> }
> 
> The situation when my problem arises is:
> 1. JFFS2 umount call is issued from the user space.
> 2. The generic_shutdown_super() VFS function is called. The code of 
> the generic_shutdown_super() function is at the end of this letter, for 
> reference (kernel 2.6.10-rcX).
> 3. The generic_shutdown_super() function is preempted  somewhere in the 
> middle, the sop->put_super(sb) is not called yet. I do not know where 
> exactly is it preempted, guess somewhere between sop->write_super(sb) and 
> sop->put_super(sb).
> 4. The GC thread wakes up and starts working (it was not killed yet since 
> the put_super was not called yet). GC thread calls iget for inode which is 
> for sure in the inode cache since there was not clear_inode call yet. But 
> VFS calls read_inode for that inode. And nasty things start from this 
> point.
> 
> I've offered patch to JFFS2 which changes it to kill the GC thread 
> *before* calling the generic_shutdown_super(), in kill_sb, like this:
> 
> /* The put_super VFS callback */
> static void jffs2_put_super (struct super_block *sb)
> {
>   ... bla ... bla ...
>   jffs2_stop_garbage_collect_thread(c); /* KILL GC thread */
>   generic_shutdown_super(sb);
>   ... other bla bla bla ...
> }
> 
> This solves problems at least in my case. But I was referred to the VFS 
> developers list and asked to ask  Al Viro's comments.
> 
> So, Al or somebody else, could you please coment this? Is it allowed to 
> call iget() during unmount()? Why?
> 
> P.S: CC me since I'm not in the list.
> 
> Thanks.
> 
> 
> 
> void generic_shutdown_super(struct super_block *sb)
> {
>         struct dentry *root = sb->s_root;
>         struct super_operations *sop = sb->s_op;
>                                                                                                                                              
>         if (root) {
>                 sb->s_root = NULL;
>                 shrink_dcache_parent(root);
>                 shrink_dcache_anon(&sb->s_anon);
>                 dput(root);
>                 fsync_super(sb);
>                 lock_super(sb);
>                 lock_kernel();
>                 sb->s_flags &= ~MS_ACTIVE;
>                 /* bad name - it should be evict_inodes() */
>                 invalidate_inodes(sb);
>                                                                                                                                              
>                 if (sop->write_super && sb->s_dirt)
>                         sop->write_super(sb);
>                 if (sop->put_super)
>                         sop->put_super(sb);
>                                                                                                                                              
>                 /* Forget any remaining inodes */
>                 if (invalidate_inodes(sb)) {
>                         printk("VFS: Busy inodes after unmount. "
>                            "Self-destruct in 5 seconds.  Have a nice 
> day...\n");
>                 }
>                                                                                                                                              
>                 unlock_kernel();
>                 unlock_super(sb);
>         }
>         spin_lock(&sb_lock);
>         /* should be initialized for __put_super_and_need_restart() */
>         list_del_init(&sb->s_list);
>         list_del(&sb->s_instances);
>         spin_unlock(&sb_lock);
>         up_write(&sb->s_umount);
> }
> 
> --
> Best Regards,
> Artem B. Bityuckiy,
> St.-Petersburg, Russia.
> 

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

      reply	other threads:[~2004-12-28 18:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-16 11:12 [JFFS2 & UMOUNT/VFS] is it safe to iget() during unmount? Artem B. Bityuckiy
2004-12-28 18:45 ` Artem B. Bityuckiy [this message]

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=Pine.LNX.4.58.0412281843350.7187@phoenix.infradead.org \
    --to=dedekind@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@math.psu.edu \
    /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;
as well as URLs for NNTP newsgroup(s).