From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DBC0FC433EF for ; Wed, 8 Sep 2021 12:35:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C7B6D6108D for ; Wed, 8 Sep 2021 12:35:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349399AbhIHMgc (ORCPT ); Wed, 8 Sep 2021 08:36:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:34930 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234005AbhIHMg1 (ORCPT ); Wed, 8 Sep 2021 08:36:27 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 69C5861139; Wed, 8 Sep 2021 12:35:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1631104519; bh=COdmmMC2NhlKWVFj31C7uZM1YgxY0x3WYgYnuLq4PgA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=m/A4aDcK8Fv+z1kk7N/+S/Z3baBZOHsGdy10qq5md1XsQ8bUS8wIj5okQG8vTNMFm nrcXld76SdV+JI9/tX8X+Si84zT+7egkmC/KeX4GEkZMK8VO8av1RBW8ccmj/CCS9n NEZkkAMiJJXg1gdlLDAxIH1S14J5bZCRHo4duD3c= Date: Wed, 8 Sep 2021 14:35:17 +0200 From: Greg KH To: Yi Tao Cc: tj@kernel.org, lizefan.x@bytedance.com, hannes@cmpxchg.org, mcgrof@kernel.org, keescook@chromium.org, yzaikin@google.com, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-fsdevel@vger.kernel.org, shanpeic@linux.alibaba.com Subject: Re: [RFC PATCH 1/2] add pinned flags for kernfs node Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 08, 2021 at 08:15:12PM +0800, Yi Tao wrote: > This patch is preparing for the implementation of cgroup pool. If a > kernfs node is set to pinned. the data of this node will no longer be > protected by kernfs internally. When it performs the following actions, > the area protected by kernfs_rwsem will be protected by the specific > spinlock: > 1.rename this node > 2.remove this node > 3.create child node > > Suggested-by: Shanpei Chen > Signed-off-by: Yi Tao > --- > fs/kernfs/dir.c | 74 ++++++++++++++++++++++++++++++++++++-------------- > include/linux/kernfs.h | 14 ++++++++++ > 2 files changed, 68 insertions(+), 20 deletions(-) Ugh, this is going to get messy fast. Why are kernfs changes needed for this? kernfs creation is not necessarily supposed to be "fast", what benchmark needs this type of change to require the addition of this complexity? And how are we going to audit things to ensure the "pinning" is working properly? thanks, greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Subject: Re: [RFC PATCH 1/2] add pinned flags for kernfs node Date: Wed, 8 Sep 2021 14:35:17 +0200 Message-ID: References: Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1631104519; bh=COdmmMC2NhlKWVFj31C7uZM1YgxY0x3WYgYnuLq4PgA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=m/A4aDcK8Fv+z1kk7N/+S/Z3baBZOHsGdy10qq5md1XsQ8bUS8wIj5okQG8vTNMFm nrcXld76SdV+JI9/tX8X+Si84zT+7egkmC/KeX4GEkZMK8VO8av1RBW8ccmj/CCS9n NEZkkAMiJJXg1gdlLDAxIH1S14J5bZCRHo4duD3c= Content-Disposition: inline In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Yi Tao Cc: tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org, hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org, mcgrof-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org, yzaikin-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, shanpeic-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org On Wed, Sep 08, 2021 at 08:15:12PM +0800, Yi Tao wrote: > This patch is preparing for the implementation of cgroup pool. If a > kernfs node is set to pinned. the data of this node will no longer be > protected by kernfs internally. When it performs the following actions, > the area protected by kernfs_rwsem will be protected by the specific > spinlock: > 1.rename this node > 2.remove this node > 3.create child node > > Suggested-by: Shanpei Chen > Signed-off-by: Yi Tao > --- > fs/kernfs/dir.c | 74 ++++++++++++++++++++++++++++++++++++-------------- > include/linux/kernfs.h | 14 ++++++++++ > 2 files changed, 68 insertions(+), 20 deletions(-) Ugh, this is going to get messy fast. Why are kernfs changes needed for this? kernfs creation is not necessarily supposed to be "fast", what benchmark needs this type of change to require the addition of this complexity? And how are we going to audit things to ensure the "pinning" is working properly? thanks, greg k-h