lkml.org 
[lkml]   [2021]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3] kernel/resource: Fix locking in request_free_mem_region
From
Date
On 3/29/21 9:59 PM, Alistair Popple wrote:
...
>>> res->desc = IORES_DESC_DEVICE_PRIVATE_MEMORY;
>>> + if (dev) {
>>> + dr->parent = &iomem_resource;
>>> + dr->start = addr;
>>> + dr->n = size;
>>> + devres_add(dev, dr);
>>> + }
>>> +
>>> + write_unlock(&resource_lock);
>>> + revoke_iomem(res);
>>
>> This is new, and not mentioned in the commit log, and therefore quite
>> surprising. It seems like the right thing to do but it also seems like a
>> different fix! I'm not saying that it should be a separate patch, but it
>> does seem worth loudly mentioning in the commit log, yes?
>
> This isn't a different fix though, it is just about maintaining the original
> behaviour which called revoke_iomem() after dropping the lock. I inadvertently
> switched this around in the initial patch such that revoke_iomem() got called
> with the lock, leading to deadlock on x86 with CONFIG_IO_STRICT_DEVMEM=y.
>
> This does change the order of revoke_iomem() and devres_add() slightly, but as
> far as I can tell that shouldn't be an issue. Can call that out in the commit
> log.

Maybe that's why it looked like a change to me. I do think it's worth mentioning.


thanks,
--
John Hubbard
NVIDIA

\
 
 \ /
  Last update: 2021-03-30 07:19    [W:0.036 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site