From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from helmsgagent01.f-secure.com ([193.110.108.21]:51565 "EHLO helmsgagent01.f-secure.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759531AbdCVQQ1 (ORCPT ); Wed, 22 Mar 2017 12:16:27 -0400 Received: from pps.filterd (helmsgagent01.f-secure.com [127.0.0.1]) by helmsgagent01.f-secure.com (8.16.0.17/8.16.0.17) with SMTP id v2MFRdG8032665 for ; Wed, 22 Mar 2017 17:31:08 +0200 Received: from helex01.fi.f-secure.com ([10.190.48.70]) by helmsgagent01.f-secure.com with ESMTP id 29b9xy289f-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 22 Mar 2017 17:31:08 +0200 From: Marko Rauhamaa To: Subject: fanotify read returns with errno == EOPENSTALE Date: Wed, 22 Mar 2017 17:31:05 +0200 Message-ID: <87inn12urq.fsf@drapion.f-secure.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-fsdevel-owner@vger.kernel.org List-ID: An F-Secure product uses fanotify with OPEN_PERM. We ran into an unexpected situation: a read(2) on the fanotify fd returned -1 with errno == EOPENSTALE. The only place in the (development) kernel where I can find EOPENSTALE is in nfs4file.c:nfs4_file_open(). Questions: * Should an fanotify client expect EOPENSTALE from read(2)? * According to , EOPENSTALE "should never be seen by user programs." Is this a kernel bug? * The kernel in question is kernel-3.10.0-229.el7.x86_64 (RHEL 7.3). I will take it up with Red Hat if necessary. However, is this a known issue that has been fixed in a newer kernel version? Marko