From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932128AbbCZVlM (ORCPT ); Thu, 26 Mar 2015 17:41:12 -0400 Received: from mail-ie0-f177.google.com ([209.85.223.177]:33666 "EHLO mail-ie0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932067AbbCZVlG (ORCPT ); Thu, 26 Mar 2015 17:41:06 -0400 MIME-Version: 1.0 X-Originating-IP: [122.106.150.15] In-Reply-To: <20150326150223.GA1953@htj.duckdns.org> References: <1426307835-5893-1-git-send-email-cyphar@cyphar.com> <1426307835-5893-3-git-send-email-cyphar@cyphar.com> <20150316165335.GC8353@htj.duckdns.org> <20150326150223.GA1953@htj.duckdns.org> Date: Fri, 27 Mar 2015 08:41:05 +1100 Message-ID: Subject: Re: [PATCH v6 2/3] cgroups: allow a cgroup subsystem to reject a fork From: Aleksa Sarai To: Tejun Heo Cc: lizefan@huawei.com, mingo@redhat.com, peterz@infradead.org, richard@nod.at, =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, >> callback if the association changes [we could call it something else if you >> like, since reapply_fork() is a pids-specific name -- what about switch_fork(), >> reassoc_fork(), re_fork() or something to show that it's a callback if the >> association changes?] (the subsystem can decide if they want to ignore it / if >> they don't want to touch it) and we deal with pinning / dropping the ref of the >> css_set for the current task inside the cgroup_* callbacks. That way, we don't >> start messing around with post-fork() callbacks that aren't related to the new >> conditional stuff. > > You can't pin css_set from inside cgroup callbacks. It's a construct > which in general shouldn't be accessible outside cgroup core. Yeah, sorry I meant css (you aren't pinning, but you're still saving under RCU and dealing with the association-related stuff inside post_fork). >> I mean, if you want to have a random, completely unused and essentially >> vestigial argument to ss->fork() [if you don't use the new can_fork() callbacks >> (and actually care about storing private data)] then I can just write that. It >> just looks like a weird callback API imho. > > It's an opaque token from pre. If a subsys doesn't have pre, it's > NULL. I don't see anything weird about that, so let's please go that > way. Alright, if you think that's the best way. I still think it's weird, but I guess that's probably just down to personal taste. -- Aleksa Sarai (cyphar) www.cyphar.com