1. 27 Sep, 2013 5 commits
  2. 14 Sep, 2013 24 commits
  3. 08 Sep, 2013 11 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.4.61 · 58055a00
      Greg Kroah-Hartman authored
      58055a00
    • Roland Dreier's avatar
      SCSI: sg: Fix user memory corruption when SG_IO is interrupted by a signal · d3ba2187
      Roland Dreier authored
      commit 35dc2483 upstream.
      
      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>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      [lizf: backported to 3.4:
       - Use __bio_for_each_segment() instead of bio_for_each_segment_all()]
      Signed-off-by: default avatarLi Zefan <lizefan@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      d3ba2187
    • Nicholas Bellinger's avatar
      target: Fix trailing ASCII space usage in INQUIRY vendor+model · e51c435e
      Nicholas Bellinger authored
      commit ee60bddb upstream.
      
      This patch fixes spc_emulate_inquiry_std() to add trailing ASCII
      spaces for INQUIRY vendor + model fields following SPC-4 text:
      
        "ASCII data fields described as being left-aligned shall have any
         unused bytes at the end of the field (i.e., highest offset) and
         the unused bytes shall be filled with ASCII space characters (20h)."
      
      This addresses a problem with Falconstor NSS multipathing.
      Reported-by: default avatarTomas Molota <tomas.molota@lightstorm.sk>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e51c435e
    • Lan Tianyu's avatar
      ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT · 3f661fbf
      Lan Tianyu authored
      commit 524f42fa upstream.
      
      The ECDT of ASUSTEK L4R doesn't provide correct command and data
      I/O ports.  The DSDT provides the correct information instead.
      
      For this reason, add this machine to quirk list for ECDT validation
      and use the EC information from the DSDT.
      
      [rjw: Changelog]
      References: https://bugzilla.kernel.org/show_bug.cgi?id=60765Reported-and-tested-by: default avatarDaniele Esposti <expo@expobrain.net>
      Signed-off-by: default avatarLan Tianyu <tianyu.lan@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3f661fbf
    • Stanislaw Gruszka's avatar
      iwl4965: fix rfkill set state regression · 32cdf903
      Stanislaw Gruszka authored
      commit b2fcc0ae upstream.
      
      My current 3.11 fix:
      
      commit 788f7a56
      Author: Stanislaw Gruszka <sgruszka@redhat.com>
      Date:   Thu Aug 1 12:07:55 2013 +0200
      
          iwl4965: reset firmware after rfkill off
      
      broke rfkill notification to user-space . I missed that bug, because
      I compiled without CONFIG_RFKILL, sorry about that.
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      32cdf903
    • Helmut Schaa's avatar
      ath9k_htc: Restore skb headroom when returning skb to mac80211 · 837049ab
      Helmut Schaa authored
      commit d2e9fc14 upstream.
      
      ath9k_htc adds padding between the 802.11 header and the payload during
      TX by moving the header. When handing the frame back to mac80211 for TX
      status handling the header is not moved back into its original position.
      This can result in a too small skb headroom when entering ath9k_htc
      again (due to a soft retransmission for example) causing an
      skb_under_panic oops.
      
      Fix this by moving the 802.11 header back into its original position
      before returning the frame to mac80211 as other drivers like rt2x00
      or ath5k do.
      Reported-by: default avatarMarc Kleine-Budde <mkl@blackshift.org>
      Signed-off-by: default avatarHelmut Schaa <helmut.schaa@googlemail.com>
      Tested-by: default avatarMarc Kleine-Budde <mkl@blackshift.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@blackshift.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      837049ab
    • Trond Myklebust's avatar
      SUNRPC: Fix memory corruption issue on 32-bit highmem systems · 52b331e9
      Trond Myklebust authored
      commit 347e2233 upstream.
      
      Some architectures, such as ARM-32 do not return the same base address
      when you call kmap_atomic() twice on the same page.
      This causes problems for the memmove() call in the XDR helper routine
      "_shift_data_right_pages()", since it defeats the detection of
      overlapping memory ranges, and has been seen to corrupt memory.
      
      The fix is to distinguish between the case where we're doing an
      inter-page copy or not. In the former case of we know that the memory
      ranges cannot possibly overlap, so we can additionally micro-optimise
      by replacing memmove() with memcpy().
      Reported-by: default avatarMark Young <MYoung@nvidia.com>
      Reported-by: default avatarMatt Craighead <mcraighead@nvidia.com>
      Cc: Bruce Fields <bfields@fieldses.org>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Tested-by: default avatarMatt Craighead <mcraighead@nvidia.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      52b331e9
    • Imre Deak's avatar
      drm/i915: ivb: fix edp voltage swing reg val · 5817e3c7
      Imre Deak authored
      commit 77fa4cbd upstream.
      
      Fix the typo introduced in
      
      commit 1a2eb460
      Author: Keith Packard <keithp@keithp.com>
      Date:   Wed Nov 16 16:26:07 2011 -0800
      
          drm/i915: Hook up Ivybridge eDP
      
      This fixes eDP link-training failures and cases where all voltage swing
      /pre-emphasis levels were tried and failed during clock recovery and -
      as a fallback - we go on to do channel equalization with the last voltage
      swing/pre-emphasis level which will succeed. Both issues can lead to a
      blank screen.
      
      v2:
      - improve commit message
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64880Tested-by: default avatarJeremy Moles <cubicool@gmail.com>
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5817e3c7
    • Jakob Bornecrantz's avatar
      drm/vmwgfx: Split GMR2_REMAP commands if they are to large · 73bc40b8
      Jakob Bornecrantz authored
      commit 6e4dcff3 upstream.
      
      This fixes the piglit test texturing/max-texture-size
      causing the VM to die due to a too large SVGA command.
      Signed-off-by: default avatarJakob Bornecrantz <jakob@vmware.com>
      Reviewed-by: default avatarBiran Paul <brianp@vmware.com>
      Reviewed-by: default avatarZack Rusin <zackr@vmware.com>
      Signed-off-by: default avatarDave Airlie <airlied@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73bc40b8
    • Russ Anderson's avatar
      drivers/base/memory.c: fix show_mem_removable() to handle missing sections · 6e99f322
      Russ Anderson authored
      commit 21ea9f5a upstream.
      
      "cat /sys/devices/system/memory/memory*/removable" crashed the system.
      
      The problem is that show_mem_removable() is passing a
      bad pfn to is_mem_section_removable(), which causes
      
          if (!node_online(page_to_nid(page)))
      
      to blow up.  Why is it passing in a bad pfn?
      
      The reason is that show_mem_removable() will loop sections_per_block
      times.  sections_per_block is 16, but mem->section_count is 8,
      indicating holes in this memory block.  Checking that the memory section
      is present before checking to see if the memory section is removable
      fixes the problem.
      
         harp5-sys:~ # cat /sys/devices/system/memory/memory*/removable
         0
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         BUG: unable to handle kernel paging request at ffffea00c3200000
         IP: [<ffffffff81117ed1>] is_pageblock_removable_nolock+0x1/0x90
         PGD 83ffd4067 PUD 37bdfce067 PMD 0
         Oops: 0000 [#1] SMP
         Modules linked in: autofs4 binfmt_misc rdma_ucm rdma_cm iw_cm ib_addr ib_srp scsi_transport_srp scsi_tgt ib_ipoib ib_cm ib_uverbs ib_umad iw_cxgb3 cxgb3 mdio mlx4_en mlx4_ib ib_sa mlx4_core ib_mthca ib_mad ib_core fuse nls_iso8859_1 nls_cp437 vfat fat joydev loop hid_generic usbhid hid hwperf(O) numatools(O) dm_mod iTCO_wdt ipv6 iTCO_vendor_support igb i2c_i801 ioatdma i2c_algo_bit ehci_pci pcspkr lpc_ich i2c_core ehci_hcd ptp sg mfd_core dca rtc_cmos pps_core mperf button xhci_hcd sd_mod crc_t10dif usbcore usb_common scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh gru(O) xvma(O) xfs crc32c libcrc32c thermal sata_nv processor piix mptsas mptscsih scsi_transport_sas mptbase megaraid_sas fan thermal_sys hwmon ext3 jbd ata_piix ahci libahci libata scsi_mod
         CPU: 4 PID: 5991 Comm: cat Tainted: G           O 3.11.0-rc5-rja-uv+ #10
         Hardware name: SGI UV2000/ROMLEY, BIOS SGI UV 2000/3000 series BIOS 01/15/2013
         task: ffff88081f034580 ti: ffff880820022000 task.ti: ffff880820022000
         RIP: 0010:[<ffffffff81117ed1>]  [<ffffffff81117ed1>] is_pageblock_removable_nolock+0x1/0x90
         RSP: 0018:ffff880820023df8  EFLAGS: 00010287
         RAX: 0000000000040000 RBX: ffffea00c3200000 RCX: 0000000000000004
         RDX: ffffea00c30b0000 RSI: 00000000001c0000 RDI: ffffea00c3200000
         RBP: ffff880820023e38 R08: 0000000000000000 R09: 0000000000000001
         R10: 0000000000000000 R11: 0000000000000001 R12: ffffea00c33c0000
         R13: 0000160000000000 R14: 6db6db6db6db6db7 R15: 0000000000000001
         FS:  00007ffff7fb2700(0000) GS:ffff88083fc80000(0000) knlGS:0000000000000000
         CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
         CR2: ffffea00c3200000 CR3: 000000081b954000 CR4: 00000000000407e0
         Call Trace:
           show_mem_removable+0x41/0x70
           dev_attr_show+0x2a/0x60
           sysfs_read_file+0xf7/0x1c0
           vfs_read+0xc8/0x130
           SyS_read+0x5d/0xa0
           system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarRuss Anderson <rja@sgi.com>
      Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Reviewed-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      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>
      6e99f322
    • Paul Bolle's avatar
      regmap: silence GCC warning · ff289c1f
      Paul Bolle authored
      commit a8f28cfa upstream.
      
      Building regmap.o triggers this GCC warning:
          drivers/base/regmap/regmap.c: In function ‘regmap_raw_read’:
          drivers/base/regmap/regmap.c:1172:6: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      Long story short: Jakub Jelinek pointed out that there is a type
      mismatch between 'num' in regmap_volatile_range() and 'val_count' in
      regmap_raw_read(). And indeed, converting 'num' to the type of
      'val_count' (ie, size_t) makes this warning go away.
      Signed-off-by: default avatarPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ff289c1f