Coccinelle archive mirror
 help / color / mirror / Atom feed
From: Markus Elfring <Markus.Elfring@web.de>
To: LKML <linux-kernel@vger.kernel.org>, cocci@inria.fr
Cc: kernel-janitors@vger.kernel.org,
	Dan Carpenter <error27@gmail.com>,
	"Derek M. Jones" <derek@knosof.co.uk>,
	John Regehr <regehr@cs.utah.edu>
Subject: [cocci] Source code review around jump label usage (snapshot 2023-03-31)
Date: Mon, 3 Apr 2023 08:51:55 +0200	[thread overview]
Message-ID: <2f9d7de8-7f99-68cc-f940-a528a1aae70f@web.de> (raw)

Hello,

Some data were published.

Source code review around jump label usage
2015-12-11
https://lore.kernel.org/lkml/566ABCD9.1060404@users.sourceforge.net/
https://lkml.org/lkml/2015/12/11/378


Various involved components were changed and improved in the meantime.

Thus I have tried another specific analysis out on the source files
of “Linux next-20230331” with help of the software “Coccinelle 1.1.1-00448-g8e007c83” (OCaml 5.0).
I have taken a more detailed look on the use of the goto statement
and corresponding jump labels once more.

Can statistics (like the following) support software evolution
and further constructive considerations?

╔═════════════════════╤═══════════╗
║       target        │ incidence ║
╠═════════════════════╪═══════════╣
║ out                 │     16652 ║
║ err                 │      3498 ║
║ done                │      2104 ║
║ error               │      1887 ║
║ fail                │      1816 ║
║ exit                │      1502 ║
║ unlock              │      1334 ║
║ out_unlock          │      1290 ║
║ err_out             │       819 ║
║ out_free            │       778 ║
║ retry               │       749 ║
║ out_err             │       678 ║
║ cleanup             │       648 ║
║ again               │       584 ║
║ nla_put_failure     │       574 ║
║ end                 │       516 ║
║ err_free            │       409 ║
║ bail                │       402 ║
║ failed              │       333 ║
║ found               │       331 ║
║ next                │       326 ║
║ drop                │       283 ║
║ free                │       276 ║
║ err1                │       264 ║
║ err_unlock          │       234 ║
║ out_put             │       201 ║
║ restart             │       200 ║
║ err2                │       199 ║
║ errout              │       185 ║
║         …           │     …     ║
║ zr_detach_codec     │         1 ║
║ zr_detach_vfe       │         1 ║
║ zr_free_irq         │         1 ║
║ zr_free_mem         │         1 ║
║ zr_pci_release      │         1 ║
║ zr_unreg            │         1 ║
║ zr_unreg_i2c        │         1 ║
║ zr_unreg_videocodec │         1 ║
╚═════════════════════╧═══════════╝


How often are different jump targets used within function implementations?
(Functions without jump labels were not searched for this analysis approach.)

╔═════════╤═══════════╗
║ counter │ incidence ║
╠═════════╪═══════════╣
║       1 │     40860 ║
║       2 │      9936 ║
║       3 │      3760 ║
║       4 │      1657 ║
║       5 │       835 ║
║       6 │       358 ║
║       7 │       186 ║
║       8 │       135 ║
║       9 │        63 ║
║      10 │        39 ║
║      11 │        23 ║
║      12 │        21 ║
║      13 │        13 ║
║      14 │        10 ║
║      15 │         5 ║
║      16 │         3 ║
║      17 │         3 ║
║      19 │         2 ║
║      20 │         1 ║
║      22 │         4 ║
║      24 │         1 ║
║      25 │         1 ║
║      27 │         1 ║
║      33 │         1 ║
║      36 │         1 ║
╚═════════╧═══════════╝


How does the text length distribution look like for the used jump targets?

╔════════╤═══════════╗
║ length │ incidence ║
╠════════╪═══════════╣
║      1 │         8 ║
║      2 │        73 ║
║      3 │     21173 ║
║      4 │      8517 ║
║      5 │      5287 ║
║      6 │      4083 ║
║      7 │      6185 ║
║      8 │      5521 ║
║      9 │      4472 ║
║     10 │      5426 ║
║   …    │     …     ║
║     38 │        15 ║
║     39 │         1 ║
║     40 │         5 ║
║     45 │         1 ║
║     48 │         1 ║
╚════════╧═══════════╝


How often are jump targets called within specific function implementations?

╔════════════════════════════════════╤═════════════════════════════════════════════╤══════╤═════════════════╤═════════╗
║              function              │                 source file                 │ line │      go to      │ counter ║
╠════════════════════════════════════╪═════════════════════════════════════════════╪══════╪═════════════════╪═════════╣
║ set_qam                            │ drivers/media/dvb-frontends/drx39xyj/drxj.c │ 7855 │ rw_error        │      93 ║
║ test_btrfs_get_extent              │ fs/btrfs/tests/inode-tests.c                │  210 │ out             │      93 ║
║                 …                  │                      …                      │  …   │        …        │    …    ║
║ dvb_register                       │ drivers/media/pci/cx23885/cx23885-dvb.c     │ 1187 │ frontend_detach │      63 ║
║                 …                  │                      …                      │  …   │        …        │    …    ║
║ zynqmp_pinctrl_prepare_func_groups │ drivers/pinctrl/pinctrl-zynqmp.c            │  548 │ done            │       1 ║
║ zynqmp_pm_debugfs_api_write        │ drivers/firmware/xilinx/zynqmp-debug.c      │  146 │ err             │       1 ║
║ zynqmp_sha_probe                   │ drivers/crypto/xilinx/zynqmp-sha.c          │  192 │ err_mem         │       1 ║
╚════════════════════════════════════╧═════════════════════════════════════════════╧══════╧═════════════════╧═════════╝


Will research and development interests be influenced accordingly?

Regards,
Markus

                 reply	other threads:[~2023-04-03  6:52 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=2f9d7de8-7f99-68cc-f940-a528a1aae70f@web.de \
    --to=markus.elfring@web.de \
    --cc=cocci@inria.fr \
    --cc=derek@knosof.co.uk \
    --cc=error27@gmail.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=regehr@cs.utah.edu \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).