* 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
* 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
* 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
* 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
* 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
* 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
* 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
* 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
* 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
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:
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:
_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
_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
* 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
> >
* 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
> >
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
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
d via proper ordering
of functions from lower level to higher levels.
On the rest:
Reviewed-by: Ingo Molnar
Thanks,
Ingo
d via proper ordering
of functions from lower level to higher levels.
On the rest:
Reviewed-by: Ingo Molnar
Thanks,
Ingo
* 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:
>
* 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:
>
* 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
* 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
* 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
>
>
* 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
>
>
* 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
* 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
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
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
* 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
* 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
* 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
* 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
[ 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
[ 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
* 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
* 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
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
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
* 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
* 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
* 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
* 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
* 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
* 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
>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
>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
* 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
* 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
* 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
* 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
:
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
:
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
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
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
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
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
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
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
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
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
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
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
* 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%
* 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%
* 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
* 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
nd IBPB always mode.
>
> - Addressed the review comments
With the typo review feedback outlined in the discussions:
Reviewed-by: Ingo Molnar
Thanks,
Ingo
nd IBPB always mode.
>
> - Addressed the review comments
With the typo review feedback outlined in the discussions:
Reviewed-by: Ingo Molnar
Thanks,
Ingo
* 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
* 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
* 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
* 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
* 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
* 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
* 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)
> > >
* 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)
> > >
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
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
* 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
* 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
* 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,
* 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,
* 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
* 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
* 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
* 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
* 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
* 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
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
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
* 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
* 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
* 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
* 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
* 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
>
* 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
>
* 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
* 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
* 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
901 - 1000 of 32618 matches
Mail list logo
