mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH v2] x86/xen: Add some null pointer checking to smp.c
@ 2024-01-17  9:00 Kunwu Chan
  2024-01-17 10:40 ` Markus Elfring
       [not found] ` <1705655941162581.825.seg@mailgw>
  0 siblings, 2 replies; 6+ messages in thread
From: Kunwu Chan @ 2024-01-17  9:00 UTC (permalink / raw)
  To: jgross, boris.ostrovsky, tglx, mingo, bp, dave.hansen, x86, hpa
  Cc: xen-devel, linux-kernel, Kunwu Chan, kernel test robot

kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.

Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202401161119.iof6BQsf-lkp@intel.com/

---
v2: Initial rc and return errno in error paths
---
 arch/x86/xen/smp.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 4b0d6fff88de..0ea4f1b2ab21 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -61,10 +61,14 @@ void xen_smp_intr_free(unsigned int cpu)
 
 int xen_smp_intr_init(unsigned int cpu)
 {
-	int rc;
+	int rc = 0;
 	char *resched_name, *callfunc_name, *debug_name;
 
 	resched_name = kasprintf(GFP_KERNEL, "resched%d", cpu);
+	if (!resched_name) {
+		rc = -ENOMEM;
+		goto fail;
+	}
 	per_cpu(xen_resched_irq, cpu).name = resched_name;
 	rc = bind_ipi_to_irqhandler(XEN_RESCHEDULE_VECTOR,
 				    cpu,
@@ -77,6 +81,10 @@ int xen_smp_intr_init(unsigned int cpu)
 	per_cpu(xen_resched_irq, cpu).irq = rc;
 
 	callfunc_name = kasprintf(GFP_KERNEL, "callfunc%d", cpu);
+	if (!callfunc_name) {
+		rc = -ENOMEM;
+		goto fail;
+	}
 	per_cpu(xen_callfunc_irq, cpu).name = callfunc_name;
 	rc = bind_ipi_to_irqhandler(XEN_CALL_FUNCTION_VECTOR,
 				    cpu,
@@ -90,6 +98,10 @@ int xen_smp_intr_init(unsigned int cpu)
 
 	if (!xen_fifo_events) {
 		debug_name = kasprintf(GFP_KERNEL, "debug%d", cpu);
+		if (!debug_name) {
+			rc = -ENOMEM;
+			goto fail;
+		}
 		per_cpu(xen_debug_irq, cpu).name = debug_name;
 		rc = bind_virq_to_irqhandler(VIRQ_DEBUG, cpu,
 					     xen_debug_interrupt,
@@ -101,6 +113,10 @@ int xen_smp_intr_init(unsigned int cpu)
 	}
 
 	callfunc_name = kasprintf(GFP_KERNEL, "callfuncsingle%d", cpu);
+	if (!callfunc_name) {
+		rc = -ENOMEM;
+		goto fail;
+	}
 	per_cpu(xen_callfuncsingle_irq, cpu).name = callfunc_name;
 	rc = bind_ipi_to_irqhandler(XEN_CALL_FUNCTION_SINGLE_VECTOR,
 				    cpu,
-- 
2.39.2


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] x86/xen: Add some null pointer checking to smp.c
  2024-01-17  9:00 [PATCH v2] x86/xen: Add some null pointer checking to smp.c Kunwu Chan
@ 2024-01-17 10:40 ` Markus Elfring
       [not found] ` <1705655941162581.825.seg@mailgw>
  1 sibling, 0 replies; 6+ messages in thread
From: Markus Elfring @ 2024-01-17 10:40 UTC (permalink / raw)
  To: Kunwu Chan, xen-devel, kernel-janitors
  Cc: LKML, kernel test robot, Boris Ostrovsky, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Ingo Molnar, Jürgen Groß,
	Thomas Gleixner, x86

> kasprintf() returns a pointer to dynamically allocated memory
> which can be NULL upon failure. Ensure the allocation was successful
> by checking the pointer validity.
…
> +++ b/arch/x86/xen/smp.c
> @@ -61,10 +61,14 @@ void xen_smp_intr_free(unsigned int cpu)
>
>  int xen_smp_intr_init(unsigned int cpu)
>  {
> -	int rc;
> +	int rc = 0;

I find the indication of a successful function execution sufficient by
the statement “return 0;” at the end.
How do you think about to omit such an extra variable initialisation?


>  	char *resched_name, *callfunc_name, *debug_name;
>
>  	resched_name = kasprintf(GFP_KERNEL, "resched%d", cpu);
> +	if (!resched_name) {
> +		rc = -ENOMEM;
> +		goto fail;
> +	}
>  	per_cpu(xen_resched_irq, cpu).name = resched_name;
>  	rc = bind_ipi_to_irqhandler(XEN_RESCHEDULE_VECTOR,
>  				    cpu,

You propose to apply the same error code in four if branches.
I suggest to avoid the specification of duplicate assignment statements
for this purpose.
How do you think about to use another label like “e_nomem”?

Regards,
Markus

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] x86/xen: Add some null pointer checking to smp.c
       [not found] ` <1705655941162581.825.seg@mailgw>
@ 2024-01-19  9:22   ` Kunwu Chan
  2024-01-22  8:30     ` Dan Carpenter
  0 siblings, 1 reply; 6+ messages in thread
From: Kunwu Chan @ 2024-01-19  9:22 UTC (permalink / raw)
  To: Markus Elfring, xen-devel, kernel-janitors
  Cc: LKML, kernel test robot, Boris Ostrovsky, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Ingo Molnar, Jürgen Groß,
	Thomas Gleixner, x86

On 2024/1/17 18:40, Markus Elfring wrote:
>> kasprintf() returns a pointer to dynamically allocated memory
>> which can be NULL upon failure. Ensure the allocation was successful
>> by checking the pointer validity.
> …
>> +++ b/arch/x86/xen/smp.c
>> @@ -61,10 +61,14 @@ void xen_smp_intr_free(unsigned int cpu)
>>
>>   int xen_smp_intr_init(unsigned int cpu)
>>   {
>> -	int rc;
>> +	int rc = 0;
> 
> I find the indication of a successful function execution sufficient by
> the statement “return 0;” at the end.
> How do you think about to omit such an extra variable initialisation?
Thanks, it's no need now. I'll remove it in v3.
> 
> 
>>   	char *resched_name, *callfunc_name, *debug_name;
>>
>>   	resched_name = kasprintf(GFP_KERNEL, "resched%d", cpu);
>> +	if (!resched_name) {
>> +		rc = -ENOMEM;
>> +		goto fail;
>> +	}
>>   	per_cpu(xen_resched_irq, cpu).name = resched_name;
>>   	rc = bind_ipi_to_irqhandler(XEN_RESCHEDULE_VECTOR,
>>   				    cpu,
> 
> You propose to apply the same error code in four if branches.
> I suggest to avoid the specification of duplicate assignment statements
> for this purpose.
> How do you think about to use another label like “e_nomem”?
I'll add a new label to simply the code.
> 
> Regards,
> Markus
-- 
Thanks,
   Kunwu


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] x86/xen: Add some null pointer checking to smp.c
  2024-01-19  9:22   ` Kunwu Chan
@ 2024-01-22  8:30     ` Dan Carpenter
  2024-01-22  8:41       ` Kunwu Chan
  2024-01-22 10:06       ` [v2] " Markus Elfring
  0 siblings, 2 replies; 6+ messages in thread
From: Dan Carpenter @ 2024-01-22  8:30 UTC (permalink / raw)
  To: Kunwu Chan
  Cc: Markus Elfring, xen-devel, kernel-janitors, LKML,
	kernel test robot, Boris Ostrovsky, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Ingo Molnar, Jürgen Groß,
	Thomas Gleixner, x86

On Fri, Jan 19, 2024 at 05:22:25PM +0800, Kunwu Chan wrote:
> On 2024/1/17 18:40, Markus Elfring wrote:
> > > kasprintf() returns a pointer to dynamically allocated memory
> > > which can be NULL upon failure. Ensure the allocation was successful
> > > by checking the pointer validity.
> > …
> > > +++ b/arch/x86/xen/smp.c
> > > @@ -61,10 +61,14 @@ void xen_smp_intr_free(unsigned int cpu)
> > > 
> > >   int xen_smp_intr_init(unsigned int cpu)
> > >   {
> > > -	int rc;
> > > +	int rc = 0;
> > 
> > I find the indication of a successful function execution sufficient by
> > the statement “return 0;” at the end.
> > How do you think about to omit such an extra variable initialisation?
> Thanks, it's no need now. I'll remove it in v3.

This advice is good.  Don't do unnecessary assignments.

> > 
> > 
> > >   	char *resched_name, *callfunc_name, *debug_name;
> > > 
> > >   	resched_name = kasprintf(GFP_KERNEL, "resched%d", cpu);
> > > +	if (!resched_name) {
> > > +		rc = -ENOMEM;
> > > +		goto fail;
> > > +	}
> > >   	per_cpu(xen_resched_irq, cpu).name = resched_name;
> > >   	rc = bind_ipi_to_irqhandler(XEN_RESCHEDULE_VECTOR,
> > >   				    cpu,
> > 
> > You propose to apply the same error code in four if branches.
> > I suggest to avoid the specification of duplicate assignment statements
> > for this purpose.
> > How do you think about to use another label like “e_nomem”?
> I'll add a new label to simply the code.

I'm not a Xen maintainer so I can't really comment on their style
choices.  However, as one of the kernel-janitors list people, I would
say that not everyone agrees with Markus's style preferences.  Markus
was banned from the list for a while, but we unbanned everyone when we
transitioned to the new list infrastructure.  Do a search on lore to
find out more.  https://lore.kernel.org/all/?q=Elfring

Perhaps wait for feedback from the maintainers for how to proceed?

regards,
dan carpenter


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] x86/xen: Add some null pointer checking to smp.c
  2024-01-22  8:30     ` Dan Carpenter
@ 2024-01-22  8:41       ` Kunwu Chan
  2024-01-22 10:06       ` [v2] " Markus Elfring
  1 sibling, 0 replies; 6+ messages in thread
From: Kunwu Chan @ 2024-01-22  8:41 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Markus Elfring, xen-devel, kernel-janitors, LKML,
	kernel test robot, Boris Ostrovsky, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Ingo Molnar, Jürgen Groß,
	Thomas Gleixner, x86

On 2024/1/22 16:30, Dan Carpenter wrote:
> On Fri, Jan 19, 2024 at 05:22:25PM +0800, Kunwu Chan wrote:
>> On 2024/1/17 18:40, Markus Elfring wrote:
>>>> kasprintf() returns a pointer to dynamically allocated memory
>>>> which can be NULL upon failure. Ensure the allocation was successful
>>>> by checking the pointer validity.
>>> …
>>>> +++ b/arch/x86/xen/smp.c
>>>> @@ -61,10 +61,14 @@ void xen_smp_intr_free(unsigned int cpu)
>>>>
>>>>    int xen_smp_intr_init(unsigned int cpu)
>>>>    {
>>>> -	int rc;
>>>> +	int rc = 0;
>>>
>>> I find the indication of a successful function execution sufficient by
>>> the statement “return 0;” at the end.
>>> How do you think about to omit such an extra variable initialisation?
>> Thanks, it's no need now. I'll remove it in v3.
> 
> This advice is good.  Don't do unnecessary assignments.
Thanks for your suggestions, I'll keep it in mind.
> 
>>>
>>>
>>>>    	char *resched_name, *callfunc_name, *debug_name;
>>>>
>>>>    	resched_name = kasprintf(GFP_KERNEL, "resched%d", cpu);
>>>> +	if (!resched_name) {
>>>> +		rc = -ENOMEM;
>>>> +		goto fail;
>>>> +	}
>>>>    	per_cpu(xen_resched_irq, cpu).name = resched_name;
>>>>    	rc = bind_ipi_to_irqhandler(XEN_RESCHEDULE_VECTOR,
>>>>    				    cpu,
>>>
>>> You propose to apply the same error code in four if branches.
>>> I suggest to avoid the specification of duplicate assignment statements
>>> for this purpose.
>>> How do you think about to use another label like “e_nomem”?
>> I'll add a new label to simply the code.
> 
> I'm not a Xen maintainer so I can't really comment on their style
> choices.  However, as one of the kernel-janitors list people, I would
> say that not everyone agrees with Markus's style preferences.  Markus
> was banned from the list for a while, but we unbanned everyone when we
> transitioned to the new list infrastructure.  Do a search on lore to
> find out more.  https://lore.kernel.org/all/?q=Elfring
> 
> Perhaps wait for feedback from the maintainers for how to proceed?
OK, I'll wait for the feedback.
> 
> regards,
> dan carpenter
> 
-- 
Thanks,
   Kunwu


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [v2] x86/xen: Add some null pointer checking to smp.c
  2024-01-22  8:30     ` Dan Carpenter
  2024-01-22  8:41       ` Kunwu Chan
@ 2024-01-22 10:06       ` Markus Elfring
  1 sibling, 0 replies; 6+ messages in thread
From: Markus Elfring @ 2024-01-22 10:06 UTC (permalink / raw)
  To: Dan Carpenter, Kunwu Chan, xen-devel, kernel-janitors
  Cc: LKML, kernel test robot, Boris Ostrovsky, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Ingo Molnar, Jürgen Groß,
	Thomas Gleixner, x86, Jonathan Corbet

>>> How do you think about to use another label like “e_nomem”?
>> I'll add a new label to simply the code.
>
> I'm not a Xen maintainer so I can't really comment on their style choices.

Linux contributors can discuss various implementation details.


> However, as one of the kernel-janitors list people, I would
> say that not everyone agrees with Markus's style preferences.

Can a corresponding document be improved accordingly?

Centralized exiting of functions
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v6.8-rc1#n526

Do you find a related information source helpful?
https://wiki.sei.cmu.edu/confluence/display/c/MEM12-C.+Consider+using+a+goto+chain+when+leaving+a+function+on+error+when+using+and+releasing+resources

Regards,
Markus

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2024-01-22 10:08 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-17  9:00 [PATCH v2] x86/xen: Add some null pointer checking to smp.c Kunwu Chan
2024-01-17 10:40 ` Markus Elfring
     [not found] ` <1705655941162581.825.seg@mailgw>
2024-01-19  9:22   ` Kunwu Chan
2024-01-22  8:30     ` Dan Carpenter
2024-01-22  8:41       ` Kunwu Chan
2024-01-22 10:06       ` [v2] " Markus Elfring

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®