On 12/10/22 01:49, Ian Kent wrote: > On 11/10/22 22:25, Alexandre Merlin wrote: >> Hello, >> >> TL;DR: Because of our use of a script-based map that dynamically creates exports >> server-side based on user's rights, we are experiencing a regression since >> commit 2f562f63a (autofs-5.1.6 - use a valid timeout in >> lookup_prune_one_cache()). Creating an option for a configurable >> positive_timeout, as mentioned in the commit comment, would be an efficient >> solution for us. >> >> We are working for the Grid'5000 scientific testbed (see >> https://www.grid5000.fr/w/Grid5000:Home). Our users can reserve nodes to make >> their experiments, and from these nodes, they can access to different NFS >> shares if they are granted access to use them. >> >> We use autofs to mount these filesystems on the fly, using a map based on a >> script which checks that the user is granted, and which asks for the creation >> of the appropriate export file on the corresponding NFS server. >> >> When the reservation is done, we signal the node's automount daemon using the >> USR1 and HUP signals in order to forget what was automounted by the user (as >> compute nodes may be shared by different users, we want to ensure that the >> previously mounted resource is no more in the running configuration). >> >> For this to work, our granting access script must be called each time a user >> request to access a mounted point. But since the commit [2f562f63a] introducing >> the positive timeout, when a user tries to access a mounted point, the cache is >> used if a another user used the same mounted point within the positive timeout >> timeframe (120s). >> >> So we need a way to disable the cache to be sure that our granting script is >> called. It can be done for the NEGATIVE_TIMEOUT but not yet for the >> POSITIVE_TIMEOUT. >> >> Since it is mentioned in the commit message that "The valid timeout probably >> should become configurable at some point too", we wonder if it would be >> possible to include it in a future release. You will find attached a patch >> introducing this new option. > > Well, yes, that will be fine. > > > The patch looks mostly fine too, I'll possibly change some of > > the wording but it should be otherwise unchanged. > > > Are you ok with having your email address as the patch author > > since the patch will be uploaded to kernel.org when it's > > committed (publicly available) or should I set myself as the > > author (not my preferred choice)? Using my email address as the patch author is fine. > Anyway, I need to find time to make a new release so it > > shouldn't too long before it's available. That's perfect. > > If you need me to commit the patch earlier than I otherwise > > would (such as your distro maintainer has upstream first policy > > on package changes) then say so and I'll commit it. No need for that. Regards, Alexandre
