public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Battersby <tonyb@cybernetics.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Greg KH <greg@kroah.com>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	dgilbert@interlog.com, James.Bottomley@HansenPartnership.com,
	hch@infradead.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 0/2] sg: fix races during device removal (v2)
Date: Wed, 14 Jan 2009 17:53:21 -0500	[thread overview]
Message-ID: <496E6CE1.9040404@cybernetics.com> (raw)
In-Reply-To: <496E6853.1010005@s5r6.in-berlin.de>

Stefan Richter wrote:
> Greg KH wrote:
>   
>> On Wed, Jan 14, 2009 at 03:31:15PM -0500, Tony Battersby wrote:
>>     
>>> 4) Add a variation of kref_get() that uses atomic_inc_not_zero().
>>>       
>> Ick.
>>     
>
> I missed the most part of this thread.  But in the grandparent post,
> Tony wrote:
>
>   
>>> Fujita, your patch results in simpler code than my version 2 patch,
>>> but it still leaves some subtle races and other problems.  The crux
>>> of the problem is that kref_put() needs do be done while holding a
>>> lock if there is still a way for some other CPU to find a reference
>>> to the object in between the time the refcount drops to 0 and the
>>> time the destructor is called.
>>>       
>
> This sounds bogus to me.  If "some other CPU can find a reference to the
> object" after the reference count dropped to zero, then the problem is
> IMO clear and simple:
>
> Some site did not increase the refcount when it should.
>   
The original code makes it possible to find the object and get
information about it right up until the point that the destructor is
called.  However, adding a reference just for this purpose would prevent
the object from ever being freed.  Removing the ability to get
information about closed fds or deleted devices that still have
outstanding commands changes the user-visible behavior, which I didn't
want to do in a patch that is just trying to fix a bunch of oopses. 
However, if the solution that I have proposed isn't acceptable, then
that is exactly what will have to happen.  I can live with that if that
is the consensus, but I was trying to avoid it.

Tony

  reply	other threads:[~2009-01-14 22:53 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-05 19:07 [PATCH 0/2] sg: fix races during device removal (v2) Tony Battersby
2009-01-08 23:21 ` Douglas Gilbert
2009-01-10 17:26 ` FUJITA Tomonori
2009-01-12 21:09   ` Tony Battersby
2009-01-13 16:24     ` FUJITA Tomonori
2009-01-14 20:31   ` Tony Battersby
2009-01-14 21:39     ` Greg KH
2009-01-14 21:59       ` Tony Battersby
2009-01-14 22:33       ` Stefan Richter
2009-01-14 22:53         ` Tony Battersby [this message]
2009-01-14 23:47           ` Stefan Richter
2009-01-15 14:47             ` Tony Battersby
2009-01-15 16:22               ` Stefan Richter
2009-01-15 16:44                 ` Stefan Richter
2009-01-15 18:17                 ` Tony Battersby
2009-01-15 18:47                   ` Stefan Richter
2009-01-15 19:14                     ` Stefan Richter
2009-01-15 19:20                     ` Tony Battersby
2009-01-15 20:43                       ` Stefan Richter
2009-01-15 21:43                         ` Tony Battersby
2009-01-15 21:58                           ` Stefan Richter
2009-01-15 22:23                             ` Tony Battersby
2009-01-15 23:24                               ` Stefan Richter
2009-01-16 14:16                                 ` Tony Battersby
2009-01-16  0:53                           ` Stefan Richter
2009-01-16  8:09                 ` Stefan Richter
2009-01-19  6:57     ` FUJITA Tomonori
2009-01-19 15:02       ` Tony Battersby
2009-01-19 23:03       ` [PATCH 1/2] sg: fix races during device removal (v4) Tony Battersby
2009-01-20  1:06         ` FUJITA Tomonori
2009-01-20 21:58           ` [PATCH 1/2] sg: fix races during device removal (v5) Tony Battersby
2009-01-21 18:25             ` Stefan Richter
2009-01-21 19:23               ` Tony Battersby
2009-01-21 19:45             ` [PATCH 1/2] sg: fix races during device removal (v6) Tony Battersby
2009-01-25 12:46               ` FUJITA Tomonori
2009-01-26 13:57               ` Douglas Gilbert
2009-01-28  1:51                 ` FUJITA Tomonori
2009-01-28 15:06                   ` James Bottomley
2009-01-20 22:00           ` [PATCH 2/2] sg: fix races with ioctl(SG_IO) (v2) Tony Battersby
2009-01-25 12:46             ` FUJITA Tomonori
2009-01-19 23:06       ` [PATCH 2/2] sg: fix races with ioctl(SG_IO) Tony Battersby

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=496E6CE1.9040404@cybernetics.com \
    --to=tonyb@cybernetics.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=dgilbert@interlog.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=greg@kroah.com \
    --cc=hch@infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=stefanr@s5r6.in-berlin.de \
    /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