On Thu, Apr 28, 2022 at 03:49:11PM -0500, Eric W. Biederman wrote:
> static void lock_parents_siglocks(bool lock_tracer)
> __releases(¤t->sighand->siglock)
> __acquires(¤t->sighand->siglock)
> __acquires(¤t->real_parent->sighand->siglock)
> __acquires(¤t->parent->sighand->s
"Eric W. Biederman" writes:
> Peter Zijlstra writes:
>
>> On Wed, Apr 27, 2022 at 09:47:10AM -0500, Eric W. Biederman wrote:
>>
>>> Hmm. If we have the following process tree.
>>>
>>> A
>>> \
>>> B
>>>\
>>> C
>>>
>>> Process A, B, and C are all in the same proce
On 04/28, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> >> The bug appears when the TRACEE makes it to schedule(). Inside
> >> schedule there is a call to signal_pending_state() which notices
> >> a SIGKILL is pending and refuses to sleep.
> >
> > And I think this is fine. This doesn't r
Peter Zijlstra writes:
> On Wed, Apr 27, 2022 at 09:47:10AM -0500, Eric W. Biederman wrote:
>
>> Hmm. If we have the following process tree.
>>
>> A
>> \
>> B
>>\
>> C
>>
>> Process A, B, and C are all in the same process group.
>> Process A and B are setup to re
On 04/28, Peter Zijlstra wrote:
>
> I've not had time to fully appreciate the nested locking here, but if it
> is possible to rework things to always take both locks at the same time,
> then it would be possible to impose an arbitrary lock order on things
> and break the cycle that way.
This is cl
On Wed, Apr 27, 2022 at 09:47:10AM -0500, Eric W. Biederman wrote:
> Hmm. If we have the following process tree.
>
> A
> \
> B
>\
> C
>
> Process A, B, and C are all in the same process group.
> Process A and B are setup to receive SIGCHILD when
> their process st
On 4/28/22 00:49, Guilherme G. Piccoli wrote:
> The panic notifiers' callbacks execute in an atomic context, with
> interrupts/preemption disabled, and all CPUs not running the panic
> function are off, so it's very dangerous to wait on a regular
> spinlock, there's a risk of deadlock.
>
> This pat
Oleg Nesterov writes:
> On 04/27, Eric W. Biederman wrote:
>>
>> "Eric W. Biederman" writes:
>>
>> > diff --git a/include/linux/sched/signal.h b/include/linux/sched/signal.h
>> > index 3c8b34876744..1947c85aa9d9 100644
>> > --- a/include/linux/sched/signal.h
>> > +++ b/include/linux/sched/signal
On Wed, Apr 27, 2022 at 07:49:15PM -0300, Guilherme G. Piccoli wrote:
> This patch renames the panic_notifier_list to panic_pre_reboot_list;
> the idea is that a subsequent patch will refactor the panic path
> in order to better split the notifiers, running some of them very
> early, some of them n
On 04/28, Peter Zijlstra wrote:
>
> On Thu, Apr 28, 2022 at 04:57:50PM +0200, Oleg Nesterov wrote:
>
> > > Shouldn't we then switch wait_task_inactive() so have & matching instead
> > > of the current ==.
> >
> > Sorry, I don't understand the context...
>
> This.. I've always found it strange to ha
On Thu, Apr 28, 2022 at 04:57:50PM +0200, Oleg Nesterov wrote:
> > Shouldn't we then switch wait_task_inactive() so have & matching instead
> > of the current ==.
>
> Sorry, I don't understand the context...
This.. I've always found it strange to have wti use a different matching
scheme from ttw
On 04/27, Eric W. Biederman wrote:
>
> "Eric W. Biederman" writes:
>
> > diff --git a/include/linux/sched/signal.h b/include/linux/sched/signal.h
> > index 3c8b34876744..1947c85aa9d9 100644
> > --- a/include/linux/sched/signal.h
> > +++ b/include/linux/sched/signal.h
> > @@ -437,7 +437,8 @@ extern
On 04/28, Peter Zijlstra wrote:
>
> On Thu, Apr 28, 2022 at 01:19:11PM +0200, Oleg Nesterov wrote:
> > > That is also the reason I couldn't do wait_task_inactive(task, 0)
> >
> > Ah, I din't notice this patch uses wait_task_inactive(child, 0),
> > I think it should do wait_task_inactive(child, __TA
On 4/27/22 5:49 PM, Guilherme G. Piccoli wrote:
This patch renames the panic_notifier_list to panic_pre_reboot_list;
the idea is that a subsequent patch will refactor the panic path
in order to better split the notifiers, running some of them very
early, some of them not so early [but still befor
On Thu, Apr 28, 2022 at 01:19:11PM +0200, Oleg Nesterov wrote:
> > That is also the reason I couldn't do wait_task_inactive(task, 0)
>
> Ah, I din't notice this patch uses wait_task_inactive(child, 0),
> I think it should do wait_task_inactive(child, __TASK_TRACED).
Shouldn't we then switch wait_
On 04/28, Peter Zijlstra wrote:
>
> On Wed, Apr 27, 2022 at 05:14:57PM +0200, Oleg Nesterov wrote:
> > On 04/26, Eric W. Biederman wrote:
> > >
> > > Asking wait_task_inactive to verify that tsk->__state == __TASK_TRACED
> > > was needed to detect the when ptrace_stop would decide not to stop
> > >
On Wed, Apr 27, 2022 at 05:14:57PM +0200, Oleg Nesterov wrote:
> On 04/26, Eric W. Biederman wrote:
> >
> > Asking wait_task_inactive to verify that tsk->__state == __TASK_TRACED
> > was needed to detect the when ptrace_stop would decide not to stop
> > after calling "set_special_state(TASK_TRACED)
On Tue, Apr 26, 2022 at 05:52:08PM -0500, Eric W. Biederman wrote:
> Now that siglock keeps tsk->parent and tsk->real_parent constant
> require that do_notify_parent_cldstop is called with tsk->siglock held
> instead of the tasklist_lock.
>
> As all of the callers of do_notify_parent_cldstop had t
On Tue, Apr 26, 2022 at 05:52:03PM -0500, Eric W. Biederman wrote:
> Rename send_signal send_signal_locked and make to make
> it usable outside of signal.c.
>
> Signed-off-by: "Eric W. Biederman"
> ---
> include/linux/signal.h | 2 ++
> kernel/signal.c| 24
> 2
On Tue, Apr 26, 2022 at 05:50:21PM -0500, Eric W. Biederman wrote:
> Peter Zijlstra has
> been rewriting the classic freezer and in earlier parts of this
> discussion so I presume it is also a problem for PREEMPT_RT.
Ah, the freezer thing is in fact a sched/arm64 issue, the common issue
betw
On 27/04/2022 23:49, Guilherme G. Piccoli wrote:
The goal of this new panic notifier is to allow its users to
register callbacks to run earlier in the panic path than they
currently do. This aims at informational mechanisms, like dumping
kernel offsets and showing device error data (in case it's
Hi Guilherme,
On 27/04/2022 23:49, Guilherme G. Piccoli wrote:
The panic notifier infrastructure executes registered callbacks when
a panic event happens - such callbacks are executed in atomic context,
with interrupts and preemption disabled in the running CPU and all other
CPUs disabled. That
22 matches
Mail list logo
