From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Yinghai Lu <yinghai@kernel.org>,
Gu Zheng <guz.fnst@cn.fujitsu.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] PCI: Fix racing for pci device removing via sysfs
Date: Mon, 29 Apr 2013 14:23:50 -0700 [thread overview]
Message-ID: <20130429212350.GA14978@xanatos> (raw)
In-Reply-To: <20130429182142.GA3385@kroah.com>
On Mon, Apr 29, 2013 at 11:21:42AM -0700, Greg Kroah-Hartman wrote:
> On Mon, Apr 29, 2013 at 11:15:50AM -0700, Bjorn Helgaas wrote:
> > On Mon, Apr 29, 2013 at 08:19:10AM -0700, Yinghai Lu wrote:
> > > On Mon, Apr 29, 2013 at 3:04 AM, Gu Zheng <guz.fnst@cn.fujitsu.com> wrote:
> > > > On 04/27/2013 05:01 AM, Yinghai Lu wrote:
> > > >> On Fri, Apr 26, 2013 at 1:53 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > > >>>
> > > >>> You can't be serious. This is a disgusting mess. Checking a list
> > > >>> pointer for LIST_POISON1? As far as I'm concerned, this is a waste of
> > > >>> my time.
> > >
> > > looks like xhci is using that LIST_POISON1 ...
> > >
> > Maybe my allergic reaction to your use of LIST_POISON1 is unjustified,
> > but I am dubious about the idea that xhci was the only place that needed
> > it before now, and we just happened to find one more place in PCI that
> > needs it. That doesn't make sense because good design patterns are used
> > many times, not just once or twice.
> >
> > I thought the whole point of the get/put scheme was that if we had a
> > pointer to a correctly reference-counted object, we didn't need to check
> > whether the object was still valid because the object remains valid until
> > all the references are released.
>
> You are correct, you shouldn't have to worry about that. If you have to
> do something like the LIST_POISON test, something is really wrong.
All right, I'll take a look at the xHCI code. From a brief glance, both
places that use LIST_POISON are handling a timed-out command. The
command handling in xHCI needs to get completely reworked anyway, due to
other race conditions.
Were you suggesting I use the get/put scheme in the xHCI driver, or was
that for Yinghai?
Sarah Sharp
next prev parent reply other threads:[~2013-04-29 21:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-26 1:47 [PATCH] PCI: Fix racing for pci device removing via sysfs Yinghai Lu
2013-04-26 16:28 ` Bjorn Helgaas
2013-04-26 20:20 ` Yinghai Lu
2013-04-26 20:53 ` Bjorn Helgaas
2013-04-26 21:01 ` Yinghai Lu
2013-04-29 10:04 ` Gu Zheng
2013-04-29 15:19 ` Yinghai Lu
2013-04-29 18:15 ` Bjorn Helgaas
2013-04-29 18:21 ` Greg Kroah-Hartman
2013-04-29 21:23 ` Sarah Sharp [this message]
2013-04-29 21:32 ` Greg Kroah-Hartman
2013-04-29 22:17 ` Yinghai Lu
2013-04-30 21:29 ` Yinghai Lu
2013-05-08 23:43 ` Bjorn Helgaas
2013-04-30 9:17 ` Gu Zheng
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=20130429212350.GA14978@xanatos \
--to=sarah.a.sharp@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=guz.fnst@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@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).