Messages in this thread | | | Date | Mon, 20 Jul 2020 08:56:33 +0200 | From | Oleg Nesterov <> | Subject | Re: 5.8-rc*: kernel BUG at kernel/signal.c:1917 |
| |
On 07/20, Jiri Slaby wrote: > > On 18. 07. 20, 19:14, Oleg Nesterov wrote: > > > > This is already wrong. But > > > > Where does this __might_sleep() come from ??? I ses no blocking calls > > in ptrace_stop(). Not to mention it is called with ->siglock held and > > right after this lock is dropped we take tasklist_lock. > > Decoded stacktrace: > > > ptrace_stop (include/linux/freezer.h:57 include/linux/freezer.h:67 include/linux/freezer.h:128 include/linux/freezer.h:173 kernel/signal.c:2217) > > ptrace_do_notify (kernel/signal.c:2272) > > ptrace_notify (arch/x86/include/asm/paravirt.h:656 arch/x86/include/asm/qspinlock.h:55 include/linux/spinlock.h:211 include/linux/spinlock_api_smp.h:167 include/linux/spinlock.h:403 kernel/signal.c:2282) > > syscall_trace_enter (include/linux/tracehook.h:73 include/linux/tracehook.h:104 arch/x86/entry/common.c:159) > > do_syscall_64 (arch/x86/entry/common.c:380) > > entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:124) > > It is try_to_freeze_unsafe in try_to_freeze in freezable_schedule in > ptrace_stop.
Aha, thanks a lot!
try_to_freeze_unsafe() is called after schedule() which must return with ->state = RUNNING, so this matches another WARN_ON(current->state) added by debugging patch after freezable_schedule().
Somehow I decided __might_sleep() was called before read_unlock/schedule.
> > > > How this connects to the debugging patch I sent? Did you see this warning > > without that patch? > > I suppose this made it appear: > +CONFIG_PREEMPT_COUNT=y > -# CONFIG_DEBUG_ATOMIC_SLEEP is not set > +CONFIG_DEBUG_ATOMIC_SLEEP=y
I see,
> Please see my other e-mail, all this is with dbfb089d360b applied. Maybe > it makes more sense now?
Yes. Thanks Jiri!
Oleg.
| |