From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.zx2c4.com (lists.zx2c4.com [165.227.139.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DD026C43334 for ; Thu, 30 Jun 2022 00:24:39 +0000 (UTC) Received: by lists.zx2c4.com (OpenSMTPD) with ESMTP id f75c5f83; Thu, 30 Jun 2022 00:24:38 +0000 (UTC) Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lists.zx2c4.com (OpenSMTPD) with ESMTPS id 13f7727f (TLSv1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256:NO) for ; Thu, 30 Jun 2022 00:24:36 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 3E5B0B827B8; Thu, 30 Jun 2022 00:24:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C1FBC34114; Thu, 30 Jun 2022 00:24:32 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="RN1R7tzA" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1656548671; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yhJeMlaJxX3LrfVXt5LEZDg6XeT5mqblmQOfOgg/+S0=; b=RN1R7tzA9LJmRLipddoaZl+SAjVveNjXi3uMxifQkM4+JW04JiAXddKuYswIKWd7I6YfzN bWiaN2IgFsUdz6qU9iV9W9jimu8OpM6ldOuliM8ZrOJ34+n0u8U/3IstNXi725jdktXGqq ojC33c7dUhSRMDZ4U1akIsKmYNrXwtw= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id f14ed555 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Thu, 30 Jun 2022 00:24:30 +0000 (UTC) Date: Thu, 30 Jun 2022 02:24:26 +0200 From: "Jason A. Donenfeld" To: John Stultz Cc: Kalesh Singh , Christoph Hellwig , Greg Kroah-Hartman , Arve =?utf-8?B?SGrDuG5uZXbDpWc=?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Christian Brauner , Hridya Valsaraju , Suren Baghdasaryan , Theodore Ts'o , "David S. Miller" , Eric Dumazet , Jakub Kicinski , "Alex Xu (Hello71)" , Paolo Abeni , Rob Herring , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Shuah Khan , LKML , wireguard@lists.zx2c4.com, netdev@vger.kernel.org, rcu , "open list:KERNEL SELFTEST FRAMEWORK" , sultan@kerneltoast.com, android-kernel-team , Saravana Kannan , "Rafael J. Wysocki" Subject: Re: [PATCH] remove CONFIG_ANDROID Message-ID: References: <20220629161527.GA24978@lst.de> <20220629163007.GA25279@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-BeenThere: wireguard@lists.zx2c4.com X-Mailman-Version: 2.1.30rc1 Precedence: list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: wireguard-bounces@lists.zx2c4.com Sender: "WireGuard" Hi John, On Wed, Jun 29, 2022 at 04:52:05PM -0700, John Stultz wrote: > Jason: Thanks for raising this issue and sharing this patch to avoid > breakage! I really appreciate it. > > My only concern with this change introducting a userspace knob set at > runtime, vs a (hopefully more specific than _ANDROID) kernel config is I'd also be okay with a compile-time knob. The details make no difference to me, so long as there's just *something* there. > that it's not exactly clear what the flag really means (which is the > same issue CONFIG_ANDROID has). And more problematic, with this it > would be an ABI. > > So for this we probably need to have a very clear description of what > userland is telling the kernel. Because I'm sure userlands behavior > will drift and shift and we'll end up litigating what kind of behavior > is really userspace_autosleeping vs userspace_sortof_autosleeping. :) I guess what I have in mind is the answer to these being "yes": - "Is it very common to be asleep for only 2 seconds before being woken?" - "Is it very common to be awake for only 2 seconds before sleeping?" I think it'd be easiest to have a knob somewhere (compiletime, runtime, wherever) that describes a device that exhibits those properties. Then wireguard and other things will make a decision on how to handle the crypto during relevant events. > Alternatively, maybe we should switch it to describe what behavior > change we are wanting the kernel take (instead of it hinting to the > kernel what to expect from userland's behavior)? That way it might be > more specific. As a general rule, I don't expose knobs like that in wireguard /itself/, but wireguard has no problem with adapting to whatever machine properties it finds itself on. And besides, this *is* a very definite device property, something really particular and peculiar about the machine the kernel is running on. It's a concrete thing that the kernel should know about. So let's go with your "very clear description idea", above, instead. So taken together, I guess there are two approaches to this: 1) Introduce a simple CONFIG_PM_CONTINUOUS_AUTOSLEEPING Kconfig thing with lots of discouraging help text. 2) Go with the /sys/power tunable and bikeshed the naming of that a bit to get it to something that reflects this better, and document it as being undesirable except for Android phones. It seems like in both cases, the key will be getting the naming right. Jason