On 2020-11-02 18:41:31 [+0100], Oleg Nesterov wrote: > Sorry, I don't understand. If it was not clear, let me repeat that I know > nothing about kernel-rt. That is why I said, if you don't want to continue just complain and leave it to me. Also, I could explain things if you want me to. > On 11/02, Sebastian Andrzej Siewior wrote: > > On 2020-11-02 18:01:33 [+0100], Oleg Nesterov wrote: > > > > > So it seems I should send V2 which uses raw_spin_(un)lock_irq(). > > > > > > Or even _irqsave() like ptrace_freeze_traced() does? Although this looks > > > confusing, exactly because ptrace_freeze_traced() calls task_is_traced() > > > which does raw_spin_lock_irq(). > > > > Urgh. Judging from > > release_task() > > -> write_lock_irq(&tasklist_lock); > > -> ptrace_release_task(); > > -> ptrace_unlink(); > > -> __ptrace_unlink(); > > -> task_is_traced(). > > > > it will break on !RT so irqsave is indeed needed. > > Why? > > task_is_traced() does raw_spin_lock_irq() under ifdef(CONFIG_PREEMPT_RT). That is correct. So it is not broken after all. So basically ptrace_freeze_traced() is okay but ptrace_unfreeze_traced() needs the same treatment. task_is_traced() acquires/drops the PI-lock and the inner of ptrace_freeze_traced() does the same but needs to be done only for RT. How much of that do find acceptable with your upstream hat on? > Oleg. Sebastian
