[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yrx8/Fyx15CTi2zq@zx2c4.com>
Date: Wed, 29 Jun 2022 18:25:32 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Christoph Hellwig <hch@....de>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Arve Hjønnevåg <arve@...roid.com>,
Todd Kjos <tkjos@...roid.com>,
Martijn Coenen <maco@...roid.com>,
Joel Fernandes <joel@...lfernandes.org>,
Christian Brauner <brauner@...nel.org>,
Hridya Valsaraju <hridya@...gle.com>,
Suren Baghdasaryan <surenb@...gle.com>,
Theodore Ts'o <tytso@....edu>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
"Alex Xu (Hello71)" <alex_y_xu@...oo.ca>,
Paolo Abeni <pabeni@...hat.com>, Rob Herring <robh@...nel.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Frederic Weisbecker <frederic@...nel.org>,
Neeraj Upadhyay <quic_neeraju@...cinc.com>,
Josh Triplett <josh@...htriplett.org>,
Steven Rostedt <rostedt@...dmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Lai Jiangshan <jiangshanlai@...il.com>,
Shuah Khan <shuah@...nel.org>, linux-kernel@...r.kernel.org,
wireguard@...ts.zx2c4.com, netdev@...r.kernel.org,
rcu@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH] remove CONFIG_ANDROID
On Wed, Jun 29, 2022 at 06:15:27PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 29, 2022 at 06:13:05PM +0200, Jason A. Donenfeld wrote:
> > Good! It sounds like you're starting to develop opinions on the matter.
>
> No, I provide facts.
Lol.
> Look at both the definition of the symbol, and
> various distribution kernel that enabled it and think hard if they run
> on "Android" hardware. Not just primarily, but at all.
There are two failure modes:
1) Key clearing code is skipped when it shouldn't be.
2) Key clearing code is run when it shouldn't be.
You've identified (well, Alex in the other thread I think?) a case of
(1). I was sort of thinking the fix to that would be that distros
shouldn't enable that option, but it doesn't really matter to me.
However, what I'm pointing out is the potential for (2). A (2)-style
regression means that WireGuard basically doesn't work, because, for
example, qcacld's packet-triggered wakeups tend to be too short to
renegotiate a handshake.
Anyway, instead of the slow drip of "facts" and ≤three sentence emails,
can you just write up a paragraph that indicates this is safe to do (for
both (1) and (2)) in your v+1?
I don't really want to argue about it, because I don't have anything to
argue about. Your change is probably fine. I'd just like it to be
spelled out why this is safe to do from somebody who has looked into it.
I have not looked into it, but it sounds like you have or are in the
process of doing so. Just write down what you find, please.
Jason
Powered by blists - more mailing lists