Re: automount subprocesses accumulate

["Cyril B." <cbay@excellency.fr>]

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