[PATCH v2 2/3] drm/etnaviv: allocate unique ID per drm_file

[Tvrtko Ursulin]

On 16/11/2022 13:18, Philipp Zabel wrote:
> On Fri, Sep 16, 2022 at 05:12:04PM +0200, Lucas Stach wrote:
>> Allows to easily track if several fd are pointing to the same
>> execution context due to being dup'ed.
>>
>> Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
>> ---
>>   drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 +++
>>   drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 +
>>   2 files changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> index 1d2b4fb4bcf8..b69edb40ae2a 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> @@ -49,6 +49,7 @@ static void load_gpu(struct drm_device *dev)
>>   static int etnaviv_open(struct drm_device *dev, struct drm_file *file)
>>   {
>>   	struct etnaviv_drm_private *priv = dev->dev_private;
>> +	static atomic_t ident = ATOMIC_INIT(0);
>>   	struct etnaviv_file_private *ctx;
>>   	int ret, i;
>>   
>> @@ -56,6 +57,8 @@ static int etnaviv_open(struct drm_device *dev, struct drm_file *file)
>>   	if (!ctx)
>>   		return -ENOMEM;
>>   
>> +	ctx->id = atomic_inc_return(&ident);
> 
> I suppose we can ignore that this could theoretically wrap around.

Depends on your usecases - if you can envisage a long running client, 
say the compositor, while other clients come and go then eventually 
these will not be unique and will break the fdinfo spec. Hence I used a 
cyclic xarray in i915 (aka idr). I would recommend you just do that and 
remove future debug sessions around the area of "why does gputop show 
nonsense all of a sudden".

Regards,

Tvrtko

> 
> Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
> 
> regards
> Philipp