2019-05-27 08:55:01 +02:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-06 15:39:13 -07:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2010-07-06 15:39:07 -07:00
|
|
|
|
2010-07-06 15:39:16 -07:00
|
|
|
|
2010-07-06 15:39:19 -07:00
|
|
|
|
2018-04-05 16:25:34 -07:00
|
|
|
|
2010-07-06 15:39:19 -07:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2016-07-28 15:48:06 -07:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-12 15:07:59 -08:00
|
|
|
|
arm64, mm, efi: Account for GICv3 LPI tables in static memblock reserve table
In the irqchip and EFI code, we have what basically amounts to a quirk
to work around a peculiarity in the GICv3 architecture, which permits
the system memory address of LPI tables to be programmable only once
after a CPU reset. This means kexec kernels must use the same memory
as the first kernel, and thus ensure that this memory has not been
given out for other purposes by the time the ITS init code runs, which
is not very early for secondary CPUs.
On systems with many CPUs, these reservations could overflow the
memblock reservation table, and this was addressed in commit:
eff896288872 ("efi/arm: Defer persistent reservations until after paging_init()")
However, this turns out to have made things worse, since the allocation
of page tables and heap space for the resized memblock reservation table
itself may overwrite the regions we are attempting to reserve, which may
cause all kinds of corruption, also considering that the ITS will still
be poking bits into that memory in response to incoming MSIs.
So instead, let's grow the static memblock reservation table on such
systems so it can accommodate these reservations at an earlier time.
This will permit us to revert the above commit in a subsequent patch.
[ mingo: Minor cleanups. ]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20190215123333.21209-2-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-02-15 13:33:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
memblock,arm64: expand the static memblock memory table
In a system(Huawei Ascend ARM64 SoC) using HBM, a multi-bit ECC error
occurs, and the BIOS will mark the corresponding area (for example, 2 MB)
as unusable. When the system restarts next time, these areas are not
reported or reported as EFI_UNUSABLE_MEMORY. Both cases lead to an
increase in the number of memblocks, whereas EFI_UNUSABLE_MEMORY leads to
a larger number of memblocks.
For example, if the EFI_UNUSABLE_MEMORY type is reported:
...
memory[0x92] [0x0000200834a00000-0x0000200835bfffff], 0x0000000001200000 bytes on node 7 flags: 0x0
memory[0x93] [0x0000200835c00000-0x0000200835dfffff], 0x0000000000200000 bytes on node 7 flags: 0x4
memory[0x94] [0x0000200835e00000-0x00002008367fffff], 0x0000000000a00000 bytes on node 7 flags: 0x0
memory[0x95] [0x0000200836800000-0x00002008369fffff], 0x0000000000200000 bytes on node 7 flags: 0x4
memory[0x96] [0x0000200836a00000-0x0000200837bfffff], 0x0000000001200000 bytes on node 7 flags: 0x0
memory[0x97] [0x0000200837c00000-0x0000200837dfffff], 0x0000000000200000 bytes on node 7 flags: 0x4
memory[0x98] [0x0000200837e00000-0x000020087fffffff], 0x0000000048200000 bytes on node 7 flags: 0x0
memory[0x99] [0x0000200880000000-0x0000200bcfffffff], 0x0000000350000000 bytes on node 6 flags: 0x0
memory[0x9a] [0x0000200bd0000000-0x0000200bd01fffff], 0x0000000000200000 bytes on node 6 flags: 0x4
memory[0x9b] [0x0000200bd0200000-0x0000200bd07fffff], 0x0000000000600000 bytes on node 6 flags: 0x0
memory[0x9c] [0x0000200bd0800000-0x0000200bd09fffff], 0x0000000000200000 bytes on node 6 flags: 0x4
memory[0x9d] [0x0000200bd0a00000-0x0000200fcfffffff], 0x00000003ff600000 bytes on node 6 flags: 0x0
memory[0x9e] [0x0000200fd0000000-0x0000200fd01fffff], 0x0000000000200000 bytes on node 6 flags: 0x4
memory[0x9f] [0x0000200fd0200000-0x0000200fffffffff], 0x000000002fe00000 bytes on node 6 flags: 0x0
...
The EFI memory map is parsed to construct the memblock arrays before the
memblock arrays can be resized. As the result, memory regions beyond
INIT_MEMBLOCK_REGIONS are lost.
Add a new macro INIT_MEMBLOCK_MEMORY_REGIONS to replace
INIT_MEMBLOCK_REGTIONS to define the size of the static memblock.memory
array.
Allow overriding memblock.memory array size with architecture defined
INIT_MEMBLOCK_MEMORY_REGIONS and make arm64 to set
INIT_MEMBLOCK_MEMORY_REGIONS to 1024 when CONFIG_EFI is enabled.
Link: https://lkml.kernel.org/r/20220615102742.96450-1-zhouguanghui1@huawei.com
Signed-off-by: Zhou Guanghui <zhouguanghui1@huawei.com>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Tested-by: Darren Hart <darren@os.amperecomputing.com>
Acked-by: Will Deacon <will@kernel.org> [arm64]
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Xu Qiang <xuqiang36@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-06-15 10:27:42 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:05 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-01 16:18:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:05 +03:00
|
|
|
|
2020-09-25 12:01:25 +02:00
|
|
|
|
2018-06-30 17:55:05 +03:00
|
|
|
|
2020-09-28 15:50:33 +02:00
|
|
|
|
|
|
|
|
|
2020-07-01 16:18:29 +02:00
|
|
|
|
2020-09-25 12:01:25 +02:00
|
|
|
|
2020-07-01 16:18:29 +02:00
|
|
|
|
memblock,arm64: expand the static memblock memory table
In a system(Huawei Ascend ARM64 SoC) using HBM, a multi-bit ECC error
occurs, and the BIOS will mark the corresponding area (for example, 2 MB)
as unusable. When the system restarts next time, these areas are not
reported or reported as EFI_UNUSABLE_MEMORY. Both cases lead to an
increase in the number of memblocks, whereas EFI_UNUSABLE_MEMORY leads to
a larger number of memblocks.
For example, if the EFI_UNUSABLE_MEMORY type is reported:
...
memory[0x92] [0x0000200834a00000-0x0000200835bfffff], 0x0000000001200000 bytes on node 7 flags: 0x0
memory[0x93] [0x0000200835c00000-0x0000200835dfffff], 0x0000000000200000 bytes on node 7 flags: 0x4
memory[0x94] [0x0000200835e00000-0x00002008367fffff], 0x0000000000a00000 bytes on node 7 flags: 0x0
memory[0x95] [0x0000200836800000-0x00002008369fffff], 0x0000000000200000 bytes on node 7 flags: 0x4
memory[0x96] [0x0000200836a00000-0x0000200837bfffff], 0x0000000001200000 bytes on node 7 flags: 0x0
memory[0x97] [0x0000200837c00000-0x0000200837dfffff], 0x0000000000200000 bytes on node 7 flags: 0x4
memory[0x98] [0x0000200837e00000-0x000020087fffffff], 0x0000000048200000 bytes on node 7 flags: 0x0
memory[0x99] [0x0000200880000000-0x0000200bcfffffff], 0x0000000350000000 bytes on node 6 flags: 0x0
memory[0x9a] [0x0000200bd0000000-0x0000200bd01fffff], 0x0000000000200000 bytes on node 6 flags: 0x4
memory[0x9b] [0x0000200bd0200000-0x0000200bd07fffff], 0x0000000000600000 bytes on node 6 flags: 0x0
memory[0x9c] [0x0000200bd0800000-0x0000200bd09fffff], 0x0000000000200000 bytes on node 6 flags: 0x4
memory[0x9d] [0x0000200bd0a00000-0x0000200fcfffffff], 0x00000003ff600000 bytes on node 6 flags: 0x0
memory[0x9e] [0x0000200fd0000000-0x0000200fd01fffff], 0x0000000000200000 bytes on node 6 flags: 0x4
memory[0x9f] [0x0000200fd0200000-0x0000200fffffffff], 0x000000002fe00000 bytes on node 6 flags: 0x0
...
The EFI memory map is parsed to construct the memblock arrays before the
memblock arrays can be resized. As the result, memory regions beyond
INIT_MEMBLOCK_REGIONS are lost.
Add a new macro INIT_MEMBLOCK_MEMORY_REGIONS to replace
INIT_MEMBLOCK_REGTIONS to define the size of the static memblock.memory
array.
Allow overriding memblock.memory array size with architecture defined
INIT_MEMBLOCK_MEMORY_REGIONS and make arm64 to set
INIT_MEMBLOCK_MEMORY_REGIONS to 1024 when CONFIG_EFI is enabled.
Link: https://lkml.kernel.org/r/20220615102742.96450-1-zhouguanghui1@huawei.com
Signed-off-by: Zhou Guanghui <zhouguanghui1@huawei.com>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Tested-by: Darren Hart <darren@os.amperecomputing.com>
Acked-by: Will Deacon <will@kernel.org> [arm64]
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Xu Qiang <xuqiang36@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-06-15 10:27:42 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-30 17:56:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:05 +03:00
|
|
|
|
|
|
|
|
|
2019-11-30 17:56:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:05 +03:00
|
|
|
|
2019-03-11 23:30:54 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-30 17:56:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-11 23:30:54 -07:00
|
|
|
|
2020-06-04 16:49:16 -07:00
|
|
|
|
2019-03-11 23:30:54 -07:00
|
|
|
|
2019-11-30 17:56:21 -08:00
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:05 +03:00
|
|
|
|
2019-11-30 17:56:21 -08:00
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:05 +03:00
|
|
|
|
2019-11-30 17:56:21 -08:00
|
|
|
|
2020-07-01 16:18:29 +02:00
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:05 +03:00
|
|
|
|
|
|
|
|
|
2021-06-28 19:43:01 -07:00
|
|
|
|
2018-10-30 15:09:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
memblock,arm64: expand the static memblock memory table
In a system(Huawei Ascend ARM64 SoC) using HBM, a multi-bit ECC error
occurs, and the BIOS will mark the corresponding area (for example, 2 MB)
as unusable. When the system restarts next time, these areas are not
reported or reported as EFI_UNUSABLE_MEMORY. Both cases lead to an
increase in the number of memblocks, whereas EFI_UNUSABLE_MEMORY leads to
a larger number of memblocks.
For example, if the EFI_UNUSABLE_MEMORY type is reported:
...
memory[0x92] [0x0000200834a00000-0x0000200835bfffff], 0x0000000001200000 bytes on node 7 flags: 0x0
memory[0x93] [0x0000200835c00000-0x0000200835dfffff], 0x0000000000200000 bytes on node 7 flags: 0x4
memory[0x94] [0x0000200835e00000-0x00002008367fffff], 0x0000000000a00000 bytes on node 7 flags: 0x0
memory[0x95] [0x0000200836800000-0x00002008369fffff], 0x0000000000200000 bytes on node 7 flags: 0x4
memory[0x96] [0x0000200836a00000-0x0000200837bfffff], 0x0000000001200000 bytes on node 7 flags: 0x0
memory[0x97] [0x0000200837c00000-0x0000200837dfffff], 0x0000000000200000 bytes on node 7 flags: 0x4
memory[0x98] [0x0000200837e00000-0x000020087fffffff], 0x0000000048200000 bytes on node 7 flags: 0x0
memory[0x99] [0x0000200880000000-0x0000200bcfffffff], 0x0000000350000000 bytes on node 6 flags: 0x0
memory[0x9a] [0x0000200bd0000000-0x0000200bd01fffff], 0x0000000000200000 bytes on node 6 flags: 0x4
memory[0x9b] [0x0000200bd0200000-0x0000200bd07fffff], 0x0000000000600000 bytes on node 6 flags: 0x0
memory[0x9c] [0x0000200bd0800000-0x0000200bd09fffff], 0x0000000000200000 bytes on node 6 flags: 0x4
memory[0x9d] [0x0000200bd0a00000-0x0000200fcfffffff], 0x00000003ff600000 bytes on node 6 flags: 0x0
memory[0x9e] [0x0000200fd0000000-0x0000200fd01fffff], 0x0000000000200000 bytes on node 6 flags: 0x4
memory[0x9f] [0x0000200fd0200000-0x0000200fffffffff], 0x000000002fe00000 bytes on node 6 flags: 0x0
...
The EFI memory map is parsed to construct the memblock arrays before the
memblock arrays can be resized. As the result, memory regions beyond
INIT_MEMBLOCK_REGIONS are lost.
Add a new macro INIT_MEMBLOCK_MEMORY_REGIONS to replace
INIT_MEMBLOCK_REGTIONS to define the size of the static memblock.memory
array.
Allow overriding memblock.memory array size with architecture defined
INIT_MEMBLOCK_MEMORY_REGIONS and make arm64 to set
INIT_MEMBLOCK_MEMORY_REGIONS to 1024 when CONFIG_EFI is enabled.
Link: https://lkml.kernel.org/r/20220615102742.96450-1-zhouguanghui1@huawei.com
Signed-off-by: Zhou Guanghui <zhouguanghui1@huawei.com>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Tested-by: Darren Hart <darren@os.amperecomputing.com>
Acked-by: Will Deacon <will@kernel.org> [arm64]
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Xu Qiang <xuqiang36@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-06-15 10:27:42 +00:00
|
|
|
|
arm64, mm, efi: Account for GICv3 LPI tables in static memblock reserve table
In the irqchip and EFI code, we have what basically amounts to a quirk
to work around a peculiarity in the GICv3 architecture, which permits
the system memory address of LPI tables to be programmable only once
after a CPU reset. This means kexec kernels must use the same memory
as the first kernel, and thus ensure that this memory has not been
given out for other purposes by the time the ITS init code runs, which
is not very early for secondary CPUs.
On systems with many CPUs, these reservations could overflow the
memblock reservation table, and this was addressed in commit:
eff896288872 ("efi/arm: Defer persistent reservations until after paging_init()")
However, this turns out to have made things worse, since the allocation
of page tables and heap space for the resized memblock reservation table
itself may overwrite the regions we are attempting to reserve, which may
cause all kinds of corruption, also considering that the ITS will still
be poking bits into that memory in response to incoming MSIs.
So instead, let's grow the static memblock reservation table on such
systems so it can accommodate these reservations at an earlier time.
This will permit us to revert the above commit in a subsequent patch.
[ mingo: Minor cleanups. ]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20190215123333.21209-2-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-02-15 13:33:32 +01:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2020-07-01 16:18:29 +02:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
memblock,arm64: expand the static memblock memory table
In a system(Huawei Ascend ARM64 SoC) using HBM, a multi-bit ECC error
occurs, and the BIOS will mark the corresponding area (for example, 2 MB)
as unusable. When the system restarts next time, these areas are not
reported or reported as EFI_UNUSABLE_MEMORY. Both cases lead to an
increase in the number of memblocks, whereas EFI_UNUSABLE_MEMORY leads to
a larger number of memblocks.
For example, if the EFI_UNUSABLE_MEMORY type is reported:
...
memory[0x92] [0x0000200834a00000-0x0000200835bfffff], 0x0000000001200000 bytes on node 7 flags: 0x0
memory[0x93] [0x0000200835c00000-0x0000200835dfffff], 0x0000000000200000 bytes on node 7 flags: 0x4
memory[0x94] [0x0000200835e00000-0x00002008367fffff], 0x0000000000a00000 bytes on node 7 flags: 0x0
memory[0x95] [0x0000200836800000-0x00002008369fffff], 0x0000000000200000 bytes on node 7 flags: 0x4
memory[0x96] [0x0000200836a00000-0x0000200837bfffff], 0x0000000001200000 bytes on node 7 flags: 0x0
memory[0x97] [0x0000200837c00000-0x0000200837dfffff], 0x0000000000200000 bytes on node 7 flags: 0x4
memory[0x98] [0x0000200837e00000-0x000020087fffffff], 0x0000000048200000 bytes on node 7 flags: 0x0
memory[0x99] [0x0000200880000000-0x0000200bcfffffff], 0x0000000350000000 bytes on node 6 flags: 0x0
memory[0x9a] [0x0000200bd0000000-0x0000200bd01fffff], 0x0000000000200000 bytes on node 6 flags: 0x4
memory[0x9b] [0x0000200bd0200000-0x0000200bd07fffff], 0x0000000000600000 bytes on node 6 flags: 0x0
memory[0x9c] [0x0000200bd0800000-0x0000200bd09fffff], 0x0000000000200000 bytes on node 6 flags: 0x4
memory[0x9d] [0x0000200bd0a00000-0x0000200fcfffffff], 0x00000003ff600000 bytes on node 6 flags: 0x0
memory[0x9e] [0x0000200fd0000000-0x0000200fd01fffff], 0x0000000000200000 bytes on node 6 flags: 0x4
memory[0x9f] [0x0000200fd0200000-0x0000200fffffffff], 0x000000002fe00000 bytes on node 6 flags: 0x0
...
The EFI memory map is parsed to construct the memblock arrays before the
memblock arrays can be resized. As the result, memory regions beyond
INIT_MEMBLOCK_REGIONS are lost.
Add a new macro INIT_MEMBLOCK_MEMORY_REGIONS to replace
INIT_MEMBLOCK_REGTIONS to define the size of the static memblock.memory
array.
Allow overriding memblock.memory array size with architecture defined
INIT_MEMBLOCK_MEMORY_REGIONS and make arm64 to set
INIT_MEMBLOCK_MEMORY_REGIONS to 1024 when CONFIG_EFI is enabled.
Link: https://lkml.kernel.org/r/20220615102742.96450-1-zhouguanghui1@huawei.com
Signed-off-by: Zhou Guanghui <zhouguanghui1@huawei.com>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Tested-by: Darren Hart <darren@os.amperecomputing.com>
Acked-by: Will Deacon <will@kernel.org> [arm64]
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Xu Qiang <xuqiang36@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-06-15 10:27:42 +00:00
|
|
|
|
2017-02-24 14:55:59 -08:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
arm64, mm, efi: Account for GICv3 LPI tables in static memblock reserve table
In the irqchip and EFI code, we have what basically amounts to a quirk
to work around a peculiarity in the GICv3 architecture, which permits
the system memory address of LPI tables to be programmable only once
after a CPU reset. This means kexec kernels must use the same memory
as the first kernel, and thus ensure that this memory has not been
given out for other purposes by the time the ITS init code runs, which
is not very early for secondary CPUs.
On systems with many CPUs, these reservations could overflow the
memblock reservation table, and this was addressed in commit:
eff896288872 ("efi/arm: Defer persistent reservations until after paging_init()")
However, this turns out to have made things worse, since the allocation
of page tables and heap space for the resized memblock reservation table
itself may overwrite the regions we are attempting to reserve, which may
cause all kinds of corruption, also considering that the ITS will still
be poking bits into that memory in response to incoming MSIs.
So instead, let's grow the static memblock reservation table on such
systems so it can accommodate these reservations at an earlier time.
This will permit us to revert the above commit in a subsequent patch.
[ mingo: Minor cleanups. ]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20190215123333.21209-2-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-02-15 13:33:32 +01:00
|
|
|
|
2017-02-24 14:55:59 -08:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
2013-11-12 15:07:59 -08:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2020-07-01 16:18:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-13 16:58:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-13 16:57:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-13 16:57:54 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-23 15:29:35 +02:00
|
|
|
|
2011-12-08 10:22:08 -08:00
|
|
|
|
2023-04-23 15:29:35 +02:00
|
|
|
|
|
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2023-08-02 15:23:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-11 23:29:46 -07:00
|
|
|
|
2015-06-24 16:58:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-07 17:06:15 -07:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
2010-07-12 14:36:48 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-12 12:09:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mem-hotplug: handle node hole when initializing numa_meminfo.
When parsing SRAT, all memory ranges are added into numa_meminfo. In
numa_init(), before entering numa_cleanup_meminfo(), all possible memory
ranges are in numa_meminfo. And numa_cleanup_meminfo() removes all
ranges over max_pfn or empty.
But, this only works if the nodes are continuous. Let's have a look at
the following example:
We have an SRAT like this:
SRAT: Node 0 PXM 0 [mem 0x00000000-0x5fffffff]
SRAT: Node 0 PXM 0 [mem 0x100000000-0x1ffffffffff]
SRAT: Node 1 PXM 1 [mem 0x20000000000-0x3ffffffffff]
SRAT: Node 4 PXM 2 [mem 0x40000000000-0x5ffffffffff] hotplug
SRAT: Node 5 PXM 3 [mem 0x60000000000-0x7ffffffffff] hotplug
SRAT: Node 2 PXM 4 [mem 0x80000000000-0x9ffffffffff] hotplug
SRAT: Node 3 PXM 5 [mem 0xa0000000000-0xbffffffffff] hotplug
SRAT: Node 6 PXM 6 [mem 0xc0000000000-0xdffffffffff] hotplug
SRAT: Node 7 PXM 7 [mem 0xe0000000000-0xfffffffffff] hotplug
On boot, only node 0,1,2,3 exist.
And the numa_meminfo will look like this:
numa_meminfo.nr_blks = 9
1. on node 0: [0, 60000000]
2. on node 0: [100000000, 20000000000]
3. on node 1: [20000000000, 40000000000]
4. on node 4: [40000000000, 60000000000]
5. on node 5: [60000000000, 80000000000]
6. on node 2: [80000000000, a0000000000]
7. on node 3: [a0000000000, a0800000000]
8. on node 6: [c0000000000, a0800000000]
9. on node 7: [e0000000000, a0800000000]
And numa_cleanup_meminfo() will merge 1 and 2, and remove 8,9 because the
end address is over max_pfn, which is a0800000000. But 4 and 5 are not
removed because their end addresses are less then max_pfn. But in fact,
node 4 and 5 don't exist.
In a word, numa_cleanup_meminfo() is not able to handle holes between nodes.
Since memory ranges in node 4 and 5 are in numa_meminfo, in
numa_register_memblks(), node 4 and 5 will be mistakenly set to online.
If you run lscpu, it will show:
NUMA node0 CPU(s): 0-14,128-142
NUMA node1 CPU(s): 15-29,143-157
NUMA node2 CPU(s):
NUMA node3 CPU(s):
NUMA node4 CPU(s): 62-76,190-204
NUMA node5 CPU(s): 78-92,206-220
In this patch, we use memblock_overlaps_region() to check if ranges in
numa_meminfo overlap with ranges in memory_block. Since memory_block
contains all available memory at boot time, if they overlap, it means the
ranges exist. If not, then remove them from numa_meminfo.
After this patch, lscpu will show:
NUMA node0 CPU(s): 0-14,128-142
NUMA node1 CPU(s): 15-29,143-157
NUMA node4 CPU(s): 62-76,190-204
NUMA node5 CPU(s): 78-92,206-220
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tejun Heo <tj@kernel.org>
Cc: Luiz Capitulino <lcapitulino@redhat.com>
Cc: Xishi Qiu <qiuxishi@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Vladimir Murzin <vladimir.murzin@arm.com>
Cc: Fabian Frederick <fabf@skynet.be>
Cc: Alexander Kuleshov <kuleshovmail@gmail.com>
Cc: Baoquan He <bhe@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-09-08 15:02:03 -07:00
|
|
|
|
2011-10-31 17:09:15 -07:00
|
|
|
|
2010-07-12 14:36:48 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-30 09:12:13 +03:00
|
|
|
|
|
|
|
|
|
2016-01-14 15:20:39 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-07 07:58:31 +00:00
|
|
|
|
|
|
|
|
|
2010-07-12 14:36:48 +10:00
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2013-11-12 15:07:59 -08:00
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
|
|
|
|
|
2013-11-12 15:07:59 -08:00
|
|
|
|
|
|
|
|
|
2014-01-21 15:50:16 -08:00
|
|
|
|
2015-06-24 16:58:09 -07:00
|
|
|
|
2013-11-12 15:07:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2013-11-12 15:07:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-24 16:58:09 -07:00
|
|
|
|
2018-06-30 17:55:01 +03:00
|
|
|
|
2013-11-12 15:07:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-24 16:58:09 -07:00
|
|
|
|
2013-11-12 15:07:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mm/memblock.c: factor out of top-down allocation
[Problem]
The current Linux cannot migrate pages used by the kernel because of the
kernel direct mapping. In Linux kernel space, va = pa + PAGE_OFFSET.
When the pa is changed, we cannot simply update the pagetable and keep the
va unmodified. So the kernel pages are not migratable.
There are also some other issues will cause the kernel pages not
migratable. For example, the physical address may be cached somewhere and
will be used. It is not to update all the caches.
When doing memory hotplug in Linux, we first migrate all the pages in one
memory device somewhere else, and then remove the device. But if pages
are used by the kernel, they are not migratable. As a result, memory used
by the kernel cannot be hot-removed.
Modifying the kernel direct mapping mechanism is too difficult to do. And
it may cause the kernel performance down and unstable. So we use the
following way to do memory hotplug.
[What we are doing]
In Linux, memory in one numa node is divided into several zones. One of
the zones is ZONE_MOVABLE, which the kernel won't use.
In order to implement memory hotplug in Linux, we are going to arrange all
hotpluggable memory in ZONE_MOVABLE so that the kernel won't use these
memory. To do this, we need ACPI's help.
In ACPI, SRAT(System Resource Affinity Table) contains NUMA info. The
memory affinities in SRAT record every memory range in the system, and
also, flags specifying if the memory range is hotpluggable. (Please refer
to ACPI spec 5.0 5.2.16)
With the help of SRAT, we have to do the following two things to achieve our
goal:
1. When doing memory hot-add, allow the users arranging hotpluggable as
ZONE_MOVABLE.
(This has been done by the MOVABLE_NODE functionality in Linux.)
2. when the system is booting, prevent bootmem allocator from allocating
hotpluggable memory for the kernel before the memory initialization
finishes.
The problem 2 is the key problem we are going to solve. But before solving it,
we need some preparation. Please see below.
[Preparation]
Bootloader has to load the kernel image into memory. And this memory must
be unhotpluggable. We cannot prevent this anyway. So in a memory hotplug
system, we can assume any node the kernel resides in is not hotpluggable.
Before SRAT is parsed, we don't know which memory ranges are hotpluggable.
But memblock has already started to work. In the current kernel,
memblock allocates the following memory before SRAT is parsed:
setup_arch()
|->memblock_x86_fill() /* memblock is ready */
|......
|->early_reserve_e820_mpc_new() /* allocate memory under 1MB */
|->reserve_real_mode() /* allocate memory under 1MB */
|->init_mem_mapping() /* allocate page tables, about 2MB to map 1GB memory */
|->dma_contiguous_reserve() /* specified by user, should be low */
|->setup_log_buf() /* specified by user, several mega bytes */
|->relocate_initrd() /* could be large, but will be freed after boot, should reorder */
|->acpi_initrd_override() /* several mega bytes */
|->reserve_crashkernel() /* could be large, should reorder */
|......
|->initmem_init() /* Parse SRAT */
According to Tejun's advice, before SRAT is parsed, we should try our best
to allocate memory near the kernel image. Since the whole node the kernel
resides in won't be hotpluggable, and for a modern server, a node may have
at least 16GB memory, allocating several mega bytes memory around the
kernel image won't cross to hotpluggable memory.
[About this patchset]
So this patchset is the preparation for the problem 2 that we want to
solve. It does the following:
1. Make memblock be able to allocate memory bottom up.
1) Keep all the memblock APIs' prototype unmodified.
2) When the direction is bottom up, keep the start address greater than the
end of kernel image.
2. Improve init_mem_mapping() to support allocate page tables in
bottom up direction.
3. Introduce "movable_node" boot option to enable and disable this
functionality.
This patch (of 6):
Create a new function __memblock_find_range_top_down to factor out of
top-down allocation from memblock_find_in_range_node. This is a
preparation because we will introduce a new bottom-up allocation mode in
the following patch.
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Jiang Liu <jiang.liu@huawei.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-11-12 15:07:57 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
|
|
|
|
|
mm/memblock.c: factor out of top-down allocation
[Problem]
The current Linux cannot migrate pages used by the kernel because of the
kernel direct mapping. In Linux kernel space, va = pa + PAGE_OFFSET.
When the pa is changed, we cannot simply update the pagetable and keep the
va unmodified. So the kernel pages are not migratable.
There are also some other issues will cause the kernel pages not
migratable. For example, the physical address may be cached somewhere and
will be used. It is not to update all the caches.
When doing memory hotplug in Linux, we first migrate all the pages in one
memory device somewhere else, and then remove the device. But if pages
are used by the kernel, they are not migratable. As a result, memory used
by the kernel cannot be hot-removed.
Modifying the kernel direct mapping mechanism is too difficult to do. And
it may cause the kernel performance down and unstable. So we use the
following way to do memory hotplug.
[What we are doing]
In Linux, memory in one numa node is divided into several zones. One of
the zones is ZONE_MOVABLE, which the kernel won't use.
In order to implement memory hotplug in Linux, we are going to arrange all
hotpluggable memory in ZONE_MOVABLE so that the kernel won't use these
memory. To do this, we need ACPI's help.
In ACPI, SRAT(System Resource Affinity Table) contains NUMA info. The
memory affinities in SRAT record every memory range in the system, and
also, flags specifying if the memory range is hotpluggable. (Please refer
to ACPI spec 5.0 5.2.16)
With the help of SRAT, we have to do the following two things to achieve our
goal:
1. When doing memory hot-add, allow the users arranging hotpluggable as
ZONE_MOVABLE.
(This has been done by the MOVABLE_NODE functionality in Linux.)
2. when the system is booting, prevent bootmem allocator from allocating
hotpluggable memory for the kernel before the memory initialization
finishes.
The problem 2 is the key problem we are going to solve. But before solving it,
we need some preparation. Please see below.
[Preparation]
Bootloader has to load the kernel image into memory. And this memory must
be unhotpluggable. We cannot prevent this anyway. So in a memory hotplug
system, we can assume any node the kernel resides in is not hotpluggable.
Before SRAT is parsed, we don't know which memory ranges are hotpluggable.
But memblock has already started to work. In the current kernel,
memblock allocates the following memory before SRAT is parsed:
setup_arch()
|->memblock_x86_fill() /* memblock is ready */
|......
|->early_reserve_e820_mpc_new() /* allocate memory under 1MB */
|->reserve_real_mode() /* allocate memory under 1MB */
|->init_mem_mapping() /* allocate page tables, about 2MB to map 1GB memory */
|->dma_contiguous_reserve() /* specified by user, should be low */
|->setup_log_buf() /* specified by user, several mega bytes */
|->relocate_initrd() /* could be large, but will be freed after boot, should reorder */
|->acpi_initrd_override() /* several mega bytes */
|->reserve_crashkernel() /* could be large, should reorder */
|......
|->initmem_init() /* Parse SRAT */
According to Tejun's advice, before SRAT is parsed, we should try our best
to allocate memory near the kernel image. Since the whole node the kernel
resides in won't be hotpluggable, and for a modern server, a node may have
at least 16GB memory, allocating several mega bytes memory around the
kernel image won't cross to hotpluggable memory.
[About this patchset]
So this patchset is the preparation for the problem 2 that we want to
solve. It does the following:
1. Make memblock be able to allocate memory bottom up.
1) Keep all the memblock APIs' prototype unmodified.
2) When the direction is bottom up, keep the start address greater than the
end of kernel image.
2. Improve init_mem_mapping() to support allocate page tables in
bottom up direction.
3. Introduce "movable_node" boot option to enable and disable this
functionality.
This patch (of 6):
Create a new function __memblock_find_range_top_down to factor out of
top-down allocation from memblock_find_in_range_node. This is a
preparation because we will introduce a new bottom-up allocation mode in
the following patch.
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Jiang Liu <jiang.liu@huawei.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-11-12 15:07:57 -08:00
|
|
|
|
|
|
|
|
|
2014-01-21 15:50:16 -08:00
|
|
|
|
2015-06-24 16:58:09 -07:00
|
|
|
|
mm/memblock.c: factor out of top-down allocation
[Problem]
The current Linux cannot migrate pages used by the kernel because of the
kernel direct mapping. In Linux kernel space, va = pa + PAGE_OFFSET.
When the pa is changed, we cannot simply update the pagetable and keep the
va unmodified. So the kernel pages are not migratable.
There are also some other issues will cause the kernel pages not
migratable. For example, the physical address may be cached somewhere and
will be used. It is not to update all the caches.
When doing memory hotplug in Linux, we first migrate all the pages in one
memory device somewhere else, and then remove the device. But if pages
are used by the kernel, they are not migratable. As a result, memory used
by the kernel cannot be hot-removed.
Modifying the kernel direct mapping mechanism is too difficult to do. And
it may cause the kernel performance down and unstable. So we use the
following way to do memory hotplug.
[What we are doing]
In Linux, memory in one numa node is divided into several zones. One of
the zones is ZONE_MOVABLE, which the kernel won't use.
In order to implement memory hotplug in Linux, we are going to arrange all
hotpluggable memory in ZONE_MOVABLE so that the kernel won't use these
memory. To do this, we need ACPI's help.
In ACPI, SRAT(System Resource Affinity Table) contains NUMA info. The
memory affinities in SRAT record every memory range in the system, and
also, flags specifying if the memory range is hotpluggable. (Please refer
to ACPI spec 5.0 5.2.16)
With the help of SRAT, we have to do the following two things to achieve our
goal:
1. When doing memory hot-add, allow the users arranging hotpluggable as
ZONE_MOVABLE.
(This has been done by the MOVABLE_NODE functionality in Linux.)
2. when the system is booting, prevent bootmem allocator from allocating
hotpluggable memory for the kernel before the memory initialization
finishes.
The problem 2 is the key problem we are going to solve. But before solving it,
we need some preparation. Please see below.
[Preparation]
Bootloader has to load the kernel image into memory. And this memory must
be unhotpluggable. We cannot prevent this anyway. So in a memory hotplug
system, we can assume any node the kernel resides in is not hotpluggable.
Before SRAT is parsed, we don't know which memory ranges are hotpluggable.
But memblock has already started to work. In the current kernel,
memblock allocates the following memory before SRAT is parsed:
setup_arch()
|->memblock_x86_fill() /* memblock is ready */
|......
|->early_reserve_e820_mpc_new() /* allocate memory under 1MB */
|->reserve_real_mode() /* allocate memory under 1MB */
|->init_mem_mapping() /* allocate page tables, about 2MB to map 1GB memory */
|->dma_contiguous_reserve() /* specified by user, should be low */
|->setup_log_buf() /* specified by user, several mega bytes */
|->relocate_initrd() /* could be large, but will be freed after boot, should reorder */
|->acpi_initrd_override() /* several mega bytes */
|->reserve_crashkernel() /* could be large, should reorder */
|......
|->initmem_init() /* Parse SRAT */
According to Tejun's advice, before SRAT is parsed, we should try our best
to allocate memory near the kernel image. Since the whole node the kernel
resides in won't be hotpluggable, and for a modern server, a node may have
at least 16GB memory, allocating several mega bytes memory around the
kernel image won't cross to hotpluggable memory.
[About this patchset]
So this patchset is the preparation for the problem 2 that we want to
solve. It does the following:
1. Make memblock be able to allocate memory bottom up.
1) Keep all the memblock APIs' prototype unmodified.
2) When the direction is bottom up, keep the start address greater than the
end of kernel image.
2. Improve init_mem_mapping() to support allocate page tables in
bottom up direction.
3. Introduce "movable_node" boot option to enable and disable this
functionality.
This patch (of 6):
Create a new function __memblock_find_range_top_down to factor out of
top-down allocation from memblock_find_in_range_node. This is a
preparation because we will introduce a new bottom-up allocation mode in
the following patch.
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Jiang Liu <jiang.liu@huawei.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-11-12 15:07:57 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2013-11-12 15:07:59 -08:00
|
|
|
|
mm/memblock.c: factor out of top-down allocation
[Problem]
The current Linux cannot migrate pages used by the kernel because of the
kernel direct mapping. In Linux kernel space, va = pa + PAGE_OFFSET.
When the pa is changed, we cannot simply update the pagetable and keep the
va unmodified. So the kernel pages are not migratable.
There are also some other issues will cause the kernel pages not
migratable. For example, the physical address may be cached somewhere and
will be used. It is not to update all the caches.
When doing memory hotplug in Linux, we first migrate all the pages in one
memory device somewhere else, and then remove the device. But if pages
are used by the kernel, they are not migratable. As a result, memory used
by the kernel cannot be hot-removed.
Modifying the kernel direct mapping mechanism is too difficult to do. And
it may cause the kernel performance down and unstable. So we use the
following way to do memory hotplug.
[What we are doing]
In Linux, memory in one numa node is divided into several zones. One of
the zones is ZONE_MOVABLE, which the kernel won't use.
In order to implement memory hotplug in Linux, we are going to arrange all
hotpluggable memory in ZONE_MOVABLE so that the kernel won't use these
memory. To do this, we need ACPI's help.
In ACPI, SRAT(System Resource Affinity Table) contains NUMA info. The
memory affinities in SRAT record every memory range in the system, and
also, flags specifying if the memory range is hotpluggable. (Please refer
to ACPI spec 5.0 5.2.16)
With the help of SRAT, we have to do the following two things to achieve our
goal:
1. When doing memory hot-add, allow the users arranging hotpluggable as
ZONE_MOVABLE.
(This has been done by the MOVABLE_NODE functionality in Linux.)
2. when the system is booting, prevent bootmem allocator from allocating
hotpluggable memory for the kernel before the memory initialization
finishes.
The problem 2 is the key problem we are going to solve. But before solving it,
we need some preparation. Please see below.
[Preparation]
Bootloader has to load the kernel image into memory. And this memory must
be unhotpluggable. We cannot prevent this anyway. So in a memory hotplug
system, we can assume any node the kernel resides in is not hotpluggable.
Before SRAT is parsed, we don't know which memory ranges are hotpluggable.
But memblock has already started to work. In the current kernel,
memblock allocates the following memory before SRAT is parsed:
setup_arch()
|->memblock_x86_fill() /* memblock is ready */
|......
|->early_reserve_e820_mpc_new() /* allocate memory under 1MB */
|->reserve_real_mode() /* allocate memory under 1MB */
|->init_mem_mapping() /* allocate page tables, about 2MB to map 1GB memory */
|->dma_contiguous_reserve() /* specified by user, should be low */
|->setup_log_buf() /* specified by user, several mega bytes */
|->relocate_initrd() /* could be large, but will be freed after boot, should reorder */
|->acpi_initrd_override() /* several mega bytes */
|->reserve_crashkernel() /* could be large, should reorder */
|......
|->initmem_init() /* Parse SRAT */
According to Tejun's advice, before SRAT is parsed, we should try our best
to allocate memory near the kernel image. Since the whole node the kernel
resides in won't be hotpluggable, and for a modern server, a node may have
at least 16GB memory, allocating several mega bytes memory around the
kernel image won't cross to hotpluggable memory.
[About this patchset]
So this patchset is the preparation for the problem 2 that we want to
solve. It does the following:
1. Make memblock be able to allocate memory bottom up.
1) Keep all the memblock APIs' prototype unmodified.
2) When the direction is bottom up, keep the start address greater than the
end of kernel image.
2. Improve init_mem_mapping() to support allocate page tables in
bottom up direction.
3. Introduce "movable_node" boot option to enable and disable this
functionality.
This patch (of 6):
Create a new function __memblock_find_range_top_down to factor out of
top-down allocation from memblock_find_in_range_node. This is a
preparation because we will introduce a new bottom-up allocation mode in
the following patch.
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Jiang Liu <jiang.liu@huawei.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-11-12 15:07:57 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-24 16:58:09 -07:00
|
|
|
|
2018-06-30 17:55:01 +03:00
|
|
|
|
mm/memblock.c: factor out of top-down allocation
[Problem]
The current Linux cannot migrate pages used by the kernel because of the
kernel direct mapping. In Linux kernel space, va = pa + PAGE_OFFSET.
When the pa is changed, we cannot simply update the pagetable and keep the
va unmodified. So the kernel pages are not migratable.
There are also some other issues will cause the kernel pages not
migratable. For example, the physical address may be cached somewhere and
will be used. It is not to update all the caches.
When doing memory hotplug in Linux, we first migrate all the pages in one
memory device somewhere else, and then remove the device. But if pages
are used by the kernel, they are not migratable. As a result, memory used
by the kernel cannot be hot-removed.
Modifying the kernel direct mapping mechanism is too difficult to do. And
it may cause the kernel performance down and unstable. So we use the
following way to do memory hotplug.
[What we are doing]
In Linux, memory in one numa node is divided into several zones. One of
the zones is ZONE_MOVABLE, which the kernel won't use.
In order to implement memory hotplug in Linux, we are going to arrange all
hotpluggable memory in ZONE_MOVABLE so that the kernel won't use these
memory. To do this, we need ACPI's help.
In ACPI, SRAT(System Resource Affinity Table) contains NUMA info. The
memory affinities in SRAT record every memory range in the system, and
also, flags specifying if the memory range is hotpluggable. (Please refer
to ACPI spec 5.0 5.2.16)
With the help of SRAT, we have to do the following two things to achieve our
goal:
1. When doing memory hot-add, allow the users arranging hotpluggable as
ZONE_MOVABLE.
(This has been done by the MOVABLE_NODE functionality in Linux.)
2. when the system is booting, prevent bootmem allocator from allocating
hotpluggable memory for the kernel before the memory initialization
finishes.
The problem 2 is the key problem we are going to solve. But before solving it,
we need some preparation. Please see below.
[Preparation]
Bootloader has to load the kernel image into memory. And this memory must
be unhotpluggable. We cannot prevent this anyway. So in a memory hotplug
system, we can assume any node the kernel resides in is not hotpluggable.
Before SRAT is parsed, we don't know which memory ranges are hotpluggable.
But memblock has already started to work. In the current kernel,
memblock allocates the following memory before SRAT is parsed:
setup_arch()
|->memblock_x86_fill() /* memblock is ready */
|......
|->early_reserve_e820_mpc_new() /* allocate memory under 1MB */
|->reserve_real_mode() /* allocate memory under 1MB */
|->init_mem_mapping() /* allocate page tables, about 2MB to map 1GB memory */
|->dma_contiguous_reserve() /* specified by user, should be low */
|->setup_log_buf() /* specified by user, several mega bytes */
|->relocate_initrd() /* could be large, but will be freed after boot, should reorder */
|->acpi_initrd_override() /* several mega bytes */
|->reserve_crashkernel() /* could be large, should reorder */
|......
|->initmem_init() /* Parse SRAT */
According to Tejun's advice, before SRAT is parsed, we should try our best
to allocate memory near the kernel image. Since the whole node the kernel
resides in won't be hotpluggable, and for a modern server, a node may have
at least 16GB memory, allocating several mega bytes memory around the
kernel image won't cross to hotpluggable memory.
[About this patchset]
So this patchset is the preparation for the problem 2 that we want to
solve. It does the following:
1. Make memblock be able to allocate memory bottom up.
1) Keep all the memblock APIs' prototype unmodified.
2) When the direction is bottom up, keep the start address greater than the
end of kernel image.
2. Improve init_mem_mapping() to support allocate page tables in
bottom up direction.
3. Introduce "movable_node" boot option to enable and disable this
functionality.
This patch (of 6):
Create a new function __memblock_find_range_top_down to factor out of
top-down allocation from memblock_find_in_range_node. This is a
preparation because we will introduce a new bottom-up allocation mode in
the following patch.
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Jiang Liu <jiang.liu@huawei.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-11-12 15:07:57 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-24 16:58:09 -07:00
|
|
|
|
|
|
|
|
|
mm/memblock.c: factor out of top-down allocation
[Problem]
The current Linux cannot migrate pages used by the kernel because of the
kernel direct mapping. In Linux kernel space, va = pa + PAGE_OFFSET.
When the pa is changed, we cannot simply update the pagetable and keep the
va unmodified. So the kernel pages are not migratable.
There are also some other issues will cause the kernel pages not
migratable. For example, the physical address may be cached somewhere and
will be used. It is not to update all the caches.
When doing memory hotplug in Linux, we first migrate all the pages in one
memory device somewhere else, and then remove the device. But if pages
are used by the kernel, they are not migratable. As a result, memory used
by the kernel cannot be hot-removed.
Modifying the kernel direct mapping mechanism is too difficult to do. And
it may cause the kernel performance down and unstable. So we use the
following way to do memory hotplug.
[What we are doing]
In Linux, memory in one numa node is divided into several zones. One of
the zones is ZONE_MOVABLE, which the kernel won't use.
In order to implement memory hotplug in Linux, we are going to arrange all
hotpluggable memory in ZONE_MOVABLE so that the kernel won't use these
memory. To do this, we need ACPI's help.
In ACPI, SRAT(System Resource Affinity Table) contains NUMA info. The
memory affinities in SRAT record every memory range in the system, and
also, flags specifying if the memory range is hotpluggable. (Please refer
to ACPI spec 5.0 5.2.16)
With the help of SRAT, we have to do the following two things to achieve our
goal:
1. When doing memory hot-add, allow the users arranging hotpluggable as
ZONE_MOVABLE.
(This has been done by the MOVABLE_NODE functionality in Linux.)
2. when the system is booting, prevent bootmem allocator from allocating
hotpluggable memory for the kernel before the memory initialization
finishes.
The problem 2 is the key problem we are going to solve. But before solving it,
we need some preparation. Please see below.
[Preparation]
Bootloader has to load the kernel image into memory. And this memory must
be unhotpluggable. We cannot prevent this anyway. So in a memory hotplug
system, we can assume any node the kernel resides in is not hotpluggable.
Before SRAT is parsed, we don't know which memory ranges are hotpluggable.
But memblock has already started to work. In the current kernel,
memblock allocates the following memory before SRAT is parsed:
setup_arch()
|->memblock_x86_fill() /* memblock is ready */
|......
|->early_reserve_e820_mpc_new() /* allocate memory under 1MB */
|->reserve_real_mode() /* allocate memory under 1MB */
|->init_mem_mapping() /* allocate page tables, about 2MB to map 1GB memory */
|->dma_contiguous_reserve() /* specified by user, should be low */
|->setup_log_buf() /* specified by user, several mega bytes */
|->relocate_initrd() /* could be large, but will be freed after boot, should reorder */
|->acpi_initrd_override() /* several mega bytes */
|->reserve_crashkernel() /* could be large, should reorder */
|......
|->initmem_init() /* Parse SRAT */
According to Tejun's advice, before SRAT is parsed, we should try our best
to allocate memory near the kernel image. Since the whole node the kernel
resides in won't be hotpluggable, and for a modern server, a node may have
at least 16GB memory, allocating several mega bytes memory around the
kernel image won't cross to hotpluggable memory.
[About this patchset]
So this patchset is the preparation for the problem 2 that we want to
solve. It does the following:
1. Make memblock be able to allocate memory bottom up.
1) Keep all the memblock APIs' prototype unmodified.
2) When the direction is bottom up, keep the start address greater than the
end of kernel image.
2. Improve init_mem_mapping() to support allocate page tables in
bottom up direction.
3. Introduce "movable_node" boot option to enable and disable this
functionality.
This patch (of 6):
Create a new function __memblock_find_range_top_down to factor out of
top-down allocation from memblock_find_in_range_node. This is a
preparation because we will introduce a new bottom-up allocation mode in
the following patch.
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Jiang Liu <jiang.liu@huawei.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-11-12 15:07:57 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-21 15:50:14 -08:00
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
|
|
|
|
|
2014-01-21 15:50:16 -08:00
|
|
|
|
2015-06-24 16:58:09 -07:00
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2013-11-12 15:07:59 -08:00
|
|
|
|
2010-07-12 14:36:48 +10:00
|
|
|
|
2019-03-11 23:29:46 -07:00
|
|
|
|
2014-01-21 15:50:14 -08:00
|
|
|
|
2018-06-30 17:55:01 +03:00
|
|
|
|
|
|
|
|
|
2013-02-22 16:33:51 -08:00
|
|
|
|
|
|
|
|
|
mm/memblock.c: skip kmemleak for kasan_init()
Kmemleak does not play well with KASAN (tested on both HPE Apollo 70 and
Huawei TaiShan 2280 aarch64 servers).
After calling start_kernel()->setup_arch()->kasan_init(), kmemleak early
log buffer went from something like 280 to 260000 which caused kmemleak
disabled and crash dump memory reservation failed. The multitude of
kmemleak_alloc() calls is from nested loops while KASAN is setting up full
memory mappings, so let early kmemleak allocations skip those
memblock_alloc_internal() calls came from kasan_init() given that those
early KASAN memory mappings should not reference to other memory. Hence,
no kmemleak false positives.
kasan_init
kasan_map_populate [1]
kasan_pgd_populate [2]
kasan_pud_populate [3]
kasan_pmd_populate [4]
kasan_pte_populate [5]
kasan_alloc_zeroed_page
memblock_alloc_try_nid
memblock_alloc_internal
kmemleak_alloc
[1] for_each_memblock(memory, reg)
[2] while (pgdp++, addr = next, addr != end)
[3] while (pudp++, addr = next, addr != end && pud_none(READ_ONCE(*pudp)))
[4] while (pmdp++, addr = next, addr != end && pmd_none(READ_ONCE(*pmdp)))
[5] while (ptep++, addr = next, addr != end && pte_none(READ_ONCE(*ptep)))
Link: http://lkml.kernel.org/r/1543442925-17794-1-git-send-email-cai@gmx.us
Signed-off-by: Qian Cai <cai@gmx.us>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-12-28 00:36:29 -08:00
|
|
|
|
2021-11-05 11:05:09 -04:00
|
|
|
|
2013-02-22 16:33:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-12 15:07:59 -08:00
|
|
|
|
2021-02-04 18:32:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-22 16:33:51 -08:00
|
|
|
|
2010-07-12 14:36:48 +10:00
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2013-11-12 15:07:59 -08:00
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
2021-09-02 15:00:26 -07:00
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-24 16:58:12 -07:00
|
|
|
|
2018-06-30 17:55:01 +03:00
|
|
|
|
2015-06-24 16:58:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-14 17:21:53 +08:00
|
|
|
|
2015-06-24 16:58:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
|
|
|
|
|
2010-07-28 15:43:02 +10:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2011-12-08 10:22:08 -08:00
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
|
|
|
|
|
2010-08-04 14:06:41 +10:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
mm/memblock: properly handle overlaps and fix error path
Currently memblock_reserve() or memblock_free() don't handle overlaps of
any kind. There is some special casing for coalescing exactly adjacent
regions but that's about it.
This is annoying because typically memblock_reserve() is used to mark
regions passed by the firmware as reserved and we all know how much we can
trust our firmwares...
Also, with the current code, if we do something it doesn't handle right
such as trying to memblock_reserve() a large range spanning multiple
existing smaller reserved regions for example, or doing overlapping
reservations, it can silently corrupt the internal region array, causing
odd errors much later on, such as allocations returning reserved regions
etc...
This patch rewrites the underlying functions that add or remove a region
to the arrays. The new code is a lot more robust as it fully handles
overlapping regions. It's also, imho, simpler than the previous
implementation.
In addition, while doing so, I found a bug where if we fail to double the
array while adding a region, we would remove the last region of the array
rather than the region we just allocated. This fixes it too.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-03-22 16:33:43 -07:00
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:08 -08:00
|
|
|
|
mm/memblock: properly handle overlaps and fix error path
Currently memblock_reserve() or memblock_free() don't handle overlaps of
any kind. There is some special casing for coalescing exactly adjacent
regions but that's about it.
This is annoying because typically memblock_reserve() is used to mark
regions passed by the firmware as reserved and we all know how much we can
trust our firmwares...
Also, with the current code, if we do something it doesn't handle right
such as trying to memblock_reserve() a large range spanning multiple
existing smaller reserved regions for example, or doing overlapping
reservations, it can silently corrupt the internal region array, causing
odd errors much later on, such as allocations returning reserved regions
etc...
This patch rewrites the underlying functions that add or remove a region
to the arrays. The new code is a lot more robust as it fully handles
overlapping regions. It's also, imho, simpler than the previous
implementation.
In addition, while doing so, I found a bug where if we fail to double the
array while adding a region, we would remove the last region of the array
rather than the region we just allocated. This fixes it too.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-03-22 16:33:43 -07:00
|
|
|
|
|
|
|
|
|
2014-01-21 15:49:20 -08:00
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
mm/memblock: properly handle overlaps and fix error path
Currently memblock_reserve() or memblock_free() don't handle overlaps of
any kind. There is some special casing for coalescing exactly adjacent
regions but that's about it.
This is annoying because typically memblock_reserve() is used to mark
regions passed by the firmware as reserved and we all know how much we can
trust our firmwares...
Also, with the current code, if we do something it doesn't handle right
such as trying to memblock_reserve() a large range spanning multiple
existing smaller reserved regions for example, or doing overlapping
reservations, it can silently corrupt the internal region array, causing
odd errors much later on, such as allocations returning reserved regions
etc...
This patch rewrites the underlying functions that add or remove a region
to the arrays. The new code is a lot more robust as it fully handles
overlapping regions. It's also, imho, simpler than the previous
implementation.
In addition, while doing so, I found a bug where if we fail to double the
array while adding a region, we would remove the last region of the array
rather than the region we just allocated. This fixes it too.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-03-22 16:33:43 -07:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2019-05-13 17:22:59 -07:00
|
|
|
|
2017-08-18 15:16:05 -07:00
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2017-08-18 15:16:05 -07:00
|
|
|
|
|
|
|
|
|
2012-07-11 14:02:56 -07:00
|
|
|
|
2017-08-18 15:16:05 -07:00
|
|
|
|
2012-07-11 14:02:56 -07:00
|
|
|
|
2017-08-18 15:16:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-17 22:53:27 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-18 15:16:05 -07:00
|
|
|
|
2012-07-11 14:02:56 -07:00
|
|
|
|
2017-08-25 15:55:46 -07:00
|
|
|
|
2017-08-18 15:16:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-17 22:53:27 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-18 15:16:05 -07:00
|
|
|
|
2020-10-13 16:58:25 -07:00
|
|
|
|
|
|
|
|
|
2012-07-11 14:02:56 -07:00
|
|
|
|
2014-01-23 15:53:11 -08:00
|
|
|
|
|
|
|
|
|
2012-06-20 12:53:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2012-06-20 12:53:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2012-06-20 12:53:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-06 15:39:13 -07:00
|
|
|
|
|
|
|
|
|
2012-07-11 14:02:56 -07:00
|
|
|
|
2018-08-17 15:47:17 -07:00
|
|
|
|
2010-07-06 15:39:13 -07:00
|
|
|
|
2012-05-29 15:06:50 -07:00
|
|
|
|
2010-07-06 15:39:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-24 11:26:07 +08:00
|
|
|
|
2010-07-06 15:39:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-11 14:02:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-06 15:39:13 -07:00
|
|
|
|
2012-05-29 15:06:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-11 23:30:54 -07:00
|
|
|
|
2010-07-06 15:39:13 -07:00
|
|
|
|
|
|
|
|
|
2011-07-12 09:58:09 +02:00
|
|
|
|
2012-05-29 15:06:50 -07:00
|
|
|
|
2012-06-20 12:53:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-11 14:02:56 -07:00
|
|
|
|
2012-06-20 12:53:05 -07:00
|
|
|
|
|
|
|
|
|
2012-07-31 16:42:40 -07:00
|
|
|
|
|
|
|
|
|
2012-06-20 12:53:05 -07:00
|
|
|
|
2025-05-08 12:24:10 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-29 15:06:50 -07:00
|
|
|
|
2011-07-12 09:58:09 +02:00
|
|
|
|
2010-07-06 15:39:13 -07:00
|
|
|
|
2017-02-24 14:55:59 -08:00
|
|
|
|
2010-07-06 15:39:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-17 15:47:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-28 15:13:22 +10:00
|
|
|
|
2012-07-31 16:42:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-06 15:39:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-31 16:42:40 -07:00
|
|
|
|
2012-05-29 15:06:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-05 13:43:22 -07:00
|
|
|
|
2010-07-06 15:39:13 -07:00
|
|
|
|
2012-07-31 16:42:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-29 15:06:50 -07:00
|
|
|
|
|
|
|
|
|
2012-07-11 14:02:56 -07:00
|
|
|
|
2012-05-29 15:06:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-06 15:39:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-29 17:00:34 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
2023-01-29 17:00:34 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
2023-01-29 17:00:34 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
|
|
|
|
|
2014-01-21 15:49:20 -08:00
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-11 14:31:44 -08:00
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
2023-01-29 17:00:34 +08:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-29 15:08:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-21 15:49:20 -08:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2016-08-04 15:31:46 -07:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-21 15:49:20 -08:00
|
|
|
|
2018-06-30 17:55:01 +03:00
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-21 15:49:20 -08:00
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
2011-12-08 10:22:08 -08:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:08 -08:00
|
|
|
|
2014-01-21 15:49:20 -08:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
2020-01-30 22:14:20 -08:00
|
|
|
|
2014-01-21 15:49:20 -08:00
|
|
|
|
2018-06-30 17:55:01 +03:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
2023-01-29 17:00:34 +08:00
|
|
|
|
2016-01-14 15:20:42 -08:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2012-04-20 08:31:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
2024-04-05 01:58:21 +00:00
|
|
|
|
2010-08-04 14:06:41 +10:00
|
|
|
|
|
|
|
|
|
2014-01-21 15:49:20 -08:00
|
|
|
|
2011-12-08 10:22:08 -08:00
|
|
|
|
2011-12-08 10:22:08 -08:00
|
|
|
|
2024-04-05 01:58:21 +00:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2022-06-15 17:40:15 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-29 17:00:33 +08:00
|
|
|
|
2022-06-15 17:40:15 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-29 17:00:33 +08:00
|
|
|
|
2022-06-15 17:40:15 +08:00
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-04 15:31:46 -07:00
|
|
|
|
2010-07-06 15:39:13 -07:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2017-11-15 17:33:42 -08:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-28 19:43:01 -07:00
|
|
|
|
2015-09-04 15:47:38 -07:00
|
|
|
|
|
|
|
|
|
2015-09-08 14:59:53 -07:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
2023-01-29 17:00:34 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-14 15:20:42 -08:00
|
|
|
|
2014-01-21 15:49:20 -08:00
|
|
|
|
|
|
|
|
|
2023-01-29 17:00:34 +08:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-29 17:00:34 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-14 15:20:42 -08:00
|
|
|
|
2014-01-21 15:49:20 -08:00
|
|
|
|
2023-01-29 17:00:34 +08:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
2016-07-26 15:24:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-06 15:39:13 -07:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
2012-06-20 12:53:05 -07:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-29 17:00:34 +08:00
|
|
|
|
2011-07-12 11:15:55 +02:00
|
|
|
|
2010-07-06 15:39:13 -07:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:03 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-05 13:44:49 -07:00
|
|
|
|
2018-06-30 17:55:03 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:08 -08:00
|
|
|
|
2021-11-05 13:44:49 -07:00
|
|
|
|
2011-12-08 10:22:08 -08:00
|
|
|
|
2021-08-11 10:54:36 +02:00
|
|
|
|
|
|
|
|
|
2021-11-05 13:44:49 -07:00
|
|
|
|
|
|
|
|
|
2021-08-11 10:54:36 +02:00
|
|
|
|
2021-11-05 13:44:49 -07:00
|
|
|
|
2011-12-08 10:22:08 -08:00
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:03 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-20 16:57:35 -07:00
|
|
|
|
2015-04-15 16:14:44 -07:00
|
|
|
|
2017-02-22 15:46:42 -08:00
|
|
|
|
|
|
|
|
|
2020-01-30 22:14:23 -08:00
|
|
|
|
2017-02-22 15:46:42 -08:00
|
|
|
|
2015-04-15 16:14:44 -07:00
|
|
|
|
2016-05-20 16:57:35 -07:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2023-10-26 10:03:29 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-29 11:13:47 +02:00
|
|
|
|
2023-10-26 10:03:29 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-14 11:05:43 +03:00
|
|
|
|
2023-10-26 10:03:29 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-29 11:13:47 +02:00
|
|
|
|
2023-10-26 10:03:29 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
2024-05-07 07:58:29 +00:00
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
2016-01-14 15:20:42 -08:00
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 08:31:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
2012-06-20 12:53:05 -07:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
2017-11-15 17:33:42 -08:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:08 -08:00
|
|
|
|
|
|
|
|
|
2016-01-14 15:20:42 -08:00
|
|
|
|
2014-01-21 15:49:20 -08:00
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:08 -08:00
|
|
|
|
|
|
|
|
|
2016-01-14 15:20:42 -08:00
|
|
|
|
2014-01-21 15:49:20 -08:00
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-14 15:20:42 -08:00
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-05 18:47:00 -08:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
mm/memblock: properly handle overlaps and fix error path
Currently memblock_reserve() or memblock_free() don't handle overlaps of
any kind. There is some special casing for coalescing exactly adjacent
regions but that's about it.
This is annoying because typically memblock_reserve() is used to mark
regions passed by the firmware as reserved and we all know how much we can
trust our firmwares...
Also, with the current code, if we do something it doesn't handle right
such as trying to memblock_reserve() a large range spanning multiple
existing smaller reserved regions for example, or doing overlapping
reservations, it can silently corrupt the internal region array, causing
odd errors much later on, such as allocations returning reserved regions
etc...
This patch rewrites the underlying functions that add or remove a region
to the arrays. The new code is a lot more robust as it fully handles
overlapping regions. It's also, imho, simpler than the previous
implementation.
In addition, while doing so, I found a bug where if we fail to double the
array while adding a region, we would remove the last region of the array
rather than the region we just allocated. This fixes it too.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-03-22 16:33:43 -07:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:06 -08:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2018-06-07 17:07:35 -07:00
|
|
|
|
|
|
|
|
|
2020-01-30 22:14:23 -08:00
|
|
|
|
2018-06-07 17:07:35 -07:00
|
|
|
|
|
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
memblock: introduce saner 'memblock_free_ptr()' interface
The boot-time allocation interface for memblock is a mess, with
'memblock_alloc()' returning a virtual pointer, but then you are
supposed to free it with 'memblock_free()' that takes a _physical_
address.
Not only is that all kinds of strange and illogical, but it actually
causes bugs, when people then use it like a normal allocation function,
and it fails spectacularly on a NULL pointer:
https://lore.kernel.org/all/20210912140820.GD25450@xsang-OptiPlex-9020/
or just random memory corruption if the debug checks don't catch it:
https://lore.kernel.org/all/61ab2d0c-3313-aaab-514c-e15b7aa054a0@suse.cz/
I really don't want to apply patches that treat the symptoms, when the
fundamental cause is this horribly confusing interface.
I started out looking at just automating a sane replacement sequence,
but because of this mix or virtual and physical addresses, and because
people have used the "__pa()" macro that can take either a regular
kernel pointer, or just the raw "unsigned long" address, it's all quite
messy.
So this just introduces a new saner interface for freeing a virtual
address that was allocated using 'memblock_alloc()', and that was kept
as a regular kernel pointer. And then it converts a couple of users
that are obvious and easy to test, including the 'xbc_nodes' case in
lib/bootconfig.c that caused problems.
Reported-by: kernel test robot <oliver.sang@intel.com>
Fixes: 40caa127f3c7 ("init: bootconfig: Remove all bootconfig data when the init memory is removed")
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-09-14 13:23:22 -07:00
|
|
|
|
2021-11-05 13:43:22 -07:00
|
|
|
|
memblock: introduce saner 'memblock_free_ptr()' interface
The boot-time allocation interface for memblock is a mess, with
'memblock_alloc()' returning a virtual pointer, but then you are
supposed to free it with 'memblock_free()' that takes a _physical_
address.
Not only is that all kinds of strange and illogical, but it actually
causes bugs, when people then use it like a normal allocation function,
and it fails spectacularly on a NULL pointer:
https://lore.kernel.org/all/20210912140820.GD25450@xsang-OptiPlex-9020/
or just random memory corruption if the debug checks don't catch it:
https://lore.kernel.org/all/61ab2d0c-3313-aaab-514c-e15b7aa054a0@suse.cz/
I really don't want to apply patches that treat the symptoms, when the
fundamental cause is this horribly confusing interface.
I started out looking at just automating a sane replacement sequence,
but because of this mix or virtual and physical addresses, and because
people have used the "__pa()" macro that can take either a regular
kernel pointer, or just the raw "unsigned long" address, it's all quite
messy.
So this just introduces a new saner interface for freeing a virtual
address that was allocated using 'memblock_alloc()', and that was kept
as a regular kernel pointer. And then it converts a couple of users
that are obvious and easy to test, including the 'xbc_nodes' case in
lib/bootconfig.c that caused problems.
Reported-by: kernel test robot <oliver.sang@intel.com>
Fixes: 40caa127f3c7 ("init: bootconfig: Remove all bootconfig data when the init memory is removed")
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-09-14 13:23:22 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-05 13:43:22 -07:00
|
|
|
|
memblock: introduce saner 'memblock_free_ptr()' interface
The boot-time allocation interface for memblock is a mess, with
'memblock_alloc()' returning a virtual pointer, but then you are
supposed to free it with 'memblock_free()' that takes a _physical_
address.
Not only is that all kinds of strange and illogical, but it actually
causes bugs, when people then use it like a normal allocation function,
and it fails spectacularly on a NULL pointer:
https://lore.kernel.org/all/20210912140820.GD25450@xsang-OptiPlex-9020/
or just random memory corruption if the debug checks don't catch it:
https://lore.kernel.org/all/61ab2d0c-3313-aaab-514c-e15b7aa054a0@suse.cz/
I really don't want to apply patches that treat the symptoms, when the
fundamental cause is this horribly confusing interface.
I started out looking at just automating a sane replacement sequence,
but because of this mix or virtual and physical addresses, and because
people have used the "__pa()" macro that can take either a regular
kernel pointer, or just the raw "unsigned long" address, it's all quite
messy.
So this just introduces a new saner interface for freeing a virtual
address that was allocated using 'memblock_alloc()', and that was kept
as a regular kernel pointer. And then it converts a couple of users
that are obvious and easy to test, including the 'xbc_nodes' case in
lib/bootconfig.c that caused problems.
Reported-by: kernel test robot <oliver.sang@intel.com>
Fixes: 40caa127f3c7 ("init: bootconfig: Remove all bootconfig data when the init memory is removed")
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-09-14 13:23:22 -07:00
|
|
|
|
|
|
|
|
|
2021-11-05 13:43:19 -07:00
|
|
|
|
memblock: introduce saner 'memblock_free_ptr()' interface
The boot-time allocation interface for memblock is a mess, with
'memblock_alloc()' returning a virtual pointer, but then you are
supposed to free it with 'memblock_free()' that takes a _physical_
address.
Not only is that all kinds of strange and illogical, but it actually
causes bugs, when people then use it like a normal allocation function,
and it fails spectacularly on a NULL pointer:
https://lore.kernel.org/all/20210912140820.GD25450@xsang-OptiPlex-9020/
or just random memory corruption if the debug checks don't catch it:
https://lore.kernel.org/all/61ab2d0c-3313-aaab-514c-e15b7aa054a0@suse.cz/
I really don't want to apply patches that treat the symptoms, when the
fundamental cause is this horribly confusing interface.
I started out looking at just automating a sane replacement sequence,
but because of this mix or virtual and physical addresses, and because
people have used the "__pa()" macro that can take either a regular
kernel pointer, or just the raw "unsigned long" address, it's all quite
messy.
So this just introduces a new saner interface for freeing a virtual
address that was allocated using 'memblock_alloc()', and that was kept
as a regular kernel pointer. And then it converts a couple of users
that are obvious and easy to test, including the 'xbc_nodes' case in
lib/bootconfig.c that caused problems.
Reported-by: kernel test robot <oliver.sang@intel.com>
Fixes: 40caa127f3c7 ("init: bootconfig: Remove all bootconfig data when the init memory is removed")
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-09-14 13:23:22 -07:00
|
|
|
|
|
|
|
|
|
2018-12-28 00:35:29 -08:00
|
|
|
|
2021-11-05 13:43:19 -07:00
|
|
|
|
2018-12-28 00:35:29 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-16 14:03:03 +04:00
|
|
|
|
2018-12-28 00:35:29 -08:00
|
|
|
|
|
|
|
|
|
2021-11-05 13:43:19 -07:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2017-02-22 15:46:42 -08:00
|
|
|
|
|
|
|
|
|
2020-01-30 22:14:23 -08:00
|
|
|
|
2017-02-22 15:46:42 -08:00
|
|
|
|
2011-07-12 11:16:06 +02:00
|
|
|
|
2016-10-11 13:55:11 -07:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2016-05-20 16:57:35 -07:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2017-02-22 15:46:42 -08:00
|
|
|
|
|
|
|
|
|
2020-01-30 22:14:23 -08:00
|
|
|
|
2017-02-22 15:46:42 -08:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2016-05-20 16:57:35 -07:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2020-01-30 22:14:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-01 16:18:29 +02:00
|
|
|
|
2020-01-30 22:14:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-21 15:49:23 -08:00
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2023-09-13 11:53:59 +01:00
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-15 20:47:26 -08:00
|
|
|
|
2014-01-21 15:49:23 -08:00
|
|
|
|
2014-12-12 16:54:59 -08:00
|
|
|
|
2014-01-21 15:49:23 -08:00
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2014-01-21 15:49:23 -08:00
|
|
|
|
2023-09-13 11:53:59 +01:00
|
|
|
|
|
|
|
|
|
2014-01-21 15:49:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-11 23:30:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-12 16:54:59 -08:00
|
|
|
|
2019-03-11 23:30:46 -07:00
|
|
|
|
2014-12-12 16:54:59 -08:00
|
|
|
|
2019-03-11 23:30:46 -07:00
|
|
|
|
|
|
|
|
|
2014-01-21 15:49:23 -08:00
|
|
|
|
2023-01-29 17:00:34 +08:00
|
|
|
|
2014-01-21 15:49:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-12 16:54:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2014-12-12 16:54:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-13 11:53:59 +01:00
|
|
|
|
2014-12-12 16:54:59 -08:00
|
|
|
|
|
|
|
|
|
2014-01-21 15:49:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2014-01-21 15:49:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-13 11:53:59 +01:00
|
|
|
|
2014-01-21 15:49:23 -08:00
|
|
|
|
|
|
|
|
|
2015-06-24 16:58:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2015-06-24 16:58:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-14 17:21:56 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-24 16:58:12 -07:00
|
|
|
|
|
|
|
|
|
2023-09-13 11:53:59 +01:00
|
|
|
|
2015-06-24 16:58:12 -07:00
|
|
|
|
|
|
|
|
|
2015-11-30 13:28:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-30 18:51:16 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-21 10:09:29 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2015-11-30 13:28:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-13 11:53:59 +01:00
|
|
|
|
2015-11-30 13:28:15 +01:00
|
|
|
|
2015-06-24 16:58:12 -07:00
|
|
|
|
2017-04-03 11:23:54 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2017-04-03 11:23:54 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-13 11:53:59 +01:00
|
|
|
|
2017-04-03 11:23:54 +09:00
|
|
|
|
|
|
|
|
|
2023-09-13 11:54:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-13 16:58:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-11 23:30:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-13 16:58:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-11 23:30:50 -07:00
|
|
|
|
2024-06-14 11:05:43 +03:00
|
|
|
|
2019-03-11 23:30:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
memblock: make for_each_mem_range() traverse MEMBLOCK_HOTPLUG regions
Commit b10d6bca8720 ("arch, drivers: replace for_each_membock() with
for_each_mem_range()") didn't take into account that when there is
movable_node parameter in the kernel command line, for_each_mem_range()
would skip ranges marked with MEMBLOCK_HOTPLUG.
The page table setup code in POWER uses for_each_mem_range() to create
the linear mapping of the physical memory and since the regions marked
as MEMORY_HOTPLUG are skipped, they never make it to the linear map.
A later access to the memory in those ranges will fail:
BUG: Unable to handle kernel data access on write at 0xc000000400000000
Faulting instruction address: 0xc00000000008a3c0
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 0 PID: 53 Comm: kworker/u2:0 Not tainted 5.13.0 #7
NIP: c00000000008a3c0 LR: c0000000003c1ed8 CTR: 0000000000000040
REGS: c000000008a57770 TRAP: 0300 Not tainted (5.13.0)
MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 84222202 XER: 20040000
CFAR: c0000000003c1ed4 DAR: c000000400000000 DSISR: 42000000 IRQMASK: 0
GPR00: c0000000003c1ed8 c000000008a57a10 c0000000019da700 c000000400000000
GPR04: 0000000000000280 0000000000000180 0000000000000400 0000000000000200
GPR08: 0000000000000100 0000000000000080 0000000000000040 0000000000000300
GPR12: 0000000000000380 c000000001bc0000 c0000000001660c8 c000000006337e00
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000040000000 0000000020000000 c000000001a81990 c000000008c30000
GPR24: c000000008c20000 c000000001a81998 000fffffffff0000 c000000001a819a0
GPR28: c000000001a81908 c00c000001000000 c000000008c40000 c000000008a64680
NIP clear_user_page+0x50/0x80
LR __handle_mm_fault+0xc88/0x1910
Call Trace:
__handle_mm_fault+0xc44/0x1910 (unreliable)
handle_mm_fault+0x130/0x2a0
__get_user_pages+0x248/0x610
__get_user_pages_remote+0x12c/0x3e0
get_arg_page+0x54/0xf0
copy_string_kernel+0x11c/0x210
kernel_execve+0x16c/0x220
call_usermodehelper_exec_async+0x1b0/0x2f0
ret_from_kernel_thread+0x5c/0x70
Instruction dump:
79280fa4 79271764 79261f24 794ae8e2 7ca94214 7d683a14 7c893a14 7d893050
7d4903a6 60000000 60000000 60000000 <7c001fec> 7c091fec 7c081fec 7c051fec
---[ end trace 490b8c67e6075e09 ]---
Making for_each_mem_range() include MEMBLOCK_HOTPLUG regions in the
traversal fixes this issue.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1976100
Link: https://lkml.kernel.org/r/20210712071132.20902-1-rppt@kernel.org
Fixes: b10d6bca8720 ("arch, drivers: replace for_each_membock() with for_each_mem_range()")
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Tested-by: Greg Kurz <groug@kaod.org>
Reviewed-by: David Hildenbrand <david@redhat.com>
Cc: <stable@vger.kernel.org> [5.10+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-23 15:50:26 -07:00
|
|
|
|
|
|
|
|
|
2019-03-11 23:30:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
memblock: add MEMBLOCK_DRIVER_MANAGED to mimic IORESOURCE_SYSRAM_DRIVER_MANAGED
Let's add a flag that corresponds to IORESOURCE_SYSRAM_DRIVER_MANAGED,
indicating that we're dealing with a memory region that is never
indicated in the firmware-provided memory map, but always detected and
added by a driver.
Similar to MEMBLOCK_HOTPLUG, most infrastructure has to treat such
memory regions like ordinary MEMBLOCK_NONE memory regions -- for
example, when selecting memory regions to add to the vmcore for dumping
in the crashkernel via for_each_mem_range().
However, especially kexec_file is not supposed to select such memblocks
via for_each_free_mem_range() / for_each_free_mem_range_reverse() to
place kexec images, similar to how we handle
IORESOURCE_SYSRAM_DRIVER_MANAGED without CONFIG_ARCH_KEEP_MEMBLOCK.
We'll make sure that memory hotplug code sets the flag where applicable
(IORESOURCE_SYSRAM_DRIVER_MANAGED) next. This prepares architectures
that need CONFIG_ARCH_KEEP_MEMBLOCK, such as arm64, for virtio-mem
support.
Note that kexec *must not* indicate this memory to the second kernel and
*must not* place kexec-images on this memory. Let's add a comment to
kexec_walk_memblock(), documenting how we handle MEMBLOCK_DRIVER_MANAGED
now just like using IORESOURCE_SYSRAM_DRIVER_MANAGED in
locate_mem_hole_callback() for kexec_walk_resources().
Also note that MEMBLOCK_HOTPLUG cannot be reused due to different
semantics:
MEMBLOCK_HOTPLUG: memory is indicated as "System RAM" in the
firmware-provided memory map and added to the system early during
boot; kexec *has to* indicate this memory to the second kernel and
can place kexec-images on this memory. After memory hotunplug,
kexec has to be re-armed. We mostly ignore this flag when
"movable_node" is not set on the kernel command line, because
then we're told to not care about hotunpluggability of such
memory regions.
MEMBLOCK_DRIVER_MANAGED: memory is not indicated as "System RAM" in
the firmware-provided memory map; this memory is always detected
and added to the system by a driver; memory might not actually be
physically hotunpluggable. kexec *must not* indicate this memory to
the second kernel and *must not* place kexec-images on this memory.
Link: https://lkml.kernel.org/r/20211004093605.5830-5-david@redhat.com
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: Jianyong Wu <Jianyong.Wu@arm.com>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Shahab Vahedi <shahab@synopsys.com>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Vineet Gupta <vgupta@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-05 13:44:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-11 23:30:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:59 +02:00
|
|
|
|
2019-03-11 23:30:54 -07:00
|
|
|
|
2011-07-12 11:15:59 +02:00
|
|
|
|
2014-01-21 15:50:16 -08:00
|
|
|
|
2015-06-24 16:58:09 -07:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
2012-06-20 12:53:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:59 +02:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2011-07-12 11:15:59 +02:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-01 16:18:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:59 +02:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
2014-01-21 15:50:16 -08:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:59 +02:00
|
|
|
|
|
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2011-07-12 11:15:59 +02:00
|
|
|
|
2020-10-13 16:58:25 -07:00
|
|
|
|
2015-11-30 13:28:15 +01:00
|
|
|
|
|
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:59 +02:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-07 17:06:15 -07:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2011-07-12 11:15:59 +02:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:59 +02:00
|
|
|
|
|
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2011-07-12 11:15:59 +02:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
2011-07-12 11:15:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
2015-09-08 15:04:22 -07:00
|
|
|
|
2015-06-24 16:58:09 -07:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
2012-06-20 12:53:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
2018-06-30 17:55:01 +03:00
|
|
|
|
|
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
2014-01-21 15:50:16 -08:00
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2016-08-04 15:32:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
|
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
|
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
2020-10-13 16:58:25 -07:00
|
|
|
|
2015-11-30 13:28:15 +01:00
|
|
|
|
|
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-28 15:48:56 -07:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-07 17:06:15 -07:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
2018-11-16 15:08:57 -08:00
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-03 15:56:53 -07:00
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-03 15:56:53 -07:00
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-14 11:05:43 +03:00
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-03 15:56:53 -07:00
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-21 15:49:26 -08:00
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-21 15:49:26 -08:00
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
2021-06-28 19:43:01 -07:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
2012-10-08 16:32:21 -07:00
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
2023-01-29 17:00:34 +08:00
|
|
|
|
2020-06-03 15:57:02 -07:00
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
|
|
|
|
|
2020-06-03 15:57:02 -07:00
|
|
|
|
2019-05-13 17:21:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-17 22:07:54 +08:00
|
|
|
|
2019-05-13 17:21:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-17 22:07:54 +08:00
|
|
|
|
2019-05-13 17:21:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
2019-03-11 23:29:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-30 17:56:27 -08:00
|
|
|
|
2019-03-11 23:29:41 -07:00
|
|
|
|
|
|
|
|
|
2019-11-30 17:56:24 -08:00
|
|
|
|
2019-03-11 23:29:41 -07:00
|
|
|
|
2019-11-30 17:56:27 -08:00
|
|
|
|
|
|
|
|
|
2019-03-11 23:29:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-11 11:55:48 +08:00
|
|
|
|
|
|
|
|
|
2019-03-11 23:29:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-10 14:32:42 -07:00
|
|
|
|
2014-06-04 16:06:53 -07:00
|
|
|
|
2019-11-30 17:56:27 -08:00
|
|
|
|
|
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2019-03-11 23:29:41 -07:00
|
|
|
|
2010-07-12 14:36:48 +10:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2024-06-19 11:55:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-30 15:10:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-11 23:29:41 -07:00
|
|
|
|
2015-06-24 16:58:09 -07:00
|
|
|
|
|
|
|
|
|
2019-03-11 23:29:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-14 11:05:43 +03:00
|
|
|
|
2019-03-11 23:29:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-14 17:21:53 +08:00
|
|
|
|
2019-03-11 23:29:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-05 11:05:09 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-06 14:38:20 -07:00
|
|
|
|
2022-06-11 11:55:48 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-06 14:38:20 -07:00
|
|
|
|
2022-06-11 11:55:48 +08:00
|
|
|
|
2019-03-11 23:29:41 -07:00
|
|
|
|
2023-06-06 17:26:29 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-09 14:48:51 +03:00
|
|
|
|
2023-06-06 17:26:29 +03:00
|
|
|
|
2019-03-11 23:29:41 -07:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2019-03-11 23:30:54 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-11 23:29:16 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-04 16:06:53 -07:00
|
|
|
|
2020-11-16 10:14:04 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-30 17:56:27 -08:00
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:09 -08:00
|
|
|
|
|
|
|
|
|
2019-03-11 23:30:54 -07:00
|
|
|
|
2021-01-20 21:28:18 +09:00
|
|
|
|
2019-03-11 23:30:54 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
memblock: rename memblock_alloc{_nid,_try_nid} to memblock_phys_alloc*
Make it explicit that the caller gets a physical address rather than a
virtual one.
This will also allow using meblock_alloc prefix for memblock allocations
returning virtual address, which is done in the following patches.
The conversion is done using the following semantic patch:
@@
expression e1, e2, e3;
@@
(
- memblock_alloc(e1, e2)
+ memblock_phys_alloc(e1, e2)
|
- memblock_alloc_nid(e1, e2, e3)
+ memblock_phys_alloc_nid(e1, e2, e3)
|
- memblock_alloc_try_nid(e1, e2, e3)
+ memblock_phys_alloc_try_nid(e1, e2, e3)
)
Link: http://lkml.kernel.org/r/1536927045-23536-7-git-send-email-rppt@linux.vnet.ibm.com
Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chris Zankel <chris@zankel.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Greentime Hu <green.hu@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Guan Xuetao <gxt@pku.edu.cn>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Jonas Bonn <jonas@southpole.se>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Ley Foon Tan <lftan@altera.com>
Cc: Mark Salter <msalter@redhat.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Palmer Dabbelt <palmer@sifive.com>
Cc: Paul Burton <paul.burton@mips.com>
Cc: Richard Kuo <rkuo@codeaurora.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: Rich Felker <dalias@libc.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Serge Semin <fancer.lancer@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-10-30 15:07:59 -07:00
|
|
|
|
2010-07-06 15:39:17 -07:00
|
|
|
|
2019-03-11 23:29:21 -07:00
|
|
|
|
2019-11-30 17:56:27 -08:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
2018-10-30 15:08:04 -07:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-30 17:56:27 -08:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
2019-03-11 23:29:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
2019-03-11 23:29:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
|
|
|
|
|
2018-10-30 15:08:04 -07:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
|
|
|
|
|
2019-11-30 17:56:27 -08:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-18 20:20:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-30 17:56:27 -08:00
|
|
|
|
|
|
|
|
|
2018-10-30 15:10:01 -07:00
|
|
|
|
2019-03-11 23:29:41 -07:00
|
|
|
|
|
|
|
|
|
2019-11-30 17:56:27 -08:00
|
|
|
|
|
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
2019-03-11 23:29:41 -07:00
|
|
|
|
|
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
2019-03-11 23:29:41 -07:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
|
|
|
|
|
2019-11-30 17:56:27 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-02 14:58:05 -07:00
|
|
|
|
|
|
|
|
|
2019-11-30 17:56:27 -08:00
|
|
|
|
|
|
|
|
|
2017-11-15 17:36:27 -08:00
|
|
|
|
2018-10-30 15:08:04 -07:00
|
|
|
|
2017-11-15 17:36:27 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-30 15:09:44 -07:00
|
|
|
|
2017-11-15 17:36:27 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2017-11-15 17:36:27 -08:00
|
|
|
|
|
|
|
|
|
2018-10-30 15:08:04 -07:00
|
|
|
|
2017-11-15 17:36:27 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-25 21:32:28 +02:00
|
|
|
|
2018-08-17 15:47:17 -07:00
|
|
|
|
|
|
|
|
|
2017-11-15 17:36:27 -08:00
|
|
|
|
2021-09-02 14:58:05 -07:00
|
|
|
|
|
|
|
|
|
2017-11-15 17:36:27 -08:00
|
|
|
|
|
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
2019-03-11 23:30:37 -07:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-30 15:09:44 -07:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-11 23:30:37 -07:00
|
|
|
|
|
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
|
|
|
|
|
2018-10-30 15:08:04 -07:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-25 21:32:28 +02:00
|
|
|
|
2018-08-17 15:47:17 -07:00
|
|
|
|
|
|
|
|
|
2018-10-30 15:08:04 -07:00
|
|
|
|
2019-11-30 17:56:27 -08:00
|
|
|
|
2019-03-11 23:30:37 -07:00
|
|
|
|
2017-11-15 17:36:27 -08:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
2019-03-11 23:30:37 -07:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:03 +03:00
|
|
|
|
2021-11-05 13:43:16 -07:00
|
|
|
|
2018-06-30 17:55:03 +03:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
|
|
|
|
|
2019-03-11 23:30:54 -07:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
2019-03-11 23:30:54 -07:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
2021-11-05 13:43:16 -07:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
2018-08-17 15:47:17 -07:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
2018-08-17 15:47:17 -07:00
|
|
|
|
2019-03-25 21:32:28 +02:00
|
|
|
|
2018-08-17 15:47:17 -07:00
|
|
|
|
2016-10-11 13:55:11 -07:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-07 08:21:51 +00:00
|
|
|
|
2018-12-28 00:34:29 -08:00
|
|
|
|
2014-01-21 15:50:19 -08:00
|
|
|
|
|
|
|
|
|
2010-07-06 15:39:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-05 15:36:19 -08:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2011-12-08 10:22:08 -08:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2016-10-07 16:59:18 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-08 00:14:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-31 17:08:16 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-28 15:43:02 +10:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-04 14:06:41 +10:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2016-07-28 15:48:26 -07:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2018-06-07 17:06:15 -07:00
|
|
|
|
2014-04-07 15:37:52 -07:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2016-07-28 15:48:26 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-07 17:06:15 -07:00
|
|
|
|
2016-07-28 15:48:26 -07:00
|
|
|
|
2020-10-13 16:58:30 -07:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2016-07-28 15:48:26 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-01 21:11:01 -07:00
|
|
|
|
2016-07-28 15:48:26 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-07 17:06:15 -07:00
|
|
|
|
2016-07-28 15:48:26 -07:00
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2018-06-07 17:06:15 -07:00
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2018-06-07 17:06:15 -07:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2017-04-03 11:23:55 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-18 15:15:45 -07:00
|
|
|
|
2021-08-11 10:55:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-03 11:23:55 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-07 17:06:15 -07:00
|
|
|
|
2017-04-03 11:23:55 +09:00
|
|
|
|
|
|
|
|
|
2016-07-28 15:48:26 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-07 17:06:15 -07:00
|
|
|
|
2016-07-28 15:48:26 -07:00
|
|
|
|
|
|
|
|
|
2017-04-03 11:23:55 +09:00
|
|
|
|
2016-07-28 15:48:26 -07:00
|
|
|
|
|
|
|
|
|
2010-10-11 12:34:09 -07:00
|
|
|
|
2010-08-04 14:38:47 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-14 14:17:06 -08:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2010-08-04 14:38:47 +10:00
|
|
|
|
|
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2016-01-14 15:18:54 -08:00
|
|
|
|
2010-08-04 14:38:47 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-06 15:41:18 -08:00
|
|
|
|
2015-11-30 13:28:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-11 14:22:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-07 15:37:53 -07:00
|
|
|
|
2013-09-11 14:22:17 -07:00
|
|
|
|
|
|
|
|
|
2023-12-07 21:10:01 +08:00
|
|
|
|
2013-09-11 14:22:17 -07:00
|
|
|
|
2014-06-04 16:07:51 -07:00
|
|
|
|
|
|
|
|
|
2013-09-11 14:22:17 -07:00
|
|
|
|
2020-06-03 15:56:53 -07:00
|
|
|
|
2013-09-11 14:22:17 -07:00
|
|
|
|
|
|
|
|
|
2012-05-24 00:45:21 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2012-05-24 00:45:21 -07:00
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2012-05-24 00:45:21 -07:00
|
|
|
|
|
|
|
|
|
2018-02-06 15:41:18 -08:00
|
|
|
|
2010-08-04 14:38:47 +10:00
|
|
|
|
2011-01-20 14:44:20 -08:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
2010-08-04 14:38:47 +10:00
|
|
|
|
|
|
|
|
|
2018-02-06 15:41:18 -08:00
|
|
|
|
2017-02-22 15:45:04 -08:00
|
|
|
|
2011-12-08 10:22:07 -08:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2012-05-24 00:45:21 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
|
|
|
|
|
2012-05-24 00:45:21 -07:00
|
|
|
|
2018-06-30 17:55:02 +03:00
|
|
|
|
2015-09-08 15:02:00 -07:00
|
|
|
|
2012-05-24 00:45:21 -07:00
|
|
|
|
2015-09-08 15:02:00 -07:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
2015-09-08 15:02:00 -07:00
|
|
|
|
2010-07-12 14:36:09 +10:00
|
|
|
|
|
|
|
|
|
2012-10-22 16:35:18 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-07 15:37:52 -07:00
|
|
|
|
2012-10-22 16:35:18 -07:00
|
|
|
|
2020-10-13 16:58:30 -07:00
|
|
|
|
2014-04-07 15:37:52 -07:00
|
|
|
|
|
|
|
|
|
2012-10-22 16:35:18 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-07 15:37:52 -07:00
|
|
|
|
|
|
|
|
|
2012-10-22 16:35:18 -07:00
|
|
|
|
2014-04-07 15:37:52 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-22 16:35:18 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-06 15:39:01 -07:00
|
|
|
|
2010-09-15 13:05:29 -07:00
|
|
|
|
2010-07-06 15:39:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-27 01:23:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-24 14:55:59 -08:00
|
|
|
|
2010-07-12 14:36:48 +10:00
|
|
|
|
2017-02-22 15:46:42 -08:00
|
|
|
|
2018-06-30 17:55:01 +03:00
|
|
|
|
2016-01-14 15:20:42 -08:00
|
|
|
|
|
|
|
|
|
2010-07-12 14:36:48 +10:00
|
|
|
|
2017-02-24 14:55:59 -08:00
|
|
|
|
2010-07-12 14:36:48 +10:00
|
|
|
|
2017-11-15 17:33:42 -08:00
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
2010-07-12 14:36:48 +10:00
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
|
|
|
|
|
2017-02-22 15:46:42 -08:00
|
|
|
|
2014-01-21 15:49:20 -08:00
|
|
|
|
2021-06-28 19:43:01 -07:00
|
|
|
|
2024-06-14 11:05:43 +03:00
|
|
|
|
2011-07-14 11:43:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-30 17:55:01 +03:00
|
|
|
|
2017-02-24 14:55:59 -08:00
|
|
|
|
2010-07-12 14:36:48 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-13 16:57:54 -07:00
|
|
|
|
2010-07-12 14:36:48 +10:00
|
|
|
|
|
|
|
|
|
2017-02-22 15:46:42 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-12 14:36:48 +10:00
|
|
|
|
2017-02-24 14:55:59 -08:00
|
|
|
|
|
|
|
|
|
2017-02-24 14:55:56 -08:00
|
|
|
|
2020-07-01 16:18:29 +02:00
|
|
|
|
2017-02-24 14:55:56 -08:00
|
|
|
|
2010-07-12 14:36:48 +10:00
|
|
|
|
|
|
|
|
|
2020-10-13 16:57:54 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 10:22:08 -08:00
|
|
|
|
2010-07-12 14:36:48 +10:00
|
|
|
|
2010-07-06 15:39:13 -07:00
|
|
|
|
2010-07-12 14:36:48 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-14 19:09:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-07 07:58:32 +00:00
|
|
|
|
2020-12-14 19:09:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-05 13:43:19 -07:00
|
|
|
|
2020-12-14 19:09:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-17 21:15:15 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-14 19:09:59 -08:00
|
|
|
|
2022-09-07 14:08:42 +08:00
|
|
|
|
2020-12-14 19:09:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-17 21:15:15 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-14 19:09:59 -08:00
|
|
|
|
2022-09-07 14:08:43 +08:00
|
|
|
|
2020-12-14 19:09:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-17 21:31:59 +03:00
|
|
|
|
2022-09-07 14:08:43 +08:00
|
|
|
|
2020-12-14 19:09:59 -08:00
|
|
|
|
2021-05-17 21:31:59 +03:00
|
|
|
|
2020-12-14 19:09:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-30 15:09:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-06 10:25:29 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-28 17:47:04 +03:00
|
|
|
|
|
|
|
|
|
2023-04-06 10:25:29 +03:00
|
|
|
|
|
|
|
|
|
2023-12-28 17:47:04 +03:00
|
|
|
|
2023-04-06 10:25:29 +03:00
|
|
|
|
2023-12-28 17:47:04 +03:00
|
|
|
|
2018-10-30 15:09:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-30 18:51:16 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-19 10:34:06 +08:00
|
|
|
|
2025-03-18 07:19:47 +00:00
|
|
|
|
2023-06-19 10:34:06 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-03-18 07:19:47 +00:00
|
|
|
|
|
|
|
|
|
2023-06-19 10:34:06 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-03-18 07:19:46 +00:00
|
|
|
|
2023-06-19 10:34:06 +08:00
|
|
|
|
2025-03-18 07:19:47 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-30 18:51:16 -07:00
|
|
|
|
2023-09-13 11:54:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-19 10:34:06 +08:00
|
|
|
|
2023-09-13 11:54:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-30 18:51:16 -07:00
|
|
|
|
2024-06-14 11:05:43 +03:00
|
|
|
|
2024-01-18 14:18:53 +08:00
|
|
|
|
|
|
|
|
|
2023-09-13 11:54:00 +01:00
|
|
|
|
|
|
|
|
|
2021-06-30 18:51:16 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-30 15:09:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-30 18:51:16 -07:00
|
|
|
|
2018-10-30 15:09:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-07 02:45:48 +00:00
|
|
|
|
2018-10-30 15:09:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-28 00:34:24 -08:00
|
|
|
|
2018-10-30 15:09:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-14 16:08:17 +09:00
|
|
|
|
2018-10-30 15:09:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-14 19:09:59 -08:00
|
|
|
|
2018-10-30 15:09:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-28 00:34:29 -08:00
|
|
|
|
2018-10-30 15:09:40 -07:00
|
|
|
|
|
|
|
|
|
2024-06-13 11:55:07 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-05-13 17:22:59 -07:00
|
|
|
|
2023-05-19 18:53:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-09 08:39:12 +05:30
|
|
|
|
2023-05-19 18:53:21 +08:00
|
|
|
|
2010-07-06 15:39:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-01 21:31:49 +08:00
|
|
|
|
2023-05-19 18:53:21 +08:00
|
|
|
|
2017-02-22 15:46:42 -08:00
|
|
|
|
2010-07-06 15:39:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-22 15:46:42 -08:00
|
|
|
|
2023-06-01 21:31:49 +08:00
|
|
|
|
2010-07-06 15:39:19 -07:00
|
|
|
|
2017-02-22 15:46:42 -08:00
|
|
|
|
2023-05-19 18:53:21 +08:00
|
|
|
|
2024-06-14 11:05:43 +03:00
|
|
|
|
2023-06-01 21:31:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-19 18:53:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-06 15:39:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-04-05 16:23:16 -07:00
|
|
|
|
2010-07-06 15:39:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-05 15:46:09 -08:00
|
|
|
|
2018-06-14 15:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2020-07-01 16:18:29 +02:00
|
|
|
|
|
|
|
|
|
2014-01-29 18:16:01 +01:00
|
|
|
|
2010-07-06 15:39:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
