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/20250801152210.15501-2-ddiss@xxxxxxx/ 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. Thanks, David
