1. 26 Mar, 2015 22 commits
  2. 18 Mar, 2015 18 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.10.72 · 7f4e6424
      Greg Kroah-Hartman authored
      7f4e6424
    • Sergey Ryazanov's avatar
      ath5k: fix spontaneus AR5312 freezes · 868fd3d3
      Sergey Ryazanov authored
      commit 8bfae4f9 upstream.
      
      Sometimes while CPU have some load and ath5k doing the wireless
      interface reset the whole WiSoC completely freezes. Set of tests shows
      that using atomic delay function while we wait interface reset helps to
      avoid such freezes.
      
      The easiest way to reproduce this issue: create a station interface,
      start continous scan with wpa_supplicant and load CPU by something. Or
      just create multiple station interfaces and put them all in continous
      scan.
      
      This patch partially reverts the commit 1846ac3d ("ath5k: Use
      usleep_range where possible"), which replaces initial udelay()
      by usleep_range().
      
      I do not know actual source of this issue, but all looks like that HW
      freeze is caused by transaction on internal SoC bus, while wireless
      block is in reset state.
      
      Also I should note that I do not know how many chips are affected, but I
      did not see this issue with chips, other than AR5312.
      
      CC: Jiri Slaby <jirislaby@gmail.com>
      CC: Nick Kossifidis <mickflemm@gmail.com>
      CC: Luis R. Rodriguez <mcgrof@do-not-panic.com>
      Fixes: 1846ac3d ("ath5k: Use usleep_range where possible")
      Reported-by: default avatarChristophe Prevotaux <c.prevotaux@rural-networks.com>
      Tested-by: default avatarChristophe Prevotaux <c.prevotaux@rural-networks.com>
      Tested-by: default avatarEric Bree <ebree@nltinc.com>
      Signed-off-by: default avatarSergey Ryazanov <ryazanov.s.a@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      868fd3d3
    • Chris Wilson's avatar
      ACPI / video: Load the module even if ACPI is disabled · 8686fc3d
      Chris Wilson authored
      commit 6e17cb12 upstream.
      
      i915.ko depends upon the acpi/video.ko module and so refuses to load if
      ACPI is disabled at runtime if for example the BIOS is broken beyond
      repair. acpi/video provides an optional service for i915.ko and so we
      should just allow the modules to load, but do no nothing in order to let
      the machines boot correctly.
      Reported-by: default avatarBill Augur <bill-auger@programmer.net>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Acked-by: default avatarAaron Lu <aaron.lu@intel.com>
      [ rjw: Fixed up the new comment in acpi_video_init() ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8686fc3d
    • Alex Deucher's avatar
      drm/radeon: fix 1 RB harvest config setup for TN/RL · 7f0240c5
      Alex Deucher authored
      commit dbfb00c3 upstream.
      
      The logic was reversed from what the hw actually exposed.
      Fixes graphics corruption in certain harvest configurations.
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7f0240c5
    • Fernando Soto's avatar
      Drivers: hv: vmbus: incorrect device name is printed when child device is unregistered · a370f956
      Fernando Soto authored
      commit 84672369 upstream.
      
      Whenever a device is unregistered in vmbus_device_unregister (drivers/hv/vmbus_drv.c), the device name in the log message may contain garbage as the memory has already been freed by the time pr_info is called. Log example:
       [ 3149.170475] hv_vmbus: child device àõsèè0_5 unregistered
      
      By logging the message just before calling device_unregister, the correct device name is printed:
      [ 3145.034652] hv_vmbus: child device vmbus_0_5 unregistered
      
      Also changing register & unregister messages to debug to avoid unnecessarily cluttering the kernel log.
      Signed-off-by: default avatarFernando M Soto <fsoto@bluecatnetworks.com>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Cc: Joseph Salisbury <joseph.salisbury@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a370f956
    • Jiri Kosina's avatar
      HID: fixup the conflicting keyboard mappings quirk · 0ec88c96
      Jiri Kosina authored
      commit 8e7b3410 upstream.
      
      The ignore check that got added in 6ce901eb ("HID: input: fix confusion
      on conflicting mappings") needs to properly check for VARIABLE reports
      as well (ARRAY reports should be ignored), otherwise legitimate keyboards
      might break.
      
      Fixes: 6ce901eb ("HID: input: fix confusion on conflicting mappings")
      Reported-by: default avatarFredrik Hallenberg <megahallon@gmail.com>
      Reported-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ec88c96
    • David Herrmann's avatar
      HID: input: fix confusion on conflicting mappings · 3e886ecb
      David Herrmann authored
      commit 6ce901eb upstream.
      
      On an PC-101/103/104 keyboard (American layout) the 'Enter' key and its
      neighbours look like this:
      
                 +---+ +---+ +-------+
                 | 1 | | 2 | |   5   |
                 +---+ +---+ +-------+
                   +---+ +-----------+
                   | 3 | |     4     |
                   +---+ +-----------+
      
      On a PC-102/105 keyboard (European layout) it looks like this:
      
                 +---+ +---+ +-------+
                 | 1 | | 2 | |       |
                 +---+ +---+ +-+  4  |
                   +---+ +---+ |     |
                   | 3 | | 5 | |     |
                   +---+ +---+ +-----+
      
      (Note that the number of keys is the same, but key '5' is moved down and
       the shape of key '4' is changed. Keys '1' to '3' are exactly the same.)
      
      The keys 1-4 report the same scan-code in HID in both layouts, even though
      the keysym they produce is usually different depending on the XKB-keymap
      used by user-space.
      However, key '5' (US 'backslash'/'pipe') reports 0x31 for the upper layout
      and 0x32 for the lower layout, as defined by the HID spec. This is highly
      confusing as the linux-input API uses a single keycode for both.
      
      So far, this was never a problem as there never has been a keyboard with
      both of those keys present at the same time. It would have to look
      something like this:
      
                 +---+ +---+ +-------+
                 | 1 | | 2 | |  x31  |
                 +---+ +---+ +-------+
                   +---+ +---+ +-----+
                   | 3 | |x32| |  4  |
                   +---+ +---+ +-----+
      
      HID can represent such a keyboard, but the linux-input API cannot.
      Furthermore, any user-space mapping would be confused by this and,
      luckily, no-one ever produced such hardware.
      
      Now, the HID input layer fixed this mess by mapping both 0x31 and 0x32 to
      the same keycode (KEY_BACKSLASH==0x2b). As only one of both physical keys
      is present on a hardware, this works just fine.
      
      Lets introduce hardware-vendors into this:
      ------------------------------------------
      
      Unfortunately, it seems way to expensive to produce a different device for
      American and European layouts. Therefore, hardware-vendors put both keys,
      (0x31 and 0x32) on the same keyboard, but only one of them is hooked up
      to the physical button, the other one is 'dead'.
      This means, they can use the same hardware, with a different button-layout
      and automatically produce the correct HID events for American *and*
      European layouts. This is unproblematic for normal keyboards, as the
      'dead' key will never report any KEY-DOWN events. But RollOver keyboards
      send the whole matrix on each key-event, allowing n-key roll-over mode.
      This means, we get a 0x31 and 0x32 event on each key-press. One of them
      will always be 0, the other reports the real state. As we map both to the
      same keycode, we will get spurious key-events, even though the real
      key-state never changed.
      
      The easiest way would be to blacklist 'dead' keys and never handle those.
      We could simply read the 'country' tag of USB devices and blacklist either
      key according to the layout. But... hardware vendors... want the same
      device for all countries and thus many of them set 'country' to 0 for all
      devices. Meh..
      
      So we have to deal with this properly. As we cannot know which of the keys
      is 'dead', we either need a heuristic and track those keys, or we simply
      make use of our value-tracking for HID fields. We simply ignore HID events
      for absolute data if the data didn't change. As HID tracks events on the
      HID level, we haven't done the keycode translation, yet. Therefore, the
      'dead' key is tracked independently of the real key, therefore, any events
      on it will be ignored.
      
      This patch simply discards any HID events for absolute data if it didn't
      change compared to the last report. We need to ignore relative and
      buffered-byte reports for obvious reasons. But those cannot be affected by
      this bug, so we're fine.
      
      Preferably, we'd do this filtering on the HID-core level. But this might
      break a lot of custom drivers, if they do not follow the HID specs.
      Therefore, we do this late in hid-input just before we inject it into the
      input layer (which does the exact same filtering, but on the keycode
      level).
      
      If this turns out to break some devices, we might have to limit filtering
      to EV_KEY events. But lets try to do the Right Thing first, and properly
      filter any absolute data that didn't change.
      
      This patch is tagged for 'stable' as it fixes a lot of n-key RollOver
      hardware. We might wanna wait with backporting for a while, before we know
      it doesn't break anything else, though.
      Reported-by: default avatarAdam Goode <adam@spicenitz.org>
      Reported-by: default avatarFredrik Hallenberg <megahallon@gmail.com>
      Tested-by: default avatarFredrik Hallenberg <megahallon@gmail.com>
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e886ecb
    • Ian Abbott's avatar
      staging: comedi: cb_pcidas64: fix incorrect AI range code handling · 52857af3
      Ian Abbott authored
      commit be8e8908 upstream.
      
      The hardware range code values and list of valid ranges for the AI
      subdevice is incorrect for several supported boards.  The hardware range
      code values for all boards except PCI-DAS4020/12 is determined by
      calling `ai_range_bits_6xxx()` based on the maximum voltage of the range
      and whether it is bipolar or unipolar, however it only returns the
      correct hardware range code for the PCI-DAS60xx boards.  For
      PCI-DAS6402/16 (and /12) it returns the wrong code for the unipolar
      ranges.  For PCI-DAS64/Mx/16 it returns the wrong code for all the
      ranges and the comedi range table is incorrect.
      
      Change `ai_range_bits_6xxx()` to use a look-up table pointed to by new
      member `ai_range_codes` of `struct pcidas64_board` to map the comedi
      range table indices to the hardware range codes.  Use a new comedi range
      table for the PCI-DAS64/Mx/16 boards (and the commented out variants).
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      52857af3
    • Mikulas Patocka's avatar
      dm snapshot: fix a possible invalid memory access on unload · 840732fd
      Mikulas Patocka authored
      commit 22aa66a3 upstream.
      
      When the snapshot target is unloaded, snapshot_dtr() waits until
      pending_exceptions_count drops to zero.  Then, it destroys the snapshot.
      Therefore, the function that decrements pending_exceptions_count
      should not touch the snapshot structure after the decrement.
      
      pending_complete() calls free_pending_exception(), which decrements
      pending_exceptions_count, and then it performs up_write(&s->lock) and it
      calls retry_origin_bios() which dereferences  s->origin.  These two
      memory accesses to the fields of the snapshot may touch the dm_snapshot
      struture after it is freed.
      
      This patch moves the call to free_pending_exception() to the end of
      pending_complete(), so that the snapshot will not be destroyed while
      pending_complete() is in progress.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      840732fd
    • Mikulas Patocka's avatar
      dm: fix a race condition in dm_get_md · 6bed72e4
      Mikulas Patocka authored
      commit 2bec1f4a upstream.
      
      The function dm_get_md finds a device mapper device with a given dev_t,
      increases the reference count and returns the pointer.
      
      dm_get_md calls dm_find_md, dm_find_md takes _minor_lock, finds the
      device, tests that the device doesn't have DMF_DELETING or DMF_FREEING
      flag, drops _minor_lock and returns pointer to the device. dm_get_md then
      calls dm_get. dm_get calls BUG if the device has the DMF_FREEING flag,
      otherwise it increments the reference count.
      
      There is a possible race condition - after dm_find_md exits and before
      dm_get is called, there are no locks held, so the device may disappear or
      DMF_FREEING flag may be set, which results in BUG.
      
      To fix this bug, we need to call dm_get while we hold _minor_lock. This
      patch renames dm_find_md to dm_get_md and changes it so that it calls
      dm_get while holding the lock.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6bed72e4
    • Darrick J. Wong's avatar
      dm io: reject unsupported DISCARD requests with EOPNOTSUPP · 0696dbb4
      Darrick J. Wong authored
      commit 37527b86 upstream.
      
      I created a dm-raid1 device backed by a device that supports DISCARD
      and another device that does NOT support DISCARD with the following
      dm configuration:
      
       #  echo '0 2048 mirror core 1 512 2 /dev/sda 0 /dev/sdb 0' | dmsetup create moo
       # lsblk -D
       NAME         DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
       sda                 0        4K       1G         0
       `-moo (dm-0)        0        4K       1G         0
       sdb                 0        0B       0B         0
       `-moo (dm-0)        0        4K       1G         0
      
      Notice that the mirror device /dev/mapper/moo advertises DISCARD
      support even though one of the mirror halves doesn't.
      
      If I issue a DISCARD request (via fstrim, mount -o discard, or ioctl
      BLKDISCARD) through the mirror, kmirrord gets stuck in an infinite
      loop in do_region() when it tries to issue a DISCARD request to sdb.
      The problem is that when we call do_region() against sdb, num_sectors
      is set to zero because q->limits.max_discard_sectors is zero.
      Therefore, "remaining" never decreases and the loop never terminates.
      
      To fix this: before entering the loop, check for the combination of
      REQ_DISCARD and no discard and return -EOPNOTSUPP to avoid hanging up
      the mirror device.
      
      This bug was found by the unfortunate coincidence of pvmove and a
      discard operation in the RHEL 6.5 kernel; upstream is also affected.
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Acked-by: default avatar"Martin K. Petersen" <martin.petersen@oracle.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0696dbb4
    • Mikulas Patocka's avatar
      dm mirror: do not degrade the mirror on discard error · 8843f1a0
      Mikulas Patocka authored
      commit f2ed51ac upstream.
      
      It may be possible that a device claims discard support but it rejects
      discards with -EOPNOTSUPP.  It happens when using loopback on ext2/ext3
      filesystem driven by the ext4 driver.  It may also happen if the
      underlying devices are moved from one disk on another.
      
      If discard error happens, we reject the bio with -EOPNOTSUPP, but we do
      not degrade the array.
      
      This patch fixes failed test shell/lvconvert-repair-transient.sh in the
      lvm2 testsuite if the testsuite is extracted on an ext2 or ext3
      filesystem and it is being driven by the ext4 driver.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8843f1a0
    • Ian Abbott's avatar
      staging: comedi: comedi_compat32.c: fix COMEDI_CMD copy back · 596c469f
      Ian Abbott authored
      commit 42b8ce6f upstream.
      
      `do_cmd_ioctl()` in "comedi_fops.c" handles the `COMEDI_CMD` ioctl.
      This returns `-EAGAIN` if it has copied a modified `struct comedi_cmd`
      back to user-space.  (This occurs when the low-level Comedi driver's
      `do_cmdtest()` handler returns non-zero to indicate a problem with the
      contents of the `struct comedi_cmd`, or when the `struct comedi_cmd` has
      the `CMDF_BOGUS` flag set.)
      
      `compat_cmd()` in "comedi_compat32.c" handles the 32-bit compatible
      version of the `COMEDI_CMD` ioctl.  Currently, it never copies a 32-bit
      compatible version of `struct comedi_cmd` back to user-space, which is
      at odds with the way the regular `COMEDI_CMD` ioctl is handled.  To fix
      it, change `compat_cmd()` to copy a 32-bit compatible version of the
      `struct comedi_cmd` back to user-space when the main ioctl handler
      returns `-EAGAIN`.
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Reviewed-by: default avatarH Hartley Sweeten <hsweeten@visionengravers.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      596c469f
    • Chen-Yu Tsai's avatar
      clk: sunxi: Support factor clocks with N factor starting not from 0 · 6e6493c2
      Chen-Yu Tsai authored
      commit 9a5e6c7e upstream.
      
      The PLLs on newer Allwinner SoC's, such as the A31 and A23, have a
      N multiplier factor that starts from 1, not 0.
      
      This patch adds an option to the factor clk driver's config data
      structures to specify the base value of N.
      Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
      Acked-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e6493c2
    • Minh Duc Tran's avatar
      fixed invalid assignment of 64bit mask to host dma_boundary for scatter gather... · 28e75102
      Minh Duc Tran authored
      fixed invalid assignment of 64bit mask to host dma_boundary for scatter gather segment boundary limit.
      
      commit f76a610a upstream.
      
      In reference to bug https://bugzilla.redhat.com/show_bug.cgi?id=1097141
      Assert is seen with AMD cpu whenever calling pci_alloc_consistent.
      
      [   29.406183] ------------[ cut here ]------------
      [   29.410505] kernel BUG at lib/iommu-helper.c:13!
      Signed-off-by: default avatarMinh Tran <minh.tran@emulex.com>
      Fixes: 6733b39aSigned-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      28e75102
    • Ryusuke Konishi's avatar
      nilfs2: fix potential memory overrun on inode · b6b14e98
      Ryusuke Konishi authored
      commit 957ed60b upstream.
      
      Each inode of nilfs2 stores a root node of a b-tree, and it turned out to
      have a memory overrun issue:
      
      Each b-tree node of nilfs2 stores a set of key-value pairs and the number
      of them (in "bn_nchildren" member of nilfs_btree_node struct), as well as
      a few other "bn_*" members.
      
      Since the value of "bn_nchildren" is used for operations on the key-values
      within the b-tree node, it can cause memory access overrun if a large
      number is incorrectly set to "bn_nchildren".
      
      For instance, nilfs_btree_node_lookup() function determines the range of
      binary search with it, and too large "bn_nchildren" leads
      nilfs_btree_node_get_key() in that function to overrun.
      
      As for intermediate b-tree nodes, this is prevented by a sanity check
      performed when each node is read from a drive, however, no sanity check
      has been done for root nodes stored in inodes.
      
      This patch fixes the issue by adding missing sanity check against b-tree
      root nodes so that it's called when on-memory inodes are read from ifile,
      inode metadata file.
      Signed-off-by: default avatarRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b6b14e98
    • Mitko Haralanov's avatar
      IB/qib: Do not write EEPROM · 1152730c
      Mitko Haralanov authored
      commit 18c0b82a upstream.
      
      This changeset removes all the code that allows the driver to write to
      the EEPROM and update the recorded error counters and power on hours.
      
      These two stats are unused and writing them exposes a timing risk
      which could leave the EEPROM in a bad state preventing further normal
      operation of the HCA.
      Reviewed-by: default avatarMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: default avatarMitko Haralanov <mitko.haralanov@intel.com>
      Signed-off-by: default avatarMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1152730c
    • Tony Battersby's avatar
      sg: fix read() error reporting · 7e959418
      Tony Battersby authored
      commit 3b524a68 upstream.
      
      Fix SCSI generic read() incorrectly returning success after detecting an
      error.
      Signed-off-by: default avatarTony Battersby <tonyb@cybernetics.com>
      Acked-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7e959418