Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp184078ybj; Wed, 6 May 2020 14:44:36 -0700 (PDT) X-Google-Smtp-Source: APiQypK146AcQ+U/kTDZ74ALTUvvwQ2FFhEAzpgyxGXovG2EoM8gDlVhmFZGtUaLCBSb8tJME8pK X-Received: by 2002:aa7:d718:: with SMTP id t24mr9331859edq.29.1588801476626; Wed, 06 May 2020 14:44:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588801476; cv=none; d=google.com; s=arc-20160816; b=m1CyoWyKeMEDQ28XrfgFIPV34MPlYuaYcUnYLkMkPW8x8mGFmjqcAnLtsbIsseqBkI zJE6Zn9Ss64K/nEZk6kGS1jEfqOeJDnxKzDRSVbDqUuK/6WStEdDAoc/sWuAGpLkfeTs oDYPk9gPs8VOQx2SguI86Y5jpBAlhzuBXm38nF9yoNLozuHw+KW6kxLKwMWb+4Wq9mkj LjEz+sd6HyiqGQDl4cVvZbfSJDi/t+h4TPIpMnG8ORv9+gtldYshQcqiuuZ4P6i6Pz/L QZ4NOsJoh6BjimM76WOPp8T3XFs0RD+F/OjCXN9Krw+N72zxxmpqE0SkSZgRPUX7AUWa E0CQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ICA08eo2A+qP7RtXmrfg2CY1fdR7TD7YkRgnps9JOzE=; b=TL/M1Cq4Owti3TvVD4HgC5LKuhksddywrcvcy6LSUJ8ARpsQABamNrR65c460UNTeD san358y+XRJJD24Giw5dfe1skunVYFkNY5CA6JRjy5tnfxGaMrcp+wnF/CwCV1bVTaAy lbyWTJ6QvNByAiduhfGkvbqWP8zHDg3X0x3cfZZjoa4x3Ld7UnVssv346Mn2feJEsJ1a TLas0LA2sb4ejBulp5dDGici70idds2ouKVw3IgSq8I+O2RXErIuFT4m9U26H+nY8f+K 47NTuqmOJ59Nr/v1/O9nFwBUFYWObkpj01B0r+mAUDq11JtM+ykOfA4ogrNHNEW16fp6 4gvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="cH/93Cd9"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d22si1795298edz.94.2020.05.06.14.44.12; Wed, 06 May 2020 14:44:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="cH/93Cd9"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729817AbgEFVko (ORCPT + 99 others); Wed, 6 May 2020 17:40:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33110 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1728621AbgEFVko (ORCPT ); Wed, 6 May 2020 17:40:44 -0400 Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [IPv6:2a00:1450:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB7AEC061A0F; Wed, 6 May 2020 14:40:42 -0700 (PDT) Received: by mail-ej1-x641.google.com with SMTP id rh22so2705113ejb.12; Wed, 06 May 2020 14:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ICA08eo2A+qP7RtXmrfg2CY1fdR7TD7YkRgnps9JOzE=; b=cH/93Cd9cgBcrTrT7Mv6ggZmvk02MtrgH1b/9h+qdX57UGj0tckw19IPgbfASl0az9 Ix9a291erbKk7XqEl1Bw1YwWxnxnmXQ7Iw5j3FeeOnyLebw5ye44+k+r31/jC+BpRLV3 8PpwgMGHPp9GaHEKB8KcDSW5lAUyfLfsGaXWKWaHu2NtuqFLop8xt17Rrj4hz+AYzrgz bNO0APyAprnHMK/1cGt4nv2CKnZbetJJjipsqubhdUD3ADfVAyZv0YlO+egx+caIcfd2 wGhLyylogXp7AHKVRkMQ+WTYsENt9wFYv4SaHIh8Hz0Ca/KuwVcRzvHh/zjioqimXnKU ZG/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ICA08eo2A+qP7RtXmrfg2CY1fdR7TD7YkRgnps9JOzE=; b=E0+WL+BwEfmeZPz5MYIaZgygoJQYlw8UrIGZbqRKP4rLYbFAQFx9ZzEhuPf2f24xyf Nrl2DoNtnRTHz5slm90MgEKJUfVw23ha0MYMMMyTMEY2+xnrA2VKo8uLHE7yojw1WmzT tdyYrNRjZGZquJtjosGk1Dlf+D1izJY1SC9kKzlfwoWFIRWRISIfGbMRaashGkZKJ2nx 7RMOzXEzuj6GWTIed4CaXp99JsppFwb2W9syIEaq+vIC28NeuAz7fDsrE4tcYy0AZRCc /57KreG/T1m8ORqna7IJUOCfJEabnRkxmPXuesd8bJ0Eb89NMmZidiwgQ/z5p+06QhNj cMrw== X-Gm-Message-State: AGi0PuZk1gpf+mAx/G54essh71pC61nwz+Z567/C38M1im2c7YHv1QsC uQKoBWknJjvGVPxOr3N/XizNXQCpuF7G9sJPtGU= X-Received: by 2002:a17:906:355b:: with SMTP id s27mr9460830eja.184.1588801241411; Wed, 06 May 2020 14:40:41 -0700 (PDT) MIME-Version: 1.0 References: <20200505210253.20311-1-f.fainelli@gmail.com> <20200505172302.GB1170406@t480s.localdomain> In-Reply-To: From: Vladimir Oltean Date: Thu, 7 May 2020 00:40:30 +0300 Message-ID: Subject: Re: [RFC net] net: dsa: Add missing reference counting To: Florian Fainelli Cc: Vivien Didelot , netdev , Andrew Lunn , "David S. Miller" , Jakub Kicinski , open list Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Florian, On Thu, 7 May 2020 at 00:24, Florian Fainelli wrote: > > > > On 5/5/2020 2:23 PM, Vivien Didelot wrote: > > On Tue, 5 May 2020 14:02:53 -0700, Florian Fainelli wrote: > >> If we are probed through platform_data we would be intentionally > >> dropping the reference count on master after dev_to_net_device() > >> incremented it. If we are probed through Device Tree, > >> of_find_net_device() does not do a dev_hold() at all. > >> > >> Ensure that the DSA master device is properly reference counted by > >> holding it as soon as the CPU port is successfully initialized and later > >> released during dsa_switch_release_ports(). dsa_get_tag_protocol() does > >> a short de-reference, so we hold and release the master at that time, > >> too. > >> > >> Fixes: 83c0afaec7b7 ("net: dsa: Add new binding implementation") > >> Signed-off-by: Florian Fainelli > > > > Reviewed-by: Vivien Didelot > > > Andrew, Vladimir, any thoughts on that? > -- > Florian I might be completely off because I guess I just don't understand what is the goal of keeping a reference to the DSA master in this way for the entire lifetime of the DSA switch. I think that dev_hold is for short-term things that cannot complete atomically, but I think that you are trying to prevent the DSA master from getting freed from under our feet, which at the moment would fault the kernel instantaneously? If this is correct, it certainly doesn't do what it intends to do: echo 0000\:00\:00.5> /sys/bus/pci/drivers/mscc_felix/unbind [ 71.576333] unregister_netdevice: waiting for swp0 to become free. Usage count = 1 (hangs there) But if I'm right and that's indeed what you want to achieve, shouldn't we be using device links instead? https://www.kernel.org/doc/html/v4.14/driver-api/device_link.html Thanks, -Vladimir