[1/2] powerpc/platforms/cell: Delete an error message for a failed memory allocation in three functions

Message ID 62146108-5be0-c236-f404-4be122e162ac@users.sourceforge.net
State New
Headers show
Series
  • PowerPC-Cell platform: Adjustments for four function implementations
Related show

Commit Message

SF Markus Elfring Oct. 5, 2017, 7:36 p.m.
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 5 Oct 2017 21:04:30 +0200

Omit extra messages for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 arch/powerpc/platforms/cell/axon_msi.c   | 5 +----
 arch/powerpc/platforms/cell/spider-pci.c | 9 ++-------
 2 files changed, 3 insertions(+), 11 deletions(-)

Comments

Michal Suchánek Oct. 5, 2017, 8:02 p.m. | #1
Hello,

On Thu, 5 Oct 2017 21:36:26 +0200
SF Markus Elfring <elfring@users.sourceforge.net> wrote:

> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Thu, 5 Oct 2017 21:04:30 +0200
> 
> Omit extra messages for a memory allocation failure in these
> functions.

this is bogus. All these functions return -1 on any error. Until they
reflect the error in their return value (and it is properly propagated
to the user) there is no way to tell WTF failed without the message.

> 
> This issue was detected by using the Coccinelle software.
> 

... which provides only a hint which should be evaluated by the user.

Thanks

Michal
Julia Lawall Oct. 5, 2017, 8:06 p.m. | #2
On Thu, 5 Oct 2017, Michal Suchánek wrote:

> Hello,
>
> On Thu, 5 Oct 2017 21:36:26 +0200
> SF Markus Elfring <elfring@users.sourceforge.net> wrote:
>
> > From: Markus Elfring <elfring@users.sourceforge.net>
> > Date: Thu, 5 Oct 2017 21:04:30 +0200
> >
> > Omit extra messages for a memory allocation failure in these
> > functions.
>
> this is bogus. All these functions return -1 on any error. Until they
> reflect the error in their return value (and it is properly propagated
> to the user) there is no way to tell WTF failed without the message.

A backtrace will be generated.

julia

>
> >
> > This issue was detected by using the Coccinelle software.
> >
>
> ... which provides only a hint which should be evaluated by the user.
>
> Thanks
>
> Michal
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Michal Suchánek Oct. 5, 2017, 8:29 p.m. | #3
On Thu, 5 Oct 2017 22:06:11 +0200 (CEST)
Julia Lawall <julia.lawall@lip6.fr> wrote:

> On Thu, 5 Oct 2017, Michal Suchánek wrote:
> 
> > Hello,
> >
> > On Thu, 5 Oct 2017 21:36:26 +0200
> > SF Markus Elfring <elfring@users.sourceforge.net> wrote:
> >  
> > > From: Markus Elfring <elfring@users.sourceforge.net>
> > > Date: Thu, 5 Oct 2017 21:04:30 +0200
> > >
> > > Omit extra messages for a memory allocation failure in these
> > > functions.  
> >
> > this is bogus. All these functions return -1 on any error. Until
> > they reflect the error in their return value (and it is properly
> > propagated to the user) there is no way to tell WTF failed without
> > the message.  
> 
> A backtrace will be generated.
> 

I do not see why it would. I do not expect the kernel to generate a
stack trace every time memory allocation fails. With all the hooks in
the code it is hard to tell, though.

Thanks

Michal
Joe Perches Oct. 6, 2017, 2:02 a.m. | #4
On Thu, 2017-10-05 at 22:29 +0200, Michal Suchánek wrote:
> I do not expect the kernel to generate a
> stack trace every time memory allocation fails. With all the hooks in
> the code it is hard to tell, though.

All [kv].alloc failures without __GFP_NOWARN call dump_stack()

Patch

diff --git a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c
index 6ea3f248b155..513d13d779b3 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -343,11 +343,8 @@  static int axon_msi_probe(struct platform_device *device)
 	pr_devel("axon_msi: setting up dn %pOF\n", dn);
 
 	msic = kzalloc(sizeof(struct axon_msic), GFP_KERNEL);
-	if (!msic) {
-		printk(KERN_ERR "axon_msi: couldn't allocate msic for %pOF\n",
-		       dn);
+	if (!msic)
 		goto out;
-	}
 
 	dcr_base = dcr_resource_start(dn, 0);
 	dcr_len = dcr_resource_len(dn, 0);
diff --git a/arch/powerpc/platforms/cell/spider-pci.c b/arch/powerpc/platforms/cell/spider-pci.c
index d1e61e273e64..0a9f00563144 100644
--- a/arch/powerpc/platforms/cell/spider-pci.c
+++ b/arch/powerpc/platforms/cell/spider-pci.c
@@ -104,10 +104,8 @@  static int __init spiderpci_pci_setup_chip(struct pci_controller *phb,
 	 * Celleb does not have this problem, because it has only one XDR.
 	 */
 	dummy_page_va = kmalloc(PAGE_SIZE, GFP_KERNEL);
-	if (!dummy_page_va) {
-		pr_err("SPIDERPCI-IOWA:Alloc dummy_page_va failed.\n");
+	if (!dummy_page_va)
 		return -1;
-	}
 
 	dummy_page_da = dma_map_single(phb->parent, dummy_page_va,
 				       PAGE_SIZE, DMA_FROM_DEVICE);
@@ -134,11 +132,8 @@  int __init spiderpci_iowa_init(struct iowa_bus *bus, void *data)
 		 np);
 
 	priv = kzalloc(sizeof(struct spiderpci_iowa_private), GFP_KERNEL);
-	if (!priv) {
-		pr_err("SPIDERPCI-IOWA:"
-		       "Can't allocate struct spiderpci_iowa_private");
+	if (!priv)
 		return -1;
-	}
 
 	if (of_address_to_resource(np, 0, &r)) {
 		pr_err("SPIDERPCI-IOWA:Can't get resource.\n");