From: Greg KH <greg@kroah.com>
To: Jens Axboe <jaxboe@fusionio.com>
Cc: Jerome Marchand <jmarchan@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>,
Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] block: fix accounting bug on cross partition merges
Date: Wed, 5 Jan 2011 12:08:25 -0800 [thread overview]
Message-ID: <20110105200825.GA11372@kroah.com> (raw)
In-Reply-To: <4D24BC88.4090804@fusionio.com>
On Wed, Jan 05, 2011 at 07:46:32PM +0100, Jens Axboe wrote:
> On 2011-01-05 16:58, Greg KH wrote:
> > On Wed, Jan 05, 2011 at 02:55:51PM +0100, Jens Axboe wrote:
> >> On 2011-01-04 22:00, Greg KH wrote:
> >>> On Tue, Jan 04, 2011 at 04:55:13PM +0100, Jerome Marchand wrote:
> >>>> Also add a refcount to struct hd_struct to keep the partition in
> >>>> memory as long as users exist. We use kref_test_and_get() to ensure
> >>>> we don't add a reference to a partition which is going away.
> >>>
> >>> No, don't do this, use a kref correctly and no such function should be
> >>> needed.
> >>>
> >>>> + } else {
> >>>> + part = disk_map_sector_rcu(rq->rq_disk, blk_rq_pos(rq));
> >>>
> >>> That is the function that should properly increment the reference count
> >>> on the object. If the object is "being removed", then it will return
> >>> NULL and you need to check that. Do that and you do not need to add:
> >>
> >> It doesn't matter if you do it in there of after the fact, since the
> >> "lock" (RCU) is being held across the call. See my original suggestion
> >> here:
> >>
> >> https://lkml.org/lkml/2010/12/17/275
> >
> > Ok, that's fine, just do it without adding that kref function and I have
> > no objection :)
>
> Why? The code is perfectly fine. I originally objected to making an API
> like this for simple reference counting - seems I was right. Please
> actually look at the code and use. Alexey asked whether this was a toy
> API or a real one, I'd like to know that as well. If this is meant just
> for very basic get/put references, fine, then document that. But then
> what's the point of having this API in the first place?
The point is that you shouldn't have to roll your own reference count
code all over the place, 99% of the time, you should just use the
debugged, and documented, interface that the kernel provides with the
kref interface.
As for it being a "toy", it properly handles a very large majority of
the kernel reference counting logic today, in a race-free manner, so I
would not call that a "toy" at all.
Just use it properly. As this patch series points out, adding this type
of function to the api is not a good idea, as it will be incorrect when
used.
thanks,
greg k-h
next prev parent reply other threads:[~2011-01-05 20:47 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-06 9:44 [PATCH 1/2] Don't merge different partition's IOs Yasuaki Ishimatsu
2010-12-06 16:08 ` Linus Torvalds
2010-12-07 7:18 ` Satoru Takeuchi
2010-12-07 18:39 ` Vivek Goyal
2010-12-08 7:33 ` Jens Axboe
2010-12-08 7:59 ` Satoru Takeuchi
2010-12-08 8:06 ` Jens Axboe
2010-12-08 8:11 ` Satoru Takeuchi
2010-12-08 14:46 ` Jens Axboe
2010-12-08 15:51 ` Vivek Goyal
2010-12-08 15:58 ` Vivek Goyal
2010-12-10 11:22 ` Jerome Marchand
2010-12-10 16:12 ` Jerome Marchand
2010-12-10 16:55 ` Vivek Goyal
2010-12-14 20:25 ` Jens Axboe
2010-12-17 13:42 ` [PATCH] block: fix accounting bug on cross partition merges Jerome Marchand
2010-12-17 19:06 ` Jens Axboe
2010-12-17 22:32 ` Vivek Goyal
2010-12-23 15:10 ` Jerome Marchand
2010-12-23 15:39 ` Vivek Goyal
2010-12-23 17:04 ` Jerome Marchand
2010-12-24 19:29 ` Vivek Goyal
2011-01-04 15:52 ` [PATCH 1/2] kref: add kref_test_and_get Jerome Marchand
2011-01-04 15:55 ` [PATCH 2/2] block: fix accounting bug on cross partition merges Jerome Marchand
2011-01-04 21:00 ` Greg KH
2011-01-05 13:51 ` Jerome Marchand
2011-01-05 16:00 ` Greg KH
2011-01-05 16:19 ` Jerome Marchand
2011-01-05 16:27 ` Greg KH
2011-01-05 13:55 ` Jens Axboe
2011-01-05 15:58 ` Greg KH
2011-01-05 18:46 ` Jens Axboe
2011-01-05 20:08 ` Greg KH [this message]
2011-01-05 21:38 ` Jens Axboe
2011-01-05 22:16 ` Greg KH
2011-01-06 9:46 ` Jens Axboe
2011-01-05 14:00 ` Jens Axboe
2011-01-05 14:09 ` Jerome Marchand
2011-01-05 14:17 ` Jens Axboe
2011-01-04 16:05 ` [PATCH 1/2] kref: add kref_test_and_get Eric Dumazet
2011-01-05 15:02 ` [PATCH 1/2 v2] " Jerome Marchand
2011-01-05 15:43 ` Alexey Dobriyan
2011-01-05 15:57 ` Greg KH
2011-01-05 15:56 ` Greg KH
2011-01-04 20:57 ` [PATCH 1/2] " Greg KH
2011-01-05 13:35 ` Jerome Marchand
2011-01-05 15:55 ` Greg KH
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=20110105200825.GA11372@kroah.com \
--to=greg@kroah.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=jaxboe@fusionio.com \
--cc=jmarchan@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=takeuchi_satoru@jp.fujitsu.com \
--cc=torvalds@linux-foundation.org \
--cc=vgoyal@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.