Re: [PATCH 2/2] autofs: dont trigger mount if it cant succeed

On 14/11/25 19:44, Christian Brauner wrote:
> On Fri, Nov 14, 2025 at 07:49:53AM +0800, Ian Kent wrote:
>> On 13/11/25 21:19, Christian Brauner wrote:
>>> On Thu, Nov 13, 2025 at 08:14:36AM +0800, Ian Kent wrote:
>>>> On 12/11/25 19:01, Christian Brauner wrote:
>>>>> On Tue, Nov 11, 2025 at 08:27:42PM +0800, Ian Kent wrote:
>>>>>> On 11/11/25 18:55, Christian Brauner wrote:
>>>>>>> On Tue, Nov 11, 2025 at 10:24:35AM +0000, Al Viro wrote:
>>>>>>>> On Tue, Nov 11, 2025 at 11:19:59AM +0100, Christian Brauner wrote:
>>>>>>>>
>>>>>>>>>> +	sbi->owner = current->nsproxy->mnt_ns;
>>>>>>>>> ns_ref_get()
>>>>>>>>> Can be called directly on the mount namespace.
>>>>>>>> ... and would leak all mounts in the mount tree, unless I'm missing
>>>>>>>> something subtle.
>>>>>>> Right, I thought you actually wanted to pin it.
>>>>>>> Anyway, you could take a passive reference but I think that's nonsense
>>>>>>> as well. The following should do it:
>>>>>> Right, I'll need to think about this for a little while, I did think
>>>>>>
>>>>>> of using an id for the comparison but I diverged down the wrong path so
>>>>>>
>>>>>> this is a very welcome suggestion. There's still the handling of where
>>>>>>
>>>>>> the daemon goes away (crash or SIGKILL, yes people deliberately do this
>>>>>>
>>>>>> at times, think simulated disaster recovery) which I've missed in this
>>>>> Can you describe the problem in more detail and I'm happy to help you
>>>>> out here. I don't yet understand what the issue is.
>>>> I thought the patch description was ok but I'll certainly try.
>>> I'm sorry, we're talking past each other: I was interested in your
>>> SIGKILL problem when the daemon crashes. You seemed to say that you
>>> needed additional changes for that case. So I'm trying to understand
>>> what the fundamental additional problem is with a crashing daemon that
>>> would require additional changes here.
>> Right, sorry.
>>
>> It's pretty straight forward.
>>
>>
>> If the daemon is shutdown (or killed summarily) and there are busy
>>
>> mounts left mounted then when started again they are "re-connected to"
>>
>> by the newly running daemon. So there's a need to update the mnt_ns_id in
>>
>> the ioctl that is used to set the new pipefd.
>>
>>
>> I can't provide a patch fragment because I didn't realise the id in
>> ns_common
> Before that you can grab it from the mount namespace directly from the
> mntns->seq field.

I'd noticed some of that type of usage, using that will certainly help

with the backports I need to do too but I've started looking at the series

so I'll probably back port it for most recent kernel.


I'll send my current path once I get a kernel built that boots in my

VM ...


Thanks for your help.

Ian