1. 28 9月, 2016 1 次提交
  2. 27 9月, 2016 1 次提交
  3. 15 9月, 2016 1 次提交
  4. 03 9月, 2016 1 次提交
    • L
      ACPI / drivers: fix typo in ACPI_DECLARE_PROBE_ENTRY macro · 3feab13c
      Lorenzo Pieralisi 提交于
      When the ACPI_DECLARE_PROBE_ENTRY macro was added in
      commit e647b532 ("ACPI: Add early device probing infrastructure"),
      a stub macro adding an unused entry was added for the !CONFIG_ACPI
      Kconfig option case to make sure kernel code making use of the
      macro did not require to be guarded within CONFIG_ACPI in order to
      be compiled.
      
      The stub macro was never used since all kernel code that defines
      ACPI_DECLARE_PROBE_ENTRY entries is currently guarded within
      CONFIG_ACPI; it contains a typo that should be nonetheless fixed.
      
      Fix the typo in the stub (ie !CONFIG_ACPI) ACPI_DECLARE_PROBE_ENTRY()
      macro so that it can actually be used if needed.
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Fixes: e647b532 (ACPI: Add early device probing infrastructure)
      Cc: 4.4+ <stable@vger.kernel.org> # 4.4+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3feab13c
  5. 02 9月, 2016 5 次提交
  6. 01 9月, 2016 2 次提交
    • M
      ovl: don't cache acl on overlay layer · 2a3a2a3f
      Miklos Szeredi 提交于
      Some operations (setxattr/chmod) can make the cached acl stale.  We either
      need to clear overlay's acl cache for the affected inode or prevent acl
      caching on the overlay altogether.  Preventing caching has the following
      advantages:
      
       - no double caching, less memory used
      
       - overlay cache doesn't go stale when fs clears it's own cache
      
      Possible disadvantage is performance loss.  If that becomes a problem
      get_acl() can be optimized for overlayfs.
      
      This patch disables caching by pre setting i_*acl to a value that
      
        - has bit 0 set, so is_uncached_acl() will return true
      
        - is not equal to ACL_NOT_CACHED, so get_acl() will not overwrite it
      
      The constant -3 was chosen for this purpose.
      
      Fixes: 39a25b2b ("ovl: define ->get_acl() for overlay inodes")
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      2a3a2a3f
    • M
      mm: introduce get_task_exe_file · cd81a917
      Mateusz Guzik 提交于
      For more convenient access if one has a pointer to the task.
      
      As a minor nit take advantage of the fact that only task lock + rcu are
      needed to safely grab ->exe_file. This saves mm refcount dance.
      
      Use the helper in proc_exe_link.
      Signed-off-by: NMateusz Guzik <mguzik@redhat.com>
      Acked-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Acked-by: NRichard Guy Briggs <rgb@redhat.com>
      Cc: <stable@vger.kernel.org> # 4.3.x
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      cd81a917
  7. 31 8月, 2016 8 次提交
  8. 29 8月, 2016 2 次提交
    • R
      net: smc91x: fix SMC accesses · 2fb04fdf
      Russell King 提交于
      Commit b70661c7 ("net: smc91x: use run-time configuration on all ARM
      machines") broke some ARM platforms through several mistakes.  Firstly,
      the access size must correspond to the following rule:
      
      (a) at least one of 16-bit or 8-bit access size must be supported
      (b) 32-bit accesses are optional, and may be enabled in addition to
          the above.
      
      Secondly, it provides no emulation of 16-bit accesses, instead blindly
      making 16-bit accesses even when the platform specifies that only 8-bit
      is supported.
      
      Reorganise smc91x.h so we can make use of the existing 16-bit access
      emulation already provided - if 16-bit accesses are supported, use
      16-bit accesses directly, otherwise if 8-bit accesses are supported,
      use the provided 16-bit access emulation.  If neither, BUG().  This
      exactly reflects the driver behaviour prior to the commit being fixed.
      
      Since the conversion incorrectly cut down the available access sizes on
      several platforms, we also need to go through every platform and fix up
      the overly-restrictive access size: Arnd assumed that if a platform can
      perform 32-bit, 16-bit and 8-bit accesses, then only a 32-bit access
      size needed to be specified - not so, all available access sizes must
      be specified.
      
      This likely fixes some performance regressions in doing this: if a
      platform does not support 8-bit accesses, 8-bit accesses have been
      emulated by performing a 16-bit read-modify-write access.
      
      Tested on the Intel Assabet/Neponset platform, which supports only 8-bit
      accesses, which was broken by the original commit.
      
      Fixes: b70661c7 ("net: smc91x: use run-time configuration on all ARM machines")
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2fb04fdf
    • C
      iomap: don't set FIEMAP_EXTENT_MERGED for extent based filesystems · 17de0a9f
      Christoph Hellwig 提交于
      Filesystems like XFS that use extents should not set the
      FIEMAP_EXTENT_MERGED flag in the fiemap extent structures.  To allow
      for both behaviors for the upcoming gfs2 usage split the iomap
      type field into type and flags, and only set FIEMAP_EXTENT_MERGED if
      the IOMAP_F_MERGED flag is set.  The flags field will also come in
      handy for future features such as shared extents on reflink-enabled
      file systems.
      Reported-by: NAndreas Gruenbacher <agruenba@redhat.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      17de0a9f
  9. 27 8月, 2016 2 次提交
  10. 24 8月, 2016 1 次提交
    • T
      drm/tegra: dsi: Enhance runtime power management · 87904c3e
      Thierry Reding 提交于
      The MIPI DSI output on Tegra SoCs requires some external logic to
      calibrate the MIPI pads before a video signal can be transmitted. This
      MIPI calibration logic requires to be powered on while the MIPI pads are
      being used, which is currently done as part of the DSI driver's probe
      implementation.
      
      This is suboptimal because it will leave the MIPI calibration logic
      powered up even if the DSI output is never used.
      
      On Tegra114 and earlier this behaviour also causes the driver to hang
      while trying to power up the MIPI calibration logic because the power
      partition that contains the MIPI calibration logic will be powered on
      by the display controller at output pipeline configuration time. Thus
      the power up sequence for the MIPI calibration logic happens before
      it's power partition is guaranteed to be enabled.
      
      Fix this by splitting up the API into a request/free pair of functions
      that manage the runtime dependency between the DSI and the calibration
      modules (no registers are accessed) and a set of enable, calibrate and
      disable functions that program the MIPI calibration logic at points in
      time where the power partition is really enabled.
      
      While at it, make sure that the runtime power management also works in
      ganged mode, which is currently also broken.
      Reported-by: NJonathan Hunter <jonathanh@nvidia.com>
      Tested-by: NJonathan Hunter <jonathanh@nvidia.com>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      87904c3e
  11. 22 8月, 2016 1 次提交
  12. 21 8月, 2016 1 次提交
  13. 19 8月, 2016 1 次提交
  14. 18 8月, 2016 2 次提交
  15. 17 8月, 2016 1 次提交
    • C
      PCI: Use positive flags in pci_alloc_irq_vectors() · 4fe0d154
      Christoph Hellwig 提交于
      Instead of passing negative flags like PCI_IRQ_NOMSI to prevent use of
      certain interrupt types, pass positive flags like PCI_IRQ_LEGACY,
      PCI_IRQ_MSI, etc., to specify the acceptable interrupt types.
      
      This is based on a number of pending driver conversions that just happend
      to be a whole more obvious to read this way, and given that we have no
      users in the tree yet it can still easily be done.
      
      I've also added a PCI_IRQ_ALL_TYPES catchall to keep the case of accepting
      all interrupt types very simple.
      
      [bhelgaas: changelog, fix PCI_IRQ_AFFINITY doc typo, remove mention of
      PCI_IRQ_NOLEGACY]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NAlexander Gordeev <agordeev@redhat.com>
      4fe0d154
  16. 16 8月, 2016 1 次提交
  17. 15 8月, 2016 1 次提交
  18. 14 8月, 2016 1 次提交
    • S
      net: remove type_check from dev_get_nest_level() · 952fcfd0
      Sabrina Dubroca 提交于
      The idea for type_check in dev_get_nest_level() was to count the number
      of nested devices of the same type (currently, only macvlan or vlan
      devices).
      This prevented the false positive lockdep warning on configurations such
      as:
      
      eth0 <--- macvlan0 <--- vlan0 <--- macvlan1
      
      However, this doesn't prevent a warning on a configuration such as:
      
      eth0 <--- macvlan0 <--- vlan0
      eth1 <--- vlan1 <--- macvlan1
      
      In this case, all the locks end up with a nesting subclass of 1, so
      lockdep thinks that there is still a deadlock:
      
      - in the first case we have (macvlan_netdev_addr_lock_key, 1) and then
        take (vlan_netdev_xmit_lock_key, 1)
      - in the second case, we have (vlan_netdev_xmit_lock_key, 1) and then
        take (macvlan_netdev_addr_lock_key, 1)
      
      By removing the linktype check in dev_get_nest_level() and always
      incrementing the nesting depth, lockdep considers this configuration
      valid.
      Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      952fcfd0
  19. 12 8月, 2016 3 次提交
  20. 11 8月, 2016 1 次提交
  21. 10 8月, 2016 2 次提交
    • D
      perf/core: Set cgroup in CPU contexts for new cgroup events · db4a8356
      David Carrillo-Cisneros 提交于
      There's a perf stat bug easy to observer on a machine with only one cgroup:
      
        $ perf stat -e cycles -I 1000 -C 0 -G /
        #          time             counts unit events
            1.000161699      <not counted>      cycles                    /
            2.000355591      <not counted>      cycles                    /
            3.000565154      <not counted>      cycles                    /
            4.000951350      <not counted>      cycles                    /
      
      We'd expect some output there.
      
      The underlying problem is that there is an optimization in
      perf_cgroup_sched_{in,out}() that skips the switch of cgroup events
      if the old and new cgroups in a task switch are the same.
      
      This optimization interacts with the current code in two ways
      that cause a CPU context's cgroup (cpuctx->cgrp) to be NULL even if a
      cgroup event matches the current task. These are:
      
        1. On creation of the first cgroup event in a CPU: In current code,
        cpuctx->cpu is only set in perf_cgroup_sched_in, but due to the
        aforesaid optimization, perf_cgroup_sched_in will run until the next
        cgroup switches in that CPU. This may happen late or never happen,
        depending on system's number of cgroups, CPU load, etc.
      
        2. On deletion of the last cgroup event in a cpuctx: In list_del_event,
        cpuctx->cgrp is set NULL. Any new cgroup event will not be sched in
        because cpuctx->cgrp == NULL until a cgroup switch occurs and
        perf_cgroup_sched_in is executed (updating cpuctx->cgrp).
      
      This patch fixes both problems by setting cpuctx->cgrp in list_add_event,
      mirroring what list_del_event does when removing a cgroup event from CPU
      context, as introduced in:
      
        commit 68cacd29 ("perf_events: Fix stale ->cgrp pointer in update_cgrp_time_from_cpuctx()")
      
      With this patch, cpuctx->cgrp is always set/clear when installing/removing
      the first/last cgroup event in/from the CPU context. With cpuctx->cgrp
      correctly set, event_filter_match works as intended when events are
      sched in/out.
      
      After the fix, the output is as expected:
      
        $ perf stat -e cycles -I 1000 -a -G /
        #         time             counts unit events
           1.004699159          627342882      cycles                    /
           2.007397156          615272690      cycles                    /
           3.010019057          616726074      cycles                    /
      Signed-off-by: NDavid Carrillo-Cisneros <davidcc@google.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Turner <pjt@google.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Link: http://lkml.kernel.org/r/1470124092-113192-1-git-send-email-davidcc@google.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      db4a8356
    • L
      Revert "printk: create pr_<level> functions" · a0cba217
      Linus Torvalds 提交于
      This reverts commit 874f9c7d.
      
      Geert Uytterhoeven reports:
       "This change seems to have an (unintendent?) side-effect.
      
        Before, pr_*() calls without a trailing newline characters would be
        printed with a newline character appended, both on the console and in
        the output of the dmesg command.
      
        After this commit, no new line character is appended, and the output
        of the next pr_*() call of the same type may be appended, like in:
      
          - Truncating RAM at 0x0000000040000000-0x00000000c0000000 to -0x0000000070000000
          - Ignoring RAM at 0x0000000200000000-0x0000000240000000 (!CONFIG_HIGHMEM)
          + Truncating RAM at 0x0000000040000000-0x00000000c0000000 to -0x0000000070000000Ignoring RAM at 0x0000000200000000-0x0000000240000000 (!CONFIG_HIGHMEM)"
      
      Joe Perches says:
       "No, that is not intentional.
      
        The newline handling code inside vprintk_emit is a bit involved and
        for now I suggest a revert until this has all the same behavior as
        earlier"
      Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Requested-by: NJoe Perches <joe@perches.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a0cba217
  22. 09 8月, 2016 1 次提交
新手
引导
客服 返回
顶部