Ian Kent wrote:
On Fri, 2015-09-11 at 17:14 +0200, Cyril B. wrote:
> Hello Ian,
>
> Thanks for the quick response. I was able to reliably reproduce the
> deadlock on a test server with a test script that triggers many
> simultaneous mounts. On this setup /home is replaced with /mnt.
Yes, it's a puzzle.
The default.c module looks like there's no possibility of a deadlock.
It's fairly simple and there is no place where the mutex isn't released
before return and there are no other calls are made that could take
other locks that could introduce a deadlock.
It occurred to me that the call to force_standard_program_map_env() is
out probably out of order.
It's made after the fork() that's used to exec the program map code.
I think the child is seeing the state of the mutex at the time of the
fork and if the mutex was locked at that time the child process will
never see it unlocked since the forked process copy will not see that
change.
That's just a guess, so let me put together a patch for you to try.
Are you in a position to be able to apply and build autofs to test?
Sure, I can test as much as I want. I guess I could probably even setup
a test VM that reproduces the issue and give you root credentials if it
helps.
--
Cyril B.
--
To unsubscribe from this list: send the line "unsubscribe autofs" in
