1. 01 5月, 2019 1 次提交
  2. 26 4月, 2019 1 次提交
  3. 18 4月, 2019 4 次提交
    • J
      s390/speculation: Support 'mitigations=' cmdline option · 0336e04a
      Josh Poimboeuf 提交于
      Configure s390 runtime CPU speculation bug mitigations in accordance
      with the 'mitigations=' cmdline option.  This affects Spectre v1 and
      Spectre v2.
      
      The default behavior is unchanged.
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: Jiri Kosina <jkosina@suse.cz> (on x86)
      Reviewed-by: NJiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Jiri Kosina <jikos@kernel.org>
      Cc: Waiman Long <longman@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Jon Masters <jcm@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: linux-s390@vger.kernel.org
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-arch@vger.kernel.org
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Steven Price <steven.price@arm.com>
      Cc: Phil Auld <pauld@redhat.com>
      Link: https://lkml.kernel.org/r/e4a161805458a5ec88812aac0307ae3908a030fc.1555085500.git.jpoimboe@redhat.com
      0336e04a
    • J
      powerpc/speculation: Support 'mitigations=' cmdline option · 782e69ef
      Josh Poimboeuf 提交于
      Configure powerpc CPU runtime speculation bug mitigations in accordance
      with the 'mitigations=' cmdline option.  This affects Meltdown, Spectre
      v1, Spectre v2, and Speculative Store Bypass.
      
      The default behavior is unchanged.
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: Jiri Kosina <jkosina@suse.cz> (on x86)
      Reviewed-by: NJiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Jiri Kosina <jikos@kernel.org>
      Cc: Waiman Long <longman@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Jon Masters <jcm@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: linux-s390@vger.kernel.org
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-arch@vger.kernel.org
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Steven Price <steven.price@arm.com>
      Cc: Phil Auld <pauld@redhat.com>
      Link: https://lkml.kernel.org/r/245a606e1a42a558a310220312d9b6adb9159df6.1555085500.git.jpoimboe@redhat.com
      782e69ef
    • J
      x86/speculation: Support 'mitigations=' cmdline option · d68be4c4
      Josh Poimboeuf 提交于
      Configure x86 runtime CPU speculation bug mitigations in accordance with
      the 'mitigations=' cmdline option.  This affects Meltdown, Spectre v2,
      Speculative Store Bypass, and L1TF.
      
      The default behavior is unchanged.
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: Jiri Kosina <jkosina@suse.cz> (on x86)
      Reviewed-by: NJiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Jiri Kosina <jikos@kernel.org>
      Cc: Waiman Long <longman@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Jon Masters <jcm@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: linux-s390@vger.kernel.org
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-arch@vger.kernel.org
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Steven Price <steven.price@arm.com>
      Cc: Phil Auld <pauld@redhat.com>
      Link: https://lkml.kernel.org/r/6616d0ae169308516cfdf5216bedd169f8a8291b.1555085500.git.jpoimboe@redhat.com
      d68be4c4
    • J
      cpu/speculation: Add 'mitigations=' cmdline option · 98af8452
      Josh Poimboeuf 提交于
      Keeping track of the number of mitigations for all the CPU speculation
      bugs has become overwhelming for many users.  It's getting more and more
      complicated to decide which mitigations are needed for a given
      architecture.  Complicating matters is the fact that each arch tends to
      have its own custom way to mitigate the same vulnerability.
      
      Most users fall into a few basic categories:
      
      a) they want all mitigations off;
      
      b) they want all reasonable mitigations on, with SMT enabled even if
         it's vulnerable; or
      
      c) they want all reasonable mitigations on, with SMT disabled if
         vulnerable.
      
      Define a set of curated, arch-independent options, each of which is an
      aggregation of existing options:
      
      - mitigations=off: Disable all mitigations.
      
      - mitigations=auto: [default] Enable all the default mitigations, but
        leave SMT enabled, even if it's vulnerable.
      
      - mitigations=auto,nosmt: Enable all the default mitigations, disabling
        SMT if needed by a mitigation.
      
      Currently, these options are placeholders which don't actually do
      anything.  They will be fleshed out in upcoming patches.
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: Jiri Kosina <jkosina@suse.cz> (on x86)
      Reviewed-by: NJiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Jiri Kosina <jikos@kernel.org>
      Cc: Waiman Long <longman@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Jon Masters <jcm@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: linux-s390@vger.kernel.org
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-arch@vger.kernel.org
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Steven Price <steven.price@arm.com>
      Cc: Phil Auld <pauld@redhat.com>
      Link: https://lkml.kernel.org/r/b07a8ef9b7c5055c3a4637c87d07c296d5016fe0.1555085500.git.jpoimboe@redhat.com
      98af8452
  4. 13 3月, 2019 1 次提交
  5. 06 3月, 2019 2 次提交
    • C
      mm: memcontrol: expose THP events on a per-memcg basis · 1ff9e6e1
      Chris Down 提交于
      Currently THP allocation events data is fairly opaque, since you can
      only get it system-wide.  This patch makes it easier to reason about
      transparent hugepage behaviour on a per-memcg basis.
      
      For anonymous THP-backed pages, we already have MEMCG_RSS_HUGE in v1,
      which is used for v1's rss_huge [sic].  This is reused here as it's
      fairly involved to untangle NR_ANON_THPS right now to make it per-memcg,
      since right now some of this is delegated to rmap before we have any
      memcg actually assigned to the page.  It's a good idea to rework that,
      but let's leave untangling THP allocation for a future patch.
      
      [akpm@linux-foundation.org: fix build]
      [chris@chrisdown.name: fix memcontrol build when THP is disabled]
        Link: http://lkml.kernel.org/r/20190131160802.GA5777@chrisdown.name
      Link: http://lkml.kernel.org/r/20190129205852.GA7310@chrisdown.nameSigned-off-by: NChris Down <chris@chrisdown.name>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Roman Gushchin <guro@fb.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1ff9e6e1
    • D
      mm: convert PG_balloon to PG_offline · ca215086
      David Hildenbrand 提交于
      PG_balloon was introduced to implement page migration/compaction for
      pages inflated in virtio-balloon.  Nowadays, it is only a marker that a
      page is part of virtio-balloon and therefore logically offline.
      
      We also want to make use of this flag in other balloon drivers - for
      inflated pages or when onlining a section but keeping some pages offline
      (e.g.  used right now by XEN and Hyper-V via set_online_page_callback()).
      
      We are going to expose this flag to dump tools like makedumpfile.  But
      instead of exposing PG_balloon, let's generalize the concept of marking
      pages as logically offline, so it can be reused for other purposes later
      on.
      
      Rename PG_balloon to PG_offline.  This is an indicator that the page is
      logically offline, the content stale and that it should not be touched
      (e.g.  a hypervisor would have to allocate backing storage in order for
      the guest to dump an unused page).  We can then e.g.  exclude such pages
      from dumps.
      
      We replace and reuse KPF_BALLOON (23), as this shouldn't really harm
      (and for now the semantics stay the same).  In following patches, we
      will make use of this bit also in other balloon drivers.  While at it,
      document PGTABLE.
      
      [akpm@linux-foundation.org: fix comment text, per David]
      Link: http://lkml.kernel.org/r/20181119101616.8901-3-david@redhat.comSigned-off-by: NDavid Hildenbrand <david@redhat.com>
      Acked-by: NKonstantin Khlebnikov <koct9i@gmail.com>
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Acked-by: NPankaj gupta <pagupta@redhat.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: Christian Hansen <chansen3@cisco.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Pavel Tatashin <pasha.tatashin@oracle.com>
      Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Miles Chen <miles.chen@mediatek.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Kazuhito Hagio <k-hagio@ab.jp.nec.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Julien Freche <jfreche@vmware.com>
      Cc: Kairui Song <kasong@redhat.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Lianbo Jiang <lijiang@redhat.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Nadav Amit <namit@vmware.com>
      Cc: Omar Sandoval <osandov@fb.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Stefano Stabellini <sstabellini@kernel.org>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Xavier Deguillard <xdeguillard@vmware.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ca215086
  6. 26 2月, 2019 1 次提交
  7. 22 2月, 2019 2 次提交
  8. 18 2月, 2019 5 次提交
  9. 14 2月, 2019 1 次提交
    • F
      async: Add cmdline option to specify drivers to be async probed · 1ea61b68
      Feng Tang 提交于
      Asynchronous driver probing can help much on kernel fastboot, and
      this option can provide a flexible way to optimize and quickly verify
      async driver probe.
      
      Also it will help in below cases:
      * Some driver actually covers several families of HWs, some of which
        could use async probing while others don't. So we can't simply
        turn on the PROBE_PREFER_ASYNCHRONOUS flag in driver, but use this
        cmdline option, like igb driver async patch discussed at
        https://www.spinics.net/lists/netdev/msg545986.html
      
      * For SOC (System on Chip) with multiple spi or i2c controllers, most
        of the slave spi/i2c devices will be assigned with fixed controller
        number, while async probing may make those controllers get different
        index for each boot, which prevents those controller drivers to be
        async probed. For platforms not using these spi/i2c slave devices,
        they can use this cmdline option to benefit from the async probing.
      Suggested-by: NAlexander Duyck <alexander.h.duyck@linux.intel.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NFeng Tang <feng.tang@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ea61b68
  10. 09 2月, 2019 1 次提交
    • R
      Documentation: cgroup-v2: eliminate markup warnings · 34b43446
      Randy Dunlap 提交于
      Fix markup warnings in cgroup-v2.rst:
      
      Documentation/admin-guide/cgroup-v2.rst:1509: WARNING: Block quote ends without a blank line; unexpected unindent.
      Documentation/admin-guide/cgroup-v2.rst:1511: WARNING: Block quote ends without a blank line; unexpected unindent.
      Documentation/admin-guide/cgroup-v2.rst:1512: WARNING: Block quote ends without a blank line; unexpected unindent.
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Li Zefan <lizefan@huawei.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: cgroups@vger.kernel.org
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: linux-doc@vger.kernel.org
      Signed-off-by: NTejun Heo <tj@kernel.org>
      34b43446
  11. 07 2月, 2019 2 次提交
  12. 06 2月, 2019 1 次提交
  13. 04 2月, 2019 1 次提交
    • A
      efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation · 69c1f396
      Ard Biesheuvel 提交于
      Move the x86 EFI earlyprintk implementation to a shared location under
      drivers/firmware and tweak it slightly so we can expose it as an earlycon
      implementation (which is generic) rather than earlyprintk (which is only
      implemented for a few architectures)
      
      This also involves switching to write-combine mappings by default (which
      is required on ARM since device mappings lack memory semantics, and so
      memcpy/memset may not be used on them), and adding support for shared
      memory framebuffers on cache coherent non-x86 systems (which do not
      tolerate mismatched attributes).
      
      Note that 32-bit ARM does not populate its struct screen_info early
      enough for earlycon=efifb to work, so it is disabled there.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: NAlexander Graf <agraf@suse.de>
      Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
      Cc: Jeffrey Hugo <jhugo@codeaurora.org>
      Cc: Lee Jones <lee.jones@linaro.org>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20190202094119.13230-10-ard.biesheuvel@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      69c1f396
  14. 02 2月, 2019 1 次提交
  15. 31 1月, 2019 1 次提交
    • L
      iommu/vt-d: Leave scalable mode default off · 8950dcd8
      Lu Baolu 提交于
      Commit 765b6a98 ("iommu/vt-d: Enumerate the scalable
      mode capability") enables VT-d scalable mode if hardware
      advertises the capability. As we will bring up different
      features and use cases to upstream in different patch
      series, it will leave some intermediate kernel versions
      which support partial features. Hence, end user might run
      into problems when they use such kernels on bare metals
      or virtualization environments.
      
      This leaves scalable mode default off and end users could
      turn it on with "intel-iommu=sm_on" only when they have
      clear ideas about which scalable features are supported
      in the kernel.
      
      Cc: Liu Yi L <yi.l.liu@intel.com>
      Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
      Suggested-by: NAshok Raj <ashok.raj@intel.com>
      Suggested-by: NKevin Tian <kevin.tian@intel.com>
      Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      8950dcd8
  16. 26 1月, 2019 3 次提交
  17. 17 1月, 2019 1 次提交
    • R
      cpuidle: New timer events oriented governor for tickless systems · b26bf6ab
      Rafael J. Wysocki 提交于
      The venerable menu governor does some things that are quite
      questionable in my view.
      
      First, it includes timer wakeups in the pattern detection data and
      mixes them up with wakeups from other sources which in some cases
      causes it to expect what essentially would be a timer wakeup in a
      time frame in which no timer wakeups are possible (because it knows
      the time until the next timer event and that is later than the
      expected wakeup time).
      
      Second, it uses the extra exit latency limit based on the predicted
      idle duration and depending on the number of tasks waiting on I/O,
      even though those tasks may run on a different CPU when they are
      woken up.  Moreover, the time ranges used by it for the sleep length
      correction factors depend on whether or not there are tasks waiting
      on I/O, which again doesn't imply anything in particular, and they
      are not correlated to the list of available idle states in any way
      whatever.
      
      Also, the pattern detection code in menu may end up considering
      values that are too large to matter at all, in which cases running
      it is a waste of time.
      
      A major rework of the menu governor would be required to address
      these issues and the performance of at least some workloads (tuned
      specifically to the current behavior of the menu governor) is likely
      to suffer from that.  It is thus better to introduce an entirely new
      governor without them and let everybody use the governor that works
      better with their actual workloads.
      
      The new governor introduced here, the timer events oriented (TEO)
      governor, uses the same basic strategy as menu: it always tries to
      find the deepest idle state that can be used in the given conditions.
      However, it applies a different approach to that problem.
      
      First, it doesn't use "correction factors" for the time till the
      closest timer, but instead it tries to correlate the measured idle
      duration values with the available idle states and use that
      information to pick up the idle state that is most likely to "match"
      the upcoming CPU idle interval.
      
      Second, it doesn't take the number of "I/O waiters" into account at
      all and the pattern detection code in it avoids taking timer wakeups
      into account.  It also only uses idle duration values less than the
      current time till the closest timer (with the tick excluded) for that
      purpose.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      b26bf6ab
  18. 09 1月, 2019 3 次提交
    • T
      docs: Revamp tainted-kernels.rst to make it more comprehensible · 896dd323
      Thorsten Leemhuis 提交于
      Add a section about decoding /proc/sys/kernel/tainted, create a more
      understandable intro and a hopefully explain better the tainted flags in
      bugs, oops or panics messages. Only thing missing then is a table that
      quickly describes the various bits and taint flags before going into more
      detail, so add that as well.
      
      That table is partly based on a section from Documentation/sysctl/kernel.txt,
      but a bit more compact. To avoid confusion I added the shortened version to
      kernel.txt; the same table is used in three different places now:
      ./tools/debugging/kernel-chktaint,
      Documentation/admin-guide/tainted-kernels.rst and
      Documentation/sysctl/kernel.txt
      
      During review of v1 (see above) a number of existing issues with the text
      were raised, like outdated usages as well as incomplete or missing
      descriptions.  Address most of those as well.
      Signed-off-by: NThorsten Leemhuis <linux@leemhuis.info>
      [jc: tightened up changelog]
      Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      896dd323
    • C
      procfs: add smack subdir to attrs · 6d9c939d
      Casey Schaufler 提交于
      Back in 2007 I made what turned out to be a rather serious
      mistake in the implementation of the Smack security module.
      The SELinux module used an interface in /proc to manipulate
      the security context on processes. Rather than use a similar
      interface, I used the same interface. The AppArmor team did
      likewise. Now /proc/.../attr/current will tell you the
      security "context" of the process, but it will be different
      depending on the security module you're using.
      
      This patch provides a subdirectory in /proc/.../attr for
      Smack. Smack user space can use the "current" file in
      this subdirectory and never have to worry about getting
      SELinux attributes by mistake. Programs that use the
      old interface will continue to work (or fail, as the case
      may be) as before.
      
      The proposed S.A.R.A security module is dependent on
      the mechanism to create its own attr subdirectory.
      
      The original implementation is by Kees Cook.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      Reviewed-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      6d9c939d
    • K
      LSM: Introduce "lsm=" for boottime LSM selection · 79f7865d
      Kees Cook 提交于
      Provide a way to explicitly choose LSM initialization order via the new
      "lsm=" comma-separated list of LSMs.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      79f7865d
  19. 05 1月, 2019 1 次提交
  20. 04 1月, 2019 1 次提交
  21. 01 1月, 2019 1 次提交
  22. 29 12月, 2018 1 次提交
  23. 20 12月, 2018 1 次提交
  24. 14 12月, 2018 1 次提交
  25. 13 12月, 2018 1 次提交
  26. 11 12月, 2018 1 次提交