Re: linux-next: manual merge of the tip tree with Linus' tree
On Fri, 6 Nov 2020 13:39:02 +1100 Stephen Rothwell wrote: > I fixed it up (the latter removed the code updated by the former, so I > just used the latter) 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. Thanks Stephen, Yeah, updates caused errors that needed to be fixed, which we knew were just a work around till the next merge window. Which is why that commit had in the comments: "Nested is a workaround that will soon not be needed." ;-) -- Steve
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
kernel/kprobes.c
between commit:
645f224e7ba2 ("kprobes: Tell lockdep about kprobe nesting")
from Linus' tree and commits:
d741bf41d7c7 ("kprobes: Remove kretprobe hash")
6e426e0fcd20 ("kprobes: Replace rp->free_instance with freelist")
from the tip tree.
I fixed it up (the latter removed the code updated by the former, so I
just used the latter) 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
pgpmmhRLgz_ZK.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
kernel/time/timekeeping.c
between commit:
025e82bcbc34 ("timekeeping: Use sequence counter with associated raw
spinlock")
from Linus' tree and commit:
19d0070a2792 ("timekeeping/vsyscall: Provide vdso_update_begin/end()")
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 kernel/time/timekeeping.c
index 406306b33452,4c7212f3c603..
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@@ -39,8 -39,6 +39,8 @@@ enum timekeeping_adv_mode
TK_ADV_FREQ
};
- static DEFINE_RAW_SPINLOCK(timekeeper_lock);
++DEFINE_RAW_SPINLOCK(timekeeper_lock);
+
/*
* The most important data for readout fits into a single 64 byte
* cache line.
pgp5ITxPcZF6m.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the tip tree with Linus' tree
Hi Thomas, On Thu, 11 Jun 2020 12:43:24 +0200 Thomas Gleixner wrote: > > Sorry for that inconveniance. I'm about to get rid of the conflicts on > the tip side. Thanks. I do realise that it can take a little while between when Linus adds something to his tree and previous versions get purged. It doesn't happen to much, thankfully. -- Cheers, Stephen Rothwell pgpVjhxoaP_Vh.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the tip tree with Linus' tree
Stephen Rothwell writes:
> Today's linux-next merge of the tip tree got conflicts in:
>
> include/linux/compiler.h
>
> between commits:
>
> dee081bf8f82 ("READ_ONCE: Drop pointer qualifiers when reading from scalar
> types")
> 9e343b467c70 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory
> accesses")
> a5460b5e5fb8 ("READ_ONCE: Simplify implementations of {READ,WRITE}_ONCE()")
>
> from Linus' tree and commits:
>
> 2ab3a0a02905 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory
> accesses")
> 7b364f0949ae ("READ_ONCE: Drop pointer qualifiers when reading from scalar
> types")
> bbfa112b46bd ("READ_ONCE: Simplify implementations of {READ,WRITE}_ONCE()")
> (and maybe others)
>
> from the tip tree.
Sorry for that inconveniance. I'm about to get rid of the conflicts on
the tip side.
Thanks,
tglx
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
include/linux/compiler_types.h
between commits:
a5dead405f6b ("compiler_types.h: Optimize __unqual_scalar_typeof compilation
time")
from Linus' tree and commits:
1fd76043ecb0 ("compiler_types.h: Optimize __unqual_scalar_typeof compilation
time")
from the tip tree.
I fixed it up (I just used the version from Linus' tree) 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
pgpktSqjCLo9f.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got conflicts in:
include/linux/compiler.h
between commits:
dee081bf8f82 ("READ_ONCE: Drop pointer qualifiers when reading from scalar
types")
9e343b467c70 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory
accesses")
a5460b5e5fb8 ("READ_ONCE: Simplify implementations of {READ,WRITE}_ONCE()")
from Linus' tree and commits:
2ab3a0a02905 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory
accesses")
7b364f0949ae ("READ_ONCE: Drop pointer qualifiers when reading from scalar
types")
bbfa112b46bd ("READ_ONCE: Simplify implementations of {READ,WRITE}_ONCE()")
(and maybe others)
from the tip tree.
I fixed it up (I think - please check the final result when I release it)
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
pgpwfGNqlsdKb.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/sparc/include/asm/pgtable_32.h
because commits
3408974d0533 ("sparc32: mm: Restructure sparc32 MMU page-table layout")
c95be5b549d6 ("sparc32: mm: Change pgtable_t type to pte_t * instead of
struct page *")
from the tip tree also exist in Linus' tree as different commits followed
by other changes.
I fixed it up (I just used Linus' version) 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
pgpmeuLAPMjXo.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
Documentation/admin-guide/hw-vuln/index.rst
between commit:
7222a1b5b874 ("x86/speculation: Add SRBDS vulnerability and mitigation
documentation")
from Linus' tree and commit:
0fcfdf55db9e ("Documentation: Add L1D flushing Documentation")
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 Documentation/admin-guide/hw-vuln/index.rst
index ca4dbdd9016d,35633b299d45..
--- a/Documentation/admin-guide/hw-vuln/index.rst
+++ b/Documentation/admin-guide/hw-vuln/index.rst
@@@ -14,4 -14,4 +14,5 @@@ are configurable at compile, boot or ru
mds
tsx_async_abort
multihit.rst
+ special-register-buffer-data-sampling.rst
+l1d_flush
pgpaPv4NL0i1V.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the tip tree with Linus' tree
On Mon, May 18, 2020 at 03:10:32PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> include/linux/compiler.h
>
> between commit:
>
> a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")
>
> from Linus' tree and commit:
>
> f670269a42bf ("x86: Fix early boot crash on gcc-10, next try")
>
> from the tip tree.
That commit is gone in the meantime so you won't have the merge conflict
anymore once tip/master is regenerated.
Thx.
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG
Nürnberg
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
include/linux/compiler.h
between commit:
a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")
from Linus' tree and commit:
f670269a42bf ("x86: Fix early boot crash on gcc-10, next try")
from the tip tree.
I fixed it up (I just used Linus' tree version) 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
pgp5lDpmcG89O.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the tip tree with Linus' tree
* Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> tools/power/x86/turbostat/turbostat.c
>
> between commit:
>
> cd188af5282d ("tools/power turbostat: Fix Haswell Core systems")
> b62b3184576b ("tools/power turbostat: add Jacobsville support")
> d93ea567fc4e ("tools/power turbostat: Add Ice Lake NNPI support")
>
> from Linus' tree and commit:
>
> c66f78a6de4d ("x86/intel: Aggregate big core client naming")
> af239c44e3f9 ("x86/intel: Aggregate big core mobile naming")
> 5e741407eab7 ("x86/intel: Aggregate big core graphics naming")
> 5ebb34edbefa ("x86/intel: Aggregate microserver naming")
>
> 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.
Thanks Stephen - I resolved this in -tip too, this conflict should not
trigger anymore in tomorrow's -next integration.
Thanks,
Ingo
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
tools/power/x86/turbostat/turbostat.c
between commit:
cd188af5282d ("tools/power turbostat: Fix Haswell Core systems")
b62b3184576b ("tools/power turbostat: add Jacobsville support")
d93ea567fc4e ("tools/power turbostat: Add Ice Lake NNPI support")
from Linus' tree and commit:
c66f78a6de4d ("x86/intel: Aggregate big core client naming")
af239c44e3f9 ("x86/intel: Aggregate big core mobile naming")
5e741407eab7 ("x86/intel: Aggregate big core graphics naming")
5ebb34edbefa ("x86/intel: Aggregate microserver naming")
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 tools/power/x86/turbostat/turbostat.c
index b2a86438f074,6eef0cee6d75..
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@@ -3234,15 -3207,14 +3234,15 @@@ int probe_nhm_msrs(unsigned int family
pkg_cstate_limits = snb_pkg_cstate_limits;
has_misc_feature_control = 1;
break;
- case INTEL_FAM6_HASWELL_CORE: /* HSW */
+ case INTEL_FAM6_HASWELL:/* HSW */
case INTEL_FAM6_HASWELL_X: /* HSX */
- case INTEL_FAM6_HASWELL_ULT:/* HSW */
- case INTEL_FAM6_HASWELL_GT3E: /* HSW */
- case INTEL_FAM6_BROADWELL_CORE: /* BDW */
- case INTEL_FAM6_BROADWELL_GT3E: /* BDW */
++ case INTEL_FAM6_HASWELL_L: /* HSW */
+ case INTEL_FAM6_HASWELL_G: /* HSW */
+ case INTEL_FAM6_BROADWELL: /* BDW */
+ case INTEL_FAM6_BROADWELL_G:/* BDW */
case INTEL_FAM6_BROADWELL_X:/* BDX */
- case INTEL_FAM6_SKYLAKE_MOBILE: /* SKL */
- case INTEL_FAM6_CANNONLAKE_MOBILE: /* CNL */
+ case INTEL_FAM6_SKYLAKE_L: /* SKL */
+ case INTEL_FAM6_CANNONLAKE_L: /* CNL */
pkg_cstate_limits = hsw_pkg_cstate_limits;
has_misc_feature_control = 1;
break;
@@@ -3431,15 -3403,14 +3431,15 @@@ int has_config_tdp(unsigned int family
switch (model) {
case INTEL_FAM6_IVYBRIDGE: /* IVB */
- case INTEL_FAM6_HASWELL_CORE: /* HSW */
+ case INTEL_FAM6_HASWELL:/* HSW */
case INTEL_FAM6_HASWELL_X: /* HSX */
- case INTEL_FAM6_HASWELL_ULT:/* HSW */
- case INTEL_FAM6_HASWELL_GT3E: /* HSW */
- case INTEL_FAM6_BROADWELL_CORE: /* BDW */
- case INTEL_FAM6_BROADWELL_GT3E: /* BDW */
++ case INTEL_FAM6_HASWELL_L: /* HSW */
+ case INTEL_FAM6_HASWELL_G: /* HSW */
+ case INTEL_FAM6_BROADWELL: /* BDW */
+ case INTEL_FAM6_BROADWELL_G:/* BDW */
case INTEL_FAM6_BROADWELL_X:/* BDX */
- case INTEL_FAM6_SKYLAKE_MOBILE: /* SKL */
- case INTEL_FAM6_CANNONLAKE_MOBILE: /* CNL */
+ case INTEL_FAM6_SKYLAKE_L: /* SKL */
+ case INTEL_FAM6_CANNONLAKE_L: /* CNL */
case INTEL_FAM6_SKYLAKE_X: /* SKX */
case INTEL_FAM6_XEON_PHI_KNL: /* Knights Landing */
@@@ -3870,11 -3840,10 +3870,11 @@@ void rapl_probe_intel(unsigned int fami
switch (model) {
case INTEL_FAM6_SANDYBRIDGE:
case INTEL_FAM6_IVYBRIDGE:
- case INTEL_FAM6_HASWELL_CORE: /* HSW */
- case INTEL_FAM6_HASWELL_ULT:/* HSW */
- case INTEL_FAM6_HASWELL_GT3E: /* HSW */
- case INTEL_FAM6_BROADWELL_CORE: /* BDW */
- case INTEL_FAM6_BROADWELL_GT3E: /* BDW */
+ case INTEL_FAM6_HASWELL:/* HSW */
++ case INTEL_FAM6_HASWELL_L: /* HSW */
+ case INTEL_FAM6_HASWELL_G: /* HSW */
+ case INTEL_FAM6_BROADWELL: /* BDW */
+ case INTEL_FAM6_BROADWELL_G:/* BDW */
do_rapl = RAPL_PKG | RAPL_CORES | RAPL_CORE_POLICY | RAPL_GFX |
RAPL_PKG_POWER_INFO;
if (rapl_joules) {
BIC_PRESENT(BIC_Pkg_J);
@@@ -4063,9 -4031,8 +4063,9 @@@ void perf_limit_reasons_probe(unsigned
return;
switch (model) {
- case INTEL_FAM6_HASWELL_CORE: /* HSW */
- case INTEL_FAM6_HASWELL_ULT:/* HSW */
- case INTEL_FAM6_HASWELL_GT3E: /* HSW */
+ case INTEL_FAM6_HASWELL:/* HSW */
++ case INTEL_FAM6_HASWELL_L: /* HSW */
+ case INTEL_FAM6_HASWELL_G: /* HSW */
do_gfx_perf_limit_reasons = 1;
case INTEL_FAM6_HASWELL_X: /* HSX */
do_core_perf_limit_reasons = 1;
@@@ -4282,15 -4249,14 +4282,15 @@@ int has_snb_msrs(unsigned int family, u
case INTEL_FAM6_SANDYBRIDGE_X:
case INTEL_FAM6_IVYBRIDGE
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/include/uapi/asm/types.h
between commit:
d9c525229521 ("treewide: add "WITH Linux-syscall-note" to SPDX tag of uapi
headers")
from Linus' tree and commit:
701010532164 ("x86/build: Remove unneeded uapi asm-generic wrappers")
from the tip tree.
I fixed it up (I removed the file) 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
pgpPtrDwdWOoG.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/um/Kconfig
between commit:
eac616557050 ("x86: Deprecate a.out support")
from Linus' tree and commit:
942fa985e9f1 ("32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config
option")
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/um/Kconfig
index 494eeb51e4e1,ab14e6f73ca4..a9e80e44178c
--- a/arch/x86/um/Kconfig
+++ b/arch/x86/um/Kconfig
@@@ -16,6 -16,8 +16,7 @@@ config 64BI
config X86_32
def_bool !64BIT
- select HAVE_AOUT
+ select ARCH_32BIT_OFF_T
select ARCH_WANT_IPC_PARSE_VERSION
select MODULES_USE_ELF_REL
select CLONE_BACKWARDS
pgpmYHszayOPS.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the tip tree with Linus' tree
On Fri, Oct 12, 2018 at 3:47 AM, Ingo Molnar wrote:
>
> * Kees Cook wrote:
>
>> On Thu, Oct 11, 2018 at 7:14 PM, Stephen Rothwell
>> wrote:
>> > Hi all,
>> >
>> > Today's linux-next merge of the tip tree got a conflict in:
>> >
>> > arch/x86/mm/pgtable.c
>> >
>> > between commit:
>> >
>> > 184d47f0fd36 ("x86/mm: Avoid VLA in pgd_alloc()")
>> >
>> > from Linus' tree and commit:
>> >
>> > 1be3f247c288 ("x86/mm: Avoid VLA in pgd_alloc()")
>> >
>> > from the tip tree.
>> >
>> > I fixed it up (I used the version from Linus' tree) 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.
>
> This is the correct resolution, thanks Stephen!
>
>> Ingo, it looks like that commit needs to be split up again ... Linus's
>> tree still needs the fix for the fix?
>
> -next still had the old commit, I've now refreshed tip:auto-latest so the
> conflict should go away in the next iteration.
>
> Linus's tree has the correct fix.
Ah! Gotcha, okay. I had it backwards. Thanks for checking!
-Kees
--
Kees Cook
Pixel Security
Re: linux-next: manual merge of the tip tree with Linus' tree
* Kees Cook wrote:
> On Thu, Oct 11, 2018 at 7:14 PM, Stephen Rothwell
> wrote:
> > Hi all,
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > arch/x86/mm/pgtable.c
> >
> > between commit:
> >
> > 184d47f0fd36 ("x86/mm: Avoid VLA in pgd_alloc()")
> >
> > from Linus' tree and commit:
> >
> > 1be3f247c288 ("x86/mm: Avoid VLA in pgd_alloc()")
> >
> > from the tip tree.
> >
> > I fixed it up (I used the version from Linus' tree) 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.
This is the correct resolution, thanks Stephen!
> Ingo, it looks like that commit needs to be split up again ... Linus's
> tree still needs the fix for the fix?
-next still had the old commit, I've now refreshed tip:auto-latest so the
conflict should go away in the next iteration.
Linus's tree has the correct fix.
Thanks,
Ingo
Re: linux-next: manual merge of the tip tree with Linus' tree
On Thu, Oct 11, 2018 at 7:14 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/x86/mm/pgtable.c
>
> between commit:
>
> 184d47f0fd36 ("x86/mm: Avoid VLA in pgd_alloc()")
>
> from Linus' tree and commit:
>
> 1be3f247c288 ("x86/mm: Avoid VLA in pgd_alloc()")
>
> from the tip tree.
>
> I fixed it up (I used the version from Linus' tree) 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.
Ingo, it looks like that commit needs to be split up again ... Linus's
tree still needs the fix for the fix?
-Kees
>
> --
> Cheers,
> Stephen Rothwell
--
Kees Cook
Pixel Security
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/mm/pgtable.c
between commit:
184d47f0fd36 ("x86/mm: Avoid VLA in pgd_alloc()")
from Linus' tree and commit:
1be3f247c288 ("x86/mm: Avoid VLA in pgd_alloc()")
from the tip tree.
I fixed it up (I used the version from Linus' tree) 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
pgpnIVlotlWGn.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
tools/testing/selftests/Makefile
between commit:
a12ab9e125f1 ("selftests: move RTC tests to rtc subfolder")
from Linus' tree and commit:
ccba8b64452b ("rseq/selftests: Provide Makefile, scripts, gitignore")
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 tools/testing/selftests/Makefile
index 4cd339b5366a,593fb44c9cd4..
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@@ -29,7 -28,7 +29,8 @@@ TARGETS += powerp
TARGETS += proc
TARGETS += pstore
TARGETS += ptrace
+ TARGETS += rseq
+TARGETS += rtc
TARGETS += seccomp
TARGETS += sigaltstack
TARGETS += size
pgp1EdnUyas_k.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the tip tree with Linus' tree
* Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/x86/kvm/vmx.c
>
> between commit:
>
> c992384bde84 ("KVM: vmx: speed up MSR bitmap merge")
>
> from Linus' tree and commit:
>
> ff37dc0cd96c ("KVM/nVMX: Set the CPU_BASED_USE_MSR_BITMAPS if we have a
> valid L02 MSR bitmap")
>
> 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/kvm/vmx.c
> index f427723dc7db,91e3539cba02..
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@@ -10136,7 -10127,12 +10136,10 @@@ static void nested_get_vmcs12_pages(str
> (unsigned long)(vmcs12->posted_intr_desc_addr &
> (PAGE_SIZE - 1)));
> }
> - if (!nested_vmx_prepare_msr_bitmap(vcpu, vmcs12))
> -if (cpu_has_vmx_msr_bitmap() &&
> -nested_cpu_has(vmcs12, CPU_BASED_USE_MSR_BITMAPS) &&
> -nested_vmx_merge_msr_bitmap(vcpu, vmcs12))
> ++if (nested_vmx_prepare_msr_bitmap(vcpu, vmcs12))
> + vmcs_set_bits(CPU_BASED_VM_EXEC_CONTROL,
> + CPU_BASED_USE_MSR_BITMAPS);
> + else
> vmcs_clear_bits(CPU_BASED_VM_EXEC_CONTROL,
> CPU_BASED_USE_MSR_BITMAPS);
> }
>
> @@@ -10224,14 -10220,9 +10227,14 @@@ static inline bool nested_vmx_prepare_m
>*updated to reflect this when L1 (or its L2s) actually write to
>*the MSR.
>*/
> - bool pred_cmd = msr_write_intercepted_l01(vcpu, MSR_IA32_PRED_CMD);
> - bool spec_ctrl = msr_write_intercepted_l01(vcpu, MSR_IA32_SPEC_CTRL);
> + bool pred_cmd = !msr_write_intercepted_l01(vcpu, MSR_IA32_PRED_CMD);
> + bool spec_ctrl = !msr_write_intercepted_l01(vcpu, MSR_IA32_SPEC_CTRL);
>
> +/* Nothing to do if the MSR bitmap is not in use. */
> +if (!cpu_has_vmx_msr_bitmap() ||
> +!nested_cpu_has(vmcs12, CPU_BASED_USE_MSR_BITMAPS))
> +return false;
> +
> if (!nested_cpu_has_virt_x2apic_mode(vmcs12) &&
> !pred_cmd && !spec_ctrl)
> return false;
The resolution looks good to me, I did a similar resolution and diffed the
linux-next version to the tip:msater version.
Thanks,
Ingo
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/kvm/vmx.c
between commit:
c992384bde84 ("KVM: vmx: speed up MSR bitmap merge")
from Linus' tree and commit:
ff37dc0cd96c ("KVM/nVMX: Set the CPU_BASED_USE_MSR_BITMAPS if we have a valid
L02 MSR bitmap")
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/kvm/vmx.c
index f427723dc7db,91e3539cba02..
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@@ -10136,7 -10127,12 +10136,10 @@@ static void nested_get_vmcs12_pages(str
(unsigned long)(vmcs12->posted_intr_desc_addr &
(PAGE_SIZE - 1)));
}
- if (!nested_vmx_prepare_msr_bitmap(vcpu, vmcs12))
- if (cpu_has_vmx_msr_bitmap() &&
- nested_cpu_has(vmcs12, CPU_BASED_USE_MSR_BITMAPS) &&
- nested_vmx_merge_msr_bitmap(vcpu, vmcs12))
++ if (nested_vmx_prepare_msr_bitmap(vcpu, vmcs12))
+ vmcs_set_bits(CPU_BASED_VM_EXEC_CONTROL,
+ CPU_BASED_USE_MSR_BITMAPS);
+ else
vmcs_clear_bits(CPU_BASED_VM_EXEC_CONTROL,
CPU_BASED_USE_MSR_BITMAPS);
}
@@@ -10224,14 -10220,9 +10227,14 @@@ static inline bool nested_vmx_prepare_m
*updated to reflect this when L1 (or its L2s) actually write to
*the MSR.
*/
- bool pred_cmd = msr_write_intercepted_l01(vcpu, MSR_IA32_PRED_CMD);
- bool spec_ctrl = msr_write_intercepted_l01(vcpu, MSR_IA32_SPEC_CTRL);
+ bool pred_cmd = !msr_write_intercepted_l01(vcpu, MSR_IA32_PRED_CMD);
+ bool spec_ctrl = !msr_write_intercepted_l01(vcpu, MSR_IA32_SPEC_CTRL);
+ /* Nothing to do if the MSR bitmap is not in use. */
+ if (!cpu_has_vmx_msr_bitmap() ||
+ !nested_cpu_has(vmcs12, CPU_BASED_USE_MSR_BITMAPS))
+ return false;
+
if (!nested_cpu_has_virt_x2apic_mode(vmcs12) &&
!pred_cmd && !spec_ctrl)
return false;
Re: linux-next: manual merge of the tip tree with Linus' tree
- On Feb 9, 2018, at 1:25 PM, Will Deacon will.dea...@arm.com wrote: > On Thu, Feb 08, 2018 at 07:04:56PM +, Mathieu Desnoyers wrote: >> - On Feb 8, 2018, at 1:56 PM, Will Deacon will.dea...@arm.com wrote: >> >> > On Thu, Feb 08, 2018 at 08:03:50AM +0100, Ingo Molnar wrote: >> >> >> >> * Will Deacon wrote: >> >> >> >> > For the sake of avoiding the conflict, can we just drop it for now, >> >> > please? >> >> >> >> Yeah, so I resolved the conflict by merging the (already upstream) bits >> >> and >> >> Linus >> >> pulled that resolution. From now on the level of comments you want there >> >> is up >> >> to >> >> you! :-) >> > >> > Haha, ok! Mathieu -- are you still planning to add something under >> > Documentation/? Regardless of my preference on comments, I think it would >> > be useful. >> >> I submitted it as RFC a few days ago, and I'm still awaiting feedback: >> >> http://lkml.kernel.org/r/1517936413-19675-1-git-send-email-mathieu.desnoy...@efficios.com >> >> If you guys are OK with the approach, I can submit it again, this time >> without >> the RFC >> tag. > > Yes, please! Done: https://lkml.kernel.org/r/1518208256-22034-1-git-send-email-mathieu.desnoy...@efficios.com Let's see what Thomas/Ingo/PeterZ have to say about this approach to documentation. Ingo, if you are OK with it, this feature documentation patch could go through the scheduler tree. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Re: linux-next: manual merge of the tip tree with Linus' tree
On Thu, Feb 08, 2018 at 07:04:56PM +, Mathieu Desnoyers wrote: > - On Feb 8, 2018, at 1:56 PM, Will Deacon will.dea...@arm.com wrote: > > > On Thu, Feb 08, 2018 at 08:03:50AM +0100, Ingo Molnar wrote: > >> > >> * Will Deacon wrote: > >> > >> > For the sake of avoiding the conflict, can we just drop it for now, > >> > please? > >> > >> Yeah, so I resolved the conflict by merging the (already upstream) bits and > >> Linus > >> pulled that resolution. From now on the level of comments you want there > >> is up > >> to > >> you! :-) > > > > Haha, ok! Mathieu -- are you still planning to add something under > > Documentation/? Regardless of my preference on comments, I think it would > > be useful. > > I submitted it as RFC a few days ago, and I'm still awaiting feedback: > > http://lkml.kernel.org/r/1517936413-19675-1-git-send-email-mathieu.desnoy...@efficios.com > > If you guys are OK with the approach, I can submit it again, this time > without the RFC > tag. Yes, please! Will
Re: linux-next: manual merge of the tip tree with Linus' tree
- On Feb 8, 2018, at 1:56 PM, Will Deacon will.dea...@arm.com wrote: > On Thu, Feb 08, 2018 at 08:03:50AM +0100, Ingo Molnar wrote: >> >> * Will Deacon wrote: >> >> > For the sake of avoiding the conflict, can we just drop it for now, please? >> >> Yeah, so I resolved the conflict by merging the (already upstream) bits and >> Linus >> pulled that resolution. From now on the level of comments you want there is >> up >> to >> you! :-) > > Haha, ok! Mathieu -- are you still planning to add something under > Documentation/? Regardless of my preference on comments, I think it would > be useful. I submitted it as RFC a few days ago, and I'm still awaiting feedback: http://lkml.kernel.org/r/1517936413-19675-1-git-send-email-mathieu.desnoy...@efficios.com If you guys are OK with the approach, I can submit it again, this time without the RFC tag. Thanks, Mathieu > > Will -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Re: linux-next: manual merge of the tip tree with Linus' tree
On Thu, Feb 08, 2018 at 08:03:50AM +0100, Ingo Molnar wrote: > > * Will Deacon wrote: > > > For the sake of avoiding the conflict, can we just drop it for now, please? > > Yeah, so I resolved the conflict by merging the (already upstream) bits and > Linus > pulled that resolution. From now on the level of comments you want there is > up to > you! :-) Haha, ok! Mathieu -- are you still planning to add something under Documentation/? Regardless of my preference on comments, I think it would be useful. Will
Re: linux-next: manual merge of the tip tree with Linus' tree
* Will Deacon wrote: > For the sake of avoiding the conflict, can we just drop it for now, please? Yeah, so I resolved the conflict by merging the (already upstream) bits and Linus pulled that resolution. From now on the level of comments you want there is up to you! :-) Thanks, Ingo
Re: linux-next: manual merge of the tip tree with Linus' tree
On Tue, Feb 06, 2018 at 05:05:52PM +, Mathieu Desnoyers wrote: > - On Feb 6, 2018, at 9:11 AM, Will Deacon will.dea...@arm.com wrote: > > > On Tue, Feb 06, 2018 at 02:06:50PM +, Mathieu Desnoyers wrote: > >> - On Feb 6, 2018, at 8:55 AM, Will Deacon will.dea...@arm.com wrote: > >> > On Tue, Feb 06, 2018 at 12:52:34PM +, Mathieu Desnoyers wrote: > >> >> One approach I would consider for this is to duplicate this > >> >> comment and add it just above the "eret" instruction within the > >> >> macro: > >> >> > >> >> /* > >> >> * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context > >> >> synchronization > >> >> * when returning from IPI handler, and when returning to > >> >> user-space. > >> >> */ > >> >> > >> >> Or perhaps Will has something else in mind ? > >> > > >> > To be honest with you, I'd just drop the comment entirely. entry.S is > >> > terrifying these days and nobody should have to go in there to understand > >> > why we select ARCH_HAS_MEMBARRIER_SYNC_CORE. If you really feel a > >> > justification > >> > is needed, I'd be happy with a line in the Kconfig file. > >> > >> My concern is that someone wanting to optimize away a few cycles by > >> changing > >> eret to something else in the future will not be looking at Kconfig: that > >> person will be staring at entry.S. > > > > That person will probably also be me, or somebody who sits within punching > > distance. I really wouldn't worry about it. There a bunch of other > > things that will break if we don't use ERET here and, if it's a real > > concern, we're making the *huge* assumption that developers actually > > read and pay attention to comments. > > > >> One alternative presented by PeterZ on irc is to do like ppc: define a > >> macro for eret, and stick all appropriate comments near the macro. This > >> way, it won't hurt when reading the code, but at least it keeps the > >> comments near the instruction being discussed. > > > > For the sake of avoiding the conflict, can we just drop it for now, please? > > Having an "eret" macro isn't obvious, because people won't realise that it's > > a macro. Having "exception_return" is cryptic as hell to people familiar > > with the ISA. > > I'd be OK not adding comments in the assembly provided that we document this > within the new documentation file as I just posted as RFC: > > http://lkml.kernel.org/r/1517936413-19675-1-git-send-email-mathieu.desnoy...@efficios.com > > Thoughts ? I certainly think that Documentation/ and probably init/Kconfig are the right places to describe this, but I defer to Ingo on whether or not arch-support.txt is ok with free-form text comments. Will
Re: linux-next: manual merge of the tip tree with Linus' tree
- On Feb 6, 2018, at 9:11 AM, Will Deacon will.dea...@arm.com wrote: > On Tue, Feb 06, 2018 at 02:06:50PM +, Mathieu Desnoyers wrote: >> - On Feb 6, 2018, at 8:55 AM, Will Deacon will.dea...@arm.com wrote: >> > On Tue, Feb 06, 2018 at 12:52:34PM +, Mathieu Desnoyers wrote: >> >> One approach I would consider for this is to duplicate this >> >> comment and add it just above the "eret" instruction within the >> >> macro: >> >> >> >> /* >> >>* ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization >> >>* when returning from IPI handler, and when returning to user-space. >> >>*/ >> >> >> >> Or perhaps Will has something else in mind ? >> > >> > To be honest with you, I'd just drop the comment entirely. entry.S is >> > terrifying these days and nobody should have to go in there to understand >> > why we select ARCH_HAS_MEMBARRIER_SYNC_CORE. If you really feel a >> > justification >> > is needed, I'd be happy with a line in the Kconfig file. >> >> My concern is that someone wanting to optimize away a few cycles by changing >> eret to something else in the future will not be looking at Kconfig: that >> person will be staring at entry.S. > > That person will probably also be me, or somebody who sits within punching > distance. I really wouldn't worry about it. There a bunch of other > things that will break if we don't use ERET here and, if it's a real > concern, we're making the *huge* assumption that developers actually > read and pay attention to comments. > >> One alternative presented by PeterZ on irc is to do like ppc: define a >> macro for eret, and stick all appropriate comments near the macro. This >> way, it won't hurt when reading the code, but at least it keeps the >> comments near the instruction being discussed. > > For the sake of avoiding the conflict, can we just drop it for now, please? > Having an "eret" macro isn't obvious, because people won't realise that it's > a macro. Having "exception_return" is cryptic as hell to people familiar > with the ISA. I'd be OK not adding comments in the assembly provided that we document this within the new documentation file as I just posted as RFC: http://lkml.kernel.org/r/1517936413-19675-1-git-send-email-mathieu.desnoy...@efficios.com Thoughts ? Thanks, Mathieu > > Will -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Re: linux-next: manual merge of the tip tree with Linus' tree
On Tue, Feb 06, 2018 at 02:06:50PM +, Mathieu Desnoyers wrote: > - On Feb 6, 2018, at 8:55 AM, Will Deacon will.dea...@arm.com wrote: > > On Tue, Feb 06, 2018 at 12:52:34PM +, Mathieu Desnoyers wrote: > >> One approach I would consider for this is to duplicate this > >> comment and add it just above the "eret" instruction within the > >> macro: > >> > >>/* > >> * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization > >> * when returning from IPI handler, and when returning to user-space. > >> */ > >> > >> Or perhaps Will has something else in mind ? > > > > To be honest with you, I'd just drop the comment entirely. entry.S is > > terrifying these days and nobody should have to go in there to understand > > why we select ARCH_HAS_MEMBARRIER_SYNC_CORE. If you really feel a > > justification > > is needed, I'd be happy with a line in the Kconfig file. > > My concern is that someone wanting to optimize away a few cycles by changing > eret to something else in the future will not be looking at Kconfig: that > person will be staring at entry.S. That person will probably also be me, or somebody who sits within punching distance. I really wouldn't worry about it. There a bunch of other things that will break if we don't use ERET here and, if it's a real concern, we're making the *huge* assumption that developers actually read and pay attention to comments. > One alternative presented by PeterZ on irc is to do like ppc: define a > macro for eret, and stick all appropriate comments near the macro. This > way, it won't hurt when reading the code, but at least it keeps the > comments near the instruction being discussed. For the sake of avoiding the conflict, can we just drop it for now, please? Having an "eret" macro isn't obvious, because people won't realise that it's a macro. Having "exception_return" is cryptic as hell to people familiar with the ISA. Will
Re: linux-next: manual merge of the tip tree with Linus' tree
- On Feb 6, 2018, at 8:55 AM, Will Deacon will.dea...@arm.com wrote:
> On Tue, Feb 06, 2018 at 12:52:34PM +, Mathieu Desnoyers wrote:
>> - On Feb 5, 2018, at 7:40 PM, Stephen Rothwell s...@canb.auug.org.au
>> wrote:
>>
>> > Hi all,
>> >
>> > Today's linux-next merge of the tip tree got a conflict in:
>> >
>> > arch/arm64/kernel/entry.S
>> >
>> > between commit:
>> >
>> > 4bf3286d29f3 ("arm64: entry: Hook up entry trampoline to exception
>> > vectors")
>> >
>> > from Linus' tree and commit:
>> >
>> > f1e3a12b6543 ("membarrier/arm64: Provide core serializing command")
>> >
>> > from the tip tree.
>> >
>> > I fixed it up (probably not completely - 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.
>>
>> The change introduced by 4bf3286d29 "arm64: entry: Hook up entry trampoline
>> to exception vectors" adds a trampoline as mechanism for return:
>>
>> - eret// return to kernel
>> +
>> +#ifndef CONFIG_UNMAP_KERNEL_AT_EL0
>> + eret
>> +#else
>> + .if \el == 0
>> + bne 4f
>> + msr far_el1, x30
>> + tramp_alias x30, tramp_exit_native
>> + br x30
>> +4:
>> + tramp_alias x30, tramp_exit_compat
>> + br x30
>> + .else
>> + eret
>> + .endif
>> +#endif
>>
>> Which means that with CONFIG_UNMAP_KERNEL_AT_EL0, for return to EL0,
>> the eret is in the trampoline:
>>
>> .macro tramp_exit, regsize = 64
>> adr x30, tramp_vectors
>> msr vbar_el1, x30
>> tramp_unmap_kernel x30
>> .if \regsize == 64
>> mrs x30, far_el1
>> .endif
>> eret
>> .endm
>>
>> ENTRY(tramp_exit_native)
>> tramp_exit
>> END(tramp_exit_native)
>>
>> ENTRY(tramp_exit_compat)
>> tramp_exit 32
>> END(tramp_exit_compat)
>>
>>
>> One approach I would consider for this is to duplicate this
>> comment and add it just above the "eret" instruction within the
>> macro:
>>
>> /*
>> * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization
>> * when returning from IPI handler, and when returning to user-space.
>> */
>>
>> Or perhaps Will has something else in mind ?
>
> To be honest with you, I'd just drop the comment entirely. entry.S is
> terrifying these days and nobody should have to go in there to understand
> why we select ARCH_HAS_MEMBARRIER_SYNC_CORE. If you really feel a
> justification
> is needed, I'd be happy with a line in the Kconfig file.
My concern is that someone wanting to optimize away a few cycles by changing
eret to something else in the future will not be looking at Kconfig: that
person will be staring at entry.S.
One alternative presented by PeterZ on irc is to do like ppc: define a
macro for eret, and stick all appropriate comments near the macro. This
way, it won't hurt when reading the code, but at least it keeps the
comments near the instruction being discussed.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Re: linux-next: manual merge of the tip tree with Linus' tree
On Tue, Feb 06, 2018 at 12:52:34PM +, Mathieu Desnoyers wrote:
> - On Feb 5, 2018, at 7:40 PM, Stephen Rothwell s...@canb.auug.org.au
> wrote:
>
> > Hi all,
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > arch/arm64/kernel/entry.S
> >
> > between commit:
> >
> > 4bf3286d29f3 ("arm64: entry: Hook up entry trampoline to exception
> > vectors")
> >
> > from Linus' tree and commit:
> >
> > f1e3a12b6543 ("membarrier/arm64: Provide core serializing command")
> >
> > from the tip tree.
> >
> > I fixed it up (probably not completely - 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.
>
> The change introduced by 4bf3286d29 "arm64: entry: Hook up entry trampoline
> to exception vectors" adds a trampoline as mechanism for return:
>
> - eret// return to kernel
> +
> +#ifndef CONFIG_UNMAP_KERNEL_AT_EL0
> + eret
> +#else
> + .if \el == 0
> + bne 4f
> + msr far_el1, x30
> + tramp_alias x30, tramp_exit_native
> + br x30
> +4:
> + tramp_alias x30, tramp_exit_compat
> + br x30
> + .else
> + eret
> + .endif
> +#endif
>
> Which means that with CONFIG_UNMAP_KERNEL_AT_EL0, for return to EL0,
> the eret is in the trampoline:
>
> .macro tramp_exit, regsize = 64
> adr x30, tramp_vectors
> msr vbar_el1, x30
> tramp_unmap_kernel x30
> .if \regsize == 64
> mrs x30, far_el1
> .endif
> eret
> .endm
>
> ENTRY(tramp_exit_native)
> tramp_exit
> END(tramp_exit_native)
>
> ENTRY(tramp_exit_compat)
> tramp_exit 32
> END(tramp_exit_compat)
>
>
> One approach I would consider for this is to duplicate this
> comment and add it just above the "eret" instruction within the
> macro:
>
> /*
>* ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization
>* when returning from IPI handler, and when returning to user-space.
>*/
>
> Or perhaps Will has something else in mind ?
To be honest with you, I'd just drop the comment entirely. entry.S is
terrifying these days and nobody should have to go in there to understand
why we select ARCH_HAS_MEMBARRIER_SYNC_CORE. If you really feel a justification
is needed, I'd be happy with a line in the Kconfig file.
Will
Re: linux-next: manual merge of the tip tree with Linus' tree
- On Feb 5, 2018, at 7:40 PM, Stephen Rothwell s...@canb.auug.org.au wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/arm64/kernel/entry.S
>
> between commit:
>
> 4bf3286d29f3 ("arm64: entry: Hook up entry trampoline to exception vectors")
>
> from Linus' tree and commit:
>
> f1e3a12b6543 ("membarrier/arm64: Provide core serializing command")
>
> from the tip tree.
>
> I fixed it up (probably not completely - 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.
The change introduced by 4bf3286d29 "arm64: entry: Hook up entry trampoline
to exception vectors" adds a trampoline as mechanism for return:
- eret// return to kernel
+
+#ifndef CONFIG_UNMAP_KERNEL_AT_EL0
+ eret
+#else
+ .if \el == 0
+ bne 4f
+ msr far_el1, x30
+ tramp_alias x30, tramp_exit_native
+ br x30
+4:
+ tramp_alias x30, tramp_exit_compat
+ br x30
+ .else
+ eret
+ .endif
+#endif
Which means that with CONFIG_UNMAP_KERNEL_AT_EL0, for return to EL0,
the eret is in the trampoline:
.macro tramp_exit, regsize = 64
adr x30, tramp_vectors
msr vbar_el1, x30
tramp_unmap_kernel x30
.if \regsize == 64
mrs x30, far_el1
.endif
eret
.endm
ENTRY(tramp_exit_native)
tramp_exit
END(tramp_exit_native)
ENTRY(tramp_exit_compat)
tramp_exit 32
END(tramp_exit_compat)
One approach I would consider for this is to duplicate this
comment and add it just above the "eret" instruction within the
macro:
/*
* ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization
* when returning from IPI handler, and when returning to user-space.
*/
Or perhaps Will has something else in mind ?
Thanks,
Mathieu
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm64/kernel/entry.S
> index b34e717d7597,5edde1c2e93e..
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@@ -324,21 -302,11 +324,25 @@@ alternative_else_nop_endi
> ldp x28, x29, [sp, #16 * 14]
> ldr lr, [sp, #S_LR]
> add sp, sp, #S_FRAME_SIZE // restore sp
> +
> + .if \el == 0
> +alternative_insn eret, nop, ARM64_UNMAP_KERNEL_AT_EL0
> +#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
> + bne 4f
> + msr far_el1, x30
> + tramp_alias x30, tramp_exit_native
> + br x30
> +4:
> + tramp_alias x30, tramp_exit_compat
> + br x30
> +#endif
> + .else
> + /*
> + * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization
> + * when returning from IPI handler, and when returning to user-space.
> + */
> - eret// return to kernel
> + eret
> + .endif
> .endm
>
> .macro irq_stack_entry
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Re: linux-next: manual merge of the tip tree with Linus' tree
On Tue, Feb 06, 2018 at 11:54:38AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> include/linux/sched/mm.h
>
> between commit:
>
> d70f2a14b72a ("include/linux/sched/mm.h: uninline mmdrop_async(), etc")
FWIW, akpm has a patch that re-inlines mmdrop().
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
include/linux/sched/mm.h
between commit:
d70f2a14b72a ("include/linux/sched/mm.h: uninline mmdrop_async(), etc")
from Linus' tree and commit:
306e060435d7 ("membarrier: Document scheduler barrier requirements")
from the tip tree.
I fixed it up (I used the former version ofinclude/linux/sched/mm.h
and adde the following merge fix patch) 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.
From: Stephen Rothwell
Date: Tue, 6 Feb 2018 11:51:34 +1100
Subject: [PATCH] membarrier: fix up for mmdrop move
Signed-off-by: Stephen Rothwell
---
kernel/fork.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/kernel/fork.c b/kernel/fork.c
index 5c372c954f3b..c7c112391d79 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -606,6 +606,11 @@ static void __mmdrop(struct mm_struct *mm)
void mmdrop(struct mm_struct *mm)
{
+ /*
+* The implicit full barrier implied by atomic_dec_and_test() is
+* required by the membarrier system call before returning to
+* user-space, after storing to rq->curr.
+*/
if (unlikely(atomic_dec_and_test(&mm->mm_count)))
__mmdrop(mm);
}
--
2.15.1
--
Cheers,
Stephen Rothwell
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/Kconfig
between commit:
ea8c64ace866 ("dma-mapping: move swiotlb arch helpers to a new header")
from Linus' tree and commit:
10bcc80e9dbc ("membarrier/x86: Provide core serializing command")
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/Kconfig
index b0771ceabb4b,e095bdb9afdf..
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -54,7 -54,7 +54,8 @@@ config X8
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_KCOVif X86_64
+ select ARCH_HAS_MEMBARRIER_SYNC_CORE
+ select ARCH_HAS_PHYS_TO_DMA
select ARCH_HAS_PMEM_APIif X86_64
select ARCH_HAS_REFCOUNT
select ARCH_HAS_UACCESS_FLUSHCACHE if X86_64
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/arm64/kernel/entry.S
between commit:
4bf3286d29f3 ("arm64: entry: Hook up entry trampoline to exception vectors")
from Linus' tree and commit:
f1e3a12b6543 ("membarrier/arm64: Provide core serializing command")
from the tip tree.
I fixed it up (probably not completely - 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/arm64/kernel/entry.S
index b34e717d7597,5edde1c2e93e..
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@@ -324,21 -302,11 +324,25 @@@ alternative_else_nop_endi
ldp x28, x29, [sp, #16 * 14]
ldr lr, [sp, #S_LR]
add sp, sp, #S_FRAME_SIZE // restore sp
+
+ .if \el == 0
+alternative_insn eret, nop, ARM64_UNMAP_KERNEL_AT_EL0
+#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
+ bne 4f
+ msr far_el1, x30
+ tramp_alias x30, tramp_exit_native
+ br x30
+4:
+ tramp_alias x30, tramp_exit_compat
+ br x30
+#endif
+ .else
+ /*
+* ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization
+* when returning from IPI handler, and when returning to user-space.
+*/
- eret// return to kernel
+ eret
+ .endif
.endm
.macro irq_stack_entry
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/mm/mem_encrypt.c
between commit:
87df26175e67 ("x86/mm: Unbreak modules that rely on external PAGE_KERNEL
availability")
from Linus' tree and commit:
606b21d4a649 ("x86/io: Unroll string I/O when SEV is active")
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/mem_encrypt.c
index 0286327e65fa,d247c14469de..
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@@ -40,7 -42,11 +42,11 @@@ static char sme_cmdline_off[] __initdat
* section is later cleared.
*/
u64 sme_me_mask __section(.data) = 0;
-EXPORT_SYMBOL_GPL(sme_me_mask);
+EXPORT_SYMBOL(sme_me_mask);
+ DEFINE_STATIC_KEY_FALSE(sev_enable_key);
+ EXPORT_SYMBOL_GPL(sev_enable_key);
+
+ static bool sev_enabled __section(.data);
/* Buffer used for early in-place encryption by BSP, no locking needed */
static char sme_early_buffer[PAGE_SIZE] __aligned(PAGE_SIZE);
Re: linux-next: manual merge of the tip tree with Linus' tree
Hi Stephen, On Tue, May 23, 2017 at 07:44:56AM +1000, Stephen Rothwell wrote: > On Mon, 22 May 2017 09:32:15 +0100 Mark Rutland wrote: > > > > Just to check, is your copy of tip up-to-date? > > Yes, it was fetched just before being merged. I use the auto-latest > branch of the tip tree which may not be as up to date as the master > branch. Thanks for the pointer; there was a stale copy there, which has now been zapped. Hopefully we're conflict-free for next-20170524. Thanks for the heads-up! Mark.
Re: linux-next: manual merge of the tip tree with Linus' tree
Hi Mark, On Mon, 22 May 2017 09:32:15 +0100 Mark Rutland wrote: > > Just to check, is your copy of tip up-to-date? Yes, it was fetched just before being merged. I use the auto-latest branch of the tip tree which may not be as up to date as the master branch. > That latter commit was in the tip smp/hotplug branch, but that branch > was reset to v4.12-rc1 a few days ago (before the first commit was sent > to Linus), specifically to avoid this conflict. > > ... did we miss another branch that was merged into, perhaps? Presumably, but that's ok - I assume it will come good eventually. > The good news is that the commit in Linus' tree is the correct fix. :) Well, except that I only fixed up that one spot, the rest of the commit from the tip tree was still there. > The other commit was a slightly broken prior attempt, and shouldn't be > in the tip tree any more. OK. -- Cheers, Stephen Rothwell
Re: linux-next: manual merge of the tip tree with Linus' tree
On Mon, May 22, 2017 at 01:27:11PM +1000, Stephen Rothwell wrote:
> Hi all,
Hi,
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/arm64/include/asm/cpufeature.h
>
> between commit:
>
> 63a1e1c95e60 ("arm64/cpufeature: don't use mutex in bringup path")
>
> from Linus' tree and commit:
>
> d54bb72551b9 ("arm64/cpufeature: Use static_branch_enable_cpuslocked()")
>
> from the tip tree.
Just to check, is your copy of tip up-to-date?
That latter commit was in the tip smp/hotplug branch, but that branch
was reset to v4.12-rc1 a few days ago (before the first commit was sent
to Linus), specifically to avoid this conflict.
... did we miss another branch that was merged into, perhaps?
> I have no idea what the correct resolution is here, so I have just gone
> with the former for now (i.e. removed the
> static_branch_enable_cpuslocked() call). This will probably need a
> better (or even correct :-)) fix.
The good news is that the commit in Linus' tree is the correct fix. :)
The other commit was a slightly broken prior attempt, and shouldn't be
in the tip tree any more.
> I fixed it up (see above) 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.
We tried, but evidently something went wrong. :/
Thanks,
Mark.
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/arm64/include/asm/cpufeature.h
between commit:
63a1e1c95e60 ("arm64/cpufeature: don't use mutex in bringup path")
from Linus' tree and commit:
d54bb72551b9 ("arm64/cpufeature: Use static_branch_enable_cpuslocked()")
from the tip tree.
I have no idea what the correct resolution is here, so I have just gone
with the former for now (i.e. removed the
static_branch_enable_cpuslocked() call). This will probably need a
better (or even correct :-)) fix.
I fixed it up (see above) 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
Re: linux-next: manual merge of the tip tree with Linus' tree
On Wed, 2016-02-03 at 11:09 +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> kernel/memremap.c
>
> between commit:
>
> eb7d78c9e7f6 ("devm_memremap_pages: fix vmem_altmap lifetime +
> alignment handling")
>
> from Linus' tree and commit:
>
> 1c29f25bf5d6 ("memremap: Change region_intersects() to take @flags and
> @desc")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good. Thanks for the marge.
-Toshi
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
kernel/memremap.c
between commit:
eb7d78c9e7f6 ("devm_memremap_pages: fix vmem_altmap lifetime + alignment
handling")
from Linus' tree and commit:
1c29f25bf5d6 ("memremap: Change region_intersects() to take @flags and @desc")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell
diff --cc kernel/memremap.c
index 70ee3775de24,293309cac061..
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@@ -269,8 -267,8 +270,8 @@@ void *devm_memremap_pages(struct devic
struct percpu_ref *ref, struct vmem_altmap *altmap)
{
int is_ram = region_intersects(res->start, resource_size(res),
- "System RAM");
+ IORESOURCE_SYSTEM_RAM, IORES_DESC_NONE);
- resource_size_t key, align_start, align_size;
+ resource_size_t key, align_start, align_size, align_end;
struct dev_pagemap *pgmap;
struct page_map *page_map;
unsigned long pfn;
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
tools/perf/ui/browsers/hists.c
between commit:
bd315aab8a3a ("perf top: Fix segfault pressing -> with no hist entries")
from Linus' tree and commit:
84734b06b630 ("perf hists browser: Zoom in/out for processor socket")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc tools/perf/ui/browsers/hists.c
index c04c60d4863c,380e9080991e..
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@@ -1968,9 -2017,10 +2017,11 @@@ skip_annotation
&options[nr_options], dso);
nr_options += add_map_opt(browser, &actions[nr_options],
&options[nr_options],
-browser->selection->map);
+browser->selection ?
+ browser->selection->map : NULL);
-
+ nr_options += add_socket_opt(browser, &actions[nr_options],
+&options[nr_options],
+socked_id);
/* perf script support */
if (browser->he_selection) {
nr_options += add_script_opt(browser,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/entry/entry_64_compat.S
between commit:
cd88ec231701 ("x86: fix error handling for 32-bit compat out-of-range system
call numbers")
from Linus' tree and commit:
c73e36b775a7 ("x86/asm/entry/32: Replace RESTORE_RSI_RDI with open-coded
32-bit reads")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/x86/entry/entry_64_compat.S
index a7e257d9cb90,8997383ba170..
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@@ -140,8 -140,8 +140,9 @@@ sysexit_from_sys_call
*/
andl$~TS_COMPAT, ASM_THREAD_INFO(TI_status, %rsp, SIZEOF_PTREGS)
movlRIP(%rsp), %ecx /* User %eip */
+ movqRAX(%rsp), %rax
- RESTORE_RSI_RDI
+ movlRSI(%rsp), %esi
+ movlRDI(%rsp), %edi
xorl%edx, %edx /* Do not leak kernel information */
xorq%r8, %r8
xorq%r9, %r9
@@@ -365,10 -366,11 +366,12 @@@ cstar_dispatch
sysretl_from_sys_call:
andl$~TS_COMPAT, ASM_THREAD_INFO(TI_status, %rsp, SIZEOF_PTREGS)
- RESTORE_RSI_RDI_RDX
+ movlRDX(%rsp), %edx
+ movlRSI(%rsp), %esi
+ movlRDI(%rsp), %edi
movlRIP(%rsp), %ecx
movlEFLAGS(%rsp), %r11d
+ movqRAX(%rsp), %rax
xorq%r10, %r10
xorq%r9, %r9
xorq%r8, %r8
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the tip tree with Linus' tree
Hi Paolo,
On Mon, 6 Jul 2015 09:49:09 +0200 Paolo Bonzini wrote:
>
> On 06/07/2015 02:08, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > kernel/sched/core.c
> >
> > between commit:
> >
> > 2ecd9d29abb1 ("sched, preempt_notifier: separate notifier
> > registration from static_key inc/dec")
> >
> > from Linus' tree and commit:
> >
> > 6efde1d3716b ("sched/preempt, kvm: Fix KVM preempt_notifier
> > usage")
> >
> > from the tip tree.
> >
> > I fixed it up (maybe - see below) and can carry the fix as
> > necessary (no action is required).
>
> The commit from the tip tree is obsolete.
And has now been removed from the tip tree, so we won't see that
conflict today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpzR5mm6htap.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the tip tree with Linus' tree
On 06/07/2015 02:08, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> kernel/sched/core.c
>
> between commit:
>
> 2ecd9d29abb1 ("sched, preempt_notifier: separate notifier
> registration from static_key inc/dec")
>
> from Linus' tree and commit:
>
> 6efde1d3716b ("sched/preempt, kvm: Fix KVM preempt_notifier
> usage")
>
> from the tip tree.
>
> I fixed it up (maybe - see below) and can carry the fix as
> necessary (no action is required).
The commit from the tip tree is obsolete.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
kernel/sched/core.c
between commit:
2ecd9d29abb1 ("sched, preempt_notifier: separate notifier registration from
static_key inc/dec")
from Linus' tree and commit:
6efde1d3716b ("sched/preempt, kvm: Fix KVM preempt_notifier usage")
from the tip tree.
I fixed it up (maybe - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc kernel/sched/core.c
index 78b4bad10081,850e54b89a11..
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@@ -2338,10 -2326,13 +2338,15 @@@ EXPORT_SYMBOL_GPL(preempt_notifier_dec)
*/
void preempt_notifier_register(struct preempt_notifier *notifier)
{
- static_key_slow_inc(&preempt_notifier_key);
+ if (!static_key_false(&preempt_notifier_key))
+ WARN(1, "registering preempt_notifier while notifiers
disabled\n");
+
+ /*
+* Avoid preemption while changing the preempt notifier list.
+*/
+ preempt_disable();
hlist_add_head(¬ifier->link, ¤t->preempt_notifiers);
+ preempt_enable();
}
EXPORT_SYMBOL_GPL(preempt_notifier_register);
@@@ -2353,7 -2344,14 +2358,12 @@@
*/
void preempt_notifier_unregister(struct preempt_notifier *notifier)
{
+ /*
+* Avoid preemption while changing the preempt notifier list.
+*/
+ preempt_disable();
hlist_del(¬ifier->link);
+ preempt_enable();
-
- static_key_slow_dec(&preempt_notifier_key);
}
EXPORT_SYMBOL_GPL(preempt_notifier_unregister);
pgpndyfYs0C4c.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the tip tree with Linus' tree
* Ingo Molnar wrote:
>
> * H. Peter Anvin wrote:
>
> > On 05/20/2014 09:12 PM, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the tip tree got a conflict in
> > > arch/x86/kernel/ldt.c between commit fa81511bb0bb ("x86-64,
> > > modify_ldt: Make support for 16-bit segments a runtime option")
> > > from Linus' tree and commit 34273f41d57e ("x86, espfix: Make it
> > > possible to disable 16-bit support") from the tip tree.
> > >
> > > I fixed it up (see below) and can carry the fix as necessary (no
> > > action is required).
> > >
> >
> > This (and the previous one) is not the correct fix, although it will
> > work. The correct fix is instead to completely revert fa81511bb0bb
> > before merging in tip:x86/espfix.
> >
> > Sorry for the inconvenience. Linus generally doesn't like it when we
> > fix up merges for him, or I'd set up a "clean" tip:x86/espfix branch.
>
> Please merge x86/urgent into x86/vdso while memories are still fresh
> - fixing up conflicts between our own branches is entirely fine (I'm
> doing it all the time to help the development flow) and it will make
> life easier.
>
> What Linus dislikes most are merges between completely _unrelated_
> topic branches, especially if they cross maintenance domains.
Also, 'pre pull request' conflict resolution merges are frowned upon
mostly, as they tend to be of lower quality, come with little testing,
and they also hide the various conflict interactions, many of which
are canaries of bad development flow.
Here the development flow is healthy: what conflicted was a quick and
simple short term urgent fix for upstream which came through you, with
the longer term fix coming in the next window, through you as well.
Resolving those conflicts in the development branch, to make developer
life easier, is pretty natural and I'd say is even considered good
practice in a clean Git flow.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the tip tree with Linus' tree
* H. Peter Anvin wrote: > Ok. Will do. Thanks! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the tip tree with Linus' tree
Ok. Will do.
On May 20, 2014 11:01:00 PM PDT, Ingo Molnar wrote:
>
>* H. Peter Anvin wrote:
>
>> On 05/20/2014 09:12 PM, Stephen Rothwell wrote:
>> > Hi all,
>> >
>> > Today's linux-next merge of the tip tree got a conflict in
>> > arch/x86/kernel/ldt.c between commit fa81511bb0bb ("x86-64,
>> > modify_ldt: Make support for 16-bit segments a runtime option")
>> > from Linus' tree and commit 34273f41d57e ("x86, espfix: Make it
>> > possible to disable 16-bit support") from the tip tree.
>> >
>> > I fixed it up (see below) and can carry the fix as necessary (no
>> > action is required).
>> >
>>
>> This (and the previous one) is not the correct fix, although it will
>> work. The correct fix is instead to completely revert fa81511bb0bb
>> before merging in tip:x86/espfix.
>>
>> Sorry for the inconvenience. Linus generally doesn't like it when we
>> fix up merges for him, or I'd set up a "clean" tip:x86/espfix branch.
>
>Please merge x86/urgent into x86/vdso while memories are still fresh -
>fixing up conflicts between our own branches is entirely fine (I'm
>doing it all the time to help the development flow) and it will make
>life easier.
>
>What Linus dislikes most are merges between completely _unrelated_
>topic branches, especially if they cross maintenance domains.
>
>Thanks,
>
> Ingo
--
Sent from my mobile phone. Please pardon brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the tip tree with Linus' tree
* H. Peter Anvin wrote:
> On 05/20/2014 09:12 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the tip tree got a conflict in
> > arch/x86/kernel/ldt.c between commit fa81511bb0bb ("x86-64,
> > modify_ldt: Make support for 16-bit segments a runtime option")
> > from Linus' tree and commit 34273f41d57e ("x86, espfix: Make it
> > possible to disable 16-bit support") from the tip tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary (no
> > action is required).
> >
>
> This (and the previous one) is not the correct fix, although it will
> work. The correct fix is instead to completely revert fa81511bb0bb
> before merging in tip:x86/espfix.
>
> Sorry for the inconvenience. Linus generally doesn't like it when we
> fix up merges for him, or I'd set up a "clean" tip:x86/espfix branch.
Please merge x86/urgent into x86/vdso while memories are still fresh -
fixing up conflicts between our own branches is entirely fine (I'm
doing it all the time to help the development flow) and it will make
life easier.
What Linus dislikes most are merges between completely _unrelated_
topic branches, especially if they cross maintenance domains.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the tip tree with Linus' tree
On 05/20/2014 09:12 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in
> arch/x86/kernel/ldt.c between commit fa81511bb0bb ("x86-64,
> modify_ldt: Make support for 16-bit segments a runtime option")
> from Linus' tree and commit 34273f41d57e ("x86, espfix: Make it
> possible to disable 16-bit support") from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no
> action is required).
>
This (and the previous one) is not the correct fix, although it will
work. The correct fix is instead to completely revert fa81511bb0bb
before merging in tip:x86/espfix.
Sorry for the inconvenience. Linus generally doesn't like it when we
fix up merges for him, or I'd set up a "clean" tip:x86/espfix branch.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/x86/kernel/ldt.c between commit fa81511bb0bb ("x86-64, modify_ldt:
Make support for 16-bit segments a runtime option") from Linus' tree
and commit 34273f41d57e ("x86, espfix: Make it possible to disable
16-bit support") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/x86/kernel/ldt.c
index dcbbaa165bde,c37886d759cc..
--- a/arch/x86/kernel/ldt.c
+++ b/arch/x86/kernel/ldt.c
@@@ -231,12 -229,7 +231,7 @@@ static int write_ldt(void __user *ptr,
}
}
- /*
-* On x86-64 we do not support 16-bit segments due to
-* IRET leaking the high bits of the kernel stack address.
-*/
- #ifdef CONFIG_X86_64
- if (!ldt_info.seg_32bit && !sysctl_ldt16) {
- if (!IS_ENABLED(CONFIG_X86_16BIT) && !ldt_info.seg_32bit) {
++ if (!IS_ENABLED(CONFIG_X86_16BIT) && !ldt_info.seg_32bit &&
!sysctl_ldt16) {
error = -EINVAL;
goto out_unlock;
}
signature.asc
Description: PGP signature
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/x86/vdso/vdso32-setup.c between commit fa81511bb0bb ("x86-64,
modify_ldt: Make support for 16-bit segments a runtime option") from
Linus' tree and commit 18d0a6fd2271 ("x86, vdso: Move the 32-bit vdso
special pages after the text") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/x86/vdso/vdso32-setup.c
index e1f220e3ca68,c3ed708e50f4..
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@@ -36,12 -21,6 +21,10 @@@
#define VDSO_DEFAULT 1
#endif
+#ifdef CONFIG_X86_64
- #define vdso_enabled sysctl_vsyscall32
- #define arch_setup_additional_pages syscall32_setup_pages
+extern int sysctl_ldt16;
+#endif
+
/*
* Should the kernel map a VDSO page into processes and pass its
* address down to glibc upon exec()?
signature.asc
Description: PGP signature
Re: linux-next: manual merge of the tip tree with Linus' tree
On 03/21/2014 09:53 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in
> arch/x86/kernel/cpu/perf_event_intel_uncore.c between commit 2c666adacc9e
> ("x86, intel, uncore: Fix CPU hotplug callback registration") from Linus'
> tree and commit 411cf180fa00 ("perf/x86/uncore: fix initialization of
> cpumask") from the tip tree.
>
> I fixed it up (maybe incorrectly - see below) and can carry the fix as
> necessary (no action is required).
>
The fix looks good to me. Thank you!
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/x86/kernel/cpu/perf_event_intel_uncore.c between commit 2c666adacc9e
("x86, intel, uncore: Fix CPU hotplug callback registration") from Linus'
tree and commit 411cf180fa00 ("perf/x86/uncore: fix initialization of
cpumask") from the tip tree.
I fixed it up (maybe incorrectly - see below) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 28922f62eb29,bd2253d40cff..
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@@ -3868,6 -4234,41 +4234,41 @@@ static int __init uncore_pmus_register(
return 0;
}
+ static void __init uncore_cpumask_init(void)
+ {
+ int cpu;
+
+ /*
+* ony invoke once from msr or pci init code
+*/
+ if (!cpumask_empty(&uncore_cpu_mask))
+ return;
+
- get_online_cpus();
++ cpu_notifier_register_begin();
+
+ for_each_online_cpu(cpu) {
+ int i, phys_id = topology_physical_package_id(cpu);
+
+ for_each_cpu(i, &uncore_cpu_mask) {
+ if (phys_id == topology_physical_package_id(i)) {
+ phys_id = -1;
+ break;
+ }
+ }
+ if (phys_id < 0)
+ continue;
+
+ uncore_cpu_prepare(cpu, phys_id);
+ uncore_event_init_cpu(cpu);
+ }
+ on_each_cpu(uncore_cpu_setup, NULL, 1);
+
- register_cpu_notifier(&uncore_cpu_nb);
++ __register_cpu_notifier(&uncore_cpu_nb);
+
- put_online_cpus();
++ cpu_notifier_register_done();
+ }
+
+
static int __init intel_uncore_init(void)
{
int ret;
pgp4hMp5ePTQi.pgp
Description: PGP signature
Re: linux-next: manual merge of the tip tree with Linus' tree
On 02/18/2014 04:06 PM, Hans-Christian Egtvedt wrote:
> Around Tue 18 Feb 2014 14:09:20 +1100 or thereabout, Stephen Rothwell wrote:
>
> Hello Stephen,
>
>> Today's linux-next merge of the tip tree got a conflict in
>> arch/avr32/include/asm/Kbuild between commit d7668f9d448a ("avr32: add
>> generic vga.h to Kbuild") from the tree and commit b119fa61d440
>> ("locking/mcs: Order the header files in Kbuild of each architecture in
>> alphabetical order") from the tip tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
>
> Thank you for handling the merge.
>
> PS! I typically don't use my Cisco address for avr32 related kernel patches,
> but it seems to be my own fault, my global gitconfig contained my @cisco.com
> address. Fixed now.
>
Thank all of your work (also include another 2 patches).
And I guess, in the next month, I shall/can have more free time for
upstream open source, so I will/should finish avr32 allmodconfig within
next month (2014-03-31).
Thanks.
--
Chen Gang
Open, share and attitude like air, water and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the tip tree with Linus' tree
Around Tue 18 Feb 2014 14:09:20 +1100 or thereabout, Stephen Rothwell wrote:
Hello Stephen,
> Today's linux-next merge of the tip tree got a conflict in
> arch/avr32/include/asm/Kbuild between commit d7668f9d448a ("avr32: add
> generic vga.h to Kbuild") from the tree and commit b119fa61d440
> ("locking/mcs: Order the header files in Kbuild of each architecture in
> alphabetical order") from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Thank you for handling the merge.
PS! I typically don't use my Cisco address for avr32 related kernel patches,
but it seems to be my own fault, my global gitconfig contained my @cisco.com
address. Fixed now.
--
Best regards,
Hans-Christian Egtvedt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/avr32/include/asm/Kbuild between commit d7668f9d448a ("avr32: add
generic vga.h to Kbuild") from the tree and commit b119fa61d440
("locking/mcs: Order the header files in Kbuild of each architecture in
alphabetical order") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/avr32/include/asm/Kbuild
index c7c64a63c29f,8b398ff96974..
--- a/arch/avr32/include/asm/Kbuild
+++ b/arch/avr32/include/asm/Kbuild
@@@ -1,22 -1,22 +1,23 @@@
- generic-y += clkdev.h
- generic-y += cputime.h
- generic-y += delay.h
- generic-y += device.h
- generic-y += div64.h
- generic-y += emergency-restart.h
- generic-y += exec.h
- generic-y += futex.h
- generic-y += preempt.h
- generic-y += irq_regs.h
- generic-y += param.h
- generic-y += local.h
- generic-y += local64.h
- generic-y += percpu.h
- generic-y += scatterlist.h
- generic-y += sections.h
- generic-y += topology.h
- generic-y += trace_clock.h
+ generic-y += clkdev.h
+ generic-y += cputime.h
+ generic-y += delay.h
+ generic-y += device.h
+ generic-y += div64.h
+ generic-y += emergency-restart.h
+ generic-y += exec.h
+ generic-y += futex.h
+ generic-y += hash.h
+ generic-y += irq_regs.h
+ generic-y += local.h
+ generic-y += local64.h
+ generic-y += mcs_spinlock.h
+ generic-y += param.h
+ generic-y += percpu.h
+ generic-y += preempt.h
+ generic-y += scatterlist.h
+ generic-y += sections.h
+ generic-y += topology.h
+ generic-y += trace_clock.h
+generic-y += vga.h
- generic-y += xor.h
- generic-y += hash.h
+ generic-y += xor.h
pgpJPXu4g1IYQ.pgp
Description: PGP signature
Re: linux-next: manual merge of the tip tree with Linus' tree
On Thu, Jan 30, 2014 at 12:58:35PM +1100, Stephen Rothwell wrote:
> Hi Andi,
>
> On Wed, 29 Jan 2014 17:49:14 -0800 Andi Kleen wrote:
> >
> > > I fixed it up (see below) and can carry the fix as necessary (no action
> > > is required).
> >
> > I don't think the fix is correct, both sysctls need to be kept. They
> > do different things.
>
> The tip tree commit 52bf84aa206c ("sched/numa,mm: Remove
> p->numa_migrate_deferred") explicitly removed the
> numa_balancing_migrate_deferred sysctl.
Okay, sorry for the noise then.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the tip tree with Linus' tree
Hi Andi,
On Wed, 29 Jan 2014 17:49:14 -0800 Andi Kleen wrote:
>
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
>
> I don't think the fix is correct, both sysctls need to be kept. They
> do different things.
The tip tree commit 52bf84aa206c ("sched/numa,mm: Remove
p->numa_migrate_deferred") explicitly removed the
numa_balancing_migrate_deferred sysctl.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpOpqDm_OUlR.pgp
Description: PGP signature
Re: linux-next: manual merge of the tip tree with Linus' tree
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
I don't think the fix is correct, both sysctls need to be kept. They
do different things.
-Andi
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc kernel/sysctl.c
> index 096db7452cbd,2a4a4fc89cd1..
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@@ -383,22 -386,6 +385,15 @@@ static struct ctl_table kern_table[] =
> .mode = 0644,
> .proc_handler = proc_dointvec,
> },
> +{
> - .procname = "numa_balancing_migrate_deferred",
> - .data = &sysctl_numa_balancing_migrate_deferred,
> - .maxlen = sizeof(unsigned int),
> - .mode = 0644,
> - .proc_handler = proc_dointvec,
> - },
> - {
> +.procname = "numa_balancing",
> +.data = NULL, /* filled in by handler */
> +.maxlen = sizeof(unsigned int),
> +.mode = 0644,
> +.proc_handler = sysctl_numa_balancing,
> +.extra1 = &zero,
> +.extra2 = &one,
> +},
> #endif /* CONFIG_NUMA_BALANCING */
> #endif /* CONFIG_SCHED_DEBUG */
> {
--
a...@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
kernel/sysctl.c between commit 54a43d54988a ("numa: add a sysctl for
numa_balancing") from Linus' tree and commit 52bf84aa206c ("sched/numa,
mm: Remove p->numa_migrate_deferred") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc kernel/sysctl.c
index 096db7452cbd,2a4a4fc89cd1..
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@@ -383,22 -386,6 +385,15 @@@ static struct ctl_table kern_table[] =
.mode = 0644,
.proc_handler = proc_dointvec,
},
+ {
- .procname = "numa_balancing_migrate_deferred",
- .data = &sysctl_numa_balancing_migrate_deferred,
- .maxlen = sizeof(unsigned int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
+ .procname = "numa_balancing",
+ .data = NULL, /* filled in by handler */
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = sysctl_numa_balancing,
+ .extra1 = &zero,
+ .extra2 = &one,
+ },
#endif /* CONFIG_NUMA_BALANCING */
#endif /* CONFIG_SCHED_DEBUG */
{
pgpr9mIN2YDgh.pgp
Description: PGP signature
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
Documentation/sysctl/kernel.txt between commit 7984754b99b6 ("kexec: add
sysctl to disable kexec_load") from Linus' tree and commit 270750dbc18a
("hung_task: Display every hung task warning") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc Documentation/sysctl/kernel.txt
index ee9a2f983b99,4205f3c05cbe..
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@@ -33,7 -33,10 +33,11 @@@ show up in /proc/sys/kernel
- domainname
- hostname
- hotplug
+ - hung_task_panic
+ - hung_task_check_count
+ - hung_task_timeout_secs
+ - hung_task_warnings
+- kexec_load_disabled
- kptr_restrict
- kstack_depth_to_print [ X86 only ]
- l2cr[ PPC only ]
@@@ -288,18 -291,44 +292,56 @@@ Default value is "/sbin/hotplug"
==
+ hung_task_panic:
+
+ Controls the kernel's behavior when a hung task is detected.
+ This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
+
+ 0: continue operation. This is the default behavior.
+
+ 1: panic immediately.
+
+ ==
+
+ hung_task_check_count:
+
+ The upper bound on the number of tasks that are checked.
+ This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
+
+ ==
+
+ hung_task_timeout_secs:
+
+ Check interval. When a task in D state did not get scheduled
+ for more than this value report a warning.
+ This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
+
+ 0: means infinite timeout - no checking done.
+
+ ==
+
+ hung_task_warning:
+
+ The maximum number of warnings to report. During a check interval
+ When this value is reached, no more the warnings will be reported.
+ This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
+
+ -1: report an infinite number of warnings.
+
+ ==
+
+kexec_load_disabled:
+
+A toggle indicating if the kexec_load syscall has been disabled. This
+value defaults to 0 (false: kexec_load enabled), but can be set to 1
+(true: kexec_load disabled). Once true, kexec can no longer be used, and
+the toggle cannot be set back to false. This allows a kexec image to be
+loaded before disabling the syscall, allowing a system to set up (and
+later use) an image without it being altered. Generally used together
+with the "modules_disabled" sysctl.
+
+==
+
kptr_restrict:
This toggle indicates whether restrictions are placed on
pgpsLU2owuYpv.pgp
Description: PGP signature
Re: linux-next: manual merge of the tip tree with Linus' tree
Hi Stephen,
On Fri, Jan 17, 2014 at 02:30:35PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in
> drivers/clocksource/cadence_ttc_timer.c between commit c1dcc927dae0
> ("clocksource: cadence_ttc: Fix mutex taken inside interrupt context")
> from Linus' tree and commit dfded00902d7 ("clocksource:
> cadence_ttc_timer: Switch to sched_clock_register()") from the tip tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).
The fix is correct.
Thanks,
Sören
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
drivers/clocksource/cadence_ttc_timer.c between commit c1dcc927dae0
("clocksource: cadence_ttc: Fix mutex taken inside interrupt context")
from Linus' tree and commit dfded00902d7 ("clocksource:
cadence_ttc_timer: Switch to sched_clock_register()") from the tip tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/clocksource/cadence_ttc_timer.c
index a92350b55d32,8c7382bf260c..
--- a/drivers/clocksource/cadence_ttc_timer.c
+++ b/drivers/clocksource/cadence_ttc_timer.c
@@@ -308,7 -306,8 +308,8 @@@ static void __init ttc_setup_clocksourc
}
ttc_sched_clock_val_reg = base + TTC_COUNT_VAL_OFFSET;
- setup_sched_clock(ttc_sched_clock_read, 16, ttccs->ttc.freq / PRESCALE);
+ sched_clock_register(ttc_sched_clock_read, 16,
- clk_get_rate(ttccs->ttc.clk) / PRESCALE);
++ ttccs->ttc.freq / PRESCALE);
}
static int ttc_rate_change_clockevent_cb(struct notifier_block *nb,
pgpehNCpOYmWJ.pgp
Description: PGP signature
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/x86/platform/efi/efi.c between commit 04bf9ba720fc ("x86, efi: Don't
use (U)EFI time services on 32 bit") from Linus' tree and commit
f4fccac05f7f ("x86/efi: Simplify EFI_DEBUG") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/platform/efi/efi.c
index cceb813044ef,f8ec4dafc74e..
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@@ -690,9 -692,13 +692,7 @@@ void __init efi_init(void
set_bit(EFI_MEMMAP, &x86_efi_facility);
- #if EFI_DEBUG
-#ifdef CONFIG_X86_32
- if (efi_is_native()) {
- x86_platform.get_wallclock = efi_get_time;
- x86_platform.set_wallclock = efi_set_rtc_mmss;
- }
-#endif
print_efi_memmap();
- #endif
}
void __init efi_late_init(void)
pgpnDDY3a5Ifl.pgp
Description: PGP signature
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/x86/include/asm/spinlock.h between commit bc08b449ee14 ("lockref:
implement lockless reference count updates using cmpxchg()") from Linus'
tree and commit 545ac13892ab ("x86, spinlock: Replace pv spinlocks with
pv ticketlocks") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/x86/include/asm/spinlock.h
index e0e6684,8963bfe..000
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@@ -34,11 -37,31 +37,36 @@@
# define UNLOCK_LOCK_PREFIX
#endif
+static __always_inline int arch_spin_value_unlocked(arch_spinlock_t lock)
+{
+ return lock.tickets.head == lock.tickets.tail;
+}
+
+ /* How long a lock should spin before we consider blocking */
+ #define SPIN_THRESHOLD(1 << 15)
+
+ extern struct static_key paravirt_ticketlocks_enabled;
+ static __always_inline bool static_key_false(struct static_key *key);
+
+ #ifdef CONFIG_PARAVIRT_SPINLOCKS
+
+ static inline void __ticket_enter_slowpath(arch_spinlock_t *lock)
+ {
+ set_bit(0, (volatile unsigned long *)&lock->tickets.tail);
+ }
+
+ #else /* !CONFIG_PARAVIRT_SPINLOCKS */
+ static __always_inline void __ticket_lock_spinning(arch_spinlock_t *lock,
+ __ticket_t ticket)
+ {
+ }
+ static inline void __ticket_unlock_kick(arch_spinlock_t *lock,
+ __ticket_t ticket)
+ {
+ }
+
+ #endif /* CONFIG_PARAVIRT_SPINLOCKS */
+
/*
* Ticket locks are conceptually two parts, one indicating the current head of
* the queue, and the other indicating the current tail. The lock is acquired
pgpIH71TunXTN.pgp
Description: PGP signature
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
kernel/irq/generic-chip.c between commit 1aa0dd94ca07 ("irqdomain:
Eliminate revmap type") from Linus' tree and commit 002fca5df168
("genirq: generic chip: Use DIV_ROUND_UP to calculate numchips") from the
tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc kernel/irq/generic-chip.c
index 10e663a,2f274f3..000
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@@ -275,7 -275,10 +275,7 @@@ int irq_alloc_domain_generic_chips(stru
if (d->gc)
return -EBUSY;
- numchips = d->revmap_size / irqs_per_chip;
- if (d->revmap_type != IRQ_DOMAIN_MAP_LINEAR)
- return -EINVAL;
-
- numchips = DIV_ROUND_UP(d->revmap_data.linear.size, irqs_per_chip);
++ numchips = DIV_ROUND_UP(d->revmap_size, irqs_per_chip);
if (!numchips)
return -EINVAL;
pgp6McMrFph2Y.pgp
Description: PGP signature
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
tools/perf/Makefile between commit d2709c7ce4c5 ("perf: Make perf build
for x86 with UAPI disintegration applied") from Linus' tree and commit
945aea220bb8 ("perf tests: Move test objects into 'tests' directory")
from the tip tree.
I just used the version from Linus' tree (since it seems to be a superset
of the latter - see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc tools/perf/Makefile
index 0a619af,cca5bb8..000
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@@ -169,36 -169,16 +169,43 @@@ endi
### --- END CONFIGURATION SECTION ---
-BASIC_CFLAGS = -Iutil/include -Iarch/$(ARCH)/include -I$(OUTPUT)util -Iutil
-I. -I$(TRACE_EVENT_DIR) -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-D_GNU_SOURCE
+ifeq ($(srctree),)
+srctree := $(patsubst %/,%,$(dir $(shell pwd)))
+srctree := $(patsubst %/,%,$(dir $(srctree)))
+#$(info Determined 'srctree' to be $(srctree))
+endif
+
+ifneq ($(objtree),)
+#$(info Determined 'objtree' to be $(objtree))
+endif
+
+ifneq ($(OUTPUT),)
+#$(info Determined 'OUTPUT' to be $(OUTPUT))
+endif
+
+BASIC_CFLAGS = \
+ -Iutil/include \
+ -Iarch/$(ARCH)/include \
+ $(if $(objtree),-I$(objtree)/arch/$(ARCH)/include/generated/uapi) \
+ -I$(srctree)/arch/$(ARCH)/include/uapi \
+ -I$(srctree)/arch/$(ARCH)/include \
+ $(if $(objtree),-I$(objtree)/include/generated/uapi) \
+ -I$(srctree)/include/uapi \
+ -I$(srctree)/include \
+ -I$(OUTPUT)util \
+ -Iutil \
+ -I. \
+ -I$(TRACE_EVENT_DIR) \
+ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
BASIC_LDFLAGS =
+ ifeq ($(call try-cc,$(SOURCE_BIONIC),$(CFLAGS),bionic),y)
+ BIONIC := 1
+ EXTLIBS := $(filter-out -lrt,$(EXTLIBS))
+ EXTLIBS := $(filter-out -lpthread,$(EXTLIBS))
+ BASIC_CFLAGS += -I.
+ endif
+
# Guard against environment variables
BUILTIN_OBJS =
LIB_H =
pgpbBKRNixEIT.pgp
Description: PGP signature
Re: linux-next: manual merge of the tip tree with Linus' tree
* Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in
> mm/huge_memory.c between commit 325adeb55e32 ("mm: huge_memory: Fix build
> error") from Linus' tree and commit 39d6cb39a817 ("mm/mpol: Use special
> PROT_NONE to migrate pages") from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Ok, this conflict should go away the next time you integrate
linux-next.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
mm/huge_memory.c between commit 325adeb55e32 ("mm: huge_memory: Fix build
error") from Linus' tree and commit 39d6cb39a817 ("mm/mpol: Use special
PROT_NONE to migrate pages") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
diff --cc mm/huge_memory.c
index 40f17c3,d14c8b2..000
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@@ -17,7 -17,7 +17,8 @@@
#include
#include
#include
+#include
+ #include
#include
#include
#include "internal.h"
@@@ -1347,59 -1428,55 +1418,54 @@@ static int __split_huge_page_map(struc
spin_lock(&mm->page_table_lock);
pmd = page_check_address_pmd(page, mm, address,
PAGE_CHECK_ADDRESS_PMD_SPLITTING_FLAG);
- if (pmd) {
- pgtable = pgtable_trans_huge_withdraw(mm);
- pmd_populate(mm, &_pmd, pgtable);
-
- haddr = address;
- for (i = 0; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
- pte_t *pte, entry;
- BUG_ON(PageCompound(page+i));
- entry = mk_pte(page + i, vma->vm_page_prot);
- entry = maybe_mkwrite(pte_mkdirty(entry), vma);
- if (!pmd_write(*pmd))
- entry = pte_wrprotect(entry);
- else
- BUG_ON(page_mapcount(page) != 1);
- if (!pmd_young(*pmd))
- entry = pte_mkold(entry);
- pte = pte_offset_map(&_pmd, haddr);
- BUG_ON(!pte_none(*pte));
- set_pte_at(mm, haddr, pte, entry);
- pte_unmap(pte);
- }
+ if (!pmd)
+ goto unlock;
- smp_wmb(); /* make pte visible before pmd */
- /*
-* Up to this point the pmd is present and huge and
-* userland has the whole access to the hugepage
-* during the split (which happens in place). If we
-* overwrite the pmd with the not-huge version
-* pointing to the pte here (which of course we could
-* if all CPUs were bug free), userland could trigger
-* a small page size TLB miss on the small sized TLB
-* while the hugepage TLB entry is still established
-* in the huge TLB. Some CPU doesn't like that. See
-* http://support.amd.com/us/Processor_TechDocs/41322.pdf,
-* Erratum 383 on page 93. Intel should be safe but is
-* also warns that it's only safe if the permission
-* and cache attributes of the two entries loaded in
-* the two TLB is identical (which should be the case
-* here). But it is generally safer to never allow
-* small and huge TLB entries for the same virtual
-* address to be loaded simultaneously. So instead of
-* doing "pmd_populate(); flush_tlb_range();" we first
-* mark the current pmd notpresent (atomically because
-* here the pmd_trans_huge and pmd_trans_splitting
-* must remain set at all times on the pmd until the
-* split is complete for this pmd), then we flush the
-* SMP TLB and finally we write the non-huge version
-* of the pmd entry with pmd_populate.
-*/
- pmdp_invalidate(vma, address, pmd);
- pmd_populate(mm, pmd, pgtable);
- ret = 1;
+ prot = pmd_pgprot(*pmd);
- pgtable = get_pmd_huge_pte(mm);
++ pgtable = pgtable_trans_huge_withdraw(mm);
+ pmd_populate(mm, &_pmd, pgtable);
+
+ for (i = 0, haddr = address; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE)
{
+ pte_t *pte, entry;
+
+ BUG_ON(PageCompound(page+i));
+ entry = mk_pte(page + i, prot);
+ entry = pte_mkdirty(entry);
+ if (!pmd_young(*pmd))
+ entry = pte_mkold(entry);
+ pte = pte_offset_map(&_pmd, haddr);
+ BUG_ON(!pte_none(*pte));
+ set_pte_at(mm, haddr, pte, entry);
+ pte_unmap(pte);
}
+
+ smp_wmb(); /* make ptes visible before pmd, see __pte_alloc */
+ /*
+* Up to this point the pmd is present and huge.
+*
+* If we overwrite the pmd with the not-huge version, we could trigger
+* a small page size TLB miss on the small sized TLB while the hugepage
+* TLB entry is still established in the huge TLB.
+*
+* Some CPUs don't like that. See
+* http://support.amd.com/us/Processor_TechDocs/41322.pdf, Erratum 383
+* on page 93.
+*
+
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
include/linux/mempolicy.h between commit 607ca46e97a1 ("UAPI: (Scripted)
Disintegrate include/linux") from Linus' tree and commits 6f98f92971e9
("mm/mpol: Make MPOL_LOCAL a real policy"), 84e3a981648d ("mm/mpol: Add
MPOL_MF_LAZY ..."), 0719b9688bfe ("mm/mpol: Add MPOL_MF_NOOP"),
4d58c795f691 ("mm/mpol: Check for misplaced page") and fa74ef9e42df
("sched/numa: Implement per task memory placement for 'big' processes")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
I also added this merge fix patch:
From: Stephen Rothwell
Date: Mon, 15 Oct 2012 11:14:21 +1100
Subject: [PATCH] mm/pol: fixups for UAPI include files split
Signed-off-by: Stephen Rothwell
---
include/uapi/linux/mempolicy.h | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/mempolicy.h b/include/uapi/linux/mempolicy.h
index 23e62e0..0c774c6 100644
--- a/include/uapi/linux/mempolicy.h
+++ b/include/uapi/linux/mempolicy.h
@@ -20,6 +20,8 @@ enum {
MPOL_PREFERRED,
MPOL_BIND,
MPOL_INTERLEAVE,
+ MPOL_LOCAL,
+ MPOL_NOOP, /* retain existing policy for range */
MPOL_MAX, /* always last member of enum */
};
@@ -47,9 +49,16 @@ enum mpol_rebind_step {
/* Flags for mbind */
#define MPOL_MF_STRICT (1<<0) /* Verify existing pages in the mapping */
-#define MPOL_MF_MOVE (1<<1) /* Move pages owned by this process to conform
to mapping */
-#define MPOL_MF_MOVE_ALL (1<<2)/* Move every page to conform to
mapping */
-#define MPOL_MF_INTERNAL (1<<3)/* Internal flags start here */
+#define MPOL_MF_MOVE(1<<1) /* Move pages owned by this process to conform
+ to policy */
+#define MPOL_MF_MOVE_ALL (1<<2)/* Move every page to conform to policy
*/
+#define MPOL_MF_LAZY(1<<3) /* Modifies '_MOVE: lazy migrate on fault */
+#define MPOL_MF_INTERNAL (1<<4)/* Internal flags start here */
+
+#define MPOL_MF_VALID (MPOL_MF_STRICT | \
+MPOL_MF_MOVE | \
+MPOL_MF_MOVE_ALL | \
+MPOL_MF_LAZY)
/*
* Internal flags that share the struct mempolicy flags word with
@@ -59,6 +68,7 @@ enum mpol_rebind_step {
#define MPOL_F_SHARED (1 << 0)/* identify shared policies */
#define MPOL_F_LOCAL (1 << 1)/* preferred local allocation */
#define MPOL_F_REBINDING (1 << 2) /* identify policies in rebinding */
-
+#define MPOL_F_MOF (1 << 3) /* this policy wants migrate on fault */
+#define MPOL_F_HOME(1 << 4) /* this is the home-node policy */
#endif /* _UAPI_LINUX_MEMPOLICY_H */
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/linux/mempolicy.h
index e5ccb9d,67c9734..000
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@@ -2,10 -7,72 +2,9 @@@
* NUMA memory policies for Linux.
* Copyright 2003,2004 Andi Kleen SuSE Labs
*/
-
-/*
- * Both the MPOL_* mempolicy mode and the MPOL_F_* optional mode flags are
- * passed by the user to either set_mempolicy() or mbind() in an 'int' actual.
- * The MPOL_MODE_FLAGS macro determines the legal set of optional mode flags.
- */
-
-/* Policies */
-enum {
- MPOL_DEFAULT,
- MPOL_PREFERRED,
- MPOL_BIND,
- MPOL_INTERLEAVE,
- MPOL_LOCAL,
- MPOL_NOOP, /* retain existing policy for range */
- MPOL_MAX, /* always last member of enum */
-};
-
-enum mpol_rebind_step {
- MPOL_REBIND_ONCE, /* do rebind work at once(not by two step) */
- MPOL_REBIND_STEP1, /* first step(set all the newly nodes) */
- MPOL_REBIND_STEP2, /* second step(clean all the disallowed nodes)*/
- MPOL_REBIND_NSTEP,
-};
-
-/* Flags for set_mempolicy */
-#define MPOL_F_STATIC_NODES (1 << 15)
-#define MPOL_F_RELATIVE_NODES (1 << 14)
-
-/*
- * MPOL_MODE_FLAGS is the union of all possible optional mode flags passed to
- * either set_mempolicy() or mbind().
- */
-#define MPOL_MODE_FLAGS (MPOL_F_STATIC_NODES | MPOL_F_RELATIVE_NODES)
-
-/* Flags for get_mempolicy */
-#define MPOL_F_NODE (1<<0) /* return next IL mode instead of node mask */
-#define MPOL_F_ADDR (1<<1) /* look up vma using address */
-#define MPOL_F_MEMS_ALLOWED (1<<2) /* return allowed memories */
-
-/* Flags for mbind */
-#define MPOL_MF_STRICT(1<<0) /* Verify existing pages in the mapping
*/
-#define MPOL_MF_MOVE (1<<1) /* Move pages owned by this process to conform
- to policy */
-#define MPOL_MF_MOVE_ALL (1<<2) /* Move every page to conform to policy
*/
-#define MPOL_MF_LAZY (1<<3) /* Modifies '_MOVE: lazy migrate on fault */
-#define MPOL_MF_INTERNAL (1<<4) /* Internal flags start here */
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in mm/mempolicy.c
between commit 63f74ca21f1f ("mempolicy: fix refcount leak in
mpol_set_shared_policy()") from Linus' tree and commit 4d58c795f691
("mm/mpol: Check for misplaced page") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc mm/mempolicy.c
index 0b78fb9,3360a8d..000
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@@ -2170,12 -2168,116 +2203,122 @@@ mpol_shared_policy_lookup(struct shared
return pol;
}
+static void sp_free(struct sp_node *n)
+{
+ mpol_put(n->policy);
+ kmem_cache_free(sn_cache, n);
+}
+
+ /**
+ * mpol_misplaced - check whether current page node is valid in policy
+ *
+ * @page - page to be checked
+ * @vma- vm area where page mapped
+ * @addr - virtual address where page mapped
+ * @multi - use multi-stage node binding
+ *
+ * Lookup current policy node id for vma,addr and "compare to" page's
+ * node id.
+ *
+ * Returns:
+ *-1 - not misplaced, page is in the right node
+ *node- node id where the page should be
+ *
+ * Policy determination "mimics" alloc_page_vma().
+ * Called from fault path where we know the vma and faulting address.
+ */
+ int mpol_misplaced(struct page *page, struct vm_area_struct *vma,
+ unsigned long addr, int multi)
+ {
+ struct mempolicy *pol;
+ struct zone *zone;
+ int curnid = page_to_nid(page);
+ unsigned long pgoff;
+ int polnid = -1;
+ int ret = -1;
+
+ BUG_ON(!vma);
+
+ pol = get_vma_policy(current, vma, addr);
+ if (!(pol->flags & MPOL_F_MOF))
+ goto out;
+
+ switch (pol->mode) {
+ case MPOL_INTERLEAVE:
+ BUG_ON(addr >= vma->vm_end);
+ BUG_ON(addr < vma->vm_start);
+
+ pgoff = vma->vm_pgoff;
+ pgoff += (addr - vma->vm_start) >> PAGE_SHIFT;
+ polnid = offset_il_node(pol, vma, pgoff);
+ break;
+
+ case MPOL_PREFERRED:
+ if (pol->flags & MPOL_F_LOCAL)
+ polnid = numa_node_id();
+ else
+ polnid = pol->v.preferred_node;
+ break;
+
+ case MPOL_BIND:
+ /*
+* allows binding to multiple nodes.
+* use current page if in policy nodemask,
+* else select nearest allowed node, if any.
+* If no allowed nodes, use current [!misplaced].
+*/
+ if (node_isset(curnid, pol->v.nodes))
+ goto out;
+ (void)first_zones_zonelist(
+ node_zonelist(numa_node_id(), GFP_HIGHUSER),
+ gfp_zone(GFP_HIGHUSER),
+ &pol->v.nodes, &zone);
+ polnid = zone->node;
+ break;
+
+ default:
+ BUG();
+ }
+
+ /*
+* Multi-stage node selection is used in conjunction with a periodic
+* migration fault to build a temporal task<->page relation. By
+* using a two-stage filter we remove short/unlikely relations.
+*
+* Using P(p) ~ n_p / n_t as per frequentist probability, we can
+* equate a task's usage of a particular page (n_p) per total usage
+* of this page (n_t) (in a given time-span) to a probability.
+*
+* Our periodic faults will then sample this probability and getting
+* the same result twice in a row, given these samples are fully
+* independent, is then given by P(n)^2, provided our sample period
+* is sufficiently short compared to the usage pattern.
+*
+* This quadric squishes small probabilities, making it less likely
+* we act on an unlikely task<->page relation.
+*
+* NOTE: effectively we're using task-home-node<->page-node relations
+* since those are the only thing we can affect.
+*
+* NOTE: we're using task-home-node as opposed to the current node
+* the task might be running on, since the task-home-node is the
+* long-term node of this task, further reducing noise. Also see
+* task_tick_numa().
+*/
+ if (multi && (pol->flags & MPOL_F_HOME)) {
+ int last_nid = page_xchg_last_nid(page, polnid);
+ if (last_nid != polnid)
+ goto out;
+ }
+
+ if (curnid != polnid)
+ ret = polnid;
+ out:
+ mpol_cond_put(pol);
+
+ return ret;
+ }
+
static void sp_delete(struct shared_policy *sp, struct sp_node *n)
{
pr_debug("deleting %lx-l%lx\n", n->start, n->end);
pgpVglgEmApPz.pgp
Description: PGP signature
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
mm/huge_memory.c between commits d516904bd239 ("thp: merge page pre-alloc
in khugepaged_loop into khugepaged_do_scan"), e3ebcf643811 ("thp: remove
assumptions on pgtable_t type") and 46dcde735c9d ("thp: introduce
pmdp_invalidate()") from Linus' tree and commit 93c9d633bd9e ("mm/thp:
Preserve pgprot across huge page split") from the tip tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc mm/huge_memory.c
index a863af2,5b9ab25..000
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@@ -1346,59 -1428,55 +1417,54 @@@ static int __split_huge_page_map(struc
spin_lock(&mm->page_table_lock);
pmd = page_check_address_pmd(page, mm, address,
PAGE_CHECK_ADDRESS_PMD_SPLITTING_FLAG);
- if (pmd) {
- pgtable = pgtable_trans_huge_withdraw(mm);
- pmd_populate(mm, &_pmd, pgtable);
-
- haddr = address;
- for (i = 0; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
- pte_t *pte, entry;
- BUG_ON(PageCompound(page+i));
- entry = mk_pte(page + i, vma->vm_page_prot);
- entry = maybe_mkwrite(pte_mkdirty(entry), vma);
- if (!pmd_write(*pmd))
- entry = pte_wrprotect(entry);
- else
- BUG_ON(page_mapcount(page) != 1);
- if (!pmd_young(*pmd))
- entry = pte_mkold(entry);
- pte = pte_offset_map(&_pmd, haddr);
- BUG_ON(!pte_none(*pte));
- set_pte_at(mm, haddr, pte, entry);
- pte_unmap(pte);
- }
+ if (!pmd)
+ goto unlock;
- smp_wmb(); /* make pte visible before pmd */
- /*
-* Up to this point the pmd is present and huge and
-* userland has the whole access to the hugepage
-* during the split (which happens in place). If we
-* overwrite the pmd with the not-huge version
-* pointing to the pte here (which of course we could
-* if all CPUs were bug free), userland could trigger
-* a small page size TLB miss on the small sized TLB
-* while the hugepage TLB entry is still established
-* in the huge TLB. Some CPU doesn't like that. See
-* http://support.amd.com/us/Processor_TechDocs/41322.pdf,
-* Erratum 383 on page 93. Intel should be safe but is
-* also warns that it's only safe if the permission
-* and cache attributes of the two entries loaded in
-* the two TLB is identical (which should be the case
-* here). But it is generally safer to never allow
-* small and huge TLB entries for the same virtual
-* address to be loaded simultaneously. So instead of
-* doing "pmd_populate(); flush_tlb_range();" we first
-* mark the current pmd notpresent (atomically because
-* here the pmd_trans_huge and pmd_trans_splitting
-* must remain set at all times on the pmd until the
-* split is complete for this pmd), then we flush the
-* SMP TLB and finally we write the non-huge version
-* of the pmd entry with pmd_populate.
-*/
- pmdp_invalidate(vma, address, pmd);
- pmd_populate(mm, pmd, pgtable);
- ret = 1;
+ prot = pmd_pgprot(*pmd);
- pgtable = get_pmd_huge_pte(mm);
++ pgtable = pgtable_trans_huge_withdraw(mm);
+ pmd_populate(mm, &_pmd, pgtable);
+
+ for (i = 0, haddr = address; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE)
{
+ pte_t *pte, entry;
+
+ BUG_ON(PageCompound(page+i));
+ entry = mk_pte(page + i, prot);
+ entry = pte_mkdirty(entry);
+ if (!pmd_young(*pmd))
+ entry = pte_mkold(entry);
+ pte = pte_offset_map(&_pmd, haddr);
+ BUG_ON(!pte_none(*pte));
+ set_pte_at(mm, haddr, pte, entry);
+ pte_unmap(pte);
}
+
+ smp_wmb(); /* make ptes visible before pmd, see __pte_alloc */
+ /*
+* Up to this point the pmd is present and huge.
+*
+* If we overwrite the pmd with the not-huge version, we could trigger
+* a small page size TLB miss on the small sized TLB while the hugepage
+* TLB entry is still established in the huge TLB.
+*
+* Some CPUs don't like that. See
+* http://
