1. 08 2月, 2018 1 次提交
  2. 25 1月, 2018 1 次提交
  3. 24 1月, 2018 2 次提交
  4. 22 1月, 2018 1 次提交
  5. 20 1月, 2018 1 次提交
  6. 17 1月, 2018 5 次提交
  7. 16 1月, 2018 3 次提交
  8. 14 1月, 2018 1 次提交
  9. 13 1月, 2018 1 次提交
    • K
      kdump: Write the correct address of mem_section into vmcoreinfo · 9f15b912
      Kirill A. Shutemov 提交于
      Depending on configuration mem_section can now be an array or a pointer
      to an array allocated dynamically. In most cases, we can continue to refer
      to it as 'mem_section' regardless of what it is.
      
      But there's one exception: '&mem_section' means "address of the array" if
      mem_section is an array, but if mem_section is a pointer, it would mean
      "address of the pointer".
      
      We've stepped onto this in the kdump code: VMCOREINFO_SYMBOL(mem_section)
      writes down the address of pointer into vmcoreinfo, not the array as we wanted,
      breaking kdump.
      
      Let's introduce VMCOREINFO_SYMBOL_ARRAY() that would handle the
      situation correctly for both cases.
      
      Mike Galbraith <efault@gmx.de>
      Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: NBaoquan He <bhe@redhat.com>
      Acked-by: NDave Young <dyoung@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: kexec@lists.infradead.org
      Cc: linux-mm@kvack.org
      Cc: stable@vger.kernel.org
      Fixes: 83e3c487 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y")
      Link: http://lkml.kernel.org/r/20180112162532.35896-1-kirill.shutemov@linux.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      9f15b912
  10. 12 1月, 2018 3 次提交
    • S
      net/mlx5: Fix get vector affinity helper function · 05e0cc84
      Saeed Mahameed 提交于
      mlx5_get_vector_affinity used to call pci_irq_get_affinity and after
      reverting the patch that sets the device affinity via PCI_IRQ_AFFINITY
      API, calling pci_irq_get_affinity becomes useless and it breaks RDMA
      mlx5 users.  To fix this, this patch provides an alternative way to
      retrieve IRQ vector affinity using legacy IRQ API, following
      smp_affinity read procfs implementation.
      
      Fixes: 231243c8 ("Revert mlx5: move affinity hints assignments to generic code")
      Fixes: a435393a ("mlx5: move affinity hints assignments to generic code")
      Cc: Sagi Grimberg <sagi@grimberg.me>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      05e0cc84
    • E
      {net,ib}/mlx5: Don't disable local loopback multicast traffic when needed · 8978cc92
      Eran Ben Elisha 提交于
      There are systems platform information management interfaces (such as
      HOST2BMC) for which we cannot disable local loopback multicast traffic.
      
      Separate disable_local_lb_mc and disable_local_lb_uc capability bits so
      driver will not disable multicast loopback traffic if not supported.
      (It is expected that Firmware will not set disable_local_lb_mc if
      HOST2BMC is running for example.)
      
      Function mlx5_nic_vport_update_local_lb will do best effort to
      disable/enable UC/MC loopback traffic and return success only in case it
      succeeded to changed all allowed by Firmware.
      
      Adapt mlx5_ib and mlx5e to support the new cap bits.
      
      Fixes: 2c43c5a0 ("net/mlx5e: Enable local loopback in loopback selftest")
      Fixes: c85023e1 ("IB/mlx5: Add raw ethernet local loopback support")
      Fixes: bded747b ("net/mlx5: Add raw ethernet local loopback firmware command")
      Signed-off-by: NEran Ben Elisha <eranbe@mellanox.com>
      Cc: kernel-team@fb.com
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      8978cc92
    • T
      sound: Remove unused register_sound_midi() and co · 4d885f2d
      Takashi Iwai 提交于
      These helpers are no longer used after the removal of the legacy OSS
      drivers.  Let's clean up.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      4d885f2d
  11. 10 1月, 2018 9 次提交
  12. 09 1月, 2018 3 次提交
    • U
      PM / wakeup: Add device_set_wakeup_path() helper to control wakeup path · cf04ce78
      Ulf Hansson 提交于
      During system suspend, a driver may find that the wakeup setting is
      enabled for its device and therefore configures it to deliver system
      wakeup signals.
      
      Additionally, sometimes the driver and its device, relies on some
      further consumed resource, like an irqchip or a phy for example, to
      stay powered on, as to be able to deliver system wakeup signals.
      
      In general the driver deals with this, via raising an "enable count"
      of the consumed resource or via a subsystem specific API, like
      irq_set_irq_wake() or enable|disable_irq_wake() for an irqchip.
      However, this may not be sufficient in cases when the resource's
      device may be attached to a PM domain (genpd for example) or is
      handled by a non-trivial middle layer (PCI for example).
      
      To address cases like these, the existing ->dev.power.wakeup_path
      status flag is there to help.  As a matter of fact, genpd already
      monitors the flag during system suspend and acts accordingly.
      
      However, so far it has not been clear, if anybody else but the PM
      core is allowed to set the ->dev.power.wakeup_path status flag,
      which is required to make this work.  For this reason, introduce
      a new helper function, device_set_wakeup_path() for that.
      
      Typically, a driver that manages a resource needed in the wakeup path
      should call device_set_wakeup_path() from its ->suspend() or
      ->suspend_late() callback.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      cf04ce78
    • A
      bpf: prevent out-of-bounds speculation · b2157399
      Alexei Starovoitov 提交于
      Under speculation, CPUs may mis-predict branches in bounds checks. Thus,
      memory accesses under a bounds check may be speculated even if the
      bounds check fails, providing a primitive for building a side channel.
      
      To avoid leaking kernel data round up array-based maps and mask the index
      after bounds check, so speculated load with out of bounds index will load
      either valid value from the array or zero from the padded area.
      
      Unconditionally mask index for all array types even when max_entries
      are not rounded to power of 2 for root user.
      When map is created by unpriv user generate a sequence of bpf insns
      that includes AND operation to make sure that JITed code includes
      the same 'index & index_mask' operation.
      
      If prog_array map is created by unpriv user replace
        bpf_tail_call(ctx, map, index);
      with
        if (index >= max_entries) {
          index &= map->index_mask;
          bpf_tail_call(ctx, map, index);
        }
      (along with roundup to power 2) to prevent out-of-bounds speculation.
      There is secondary redundant 'if (index >= max_entries)' in the interpreter
      and in all JITs, but they can be optimized later if necessary.
      
      Other array-like maps (cpumap, devmap, sockmap, perf_event_array, cgroup_array)
      cannot be used by unpriv, so no changes there.
      
      That fixes bpf side of "Variant 1: bounds check bypass (CVE-2017-5753)" on
      all architectures with and without JIT.
      
      v2->v3:
      Daniel noticed that attack potentially can be crafted via syscall commands
      without loading the program, so add masking to those paths as well.
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      b2157399
    • I
      locking/lockdep: Remove cross-release leftovers · 527187d2
      Ingo Molnar 提交于
      There's two cross-release leftover facilities:
      
       - the crossrelease_hist_*() irq-tracing callbacks (NOPs currently)
       - the complete_release_commit() callback (NOP as well)
      
      Remove them.
      
      Cc: David Sterba <dsterba@suse.com>
      Cc: Byungchul Park <byungchul.park@lge.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      527187d2
  13. 08 1月, 2018 1 次提交
  14. 06 1月, 2018 2 次提交
  15. 03 1月, 2018 1 次提交
    • A
      efi/capsule-loader: Reinstate virtual capsule mapping · f24c4d47
      Ard Biesheuvel 提交于
      Commit:
      
        82c3768b ("efi/capsule-loader: Use a cached copy of the capsule header")
      
      ... refactored the capsule loading code that maps the capsule header,
      to avoid having to map it several times.
      
      However, as it turns out, the vmap() call we ended up removing did not
      just map the header, but the entire capsule image, and dropping this
      virtual mapping breaks capsules that are processed by the firmware
      immediately (i.e., without a reboot).
      
      Unfortunately, that change was part of a larger refactor that allowed
      a quirk to be implemented for Quark, which has a non-standard memory
      layout for capsules, and we have slightly painted ourselves into a
      corner by allowing quirk code to mangle the capsule header and memory
      layout.
      
      So we need to fix this without breaking Quark. Fortunately, Quark does
      not appear to care about the virtual mapping, and so we can simply
      do a partial revert of commit:
      
        2a457fb3 ("efi/capsule-loader: Use page addresses rather than struct page pointers")
      
      ... and create a vmap() mapping of the entire capsule (including header)
      based on the reinstated struct page array, unless running on Quark, in
      which case we pass the capsule header copy as before.
      Reported-by: NGe Song <ge.song@hxt-semitech.com>
      Tested-by: NBryan O'Donoghue <pure.logic@nexus-software.ie>
      Tested-by: NGe Song <ge.song@hxt-semitech.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: <stable@vger.kernel.org>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Fixes: 82c3768b ("efi/capsule-loader: Use a cached copy of the capsule header")
      Link: http://lkml.kernel.org/r/20180102172110.17018-3-ard.biesheuvel@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      f24c4d47
  16. 02 1月, 2018 1 次提交
    • D
      fscache: Fix the default for fscache_maybe_release_page() · 98801506
      David Howells 提交于
      Fix the default for fscache_maybe_release_page() for when the cookie isn't
      valid or the page isn't cached.  It mustn't return false as that indicates
      the page cannot yet be freed.
      
      The problem with the default is that if, say, there's no cache, but a
      network filesystem's pages are using up almost all the available memory, a
      system can OOM because the filesystem ->releasepage() op will not allow
      them to be released as fscache_maybe_release_page() incorrectly prevents
      it.
      
      This can be tested by writing a sequence of 512MiB files to an AFS mount.
      It does not affect NFS or CIFS because both of those wrap the call in a
      check of PG_fscache and it shouldn't bother Ceph as that only has
      PG_private set whilst writeback is in progress.  This might be an issue for
      9P, however.
      
      Note that the pages aren't entirely stuck.  Removing a file or unmounting
      will clear things because that uses ->invalidatepage() instead.
      
      Fixes: 201a1542 ("FS-Cache: Handle pages pending storage that get evicted under OOM conditions")
      Reported-by: NMarc Dionne <marc.dionne@auristor.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
      Tested-by: NMarc Dionne <marc.dionne@auristor.com>
      cc: stable@vger.kernel.org # 2.6.32+
      98801506
  17. 30 12月, 2017 3 次提交
    • T
      timers: Reinitialize per cpu bases on hotplug · 26456f87
      Thomas Gleixner 提交于
      The timer wheel bases are not (re)initialized on CPU hotplug. That leaves
      them with a potentially stale clk and next_expiry valuem, which can cause
      trouble then the CPU is plugged.
      
      Add a prepare callback which forwards the clock, sets next_expiry to far in
      the future and reset the control flags to a known state.
      
      Set base->must_forward_clk so the first timer which is queued will try to
      forward the clock to current jiffies.
      
      Fixes: 500462a9 ("timers: Switch to a non-cascading wheel")
      Reported-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Cc: Anna-Maria Gleixner <anna-maria@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1712272152200.2431@nanos
      26456f87
    • T
      genirq/irqdomain: Rename early argument of irq_domain_activate_irq() · 702cb0a0
      Thomas Gleixner 提交于
      The 'early' argument of irq_domain_activate_irq() is actually used to
      denote reservation mode. To avoid confusion, rename it before abuse
      happens.
      
      No functional change.
      
      Fixes: 72491643 ("genirq/irqdomain: Update irq_domain_ops.activate() signature")
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Alexandru Chirvasitu <achirvasub@gmail.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Dou Liyang <douly.fnst@cn.fujitsu.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      Cc: Mikael Pettersson <mikpelinux@gmail.com>
      Cc: Josh Poulson <jopoulso@microsoft.com>
      Cc: Mihai Costache <v-micos@microsoft.com>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: linux-pci@vger.kernel.org
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: Dexuan Cui <decui@microsoft.com>
      Cc: Simon Xiao <sixiao@microsoft.com>
      Cc: Saeed Mahameed <saeedm@mellanox.com>
      Cc: Jork Loeser <Jork.Loeser@microsoft.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: devel@linuxdriverproject.org
      Cc: KY Srinivasan <kys@microsoft.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Sakari Ailus <sakari.ailus@intel.com>,
      Cc: linux-media@vger.kernel.org
      702cb0a0
    • T
      genirq: Introduce IRQD_CAN_RESERVE flag · 69790ba9
      Thomas Gleixner 提交于
      Add a new flag to mark interrupts which can use reservation mode. This is
      going to be used in subsequent patches to disable reservation mode for a
      certain class of MSI devices.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NAlexandru Chirvasitu <achirvasub@gmail.com>
      Tested-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Dou Liyang <douly.fnst@cn.fujitsu.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      Cc: Mikael Pettersson <mikpelinux@gmail.com>
      Cc: Josh Poulson <jopoulso@microsoft.com>
      Cc: Mihai Costache <v-micos@microsoft.com>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: linux-pci@vger.kernel.org
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: Dexuan Cui <decui@microsoft.com>
      Cc: Simon Xiao <sixiao@microsoft.com>
      Cc: Saeed Mahameed <saeedm@mellanox.com>
      Cc: Jork Loeser <Jork.Loeser@microsoft.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: devel@linuxdriverproject.org
      Cc: KY Srinivasan <kys@microsoft.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Sakari Ailus <sakari.ailus@intel.com>,
      Cc: linux-media@vger.kernel.org
      69790ba9
  18. 28 12月, 2017 1 次提交