> On Jun 12, 2020, at 12:25 PM, Thomas Gleixner wrote:
>
> "Paul E. McKenney" writes:
>>> On Fri, Jun 12, 2020 at 10:49:53AM -0700, Paul E. McKenney wrote:
>>> I will therefore address this issue in a follow-on patch.
>>
>> I should add that -your- patch from yesterday did -not- cause this
t do anything stupid even
> if rcu_irq_enter() has not been invoked.
Acked-by: Andy Lutomirski
> On Jun 12, 2020, at 2:01 AM, Thomas Gleixner wrote:
>
> Andy Lutomirski writes:
>> On Thu, Jun 11, 2020 at 4:22 PM Andy Lutomirski wrote:
>>
>> Two bugs here.
>>
>> 1. We had an issue with WARN. Patch sent.
>
> Grabbed it
>
&
On Thu, Jun 11, 2020 at 4:53 PM Paul E. McKenney wrote:
>
> RCU needs to detect when one if its interrupt handlers interrupted an idle
> state, where an idle state is either the idle loop itself or nohz_full
> userspace execution. When a CPU has been interrupted from one of these
> idle states,
On Thu, Jun 11, 2020 at 8:26 PM Andy Lutomirski wrote:
>
> If we BUG or WARN in a funny RCU context, we cleverly optimize the
> BUG/WARN using the ud2 hack, which takes us through the
> idtentry_enter...() paths, which might helpfully WARN that the RCU
> context is invalid
On Thu, Jun 11, 2020 at 4:22 PM Andy Lutomirski wrote:
>
> On Thu, Jun 11, 2020 at 12:25 PM Peter Zijlstra wrote:
> >
> > On Thu, Jun 11, 2020 at 12:10:50PM -0700, Andy Lutomirski wrote:
> > > On Thu, Jun 11, 2020 at 11:56 AM Naresh Kamboju
> > > wrote:
>
()/nmi_exit() path in
exc_invalid_op() to increase the chance that we survive the
experience.
Signed-off-by: Andy Lutomirski
---
This is not as well tested as I would like, but it does cause the splat
I'm chasing to display a nice warning instead of causing an undebuggable
stack overflow.
(It would
On Thu, Jun 11, 2020 at 12:25 PM Peter Zijlstra wrote:
>
> On Thu, Jun 11, 2020 at 12:10:50PM -0700, Andy Lutomirski wrote:
> > On Thu, Jun 11, 2020 at 11:56 AM Naresh Kamboju
> > wrote:
> > >
> > > While running perf test and selftest x86 single_step_s
On Thu, Jun 11, 2020 at 11:56 AM Naresh Kamboju
wrote:
>
> While running perf test and selftest x86 single_step_syscall_32 on
> i386 kernel linux
> next 5.7.0-next-20200610 kernel warning noticed.
>
> steps to reproduce:
> --
> perf test
> and
> cd
On Thu, Jun 11, 2020 at 10:00 AM Sean Christopherson
wrote:
>
> On Thu, Jun 11, 2020 at 12:33:20PM -0400, David P. Reed wrote:
> > To respond to Thomas Gleixner's suggestion about exception masking mechanism
> > - it may well be a better fix, but a) I used "BUG" as a model, and b) the
> >
> On Jun 11, 2020, at 2:18 AM, Borislav Petkov wrote:
>
> On Thu, Jun 11, 2020 at 10:36:08AM +0300, Petteri Aimonen wrote:
>> Hi,
>>
>>> How about putting the file you frob in
>>> /sys/kernel/debug/selftest_helpers/something_or_other. The idea would
>>> be that
On Wed, Jun 10, 2020 at 5:00 PM Sean Christopherson
wrote:
>
> On Wed, Jun 10, 2020 at 02:59:19PM -0700, Andy Lutomirski wrote:
> >
> >
> > > On Jun 10, 2020, at 11:21 AM, David P. Reed wrote:
> > >
> > > If a panic/reboot occurs when CR4 has VM
> On Jun 10, 2020, at 11:21 AM, David P. Reed wrote:
>
> If a panic/reboot occurs when CR4 has VMX enabled, a VMXOFF is
> done on all CPUS, to allow the INIT IPI to function, since
> INIT is suppressed when CPUs are in VMX root operation.
> However, VMXOFF causes an undefined operation fault
On Thu, Jun 4, 2020 at 6:35 AM Peter Zijlstra wrote:
>
> On Thu, Jun 04, 2020 at 03:29:26PM +0200, Paolo Bonzini wrote:
> > On 04/06/20 15:25, Peter Zijlstra wrote:
> > > It being enabled through IA32_DEBUGCTL instead of through DR7 means that
> > > the current code doesn't disable it and this
On Wed, Jun 3, 2020 at 5:12 PM Ricardo Neri
wrote:
>
> On Tue, Jun 02, 2020 at 11:42:12AM -0700, Brendan Shanks wrote:
> > Add emulation/spoofing of SLDT and STR for both 32- and 64-bit
> > processes.
> >
> > Wine users have found a small number of Windows apps using SLDT that
> > were crashing
> On Jun 2, 2020, at 10:27 AM, Shuah Khan wrote:
>
> On 6/2/20 11:03 AM, Andy Lutomirski wrote:
>>> On Tue, Jun 2, 2020 at 3:56 AM Borislav Petkov wrote:
>>>
>>> Hi,
>>>
>>> On Tue, Jun 02, 2020 at 01:29:51PM +0300, Petteri Aim
On Tue, Jun 2, 2020 at 3:56 AM Borislav Petkov wrote:
>
> Hi,
>
> On Tue, Jun 02, 2020 at 01:29:51PM +0300, Petteri Aimonen wrote:
> > The kernel module is not actually x86-specific, even though it is
> > currently only enabled for x86. amdgpu driver already does kernel mode
> > floating point
> On Jun 1, 2020, at 5:14 PM, Daniel P. Smith
> wrote:
>
> On 6/1/20 3:39 PM, Andy Lutomirski wrote:
>>>> .
>
> In other words, the log for the relaunch to attest what is currently
> running is really no less useful than using the first launch log to
On Mon, Jun 1, 2020 at 1:08 PM Kees Cook wrote:
>
> On Sun, May 31, 2020 at 02:03:48PM -0700, Andy Lutomirski wrote:
> > On Sun, May 31, 2020 at 11:57 AM Andy Lutomirski wrote:
> > >
> > >
> > > What if there was a special filter type that ran a BPF program
> On Jun 1, 2020, at 10:56 AM, Daniel P. Smith
> wrote:
>
> On 6/1/20 12:51 PM, Andy Lutomirski wrote:
>>> On Mon, Jun 1, 2020 at 8:33 AM Daniel P. Smith
>>> wrote:
>>>
>>> On 5/7/20 7:06 AM, Daniel Kiper wrote:
>>>> Hi Łukasz,
On Mon, Jun 1, 2020 at 8:33 AM Daniel P. Smith
wrote:
>
> On 5/7/20 7:06 AM, Daniel Kiper wrote:
> > Hi Łukasz,
> >
> > On Tue, May 05, 2020 at 04:38:02PM +0200, Lukasz Hawrylko wrote:
> >> On Tue, 2020-05-05 at 01:21 +0200, Daniel Kiper wrote:
>
> ...
>
> >> In OS-MLE table there is a buffer for
> On Jun 1, 2020, at 2:23 AM, Billy Laws wrote:
>
>
>>
>> On May 30, 2020, at 5:26 PM, Gabriel Krisman Bertazi
>> wrote:
>>
>> Andy Lutomirski writes:
>>
>>>>>> On May 29, 2020, at 11:00 PM, Gabriel Krisman Be
> On May 31, 2020, at 4:50 PM, Brendan Shanks wrote:
>
>
>> On May 31, 2020, at 11:57 AM, Andy Lutomirski wrote:
>>
>> Using SECCOMP_RET_USER_NOTIF is likely to be considerably more
>> expensive than my scheme. On a non-PTI system, my approach will add a
On Sun, May 31, 2020 at 11:57 AM Andy Lutomirski wrote:
>
>
> What if there was a special filter type that ran a BPF program on each
> syscall, and the program was allowed to access user memory to make its
> decisions, e.g. to look at some list of memory addresses. But this
>
On Sun, May 31, 2020 at 11:36 AM Paul Gofman wrote:
>
> On 5/31/20 21:10, Andy Lutomirski wrote:
> >
> > That's not what I meant. I meant that you would set the kernel up to
> > redirect *all* syscalls from the thread with the sole exception of one
> > sy
On Sun, May 31, 2020 at 5:56 AM Paul Gofman wrote:
>
> On 5/31/20 03:59, Andy Lutomirski wrote:
> >
> > I’m suggesting that the kernel learn how to help you, maybe like this:
> >
> > prctl(PR_SET_SYSCALL_THUNK, target, address_of_unredirected_syscall, 0, 0,
> On May 30, 2020, at 5:26 PM, Gabriel Krisman Bertazi
> wrote:
>
> Andy Lutomirski writes:
>
>>>> On May 29, 2020, at 11:00 PM, Gabriel Krisman Bertazi
>>>> wrote:
>>>
>>> Modern Windows applications are executing system c
> On May 29, 2020, at 11:00 PM, Gabriel Krisman Bertazi
> wrote:
>
> Modern Windows applications are executing system call instructions
> directly from the application's code without going through the WinAPI.
> This breaks Wine emulation, because it doesn't have a chance to
> intercept and
On Fri, May 29, 2020 at 1:26 AM Lai Jiangshan wrote:
>
> 7f2590a110b8("x86/entry/64: Use a per-CPU trampoline stack for IDT entries")
> has resulted that when exception on userspace, the kernel (error_entry)
> always push the pt_regs to entry stack(sp0), and then copy them to the
> kernel stack.
_CR3") for
> kernel CR3.
>
> Patch 2 *reverts* 21e944591102("x86/mm: Optimize RESTORE_CR3") for
> User CR3.
This series looks correct, but I don't think it's 5.8 material. I
also want to try moving all this code to C, so it's possible this
little series will become obsole
> On May 28, 2020, at 2:34 PM, Peter Zijlstra wrote:
>
> On Thu, May 28, 2020 at 11:15:50PM +0200, Peter Zijlstra wrote:
>>> On Thu, May 28, 2020 at 09:52:30PM +0100, Andrew Cooper wrote:
>>> On 28/05/2020 21:19, Peter Zijlstra wrote:
--- a/arch/x86/include/asm/debugreg.h
+++
> On May 29, 2020, at 4:30 AM, Daniel Kiper wrote:
>
> Hey,
>
> Below you can find my rough idea of the bootloader log format which is
> generic thing but initially will be used for TrenchBoot work. I discussed
> this proposal with Ross and Daniel S. So, the idea went through initial
>
> On May 28, 2020, at 10:40 AM, Don Porter wrote:
>
> Hi Thomas,
>
> On 5/28/20 6:29 AM, Thomas Gleixner wrote:
>>> Until recently, we were doing proof-of-concept research, not product
>>> development, and there are limited hours in the day. I also hasten to
>>> say that the product of
; 0
[SKIP] Illegal instruction
A failed run causes a kernel hang, and I believe it's because we
double-fault and then get a never ending series of page faults and,
when we exhaust the double fault stack we double fault again,
starting the process over.
Signed-off-by: Andy Lutomir
[cc Andrew Cooper and Dave Hansen]
On Fri, May 15, 2020 at 7:35 PM Nicholas Piggin wrote:
>
> Excerpts from Rik van Riel's message of May 16, 2020 5:24 am:
> > On Fri, 2020-05-15 at 16:50 +1000, Nicholas Piggin wrote:
> >>
> >> But what about if there are (real, not speculative) stores in the
>
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 700d3a5a664df267f01ec8887fd2d8ff98f67e7f
Gitweb:
https://git.kernel.org/tip/700d3a5a664df267f01ec8887fd2d8ff98f67e7f
Author:Andy Lutomirski
AuthorDate:Fri, 08 May 2020 17:25:32 -07:00
On Mon, May 25, 2020 at 9:31 PM Lai Jiangshan
wrote:
>
> On Tue, May 26, 2020 at 12:21 PM Andy Lutomirski wrote:
> >
> > On Mon, May 25, 2020 at 6:42 PM Lai Jiangshan
> > wrote:
> > >
> > > The percpu user_pcid_flush_mask is used for CPU entry
>
On Thu, May 21, 2020 at 1:31 PM Thomas Gleixner wrote:
>
> Folks!
>
> This is V9 of the rework series. V7 and V8 were never posted but I used the
> version numbers for tags while fixing up 0day complaints. The last posted
> version was V6 which can be found here:
The whole pile
On Mon, May 25, 2020 at 6:42 PM Lai Jiangshan wrote:
>
> The percpu user_pcid_flush_mask is used for CPU entry
> If a data breakpoint on it, it will cause an unwanted #DB.
> Protect the full cpu_tlbstate structure to be sure.
>
> There are some other percpu data used in CPU entry, but they are
>
> On May 25, 2020, at 4:01 AM, Peter Zijlstra wrote:
>
> On Mon, May 25, 2020 at 12:40:38PM +0200, Peter Zijlstra wrote:
>>> On Mon, May 25, 2020 at 12:02:48PM +0200, Rasmus Villemoes wrote:
>>>
>>> Naive question: did you check disassembly to see whether gcc threw your
>>>
On Sat, May 23, 2020 at 8:57 AM Arvind Sankar wrote:
>
> Hi,
>
> I have a question about the state of the upper 32 bits of the general
> purpose registers following a switch from/to 64-bit mode.
>
> Both the AMD [0] and Intel [1] manuals state that these bits are
> undefined following a switch
> On May 22, 2020, at 3:20 PM, Sean Christopherson
> wrote:
>
> On Fri, May 22, 2020 at 03:13:57PM -0700, Andy Lutomirski wrote:
>>> On Fri, May 22, 2020 at 1:49 PM Peter Zijlstra wrote:
>>>
>>> Hai, this kills #DB during NMI/#MC and with that all
On Fri, May 22, 2020 at 1:49 PM Peter Zijlstra wrote:
>
> Hai, this kills #DB during NMI/#MC and with that allows removing all the nasty
> IST rewrite crud.
>
This is great, except that the unconditional DR7 write is going to
seriously hurt perf performance. Fortunately, no one cares about
> On May 20, 2020, at 5:55 PM, Ricardo Neri
> wrote:
>
> On Tue, May 19, 2020 at 05:54:53PM -0700, Andy Lutomirski wrote:
>>> On Tue, May 19, 2020 at 12:43 PM Ricardo Neri
>>> wrote:
>>>
>>> On Tue, May 19, 2020 at 11:56:40AM -0700, Brendan
On Wed, May 20, 2020 at 12:17 PM Thomas Gleixner wrote:
>
> Andy Lutomirski writes:
> > Andrew Cooper pointed out that there is too much magic in Xen for this
> > to work. So never mind.
>
> :)
>
> But you made me stare more at that stuff and I came up with a way
> On May 20, 2020, at 1:10 PM, Thomas Gleixner wrote:
>
> Peter Zijlstra writes:
>>> On Mon, May 18, 2020 at 10:05:56AM +0200, Thomas Gleixner wrote:
>>> Peter Zijlstra writes:
On Sat, May 16, 2020 at 01:45:51AM +0200, Thomas Gleixner wrote:
> --- a/arch/x86/kernel/nmi.c
> +++
On Wed, May 20, 2020 at 10:38 AM Paul E. McKenney wrote:
>
> On Wed, May 20, 2020 at 08:36:06AM -0700, Andy Lutomirski wrote:
> > On Tue, May 19, 2020 at 7:23 PM Paul E. McKenney wrote:
> > > On Tue, May 19, 2020 at 05:26:58PM -0700, Andy Lutomirski wrote:
> > > >
On Wed, May 20, 2020 at 8:16 AM Andy Lutomirski wrote:
>
> On Wed, May 20, 2020 at 7:13 AM Thomas Gleixner wrote:
> >
> > Andy Lutomirski writes:
> > > On Tue, May 19, 2020 at 11:58 AM Thomas Gleixner
> > > wrote:
> > >> Which brings you
On Wed, May 20, 2020 at 8:17 AM Thomas Gleixner wrote:
>
> Andy Lutomirski writes:
>
> > On Fri, May 15, 2020 at 5:11 PM Thomas Gleixner wrote:
> >
> > I think something's missing here. With this patch applied, don't we
> > get to exc_debug_kernel(
On Wed, May 20, 2020 at 8:36 AM Andy Lutomirski wrote:
>
> On Tue, May 19, 2020 at 7:23 PM Paul E. McKenney wrote:
> >
> > On Tue, May 19, 2020 at 05:26:58PM -0700, Andy Lutomirski wrote:
> > > On Tue, May 19, 2020 at 2:20 PM Thomas Gleixner
> > > wrote
On Wed, May 20, 2020 at 8:27 AM Thomas Gleixner wrote:
>
> Andy Lutomirski writes:
> > On Wed, May 20, 2020 at 5:35 AM Thomas Gleixner wrote:
> >>
> >> Andy Lutomirski writes:
> >> > On Mon, May 18, 2020 at 4:53 PM Thomas Gleixner
> >&g
On Tue, May 19, 2020 at 7:23 PM Paul E. McKenney wrote:
>
> On Tue, May 19, 2020 at 05:26:58PM -0700, Andy Lutomirski wrote:
> > On Tue, May 19, 2020 at 2:20 PM Thomas Gleixner wrote:
> > >
> > > Andy Lutomirski writes:
> > > > On Tue, May 19, 2020
On Wed, May 20, 2020 at 7:13 AM Thomas Gleixner wrote:
>
> Andy Lutomirski writes:
> > On Tue, May 19, 2020 at 11:58 AM Thomas Gleixner wrote:
> >> Which brings you into the situation that you call schedule() from the
> >> point where we just moved it out.
On Wed, May 20, 2020 at 5:35 AM Thomas Gleixner wrote:
>
> Andy Lutomirski writes:
> > On Mon, May 18, 2020 at 4:53 PM Thomas Gleixner wrote:
> >>
> >> Andy Lutomirski writes:
> >> > Actually, I revoke my ack. Can you make one of two changes
On Mon, May 18, 2020 at 6:35 PM Andy Lutomirski wrote:
>
>
>
> > On May 18, 2020, at 5:38 PM, Dave Hansen wrote:
> >
> > On 5/18/20 4:47 PM, Yu-cheng Yu wrote:
> >>> On Fri, 2020-05-15 at 19:53 -0700, Yu-cheng Yu wrote:
> >>> On Fri, 2020-05-1
On Tue, May 19, 2020 at 12:43 PM Ricardo Neri
wrote:
>
> On Tue, May 19, 2020 at 11:56:40AM -0700, Brendan Shanks wrote:
> >
> > > On May 19, 2020, at 7:38 AM, Andreas Rammhold wrote:
> > >
> > > Hi,
> > >
> > > I've been running into a weird problem with UMIP on a current Ryzen
> > > 3900x with
On Fri, May 15, 2020 at 5:11 PM Thomas Gleixner wrote:
>
I think something's missing here. With this patch applied, don't we
get to exc_debug_kernel() -> handle_debug() without doing
idtentry_enter() or equivalent? And that can even enable IRQs.
Maybe exc_debug_kernel() should wrap
stacks in DEBUG when calling
> lockdep")
Acked-by: Andy Lutomirski
On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
>
>
> All exceptions/interrupts return with interrupts disabled now. No point in
> doing this in ASM again.
Acked-by: Andy Lutomirski
On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
>
>
> The ASM users are gone. All callers are local.
Acked-by: Andy Lutomirski
On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
>
Acked-by: Andy Lutomirski
e while at it.
Acked-by: Andy Lutomirski
64bit
> - Remove the BUILD_INTERRUPT entries in 32bit
> - Remove the old prototypes
>
> No functional change.
Acked-by: Andy Lutomirski
64bit
> - Remove the BUILD_INTERRUPT entries in 32bit
> - Remove the old prototypes
Acked-by: Andy Lutomirski
64bit
> - Remove the BUILD_INTERRUPT entries in 32bit
> - Remove the old prototypes
>
> No functional change.
Acked-by: Andy Lutomirski
The wakeup handler does more work and runs on the interrupt stack.
>
> None of these handlers need to save and restore the irq_regs pointer.
Acked-by: Andy Lutomirski
te the system vectors w/o stack switching as before. As some of the
> system vector handlers require access to pt_regs this requires a new stack
> switching macro which can handle an argument.
Is that last sentence obsolete?
Otherwise,
Acked-by: Andy Lutomirski
e the BUILD_INTERRUPT entries in 32bit
> - Remove the old prototypes
Acked-by: Andy Lutomirski
e the BUILD_INTERRUPT entries in 32bit
> - Remove the old prototypes
>
> No functional change.
>
Acked-by: Andy Lutomirski
On Tue, May 19, 2020 at 2:20 PM Thomas Gleixner wrote:
>
> Andy Lutomirski writes:
> > On Tue, May 19, 2020 at 1:20 PM Thomas Gleixner wrote:
> >> Thomas Gleixner writes:
> >> It's about this:
> >>
> >> rcu_nmi_enter()
> >> {
>
observes the correct preempt count
> state.
Leftover text from an old version?
The code is Reviewed-by: Andy Lutomirski
On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
>
>
> Replace the extra interrupt handling code and reuse the existing idtentry
> machinery. This moves the irq stack switching on 64 bit from ASM to C code;
> 32bit already does the stack switching in C.
Acked-by: Andy Lutomirski
truncates the sign extended vector number.
Acked-by: Andy Lutomirski
with a minor minor optimization suggestion:
> +.macro idtentry_irq vector cfunc
> + .p2align CONFIG_X86_L1_CACHE_SHIFT
> +SYM_CODE_START_LOCAL(asm_\cfunc)
> + ASM_CLAC
> + SAVE_ALL switch_stacks
On Tue, May 19, 2020 at 1:20 PM Thomas Gleixner wrote:
>
> Thomas Gleixner writes:
> > Andy Lutomirski writes:
> >> On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
> >>> The pagefault handler cannot use the regular idtentry_enter() because
ng by
> reusing the idtentry machinery both in ASM and C.
Reviewed-by: Andy Lutomirski
>
> Signed-off-by: Thomas Gleixner
>
> diff --git a/arch/x86/kernel/irq_64.c b/arch/x86/kernel/irq_64.c
> index 62cff52e03c5..6087164e581c 100644
> --- a/arch/x86/kernel/irq_64.c
> +++ b/arc
tending the resulting error code needs to be truncated
> to 8 bits in C code.
Acked-by: Andy Lutomirski
although you may be giving me more credit than deserved :)
+ .align 8
> +SYM_CODE_START(irq_entries_start)
> +vector=FIRST_EXTERNAL_VECTOR
> +.rept (FIRST_SYST
On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
>
>
> No more users.
Acked-by: Andy Lutomirski
On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
>
>
> No more users.
Acked-by: Andy Lutomirski
2 injects a #GP which kills the task
>
> For #1 there is no reason to go through the full exception return path
> because the tasks TIF state is still the same. So just going straight to
> the IRET path is good enough.
Seems reasonable:
Acked-by: Andy Lutomirski
Although a look from a Xen person might be nice too.
On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
>
>
> Now that all exceptions are converted over the sane flag is not longer
> needed. Also the vector argument of idtentry_body on 64 bit is pointless
> now.
Acked-by: Andy Lutomirski
in 32bit
> - Fixup the XEN/PV code
> - Remove the old prototypes
>
Acked-by: Andy Lutomirski
although if you make the irq_enter_cond_rcu() mode unconditional, then
this comment can go away too:
> + /*
> +* Entry handling for valid #PF from kernel mode is sligh
The following commit has been merged into the x86/entry branch of tip:
Commit-ID: 3ea11ac991d594728e5df42f7eb1145072b9c2bc
Gitweb:
https://git.kernel.org/tip/3ea11ac991d594728e5df42f7eb1145072b9c2bc
Author:Andy Lutomirski
AuthorDate:Mon, 24 Feb 2020 13:24:58 +01:00
The following commit has been merged into the x86/entry branch of tip:
Commit-ID: ef68017eb5704eb2b0577c3aa6619e13caf2b59f
Gitweb:
https://git.kernel.org/tip/ef68017eb5704eb2b0577c3aa6619e13caf2b59f
Author:Andy Lutomirski
AuthorDate:Fri, 28 Feb 2020 10:42:48 -08:00
On Tue, May 19, 2020 at 11:58 AM Thomas Gleixner wrote:
>
> Andy Lutomirski writes:
> > On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
> >> @@ -573,6 +578,16 @@ static __always_inline void __idtentry_exit(struc
On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
>
>
> The pagefault handler cannot use the regular idtentry_enter() because that
> invokes rcu_irq_enter() if the pagefault was caused in the kernel. Not a
> problem per se, but kernel side page faults can schedule which is not
> possible
On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
>
>
> All C functions which do not have an error code have been converted to the
> new IDTENTRY interface which does not expect an error code in the
> arguments. Spare the XORL.
Acked-by: Andy Lutomirski
On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
>
>
> Convert the XEN/PV hypercall to IDTENTRY:
>
> - Emit the ASM stub with DECLARE_IDTENTRY
> - Remove the ASM idtentry in 64bit
> - Remove the open coded ASM entry code in 32bit
> - Remove the old prototypes
>
> The handler stubs
> On May 18, 2020, at 5:38 PM, Dave Hansen wrote:
>
> On 5/18/20 4:47 PM, Yu-cheng Yu wrote:
>>> On Fri, 2020-05-15 at 19:53 -0700, Yu-cheng Yu wrote:
>>> On Fri, 2020-05-15 at 16:56 -0700, Dave Hansen wrote:
On 5/15/20 4:29 PM, Yu-cheng Yu wrote:
> [...]
> I have run them with
On Mon, May 18, 2020 at 4:53 PM Thomas Gleixner wrote:
>
> Andy Lutomirski writes:
> > Actually, I revoke my ack. Can you make one of two changes:
> >
> > Option A: Add an assertion to run_on_irqstack to verify that irq_count
> > was -1 at the beginning? I sup
On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
>
>
> Split the implementation of idtentry_enter/exit() out into inline functions
> so that variants of idtentry_enter/exit() can be implemented without
> duplicating code.
>
After reading just this patch, I don't see how it helps anything.
On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
>
>
> The first step to get rid of the ENTER/LEAVE_IRQ_STACK ASM macro maze. Use
> the new C code helpers to move do_softirq_own_stack() out of ASM code.
>
> Signed-off-by: Thomas Gleixner
>
> diff --git a/arch/x86/entry/entry_64.S
On Mon, May 18, 2020 at 4:11 PM Andy Lutomirski wrote:
>
> On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
> >
> >
> > Device interrupt handlers and system vector handlers are executed on the
> > interrupt stack. The stack switch happens in the low
64 bit only for now. 32 bit has a variant of that already. Once this is
> cleaned up the two implementations might be consolidated as a cleanup on
> top.
>
Acked-by: Andy Lutomirski
Have you tested by forcing a stack trace from the IRQ stack and making
sure it unwinds all the way out?
On Fri, May 15, 2020 at 5:11 PM Thomas Gleixner wrote:
>
>
> No more users.
Hallelujah!
Acked-by: Andy Lutomirski
>
On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
>
Reviewed-by: Andy Lutomirski
On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
>
>
> irq_enter()/exit() include the RCU handling. To properly separate the RCU
> handling provide variants which contain only the non-RCU related
> functionality.
Reviewed-by: Andy Lutomirski
On Mon, May 18, 2020 at 2:05 PM Kees Cook wrote:
>
> Hi!
>
This is minor, but, if we grow seccomp_data, I would like to add the
other 32 bits of the syscall nr to it. Syscall numbers are unsigned
long, but they get munged into u32 for seccomp_data.
Sure, no one uses those high bits yet, but if
On Mon, May 18, 2020 at 1:50 AM Anastassios Nanos
wrote:
>
> On Mon, May 18, 2020 at 10:50 AM Marc Zyngier wrote:
> >
> > On 2020-05-18 07:58, Anastassios Nanos wrote:
> > > To spawn KVM-enabled Virtual Machines on Linux systems, one has to use
> > > QEMU, or some other kind of VM monitor in
On Mon, May 18, 2020 at 1:03 AM Thomas Gleixner wrote:
>
> Andy Lutomirski writes:
> > On Sun, May 17, 2020 at 1:48 AM Thomas Gleixner wrote:
> >> Remember this is about ensuring that all the state is properly
> >> established before any of this instrumentation
On Sun, May 17, 2020 at 1:48 AM Thomas Gleixner wrote:
>
> Andy Lutomirski writes:
> > On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
> >>
> >>
> >> The hardware latency tracer calls into trace_sched_clock and ends up in
> >> various i
801 - 900 of 19466 matches
Mail list logo
