From: Linus Torvalds <torvalds@linux-foundation.org>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
Matthew Wilcox <matthew@wil.cx>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] PCI: Make sriov work with hotplug remove
Date: Mon, 23 Jan 2012 10:45:35 -0800 [thread overview]
Message-ID: <CA+55aFyok04YrmEYXLbAE2vB_944+aEJZhd5tzu6U2k0CLaN5A@mail.gmail.com> (raw)
In-Reply-To: <CAE9FiQWbmO+FFsE06eQ=-PVNtdaTG3EsqXNXdUCxb9YxtPS8Cw@mail.gmail.com>
On Mon, Jan 23, 2012 at 10:30 AM, Yinghai Lu <yinghai@kernel.org> wrote:
> in list_for_each_safe()
>
> #define list_for_each_safe(pos, n, head) \
> for (pos = (head)->next, n = pos->next; pos != (head); \
> pos = n, n = pos->next)
>
> n is saved before, and safe only mean pos could be freed from the
> list, but n still can be used for next loop.
>
> in our case, the list have PF and several VFs, when
> pci_stop_bus_device() is called for PF, pos are still valid, but
> VFs are removed from the list. so n will not be valid.
That still doesn't explain anything.
The whole point of the safe version is that if the entry that is being
worked on is removed, then we can still use the next one.
Why isn't this magically true in this case? If some *other* random
entry than the one that is being iterated over can magically be
removed, then the whole thing is just pure and utter crap, and no
amount of list maintenance can ever fix it.
So explain.
> https://lkml.org/lkml/2011/10/15/141
> or from attached one.
This still doesn't make sense. Why do that stupid allocation? Why not
just move the entry? Why doesn't just the sane approach work?
Exactly why does not the obvious
/* stop bus device for phys_fn at first */
list_for_each_safe(l, n, &bus->devices) {
struct pci_dev *dev = pci_dev_b(l);
if (!dev->is_virtfn)
pci_stop_bus_device(dev);
}
work? What the f*^& does that pci_stop_bus_device() function do to
that bus->devices list that isn't just a "list_del()" of that single
entry? And if it does anything else, it should damn well stop doing
that.
The *exact* same loop is then apparently working for the virtual
device case, so what the hell is going on that it wouldn't work for
the physical one?
What's the confusion? Why all the crazy idiotic code that makes no sense?
Linus
next prev parent reply other threads:[~2012-01-23 18:45 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-21 9:52 [PATCH 0/7] PCI: pcie hotplug related patch Yinghai Lu
2012-01-21 9:52 ` [PATCH 1/7] PCI: Make sriov work with hotplug remove Yinghai Lu
2012-01-23 16:06 ` Linus Torvalds
2012-01-23 18:30 ` Yinghai Lu
2012-01-23 18:45 ` Linus Torvalds [this message]
2012-01-23 19:34 ` Linus Torvalds
2012-01-23 19:59 ` Yinghai Lu
2012-01-23 20:48 ` Yinghai Lu
2012-01-23 22:35 ` Linus Torvalds
2012-01-24 4:34 ` Benjamin Herrenschmidt
2012-01-23 19:36 ` Yinghai Lu
2012-01-23 19:44 ` Linus Torvalds
2012-01-23 21:34 ` Yinghai Lu
2012-01-23 22:30 ` Yinghai Lu
2012-01-23 22:38 ` Linus Torvalds
2012-01-21 9:52 ` [PATCH 2/7] PCI: Separate pci_bus_read_dev_vendor_id from pci_scan_device Yinghai Lu
2012-01-21 9:52 ` [PATCH 3/7] pciehp: Checking pci conf reading to new added device instead of sleep 1s Yinghai Lu
2012-01-21 9:52 ` [PATCH 4/7] pciehp: print out link status when dlla get active Yinghai Lu
2012-01-21 9:52 ` [PATCH 5/7] pciehp: Add pcie_wait_link_not_active() Yinghai Lu
2012-01-21 9:52 ` [PATCH 6/7] pciehp: Add Disable/enable link functions Yinghai Lu
2012-01-23 16:13 ` Linus Torvalds
2012-01-24 5:36 ` Yinghai Lu
2012-01-21 9:52 ` [PATCH 7/7] pciehp: Disable/enable link during slot power off/on Yinghai Lu
2012-01-21 10:26 ` [PATCH 0/7] PCI: pcie hotplug related patch Yinghai Lu
2012-01-27 18:36 ` Jesse Barnes
2012-01-27 18:58 ` Yinghai Lu
2012-01-30 3:42 ` Kenji Kaneshige
-- strict thread matches above, loose matches on Subject: below --
2012-01-27 18:55 [PATCH -v2 " Yinghai Lu
2012-01-27 18:55 ` [PATCH 1/7] PCI: Make sriov work with hotplug remove Yinghai Lu
2012-01-27 19:43 ` Jesse Barnes
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=CA+55aFyok04YrmEYXLbAE2vB_944+aEJZhd5tzu6U2k0CLaN5A@mail.gmail.com \
--to=torvalds@linux-foundation.org \
--cc=jbarnes@virtuousgeek.org \
--cc=kaneshige.kenji@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=matthew@wil.cx \
--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).