search for: krefs

It is sometimes useful to get the value of the reference count after decrement. For example, vhost wants to execute some periodic cleanup operations once number of references drops below a specific value, before it reaches zero (for efficiency). Add an API to do this atomically and efficiently using atomic_sub_return. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Greg, could

This fixes a deadlock with vhost reported in the field, as well as a theoretical race issue found by code review. Patches 1+2 are needed for stable. Thanks to Qin Chuanyu for reporting the issue! Michael S. Tsirkin (3): kref: add kref_sub_return vhost: fix ref cnt checking deadlock vhost: fix a theoretical race in device cleanup include/linux/kref.h | 33

This fixes a deadlock with vhost reported in the field, as well as a theoretical race issue found by code review. Patches 1+2 are needed for stable. Thanks to Qin Chuanyu for reporting the issue! Michael S. Tsirkin (3): kref: add kref_sub_return vhost: fix ref cnt checking deadlock vhost: fix a theoretical race in device cleanup include/linux/kref.h | 33

...rom: Greg KH <gregkh at linuxfoundation.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....

...rom: Greg KH <gregkh at linuxfoundation.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....

vhost checked the counter within the refcnt before decrementing. It really wanted to know that it is the one that has the last reference, as a way to batch freeing resources a bit more efficiently. Note: we only let refcount go to 0 on device release. This works well but we now access the ref counter twice so there's a race: all users might see a high count and decide to defer freeing

vhost checked the counter within the refcnt before decrementing. It really wanted to know that it is the one that has the last reference, as a way to batch freeing resources a bit more efficiently. Note: we only let refcount go to 0 on device release. This works well but we now access the ref counter twice so there's a race: all users might see a high count and decide to defer freeing

On Wed, Feb 12, 2014 at 06:38:21PM +0200, Michael S. Tsirkin wrote: > It is sometimes useful to get the value of the reference count after > decrement. > For example, vhost wants to execute some periodic cleanup operations > once number of references drops below a specific value, before it > reaches zero (for efficiency). You should never care about what the value of the kref is,

On Wed, Feb 12, 2014 at 06:38:21PM +0200, Michael S. Tsirkin wrote: > It is sometimes useful to get the value of the reference count after > decrement. > For example, vhost wants to execute some periodic cleanup operations > once number of references drops below a specific value, before it > reaches zero (for efficiency). You should never care about what the value of the kref is,

...docs - danvet * Modify diagrams to show how the DRM driver interacts with the topology and payloads - danvet * Make suggested documentation changes for drm_dp_mst_topology_get_mstb() and drm_dp_mst_topology_get_port() - danvet * Better explain the relationship between malloc refs and topology krefs in the documentation for drm_dp_mst_topology_get_port() and drm_dp_mst_topology_get_mstb() - danvet * Fix "See also" in drm_dp_mst_topology_get_mstb() - danvet * Rename drm_dp_mst_topology_get_(port|mstb)() -> drm_dp_mst_topology_try_get_(port|mstb)() and drm_dp_mst_topology_re...

...lower. > > Right now they are reading the atomic refcount directly, which > I think is much worse than this helper. 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. thanks, greg k-h

...lower. > > Right now they are reading the atomic refcount directly, which > I think is much worse than this helper. 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. thanks, greg k-h

...t linuxfoundation.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 wi...

...docs - danvet * Modify diagrams to show how the DRM driver interacts with the topology and payloads - danvet * Make suggested documentation changes for drm_dp_mst_topology_get_mstb() and drm_dp_mst_topology_get_port() - danvet * Better explain the relationship between malloc refs and topology krefs in the documentation for drm_dp_mst_topology_get_port() and drm_dp_mst_topology_get_mstb() - danvet * Fix "See also" in drm_dp_mst_topology_get_mstb() - danvet * Rename drm_dp_mst_topology_get_(port|mstb)() -> drm_dp_mst_topology_try_get_(port|mstb)() and drm_dp_mst_topology_re...

On Thu, Dec 13, 2018 at 08:25:32PM -0500, Lyude Paul wrote: > The current way of handling refcounting in the DP MST helpers is really > confusing and probably just plain wrong because it's been hacked up many > times over the years without anyone actually going over the code and > seeing if things could be simplified. > > To the best of my understanding, the current scheme

The current way of handling refcounting in the DP MST helpers is really confusing and probably just plain wrong because it's been hacked up many times over the years without anyone actually going over the code and seeing if things could be simplified. To the best of my understanding, the current scheme works like this: drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When

On Tue, Dec 18, 2018 at 04:27:58PM -0500, Lyude Paul wrote: > On Fri, 2018-12-14 at 10:29 +0100, Daniel Vetter wrote: > > On Thu, Dec 13, 2018 at 08:25:32PM -0500, Lyude Paul wrote: > > > The current way of handling refcounting in the DP MST helpers is really > > > confusing and probably just plain wrong because it's been hacked up many > > > times over the

On Fri, 2018-12-14 at 10:29 +0100, Daniel Vetter wrote: > On Thu, Dec 13, 2018 at 08:25:32PM -0500, Lyude Paul wrote: > > The current way of handling refcounting in the DP MST helpers is really > > confusing and probably just plain wrong because it's been hacked up many > > times over the years without anyone actually going over the code and > > seeing if things

Implement reference counting for struct drm_gpuvm. Signed-off-by: Danilo Krummrich <dakr at redhat.com> --- drivers/gpu/drm/drm_gpuvm.c | 56 +++++++++++++++++++++----- drivers/gpu/drm/nouveau/nouveau_uvmm.c | 20 ++++++--- include/drm/drm_gpuvm.h | 31 +++++++++++++- 3 files changed, 90 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/drm_gpuvm.c

On top of 'vhost: Allow device specific fields per vq', we can move device specific fields to device virt queue from vhost virt queue. Signed-off-by: Asias He <asias at redhat.com> --- drivers/vhost/net.c | 164 +++++++++++++++++++++++++++++++++++++++++++------- drivers/vhost/vhost.c | 57 +----------------- drivers/vhost/vhost.h | 22 ------- 3 files changed, 142