From: Andrew Morton <akpm@osdl.org>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
"Eric Dumazet" <dada1@cosmosbay.com>, "Greg KH" <gregkh@suse.de>,
"Arjan" <arjan@linux.intel.com>,
"linux-kernel" <linux-kernel@vger.kernel.org>
Subject: Re: kref refcnt and false positives
Date: Thu, 14 Dec 2006 16:35:19 -0800 [thread overview]
Message-ID: <20061214163519.9e5f4f64.akpm@osdl.org> (raw)
In-Reply-To: <m13b7ivwlw.fsf@ebiederm.dsl.xmission.com>
On Thu, 14 Dec 2006 17:19:55 -0700
ebiederm@xmission.com (Eric W. Biederman) wrote:
> "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> writes:
>
> >>But I believe Venkatesh problem comes from its release()
> >>function : It is
> >>supposed to free the object.
> >>If not, it should properly setup it so that further uses are OK.
> >>
> >>ie doing in release(kref)
> >>atomic_set(&kref->count, 0);
> >>
> >
> > Agreed that setting kref refcnt to 0 in release will solve the probloem.
> > But, once the optimization code is removed, we don't need to set it to
> > zero as release will only be called after the count reaches zero anyway.
>
> The primary point of the optimization is to not write allocate a cache line
> unnecessarily. I don't know it's value, but it can have one especially
> on big way SMP machines.
Guys, we have about 1000000000000000000000000000000 reports of weirdo
crashes, smashes, bashes and splats in the kref code. The last thing we
need is some obscure, tricksy little optimisation which leads legitimate
uses of the API to mysteriously fail.
If we are allocating and freeing kref-counted objects at a sufficiently
high frequency for this thing to make a difference then we should fix that
instead of trying to suck faster.
next prev parent reply other threads:[~2006-12-15 0:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-14 23:51 Pallipadi, Venkatesh
2006-12-15 0:19 ` Eric W. Biederman
2006-12-15 0:35 ` Andrew Morton [this message]
2006-12-15 0:53 ` Eric W. Biederman
[not found] <200612210901.kBL91MwR027509@hera.kernel.org>
2006-12-31 15:16 ` David Woodhouse
2007-01-01 20:13 ` Benjamin Herrenschmidt
-- strict thread matches above, loose matches on Subject: below --
2006-12-13 23:34 Venkatesh Pallipadi
2006-12-14 0:12 ` Greg KH
2006-12-14 0:08 ` Venkatesh Pallipadi
2006-12-14 0:41 ` Andrew Morton
2006-12-14 7:56 ` Eric Dumazet
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=20061214163519.9e5f4f64.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=arjan@linux.intel.com \
--cc=dada1@cosmosbay.com \
--cc=ebiederm@xmission.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=venkatesh.pallipadi@intel.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
all inboxes | Powered by JetHome®