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: Fri, 16 Jan 2009 00:24:51 +0100 [thread overview]
Message-ID: <496FC5C3.1010401@s5r6.in-berlin.de> (raw)
In-Reply-To: <496FB744.90501@cybernetics.com>
Tony Battersby wrote:
> Stefan Richter wrote:
>> I wrote that there is a bug if you have a reference while the reference
>> count is zero.
>>
> Being pragmatic, I call that a _philosophical_ objection rather than a
> bug because the code does actually work in practice as far as I can
> tell. But you can call it a bug if you like. If you want me to give in
> and call it a bug, then you will have to come up with an actual case
> where the code fails to do the right thing - memory use after free,
> double free, memory leak, oops, etc.
I understood that you want to fix bugs which are caused by lack of
reference counting.
You fix it by /reference count estimation/.
(Yet you could also fix it by /reference counting/.)
Actual reference counting would have the benefit that it works not only
right after your fix, but it will continue to work when people proceed
to modify sg, provided they follow the sound, proven, straight-forward,
familiar rules of reference counting:
- r++ when a copy of a reference is made.
- r-- when a reference is given up.
Sure, it will also continue to work if those who modify sg follow the
ad-hoc rules of your special reference count estimation, which are:
- ...
- ...
- ...
I recommend to stick to the semantics of "refcount == 0 means there is
no reference anymore" because it's simple and robust. This is
pragmatism. I recommend it over "refcount == 0 means that there are,
hmm, still some references somewhere, but believe me, you can ignore
those" because that's not very pragmatic in code which is supposed to be
maintainable and to not crash people's machines.
In the subsystems which I maintain, I made the experience that reference
counting is easier to get right and keep right than some locking tricks
around reference stores or whatever other lifetime assumptions.
Anyway. Fix sg in whatever way you prefer; you are doing the work, your
opinion counts. Mine doesn't, as I don't contribute the code.
(I spoke up nevertheless because the idea came up in this thread to
change lib/kref in a way which is only useful to buggy refcounting.
This worried me..)
--
Stefan Richter
-=====-==--= ---= -====
http://arcgraph.de/sr/
next prev parent reply other threads:[~2009-01-15 23:25 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
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 [this message]
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=496FC5C3.1010401@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