| Message ID | 1584343103-13896-1-git-send-email-hqjagain@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RESEND] drm/lease: fix potential race in fill_object_idr | expand |
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 <hqjagain@gmail.com> 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 >
On Wed, Mar 18, 2020 at 1:02 AM Daniel Vetter <daniel@ffwll.ch> 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 <hqjagain@gmail.com> > > 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 <hqjagain@gmail.com> wrote: > > On Wed, Mar 18, 2020 at 1:02 AM Daniel Vetter <daniel@ffwll.ch> 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 <hqjagain@gmail.com> > > > > 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
On Wed, Mar 18, 2020 at 3:34 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > On Tue, Mar 17, 2020 at 11:33 PM Qiujun Huang <hqjagain@gmail.com> wrote: > > > > On Wed, Mar 18, 2020 at 1:02 AM Daniel Vetter <daniel@ffwll.ch> 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 <hqjagain@gmail.com> > > > > > > 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 <daniel@ffwll.ch> wrote: > > On Tue, Mar 17, 2020 at 11:33 PM Qiujun Huang <hqjagain@gmail.com> wrote: > > > > On Wed, Mar 18, 2020 at 1:02 AM Daniel Vetter <daniel@ffwll.ch> 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 <hqjagain@gmail.com> > > > > > > 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
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])
We should hold idr_mutex for idr_alloc. Signed-off-by: Qiujun Huang <hqjagain@gmail.com> --- drivers/gpu/drm/drm_lease.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)