On 09/05/2022 12:52, Sean Christopherson wrote:
> I find the shortlog to be very confusing, the bug has nothing to do with
> disabling
> VMX and I distinctly remember wrapping VMXOFF with exception fixup to prevent
> doom
> if VMX is already disabled :-). The issue is really that
> nmi_shootdow
On 2022-05-10, Steven Rostedt wrote:
>> As already mentioned in the other reply, panic() sometimes stops the
>> other CPUs using NMI, for example, see kdump_nmi_shootdown_cpus().
>>
>> Another situation is when the CPU using the lock ends in some
>> infinite loop because something went wrong. The
On Wed, 27 Apr 2022 19:49:17 -0300
"Guilherme G. Piccoli" wrote:
> Currently we don't have a way to check if there are dumpers set,
> except counting the list members maybe. This patch introduces a very
> simple helper to provide this information, by just keeping track of
> registered/unregistere
On Thu, 28 Apr 2022 09:01:13 +0800
Xiaoming Ni wrote:
> > +#ifdef CONFIG_DEBUG_NOTIFIERS
> > + {
> > + char sym_name[KSYM_NAME_LEN];
> > +
> > + pr_info("notifiers: registered %s()\n",
> > + notifier_name(n, sym_name));
> > + }
>
> Duplicate Code.
>
>
On Tue, 10 May 2022 13:38:39 +0200
Petr Mladek wrote:
> As already mentioned in the other reply, panic() sometimes stops
> the other CPUs using NMI, for example, see kdump_nmi_shootdown_cpus().
>
> Another situation is when the CPU using the lock ends in some
> infinite loop because something we
On 10/05/2022 12:16, Petr Mladek wrote:
> [...]
> Hmm, this looks like a hack. PANIC_UNUSED will never be used.
> All notifiers will be always called with PANIC_NOTIFIER.
>
> The @val parameter is normally used when the same notifier_list
> is used in different situations.
>
> But you are going t
On 05/10, Eric W. Biederman wrote:
>
> > But I still think that a lockless
> >
> > if (!(task->jobctl & JOBCTL_PTRACE_FROZEN))
> > return;
> >
> > check at the start of ptrace_unfreeze_traced() makes sense to avoid
> > lock_task_sighand() if possible.
> >
> > And ptrace_resume() can
Sebastian Andrzej Siewior writes:
> On 2022-05-10 09:26:36 [-0500], Eric W. Biederman wrote:
>> Does anyone else have any comments on this patchset?
>>
>> If not I am going to apply this to a branch and get it into linux-next.
>
> Looks good I guess.
> Be aware that there will be clash due to
>
Oleg Nesterov writes:
> On 05/05, Eric W. Biederman wrote:
>>
>> static void ptrace_unfreeze_traced(struct task_struct *task)
>> {
>> -if (READ_ONCE(task->__state) != __TASK_TRACED)
>> -return;
>> -
>> -WARN_ON(!task->ptrace || task->parent != current);
>> +unsigned long
On 2022-05-10 09:26:36 [-0500], Eric W. Biederman wrote:
> Does anyone else have any comments on this patchset?
>
> If not I am going to apply this to a branch and get it into linux-next.
Looks good I guess.
Be aware that there will be clash due to
https://lore.kernel.org/all/1649240981-11024
Oleg Nesterov writes:
> On 05/05, Eric W. Biederman wrote:
>>
>> Eric W. Biederman (11):
>> signal: Rename send_signal send_signal_locked
>> signal: Replace __group_send_sig_info with send_signal_locked
>> ptrace/um: Replace PT_DTRACE with TIF_SINGLESTEP
>> ptrace/xtensa:
On 05/05, Eric W. Biederman wrote:
>
> static void ptrace_unfreeze_traced(struct task_struct *task)
> {
> - if (READ_ONCE(task->__state) != __TASK_TRACED)
> - return;
> -
> - WARN_ON(!task->ptrace || task->parent != current);
> + unsigned long flags;
>
> /*
> -
On 10/05/2022 10:53, Michael Ellerman wrote:
> "Guilherme G. Piccoli" writes:
>> On 05/05/2022 15:55, Hari Bathini wrote:
>>> [...]
>>> The change looks good. I have tested it on an LPAR (ppc64).
>>>
>>> Reviewed-by: Hari Bathini
>>>
>>
>> Hi Michael. do you think it's possible to add this one t
On 05/05, Eric W. Biederman wrote:
>
> Eric W. Biederman (11):
> signal: Rename send_signal send_signal_locked
> signal: Replace __group_send_sig_info with send_signal_locked
> ptrace/um: Replace PT_DTRACE with TIF_SINGLESTEP
> ptrace/xtensa: Replace PT_SINGLESTEP with TIF_S
"Guilherme G. Piccoli" writes:
> On 05/05/2022 15:55, Hari Bathini wrote:
>> [...]
>> The change looks good. I have tested it on an LPAR (ppc64).
>>
>> Reviewed-by: Hari Bathini
>>
>
> Hi Michael. do you think it's possible to add this one to powerpc/next
> (or something like that), or do you
On 10/05/2022 08:38, Petr Mladek wrote:
> [...]
> I see two more alternative solutions:
>
> 1st variant is a trick already used in console write() callbacks.
> They do trylock() when oops_in_progress is set. They remember
> the result to prevent double unlock when printing Oops messages and
> the
On 10/05/2022 09:14, Petr Mladek wrote:
> [...]
>> With that said, it's dangerous to use regular spinlocks in such path,
>> as introduced by commit b3c0f8774668 ("misc/pvpanic: probe multiple
>> instances").
>> This patch fixes that by replacing regular spinlocks with the trylock
>> safer approach
17 matches
Mail list logo
