From: Nicholas Mc Guire <der.herr@hofr.at>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
sil2review@lists.osadl.org,
Michal Marek <michal.lkml@markovi.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] fixdep: exit with error code in error branches of do_config_file()
Date: Sun, 31 Dec 2017 15:45:48 +0000 [thread overview]
Message-ID: <20171231154548.GA27372@osadl.at> (raw)
In-Reply-To: <CAK7LNAROjcbES8-debAnzVz1EV1Ar+RLW8phF5+bQxpHQUODKQ@mail.gmail.com>
On Sun, Dec 31, 2017 at 01:51:33AM +0900, Masahiro Yamada wrote:
> 2017-12-22 4:10 GMT+09:00 Lukas Bulwahn <lukas.bulwahn@gmail.com>:
> > do_config_file() should exit with an error code, and not return if it fails
> > as then the error in do_config_file() would go unnoticed in the current
> > code and allow the build to continue. The exit with error code will make
> > the build fail in those very exceptional cases. If this occurs, this
> > actually indicates a deeper problem in the execution of the kernel build
> > process.
> >
> > Now, that the function exists, we do not explicitly free memory and close
> > the file handlers in do_config_file(), as this is covered by exit().
> >
> > This issue in the fixdep script was introduced with its initial
> > implementation back in 2002 by the original author Kai Germaschewski with
> > this commit 04bd72170653 ("kbuild: Make dependencies at compile time").
>
> "04bd72170653" is just confusing.
>
> If you really want to mention this hash,
> please clearly say it is in the history repository
> outside of this.
>
>
> > This issue was identified during the review of a previous patch that
> > intended to address a memory leak detected by a static analysis tool.
> >
> > Link: https://lkml.org/lkml/2017/12/14/736
> >
> > Fixes: 04bd72170653 ("kbuild: Make dependencies at compile time")
>
> Please drop this pointless Fixes tag
> because that commit is not reachable from this patch.
>
>
>
> > Suggested-by: Nicholas Mc Guire <der.herr@hofr.at>
> > Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
> > ---
> > compile tested on top of next-20171220 with clang and gcc
> > Change in v2:
> > - no code change; only include proper Fixes tag and explain it
> >
> > scripts/basic/fixdep.c | 11 +++++------
> > 1 file changed, 5 insertions(+), 6 deletions(-)
> >
> > diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
> > index bbf62cb..4274610 100644
> > --- a/scripts/basic/fixdep.c
> > +++ b/scripts/basic/fixdep.c
> > @@ -284,19 +284,18 @@ static void do_config_file(const char *filename)
> > exit(2);
> > }
> > if (st.st_size == 0) {
> > - close(fd);
> > - return;
> > + fprintf(stderr, "fixdep: error empty file config file: ");
> > + perror(filename);
> > + exit(2);
> > }
>
> No. This is correct as-is.
>
> do_config_file() does not parse .cmd files
> but parse source files (.c .h .S etc.)
>
What case for a legitimately empty source file would there be ?
the files being checked are assumed to be mandatory for the
given configuration right ? if so how can a configuration depend
on an empty file ? would that not point to a config problem and
rather be fixed there ? or am I misunderstanding this here ?
> Having an empty source file is rare, but possible.
>
putting a printf in the empty case handling and running a set of
randconfigs did not reveal such an event (10 runs).
thx!
hofrat
>
>
>
>
>
> > map = malloc(st.st_size + 1);
> > if (!map) {
> > perror("fixdep: malloc");
> > - close(fd);
> > - return;
> > + exit(2);
> > }
> > if (read(fd, map, st.st_size) != st.st_size) {
> > perror("fixdep: read");
> > - close(fd);
> > - return;
> > + exit(2);
> > }
> > map[st.st_size] = '\0';
> > close(fd);
> > --
> > 2.7.4
> >
>
> These two changes are OK.
>
>
>
> --
> Best Regards
> Masahiro Yamada
next prev parent reply other threads:[~2017-12-31 15:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-20 20:27 [PATCH] fixdep: exit with error code in error branches of do_config_file() Lukas Bulwahn
2017-12-21 15:33 ` Nicholas Mc Guire
2017-12-21 19:10 ` [PATCH v2] " Lukas Bulwahn
2017-12-30 16:51 ` Masahiro Yamada
2017-12-31 15:45 ` Nicholas Mc Guire [this message]
2018-01-01 6:41 ` Masahiro Yamada
2018-01-01 9:31 ` Nicholas Mc Guire
2018-01-01 9:55 ` Sam Ravnborg
2018-01-08 10:17 ` Lukas Bulwahn
2018-01-09 8:39 ` Masahiro Yamada
2018-01-08 10:04 ` [PATCH v3] " Lukas Bulwahn
2018-01-09 8:26 ` Masahiro Yamada
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=20171231154548.GA27372@osadl.at \
--to=der.herr@hofr.at \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=michal.lkml@markovi.net \
--cc=sil2review@lists.osadl.org \
--cc=yamada.masahiro@socionext.com \
/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