Re: [patch] kjournald locking fix

Andrew Morton (akpm@zip.com.au)
Thu, 04 Apr 2002 02:19:46 -0800


"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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/