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: Thu, 15 Jan 2009 13:17:26 -0500	[thread overview]
Message-ID: <496F7DB6.6090506@cybernetics.com> (raw)
In-Reply-To: <496F62CC.8000007@s5r6.in-berlin.de>

Stefan Richter wrote:
> I believe your kref_get_not_zero() invention is because you want to
> count two unrelated numbers in the same counter.  This won't work, I'm
> afraid.
>
>   
It does work actually, just in a way that people don't seem to like very
much.  And it is not really my invention; other people have run into the
same problem and come up with the same solution.  Sometimes people drop
kref and go directly to using atomic ops just so that they can use
atomic_inc_not_zero() without "violating" the kref API.

> One number is
>   - the number of unfinished transactions (request->response)
> of an sg device.  (Is that struct sg_device, or struct sg_fd?)
>
> The other number is
>   - the number of contexts which peek and poke at the device
> representation's memory.  (struct sg_device, or struct sg_fd?)
>
> These two numbers are of course unrelated.  Hence I recommend you count
> them in separate counters.
>
>   
I might be able to get this to work, but is it really better than
kref_get_not_zero()?  And since there are actually two different types
of objects being refcounted with the same issue (sg_fd and sg_device),
applying the same "trick" to both might require (ugh) four counters
total.  Does anyone else favor this approach?  I expect that if I put
the effort into a patch that does this, someone else will just tell me
to do it some other way.  But if someone else seconds your proposal, I
will give it a try.  Please, cast your votes now.

Rant:
1) I posted a patch that fixes a bunch of oopses.
2) I was told to use a kref because it makes things "simpler".
3) I posted a second patch using one kref, being very careful to avoid
the subtle pitfalls of the kref API.
4) Someone else modified my patch to use two krefs to make things "even
simpler", but it was subtly broken because krefs aren't an ideal fit for
this problem.
5) I fixed the patch that used two krefs by extending the kref API.
6) I get flamed all to hell.
7) I am told to use three krefs now, using one kref to refcount another
kref.  However, it may be necessary to use as many as four.
8) I give up being a programmer, move to Wisconsin, and become a dairy
farmer.

I am of course just joking around and not actually offended, but this
whole thing is starting to seem a bit silly.  How much more complicated
does it have to get just to make things simpler?  NIH syndrome, anyone?

--Tony "moo cow" Battersby


  parent reply	other threads:[~2009-01-15 18:17 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
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 [this message]
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=496F7DB6.6090506@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