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: <20140212.230953.770721407102955395.davem@davemloft.net>
Date:	Wed, 12 Feb 2014 23:09:53 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	gregkh@...uxfoundation.org
Cc:	mst@...hat.com, linux-kernel@...r.kernel.org, jasowang@...hat.com,
	virtio-dev@...ts.oasis-open.org,
	virtualization@...ts.linux-foundation.org, netdev@...r.kernel.org,
	qinchuanyu@...wei.com, joern@...fs.org, anatol.pomozov@...il.com,
	nab@...ux-iscsi.org
Subject: Re: [PATCH net 1/3] kref: add kref_sub_return

From: David Miller <davem@...emloft.net>
Date: Wed, 12 Feb 2014 23:05:06 -0500 (EST)

> From: Greg KH <gregkh@...uxfoundation.org>
> Date: Wed, 12 Feb 2014 17:39:02 -0800
> 
>> Yes, that's horrible as well, but as was already pointed out in this
>> thread, you can't rely on that value to really be "1" after reading it
>> due to the way krefs work, what happened if someone else just grabbed
>> it?
>> 
>> If all they want is a "count" for when to start polling, then use a
>> separate atomic count, but don't abuse the kref interface for this, I
>> don't think that will work properly at all.
> 
> They want to know which thread of control decrements the count to "1"
> as buffers are released.
> 
> That seems entirely reasonable to me.
> 
> They could add another atomic counter for this, but that's rather
> silly since the kref already has an atomic they can use for this
> purpose.

If you still can't understand what they are trying to do, they want to
do something precisely when the number of pending buffers is dropped
to 1 or less.

They are using krefs to track how many buffers are attached at a given
moment.

The counter can re-increment after the decrement to 1 or less occurs,
they don't care.

But they want precisely the entity that drops it down to 1 or less to
perform that action.

Just reading the atomic value directly, they cannot do this.


--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ