linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Michal Marek <mmarek@suse.cz>
Cc: Jan Beulich <JBeulich@suse.com>,
	dt.tangr@gmail.com, Geert Uytterhoeven <geert@linux-m68k.org>,
	James Hogan <james.hogan@imgtec.com>,
	Christian Kujau <lists@nerdbynature.de>,
	Mike Marciniszyn <mike.marciniszyn@intel.com>,
	Nicolas Dichtel <nicolas.dichtel@6wind.com>,
	robert.richter@calxeda.com,
	"Yaakov (Cygwin/X)" <yselkowitz@users.sourceforge.net>,
	zzs0213@gmail.com,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT] kbuild changes for v3.11-rc1
Date: Thu, 11 Jul 2013 10:16:18 -0700	[thread overview]
Message-ID: <CA+55aFyVjugxM7cUDWi0ASWttYthCxa6e7X3CADknBcSFxWgew@mail.gmail.com> (raw)
In-Reply-To: <20130711135445.GA21500@sepie.suse.cz>

On Thu, Jul 11, 2013 at 6:54 AM, Michal Marek <mmarek@suse.cz> wrote:
>
> Yeah. It also reveals another bug that we rewrite the kernel.release
> file each time. This patch should fix it, but please do not apply it
> yet:

So I think not rewriting the file is a good thing, but in this case it
would actually have hidden the real bug.

At least for most people. For me, it would have rewritten the file
anyway, because as a normal user I have

  core.abbrev=12

in my ~/.gitconfig, but when running it as root, it will take the
abbrev setting from the git defaults (which I think is 7). So the
content actually *changes* if root generates the version as opposed to
my normal user account.

Of course, that's arguably something we could fix in our localversion
script (by just forcing a particular abbreviation length), but I
actually like how a plain "git describe" (which will use the
user-specified SHA1 abbreviations) matches "uname -r" (which will
obviously take the version from the kernel version file at
build-time). So I'm not convinced that it is wrong for us to just use
the format that the user specified in their gitconfig, even if it does
result in "odd" situations like this where "make kernelrelease" will
then potentially give different output for different users.

> We also run dozens of gcc checks during every make invocation, including
> make install or make help, so there is some room for improvement. But at
> least, these do not write to the source or object tree.

It would be good to try to minimize these kinds of things, for the
simple reason that I'm not at all sure that we necessarily get all the
temporary file security issues right.

Running as little as possible as root is good practice for a very real
reason: there can be very subtle security issues. Let's not worry
about it *too* much, but keeping it in mind is good.

At least for the gcc checking scripts I looked at, we seem to be doing
things safely (ie using pipes instead of temp-files in /tmp).

              Linus

  reply	other threads:[~2013-07-11 17:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-10 13:37 [GIT] kbuild changes for v3.11-rc1 Michal Marek
2013-07-11  2:11 ` Linus Torvalds
2013-07-11  4:26   ` Greg KH
2013-07-11 13:54   ` Michal Marek
2013-07-11 17:16     ` Linus Torvalds [this message]
2013-07-12 10:57       ` Robert Richter
2013-07-17 16:05         ` [PATCH] arm, kbuild: make "make install" not depend on vmlinux Robert Richter
2013-07-17 16:36           ` Linus Torvalds
2013-07-17 16:57             ` Robert Richter
2013-07-17 17:03               ` Linus Torvalds
2013-07-18  9:22                 ` Michal Marek
2013-09-30  8:49                   ` Robert Richter
2013-09-30 16:31                     ` Yann E. MORIN
2013-10-09  7:18                       ` Geert Uytterhoeven
2013-10-09 10:28                         ` Michal Marek
2013-10-09 10:46                           ` Geert Uytterhoeven

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=CA+55aFyVjugxM7cUDWi0ASWttYthCxa6e7X3CADknBcSFxWgew@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=JBeulich@suse.com \
    --cc=dt.tangr@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=james.hogan@imgtec.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lists@nerdbynature.de \
    --cc=mike.marciniszyn@intel.com \
    --cc=mmarek@suse.cz \
    --cc=nicolas.dichtel@6wind.com \
    --cc=robert.richter@calxeda.com \
    --cc=yselkowitz@users.sourceforge.net \
    --cc=zzs0213@gmail.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;
as well as URLs for NNTP newsgroup(s).