1. 15 12月, 2016 2 次提交
  2. 14 12月, 2016 3 次提交
  3. 13 12月, 2016 4 次提交
    • K
      proc: report no_new_privs state · af884cd4
      Kees Cook 提交于
      Similar to being able to examine if a process has been correctly
      confined with seccomp, the state of no_new_privs is equally interesting,
      so this adds it to /proc/$pid/status.
      
      Link: http://lkml.kernel.org/r/20161103214041.GA58566@beastSigned-off-by: NKees Cook <keescook@chromium.org>
      Reviewed-by: NJann Horn <jann@thejh.net>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Rodrigo Freire <rfreire@redhat.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Cc: Robert Ho <robert.hu@intel.com>
      Cc: Jerome Marchand <jmarchan@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: "Richard W.M. Jones" <rjones@redhat.com>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      af884cd4
    • H
      mm: make transparent hugepage size public · 49920d28
      Hugh Dickins 提交于
      Test programs want to know the size of a transparent hugepage.  While it
      is commonly the same as the size of a hugetlbfs page (shown as
      Hugepagesize in /proc/meminfo), that is not always so: powerpc
      implements transparent hugepages in a different way from hugetlbfs
      pages, so it's coincidence when their sizes are the same; and x86 and
      others can support more than one hugetlbfs page size.
      
      Add /sys/kernel/mm/transparent_hugepage/hpage_pmd_size to show the THP
      size in bytes - it's the same for Anonymous and Shmem hugepages.  Call
      it hpage_pmd_size (after HPAGE_PMD_SIZE) rather than hpage_size, in case
      some transparent support for pud and pgd pages is added later.
      
      Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1612052200290.13021@eggly.anvilsSigned-off-by: NHugh Dickins <hughd@google.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      49920d28
    • R
      dt: add documentation of "hotpluggable" memory property · c3352cbb
      Reza Arbab 提交于
      Summarize the "hotpluggable" property of dt memory nodes.
      
      Link: http://lkml.kernel.org/r/1479160961-25840-6-git-send-email-arbab@linux.vnet.ibm.comSigned-off-by: NReza Arbab <arbab@linux.vnet.ibm.com>
      Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Alistair Popple <apopple@au1.ibm.com>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Balbir Singh <bsingharora@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Bharata B Rao <bharata@linux.vnet.ibm.com>
      Cc: Frank Rowand <frowand.list@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Stewart Smith <stewart@linux.vnet.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c3352cbb
    • R
      mm: remove x86-only restriction of movable_node · 39fa104d
      Reza Arbab 提交于
      In commit c5320926 ("mem-hotplug: introduce movable_node boot
      option"), the memblock allocation direction is changed to bottom-up and
      then back to top-down like this:
      
      1. memblock_set_bottom_up(true), called by cmdline_parse_movable_node().
      2. memblock_set_bottom_up(false), called by x86's numa_init().
      
      Even though (1) occurs in generic mm code, it is wrapped by #ifdef
      CONFIG_MOVABLE_NODE, which depends on X86_64.
      
      This means that when we extend CONFIG_MOVABLE_NODE to non-x86 arches,
      things will be unbalanced.  (1) will happen for them, but (2) will not.
      
      This toggle was added in the first place because x86 has a delay between
      adding memblocks and marking them as hotpluggable.  Since other arches
      do this marking either immediately or not at all, they do not require
      the bottom-up toggle.
      
      So, resolve things by moving (1) from cmdline_parse_movable_node() to
      x86's setup_arch(), immediately after the movable_node parameter has
      been parsed.
      
      Link: http://lkml.kernel.org/r/1479160961-25840-3-git-send-email-arbab@linux.vnet.ibm.comSigned-off-by: NReza Arbab <arbab@linux.vnet.ibm.com>
      Acked-by: NBalbir Singh <bsingharora@gmail.com>
      Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Alistair Popple <apopple@au1.ibm.com>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Bharata B Rao <bharata@linux.vnet.ibm.com>
      Cc: Frank Rowand <frowand.list@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Stewart Smith <stewart@linux.vnet.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      39fa104d
  4. 12 12月, 2016 3 次提交
    • S
      i2c: sh_mobile: Add per-Generation fallback bindings · b880ccaf
      Simon Horman 提交于
      Add per-Generation fallback bindings for R-Car SoCs.
      
      This is in keeping with the compatibility string scheme is being adopted
      for drivers for Renesas SoCs.
      
      Also, improve readability by listing the rmobile fallback compatibility
      string after the more-specific compatibility strings they provide a
      fallback for.
      Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
      Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      b880ccaf
    • S
      i2c: rcar: Add per-Generation fallback bindings · ad4a8dc3
      Simon Horman 提交于
      In the case of Renesas R-Car hardware we know that there are generations of
      SoCs, e.g. Gen 2 and Gen 3. But beyond that it's not clear what the
      relationship between IP blocks might be. For example, I believe that
      r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
      descendant of the former or vice versa.
      
      We can, however, by examining the documentation and behaviour of the
      hardware at run-time observe that the current driver implementation appears
      to be compatible with the IP blocks on SoCs within a given generation.
      
      For the above reasons and convenience when enabling new SoCs a
      per-generation fallback compatibility string scheme is being adopted for
      drivers for Renesas SoCs.
      
      Also:
      * Deprecate renesas,i2c-rcar. It seems poorly named as it is only
        compatible with R-Car Gen 1. It also appears unused in mainline.
      * Add some text to describe per-SoC bindings
      Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
      Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      ad4a8dc3
    • D
      dma-buf: Extract dma-buf.rst · 868c97a8
      Daniel Vetter 提交于
      Just prep work to polish and consolidate all the dma-buf related
      documenation.
      
      Unfortunately I didn't discover a way to both integrate this new file
      into the overall toc while keeping it at the current place. Work
      around that by moving it into the overall driver-api/index.rst.
      
      Cc: linux-doc@vger.kernel.org
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      868c97a8
  5. 11 12月, 2016 1 次提交
  6. 10 12月, 2016 10 次提交
  7. 09 12月, 2016 11 次提交
  8. 08 12月, 2016 5 次提交
  9. 07 12月, 2016 1 次提交