linux-kernel - [RFC PATCH 2/2] modpost: sumversions: try to fix "same dir" logic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20180322150005.15061-2-linux@rasmusvillemoes.dk>
Date:   Thu, 22 Mar 2018 15:59:54 +0100
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Michal Marek <mmarek@...e.cz>,
        Masahiro Yamada <yamada.m@...panasonic.com>
Cc:     Rusty Russell <rusty@...tcorp.com.au>,
        Sam Ravnborg <sam@...nborg.org>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        linux-kernel@...r.kernel.org
Subject: [RFC PATCH 2/2] modpost: sumversions: try to fix "same dir" logic

The current logic for deciding whether to parse a file listed in the
.o.cmd file matches neither "is in same dir" (implied by the comment
here), nor the "/* Sum all files in the same dir or subdirs. */" a
little higher up. For example, for an object file in the top-level
crypto/ directory, we end up also parsing anything it includes from
include/crypto/ (though not subdirectories of that) and
arch/x86/include/asm/crypto/. On the other hand, we never parse anything
included from subdirectories of the object file's directory, contrary to
at least one of the comments.

This tries to fix things so that we actually implement "parse stuff
found in $(dirname $objfile) and below" by simply checking whether line
begins with dir. It doesn't quite work, though, because there are some

#include "../blabla"

directives, e.g. in drivers/scsi/libsas/ we have #include
"../scsi_sas_internal.h", and gcc doesn't normalize the path before
printing it, so we have

drivers/scsi/libsas/../scsi_sas_internal.h

in the .o.cmd file. But perhaps that's actually a good thing - then the
logic would be something like "if gcc found the included file using . as
starting point, we include it - otherwise it was found via some -I path,
so do not include it".

In any case, this is mostly just something I stumbled on because I'm
about to change the .o.cmd layout slightly, so I'd like to know what the
rules are really supposed to be.

Signed-off-by: Rasmus Villemoes <linux@...musvillemoes.dk>
---
 scripts/mod/sumversion.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/mod/sumversion.c b/scripts/mod/sumversion.c
index 0f6dcb4011a8..e4f83fb9da2f 100644
--- a/scripts/mod/sumversion.c
+++ b/scripts/mod/sumversion.c
@@ -368,7 +368,7 @@ static int parse_source_files(const char *objfile, struct md4_ctx *md)
 		}

 		/* Check if this file is in same dir as objfile */
-		if ((strstr(line, dir)+strlen(dir)-1) == strrchr(line, '/')) {
+		if (strncmp(line, dir, dirlen) == 0) {
 			if (!parse_file(line, md)) {
 				warn("could not open %s: %s\n",
 				     line, strerror(errno));
-- 
2.15.1