On Wed, Dec 13, 2023 at 7:28 PM Jan Kara <jack@xxxxxxx> wrote: > > On Fri 08-12-23 10:01:35, Amir Goldstein wrote: > > With FAN_DENY response, user trying to perform the filesystem operation > > gets an error with errno set to EPERM. > > > > It is useful for hierarchical storage management (HSM) service to be able > > to deny access for reasons more diverse than EPERM, for example EAGAIN, > > if HSM could retry the operation later. > > > > Allow userspace to response to permission events with the response value > > FAN_DENY_ERRNO(errno), instead of FAN_DENY to return a custom error. > > > > The change in fanotify_response is backward compatible, because errno is > > written in the high 8 bits of the 32bit response field and old kernels > > reject respose value with high bits set. > > > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> > > So a couple of comments that spring to my mind when I'm looking into this > now (partly maybe due to my weak memory ;): > > 1) Do we still need the EAGAIN return? I think we have mostly dealt with > freezing deadlocks in another way, didn't we? I was thinking about EAGAIN on account of the HSM not being able to download the file ATM. There are a bunch of error codes that are typical for network filesystems, e.g. ETIMEDOUT, ENOTCONN, ECONNRESET which could be relevant to HSM failures. > > 2) If answer to 1) is yes, then there is a second question - do we expect > the errors to propagate back to the unsuspecting application doing say > read(2) syscall? Because I don't think that will fly well with a big > majority of applications which basically treat *any* error from read(2) as > fatal. This is also related to your question about standard permission > events. Consumers of these error numbers are going to be random > applications and I see a potential for rather big confusion arising there > (like read(1) returning EINVAL or EBADF and now you wonder why the hell > until you go debug the kernel and find out the error is coming out of > fanotify handler). And the usecase is not quite clear to me for ordinary > fanotify permission events (while I have no doubts about creativity of > implementors of fanotify handlers ;)). > That's a good question. I prefer to delegate your question to the prospect users of the feature. Josef, which errors did your use case need this feature for? > 3) Given the potential for confusion, maybe we should stay conservative and > only allow additional EAGAIN error instead of arbitrary errno if we need it? > I know I was planning to use this for EDQUOT error (from FAN_PRE_MODIFY), but I certainly wouldn't mind restricting the set of custom errors. I think it makes sense. The hard part is to agree on this set of errors. > I'm leaving the API question aside for a moment until I have a clearer > picture of what we actually want to implement :). Fair enough ;) Thanks, Amir.
