Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp5735005pxb; Mon, 14 Feb 2022 06:28:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJwvrcZYdNZU6KK7EIGoF3cjXNeHoQ38jYOPor09rrR/t0saoT1GVYj2WigKNK26rj+WsExq X-Received: by 2002:a05:6402:942:: with SMTP id h2mr14978618edz.328.1644848913885; Mon, 14 Feb 2022 06:28:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644848913; cv=none; d=google.com; s=arc-20160816; b=NfKIZWO9s7VfX/q5aBhMV0PVg+qLI86lW2I7wOfg8cDgSpQsEjuK2mz6N27x1NIlpY 6OJSb0/LXIvisEiseak6mgUeTSXkq6WY10jXqSeh1T6Hfo+w7e+EgSSmS7iCxon+Kah6 myvaIIiZFzRrSKny/bBN0l1CCqiAFRXSdvFu72o05xE4vWliNrugRLa+yZZ/QhtRG2Ga 8fY4jnAl1h7CXPh5E0DQ0RYjHquHX0pwSAcyGFQ6ApBvyaURYMdJK1W3mBUOwf0oD05E ylBX2/EHbThiCoA7LQ/KSEhhcapXDyISRBdOEVrOiHSt1Z3qdRV2ZUTKTLQqaycUDe3l eYrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=3rdhrGsB6cka+Ef4Pbq9BbguW4PKC4/Ny/Dc/UgVg9I=; b=jD5g/1YwFuFCE7em6BwtRJoUtTSPu4cTzY4rR/9I/a/52NTtCZ0am2MnpirRgjfIWr wpYbWhJ+Bnw26iEcFa7l0GgepaAM9RtRdd9fasUF1GqPSe7ahiOM7/9kJlUOt9MaHkre tME1FDI43na3/SlBYO4h1bLKjFBZCRTBsY9m/J0vD2x5VXmCMzIoQP6/BwrEyL4RBWdu eRO6oyDiWAs3EQ/Mc6qBIEtCjS2QIHfgHLjHCxraB945D3pJxiBLoNhAOgpVIuGAKpTt oAIVdv697cKXdMOtIjH7nxQlh/UC3L4RSzSkfOeOK54jE6mTlRJyS+iAeMbOlLI2w8SU 5YHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cloudflare.com header.s=google header.b=MgetSyyf; 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=REJECT sp=REJECT dis=NONE) header.from=cloudflare.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m4si17423647ejn.639.2022.02.14.06.28.10; Mon, 14 Feb 2022 06:28:33 -0800 (PST) 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=@cloudflare.com header.s=google header.b=MgetSyyf; 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=REJECT sp=REJECT dis=NONE) header.from=cloudflare.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238229AbiBMUb6 (ORCPT + 99 others); Sun, 13 Feb 2022 15:31:58 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:50578 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232770AbiBMUb4 (ORCPT ); Sun, 13 Feb 2022 15:31:56 -0500 Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8191E532FB for ; Sun, 13 Feb 2022 12:31:50 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id n17so17692406iod.4 for ; Sun, 13 Feb 2022 12:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3rdhrGsB6cka+Ef4Pbq9BbguW4PKC4/Ny/Dc/UgVg9I=; b=MgetSyyfZYVU8EdQAtQ9EEk5/SnlzABkFcm79j3fvcLWmIlv4dELeia897T/vXhsuy ccM8qTg8WfTtmB8XlH6L+d4cZyj3NBXABqGP2pPpY6EeyJ9pkE2lYGhydWx4R91HKbk9 83f2H+AsDDamhGiZ/LipYRXzSRHLOXxfq+T0I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3rdhrGsB6cka+Ef4Pbq9BbguW4PKC4/Ny/Dc/UgVg9I=; b=PgLeNZOViyjRCCPw5ODPFV9p5hWOO2tb9iUrpCpJNRB4IzlmhZ7wTn5NmpKnMQZw0D 7xl8H/G0Es5GFVJ3te/BwNtqwoxQUMg9VnwHK886GJsf7mLp0RSCKTKOlJgIbe11cbwR 7G86ZkspdYnyJ8zYvzXvqmGLDtuL3OMh3THv1xnHKgFdsFnbqVp/Q/pkOSGgKy8s/n7P MP5yF5VeMWoLuKAvakK12p3ENoIkVS3aHeq3/zALYbyka1GE+qS7/SdQzEz2mFtVMpsJ B7feLaA3B5vuw8vDG3gCyDf0MjKElDQarqTtB56tUfkkjG8Qzjeb+H/fpK50S096RxXj Icbg== X-Gm-Message-State: AOAM533/XM5rYuPIXapPpR2wiNnZF5XZadYyAql3+rBtlmkr3vLFr9Qu R4wQDwcYEySiOIDOApi+NBQ3gJcbt4Zs6HH7T3Cjyw== X-Received: by 2002:a02:824e:: with SMTP id q14mr6457263jag.0.1644784309865; Sun, 13 Feb 2022 12:31:49 -0800 (PST) MIME-Version: 1.0 References: <20220211173042.112852-1-ignat@cloudflare.com> <717c68c0-f139-b6e5-aff1-3a4264344eeb@gmail.com> In-Reply-To: <717c68c0-f139-b6e5-aff1-3a4264344eeb@gmail.com> From: Ignat Korchagin Date: Sun, 13 Feb 2022 20:31:39 +0000 Message-ID: Subject: Re: [PATCH] ipv6: mcast: use rcu-safe version of ipv6_get_lladdr() To: David Ahern Cc: "David S . Miller" , Hideaki YOSHIFUJI , David Ahern , Jakub Kicinski , netdev , linux-kernel , kernel-team , David Pinilla Caparros Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE,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 Stupid me - forgot to reply to all and a discussion between me and David happend off list. Below, is the transcript for posterity: On Sun, Feb 13, 2022 at 5:53 PM David Ahern wrote: > > On 2/13/22 8:43 AM, Ignat Korchagin wrote: > > On Sun, Feb 13, 2022 at 4:17 PM David Ahern wrote: > >> > >> On 2/12/22 1:46 PM, Ignat Korchagin wrote: > >>> In 8965779d2c0e ("ipv6,mcast: always hold idev->lock before mca_lock") > >>> mld_newpack() was actually migrated from "dev" to "idev' just for this > >>> use case. It seems the most reasonable approach would be to revert > >>> mld_newpack() back to dev and use the original code. > >> > >> > >> pmc already has the reference on idev and idev->dev is the source of dev > >> passed to mld_newpack. There is no reason to go back to the idev -> dev > >> -> idev dance. > > > > I don't know. Three things which make it more reasonable in my opinion: > > * we're already using idev->dev in mld_newpack() - that is we're not > > adding an extra variable here in mld_newpack() - we need it anyway, so > > can use in multiple places > > * it makes the code more consistent with the same code for the same > > reason in igmp6_send() in the same file, which uses "dev" and > > ipv6_get_lladdr() > > * we're making __ipv6_get_lladdr() static again and everything in > > the kernel is now using the public version of ipv6_get_lladdr() - I > > think the extra indirection of idev->dev-idev is a reasonable price to > > pay to avoid customized locking code in the caller, which may backfire > > later again in the same way it backfired this time > > which is why I later said move the locking to __ipv6_get_lladdr. > ipv6_get_lladdr takes a net_dev, looks up the idev and calls > __ipv6_get_lladdr. __ipv6_get_lladdr handles the idev locking needs. > > Users of the get_lladdr API that already have the idev reference use > __ipv6_get_lladdr. That is a common paradigm in the stack. Ah. I see now. This does make sense as well to me. > igmp6 code can use some modernization - but that is a net-next change. > This is a -net change.