linux-kernel - Re: [PATCH v2] gpu/drm: Remove debug info about CPU address

Open Source and information security mailing list archives

Message-ID: <CADnq5_M4Dk=+MDc7VdeQ1SN6QpPhkRMX9z84Qo4Q_DMw3xS7+A@mail.gmail.com>
Date:   Mon, 6 Jul 2020 12:16:40 -0400
From:   Alex Deucher <alexdeucher@...il.com>
To:     Tiezhu Yang <yangtiezhu@...ngson.cn>
Cc:     Christian König <christian.koenig@....com>,
        "Deucher, Alexander" <alexander.deucher@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        amd-gfx list <amd-gfx@...ts.freedesktop.org>
Subject: Re: [PATCH v2] gpu/drm: Remove debug info about CPU address

Applied.  Thanks!

Alex

On Thu, Jul 2, 2020 at 11:54 AM Tiezhu Yang <yangtiezhu@...ngson.cn> wrote:
>
> On 07/02/2020 04:39 PM, Christian König wrote:
> > Am 02.07.20 um 10:35 schrieb Tiezhu Yang:
> >> On 07/02/2020 04:27 PM, Christian König wrote:
> >>> Am 02.07.20 um 04:27 schrieb Tiezhu Yang:
> >>>> When I update the latest kernel, I see the following
> >>>> "____ptrval____" boot
> >>>> messages.
> >>>>
> >>>> [    1.872600] radeon 0000:01:05.0: fence driver on ring 0 use gpu
> >>>> addr 0x0000000048000c00 and cpu addr 0x(____ptrval____)
> >>>> [    1.879095] radeon 0000:01:05.0: fence driver on ring 5 use gpu
> >>>> addr 0x0000000040056038 and cpu addr 0x(____ptrval____)
> >>>>
> >>>> Both radeon_fence_driver_start_ring() and
> >>>> amdgpu_fence_driver_start_ring()
> >>>> have the similar issue, there exists the following two methods to
> >>>> solve it:
> >>>> (1) Use "%pK" instead of "%p" so that the CPU address can be
> >>>> printed when
> >>>> the kptr_restrict sysctl is set to 1.
> >>>> (2) Just completely drop the CPU address suggested by Christian,
> >>>> because
> >>>> the CPU address was useful in the past, but isn't any more. We now
> >>>> have a
> >>>> debugfs file to read the current fence values.
> >>>>
> >>>> Since the CPU address is not much useful, just remove the debug
> >>>> info about
> >>>> CPU address.
> >>>>
> >>>> Signed-off-by: Tiezhu Yang <yangtiezhu@...ngson.cn>
> >>>
> >>> Splitting it into one patch for radeon and one for amdgpu might be
> >>> nice to have.
> >>
> >> Should I split this patch into two patches and then send v3?
> >> If yes, I will do it soon.
> >
> > For me it's ok to merge it like it is now.
> >
> > Only Alex could insists to split the patches, but then he will
> > probably do it himself.
>
> OK, then I will not send v3.
>
> >
> > Thanks for the help,
> > Christian.
> >
> >>
> >>>
> >>> But either way Reviewed-by: Christian König
> >>> <christian.koenig@....com> for the patch.
> >>>
> >>> Thanks,
> >>> Christian.
> >>>
> >>>> ---
> >>>>
> >>>> v2:
> >>>>    - Just remove the debug info about CPU address suggested by
> >>>> Christian
> >>>>    - Modify the patch subject and update the commit message
> >>>>
> >>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 5 ++---
> >>>>   drivers/gpu/drm/radeon/radeon_fence.c     | 4 ++--
> >>>>   2 files changed, 4 insertions(+), 5 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> >>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> >>>> index d878fe7..a29f2f9 100644
> >>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> >>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> >>>> @@ -422,9 +422,8 @@ int amdgpu_fence_driver_start_ring(struct
> >>>> amdgpu_ring *ring,
> >>>>       ring->fence_drv.irq_type = irq_type;
> >>>>       ring->fence_drv.initialized = true;
> >>>>   -    DRM_DEV_DEBUG(adev->dev, "fence driver on ring %s use gpu
> >>>> addr "
> >>>> -              "0x%016llx, cpu addr 0x%p\n", ring->name,
> >>>> -              ring->fence_drv.gpu_addr, ring->fence_drv.cpu_addr);
> >>>> +    DRM_DEV_DEBUG(adev->dev, "fence driver on ring %s use gpu addr
> >>>> 0x%016llx\n",
> >>>> +              ring->name, ring->fence_drv.gpu_addr);
> >>>>       return 0;
> >>>>   }
> >>>>   diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
> >>>> b/drivers/gpu/drm/radeon/radeon_fence.c
> >>>> index 43f2f93..8735bf2 100644
> >>>> --- a/drivers/gpu/drm/radeon/radeon_fence.c
> >>>> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> >>>> @@ -865,8 +865,8 @@ int radeon_fence_driver_start_ring(struct
> >>>> radeon_device *rdev, int ring)
> >>>>       }
> >>>>       radeon_fence_write(rdev,
> >>>> atomic64_read(&rdev->fence_drv[ring].last_seq), ring);
> >>>>       rdev->fence_drv[ring].initialized = true;
> >>>> -    dev_info(rdev->dev, "fence driver on ring %d use gpu addr
> >>>> 0x%016llx and cpu addr 0x%p\n",
> >>>> -         ring, rdev->fence_drv[ring].gpu_addr,
> >>>> rdev->fence_drv[ring].cpu_addr);
> >>>> +    dev_info(rdev->dev, "fence driver on ring %d use gpu addr
> >>>> 0x%016llx\n",
> >>>> +         ring, rdev->fence_drv[ring].gpu_addr);
> >>>>       return 0;
> >>>>   }
> >>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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