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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 8AD50C43381 for ; Thu, 21 Feb 2019 10:53:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 613432085A for ; Thu, 21 Feb 2019 10:53:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726075AbfBUKxN (ORCPT ); Thu, 21 Feb 2019 05:53:13 -0500 Received: from mx2.suse.de ([195.135.220.15]:38364 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725831AbfBUKxN (ORCPT ); Thu, 21 Feb 2019 05:53:13 -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 5C249B11E; Thu, 21 Feb 2019 10:53:11 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 3409C1E0900; Thu, 21 Feb 2019 11:53:10 +0100 (CET) Date: Thu, 21 Feb 2019 11:53:10 +0100 From: Jan Kara To: Orion Poplawski Cc: Jan Kara , linux-fsdevel@vger.kernel.org, Amir Goldstein , Konstantin Khlebnikov , Vivek Trivedi Subject: Re: [PATCH v2 0/6] fanotify: Make wait for permission event response interruptible Message-ID: <20190221105310.GD27474@quack2.suse.cz> References: <20190213145443.26836-1-jack@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Wed 20-02-19 10:27:04, Orion Poplawski wrote: > On 2/13/19 7:54 AM, Jan Kara wrote: > > Hello, > > > > 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) - reported e.g. in [1]. Uninterruptible sleep also > > makes system hibernation fail if the listener gets frozen before the process > > generating fanotify permission event (as reported e.g. here [2]). > > > > This patch set modifies fanotify so that it will use interruptible wait when > > waiting for fanotify permission event response. Patches are based on current > > Linus' tree for the ease of testing (I plan to rebase them on top of Amir's > > pending changes later). I have also create LTP test which stresses handling of > > permission events while sending processes signals to test the new code [3] > > Review, comments, and testing are welcome. > > > > [1] https://lore.kernel.org/lkml/153474898224.6806.12518115530793064797.stgit@buzz/ > > [2] https://lore.kernel.org/lkml/c1bb16b7-9eee-9cea-2c96-a512d8b3b9c7@nwra.com/ > > [3] https://lwn.net/ml/linux-fsdevel/20190108165307.GA11259@quack2.suse.cz/ > > > > Changes since v1: > > * leave pr_debug() calls alone (Amir) > > * simplify permission event state tracking (Amir) > > * split some changes into separate patches (Amir) > > > > Honza > > > > I backported these patches to the RHEL7 kernel and have started running that. > One thing I've noticed are messages like the following at login time: > > bash: /etc/bash_completion.d/itweb-settings.bash: Interrupted system call > > I've commented on a bash bug report here > https://savannah.gnu.org/support/?109159 Thanks for trying these out! Yes, so the patches can definitely lead to EINTR returns from open(2) if there's fanotify permission event generated by it and the opening process has a signal pending. Now EINTR is documented as a possible return from open(2) but Marko is right that in practice open(2) on local filesystem never returns EINTR so programs just don't bother handling it. Since breaking userspace is no-go, we probably cannot apply the change as is. What we can do easily is to change the wait_event_interruptible() to wait_event_killable(). This is what we commonly do when we want to allow administrator to interrupt a syscall but userspace is not prepared for EINTR. That will at least allow processes that are waiting for fanotify response to be killed. So I'll do this for the coming merge window (attached patch). However this will not solve your problems with hibernation as TASK_KILLABLE tasks cannot be hibernated AFAICS. I will have to talk with people more knowledgeable about hibernation if there's a solution to this. Honza -- Jan Kara SUSE Labs, CR