We should hold idr_mutex for idr_alloc.
Signed-off-by: Qiujun Huang <[email protected]>
---
drivers/gpu/drm/drm_lease.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index b481caf..427ee21 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -418,6 +418,7 @@ static int fill_object_idr(struct drm_device *dev,
goto out_free_objects;
}
+ mutex_lock(&dev->mode_config.idr_mutex);
/* add their IDs to the lease request - taking into account
universal planes */
for (o = 0; o < object_count; o++) {
@@ -437,7 +438,7 @@ static int fill_object_idr(struct drm_device *dev,
if (ret < 0) {
DRM_DEBUG_LEASE("Object %d cannot be inserted into leases (%d)\n",
object_id, ret);
- goto out_free_objects;
+ goto out_unlock;
}
if (obj->type == DRM_MODE_OBJECT_CRTC && !universal_planes) {
struct drm_crtc *crtc = obj_to_crtc(obj);
@@ -445,20 +446,22 @@ static int fill_object_idr(struct drm_device *dev,
if (ret < 0) {
DRM_DEBUG_LEASE("Object primary plane %d cannot be inserted into leases (%d)\n",
object_id, ret);
- goto out_free_objects;
+ goto out_unlock;
}
if (crtc->cursor) {
ret = idr_alloc(leases, &drm_lease_idr_object, crtc->cursor->base.id, crtc->cursor->base.id + 1, GFP_KERNEL);
if (ret < 0) {
DRM_DEBUG_LEASE("Object cursor plane %d cannot be inserted into leases (%d)\n",
object_id, ret);
- goto out_free_objects;
+ goto out_unlock;
}
}
}
}
ret = 0;
+out_unlock:
+ mutex_unlock(&dev->mode_config.idr_mutex);
out_free_objects:
for (o = 0; o < object_count; o++) {
if (objects[o])
--
1.8.3.1
On Mon, Mar 16, 2020 at 03:18:23PM +0800, Qiujun Huang wrote:
> We should hold idr_mutex for idr_alloc.
>
> Signed-off-by: Qiujun Huang <[email protected]>
I've not seen the first version of this anywhere in my inbox, not sure
where that got lost.
Anyway, this seems like a false positive - I'm assuming this was caught
with KCSAN. The commit message really should mention that.
fill_object_idr creates the idr, which yes is only access later on under
the idr_mutex. But here it's not yet visible to any other thread, and
hence lockless access is safe and correct.
No idea what the KCSAN complains about safe access like this best practice
is.
-Daniel
> ---
> drivers/gpu/drm/drm_lease.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
> index b481caf..427ee21 100644
> --- a/drivers/gpu/drm/drm_lease.c
> +++ b/drivers/gpu/drm/drm_lease.c
> @@ -418,6 +418,7 @@ static int fill_object_idr(struct drm_device *dev,
> goto out_free_objects;
> }
>
> + mutex_lock(&dev->mode_config.idr_mutex);
> /* add their IDs to the lease request - taking into account
> universal planes */
> for (o = 0; o < object_count; o++) {
> @@ -437,7 +438,7 @@ static int fill_object_idr(struct drm_device *dev,
> if (ret < 0) {
> DRM_DEBUG_LEASE("Object %d cannot be inserted into leases (%d)\n",
> object_id, ret);
> - goto out_free_objects;
> + goto out_unlock;
> }
> if (obj->type == DRM_MODE_OBJECT_CRTC && !universal_planes) {
> struct drm_crtc *crtc = obj_to_crtc(obj);
> @@ -445,20 +446,22 @@ static int fill_object_idr(struct drm_device *dev,
> if (ret < 0) {
> DRM_DEBUG_LEASE("Object primary plane %d cannot be inserted into leases (%d)\n",
> object_id, ret);
> - goto out_free_objects;
> + goto out_unlock;
> }
> if (crtc->cursor) {
> ret = idr_alloc(leases, &drm_lease_idr_object, crtc->cursor->base.id, crtc->cursor->base.id + 1, GFP_KERNEL);
> if (ret < 0) {
> DRM_DEBUG_LEASE("Object cursor plane %d cannot be inserted into leases (%d)\n",
> object_id, ret);
> - goto out_free_objects;
> + goto out_unlock;
> }
> }
> }
> }
>
> ret = 0;
> +out_unlock:
> + mutex_unlock(&dev->mode_config.idr_mutex);
> out_free_objects:
> for (o = 0; o < object_count; o++) {
> if (objects[o])
> --
> 1.8.3.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Mar 18, 2020 at 1:02 AM Daniel Vetter <[email protected]> wrote:
>
> On Mon, Mar 16, 2020 at 03:18:23PM +0800, Qiujun Huang wrote:
> > We should hold idr_mutex for idr_alloc.
> >
> > Signed-off-by: Qiujun Huang <[email protected]>
>
> I've not seen the first version of this anywhere in my inbox, not sure
> where that got lost.
>
> Anyway, this seems like a false positive - I'm assuming this was caught
> with KCSAN. The commit message really should mention that.
>
> fill_object_idr creates the idr, which yes is only access later on under
> the idr_mutex. But here it's not yet visible to any other thread, and
> hence lockless access is safe and correct.
Agree that.
Thanks.
>
> No idea what the KCSAN complains about safe access like this best practice
> is.
> -Daniel
>
On Tue, Mar 17, 2020 at 11:33 PM Qiujun Huang <[email protected]> wrote:
>
> On Wed, Mar 18, 2020 at 1:02 AM Daniel Vetter <[email protected]> wrote:
> >
> > On Mon, Mar 16, 2020 at 03:18:23PM +0800, Qiujun Huang wrote:
> > > We should hold idr_mutex for idr_alloc.
> > >
> > > Signed-off-by: Qiujun Huang <[email protected]>
> >
> > I've not seen the first version of this anywhere in my inbox, not sure
> > where that got lost.
> >
> > Anyway, this seems like a false positive - I'm assuming this was caught
> > with KCSAN. The commit message really should mention that.
> >
> > fill_object_idr creates the idr, which yes is only access later on under
> > the idr_mutex. But here it's not yet visible to any other thread, and
> > hence lockless access is safe and correct.
>
> Agree that.
Do you know what the recommended annotation for kcsan false positives
like this should be? Adding kcsan author Marco.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Wed, Mar 18, 2020 at 3:34 PM Daniel Vetter <[email protected]> wrote:
>
> On Tue, Mar 17, 2020 at 11:33 PM Qiujun Huang <[email protected]> wrote:
> >
> > On Wed, Mar 18, 2020 at 1:02 AM Daniel Vetter <[email protected]> wrote:
> > >
> > > On Mon, Mar 16, 2020 at 03:18:23PM +0800, Qiujun Huang wrote:
> > > > We should hold idr_mutex for idr_alloc.
> > > >
> > > > Signed-off-by: Qiujun Huang <[email protected]>
> > >
> > > I've not seen the first version of this anywhere in my inbox, not sure
> > > where that got lost.
> > >
> > > Anyway, this seems like a false positive - I'm assuming this was caught
> > > with KCSAN. The commit message really should mention that.
> > >
> > > fill_object_idr creates the idr, which yes is only access later on under
> > > the idr_mutex. But here it's not yet visible to any other thread, and
> > > hence lockless access is safe and correct.
> >
> > Agree that.
>
> Do you know what the recommended annotation for kcsan false positives
> like this should be? Adding kcsan author Marco.
Actually it's not reported by kcsan. I found idr_alloc isn't safe for
parallel modifications,
and I didn't understand it's a exclusive path here. :)
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Wed, 18 Mar 2020 at 08:34, Daniel Vetter <[email protected]> wrote:
>
> On Tue, Mar 17, 2020 at 11:33 PM Qiujun Huang <[email protected]> wrote:
> >
> > On Wed, Mar 18, 2020 at 1:02 AM Daniel Vetter <[email protected]> wrote:
> > >
> > > On Mon, Mar 16, 2020 at 03:18:23PM +0800, Qiujun Huang wrote:
> > > > We should hold idr_mutex for idr_alloc.
> > > >
> > > > Signed-off-by: Qiujun Huang <[email protected]>
> > >
> > > I've not seen the first version of this anywhere in my inbox, not sure
> > > where that got lost.
> > >
> > > Anyway, this seems like a false positive - I'm assuming this was caught
> > > with KCSAN. The commit message really should mention that.
> > >
> > > fill_object_idr creates the idr, which yes is only access later on under
> > > the idr_mutex. But here it's not yet visible to any other thread, and
> > > hence lockless access is safe and correct.
> >
> > Agree that.
>
> Do you know what the recommended annotation for kcsan false positives
> like this should be? Adding kcsan author Marco.
AFAIK KCSAN has not reported this, so I think there is nothing to do here.
Thanks,
-- Marco