From: Kees Cook <keescook@chromium.org>
To: cocci@inria.fr
Cc: Julia Lawall <Julia.Lawall@inria.fr>,
linux-hardening@vger.kernle.org,
"Gustavo A. R. Silva" <gustavoars@kernel.org>
Subject: [cocci] spatch --jobs N missing matches?
Date: Mon, 26 Sep 2022 11:52:38 -0700 [thread overview]
Message-ID: <202209260912.8DCCD70@keescook> (raw)
Hi,
I have been unable to figure out what is going wrong with spatch doing
what seems like a simple match, but not finding correct results. Here is
the .cocci file:
----
// "level1" matches a struct ending in a flexible array.
@level1@
identifier inner, flex;
type T;
@@
struct inner {
...
T flex[];
};
// "level2" matches a composite flexible array struct (struct ending with "level1")
@level2@
identifier level1.inner;
identifier outer, compflex;
@@
struct outer {
...
struct inner compflex;
};
// match memcpy() which has a composite flexible array struct as the destination
@memcpy_compflex_dest depends on level2@
identifier level2.outer, level2.compflex;
struct outer *PTR;
expression SRC, SIZE;
@@
memcpy(
* &PTR->compflex
, SRC, SIZE)
----
I am using spatch on Ubuntu 22.04.1 LTS:
$ spatch --version
spatch version 1.1.1 compiled with OCaml version 4.13.1
But I've also tried this with the latest from git with (worse?) results
(see below).
I'm using the same "include" options as generated by current Linux builds:
$ INCLUDES="-I ./arch/x86/include -I ./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi --include ./include/linux/compiler-version.h --include ./include/linux/kconfig.h"
And here are the other common arguments:
$ ARGS="--very-quiet $INCLUDES --cocci-file compflex-simple.cocci"
I'm running this against linux-next (20220923).
The first issue I encountered, was that the default didn't match for a
known case:
$ time spatch $ARGS net/sched/cls_u32.c | grep ^---
real 0m0.096s
...
Also it didn't work with "--all-includes":
$ time spatch $ARGS --all-includes net/sched/cls_u32.c | grep ^---
real 0m1.150s
...
In reading the documentation carefully, it seem the desired option is
actually "--recursive-includes" option, which _does_ work:
$ time spatch $ARGS --recursive-includes net/sched/cls_u32.c | grep ^---
--- net/sched/cls_u32.c
real 0m25.332s
...
This takes _much_ longer to run, though. (25 seconds vs 1 ...)
However, if I run this in parallel (using the options shown in the
kernel's build), it does _not_ find the hit in net/sched/cls_u32.c (?!)
$ time spatch $ARGS --recursive-includes --jobs 36 --chunksize 1 --dir . | grep ^---
6594 files match
EXN: Sys_error("./sound/firewire/fireworks/packets-buffer.h: No such file or directory") in ./sound/firewire/fireworks/fireworks_command.c
EXN: Sys_error("./sound/firewire/bebob/lib.h: No such file or directory") in ./sound/firewire/bebob/bebob_command.c
EXN: Sys_error("./sound/firewire/fireworks/packets-buffer.h: No such file or directory") in ./sound/firewire/fireworks/fireworks_transaction.c
--- ./fs/dlm/requestqueue.c
--- ./drivers/w1/w1_netlink.c
--- ./drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c
--- ./drivers/platform/surface/surface_acpi_notify.c
--- ./net/nfc/hci/hcp.c
--- ./drivers/s390/net/qeth_l2_main.c
real 8m50.993s
...
With the latest from git, it additionally misses "fs/dlm/requestqueue.c",
(but it takes half the time):
$ time ~/.local/bin/spatch $ARGS --recursive-includes --jobs 36 --chunksize 1 --dir . | grep ^---
6594 files match
--- ./drivers/w1/w1_netlink.c
--- ./drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c
--- ./drivers/platform/surface/surface_acpi_notify.c
--- ./net/nfc/hci/hcp.c
--- ./drivers/s390/net/qeth_l2_main.c
real 4m39.263s
...
If I run it _not_ in parallel it is obviously MUCH slower, but ends up
finding _no_ hits at all!
$ $ time spatch $ARGS --recursive-includes --dir . | tee /tmp/slow.log | grep ^---
6594 files match
EXN: Sys_error("./sound/firewire/bebob/lib.h: No such file or directory") in ./sound/firewire/bebob/bebob_command.c
EXN: Sys_error("./sound/firewire/fireworks/packets-buffer.h: No such file or directory") in ./sound/firewire/fireworks/fireworks_command.c
real 66m49.620s
...
Do you have any idea what is going on?
--
Kees Cook
next reply other threads:[~2022-09-26 18:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-26 18:52 Kees Cook [this message]
2022-09-26 21:14 ` [cocci] spatch --jobs N missing matches? Julia Lawall
2022-09-26 22:09 ` Kees Cook
2022-09-27 20:37 ` Julia Lawall
2022-09-27 21:09 ` Julia Lawall
2022-09-28 0:06 ` Kees Cook
2022-09-28 5:23 ` Julia Lawall
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=202209260912.8DCCD70@keescook \
--to=keescook@chromium.org \
--cc=Julia.Lawall@inria.fr \
--cc=cocci@inria.fr \
--cc=gustavoars@kernel.org \
--cc=linux-hardening@vger.kernle.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).