1. 16 Mar, 2016 17 commits
    • Harvey Hunt's avatar
      libata: Align ata_device's id on a cacheline · dff6b608
      Harvey Hunt authored
      commit 4ee34ea3 upstream.
      
      The id buffer in ata_device is a DMA target, but it isn't explicitly
      cacheline aligned. Due to this, adjacent fields can be overwritten with
      stale data from memory on non coherent architectures. As a result, the
      kernel is sometimes unable to communicate with an ATA device.
      
      Fix this by ensuring that the id buffer is cacheline aligned.
      
      This issue is similar to that fixed by Commit 84bda12a
      ("libata: align ap->sector_buf").
      Signed-off-by: default avatarHarvey Hunt <harvey.hunt@imgtec.com>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      dff6b608
    • Jay Cornwall's avatar
      iommu/amd: Apply workaround for ATS write permission check · ee25dfd9
      Jay Cornwall authored
      commit 358875fd upstream.
      
      The AMD Family 15h Models 30h-3Fh (Kaveri) BIOS and Kernel Developer's
      Guide omitted part of the BIOS IOMMU L2 register setup specification.
      Without this setup the IOMMU L2 does not fully respect write permissions
      when handling an ATS translation request.
      
      The IOMMU L2 will set PTE dirty bit when handling an ATS translation with
      write permission request, even when PTE RW bit is clear. This may occur by
      direct translation (which would cause a PPR) or by prefetch request from
      the ATC.
      
      This is observed in practice when the IOMMU L2 modifies a PTE which maps a
      pagecache page. The ext4 filesystem driver BUGs when asked to writeback
      these (non-modified) pages.
      
      Enable ATS write permission check in the Kaveri IOMMU L2 if BIOS has not.
      Signed-off-by: default avatarJay Cornwall <jay@jcornwall.me>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ee25dfd9
    • Suravee Suthikulpanit's avatar
      iommu/amd: Fix boot warning when device 00:00.0 is not iommu covered · 40595089
      Suravee Suthikulpanit authored
      commit 38e45d02 upstream.
      
      The setup code for the performance counters in the AMD IOMMU driver
      tests whether the counters can be written. It tests to setup a counter
      for device 00:00.0, which fails on systems where this particular device
      is not covered by the IOMMU.
      
      Fix this by not relying on device 00:00.0 but only on the IOMMU being
      present.
      Signed-off-by: default avatarSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      40595089
    • David Woodhouse's avatar
      Fix directory hardlinks from deleted directories · 104b7dc8
      David Woodhouse authored
      commit be629c62 upstream.
      
      When a directory is deleted, we don't take too much care about killing off
      all the dirents that belong to it — on the basis that on remount, the scan
      will conclude that the directory is dead anyway.
      
      This doesn't work though, when the deleted directory contained a child
      directory which was moved *out*. In the early stages of the fs build
      we can then end up with an apparent hard link, with the child directory
      appearing both in its true location, and as a child of the original
      directory which are this stage of the mount process we don't *yet* know
      is defunct.
      
      To resolve this, take out the early special-casing of the "directories
      shall not have hard links" rule in jffs2_build_inode_pass1(), and let the
      normal nlink processing happen for directories as well as other inodes.
      
      Then later in the build process we can set ic->pino_nlink to the parent
      inode#, as is required for directories during normal operaton, instead
      of the nlink. And complain only *then* about hard links which are still
      in evidence even after killing off all the unreachable paths.
      Reported-by: default avatarLiu Song <liu.song11@zte.com.cn>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      104b7dc8
    • David Woodhouse's avatar
      jffs2: Fix page lock / f->sem deadlock · bc0be441
      David Woodhouse authored
      commit 49e91e70 upstream.
      
      With this fix, all code paths should now be obtaining the page lock before
      f->sem.
      Reported-by: default avatarSzabó Tamás <sztomi89@gmail.com>
      Tested-by: default avatarThomas Betker <thomas.betker@rohde-schwarz.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      bc0be441
    • Thomas Betker's avatar
      Revert "jffs2: Fix lock acquisition order bug in jffs2_write_begin" · 35b8c417
      Thomas Betker authored
      commit 157078f6 upstream.
      
      This reverts commit 5ffd3412
      ("jffs2: Fix lock acquisition order bug in jffs2_write_begin").
      
      The commit modified jffs2_write_begin() to remove a deadlock with
      jffs2_garbage_collect_live(), but this introduced new deadlocks found
      by multiple users. page_lock() actually has to be called before
      mutex_lock(&c->alloc_sem) or mutex_lock(&f->sem) because
      jffs2_write_end() and jffs2_readpage() are called with the page locked,
      and they acquire c->alloc_sem and f->sem, resp.
      
      In other words, the lock order in jffs2_write_begin() was correct, and
      it is the jffs2_garbage_collect_live() path that has to be changed.
      
      Revert the commit to get rid of the new deadlocks, and to clear the way
      for a better fix of the original deadlock.
      Reported-by: default avatarDeng Chao <deng.chao1@zte.com.cn>
      Reported-by: default avatarMing Liu <liu.ming50@gmail.com>
      Reported-by: default avatarwangzaiwei <wangzaiwei@top-vision.cn>
      Signed-off-by: default avatarThomas Betker <thomas.betker@rohde-schwarz.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      35b8c417
    • Peter Chen's avatar
      usb: chipidea: otg: change workqueue ci_otg as freezable · 3eab4cae
      Peter Chen authored
      commit d144dfea upstream.
      
      If we use USB ID pin as wakeup source, and there is a USB block
      device on this USB OTG (ID) cable, the system will be deadlock
      after system resume.
      
      The root cause for this problem is: the workqueue ci_otg may try
      to remove hcd before the driver resume has finished, and hcd will
      disconnect the device on it, then, it will call device_release_driver,
      and holds the device lock "dev->mutex", but it is never unlocked since
      it waits workqueue writeback to run to flush the block information, but
      the workqueue writeback is freezable, it is not thawed before driver
      resume has finished.
      
      When the driver (device: sd 0:0:0:0:) resume goes to dpm_complete, it
      tries to get its device lock "dev->mutex", but it can't get it forever,
      then the deadlock occurs. Below call stacks show the situation.
      
      So, in order to fix this problem, we need to change workqueue ci_otg
      as freezable, then the work item in this workqueue will be run after
      driver's resume, this workqueue will not be blocked forever like above
      case since the workqueue writeback has been thawed too.
      
      Tested at: i.mx6qdl-sabresd and i.mx6sx-sdb.
      
      [  555.178869] kworker/u2:13   D c07de74c     0   826      2 0x00000000
      [  555.185310] Workqueue: ci_otg ci_otg_work
      [  555.189353] Backtrace:
      [  555.191849] [<c07de4fc>] (__schedule) from [<c07dec6c>] (schedule+0x48/0xa0)
      [  555.198912]  r10:ee471ba0 r9:00000000 r8:00000000 r7:00000002 r6:ee470000 r5:ee471ba4
      [  555.206867]  r4:ee470000
      [  555.209453] [<c07dec24>] (schedule) from [<c07e2fc4>] (schedule_timeout+0x15c/0x1e0)
      [  555.217212]  r4:7fffffff r3:edc2b000
      [  555.220862] [<c07e2e68>] (schedule_timeout) from [<c07df6c8>] (wait_for_common+0x94/0x144)
      [  555.229140]  r8:00000000 r7:00000002 r6:ee470000 r5:ee471ba4 r4:7fffffff
      [  555.235980] [<c07df634>] (wait_for_common) from [<c07df790>] (wait_for_completion+0x18/0x1c)
      [  555.244430]  r10:00000001 r9:c0b5563c r8:c0042e48 r7:ef086000 r6:eea4372c r5:ef131b00
      [  555.252383]  r4:00000000
      [  555.254970] [<c07df778>] (wait_for_completion) from [<c0043cb8>] (flush_work+0x19c/0x234)
      [  555.263177] [<c0043b1c>] (flush_work) from [<c0043fac>] (flush_delayed_work+0x48/0x4c)
      [  555.271106]  r8:ed5b5000 r7:c0b38a3c r6:eea439cc r5:eea4372c r4:eea4372c
      [  555.277958] [<c0043f64>] (flush_delayed_work) from [<c00eae18>] (bdi_unregister+0x84/0xec)
      [  555.286236]  r4:eea43520 r3:20000153
      [  555.289885] [<c00ead94>] (bdi_unregister) from [<c02c2154>] (blk_cleanup_queue+0x180/0x29c)
      [  555.298250]  r5:eea43808 r4:eea43400
      [  555.301909] [<c02c1fd4>] (blk_cleanup_queue) from [<c0417914>] (__scsi_remove_device+0x48/0xb8)
      [  555.310623]  r7:00000000 r6:20000153 r5:ededa950 r4:ededa800
      [  555.316403] [<c04178cc>] (__scsi_remove_device) from [<c0415e90>] (scsi_forget_host+0x64/0x68)
      [  555.325028]  r5:ededa800 r4:ed5b5000
      [  555.328689] [<c0415e2c>] (scsi_forget_host) from [<c0409828>] (scsi_remove_host+0x78/0x104)
      [  555.337054]  r5:ed5b5068 r4:ed5b5000
      [  555.340709] [<c04097b0>] (scsi_remove_host) from [<c04cdfcc>] (usb_stor_disconnect+0x50/0xb4)
      [  555.349247]  r6:ed5b56e4 r5:ed5b5818 r4:ed5b5690 r3:00000008
      [  555.355025] [<c04cdf7c>] (usb_stor_disconnect) from [<c04b3bc8>] (usb_unbind_interface+0x78/0x25c)
      [  555.363997]  r8:c13919b4 r7:edd3c000 r6:edd3c020 r5:ee551c68 r4:ee551c00 r3:c04cdf7c
      [  555.371892] [<c04b3b50>] (usb_unbind_interface) from [<c03dc248>] (__device_release_driver+0x8c/0x118)
      [  555.381213]  r10:00000001 r9:edd90c00 r8:c13919b4 r7:ee551c68 r6:c0b546e0 r5:c0b5563c
      [  555.389167]  r4:edd3c020
      [  555.391752] [<c03dc1bc>] (__device_release_driver) from [<c03dc2fc>] (device_release_driver+0x28/0x34)
      [  555.401071]  r5:edd3c020 r4:edd3c054
      [  555.404721] [<c03dc2d4>] (device_release_driver) from [<c03db304>] (bus_remove_device+0xe0/0x110)
      [  555.413607]  r5:edd3c020 r4:ef17f04c
      [  555.417253] [<c03db224>] (bus_remove_device) from [<c03d8128>] (device_del+0x114/0x21c)
      [  555.425270]  r6:edd3c028 r5:edd3c020 r4:ee551c00 r3:00000000
      [  555.431045] [<c03d8014>] (device_del) from [<c04b1560>] (usb_disable_device+0xa4/0x1e8)
      [  555.439061]  r8:edd3c000 r7:eded8000 r6:00000000 r5:00000001 r4:ee551c00
      [  555.445906] [<c04b14bc>] (usb_disable_device) from [<c04a8e54>] (usb_disconnect+0x74/0x224)
      [  555.454271]  r9:edd90c00 r8:ee551000 r7:ee551c68 r6:ee551c9c r5:ee551c00 r4:00000001
      [  555.462156] [<c04a8de0>] (usb_disconnect) from [<c04a8fb8>] (usb_disconnect+0x1d8/0x224)
      [  555.470259]  r10:00000001 r9:edd90000 r8:ee471e2c r7:ee551468 r6:ee55149c r5:ee551400
      [  555.478213]  r4:00000001
      [  555.480797] [<c04a8de0>] (usb_disconnect) from [<c04ae5ec>] (usb_remove_hcd+0xa0/0x1ac)
      [  555.488813]  r10:00000001 r9:ee471eb0 r8:00000000 r7:ef3d9500 r6:eded810c r5:eded80b0
      [  555.496765]  r4:eded8000
      [  555.499351] [<c04ae54c>] (usb_remove_hcd) from [<c04d4158>] (host_stop+0x28/0x64)
      [  555.506847]  r6:eeb50010 r5:eded8000 r4:eeb51010
      [  555.511563] [<c04d4130>] (host_stop) from [<c04d09b8>] (ci_otg_work+0xc4/0x124)
      [  555.518885]  r6:00000001 r5:eeb50010 r4:eeb502a0 r3:c04d4130
      [  555.524665] [<c04d08f4>] (ci_otg_work) from [<c00454f0>] (process_one_work+0x194/0x420)
      [  555.532682]  r6:ef086000 r5:eeb502a0 r4:edc44480
      [  555.537393] [<c004535c>] (process_one_work) from [<c00457b0>] (worker_thread+0x34/0x514)
      [  555.545496]  r10:edc44480 r9:ef086000 r8:c0b1a100 r7:ef086034 r6:00000088 r5:edc44498
      [  555.553450]  r4:ef086000
      [  555.556032] [<c004577c>] (worker_thread) from [<c004bab4>] (kthread+0xdc/0xf8)
      [  555.563268]  r10:00000000 r9:00000000 r8:00000000 r7:c004577c r6:edc44480 r5:eddc15c0
      [  555.571221]  r4:00000000
      [  555.573804] [<c004b9d8>] (kthread) from [<c000fef0>] (ret_from_fork+0x14/0x24)
      [  555.581040]  r7:00000000 r6:00000000 r5:c004b9d8 r4:eddc15c0
      
      [  553.429383] sh              D c07de74c     0   694    691 0x00000000
      [  553.435801] Backtrace:
      [  553.438295] [<c07de4fc>] (__schedule) from [<c07dec6c>] (schedule+0x48/0xa0)
      [  553.445358]  r10:edd3c054 r9:edd3c078 r8:edddbd50 r7:edcbbc00 r6:c1377c34 r5:60000153
      [  553.453313]  r4:eddda000
      [  553.455896] [<c07dec24>] (schedule) from [<c07deff8>] (schedule_preempt_disabled+0x10/0x14)
      [  553.464261]  r4:edd3c058 r3:0000000a
      [  553.467910] [<c07defe8>] (schedule_preempt_disabled) from [<c07e0bbc>] (mutex_lock_nested+0x1a0/0x3e8)
      [  553.477254] [<c07e0a1c>] (mutex_lock_nested) from [<c03e927c>] (dpm_complete+0xc0/0x1b0)
      [  553.485358]  r10:00561408 r9:edd3c054 r8:c0b4863c r7:edddbd90 r6:c0b485d8 r5:edd3c020
      [  553.493313]  r4:edd3c0d0
      [  553.495896] [<c03e91bc>] (dpm_complete) from [<c03e9388>] (dpm_resume_end+0x1c/0x20)
      [  553.503652]  r9:00000000 r8:c0b1a9d0 r7:c1334ec0 r6:c1334edc r5:00000003 r4:00000010
      [  553.511544] [<c03e936c>] (dpm_resume_end) from [<c0079894>] (suspend_devices_and_enter+0x158/0x504)
      [  553.520604]  r4:00000000 r3:c1334efc
      [  553.524250] [<c007973c>] (suspend_devices_and_enter) from [<c0079e74>] (pm_suspend+0x234/0x2cc)
      [  553.532961]  r10:00561408 r9:ed6b7300 r8:00000004 r7:c1334eec r6:00000000 r5:c1334ee8
      [  553.540914]  r4:00000003
      [  553.543493] [<c0079c40>] (pm_suspend) from [<c0078a6c>] (state_store+0x6c/0xc0)
      
      [  555.703684] 7 locks held by kworker/u2:13/826:
      [  555.708140]  #0:  ("%s""ci_otg"){++++.+}, at: [<c0045484>] process_one_work+0x128/0x420
      [  555.716277]  #1:  ((&ci->work)){+.+.+.}, at: [<c0045484>] process_one_work+0x128/0x420
      [  555.724317]  #2:  (usb_bus_list_lock){+.+.+.}, at: [<c04ae5e4>] usb_remove_hcd+0x98/0x1ac
      [  555.732626]  #3:  (&dev->mutex){......}, at: [<c04a8e28>] usb_disconnect+0x48/0x224
      [  555.740403]  #4:  (&dev->mutex){......}, at: [<c04a8e28>] usb_disconnect+0x48/0x224
      [  555.748179]  #5:  (&dev->mutex){......}, at: [<c03dc2f4>] device_release_driver+0x20/0x34
      [  555.756487]  #6:  (&shost->scan_mutex){+.+.+.}, at: [<c04097d0>] scsi_remove_host+0x20/0x104
      
      Cc: Jun Li <jun.li@nxp.com>
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      3eab4cae
    • Felix Fietkau's avatar
      mac80211: minstrel_ht: set default tx aggregation timeout to 0 · 067988ee
      Felix Fietkau authored
      commit 7a36b930 upstream.
      
      The value 5000 was put here with the addition of the timeout field to
      ieee80211_start_tx_ba_session. It was originally added in mac80211 to
      save resources for drivers like iwlwifi, which only supports a limited
      number of concurrent aggregation sessions.
      
      Since iwlwifi does not use minstrel_ht and other drivers don't need
      this, 0 is a better default - especially since there have been
      recent reports of aggregation setup related issues reproduced with
      ath9k. This should improve stability without causing any adverse
      effects.
      Acked-by: default avatarAvery Pennarun <apenwarr@gmail.com>
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      067988ee
    • Alexandra Yates's avatar
      Adding Intel Lewisburg device IDs for SATA · da8228dc
      Alexandra Yates authored
      commit f5bdd66c upstream.
      
      This patch complements the list of device IDs previously
      added for lewisburg sata.
      Signed-off-by: default avatarAlexandra Yates <alexandra.yates@linux.intel.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      da8228dc
    • Alexandra Yates's avatar
      ahci: Order SATA device IDs for codename Lewisburg · 69dd6de7
      Alexandra Yates authored
      commit 4d92f009 upstream.
      
      This change was to preserve the ascending order of device IDs.
      There was an exception with the first two Lewisburg device IDs to
      keep all device IDs of the same kind grouped by code name.
      Signed-off-by: default avatarAlexandra Yates <alexandra.yates@linux.intel.com>
      signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      69dd6de7
    • Alexandra Yates's avatar
      ahci: add new Intel device IDs · 979e39e0
      Alexandra Yates authored
      commit 56e74338 upstream.
      
      Adding Intel codename Lewisburg platform device IDs for SATA.
      Signed-off-by: default avatarAlexandra Yates <alexandra.yates@linux.intel.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      979e39e0
    • Hans Verkuil's avatar
      [media] adv7604: fix tx 5v detect regression · b9095408
      Hans Verkuil authored
      commit 0ba4581c upstream.
      
      The 5 volt detect functionality broke in 3.14: the code reads IO register 0x70
      again after it has already been cleared. Instead it should use the cached
      irq_reg_0x70 value and the io_write to 0x71 to clear 0x70 can be dropped since
      this has already been done.
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b9095408
    • Liad Kaufman's avatar
      iwlwifi: mvm: inc pending frames counter also when txing non-sta · a30a4a91
      Liad Kaufman authored
      commit fb896c44 upstream.
      
      Until this patch, when TXing non-sta the pending_frames counter
      wasn't increased, but it WAS decreased in
      iwl_mvm_rx_tx_cmd_single(), what makes it negative in certain
      conditions. This in turn caused much trouble when we need to
      remove the station since we won't be waiting forever until
      pending_frames gets 0. In certain cases, we were exhausting
      the station table even in BSS mode, because we had a lot of
      stale stations.
      
      Increase the counter also in iwl_mvm_tx_skb_non_sta() after a
      successful TX to avoid this outcome.
      Signed-off-by: default avatarLiad Kaufman <liad.kaufman@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      [ kamal: backport to 4.2: file rename ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      a30a4a91
    • Arnd Bergmann's avatar
      libata: fix HDIO_GET_32BIT ioctl · 1291f671
      Arnd Bergmann authored
      commit 287e6611 upstream.
      
      As reported by Soohoon Lee, the HDIO_GET_32BIT ioctl does not
      work correctly in compat mode with libata.
      
      I have investigated the issue further and found multiple problems
      that all appeared with the same commit that originally introduced
      HDIO_GET_32BIT handling in libata back in linux-2.6.8 and presumably
      also linux-2.4, as the code uses "copy_to_user(arg, &val, 1)" to copy
      a 'long' variable containing either 0 or 1 to user space.
      
      The problems with this are:
      
      * On big-endian machines, this will always write a zero because it
        stores the wrong byte into user space.
      
      * In compat mode, the upper three bytes of the variable are updated
        by the compat_hdio_ioctl() function, but they now contain
        uninitialized stack data.
      
      * The hdparm tool calling this ioctl uses a 'static long' variable
        to store the result. This means at least the upper bytes are
        initialized to zero, but calling another ioctl like HDIO_GET_MULTCOUNT
        would fill them with data that remains stale when the low byte
        is overwritten. Fortunately libata doesn't implement any of the
        affected ioctl commands, so this would only happen when we query
        both an IDE and an ATA device in the same command such as
        "hdparm -N -c /dev/hda /dev/sda"
      
      * The libata code for unknown reasons started using ATA_IOC_GET_IO32
        and ATA_IOC_SET_IO32 as aliases for HDIO_GET_32BIT and HDIO_SET_32BIT,
        while the ioctl commands that were added later use the normal
        HDIO_* names. This is harmless but rather confusing.
      
      This addresses all four issues by changing the code to use put_user()
      on an 'unsigned long' variable in HDIO_GET_32BIT, like the IDE subsystem
      does, and by clarifying the names of the ioctl commands.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reported-by: default avatarSoohoon Lee <Soohoon.Lee@f5.com>
      Tested-by: default avatarSoohoon Lee <Soohoon.Lee@f5.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1291f671
    • Chris Bainbridge's avatar
      mac80211: fix use of uninitialised values in RX aggregation · bc9d3990
      Chris Bainbridge authored
      commit f39ea269 upstream.
      
      Use kzalloc instead of kmalloc for struct tid_ampdu_rx to
      initialize the "removed" field (all others are initialized
      manually). That fixes:
      
      UBSAN: Undefined behaviour in net/mac80211/rx.c:932:29
      load of value 2 is not a valid value for type '_Bool'
      CPU: 3 PID: 1134 Comm: kworker/u16:7 Not tainted 4.5.0-rc1+ #265
      Workqueue: phy0 rt2x00usb_work_rxdone
       0000000000000004 ffff880254a7ba50 ffffffff8181d866 0000000000000007
       ffff880254a7ba78 ffff880254a7ba68 ffffffff8188422d ffffffff8379b500
       ffff880254a7bab8 ffffffff81884747 0000000000000202 0000000348620032
      Call Trace:
       [<ffffffff8181d866>] dump_stack+0x45/0x5f
       [<ffffffff8188422d>] ubsan_epilogue+0xd/0x40
       [<ffffffff81884747>] __ubsan_handle_load_invalid_value+0x67/0x70
       [<ffffffff82227b4d>] ieee80211_sta_reorder_release.isra.16+0x5ed/0x730
       [<ffffffff8222ca14>] ieee80211_prepare_and_rx_handle+0xd04/0x1c00
       [<ffffffff8222db03>] __ieee80211_rx_handle_packet+0x1f3/0x750
       [<ffffffff8222e4a7>] ieee80211_rx_napi+0x447/0x990
      
      While at it, convert to use sizeof(*tid_agg_rx) instead.
      
      Fixes: 788211d8 ("mac80211: fix RX A-MPDU session reorder timer deletion")
      Signed-off-by: default avatarChris Bainbridge <chris.bainbridge@gmail.com>
      [reword commit message, use sizeof(*tid_agg_rx)]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      bc9d3990
    • Johannes Berg's avatar
      cfg80211/wext: fix message ordering · 12eaff63
      Johannes Berg authored
      commit cb150b9d upstream.
      
      Since cfg80211 frequently takes actions from its netdev notifier
      call, wireless extensions messages could still be ordered badly
      since the wext netdev notifier, since wext is built into the
      kernel, runs before the cfg80211 netdev notifier. For example,
      the following can happen:
      
      5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default
          link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
      5: wlan1: <BROADCAST,MULTICAST,UP>
          link/ether
      
      when setting the interface down causes the wext message.
      
      To also fix this, export the wireless_nlevent_flush() function
      and also call it from the cfg80211 notifier.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      12eaff63
    • Johannes Berg's avatar
      wext: fix message delay/ordering · 7c20cf58
      Johannes Berg authored
      commit 8bf86273 upstream.
      
      Beniamino reported that he was getting an RTM_NEWLINK message for a
      given interface, after the RTM_DELLINK for it. It turns out that the
      message is a wireless extensions message, which was sent because the
      interface had been connected and disconnection while it was deleted
      caused a wext message.
      
      For its netlink messages, wext uses RTM_NEWLINK, but the message is
      without all the regular rtnetlink attributes, so "ip monitor link"
      prints just rudimentary information:
      
      5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default
          link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
      Deleted 5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
          link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
      5: wlan1: <BROADCAST,MULTICAST,UP>
          link/ether
      (from my hwsim reproduction)
      
      This can cause userspace to get confused since it doesn't expect an
      RTM_NEWLINK message after RTM_DELLINK.
      
      The reason for this is that wext schedules a worker to send out the
      messages, and the scheduling delay can cause the messages to get out
      to userspace in different order.
      
      To fix this, have wext register a netdevice notifier and flush out
      any pending messages when netdevice state changes. This fixes any
      ordering whenever the original message wasn't sent by a notifier
      itself.
      Reported-by: default avatarBeniamino Galvani <bgalvani@redhat.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7c20cf58
  2. 15 Mar, 2016 2 commits
  3. 11 Mar, 2016 1 commit
  4. 09 Mar, 2016 20 commits