sk
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
Signed-off-by: Yunsheng Lin
---
arch/powerpc/include/asm/topology.h | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/topology.h
b/arch/powerpc/include/asm/topo
sk
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
Signed-off-by: Yunsheng Lin
---
arch/x86/include/asm/topology.h | 6 ++
arch/x86/mm/numa.c | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/topology.h b/ar
u_online_mask
3. if hub_data(node) is NULL, return cpu_online_mask
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
Signed-off-by: Yunsheng Lin
---
arch/mips/include/asm/mach-loongson64/topology.h | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff
p[node_id] is NULL, return cpu_online_mask
Signed-off-by: Yunsheng Lin
---
arch/arm64/include/asm/numa.h | 6 ++
arch/arm64/mm/numa.c | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 626ad01..65a0e
On 2019/8/31 16:55, Peter Zijlstra wrote:
> On Sat, Aug 31, 2019 at 01:58:16PM +0800, Yunsheng Lin wrote:
>> According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
>> of proximity domain is optional, as below:
>>
>> This optional object is used t
ne_mask
3. if hub_data(node) is NULL, return cpu_online_mask
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
Signed-off-by: Yunsheng Lin
---
arch/mips/include/asm/mach-ip27/topology.h | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/mip
sk
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
Signed-off-by: Yunsheng Lin
---
Note node_to_cpumask_map[node] is already a pointer, so
returning _to_cpumask_map[node] does not seem to
be correct, if this is problem, maybe clean it up in another
patch.
---
arch/s390/i
e_mask
3. if node_to_cpumask_map[node_id] is NULL, return cpu_online_mask
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
Signed-off-by: Yunsheng Lin
---
arch/sh/include/asm/topology.h | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git
On 2019/8/31 14:53, David Miller wrote:
> From: Yunsheng Lin
> Date: Sat, 31 Aug 2019 13:58:21 +0800
>
>> According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
>> of proximity domain is optional, as below:
>
> What in the world does the ACPI spec have to do
to
other arches as well.
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
[2] https://patchwork.kernel.org/patch/11122823/
Yunsheng Lin (9):
arm64: numa: check the node id consistently for arm64
x86: numa: check the node id consistently for x86
alpha: numa
omment
is added to indicate that
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
Signed-off-by: Yunsheng Lin
---
arch/sparc/include/asm/topology_64.h | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/sparc/include/asm/topology_64.h
sk
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
Signed-off-by: Yunsheng Lin
---
note node_to_cpumask_map[node] is already a pointer, so the
cpumask_clear should be called with node_to_cpumask_map[node]
instead of _to_cpumask_map[node]? And cpumask_of_node()
functio
On 2019/9/2 20:56, Peter Zijlstra wrote:
> On Mon, Sep 02, 2019 at 08:25:24PM +0800, Yunsheng Lin wrote:
>> On 2019/9/2 15:25, Peter Zijlstra wrote:
>>> On Mon, Sep 02, 2019 at 01:46:51PM +0800, Yunsheng Lin wrote:
>>>> On 2019/9/1 0:12, Peter Zijlstra wr
On 2019/9/3 15:11, Peter Zijlstra wrote:
> On Tue, Sep 03, 2019 at 02:19:04PM +0800, Yunsheng Lin wrote:
>> On 2019/9/2 20:56, Peter Zijlstra wrote:
>>> On Mon, Sep 02, 2019 at 08:25:24PM +0800, Yunsheng Lin wrote:
>>>> On 2019/9/2 15:25, Peter Zijlstra wrote:
>&
On 2019/9/1 0:12, Peter Zijlstra wrote:
> On Sat, Aug 31, 2019 at 06:09:39PM +0800, Yunsheng Lin wrote:
>>
>>
>> On 2019/8/31 16:55, Peter Zijlstra wrote:
>>> On Sat, Aug 31, 2019 at 01:58:16PM +0800, Yunsheng Lin wrote:
>>>> According to Section
On 2019/8/31 23:45, Paul Burton wrote:
> Hi Yunsheng,
>
> On Sat, Aug 31, 2019 at 01:58:22PM +0800, Yunsheng Lin wrote:
>> According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
>> of proximity domain is optional, as below:
>>
>> This optional object is
On 2019/9/1 4:02, David Miller wrote:
> From: Yunsheng Lin
> Date: Sat, 31 Aug 2019 16:57:04 +0800
>
>> Did you mean sparc64 system does not has ACPI, the device's node id will
>> not specified by ACPI, so the ACPI is unrelated here?
>
> Yes, sparc64 never h
On 2019/9/2 15:25, Peter Zijlstra wrote:
> On Mon, Sep 02, 2019 at 01:46:51PM +0800, Yunsheng Lin wrote:
>> On 2019/9/1 0:12, Peter Zijlstra wrote:
>
>>> 1) because even it is not set, the device really does belong to a node.
>>> It is impossible a device will have
n "bug" since it is for debugging and should catch all the error
cases.
[1] https://lore.kernel.org/patchwork/patch/1125789/
Signed-off-by: Yunsheng Lin
Suggested-by: Michal Hocko
---
V3: Change to only handle NUMA_NO_NODE, and return cpu_online_mask
for NUMA_NO_NODE case, and change the commi
we really
want to return cpu_online_mask for NUMA_NO_NODE.
Since this arch was already NUMA_NO_NODE aware, this patch only changes
it to return cpu_online_mask and use NUMA_NO_NODE instead of "-1".
[1] https://lore.kernel.org/patchwork/patch/1125789/
Signed-off-by: Yunsheng Lin
Suggest
we really
want to return cpu_online_mask for NUMA_NO_NODE.
[1] https://lore.kernel.org/patchwork/patch/1125789/
Signed-off-by: Yunsheng Lin
Suggested-by: Michal Hocko
---
V3: Change to only handle NUMA_NO_NODE, and return cpu_online_mask
for NUMA_NO_NODE case, and change the commit log to bet
we really
want to return cpu_online_mask for NUMA_NO_NODE.
[1] https://lore.kernel.org/patchwork/patch/1125789/
Signed-off-by: Yunsheng Lin
Suggested-by: Michal Hocko
---
V3: Change to only handle NUMA_NO_NODE, and return cpu_online_mask
for NUMA_NO_NODE case, and change the commit log to bet
we really
want to return cpu_online_mask for NUMA_NO_NODE.
Since this arch was already NUMA_NO_NODE aware, this patch only changes
it to return cpu_online_mask and use NUMA_NO_NODE instead of "-1".
[1] https://lore.kernel.org/patchwork/patch/1125789/
Signed-off-by: Yunsheng Lin
Suggest
we really
want to return cpu_online_mask for NUMA_NO_NODE.
Since this arch was already NUMA_NO_NODE aware, this patch only changes
it to return cpu_online_mask.
[1] https://lore.kernel.org/patchwork/patch/1125789/
Signed-off-by: Yunsheng Lin
Suggested-by: Michal Hocko
---
V3: Change to only han
ustify
the change, drop sh arch change since it always return cpu_online_mask.
Yunsheng Lin (8):
arm64: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for arm64
x86: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for x86
alpha: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for
we really
want to return cpu_online_mask for NUMA_NO_NODE.
Since this arch was already NUMA_NO_NODE aware, this patch only changes
it to return cpu_online_mask and use NUMA_NO_NODE instead of "-1".
[1] https://lore.kernel.org/patchwork/patch/1125789/
Signed-off-by: Yunsheng Lin
Suggest
n "bug" since it is for debugging and should catch all the error
cases.
[1] https://lore.kernel.org/patchwork/patch/1125789/
Signed-off-by: Yunsheng Lin
Suggested-by: Michal Hocko
---
V3: Change to only handle NUMA_NO_NODE, and return cpu_online_mask
for NUMA_NO_NODE case, and change the commi
nly used when CONFIG_DEBUG_PER_CPU_MAPS is defined, this
patch changes it to handle NUMA_NO_NODE as normal node_to_cpumask_map().
And "fix" a sign "bug" since it is for debugging and should catch all the
error cases.
[1] https://lore.kernel.org/patchwork/patch/1125789/
Signed-off-by: Yunshen
On 2019/9/15 13:49, Mike Rapoport wrote:
> Hi,
>
> On Thu, Sep 12, 2019 at 06:15:33PM +0800, Yunsheng Lin wrote:
>> When passing the return value of dev_to_node() to cpumask_of_node()
>> without checking the node id if the node id is NUMA_NO_NODE, there is
>> gl
On 2019/9/15 14:46, Mike Rapoport wrote:
> On Sun, Sep 15, 2019 at 02:13:51PM +0800, Yunsheng Lin wrote:
>> On 2019/9/15 13:49, Mike Rapoport wrote:
>>> Hi,
>>>
>>> On Thu, Sep 12, 2019 at 06:15:33PM +0800, Yunsheng Lin wrote:
>>>> When passing the
On 2019/9/17 13:28, Michael Ellerman wrote:
> Yunsheng Lin writes:
>> When passing the return value of dev_to_node() to cpumask_of_node()
>> without checking if the device's node id is NUMA_NO_NODE, there is
>> global-out-of-bounds detected by KASAN.
>>
>> From
On 2019/9/17 17:36, Michal Hocko wrote:
> On Tue 17-09-19 14:20:11, Yunsheng Lin wrote:
>> On 2019/9/17 13:28, Michael Ellerman wrote:
>>> Yunsheng Lin writes:
> [...]
>>>> But we cannot really copy the page allocator logic. Simply because the
>>>>
On 2019/9/17 18:08, Michal Hocko wrote:
> On Tue 17-09-19 17:53:57, Yunsheng Lin wrote:
>> On 2019/9/17 17:36, Michal Hocko wrote:
>>> On Tue 17-09-19 14:20:11, Yunsheng Lin wrote:
>>>> On 2019/9/17 13:28, Michael Ellerman wrote:
>>>>> Yunsheng Lin
org/patchwork/patch/1125789/
Signed-off-by: Yunsheng Lin
Suggested-by: Michal Hocko
Acked-by: Michal Hocko
---
V6: Drop the cpu_all_mask -> cpu_online_mask change for it seems a
little controversial, may need deeper investigation, and rebased
on the latest linux-next.
V5: Drop unsigne
On 2019/9/16 16:43, Michal Hocko wrote:
> On Sun 15-09-19 16:20:56, Yunsheng Lin wrote:
>> When passing the return value of dev_to_node() to cpumask_of_node()
>> without checking if the device's node id is NUMA_NO_NODE, there is
>> global-out-of-bounds detected by KASAN.
>&
On 2019/9/16 20:23, Michal Hocko wrote:
> On Mon 16-09-19 20:07:22, Yunsheng Lin wrote:
> [...]
>>>> @@ -861,9 +861,12 @@ void numa_remove_cpu(int cpu)
>>>> */
>>>> const struct cpumask *cpumask_of_node(int node)
>>>> {
>>>&
org/patchwork/patch/1125789/
Signed-off-by: Yunsheng Lin
Suggested-by: Michal Hocko
Acked-by: Michal Hocko
---
V5: Drop unsigned "fix" change for x86/arm64, and change comment log
according to Michal's comment.
V4: Have all these changes in a single patch.
V3: Change to only handle N
On 2019/9/24 17:25, Peter Zijlstra wrote:
> On Tue, Sep 24, 2019 at 09:29:50AM +0800, Yunsheng Lin wrote:
>> On 2019/9/24 4:34, Peter Zijlstra wrote:
>
>>> I'm saying the ACPI standard is wrong. Explain to me how it is
>>> physically possible to have a device w
On 2019/9/24 19:28, Peter Zijlstra wrote:
> On Tue, Sep 24, 2019 at 07:07:36PM +0800, Yunsheng Lin wrote:
>> On 2019/9/24 17:25, Peter Zijlstra wrote:
>>> On Tue, Sep 24, 2019 at 09:29:50AM +0800, Yunsheng Lin wrote:
>>>> On 2019/9/24 4:34, Peter Zijlstra wrote:
On 2019/9/24 19:58, Peter Zijlstra wrote:
> On Tue, Sep 24, 2019 at 07:44:28PM +0800, Yunsheng Lin wrote:
>> From [1], there is a lot of devices with node id of NUMA_NO_NODE with the
>> FW_BUG.
>>
>> [1]
>> https://lore.kernel.org/lkml/5a188e2b-6c07-a9db-fbaa
plain about it.
>
>> Because as to NUMA_NO_NODE I believe this makes sense because this is
>> the only way that a device is not bound to any numa node.
>
> Which is a physical impossibility.
>
>> I even the
>> ACPI standard is considering this optional. Yunsheng
kml/2019/9/11/66
Signed-off-by: Yunsheng Lin
Suggested-by: Michal Hocko
Acked-by: Michal Hocko
Acked-by: Paul Burton # MIPS bits
---
V7: replace -1 with NUMA_NO_NODE for mips ip27 as suggested by Paul.
V6: Drop the cpu_all_mask -> cpu_online_mask change for it seems a
little controversia
On 2019/10/30 18:14, Peter Zijlstra wrote:
> On Wed, Oct 30, 2019 at 05:34:28PM +0800, Yunsheng Lin wrote:
>> When passing the return value of dev_to_node() to cpumask_of_node()
>> without checking if the device's node id is NUMA_NO_NODE, there is
>> global-out-of-bou
On 2019/10/12 15:40, Greg KH wrote:
> On Sat, Oct 12, 2019 at 02:17:26PM +0800, Yunsheng Lin wrote:
>> add pci and acpi maintainer
>> cc linux-...@vger.kernel.org and linux-a...@vger.kernel.org
>>
>> On 2019/10/11 19:15, Peter Zijlstra wrote:
>>> On Fri, Oct 11
On 2019/10/16 0:58, Greg KH wrote:
> On Tue, Oct 15, 2019 at 06:40:29PM +0800, Yunsheng Lin wrote:
>> On 2019/10/14 17:25, Greg KH wrote:
>>> On Mon, Oct 14, 2019 at 04:00:46PM +0800, Yunsheng Lin wrote:
>>>> On 2019/10/12 18:47, Greg KH wrote:
>>>>> O
On 2019/10/14 17:25, Greg KH wrote:
> On Mon, Oct 14, 2019 at 04:00:46PM +0800, Yunsheng Lin wrote:
>> On 2019/10/12 18:47, Greg KH wrote:
>>> On Sat, Oct 12, 2019 at 12:40:01PM +0200, Greg KH wrote:
>>>> On Sat, Oct 12, 2019 at 05:47:56PM +0800, Yunsheng Lin wrote:
&
On 2019/10/29 16:53, Michal Hocko wrote:
> On Mon 28-10-19 17:20:33, Yunsheng Lin wrote:
>> On 2019/10/12 15:40, Greg KH wrote:
>>> On Sat, Oct 12, 2019 at 02:17:26PM +0800, Yunsheng Lin wrote:
>>>> add pci and acpi maintainer
>>>> cc linux-...@vger
On 2019/9/22 6:38, Paul Burton wrote:
> Hi Yunsheng,
>
> On Tue, Sep 17, 2019 at 08:48:54PM +0800, Yunsheng Lin wrote:
>> When passing the return value of dev_to_node() to cpumask_of_node()
>> without checking if the device's node id is NUMA_NO_NODE, there is
>> gl
On 2019/9/24 21:19, Michal Hocko wrote:
> On Tue 24-09-19 14:59:36, Peter Zijlstra wrote:
>> On Tue, Sep 24, 2019 at 02:43:25PM +0200, Peter Zijlstra wrote:
>>> On Tue, Sep 24, 2019 at 02:25:00PM +0200, Michal Hocko wrote:
On Tue 24-09-19 14:09:43, Peter Zijlstra wrote:
>>>
> We can push
On 2019/9/25 18:41, Peter Zijlstra wrote:
> On Wed, Sep 25, 2019 at 05:14:20PM +0800, Yunsheng Lin wrote:
>> From the discussion above, It seems making the node_to_cpumask_map()
>> NUMA_NO_NODE aware is the most feasible way to move forwad.
>
> That's still wrong.
Hi, Pet
On 2019/10/9 20:25, Robin Murphy wrote:
> On 2019-10-08 9:38 am, Yunsheng Lin wrote:
>> On 2019/9/25 18:41, Peter Zijlstra wrote:
>>> On Wed, Sep 25, 2019 at 05:14:20PM +0800, Yunsheng Lin wrote:
>>>> From the discussion above, It seems making the node_to_cpumask
On 2019/10/10 15:32, Michal Hocko wrote:
> On Thu 10-10-19 14:07:21, Yunsheng Lin wrote:
>> On 2019/10/9 20:25, Robin Murphy wrote:
>>> On 2019-10-08 9:38 am, Yunsheng Lin wrote:
>>>> On 2019/9/25 18:41, Peter Zijlstra wrote:
>>>>> On Wed, Sep 25,
add pci and acpi maintainer
cc linux-...@vger.kernel.org and linux-a...@vger.kernel.org
On 2019/10/11 19:15, Peter Zijlstra wrote:
> On Fri, Oct 11, 2019 at 11:27:54AM +0800, Yunsheng Lin wrote:
>> But I failed to see why the above is related to making node_to_cpumask_map()
>> NUM
On 2019/10/12 15:40, Greg KH wrote:
> On Sat, Oct 12, 2019 at 02:17:26PM +0800, Yunsheng Lin wrote:
>> add pci and acpi maintainer
>> cc linux-...@vger.kernel.org and linux-a...@vger.kernel.org
>>
>> On 2019/10/11 19:15, Peter Zijlstra wrote:
>>> On Fri, Oct 11
On 2019/10/12 18:47, Greg KH wrote:
> On Sat, Oct 12, 2019 at 12:40:01PM +0200, Greg KH wrote:
>> On Sat, Oct 12, 2019 at 05:47:56PM +0800, Yunsheng Lin wrote:
>>> On 2019/10/12 15:40, Greg KH wrote:
>>>> On Sat, Oct 12, 2019 at 02:17:26PM +0800, Yunsheng Lin
On 2020/11/29 3:36, Jakub Kicinski wrote:
> On Sat, 28 Nov 2020 16:20:54 +1100 Stephen Rothwell wrote:
>> On Fri, 27 Nov 2020 17:56:42 -0800 Jakub Kicinski wrote:
>>>
>>> What's the offending structure in hisilicon? I'd rather have a look
>>> packing structs with pointers in 'em sounds
On 2020/11/28 9:56, Jakub Kicinski wrote:
> On Sat, 28 Nov 2020 12:28:19 +1100 Stephen Rothwell wrote:
>> There are 2 drivers that have arrays of packed structures that contain
>> pointers that end up at unaligned offsets. These produce warnings in
>> the PowerPC allyesconfig build like this:
>>
57 matches
Mail list logo
