From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750986AbcGGNEe (ORCPT ); Thu, 7 Jul 2016 09:04:34 -0400 Received: from sainfoin-out.extra.cea.fr ([132.167.192.145]:45414 "EHLO sainfoin-out.extra.cea.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751035AbcGGNEZ (ORCPT ); Thu, 7 Jul 2016 09:04:25 -0400 X-Greylist: delayed 1706 seconds by postgrey-1.27 at vger.kernel.org; Thu, 07 Jul 2016 09:04:25 EDT Date: Thu, 7 Jul 2016 14:35:40 +0200 From: Dominique Martinet To: Greg Kurz CC: Eric Van Hensbergen , Latchesar Ionkov , , , , Ron Minnich , "David S. Miller" Subject: Re: [PATCH 0/3] fs/9p: fix setattr/getattr issues with open files Message-ID: <20160707123540.GA15192@u-isr-cdi-08> References: <146659832556.15781.17414806975641516683.stgit@bahia.lan> <20160704141655.GA5799@u-isr-cdi-08> <20160704170849.1654d6a0@bahia.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <20160704170849.1654d6a0@bahia.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Greg, Greg Kurz wrote on Mon, Jul 04, 2016 at 05:08:49PM +0200: > On Mon, 4 Jul 2016 16:16:55 +0200 > Dominique Martinet wrote: > > > I *think* this introduces a race somewhere, I'm getting errors like: > > cat: f.05: No such file or directory > > cat: f.14: No such file or directory > > cat: f.13: No such file or directory > > cat: f.39: No such file or directory > > cat: f.05: No such file or directory > > > > > > when doing: > > for file in {01..50}; do touch f.${file}; done > > seq 1 1000 | xargs -n 1 -P 25 -I{} cat f.* > /dev/null Ok so, tested with the first two patches and I can't seem to hit any problem with the qemu server at least (I'd need more time to fix ganesha's 9p tcp/rdma server before I could blame the client in any way) The last patch looks good to me, I think it only makes an existing race more visible... What I think could happen is: process 1 has file open process 2 tries to open file, sees fid open process 1 closes file/clunk fids process 2 tries to clone now-clunked fid and gets ENOENT I'm afraid I just found out my hypervisor is no longer recent enough for gdb kernel scripts (gdb 7.6 and python 2.7.5 in el7 compared to the apparently required 7.7 and 2.7.6 respectively...), and I don't see anything obvious with just debug messages/adding a few printks (wasn't able to confirm where exactly that ENOENT comes from or if my theory is even close to the truth) I'd like to spend more time on it but don't think I'll be able to for a couple of weeks ; sorry about that. Were you able to reproduce the problem? Thanks, -- Dominique