On Wed, Nov 20, 2013 at 9:47 PM, Bjorn Helgaas <bhelg...@google.com> wrote:
> [+cc Jiri]
>
> On Wed, Nov 20, 2013 at 9:26 PM, Sasha Levin <sasha.le...@oracle.com> wrote:
>> On 11/18/2013 03:39 PM, Bjorn Helgaas wrote:
>>>
>>> On Mon, Nov 18, 2013 at 11:29:32AM -0800, Yinghai Lu wrote:
>>>>
>>>> On Mon, Nov 18, 2013 at 10:14 AM, Bjorn Helgaas <bhelg...@google.com>
>>>> wrote:
>>>>>>
>>>>>> A bit of comment here would be nice but yeah I think this should work.
>>>>>> Can you please also queue the revert of c2fda509667b ("workqueue:
>>>>>> allow work_on_cpu() to be called recursively") after this patch?
>>>>>> Please feel free to add my acked-by.
>>>>>
>>>>>
>>>>> OK, below are the two patches (Alex's fix + the revert) I propose to
>>>>> merge. Unless there are objections, I'll ask Linus to pull these
>>>>> before v3.13-rc1.
>>>>>
>>>>>
>>>>>
>>>>> commit 84f23f99b507c2c9247f47d3db0f71a3fd65e3a3
>>>>> Author: Alexander Duyck <alexander.h.du...@intel.com>
>>>>> Date: Mon Nov 18 10:59:59 2013 -0700
>>>>>
>>>>> PCI: Avoid unnecessary CPU switch when calling driver .probe()
>>>>> method
>>>>>
>>>>> If we are already on a CPU local to the device, call the driver
>>>>> .probe()
>>>>> method directly without using work_on_cpu().
>>>>>
>>>>> This is a workaround for a lockdep warning in the following
>>>>> scenario:
>>>>>
>>>>> pci_call_probe
>>>>> work_on_cpu(cpu, local_pci_probe, ...)
>>>>> driver .probe
>>>>> pci_enable_sriov
>>>>> ...
>>>>> pci_bus_add_device
>>>>> ...
>>>>> pci_call_probe
>>>>> work_on_cpu(cpu, local_pci_probe, ...)
>>>>>
>>>>> It would be better to fix PCI so we don't call VF driver .probe()
>>>>> methods
>>>>> from inside a PF driver .probe() method, but that's a bigger
>>>>> project.
>>>>>
>>>>> [bhelgaas: disable preemption, open bugzilla, rework comments &
>>>>> changelog]
>>>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=65071
>>>>> Link:
>>>>> http://lkml.kernel.org/r/CAE9FiQXYQEAZ=0sg6+2odffbqfls9mpon1xvirr9adbxpxc...@mail.gmail.com
>>>>> Link:
>>>>> http://lkml.kernel.org/r/20130624195942.40795.27292.st...@ahduyck-cp1.jf.intel.com
>>>>> Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com>
>>>>> Signed-off-by: Bjorn Helgaas <bhelg...@google.com>
>>>>> Acked-by: Tejun Heo <t...@kernel.org>
>>>>
>>>>
>>>> Tested-by: Yinghai Lu <ying...@kernel.org>
>>>> Acked-by: Yinghai Lu <ying...@kernel.org>
>>>
>>>
>>> Thanks, I added these and pushed my for-linus branch for -next to
>>> pick up before I ask Linus to pull them.
>>
>>
>> Hi guys,
>>
>> This patch seems to be causing virtio (wouldn't it happen with any other
>> driver too?) to give
>> the following spew:
>
> Yep, Jiri Slaby reported this earlier. I dropped those patches for
> now. Yinghai and I both tested this without incident, but we must
> have tested quite the same scenario you did.
>
> I'll look at this more tomorrow. My first thought is that it's
> probably silly to worry about preemption when checking the node. It's
> unlikely that we'd be preempted (probably not even possible except at
> hot add-time), and the worst that can happen is we run the .probe()
> method on the wrong node, which means worse performance but correct
> functionality.
I dropped the preempt_disable() and re-added this to my for-linus
branch. Let me know if you see any more issues.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
