Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Christoph Hellwig <hch@lst.de>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Todd Kjos" <tkjos@android.com>,
	"Martijn Coenen" <maco@android.com>,
	"Joel Fernandes" <joel@joelfernandes.org>,
	"Christian Brauner" <brauner@kernel.org>,
	"Hridya Valsaraju" <hridya@google.com>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Theodore Ts'o" <tytso@mit.edu>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Rob Herring" <robh@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	"Frederic Weisbecker" <frederic@kernel.org>,
	"Neeraj Upadhyay" <quic_neeraju@quicinc.com>,
	"Josh Triplett" <josh@joshtriplett.org>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
	"Lai Jiangshan" <jiangshanlai@gmail.com>,
	"Shuah Khan" <shuah@kernel.org>,
	linux-kernel@vger.kernel.org, wireguard@lists.zx2c4.com,
	netdev@vger.kernel.org, rcu@vger.kernel.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH] remove CONFIG_ANDROID
Date: Wed, 29 Jun 2022 18:09:18 +0200	[thread overview]
Message-ID: <Yrx5Lt7jrk5BiHXx@zx2c4.com> (raw)
In-Reply-To: <20220629150102.1582425-2-hch@lst.de>

Hi Christoph,

On Wed, Jun 29, 2022 at 05:01:02PM +0200, Christoph Hellwig wrote:
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index e3dd1dd3dd226..f35ad1a9dff3e 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -755,8 +755,7 @@ static int random_pm_notification(struct notifier_block *nb, unsigned long actio
>  	spin_unlock_irqrestore(&input_pool.lock, flags);
>  
>  	if (crng_ready() && (action == PM_RESTORE_PREPARE ||
> -	    (action == PM_POST_SUSPEND &&
> -	     !IS_ENABLED(CONFIG_PM_AUTOSLEEP) && !IS_ENABLED(CONFIG_ANDROID)))) {
> +	    (action == PM_POST_SUSPEND && !IS_ENABLED(CONFIG_PM_AUTOSLEEP)))) {
>  		crng_reseed();
>  		pr_notice("crng reseeded on system resumption\n");
>  	}
> diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
> index aa9a7a5970fda..de1cc03f7ee86 100644
> --- a/drivers/net/wireguard/device.c
> +++ b/drivers/net/wireguard/device.c
> @@ -69,7 +69,7 @@ static int wg_pm_notification(struct notifier_block *nb, unsigned long action, v
>  	 * its normal operation rather than as a somewhat rare event, then we
>  	 * don't actually want to clear keys.
>  	 */
> -	if (IS_ENABLED(CONFIG_PM_AUTOSLEEP) || IS_ENABLED(CONFIG_ANDROID))
> +	if (IS_ENABLED(CONFIG_PM_AUTOSLEEP))
>  		return 0;
>  
>  	if (action != PM_HIBERNATION_PREPARE && action != PM_SUSPEND_PREPARE)
 
CONFIG_ANDROID is used here for a reason. As somebody suggested in
another thread of which you were a participant, it acts as a proxy for
"probably running on Android hardware", which in turn is a proxy for,
"suspend happens all the time on this machine, so don't do fancy key
clearing stuff every time the user clicks the power button."

You can see the history of that in these two commits here:
https://git.zx2c4.com/wireguard-linux-compat/commit/?id=36f81c83674e0fd7c18e5b15499d1a275b6d4d7f
https://git.zx2c4.com/wireguard-linux-compat/commit/?id=a89d53098dbde43f56e4d1e16ba5e24ef807c03b

The former commit was done when I first got this running on an Android
device (a Oneplus 3T, IIRC) and I encountered this problem. The latter
was a refinement after suggestions on LKML during WireGuard's
upstreaming.

So there *is* a reason to have that kind of conditionalization in the
code. The question is: does CONFIG_ANDROID actually represent something
interesting here? Is this already taken care of by CONFIG_PM_AUTOSLEEP
on all CONFIG_ANDROID devices? That is, do the base Android configs set
CONFIG_PM_AUTOSLEEP already so this isn't necessary? Or is there some
*other* proxy config value that should be used? Or is there a different
solution entirely that should be considered?

I don't know the answers to these questions, because I haven't done a
recent analysis. Obviously at one point in time I did, and that's why
the code is how it is. It sounds like you'd now like to revisit that
original decision. That's fine with me. But you need to conduct a new
analysis and write down your findings inside of a commit message. I must
see that you've at least thought about the problem and looked into it
substantially enough that making this change is safe. Your "let's delete
it; it's not doing much" alone seems more expedient than thorough.

Jason

  parent reply	other threads:[~2022-06-29 16:22 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-29 15:01 Christoph Hellwig
2022-06-29 15:01 ` [PATCH] " Christoph Hellwig
2022-06-29 15:27   ` Greg Kroah-Hartman
2022-06-29 16:07   ` Paul E. McKenney
2022-06-29 16:09   ` Jason A. Donenfeld [this message]
2022-06-29 16:10     ` Christoph Hellwig
2022-06-29 16:13       ` Jason A. Donenfeld
2022-06-29 16:15         ` Christoph Hellwig
2022-06-29 16:25           ` Jason A. Donenfeld
2022-06-29 16:30             ` Christoph Hellwig
2022-06-29 16:38               ` Jason A. Donenfeld
2022-06-29 16:45                 ` Christoph Hellwig
2022-06-29 16:52                   ` Jason A. Donenfeld
2022-06-29 17:00                     ` Greg Kroah-Hartman
2022-06-29 17:10                       ` Jason A. Donenfeld
2022-06-29 17:19                         ` Greg Kroah-Hartman
2022-06-29 17:30                           ` Jason A. Donenfeld
2022-06-29 17:35                             ` Christoph Hellwig
2022-06-29 17:42                               ` Jason A. Donenfeld
2022-06-29 18:59                           ` Paul E. McKenney
2022-06-29 16:56                   ` Steven Rostedt
2022-06-29 17:19                     ` Jason A. Donenfeld
2022-06-29 17:34                 ` Jason A. Donenfeld
2022-06-29 19:05                   ` Kalesh Singh
2022-06-29 19:41                     ` Theodore Ts'o
2022-06-29 20:47                     ` Jason A. Donenfeld
2022-06-29 22:26                       ` Kalesh Singh
2022-06-29 23:02                         ` Jason A. Donenfeld
2022-06-29 23:19                           ` Kalesh Singh
2022-06-30  0:36                             ` Joe Perches
2022-06-30  0:50                               ` Jason A. Donenfeld
2022-06-30  1:44                                 ` Joe Perches
2022-06-30  3:02                                   ` Jason A. Donenfeld
2022-06-29 23:52                           ` John Stultz
2022-06-30  0:24                             ` Jason A. Donenfeld
2022-06-30  0:30                               ` Jason A. Donenfeld
2022-06-30  4:25                                 ` Kalesh Singh
2022-06-30 10:05                                   ` Jason A. Donenfeld
2022-06-30 17:12                                     ` John Stultz
2022-06-30 17:24                                       ` Jason A. Donenfeld
2022-07-01 20:22                               ` Jonathan Corbet
2022-07-01 20:53                                 ` Jason A. Donenfeld
2022-06-29 16:34           ` Paul E. McKenney
2022-06-29 16:37             ` Christoph Hellwig
2022-06-29 16:45               ` Jason A. Donenfeld
2022-06-29 17:04                 ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yrx5Lt7jrk5BiHXx@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=alex_y_xu@yahoo.ca \
    --cc=arve@android.com \
    --cc=brauner@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=frederic@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=hridya@google.com \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=maco@android.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=quic_neeraju@quicinc.com \
    --cc=rcu@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=shuah@kernel.org \
    --cc=surenb@google.com \
    --cc=tkjos@android.com \
    --cc=tytso@mit.edu \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).