1. 24 Aug, 2013 2 commits
  2. 23 Aug, 2013 14 commits
  3. 22 Aug, 2013 17 commits
    • David S. Miller's avatar
      Merge branch 'sfc-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc · 2266c68f
      David S. Miller authored
      Merge in a fix for RX MAC address filter programming bug in the sfc
      driver.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2266c68f
    • Johannes Berg's avatar
      Revert "genetlink: fix family dump race" · 9d47b380
      Johannes Berg authored
      This reverts commit 58ad436f.
      
      It turns out that the change introduced a potential deadlock
      by causing a locking dependency with netlink's cb_mutex. I
      can't seem to find a way to resolve this without doing major
      changes to the locking, so revert this.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Acked-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d47b380
    • Linus Torvalds's avatar
      Merge branch 'linux-next' of git://cavan.codon.org.uk/platform-drivers-x86 · 6a7492a4
      Linus Torvalds authored
      Pull x86 platform driver fixes from Matthew Garrett:
       "Three trivial fixes - the first reverts a patch that's broken some
        other devices (again - I'm trying to figure out a clean way to
        implement this), the other two fix minor issues in the sony-laptop
        driver"
      
      * 'linux-next' of git://cavan.codon.org.uk/platform-drivers-x86:
        Revert "hp-wmi: Enable hotkeys on some systems"
        sony-laptop: Fix reporting of gfx_switch_status
        sony-laptop: return a negative error code in sonypi_compat_init()
      6a7492a4
    • Linus Torvalds's avatar
      Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 1f8b7665
      Linus Torvalds authored
      Pull ARM SoC fixes from Olof Johansson:
       "A handful of fixes for 3.11 are still trickling in.  These are:
         - A couple of fixes for older OMAP platforms
         - Another few fixes for at91 (lateish due to European summer
           vacations)
         - A late-found problem with USB on Tegra, fix is to keep VBUS
           regulator on at all times
         - One fix for Exynos 5440 dealing with CPU detection
         - One MAINTAINERS update"
      
      * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        ARM: tegra: always enable USB VBUS regulators
        ARM: davinci: nand: specify ecc strength
        ARM: OMAP: rx51: change musb mode to OTG
        ARM: OMAP2: fix musb usage for n8x0
        MAINTAINERS: Update email address for Benoit Cousson
        ARM: at91/DT: fix at91sam9n12ek memory node
        ARM: at91: add missing uart clocks DT entries
        ARM: SAMSUNG: fix to support for missing cpu specific map_io
        ARM: at91/DT: at91sam9x5ek: fix USB host property to enable port C
      1f8b7665
    • Linus Torvalds's avatar
      Merge tag 'devicetree-fixes-for-3.11' of git://sources.calxeda.com/kernel/linux · 8351fcfe
      Linus Torvalds authored
      Pull device tree fix from Rob Herring:
       "For DT unflattening, add missing memory initialization.
      
        This is needed for arches like PPC that use memblock_alloc.  This
        appears to have been an issue for some time, but is a somewhat limited
        usecase of OF_DYNAMIC"
      
      * tag 'devicetree-fixes-for-3.11' of git://sources.calxeda.com/kernel/linux:
        of: fdt: fix memory initialization for expanded DT
      8351fcfe
    • Linus Torvalds's avatar
      Merge tag 'dm-3.11-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm · ee7075d4
      Linus Torvalds authored
      Pull device mapper fix from Mike Snitzer:
       "A patch to fix dm-cache-policy-mq's remove_mapping() conflict with
        sparc32"
      
      * tag 'dm-3.11-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
        dm cache: avoid conflicting remove_mapping() in mq policy
      ee7075d4
    • Radu Caragea's avatar
      x86 get_unmapped_area: Access mmap_legacy_base through mm_struct member · 41aacc1e
      Radu Caragea authored
      This is the updated version of df54d6fa ("x86 get_unmapped_area():
      use proper mmap base for bottom-up direction") that only randomizes the
      mmap base address once.
      Signed-off-by: default avatarRadu Caragea <sinaelgl@gmail.com>
      Reported-and-tested-by: default avatarJeff Shorey <shoreyjeff@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Michel Lespinasse <walken@google.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Adrian Sendroiu <molecula2788@gmail.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: Kamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      41aacc1e
    • Linus Torvalds's avatar
      Revert "x86 get_unmapped_area(): use proper mmap base for bottom-up direction" · 5ea80f76
      Linus Torvalds authored
      This reverts commit df54d6fa.
      
      The commit isn't necessarily wrong, but because it recalculates the
      random mmap_base every time, it seems to confuse user memory allocators
      that expect contiguous mmap allocations even when the mmap address isn't
      specified.
      
      In particular, the MATLAB Java runtime seems to be unhappy. See
      
        https://bugzilla.kernel.org/show_bug.cgi?id=60774
      
      So we'll want to apply the random offset only once, and Radu has a patch
      for that.  Revert this older commit in order to apply the other one.
      Reported-by: default avatarJeff Shorey <shoreyjeff@gmail.com>
      Cc: Radu Caragea <sinaelgl@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5ea80f76
    • Martin Peschke's avatar
      [SCSI] zfcp: remove access control tables interface (keep sysfs files) · b5dc3c48
      Martin Peschke authored
      By popular demand, this patch brings back a couple of sysfs attributes
      removed by commit 663e0890
      "[SCSI] zfcp: remove access control tables interface".
      The content has been irrelevant for years, but the files must be
      there forever for whatever user space tools that may rely on them.
      
      Since these files always return a constant value, a new stripped
      down show-macro was required. Otherwise build warnings would have
      been introduced.
      Signed-off-by: default avatarMartin Peschke <mpeschke@linux.vnet.ibm.com>
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      b5dc3c48
    • Martin Peschke's avatar
      [SCSI] zfcp: fix schedule-inside-lock in scsi_device list loops · 924dd584
      Martin Peschke authored
      BUG: sleeping function called from invalid context at kernel/workqueue.c:2752
      in_atomic(): 1, irqs_disabled(): 1, pid: 360, name: zfcperp0.0.1700
      CPU: 1 Not tainted 3.9.3+ #69
      Process zfcperp0.0.1700 (pid: 360, task: 0000000075b7e080, ksp: 000000007476bc30)
      <snip>
      Call Trace:
      ([<00000000001165de>] show_trace+0x106/0x154)
       [<00000000001166a0>] show_stack+0x74/0xf4
       [<00000000006ff646>] dump_stack+0xc6/0xd4
       [<000000000017f3a0>] __might_sleep+0x128/0x148
       [<000000000015ece8>] flush_work+0x54/0x1f8
       [<00000000001630de>] __cancel_work_timer+0xc6/0x128
       [<00000000005067ac>] scsi_device_dev_release_usercontext+0x164/0x23c
       [<0000000000161816>] execute_in_process_context+0x96/0xa8
       [<00000000004d33d8>] device_release+0x60/0xc0
       [<000000000048af48>] kobject_release+0xa8/0x1c4
       [<00000000004f4bf2>] __scsi_iterate_devices+0xfa/0x130
       [<000003ff801b307a>] zfcp_erp_strategy+0x4da/0x1014 [zfcp]
       [<000003ff801b3caa>] zfcp_erp_thread+0xf6/0x2b0 [zfcp]
       [<000000000016b75a>] kthread+0xf2/0xfc
       [<000000000070c9de>] kernel_thread_starter+0x6/0xc
       [<000000000070c9d8>] kernel_thread_starter+0x0/0xc
      
      Apparently, the ref_count for some scsi_device drops down to zero,
      triggering device removal through execute_in_process_context(), while
      the lldd error recovery thread iterates through a scsi device list.
      Unfortunately, execute_in_process_context() decides to immediately
      execute that device removal function, instead of scheduling asynchronous
      execution, since it detects process context and thinks it is safe to do
      so. But almost all calls to shost_for_each_device() in our lldd are
      inside spin_lock_irq, even in thread context. Obviously, schedule()
      inside spin_lock_irq sections is a bad idea.
      
      Change the lldd to use the proper iterator function,
      __shost_for_each_device(), in combination with required locking.
      
      Occurences that need to be changed include all calls in zfcp_erp.c,
      since those might be executed in zfcp error recovery thread context
      with a lock held.
      
      Other occurences of shost_for_each_device() in zfcp_fsf.c do not
      need to be changed (no process context, no surrounding locking).
      
      The problem was introduced in Linux 2.6.37 by commit
      b62a8d9b
      "[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit".
      Reported-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarMartin Peschke <mpeschke@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org #2.6.37+
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      924dd584
    • Martin Peschke's avatar
      [SCSI] zfcp: fix lock imbalance by reworking request queue locking · d79ff142
      Martin Peschke authored
      This patch adds wait_event_interruptible_lock_irq_timeout(), which is a
      straight-forward descendant of wait_event_interruptible_timeout() and
      wait_event_interruptible_lock_irq().
      
      The zfcp driver used to call wait_event_interruptible_timeout()
      in combination with some intricate and error-prone locking. Using
      wait_event_interruptible_lock_irq_timeout() as a replacement
      nicely cleans up that locking.
      
      This rework removes a situation that resulted in a locking imbalance
      in zfcp_qdio_sbal_get():
      
      BUG: workqueue leaked lock or atomic: events/1/0xffffff00/10
          last function: zfcp_fc_wka_port_offline+0x0/0xa0 [zfcp]
      
      It was introduced by commit c2af7545
      "[SCSI] zfcp: Do not wait for SBALs on stopped queue", which had a new
      code path related to ZFCP_STATUS_ADAPTER_QDIOUP that took an early exit
      without a required lock being held. The problem occured when a
      special, non-SCSI I/O request was being submitted in process context,
      when the adapter's queues had been torn down. In this case the bug
      surfaced when the Fibre Channel port connection for a well-known address
      was closed during a concurrent adapter shut-down procedure, which is a
      rare constellation.
      
      This patch also fixes these warnings from the sparse tool (make C=1):
      
      drivers/s390/scsi/zfcp_qdio.c:224:12: warning: context imbalance in
       'zfcp_qdio_sbal_check' - wrong count at exit
      drivers/s390/scsi/zfcp_qdio.c:244:5: warning: context imbalance in
       'zfcp_qdio_sbal_get' - unexpected unlock
      
      Last but not least, we get rid of that crappy lock-unlock-lock
      sequence at the beginning of the critical section.
      
      It is okay to call zfcp_erp_adapter_reopen() with req_q_lock held.
      Reported-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Reported-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Peschke <mpeschke@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org #2.6.35+
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      d79ff142
    • Stephen Warren's avatar
      ARM: tegra: always enable USB VBUS regulators · 30ca2226
      Stephen Warren authored
      This fixes a regression exposed during the merge window by commit
      9f310ded "ARM: tegra: fix VBUS regulator GPIO polarity in DT"; namely that
      USB VBUS doesn't get turned on, so USB devices are not detected. This
      affects the internal USB port on TrimSlice (i.e. the USB->SATA bridge, to
      which the SSD is connected) and the external port(s) on Seaboard/
      Springbank and Whistler.
      
      The Tegra DT as written in v3.11 allows two paths to enable USB VBUS:
      
      1) Via the legacy DT binding for the USB controller; it can directly
         acquire a VBUS GPIO and activate it.
      
      2) Via a regulator for VBUS, which is referenced by the new DT binding
         for the USB controller.
      
      Those two methods both use the same GPIO, and hence whichever of the
      USB controller and regulator gets probed first ends up owning the GPIO.
      In practice, the USB driver only supports path (1) above, since the
      patches to support the new USB binding are not present until v3.12:-(
      
      In practice, the regulator ends up being probed first and owning the
      GPIO. Since nothing enables the regulator (the USB driver code is not
      yet present), the regulator ends up being turned off. This originally
      caused no problem, because the polarity in the regulator definition was
      incorrect, so attempting to turn off the regulator actually turned it
      on, and everything worked:-(
      
      However, when testing the new USB driver code in v3.12, I noticed the
      incorrect polarity and fixed it in commit 9f310ded "ARM: tegra: fix VBUS
      regulator GPIO polarity in DT". In the context of v3.11, this patch then
      caused the USB VBUS to actually turn off, which broke USB ports with VBUS
      control. I got this patch included in v3.11-rc1 since it fixed a bug in
      device tree (incorrect polarity specification), and hence was suitable to
      be included early in the rc series. I evidently did not test the patch at
      all, or correctly, in the context of v3.11, and hence did not notice the
      issue that I have explained above:-(
      
      Fix this by making the USB VBUS regulators always enabled. This way, if
      the regulator owns the GPIO, it will always be turned on, even if there
      is no USB driver code to request the regulator be turned on. Even
      ignoring this bug, this is a reasonable way to configure the HW anyway.
      
      If this patch is applied to v3.11, it will cause a couple pretty trivial
      conflicts in tegra20-{trimslice,seaboard}.dts when creating v3.12, since
      the context right above the added lines changed in patches destined for
      v3.12.
      Reported-by: default avatarKyle McMartin <kmcmarti@redhat.com>
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      30ca2226
    • Daniel Gimpelevich's avatar
      hso: Fix stack corruption on some architectures · e75dc677
      Daniel Gimpelevich authored
      As Sergei Shtylyov explained in the #mipslinux IRC channel:
      [Mon 2013-08-19 12:28:21 PM PDT] <headless> guys, are you sure it's not "DMA off stack" case?
      [Mon 2013-08-19 12:28:35 PM PDT] <headless> it's a known stack corruptor on non-coherent arches
      [Mon 2013-08-19 12:31:48 PM PDT] <DonkeyHotei> headless: for usb/ehci?
      [Mon 2013-08-19 12:34:11 PM PDT] <DonkeyHotei> headless: explain
      [Mon 2013-08-19 12:35:38 PM PDT] <headless> usb_control_msg() (or other such func) should not use buffer on stack. DMA from/to stack is prohibited
      [Mon 2013-08-19 12:35:58 PM PDT] <headless> and EHCI uses DMA on control xfers (as well as all the others)
      Signed-off-by: default avatarDaniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e75dc677
    • Daniel Gimpelevich's avatar
      hso: Earlier catch of error condition · 35e57e1b
      Daniel Gimpelevich authored
      There is no need to get an interface specification if we know it's the
      wrong one.
      Signed-off-by: default avatarDaniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      35e57e1b
    • Wladislav Wiebe's avatar
      of: fdt: fix memory initialization for expanded DT · 9e401275
      Wladislav Wiebe authored
      Already existing property flags are filled wrong for properties created from
      initial FDT. This could cause problems if this DYNAMIC device-tree functions
      are used later, i.e. properties are attached/detached/replaced. Simply dumping
      flags from the running system show, that some initial static (not allocated via
      kzmalloc()) nodes are marked as dynamic.
      
      I putted some debug extensions to property_proc_show(..) :
      ..
      +       if (OF_IS_DYNAMIC(pp))
      +               pr_err("DEBUG: xxx : OF_IS_DYNAMIC\n");
      +       if (OF_IS_DETACHED(pp))
      +               pr_err("DEBUG: xxx : OF_IS_DETACHED\n");
      
      when you operate on the nodes (e.g.: ~$ cat /proc/device-tree/*some_node*) you
      will see that those flags are filled wrong, basically in most cases it will dump
      a DYNAMIC or DETACHED status, which is in not true.
      (BTW. this OF_IS_DETACHED is a own define for debug purposes which which just
      make a test_bit(OF_DETACHED, &x->_flags)
      
      If nodes are dynamic kernel is allowed to kfree() them. But it will crash
      attempting to do so on the nodes from FDT -- they are not allocated via
      kzmalloc().
      Signed-off-by: default avatarWladislav Wiebe <wladislav.kw@gmail.com>
      Acked-by: default avatarAlexander Sverdlin <alexander.sverdlin@nsn.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRob Herring <rob.herring@calxeda.com>
      9e401275
    • Guillaume Clement's avatar
      gma500: Fix SDVO turning off randomly · 6f1e1204
      Guillaume Clement authored
      Some Poulsbo cards seem to incorrectly report SDVO_CMD_STATUS_TARGET_NOT_SPECIFIED instead of SDVO_CMD_STATUS_PENDING, which causes the display to be turned off.
      Signed-off-by: default avatarGuillaume Clement <gclement@baobob.org>
      Acked-by: default avatarPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      6f1e1204
    • Dave Airlie's avatar
      Merge branch 'drm-nouveau-next' of... · 317b07b5
      Dave Airlie authored
      Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
      
      regression fixes and null derefs and oops fixes.
      
      * 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
        drm/nv04/disp: fix framebuffer pin refcounting
        drm/nouveau/mc: fix race condition between constructor and request_irq()
        drm/nouveau: fix reclocking on nv40
        drm/nouveau/ltcg: fix allocating memory as free
        drm/nouveau/ltcg: fix ltcg memory initialization after suspend
        drm/nouveau/fb: fix null derefs in nv49 and nv4e init
      317b07b5
  4. 21 Aug, 2013 7 commits
    • Linus Torvalds's avatar
      Merge tag 'stable/for-linus-3.11-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip · d936d2d4
      Linus Torvalds authored
      Pull Xen bug-fixes from Konrad Rzeszutek Wilk:
       - On ARM did not have balanced calls to get/put_cpu.
       - Fix to make tboot + Xen + Linux correctly.
       - Fix events VCPU binding issues.
       - Fix a vCPU online race where IPIs are sent to not-yet-online vCPU.
      
      * tag 'stable/for-linus-3.11-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
        xen/smp: initialize IPI vectors before marking CPU online
        xen/events: mask events when changing their VCPU binding
        xen/events: initialize local per-cpu mask for all possible events
        x86/xen: do not identity map UNUSABLE regions in the machine E820
        xen/arm: missing put_cpu in xen_percpu_init
      d936d2d4
    • Linus Torvalds's avatar
      Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus · 0903391a
      Linus Torvalds authored
      Pull MIPS fix from Ralf Baechle:
       "Just a single patch which fixes a special case in the MIPS FPU
        emulator which is always required, even on CPUs with FPU.  There is
        the rare special case that an FPU (or certain other instructions) in a
        branch delay slot is causing an exception and then the branch
        instruction will need to be emulated by the kernel before resuming
        execution.  This is working great except if the branch instruction is
        an Octeon BBIT instruction.
      
        The boring disclaimer - all MIPS defconfigs build tested and no
        regressions and runtime tested on Octeon, no known issues"
      
      * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
        MIPS: Handle OCTEON BBIT instructions in FPU emulator.
      0903391a
    • Linus Torvalds's avatar
      Merge tag 'arm64-stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 · 7d06bafc
      Linus Torvalds authored
      Pull arm64 perf fixes from Catalin Marinas:
       "Perf backend fixes for arm64 where the user can cause kernel panic
        (discovered with Vince's fuzzing tool)"
      
      * tag 'arm64-stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64:
        arm64: perf: fix event validation for software group leaders
        arm64: perf: fix array out of bounds access in armpmu_map_hw_event()
      7d06bafc
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 69bbe136
      Linus Torvalds authored
      Pull kvm fixes from Paolo Bonzini:
       "Fixes for ARM and aarch64.
      
        This pull request is coming a bit later than I would have preferred,
        because I and Gleb happened to have holidays around the same weeks of
        August...  sorry about that"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        KVM: ARM: Squash len warning
        arm64: KVM: use 'int' instead of 'u32' for variable 'target' in kvm_host.h.
        arm64: KVM: add missing dsb before invalidating Stage-2 TLBs
        arm64: KVM: perform save/restore of PAR_EL1
        arm64: KVM: fix 2-level page tables unmapping
        ARM: KVM: Fix unaligned unmap_range leak
        ARM: KVM: Fix 64-bit coprocessor handling
      69bbe136
    • Linus Torvalds's avatar
      Merge tag 'pinctrl-for-v3.11-3' of... · da2ad2a2
      Linus Torvalds authored
      Merge tag 'pinctrl-for-v3.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
      
      Pull pinctrl fixes from Linus Walleij:
       "Fixes for the sunxi (AllWinner) pin control driver.  This was a new
        driver in this merge window, so some post-merge hardening is
        happening"
      
      [ I had completely missed this pull request for some reason, it was sent
        over a week ago but my mailbox is chaotic ]
      
      * tag 'pinctrl-for-v3.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
        pinctrl: sunxi: Add spinlocks
        pinctrl: sunxi: Fix gpio_set behaviour
        pinctrl: sunxi: Read register before writing to it in irq_set_type
      da2ad2a2
    • Roland Dreier's avatar
      [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal · 35dc2483
      Roland Dreier authored
      There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances
      leads to one process writing data into the address space of some other
      random unrelated process if the ioctl is interrupted by a signal.
      What happens is the following:
      
       - A process issues an SG_IO ioctl with direction DXFER_FROM_DEV (ie the
         underlying SCSI command will transfer data from the SCSI device to
         the buffer provided in the ioctl)
      
       - Before the command finishes, a signal is sent to the process waiting
         in the ioctl.  This will end up waking up the sg_ioctl() code:
      
      		result = wait_event_interruptible(sfp->read_wait,
      			(srp_done(sfp, srp) || sdp->detached));
      
         but neither srp_done() nor sdp->detached is true, so we end up just
         setting srp->orphan and returning to userspace:
      
      		srp->orphan = 1;
      		write_unlock_irq(&sfp->rq_list_lock);
      		return result;	/* -ERESTARTSYS because signal hit process */
      
         At this point the original process is done with the ioctl and
         blithely goes ahead handling the signal, reissuing the ioctl, etc.
      
       - Eventually, the SCSI command issued by the first ioctl finishes and
         ends up in sg_rq_end_io().  At the end of that function, we run through:
      
      	write_lock_irqsave(&sfp->rq_list_lock, iflags);
      	if (unlikely(srp->orphan)) {
      		if (sfp->keep_orphan)
      			srp->sg_io_owned = 0;
      		else
      			done = 0;
      	}
      	srp->done = done;
      	write_unlock_irqrestore(&sfp->rq_list_lock, iflags);
      
      	if (likely(done)) {
      		/* Now wake up any sg_read() that is waiting for this
      		 * packet.
      		 */
      		wake_up_interruptible(&sfp->read_wait);
      		kill_fasync(&sfp->async_qp, SIGPOLL, POLL_IN);
      		kref_put(&sfp->f_ref, sg_remove_sfp);
      	} else {
      		INIT_WORK(&srp->ew.work, sg_rq_end_io_usercontext);
      		schedule_work(&srp->ew.work);
      	}
      
         Since srp->orphan *is* set, we set done to 0 (assuming the
         userspace app has not set keep_orphan via an SG_SET_KEEP_ORPHAN
         ioctl), and therefore we end up scheduling sg_rq_end_io_usercontext()
         to run in a workqueue.
      
       - In workqueue context we go through sg_rq_end_io_usercontext() ->
         sg_finish_rem_req() -> blk_rq_unmap_user() -> ... ->
         bio_uncopy_user() -> __bio_copy_iov() -> copy_to_user().
      
         The key point here is that we are doing copy_to_user() on a
         workqueue -- that is, we're on a kernel thread with current->mm
         equal to whatever random previous user process was scheduled before
         this kernel thread.  So we end up copying whatever data the SCSI
         command returned to the virtual address of the buffer passed into
         the original ioctl, but it's quite likely we do this copying into a
         different address space!
      
      As suggested by James Bottomley <James.Bottomley@hansenpartnership.com>,
      add a check for current->mm (which is NULL if we're on a kernel thread
      without a real userspace address space) in bio_uncopy_user(), and skip
      the copy if we're on a kernel thread.
      
      There's no reason that I can think of for any caller of bio_uncopy_user()
      to want to do copying on a kernel thread with a random active userspace
      address space.
      
      Huge thanks to Costa Sapuntzakis <costa@purestorage.com> for the
      original pointer to this bug in the sg code.
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
      Tested-by: default avatarDavid Milburn <dmilburn@redhat.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      35dc2483
    • Anton Blanchard's avatar
      [SCSI] lpfc: Don't force CONFIG_GENERIC_CSUM on · f5944daa
      Anton Blanchard authored
      We want ppc64 to be able to select between optimised assembly
      checksum routines in big endian and the generic lib/checksum.c
      routines in little endian.
      
      The lpfc driver is forcing CONFIG_GENERIC_CSUM on which means
      we are unable to make the decision to enable it in the arch
      Kconfig. If the option exists it is always forced on.
      
      This got introduced in 3.10 via commit 6a7252fd ([SCSI] lpfc:
      fix up Kconfig dependencies). I spoke to Randy about it and
      the original issue was with CRC_T10DIF not being defined.
      
      As such, remove the select of CONFIG_GENERIC_CSUM.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Cc: <stable@vger.kernel.org> # 3.10
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      f5944daa