Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp824350imm; Fri, 1 Jun 2018 10:08:01 -0700 (PDT) X-Google-Smtp-Source: ADUXVKL40XliwAdZL1R6tFpUXp+kfLmfJ825f9zpfdlzXveL32Wc8YETPdl2La7mBrYGHLQZ6u8s X-Received: by 2002:a63:b505:: with SMTP id y5-v6mr3687921pge.213.1527872881590; Fri, 01 Jun 2018 10:08:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527872881; cv=none; d=google.com; s=arc-20160816; b=qECWXD4Tb/QQlmRa8y4o7R7i9tz7mMUv+3sYnwDaB8bZfAovv+9JS3h9CJ0KiozjEp tH+EN+5YIitMQz08OH/Ym3iGYdlVn9KfgEQ2X4GxUNiJ4iJ2+LSk4y1mFBJNWXepBJ2H jt7BgHM2XlOzFl+gPiOe6fjnDM4EQVsJaHoNKJiZT836GMMu8pfC7XxA7fx6Lgir9N1T RRYLIbig0gcrfGbCO7Ym6udNPM6jgipOZEI4U5xCQ08RVBdAh92Tewi1rUuHq6lltEel PxWQVvl6ymlLFmwiDgV/cbqrgmQnm3MLhnnpS48XQk2uvoZztyu2p+86797eRIEMhGcU gzEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=JoOOMaOzDgZ2C4VHnyR9LBWitONEuSyyXWduPvDvl6w=; b=Eu3wau0S6kPw7UkSY1CudxS3H/yWzWbJTwvoYY1Fi/bLcU0P+ei5K9Es4vHtGO0zZJ 8Md6huhy2isH352R3Y2mem/EYg10YMhwVeD1mlb4z4os67EJNqZAr6kWaRj14B5YZPxy Ggi6jNBavHrOTiWHw/T+EcJh2NBzmZR3aXdUIlYXbFCA2I9mKqCgJ58/sbl0Knpj0fmY 02ooftmkfx9gKJdwDuDf9anPQOKKgwPe884/U4LOcE9WkklMrSgSF/8lvC5Giu4JuBn7 YKxm7zb3WKdUjesvYTkk3HnbGmRQurjOsQ6RSzwdIs0mqLax0DvoIqklvxQEhHPuvPYg T+zA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=IxNYIO2s; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e200-v6si17970329pfh.64.2018.06.01.10.07.46; Fri, 01 Jun 2018 10:08:01 -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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=IxNYIO2s; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752998AbeFARHX (ORCPT + 99 others); Fri, 1 Jun 2018 13:07:23 -0400 Received: from mail-yw0-f194.google.com ([209.85.161.194]:45034 "EHLO mail-yw0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751584AbeFARHT (ORCPT ); Fri, 1 Jun 2018 13:07:19 -0400 Received: by mail-yw0-f194.google.com with SMTP id p14-v6so8504577ywm.11 for ; Fri, 01 Jun 2018 10:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=JoOOMaOzDgZ2C4VHnyR9LBWitONEuSyyXWduPvDvl6w=; b=IxNYIO2sgT8Zp6rmsqbkcHCRiNeHjQJ35vjFSTaH9PhPMvU8dDuvne0VQaLGTkzz4P 7wzl6ftcVUmoBKXEwpDYitO/waYsST6rrF+p3HAaqJkmkVMTGjeTWmLtLyCs2CLACR1n 1bskKuKgq50pycOZrJeVoB1rmorEThAuxK/2fVLeK12IhpncGQSwCOuee7sJelL837+w jH2niLAA17Enzx3mNvAUMHJ6nRxMzQxmMqeWamvBRI+0CCUv9atlA36gNglOAuo2O5nN iEfQf77hMsZHFd/8wrXHoD4MZFkS/gonle+GDDAxWWJrt0DaFo62caZgwfomYFhvhr8k 5nhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=JoOOMaOzDgZ2C4VHnyR9LBWitONEuSyyXWduPvDvl6w=; b=Lgzha2V9uLHLcX41k99Z4e6XcS7k3UGP3O6LuY2zowoiaFiGiCY1qP8L3CHQL4DrR5 MVY2lC8slj0aneANbYEK+hIwB5N2vUzEwoQYiGNlQYm05jvBvQY1gmm6GN+7RF+ERQgz XaIyxwcPO7wBBWbj3+d23uF4s5qt/jl++2Dt+KrkAkSeN+Zh/9hVLaxwMHBs/uHwZ+Qw cK1MHwdkFAon8k6sKOm6ODNyhliiesgSiHCdWbU7nAAoa2R8vBn930rZRWHSLmSy0PY8 eHZ3+g7RwWo1Vo3xZ6NfIgbG5o2169Cwqb6y1AJkMRiZUArN58pzaghccjTtIje8T01O VSVg== X-Gm-Message-State: APt69E0gFJ2fa0dM3WbY6dPNcJANs3Z4WPSjYFzjXWeAHBJSX2XKsxuZ tU5rypxak36NQwoLcqW6p2k= X-Received: by 2002:a0d:de85:: with SMTP id h127-v6mr542730ywe.75.1527872839281; Fri, 01 Jun 2018 10:07:19 -0700 (PDT) Received: from localhost ([2620:10d:c091:200::fbb7]) by smtp.gmail.com with ESMTPSA id v130-v6sm11109733ywb.50.2018.06.01.10.07.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jun 2018 10:07:18 -0700 (PDT) Date: Fri, 1 Jun 2018 10:07:17 -0700 From: "'tj@kernel.org'" 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 Message-ID: <20180601170717.GY1351649@devbig577.frc2.facebook.com> References: <33710E6CAA200E4583255F4FB666C4E21B63D491@G01JPEXMBYT03> <20180529162627.GH1351649@devbig577.frc2.facebook.com> <33710E6CAA200E4583255F4FB666C4E21B65779C@G01JPEXMBYT03> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33710E6CAA200E4583255F4FB666C4E21B65779C@G01JPEXMBYT03> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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? Thanks. -- tejun