[Linux-ia64] Re: deadlock in crashed multithreaded job

[Linux-ia64] Re: deadlock in crashed multithreaded job

[Erich Focht]

On Mon, 1 Oct 2001, Manfred Spraul wrote:

> > The symptoms: running the tests (make check) sometimes ends up
> > with hanging processes.
> 
> Does it _only_ hang during coredumping, or also during normal usage?
> 
> Could you remove
> 	down_read(&mmap_sem);
> 	binfmt->coredump();
> 	up_read(&mmap_sem);
> from fs/exec.c and rerun your tests?

Setting the coredumpsize limit to 0 already solves the problem.

The question that remains is how to deal with nested locks on the same
resource that can lead to deadlocks. Is there any (un)written rule that
one should avoid them in the Linux Kernel? Or are there any approaches to
deal with them (which are not yet included in the Kernel)?

> The hang during coredumping is known, there are 2 fixes [I have one, not
> yet released, Andrea wrote one, IIRC included in his -aa kernels].

Do these solutions deal only with the coredump problem or with nested
critical sections?

Thanks,
Erich

[Linux-ia64] Re: deadlock in crashed multithreaded job

[Manfred Spraul]

Erich Focht wrote:
> 
> The question that remains is how to deal with nested locks on the same
> resource that can lead to deadlocks. Is there any (un)written rule that
> one should avoid them in the Linux Kernel? Or are there any approaches to
> deal with them (which are not yet included in the Kernel)?
>

Yes, semaphores and spinlocks are not recursive. There is one exception
for rw spinlocks, they can recurse on read. I'm not aware that there are
any plans to change that.

My patch avoids calling copy_from_user in elf_core_dump, Andrea adds a 
limited recursion support and uses that to prevent the deadlock.
With his patch you can recurse on on down_read() if you pass special
parameters.

But full recursion support is not planned.

--
	Manfred