Re: [PATCH] x86/mm/fault: Streamline the fault error_code decoder some more

2018-12-06 Thread Ingo Molnar
* Andy Lutomirski wrote: > That’s why I suggested “read,” in lowercase, for reads. Other than > that, most of the unset bits are uninteresting. An OOPS is so likely to > be a kernel fault that it’s barely worth mentioning, and I even added a > whole separate diagnostic for user oopses.

Re: [PATCH] x86/mm/fault: Streamline the fault error_code decoder some more

2018-12-06 Thread Ingo Molnar
* Andy Lutomirski wrote: > > vs. (with SGX added as 'G' for testing purposes) > > > > [0.158849] #PF error code(0001): +P !W !U !S !I !K !G > > [0.159292] #PF error code(0003): +P +W !U !S !I !K !G > > [0.159742] #PF error code(0007): +P +W +U !S !I !K !G > > [0.160190] #PF

Re: [PATCH v7 08/14] x86/ftrace: Use text_poke_*() infrastructure

2018-12-06 Thread Ingo Molnar
* Nadav Amit wrote: > > On Dec 4, 2018, at 5:34 PM, Nadav Amit wrote: > > > > A following patch is going to make module allocated memory > > non-executable. This requires to modify ftrace and make the memory > > executable again after it is configured. > > > > In addition, this patch makes

Re: [PATCH] x86/mce: Streamline MCE subsystem's naming

2018-12-06 Thread Ingo Molnar
* Borislav Petkov wrote: > On Wed, Dec 05, 2018 at 07:01:58PM +0100, Ingo Molnar wrote: > > Oh - I thought we'd have arch/x86/mce/ or so? > > > > There's machine check events that are not tied to any particular CPU, > > correct? So this would be the right conceptua

Re: [PATCH] x86/mm/fault: Streamline the fault error_code decoder some more

2018-12-06 Thread Ingo Molnar
* Sean Christopherson wrote: > On Thu, Dec 06, 2018 at 08:34:09AM +0100, Ingo Molnar wrote: > > I like your '!' idea, but with a further simplification: how about using > > '-/+' differentiation and a single character and a fixed-length message. > > > > T

Re: [PATCH] scripts/atomic: change 'fold' to 'grep'

2018-12-06 Thread Ingo Molnar
* Will Deacon wrote: > [+ Ingo and Mark] > > On Tue, Dec 04, 2018 at 10:47:13PM +0100, Anders Roxell wrote: > > Some distibutions and build systems doesn't include 'fold' from > > coreutils default. > > > > .../scripts/atomic/atomic-tbl.sh: line 183: fold: command not found > > > > Rework

Re: [PATCHv2] locking/atomics: build atomic headers as required

2018-12-06 Thread Ingo Molnar
previously had issues with > (out-of-tree builds and where scripts have no execute permissions), and > have tested these cases for both x86_64 and arm64. > > The diffstat looks nice, at least... > > Signed-off-by: Mark Rutland > Cc: Andrew Morton > Cc: Boqun Feng > Cc:

[PATCH] x86/mm/fault: Streamline the fault error_code decoder some more

2018-12-05 Thread Ingo Molnar
_str_append() calls by type so that the resulting print > messages are consistent, e.g. the deciphered codes will always be: > > [PROT] [USER|SUPERVISOR] [WRITE|INSTR|READ] [RSDV] [PK] > > Cc: Andy Lutomirski > Cc: Borislav Petkov > Cc: Dave Hansen > Cc: H. Pete

Re: [PATCH] x86/mce: Streamline MCE subsystem's naming

2018-12-05 Thread Ingo Molnar
* Borislav Petkov wrote: > On Wed, Dec 05, 2018 at 05:30:37PM +0100, Ingo Molnar wrote: > > Would it make sense to organize it a bit more and separate out vendor > > specific functionality: > > > > mce/cpu/intel.c > > mce/cpu/intel-p5.c > >

Re: [PATCH] x86/mce: Streamline MCE subsystem's naming

2018-12-05 Thread Ingo Molnar
mce/inject.c mce/therm_throt.c mce/dev-mcelog.c mce/apei.c ? This way there's a clear separation between low level, vendor specific MCE logic and higher level MCE logic. mce/apei.c, if this is an Intel-only feature, could perhaps become mce/cpu/intel-apei.c? Anyway, your patch is fine too, so whichever subset you decide to use: Reviewed-by: Ingo Molnar Thanks, Ingo

Re: [PATCH] x86/kernel: Fix more -Wmissing-prototypes warnings

2018-12-05 Thread Ingo Molnar
d via proper ordering of functions from lower level to higher levels. On the rest: Reviewed-by: Ingo Molnar Thanks, Ingo

Re: [PATCH] x86/umip: Make the UMIP activated message generic

2018-12-04 Thread Ingo Molnar
* Lendacky, Thomas wrote: > The User Mode Instruction Prevention (UMIP) feature is part of the x86_64 > instruction set architecture and not specific to Intel. Make the message > generic. > > Signed-off-by: Tom Lendacky > --- > > This patch is against the x86/cpu branch of the tip tree: >

Re: [PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)

2018-12-04 Thread Ingo Molnar
* Michal Hocko wrote: > I dunno. I do not use hibernation. I am a heavy user of the suspend > though. I s2ram all the time. And I have certainly experienced cases > where suspend has failed and I onlyi found out later when I've picked > up my laptop from my heat up bag. Nothing fatal has

Re: [PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)

2018-12-04 Thread Ingo Molnar
* Oleg Nesterov wrote: > > I reviewed the ->cred_guard_mutex code, and the mutex is held across all > > of exec() - and we always did this. > > Yes, and this was always wrong. For example, this test-case hangs: > > #include > #include > #include > #include > >

Re: [PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)

2018-12-04 Thread Ingo Molnar
* Michal Hocko wrote: > > Do we actually have reports of this happening for people outside > > Android? > > Not that I am aware of. I'd say outside of Android 99% of the use of hibernation is the fail-safe that distributions offer on laptops with very low battery levels: the emergency

Re: [PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)

2018-12-04 Thread Ingo Molnar
Thanks! I have 1+ days uptime now on the system, no splat or other problems, as expected: Tested-by: Ingo Molnar I have the revert locally in -tip, will drop it once your commit hits upstream. Ingo

Re: Strange hang with gcc 8 of kprobe multiple_kprobes test

2018-12-04 Thread Ingo Molnar
* Masami Hiramatsu wrote: > I remember I have fixed this, and actually WE did it :-D > > https://lkml.org/lkml/2018/8/23/1203 > > Ah, we hit a same bug... > > Ingo, could you pick the patch? Should I resend it? Indeed: I just picked it up into tip:perf/urgent. It's my bad: I missed the

Re: [BUGFIX PATCH -tip] kprobes/x86: Fix to copy RIP relative instruction correctly

2018-12-04 Thread Ingo Molnar
* Masami Hiramatsu wrote: > Since copy_optimized_instructions() misses to update real RIP > address while copying several instructions to working buffer, > it adjusts RIP-relative instruction with wrong RIP address for > the 2nd and subsequent instructions. > > This may break the kernel (like

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

2018-12-04 Thread Ingo Molnar
[ Added Linus and Arnaldo to the Cc:, for high level kernel side and tooling side buy-in for the inclusion in the kernel tree below: ] * Paul E. McKenney wrote: > Hello, Ingo, > > This pull request contains the following changes: > > 1.Convert RCU's BUG_ON() and similar calls to

Re: [PATCH] tools: Fix diverse typos

2018-12-03 Thread Ingo Molnar
* Peter Zijlstra wrote: > On Mon, Dec 03, 2018 at 11:22:00AM +0100, Ingo Molnar wrote: > > Go over the tools/ files that are maintained in Arnaldo's tree and > > fix common typos: half of them were in comments, the other half > > in JSON files. > > > > ( Care

[PATCH] tools: Fix diverse typos

2018-12-03 Thread Ingo Molnar
in functionality intended. Cc: Arnaldo Carvalho de Melo Cc: Peter Zijlstra Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar --- tools/lib/subcmd/parse-options.h | 4 +-- tools/lib/traceevent/event-parse.c | 12 - tools/lib/traceevent

Re: [PATCH] cpu: Bool tests don't need comparisons

2018-12-03 Thread Ingo Molnar
* Wen Yang wrote: > This is the patch to the file cpu.c > which fixes the following coccinelle warning: > > WARNING: Comparison to bool > > Signed-off-by: Wen Yang > CC: Thomas Gleixner > CC: Ingo Molnar > CC: Konrad Rzeszutek Wilk > CC: Josh Poimboeuf

Re: [PATCH] locktorture: Fix assignment of boolean variables

2018-12-03 Thread Ingo Molnar
* Peter Zijlstra wrote: > On Sat, Dec 01, 2018 at 12:37:01PM -0800, Paul E. McKenney wrote: > > On Sat, Dec 01, 2018 at 04:31:49PM +0800, Wen Yang wrote: > > > Fix the following warnings reported by coccinelle: > > > > > > kernel/locking/locktorture.c:703:6-10: WARNING: Assignment of bool to

[PATCH] x86/pci: Clean up the asm/pci_x86.h header a bit

2018-12-03 Thread Ingo Molnar
* Ingo Molnar wrote: > From 22b71f970f18f5f38161be028ab7ce7cd1f769f7 Mon Sep 17 00:00:00 2001 > From: Ingo Molnar > Date: Mon, 3 Dec 2018 09:15:40 +0100 > Subject: [PATCH] x86/pci: Remove the dead-code DBG() macro > > While reading arch/x86/include/asm/pci_x86.h I no

[PATCH] x86/pci: Remove dead code DBG() macro

2018-12-03 Thread Ingo Molnar
>From 22b71f970f18f5f38161be028ab7ce7cd1f769f7 Mon Sep 17 00:00:00 2001 From: Ingo Molnar Date: Mon, 3 Dec 2018 09:15:40 +0100 Subject: [PATCH] x86/pci: Remove the dead-code DBG() macro While reading arch/x86/include/asm/pci_x86.h I noticed that we have ancient residuals of debugging code, wh

Re: [PATCH v2] locktorture: style fix - spaces required around

2018-12-03 Thread Ingo Molnar
* Wen Yang wrote: > This patch fixes the following checkpatch.pl errors: > > ERROR: spaces required around that ':' (ctx:VxW) > +torture_type, tag, cxt.debug_lock ? " [debug]": "", There's literally 1 million checkpatch 'failures' in the kernel, so unless we want to apply 1

Re: [PATCH v2] locktorture: Fix assignment of boolean variables

2018-12-03 Thread Ingo Molnar
* Wen Yang wrote: > Fix the following warnings reported by coccinelle: > > kernel/locking/locktorture.c:703:6-10: WARNING: Assignment of bool to 0/1 > kernel/locking/locktorture.c:918:2-20: WARNING: Assignment of bool to 0/1 > kernel/locking/locktorture.c:949:3-20: WARNING: Assignment of bool

[PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)

2018-12-02 Thread Ingo Molnar
: s/casue/cause s/In our/On our s/bellows/below ... Grump! :-) Note that I haven't tested the revert yet, but the code and the breakage looks pretty obvious. (I'll boot the revert, will follow up if that didn't solve the problem.) Thanks, Ingo

[GIT PULL] x86 fixes

2018-11-29 Thread Ingo Molnar
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: 60c8144afc287ef09ce8c1230c6aa972659ba1bb x86/MCE/AMD: Fix the thresholding machinery initialization order Misc fixes: - an MCE

[GIT PULL] perf fixes

2018-11-29 Thread Ingo Molnar
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: 09d3f015d1e1b4fee7e9bbdcf54201d239393391 uprobes: Fix handle_swbp() vs. unregister() + register() race once more Misc fixes: - a

[GIT PULL] EFI fix

2018-11-29 Thread Ingo Molnar
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: 976b489120cdab2b1b3a41ffa14661db43d58190 efi: Prevent GICv3 WARN() by mapping the memreserve table before first use An arm64 warning

[GIT PULL] objtool fixes

2018-11-29 Thread Ingo Molnar
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: 22566c1603030f0a036ad564634b064ad1a55db2 objtool: Fix segfault in .cold detection with -ffunction-sections Two fixes for boundary

Re: [PATCH v4 4/4] perf report: Documentation average IPC and IPC coverage

2018-11-29 Thread Ingo Molnar
s bottleneck /such as a memory access bottleneck s/it's worth further analysis for performance optimization. /it's worth further analyzing it to optimize its performance. ? Other than that: Reviewed-by: Ingo Molnar Ingo

Re: [PATCH v3 0/3] perf report/annotate: Support average IPC and IPC coverage for function

2018-11-28 Thread Ingo Molnar
* Jin Yao wrote: > Add supporting of displaying the average IPC and IPC coverage > percentage per function. > > For example, > > $ perf record -b ... > $ perf report -s symbol or > perf report -s symbol --stdio > > Overhead Symbol IPC [IPC Coverage] > 39.60%

Re: [tip:locking/core] locking/atomics: Check generated headers are up-to-date

2018-11-28 Thread Ingo Molnar
* Mark Rutland wrote: > > Could we please get this fixed so that proper dependencies are checked > > and it's only regenerated when needed? This slowdown makes additive-build > > kernel development quite painful, as ~5 seconds is in the 'too long' > > category already, while 1.2 seconds is

Re: [patch V2 00/28] x86/speculation: Remedy the STIBP/IBPB overhead

2018-11-26 Thread Ingo Molnar
nd IBPB always mode. > > - Addressed the review comments With the typo review feedback outlined in the discussions: Reviewed-by: Ingo Molnar Thanks, Ingo

Re: [patch V2 21/28] x86/speculation: Prepare for conditional IBPB in switch_mm()

2018-11-26 Thread Ingo Molnar
* Thomas Gleixner wrote: > On Sun, 25 Nov 2018, Andy Lutomirski wrote: > > > On Nov 25, 2018, at 2:20 PM, Thomas Gleixner wrote: > > > On Sun, 25 Nov 2018, Andi Kleen wrote: > > > > > >>> The current check whether two tasks belong to the same context is using > > >>> the > > >>> tasks

Re: [patch V2 27/28] x86/speculation: Add seccomp Spectre v2 user space protection mode

2018-11-26 Thread Ingo Molnar
* Thomas Gleixner wrote: > On Sun, 25 Nov 2018, Linus Torvalds wrote: > > > [ You forgot to fix your quilt setup.. ] > > Duh. Should have pinned that package. > > > On Sun, 25 Nov 2018, Thomas Gleixner wrote: > > > > > > The mitigation guide documents how STIPB works: > > > > > >Setting

Re: [patch 20/24] x86/speculation: Split out TIF update

2018-11-22 Thread Ingo Molnar
* Thomas Gleixner wrote: > On Thu, 22 Nov 2018, Ingo Molnar wrote: > > * Thomas Gleixner wrote: > > > > Had to read this twice, because the comment and the code are both correct > > but deal with the inverse case. This might have helped: > > > &g

Re: [patch 20/24] x86/speculation: Split out TIF update

2018-11-22 Thread Ingo Molnar
* Thomas Gleixner wrote: > On Wed, 21 Nov 2018, Tim Chen wrote: > > > On Wed, Nov 21, 2018 at 09:14:50PM +0100, Thomas Gleixner wrote: > > > +static void task_update_spec_tif(struct task_struct *tsk, int tifbit, > > > bool on) > > > { > > > bool update; > > > > > > + if (on) > > >

Re: [PATCH] uprobes: Fix handle_swbp() vs. unregister() + register() race once more

2018-11-22 Thread Ingo Molnar
uaranteeing that > > > (program-order) subsequent loads from the uprobe can see the initial > > > stores performed by prepare_uprobe(). > > > > > > Move the smp_rmb() accordingly. Also amend the comments associated > > > to the two memory barriers

Re: [tip:x86/cleanups] x86/headers: Fix -Wmissing-prototypes warning

2018-11-22 Thread Ingo Molnar
* tip-bot for Yi Wang wrote: > Commit-ID: d37904c5b14317a2c76efec6b9e4dbcaa17380e5 > Gitweb: > https://git.kernel.org/tip/d37904c5b14317a2c76efec6b9e4dbcaa17380e5 > Author: Yi Wang > AuthorDate: Thu, 22 Nov 2018 10:04:09 +0800 > Committer: Ingo Molnar > Co

Re: [PATCH v5] x86/fsgsbase/64: Fix the base write helper functions

2018-11-22 Thread Ingo Molnar
* Andy Lutomirski wrote: > On Fri, Nov 16, 2018 at 3:27 PM Chang S. Bae wrote: > > > > The helper functions that purport to write the base should just write it > > only. It shouldn't have magic optimizations to change the index. > > > > Make the index explicitly changed from the caller,

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-22 Thread Ingo Molnar
* Ingo Molnar wrote: > So I dug into this some more: > > 1) > > Firstly I tracked down GCC bloating the might_fault() checks and the > related out-of-line code exception handling which bloats the full > generated function. Sorry, I mis-remembered that detail w

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-22 Thread Ingo Molnar
* Ingo Molnar wrote: > The kernel text size reduction with Jen's patch is small but real: > > text databss dec hex filename > 19572694 115169341987388850963516309a43c > vmlinux.before > 195

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-22 Thread Ingo Molnar
* Linus Torvalds wrote: > On Wed, Nov 21, 2018 at 10:16 AM Linus Torvalds > wrote: > > > > It might be interesting to just change raw_copy_to/from_user() to > > handle a lot more cases (in particular, handle cases where 'size' is > > 8-byte aligned). The special cases we *do* have may not be

[PATCH 6/5] x86/fault: Clean up the page fault oops decoder a bit

2018-11-22 Thread Ingo Molnar
anups - see the changelog below. Let me know if you have any objections. Thanks, Ingo ===> >From a2aa52ab16efbee40ad118ebac4a5e438f5b43ee Mon Sep 17 00:00:00 2001 From: Ingo Molnar Date: Thu, 22 Nov 2018 09:34:03 +0100 Subject: [PATCH] x86/fault: Clean up the page fault oop

Re: [patch 14/24] x86/speculation: Unify conditional spectre v2 print functions

2018-11-21 Thread Ingo Molnar
* Thomas Gleixner wrote: > There is no point in having two functions and a conditional at the call > site. > > Signed-off-by: Thomas Gleixner patches 1-14: Reviewed-by: Ingo Molnar 15-24 look good to me too, modulo the (mostly trivial) feedback I gave. Thanks, Ingo

Re: [patch 16/24] x86/speculation: Prepare for per task indirect branch speculation control

2018-11-21 Thread Ingo Molnar
* Thomas Gleixner wrote: > From: Tim Chen > > To avoid the overhead of STIBP always on, it's necessary to allow per task > control of STIBP. > > Add a new task flag TIF_SPEC_IB and evaluate it during context switch if > SMT is active and flag evaluation is enabled by the speculation control

Re: [patch 17/24] x86/speculation: Move IBPB control out of switch_mm()

2018-11-21 Thread Ingo Molnar
* Thomas Gleixner wrote: > IBPB control is currently in switch_mm() to avoid issuing IBPB when > switching between tasks of the same process. > > But that's not covering the case of sandboxed tasks which get the > TIF_SPEC_IB flag set via seccomp. There the barrier is required when the >

Re: [patch 18/24] x86/speculation: Avoid __switch_to_xtra() calls

2018-11-21 Thread Ingo Molnar
* Tim Chen wrote: > On 11/21/2018 12:14 PM, Thomas Gleixner wrote: > > > +* Avoid __switch_to_xtra() invocation when conditional stpib is > > s/stpib/stibp and: s/stibp/STIBP to make it consistent throughout the patchset. Thanks, Ingo

Re: [patch 20/24] x86/speculation: Split out TIF update

2018-11-21 Thread Ingo Molnar
* Thomas Gleixner wrote: > The update of the TIF_SSBD flag and the conditional speculation control MSR > update is done in the ssb_prctl_set() function directly. The upcoming prctl > support for controlling indirect branch speculation via STIBP needs the > same mechanism. > > Split the code

Re: [patch 21/24] x86/speculation: Prepare arch_smt_update() for PRCTL mode

2018-11-21 Thread Ingo Molnar
* Thomas Gleixner wrote: > The upcoming fine grained per task STIBP control needs to be updated on CPU > hotplug as well. > > Split out the code which controls the strict mode so the prctl control code > can be added later. > > Signed-off-by: Thomas Gleixner > --- >

Re: [patch 24/24] x86/speculation: Add seccomp Spectre v2 app to app protection mode

2018-11-21 Thread Ingo Molnar
* Thomas Gleixner wrote: > From: Jiri Kosina > > If 'prctl' mode of app2app protection from spectre v2 is selected on the > kernel command-line, STIBP and IBPB are applied on tasks which restrict > their indirect branch speculation via prctl. > > SECCOMP enables the SSBD mitigation for

Re: [patch 23/24] x86/speculation: Enable PRCTL mode for spectre_v2_app2app

2018-11-21 Thread Ingo Molnar
* Thomas Gleixner wrote: > Now that all prerequisites are in place: > > - Add the prctl command line option > > - Default the 'auto' mode to 'prctl' > > - When SMT state changes, update the static key which controls the >conditional STIBP evaluation on context switch. > > - At init

Re: [patch 22/24] x86/speculation: Create PRCTL interface to restrict indirect branch speculation

2018-11-21 Thread Ingo Molnar
* Thomas Gleixner wrote: > From: Tim Chen > > Add the PR_SPEC_INDIR_BRANCH option for the PR_GET_SPECULATION_CTRL and > PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of > indirect branch speculation via STIBP. > > Invocations: > Check indirect branch speculation

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

2018-11-21 Thread Ingo Molnar
* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, some from before the trip to Vancouver, > some that were more easy to process before I continue with the backlog. > Took a bit more time than I antecipated due to fixing build breakage in > various places due to

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

2018-11-21 Thread Ingo Molnar
* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, more to come as I process the backlog > from being away for LPC. > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit

Re: [tip:locking/core] locking/atomics: Check generated headers are up-to-date

2018-11-21 Thread Ingo Molnar
* tip-bot for Mark Rutland wrote: > Commit-ID: 8d32588077bdc390420cfa6946f407033a20d7a8 > Gitweb: > https://git.kernel.org/tip/8d32588077bdc390420cfa6946f407033a20d7a8 > Author: Mark Rutland > AuthorDate: Tue, 4 Sep 2018 11:48:29 +0100 > Committer: Ingo Molnar &g

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-20 Thread Ingo Molnar
[ Cc:-ed a few other gents and lkml. ] * Jens Axboe wrote: > Hi, > > So this is a fun one... While I was doing the aio polled work, I noticed > that the submitting process spent a substantial amount of time copying > data to/from userspace. For aio, that's iocb and io_event, which are 64 >

Re: [PATCH 02/13] x86/fault: Check user_mode(regs) when validating a stack extension

2018-11-20 Thread Ingo Molnar
* Ingo Molnar wrote: > > * Andy Lutomirski wrote: > > > The fault handling code tries to validate that a page fault from > > user mode that would extend the stack is within a certain range of > > the user SP. regs->sp is only equal to the user SP if > >

Re: [PATCH 02/13] x86/fault: Check user_mode(regs) when validating a stack extension

2018-11-19 Thread Ingo Molnar
* Andy Lutomirski wrote: > The fault handling code tries to validate that a page fault from > user mode that would extend the stack is within a certain range of > the user SP. regs->sp is only equal to the user SP if > user_mode(regs). In the extremely unlikely event that that >

Re: Cleaning up numbering for new x86 syscalls?

2018-11-19 Thread Ingo Molnar
* Andy Lutomirski wrote: > Hi all- > > We currently have some giant turds in the way that syscalls are > numbered. We have the x86_32 table, which is totally sane other than > some legacy multiplexers. Then we have the x86_64 table, which is, > um, demented: > > - The numbers don't match

Re: STIBP by default.. Revert?

2018-11-19 Thread Ingo Molnar
* Linus Torvalds wrote: > This was marked for stable, and honestly, nowhere in the discussion > did I see any mention of just *how* bad the performance impact of this > was. Yeah. This was an oversight - we'll fix it! > When performance goes down by 50% on some loads, people need to start >

[GIT PULL] scheduler fix

2018-11-17 Thread Ingo Molnar
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: c469933e772132aad040bd6a2adc8edf9ad6f825 sched/fair: Fix cpu_util_wake() for 'execl' type workloads Fix an exec() related

[GIT PULL] perf fixes

2018-11-17 Thread Ingo Molnar
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: 4d47d6407ac7b4b442a4e717488a3bb137398b6c perf/x86/intel/uncore: Support CoffeeLake 8th CBOX Fix uncore PMU enumeration for

Re: [GIT PULL] PCI changes for v4.20

2018-11-14 Thread Ingo Molnar
* Bjorn Helgaas wrote: > [+cc Martin, Rafael, Len, linux-acpi] > > On Tue, Nov 13, 2018 at 11:20:04AM +0100, Borislav Petkov wrote: > > On Tue, Nov 13, 2018 at 08:17:12AM +0100, Ingo Molnar wrote: > > > > > > * Bjorn Helgaas wrote: > > > >

Re: [PATCH 2/2] x86: set a dependency on macros.S

2018-11-13 Thread Ingo Molnar
orce_checksrc) > $(call if_changed_rule,cc_o_c) > @{ echo $(@:.o=.ko); echo $@; \ Acked-by: Ingo Molnar Thanks, Ingo

Re: [PATCH 1/2] Makefile: Fix distcc compilation with x86 macros

2018-11-13 Thread Ingo Molnar
* Nadav Amit wrote: > Introducing the use of asm macros in c-code broke distcc, since it only > sends the preprocessed source file. The solution is to break the > compilation into two separate phases of compilation and assembly, and > between the two concatanate the assembly macros and the

Re: [GIT PULL] PCI changes for v4.20

2018-11-12 Thread Ingo Molnar
* Bjorn Helgaas wrote: > PCI changes: > > - Pay attention to device-specific _PXM node values (Jonathan Cameron) There's a new boot regression, my AMD ThreadRipper system (MSI X399 SLI PLUS (MS-7B09)) hangs during early bootup, and I have bisected it down to this commit: bad7dcd94f39:

Re: [PATCH] sched/rt: Introduce prio_{higher,lower}() helper for comparing RT task prority

2018-11-11 Thread Ingo Molnar
* Peter Zijlstra wrote: > I think you only need the less thing, because: > > static inline bool prio_lower(int a, int b) > { > return a > b; > } I'd say that should be named rt_prio_lower(), even if it's local to sched/rt.c, right? Thanks, Ingo

Re: [RFC PATCH 00/12] locking/lockdep: Add a new class of terminal locks

2018-11-11 Thread Ingo Molnar
* Josh Poimboeuf wrote: > On Mon, Nov 12, 2018 at 06:10:33AM +0100, Ingo Molnar wrote: > > > > * Waiman Long wrote: > > > > > On 11/10/2018 09:10 AM, Peter Zijlstra wrote: > > > > On Fri, Nov 09, 2018 at 09:04:12AM +0100, Ingo Molnar wrote: &g

Re: [patch 0/2] Documentation/process: Add subsystem/tree handbook

2018-11-11 Thread Ingo Molnar
* Jonathan Corbet wrote: > > Even after a decade of introducing Git I still see Signed-off-by used as > > an Acked-by or Reviewed-by substitutes, so I'd suggest adding this small > > explanation as well: > > > > + SOB chains should reflect the *real* route a patch took as it was > >

Re: [RFC PATCH v1 2/2] proc: add /proc//thread_state

2018-11-11 Thread Ingo Molnar
* Peter Zijlstra wrote: > On Thu, Nov 08, 2018 at 07:32:46AM +0100, Ingo Molnar wrote: > > > > * Aubrey Li wrote: > > > > > Expose the per-task cpu specific thread state value, it's helpful > > > for userland to classify and schedule the tasks by di

Re: [tip:ras/core] x86/mce: Fix -Wmissing-prototypes warnings

2018-11-11 Thread Ingo Molnar
* Borislav Petkov wrote: > Fix an actual bug too which the warning triggered: > > arch/x86/kernel/cpu/mcheck/therm_throt.c:395:39: error: conflicting \ > types for ‘smp_thermal_interrupt’ >asmlinkage __visible void __irq_entry smp_thermal_interrupt(struct pt_regs > *r) >

Re: [RFC PATCH 00/12] locking/lockdep: Add a new class of terminal locks

2018-11-11 Thread Ingo Molnar
* Waiman Long wrote: > > Could you please measure a locking intense workload instead, such as: > > > >$ perf stat --null --sync --repeat 10 perf bench sched messaging > > > > and profile which locks used there could be marked terminal, and measure > > the before/after performance impact?

Re: [RFC PATCH 00/12] locking/lockdep: Add a new class of terminal locks

2018-11-11 Thread Ingo Molnar
* Waiman Long wrote: > On 11/10/2018 09:10 AM, Peter Zijlstra wrote: > > On Fri, Nov 09, 2018 at 09:04:12AM +0100, Ingo Molnar wrote: > >> BTW., if you are interested in more radical approaches to optimize > >> lockdep, we could also add a static checker vi

Re: [PATCH RFC 0/3] Static calls

2018-11-11 Thread Ingo Molnar
* Josh Poimboeuf wrote: > On Fri, Nov 09, 2018 at 08:28:11AM +0100, Ingo Molnar wrote: > > > - I'm not sure about the objtool approach. Objtool is (currently) > > > x86-64 only, which means we have to use the "unoptimized" version > > > everywhere e

Re: [PATCH v2 3/3] sched/fair: add lsub_positive and use it consistently

2018-11-11 Thread Ingo Molnar
* Patrick Bellasi wrote: > The following pattern: > >var -= min_t(typeof(var), var, val); > > is used multiple times in fair.c. > > The existing sub_positive() already capture that pattern but it adds > also explicit load-sotre to properly support lockless observations. > In other

Re: [PATCH v4 06/10] x86/alternative: use temporary mm for text poking

2018-11-11 Thread Ingo Molnar
* Peter Zijlstra wrote: > On Sun, Nov 11, 2018 at 08:53:07PM +, Nadav Amit wrote: > > > >> +/* > > >> + * The lock is not really needed, but this allows to avoid > > >> open-coding. > > >> + */ > > >> +ptep = get_locked_pte(poking_mm, poking_addr, ); > >

Re: [RFC PATCH 00/12] locking/lockdep: Add a new class of terminal locks

2018-11-09 Thread Ingo Molnar
* Waiman Long wrote: > The purpose of this patchset is to add a new class of locks called > terminal locks and converts some of the low level raw or regular > spinlocks to terminal locks. A terminal lock does not have forward > dependency and it won't allow a lock or unlock operation on

Re: [PATCH RFC 0/3] Static calls

2018-11-08 Thread Ingo Molnar
* Ingo Molnar wrote: > > - Does this feature have much value without retpolines? If not, should > > we make it depend on retpolines somehow? > > Paravirt patching, as you mention in your later reply? BTW., to look for candidates of this API, I'd suggest looking at

Re: [PATCH RFC 0/3] Static calls

2018-11-08 Thread Ingo Molnar
* Josh Poimboeuf wrote: > These patches are related to two similar patch sets from Ard and Steve: > > - https://lkml.kernel.org/r/20181005081333.15018-1-ard.biesheu...@linaro.org > - https://lkml.kernel.org/r/20181006015110.653946...@goodmis.org > > The code is also heavily inspired by the

Re: [patch 2/2] Documentation/process: Add tip tree handbook

2018-11-08 Thread Ingo Molnar
* Thomas Gleixner wrote: > +Line breaks > +^^^ > + > +Restricting line length to 80 characters makes deeply indented code hard to > +read. Consider breaking out code into helper functions to avoid excessive > +line breaking. > + > +The 80 character rule is not a strict rule, so please

Re: [patch 2/2] Documentation/process: Add tip tree handbook

2018-11-08 Thread Ingo Molnar
* Thomas Gleixner wrote: > +Commit notifications > + > + > +The tip tree is monitored by a bot for new commits. The bot sends an email > +for each new commit to a dedicated mailing list > +(``linux-tip-comm...@vger.kernel.org``) and Cc's all people who are > +mentioned in

Re: [patch 2/2] Documentation/process: Add tip tree handbook

2018-11-08 Thread Ingo Molnar
* Thomas Gleixner wrote: > +Namespaces > +^^ > + > +To improve readability and to allow easy grepping for information the usage > +of consistent namespaces is important. The namespace should be used as a > +prefix for globally visible (inline) functions and variables. A simple rule >

Re: [patch 2/2] Documentation/process: Add tip tree handbook

2018-11-08 Thread Ingo Molnar
* Thomas Gleixner wrote: > +Variable types > +^^ > + > +Please use the proper u8, u16, u32, u64 types for variables which are meant > +to describe hardware or are used as arguments for functions which access > +hardware. These types are clearly defining the bit width and avoid >

Re: [patch 2/2] Documentation/process: Add tip tree handbook

2018-11-07 Thread Ingo Molnar
Lemme fill in the scheduler and locking/atomics bits as well: > +The tip tree contains the following subsystems: > + > + - **x86 architecture** > + > + The x86 architecture development takes place in the tip tree except > + for the x86 KVM and XEN specific parts which are maintained

Re: [patch 2/2] Documentation/process: Add tip tree handbook

2018-11-07 Thread Ingo Molnar
* Thomas Gleixner wrote: > + - Signed-off-by: ``Patch handler `` > + > + SOBs after the author SOB are from people handling and transporting the > + patch, but were not involved in development. If the handler made > + modifications to the patch or the changelog, then this should be > +

Re: [patch 2/2] Documentation/process: Add tip tree handbook

2018-11-07 Thread Ingo Molnar
* Thomas Gleixner wrote: > + - Fixes: 12char-SHA1 ("sub/sys: Original subject line") > + > + A Fixes tag should be added even for changes which do not need to be > + backported to stable kernels, i.e. when addressing a recently introduced > + issue which only affects tip or the current

Re: [patch 2/2] Documentation/process: Add tip tree handbook

2018-11-07 Thread Ingo Molnar
* Thomas Gleixner wrote: > +Backtraces in changelogs > + > + > +Backtraces can be useful to document the call chain which led to a > +problem. Though not all back traces are really valuable because the call > +chain is unique and obvious, e.g. in early boot code. Just

Re: [patch 2/2] Documentation/process: Add tip tree handbook

2018-11-07 Thread Ingo Molnar
* Ingo Molnar wrote: > With tail comments the code looks like this: > > res = dostuff(); /* We explain something here. */ > > seed = 1; /* Another explanation. */ > > mod_timer(_object->our_timer, jiffies + OUR_INTERVAL); /* We like >

Re: [patch 2/2] Documentation/process: Add tip tree handbook

2018-11-07 Thread Ingo Molnar
* Thomas Gleixner wrote: > +Coding style notes > +-- > + > +Comment style > +^ > + > +Sentences in comments start with a uppercase letter. > + > +Single line comments:: > + > + /* This is a single line comment */ > + > +Multi-line comments:: > + > + /* > +

Re: [RFC PATCH v1 2/2] proc: add /proc//thread_state

2018-11-07 Thread Ingo Molnar
* Aubrey Li wrote: > Expose the per-task cpu specific thread state value, it's helpful > for userland to classify and schedule the tasks by different policies That's pretty vague - what exactly would use this information? I'm sure you have a usecase in mind - could you please describe it?

Re: [PATCH 0/3] x86/cpu: fix some prototype warning

2018-11-07 Thread Ingo Molnar
* Yi Wang wrote: > This series of patch fix some prototype warning because > of missing include file. > > Yi Wang (3): > x86/cpu: fix prototype warning in cacheinfo.c > x86/cpu: fix prototype warning in scattered.c > x86/cpu: fix prototype warning in topology.c > >

Re: [GIT PULL 00/18] perf/urgent improvements and fixes

2018-11-06 Thread Ingo Molnar
* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, mostly fixes, some late coming > improvements in non-core areas, > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit

Re: [patch 0/9] time: Add SPDX identifiers and cleanup boilerplates

2018-11-05 Thread Ingo Molnar
| 17 ++--- > kernel/time/timekeeping.c| 11 +++ > kernel/time/timekeeping_debug.c | 11 +-- > kernel/time/timer.c |3 +-- > kernel/time/timer_list.c |7 +-- > 25 files changed, 45 insertions(+), 198 deletions(-) Acked-by: Ingo Molnar Thanks, Ingo

Re: [PATCH v3] x86/vsmp_64.c: Remove dependency on pv_irq_ops

2018-11-05 Thread Ingo Molnar
* Eial Czerwacki wrote: > +#if defined(CONFIG_PCI) This is shorter: #ifdef CONFIG_PCI Thanks, Ingo

Re: [tip:x86/urgent] x86/vsmp: Remove dependency on pv_irq_ops

2018-11-05 Thread Ingo Molnar
* tip-bot for Eial Czerwacki wrote: > Commit-ID: 7f2d7f8190d856949d8aaab55d3902cd10ea1048 > Gitweb: > https://git.kernel.org/tip/7f2d7f8190d856949d8aaab55d3902cd10ea1048 > Author: Eial Czerwacki > AuthorDate: Mon, 5 Nov 2018 10:01:04 +0200 > Committer: Thomas Gleixner >

Re: [PATCH] x86/gart: Rewrite early_gart_iommu_check() comment

2018-11-05 Thread Ingo Molnar
* Borislav Petkov wrote: > From: Borislav Petkov > > ... to actually explain what the function is trying to do. > > Reported-by: Mike Rapoport > Signed-off-by: Borislav Petkov > --- > arch/x86/kernel/aperture_64.c | 25 +++-- > 1 file changed, 15 insertions(+), 10

  1   2   3   4   5   6   7   8   9   10   >