public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [2.6.13] task_struct->fs_excl, kernel_thread and jffs2
@ 2005-09-08  7:47 Giancarlo Formicuccia
  2005-09-08  8:15 ` Jens Axboe
  0 siblings, 1 reply; 2+ messages in thread
From: Giancarlo Formicuccia @ 2005-09-08  7:47 UTC (permalink / raw)
  To: linux-kernel

Hi,
[please CC me in any reply]
I'm not sure that dup_task_struct() must copy the fs_excl field. This can leads to
problems if do_fork() is somehow called while fs_excl!=0.
For example, the jffs2 code creates a kernel thread (jffs2_garbage_collect_thread)
in a path where lock_super() is held (i.e. by do_remount_sb, during -o remount,rw).
When the new thread expires, a badness happens (kernel/exit.c:787). This problem
was observed by a couple of people and can be easily reproduced:
http://lists.infradead.org/pipermail/linux-mtd/2005-August/013487.html
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-September/031109.html

At first glance, I'd simply set fs_excl to 0 for every new thread in dup_task_struct:

--- linux-2.6.13/kernel/fork.c	2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13-new/kernel/fork.c	2005-09-07 17:06:23.000000000 +0200
@@ -173,6 +173,7 @@ static struct task_struct *dup_task_stru
 	*tsk = *orig;
 	tsk->thread_info = ti;
 	ti->task = tsk;
+	atomic_set(&tsk->fs_excl, 0);
 
 	/* One for us, one for whoever does the "release_task()" (usually parent) */
 	atomic_set(&tsk->usage,2);

but I've a doubt about the WARN_ON in exit.c being actually here to report these 
kernel_thread() users (like jffs2)...

Any comment/suggestion?

Thanks,

Giancarlo


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [2.6.13] task_struct->fs_excl, kernel_thread and jffs2
  2005-09-08  7:47 [2.6.13] task_struct->fs_excl, kernel_thread and jffs2 Giancarlo Formicuccia
@ 2005-09-08  8:15 ` Jens Axboe
  0 siblings, 0 replies; 2+ messages in thread
From: Jens Axboe @ 2005-09-08  8:15 UTC (permalink / raw)
  To: Giancarlo Formicuccia; +Cc: linux-kernel, Andrew Morton

On Thu, Sep 08 2005, Giancarlo Formicuccia wrote:
> Hi,
> [please CC me in any reply]
> I'm not sure that dup_task_struct() must copy the fs_excl field. This can leads to
> problems if do_fork() is somehow called while fs_excl!=0.
> For example, the jffs2 code creates a kernel thread (jffs2_garbage_collect_thread)
> in a path where lock_super() is held (i.e. by do_remount_sb, during -o remount,rw).
> When the new thread expires, a badness happens (kernel/exit.c:787). This problem
> was observed by a couple of people and can be easily reproduced:
> http://lists.infradead.org/pipermail/linux-mtd/2005-August/013487.html
> http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-September/031109.html
> 
> At first glance, I'd simply set fs_excl to 0 for every new thread in dup_task_struct:
> 
> --- linux-2.6.13/kernel/fork.c	2005-08-29 01:41:01.000000000 +0200
> +++ linux-2.6.13-new/kernel/fork.c	2005-09-07 17:06:23.000000000 +0200
> @@ -173,6 +173,7 @@ static struct task_struct *dup_task_stru
>  	*tsk = *orig;
>  	tsk->thread_info = ti;
>  	ti->task = tsk;
> +	atomic_set(&tsk->fs_excl, 0);
>  
>  	/* One for us, one for whoever does the "release_task()" (usually parent) */
>  	atomic_set(&tsk->usage,2);
> 
> but I've a doubt about the WARN_ON in exit.c being actually here to report these 
> kernel_thread() users (like jffs2)...
> 
> Any comment/suggestion?

Patch is correct, that is definitely an oversight!

Acked-by: Jens Axboe <axboe@suse.de>

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-09-08  8:15 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-09-08  7:47 [2.6.13] task_struct->fs_excl, kernel_thread and jffs2 Giancarlo Formicuccia
2005-09-08  8:15 ` Jens Axboe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox