[PATCH] compiler.h, tracing: Remove CONFIG_PROFILE_ALL_BRANCHES

HES=y feature is required for anyone it can still be reverted privately or maintained out of tree - no need to burden the mainline kernel with this. I've build tested this and it Looks Perfect Here™. Thanks, Ingo => >From 3f689ed8a1555a

Re: [PATCH V3 0/9] x86/jump_label: Bound IPIs sent when updating a static key

* Daniel Bristot de Oliveira wrote: > Considering that, in this test case, we are saving the handling of 53 IPIs, > that takes more than these 135 ns, it seems to be a meager price to be paid. > Moreover, the test case was forcing the hit of the int3, in practice, it > does not take that

Re: [PATCH v5 00/18] locking/rwsem: Rwsem rearchitecture part 2

* Ingo Molnar wrote: > > * Waiman Long wrote: > > > On 04/18/2019 07:46 PM, Waiman Long wrote: > > > v5: > > > - Drop v4 patch 1 as it is merged into tip's locking/core branch. > > > - Integrate the 2 followup patches into the series. The

Re: [GIT PULL 0/7] perf/urgent fixes

* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit b24131eb77429f7ac52d5ab5a4313fccff64c411: > > Merge tag 'perf-urgent-for-mingo-5.1-20190416' of >

Re: [PATCH v2 -next] sched/core: Make some functions static

* Yue Haibing wrote: > From: YueHaibing > > Fix sparse warnings: > > kernel/sched/core.c:6524:11: warning: symbol 'min_cfs_quota_period' was not > declared. Should it be static? > kernel/sched/core.c:6604:5: warning: symbol 'tg_set_cfs_quota' was not > declared. Should it be static? >

Re: [tip:sched/core] sched/core: Make some functions static

* tip-bot for YueHaibing wrote: > Commit-ID: 16e671afb70f28eb189136d1395c59dafecd270a > Gitweb: > https://git.kernel.org/tip/16e671afb70f28eb189136d1395c59dafecd270a > Author: YueHaibing > AuthorDate: Fri, 22 Mar 2019 22:31:53 +0800 > Committer: Ingo Molnar >

Re: [GIT PULL rcu/next + tools/memory-model] RCU and LKMM commits for 5.2

* Paul E. McKenney wrote: > Hello, Ingo, > > This pull request contains the following changes: > > 1.An LKMM commit adding support for synchronize_srcu_expedited(). > > http://lkml.kernel.org/r/20190326234133.24962-8-paul...@linux.ibm.com > > 2.A couple of straggling RCU

Re: [PATCH] x86/boot: This program cannot be run in DOS mode.$

* Pavel Machek wrote: > On Mon 2019-04-08 20:08:09, Pali Rohár wrote: > > On Monday 08 April 2019 20:04:22 Pavel Machek wrote: > > > On Mon 2019-04-01 12:24:34, Pali Rohár wrote: > > > > Every EFI binary is in PE format. And we know that PE format needs to > > > > have > > > > MZ MS-DOS

Re: [PATCH-tip 0/2] locking/rwsem: Rwsem rearchitecture part 2 follow-up patches

* Waiman Long wrote: > As the part2 patches are still being actively modified, it doesn't look > like it will make the next merge window. I am fine with postponing it > to 5.3. However, I would like to request the merging of just patch 1 of > the part 2 patchset. It fixes a locking selftest

Re: [PATCH V2 0/3] Introduce Thermal Pressure

* Thara Gopinath wrote: > > On 04/17/2019 01:36 AM, Ingo Molnar wrote: > > > > * Thara Gopinath wrote: > > > >> The test results below shows 3-5% improvement in performance when > >> using the third solution compared to the default system t

Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall

* Theodore Ts'o wrote: > It seems though the assumption that we're assuming the attacker has > arbitrary ability to get the low bits of the stack, so *if* that's > true, then eventually, you'd be able to get enough samples that you > could reverse engineer the prandom state. This could

Re: [tip:perf/core] perf/x86/intel: Force resched when TFA sysctl is modified

an > > AuthorDate: Mon, 8 Apr 2019 10:32:52 -0700 > > Committer: Ingo Molnar > > CommitDate: Tue, 16 Apr 2019 12:19:35 +0200 > > > > perf/x86/intel: Force resched when TFA sysctl is modified > > What's TFA? Tuna-fish-alarm? Heh, I wish! :-) > [...] Nowhere

Re: [PATCH v2] x86/PCI: fix a memory leak bug

* Wenwen Wang wrote: > On Tue, Apr 16, 2019 at 3:33 PM Thomas Gleixner wrote: > > > > On Tue, 16 Apr 2019, Wenwen Wang wrote: > > > > > In pcibios_irq_init(), the PCI IRQ routing table 'pirq_table' is firstly > > > found through pirq_find_routing_table(). If the table is not found and > > >

Re: [PATCH-tip 0/2] locking/rwsem: Rwsem rearchitecture part 2 follow-up patches

* Waiman Long wrote: > On 04/16/2019 01:37 PM, Peter Zijlstra wrote: > > On Tue, Apr 16, 2019 at 01:03:10PM -0400, Waiman Long wrote: > >> On 04/16/2019 10:17 AM, Peter Zijlstra wrote: > >>> On Tue, Apr 16, 2019 at 09:18:50AM -0400, Waiman Long wrote: > On 04/16/2019 09:10 AM, Peter

Re: [PATCH V2 0/3] Introduce Thermal Pressure

* Ingo Molnar wrote: > * Thara Gopinath wrote: > > > The test results below shows 3-5% improvement in performance when > > using the third solution compared to the default system today where > > scheduler is unware of cpu capacity limitations due to thermal events. &g

Re: [PATCH V2 0/3] Introduce Thermal Pressure

* Thara Gopinath wrote: > The test results below shows 3-5% improvement in performance when > using the third solution compared to the default system today where > scheduler is unware of cpu capacity limitations due to thermal events. The numbers look very promising! I've rearranged the

Re: [PATCH-tip v3 02/14] locking/rwsem: Make owner available even if !CONFIG_RWSEM_SPIN_ON_OWNER

* Waiman Long wrote: > > It can be seen that a lot more readers got the lock via optimistic > > spinning.  One possibility is that reader optimistic spinning causes > > readers to spread out into more lock acquisition groups than without. The > > K3 results show that grouping more readers into

Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall

* Reshetova, Elena wrote: > > 4) > > > > But before you tweak the patch, a more fundamental question: > > > > Does the stack offset have to be per *syscall execution* randomized? > > Which threats does this protect against that a simpler per task syscall > > random offset wouldn't protect

Re: [PATCH 1/1] x86/entry/64: randomize kernel stack offset upon syscall

* Andy Lutomirski wrote: > On Wed, Apr 10, 2019 at 4:43 AM Ingo Molnar wrote: > > > > > > * Elena Reshetova wrote: > > > > > 2) Andy's tests, misc-tests: ./timing_test_64 10M sys_enosys > > > base:10

Re: [PATCH] x86/PCI: fix a memory leak bug

; if (pirq_table) { > pirq_peer_trick(); > @@ -1145,8 +1149,10 @@ void __init pcibios_irq_init(void) >* If we're using the I/O APIC, avoid using the PCI IRQ >* routing table >*/ > - if (io_apic_assign_pci

Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall

* Elena Reshetova wrote: > This is an example of produced assembly code for gcc x86_64: > > ... > add_random_stack_offset(); > 0x810022e9 callq 0x81459570 > 0x810022ee movzbl %al,%eax > 0x810022f1 add$0x16,%rax > 0x810022f5 and$0x1f8,%eax >

Re: [PATCH] locking/lockdep: Make lockdep_register_key() ignore 'debug_locks'

* Bart Van Assche wrote: > On Fri, 2019-04-12 at 07:47 +0200, Ingo Molnar wrote: > > So why don't we add a debug_locks test to lockdep_unregister_key() > > instead? The general principle to bring lockdep to a screeching halt when > > bugs are detected, ASAP. >

Re: [PATCH-tip v3 02/14] locking/rwsem: Make owner available even if !CONFIG_RWSEM_SPIN_ON_OWNER

* Waiman Long wrote: > > BTW, the v3 patch that I posted yesterday should work fine as long as > > CONFIG_RWSEM_SPIN_ON_OWNER is defined. > > > > Cheers, > > Longman > > > Oh, I see that the WIP.locking/core is currently merged into master. I > would say rwsem part1 patchset and patch 1 of

Re: [GIT PULL 0/7] perf/urgent fixes

* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit 6d3edaae16c6c7d238360f2841212c2b26774d5e: > > x86/perf/amd: Resolve NMI latency issues for active

[GIT PULL] x86 fixes

Linus, Please pull the latest x86-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus # HEAD: 5b77e95dd7790ff6c8fbf1cd8d0104ebed818a03 x86/asm: Use stricter assembly constraints in bitops Fix typos in user-visible resctrl

[GIT PULL] timer fix

Linus, Please pull the latest timers-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-urgent-for-linus # HEAD: 07d7e12091f4ab869cc6a4bb276399057e73b0b3 alarmtimer: Return correct remaining time Fix the alarm_timer_remaining() return

[GIT PULL] scheduler fix

Linus, Please pull the latest sched-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched-urgent-for-linus # HEAD: 0e9f02450da07fc7b1346c8c32c771555173e397 sched/fair: Do not re-read ->h_load_next during hierarchical load calculation Fix a NULL

[GIT PULL] perf fixes

Linus, Please pull the latest perf-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-urgent-for-linus # HEAD: 1d54ad944074010609562da5c89e4f5df2f4e5db perf/core: Fix perf_event_disable_inatomic() race Six kernel side fixes: three related to

[GIT PULL] locking fix

Linus, Please pull the latest locking-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking-urgent-for-linus # HEAD: 90c1cba2b3b3851c151229f61801919b2904d437 locking/lockdep: Zap lock classes even with lock debugging disabled Fixes a crash

[GIT PULL] IRQ fixes

Linus, Please pull the latest irq-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-urgent-for-linus # HEAD: 325aa19598e410672175ed50982f902d4e3f31c5 genirq: Respect IRQCHIP_SKIP_SET_WAKE in irq_chip_set_wake_parent() Two genirq fixes, plus

[GIT PULL] core/urgent fixes

Linus, Please pull the latest core-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-urgent-for-linus # HEAD: 4fa5ecda2bf96be7464eb406df8aba9d89260227 objtool: Add rewind_stack_do_exit() to the noreturn list Fix an objtool warning plus fix a

Re: [PATCH-tip v3 02/14] locking/rwsem: Make owner available even if !CONFIG_RWSEM_SPIN_ON_OWNER

* Peter Zijlstra wrote: > On Fri, Apr 12, 2019 at 09:02:09AM +0200, Ingo Molnar wrote: > > > > * Waiman Long wrote: > > > > > On 04/11/2019 04:12 AM, Peter Zijlstra wrote: > > > > On Wed, Apr 10, 2019 at 02:42:19PM -0400, Waiman Long wrote: &g

Re: [PATCH-tip v3 02/14] locking/rwsem: Make owner available even if !CONFIG_RWSEM_SPIN_ON_OWNER

* Waiman Long wrote: > On 04/11/2019 04:12 AM, Peter Zijlstra wrote: > > On Wed, Apr 10, 2019 at 02:42:19PM -0400, Waiman Long wrote: > >> The owner field in the rw_semaphore structure is used primarily for > >> optimistic spinning. However, identifying the rwsem owner can also be > >> helpful

Re: [tip:perf/urgent] perf/core: Fix perf_event_disable_inatomic() race

er Zijlstra > > AuthorDate: Thu, 4 Apr 2019 15:03:00 +0200 > > Committer: Ingo Molnar > > CommitDate: Wed, 10 Apr 2019 13:47:09 +0200 > > > > perf/core: Fix perf_event_disable_inatomic() race > > > > Thomas-Mich Richter reported he triggered a WARN()in

Re: [PATCH] locking/lockdep: Make lockdep_register_key() ignore 'debug_locks'

* Bart Van Assche wrote: > If lockdep_register_key() and lockdep_unregister_key() are called with > debug_locks == false then the following warning is reported: > > WARNING: CPU: 2 PID: 15145 at kernel/locking/lockdep.c:4920 > lockdep_unregister_key+0x1ad/0x240 > > That warning is reported

Re: [PATCH v2 01/21] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section

es look good to me: Acked-by: Ingo Molnar Thanks, Ingo

Re: [PATCH 1/1] x86/entry/64: randomize kernel stack offset upon syscall

* Elena Reshetova wrote: > 2) Andy's tests, misc-tests: ./timing_test_64 10M sys_enosys > base:1000 loops in 1.62224s = > 162.22 nsec / loop > random_offset (prandom_u32() every syscall): 1000 loops in 1.64660s = > 166.26 nsec / loop

Re: [PATCH v2 01/21] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section

Mostly minor grammer fixes: * Will Deacon wrote: > + (*) readX(), writeX(): > > + The readX() and writeX() MMIO accessors take a pointer to the peripheral > + being accessed as an __iomem * parameter. For pointers mapped with the > + default I/O attributes (e.g. those returned

Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall

* Reshetova, Elena wrote: > > * Josh Poimboeuf wrote: > > > > > On Mon, Apr 08, 2019 at 09:13:58AM +0300, Elena Reshetova wrote: > > > > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c > > > > index 7bc105f47d21..38ddc213a5e9 100644 > > > > --- a/arch/x86/entry/common.c > > >

Re: [PATCH-tip v2 00/12] locking/rwsem: Rwsem rearchitecture part 2

* Waiman Long wrote: ># of Threads Before Patch After Patch > --- > 21,179 9,436 > 41,505 8,268 > 8 721 7,041 >16 575

Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall

* Josh Poimboeuf wrote: > On Mon, Apr 08, 2019 at 09:13:58AM +0300, Elena Reshetova wrote: > > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c > > index 7bc105f47d21..38ddc213a5e9 100644 > > --- a/arch/x86/entry/common.c > > +++ b/arch/x86/entry/common.c > > @@ -35,6 +35,12 @@ >

Re: [PATCH 2/2] x86/pci: Clean up usage of X86_DEV_DMA_OPS

(+Cc. Patch quoted below. Acked-by from an x86 perspective.) * Christoph Hellwig wrote: > We have supported per-device dma_map_ops in generic code for a long > time, and this symbol just guards the inclusion of the dma_map_ops > registry used for vmd. Stop enabling it for anything but vmd.

Re: [PATCH 08/10] x86-64: select DYNAMIC_DEBUG_RELATIVE_POINTERS

ig X86_64 > select SWIOTLB > select X86_DEV_DMA_OPS > select ARCH_HAS_SYSCALL_WRAPPER > + select DYNAMIC_DEBUG_RELATIVE_POINTERS Acked-by: Ingo Molnar Thanks, Ingo

Re: [PATCH v3 1/4] x86: kdump: move reserve_crashkernel_low() into kexec_core.c

* Chen Zhou wrote: > In preparation for supporting more than one crash kernel regions > in arm64 as x86_64 does, move reserve_crashkernel_low() into > kexec/kexec_core.c. > > Signed-off-by: Chen Zhou > --- > arch/x86/include/asm/kexec.h | 3 ++ > arch/x86/kernel/setup.c | 66 >

Re: [PATCH v2] x86/asm: fix assembly constraints in bitops

* Alexander Potapenko wrote: > On Fri, Apr 5, 2019 at 11:39 AM Ingo Molnar wrote: > > > > > > * Alexander Potapenko wrote: > > > > > 1. Use memory clobber in bitops that touch arbitrary memory > > > > > > Certain b

Re: [PATCH v2] x86/asm: fix assembly constraints in bitops

* Alexander Potapenko wrote: > 1. Use memory clobber in bitops that touch arbitrary memory > > Certain bit operations that read/write bits take a base pointer and an > arbitrarily large offset to address the bit relative to that base. > Inline assembly constraints aren't expressive enough to

Re: [PATCH 02/17] x86, lto: Mark all top level asm statements as .text

("start_", ops, name) \ > + code\ > + NATIVE_LABEL("end_", ops, name) \ > + ".popsection\n") Acked-by: Ingo Molnar Thanks, Ingo

Re: [GIT pull] scheduler updates for 5.1

* Linus Torvalds wrote: > On Sun, Mar 10, 2019 at 4:33 AM Thomas Gleixner wrote: > > > > A small set of fixes for the scheduler: > > What? No. > > This is completely broken, and even warns loudly about it. > > kernel/sched/cpufreq_schedutil.c: In function ‘sugov_iowait_boost’: >

Re: [GIT PULL 00/35] perf/core improvements and fixes

* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit c978b9460fe1d4a1e1effa0abd6bd69b18a098a8: > > Merge tag 'perf-core-for-mingo-5.1-20190225' of >

Re: [GIT PULL] x86/kdump changes for v5.1

* Linus Torvalds wrote: > On Thu, Mar 7, 2019 at 11:23 AM Ingo Molnar wrote: > > > > Please pull the latest x86-kdump-for-linus git tree from: > > Hmm. No diffstat? > > The branch is simple enough that I'll pull anyway, but I would have > wanted to see that

[GIT PULL] x86/uv changes for v5.1

Linus, Please pull the latest x86-uv-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-uv-for-linus # HEAD: 8945d96f7b3ead56e053ac79b8f7b0de98a30bfe x86/platform/UV: Use efi_enabled() instead of test_bit() Three UV related cleanups. Thanks,

[GIT PULL] x86/platform change for v5.1

Linus, Please pull the latest x86-platform-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-platform-for-linus # HEAD: 1c034a2fe56061af439c4e74f8f6c08e3714a730 x86/defconfig: Enable EFI stub, mixed mode and BGRT A defconfig update. Thanks,

[GIT PULL] x86/mm change for v5.1

Linus, Please pull the latest x86-mm-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-mm-for-linus # HEAD: ad8cfb9c42ef83ecf4079bc7d77e6557648e952b mm/gup: Remove the 'write' parameter from gup_fast_permitted() A single GUP cleanup. out-of-topic

[GIT PULL] x86/kdump changes for v5.1

Linus, Please pull the latest x86-kdump-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-kdump-for-linus # HEAD: f263245a0ce2c4e23b89a58fa5f7dfc048e11929 kdump: Document kernel data exported in the vmcoreinfo note Add the AMD SME mask to the

[GIT PULL] x86/fpu changes for v5.1

Linus, Please pull the latest x86-fpu-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-fpu-for-linus # HEAD: 2f7726f955572e587d5f50fbe9b2deed5334bd90 x86/fpu: Track AVX-512 usage of tasks Three changes: - There's a preparatory patches for AVX

[GIT PULL] x86/cleanups for v5.1

Linus, Please pull the latest x86-cleanups-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-cleanups-for-linus # HEAD: 2e7614c0736de93c8796bb2d58debb8871a59db8 x86/uaccess: Remove unused __addr_ok() macro Various cleanups and simplifications, none

[GIT PULL] x86/build changes for v5.1

Linus, Please pull the latest x86-build-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-build-for-linus # HEAD: ce02ef06fcf7a399a6276adb83f37373d10cbbe1 x86, retpolines: Raise limit for generating indirect calls from switch-case Misc cleanups and a

[GIT PULL] x86/boot changes for v5.1

Linus, Please pull the latest x86-boot-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-boot-for-linus # HEAD: 6f913de3231e1d70a871135b38219da7810df218 x86/boot/compressed/64: Do not read legacy ROM on EFI system Most of the changes center around

[GIT PULL] x86/alternatives changes for v5.1

Linus, Please pull the latest x86-alternatives-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-alternatives-for-linus # HEAD: 093ae8f9a86a974c920b613860f1f7fd5bbd70ab x86/TSC: Use RDTSCP Small RDTSCP opimization, enabled by the newly added

[GIT PULL] scheduler updates for v5.1

Linus, Please pull the latest sched-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched-core-for-linus # HEAD: ad01423aedaa7c6dd62d560b73a3cb39e6da3901 kthread: Do not use TIMER_IRQSAFE The main changes in this cycle were: - refcount

[GIT PULL] perf changes for v5.1

Linus, Please pull the latest perf-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-core-for-linus # HEAD: c978b9460fe1d4a1e1effa0abd6bd69b18a098a8 Merge tag 'perf-core-for-mingo-5.1-20190225' of

Re: [GIT PULL] RCU updates for v5.1

* Linus Torvalds wrote: > On Tue, Mar 5, 2019 at 4:03 AM Ingo Molnar wrote: > > > > Please pull the latest core-rcu-for-linus git tree from: > > > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > > core-rcu-for-linus > > Hmm. I think th

Re: [GIT PULL] EFI changes for v5.1

* Ard Biesheuvel wrote: > Hi ingo, > > On Tue, 5 Mar 2019 at 13:20, Ingo Molnar wrote: > > > > Linus, > > > > Please pull the latest efi-core-for-linus git tree from: > > > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.

[GIT PULL] locking changes for v5.1

(2): locking/lockdep: Simplify mark_held_locks() locking/lockdep: Provide enum lock_usage_bit mask names Greg Kroah-Hartman (1): futex: No need to check return value of debugfs_create functions Ingo Molnar (1): locking/atomics: Fix scripts/atomic/ script permissions Mark Rutl

timer updates for v5.1

+Subject line. * Thomas Gleixner wrote: > Linus, > > please pull the latest timers-core-for-linus git tree from: > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > timers-core-for-linus > > The time(r) core and clockevent updates are mostly boring this time: > > - A new

[GIT PULL] EFI changes for v5.1

ace GPL license boilerplate with SPDX headers efi/arm/arm64: Allow SetVirtualAddressMap() to be omitted x86: Make ARCH_USE_MEMREMAP_PROT a generic Kconfig symbol efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation Ingo Molnar (1): efi/fdt: Apply m

[GIT PULL] RCU updates for v5.1

Linus, Please pull the latest core-rcu-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-rcu-for-linus # HEAD: cae45e1c6c541283a1bd155aa7b0a57e353b4df4 Merge branch 'rcu-next' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into

Re: [GIT PULL] perf/core improvements and fixes

* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, this is on top of my previous pull > request, perf-core-for-mingo-5.1-20190220. > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit

Re: [GIT PULL 00/17] perf/core improvements and fixes

* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit 43f4e6279f05eefac058a3524e184cecae463bfe: > > Merge tag 'perf-core-for-mingo-5.1-20190214' of >

Re: [RFC GIT PULL] EFI fixes, memblock quirk

* Linus Torvalds wrote: > On Sun, Feb 17, 2019 at 2:59 AM Ingo Molnar wrote: > > > > I marked it RFC: please have a second look at the mm/memblock.c change, > > which adds a INIT_MEMBLOCK_RESERVED_REGIONS detour that ARM64 takes for > > these systems. > &

Re: [RFC][PATCH 00/16] sched: Core scheduling

* Linus Torvalds wrote: > On Mon, Feb 18, 2019 at 12:40 PM Peter Zijlstra wrote: > > > > If there were close to no VMEXITs, it beat smt=off, if there were lots > > of VMEXITs it was far far worse. Supposedly hosting people try their > > very bestest to have no VMEXITs so it mostly works for

[RFC GIT PULL] EFI fixes, memblock quirk

Linus, Please pull the latest efi-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-urgent-for-linus # HEAD: 582a32e708823e5957fd73ccd78dc4a9e49d21ea efi/arm: Revert "Defer persistent reservations until after paging_init()" This tree reverts

[GIT PULL] x86 fixes

Linus, Please pull the latest x86-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus # HEAD: f331e766c4be33f4338574f3c9f7f77e98ab4571 x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls Three changes: - An UV

[GIT PULL] perf fixes

an over-eager condition that failed larger perf ring-buffer sizes, plus fix crashes in the Intel BTS code for a corner case, found by fuzzing. Thanks, Ingo --> Ingo Molnar (1): perf/core: Fix impossible ring-buffer sizes warning Jiri Olsa (1): perf/x86:

Re: [PATCH v2] x86/tsc: Allow quick PIT calibration despite interruptions

[2.212732] tsc: Refined TSC clocksource calibration: 3599.931 MHz [2.218368] clocksource: tsc: mask: 0x max_cycles: 0x33e4128ece2, max_idle_ns: 440795387864 ns [ 2.261799] clocksource: Switched to clocksource tsc Tested-by: Ingo Molnar (Note that in the old log the printk

Re: [PATCH v2] x86/tsc: Allow quick PIT calibration despite interruptions

* Jan H. Schönherr wrote: > Some systems experience regular interruptions (60 Hz SMI?), that prevent > the quick PIT calibration from succeeding: individual interruptions can be > so long, that the PIT MSB is observed to decrement by 2 or 3 instead of 1. > The existing code cannot recover from

Re: [GIT PULL 00/43] perf/core improvements and fixes

* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit af63147c1edacfb75a28885a7cd7e6f44e626164: > > perf/x86/intel: Add counter freezing quirk for

Re: [PATCH v3 3/4] uaccess: Check no rescheduling function is called in unsafe region

* Julien Thierry wrote: > I guess I'll drop the might_resched() part of this patch if that sounds > alright. That sounds perfect - that bit was pretty much the only problem I had with the series. Thanks, Ingo

Re: [PATCH v3 10/10] x86/split_lock: Handle #AC exception for split lock

* Fenghua Yu wrote: > On Mon, Feb 11, 2019 at 11:53:39AM +0100, Ingo Molnar wrote: > > > + do_trap(trapnr, signr, str, regs, error_code, BUS_ADRALN, NULL); > > > + } > > > +} > > > > Is there any experience with how frequently this s

Re: [PATCH] Documentation/atomic_t: Clarify signed vs unsigned

to read that twice. Acronyms Seriously Suck. > + > +There was a bug in UBSAN prior to GCC-8 that would generate UB warnings for > +signed types. > + > +With this we also conform to the C/C++ _Atomic behaviour and things like > +P1236R1. Acked-by: Ingo Molnar Thanks, Ingo

Re: [PATCH v2 2/2] locking/rwsem: Optimize down_read_trylock()

* Waiman Long wrote: > I looked at the assembly code in arch/x86/include/asm/rwsem.h. For both > trylocks (read & write), the count is read first before attempting to > lock it. We did the same for all trylock functions in other locks. > Depending on how the trylock is used and how contended

Re: [GIT PULL rcu/next] RCU commits for 5.1

* Paul E. McKenney wrote: > Hello, Ingo, > > This pull request contains the following changes: > > 1.Additional cleanups after RCU flavor consolidation. > > http://lkml.kernel.org/r/20190109211830.ga30...@linux.ibm.com > > 2.Grace-period forward-progress cleanups and

Re: [PATCH -tip v3 05/10] kprobes: Search non-suffixed symbol in blacklist

* Ingo Molnar wrote: > > * Masami Hiramatsu wrote: > > > Newer gcc can generate some different instances of a function > > with suffixed symbols if the function is optimized and only > > has a part of that. (e.g. .constprop, .part etc.) > > > >

Re: [PATCH -tip v3 05/10] kprobes: Search non-suffixed symbol in blacklist

* Masami Hiramatsu wrote: > Newer gcc can generate some different instances of a function > with suffixed symbols if the function is optimized and only > has a part of that. (e.g. .constprop, .part etc.) > > In this case, it is not enough to check the entry of kprobe > blacklist because it

Re: [PATCH v2 0/9] kprobes: Fix and improve blacklist symbols

* Masami Hiramatsu wrote: > Hi Ingo, > > Can I ask you to pick this series and Andrea's patch? > Or would I better update this series on the latest tip/master? Yeah, an updated series with Andrea's patch included, against latest -tip, would be nice. Thanks! Ingo

Re: [RFC PATCH] x86, numa: always initialize all possible nodes

* Michal Hocko wrote: > On Thu 24-01-19 11:10:50, Dave Hansen wrote: > > On 1/24/19 6:17 AM, Michal Hocko wrote: > > > and nr_cpus set to 4. The underlying reason is tha the device is bound > > > to node 2 which doesn't have any memory and init_cpu_to_node only > > > initializes memory-less

Re: [PATCH v3 3/4] uaccess: Check no rescheduling function is called in unsafe region

are only performed when DEBUG_UACCESS_SLEEP is selected. > > Also, add a comment clarifying the behaviour of user_access regions. > > Signed-off-by: Julien Thierry > Cc: Ingo Molnar > Cc: Peter Zijlstra > > --- > include/linux/kernel.h | 11 +-- > incl

Re: [PATCH 2/2] selftests/x86/fsgsbase: Default to trying to run the test repeatedly

* Mark Brown wrote: > On Mon, Feb 11, 2019 at 09:49:16AM +0100, Ingo Molnar wrote: > > > So this isn't very user-friendly either, previously it would run a > > testcase and immediately provide output. > > > Now it's just starting and 'hanging': > > >

Re: [PATCH v-1] x86_64: new and improved memset() + question

* Alexey Dobriyan wrote: > Current memset() implementation does silly things: > * multiplication to get wide constant: > waste of cycles if filler is known at compile time, > > * REP STOSQ followed by REP STOSB: > this code is used when REP STOSB is slow but still it is used >

Re: [Xen-devel] [PATCH v2 1/2] x86: respect memory size limiting via mem= parameter

lly present in the E820 map, but the "mem=" will remove it from > there again. During ACPI scan it is found (again) and will be added via > hotplug mechanism, so "mem=" has no effect for that memory. OK. With that background: Acked-by: Ingo Molnar I suppose you want thi

Re: [PATCH v2 1/2] x86: respect memory size limiting via mem= parameter

* Juergen Gross wrote: > When limiting memory size via kernel parameter "mem=" this should be > respected even in case of memory made accessible via a PCI card. > > Today this kind of memory won't be made usable in initial memory > setup as the memory won't be visible in E820 map, but it

Re: [PATCH] locking/rwsem: Remove arch specific rwsem files

* Will Deacon wrote: > On Mon, Feb 11, 2019 at 11:39:27AM +0100, Ingo Molnar wrote: > > > > * Ingo Molnar wrote: > > > > > Sounds good to me - I've merged this patch, will push it out after > > > testing. > > > > Based on Peter

Re: [PATCH v3 10/10] x86/split_lock: Handle #AC exception for split lock

* Fenghua Yu wrote: > --- a/arch/x86/kernel/traps.c > +++ b/arch/x86/kernel/traps.c > @@ -61,6 +61,7 @@ > #include > #include > #include > +#include > > #ifdef CONFIG_X86_64 > #include > @@ -292,9 +293,36 @@ DO_ERROR(X86_TRAP_OLD_MF, SIGFPE, 0, NULL, > "coprocessor

Re: [PATCH] locking/rwsem: Remove arch specific rwsem files

* Ingo Molnar wrote: > Sounds good to me - I've merged this patch, will push it out after > testing. Based on Peter's feedback I'm delaying this - performance testing on at least one key ll/sc arch would be nice indeed. Thanks, Ingo

Re: [PATCH 2/2] selftests/x86/fsgsbase: Default to trying to run the test repeatedly

* Mark Brown wrote: > In automated testing it has been found that on many systems the fsgsbase > test fails intermittently. This was reported and discussed a while > back: > > https://lore.kernel.org/lkml/20180126153631.ha7yc33fj5uhitjo@xps/ > > with the analysis concluding that this is

Re: [PATCH 1/2] selftests/x86/fsgsbase: Indirect output through a wrapper function

* Mark Brown wrote: > In preparation for a change to make this test run repeatedly which > would generate huge amounts of output as is indirect all the printf() > calls in the program through a wrapper and add a quiet flag which can > be used to suppress the output. This is fairly quick and

Re: [PATCH -next] x86_64: tidy up KASAN_EXTRA

#ifdef CONFIG_KASAN > -#ifdef CONFIG_KASAN_EXTRA > -#define KASAN_STACK_ORDER 2 > -#else > #define KASAN_STACK_ORDER 1 > -#endif > #else > #define KASAN_STACK_ORDER 0 > #endif Acked-by: Ingo Molnar Thanks, Ingo

Re: [RFC PATCH] perf, bpf: Retain kernel executable code in memory to aid Intel PT tracing

* Peter Zijlstra wrote: > On Thu, Feb 07, 2019 at 01:19:01PM +0200, Adrian Hunter wrote: > > Subject to memory pressure and other limits, retain executable code, such > > as JIT-compiled bpf, in memory instead of freeing it immediately it is no > > longer needed for execution. > > > > While

Re: [PATCH v2] PCI: Fixup the RTIT_BAR of Intel TH on Denverton

* Alexander Shishkin wrote: > On Denverton's integration of the Intel(R) Trace Hub (for a reference > and overview see Documentation/trace/intel_th.txt) the reported size of > one of its resources (RTIT_BAR) doesn't match its actual size, which > leads to overlaps with other devices'

Re: [PATCH-tip 00/22] locking/rwsem: Rework rwsem-xadd & enable new rwsem features

* Waiman Long wrote: > On 02/07/2019 02:51 PM, Davidlohr Bueso wrote: > > On Thu, 07 Feb 2019, Waiman Long wrote: > >> 30 files changed, 1197 insertions(+), 1594 deletions(-) > > > > Performance numbers on numerous workloads, pretty please. > > > > I'll go and throw this at my mmap_sem

<    3   4   5   6   7   8   9   10   11   12   >