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]
Date:	Fri, 1 Jul 2016 09:08:34 +0200
From:	Thomas Hellstrom <thellstrom@...are.com>
To:	Dave Airlie <airlied@...hat.com>
CC:	"Jason A. Donenfeld" <Jason@...c4.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
Subject: Patch for drm-next WAS Re: [PATCH] kref: prefer atomic_inc_not_zero
 to atomic_add_unless

Dave,

Since kref_get_unless_zero() was brought in by drm, could we add this to
drm-next?

Thanks,
Thomas


On 06/30/2016 12:52 AM, Jason A. Donenfeld wrote:
> This was positively reviewed by maintainers but never picked up. Can
> someone queue this for 4.7 or 4.8?
>
> Thanks,
> Jason
>
> On Mon, Feb 1, 2016 at 10:53 PM, Jason A. Donenfeld <Jason@...c4.com> wrote:
>> This was positively reviewed but never picked up. Can someone queue
>> this for rc3?
>>
>> Thanks,
>> Jason
>>
>> On Sun, Oct 11, 2015 at 9:59 PM, Thomas Hellstrom <thellstrom@...are.com> wrote:
>>> Reviewed-by: Thomas Hellstrom <thellstrom@...are.com>
>>>
>>>
>>> On 10/10/2015 12:56 PM, Jason A. Donenfeld wrote:
>>>> On most platforms, there exists this ifdef:
>>>>
>>>>  #define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
>>>>
>>>> This makes this patch functionally useless. However, on PPC, there is
>>>> actually an explicit definition of atomic_inc_not_zero with its own
>>>> assembly that is slightly more optimized than atomic_add_unless. So,
>>>> this patch changes kref to use atomic_inc_not_zero instead, for PPC and
>>>> any future platforms that might provide an explicit implementation.
>>>>
>>>> This also puts this usage of kref more in line with a verbatim reading
>>>> of the examples in Paul McKenney's paper [1] in the section titled "2.4
>>>> Atomic Counting With Check and Release Memory Barrier", which uses
>>>> atomic_inc_not_zero.
>>>>
>>>> [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__open-2Dstd.org_jtc1_sc22_wg21_docs_papers_2007_n2167.pdf&d=BQIBAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=z5Nd9sYiJMKiphNjyZp6XT5CbayXMBlcb903f260pDY&s=HEHX3CuXRs2GRRQWuC4Vef6iJMwdilKVRkiZgJpjEpA&e=
>>>>
>>>> Signed-off-by: Jason A. Donenfeld <Jason@...c4.com>
>>>> ---
>>>>  include/linux/kref.h | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/include/linux/kref.h b/include/linux/kref.h
>>>> index 484604d..83d1f94 100644
>>>> --- a/include/linux/kref.h
>>>> +++ b/include/linux/kref.h
>>>> @@ -166,6 +166,6 @@ static inline int kref_put_mutex(struct kref *kref,
>>>>   */
>>>>  static inline int __must_check kref_get_unless_zero(struct kref *kref)
>>>>  {
>>>> -     return atomic_add_unless(&kref->refcount, 1, 0);
>>>> +     return atomic_inc_not_zero(&kref->refcount);
>>>>  }
>>>>  #endif /* _KREF_H_ */


Powered by blists - more mailing lists