Received: by 2002:a05:6358:111d:b0:dc:6189:e246 with SMTP id f29csp178539rwi; Wed, 2 Nov 2022 10:37:01 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5i+Hsw92w5TSsAQYDQs1v3tP8KfPo6M4jWNDqGnRKmV7qWMHM5mOloc9X8Lch6bX6j7CKu X-Received: by 2002:a17:902:ef47:b0:179:d18e:4262 with SMTP id e7-20020a170902ef4700b00179d18e4262mr25486480plx.22.1667410621727; Wed, 02 Nov 2022 10:37:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667410621; cv=none; d=google.com; s=arc-20160816; b=yWmhPkUC1O8Jgi7TDeGLJipdU4b6Gh6fP3JNpDTs/iCcdocUv1FiBLDrLOQdffWj2S 6q4+tfXJxTX6jrBZmUYMwIb1SEMugdGrTcNBgFx1La9ZNVt9pcQAH7X9gVHrVyutdvcM UmKr9oMgmdcR73s1mxEcJ+adxeoeXRC3N0lMNUCVGXoF1cBiHR4zncwtz69kXNFz48r6 M9QTO7l0FeEFE/0wHdACcZnLKWE/9tG3uvlYxpDdHbBgs/1KOvlYBqRSwcZHc83t8TuF 2pXQsjU4bxYiQ58HXXhIxZedIbsRL/FdT7ILa4DbZtYuXeaPioU5Fya2n9M0rIc4xVLB fMqw== 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:dkim-signature:date; bh=xtTSxM1Q/qUYa04qDvMF9fQMU1lb3nJ4Yr7MTQ7VghU=; b=NhEEvWd2KclEHZNv9W7opluU6wMZkNrPqWBhGfd4tpR5N+ajx0upBuCq+Felon4sUd lEtzqS1+tQiPv0IHFRsZozbwCdCwT3UQKt42kPQTw/steX+aQ2ug/4Lbpejf3ILZd6Yv xk/O2dwyD5FdSw3uwSVLqfTh9/uhk7C8IkiAvYX39S43Y7U+9Wuxx03yBxF2jdMmhU31 Te48x2JHUaG3UaVoVqyx04ADcVbhPgrjAGI+7P1HwZvCtA8PR2K6szJHzmii1t9bW8bR lGKPVh7YRVN4UYDNkjBSnKXwlWrfXHFZdf1kUYt64uX9sJ+/jyy8llWZH80oUXtwC2O7 PJcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=HGPpAdSi; 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=linux.dev Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u3-20020a654c03000000b0046f33e40222si15626687pgq.669.2022.11.02.10.36.43; Wed, 02 Nov 2022 10:37:01 -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=@linux.dev header.s=key1 header.b=HGPpAdSi; 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=linux.dev Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230468AbiKBRPK (ORCPT + 98 others); Wed, 2 Nov 2022 13:15:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41294 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229531AbiKBRO4 (ORCPT ); Wed, 2 Nov 2022 13:14:56 -0400 Received: from out0.migadu.com (out0.migadu.com [94.23.1.103]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D9DEB2186; Wed, 2 Nov 2022 10:14:55 -0700 (PDT) Date: Wed, 2 Nov 2022 10:14:38 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1667409294; 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=xtTSxM1Q/qUYa04qDvMF9fQMU1lb3nJ4Yr7MTQ7VghU=; b=HGPpAdSi8jBVZcmLugyVIGYvvWkqF3VSKjIyZSapgYT5aDBIwno6PFiycmuKqNRsi6eCEU 00g6vsaXFrHI8ZLMVDXPBYRRjci2zvrdgfTapXezF72FnhcQyMODDDKyeJs8AgdHDo+xZ1 Ak9oegP1g8hgVuDq9qb8v6diwqyoY50= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Jakub Kicinski Cc: Andrew Lunn , Andy Ren , netdev@vger.kernel.org, richardbgobert@gmail.com, davem@davemloft.net, wsa+renesas@sang-engineering.com, edumazet@google.com, petrm@nvidia.com, pabeni@redhat.com, corbet@lwn.net, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next v2] netconsole: Enable live renaming for network interfaces used by netconsole Message-ID: References: <20221102002420.2613004-1-andy.ren@getcruise.com> <20221101204006.75b46660@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221101204006.75b46660@kernel.org> X-Migadu-Flow: FLOW_OUT X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_PASS 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 Tue, Nov 01, 2022 at 08:40:06PM -0700, Jakub Kicinski wrote: > On Wed, 2 Nov 2022 01:48:09 +0100 Andrew Lunn wrote: > > Changing the interface name while running is probably not an > > issue. There are a few drivers which report the name to the firmware, > > presumably for logging, and phoning home, but it should not otherwise > > affect the hardware. > > Agreed. BTW I wonder if we really want to introduce a netconsole > specific uAPI for this or go ahead with something more general. Netconsole is a bit special because it brings an interface up very early. E.g. in our case without the netconsole the renaming is happening before the interface is brought up. I wonder if the netconsole-specific flag should allow renaming only once. > A sysctl for global "allow UP rename"? This will work for us, but I've no idea what it will break for other users and how to check it without actually trying to break :) And likely we won't learn about it for quite some time, asssuming they don't run net-next. > > We added the live renaming for failover a while back and there were > no reports of user space breaking as far as I know. So perhaps nobody > actually cares and we should allow renaming all interfaces while UP? > For backwards compat we can add a sysctl as mentioned or a rtnetlink > "I know what I'm doing" flag? > > Maybe print an info message into the logs for a few releases to aid > debug? > > IOW either there is a reason we don't allow rename while up, and > netconsole being bound to an interface is immaterial. Or there is > no reason and we should allow all. My understanding is that it's not an issue for the kernel, but might be an issue for some userspace apps which do not expect it. If you prefer to go with the 'global sysctl' approach, how the path forward should look like? Thanks!