From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Gu Zheng <guz.fnst@cn.fujitsu.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
NetDev <netdev@vger.kernel.org>
Subject: Re: [PATCH 6/7] PCI: Make sure VF's driver get attached after PF's
Date: Tue, 14 May 2013 14:39:00 -0700 [thread overview]
Message-ID: <5192AEF4.1070905@intel.com> (raw)
In-Reply-To: <CAE9FiQVGGHB_amKw0-DfDifpTnRGPbxA+q3WY5F-O3x-sx386A@mail.gmail.com>
On 05/14/2013 12:59 PM, Yinghai Lu wrote:
> On Tue, May 14, 2013 at 12:45 PM, Alexander Duyck
> <alexander.h.duyck@intel.com> wrote:
>> On 05/14/2013 11:44 AM, Yinghai Lu wrote:
>>> On Tue, May 14, 2013 at 9:00 AM, Alexander Duyck
>>> <alexander.h.duyck@intel.com> wrote:
>>>> I'm sorry, but what is the point of this patch? With device assignment
>>>> it is always possible to have VFs loaded and the PF driver unloaded
>>>> since you cannot remove the VFs if they are assigned to a VM.
>>> unload PF driver will not call pci_disable_sriov?
>> You cannot call pci_disable_sriov because you will panic all of the
>> guests that have devices assigned.
> ixgbe_remove did call pci_disable_sriov...
>
> for guest panic, that is another problem.
> just like you pci passthrough with real pci device and hotremove the
> card in host.
>
> ...
I suggest you take another look. In ixgbe_disable_sriov, which is the
function that is called we do a check for assigned VFs. If they are
assigned then we do not call pci_disable_sriov.
>
>> So how does your patch actually fix this problem? It seems like it is
>> just avoiding it.
> yes, until the first one is done.
Avoiding the issue doesn't fix the underlying problem and instead you
are likely just introducing more bugs as a result.
>> From what I can tell your problem is originating in pci_call_probe. I
>> believe it is calling work_on_cpu and that doesn't seem correct since
>> the work should be taking place on a CPU already local to the PF. You
>> might want to look there to see why you are trying to schedule work on a
>> CPU which should be perfectly fine for you to already be doing your work on.
> it always try to go with local cpu with same pxm.
The problem is we really shouldn't be calling work_for_cpu in this case
since we are already on the correct CPU. What probably should be
happening is that pci_call_probe should be doing a check to see if the
current CPU is already contained within the device node map and if so
just call local_pci_probe directly. That way you can avoid deadlocking
the system by trying to flush the CPU queue of the CPU you are currently on.
Thanks,
Alex
next prev parent reply other threads:[~2013-05-14 21:39 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1368498506-25857-1-git-send-email-yinghai@kernel.org>
2013-05-14 2:28 ` [PATCH 6/7] PCI: Make sure VF's driver get attached after PF's Yinghai Lu
2013-05-14 8:58 ` Yan Burman
2013-05-14 15:43 ` Yinghai Lu
2013-05-16 4:00 ` Or Gerlitz
2013-05-16 4:39 ` Yinghai Lu
2013-05-16 4:56 ` Or Gerlitz
2013-05-16 17:53 ` Tejun Heo
2013-05-16 18:36 ` Yinghai Lu
2013-05-20 12:23 ` Or Gerlitz
2013-05-14 9:46 ` Perla, Sathya
2013-05-14 15:19 ` Yinghai Lu
2013-05-14 16:00 ` Alexander Duyck
2013-05-14 18:44 ` Yinghai Lu
2013-05-14 19:45 ` Alexander Duyck
2013-05-14 19:59 ` Yinghai Lu
2013-05-14 21:39 ` Alexander Duyck [this message]
2013-05-21 21:30 ` Don Dutile
2013-05-21 21:31 ` Don Dutile
2013-05-21 21:58 ` Alexander Duyck
2013-05-21 22:09 ` Don Dutile
2013-05-21 22:12 ` Alexander Duyck
2013-05-21 21:49 ` Michael S. Tsirkin
2013-05-21 22:01 ` Alexander Duyck
2013-05-21 22:11 ` Michael S. Tsirkin
2013-05-21 22:30 ` Alexander Duyck
2013-05-22 20:16 ` Or Gerlitz
2013-05-22 21:40 ` Don Dutile
2013-05-23 6:43 ` Or Gerlitz
2013-05-22 23:45 ` Ben Hutchings
2013-05-23 6:32 ` Or Gerlitz
2013-05-16 6:39 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5192AEF4.1070905@intel.com \
--to=alexander.h.duyck@intel.com \
--cc=bhelgaas@google.com \
--cc=guz.fnst@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).