On Thu, 14 Sep 2023 16:01:37 +0300
Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx> wrote:
> On 9/14/23 14:58, Boris Brezillon wrote:
> > On Thu, 14 Sep 2023 14:36:23 +0300
> > Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx> wrote:
> >
> >> On 9/14/23 11:27, Boris Brezillon wrote:
> >>> On Thu, 14 Sep 2023 10:50:32 +0300
> >>> Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx> wrote:
> >>>
> >>>> On 9/14/23 10:36, Boris Brezillon wrote:
> >>>>> On Thu, 14 Sep 2023 07:02:52 +0300
> >>>>> Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx> wrote:
> >>>>>
> >>>>>> On 9/13/23 10:48, Boris Brezillon wrote:
> >>>>>>> On Wed, 13 Sep 2023 03:56:14 +0300
> >>>>>>> Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx> wrote:
> >>>>>>>
> >>>>>>>> On 9/5/23 11:03, Boris Brezillon wrote:
> >>>>>>>>>> * But
> >>>>>>>>>> + * acquiring the obj lock in drm_gem_shmem_release_pages_locked() can
> >>>>>>>>>> + * cause a locking order inversion between reservation_ww_class_mutex
> >>>>>>>>>> + * and fs_reclaim.
> >>>>>>>>>> + *
> >>>>>>>>>> + * This deadlock is not actually possible, because no one should
> >>>>>>>>>> + * be already holding the lock when drm_gem_shmem_free() is called.
> >>>>>>>>>> + * Unfortunately lockdep is not aware of this detail. So when the
> >>>>>>>>>> + * refcount drops to zero, don't touch the reservation lock.
> >>>>>>>>>> + */
> >>>>>>>>>> + if (shmem->got_pages_sgt &&
> >>>>>>>>>> + refcount_dec_and_test(&shmem->pages_use_count)) {
> >>>>>>>>>> + drm_gem_shmem_do_release_pages_locked(shmem);
> >>>>>>>>>> + shmem->got_pages_sgt = false;
> >>>>>>>>>> }
> >>>>>>>>> Leaking memory is the right thing to do if pages_use_count > 1 (it's
> >>>>>>>>> better to leak than having someone access memory it no longer owns), but
> >>>>>>>>> I think it's worth mentioning in the above comment.
> >>>>>>>>
> >>>>>>>> It's unlikely that it will be only a leak without a following up
> >>>>>>>> use-after-free. Neither is acceptable.
> >>>>>>>
> >>>>>>> Not necessarily, if you have a page leak, it could be that the GPU has
> >>>>>>> access to those pages, but doesn't need the GEM object anymore
> >>>>>>> (pages are mapped by the iommu, which doesn't need shmem->sgt or
> >>>>>>> shmem->pages after the mapping is created). Without a WARN_ON(), this
> >>>>>>> can go unnoticed and lead to memory corruptions/information leaks.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> The drm_gem_shmem_free() could be changed such that kernel won't blow up
> >>>>>>>> on a refcnt bug, but that's not worthwhile doing because drivers
> >>>>>>>> shouldn't have silly bugs.
> >>>>>>>
> >>>>>>> We definitely don't want to fix that, but we want to complain loudly
> >>>>>>> (WARN_ON()), and make sure the risk is limited (preventing memory from
> >>>>>>> being re-assigned to someone else by not freeing it).
> >>>>>>
> >>>>>> That's what the code did and continues to do here. Not exactly sure what
> >>>>>> you're trying to say. I'm going to relocate the comment in v17 to
> >>>>>> put_pages(), we can continue discussing it there if I'm missing yours point.
> >>>>>>
> >>>>>
> >>>>> I'm just saying it would be worth mentioning that we're intentionally
> >>>>> leaking memory if shmem->pages_use_count > 1. Something like:
> >>>>>
> >>>>> /**
> >>>>> * shmem->pages_use_count should be 1 when ->sgt != NULL and
> >>>>> * zero otherwise. If some users still hold a pages reference
> >>>>> * that's a bug, and we intentionally leak the pages so they
> >>>>> * can't be re-allocated to someone else while the GPU/CPU
> >>>>> * still have access to it.
> >>>>> */
> >>>>> drm_WARN_ON(drm,
> >>>>> refcount_read(&shmem->pages_use_count) == (shmem->sgt ? 1 : 0));
> >>>>> if (shmem->sgt && refcount_dec_and_test(&shmem->pages_use_count))
> >>>>> drm_gem_shmem_free_pages(shmem);
> >>>>
> >>>> That may be acceptable, but only once there will a driver using this
> >>>> feature.
> >>>
> >>> Which feature? That's not related to a specific feature, that's just
> >>> how drm_gem_shmem_get_pages_sgt() works, it takes a pages ref that can
> >>> only be released in drm_gem_shmem_free(), because sgt users are not
> >>> refcounted and the sgt stays around until the GEM object is freed or
> >>> its pages are evicted. The only valid cases we have at the moment are:
> >>>
> >>> - pages_use_count == 1 && sgt != NULL
> >>> - pages_use_count == 0
> >>>
> >>> any other situations are buggy.
> >>
> >> sgt may belong to dma-buf for which pages_use_count=0, this can't be
> >> done until sgt mess is sorted out
> >
> > No it can't, not in that path, because the code you're adding is in the
> > if (!obj->import_branch) branch:
> >
> >
> > if (obj->import_attach) {
> > drm_prime_gem_destroy(obj, shmem->sgt);
> > } else {
> > ...
> > // Your changes are here.
> > ...
>
> This branch is taken for the dma-buf in the prime import error code path.
I suggested a fix for this error that didn't involve adding a new flag,
but that's orthogonal to the piece of code we're discussing anyway.
> But yes, the pages_use_count=0 for the dma-buf and then it can be
> written as:
>
> if (obj->import_attach) {
> drm_prime_gem_destroy(obj, shmem->sgt);
> } else {
> drm_WARN_ON(obj->dev, refcount_read(&shmem->vmap_use_count));
>
> if (shmem->sgt && refcount_read(&shmem->pages_use_count)) {
You should drop the '&& refcount_read(&shmem->pages_use_count)',
otherwise you'll never enter this branch (sgt allocation retained
a ref, so pages_use_count > 0 when ->sgt != NULL).
If you added this pages_use_count > 0 check to deal with the
'free-partially-imported-GEM' case, I keep thinking this is not
the right fix. You should just assume that obj->import_attach == NULL
means not-a-prime-buffer, and then make sure
partially-initialized-prime-GEMs have import_attach assigned (see the
oneliner I suggested in my review of
`[PATCH v15 01/23] drm/shmem-helper: Fix UAF in error path when
freeing SGT of imported GEM`).
> dma_unmap_sgtable(obj->dev->dev, shmem->sgt,
> DMA_BIDIRECTIONAL, 0);
> sg_free_table(shmem->sgt);
> kfree(shmem->sgt);
>
> __drm_gem_shmem_put_pages(shmem);
You need to decrement pages_use_count:
/* shmem->pages_use_count should be 1 when ->sgt != NULL and
* zero otherwise. If some users still hold a pages reference
* that's a bug, and we intentionally leak the pages so they
* can't be re-allocated to someone else while the GPU/CPU
* still have access to it.
*/
if (refcount_dec_and_test(&shmem->pages_use_count))
__drm_gem_shmem_put_pages(shmem);
> }
>
> drm_WARN_ON(obj->dev, refcount_read(&shmem->pages_use_count));
And now this WARN_ON() ^ should catch unexpected pages leak.
>
> Alright, I'll check if it works as expected for fixing the error code path bug for v17
>
