* [PATCH -next] irqdomain: fix overflow error
@ 2021-09-08 1:46 Bixuan Cui
2021-09-14 11:56 ` Thomas Gleixner
0 siblings, 1 reply; 6+ messages in thread
From: Bixuan Cui @ 2021-09-08 1:46 UTC (permalink / raw)
To: linux-kernel; +Cc: maz, tglx, john.wanghui
In function ‘kmalloc_node’,
inlined from ‘kzalloc_node.constprop’ at ./include/linux/slab.h:743:9,
inlined from ‘__irq_domain_add’ at kernel/irq/irqdomain.c:153:9:
./include/linux/slab.h:618:9: error: argument 1 value ‘18446744073709551615’ exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=]
return __kmalloc_node(size, flags, node);
The 'size' can be negative here, which will then get turned into a giant
size argument for kzalloc_node(). Changing the size to 'unsigned int'
instead seems more appropriate.
Signed-off-by: Bixuan Cui <cuibixuan@huawei.com>
---
include/linux/irqdomain.h | 2 +-
kernel/irq/irqdomain.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 23e4ee523576..9ee238ad29ce 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -251,7 +251,7 @@ static inline struct fwnode_handle *irq_domain_alloc_fwnode(phys_addr_t *pa)
}
void irq_domain_free_fwnode(struct fwnode_handle *fwnode);
-struct irq_domain *__irq_domain_add(struct fwnode_handle *fwnode, int size,
+struct irq_domain *__irq_domain_add(struct fwnode_handle *fwnode, unsigned int size,
irq_hw_number_t hwirq_max, int direct_max,
const struct irq_domain_ops *ops,
void *host_data);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 19e83e9b723c..4d8fc65cf38f 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -136,7 +136,7 @@ EXPORT_SYMBOL_GPL(irq_domain_free_fwnode);
* Allocates and initializes an irq_domain structure.
* Returns pointer to IRQ domain, or NULL on failure.
*/
-struct irq_domain *__irq_domain_add(struct fwnode_handle *fwnode, int size,
+struct irq_domain *__irq_domain_add(struct fwnode_handle *fwnode, unsigned int size,
irq_hw_number_t hwirq_max, int direct_max,
const struct irq_domain_ops *ops,
void *host_data)
--
2.17.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH -next] irqdomain: fix overflow error 2021-09-08 1:46 [PATCH -next] irqdomain: fix overflow error Bixuan Cui @ 2021-09-14 11:56 ` Thomas Gleixner 2021-09-15 2:03 ` Bixuan Cui 0 siblings, 1 reply; 6+ messages in thread From: Thomas Gleixner @ 2021-09-14 11:56 UTC (permalink / raw) To: Bixuan Cui, linux-kernel; +Cc: maz, john.wanghui On Wed, Sep 08 2021 at 09:46, Bixuan Cui wrote: > In function ‘kmalloc_node’, > inlined from ‘kzalloc_node.constprop’ at ./include/linux/slab.h:743:9, > inlined from ‘__irq_domain_add’ at kernel/irq/irqdomain.c:153:9: > ./include/linux/slab.h:618:9: error: argument 1 value ‘18446744073709551615’ exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=] > return __kmalloc_node(size, flags, node); > > The 'size' can be negative here, which will then get turned into a giant > size argument for kzalloc_node(). Changing the size to 'unsigned int' > instead seems more appropriate. What's more appropriate about that? Thanks, tglx ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH -next] irqdomain: fix overflow error 2021-09-14 11:56 ` Thomas Gleixner @ 2021-09-15 2:03 ` Bixuan Cui 2021-09-15 7:49 ` Thomas Gleixner 0 siblings, 1 reply; 6+ messages in thread From: Bixuan Cui @ 2021-09-15 2:03 UTC (permalink / raw) To: Thomas Gleixner, linux-kernel; +Cc: maz, john.wanghui On 2021/9/14 19:56, Thomas Gleixner wrote: > On Wed, Sep 08 2021 at 09:46, Bixuan Cui wrote: >> In function ‘kmalloc_node’, >> inlined from ‘kzalloc_node.constprop’ at ./include/linux/slab.h:743:9, >> inlined from ‘__irq_domain_add’ at kernel/irq/irqdomain.c:153:9: >> ./include/linux/slab.h:618:9: error: argument 1 value ‘18446744073709551615’ exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=] >> return __kmalloc_node(size, flags, node); >> >> The 'size' can be negative here, which will then get turned into a giant >> size argument for kzalloc_node(). Changing the size to 'unsigned int' >> instead seems more appropriate. > What's more appropriate about that? We call struct_size(domain, revmap, size) in __irq_domain_add() for calculations. The struct_size() is implemented in include/linux/overflow.h static inline __must_check size_t __ab_c_size(size_t a, size_t b, size_t c) { size_t bytes; The 'size' is passed to __ab_c_size(), the input parameter is 'size_t'(unsigned int). On the other hand, I looked at all the code that calls __irq_domain_add(), such as: include/linux/irqdomain.h: static inline struct irq_domain *irq_domain_create_linear(struct fwnode_handle *fwnode, unsigned int size, const struct irq_domain_ops *ops, void *host_data) { return __irq_domain_add(fwnode, size, size, 0, ops, host_data); or static inline struct irq_domain *irq_domain_add_linear(struct device_node *of_node, unsigned int size, const struct irq_domain_ops *ops, void *host_data) { return __irq_domain_add(of_node_to_fwnode(of_node), size, size, 0, ops, host_data); And kernel/irq/irqdomain.c struct irq_domain *irq_domain_create_simple(struct fwnode_handle *fwnode, unsigned int size, unsigned int first_irq, const struct irq_domain_ops *ops, void *host_data) { struct irq_domain *domain; domain = __irq_domain_add(fwnode, size, size, 0, ops, host_data); All 'size' passed to __irq_domain_add() are unsigned int. So I think it's more appropriate to replace it with unsigned int. Thanks, Bixuan Cui ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH -next] irqdomain: fix overflow error 2021-09-15 2:03 ` Bixuan Cui @ 2021-09-15 7:49 ` Thomas Gleixner 2021-09-15 9:38 ` Bixuan Cui 2021-09-16 2:37 ` Bixuan Cui 0 siblings, 2 replies; 6+ messages in thread From: Thomas Gleixner @ 2021-09-15 7:49 UTC (permalink / raw) To: Bixuan Cui, linux-kernel; +Cc: maz, john.wanghui On Wed, Sep 15 2021 at 10:03, Bixuan Cui wrote: > On 2021/9/14 19:56, Thomas Gleixner wrote: > > And kernel/irq/irqdomain.c > struct irq_domain *irq_domain_create_simple(struct fwnode_handle *fwnode, > unsigned int size, > unsigned int first_irq, > const struct irq_domain_ops *ops, > void *host_data) > { > struct irq_domain *domain; > > domain = __irq_domain_add(fwnode, size, size, 0, ops, host_data); > > All 'size' passed to __irq_domain_add() are unsigned int. > > So I think it's more appropriate to replace it with unsigned int. Appropriate is not really a technical reason. Making the code consistent is. But that has nothing to do with the completely bogus compiler warning in the changelog you provided. Thanks, tglx ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH -next] irqdomain: fix overflow error 2021-09-15 7:49 ` Thomas Gleixner @ 2021-09-15 9:38 ` Bixuan Cui 2021-09-16 2:37 ` Bixuan Cui 1 sibling, 0 replies; 6+ messages in thread From: Bixuan Cui @ 2021-09-15 9:38 UTC (permalink / raw) To: Thomas Gleixner, linux-kernel; +Cc: maz, john.wanghui On 2021/9/15 15:49, Thomas Gleixner wrote: > On Wed, Sep 15 2021 at 10:03, Bixuan Cui wrote: >> On 2021/9/14 19:56, Thomas Gleixner wrote: >> >> And kernel/irq/irqdomain.c >> struct irq_domain *irq_domain_create_simple(struct fwnode_handle *fwnode, >> unsigned int size, >> unsigned int first_irq, >> const struct irq_domain_ops *ops, >> void *host_data) >> { >> struct irq_domain *domain; >> >> domain = __irq_domain_add(fwnode, size, size, 0, ops, host_data); >> >> All 'size' passed to __irq_domain_add() are unsigned int. >> >> So I think it's more appropriate to replace it with unsigned int. > Appropriate is not really a technical reason. Making the code consistent > is. > > But that has nothing to do with the completely bogus compiler warning in > the changelog you provided. Hello, It is a real compilation warning, It occurs when compiled with .config(https://syzkaller.appspot.com/text?tag=KernelConfig&x=4d196bb8b1e038c0). This is my compile log: // cp .config from https://syzkaller.appspot.com/text?tag=KernelConfig&x=4d196bb8b1e038c0 $ make menuconfig $ make kernel/irq/irqdomain.o SYNC include/config/auto.conf.cmd DESCEND objtool CALL scripts/atomic/check-atomics.sh CALL scripts/checksyscalls.sh CC kernel/irq/irqdomain.o In file included from ./include/linux/resource_ext.h:11:0, from ./include/linux/acpi.h:14, from kernel/irq/irqdomain.c:5: In function ‘kmalloc_node’, inlined from ‘kzalloc_node.constprop’ at ./include/linux/slab.h:743:9, inlined from ‘__irq_domain_add’ at kernel/irq/irqdomain.c:153:9: ./include/linux/slab.h:618:9: warning: argument 1 value ‘18446744073709551615’ exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] return __kmalloc_node(size, flags, node); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/slab.h: In function ‘__irq_domain_add’: ./include/linux/slab.h:455:7: note: in a call to allocation function ‘__kmalloc_node’ declared here void *__kmalloc_node(size_t size, gfp_t flags, int node) __assume_slab_alignment __malloc; ^~~~~~~~~~~~~~ Thanks, Bixuan Cui ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH -next] irqdomain: fix overflow error 2021-09-15 7:49 ` Thomas Gleixner 2021-09-15 9:38 ` Bixuan Cui @ 2021-09-16 2:37 ` Bixuan Cui 1 sibling, 0 replies; 6+ messages in thread From: Bixuan Cui @ 2021-09-16 2:37 UTC (permalink / raw) To: Thomas Gleixner, linux-kernel; +Cc: maz, john.wanghui On 2021/9/15 15:49, Thomas Gleixner wrote: > Appropriate is not really a technical reason. Making the code consistent > is. Agree, I'll change the message. Thanks Bixuan Cui ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-09-16 2:37 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-08 1:46 [PATCH -next] irqdomain: fix overflow error Bixuan Cui 2021-09-14 11:56 ` Thomas Gleixner 2021-09-15 2:03 ` Bixuan Cui 2021-09-15 7:49 ` Thomas Gleixner 2021-09-15 9:38 ` Bixuan Cui 2021-09-16 2:37 ` Bixuan Cui
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).