linux-kernel - Re: [PATCH 1/3] resource: Fix locking in find_next_iomem

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] [day] [month] [year] [list]

Message-ID: <239D9ACE-E365-41B2-B9EF-4CF3A7316D07@vmware.com>
Date:   Tue, 18 Jun 2019 01:32:50 +0000
From:   Nadav Amit <namit@...are.com>
To:     Sasha Levin <sashal@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>
CC:     Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Borislav Petkov <bp@...e.de>, Toshi Kani <toshi.kani@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 1/3] resource: Fix locking in find_next_iomem_res()

> On Jun 17, 2019, at 5:55 PM, Sasha Levin <sashal@...nel.org> wrote:
> 
> On Mon, Jun 17, 2019 at 07:14:53PM +0000, Nadav Amit wrote:
>>> On Jun 15, 2019, at 3:15 PM, Sasha Levin <sashal@...nel.org> wrote:
>>> 
>>> Hi,
>>> 
>>> [This is an automated email]
>>> 
>>> This commit has been processed because it contains a "Fixes:" tag,
>>> fixing commit: ff3cc952d3f0 resource: Add remove_resource interface.
>>> 
>>> The bot has tested the following trees: v5.1.9, v4.19.50, v4.14.125, v4.9.181.
>>> 
>>> v5.1.9: Build OK!
>>> v4.19.50: Failed to apply! Possible dependencies:
>>>   010a93bf97c7 ("resource: Fix find_next_iomem_res() iteration issue")
>>>   a98959fdbda1 ("resource: Include resource end in walk_*() interfaces")
>>> 
>>> v4.14.125: Failed to apply! Possible dependencies:
>>>   010a93bf97c7 ("resource: Fix find_next_iomem_res() iteration issue")
>>>   0e4c12b45aa8 ("x86/mm, resource: Use PAGE_KERNEL protection for ioremap of memory pages")
>>>   1d2e733b13b4 ("resource: Provide resource struct in resource walk callback")
>>>   4ac2aed837cb ("resource: Consolidate resource walking code")
>>>   a98959fdbda1 ("resource: Include resource end in walk_*() interfaces")
>>> 
>>> v4.9.181: Failed to apply! Possible dependencies:
>>>   010a93bf97c7 ("resource: Fix find_next_iomem_res() iteration issue")
>>>   0e4c12b45aa8 ("x86/mm, resource: Use PAGE_KERNEL protection for ioremap of memory pages")
>>>   1d2e733b13b4 ("resource: Provide resource struct in resource walk callback")
>>>   4ac2aed837cb ("resource: Consolidate resource walking code")
>>>   60fe3910bb02 ("kexec_file: Allow arch-specific memory walking for kexec_add_buffer")
>>>   a0458284f062 ("powerpc: Add support code for kexec_file_load()")
>>>   a98959fdbda1 ("resource: Include resource end in walk_*() interfaces")
>>>   da6658859b9c ("powerpc: Change places using CONFIG_KEXEC to use CONFIG_KEXEC_CORE instead.")
>>>   ec2b9bfaac44 ("kexec_file: Change kexec_add_buffer to take kexec_buf as argument.")
>> 
>> Is there a reason 010a93bf97c7 ("resource: Fix find_next_iomem_res()
>> iteration issue”) was not backported?
> 
> Mostly because it's not tagged for stable :)

Good point. Unfortunately, 010a93bf97c7 does not apply cleanly either.

Bjorn, do you think your patch should be backported?

If not, I can create a version of the patch that I sent for 4.14/4.9.