From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Tony Battersby <tonyb@cybernetics.com>
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 19:47:06 +0100 [thread overview]
Message-ID: <496F84AA.9060708@s5r6.in-berlin.de> (raw)
In-Reply-To: <496F7DB6.6090506@cybernetics.com>
Tony Battersby wrote:
> 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.
No, it doesn't work. You can track how many transactions are pending,
and you can track how many sites look at memory X, but you can't track
both issues in the same counter.
If you only count pending transactions, you know when to deregister the
device from the idr. But you don't know when it's OK to free the
device's memory.
If you cont only references to the memory, you know when it is OK to
free it but you don't know when to deregister from the idr.
> And it is not really my invention; other people have run into the
> same problem and come up with the same solution.
Perhaps these people did not analyze rigorously what it really is what
they want to count?
...
> Please, cast your votes now.
I for one am not interested in what you guys do with sg.
However, the proposal to change the kref API in a way which IMO
undermines the whole principle of reference counting motivated me to
comment in this thread, to try to understand what you want to solve, and
to propose something.
What is this kref_get_not_zero()? Do you want to encode object state
into the reference counter? That's not the purpose of a reference
count; use separate object attribute for that. The reference count says
how many sites look at the object. Nothing more, nothing less.
> 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.
...
> How much more complicated does it have to get just to make things simpler?
As I said: Why count independent numbers with a single counter?
Count number A with counter a. Count number B with counter b. This is
easy, works 100%, and is obvious to everybody. How much simpler than
that can it get?
--
Stefan Richter
-=====-==--= ---= -====
http://arcgraph.de/sr/
next prev parent reply other threads:[~2009-01-15 18:47 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
2009-01-15 18:47 ` Stefan Richter [this message]
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=496F84AA.9060708@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--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=tonyb@cybernetics.com \
/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