From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 59ECE8F72 for ; Tue, 7 May 2024 16:55:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715100933; cv=none; b=rxX/FTD6D9hiJ3wIbVqe9c0DWMiXYm/yDEZ5/xttEmd47I7M2xu7SljwF+md/TMOE4hTxhyZdpetNvOoOvho1wE482wN3BBPJ3n+SXG/2IKELeg+h7682IID4DqBezhhxZ7WWoq6bBaX9DRopu5CEKfl+CRRMGLpUqVFYLonU2Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715100933; c=relaxed/simple; bh=XzhriFPwMhiLE0x4u27I2Jmbso2FqQdddiyJo4nSyFE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=g/TlrGtjmVoYHhpefTvaDJJk8LQ4VlItgCWjHeOYJWspUXlXwB11VlX+tK7HXqczYCk3X8NPY1RjNjJGn/4XWeXh4+9kZ7DIX59MrzV48ykCZMv6IpgOXhme00mCFpn9DbsA62Vmr38ZuOEVTWOrxyf36K/rAhPBAeAlEmfyKow= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rwF3HcFl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rwF3HcFl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58B39C2BBFC; Tue, 7 May 2024 16:55:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1715100932; bh=XzhriFPwMhiLE0x4u27I2Jmbso2FqQdddiyJo4nSyFE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rwF3HcFlZK0MVvAo6IepNVxCAwW/awM8TxYBVCC5PqzHrenJIXiEyHKXnwxq+YrHP sDblTSGEfjm28FuhgHshjBjGxihA3qYquWcuADW3s/ujKjCchvwvwuUngS7gEhxMMM 6Il/bkNW70penqh8lMzAIPgPMw7PAUlkoJYjQrTO/B5ZlKTkjmiqeZxalLpdcmbqsU W7NFm5I5PIOeQOGWv6XBI9x6A1zp0zmJZbL9WPYwbhx58qF7uW/ao1QQN4+eXxPSEd 69t92HD184wZHJjCGjsSxRWBtFKN22x1+SNhP1WIL+ktF68QwOPPvgzBgeZBIKiHu7 W8M7FSwEeMuKg== Date: Tue, 7 May 2024 17:55:28 +0100 From: Simon Horman To: Eric Dumazet Cc: "David S. Miller" , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, eric.dumazet@gmail.com Subject: Re: [PATCH net-next 5/8] rtnetlink: do not depend on RTNL for many attributes Message-ID: <20240507165528.GI15955@kernel.org> References: <20240503192059.3884225-1-edumazet@google.com> <20240503192059.3884225-6-edumazet@google.com> <20240505144608.GB67882@kernel.org> <20240505150616.GI67882@kernel.org> <20240507163814.GE15955@kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, May 07, 2024 at 06:39:54PM +0200, Eric Dumazet wrote: > On Tue, May 7, 2024 at 6:38 PM Simon Horman wrote: > > > > On Sun, May 05, 2024 at 05:14:58PM +0200, Eric Dumazet wrote: > > > On Sun, May 5, 2024 at 5:06 PM Simon Horman wrote: > > > > > > > > On Sun, May 05, 2024 at 05:00:10PM +0200, Eric Dumazet wrote: > > > > > On Sun, May 5, 2024 at 4:47 PM Simon Horman wrote: > > > > > > > > > > > > On Fri, May 03, 2024 at 07:20:56PM +0000, Eric Dumazet wrote: > > > > > > > Following device fields can be read locklessly > > > > > > > in rtnl_fill_ifinfo() : > > > > > > > > > > > > > > type, ifindex, operstate, link_mode, mtu, min_mtu, max_mtu, group, > > > > > > > promiscuity, allmulti, num_tx_queues, gso_max_segs, gso_max_size, > > > > > > > gro_max_size, gso_ipv4_max_size, gro_ipv4_max_size, tso_max_size, > > > > > > > tso_max_segs, num_rx_queues. > > > > > > > > > > > > Hi Eric, > > > > > > > > > > > > * Regarding mtu, as the comment you added to sruct net_device > > > > > > some time ago mentions, mtu is written in many places. > > > > > > > > > > > > I'm wondering if, in particular wrt ndo_change_mtu implementations, > > > > > > if some it is appropriate to add WRITE_ONCE() annotations. > > > > > > > > > > Sure thing. I called for these changes in commit > > > > > 501a90c94510 ("inet: protect against too small mtu values.") > > > > > when I said "Hopefully we will add the missing ones in followup patches." > > > > > > > > Ok, so basically it would be nice to add them, > > > > but they don't block progress of this patchset? > > > > > > A patch set adding WRITE_ONCE() on all dev->mtu would be great, > > > and seems orthogonal. > > > > Ack. I'm guessing an incremental approach to getting better coverage would > > be best. I'll add this to my todo list. > > I sent a single patch about that already ;) :)