1. 04 Oct, 2013 1 commit
  2. 02 Oct, 2013 1 commit
  3. 01 Oct, 2013 4 commits
  4. 27 Sep, 2013 34 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.4.63 · 940d5466
      Greg Kroah-Hartman authored
    • Anand Avati's avatar
      fuse: invalidate inode attributes on xattr modification · b6a40685
      Anand Avati authored
      commit d331a415aef98717393dda0be69b7947da08eba3 upstream.
      Calls like setxattr and removexattr result in updation of ctime.
      Therefore invalidate inode attributes to force a refresh.
      Signed-off-by: default avatarAnand Avati <avati@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Maxim Patlasov's avatar
      fuse: postpone end_page_writeback() in fuse_writepage_locked() · ec00ecaf
      Maxim Patlasov authored
      commit 4a4ac4eba1010ef9a804569058ab29e3450c0315 upstream.
      The patch fixes a race between ftruncate(2), mmap-ed write and write(2):
      1) An user makes a page dirty via mmap-ed write.
      2) The user performs shrinking truncate(2) intended to purge the page.
      3) Before fuse_do_setattr calls truncate_pagecache, the page goes to
         writeback. fuse_writepage_locked fills FUSE_WRITE request and releases
         the original page by end_page_writeback.
      4) fuse_do_setattr() completes and successfully returns. Since now, i_mutex
         is free.
      5) Ordinary write(2) extends i_size back to cover the page. Note that
         fuse_send_write_pages do wait for fuse writeback, but for another
      6) fuse_writepage_locked proceeds by queueing FUSE_WRITE request.
         fuse_send_writepage is supposed to crop inarg->size of the request,
         but it doesn't because i_size has already been extended back.
      Moving end_page_writeback to the end of fuse_writepage_locked fixes the
      race because now the fact that truncate_pagecache is successfully returned
      infers that fuse_writepage_locked has already called end_page_writeback.
      And this, in turn, infers that fuse_flush_writepages has already called
      fuse_send_writepage, and the latter used valid (shrunk) i_size. write(2)
      could not extend it because of i_mutex held by ftruncate(2).
      Signed-off-by: default avatarMaxim Patlasov <mpatlasov@parallels.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Grant Likely's avatar
      of: Fix missing memory initialization on FDT unflattening · 579fc7a3
      Grant Likely authored
      commit 0640332e073be9207f0784df43595c0c39716e42 upstream.
      Any calls to dt_alloc() need to be zeroed. This is a temporary fix, but
      the allocation function itself needs to zero memory before returning
      it. This is a follow up to patch 9e4012752, "of: fdt: fix memory
      initialization for expanded DT" which fixed one call site but missed
      Signed-off-by: default avatarGrant Likely <grant.likely@linaro.org>
      Acked-by: default avatarWladislav Wiebe <wladislav.kw@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Sergei Shtylyov's avatar
      mmc: tmio_mmc_dma: fix PIO fallback on SDHI · ae48ae82
      Sergei Shtylyov authored
      commit f936f9b67b7f8c2eae01dd303a0e90bd777c4679 upstream.
      I'm testing SH-Mobile SDHI driver in DMA mode with  a new DMA controller  using
      'bonnie++' and getting DMA error after which the tmio_mmc_dma.c code falls back
      to PIO but all commands time out after that.  It turned out that the fallback
      code calls tmio_mmc_enable_dma() with RX/TX channels already freed and pointers
      to them cleared, so that the function bails out early instead  of clearing the
      DMA bit in the CTL_DMA_ENABLE register. The regression was introduced by commit
       (mmc: tmio: fix a deadlock).
      Moving tmio_mmc_enable_dma() calls to the top of the PIO fallback code in
      tmio_mmc_start_dma_{rx|tx}() helps.
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Acked-by: default avatarGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alex Deucher's avatar
      drm/edid: add quirk for Medion MD30217PG · d060c0b7
      Alex Deucher authored
      commit 118bdbd86b39dbb843155054021d2c59058f1e05 upstream.
      This LCD monitor (1280x1024 native) has a completely
      bogus detailed timing (640x350@70hz).  User reports that
      1280x1024@60 has waves so prefer 1280x1024@75.
      Manufacturer: MED  Model: 7b8  Serial#: 99188
      Year: 2005  Week: 5
      EDID Version: 1.3
      Analog Display Input,  Input Voltage Level: 0.700/0.700 V
      Sync:  Separate
      Max Image Size [cm]: horiz.: 34  vert.: 27
      Gamma: 2.50
      DPMS capabilities: Off; RGB/Color Display
      First detailed timing is preferred mode
      redX: 0.645 redY: 0.348   greenX: 0.280 greenY: 0.605
      blueX: 0.142 blueY: 0.071   whiteX: 0.313 whiteY: 0.329
      Supported established timings:
      Manufacturer's mask: 0
      Supported standard timings:
      Supported detailed timing:
      clock: 25.2 MHz   Image Size:  337 x 270 mm
      h_active: 640  h_sync: 688  h_sync_end 784 h_blank_end 800 h_border: 0
      v_active: 350  v_sync: 350  v_sync_end 352 v_blanking: 449 v_border: 0
      Monitor name: MD30217PG
      Ranges: V min: 56 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 145 MHz
      Serial No: 501099188
      EDID (in hex):
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Reported-by: friedrich@mailstation.de
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jan Kara's avatar
      isofs: Refuse RW mount of the filesystem instead of making it RO · 512ecf84
      Jan Kara authored
      commit 17b7f7cf58926844e1dd40f5eb5348d481deca6a upstream.
      Refuse RW mount of isofs filesystem. So far we just silently changed it
      to RO mount but when the media is writeable, block layer won't notice
      this change and thus will think device is used RW and will block eject
      button of the drive. That is unexpected by users because for
      non-writeable media eject button works just fine.
      Userspace mount(8) command handles this just fine and retries mounting
      with MS_RDONLY set so userspace shouldn't see any regression.  Plus any
      tool mounting isofs is likely confronted with the case of read-only
      media where block layer already refuses to mount the filesystem without
      MS_RDONLY set so our behavior shouldn't be anything new for it.
      Reported-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Libin's avatar
      mm/huge_memory.c: fix potential NULL pointer dereference · d778ca56
      Libin authored
      commit a8f531ebc33052642b4bd7b812eedf397108ce64 upstream.
      In collapse_huge_page() there is a race window between releasing the
      mmap_sem read lock and taking the mmap_sem write lock, so find_vma() may
      return NULL.  So check the return value to avoid NULL pointer dereference.
      	vma = find_vma(mm, address)
      Signed-off-by: default avatarLibin <huawei.libin@huawei.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Reviewed-by: default avatarWanpeng Li <liwanp@linux.vnet.ibm.com>
      Reviewed-by: default avatarMichal Hocko <mhocko@suse.cz>
      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>
    • Greg Thelen's avatar
      memcg: fix multiple large threshold notifications · 5a20c03a
      Greg Thelen authored
      commit 2bff24a3707093c435ab3241c47dcdb5f16e432b upstream.
      A memory cgroup with (1) multiple threshold notifications and (2) at least
      one threshold >=2G was not reliable.  Specifically the notifications would
      either not fire or would not fire in the proper order.
      The __mem_cgroup_threshold() signaling logic depends on keeping 64 bit
      thresholds in sorted order.  mem_cgroup_usage_register_event() sorts them
      with compare_thresholds(), which returns the difference of two 64 bit
      thresholds as an int.  If the difference is positive but has bit[31] set,
      then sort() treats the difference as negative and breaks sort order.
      This fix compares the two arbitrary 64 bit thresholds returning the
      classic -1, 0, 1 result.
      The test below sets two notifications (at 0x1000 and 0x81001000):
        cd /sys/fs/cgroup/memory
        mkdir x
        for x in 4096 2164264960; do
          cgroup_event_listener x/memory.usage_in_bytes $x | sed "s/^/$x listener:/" &
        echo $$ > x/cgroup.procs
        anon_leaker 500M
      v3.11-rc7 fails to signal the 4096 event listener:
        Done leaking pages.
      Patched v3.11-rc7 properly notifies:
        4096 listener:2013:8:31:14:13:36
        Done leaking pages.
      The fixed bug is old.  It appears to date back to the introduction of
      memcg threshold notifications in v2.6.34-rc1-116-g2e72b634
      implement memory thresholds"
      Signed-off-by: default avatarGreg Thelen <gthelen@google.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.cz>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      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>
    • Jie Liu's avatar
      ocfs2: fix the end cluster offset of FIEMAP · 55ee351d
      Jie Liu authored
      commit 28e8be31803b19d0d8f76216cb11b480b8a98bec upstream.
      Call fiemap ioctl(2) with given start offset as well as an desired mapping
      range should show extents if possible.  However, we somehow figure out the
      end offset of mapping via 'mapping_end -= cpos' before iterating the
      extent records which would cause problems if the given fiemap length is
      too small to a cluster size, e.g,
      Cluster size 4096:
      debugfs.ocfs2 1.6.3
              Block Size Bits: 12   Cluster Size Bits: 12
      The extended fiemap test utility From David:
      # dd if=/dev/urandom of=/ocfs2/test_file bs=1M count=1000
      # ./fiemap /ocfs2/test_file 4096 10
      start: 4096, length: 10
      File /ocfs2/test_file has 0 extents:
      #	Logical          Physical         Length           Flags
      	^^^^^ <-- No extent is shown
      In this case, at ocfs2_fiemap(): cpos == mapping_end == 1. Hence the
      loop of searching extent records was not executed at all.
      This patch remove the in question 'mapping_end -= cpos', and loops
      until the cpos is larger than the mapping_end as usual.
      # ./fiemap /ocfs2/test_file 4096 10
      start: 4096, length: 10
      File /ocfs2/test_file has 1 extents:
      #	Logical          Physical         Length           Flags
      0:	0000000000000000 0000000056a01000 0000000006a00000 0000
      Signed-off-by: default avatarJie Liu <jeff.liu@oracle.com>
      Reported-by: default avatarDavid Weber <wb@munzinger.de>
      Tested-by: default avatarDavid Weber <wb@munzinger.de>
      Cc: Sunil Mushran <sunil.mushran@gmail.com>
      Cc: Mark Fashen <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      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>
    • Alex Williamson's avatar
      intel-iommu: Fix leaks in pagetable freeing · 4013fc20
      Alex Williamson authored
      commit 3269ee0bd6686baf86630300d528500ac5b516d7 upstream.
      At best the current code only seems to free the leaf pagetables and
      the root.  If you're unlucky enough to have a large gap (like any
      QEMU guest with more than 3G of memory), only the first chunk of leaf
      pagetables are freed (plus the root).  This is a massive memory leak.
      This patch re-writes the pagetable freeing function to use a
      recursive algorithm and manages to not only free all the pagetables,
      but does it without any apparent performance loss versus the current
      broken version.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Reviewed-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: default avatarJoerg Roedel <joro@8bytes.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Felix Fietkau's avatar
      MIPS: ath79: Fix ar933x watchdog clock · 150189a1
      Felix Fietkau authored
      commit a1191927ace7e6f827132aa9e062779eb3f11fa5 upstream.
      The watchdog device on the AR933x is connected to
      the AHB clock, however the current code uses the
      reference clock. Due to the wrong rate, the watchdog
      driver can't calculate correct register values for
      a given timeout value and the watchdog unexpectedly
      restarts the system.
      The code uses the wrong value since the initial
      commit 04225e1d
      (MIPS: ath79: add AR933X specific clock init)
      The patch fixes the code to use the correct clock
      rate to avoid the problem.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarGabor Juhos <juhosg@openwrt.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/5777/
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Andrzej Hajda's avatar
      media: v4l2: added missing mutex.h include to v4l2-ctrls.h · 28f9d084
      Andrzej Hajda authored
      commit a19dec6ea94c036af68c31930c1c92681f55af41 upstream.
      This patch fixes following error:
      include/media/v4l2-ctrls.h:193:15: error: field ‘_lock’ has incomplete type
      include/media/v4l2-ctrls.h: In function ‘v4l2_ctrl_lock’:
      include/media/v4l2-ctrls.h:570:2: error: implicit declaration of
      	function ‘mutex_lock’ [-Werror=implicit-function-declaration]
      include/media/v4l2-ctrls.h: In function ‘v4l2_ctrl_unlock’:
      include/media/v4l2-ctrls.h:579:2: error: implicit declaration of
      	function ‘mutex_unlock’ [-Werror=implicit-function-declaration]
      Signed-off-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasily Titskiy's avatar
      HID: usbhid: quirk for N-Trig DuoSense Touch Screen · 3fb63044
      Vasily Titskiy authored
      commit 9e0bf92c223dabe0789714f8f85f6e26f8f9cda4 upstream.
      The DuoSense touchscreen device causes a 10 second timeout. This fix
      removes the delay.
      Signed-off-by: default avatarVasily Titskiy <qehgt0@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Kees Cook's avatar
      HID: check for NULL field when setting values · 9d18e13e
      Kees Cook authored
      commit be67b68d52fa28b9b721c47bb42068f0c1214855 upstream.
      Defensively check that the field to be worked on is not NULL.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jiri Kosina's avatar
      HID: battery: don't do DMA from stack · 735b7d0c
      Jiri Kosina authored
      commit 6c2794a2984f4c17a58117a68703cc7640f01c5a upstream.
      Instead of using data from stack for DMA in hidinput_get_battery_property(),
      allocate the buffer dynamically.
      Reported-by: default avatarRichard Ryniker <ryniker@alum.mit.edu>
      Reported-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Kees Cook's avatar
      HID: ntrig: validate feature report details · 2dbe9ce6
      Kees Cook authored
      commit 875b4e3763dbc941f15143dd1a18d10bb0be303b upstream.
      A HID device could send a malicious feature report that would cause the
      ntrig HID driver to trigger a NULL dereference during initialization:
      [57383.031190] usb 3-1: New USB device found, idVendor=1b96, idProduct=0001
      [57383.315193] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
      [57383.315308] IP: [<ffffffffa08102de>] ntrig_probe+0x25e/0x420 [hid_ntrig]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarRafi Rubin <rafi@seas.upenn.edu>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Kees Cook's avatar
      HID: validate HID report id size · 676bb9a4
      Kees Cook authored
      commit 43622021d2e2b82ea03d883926605bdd0525e1d1 upstream.
      The "Report ID" field of a HID report is used to build indexes of
      reports. The kernel's index of these is limited to 256 entries, so any
      malicious device that sets a Report ID greater than 255 will trigger
      memory corruption on the host:
      [ 1347.156239] BUG: unable to handle kernel paging request at ffff88094958a878
      [ 1347.156261] IP: [<ffffffff813e4da0>] hid_register_report+0x2a/0x8b
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Stefan Kriwanek's avatar
      HID: Fix Speedlink VAD Cezanne support for some devices · 355c557b
      Stefan Kriwanek authored
      commit 06bb5219118fb098f4b0c7dcb484b28a52bf1c14 upstream.
      Some devices of the "Speedlink VAD Cezanne" model need more aggressive fixing
      than already done.
      I made sure through testing that this patch would not interfere with the proper
      working of a device that is bug-free. (The driver drops EV_REL events with
      abs(val) >= 256, which are not achievable even on the highest laser resolution
      hardware setting.)
      Signed-off-by: default avatarStefan Kriwanek <mail@stefankriwanek.de>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Kees Cook's avatar
      HID: pantherlord: validate output report details · f09344e3
      Kees Cook authored
      commit 412f30105ec6735224535791eed5cdc02888ecb4 upstream.
      A HID device could send a malicious output report that would cause the
      pantherlord HID driver to write beyond the output report allocation
      during initialization, causing a heap overflow:
      [  310.939483] usb 1-1: New USB device found, idVendor=0e8f, idProduct=0003
      [  315.980774] BUG kmalloc-192 (Tainted: G        W   ): Redzone overwritten
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Felix Fietkau's avatar
      ath9k: avoid accessing MRC registers on single-chain devices · 08c44ff3
      Felix Fietkau authored
      commit a1c781bb20ac1e03280e420abd47a99eb8bbdd3b upstream.
      They are not implemented, and accessing them might trigger errors
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Felix Fietkau's avatar
      ath9k: fix rx descriptor related race condition · 0f528a11
      Felix Fietkau authored
      commit e96542e55a2aacf4bdeccfe2f17b77c4895b4df2 upstream.
      Similar to a race condition that exists in the tx path, the hardware
      might re-read the 'next' pointer of a descriptor of the last completed
      frame. This only affects non-EDMA (pre-AR93xx) devices.
      To deal with this race, defer clearing and re-linking a completed rx
      descriptor until the next one has been processed.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Felix Fietkau's avatar
      ath9k: always clear ps filter bit on new assoc · ad9e765f
      Felix Fietkau authored
      commit 026d5b07c03458f9c0ccd19c3850564a5409c325 upstream.
      Otherwise in some cases, EAPOL frames might be filtered during the
      initial handshake, causing delays and assoc failures.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • John W. Linville's avatar
      brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error() · 1df8b646
      John W. Linville authored
      commit 67d0cf50bd32b66eab709871714e55725ee30ce4 upstream.
      The driver fails to check the results of DMA mapping in twp places,
      which results in the following warning:
      [   28.078515] ------------[ cut here ]------------
      [   28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930()
      [   28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver failed to check map error[device address=0x00000000b5d60d6c] [size=1876 bytes] [mapped as
      [   28.078536] Modules linked in: bnep bluetooth vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu rtl8192c_common rtlwifi mac802
      11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer snd_seq_device snd k8temp
       cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4 jbd2 mbcache crc1
      6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_amd
      [   28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted: G           O 3.10.0-rc7-wl+ #42
      [   28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook PC/30D6, BIOS F.27 11/27/2008
      [   28.078607]  0000000000000009 ffff8800bbb03ad8 ffffffff8144f898 ffff8800bbb03b18
      [   28.078612]  ffffffff8103e1eb 0000000000000002 ffff8800b719f480 ffff8800b7b9c010
      [   28.078617]  ffffffff824204c0 ffffffff81754d57 0000000000000754 ffff8800bbb03b78
      [   28.078622] Call Trace:
      [   28.078624]  <IRQ>  [<ffffffff8144f898>] dump_stack+0x19/0x1b
      [   28.078634]  [<ffffffff8103e1eb>] warn_slowpath_common+0x6b/0xa0
      [   28.078638]  [<ffffffff8103e2c1>] warn_slowpath_fmt+0x41/0x50
      [   28.078650]  [<ffffffff8122d7ae>] check_unmap+0x47e/0x930
      [   28.078655]  [<ffffffff8122de4c>] debug_dma_unmap_page+0x5c/0x70
      [   28.078679]  [<ffffffffa04a808c>] dma64_getnextrxp+0x10c/0x190 [brcmsmac]
      [   28.078691]  [<ffffffffa04a9042>] dma_rx+0x62/0x240 [brcmsmac]
      [   28.078707]  [<ffffffffa0479101>] brcms_c_dpc+0x211/0x9d0 [brcmsmac]
      [   28.078717]  [<ffffffffa046d927>] ? brcms_dpc+0x27/0xf0 [brcmsmac]
      [   28.078731]  [<ffffffffa046d947>] brcms_dpc+0x47/0xf0 [brcmsmac]
      [   28.078736]  [<ffffffff81047dcc>] tasklet_action+0x6c/0xf0
      [   28.078974]  [<ffffffff813891bd>] SyS_sendmsg+0xd/0x20
      [   28.078979]  [<ffffffff81455c24>] tracesys+0xdd/0xe2
      [   28.078982] ---[ end trace 6164d1a08148e9c8 ]---
      [   28.078984] Mapped at:
      [   28.078985]  [<ffffffff8122c8fd>] debug_dma_map_page+0x9d/0x150
      [   28.078989]  [<ffffffffa04a9322>] dma_rxfill+0x102/0x3d0 [brcmsmac]
      [   28.079001]  [<ffffffffa047a13d>] brcms_c_init+0x87d/0x1100 [brcmsmac]
      [   28.079010]  [<ffffffffa046d851>] brcms_init+0x21/0x30 [brcmsmac]
      [   28.079018]  [<ffffffffa04786e0>] brcms_c_up+0x150/0x430 [brcmsmac]
      As the patch adds a new failure mechanism to dma_rxfill(). When I changed the
      comment at the start of the routine to add that information, I also polished
      the wording.
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Brett Rudley <brudley@broadcom.com>
      Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
      Cc: Hante Meuleman <meuleman@broadcom.com>
      Cc: brcm80211-dev-list@broadcom.com
      Acked-by: default avatarArend van Spriel <arend@broadcom.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Takashi Iwai's avatar
      ALSA: hda - Add Toshiba Satellite C870 to MSI blacklist · bd925e29
      Takashi Iwai authored
      commit 83f72151352791836a1b9c1542614cc9bf71ac61 upstream.
      Toshiba Satellite C870 shows interrupt problems occasionally when
      certain mixer controls like "Mic Switch" is toggled.  This seems
      worked around by not using MSI.
      Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=833585
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Mike Dyer's avatar
      ASoC: wm8960: Fix PLL register writes · 64c2a179
      Mike Dyer authored
      commit 85fa532b6ef920b32598df86b194571a7059a77c upstream.
      Bit 9 of PLL2,3 and 4 is reserved as '0'. The 24bit fractional part
      should be split across each register in 8bit chunks.
      Signed-off-by: default avatarMike Dyer <mike.dyer@md-soft.co.uk>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Tejun Heo's avatar
      rculist: list_first_or_null_rcu() should use list_entry_rcu() · a7179b89
      Tejun Heo authored
      commit c34ac00caefbe49d40058ae7200bd58725cebb45 upstream.
      list_first_or_null() should test whether the list is empty and return
      pointer to the first entry if not in a RCU safe manner.  It's broken
      in several ways.
      * It compares __kernel @__ptr with __rcu @__next triggering the
        following sparse warning.
        net/core/dev.c:4331:17: error: incompatible types in comparison expression (different address spaces)
      * It doesn't perform rcu_dereference*() and computes the entry address
        using container_of() directly from the __rcu pointer which is
        inconsitent with other rculist interface.  As a result, all three
        in-kernel users - net/core/dev.c, macvlan, cgroup - are buggy.  They
        dereference the pointer w/o going through read barrier.
      * While ->next dereference passes through list_next_rcu(), the
        compiler is still free to fetch ->next more than once and thus
        nullify the "__ptr != __next" condition check.
      Fix it by making list_first_or_null_rcu() dereference ->next directly
      using ACCESS_ONCE() and then use list_entry_rcu() on it like other
      rculist accessors.
      v2: Paul pointed out that the compiler may fetch the pointer more than
          once nullifying the condition check.  ACCESS_ONCE() added on
          ->next dereference.
      v3: Restored () around macro param which was accidentally removed.
          Spotted by Paul.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Cc: Dipankar Sarma <dipankar@in.ibm.com>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Li Zefan <lizefan@huawei.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Reviewed-by: default avatarJosh Triplett <josh@joshtriplett.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Hans de Goede's avatar
      usb: config->desc.bLength may not exceed amount of data returned by the device · 38a08644
      Hans de Goede authored
      commit b4f17a488ae2e09bfcf95c0e0b4219c246f1116a upstream.
      While reading the config parsing code I noticed this check is missing, without
      this check config->desc.wTotalLength can end up with a value larger then the
      dev->rawdescriptors length for the config, and when userspace then tries to
      get the rawdescriptors bad things may happen.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Oliver Neukum's avatar
      USB: cdc-wdm: fix race between interrupt handler and tasklet · e200d6be
      Oliver Neukum authored
      commit 6dd433e6cf2475ce8abec1b467720858c24450eb upstream.
      Both could want to submit the same URB. Some checks of the flag
      intended to prevent that were missing.
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Daniel Mack's avatar
      usb: ehci-mxc: check for pdata before dereferencing · 0b25f929
      Daniel Mack authored
      commit f375fc520d4df0cd9fcb570f33c103c6c0311f9e upstream.
      Commit 7e8d5cd9
       ("USB: Add EHCI support for MX27 and MX31 based
      boards") introduced code that could potentially lead to a NULL pointer
      dereference on driver removal.
      Fix this by checking for the value of pdata before dereferencing it.
      Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Johan Hovold's avatar
      USB: mos7720: fix big-endian control requests · 23595cb6
      Johan Hovold authored
      commit 3b716caf190ccc6f2a09387210e0e6a26c1d81a4 upstream.
      Fix endianess bugs in parallel-port code which caused corrupt
      control-requests to be issued on big-endian machines.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarJohan Hovold <jhovold@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Dan Carpenter's avatar
      USB: mos7720: use GFP_ATOMIC under spinlock · 659158c5
      Dan Carpenter authored
      commit d0bd9a41186e076ea543c397ad8a67a6cf604b55 upstream.
      The write_parport_reg_nonblock() function shouldn't sleep because it's
      called with spinlocks held.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarJohan Hovold <jhovold@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Dan Carpenter's avatar
      staging: comedi: dt282x: dt282x_ai_insn_read() always fails · b9ba2a57
      Dan Carpenter authored
      commit 2c4283ca7cdcc6605859c836fc536fcd83a4525f upstream.
      In dt282x_ai_insn_read() we call this macro like:
      wait_for(!mux_busy(), comedi_error(dev, "timeout\n"); return -ETIME;);
      Because the if statement doesn't have curly braces it means we always
      return -ETIME and the function never succeeds.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jeff Layton's avatar
      cifs: ensure that srv_mutex is held when dealing with ssocket pointer · b11dc974
      Jeff Layton authored
      commit 73e216a8a42c0ef3d08071705c946c38fdbe12b0 upstream.
      Oleksii reported that he had seen an oops similar to this:
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
      IP: [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
      PGD 0
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in: ipt_MASQUERADE xt_REDIRECT xt_tcpudp iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables carl9170 ath usb_storage f2fs nfnetlink_log nfnetlink md4 cifs dns_resolver hid_generic usbhid hid af_packet uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev rfcomm btusb bnep bluetooth qmi_wwan qcserial cdc_wdm usb_wwan usbnet usbserial mii snd_hda_codec_hdmi snd_hda_codec_realtek iwldvm mac80211 coretemp intel_powerclamp kvm_intel kvm iwlwifi snd_hda_intel cfg80211 snd_hda_codec xhci_hcd e1000e ehci_pci snd_hwdep sdhci_pci snd_pcm ehci_hcd microcode psmouse sdhci thinkpad_acpi mmc_core i2c_i801 pcspkr usbcore hwmon snd_timer snd_page_alloc snd ptp rfkill pps_core soundcore evdev usb_common vboxnetflt(O) vboxdrv(O)Oops#2 Part8
       loop tun binfmt_misc fuse msr acpi_call(O) ipv6 autofs4
      CPU: 0 PID: 21612 Comm: kworker/0:1 Tainted: G        W  O 3.10.1SIGN #28
      Hardware name: LENOVO 2306CTO/2306CTO, BIOS G2ET92WW (2.52 ) 02/22/2013
      Workqueue: cifsiod cifs_echo_request [cifs]
      task: ffff8801e1f416f0 ti: ffff880148744000 task.ti: ffff880148744000
      RIP: 0010:[<ffffffff814dcc13>]  [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
      RSP: 0000:ffff880148745b00  EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffff880148745b78 RCX: 0000000000000048
      RDX: ffff880148745c90 RSI: ffff880181864a00 RDI: ffff880148745b78
      RBP: ffff880148745c48 R08: 0000000000000048 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff880181864a00
      R13: ffff880148745c90 R14: 0000000000000048 R15: 0000000000000048
      FS:  0000000000000000(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000088 CR3: 000000020c42c000 CR4: 00000000001407b0
      Oops#2 Part7
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
       ffff880148745b30 ffffffff810c4af9 0000004848745b30 ffff880181864a00
       ffffffff81ffbc40 0000000000000000 ffff880148745c90 ffffffff810a5aab
       ffff880148745bc0 ffffffff81ffbc40 ffff880148745b60 ffffffff815a9fb8
      Call Trace:
       [<ffffffff810c4af9>] ? finish_task_switch+0x49/0xe0
       [<ffffffff810a5aab>] ? lock_timer_base.isra.36+0x2b/0x50
       [<ffffffff815a9fb8>] ? _raw_spin_unlock_irqrestore+0x18/0x40
       [<ffffffff810a673f>] ? try_to_del_timer_sync+0x4f/0x70
       [<ffffffff815aa38f>] ? _raw_spin_unlock_bh+0x1f/0x30
       [<ffffffff814dcc87>] kernel_sendmsg+0x37/0x50
       [<ffffffffa081a0e0>] smb_send_kvec+0xd0/0x1d0 [cifs]
       [<ffffffffa081a263>] smb_send_rqst+0x83/0x1f0 [cifs]
       [<ffffffffa081ab6c>] cifs_call_async+0xec/0x1b0 [cifs]
       [<ffffffffa08245e0>] ? free_rsp_buf+0x40/0x40 [cifs]
      Oops#2 Part6
       [<ffffffffa082606e>] SMB2_echo+0x8e/0xb0 [cifs]
       [<ffffffffa0808789>] cifs_echo_request+0x79/0xa0 [cifs]
       [<ffffffff810b45b3>] process_one_work+0x173/0x4a0
       [<ffffffff810b52a1>] worker_thread+0x121/0x3a0
       [<ffffffff810b5180>] ? manage_workers.isra.27+0x2b0/0x2b0
       [<ffffffff810bae00>] kthread+0xc0/0xd0
       [<ffffffff810bad40>] ? kthread_create_on_node+0x120/0x120
       [<ffffffff815b199c>] ret_from_fork+0x7c/0xb0
       [<ffffffff810bad40>] ? kthread_create_on_node+0x120/0x120
      Code: 84 24 b8 00 00 00 4c 89 f1 4c 89 ea 4c 89 e6 48 89 df 4c 89 60 18 48 c7 40 28 00 00 00 00 4c 89 68 30 44 89 70 14 49 8b 44 24 28 <ff> 90 88 00 00 00 3d ef fd ff ff 74 10 48 8d 65 e0 5b 41 5c 41
       RIP  [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
       RSP <ffff880148745b00>
      CR2: 0000000000000088
      The client was in the middle of trying to send a frame when the
      server->ssocket pointer got zeroed out. In most places, that we access
      that pointer, the srv_mutex is held. There's only one spot that I see
      that the server->ssocket pointer gets set and the srv_mutex isn't held.
      This patch corrects that.
      The upstream bug report was here:
      Reported-by: default avatarOleksii Shevchuk <alxchk@gmail.com>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>