1. 24 10月, 2013 2 次提交
    • B
      md: avoid deadlock when md_set_badblocks. · 905b0297
      Bian Yu 提交于
      When operate harddisk and hit errors, md_set_badblocks is called after
      scsi_restart_operations which already disabled the irq. but md_set_badblocks
      will call write_sequnlock_irq and enable irq. so softirq can preempt the
      current thread and that may cause a deadlock. I think this situation should
      use write_sequnlock_irqsave/irqrestore instead.
      
      I met the situation and the call trace is below:
      [  638.919974] BUG: spinlock recursion on CPU#0, scsi_eh_13/1010
      [  638.921923]  lock: 0xffff8800d4d51fc8, .magic: dead4ead, .owner: scsi_eh_13/1010, .owner_cpu: 0
      [  638.923890] CPU: 0 PID: 1010 Comm: scsi_eh_13 Not tainted 3.12.0-rc5+ #37
      [  638.925844] Hardware name: To be filled by O.E.M. To be filled by O.E.M./MAHOBAY, BIOS 4.6.5 03/05/2013
      [  638.927816]  ffff880037ad4640 ffff880118c03d50 ffffffff8172ff85 0000000000000007
      [  638.929829]  ffff8800d4d51fc8 ffff880118c03d70 ffffffff81730030 ffff8800d4d51fc8
      [  638.931848]  ffffffff81a72eb0 ffff880118c03d90 ffffffff81730056 ffff8800d4d51fc8
      [  638.933884] Call Trace:
      [  638.935867]  <IRQ>  [<ffffffff8172ff85>] dump_stack+0x55/0x76
      [  638.937878]  [<ffffffff81730030>] spin_dump+0x8a/0x8f
      [  638.939861]  [<ffffffff81730056>] spin_bug+0x21/0x26
      [  638.941836]  [<ffffffff81336de4>] do_raw_spin_lock+0xa4/0xc0
      [  638.943801]  [<ffffffff8173f036>] _raw_spin_lock+0x66/0x80
      [  638.945747]  [<ffffffff814a73ed>] ? scsi_device_unbusy+0x9d/0xd0
      [  638.947672]  [<ffffffff8173fb1b>] ? _raw_spin_unlock+0x2b/0x50
      [  638.949595]  [<ffffffff814a73ed>] scsi_device_unbusy+0x9d/0xd0
      [  638.951504]  [<ffffffff8149ec47>] scsi_finish_command+0x37/0xe0
      [  638.953388]  [<ffffffff814a75e8>] scsi_softirq_done+0xa8/0x140
      [  638.955248]  [<ffffffff8130e32b>] blk_done_softirq+0x7b/0x90
      [  638.957116]  [<ffffffff8104fddd>] __do_softirq+0xfd/0x330
      [  638.958987]  [<ffffffff810b964f>] ? __lock_release+0x6f/0x100
      [  638.960861]  [<ffffffff8174a5cc>] call_softirq+0x1c/0x30
      [  638.962724]  [<ffffffff81004c7d>] do_softirq+0x8d/0xc0
      [  638.964565]  [<ffffffff8105024e>] irq_exit+0x10e/0x150
      [  638.966390]  [<ffffffff8174ad4a>] smp_apic_timer_interrupt+0x4a/0x60
      [  638.968223]  [<ffffffff817499af>] apic_timer_interrupt+0x6f/0x80
      [  638.970079]  <EOI>  [<ffffffff810b964f>] ? __lock_release+0x6f/0x100
      [  638.971899]  [<ffffffff8173fa6a>] ? _raw_spin_unlock_irq+0x3a/0x50
      [  638.973691]  [<ffffffff8173fa60>] ? _raw_spin_unlock_irq+0x30/0x50
      [  638.975475]  [<ffffffff81562393>] md_set_badblocks+0x1f3/0x4a0
      [  638.977243]  [<ffffffff81566e07>] rdev_set_badblocks+0x27/0x80
      [  638.978988]  [<ffffffffa00d97bb>] raid5_end_read_request+0x36b/0x4e0 [raid456]
      [  638.980723]  [<ffffffff811b5a1d>] bio_endio+0x1d/0x40
      [  638.982463]  [<ffffffff81304ff3>] req_bio_endio.isra.65+0x83/0xa0
      [  638.984214]  [<ffffffff81306b9f>] blk_update_request+0x7f/0x350
      [  638.985967]  [<ffffffff81306ea1>] blk_update_bidi_request+0x31/0x90
      [  638.987710]  [<ffffffff813085e0>] __blk_end_bidi_request+0x20/0x50
      [  638.989439]  [<ffffffff8130862f>] __blk_end_request_all+0x1f/0x30
      [  638.991149]  [<ffffffff81308746>] blk_peek_request+0x106/0x250
      [  638.992861]  [<ffffffff814a62a9>] ? scsi_kill_request.isra.32+0xe9/0x130
      [  638.994561]  [<ffffffff814a633a>] scsi_request_fn+0x4a/0x3d0
      [  638.996251]  [<ffffffff813040a7>] __blk_run_queue+0x37/0x50
      [  638.997900]  [<ffffffff813045af>] blk_run_queue+0x2f/0x50
      [  638.999553]  [<ffffffff814a5750>] scsi_run_queue+0xe0/0x1c0
      [  639.001185]  [<ffffffff814a7721>] scsi_run_host_queues+0x21/0x40
      [  639.002798]  [<ffffffff814a2e87>] scsi_restart_operations+0x177/0x200
      [  639.004391]  [<ffffffff814a4fe9>] scsi_error_handler+0xc9/0xe0
      [  639.005996]  [<ffffffff814a4f20>] ? scsi_unjam_host+0xd0/0xd0
      [  639.007600]  [<ffffffff81072f6b>] kthread+0xdb/0xe0
      [  639.009205]  [<ffffffff81072e90>] ? flush_kthread_worker+0x170/0x170
      [  639.010821]  [<ffffffff81748cac>] ret_from_fork+0x7c/0xb0
      [  639.012437]  [<ffffffff81072e90>] ? flush_kthread_worker+0x170/0x170
      
      This bug was introduce in commit  2e8ac303
      (the first time rdev_set_badblock was call from interrupt context),
      so this patch is appropriate for 3.5 and subsequent kernels.
      
      Cc: <stable@vger.kernel.org> (3.5+)
      Signed-off-by: NBian Yu <bianyu@kedacom.com>
      Reviewed-by: NJianpeng Ma <majianpeng@gmail.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      905b0297
    • L
      md: Fix skipping recovery for read-only arrays. · 61e4947c
      Lukasz Dorau 提交于
      Since:
              commit 7ceb17e8
              md: Allow devices to be re-added to a read-only array.
      
      spares are activated on a read-only array. In case of raid1 and raid10
      personalities it causes that not-in-sync devices are marked in-sync
      without checking if recovery has been finished.
      
      If a read-only array is degraded and one of its devices is not in-sync
      (because the array has been only partially recovered) recovery will be skipped.
      
      This patch adds checking if recovery has been finished before marking a device
      in-sync for raid1 and raid10 personalities. In case of raid5 personality
      such condition is already present (at raid5.c:6029).
      
      Bug was introduced in 3.10 and causes data corruption.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NPawel Baldysiak <pawel.baldysiak@intel.com>
      Signed-off-by: NLukasz Dorau <lukasz.dorau@intel.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      61e4947c
  2. 23 10月, 2013 4 次提交
  3. 22 10月, 2013 14 次提交
  4. 21 10月, 2013 2 次提交
  5. 19 10月, 2013 11 次提交
  6. 18 10月, 2013 7 次提交
    • B
      drm/i915: Disable GGTT PTEs on GEN6+ suspend · 828c7908
      Ben Widawsky 提交于
      Once the machine gets to a certain point in the suspend process, we
      expect the GPU to be idle. If it is not, we might corrupt memory.
      Empirically (with an early version of this patch) we have seen this is
      not the case. We cannot currently explain why the latent GPU writes
      occur.
      
      In the technical sense, this patch is a workaround in that we have an
      issue we can't explain, and the patch indirectly solves the issue.
      However, it's really better than a workaround because we understand why
      it works, and it really should be a safe thing to do in all cases.
      
      The noticeable effect other than the debug messages would be an increase
      in the suspend time. I have not measure how expensive it actually is.
      
      I think it would be good to spend further time to root cause why we're
      seeing these latent writes, but it shouldn't preclude preventing the
      fallout.
      
      NOTE: It should be safe (and makes some sense IMO) to also keep the
      VALID bit unset on resume when we clear_range(). I've opted not to do
      this as properly clearing those bits at some later point would be extra
      work.
      
      v2: Fix bugzilla link
      
      Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=65496
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59321Tested-by: NTakashi Iwai <tiwai@suse.de>
      Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Tested-By: NTodd Previte <tprevite@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      828c7908
    • B
      drm/i915: Make PTE valid encoding optional · b35b380e
      Ben Widawsky 提交于
      We need this to work around a corruption when the boot kernel image
      loads the hibernated kernel image from swap on Haswell systems -
      somehow not everything is properly shut off.
      
      This is just the prep work, the next patch will implement the actual
      workaround.
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      [danvet: Add a commit message suitable for -fixes and add cc: stable]
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b35b380e
    • N
      HID: Fix unit exponent parsing again · ad0e669b
      Nikolai Kondrashov 提交于
      Revert some changes done in 77463838.
      
      Revert all changes done in hidinput_calc_abs_res as it mistakingly used
      "Unit" item exponent nibbles to affect resolution value. This wasn't
      breaking resolution calculation of relevant axes of any existing
      devices, though, as they have only one dimension to their units and thus
      1 in the corresponding nible.
      
      Revert to reading "Unit Exponent" item value as a signed integer in
      hid_parser_global to fix reading specification-complying values. This
      fixes resolution calculation of devices complying to the HID standard,
      including Huion, KYE, Waltop and UC-Logic graphics tablets which have
      their report descriptors fixed by the drivers.
      
      Explanations follow.
      
      There are two "unit exponents" in HID specification and it is important
      not to mix them. One is the global "Unit Exponent" item and another is
      nibble values in the global "Unit" item. See 6.2.2.7 Global Items.
      
      The "Unit Exponent" value is just a signed integer and is used to scale
      the integer resolution unit values, so fractions can be expressed.
      
      The nibbles of "Unit" value are used to select the unit system (nibble
      0), and presence of a particular basic unit type in the unit formula and
      its *exponent* (or power, nibbles 1-6). And yes, the latter is in two
      complement and zero means absence of the unit type.
      
      Taking the representation example of (integer) joules from the
      specification:
      
      [mass(grams)][length(centimeters)^2][time(seconds)^-2] * 10^-7
      
      the "Unit Exponent" would be -7 (or 0xF9, if stored as a byte) and the
      "Unit" value would be 0xE121, signifying:
      
      Nibble  Part        Value   Meaning
      -----   ----        -----   -------
      0       System      1       SI Linear
      1       Length      2       Centimeters^2
      2       Mass        1       Grams
      3       Time        -2      Seconds^-2
      
      To give the resolution in e.g. hundredth of joules the "Unit Exponent"
      item value should have been -9.
      
      See also the examples of "Unit" values for some common units in the same
      chapter.
      
      However, there is a common misunderstanding about the "Unit Exponent"
      value encoding, where it is assumed to be stored the same as nibbles in
      "Unit" item. This is most likely due to the specification being a bit
      vague and overloading the term "unit exponent". This also was and still
      is proliferated by the official "HID Descriptor Tool", which makes this
      mistake and stores "Unit Exponent" as such. This format is also
      mentioned in books such as "USB Complete" and in Microsoft's hardware
      design guides.
      
      As a result many devices currently on the market use this encoding and
      so the driver should support them.
      Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
      Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      ad0e669b
    • C
      drm: Prevent overwriting from userspace underallocating core ioctl structs · b062672e
      Chris Wilson 提交于
      Apply the protections from
      
      commit 1b2f1489
      Author: Dave Airlie <airlied@redhat.com>
      Date:   Sat Aug 14 20:20:34 2010 +1000
      
          drm: block userspace under allocating buffer and having drivers overwrite it (v2)
      
      to the core ioctl structs as well, for we found one instance where there
      is a 32-/64-bit size mismatch and were guilty of writing beyond the end
      of the user's buffer.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Dave Airlie <airlied@redhat.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Cc: dri-devel@lists.freedesktop.org
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      b062672e
    • E
      net: qmi_wwan: Olivetti Olicard 200 support · ce97fef4
      Enrico Mioso 提交于
      This is a QMI device, manufactured by TCT Mobile Phones.
      A companion patch blacklisting this device's QMI interface in the option.c
      driver has been sent.
      Signed-off-by: NEnrico Mioso <mrkiko.rs@gmail.com>
      Signed-off-by: NAntonella Pellizzari <anto.pellizzari83@gmail.com>
      Tested-by: NDan Williams <dcbw@redhat.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ce97fef4
    • J
      virtio-net: refill only when device is up during setting queues · 35ed159b
      Jason Wang 提交于
      We used to schedule the refill work unconditionally after changing the
      number of queues. This may lead an issue if the device is not
      up. Since we only try to cancel the work in ndo_stop(), this may cause
      the refill work still work after removing the device. Fix this by only
      schedule the work when device is up.
      
      The bug were introduce by commit 9b9cd802.
      (virtio-net: fix the race between channels setting and refill)
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      35ed159b
    • J
      virtio-net: don't respond to cpu hotplug notifier if we're not ready · 3ab098df
      Jason Wang 提交于
      We're trying to re-configure the affinity unconditionally in cpu hotplug
      callback. This may lead the issue during resuming from s3/s4 since
      
      - virt queues haven't been allocated at that time.
      - it's unnecessary since thaw method will re-configure the affinity.
      
      Fix this issue by checking the config_enable and do nothing is we're not ready.
      
      The bug were introduced by commit 8de4b2f3
      (virtio-net: reset virtqueue affinity when doing cpu hotplug).
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: NWanlong Gao <gaowanlong@cn.fujitsu.com>
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3ab098df