[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2600dde0-be65-f1f8-1563-4f3753a395aa@amd.com>
Date: Tue, 31 May 2022 14:19:45 -0500
From: "Sierra Guiza, Alejandro (Alex)" <alex.sierra@....com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: jgg@...dia.com, david@...hat.com, Felix.Kuehling@....com,
linux-mm@...ck.org, rcampbell@...dia.com,
linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org,
amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
hch@....de, jglisse@...hat.com, apopple@...dia.com,
willy@...radead.org
Subject: Re: [PATCH v4 07/13] lib: test_hmm add ioctl to get zone device type
On 5/31/2022 12:31 PM, Andrew Morton wrote:
> On Tue, 31 May 2022 10:56:23 -0500 Alex Sierra <alex.sierra@....com> wrote:
>
>> new ioctl cmd added to query zone device type. This will be
>> used once the test_hmm adds zone device coherent type.
>>
>> @@ -1026,6 +1027,15 @@ static int dmirror_snapshot(struct dmirror *dmirror,
>> return ret;
>> }
>>
>> +static int dmirror_get_device_type(struct dmirror *dmirror,
>> + struct hmm_dmirror_cmd *cmd)
>> +{
>> + mutex_lock(&dmirror->mutex);
>> + cmd->zone_device_type = dmirror->mdevice->zone_device_type;
>> + mutex_unlock(&dmirror->mutex);
> What does the locking here do?
>
> Presumably cmd->zone_device_type can become out of date the instant the
> mutex is released, so what was the point in taking the mutex?
Actually this is not used at all. Thanks for finding it. Honestly, I
don't remember what we used this type request for.
I will remove all related codeĀ and send a new patch series version.
Regards,
Alex Sierra
>
> And does it make sense to return potentially out-of-date info to
> userspace? Perhaps this interface simply shouldn't exist?
Powered by blists - more mailing lists