Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3572334imm; Tue, 29 May 2018 09:27:25 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr/s5zD7cgQzvlUef7pC3hZs9CM4c5J50bGbhA3Se+GRz3gPnTHwKG9BtC56jJk7VAPlyFK X-Received: by 2002:a65:5c09:: with SMTP id u9-v6mr14440493pgr.304.1527611245558; Tue, 29 May 2018 09:27:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527611245; cv=none; d=google.com; s=arc-20160816; b=E3iCLq6cthMq1fdam9bZM2YbmeA1Z/geb2QGjGLhVNrJW97sshjCyx0buf9VmJB6Xk ja4ZtWnI+DiMW105NookxBIVjYUwul1K/FWLX7rDrLlxbE0FnhB8e4PYuDz4ie3nVr5p sxTJaoCA2YlpxMXC+vRxGlowwbsR9cM07W+ngnuRF5pm0xG6N5ufijXLna8k9IKPB4nU nrQFbgZ0IsCz0Do0cUDXztB2jTBL12FnmWvOp5SADU+G9sNax92DgZKiBqVh/tGqt74+ IuMTgO/p67gVX9OOzUCWs1qxhPR7cNVVL+e0Coh/g0xDmHqOswu/2FQPynhZHkZKA7Dm Hkvg== 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=2YC4D7v1YGpkB7kGy0Z0vFvJTT4rG9XCgh7nFMPkxmk=; b=Gdom9UkDzSNE0Hwm/tc7iGADT+/BMf+TQOgqQI0RtvrmD4/ZVz+CjFOMxABZ37Xpbf Nqi9MrYpqXip97u6w1PFg0LuefiBwQAeE1JtxgUxIjH+X8NCOzKP3quruO873I4h8Ar8 tKmO82NymZ6jw9bWE9tALcCLh0QIKV/cVbuSxOieAyPZNUcHk8Mq5gCaJ1oog/LZDHtq wOpIQzNU086V0PWq3NRA8NuoFfx/NkNtp7aLEwccpaDlaSaQfq2AZeqml0QyGCKfVtV9 O+zwDX//qcXjVn8cIyaKZ5dbcK1NhAGhlRWoqbhJvvQIfT43drEevEZByAZEPtmJwvoh OKAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=JQb0yysR; 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 s7-v6si25287216pgr.670.2018.05.29.09.27.11; Tue, 29 May 2018 09:27:25 -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=JQb0yysR; 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 S964951AbeE2Q0e (ORCPT + 99 others); Tue, 29 May 2018 12:26:34 -0400 Received: from mail-yb0-f194.google.com ([209.85.213.194]:34906 "EHLO mail-yb0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936536AbeE2Q0a (ORCPT ); Tue, 29 May 2018 12:26:30 -0400 Received: by mail-yb0-f194.google.com with SMTP id y3-v6so5291194ybb.2 for ; Tue, 29 May 2018 09:26:30 -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=2YC4D7v1YGpkB7kGy0Z0vFvJTT4rG9XCgh7nFMPkxmk=; b=JQb0yysRlq2vet+peIu+8e5gStF2vfJ7csRV45VrozlpOAfGPklTXPlovI3eU6/KGn qAuzUf0xhXCf6WSwNScTNJTu0vbIe3XBhGVVYAEAqJyf6nz4DFlOfsf/bTEhxM/xsKSv strQMThB8YWXoNtDLDO78KfGQXJ+wrO3vRE4HsEUMocS0jCKIfAnYWTrVKpaTnql7XMd fnbmlvhqDKJgZbAQPMvisVdqZKq2t0RdJgRU+sDDO2xLfmQRJCW+7yP4u+2A9T04NKL+ 7MSmgRLbeDwdamRMlLen7I0ZxmflSvJUtD4KsJxa1PrgUCYsGW05UMp4/tT99B4XRGKW N7dA== 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=2YC4D7v1YGpkB7kGy0Z0vFvJTT4rG9XCgh7nFMPkxmk=; b=m5v2g2g1pIFnpD+3OlJSorGIGcwn/984cPPS7RelJWrES75PPnCnx/SM9d9/5+N7n5 Zo1yM+9fLsoD3UERERNY5PLJmnRzk1LxUfFkLHUg8wBFNeunDApYstKAXR+6150sUXfF h+SS7hRzgbqjDfL3kBWsXYHUldkYnpuHKiPPo6m2pvABXVEEhjzYgVKeA/DssVu5eeoX BjqiqzweAqiUv2+Sx5bwM9K6i0Jg0SxD/CmZ1AYXiYMcpFNmm67JcBuWfKy6QTPh0pmL qw0uPOkOpAjd7Jb7+8n29jxchIAtRaJ344Tw2Qk3Z70O2itFfNcEpw/F/bOtxbh4E1sZ xycw== X-Gm-Message-State: ALKqPwfWJZ4giCF89VPPfFqoi5t6ZYZoUxLk4JjJcGxOe7Fjk/KdN7Sq KihtRAnTk/k12jXuFT3mQUM= X-Received: by 2002:a25:f41:: with SMTP id 62-v6mr10204709ybp.200.1527611190167; Tue, 29 May 2018 09:26:30 -0700 (PDT) Received: from localhost ([2620:10d:c091:180::1:7e98]) by smtp.gmail.com with ESMTPSA id q129-v6sm5868587ywb.55.2018.05.29.09.26.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 May 2018 09:26:29 -0700 (PDT) Date: Tue, 29 May 2018 09:26:27 -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: <20180529162627.GH1351649@devbig577.frc2.facebook.com> References: <33710E6CAA200E4583255F4FB666C4E21B63D491@G01JPEXMBYT03> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33710E6CAA200E4583255F4FB666C4E21B63D491@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 Mon, May 28, 2018 at 12:54:03PM +0000, Hatayama, Daisuke wrote: > diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c > index 89d1dc1..3aeeb7a 100644 > --- a/fs/kernfs/dir.c > +++ b/fs/kernfs/dir.c > @@ -1621,8 +1621,10 @@ static int kernfs_dir_fop_release(struct inode *inode, struct file *filp) > static struct kernfs_node *kernfs_dir_next_pos(const void *ns, > struct kernfs_node *parent, ino_t ino, struct kernfs_node *pos) > { > + struct kernfs_node *orig = pos; > + > pos = kernfs_dir_pos(ns, parent, ino, pos); > - if (pos) { > + if (pos && kernfs_sd_compare(pos, orig) <= 0) { Hmm... the code seems a bit unintuitive to me and I wonder whether it's because there are two identical skipping loops in kernfs_dir_pos() and kernfs_dir_next_pos() and we're now trying to selectively disable one of them. Wouldn't it make more sense to get rid of it from kernfs_dir_pos() and skip explicitly only when necessary? Thanks. -- tejun