Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 20 Feb 2020 14:33:10 -0800
From: Linus Torvalds <>
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 Cook <>, Oleg Nesterov <>, 
	Solar Designer <>
Subject: Re: [PATCH 3/7] proc: Mov rcu_read_(lock|unlock) in proc_prune_siblings_dcache

On Thu, Feb 20, 2020 at 12:51 PM Eric W. Biederman
<> wrote:
> Don't make it look like rcu_read_lock is held over the entire loop
> instead just take the rcu_read_lock over the part of the loop that
> matters.  This makes the intent of the code a little clearer.

No, this is horrid.

Maybe it makes the intent clearer, but it also causes that "continue"
case to unlock and relock immediately.

And maybe that case never triggers, and that's ok. But then it needs a
big comment about it.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.