Re: [PATCH 0/9] Patch series for direct map reload bug

On 22/8/25 18:50, David Disseldorp wrote:
> Hi Ian,
>
> On Fri,  8 Aug 2025 10:16:46 +0800, Ian Kent wrote:
>
>> There have been reports of log messages like:
>> automount[nnnn]: handle_packet_expire_direct: can't find map entry for (1048647,114082)
>>
>> These messages are fatal because the direct mount path must be known to
>> lookup the mount. Historically the autofs kernel communication packet
>> size is fixed and based on the maximum path name component size used by
>> indirect mounts but direct mounts have a variable length multi-component
>> path. To solve this while maintaining compatability with indirect mounts,
>> an index of (device, inode) tuples is maintained to allow lookup of the
>> direct mount path so the map entry can be located.
>>
>> Also it's necessary to understand that direct mount maps are always read
>> fully in order to mount direct mount triggers for all direct mount map
>> entries so they must exist so this approach should always work.
>>
>> So the message above only occurs for direct mounts and the ioctl file
>> handle used by each direct mount is stored in the map entry so it's
>> not possibile to respond to the kernel at all if the map entry cache
>> entry can't be found.
>>
>> Unfortunately map entry cache cleanup on update is complicated and can
>> lead to problems which (I believe) is what's happening here.
>>
>> While I suspect your reproducer is a different case to what I've seen
>> it probably symtomatic of the underlying problem.
>>
>> Patches "autofs-5.1.9 - fix devid update on reload" and "autofs-5.1.9
>> - fix stale direct mount trigger not umounted on expire" are the main
>> fixes I was able to identify working through the code.
>>
>> Please test them and let me know how it goes.
> Your patches do indeed resolve the kernel stall in autofs_wait following
> direct map reload, but there's one slight difference in behaviour
> between my RFC and this series when running the reproducer from the
> https://lore.kernel.org/autofs/[email protected]/
> commit msg:
> The share that gets removed from the direct map and then explicitly
> unmounted will be remounted by the background `df` workload when running
> this series. With my RFC the MOUNT_FLAG_STALE flag tracks removal,
> avoiding subsequent remount.

I didn't think this would be a problem because the case should only

apply to map cache entries that have a real mount for which the cache

entry has been removed. The trigger mount has to be umounted after

being uncovered by the expire and walks should be blocked until the

daemon responds to the kernel with a result status.


Clearly something isn't right with my series, let me have a look.

We may need to merge in your recommendation of adding a flag ...


Ian