Re: [PATCH] proc: add locking checks in proc_inode_is_dead

2020-12-01 Thread Eric W. Biederman
Oleg Nesterov writes: > On 11/30, Eric W. Biederman wrote: >> >> Ouch Oleg I just looked the introduction of proc_inode_is_dead in >> d855a4b79f49 ("proc: don't (ab)use ->group_leader in proc_task_readdir() >> paths") introduced a ``regression''. >> >> Breaking the logic introduced in 7d8952

Re: [PATCH] proc: add locking checks in proc_inode_is_dead

2020-12-01 Thread Oleg Nesterov
On 11/30, Eric W. Biederman wrote: > > Ouch Oleg I just looked the introduction of proc_inode_is_dead in > d855a4b79f49 ("proc: don't (ab)use ->group_leader in proc_task_readdir() > paths") introduced a ``regression''. > > Breaking the logic introduced in 7d8952440f40 ("[PATCH] procfs: Fix > l

Re: [PATCH] proc: add locking checks in proc_inode_is_dead

2020-11-30 Thread Eric W. Biederman
Wen Yang writes: > The proc_inode_is_dead function might race with __unhash_process. > This will result in a whole bunch of stale proc entries being cached. > To prevent that, add the required locking. I assume you are talking about during proc_task_readdir? It is completely possible for the pr

Re: [PATCH] proc: add locking checks in proc_inode_is_dead

2020-11-28 Thread Oleg Nesterov
On 11/29, Wen Yang wrote: > > The proc_inode_is_dead function might race with __unhash_process. > This will result in a whole bunch of stale proc entries being cached. > To prevent that, add the required locking. I leave this to Eric but I don't understand how can this patch help, __unhash_process