Skip to content
Snippets Groups Projects
  1. Sep 28, 2022
  2. Jul 18, 2022
    • Dan Moulding's avatar
      init: add "hostname" kernel parameter · 5a704629
      Dan Moulding authored
      The gethostname system call returns the hostname for the current machine. 
      However, the kernel has no mechanism to initially set the current
      machine's name in such a way as to guarantee that the first userspace
      process to call gethostname will receive a meaningful result.  It relies
      on some unspecified userspace process to first call sethostname before
      gethostname can produce a meaningful name.
      
      Traditionally the machine's hostname is set from userspace by the init
      system.  The init system, in turn, often relies on a configuration file
      (say, /etc/hostname) to provide the value that it will supply in the call
      to sethostname.  Consequently, the file system containing /etc/hostname
      usually must be available before the hostname will be set.  There may,
      however, be earlier userspace processes that could call gethostname before
      the file system containing /etc/hostname is mounted.  Such a process will
      get some other, likely meaningless, name from gethostname (such as
      "(none)", "localhost", or "darkstar").
      
      A real-world example where this can happen, and lead to undesirable
      results, is with mdadm.  When assembling arrays, mdadm distinguishes
      between "local" arrays and "foreign" arrays.  A local array is one that
      properly belongs to the current machine, and a foreign array is one that
      is (possibly temporarily) attached to the current machine, but properly
      belongs to some other machine.  To determine if an array is local or
      foreign, mdadm may compare the "homehost" recorded on the array with the
      current hostname.  If mdadm is run before the root file system is mounted,
      perhaps because the root file system itself resides on an md-raid array,
      then /etc/hostname isn't yet available and the init system will not yet
      have called sethostname, causing mdadm to incorrectly conclude that all of
      the local arrays are foreign.
      
      Solving this problem *could* be delegated to the init system.  It could be
      left up to the init system (including any init system that starts within
      an initramfs, if one is in use) to ensure that sethostname is called
      before any other userspace process could possibly call gethostname. 
      However, it may not always be obvious which processes could call
      gethostname (for example, udev itself might not call gethostname, but it
      could via udev rules invoke processes that do).  Additionally, the init
      system has to ensure that the hostname configuration value is stored in
      some place where it will be readily accessible during early boot. 
      Unfortunately, every init system will attempt to (or has already attempted
      to) solve this problem in a different, possibly incorrect, way.  This
      makes getting consistently working configurations harder for users.
      
      I believe it is better for the kernel to provide the means by which the
      hostname may be set early, rather than making this a problem for the init
      system to solve.  The option to set the hostname during early startup, via
      a kernel parameter, provides a simple, reliable way to solve this problem.
      It also could make system configuration easier for some embedded systems.
      
      [dmoulding@me.com: v2]
        Link: https://lkml.kernel.org/r/20220506060310.7495-2-dmoulding@me.com
      Link: https://lkml.kernel.org/r/20220505180651.22849-2-dmoulding@me.com
      
      
      Signed-off-by: default avatarDan Moulding <dmoulding@me.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      5a704629
  3. Apr 24, 2021
    • Yonghong Song's avatar
      kbuild: add an elfnote for whether vmlinux is built with lto · 1fdd7433
      Yonghong Song authored
      Currently, clang LTO built vmlinux won't work with pahole.
      LTO introduced cross-cu dwarf tag references and broke
      current pahole model which handles one cu as a time.
      The solution is to merge all cu's as one pahole cu as in [1].
      We would like to do this merging only if cross-cu dwarf
      references happens. The LTO build mode is a pretty good
      indication for that.
      
      In earlier version of this patch ([2]), clang flag
      -grecord-gcc-switches is proposed to add to compilation flags
      so pahole could detect "-flto" and then merging cu's.
      This will increate the binary size of 1% without LTO though.
      
      Arnaldo suggested to use a note to indicate the vmlinux
      is built with LTO. Such a cheap way to get whether the vmlinux
      is built with LTO or not helps pahole but is also useful
      for tracing as LTO may inline/delete/demote global functions,
      promote static functions, etc.
      
      So this patch added an elfnote with a new type LINUX_ELFNOTE_LTO_INFO.
      The owner of the note is "Linux".
      
      With gcc 8.4.1 and clang trunk, without LTO, I got
        $ readelf -n vmlinux
        Displaying notes found in: .notes
          Owner                Data size        Description
        ...
          Linux                0x00000004       func
           description data: 00 00 00 00
        ...
      With "readelf -x ".notes" vmlinux", I can verify the above "func"
      with type code 0x101.
      
      With clang thin-LTO, I got the same as above except the following:
           description data: 01 00 00 00
      which indicates the vmlinux is built with LTO.
      
        [1] https://lore.kernel.org/bpf/20210325065316.3121287-1-yhs@fb.com/
        [2] https://lore.kernel.org/bpf/20210331001623.2778934-1-yhs@fb.com/
      
      
      
      Suggested-by: default avatarArnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v12.0.0-rc4 (x86-64)
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      1fdd7433
  4. Feb 26, 2021
  5. Aug 19, 2020
    • Kirill Tkhai's avatar
      uts: Use generic ns_common::count · 9a56493f
      Kirill Tkhai authored
      
      Switch over uts namespaces to use the newly introduced common lifetime
      counter.
      
      Currently every namespace type has its own lifetime counter which is stored
      in the specific namespace struct. The lifetime counters are used
      identically for all namespaces types. Namespaces may of course have
      additional unrelated counters and these are not altered.
      
      This introduces a common lifetime counter into struct ns_common. The
      ns_common struct encompasses information that all namespaces share. That
      should include the lifetime counter since its common for all of them.
      
      It also allows us to unify the type of the counters across all namespaces.
      Most of them use refcount_t but one uses atomic_t and at least one uses
      kref. Especially the last one doesn't make much sense since it's just a
      wrapper around refcount_t since 2016 and actually complicates cleanup
      operations by having to use container_of() to cast the correct namespace
      struct out of struct ns_common.
      
      Having the lifetime counter for the namespaces in one place reduces
      maintenance cost. Not just because after switching all namespaces over we
      will have removed more code than we added but also because the logic is
      more easily understandable and we indicate to the user that the basic
      lifetime requirements for all namespaces are currently identical.
      
      Signed-off-by: default avatarKirill Tkhai <ktkhai@virtuozzo.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarChristian Brauner <christian.brauner@ubuntu.com>
      Link: https://lore.kernel.org/r/159644978167.604812.1773586504374412107.stgit@localhost.localdomain
      
      
      Signed-off-by: default avatarChristian Brauner <christian.brauner@ubuntu.com>
      9a56493f
  6. May 21, 2019
  7. Jul 17, 2018
    • Laura Abbott's avatar
      kbuild: Add build salt to the kernel and modules · 9afb719e
      Laura Abbott authored
      
      In Fedora, the debug information is packaged separately (foo-debuginfo) and
      can be installed separately. There's been a long standing issue where only
      one version of a debuginfo info package can be installed at a time. There's
      been an effort for Fedora for parallel debuginfo to rectify this problem.
      
      Part of the requirement to allow parallel debuginfo to work is that build ids
      are unique between builds. The existing upstream rpm implementation ensures
      this by re-calculating the build-id using the version and release as a
      seed. This doesn't work 100% for the kernel because of the vDSO which is
      its own binary and doesn't get updated when embedded.
      
      Fix this by adding some data in an ELF note for both the kernel and modules.
      The data is controlled via a Kconfig option so distributions can set it
      to an appropriate value to ensure uniqueness between builds.
      
      Suggested-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarLaura Abbott <labbott@redhat.com>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      9afb719e
  8. Nov 18, 2017
  9. Jan 14, 2017
    • Peter Zijlstra's avatar
      locking/atomic, kref: Add KREF_INIT() · 1e24edca
      Peter Zijlstra authored
      
      Since we need to change the implementation, stop exposing internals.
      
      Provide KREF_INIT() to allow static initialization of struct kref.
      
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      1e24edca
  10. Dec 04, 2014
  11. May 01, 2013
  12. Nov 20, 2012
    • Eric W. Biederman's avatar
      proc: Usable inode numbers for the namespace file descriptors. · 98f842e6
      Eric W. Biederman authored
      
      Assign a unique proc inode to each namespace, and use that
      inode number to ensure we only allocate at most one proc
      inode for every namespace in proc.
      
      A single proc inode per namespace allows userspace to test
      to see if two processes are in the same namespace.
      
      This has been a long requested feature and only blocked because
      a naive implementation would put the id in a global space and
      would ultimately require having a namespace for the names of
      namespaces, making migration and certain virtualization tricks
      impossible.
      
      We still don't have per superblock inode numbers for proc, which
      appears necessary for application unaware checkpoint/restart and
      migrations (if the application is using namespace file descriptors)
      but that is now allowd by the design if it becomes important.
      
      I have preallocated the ipc and uts initial proc inode numbers so
      their structures can be statically initialized.
      
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      98f842e6
  13. Mar 24, 2011
    • Serge E. Hallyn's avatar
      userns: add a user_namespace as creator/owner of uts_namespace · 59607db3
      Serge E. Hallyn authored
      The expected course of development for user namespaces targeted
      capabilities is laid out at https://wiki.ubuntu.com/UserNamespace
      
      .
      
      Goals:
      
      - Make it safe for an unprivileged user to unshare namespaces.  They
        will be privileged with respect to the new namespace, but this should
        only include resources which the unprivileged user already owns.
      
      - Provide separate limits and accounting for userids in different
        namespaces.
      
      Status:
      
        Currently (as of 2.6.38) you can clone with the CLONE_NEWUSER flag to
        get a new user namespace if you have the CAP_SYS_ADMIN, CAP_SETUID, and
        CAP_SETGID capabilities.  What this gets you is a whole new set of
        userids, meaning that user 500 will have a different 'struct user' in
        your namespace than in other namespaces.  So any accounting information
        stored in struct user will be unique to your namespace.
      
        However, throughout the kernel there are checks which
      
        - simply check for a capability.  Since root in a child namespace
          has all capabilities, this means that a child namespace is not
          constrained.
      
        - simply compare uid1 == uid2.  Since these are the integer uids,
          uid 500 in namespace 1 will be said to be equal to uid 500 in
          namespace 2.
      
        As a result, the lxc implementation at lxc.sf.net does not use user
        namespaces.  This is actually helpful because it leaves us free to
        develop user namespaces in such a way that, for some time, user
        namespaces may be unuseful.
      
      Bugs aside, this patchset is supposed to not at all affect systems which
      are not actively using user namespaces, and only restrict what tasks in
      child user namespace can do.  They begin to limit privilege to a user
      namespace, so that root in a container cannot kill or ptrace tasks in the
      parent user namespace, and can only get world access rights to files.
      Since all files currently belong to the initila user namespace, that means
      that child user namespaces can only get world access rights to *all*
      files.  While this temporarily makes user namespaces bad for system
      containers, it starts to get useful for some sandboxing.
      
      I've run the 'runltplite.sh' with and without this patchset and found no
      difference.
      
      This patch:
      
      copy_process() handles CLONE_NEWUSER before the rest of the namespaces.
      So in the case of clone(CLONE_NEWUSER|CLONE_NEWUTS) the new uts namespace
      will have the new user namespace as its owner.  That is what we want,
      since we want root in that new userns to be able to have privilege over
      it.
      
      Changelog:
      	Feb 15: don't set uts_ns->user_ns if we didn't create
      		a new uts_ns.
      	Feb 23: Move extern init_user_ns declaration from
      		init/version.c to utsname.h.
      
      Signed-off-by: default avatarSerge E. Hallyn <serge.hallyn@canonical.com>
      Acked-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: default avatarDaniel Lezcano <daniel.lezcano@free.fr>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: James Morris <jmorris@namei.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      59607db3
  14. Dec 12, 2009
  15. Jul 25, 2008
  16. Feb 14, 2007
    • Tim Schmielau's avatar
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau authored
      
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      
      Signed-off-by: default avatarTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  17. Jan 12, 2007
    • Linus Torvalds's avatar
      Don't put "linux_banner" in the .init section · c71551ad
      Linus Torvalds authored
      
      It might save a few bytes after bootup, but it causes the string to be
      linked in at the end of the final vmlinux image, which defeats the whole
      point of doing all this, namely allowing some broken user-space binaries
      to search for the kernel version string in the kernel binary.
      
      So just remove the __init specifier.
      
      Cc: Olaf Hering <olaf@aepfle.de>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Andrey Borzenkov <arvidjaar@mail.ru>
      Cc: Andrew Morton <akpm@osdl.org>
      Acked-by: default avatarAndy Whitcroft <apw@shadowen.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c71551ad
  18. Jan 10, 2007
  19. Dec 11, 2006
    • Linus Torvalds's avatar
      Make SLES9 "get_kernel_version" work on the kernel binary again · 8993780a
      Linus Torvalds authored
      
      As reported by Andy Whitcroft, at least the SLES9 initrd build process
      depends on getting the kernel version from the kernel binary.  It does
      that by simply trawling the binary and looking for the signature of the
      "linux_banner" string (the string "Linux version " to be exact. Which
      is really broken in itself, but whatever..)
      
      That got broken when the string was changed to allow /proc/version to
      change the UTS release information dynamically, and "get_kernel_version"
      thus returned "%s" (see commit a2ee8649:
      "[PATCH] Fix linux banner utsname information").
      
      This just restores "linux_banner" as a static string, which should fix
      the version finding.  And /proc/version simply uses a different string.
      
      To avoid wasting even that miniscule amount of memory, the early boot
      string should really be marked __initdata, but that just causes the same
      bug in SLES9 to re-appear, since it will then find other occurrences of
      "Linux version " first.
      
      Cc: Andy Whitcroft <apw@shadowen.org>
      Acked-by: default avatarHerbert Poetzl <herbert@13thfloor.at>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Andrew Morton <akpm@osdl.org>
      Cc: Steve Fox <drfickle@us.ibm.com>
      Acked-by: default avatarOlaf Hering <olaf@aepfle.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      8993780a
  20. Dec 08, 2006
  21. Oct 02, 2006
  22. Jul 03, 2006
    • Sam Ravnborg's avatar
      kbuild: introduce utsrelease.h · 63104eec
      Sam Ravnborg authored
      
      include/linux/version.h contained both actual KERNEL version
      and UTS_RELEASE that contains a subset from git SHA1 for when
      kernel was compiled as part of a git repository.
      This had the unfortunate side-effect that all files including version.h
      would be recompiled when some git changes was made due to changes SHA1.
      Split it out so we keep independent parts in separate files.
      
      Also update checkversion.pl script to no longer check for UTS_RELEASE.
      
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      63104eec
  23. Apr 17, 2005
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
Loading