[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190102125619.32ee905d@canb.auug.org.au>
Date: Wed, 2 Jan 2019 12:56:19 +1100
From: Stephen Rothwell <sfr@...b.auug.org.au>
To: Al Viro <viro@...IV.linux.org.uk>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
David Howells <dhowells@...hat.com>,
Babu Moger <Babu.Moger@....com>, Borislav Petkov <bp@...e.de>
Subject: Re: linux-next: manual merge of the tip tree with the vfs tree
Hi all,
On Mon, 26 Nov 2018 15:39:25 +1100 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/x86/kernel/cpu/resctrl/rdtgroup.c
>
> between commit:
>
> 16ec1a5d58ea ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context")
> (where the file is arch/x86/kernel/cpu/intel_rdt_rdtgroup.c)
>
> from the vfs tree and commit:
>
> 580ebb66cbb3 ("x86/resctrl: Add vendor check for the MBA software controller")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index 37c0ccb50823,61b102dd51a5..000000000000
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@@ -2032,88 -2065,8 +2032,91 @@@ out
> rdt_last_cmd_clear();
> mutex_unlock(&rdtgroup_mutex);
> cpus_read_unlock();
> + return ret;
> +}
> +
> +enum rdt_param {
> + Opt_cdp,
> + Opt_cdpl2,
> + Opt_mba_mpbs,
> + nr__rdt_params
> +};
>
> - return dentry;
> +static const struct fs_parameter_spec rdt_param_specs[nr__rdt_params] = {
> + [Opt_cdp] = { fs_param_is_flag },
> + [Opt_cdpl2] = { fs_param_is_flag },
> + [Opt_mba_mpbs] = { fs_param_is_flag },
> +};
> +
> +static const char *const rdt_param_keys[nr__rdt_params] = {
> + [Opt_cdp] = "cdp",
> + [Opt_cdpl2] = "cdpl2",
> + [Opt_mba_mpbs] = "mba_mbps",
> +};
> +
> +static const struct fs_parameter_description rdt_fs_parameters = {
> + .name = "rdt",
> + .nr_params = nr__rdt_params,
> + .keys = rdt_param_keys,
> + .specs = rdt_param_specs,
> + .no_source = true,
> +};
> +
> +static int rdt_parse_param(struct fs_context *fc, struct fs_parameter *param)
> +{
> + struct rdt_fs_context *ctx = rdt_fc2context(fc);
> + struct fs_parse_result result;
> + int opt;
> +
> + opt = fs_parse(fc, &rdt_fs_parameters, param, &result);
> + if (opt < 0)
> + return opt;
> +
> + switch (opt) {
> + case Opt_cdp:
> + ctx->enable_cdpl3 = true;
> + return 0;
> + case Opt_cdpl2:
> + ctx->enable_cdpl2 = true;
> + return 0;
> + case Opt_mba_mpbs:
> - ctx->enable_mba_mbps = true;
> - return 0;
> ++ if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
> ++ ctx->enable_mba_mbps = true;
> ++ return 0;
> ++ }
> ++ break;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static void rdt_fs_context_free(struct fs_context *fc)
> +{
> + struct rdt_fs_context *ctx = rdt_fc2context(fc);
> +
> + kernfs_free_fs_context(fc);
> + kfree(ctx);
> +}
> +
> +static const struct fs_context_operations rdt_fs_context_ops = {
> + .free = rdt_fs_context_free,
> + .parse_param = rdt_parse_param,
> + .get_tree = rdt_get_tree,
> +};
> +
> +static int rdt_init_fs_context(struct fs_context *fc, struct dentry *reference)
> +{
> + struct rdt_fs_context *ctx;
> +
> + ctx = kzalloc(sizeof(struct rdt_fs_context), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> +
> + ctx->kfc.root = rdt_root;
> + ctx->kfc.magic = RDTGROUP_SUPER_MAGIC;
> + fc->fs_private = &ctx->kfc;
> + fc->ops = &rdt_fs_context_ops;
> + return 0;
> }
>
> static int reset_all_ctrls(struct rdt_resource *r)
This is now a conflict between Linus' tree and the vfs tree.
--
Cheers,
Stephen Rothwell
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists