On Fri, Jan 20, 2017 at 2:21 PM, Jan Kara <jack@xxxxxxx> wrote: > When userspace task processing fanotify permission events screws up and > does not respond, fsnotify_mark_srcu SRCU is held indefinitely which > causes further hangs in the whole notification subsystem. Although we > cannot easily solve the problem of operations blocked waiting for > response from userspace, we can at least somewhat localize the damage by > dropping SRCU lock before waiting for userspace response and reacquiring > it when userspace responds. > > Reviewed-by: Amir Goldstein <amir73il@xxxxxxxxx> > Signed-off-by: Jan Kara <jack@xxxxxxx> > --- > fs/notify/fanotify/fanotify.c | 19 +++++++++++++++++-- > 1 file changed, 17 insertions(+), 2 deletions(-) > > diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c > index 2e8ca885fb3e..98d7dc94d34c 100644 > --- a/fs/notify/fanotify/fanotify.c > +++ b/fs/notify/fanotify/fanotify.c > @@ -61,14 +61,28 @@ static int fanotify_merge(struct list_head *list, struct fsnotify_event *event) > > #ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS > static int fanotify_get_response(struct fsnotify_group *group, > - struct fanotify_perm_event_info *event) > + struct fsnotify_mark *inode_mark, > + struct fsnotify_mark *vfsmount_mark, > + struct fanotify_perm_event_info *event, > + int *srcu_idx) Should these (inode_mark, vfsmount_mark, srcu_idx) be passed in an opaque struct to simplify the interface? Alternatively, waiting could be done by fsnotify core (a-la poll). That's a bit bigger change though. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
