[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241208112706.cmzyrotgnjflv47h@master>
Date: Sun, 8 Dec 2024 11:27:06 +0000
From: Wei Yang <richard.weiyang@...il.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Wei Yang <richard.weiyang@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>,
Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
Eric Biederman <ebiederm@...ssion.com>, Kees Cook <kees@...nel.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/5] mm: abstract get_arg_page() stack expansion and mmap
read lock
On Thu, Dec 05, 2024 at 07:01:14AM +0000, Lorenzo Stoakes wrote:
[...]
>>
>> Maybe we just leave this done in one place is enough?
>
>Wei, I feel like I have repeated myself about 'mathematically smallest
>code' rather too many times at this stage. Doing an unsolicited drive-by
>review applying this concept, which I have roundly and clearly rejected, is
>not appreciated.
>
Hi, Lorenzo
I would apologize for introducing this un-pleasant mail. Would be more
thoughtful next time.
>At any rate, we are checking this _before the mmap lock is acquired_. It is
>also self-documenting.
>
>Please try to take on board the point that there are many factors when it
>comes to writing kernel code, aversion to possibly generated branches being
>only one of them.
>
Thanks for this suggestion.
I am trying to be as professional as you are. In case you have other
suggestions, they are welcome.
--
Wei Yang
Help you, Help me
Powered by blists - more mailing lists