Messages in this thread | | | From | Andreas Gruenbacher <> | Subject | Re: [PATCH 1/4] fanotify: flush outstanding perm requests on group destroy | Date | Tue, 24 Aug 2010 11:36:29 +0200 |
| |
On Tuesday 24 August 2010 10:49:45 Tvrtko Ursulin wrote: > I think just switching to interruptible sleep in > fanotify_get_response_from_access should be fine. And it should probably > deny the current event when signal is received.
Well the result would be -EINTR from the system call that blocked on the perm event, the same as with an interruptible nfs mount. The process would never get -EPERM. Processes may not be prepared to handle -EINTR in all cases, and so it may make more sense to use the same behavior as NFS and only allow SIGKILL to kill a process blocked on a perm event (which the blocked process will never see).
From the nfs man page: > intr / nointr > > Selects whether to allow signals to interrupt file operations on this mount > point. If neither option is specified (or if nointr is specified), > signals do not interrupt NFS file operations. If intr is specified, > system calls return EINTR if an in-progress NFS operation is interrupted > by a signal. > > Using the intr option is preferred to using the soft option because it is > significantly less likely to result in data corruption. The intr / nointr > mount option is deprecated after kernel 2.6.25. Only SIGKILL can > interrupt a pending NFS operation on these kernels, and if specified, > this mount option is ignored to provide backwards compatibility with > older kernels.
Andreas
| |