From patchwork Tue Sep 19 01:53:45 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: stuart hayes X-Patchwork-Id: 9957989 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id C1EA1601E9 for ; Tue, 19 Sep 2017 01:53:54 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A09DB28CC6 for ; Tue, 19 Sep 2017 01:53:54 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 94BE328D17; Tue, 19 Sep 2017 01:53:54 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 477D228CC6 for ; Tue, 19 Sep 2017 01:53:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750815AbdISBxv (ORCPT ); Mon, 18 Sep 2017 21:53:51 -0400 Received: from mail-io0-f173.google.com ([209.85.223.173]:49466 "EHLO mail-io0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750783AbdISBxu (ORCPT ); Mon, 18 Sep 2017 21:53:50 -0400 Received: by mail-io0-f173.google.com with SMTP id 21so6614674iof.6 for ; Mon, 18 Sep 2017 18:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=Vg8ZSt5AjsT8XqDi7NvWRLcIA8y3mnXgBNYLzlfPF5E=; b=IrU2pKIBswwQzmBGrZh3SPaLhazGcqWVAXAG8MBmYzyY7iahRIYsyCFspgUytzwl3v 8mNdKTKxoNU31HKfYSa1Xn3oDnzjkbg7epbH5R8Re98mgdyDckvMsj7EU0P32x1uxn/w CdjC/e+Hagy3fbzLHwsVR10lbsCluVqvFnGxTcNDDLiqm0yZlz8VBrNJWJroavpi6NZ6 MvF56j+1pJnIWmiPCeywedzuT8seeI81ku7yWuu0SqkGPc++jKifwxAyuHz/0cWcE1Cj RT0Br/TAfDDVmR2XF8ZhxgAhWCwU7xYl853d95E4hU/SGZMPcA/8xX0uqD7L7mvzUdGe RoZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=Vg8ZSt5AjsT8XqDi7NvWRLcIA8y3mnXgBNYLzlfPF5E=; b=AhHFZpwGpw2lfG+sEaYzDCNtG/UYObQxhg5rI7LrI/4PunrwFTrkle4RszWRnpom8G aa1qcxcI9Yn19zEPq4RnUyz3FM2IsHMbQt2OP8szY0RLXAG9OYsq6AROPZHxEA+jN21s ldK1q9uPk9kZpRIr4KABxLgateEauHfpSBQWku0cwTUmbhrN8dtUrA0Us7cjMnXWEX4t taa+Tswghy4Z0cWNqIC6WhxKALn68+1jrJvbLRC21IWhqObzoDi/9onjKYxKpQDL/dqA yocfiqXyDKzY6e+6UfTjs/PU7L3DiHQr3FVcCYrdpJQfCF0wkgS4gDjcCro6Z8uq8coi K+5A== X-Gm-Message-State: AHPjjUiRsY+jy6u7YVeCWfjI7lB2EB2eTIDwuR/EJ3yK175jt2x7NvtU X8ORKk+P4hIiM9I+FWE= X-Google-Smtp-Source: AOwi7QDcKtY54H1PGARexck/uGicCoh8SgDnewYgE2nr2G20hz2SrBC6VWnqBwA9C/m8QejnovBngw== X-Received: by 10.202.229.13 with SMTP id c13mr11533088oih.121.1505786029608; Mon, 18 Sep 2017 18:53:49 -0700 (PDT) Received: from [192.168.0.2] (cpe-24-27-59-32.austin.res.rr.com. [24.27.59.32]) by smtp.gmail.com with ESMTPSA id o2sm2219920oia.18.2017.09.18.18.53.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Sep 2017 18:53:48 -0700 (PDT) To: bhelgaas@google.com, linux-pci@vger.kernel.org From: Stuart Hayes Subject: SR-IOV & virtfn/physfn sysfs links Message-ID: Date: Mon, 18 Sep 2017 20:53:45 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Language: en-US X-Antivirus: Avast (VPS 170918-4, 09/18/2017), Outbound message X-Antivirus-Status: Clean Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Bjorn et al, I'm hoping to enhance network device naming in systemd to parse sysfs "virtfn%u" and "physfn" links, so it understands virtual devices. I've noticed that the udev event which triggers the systemd/biosdevname network device naming--the udev "add" event for the network device, which happens within pci_bus_add_device() when the network driver's probe function calls register_netdev()--occurs before the sysfs links "physfn" and "virtfn%u" are created. This creates a race when the network naming code tries to look at those links (something biosdevname already does). Is there any reason why we couldn't switch the order of those calls to eliminate the race, as shown in the patch below? I couldn't think of any, since those links apply to the pci subsystem devices in sysfs (which are already created), not the net subsystem devices. I'd be happy to submit a patch if that looks ok. Thank you, Stuart --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus --- linux-4.14-rc1/drivers/pci/iov.c.orig 2017-09-18 15:00:43.168255665 -0500 +++ linux-4.14-rc1/drivers/pci/iov.c 2017-09-18 15:07:04.792280999 -0500 @@ -162,7 +162,6 @@ int pci_iov_add_virtfn(struct pci_dev *d pci_device_add(virtfn, virtfn->bus); - pci_bus_add_device(virtfn); sprintf(buf, "virtfn%u", id); rc = sysfs_create_link(&dev->dev.kobj, &virtfn->dev.kobj, buf); if (rc) @@ -173,6 +172,8 @@ int pci_iov_add_virtfn(struct pci_dev *d kobject_uevent(&virtfn->dev.kobj, KOBJ_CHANGE); + pci_bus_add_device(virtfn); + return 0; failed2: