On Thu, 2019-06-20 at 10:19 -0700, Patrick Donnelly wrote: > On Mon, Jun 17, 2019 at 1:45 PM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > Again, I'd like to see SIGLOST sent to the application here. Are there > > > any objections to reviving whatever patchset was in flight to add > > > that? Or just writeup a new one? > > > > > > > I think SIGLOST's utility is somewhat questionable. Applications will > > need to be custom-written to handle it. If you're going to do that, then > > it may be better to consider other async notification mechanisms. > > inotify or fanotify, perhaps? Those may be simpler to implement and get > > merged. > > The utility of SIGLOST is not well understood from the viewpoint of a > local file system. The problem uniquely applies to distributed file > systems. There simply is no way to recover from a lost lock for an > application through POSIX mechanisms. We really need a new signal to > just kill the application (by default) because recovery cannot be > automatically performed even through system call errors. I don't see > how inotify/fanotify (not POSIX interfaces!) helps here as it assumes > the application will even use those system calls to monitor for lost > locks when POSIX has no provision for that to happen. > (cc'ing Anna in case she has an opinion) SIGLOST isn't defined in POSIX either, so I'm not sure that argument carries much weight. The _only_ way you'd be able to add SIGLOST is if it defaults to SIG_IGN, such that only applications that are watching for it will react to it. Given that, you're already looking at code modifications. So, the real question is: what's the best method to watch for lost locks? I don't have a terribly strong opinion about any of these notification methods, tbh. I only suggested inotify/fanotify because they'd likely be much simpler to implement. Adding signals is a non-trivial affair as we're running out of bits in that space. The lower 32 bits are all taken and the upper ones are reserved for realtime signals. My signal.h has a commented out SIGLOST: #define SIGIO 29 #define SIGPOLL SIGIO /* #define SIGLOST 29 */ Sharing the value with SIGIO/SIGPOLL makes it distinctly less useful. I think it'd probably need its own value. Maybe there is some way to have the application ask that one of the realtime signals be set up for this? > It's worth noting as well that the current behavior of the mount > freezing on blacklist is not an acceptable status quo. The application > will just silently stall the next time it tries to access the mount, > if it ever does. Fair enough. -- Jeff Layton <jlayton@xxxxxxxxxx>
