All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	cgroups@vger.kernel.org, Alexander Viro <viro@zeniv.linux.org.uk>,
	Tejun Heo <tj@kernel.org>, Zefan Li <lizefan.x@bytedance.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Dave Chinner <dchinner@redhat.com>,
	Rik van Riel <riel@surriel.com>, Jiri Wiesner <jwiesner@suse.de>
Subject: Re: [RFC PATCH 0/3] Rework locking when rendering mountinfo cgroup paths
Date: Tue, 23 May 2023 14:09:12 +0200	[thread overview]
Message-ID: <20230523-salamander-gemeldet-b549ea345cf8@brauner> (raw)
In-Reply-To: <20230502133847.14570-1-mkoutny@suse.com>

On Tue, May 02, 2023 at 03:38:44PM +0200, Michal Koutný wrote:
> Idea for these modification came up when css_set_lock seemed unneeded in
> cgroup_show_path.
> It's a delicate change, so the deciding factor was when cgroup_show_path popped
> up also in some profiles of frequent mountinfo readers.
> The idea is to trade the exclusive css_set_lock for the shared
> namespace_sem when rendering cgroup paths. Details are described more in

I have no issue with the cgroup specific part of relying on
namespace_sem but kernel/cgroup/ has no business of being aware of
namespace semaphore in any way. Leave a comment to clarify what you're
doing but we're not going to sprinkle namespace_sem references - even if
only for the sake of lockdep - into other subsystems.

WARNING: multiple messages have this Message-ID (diff)
From: Christian Brauner <brauner@kernel.org>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	cgroups@vger.kernel.org, Alexander Viro <viro@zeniv.linux.org.uk>,
	Tejun Heo <tj@kernel.org>, Zefan Li <lizefan.x@bytedance.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Dave Chinner <dchinner@redhat.com>,
	Rik van Riel <riel@surriel.com>, Jiri Wiesner <jwiesner@suse.de>
Subject: Re: [RFC PATCH 0/3] Rework locking when rendering mountinfo cgroup paths
Date: Tue, 23 May 2023 14:09:12 +0200	[thread overview]
Message-ID: <20230523-salamander-gemeldet-b549ea345cf8@brauner> (raw)
In-Reply-To: <20230502133847.14570-1-mkoutny@suse.com>

On Tue, May 02, 2023 at 03:38:44PM +0200, Michal Koutný wrote:
> Idea for these modification came up when css_set_lock seemed unneeded in
> cgroup_show_path.
> It's a delicate change, so the deciding factor was when cgroup_show_path popped
> up also in some profiles of frequent mountinfo readers.
> The idea is to trade the exclusive css_set_lock for the shared
> namespace_sem when rendering cgroup paths. Details are described more in

I have no issue with the cgroup specific part of relying on
namespace_sem but kernel/cgroup/ has no business of being aware of
namespace semaphore in any way. Leave a comment to clarify what you're
doing but we're not going to sprinkle namespace_sem references - even if
only for the sake of lockdep - into other subsystems.

  parent reply	other threads:[~2023-05-23 12:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-02 13:38 [RFC PATCH 0/3] Rework locking when rendering mountinfo cgroup paths Michal Koutný
2023-05-02 13:38 ` Michal Koutný
2023-05-02 13:38 ` [RFC PATCH 1/3] cgroup: Drop unused function for cgroup_path Michal Koutný
2023-05-02 13:38   ` Michal Koutný
2023-05-02 19:58   ` Waiman Long
2023-05-02 13:38 ` [RFC PATCH 2/3] cgroup: Rely on namespace_sem in current_cgns_cgroup_from_root explicitly Michal Koutný
2023-05-02 13:38   ` Michal Koutný
2023-05-02 19:50   ` Waiman Long
2023-05-23 10:42   ` Christian Brauner
2023-05-23 10:42     ` Christian Brauner
2023-05-23 19:12     ` Tejun Heo
2023-05-02 13:38 ` [RFC PATCH 3/3] cgroup: Do not take css_set_lock in cgroup_show_path Michal Koutný
2023-05-02 13:38   ` Michal Koutný
2023-05-02 19:56   ` Waiman Long
2023-05-02 19:56     ` Waiman Long
2023-05-05 15:45   ` Tejun Heo
2023-05-05 17:32     ` Michal Koutný
2023-05-05 18:17       ` Tejun Heo
2023-05-09 10:34         ` Michal Koutný
2023-05-22 20:55           ` Tejun Heo
2023-05-23 12:09 ` Christian Brauner [this message]
2023-05-23 12:09   ` [RFC PATCH 0/3] Rework locking when rendering mountinfo cgroup paths Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230523-salamander-gemeldet-b549ea345cf8@brauner \
    --to=brauner@kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=dchinner@redhat.com \
    --cc=hannes@cmpxchg.org \
    --cc=jwiesner@suse.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --cc=mkoutny@suse.com \
    --cc=riel@surriel.com \
    --cc=tj@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.