commit 58055a005855e4befb1d952aadba98acd78da354
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Sep 7 21:58:39 2013 -0700

    Linux 3.4.61

commit d3ba21877b9488abffd4528aa4b316ec5af27ea3
Author: Roland Dreier <roland@purestorage.com>
Date:   Mon Aug 5 17:55:01 2013 -0700

    SCSI: sg: Fix user memory corruption when SG_IO is interrupted by a signal
    
    commit 35dc248383bbab0a7203fca4d722875bc81ef091 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: Roland Dreier <roland@purestorage.com>
    Tested-by: David Milburn <dmilburn@redhat.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    [lizf: backported to 3.4:
     - Use __bio_for_each_segment() instead of bio_for_each_segment_all()]
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e51c435e8f955faeb93c8a10f71d7ebf43d887db
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Jul 24 16:15:08 2013 -0700

    target: Fix trailing ASCII space usage in INQUIRY vendor+model
    
    commit ee60bddba5a5f23e39598195d944aa0eb2d455e5 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: Tomas Molota <tomas.molota@lightstorm.sk>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f661fbf82b3751be0875ed0993d4c29f8268186
Author: Lan Tianyu <tianyu.lan@intel.com>
Date:   Mon Aug 26 10:19:18 2013 +0800

    ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT
    
    commit 524f42fab787a9510be826ce3d736b56d454ac6d 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=60765
    Reported-and-tested-by: Daniele Esposti <expo@expobrain.net>
    Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32cdf9033d757224ec8edc7d15a2206fe5975f5b
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Wed Aug 21 10:18:19 2013 +0200

    iwl4965: fix rfkill set state regression
    
    commit b2fcc0aee58a3435566dd6d8501a0b355552f28b upstream.
    
    My current 3.11 fix:
    
    commit 788f7a56fce1bcb2067b62b851a086fca48a0056
    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: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 837049ab21626553f6d84062cde74e38d4b7b0bd
Author: Helmut Schaa <helmut.schaa@googlemail.com>
Date:   Fri Aug 16 21:39:40 2013 +0200

    ath9k_htc: Restore skb headroom when returning skb to mac80211
    
    commit d2e9fc141e2aa21f4b35ee27072d84e9aa6e2ba0 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: Marc Kleine-Budde <mkl@blackshift.org>
    Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
    Tested-by: Marc Kleine-Budde <mkl@blackshift.org>
    Signed-off-by: Marc Kleine-Budde <mkl@blackshift.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52b331e9991f5639e8888349eccc02dd2986b51c
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed Aug 28 13:35:13 2013 -0400

    SUNRPC: Fix memory corruption issue on 32-bit highmem systems
    
    commit 347e2233b7667e336d9f671f1a52dfa3f0416e2c 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: Mark Young <MYoung@nvidia.com>
    Reported-by: Matt Craighead <mcraighead@nvidia.com>
    Cc: Bruce Fields <bfields@fieldses.org>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Tested-by: Matt Craighead <mcraighead@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5817e3c7a152e2febbb342a807487e739395a973
Author: Imre Deak <imre.deak@intel.com>
Date:   Fri Aug 23 23:50:23 2013 +0300

    drm/i915: ivb: fix edp voltage swing reg val
    
    commit 77fa4cbd5fa389e28419bbe8ac491b5fdd54840d upstream.
    
    Fix the typo introduced in
    
    commit 1a2eb4604b85c5efb343da8a4dcf41288fcfca85
    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=64880
    Tested-by: Jeremy Moles <cubicool@gmail.com>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73bc40b87e7e61dea9e06576f7e1c5eaf49abe31
Author: Jakob Bornecrantz <jakob@vmware.com>
Date:   Thu Aug 29 02:32:53 2013 +0200

    drm/vmwgfx: Split GMR2_REMAP commands if they are to large
    
    commit 6e4dcff3adbf25acb87e74500a58e3c07bdec40f 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: Jakob Bornecrantz <jakob@vmware.com>
    Reviewed-by: Biran Paul <brianp@vmware.com>
    Reviewed-by: Zack Rusin <zackr@vmware.com>
    Signed-off-by: Dave Airlie <airlied@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e99f322b52642004e9949bedf70bb12f12e3a17
Author: Russ Anderson <rja@sgi.com>
Date:   Wed Aug 28 16:35:18 2013 -0700

    drivers/base/memory.c: fix show_mem_removable() to handle missing sections
    
    commit 21ea9f5ace3a7317cc3ba1fbc749758021a83136 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: Russ Anderson <rja@sgi.com>
    Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
    Cc: Yinghai Lu <yinghai@kernel.org>
    Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff289c1fa9e4ca50d0ec0197678fa565f7b65d1b
Author: Paul Bolle <pebolle@tiscali.nl>
Date:   Mon Oct 8 22:06:30 2012 +0200

    regmap: silence GCC warning
    
    commit a8f28cfad8cd44d7c34b166d0e5ace1125dbee1f 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: Paul Bolle <pebolle@tiscali.nl>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ad23b795892c3f128cb05de5ee6d5ae5c422c28
Author: Eugene Surovegin <ebs@ebshome.net>
Date:   Mon Aug 26 11:53:32 2013 -0700

    powerpc/hvsi: Increase handshake timeout from 200ms to 400ms.
    
    commit d220980b701d838560a70de691b53be007e99e78 upstream.
    
    This solves a problem observed in kexec'ed kernel where 200ms timeout is
    too short and bootconsole fails to initialize. Console did eventually
    become workable but much later into the boot process.
    
    Observed timeout was around 260ms, but I decided to make it a little bigger
    for more reliability.
    
    This has been tested on Power7 machine with Petitboot as a primary
    bootloader and PowerNV firmware.
    
    Signed-off-by: Eugene Surovegin <surovegin@google.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a72233b3de7a35cd106db00f46c38960f9698f4
Author: Paul Mackerras <paulus@samba.org>
Date:   Tue Aug 27 16:07:49 2013 +1000

    powerpc: Work around gcc miscompilation of __pa() on 64-bit
    
    commit bdbc29c19b2633b1d9c52638fb732bcde7a2031a upstream.
    
    On 64-bit, __pa(&static_var) gets miscompiled by recent versions of
    gcc as something like:
    
            addis 3,2,.LANCHOR1+4611686018427387904@toc@ha
            addi 3,3,.LANCHOR1+4611686018427387904@toc@l
    
    This ends up effectively ignoring the offset, since its bottom 32 bits
    are zero, and means that the result of __pa() still has 0xC in the top
    nibble.  This happens with gcc 4.8.1, at least.
    
    To work around this, for 64-bit we make __pa() use an AND operator,
    and for symmetry, we make __va() use an OR operator.  Using an AND
    operator rather than a subtraction ends up with slightly shorter code
    since it can be done with a single clrldi instruction, whereas it
    takes three instructions to form the constant (-PAGE_OFFSET) and add
    it on.  (Note that MEMORY_START is always 0 on 64-bit.)
    
    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa5189165d9897c84b43d762618ee8924c5f9c9e
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Aug 27 12:03:01 2013 +0200

    ALSA: opti9xx: Fix conflicting driver object name
    
    commit fb615499f0ad28ed74201c1cdfddf9e64e205424 upstream.
    
    The recent commit to delay the release of kobject triggered NULL
    dereferences of opti9xx drivers.  The cause is that all
    snd-opti92x-ad1848, snd-opti92x-cs4231 and snd-opti93x drivers
    register the PnP card driver with the very same name, and also
    snd-opti92x-ad1848 and -cs4231 drivers register the ISA driver with
    the same name, too.  When these drivers are built in, quick
    "register-release-and-re-register" actions occur, and this results in
    Oops because of the same name is assigned to the kobject.
    
    The fix is simply to assign individual names.  As a bonus, by using
    KBUILD_MODNAME, the patch reduces more lines than it adds.
    
    The fix is based on the suggestion by Russell King.
    
    Reported-and-tested-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e446ef9608a07af0cf07aa887ddf37224fd345d8
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Thu Aug 15 15:36:49 2013 -0500

    jfs: fix readdir cookie incompatibility with NFSv4
    
    commit 44512449c0ab368889dd13ae0031fba74ee7e1d2 upstream.
    
    NFSv4 reserves readdir cookie values 0-2 for special entries (. and ..),
    but jfs allows a value of 2 for a non-special entry. This incompatibility
    can result in the nfs client reporting a readdir loop.
    
    This patch doesn't change the value stored internally, but adds one to
    the value exposed to the iterate method.
    
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - s/ctx->pos/filp->f_pos/]
    Tested-by: Christian Kujau <lists@nerdbynature.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>