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 3E0A4CCA480 for ; Wed, 29 Jun 2022 17:30:54 +0000 (UTC) Received: by lists.zx2c4.com (OpenSMTPD) with ESMTP id afa17a9d; Wed, 29 Jun 2022 17:30:52 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lists.zx2c4.com (OpenSMTPD) with ESMTPS id aba4b47f (TLSv1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256:NO) for ; Wed, 29 Jun 2022 17:30:50 +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 dfw.source.kernel.org (Postfix) with ESMTPS id D090061E71; Wed, 29 Jun 2022 17:30:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71CC4C34114; Wed, 29 Jun 2022 17:30:45 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="VPJ/wvyO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1656523843; 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=nzpFb7EApUekHzpz3mO22Jl6tEsl6h0iB+dQdHcUEUw=; b=VPJ/wvyOk175tYD7uLJCskYvUM++WdD2Q8q1cq1VMFHK01Jh1ZstEAYoemSUPZw6KujEnR TO8VJvBEnfyrWsVFn2G2gU4AHtJxk9XaYZZT06QTQ/GFQCrJRa63QU9Mb8PP9Ndq2m7sKf re0GdWfl1nLiTbfyj0jhUSzzeL2qBZc= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 146d0254 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Wed, 29 Jun 2022 17:30:43 +0000 (UTC) Date: Wed, 29 Jun 2022 19:30:35 +0200 From: "Jason A. Donenfeld" To: Greg Kroah-Hartman Cc: Christoph Hellwig , 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 mailing list , Netdev , rcu@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH] remove CONFIG_ANDROID Message-ID: References: <20220629161527.GA24978@lst.de> <20220629163007.GA25279@lst.de> <20220629164543.GA25672@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" On Wed, Jun 29, 2022 at 07:19:36PM +0200, Greg Kroah-Hartman wrote: > I would be totally and completly amazed if there are any Android kernels > in real devices in the world that are not at the very least, based on > LTS releases. But maybe there is, this patch series isn't going to land > until 5.20, and by then, I think the "define behavior, not hardware" fix > for random and wg will be properly resolved :) Properly resolved by whom? It sounds like you're up for intentionally allowing a userspace regression, and also volunteering other people's time into fixing that regression? The way I understand the kernel development process is that the person proposing a change is responsible for not intentionally causing regressions, and if one is pointed out, a v+1 of that patch is provided that doesn't cause the regression. > > > > In the meantime, this might actually fix issues in desktop distros that > > > were enabling this option, thinking it only affected the building of a > > > driver > > > > That sounds like a false dichotomy. It's not about "fix Android" vs "fix > > distros". What I'm suggesting is fixing Android AND fixing distros, by > > looking at the problem holistically. Trading a bad problem on Android > > (wg connections are broken) for a manageable problem on distros (something > > something theoretical warm boot attack something) doesn't sound like a > > nice trade off. Let's instead get this all fixed at the same time. > > Agreed, so what should we use instead in the wg code? What userspace > functionality are you trying to trigger off of here in the current > CONFIG_ANDROID check? It's systems that go to sleep all the time, nonstop, like Android handsets do. I'm fine with a compile time constant for this, or some runtime sysctl, or whatever else. It doesn't really matter to me. The only concern is that the Android people are okay with it and enable it (and that the distros don't enable it, I guess). So whatever they want is fine. Or maybe such a runtime indicator already exists. I'm not sure. But I think a v+1 of this patchset needs to work that out in one direction or another. To put it simply, - I highly suspect that this patch will cause a regression. - I don't have a ready-made solution offhand to fix said regression. - The submitter of the patch, now aware of regression potential, should look into not causing that regression. That seems pretty clear cut: you're welcome to improve it, but please don't *intentionally* break my code. Jason