mbox series

[stable,v5.10,0/7] arm64: Default to 32-bit wide ZONE_DMA

Message ID 20210303073319.2215839-1-jingxiangfeng@huawei.com (mailing list archive)
Headers show
Series arm64: Default to 32-bit wide ZONE_DMA | expand

Message

Jing Xiangfeng March 3, 2021, 7:33 a.m. UTC
Using two distinct DMA zones turned out to be problematic. Here's an
attempt go back to a saner default.

Ard Biesheuvel (1):
  arm64: mm: Set ZONE_DMA size based on early IORT scan

Nicolas Saenz Julienne (6):
  arm64: mm: Move reserve_crashkernel() into mem_init()
  arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()
  of/address: Introduce of_dma_get_max_cpu_address()
  of: unittest: Add test for of_dma_get_max_cpu_address()
  arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges
  mm: Remove examples from enum zone_type comment

 arch/arm64/mm/init.c      | 22 +++++++++-------
 drivers/acpi/arm64/iort.c | 55 +++++++++++++++++++++++++++++++++++++++
 drivers/of/address.c      | 42 ++++++++++++++++++++++++++++++
 drivers/of/unittest.c     | 18 +++++++++++++
 include/linux/acpi_iort.h |  4 +++
 include/linux/mmzone.h    | 20 --------------
 include/linux/of.h        |  7 +++++
 7 files changed, 139 insertions(+), 29 deletions(-)

Comments

Greg Kroah-Hartman March 4, 2021, 1:46 p.m. UTC | #1
On Wed, Mar 03, 2021 at 03:33:12PM +0800, Jing Xiangfeng wrote:
> Using two distinct DMA zones turned out to be problematic. Here's an
> attempt go back to a saner default.

What problem does this solve?  How does this fit into the stable kernel
rules?

thanks,

greg k-h
Nicolas Saenz Julienne March 4, 2021, 2:05 p.m. UTC | #2
Hi Greg.

On Thu, 2021-03-04 at 14:46 +0100, Greg KH wrote:
> On Wed, Mar 03, 2021 at 03:33:12PM +0800, Jing Xiangfeng wrote:
> > Using two distinct DMA zones turned out to be problematic. Here's an
> > attempt go back to a saner default.
> 
> What problem does this solve?  How does this fit into the stable kernel
> rules?

We changed the way we setup memory zones in arm64 in order to cater for
Raspberry Pi 4's weird DMA constraints: ZONE_DMA spans the lower 1GB of memory
and ZONE_DMA32 the rest of the 32bit address space. Since you can't allocate
memory that crosses zone boundaries, this broke crashkernel allocations on big
machines. This series fixes all this by parsing the HW description and checking
for DMA constrained buses. When not found, the unnecessary zone creation is
skipped.

That said, I have no clue whether this falls or not into the stable kernel
rules.

Regards,
Nicolas
Greg Kroah-Hartman March 4, 2021, 2:17 p.m. UTC | #3
On Thu, Mar 04, 2021 at 03:05:32PM +0100, Nicolas Saenz Julienne wrote:
> Hi Greg.
> 
> On Thu, 2021-03-04 at 14:46 +0100, Greg KH wrote:
> > On Wed, Mar 03, 2021 at 03:33:12PM +0800, Jing Xiangfeng wrote:
> > > Using two distinct DMA zones turned out to be problematic. Here's an
> > > attempt go back to a saner default.
> > 
> > What problem does this solve?  How does this fit into the stable kernel
> > rules?
> 
> We changed the way we setup memory zones in arm64 in order to cater for
> Raspberry Pi 4's weird DMA constraints: ZONE_DMA spans the lower 1GB of memory
> and ZONE_DMA32 the rest of the 32bit address space. Since you can't allocate
> memory that crosses zone boundaries, this broke crashkernel allocations on big
> machines. This series fixes all this by parsing the HW description and checking
> for DMA constrained buses. When not found, the unnecessary zone creation is
> skipped.

What kernel/commit caused this "breakage"?

thanks,

greg k-h
Nicolas Saenz Julienne March 4, 2021, 3:09 p.m. UTC | #4
On Thu, 2021-03-04 at 15:17 +0100, Greg KH wrote:
> On Thu, Mar 04, 2021 at 03:05:32PM +0100, Nicolas Saenz Julienne wrote:
> > Hi Greg.
> > 
> > On Thu, 2021-03-04 at 14:46 +0100, Greg KH wrote:
> > > On Wed, Mar 03, 2021 at 03:33:12PM +0800, Jing Xiangfeng wrote:
> > > > Using two distinct DMA zones turned out to be problematic. Here's an
> > > > attempt go back to a saner default.
> > > 
> > > What problem does this solve?  How does this fit into the stable kernel
> > > rules?
> > 
> > We changed the way we setup memory zones in arm64 in order to cater for
> > Raspberry Pi 4's weird DMA constraints: ZONE_DMA spans the lower 1GB of memory
> > and ZONE_DMA32 the rest of the 32bit address space. Since you can't allocate
> > memory that crosses zone boundaries, this broke crashkernel allocations on big
> > machines. This series fixes all this by parsing the HW description and checking
> > for DMA constrained buses. When not found, the unnecessary zone creation is
> > skipped.
> 
> What kernel/commit caused this "breakage"?

1a8e1cef7603 arm64: use both ZONE_DMA and ZONE_DMA32

Regards,
Nicolas
Greg Kroah-Hartman March 7, 2021, 3:24 p.m. UTC | #5
On Thu, Mar 04, 2021 at 04:09:28PM +0100, Nicolas Saenz Julienne wrote:
> On Thu, 2021-03-04 at 15:17 +0100, Greg KH wrote:
> > On Thu, Mar 04, 2021 at 03:05:32PM +0100, Nicolas Saenz Julienne wrote:
> > > Hi Greg.
> > > 
> > > On Thu, 2021-03-04 at 14:46 +0100, Greg KH wrote:
> > > > On Wed, Mar 03, 2021 at 03:33:12PM +0800, Jing Xiangfeng wrote:
> > > > > Using two distinct DMA zones turned out to be problematic. Here's an
> > > > > attempt go back to a saner default.
> > > > 
> > > > What problem does this solve?  How does this fit into the stable kernel
> > > > rules?
> > > 
> > > We changed the way we setup memory zones in arm64 in order to cater for
> > > Raspberry Pi 4's weird DMA constraints: ZONE_DMA spans the lower 1GB of memory
> > > and ZONE_DMA32 the rest of the 32bit address space. Since you can't allocate
> > > memory that crosses zone boundaries, this broke crashkernel allocations on big
> > > machines. This series fixes all this by parsing the HW description and checking
> > > for DMA constrained buses. When not found, the unnecessary zone creation is
> > > skipped.
> > 
> > What kernel/commit caused this "breakage"?
> 
> 1a8e1cef7603 arm64: use both ZONE_DMA and ZONE_DMA32

Thanks for the info, all now queued up.

greg k-h
Jing Xiangfeng March 8, 2021, 3:20 a.m. UTC | #6
On 2021/3/7 23:24, Greg KH wrote:
> On Thu, Mar 04, 2021 at 04:09:28PM +0100, Nicolas Saenz Julienne wrote:
>> On Thu, 2021-03-04 at 15:17 +0100, Greg KH wrote:
>>> On Thu, Mar 04, 2021 at 03:05:32PM +0100, Nicolas Saenz Julienne wrote:
>>>> Hi Greg.
>>>>
>>>> On Thu, 2021-03-04 at 14:46 +0100, Greg KH wrote:
>>>>> On Wed, Mar 03, 2021 at 03:33:12PM +0800, Jing Xiangfeng wrote:
>>>>>> Using two distinct DMA zones turned out to be problematic. Here's an
>>>>>> attempt go back to a saner default.
>>>>> What problem does this solve?  How does this fit into the stable kernel
>>>>> rules?
>>>> We changed the way we setup memory zones in arm64 in order to cater for
>>>> Raspberry Pi 4's weird DMA constraints: ZONE_DMA spans the lower 1GB of memory
>>>> and ZONE_DMA32 the rest of the 32bit address space. Since you can't allocate
>>>> memory that crosses zone boundaries, this broke crashkernel allocations on big
>>>> machines. This series fixes all this by parsing the HW description and checking
>>>> for DMA constrained buses. When not found, the unnecessary zone creation is
>>>> skipped.
>>> What kernel/commit caused this "breakage"?
>> 1a8e1cef7603 arm64: use both ZONE_DMA and ZONE_DMA32
> Thanks for the info, all now queued up.
There is a fix in 5.11. Please consider applying the following commit to 
5.10.y:

aed5041ef9a3 of: unittest: Fix build on architectures without 
CONFIG_OF_ADDRES

Thanks

>
> greg k-h
> .
>
Greg Kroah-Hartman March 8, 2021, 9:58 a.m. UTC | #7
On Mon, Mar 08, 2021 at 11:20:03AM +0800, Jing Xiangfeng wrote:
> 
> 
> On 2021/3/7 23:24, Greg KH wrote:
> > On Thu, Mar 04, 2021 at 04:09:28PM +0100, Nicolas Saenz Julienne wrote:
> > > On Thu, 2021-03-04 at 15:17 +0100, Greg KH wrote:
> > > > On Thu, Mar 04, 2021 at 03:05:32PM +0100, Nicolas Saenz Julienne wrote:
> > > > > Hi Greg.
> > > > > 
> > > > > On Thu, 2021-03-04 at 14:46 +0100, Greg KH wrote:
> > > > > > On Wed, Mar 03, 2021 at 03:33:12PM +0800, Jing Xiangfeng wrote:
> > > > > > > Using two distinct DMA zones turned out to be problematic. Here's an
> > > > > > > attempt go back to a saner default.
> > > > > > What problem does this solve?  How does this fit into the stable kernel
> > > > > > rules?
> > > > > We changed the way we setup memory zones in arm64 in order to cater for
> > > > > Raspberry Pi 4's weird DMA constraints: ZONE_DMA spans the lower 1GB of memory
> > > > > and ZONE_DMA32 the rest of the 32bit address space. Since you can't allocate
> > > > > memory that crosses zone boundaries, this broke crashkernel allocations on big
> > > > > machines. This series fixes all this by parsing the HW description and checking
> > > > > for DMA constrained buses. When not found, the unnecessary zone creation is
> > > > > skipped.
> > > > What kernel/commit caused this "breakage"?
> > > 1a8e1cef7603 arm64: use both ZONE_DMA and ZONE_DMA32
> > Thanks for the info, all now queued up.
> There is a fix in 5.11. Please consider applying the following commit to
> 5.10.y:
> 
> aed5041ef9a3 of: unittest: Fix build on architectures without
> CONFIG_OF_ADDRES

Thanks, now queued up.

greg k-h
Kefeng Wang May 11, 2021, 12:35 p.m. UTC | #8
On 2021/3/8 17:58, Greg KH wrote:
> On Mon, Mar 08, 2021 at 11:20:03AM +0800, Jing Xiangfeng wrote:
>>
>>
>> On 2021/3/7 23:24, Greg KH wrote:
>>> On Thu, Mar 04, 2021 at 04:09:28PM +0100, Nicolas Saenz Julienne wrote:
>>>> On Thu, 2021-03-04 at 15:17 +0100, Greg KH wrote:
>>>>> On Thu, Mar 04, 2021 at 03:05:32PM +0100, Nicolas Saenz Julienne wrote:
>>>>>> Hi Greg.
>>>>>>
>>>>>> On Thu, 2021-03-04 at 14:46 +0100, Greg KH wrote:
>>>>>>> On Wed, Mar 03, 2021 at 03:33:12PM +0800, Jing Xiangfeng wrote:
>>>>>>>> Using two distinct DMA zones turned out to be problematic. Here's an
>>>>>>>> attempt go back to a saner default.
>>>>>>> What problem does this solve?  How does this fit into the stable kernel
>>>>>>> rules?
>>>>>> We changed the way we setup memory zones in arm64 in order to cater for
>>>>>> Raspberry Pi 4's weird DMA constraints: ZONE_DMA spans the lower 1GB of memory
>>>>>> and ZONE_DMA32 the rest of the 32bit address space. Since you can't allocate
>>>>>> memory that crosses zone boundaries, this broke crashkernel allocations on big
>>>>>> machines. This series fixes all this by parsing the HW description and checking
>>>>>> for DMA constrained buses. When not found, the unnecessary zone creation is
>>>>>> skipped.
>>>>> What kernel/commit caused this "breakage"?
>>>> 1a8e1cef7603 arm64: use both ZONE_DMA and ZONE_DMA32
>>> Thanks for the info, all now queued up.
>> There is a fix in 5.11. Please consider applying the following commit to
>> 5.10.y:
>>
>> aed5041ef9a3 of: unittest: Fix build on architectures without
>> CONFIG_OF_ADDRES
> 
> Thanks, now queued up.

Hi Grep, another commit d78050ee3544 "arm64: Remove 
arm64_dma32_phys_limit and its uses" should be involved, thanks.

"Prior to this patch, disabling CONFIG_ZONE_DMA32 leads to CMA
allocation from the whole RAM as arm64_dma32_phys_limit becomes
PHYS_MASK+1." from Catalin, see more from the link
https://www.spinics.net/lists/arm-kernel/msg867356.html
> 
> greg k-h
> .
>
Greg Kroah-Hartman May 12, 2021, 12:06 p.m. UTC | #9
On Tue, May 11, 2021 at 08:35:47PM +0800, Kefeng Wang wrote:
> 
> 
> On 2021/3/8 17:58, Greg KH wrote:
> > On Mon, Mar 08, 2021 at 11:20:03AM +0800, Jing Xiangfeng wrote:
> > > 
> > > 
> > > On 2021/3/7 23:24, Greg KH wrote:
> > > > On Thu, Mar 04, 2021 at 04:09:28PM +0100, Nicolas Saenz Julienne wrote:
> > > > > On Thu, 2021-03-04 at 15:17 +0100, Greg KH wrote:
> > > > > > On Thu, Mar 04, 2021 at 03:05:32PM +0100, Nicolas Saenz Julienne wrote:
> > > > > > > Hi Greg.
> > > > > > > 
> > > > > > > On Thu, 2021-03-04 at 14:46 +0100, Greg KH wrote:
> > > > > > > > On Wed, Mar 03, 2021 at 03:33:12PM +0800, Jing Xiangfeng wrote:
> > > > > > > > > Using two distinct DMA zones turned out to be problematic. Here's an
> > > > > > > > > attempt go back to a saner default.
> > > > > > > > What problem does this solve?  How does this fit into the stable kernel
> > > > > > > > rules?
> > > > > > > We changed the way we setup memory zones in arm64 in order to cater for
> > > > > > > Raspberry Pi 4's weird DMA constraints: ZONE_DMA spans the lower 1GB of memory
> > > > > > > and ZONE_DMA32 the rest of the 32bit address space. Since you can't allocate
> > > > > > > memory that crosses zone boundaries, this broke crashkernel allocations on big
> > > > > > > machines. This series fixes all this by parsing the HW description and checking
> > > > > > > for DMA constrained buses. When not found, the unnecessary zone creation is
> > > > > > > skipped.
> > > > > > What kernel/commit caused this "breakage"?
> > > > > 1a8e1cef7603 arm64: use both ZONE_DMA and ZONE_DMA32
> > > > Thanks for the info, all now queued up.
> > > There is a fix in 5.11. Please consider applying the following commit to
> > > 5.10.y:
> > > 
> > > aed5041ef9a3 of: unittest: Fix build on architectures without
> > > CONFIG_OF_ADDRES
> > 
> > Thanks, now queued up.
> 
> Hi Grep, another commit d78050ee3544 "arm64: Remove arm64_dma32_phys_limit
> and its uses" should be involved, thanks.
> 
> "Prior to this patch, disabling CONFIG_ZONE_DMA32 leads to CMA
> allocation from the whole RAM as arm64_dma32_phys_limit becomes
> PHYS_MASK+1." from Catalin, see more from the link
> https://www.spinics.net/lists/arm-kernel/msg867356.html

Ok, now queued up.

greg k-h