[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210826194113.yihk7ete4n4ej4gz@liuwe-devbox-debian-v2>
Date: Thu, 26 Aug 2021 19:41:13 +0000
From: Wei Liu <wei.liu@...nel.org>
To: Michael Kelley <mikelley@...rosoft.com>
Cc: Long Li <longli@...rosoft.com>, Wei Liu <wei.liu@...nel.org>,
"longli@...uxonhyperv.com" <longli@...uxonhyperv.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
Dexuan Cui <decui@...rosoft.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Rob Herring <robh@...nel.org>,
Krzysztof WilczyĆski <kw@...ux.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Dan Carpenter <dan.carpenter@...cle.com>
Subject: Re: [PATCH] PCI: hv: Fix a bug on removing child devices on the bus
On Thu, Aug 26, 2021 at 04:50:28PM +0000, Michael Kelley wrote:
> From: Long Li <longli@...rosoft.com> Sent: Wednesday, August 25, 2021 1:25 PM
>
> > >
> > > I thought list_for_each_entry_safe() is for use when list manipulation is *not*
> > > protected by a lock and you want to safely walk the list even if an entry gets
> > > removed. If the list is protected by a lock or not subject to contention (as is the
> > > case here), then
> > > list_for_each_entry() is the simpler implementation. The original
> > > implementation didn't need to use the _safe version because of the spin lock.
> > >
> > > Or do I have it backwards?
> > >
> > > Michael
> >
> > I think we need list_for_each_entry_safe() because we delete the list elements while going through them:
> >
> > Here is the comment on list_for_each_entry_safe():
> > /**
> > * Loop through the list, keeping a backup pointer to the element. This
> > * macro allows for the deletion of a list element while looping through the
> > * list.
> > *
> > * See list_for_each_entry for more details.
> > */
> >
>
> Got it. Thanks (and to Rob Herring). I read that comment but
> with the wrong assumptions and didn't understand it correctly.
>
> Interestingly, pci-hyperv.c has another case of looping through
> this list and removing items where the _safe version is not used.
> See pci_devices_present_work() where the missing children are
> moved to a list on the stack.
That can be converted too, I think.
The original code is not wrong per-se. It is just not as concise as
using list_for_each_entry_safe.
Wei.
>
> Michael
Powered by blists - more mailing lists