linux-kernel - Re: kref refcnt and false positives

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m13b7ivwlw.fsf@ebiederm.dsl.xmission.com>
Date:	Thu, 14 Dec 2006 17:19:55 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
Cc:	"Eric Dumazet" <dada1@...mosbay.com>,
	"Andrew Morton" <akpm@...l.org>, "Greg KH" <gregkh@...e.de>,
	"Arjan" <arjan@...ux.intel.com>,
	"linux-kernel" <linux-kernel@...r.kernel.org>
Subject: Re: kref refcnt and false positives

"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.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.

If the optimization is not performed setting the value to 0 immediately
there after has not real cost as your cpu has the dirty cache line
already.  If the optimization is performed you still have to dirty
the cache line but at least you don't have to allocate it.

How that compares to the branch mispredict in cost I don't know, except
that cache line misses are the only operation that is generally
more expensive than branch misses.

So I see no virtue in avoiding the atomic_set(&kref->count, 0) if
you are about to immediately reuse the data structure.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/