1. 08 Nov, 2017 2 commits
    • Matthew Garrett's avatar
      EVM: Allow userspace to signal an RSA key has been loaded · f00d7975
      Matthew Garrett authored
      
      
      EVM will only perform validation once a key has been loaded. This key
      may either be a symmetric trusted key (for HMAC validation and creation)
      or the public half of an asymmetric key (for digital signature
      validation). The /sys/kernel/security/evm interface allows userland to
      signal that a symmetric key has been loaded, but does not allow userland
      to signal that an asymmetric public key has been loaded.
      
      This patch extends the interface to permit userspace to pass a bitmask
      of loaded key types. It also allows userspace to block loading of a
      symmetric key in order to avoid a compromised system from being able to
      load an additional key type later.
      Signed-off-by: default avatarMatthew Garrett <mjg59@google.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      f00d7975
    • Rafael J. Wysocki's avatar
      PM / QoS: Fix device resume latency framework · 0759e80b
      Rafael J. Wysocki authored
      The special value of 0 for device resume latency PM QoS means
      "no restriction", but there are two problems with that.
      
      First, device resume latency PM QoS requests with 0 as the
      value are always put in front of requests with positive
      values in the priority lists used internally by the PM QoS
      framework, causing 0 to be chosen as an effective constraint
      value.  However, that 0 is then interpreted as "no restriction"
      effectively overriding the other requests with specific
      restrictions which is incorrect.
      
      Second, the users of device resume latency PM QoS have no
      way to specify that *any* resume latency at all should be
      avoided, which is an artificial limitation in general.
      
      To address these issues, modify device resume latency PM QoS to
      use S32_MAX as the "no constraint" value and 0 as the "no
      latency at all" one and rework its users (the cpuidle menu
      governor, the genpd QoS governor and the runtime PM framework)
      to follow these changes.
      
      Also add a special "n/a" value to the corresponding user space I/F
      to allow user space to indicate that it cannot accept any resume
      latencies at all for the given device.
      
      Fixes: 85dc0b8a (PM / QoS: Make it possible to expose PM QoS latency constraints)
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=197323
      
      Reported-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Tested-by: default avatarTero Kristo <t-kristo@ti.com>
      Reviewed-by: default avatarRamesh Thomas <ramesh.thomas@intel.com>
      0759e80b
  2. 03 Nov, 2017 1 commit
    • Paul Burton's avatar
      Update MIPS email addresses · fb615d61
      Paul Burton authored
      
      
      MIPS will soon not be a part of Imagination Technologies, and as such
      many @imgtec.com email addresses will no longer be valid. This patch
      updates the addresses for those who:
      
       - Have 10 or more patches in mainline authored using an @imgtec.com
         email address, or any patches dated within the past year.
      
       - Are still with Imagination but leaving as part of the MIPS business
         unit, as determined from an internal email address list.
      
       - Haven't already updated their email address (ie. JamesH) or expressed
         a desire to be excluded (ie. Maciej).
      
       - Acked v2 or earlier of this patch, which leaves Deng-Cheng, Matt &
         myself.
      
      New addresses are of the form firstname.lastname@mips.com, and all
      verified against an internal email address list.  An entry is added to
      .mailmap for each person such that get_maintainer.pl will report the new
      addresses rather than @imgtec.com addresses which will soon be dead.
      
      Instances of the affected addresses throughout the tree are then
      mechanically replaced with the new @mips.com address.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@mips.com>
      Acked-by: default avatarDengcheng Zhu <dengcheng.zhu@mips.com>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Matt Redfearn <matt.redfearn@mips.com>
      Acked-by: default avatarMatt Redfearn <matt.redfearn@mips.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: trivial@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fb615d61
  3. 31 Oct, 2017 2 commits
    • Paul Burton's avatar
      Update MIPS email addresses · 48c834be
      Paul Burton authored
      
      
      MIPS will soon not be a part of Imagination Technologies, and as such
      many @imgtec.com email addresses will no longer be valid. This patch
      updates the addresses for those who:
      
       - Have 10 or more patches in mainline authored using an @imgtec.com
         email address, or any patches dated within the past year.
      
       - Are still with Imagination but leaving as part of the MIPS business
         unit, as determined from an internal email address list.
      
       - Haven't already updated their email address (ie. JamesH) or expressed
         a desire to be excluded (ie. Maciej).
      
       - Acked v2 or earlier of this patch, which leaves Deng-Cheng, Matt &
         myself.
      
      New addresses are of the form firstname.lastname@mips.com, and all
      verified against an internal email address list. An entry is added to
      .mailmap for each person such that get_maintainer.pl will report the new
      addresses rather than @imgtec.com addresses which will soon be dead.
      
      Instances of the affected addresses throughout the tree are then
      mechanically replaced with the new @mips.com address.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@mips.com>
      Acked-by: default avatarDengcheng Zhu <dengcheng.zhu@mips.com>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Matt Redfearn <matt.redfearn@mips.com>
      Acked-by: default avatarMatt Redfearn <matt.redfearn@mips.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: trivial@kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/17540/
      
      Signed-off-by: default avatarJames Hogan <jhogan@kernel.org>
      48c834be
    • Rafael J. Wysocki's avatar
      Revert "PM / QoS: Fix device resume latency PM QoS" · d5919dcc
      Rafael J. Wysocki authored
      This reverts commit 0cc2b4e5 (PM / QoS: Fix device resume latency PM
      QoS) as it introduced regressions on multiple systems and the fix-up
      in commit 2a9a86d5 (PM / QoS: Fix default runtime_pm device resume
      latency) does not address all of them.
      
      The original problem that commit 0cc2b4e5 was attempting to fix
      will be addressed later.
      
      Fixes: 0cc2b4e5
      
       (PM / QoS: Fix device resume latency PM QoS)
      Reported-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d5919dcc
  4. 30 Oct, 2017 1 commit
  5. 24 Oct, 2017 1 commit
    • Rafael J. Wysocki's avatar
      PM / QoS: Fix device resume latency PM QoS · 0cc2b4e5
      Rafael J. Wysocki authored
      The special value of 0 for device resume latency PM QoS means
      "no restriction", but there are two problems with that.
      
      First, device resume latency PM QoS requests with 0 as the
      value are always put in front of requests with positive
      values in the priority lists used internally by the PM QoS
      framework, causing 0 to be chosen as an effective constraint
      value.  However, that 0 is then interpreted as "no restriction"
      effectively overriding the other requests with specific
      restrictions which is incorrect.
      
      Second, the users of device resume latency PM QoS have no
      way to specify that *any* resume latency at all should be
      avoided, which is an artificial limitation in general.
      
      To address these issues, modify device resume latency PM QoS to
      use S32_MAX as the "no constraint" value and 0 as the "no
      latency at all" one and rework its users (the cpuidle menu
      governor, the genpd QoS governor and the runtime PM framework)
      to follow these changes.
      
      Also add a special "n/a" value to the corresponding user space I/F
      to allow user space to indicate that it cannot accept any resume
      latencies at all for the given device.
      
      Fixes: 85dc0b8a (PM / QoS: Make it possible to expose PM QoS latency constraints)
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=197323
      
      Reported-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Tested-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarAlex Shi <alex.shi@linaro.org>
      Cc: All applicable <stable@vger.kernel.org>
      0cc2b4e5
  6. 21 Oct, 2017 1 commit
    • Lukas Wunner's avatar
      iio: dac: Add Texas Instruments 8/10/12-bit 2/4-channel DAC driver · 61011264
      Lukas Wunner authored
      
      
      The DACrrcS085 (rr = 08/10/12, c = 2/4) family of SPI DACs was
      inherited by TI when they acquired National Semiconductor in 2011.
      This driver was developed for and tested with the DAC082S085 built into
      the Revolution Pi by KUNBUS, but should work with any of the other
      chips as they share the same programming interface.
      
      There is also a family of I2C DACs with just a single channel called
      DACrr1C08x (rr = 08/10/12, x = 1/5).  Their programming interface is
      very similar and it should be possible to extend the driver for these
      chips with moderate effort.  Alternatively they could be integrated into
      ad5446.c.  (The AD5301/AD5311/AD5321 use different power-down modes but
      otherwise appear to be comparable.)
      
      Furthermore there is a family of 8-channel DACs called DACrr8S085
      (rr = 08/10/12) as well as two 16-bit DACs called DAC161Sxxx
      (xxx = 055/997).  These are more complicated devices with support for
      daisy-chaining and the ability to power down each channel separately.
      They could either be handled by a separate driver or integrated into the
      present driver with a larger effort.
      
      Cc: Mathias Duckeck <m.duckeck@kunbus.de>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      61011264
  7. 19 Oct, 2017 1 commit
  8. 14 Oct, 2017 2 commits
  9. 13 Oct, 2017 2 commits
  10. 12 Oct, 2017 2 commits
  11. 05 Oct, 2017 1 commit
  12. 04 Oct, 2017 1 commit
  13. 25 Sep, 2017 1 commit
  14. 07 Sep, 2017 3 commits
    • Daniel Colascione's avatar
      mm: add /proc/pid/smaps_rollup · 493b0e9d
      Daniel Colascione authored
      /proc/pid/smaps_rollup is a new proc file that improves the performance
      of user programs that determine aggregate memory statistics (e.g., total
      PSS) of a process.
      
      Android regularly "samples" the memory usage of various processes in
      order to balance its memory pool sizes.  This sampling process involves
      opening /proc/pid/smaps and summing certain fields.  For very large
      processes, sampling memory use this way can take several hundred
      milliseconds, due mostly to the overhead of the seq_printf calls in
      task_mmu.c.
      
      smaps_rollup improves the situation.  It contains most of the fields of
      /proc/pid/smaps, but instead of a set of fields for each VMA,
      smaps_rollup instead contains one synthetic smaps-format entry
      representing the whole process.  In the single smaps_rollup synthetic
      entry, each field is the summation of the corresponding field in all of
      the real-smaps VMAs.  Using a common format for smaps_rollup and smaps
      allows userspace parsers to repurpose parsers meant for use with
      non-rollup smaps for smaps_rollup, and it allows userspace to switch
      between smaps_rollup and smaps at runtime (say, based on the
      availability of smaps_rollup in a given kernel) with minimal fuss.
      
      By using smaps_rollup instead of smaps, a caller can avoid the
      significant overhead of formatting, reading, and parsing each of a large
      process's potentially very numerous memory mappings.  For sampling
      system_server's PSS in Android, we measured a 12x speedup, representing
      a savings of several hundred milliseconds.
      
      One alternative to a new per-process proc file would have been including
      PSS information in /proc/pid/status.  We considered this option but
      thought that PSS would be too expensive (by a few orders of magnitude)
      to collect relative to what's already emitted as part of
      /proc/pid/status, and slowing every user of /proc/pid/status for the
      sake of readers that happen to want PSS feels wrong.
      
      The code itself works by reusing the existing VMA-walking framework we
      use for regular smaps generation and keeping the mem_size_stats
      structure around between VMA walks instead of using a fresh one for each
      VMA.  In this way, summation happens automatically.  We let seq_file
      walk over the VMAs just as it does for regular smaps and just emit
      nothing to the seq_file until we hit the last VMA.
      
      Benchmarks:
      
          using smaps:
          iterations:1000 pid:1163 pss:220023808
          0m29.46s real 0m08.28s user 0m20.98s system
      
          using smaps_rollup:
          iterations:1000 pid:1163 pss:220702720
          0m04.39s real 0m00.03s user 0m04.31s system
      
      We're using the PSS samples we collect asynchronously for
      system-management tasks like fine-tuning oom_adj_score, memory use
      tracking for debugging, application-level memory-use attribution, and
      deciding whether we want to kill large processes during system idle
      maintenance windows.  Android has been using PSS for these purposes for
      a long time; as the average process VMA count has increased and and
      devices become more efficiency-conscious, PSS-collection inefficiency
      has started to matter more.  IMHO, it'd be a lot safer to optimize the
      existing PSS-collection model, which has been fine-tuned over the years,
      instead of changing the memory tracking approach entirely to work around
      smaps-generation inefficiency.
      
      Tim said:
      
      : There are two main reasons why Android gathers PSS information:
      :
      : 1. Android devices can show the user the amount of memory used per
      :    application via the settings app.  This is a less important use case.
      :
      : 2. We log PSS to help identify leaks in applications.  We have found
      :    an enormous number of bugs (in the Android platform, in Google's own
      :    apps, and in third-party applications) using this data.
      :
      : To do this, system_server (the main process in Android userspace) will
      : sample the PSS of a process three seconds after it changes state (for
      : example, app is launched and becomes the foreground application) and about
      : every ten minutes after that.  The net result is that PSS collection is
      : regularly running on at least one process in the system (usually a few
      : times a minute while the screen is on, less when screen is off due to
      : suspend).  PSS of a process is an incredibly useful stat to track, and we
      : aren't going to get rid of it.  We've looked at some very hacky approaches
      : using RSS ("take the RSS of the target process, subtract the RSS of the
      : zygote process that is the parent of all Android apps") to reduce the
      : accounting time, but it regularly overestimated the memory used by 20+
      : percent.  Accordingly, I don't think that there's a good alternative to
      : using PSS.
      :
      : We started looking into PSS collection performance after we noticed random
      : frequency spikes while a phone's screen was off; occasionally, one of the
      : CPU clusters would ramp to a high frequency because there was 200-300ms of
      : constant CPU work from a single thread in the main Android userspace
      : process.  The work causing the spike (which is reasonable governor
      : behavior given the amount of CPU time needed) was always PSS collection.
      : As a result, Android is burning more power than we should be on PSS
      : collection.
      :
      : The other issue (and why I'm less sure about improving smaps as a
      : long-term solution) is that the number of VMAs per process has increased
      : significantly from release to release.  After trying to figure out why we
      : were seeing these 200-300ms PSS collection times on Android O but had not
      : noticed it in previous versions, we found that the number of VMAs in the
      : main system process increased by 50% from Android N to Android O (from
      : ~1800 to ~2700) and varying increases in every userspace process.  Android
      : M to N also had an increase in the number of VMAs, although not as much.
      : I'm not sure why this is increasing so much over time, but thinking about
      : ASLR and ways to make ASLR better, I expect that this will continue to
      : increase going forward.  I would not be surprised if we hit 5000 VMAs on
      : the main Android process (system_server) by 2020.
      :
      : If we assume that the number of VMAs is going to increase over time, then
      : doing anything we can do to reduce the overhead of each VMA during PSS
      : collection seems like the right way to go, and that means outputting an
      : aggregate statistic (to avoid whatever overhead there is per line in
      : writing smaps and in reading each line from userspace).
      
      Link: http://lkml.kernel.org/r/20170812022148.178293-1-dancol@google.com
      
      Signed-off-by: default avatarDaniel Colascione <dancol@google.com>
      Cc: Tim Murray <timmurray@google.com>
      Cc: Joel Fernandes <joelaf@google.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Sonny Rao <sonnyrao@chromium.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      493b0e9d
    • Huang Ying's avatar
      mm, swap: add sysfs interface for VMA based swap readahead · d9bfcfdc
      Huang Ying authored
      The sysfs interface to control the VMA based swap readahead is added as
      follow,
      
      /sys/kernel/mm/swap/vma_ra_enabled
      
      Enable the VMA based swap readahead algorithm, or use the original
      global swap readahead algorithm.
      
      /sys/kernel/mm/swap/vma_ra_max_order
      
      Set the max order of the readahead window size for the VMA based swap
      readahead algorithm.
      
      The corresponding ABI documentation is added too.
      
      Link: http://lkml.kernel.org/r/20170807054038.1843-5-ying.huang@intel.com
      
      Signed-off-by: default avatar"Huang, Ying" <ying.huang@intel.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Shaohua Li <shli@kernel.org>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Tim Chen <tim.c.chen@intel.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d9bfcfdc
    • Minchan Kim's avatar
      zram: add config and doc file for writeback feature · 5a47074f
      Minchan Kim authored
      This patch adds document and kconfig for using of writeback feature.
      
      Link: http://lkml.kernel.org/r/1498459987-24562-10-git-send-email-minchan@kernel.org
      
      Signed-off-by: default avatarMinchan Kim <minchan@kernel.org>
      Cc: Juneho Choi <juno.choi@lge.com>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5a47074f
  15. 04 Sep, 2017 1 commit
  16. 28 Aug, 2017 4 commits
  17. 21 Aug, 2017 2 commits
    • Chao Yu's avatar
      f2fs: introduce discard_granularity sysfs entry · 969d1b18
      Chao Yu authored
      Commit d618ebaf
      
       ("f2fs: enable small discard by default") enables
      f2fs to issue 4K size discard in real-time discard mode. However, issuing
      smaller discard may cost more lifetime but releasing less free space in
      flash device. Since f2fs has ability of separating hot/cold data and
      garbage collection, we can expect that small-sized invalid region would
      expand soon with OPU, deletion or garbage collection on valid datas, so
      it's better to delay or skip issuing smaller size discards, it could help
      to reduce overmuch consumption of IO bandwidth and lifetime of flash
      storage.
      
      This patch makes f2fs selectng 64K size as its default minimal
      granularity, and issue discard with the size which is not smaller than
      minimal granularity. Also it exposes discard granularity as sysfs entry
      for configuration in different scenario.
      
      Jaegeuk Kim:
       We must issue all the accumulated discard commands when fstrim is called.
       So, I've added pend_list_tag[] to indicate whether we should issue the
       commands or not. If tag sets P_ACTIVE or P_TRIM, we have to issue them.
       P_TRIM is set once at a time, given fstrim trigger.
       In addition, issue_discard_thread is calling too much due to the number of
       discard commands remaining in the pending list. I added a timer to control
       it likewise gc_thread.
      Signed-off-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      969d1b18
    • Ujjal Singh's avatar
      dmaengine: ioatdma: Add ABI document · 2e442003
      Ujjal Singh authored
      
      
      ABI document added to describe all sysfs variables
      for dma
      Signed-off-by: default avatarUjjal Singh <ujjal.singh@intel.com>
      Acked-by: default avatarDave Jiang <dave.jiang@intel.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      2e442003
  18. 15 Aug, 2017 2 commits
  19. 10 Aug, 2017 2 commits
  20. 22 Jul, 2017 1 commit
    • Rafael J. Wysocki's avatar
      PM / sleep: Do not print debug messages by default · 8d8b2441
      Rafael J. Wysocki authored
      
      
      Debug messages from the system suspend/hibernation infrastructure can
      fill up the entire kernel log buffer in some cases and anyway they
      are only useful for debugging.  They depend on CONFIG_PM_DEBUG, but
      that is set as a rule as some generally useful diagnostic facilities
      depend on it too.
      
      For this reason, avoid printing those messages by default, but make
      it possible to turn them on as needed with the help of a new sysfs
      attribute under /sys/power/.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8d8b2441
  21. 17 Jul, 2017 2 commits
  22. 13 Jul, 2017 1 commit
  23. 07 Jul, 2017 1 commit
    • Chao Yu's avatar
      f2fs: introduce reserved_blocks in sysfs · daeb433e
      Chao Yu authored
      
      
      In this patch, we add a new sysfs interface, with it, we can control
      number of reserved blocks in system which could not be used by user,
      it enable f2fs to let user to configure for adjusting over-provision
      ratio dynamically instead of changing it by mkfs.
      
      So we can expect it will help to reserve more free space for relieving
      GC in both filesystem and flash device.
      Signed-off-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      daeb433e
  24. 04 Jul, 2017 2 commits
  25. 30 Jun, 2017 1 commit