linux-kernel - Re: [RFC PATCH 1/4] drm/msm: register a fault handler for display mmu faults

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 21 Jun 2024 18:54:19 -0700
From: Abhinav Kumar <quic_abhinavk@...cinc.com>
To: Stephen Boyd <swboyd@...omium.org>, Daniel Vetter <daniel@...ll.ch>,
        "David Airlie" <airlied@...il.com>,
        Dmitry Baryshkov
	<dmitry.baryshkov@...aro.org>,
        Marijn Suijten
	<marijn.suijten@...ainline.org>,
        Rob Clark <robdclark@...il.com>, Sean Paul
	<sean@...rly.run>,
        <freedreno@...ts.freedesktop.org>
CC: <dri-devel@...ts.freedesktop.org>, <seanpaul@...omium.org>,
        <dianders@...omium.org>, <quic_jesszhan@...cinc.com>,
        <linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 1/4] drm/msm: register a fault handler for display mmu
 faults



On 5/20/2024 9:12 PM, Stephen Boyd wrote:
> Quoting Abhinav Kumar (2024-05-17 16:37:56)
>> diff --git a/drivers/gpu/drm/msm/msm_kms.c b/drivers/gpu/drm/msm/msm_kms.c
>> index af6a6fcb1173..62c8e6163e81 100644
>> --- a/drivers/gpu/drm/msm/msm_kms.c
>> +++ b/drivers/gpu/drm/msm/msm_kms.c
>> @@ -200,6 +200,28 @@ struct msm_gem_address_space *msm_kms_init_aspace(struct drm_device *dev)
>>          return aspace;
>>   }
>>
>> +static int msm_kms_fault_handler(void *arg, unsigned long iova, int flags, void *data)
>> +{
>> +       struct msm_kms *kms = arg;
>> +       struct msm_disp_state *state;
>> +       int ret;
>> +
>> +       ret = mutex_lock_interruptible(&kms->dump_mutex);
> 
>  From past experience I've seen the smmu fault handler called in hardirq
> context, so it can't sleep. Is there some way to grab the register
> contents without sleeping? Otherwise this will have to fork off
> somewhere else that can take locks, runtime PM resume, etc.
>

Sorry for the delay in this series.

Yes, this is a valid point.

Let me see move to msm_disp_snapshot_state() as that one will spawn a 
kthread then dump the registers.

>> +       if (ret)
>> +               return ret;
>> +
>> +       state = msm_disp_snapshot_state_sync(kms);
>> +
>> +       mutex_unlock(&kms->dump_mutex);
>> +