public inbox for kernel-janitors@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: kernel-janitors@vger.kernel.org
Subject: Re: [patch] clk: shmobile: r8a7779: silence some static checker warnings
Date: Fri, 01 Aug 2014 14:32:08 +0000	[thread overview]
Message-ID: <20140801143208.GN4804@mwanda> (raw)
In-Reply-To: <20140801081926.GB28869@mwanda>


The code here checks for NULL and then prints an error and there is a
comment saying that it won't handle it correctly because why bother?

It's more normal to just not check for NULL at all.  I am able to find
2 places which do that:

mm/vmalloc.c:1198 vmalloc_init() error: potential null dereference 'va'.  (kzalloc returns null)
drivers/tty/vt/vt.c:2979 con_init() error: potential null dereference 'vc'.  (kzalloc returns null)

We used to have a lot more code like that but it caused static checker
warnings so people updated it to look like this:

	uv_blade_info = kzalloc(bytes, GFP_KERNEL);
	BUG_ON(!uv_blade_info);

Then btrfs started handling allocation errors that way so I made that
trigger a static checker warning as well.  Here are the places that
handle memory allocation that way during bootup.

kernel/power/snapshot.c:861 __register_nosave_region() warn: bug on allocation failure 'region'
kernel/workqueue.c:4802 wq_numa_init() warn: bug on allocation failure 'tbl'
kernel/params.c:741 locate_module_kobject() warn: bug on allocation failure 'mk'
arch/x86/kernel/apic/x2apic_uv_x.c:904 uv_system_init() warn: bug on allocation failure 'uv_blade_info'
arch/x86/kernel/apic/x2apic_uv_x.c:913 uv_system_init() warn: bug on allocation failure 'uv_node_to_blade'
arch/x86/kernel/apic/x2apic_uv_x.c:918 uv_system_init() warn: bug on allocation failure 'uv_cpu_to_blade'
arch/x86/platform/uv/uv_nmi.c:712 uv_nmi_setup() warn: bug on allocation failure 'uv_hub_nmi_list'
mm/memory_hotplug.c:133 register_memory_resource() warn: bug on allocation failure 'res'
mm/slub.c:5109 create_unique_id() warn: bug on allocation failure 'name'
mm/hugetlb.c:2165 hugetlb_init() warn: bug on allocation failure 'htlb_fault_mutex_table'
drivers/block/xen-blkfront.c:1544 blkif_recover() warn: bug on allocation failure 'split_bio'

13 warnings is very small in terms of the whole kernel which means that
most people just gave in and added NULL checks and error handling to
handle errors during boot even though they knew the errors weren't
recoverable.

Another option is would be to use __GFP_NOFAIL.  I don't know if anyone
has done that just to silence static checker warnings but it would work.

regards,
dan carpenter

      parent reply	other threads:[~2014-08-01 14:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-01  8:19 [patch] clk: shmobile: r8a7779: silence some static checker warnings Dan Carpenter
2014-08-01 12:51 ` Laurent Pinchart
2014-08-01 14:32 ` Dan Carpenter [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140801143208.GN4804@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=kernel-janitors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox