From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from helmsgmaster01.f-secure.com ([193.110.108.20]:33349 "EHLO helmsgmaster01.f-secure.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751868AbdCWIN2 (ORCPT ); Thu, 23 Mar 2017 04:13:28 -0400 From: Marko Rauhamaa To: Amir Goldstein CC: Al Viro , linux-fsdevel , Jan Kara , Jeff Layton Subject: Re: fanotify read returns with errno == EOPENSTALE References: <87inn12urq.fsf@drapion.f-secure.com> <20170322193122.GV29622@ZenIV.linux.org.uk> Date: Thu, 23 Mar 2017 10:13:21 +0200 In-Reply-To: (Amir Goldstein's message of "Wed, 22 Mar 2017 15:39:10 -0400") Message-ID: <87a88c2yxq.fsf@drapion.f-secure.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Amir Goldstein : > On Wed, Mar 22, 2017 at 3:31 PM, Al Viro wrote: >> On Wed, Mar 22, 2017 at 02:20:15PM -0400, Amir Goldstein wrote: >> >>> Well, the behavior was changed in kernel 4.7 (and stable kernels) by >>> commit by Al Viro: >>> fac7d19 fix EOPENSTALE bug in do_last() >>> >>> Since that commit userspace will be able to see this error in >>> fanotify events. >> >> Unless *notify somehow uses do_last() directly, that commit should >> have no effect on it (and it definitely has no effect on >> dentry_open() callers)... > > Right. I'm being silly :/ > > Back to Redhat I guess... I will gladly take the issue to RedHat. However, the discussion so far confuses me a bit. To confirm, is there a consensus here that EOPENSTALE should never leak to userspace (through fanotify read anyway)? If EOPENSTALE *is* a valid possible return from fanotify read, this is my bug and not RedHat's. In that case, what is the correct recovery? As for reproduction, I don't yet have one. At the moment, I just need an authoritative user-space API clarification. Marko