Re: [patch] kjournald locking fix

[Andrew Morton <akpm@zip.com.au>]

"Ishan O. Jayawardena" wrote:
> 
> Greetings,
> 
>         kjournald seems to be missing an unlock_kernel() for a matching
> lock_kernel(). A posting by  Dennis Vadura to l-k mentions (among other
> things) a kernel message that says kjournald exited with preempt_count ==
> 1. The attached patch (text/plain) adds the necessary
> unlock_kernel(). [But I haven't been able to reproduce the hang that
> Dennis experiences...]
>         Tested only on UP. Patch is for 2.4.19-pre5 + prempt-kernel, _no_
> lock-break. I hope the positioning of unlock_kernel() is correct... please
> correct me if I'm wrong.

The unlock_kernel() is fine.  The kernel will drop the
lock for us as the task makes its final call to schedule()
on its way to the process graveyard, but it's neater this way.

>         Please CC me (ioshadij@hotmail.com). I can't subscribe to the list
> with my own ISP because they aren't ECN-friendly, and subscribing via
> 
> PS: Of course, the reparent_to_init() isn't part of the fix, but I've seen
> kjournald become a zombie in an ugly episode with a deadlock in devfs many
> moons ago.

I've always put the reparent_to_init() call after the daemonize()
call.  I don't immediately see anything wrong with doing it
beforehand, but that is a less tested code sequence.

But yes, you're right - kjournald needs to call reparent_to_init(),
else it'll turn into a zombie if the process which mounted the
filesystem is still running.

Could you please move the reparent_to_init() down a line and send
a diff to Marcelo?

Thanks.