Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3880624imu; Mon, 12 Nov 2018 01:59:18 -0800 (PST) X-Google-Smtp-Source: AJdET5dGELt8HRV4Q/LFazPMAYTuCIEBdXsXuK7inKvokPwk+BzaYKW5G9vKj2ctA95jQA478kwE X-Received: by 2002:a62:7e93:: with SMTP id z141-v6mr260387pfc.241.1542016758393; Mon, 12 Nov 2018 01:59:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542016758; cv=none; d=google.com; s=arc-20160816; b=r4YcTVYLgr2lgefU2Kx8zPT6tXqqgfsx+pg/dwYvS7vAmZSBZqmXEpAmzsSwLb/i1T 2Xl+JB3PZz4BYIGf4vOTBFXsB0dRJqkLpCZNs4GD1QweyeC/uCn0rN//cbD8JifFJeuT 4w6jiJwd51dam8vWwUXu8g0KQkgb9VMLqqP35rkx5vBgUPOizz2SIW8QpYRNIB4L7dyw RWRlBFkK/9CIRWMt3iIgSNtJFpHPG1lfFq2hQsbKNKX/z4QKTOYh0AuWAnYONjzS+l29 59XcknZ/y+yyfAIAiW/3NLnm+JG9DxB30GmG3R7szY0GfZiNHglvSduN2axDLatfY6Hj Al9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature; bh=symMBI0AEZzZj3jXIeKSzDkA196PYWRtmcxOC8y15f0=; b=CEd+1etEgUeFunXgGfKn5VoWFOcAw43b11gEpHr1UpvSG+sp9J4IMGfughntWVJvSf PEUk8Rjz2coQD7/CEC91Sk4HxGkyHEqToWHw6axtLMj58r+jHev5+HgHKjp6Q8Rhc5j8 foQ2ngal4oLoNSTzak413lwlHTHItBPYftZSAqQADoOj/TwhmijPM41rDAo9LnwBUbO5 /+PwcDT8AEToAGsFTOEOEKr6Rl3QcNTyGVEk0002wkFZtPPSQTenDQdliWT0wMXo7beD hAnpjzKqaJia+P1uGYWGsGUONO13jtGta9Sz+UdV2WQ0h6H3uxlS0AwsnMNc8pFsDlCU mHfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=PLZQsYk8; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t25-v6si19530845pfm.152.2018.11.12.01.59.03; Mon, 12 Nov 2018 01:59:18 -0800 (PST) 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; dkim=pass header.i=@linaro.org header.s=google header.b=PLZQsYk8; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729214AbeKLTtq (ORCPT + 99 others); Mon, 12 Nov 2018 14:49:46 -0500 Received: from mail-wr1-f65.google.com ([209.85.221.65]:37080 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728810AbeKLTtn (ORCPT ); Mon, 12 Nov 2018 14:49:43 -0500 Received: by mail-wr1-f65.google.com with SMTP id o15-v6so8559267wrv.4 for ; Mon, 12 Nov 2018 01:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=symMBI0AEZzZj3jXIeKSzDkA196PYWRtmcxOC8y15f0=; b=PLZQsYk8zx5Q6H+H+XLenq9zy5WTTXzbjsINOjU45dyhex93N5hCav2aGJsu5FmV2p TwXAeQNkschEKoKPJaFtk3IKly/y954thUgWArusiHRfCOorjEt67znBLPbkOXdFz+uH jkwbbS5vgHj6TxcDWHCYS9W4Y1QoGNib19Qyw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=symMBI0AEZzZj3jXIeKSzDkA196PYWRtmcxOC8y15f0=; b=LybT6D7ToVWOtAqSFMnXxBrajNgK2ldA/pev9b/rP8SB2ZPtNR9EnRQkskMIIWXoKt A5AGzVSlOjjhrcvK+CoayS0V6SAjSUdDHwkMVd0URuzpbvdWXo0kqZl19D1i7VrdEP2j jMAxu9deZ6yyeXkGHF/rfUXUKEtrkDrgNX3ugj5NioT4iZi8ybYsF6HrA5ZR7vqhDJzG Ghp2Qw+4bZXtwnM2r3keF2Mrh0d4nWU3OLvTKuG1H9WukAbdQ8wYnWscm8gxb2P5pAIw H3K71bLwETBj1yWL/MjBQ/jwK2+PCgpgMFlE/w9nkYj4epR5pDiM/4CVvZkNv1ThzTZB pBkw== X-Gm-Message-State: AGRZ1gJGEzp4JOfr3Dk2QMwzuR8c7nkhNYTirTH82iHJ1wFX4UMqqcwg XuHfV2h2HCbdc3xm603J88TUbQ== X-Received: by 2002:adf:f8d0:: with SMTP id f16-v6mr292162wrq.265.1542016633209; Mon, 12 Nov 2018 01:57:13 -0800 (PST) Received: from localhost.localdomain ([93.68.220.21]) by smtp.gmail.com with ESMTPSA id r14-v6sm21273089wro.8.2018.11.12.01.57.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Nov 2018 01:57:12 -0800 (PST) From: Paolo Valente To: Jens Axboe , Greg Kroah-Hartman , Tejun Heo , Li Zefan , Angelo Ruocco , Dennis Zhou , Josef Bacik , Liu Bo , Bart Van Assche , Johannes Weiner Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, ulf.hansson@linaro.org, linus.walleij@linaro.org, broonie@kernel.org, bfq-iosched@googlegroups.com, oleksandr@natalenko.name, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, Jonathan Corbet , Paolo Valente Subject: [PATCH 04/12] cgroup: link cftypes of the same subsystem with the same name Date: Mon, 12 Nov 2018 10:56:24 +0100 Message-Id: <20181112095632.69114-5-paolo.valente@linaro.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20181112095632.69114-1-paolo.valente@linaro.org> References: <20181112095632.69114-1-paolo.valente@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Angelo Ruocco When a cgroup policy is activated, it creates its files in its subsystem directory. Two policies are not able to create a file with the same name: if a policy tries to create a file that has the same name as a file created by another policy, the cgroup core stops it, warns the user about the error, and then proceeds to delete all the files created by the last policy. However, in some specific situations, it may be useful for two or more policies to use a common file, e.g., the I/O schedulers bfq and cfq have the same "weight" attribute, that changes the behavior of the two schedulers in a similar way. This commit prepares the interface that allows two policies of the same subsystem to share files. It adds a flag CFTYPE_SHARE_FILE for cftypes, flag that allows cftypes to be linked together if they are part of the same subsystem and have the same name. There is a limitation for a cftype that wants to share a file: it can't have the hooks seq_start/next/stop. The reason is that there is no consistent way to show portions of a file once multiple cftypes are attached to it, and thus more than one seq_show() is invoked: there are neither an univocal start point, nor univocal "next" and "stop" operations. Signed-off-by: Angelo Ruocco Signed-off-by: Paolo Valente --- include/linux/cgroup-defs.h | 9 ++++++ kernel/cgroup/cgroup.c | 78 +++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 85 insertions(+), 2 deletions(-) diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h index 7841db6e7fb3..d659763c7221 100644 --- a/include/linux/cgroup-defs.h +++ b/include/linux/cgroup-defs.h @@ -93,6 +93,8 @@ enum { CFTYPE_NO_PREFIX = (1 << 3), /* (DON'T USE FOR NEW FILES) no subsys prefix */ CFTYPE_WORLD_WRITABLE = (1 << 4), /* (DON'T USE FOR NEW FILES) S_IWUGO */ + CFTYPE_SHARES_FILE = (1 << 5), /* shares file w/ other cfts */ + /* internal flags, do not use outside cgroup core proper */ __CFTYPE_ONLY_ON_DFL = (1 << 16), /* only on default hierarchy */ __CFTYPE_NOT_ON_DFL = (1 << 17), /* not on default hierarchy */ @@ -528,6 +530,13 @@ struct cftype { */ struct cgroup_subsys *ss; /* NULL for cgroup core files */ struct list_head node; /* anchored at ss->cfts */ + + /* + * List of cftypes that are sharing the same file. It allows the hook + * functions of the cftypes in the list to be called together. + */ + struct list_head share_node; + struct kernfs_ops *kf_ops; int (*open)(struct kernfs_open_file *of); diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c index 74012b61fe19..e3cc437669a8 100644 --- a/kernel/cgroup/cgroup.c +++ b/kernel/cgroup/cgroup.c @@ -1579,9 +1579,12 @@ struct cgroup *cgroup_kn_lock_live(struct kernfs_node *kn, bool drain_offline) return NULL; } -static void cgroup_rm_file(struct cgroup *cgrp, const struct cftype *cft) +static void cgroup_rm_file(struct cgroup *cgrp, struct cftype *cft) { char name[CGROUP_FILE_NAME_MAX]; + struct kernfs_node *kn = kernfs_find(cgrp->kn, + cgroup_file_name(cgrp, cft, name)); + struct cftype *cfts = kn->priv; lockdep_assert_held(&cgroup_mutex); @@ -1596,7 +1599,19 @@ static void cgroup_rm_file(struct cgroup *cgrp, const struct cftype *cft) del_timer_sync(&cfile->notify_timer); } - kernfs_remove_by_name(cgrp->kn, cgroup_file_name(cgrp, cft, name)); + /* Delete the file only if it's used by one cftype */ + if (list_empty(&cft->share_node) || atomic_read(&kn->count) == 1) { + kernfs_remove(kn); + } else { + /* + * Update the "priv" pointer of the kernfs_node if the cftype + * that first created the file is removed. + */ + if (cft == cfts) + kn->priv = list_next_entry(cft, share_node); + + kernfs_put(kn); + } } /** @@ -3467,6 +3482,7 @@ static int cgroup_file_open(struct kernfs_open_file *of) { struct cftype *cft = of->kn->priv; + if (cft->open) return cft->open(of); return 0; @@ -3615,6 +3631,23 @@ static int cgroup_add_file(struct cgroup_subsys_state *css, struct cgroup *cgrp, #ifdef CONFIG_DEBUG_LOCK_ALLOC key = &cft->lockdep_key; #endif + + if (cft->flags & CFTYPE_SHARES_FILE) { + kn = kernfs_find(cgrp->kn, cgroup_file_name(cgrp, cft, name)); + if (kn) { + struct cftype *cfts = kn->priv; + + if (cfts->flags & CFTYPE_SHARES_FILE) { + /* + * kn->count keeps track of how many cftypes + * share kn + */ + kernfs_get(kn); + goto out_set_cfile; + } + } + } + kn = __kernfs_create_file(cgrp->kn, cgroup_file_name(cgrp, cft, name), cgroup_file_mode(cft), GLOBAL_ROOT_UID, GLOBAL_ROOT_GID, @@ -3629,6 +3662,7 @@ static int cgroup_add_file(struct cgroup_subsys_state *css, struct cgroup *cgrp, return ret; } +out_set_cfile: if (cft->file_offset) { struct cgroup_file *cfile = (void *)css + cft->file_offset; @@ -3726,11 +3760,46 @@ static void cgroup_exit_cftypes(struct cftype *cfts) cft->kf_ops = NULL; cft->ss = NULL; + list_del(&cft->share_node); + /* revert flags set by cgroup core while adding @cfts */ cft->flags &= ~(__CFTYPE_ONLY_ON_DFL | __CFTYPE_NOT_ON_DFL); } } +/* + * Link a cftype that wants to share a file to the list of cftypes that are + * using it. + * + * The conditions for a cftype to be put in an existing list of cftypes and + * thus start to share a file are: + * - to have the flag CFTYPE_SHARES_FILE set; + * - to have all flags coincide with the flags of the other cftypes in the + * list; + * - to not have a seq_start hook: there is no consistent way to show + * portions of a file once multiple cftypes are attached to it, and thus + * more than one seq_show() is invoked. + * + * Once two or more cftypes are linked together, the file only points + * to the first of them. + */ +static void cgroup_link_cftype(struct cgroup_subsys *ss, struct cftype *cft) +{ + struct cftype *cfts; + + list_for_each_entry(cfts, &ss->cfts, node) { + struct cftype *c; + + for (c = cfts; c->name[0] != '\0'; c++) + if (c != cft && !(c->flags ^ cft->flags) && + !(c->seq_start || cft->seq_start) && + !strcmp(c->name, cft->name)) { + list_add(&cft->share_node, &c->share_node); + return; + } + } +} + static int cgroup_init_cftypes(struct cgroup_subsys *ss, struct cftype *cfts) { struct cftype *cft; @@ -3760,6 +3829,11 @@ static int cgroup_init_cftypes(struct cgroup_subsys *ss, struct cftype *cfts) cft->kf_ops = kf_ops; cft->ss = ss; + + INIT_LIST_HEAD(&cft->share_node); + + if (cft->flags & CFTYPE_SHARES_FILE) + cgroup_link_cftype(ss, cft); } return 0; -- 2.16.1