Thread (30 messages) 30 messages, 7 authors, 2021-03-20

Re: possible deadlock in start_this_handle (2)

From: Matthew Wilcox <willy@infradead.org>
Date: 2021-02-12 12:26:10
Also in: linux-mm, lkml

On Fri, Feb 12, 2021 at 08:18:11PM +0900, Tetsuo Handa wrote:
On 2021/02/12 1:41, Michal Hocko wrote:
quoted
But I suspect we have drifted away from the original issue. I thought
that a simple check would help us narrow down this particular case and
somebody messing up from the IRQ context didn't sound like a completely
off.
 From my experience at https://lkml.kernel.org/r/201409192053.IHJ35462.JLOMOSOFFVtQFH@I-love.SAKURA.ne.jp ,
I think we can replace direct PF_* manipulation with macros which do not receive "struct task_struct *" argument.
Since TASK_PFA_TEST()/TASK_PFA_SET()/TASK_PFA_CLEAR() are for manipulating PFA_* flags on a remote thread, we can
define similar ones for manipulating PF_* flags on current thread. Then, auditing dangerous users becomes easier.
No, nobody is manipulating another task's GFP flags.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help