Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2529629imm; Thu, 7 Jun 2018 12:11:30 -0700 (PDT) X-Google-Smtp-Source: ADUXVKL4BKpp8oBlX/1+UIxslqPkC9P9DncVRcxwB3g4O5cDTyDK7/Z9jac3O1A69MlpGCt2fngy X-Received: by 2002:a65:4783:: with SMTP id e3-v6mr2589458pgs.235.1528398690533; Thu, 07 Jun 2018 12:11:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528398690; cv=none; d=google.com; s=arc-20160816; b=HxUm7Ihn/G0gXqImJcloQa9WaUm0Uvg9qzfYY3UXZfZh0SsS1Amabep0jFJzBvDviX +9afMMsAkT5Gh4BAQQN7MoR/2+11zdJvCT8oWSGvIgJHc6w7y/7d35bz0j6SHCkpNbxU QOWr9116lG0nP19SnI9tdDK+oXEuNt0Uy4PLe9opFIQzfJIRxftL6VKDD/I/nQyuKovp x1ansvRU45PLtBTRh8hVR1BCBXESgbjAbtuOqOqyCUDRZbuuYycCtuBtqlQ1hRON+IyB mNzZDw5dPv/lv7Qx3hqKObjgsCStCCfQoMh8IiYQqEdLDsCH980uodKlrLOQEGXyI6cj N63w== 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:arc-authentication-results; bh=6wFbKU9Hzlan8yefmlzF87syVvJE5KWL4AEHeBqCpzQ=; b=pyxUVmGbtATJggi4Mwo7wDLNQ1b8L24Of+iUYMpXfGjHqSS1KpeWJzNvEHUWG2Ko93 T7BX1HX18LwVeBLr8ZxQ3Fy9aXDKLhre2cGVUNixyYEv8d7FYUj/avbABzYiyZIt9W07 HZHUPfznZlfE0EGBcxsjtR2NeZsFtbRilmjJKo2UVg4fMywhSAkoPGAJCUi3fPfrIncz YC3zJUbgHaZaVGgLgYzmrhTPKfdZOaEAOZECPPUp/w+EkDiyBLttWCz7GnbNXqceSLSD T+3uCETXRLFNeVIJZcPzNrTjGti5tgYDlyUFpl24DKloFI3lDFtpWregFqCRmuEhi38a sAEQ== 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 v38-v6si55981564plg.283.2018.06.07.12.11.16; Thu, 07 Jun 2018 12:11:30 -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 S1753988AbeFGSgb (ORCPT + 99 others); Thu, 7 Jun 2018 14:36:31 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:52496 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753716AbeFGSga (ORCPT ); Thu, 7 Jun 2018 14:36:30 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1fQzlk-00039U-BS; Thu, 07 Jun 2018 18:36:20 +0000 Date: Thu, 7 Jun 2018 19:36:20 +0100 From: Al Viro To: "Eric W. Biederman" Cc: "'tj@kernel.org'" , "Hatayama, Daisuke" , "'gregkh@linuxfoundation.org'" , "Okajima, Toshiyuki" , "linux-kernel@vger.kernel.org" , "'ebiederm@aristanetworks.com'" Subject: Re: [CFT][PATCH] kernfs: Correct kernfs directory seeks. Message-ID: <20180607183620.GU30522@ZenIV.linux.org.uk> References: <33710E6CAA200E4583255F4FB666C4E21B63D491@G01JPEXMBYT03> <87wovhqex2.fsf@xmission.com> <87po17r9ek.fsf_-_@xmission.com> <33710E6CAA200E4583255F4FB666C4E21B65E04E@G01JPEXMBYT03> <87sh62k3vk.fsf@xmission.com> <33710E6CAA200E4583255F4FB666C4E21B66BAC8@G01JPEXMBYT03> <87h8mhgsh3.fsf@xmission.com> <20180605154210.GD1351649@devbig577.frc2.facebook.com> <8736y1dt1m.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8736y1dt1m.fsf@xmission.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 05, 2018 at 12:47:33PM -0500, Eric W. Biederman wrote: > Sigh, I have found another issue with kernfs_fop_readdir. > > We are not currently protecting file->private_data with the kernfs_mutex > or any other kind of serialization. Which means if two processes are > calling readdir on the same file descriptor we might get unpredictable > behavior. > > It doesn't look too bad and easy enough to fix, but definitely something > to be watchful of. As discussed off-list - this is not a problem; getdents() et.al. are serialized on per-struct-file basis by fdget_pos() in relevant syscalls, since all directories automatically get FMODE_ATOMIC_POS in ->f_mode.