1. 12 Aug, 2013 32 commits
  2. 04 Aug, 2013 8 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.10.5 · dc51cd25
      Greg Kroah-Hartman authored
      dc51cd25
    • Yinghai Lu's avatar
      x86: Fix /proc/mtrr with base/size more than 44bits · b1851628
      Yinghai Lu authored
      commit d5c78673 upstream.
      
      On one sytem that mtrr range is more then 44bits, in dmesg we have
      [    0.000000] MTRR default type: write-back
      [    0.000000] MTRR fixed ranges enabled:
      [    0.000000]   00000-9FFFF write-back
      [    0.000000]   A0000-BFFFF uncachable
      [    0.000000]   C0000-DFFFF write-through
      [    0.000000]   E0000-FFFFF write-protect
      [    0.000000] MTRR variable ranges enabled:
      [    0.000000]   0 [000080000000-0000FFFFFFFF] mask 3FFF80000000 uncachable
      [    0.000000]   1 [380000000000-38FFFFFFFFFF] mask 3F0000000000 uncachable
      [    0.000000]   2 [000099000000-000099FFFFFF] mask 3FFFFF000000 write-through
      [    0.000000]   3 [00009A000000-00009AFFFFFF] mask 3FFFFF000000 write-through
      [    0.000000]   4 [381FFA000000-381FFBFFFFFF] mask 3FFFFE000000 write-through
      [    0.000000]   5 [381FFC000000-381FFC0FFFFF] mask 3FFFFFF00000 write-through
      [    0.000000]   6 [0000AD000000-0000ADFFFFFF] mask 3FFFFF000000 write-through
      [    0.000000]   7 [0000BD000000-0000BDFFFFFF] mask 3FFFFF000000 write-through
      [    0.000000]   8 disabled
      [    0.000000]   9 disabled
      
      but /proc/mtrr report wrong:
      reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable
      reg01: base=0x80000000000 (8388608MB), size=1048576MB, count=1: uncachable
      reg02: base=0x099000000 ( 2448MB), size=   16MB, count=1: write-through
      reg03: base=0x09a000000 ( 2464MB), size=   16MB, count=1: write-through
      reg04: base=0x81ffa000000 (8519584MB), size=   32MB, count=1: write-through
      reg05: base=0x81ffc000000 (8519616MB), size=    1MB, count=1: write-through
      reg06: base=0x0ad000000 ( 2768MB), size=   16MB, count=1: write-through
      reg07: base=0x0bd000000 ( 3024MB), size=   16MB, count=1: write-through
      reg08: base=0x09b000000 ( 2480MB), size=   16MB, count=1: write-combining
      
      so bit 44 and bit 45 get cut off.
      
      We have problems in arch/x86/kernel/cpu/mtrr/generic.c::generic_get_mtrr().
      1. for base, we miss cast base_lo to 64bit before shifting.
      Fix that by adding u64 casting.
      
      2. for size, it only can handle 44 bits aka 32bits + page_shift
      Fix that with 64bit mask instead of 32bit mask_lo, then range could be
      more than 44bits.
      At the same time, we need to update size_or_mask for old cpus that does
      support cpuid 0x80000008 to get phys_addr. Need to set high 32bits
      to all 1s, otherwise will not get correct size for them.
      
      Also fix mtrr_add_page: it should check base and (base + size - 1)
      instead of base and size, as base and size could be small but
      base + size could bigger enough to be out of boundary. We can
      use boot_cpu_data.x86_phys_bits directly to avoid size_or_mask.
      
      So When are we going to have size more than 44bits? that is 16TiB.
      
      after patch we have right ouput:
      reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable
      reg01: base=0x380000000000 (58720256MB), size=1048576MB, count=1: uncachable
      reg02: base=0x099000000 ( 2448MB), size=   16MB, count=1: write-through
      reg03: base=0x09a000000 ( 2464MB), size=   16MB, count=1: write-through
      reg04: base=0x381ffa000000 (58851232MB), size=   32MB, count=1: write-through
      reg05: base=0x381ffc000000 (58851264MB), size=    1MB, count=1: write-through
      reg06: base=0x0ad000000 ( 2768MB), size=   16MB, count=1: write-through
      reg07: base=0x0bd000000 ( 3024MB), size=   16MB, count=1: write-through
      reg08: base=0x09b000000 ( 2480MB), size=   16MB, count=1: write-combining
      
      -v2: simply checking in mtrr_add_page according to hpa.
      
      [ hpa: This probably wants to go into -stable only after having sat in
        mainline for a bit.  It is not a regression. ]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/1371162815-29931-1-git-send-email-yinghai@kernel.orgSigned-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b1851628
    • Xiong Zhang's avatar
      drm/i915: Correct obj->mm_list link to dev_priv->dev_priv->mm.inactive_list · 0915f45b
      Xiong Zhang authored
      commit 06755608 upstream.
      
      obj->mm_list link to dev_priv->mm.inactive_list/active_list
      obj->global_list link to dev_priv->mm.unbound_list/bound_list
      
      This regression has been introduced in
      
      commit 93927ca5
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Jan 10 18:03:00 2013 +0100
      
          drm/i915: Revert shrinker changes from "Track unbound pages"
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarXiong Zhang <xiong.y.zhang@intel.com>
      [danvet: Add regression notice.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarZhouping Liu <zliu@redhat.com>
      
      0915f45b
    • Michael Witten's avatar
      perf tools: Revert regression in configuration of Python support · 2652eb44
      Michael Witten authored
      commit a363a9da upstream.
      
      Among other things, the following:
      
        commit 31160d7f
        Date:   Tue Jan 8 16:22:36 2013 -0500
        perf tools: Fix GNU make v3.80 compatibility issue
      
      attempts to aid the user by tapping into an existing error message,
      as described in the commit message:
      
        ... Also fix an issue where _get_attempt was called with only
        one argument. This prevented the error message from printing
        the name of the variable that can be used to fix the problem.
      
      or more precisely:
      
        -$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2)))
        +$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2),$(1)))
      
      However, The "missing" argument was in fact missing on purpose; it's
      absence is a signal that the error message should be skipped, because
      the failure would be due to the default value, not any user-supplied
      value.  This can be seen in how `_ge_attempt' uses `gea_err' (in the
      config/utilities.mak file):
      
        _ge_attempt = $(if $(get-executable),$(get-executable),$(_gea_warn)$(call _gea_err,$(2)))
        _gea_warn = $(warning The path '$(1)' is not executable.)
        _gea_err  = $(if $(1),$(error Please set '$(1)' appropriately))
      
      That is, because the argument is no longer missing, the value `$(1)'
      (associated with `_gea_err') always evaluates to true, thus always
      triggering the error condition that is meant to be reserved for
      only the case when a user explicitly supplies an invalid value.
      
      Concretely, the result is a regression in the Makefile's configuration
      of python support; rather than gracefully disable support when the
      relevant executables cannot be found according to default values, the
      build process halts in error as though the user explicitly supplied
      the values.
      
      This new commit simply reverts the offending one-line change.
      Reported-by: default avatarPekka Enberg <penberg@kernel.org>
      Link: http://lkml.kernel.org/r/CAOJsxLHv17Ys3M7P5q25imkUxQW6LE_vABxh1N3Tt7Mv6Ho4iw@mail.gmail.comSigned-off-by: default avatarMichael Witten <mfwitten@gmail.com>
      Cc: Mark Brown <broonie@sirena.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2652eb44
    • Nicholas Bellinger's avatar
      iscsi-target: Fix iscsit_sequence_cmd reject handling for iser · adb97c29
      Nicholas Bellinger authored
      commit 561bf158 upstream
      
      This patch moves ISCSI_OP_REJECT failures into iscsit_sequence_cmd()
      in order to avoid external iscsit_reject_cmd() reject usage for all
      PDU types.
      
      It also updates PDU specific handlers for traditional iscsi-target
      code to not reset the session after posting a ISCSI_OP_REJECT during
      setup.
      
      (v2: Fix CMDSN_LOWER_THAN_EXP for ISCSI_OP_SCSI to call
           target_put_sess_cmd() after iscsit_sequence_cmd() failure)
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Cc: Or Gerlitz <ogerlitz@mellanox.com>
      Cc: Mike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      adb97c29
    • Nicholas Bellinger's avatar
      iscsi-target: Fix iscsit_add_reject* usage for iser · 1aa58ccd
      Nicholas Bellinger authored
      commit ba159914 upstream
      
      This patch changes iscsit_add_reject() + iscsit_add_reject_from_cmd()
      usage to not sleep on iscsi_cmd->reject_comp to address a free-after-use
      usage bug in v3.10 with iser-target code.
      
      It saves ->reject_reason for use within iscsit_build_reject() so the
      correct value for both transport cases.  It also drops the legacy
      fail_conn parameter usage throughput iscsi-target code and adds
      two iscsit_add_reject_cmd() and iscsit_reject_cmd helper functions,
      along with various small cleanups.
      
      (v2: Re-enable target_put_sess_cmd() to be called from
           iscsit_add_reject_from_cmd() for rejects invoked after
           target_get_sess_cmd() has been called)
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Cc: Or Gerlitz <ogerlitz@mellanox.com>
      Cc: Mike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1aa58ccd
    • Sergey Senozhatsky's avatar
      radeon kms: do not flush uninitialized hotplug work · 6655d76e
      Sergey Senozhatsky authored
      commit a01c34f7 upstream.
      
      Fix a warning from lockdep caused by calling flush_work() for
      uninitialized hotplug work. Initialize hotplug_work, audio_work
      and reset_work upon successful radeon_irq_kms_init() completion
      and thus perform hotplug flush_work only when rdev->irq.installed
      is true.
      
      [    4.790019] [drm] Loading CEDAR Microcode
      [    4.790943] r600_cp: Failed to load firmware "radeon/CEDAR_smc.bin"
      [    4.791152] [drm:evergreen_startup] *ERROR* Failed to load firmware!
      [    4.791330] radeon 0000:01:00.0: disabling GPU acceleration
      
      [    4.792633] INFO: trying to register non-static key.
      [    4.792792] the code is fine but needs lockdep annotation.
      [    4.792953] turning off the locking correctness validator.
      
      [    4.793114] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc0-dbg-10676-gfe56456-dirty #1816
      [    4.793314] Hardware name: Acer             Aspire 5741G    /Aspire 5741G    , BIOS V1.20 02/08/2011
      [    4.793507]  ffffffff821fd810 ffff8801530b9a18 ffffffff8160434e 0000000000000002
      [    4.794155]  ffff8801530b9ad8 ffffffff810b8404 ffff8801530b0798 ffff8801530b0000
      [    4.794789]  ffff8801530b9b00 0000000000000046 00000000000004c0 ffffffff00000000
      [    4.795418] Call Trace:
      [    4.795573]  [<ffffffff8160434e>] dump_stack+0x4e/0x82
      [    4.795731]  [<ffffffff810b8404>] __lock_acquire+0x1a64/0x1d30
      [    4.795893]  [<ffffffff814a87f0>] ? dev_vprintk_emit+0x50/0x60
      [    4.796034]  [<ffffffff810b8fb4>] lock_acquire+0xa4/0x200
      [    4.796216]  [<ffffffff8106cd75>] ? flush_work+0x5/0x280
      [    4.796375]  [<ffffffff8106cdad>] flush_work+0x3d/0x280
      [    4.796520]  [<ffffffff8106cd75>] ? flush_work+0x5/0x280
      [    4.796682]  [<ffffffff810b659d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
      [    4.796862]  [<ffffffff8131d775>] ? delay_tsc+0x95/0xf0
      [    4.797024]  [<ffffffff8141bb8b>] radeon_irq_kms_fini+0x2b/0x70
      [    4.797186]  [<ffffffff814557c9>] evergreen_init+0x2a9/0x2e0
      [    4.797347]  [<ffffffff813ebb1f>] radeon_device_init+0x5ef/0x700
      [    4.797511]  [<ffffffff81335bc7>] ? pci_find_capability+0x47/0x50
      [    4.797672]  [<ffffffff813edaed>] radeon_driver_load_kms+0x8d/0x150
      [    4.797843]  [<ffffffff813ce426>] drm_get_pci_dev+0x166/0x280
      [    4.798007]  [<ffffffff8116cff5>] ? kfree+0xf5/0x2e0
      [    4.798168]  [<ffffffff813ea298>] ? radeon_pci_probe+0x98/0xd0
      [    4.798329]  [<ffffffff813ea2aa>] radeon_pci_probe+0xaa/0xd0
      [    4.798489]  [<ffffffff81339404>] pci_device_probe+0x84/0xe0
      [    4.798644]  [<ffffffff814ac7d6>] driver_probe_device+0x76/0x240
      [    4.798805]  [<ffffffff814aca73>] __driver_attach+0x93/0xa0
      [    4.798948]  [<ffffffff814ac9e0>] ? __device_attach+0x40/0x40
      [    4.799126]  [<ffffffff814aa82b>] bus_for_each_dev+0x6b/0xb0
      [    4.799272]  [<ffffffff814ac2be>] driver_attach+0x1e/0x20
      [    4.799434]  [<ffffffff814abec0>] bus_add_driver+0x1f0/0x280
      [    4.799596]  [<ffffffff814ad0e4>] driver_register+0x74/0x150
      [    4.799758]  [<ffffffff8133923d>] __pci_register_driver+0x5d/0x60
      [    4.799936]  [<ffffffff81d16efc>] ? ttm_init+0x67/0x67
      [    4.800081]  [<ffffffff813ce655>] drm_pci_init+0x115/0x130
      [    4.800243]  [<ffffffff81d16efc>] ? ttm_init+0x67/0x67
      [    4.800405]  [<ffffffff81d16f98>] radeon_init+0x9c/0xba
      [    4.800586]  [<ffffffff810002ca>] do_one_initcall+0xfa/0x150
      [    4.800746]  [<ffffffff81073f60>] ? parse_args+0x120/0x330
      [    4.800909]  [<ffffffff81cdafae>] kernel_init_freeable+0x111/0x191
      [    4.801052]  [<ffffffff81cda87a>] ? do_early_param+0x88/0x88
      [    4.801233]  [<ffffffff815fb670>] ? rest_init+0x140/0x140
      [    4.801393]  [<ffffffff815fb67e>] kernel_init+0xe/0x180
      [    4.801556]  [<ffffffff8160dcac>] ret_from_fork+0x7c/0xb0
      [    4.801718]  [<ffffffff815fb670>] ? rest_init+0x140/0x140
      Signed-off-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6655d76e
    • David Vrabel's avatar
      xen/evtchn: avoid a deadlock when unbinding an event channel · 3d63d1e0
      David Vrabel authored
      commit 179fbd5a upstream.
      
      Unbinding an event channel (either with the ioctl or when the evtchn
      device is closed) may deadlock because disable_irq() is called with
      port_user_lock held which is also locked by the interrupt handler.
      
      Think of the IOCTL_EVTCHN_UNBIND is being serviced, the routine has
      just taken the lock, and an interrupt happens. The evtchn_interrupt
      is invoked, tries to take the lock and spins forever.
      
      A quick glance at the code shows that the spinlock is a local IRQ
      variant. Unfortunately that does not help as "disable_irq() waits for
      the interrupt handler on all CPUs to stop running.  If the irq occurs
      on another VCPU, it tries to take port_user_lock and can't because
      the unbind ioctl is holding it." (from David). Hence we cannot
      depend on the said spinlock to protect us. We could make it a system
      wide IRQ disable spinlock but there is a better way.
      
      We can piggyback on the fact that the existence of the spinlock is
      to make get_port_user() checks be up-to-date. And we can alter those
      checks to not depend on the spin lock (as it's protected by u->bind_mutex
      in the ioctl) and can remove the unnecessary locking (this is
      IOCTL_EVTCHN_UNBIND) path.
      
      In the interrupt handler we cannot use the mutex, but we do not
      need it.
      
      "The unbind disables the irq before making the port user stale, so when
      you clear it you are guaranteed that the interrupt handler that might
      use that port cannot be running." (from David).
      
      Hence this patch removes the spinlock usage on the teardown path
      and piggybacks on disable_irq happening before we muck with the
      get_port_user() data. This ensures that the interrupt handler will
      never run on stale data.
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      [v1: Expanded the commit description a bit]
      Signed-off-by: default avatarJonghwan Choi <jhbird.choi@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3d63d1e0