From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A63AC282CA for ; Wed, 13 Feb 2019 14:56:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D914A222C9 for ; Wed, 13 Feb 2019 14:56:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2403989AbfBMO4w (ORCPT ); Wed, 13 Feb 2019 09:56:52 -0500 Received: from mx2.suse.de ([195.135.220.15]:60570 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729130AbfBMO4w (ORCPT ); Wed, 13 Feb 2019 09:56:52 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 43F7AAC24; Wed, 13 Feb 2019 14:56:50 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id BF9461E09CD; Wed, 13 Feb 2019 15:56:49 +0100 (CET) Date: Wed, 13 Feb 2019 15:56:49 +0100 From: Jan Kara To: Orion Poplawski Cc: Jan Kara , Amir Goldstein , linux-fsdevel , Vivek Trivedi , Konstantin Khlebnikov Subject: Re: [PATCH 4/4] fanotify: Use interruptible wait when waiting for permission events Message-ID: <20190213145649.GA26828@quack2.suse.cz> References: <20190108164611.11440-1-jack@suse.cz> <20190108164611.11440-5-jack@suse.cz> <20190109092359.GC15397@quack2.suse.cz> <55525f75-6fc0-66c2-dbb0-1194895e8a72@nwra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55525f75-6fc0-66c2-dbb0-1194895e8a72@nwra.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Tue 12-02-19 08:40:13, Orion Poplawski wrote: > On 1/9/19 2:23 AM, Jan Kara wrote: > > On Wed 09-01-19 09:51:08, Amir Goldstein wrote: > >> On Tue, Jan 8, 2019 at 6:46 PM Jan Kara wrote: > >>> > >>> When waiting for response to fanotify permission events, we currently > >>> use uninterruptible waits. That makes code simple however it can cause > >>> lots of processes to end up in uninterruptible sleep with hard reboot > >>> being the only alternative in case fanotify listener process stops > >>> responding (e.g. due to a bug in its implementation). Uninterruptible > >>> sleep also makes system hibernation fail if the listener gets frozen > >>> before the process generating fanotify permission event. > >>> > >>> Fix these problems by using interruptible sleep for waiting for response > >>> to fanotify event. This is slightly tricky though - we have to > >>> detect when the event got already reported to userspace as in that > >>> case we must not free the event. > >> > >>> Instead we push the responsibility for > >>> freeing the event to the process that will write response to the > >>> event. > >> > >> It a bit hard to follow this patch. Can we make the patch that > >> shifts responsibility to free the event a separate patch? > >> fsnotify_remove_queued_event() helper can tag along with it > >> or separate patch as you wish. > > > > I'll have a look how to best split this. It should be possible. > > > >>> Signed-off-by: Jan Kara > >>> --- > >> > >> I think it would be good to add reported-by tand the links you provided > >> in cover letter in this patch as well. > > > > Good point. Will do. > > > >>> > >>> @@ -87,8 +116,8 @@ static int fanotify_get_response(struct fsnotify_group *group, > >>> if (response & FAN_AUDIT) > >>> audit_fanotify(response & ~FAN_AUDIT); > >>> > >>> - pr_debug("%s: group=%p event=%p about to return ret=%d\n", __func__, > >>> - group, event, ret); > >> > >> Looks useful. Why remove? > > > > OK, I'll leave it alone. > > > >>> +static void set_event_response(struct fsnotify_group *group, > >>> + struct fanotify_perm_event_info *event, > >>> + unsigned int response) > >>> +{ > >>> + spin_lock(&group->notification_lock); > >>> + /* Waiter got aborted by a signal? Free the event. */ > >>> + if (unlikely(event->response == FAN_EVENT_CANCELED)) { > >>> + spin_unlock(&group->notification_lock); > >>> + fsnotify_destroy_event(group, &event->fae.fse); > >>> + return; > >>> + } > >>> + event->response = response | FAN_EVENT_ANSWERED; > >>> + spin_unlock(&group->notification_lock); > >>> +} > >>> + > >> > >> I don't understand. AFAICS, all callers of set_event_response() > >> call immediately after spin_unlock(&group->notification_lock), > >> without any user wait involved. > >> I think it makes more sense for set_event_response() to assert the > >> lock than it is to take it. > >> > >> Am I missing anything? > > > > In case we need to destroy the event, we want to drop the > > notification_lock. So to avoid a situation where set_event_response() drops > > a lock it did not acquire (which is not very intuitive), I've decided for > > the less efficient scheme of dropping and retaking the lock. > > > > But maybe with better function name and some asserts, we could live with > > dropping the lock inside the function without taking it. > > > > Honza > > > > > Any more progress here? Thanks for your work on this, it's a real thorn in > our side here. I've sent v2 of the patches today to push things further. Honza -- Jan Kara SUSE Labs, CR