linux-next: manual merge of the tip tree with the vfs tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/Kconfig
between commit:
139d7deeea00 ("[elfcore-compat][amd64] clean PRSTATUS_SIZE/SET_PR_FPVALID up
properly")
from the vfs tree and commit:
2ca408d9c749 ("fanotify: Fix sys_fanotify_mark() on native x86-32")
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/Kconfig
index a17ced73b23c,24862d15f3a3..
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@@ -1105,9 -1105,12 +1105,15 @@@ config HAVE_ARCH_PFN_VALI
config ARCH_SUPPORTS_DEBUG_PAGEALLOC
bool
+config ARCH_HAS_ELFCORE_COMPAT
+ bool
+
+ config ARCH_SPLIT_ARG64
+ bool
+ help
+ If a 32-bit architecture requires 64-bit arguments to be split into
+ pairs of 32-bit arguments, select this option.
+
source "kernel/gcov/Kconfig"
source "scripts/gcc-plugins/Kconfig"
pgpIr6jMiNEjf.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with the vfs tree
Hi all,
Today's linux-next merge of the tip tree got conflicts in:
arch/ia64/Kconfig
arch/s390/Kconfig
between commit:
5e6e9852d6f7 ("uaccess: add infrastructure for kernel builds with set_fs()")
from the vfs tree and commit:
077ee78e3928 ("PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable")
981aa1d366bf ("PCI: MSI: Fix Kconfig dependencies for PCI_MSI_ARCH_FALLBACKS")
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/ia64/Kconfig
index 3414e67229b3,9d0f1e13c918..
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@@ -55,7 -56,7 +55,8 @@@ config IA6
select NEED_DMA_MAP_STATE
select NEED_SG_DMA_LENGTH
select NUMA if !FLATMEM
+ select PCI_MSI_ARCH_FALLBACKS if PCI_MSI
+ select SET_FS
default y
help
The Itanium Processor Family is Intel's 64-bit successor to
diff --cc arch/s390/Kconfig
index dde501bc6304,0a3899386a51..
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@@ -190,7 -185,7 +190,8 @@@ config S39
select OLD_SIGSUSPEND3
select PCI_DOMAINS if PCI
select PCI_MSI if PCI
+ select PCI_MSI_ARCH_FALLBACKS if PCI_MSI
+ select SET_FS
select SPARSE_IRQ
select SYSCTL_EXCEPTION_TRACE
select THREAD_INFO_IN_TASK
pgp0xioT5DHNd.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with the vfs tree
Hi all,
Today's linux-next merge of the tip tree got conflicts in:
arch/ia64/Kconfig
arch/s390/Kconfig
between commit:
5e6e9852d6f7 ("uaccess: add infrastructure for kernel builds with set_fs()")
from the vfs tree and commit:
077ee78e3928 ("PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable")
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/ia64/Kconfig
index 3414e67229b3,7ff5b3bbf160..
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@@ -55,7 -56,7 +55,8 @@@ config IA6
select NEED_DMA_MAP_STATE
select NEED_SG_DMA_LENGTH
select NUMA if !FLATMEM
+ select PCI_MSI_ARCH_FALLBACKS
+ select SET_FS
default y
help
The Itanium Processor Family is Intel's 64-bit successor to
diff --cc arch/s390/Kconfig
index dde501bc6304,63dd5a0aa252..
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@@ -190,7 -185,7 +190,8 @@@ config S39
select OLD_SIGSUSPEND3
select PCI_DOMAINS if PCI
select PCI_MSI if PCI
+ select PCI_MSI_ARCH_FALLBACKS
+ select SET_FS
select SPARSE_IRQ
select SYSCTL_EXCEPTION_TRACE
select THREAD_INFO_IN_TASK
pgpXBdqE61P9f.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the tip tree with the vfs tree
Hi all,
On Mon, 27 Jul 2020 15:35:10 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/x86/include/asm/fpu/xstate.h
>
> between commit:
>
> c196049cc732 ("x86: switch to ->regset_get()")
>
> from the vfs tree and commit:
>
> ce711ea3cab9 ("perf/x86/intel/lbr: Support XSAVES/XRSTORS for LBR context
> switch")
>
> 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.
>
> diff --cc arch/x86/include/asm/fpu/xstate.h
> index f691ea1bc086,1559554af931..
> --- a/arch/x86/include/asm/fpu/xstate.h
> +++ b/arch/x86/include/asm/fpu/xstate.h
> @@@ -71,8 -103,9 +103,9 @@@ extern void __init update_regset_xstate
> void *get_xsave_addr(struct xregs_state *xsave, int xfeature_nr);
> const void *get_xsave_field_ptr(int xfeature_nr);
> int using_compacted_format(void);
> + int xfeature_size(int xfeature_nr);
> -int copy_xstate_to_kernel(void *kbuf, struct xregs_state *xsave, unsigned
> int offset, unsigned int size);
> -int copy_xstate_to_user(void __user *ubuf, struct xregs_state *xsave,
> unsigned int offset, unsigned int size);
> +struct membuf;
> +void copy_xstate_to_kernel(struct membuf to, struct xregs_state *xsave);
> int copy_kernel_to_xstate(struct xregs_state *xsave, const void *kbuf);
> int copy_user_to_xstate(struct xregs_state *xsave, const void __user *ubuf);
> void copy_supervisor_to_kernel(struct xregs_state *xsave);
This is now a conflict between the vfs tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpZ2t9cChZeY.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with the vfs tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/include/asm/fpu/xstate.h
between commit:
c196049cc732 ("x86: switch to ->regset_get()")
from the vfs tree and commit:
ce711ea3cab9 ("perf/x86/intel/lbr: Support XSAVES/XRSTORS for LBR context
switch")
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/include/asm/fpu/xstate.h
index f691ea1bc086,1559554af931..
--- a/arch/x86/include/asm/fpu/xstate.h
+++ b/arch/x86/include/asm/fpu/xstate.h
@@@ -71,8 -103,9 +103,9 @@@ extern void __init update_regset_xstate
void *get_xsave_addr(struct xregs_state *xsave, int xfeature_nr);
const void *get_xsave_field_ptr(int xfeature_nr);
int using_compacted_format(void);
+ int xfeature_size(int xfeature_nr);
-int copy_xstate_to_kernel(void *kbuf, struct xregs_state *xsave, unsigned int
offset, unsigned int size);
-int copy_xstate_to_user(void __user *ubuf, struct xregs_state *xsave,
unsigned int offset, unsigned int size);
+struct membuf;
+void copy_xstate_to_kernel(struct membuf to, struct xregs_state *xsave);
int copy_kernel_to_xstate(struct xregs_state *xsave, const void *kbuf);
int copy_user_to_xstate(struct xregs_state *xsave, const void __user *ubuf);
void copy_supervisor_to_kernel(struct xregs_state *xsave);
pgpd4jWSQlBvh.pgp
Description: OpenPGP digital signature
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
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..
> --- 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(_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, _fs_parameters, param, );
> +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 = >kfc;
> +fc->ops = _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
pgprZIlQs20FY.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with the vfs tree
Hi all,
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..
--- 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(_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, _fs_parameters, param, );
+ 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 = >kfc;
+ fc->ops = _fs_context_ops;
+ return 0;
}
static int reset_all_ctrls(struct rdt_resource *r)
pgpj3I5byCSbe.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with the vfs tree
Hi all,
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..
--- 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(_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, _fs_parameters, param, );
+ 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 = >kfc;
+ fc->ops = _fs_context_ops;
+ return 0;
}
static int reset_all_ctrls(struct rdt_resource *r)
pgpj3I5byCSbe.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the tip tree with the vfs tree
On Fri, 22 Jun 2018, Reinette Chatre wrote: > On 6/22/2018 6:39 AM, Thomas Gleixner wrote: > > On Fri, 22 Jun 2018, Al Viro wrote: > >> On Fri, Jun 22, 2018 at 01:45:23PM +0100, David Howells wrote: > >>> Reinette Chatre wrote: > >>> > Thomas and David, please let me know what I can do from my side to help > with this. > >>> > >>> You could try basing on Al Viro's for-next tree which has the mount API > >>> changes in it. > >> > >> Umm... That would be a massive headache for everyone involved; the changes > >> in there have very little in common with what you are doing in rdt_mount(), > >> so it might make sense to start with a minimal never-rebased branch that > >> would > >>* define rdt_pseudo_lock_init as 0 > >>* define rdt_pseudo_lock_release as empty > >>* do the rdt_mount() part of a3dbd01e6c9d > >>* have commit message along the lines of > >> "hooks in rdt_mount() for rdt_pseudo_lock to use > >> > >> Functionally a no-op right now; the only reason for having that > >> as a never-rebased branch to get rdt_pseudo_lock and mount series > >> out of each other's hair" > >> > >> Base that on -rc1, then pull it into your rdt branch and David could pull > >> the > >> same into his. > > > > Yes, that works. > > > > Reinette, can you please look into creating that ordering. Then we just zap > > the existing branch and redo it with this scheme. > > Will do. How would you prefer to consume this to make the branches > simple to create? Is it ok if I create a new patch series with Al's > suggestion above as the first commit? > > The original pseudo-locking patch series consisted out of two sections > with the pseudo-locking specific parts starting in the middle. If I > create a new series with the above change then it will not be cleanly > separate anymore. Is that ok? That's fine. Just mention it clearly in the changelog of that first one or two patches you need for that. Thanks, tglx
Re: linux-next: manual merge of the tip tree with the vfs tree
On Fri, 22 Jun 2018, Reinette Chatre wrote: > On 6/22/2018 6:39 AM, Thomas Gleixner wrote: > > On Fri, 22 Jun 2018, Al Viro wrote: > >> On Fri, Jun 22, 2018 at 01:45:23PM +0100, David Howells wrote: > >>> Reinette Chatre wrote: > >>> > Thomas and David, please let me know what I can do from my side to help > with this. > >>> > >>> You could try basing on Al Viro's for-next tree which has the mount API > >>> changes in it. > >> > >> Umm... That would be a massive headache for everyone involved; the changes > >> in there have very little in common with what you are doing in rdt_mount(), > >> so it might make sense to start with a minimal never-rebased branch that > >> would > >>* define rdt_pseudo_lock_init as 0 > >>* define rdt_pseudo_lock_release as empty > >>* do the rdt_mount() part of a3dbd01e6c9d > >>* have commit message along the lines of > >> "hooks in rdt_mount() for rdt_pseudo_lock to use > >> > >> Functionally a no-op right now; the only reason for having that > >> as a never-rebased branch to get rdt_pseudo_lock and mount series > >> out of each other's hair" > >> > >> Base that on -rc1, then pull it into your rdt branch and David could pull > >> the > >> same into his. > > > > Yes, that works. > > > > Reinette, can you please look into creating that ordering. Then we just zap > > the existing branch and redo it with this scheme. > > Will do. How would you prefer to consume this to make the branches > simple to create? Is it ok if I create a new patch series with Al's > suggestion above as the first commit? > > The original pseudo-locking patch series consisted out of two sections > with the pseudo-locking specific parts starting in the middle. If I > create a new series with the above change then it will not be cleanly > separate anymore. Is that ok? That's fine. Just mention it clearly in the changelog of that first one or two patches you need for that. Thanks, tglx
Re: linux-next: manual merge of the tip tree with the vfs tree
Hi Thomas, On 6/22/2018 6:39 AM, Thomas Gleixner wrote: > On Fri, 22 Jun 2018, Al Viro wrote: >> On Fri, Jun 22, 2018 at 01:45:23PM +0100, David Howells wrote: >>> Reinette Chatre wrote: >>> Thomas and David, please let me know what I can do from my side to help with this. >>> >>> You could try basing on Al Viro's for-next tree which has the mount API >>> changes in it. >> >> Umm... That would be a massive headache for everyone involved; the changes >> in there have very little in common with what you are doing in rdt_mount(), >> so it might make sense to start with a minimal never-rebased branch that >> would >> * define rdt_pseudo_lock_init as 0 >> * define rdt_pseudo_lock_release as empty >> * do the rdt_mount() part of a3dbd01e6c9d >> * have commit message along the lines of >> "hooks in rdt_mount() for rdt_pseudo_lock to use >> >> Functionally a no-op right now; the only reason for having that >> as a never-rebased branch to get rdt_pseudo_lock and mount series >> out of each other's hair" >> >> Base that on -rc1, then pull it into your rdt branch and David could pull the >> same into his. > > Yes, that works. > > Reinette, can you please look into creating that ordering. Then we just zap > the existing branch and redo it with this scheme. Will do. How would you prefer to consume this to make the branches simple to create? Is it ok if I create a new patch series with Al's suggestion above as the first commit? The original pseudo-locking patch series consisted out of two sections with the pseudo-locking specific parts starting in the middle. If I create a new series with the above change then it will not be cleanly separate anymore. Is that ok? Reinette
Re: linux-next: manual merge of the tip tree with the vfs tree
Hi Thomas, On 6/22/2018 6:39 AM, Thomas Gleixner wrote: > On Fri, 22 Jun 2018, Al Viro wrote: >> On Fri, Jun 22, 2018 at 01:45:23PM +0100, David Howells wrote: >>> Reinette Chatre wrote: >>> Thomas and David, please let me know what I can do from my side to help with this. >>> >>> You could try basing on Al Viro's for-next tree which has the mount API >>> changes in it. >> >> Umm... That would be a massive headache for everyone involved; the changes >> in there have very little in common with what you are doing in rdt_mount(), >> so it might make sense to start with a minimal never-rebased branch that >> would >> * define rdt_pseudo_lock_init as 0 >> * define rdt_pseudo_lock_release as empty >> * do the rdt_mount() part of a3dbd01e6c9d >> * have commit message along the lines of >> "hooks in rdt_mount() for rdt_pseudo_lock to use >> >> Functionally a no-op right now; the only reason for having that >> as a never-rebased branch to get rdt_pseudo_lock and mount series >> out of each other's hair" >> >> Base that on -rc1, then pull it into your rdt branch and David could pull the >> same into his. > > Yes, that works. > > Reinette, can you please look into creating that ordering. Then we just zap > the existing branch and redo it with this scheme. Will do. How would you prefer to consume this to make the branches simple to create? Is it ok if I create a new patch series with Al's suggestion above as the first commit? The original pseudo-locking patch series consisted out of two sections with the pseudo-locking specific parts starting in the middle. If I create a new series with the above change then it will not be cleanly separate anymore. Is that ok? Reinette
Re: linux-next: manual merge of the tip tree with the vfs tree
On Fri, 22 Jun 2018, Al Viro wrote: > On Fri, Jun 22, 2018 at 01:45:23PM +0100, David Howells wrote: > > Reinette Chatre wrote: > > > > > Thomas and David, please let me know what I can do from my side to help > > > with this. > > > > You could try basing on Al Viro's for-next tree which has the mount API > > changes in it. > > Umm... That would be a massive headache for everyone involved; the changes > in there have very little in common with what you are doing in rdt_mount(), > so it might make sense to start with a minimal never-rebased branch that > would > * define rdt_pseudo_lock_init as 0 > * define rdt_pseudo_lock_release as empty > * do the rdt_mount() part of a3dbd01e6c9d > * have commit message along the lines of > "hooks in rdt_mount() for rdt_pseudo_lock to use > > Functionally a no-op right now; the only reason for having that > as a never-rebased branch to get rdt_pseudo_lock and mount series > out of each other's hair" > > Base that on -rc1, then pull it into your rdt branch and David could pull the > same into his. Yes, that works. Reinette, can you please look into creating that ordering. Then we just zap the existing branch and redo it with this scheme. Thanks, tglx
Re: linux-next: manual merge of the tip tree with the vfs tree
On Fri, 22 Jun 2018, Al Viro wrote: > On Fri, Jun 22, 2018 at 01:45:23PM +0100, David Howells wrote: > > Reinette Chatre wrote: > > > > > Thomas and David, please let me know what I can do from my side to help > > > with this. > > > > You could try basing on Al Viro's for-next tree which has the mount API > > changes in it. > > Umm... That would be a massive headache for everyone involved; the changes > in there have very little in common with what you are doing in rdt_mount(), > so it might make sense to start with a minimal never-rebased branch that > would > * define rdt_pseudo_lock_init as 0 > * define rdt_pseudo_lock_release as empty > * do the rdt_mount() part of a3dbd01e6c9d > * have commit message along the lines of > "hooks in rdt_mount() for rdt_pseudo_lock to use > > Functionally a no-op right now; the only reason for having that > as a never-rebased branch to get rdt_pseudo_lock and mount series > out of each other's hair" > > Base that on -rc1, then pull it into your rdt branch and David could pull the > same into his. Yes, that works. Reinette, can you please look into creating that ordering. Then we just zap the existing branch and redo it with this scheme. Thanks, tglx
Re: linux-next: manual merge of the tip tree with the vfs tree
On Fri, Jun 22, 2018 at 01:45:23PM +0100, David Howells wrote: > Reinette Chatre wrote: > > > Thomas and David, please let me know what I can do from my side to help > > with this. > > You could try basing on Al Viro's for-next tree which has the mount API > changes in it. Umm... That would be a massive headache for everyone involved; the changes in there have very little in common with what you are doing in rdt_mount(), so it might make sense to start with a minimal never-rebased branch that would * define rdt_pseudo_lock_init as 0 * define rdt_pseudo_lock_release as empty * do the rdt_mount() part of a3dbd01e6c9d * have commit message along the lines of "hooks in rdt_mount() for rdt_pseudo_lock to use Functionally a no-op right now; the only reason for having that as a never-rebased branch to get rdt_pseudo_lock and mount series out of each other's hair" Base that on -rc1, then pull it into your rdt branch and David could pull the same into his.
Re: linux-next: manual merge of the tip tree with the vfs tree
On Fri, Jun 22, 2018 at 01:45:23PM +0100, David Howells wrote: > Reinette Chatre wrote: > > > Thomas and David, please let me know what I can do from my side to help > > with this. > > You could try basing on Al Viro's for-next tree which has the mount API > changes in it. Umm... That would be a massive headache for everyone involved; the changes in there have very little in common with what you are doing in rdt_mount(), so it might make sense to start with a minimal never-rebased branch that would * define rdt_pseudo_lock_init as 0 * define rdt_pseudo_lock_release as empty * do the rdt_mount() part of a3dbd01e6c9d * have commit message along the lines of "hooks in rdt_mount() for rdt_pseudo_lock to use Functionally a no-op right now; the only reason for having that as a never-rebased branch to get rdt_pseudo_lock and mount series out of each other's hair" Base that on -rc1, then pull it into your rdt branch and David could pull the same into his.
Re: linux-next: manual merge of the tip tree with the vfs tree
Reinette Chatre wrote: > Thomas and David, please let me know what I can do from my side to help > with this. You could try basing on Al Viro's for-next tree which has the mount API changes in it. Sorry, I was hoping that this would go in the last merge window, but I don't think Al has sufficient bandwidth available. Note that it's likely to get rebased shortly as I have some patches to apply, which given we're not at -rc2 yet, I'd like to roll into the original patches to for bisectability reasons. Also, Eric has some user_ns fixes that conflict with my procfs changes that he wants to get upstream, though Linus said no - so I'm not sure what's going to happen there. David
Re: linux-next: manual merge of the tip tree with the vfs tree
Reinette Chatre wrote: > Thomas and David, please let me know what I can do from my side to help > with this. You could try basing on Al Viro's for-next tree which has the mount API changes in it. Sorry, I was hoping that this would go in the last merge window, but I don't think Al has sufficient bandwidth available. Note that it's likely to get rebased shortly as I have some patches to apply, which given we're not at -rc2 yet, I'd like to roll into the original patches to for bisectability reasons. Also, Eric has some user_ns fixes that conflict with my procfs changes that he wants to get upstream, though Linus said no - so I'm not sure what's going to happen there. David
Re: linux-next: manual merge of the tip tree with the vfs tree
On Thu, 21 Jun 2018, Reinette Chatre wrote:
> I am the contributor of the pseudo-locking related code that caused the
> conflict.
>
> Stephen, thank you very much for proceeding with the merge and fixing it
> up. I copied your later fix addition to this email and combined they
> look good. I did some basic smoke testing of the merged code and it works.
>
> Thomas and David, please let me know what I can do from my side to help
> with this.
I'll have a look later today.
>
> As summary, with the above changes combined the merge can be done using:
>
> ->8-
> diff --cc arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> index 7b4a09d81a30,38a54f56ff40..caa2754f8948
> --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> @@@ -1861,16 -1270,9 +1842,13 @@@ static int rdt_get_tree(struct fs_conte
> rdtgroup_default.mon.mon_data_kn = kn_mondata;
> }
>
> +ret = rdt_pseudo_lock_init();
> - if (ret) {
> - dentry = ERR_PTR(ret);
> ++if (ret)
> +goto out_mondata;
> - }
> +
> - dentry = kernfs_mount(fs_type, flags, rdt_root,
> - RDTGROUP_SUPER_MAGIC, NULL);
> - if (IS_ERR(dentry))
> + ret = kernfs_get_tree(fc);
> + if (ret < 0)
> -goto out_mondata;
> +goto out_psl;
>
> if (rdt_alloc_capable)
> static_branch_enable_cpuslocked(_alloc_enable_key);
>
> Reinette
>
>
Re: linux-next: manual merge of the tip tree with the vfs tree
On Thu, 21 Jun 2018, Reinette Chatre wrote:
> I am the contributor of the pseudo-locking related code that caused the
> conflict.
>
> Stephen, thank you very much for proceeding with the merge and fixing it
> up. I copied your later fix addition to this email and combined they
> look good. I did some basic smoke testing of the merged code and it works.
>
> Thomas and David, please let me know what I can do from my side to help
> with this.
I'll have a look later today.
>
> As summary, with the above changes combined the merge can be done using:
>
> ->8-
> diff --cc arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> index 7b4a09d81a30,38a54f56ff40..caa2754f8948
> --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> @@@ -1861,16 -1270,9 +1842,13 @@@ static int rdt_get_tree(struct fs_conte
> rdtgroup_default.mon.mon_data_kn = kn_mondata;
> }
>
> +ret = rdt_pseudo_lock_init();
> - if (ret) {
> - dentry = ERR_PTR(ret);
> ++if (ret)
> +goto out_mondata;
> - }
> +
> - dentry = kernfs_mount(fs_type, flags, rdt_root,
> - RDTGROUP_SUPER_MAGIC, NULL);
> - if (IS_ERR(dentry))
> + ret = kernfs_get_tree(fc);
> + if (ret < 0)
> -goto out_mondata;
> +goto out_psl;
>
> if (rdt_alloc_capable)
> static_branch_enable_cpuslocked(_alloc_enable_key);
>
> Reinette
>
>
Re: linux-next: manual merge of the tip tree with the vfs tree
All,
On 6/21/2018 6:53 PM, Stephen Rothwell wrote:
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
>
> between commit:
>
> 58e4e43911f8 ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context")
>
> from the vfs tree and commit:
>
> a3dbd01e6c9d ("x86/intel_rdt: Create character device exposing pseudo-loc=
> ked region")
>
> from the tip tree.
>
> I fixed it up (I think - 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/intel_rdt_rdtgroup.c
> index 38a54f56ff40,7b4a09d81a30..
> --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> @@@ -1270,9 -1861,16 +1842,15 @@@ static int rdt_get_tree(struct fs_conte
> rdtgroup_default.mon.mon_data_kn = kn_mondata;
> }
>
> + ret = rdt_pseudo_lock_init();
> + if (ret) {
> + dentry = ERR_PTR(ret);
> + goto out_mondata;
> + }
> +
> -dentry = kernfs_mount(fs_type, flags, rdt_root,
> - RDTGROUP_SUPER_MAGIC, NULL);
> -if (IS_ERR(dentry))
> +ret = kernfs_get_tree(fc);
> +if (ret < 0)
> - goto out_mondata;
> + goto out_psl;
>
> if (rdt_alloc_capable)
> static_branch_enable_cpuslocked(_alloc_enable_key);
>> +ret = rdt_pseudo_lock_init();
>> +if (ret) {
>> +dentry = ERR_PTR(ret);
>
> Actually I have removed the above line as well.
I am the contributor of the pseudo-locking related code that caused the
conflict.
Stephen, thank you very much for proceeding with the merge and fixing it
up. I copied your later fix addition to this email and combined they
look good. I did some basic smoke testing of the merged code and it works.
Thomas and David, please let me know what I can do from my side to help
with this.
As summary, with the above changes combined the merge can be done using:
->8-
diff --cc arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index 7b4a09d81a30,38a54f56ff40..caa2754f8948
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@@ -1861,16 -1270,9 +1842,13 @@@ static int rdt_get_tree(struct fs_conte
rdtgroup_default.mon.mon_data_kn = kn_mondata;
}
+ ret = rdt_pseudo_lock_init();
- if (ret) {
- dentry = ERR_PTR(ret);
++ if (ret)
+ goto out_mondata;
- }
+
- dentry = kernfs_mount(fs_type, flags, rdt_root,
- RDTGROUP_SUPER_MAGIC, NULL);
- if (IS_ERR(dentry))
+ ret = kernfs_get_tree(fc);
+ if (ret < 0)
- goto out_mondata;
+ goto out_psl;
if (rdt_alloc_capable)
static_branch_enable_cpuslocked(_alloc_enable_key);
Reinette
Re: linux-next: manual merge of the tip tree with the vfs tree
All,
On 6/21/2018 6:53 PM, Stephen Rothwell wrote:
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
>
> between commit:
>
> 58e4e43911f8 ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context")
>
> from the vfs tree and commit:
>
> a3dbd01e6c9d ("x86/intel_rdt: Create character device exposing pseudo-loc=
> ked region")
>
> from the tip tree.
>
> I fixed it up (I think - 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/intel_rdt_rdtgroup.c
> index 38a54f56ff40,7b4a09d81a30..
> --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> @@@ -1270,9 -1861,16 +1842,15 @@@ static int rdt_get_tree(struct fs_conte
> rdtgroup_default.mon.mon_data_kn = kn_mondata;
> }
>
> + ret = rdt_pseudo_lock_init();
> + if (ret) {
> + dentry = ERR_PTR(ret);
> + goto out_mondata;
> + }
> +
> -dentry = kernfs_mount(fs_type, flags, rdt_root,
> - RDTGROUP_SUPER_MAGIC, NULL);
> -if (IS_ERR(dentry))
> +ret = kernfs_get_tree(fc);
> +if (ret < 0)
> - goto out_mondata;
> + goto out_psl;
>
> if (rdt_alloc_capable)
> static_branch_enable_cpuslocked(_alloc_enable_key);
>> +ret = rdt_pseudo_lock_init();
>> +if (ret) {
>> +dentry = ERR_PTR(ret);
>
> Actually I have removed the above line as well.
I am the contributor of the pseudo-locking related code that caused the
conflict.
Stephen, thank you very much for proceeding with the merge and fixing it
up. I copied your later fix addition to this email and combined they
look good. I did some basic smoke testing of the merged code and it works.
Thomas and David, please let me know what I can do from my side to help
with this.
As summary, with the above changes combined the merge can be done using:
->8-
diff --cc arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index 7b4a09d81a30,38a54f56ff40..caa2754f8948
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@@ -1861,16 -1270,9 +1842,13 @@@ static int rdt_get_tree(struct fs_conte
rdtgroup_default.mon.mon_data_kn = kn_mondata;
}
+ ret = rdt_pseudo_lock_init();
- if (ret) {
- dentry = ERR_PTR(ret);
++ if (ret)
+ goto out_mondata;
- }
+
- dentry = kernfs_mount(fs_type, flags, rdt_root,
- RDTGROUP_SUPER_MAGIC, NULL);
- if (IS_ERR(dentry))
+ ret = kernfs_get_tree(fc);
+ if (ret < 0)
- goto out_mondata;
+ goto out_psl;
if (rdt_alloc_capable)
static_branch_enable_cpuslocked(_alloc_enable_key);
Reinette
Re: linux-next: manual merge of the tip tree with the vfs tree
Hi all,
On Fri, 22 Jun 2018 11:53:46 +1000 Stephen Rothwell
wrote:
>
> diff --cc arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> index 38a54f56ff40,7b4a09d81a30..
> --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> @@@ -1270,9 -1861,16 +1842,15 @@@ static int rdt_get_tree(struct fs_conte
> rdtgroup_default.mon.mon_data_kn = kn_mondata;
> }
>
> + ret = rdt_pseudo_lock_init();
> + if (ret) {
> + dentry = ERR_PTR(ret);
Actually I have removed the above line as well.
--
Cheers,
Stephen Rothwell
pgpRA4EYfMofn.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the tip tree with the vfs tree
Hi all,
On Fri, 22 Jun 2018 11:53:46 +1000 Stephen Rothwell
wrote:
>
> diff --cc arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> index 38a54f56ff40,7b4a09d81a30..
> --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> @@@ -1270,9 -1861,16 +1842,15 @@@ static int rdt_get_tree(struct fs_conte
> rdtgroup_default.mon.mon_data_kn = kn_mondata;
> }
>
> + ret = rdt_pseudo_lock_init();
> + if (ret) {
> + dentry = ERR_PTR(ret);
Actually I have removed the above line as well.
--
Cheers,
Stephen Rothwell
pgpRA4EYfMofn.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with the vfs tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
between commit:
58e4e43911f8 ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context")
from the vfs tree and commit:
a3dbd01e6c9d ("x86/intel_rdt: Create character device exposing pseudo-locked
region")
from the tip tree.
I fixed it up (I think - 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/intel_rdt_rdtgroup.c
index 38a54f56ff40,7b4a09d81a30..
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@@ -1270,9 -1861,16 +1842,15 @@@ static int rdt_get_tree(struct fs_conte
rdtgroup_default.mon.mon_data_kn = kn_mondata;
}
+ ret = rdt_pseudo_lock_init();
+ if (ret) {
+ dentry = ERR_PTR(ret);
+ goto out_mondata;
+ }
+
- dentry = kernfs_mount(fs_type, flags, rdt_root,
-RDTGROUP_SUPER_MAGIC, NULL);
- if (IS_ERR(dentry))
+ ret = kernfs_get_tree(fc);
+ if (ret < 0)
- goto out_mondata;
+ goto out_psl;
if (rdt_alloc_capable)
static_branch_enable_cpuslocked(_alloc_enable_key);
pgpayUC8GD3l_.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with the vfs tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
between commit:
58e4e43911f8 ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context")
from the vfs tree and commit:
a3dbd01e6c9d ("x86/intel_rdt: Create character device exposing pseudo-locked
region")
from the tip tree.
I fixed it up (I think - 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/intel_rdt_rdtgroup.c
index 38a54f56ff40,7b4a09d81a30..
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@@ -1270,9 -1861,16 +1842,15 @@@ static int rdt_get_tree(struct fs_conte
rdtgroup_default.mon.mon_data_kn = kn_mondata;
}
+ ret = rdt_pseudo_lock_init();
+ if (ret) {
+ dentry = ERR_PTR(ret);
+ goto out_mondata;
+ }
+
- dentry = kernfs_mount(fs_type, flags, rdt_root,
-RDTGROUP_SUPER_MAGIC, NULL);
- if (IS_ERR(dentry))
+ ret = kernfs_get_tree(fc);
+ if (ret < 0)
- goto out_mondata;
+ goto out_psl;
if (rdt_alloc_capable)
static_branch_enable_cpuslocked(_alloc_enable_key);
pgpayUC8GD3l_.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with the vfs tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/mm/fault.c
between commit:
df720ac12fc7 ("exceptions: detritus removal")
from the vfs tree and commit:
744c193eb9a2 ("x86: Migrate exception table users off module.h and onto
extable.h")
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/mm/fault.c
index c0413d5541af,4dc13340653e..
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@@ -5,7 -5,7 +5,7 @@@
*/
#include /* test_thread_flag(), ... */
#include /* oops_begin/end, ... */
- #include /* search_exception_tables */
-#include /* search_exception_table */
++#include /* search_exception_tables */
#include /* max_low_pfn */
#include /* NOKPROBE_SYMBOL, ... */
#include /* kmmio_handler, ... */
linux-next: manual merge of the tip tree with the vfs tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/mm/fault.c
between commit:
df720ac12fc7 ("exceptions: detritus removal")
from the vfs tree and commit:
744c193eb9a2 ("x86: Migrate exception table users off module.h and onto
extable.h")
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/mm/fault.c
index c0413d5541af,4dc13340653e..
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@@ -5,7 -5,7 +5,7 @@@
*/
#include /* test_thread_flag(), ... */
#include /* oops_begin/end, ... */
- #include /* search_exception_tables */
-#include /* search_exception_table */
++#include /* search_exception_tables */
#include /* max_low_pfn */
#include /* NOKPROBE_SYMBOL, ... */
#include /* kmmio_handler, ... */
