Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3389361imm; Mon, 4 Jun 2018 02:47:07 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKdY1Ugg2iOM2iDP3Q3nxmBqYnhuQLhjC0orYd9vBkudUjCFqwDTEPr3k+eRNjYylK/po0m X-Received: by 2002:a17:902:8a82:: with SMTP id p2-v6mr21144704plo.244.1528105627741; Mon, 04 Jun 2018 02:47:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528105627; cv=none; d=google.com; s=arc-20160816; b=Pg47CwiLyEQrvdQ3THDod6gqoe1Rj31YeFO6/cJu7vvHuXbvLUoRl2rbyxjN/ObA9o IfXi3B5MZerPjnUTeyYfUmNvo+fgnkrDMYJXYsoFuj4c0ZQ0zfEKjnGwr7fRp7wLjA7b GNNNhtqbKX+9WLpoMP25PI/Bv/j5/E6QiBYzyP26nQ19U7rSYJmbpCnkJP0FwvC2fwvD uYm1iGX/807pbXt7h6MWVTvWCKipFLRf8Lx9ookpWNDOW0oKoJXAJIg24SxrKsrF1fu6 C2qwfmCseIdwzQZwkZMagB8MjxaNM5L7eZlyF1rSjal7pXrlCojKU88I3AzPDvAzkIBa grqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from:arc-authentication-results; bh=1FMU9tdipxVIViY8twK5vQ0tc07yJMkli8kLOVOjtZQ=; b=IHdKf+J9JuZnLMUVazoOPm2xRq4PWpwUQssFxXPAmRiKn0f0dL4Dl6X30LNfN+DjxM ZLw/Hx5j7DlPiu8wmM/UhXbEe2+mrpTt3iAhfh5lvLJMA9CWJdltSo+2+a4gIpsvnR+z b60/GX5atXzy3Rf1YubWsT7Ww+QZD/27LP7fn7CLsOvUjkv5KvZPSTuBE1rF+BCS4+df wEk8OLqSJ3WDmPgYOVWatIYjtTv224JFkcClBL6kV/8GY2d2ydEbr8EDUYiGIVYvCegU +E0wk4kTKpRG0mtyixbD1wCUpHGMPulDKBeYYimF1tv8amjDkr4uXrfgKyHR0ha+jmRu SlDg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k4-v6si36247709pgq.683.2018.06.04.02.46.52; Mon, 04 Jun 2018 02:47:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751970AbeFDJq1 (ORCPT + 99 others); Mon, 4 Jun 2018 05:46:27 -0400 Received: from mgwkm04.jp.fujitsu.com ([202.219.69.171]:10813 "EHLO mgwkm04.jp.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751183AbeFDJq0 (ORCPT ); Mon, 4 Jun 2018 05:46:26 -0400 Received: from kw-mxq.gw.nic.fujitsu.com (unknown [192.168.231.130]) by mgwkm04.jp.fujitsu.com with smtp id 3eba_d019_63b6046e_02ff_4869_a3ba_5dff520cac02; Mon, 04 Jun 2018 18:46:20 +0900 Received: from g01jpfmpwyt02.exch.g01.fujitsu.local (g01jpfmpwyt02.exch.g01.fujitsu.local [10.128.193.56]) by kw-mxq.gw.nic.fujitsu.com (Postfix) with ESMTP id A40BEAC00BB for ; Mon, 4 Jun 2018 18:46:19 +0900 (JST) Received: from G01JPEXCHYT13.g01.fujitsu.local (G01JPEXCHYT13.g01.fujitsu.local [10.128.194.52]) by g01jpfmpwyt02.exch.g01.fujitsu.local (Postfix) with ESMTP id 76B3458421F; Mon, 4 Jun 2018 18:46:18 +0900 (JST) Received: from G01JPEXMBYT03.g01.fujitsu.local ([10.128.194.67]) by G01JPEXCHYT13 ([10.128.194.52]) with mapi id 14.03.0352.000; Mon, 4 Jun 2018 18:46:18 +0900 From: "Hatayama, Daisuke" To: "'tj@kernel.org'" CC: "'gregkh@linuxfoundation.org'" , "Okajima, Toshiyuki" , "linux-kernel@vger.kernel.org" , "'ebiederm@aristanetworks.com'" Subject: RE: [RESEND PATCH v2] kernfs: fix dentry unexpected skip Thread-Topic: [RESEND PATCH v2] kernfs: fix dentry unexpected skip Thread-Index: AdP2gtQcFftKX6rKRguW2o+iRXsAXgAm4bKAAJr88AD//+p/gP/7MDrw Date: Mon, 4 Jun 2018 09:46:17 +0000 Message-ID: <33710E6CAA200E4583255F4FB666C4E21B65E08B@G01JPEXMBYT03> References: <33710E6CAA200E4583255F4FB666C4E21B63D491@G01JPEXMBYT03> <20180529162627.GH1351649@devbig577.frc2.facebook.com> <33710E6CAA200E4583255F4FB666C4E21B65779C@G01JPEXMBYT03> <20180601170717.GY1351649@devbig577.frc2.facebook.com> In-Reply-To: <20180601170717.GY1351649@devbig577.frc2.facebook.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-securitypolicycheck: OK by SHieldMailChecker v2.5.2 x-shieldmailcheckerpolicyversion: FJ-ISEC-20170217-enc x-shieldmailcheckermailid: a0eb8eb1e96e46dfb0d5c10c9d2c8f0d x-originating-ip: [10.124.89.120] Content-Type: text/plain; charset="iso-2022-jp" MIME-Version: 1.0 X-SecurityPolicyCheck-GC: OK by FENCE-Mail X-TM-AS-MML: disable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----Original Message----- > From: Tejun Heo [mailto:htejun@gmail.com] On Behalf Of 'tj@kernel.org' > Sent: Saturday, June 2, 2018 2:07 AM > To: Hatayama, Daisuke > Cc: 'gregkh@linuxfoundation.org' ; Okajima, > Toshiyuki ; > linux-kernel@vger.kernel.org; 'ebiederm@aristanetworks.com' > > Subject: Re: [RESEND PATCH v2] kernfs: fix dentry unexpected skip > > Hello, > > On Fri, Jun 01, 2018 at 09:25:32AM +0000, Hatayama, Daisuke wrote: > > kernfs_dir_pos() checks if a kernfs_node object given as one of its > > arguments is still active and if so returns it, or returns a > > kernfs_node object that is most equal (possibly smaller and larger) to > > the given object. > > Sometimes they're duplicate operations tho, which is exactly the bug > the posted patch is trying to fix. What I'm suggesting is instead of > leaving both instances and skipping one conditionally, put them in one > place and trigger only when necessary. The sequence of operations > would be exactly the same. The only difference is how the code is > organized. > I see and I think Eric's patch is written as you suggest very well. > > kernfs_dir_next_pos() returns a kernfs_node object that is next to the > > object given by kernfs_dir_pos(). > > > > Two functions does different things and both need to skip inactive > > nodes. I don't think it natural to remove the skip only from > > kernfs_dir_pos(). > > > > OTOH, throughout getdents(), there is no case that the kernfs_node > > object given to kernfs_dir_pos() is used afterwards in the > > processing. So, is it enough to provide kernfs_dir_next_pos() only? > > Then, the skip code is now not duplicated. > > > > The patch below is my thought. How do you think? > > > > But note that this patch has some bug so that system boot get hang > > without detecting root filesystem disk :) I'm debugging this now. > > I haven't looked into the code that closely but given that we had > cases where both skippings were fine and not, the condition is likely > gonna be a bit tricker? I agree to this version looks a bit tricker. But I think once the skipping code is separated as Eric's patch, it would be resolved naturally. > > Thanks. > > -- > tejun >