From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PATCH v8 07/11] proc: flush task dcache entries from all procfs instances Date: Wed, 12 Feb 2020 16:48:14 -0800 Message-ID: References: <20200210150519.538333-8-gladkov.alexey@gmail.com> <87v9odlxbr.fsf@x220.int.ebiederm.org> <20200212144921.sykucj4mekcziicz@comp-core-i7-2640m-0182e6> <87tv3vkg1a.fsf@x220.int.ebiederm.org> <87v9obipk9.fsf@x220.int.ebiederm.org> <20200212200335.GO23230@ZenIV.linux.org.uk> <20200212203833.GQ23230@ZenIV.linux.org.uk> <20200212204124.GR23230@ZenIV.linux.org.uk> <87lfp7h422.fsf@x220.int.ebiederm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <87lfp7h422.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "Eric W. Biederman" Cc: Al Viro , LKML , Kernel Hardening , Linux API , Linux FS Devel , Linux Security Module , Akinobu Mita , Alexey Dobriyan , Andrew Morton , Andy Lutomirski , Daniel Micay , Djalal Harouni , "Dmitry V . Levin" , Greg Kroah-Hartman , Ingo Molnar , "J . Bruce Fields" , Jeff Layton , Jonathan Corbet , Kees List-Id: linux-api@vger.kernel.org On Wed, Feb 12, 2020 at 1:48 PM Eric W. Biederman wrote: > > The good news is proc_flush_task isn't exactly called from process exit. > proc_flush_task is called during zombie clean up. AKA release_task. Yeah, that at least avoids some of the nasty locking while dying debug problems. But the one I was more worried about was actually the lock contention issue with lots of processes. The lock is basically a single global lock in many situations - yes, it's technically per-ns, but in a lot of cases you really only have one namespace anyway. And we've had problems with global locks in this area before, notably the one you call out: > Further after proc_flush_task does it's thing the code goes > and does "write_lock_irq(&task_list_lock);" Yeah, so it's not introducing a new issue, but it is potentially making something we already know is bad even worse. > What would be downside of having a mutex for a list of proc superblocks? > A mutex that is taken for both reading and writing the list. That's what the original patch actually was, and I was hoping we could avoid that thing. An rwsem would be possibly better, since most cases by far are likely about reading. And yes, I'm very aware of the task_list_lock, but it's literally why I don't want to make a new one. I'm _hoping_ we can some day come up with something better than task_list_lock. Linus