Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp3002237pxa; Tue, 18 Aug 2020 04:07:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy9zCvv4MrLX4y7OR+DCtEGsTABAvnE7TqaLfC0EoxfSvNnZMqMDj2cfpxJQXhiT+0qpV58 X-Received: by 2002:a17:906:b2c3:: with SMTP id cf3mr20350256ejb.387.1597748834970; Tue, 18 Aug 2020 04:07:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597748834; cv=none; d=google.com; s=arc-20160816; b=XwyBxxZOwiJ7eFKTKebArGlDCCnEZMTb2HFZ2Eoz1D7gWYB/Mk+zCTYWflVkt6iEj3 eZ0LRm8fbketjSRDHFVI5OLqByjih5SutPChl95nujMgdjlCiszMJskRyzj1VKed4xXR LRKsNlgn1NazXtZwA6BfHUhu14hl8GKGapvu62CVsmzerFNpz+dTch56ttUGT/kFDVce 0tip3vjnsK1wzNSPt2U6HC10+06Tb+moUh/EYIVbPWYK8/RQ9mUy/MDr5wEKzMCnQSJ5 qk3z5boj0GIhbVyf2l/HRmnlZCFJbeGYwMDNuCWdyIAv1MR2MgsbFSTKEcELSSeNNmei ll5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=sKcEAR1JIDyNYkoxL2yGA0tgIV7bIz93oo4Wl5qNtuQ=; b=ErnFZgODZPGzaIZyX0klzcNMpfsL1tTQ2pBvLjhtHJ2ZxvT50UENgrNPWuFI/8zMMh pxTaraddtXSlLtFIxuAaxHxhGm0ky5T+EoyngVMatqOAD38pHqFdhWCV9kRzjzAHkbmd tWvBpsKYPO5j0wWnm4qEEwfpq3mwy61TQ7cQyE9UUjAm99avi+nDU23CFpM2dvn87TpI Fx/uMnjsHcxbFazOfPZpzR57U9ZTz4KfXImgWTCrbaXxxZtUAaoQQcUTzqOf7TLXxRyf YCZdep0zc2UVJyRmkURt1MQzB7EWUoGyttgsThntrG3GNnqMINZNyYxeIZR/cAMu5XNE C7FA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a15si13262208ejb.44.2020.08.18.04.06.50; Tue, 18 Aug 2020 04:07:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726599AbgHRLGF (ORCPT + 99 others); Tue, 18 Aug 2020 07:06:05 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:39898 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726273AbgHRLGD (ORCPT ); Tue, 18 Aug 2020 07:06:03 -0400 Received: from ip5f5af70b.dynamic.kabel-deutschland.de ([95.90.247.11] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1k7zRG-0005Sq-Q5; Tue, 18 Aug 2020 11:05:58 +0000 Date: Tue, 18 Aug 2020 13:05:56 +0200 From: Christian Brauner To: Linus Torvalds Cc: "Eric W. Biederman" , Linux Kernel Mailing List , "" , criu@openvz.org, bpf , Alexander Viro , Oleg Nesterov , Cyrill Gorcunov , Jann Horn , Kees Cook , Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= , Jeff Layton , Miklos Szeredi , Matthew Wilcox , "J. Bruce Fields" , Matthew Wilcox , Trond Myklebust , Chris Wright , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , John Fastabend , KP Singh Subject: Re: [PATCH 09/17] file: Implement fnext_task Message-ID: <20200818110556.q5i5quflrcljv4wa@wittgenstein> References: <87ft8l6ic3.fsf@x220.int.ebiederm.org> <20200817220425.9389-9-ebiederm@xmission.com> <875z9g7oln.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 17, 2020 at 06:17:35PM -0700, Linus Torvalds wrote: > On Mon, Aug 17, 2020 at 6:06 PM Eric W. Biederman wrote: > > > > I struggle with the fcheck name as I have not seen or at least not > > registed on the the user that just checks to see if the result is NULL. > > So the name fcheck never made a bit of sense to me. > > Yeah, that name is not great. I just don't want to make things even worse. > > > I will see if I can come up with some good descriptive comments around > > these functions. Along with describing what these things are doing I am > > thinking maybe I should put "_rcu" in their names and have a debug check > > that verifies "_rcu" is held. > > Yeah, something along the lines of "rcu_lookup_fd_task(tsk,fd)" would > be a *lot* more descriptive than fcheck_task(). > > And I think "fnext_task()" could be "rcu_lookup_next_fd_task(tsk,fd)". > > Yes, those are much longer names, but it's not like you end up typing > them all that often, and I think being descriptive would be worth it. > > And "fcheck()" and "fcheck_files()" would be good to rename too along > the same lines. > > Something like "rcu_lookup_fd()" and "rcu_lookup_fd_files()" respectively? > > I'm obviously trying to go for a "rcu_lookup_fd*()" kind of pattern, > and I'm not married to _that_ particular pattern but I think it would > be better than what we have now. In fs/inode.c and a few other places we have the *_rcu suffix pattern already so maybe: fcheck() -> fd_file_rcu() or lookup_fd_rcu() fcheck_files() -> fd_files_rcu() or lookup_fd_files_rcu() fnext_task() -> fd_file_from_task_rcu() or lookup_next_fd_from_task_rcu() rather than as prefix or sm. Christian