* [cocci] coccinelle is skipping include files?
@ 2022-10-19 23:36 Kees Cook
2022-10-20 4:43 ` Julia Lawall
0 siblings, 1 reply; 5+ messages in thread
From: Kees Cook @ 2022-10-19 23:36 UTC (permalink / raw)
To: Julia Lawall; +Cc: cocci, Darrick J. Wong
Hi!
I'm once against stumped by include file handling. Here's my .cocci
file:
// match memcpy() which has a flexible array struct as the destination
@memcpy_fas_dest@
identifier FAS;
struct FAS *PTR;
expression SRC, SIZE;
@@
memcpy(
PTR
, SRC, SIZE)
@fas@
identifier memcpy_fas_dest.FAS;
identifier flex;
type T;
@@
* struct FAS {
...
(
T flex[1];
|
T flex[0];
|
T flex[];
)
};
// match memcpy() which has a flexible array struct as the destination
@memcpy_hit depends on fas@
identifier memcpy_fas_dest.FAS;
struct FAS *memcpy_fas_dest.PTR;
expression SRC, SIZE;
@@
memcpy(
* PTR
, SRC, SIZE)
The example I'm looking at is fs/xfs/xfs_bmap_item.c, which starts with:
#include "xfs.h"
#include "xfs_fs.h"
#include "xfs_format.h"
#include "xfs_log_format.h"
...
Here it is working, if I explicitly as for "xfs_log_format.h" to be
included:
$ ARGS="--very-quiet \
-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 \
--jobs 36 --chunksize 1"
$ spatch $ARGS --all-includes --cocci-file t.cocci \
--include fs/xfs/libxfs/xfs_log_format.h \
fs/xfs/xfs_bmap_item.c
--- fs/xfs/xfs_bmap_item.c
+++ /tmp/cocci-output-742963-d11c3c-xfs_bmap_item.c
@@ -625,7 +625,6 @@ xfs_bui_copy_format(
len = xfs_bui_log_format_sizeof(src_bui_fmt->bui_nextents);
if (buf->i_len == len) {
- memcpy(dst_bui_fmt, src_bui_fmt, len);
return 0;
}
XFS_ERROR_REPORT(__func__, XFS_ERRLEVEL_LOW, NULL);
But if I don't explicitly ask it to process
"fs/xfs/libxfs/xfs_log_format.h", it doesn't match,
no matter what "includes" option I try:
$ spatch $ARGS --all-includes --cocci-file t.cocci \
fs/xfs/xfs_bmap_item.c
$ spatch $ARGS -recusrive-includes --cocci-file t.cocci \
fs/xfs/xfs_bmap_item.c
Weirder yet, it doesn't seem to even _try_ to include the right headers.
$ strace -f -e openat \
spatch $ARGS --all-includes --cocci-file t.cocci \
fs/xfs/xfs_bmap_item.c \
2>&1 | grep '\.h"' | grep xfs
openat(AT_FDCWD, "fs/xfs/xfs.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_mount.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_inode.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_trans.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_trans_priv.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_bmap_item.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_log.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_icache.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_error.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_log_priv.h", O_RDONLY|O_CLOEXEC) = 4
Using --recursive-includes open a massive amount of headers, but still
not fs/xfs/libxfs/xfs_log_format.h:
$ strace -f -e openat \
spatch $ARGS --recursive-includes --cocci-file t.cocci \
fs/xfs/xfs_bmap_item.c \
2>&1 | grep '\.h"' | grep xfs
openat(AT_FDCWD, "fs/xfs/xfs.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_linux.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/kmem.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "./include/uapi/linux/dqblk_xfs.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/mrlock.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_stats.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_sysctl.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_iops.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_aops.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_super.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_buf.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_message.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_mount.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_inode.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_trans.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_trans_priv.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_bmap_item.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_log.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_icache.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_error.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_log_priv.h", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "fs/xfs/xfs_message.h", O_RDONLY|O_CLOEXEC) = 4
Any idea what is going on here?
Thanks!
-Kees
--
Kees Cook
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [cocci] coccinelle is skipping include files?
2022-10-19 23:36 [cocci] coccinelle is skipping include files? Kees Cook
@ 2022-10-20 4:43 ` Julia Lawall
2022-10-20 5:18 ` Kees Cook
0 siblings, 1 reply; 5+ messages in thread
From: Julia Lawall @ 2022-10-20 4:43 UTC (permalink / raw)
To: Kees Cook; +Cc: cocci, Darrick J. Wong
> The example I'm looking at is fs/xfs/xfs_bmap_item.c, which starts with:
> #include "xfs.h"
> #include "xfs_fs.h"
> #include "xfs_format.h"
> #include "xfs_log_format.h"
> ...
>
>
> Here it is working, if I explicitly as for "xfs_log_format.h" to be
> included:
>
> $ ARGS="--very-quiet \
> -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 \
> --jobs 36 --chunksize 1"
> $ spatch $ARGS --all-includes --cocci-file t.cocci \
> --include fs/xfs/libxfs/xfs_log_format.h \
> fs/xfs/xfs_bmap_item.c
> --- fs/xfs/xfs_bmap_item.c
> +++ /tmp/cocci-output-742963-d11c3c-xfs_bmap_item.c
> @@ -625,7 +625,6 @@ xfs_bui_copy_format(
> len = xfs_bui_log_format_sizeof(src_bui_fmt->bui_nextents);
>
> if (buf->i_len == len) {
> - memcpy(dst_bui_fmt, src_bui_fmt, len);
> return 0;
> }
> XFS_ERROR_REPORT(__func__, XFS_ERRLEVEL_LOW, NULL);
>
>
> But if I don't explicitly ask it to process
> "fs/xfs/libxfs/xfs_log_format.h", it doesn't match,
> no matter what "includes" option I try:
You may want to start with the option --verbose-includes for such
problems.
The problem is that Coccinelle can't find the file. Your .c file is in
fs/xfs, and despite the lack of a complete path, the header file is in
a subdirectory: fs/xfs/libxfs. So you could add -I fs/xfs/libxfs to your
command line.
Another solution is the option --relax-include-path. This should cause
Coccinelle to look over the entire kernel to see if it can find exactly
one file named xfs_log_format.h. If only one exists, that has to be the
one you want.
julia
>
> $ spatch $ARGS --all-includes --cocci-file t.cocci \
> fs/xfs/xfs_bmap_item.c
> $ spatch $ARGS -recusrive-includes --cocci-file t.cocci \
> fs/xfs/xfs_bmap_item.c
>
> Weirder yet, it doesn't seem to even _try_ to include the right headers.
>
> $ strace -f -e openat \
> spatch $ARGS --all-includes --cocci-file t.cocci \
> fs/xfs/xfs_bmap_item.c \
> 2>&1 | grep '\.h"' | grep xfs
> openat(AT_FDCWD, "fs/xfs/xfs.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_mount.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_inode.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_trans.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_trans_priv.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_bmap_item.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_log.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_icache.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_error.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_log_priv.h", O_RDONLY|O_CLOEXEC) = 4
>
> Using --recursive-includes open a massive amount of headers, but still
> not fs/xfs/libxfs/xfs_log_format.h:
>
> $ strace -f -e openat \
> spatch $ARGS --recursive-includes --cocci-file t.cocci \
> fs/xfs/xfs_bmap_item.c \
> 2>&1 | grep '\.h"' | grep xfs
> openat(AT_FDCWD, "fs/xfs/xfs.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_linux.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/kmem.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "./include/uapi/linux/dqblk_xfs.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/mrlock.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_stats.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_sysctl.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_iops.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_aops.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_super.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_buf.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_message.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_mount.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_inode.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_trans.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_trans_priv.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_bmap_item.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_log.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_icache.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_error.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_log_priv.h", O_RDONLY|O_CLOEXEC) = 4
> openat(AT_FDCWD, "fs/xfs/xfs_message.h", O_RDONLY|O_CLOEXEC) = 4
>
> Any idea what is going on here?
>
> Thanks!
>
> -Kees
>
> --
> Kees Cook
>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [cocci] coccinelle is skipping include files?
2022-10-20 4:43 ` Julia Lawall
@ 2022-10-20 5:18 ` Kees Cook
2022-10-20 5:23 ` Julia Lawall
0 siblings, 1 reply; 5+ messages in thread
From: Kees Cook @ 2022-10-20 5:18 UTC (permalink / raw)
To: Julia Lawall, Kees Cook; +Cc: cocci, Darrick J. Wong
On October 19, 2022 9:43:35 PM PDT, Julia Lawall <julia.lawall@inria.fr> wrote:
>> The example I'm looking at is fs/xfs/xfs_bmap_item.c, which starts with:
>> #include "xfs.h"
>> #include "xfs_fs.h"
>> #include "xfs_format.h"
>> #include "xfs_log_format.h"
>> ...
>You may want to start with the option --verbose-includes for such
>problems.
Ah-ha, thanks!
>The problem is that Coccinelle can't find the file. Your .c file is in
>fs/xfs, and despite the lack of a complete path, the header file is in
>a subdirectory: fs/xfs/libxfs. So you could add -I fs/xfs/libxfs to your
>command line.
Ugh, yes, I see this now. It looks like we need to parse the Makefiles? :(
>Another solution is the option --relax-include-path. This should cause
>Coccinelle to look over the entire kernel to see if it can find exactly
>one file named xfs_log_format.h. If only one exists, that has to be the
>one you want.
Interesting solution, and would work here. I wonder if there needs to be a "fail I Coccinelle fails to find a header" option? Hmmm
--
Kees Cook
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [cocci] coccinelle is skipping include files?
2022-10-20 5:18 ` Kees Cook
@ 2022-10-20 5:23 ` Julia Lawall
2022-10-24 16:53 ` Kees Cook
0 siblings, 1 reply; 5+ messages in thread
From: Julia Lawall @ 2022-10-20 5:23 UTC (permalink / raw)
To: Kees Cook; +Cc: Kees Cook, cocci, Darrick J. Wong
On Wed, 19 Oct 2022, Kees Cook wrote:
> On October 19, 2022 9:43:35 PM PDT, Julia Lawall <julia.lawall@inria.fr> wrote:
> >> The example I'm looking at is fs/xfs/xfs_bmap_item.c, which starts with:
> >> #include "xfs.h"
> >> #include "xfs_fs.h"
> >> #include "xfs_format.h"
> >> #include "xfs_log_format.h"
> >> ...
> >You may want to start with the option --verbose-includes for such
> >problems.
>
> Ah-ha, thanks!
>
> >The problem is that Coccinelle can't find the file. Your .c file is in
> >fs/xfs, and despite the lack of a complete path, the header file is in
> >a subdirectory: fs/xfs/libxfs. So you could add -I fs/xfs/libxfs to your
> >command line.
>
> Ugh, yes, I see this now. It looks like we need to parse the Makefiles? :(
>
> >Another solution is the option --relax-include-path. This should cause
> >Coccinelle to look over the entire kernel to see if it can find exactly
> >one file named xfs_log_format.h. If only one exists, that has to be the
> >one you want.
>
> Interesting solution, and would work here. I wonder if there needs to be a "fail I Coccinelle fails to find a header" option? Hmmm
What do you mean by fail? Do you want spatch to stop completely, or the
file to just be ignored?
julia
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [cocci] coccinelle is skipping include files?
2022-10-20 5:23 ` Julia Lawall
@ 2022-10-24 16:53 ` Kees Cook
0 siblings, 0 replies; 5+ messages in thread
From: Kees Cook @ 2022-10-24 16:53 UTC (permalink / raw)
To: Julia Lawall; +Cc: Kees Cook, cocci, Darrick J. Wong
On Thu, Oct 20, 2022 at 07:23:34AM +0200, Julia Lawall wrote:
> On Wed, 19 Oct 2022, Kees Cook wrote:
>
> > On October 19, 2022 9:43:35 PM PDT, Julia Lawall <julia.lawall@inria.fr> wrote:
> > >> The example I'm looking at is fs/xfs/xfs_bmap_item.c, which starts with:
> > >> #include "xfs.h"
> > >> #include "xfs_fs.h"
> > >> #include "xfs_format.h"
> > >> #include "xfs_log_format.h"
> > >> ...
> > >You may want to start with the option --verbose-includes for such
> > >problems.
> >
> > Ah-ha, thanks!
> >
> > >The problem is that Coccinelle can't find the file. Your .c file is in
> > >fs/xfs, and despite the lack of a complete path, the header file is in
> > >a subdirectory: fs/xfs/libxfs. So you could add -I fs/xfs/libxfs to your
> > >command line.
> >
> > Ugh, yes, I see this now. It looks like we need to parse the Makefiles? :(
> >
> > >Another solution is the option --relax-include-path. This should cause
> > >Coccinelle to look over the entire kernel to see if it can find exactly
> > >one file named xfs_log_format.h. If only one exists, that has to be the
> > >one you want.
> >
> > Interesting solution, and would work here. I wonder if there needs to be a "fail I Coccinelle fails to find a header" option? Hmmm
>
> What do you mean by fail? Do you want spatch to stop completely, or the
> file to just be ignored?
I mean have a mode where cocci will error out if it can't find a header.
It already ignores missing headers, but if it can't resolve a header,
and I'm depending on struct declarations to be found, silently ignoring
missing headers is going to mean I miss matches.
--
Kees Cook
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-10-24 19:30 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-10-19 23:36 [cocci] coccinelle is skipping include files? Kees Cook
2022-10-20 4:43 ` Julia Lawall
2022-10-20 5:18 ` Kees Cook
2022-10-20 5:23 ` Julia Lawall
2022-10-24 16:53 ` Kees Cook
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.