Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates
 216.228.112.34 as permitted sender) receiver=protection.outlook.com;
 client-ip=216.228.112.34; helo=mail.nvidia.com;
Subject: Re: [PATCH v3] kernel/resource: Fix locking in
 request_free_mem_region
To:     Alistair Popple <apopple@nvidia.com>
CC:     <akpm@linux-foundation.org>, <linux-mm@kvack.org>,
        <linux-kernel@vger.kernel.org>, <david@redhat.com>,
        <daniel.vetter@ffwll.ch>, <dan.j.williams@intel.com>,
        <gregkh@linuxfoundation.org>, <jglisse@redhat.com>,
        <bsingharora@gmail.com>, kernel test robot <oliver.sang@intel.com>
References: <20210330003842.18948-1-apopple@nvidia.com>
 <801cd23e-9ac0-adb6-88ba-63ad18d4664c@nvidia.com>
 <7635785.yHxt4vaozm@nvdebian>
From:   John Hubbard <jhubbard@nvidia.com>
Message-ID: <4738a7e1-ec62-0b11-28df-e81c0f904f84@nvidia.com>
Date:   Mon, 29 Mar 2021 22:17:41 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <7635785.yHxt4vaozm@nvdebian>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2021 05:17:42.6589
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c1d18322-b3a8-4c68-bbb1-08d8f33b2551
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[216.228.112.34];Helo=[mail.nvidia.com]
X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT067.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB3936
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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