Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp819556iog; Wed, 29 Jun 2022 10:51:27 -0700 (PDT) X-Google-Smtp-Source: AGRyM1srlp8DdWXa6wVzOSwUgJGET7q64Cagf/a4EtC8CgDVvM8I36r/HQuVMMal9MX/Xvr0a41c X-Received: by 2002:a17:902:ea07:b0:16a:2833:3207 with SMTP id s7-20020a170902ea0700b0016a28333207mr11146222plg.86.1656525087704; Wed, 29 Jun 2022 10:51:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656525087; cv=none; d=google.com; s=arc-20160816; b=HGVTP6Et1KlTTdT8jkzh+CgPrl2LBPitw7sDvPvVclm16feESiE7kLEGmE96AosBue tjBvW9ehrm2WxNfH51ocZztqH4FfRBtS7/RykznDcSBgnkQaxcqAZjrz7NHgIZh05jnJ u5jlsug6lp5KYBIXpgxFCP95WR5J/hL84/rtfquUJyBQeSScjF/V8I/tOX6Ft2LS0n5J AZd4O3bsnvAJvWz9JuKWagCH6soKmZWCyI7xWsUjs5jFVwK13Hxf/SuI9HKC/+G1p0mW cexzk+j1zQJVhg2gDCNoMvoMkfDJdUqtZ38/3S/BG5YbvTwZnwlYEYq17gkHpleWSehq SsZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=BRvA5QhF67gpiBhOMTTID7C0qNSV5AXOHDu8vxDuqR0=; b=x5kavQSF//sre7SJN3+vwKXuIaoy7/XK3y4mvUdzRfroTuxh7u4KG4TDCb9EFJDmwU f86TfIRDZrwGWPvw3isEISPDfpiy7+EBDSUlPbyURRD1uOaTmLpgLnYt9VAPUduEzIUQ bqhPf6IEeoOSjPwS87+eDcrHbNOE/gOKKb2/7HFTkzmKXzyw2ggcZruVCsd0DP1FUnB3 z8Iz73xWzRmm22Nf7QJGWoMm6Jdxxe9kPVhWZ5lRV5GR6xANS+wVVprGBgx3PPxIkSzQ orul4TpT9O0mUyPg3CPzhulfJJQ20CNvNXzK/hIRFiZjVvrJVdKRfknbkSjINEWX/2n0 Qkog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=nTB2P46G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n21-20020a634d55000000b003fd60345d13si24334862pgl.693.2022.06.29.10.51.14; Wed, 29 Jun 2022 10:51:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=nTB2P46G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231506AbiF2RTr (ORCPT + 99 others); Wed, 29 Jun 2022 13:19:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230254AbiF2RTp (ORCPT ); Wed, 29 Jun 2022 13:19:45 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E74822289; Wed, 29 Jun 2022 10:19:45 -0700 (PDT) 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 A13DF61E6B; Wed, 29 Jun 2022 17:19:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D9E1C341C8; Wed, 29 Jun 2022 17:19:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656523184; bh=7SEzehmTNiedxnN/WyWz5hw+VLLOK+1tiViOeyV+LwU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nTB2P46GglBZYH8eYlOmT0yhVsC0SdQpx2SlanJHUQqipHLAZHXfbNFgBiQ0FQM/F cD+JTc+uDNS6UJ9YPZzL8dsW2GbUU5yf8dl5N9O/jtPNDW7Zui8HY9idCsKDfXZd8W 46gApD0MR22xzwtQEPeLhQJLah20KDBiKC3GVi7Y= Date: Wed, 29 Jun 2022 19:19:36 +0200 From: Greg Kroah-Hartman To: "Jason A. Donenfeld" Cc: Christoph Hellwig , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , 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: <20220629161020.GA24891@lst.de> <20220629161527.GA24978@lst.de> <20220629163007.GA25279@lst.de> <20220629164543.GA25672@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 29, 2022 at 07:10:43PM +0200, Jason A. Donenfeld wrote: > On Wed, Jun 29, 2022 at 07:00:25PM +0200, Greg Kroah-Hartman wrote: > > I think that by the time the next kernel release comes out, and > > percolates to a real Android device, the years gone by will have caused > > those who care about this to fix it. > > You assume that there aren't Android devices using kernels outside of > the ones you're referring to. That's a rather Google-centric > perspective. It's still breakage, even if Google has the ability to fix > it locally after "years gone by". If you want Android things to be > upstream, this is the way you must think about it; otherwise, what's the > point? By your logic, upstream should probably remove the Android code > everywhere and let Google handle it downstream. Except nobody wants > that; we want Android upstream. So let's keep it working upstream, not > intentionally break it. 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 :) > > 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? The RCU stuff is already handled as Paul has stated, so that's not an issue. thanks, greg k-h