Btrfs: don't allow the replace procedure on read only filesystems

commit bbb651e469d99f0088e286fdeb54acca7bb4ad4e upstream.

If you start the replace procedure on a read only filesystem, at
the end the procedure fails to write the updated dev_items to the
chunk tree. The problem is that this error is not indicated except
for a WARN_ON(). If the user now thinks that everything was done
as expected and destroys the source device (with mkfs or with a
hammer). The next mount fails with "failed to read chunk root" and
the filesystem is gone.

This commit adds code to fail the attempt to start the replace
procedure if the filesystem is mounted read-only.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: siano: fix divide error on 0 counters

commit ec532503209053bbee0c7dac410031e50835e01a upstream.

GIT_AUTHOR_DATE=1376465691
I took a quick look at the code and wonder if the problem is caused by
an initial zero statistics message?  This is all just a wild guess, but
if it is correct, then the attached untested patch might fix it...
Bjørn
>From d78a0599d5b5d4da384eae08bf7da316389dfbe5 Mon Sep 17 00:00:00 2001
ts_packets and ets_packets counters can be 0.  Don't fall over
if they are. Fixes:
[  846.851711] divide error: 0000 [#1] SMP
[  846.851806] Modules linked in: smsdvb dvb_core ir_lirc_codec lirc_dev ir_sanyo_decoder ir_mce_kbd_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder rc_hauppauge smsusb smsmdtv rc_core pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) parport_pc ppdev lp parport cpufreq_userspace cpufreq_powersave cpufreq_stats cpufreq_conservative rfcomm bnep binfmt_misc uinput nfsd auth_rpcgss oid_registry nfs_acl nfs lockd dns_resolver fscache sunrpc ext4 jbd2 fuse tp_smapi(O) thinkpad_ec(O) loop firewire_sbp2 dm_crypt snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm thinkpad_acpi nvram snd_page_alloc hid_generic snd_seq_midi snd_seq_midi_event arc4 usbhid snd_rawmidi uvcvideo hid iwldvm coretemp kvm_intel mac8021
 1 cdc_wdm
[  846.853477]  cdc_acm snd_seq videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media kvm radeon r852 ttm joydev cdc_ether usbnet pcmcia mii sm_common nand btusb drm_kms_helper tpm_tis acpi_cpufreq bluetooth iwlwifi nand_ecc drm nand_ids i2c_i801 mtd snd_seq_device iTCO_wdt iTCO_vendor_support r592 memstick lpc_ich mperf tpm yenta_socket pcmcia_rsrc pcmcia_core cfg80211 snd_timer snd pcspkr i2c_algo_bit crc16 i2c_core tpm_bios processor mfd_core wmi psmouse mei_me rfkill mei serio_raw soundcore evdev battery button video ac microcode ext3 mbcache jbd md_mod dm_mirror dm_region_hash dm_log dm_mod sg sr_mod sd_mod cdrom crc_t10dif firewire_ohci sdhci_pci sdhci mmc_core firewire_core crc_itu_t thermal thermal_sys ahci libahci ehci_pci uhci_hcd ehci_hcd libata scsi_mod usbcore e1000
 e usb_common
[  846.855310]  ptp pps_core
[  846.855356] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O 3.10-2-amd64 #1 Debian 3.10.5-1
[  846.855490] Hardware name: LENOVO 4061WFA/4061WFA, BIOS 6FET92WW (3.22 ) 12/14/2011
[  846.855609] task: ffffffff81613400 ti: ffffffff81600000 task.ti: ffffffff81600000
[  846.855636] RIP: 0010:[<ffffffffa092be0c>]  [<ffffffffa092be0c>] smsdvb_onresponse+0x264/0xa86 [smsdvb]
[  846.863906] RSP: 0018:ffff88013bc03cf0  EFLAGS: 00010046
[  846.863906] RAX: 0000000000000000 RBX: ffff880133bf6000 RCX: 0000000000000000
[  846.863906] RDX: 0000000000000000 RSI: ffff88005d3b58c0 RDI: ffff880133bf6000
[  846.863906] RBP: ffff88005d1da000 R08: 0000000000000058 R09: 0000000000000015
[  846.863906] R10: 0000000000001a0d R11: 000000000000021a R12: ffff88005d3b58c0
[  846.863906] R13: ffff88005d1da008 R14: 00000000ffffff8d R15: ffff880036cf5060
[  846.863906] FS:  0000000000000000(0000) GS:ffff88013bc00000(0000) knlGS:0000000000000000
[  846.863906] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  846.863906] CR2: 00007f3a4b69ae50 CR3: 0000000036dac000 CR4: 00000000000407f0
[  846.863906] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  846.863906] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  846.863906] Stack:
[  846.863906]  ffff88007a102000 ffff88005d1da000 ffff88005d3b58c0 0000000000085824
[  846.863906]  ffffffffa08c5aa3 ffff88005d1da000 ffff8800a6907390 ffff8800a69073b0
[  846.863906]  ffff8800a6907000 ffffffffa08b642c 000000000000021a ffff8800a69073b0
[  846.863906] Call Trace:
[  846.863906]  <IRQ>
[  846.863906]
[  846.863906]  [<ffffffffa08c5aa3>] ? smscore_onresponse+0x1d5/0x353 [smsmdtv]
[  846.863906]  [<ffffffffa08b642c>] ? smsusb_onresponse+0x146/0x192 [smsusb]
[  846.863906]  [<ffffffffa004cb1a>] ? usb_hcd_giveback_urb+0x6c/0xac [usbcore]
[  846.863906]  [<ffffffffa0217be1>] ? ehci_urb_done+0x62/0x72 [ehci_hcd]
[  846.863906]  [<ffffffffa0217c82>] ? qh_completions+0x91/0x364 [ehci_hcd]
[  846.863906]  [<ffffffffa0219bba>] ? ehci_work+0x8a/0x68e [ehci_hcd]
[  846.863906]  [<ffffffff8107336c>] ? timekeeping_get_ns.constprop.10+0xd/0x31
[  846.863906]  [<ffffffff81064d41>] ? update_cfs_rq_blocked_load+0xde/0xec
[  846.863906]  [<ffffffff81058ec2>] ? run_posix_cpu_timers+0x25/0x575
[  846.863906]  [<ffffffffa021aa46>] ? ehci_irq+0x211/0x23d [ehci_hcd]
[  846.863906]  [<ffffffffa004c0c1>] ? usb_hcd_irq+0x31/0x48 [usbcore]
[  846.863906]  [<ffffffff810996fd>] ? handle_irq_event_percpu+0x49/0x1a4
[  846.863906]  [<ffffffff8109988a>] ? handle_irq_event+0x32/0x4b
[  846.863906]  [<ffffffff8109bd76>] ? handle_fasteoi_irq+0x80/0xb6
[  846.863906]  [<ffffffff8100e93e>] ? handle_irq+0x18/0x20
[  846.863906]  [<ffffffff8100e657>] ? do_IRQ+0x40/0x95
[  846.863906]  [<ffffffff813883ed>] ? common_interrupt+0x6d/0x6d
[  846.863906]  <EOI>
[  846.863906]
[  846.863906]  [<ffffffff812a011c>] ? arch_local_irq_enable+0x4/0x8
[  846.863906]  [<ffffffff812a04f3>] ? cpuidle_enter_state+0x52/0xc1
[  846.863906]  [<ffffffff812a0636>] ? cpuidle_idle_call+0xd4/0x143
[  846.863906]  [<ffffffff8101398c>] ? arch_cpu_idle+0x5/0x17
[  846.863906]  [<ffffffff81072571>] ? cpu_startup_entry+0x10d/0x187
[  846.863906]  [<ffffffff816b3d3d>] ? start_kernel+0x3e8/0x3f3
[  846.863906]  [<ffffffff816b3777>] ? repair_env_string+0x54/0x54
[  846.863906]  [<ffffffff816b3598>] ? x86_64_start_kernel+0xf2/0xfd
[  846.863906] Code: 25 09 00 00 c6 83 da 08 00 00 03 8b 45 54 48 01 83 b6 08 00 00 8b 45 50 48 01 83 db 08 00 00 8b 4d 18 69 c1 ff ff 00 00 03 4d 14 <48> f7 f1 89 83 a8 09 00 00 e9 68 fe ff ff 48 8b 7f 10 e8 79 92
[  846.863906] RIP  [<ffffffffa092be0c>] smsdvb_onresponse+0x264/0xa86 [smsdvb]
[  846.863906]  RSP <ffff88013bc03cf0>
Reference: http://bugs.debian.org/719623

Reported-by: Johannes Rohr <jorohr@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: mb86a20s: Fix TS parallel mode

commit 9d32069faacdc81fe1dcb5d297c32a3ac81da8f0 upstream.

changeset 768e6dadd74 caused a regression on using mb86a20s
in parallel mode, as the parallel mode selection got
overriden by mb86a20s_init2.

Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: cx88: Fix regression: CX88_AUDIO_WM8775 can't be 0

commit f66b2a1c7f2ae3fb0d5b67d07ab4f5055fd3cf16 upstream.

Cards using the wm8775 specify that in their card struct. Those that do not
use it leave the audio_chip field to 0. Unfortunately, the CX88_AUDIO_WM8775
enum is 0 as well, so boards that do not have the wm8775 still try to load
and use that driver. Change it to 1 to fix this.
This regression was introduced in commit facd23664f1d63c33fbc6da52261c8548ed3fbd4.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Tested-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: exynos4-is: Fix entity unregistration on error path

commit d2b903b4427e417a73863cef36ad0796ea6b7404 upstream.

This patch corrects media entities unregistration order to make sure
the fimc.N.capture and fimc-lite video nodes are unregistered with
fimc->lock mutex held. This prevents races between video device open()
and defered probing and NULL pointer dereference in open() callback
as follows:
[   77.645000] Unable to handle kernel NULL pointer dereference at virtual address 00000290t
[   77.655000] pgd = ee7a8000
[   77.660000] [00000290] *pgd=6e13c831, *pte=00000000, *ppte=00000000
[   77.665000] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[   77.670000] Modules linked in: s5p_fimc ipv6 exynos_fimc_is exynos_fimc_lite
 s5p_csis v4l2_mem2mem videobuf2_dma_contig videobuf2_memops exynos4_is_common videobuf2_core [last unloaded: s5p_fimc]
[   77.685000] CPU: 0 PID : 2998 Comm: v4l_id Tainted: G        W   3.10.0-next-20130709-00039-g39f491b-dirty #1548
[   77.695000] task: ee084000 ti: ee46e000 task.ti: ee46e000
[   77.700000] PC is at __mutex_lock_slowpath+0x54/0x368
[   77.705000] LR is at __mutex_lock_slowpath+0x24/0x368
[   77.710000] pc : [<c038dc10>]    lr : [<c038dbe0>]    psr: 60000093
[   77.710000] sp : ee46fd70  ip : 000008c8  fp : c054e34c
[   77.725000] r10: ee084000  r9 : 00000000  r8 : ee439480
[   77.730000] r7 : ee46e000  r6 : 60000013  r5 : 00000290  r4 : 0000028c
[   77.735000] r3 : 00000000  r2 : 00000000  r1 : 20000093  r0 : 00000001
[   77.740000] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment user
[   77.750000] Control: 10c5387d  Table: 6e7a804a  DAC: 00000015
[   77.755000] Process v4l_id (pid: 2998, stack limit = 0xee46e238)
[   77.760000] Stack: (0xee46fd70 to 0xee470000)
            ...
[   77.935000] [<c038dc10>] (__mutex_lock_slowpath+0x54/0x368) from [<c038df30>] (mutex_lock+0xc/0x24)
[   77.945000] [<c038df30>] (mutex_lock+0xc/0x24) from [<bf03fa90>] (fimc_lite_open+0x12c/0x2bc [exynos_fimc_lite])
[   77.955000] [<bf03fa90>] (fimc_lite_open+0x12c/0x2bc [exynos_fimc_lite]) from [<c02ab11c>] (v4l2_open+0xa0/0xe0)
[   77.965000] [<c02ab11c>] (v4l2_open+0xa0/0xe0) from [<c00b1de4>] (chrdev_open+0x88/0x170)
[   77.975000] [<c00b1de4>] (chrdev_open+0x88/0x170) from [<c00ac710>] (do_dentry_open.isra.14+0x1d8/0x258)
[   77.985000] [<c00ac710>] (do_dentry_open.isra.14+0x1d8/0x258) from [<c00ac860>] (finish_open+0x20/0x38)
[   77.995000] [<c00ac860>] (finish_open+0x20/0x38) from [<c00ba658>] (do_last.isra.43+0x538/0xb1c)
[   78.000000] [<c00ba658>] (do_last.isra.43+0x538/0xb1c) from [<c00bacf0>] (path_openat+0xb4/0x5c4)
[   78.010000] [<c00bacf0>] (path_openat+0xb4/0x5c4) from [<c00bb4b4>] (do_filp_open+0x2c/0x80)
[   78.020000] [<c00bb4b4>] (do_filp_open+0x2c/0x80) from [<c00ad744>] (do_sys_open+0xf4/0x1a8)
[   78.025000] [<c00ad744>] (do_sys_open+0xf4/0x1a8) from [<c000e320>] (ret_fast_syscall+0x0/0x30)
[   78.035000] Code: 1a000093 e10f6000 f10c0080 e2845004 (e1953f9f)

Reported-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: exynos-gsc: Register v4l2 device

commit d0b1c31349969973204fad21a076aecf131cc5e4 upstream.

Gscaler video device registration was happening without reference to
a parent v4l2_dev causing probe to fail. The patch creates a parent
v4l2 device and uses it for the gsc m2m video device registration.
This fixes regression introduced with comit commit 1c1d86a1ea07506
[media] v4l2: always require v4l2_dev, rename parent to dev_parent

Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: exynos4-is: Fix fimc-lite bayer formats

commit 3396b096c54a84603c51bd705effa88f7f5b0d76 upstream.

The 10-bit and 12-bit Bayer output formats supported by FIMC-LITE
actually use 16 bits where the extra bits are padded with zeros.
The patch corrects buffer allocation for these two formats by
modifying the depth field. This prevents memory corruption by the
output DMA due to insufficient buffer size.

Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: usbhid: quirk for N-Trig DuoSense Touch Screen

commit 9e0bf92c223dabe0789714f8f85f6e26f8f9cda4 upstream.

The DuoSense touchscreen device causes a 10 second timeout. This fix
removes the delay.

Signed-off-by: Vasily Titskiy <qehgt0@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: check for NULL field when setting values

commit be67b68d52fa28b9b721c47bb42068f0c1214855 upstream.

Defensively check that the field to be worked on is not NULL.

Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: hidraw: correctly deallocate memory on device disconnect

commit 212a871a3934beccf43431608c27ed2e05a476ec upstream.

This changes puts the commit 4fe9f8e203f back in place
with the fixes for slab corruption because of the commit.

When a device is unplugged, wait for all processes that
have opened the device to close before deallocating the device.

This commit was solving kernel crash because of the corruption in
rb tree of vmalloc. The rootcause was the device data pointer was
geting excessed after the memory associated with hidraw was freed.

The commit 4fe9f8e203f was buggy as it was also freeing the hidraw
first and then calling delete operation on the list associated with
that hidraw leading to slab corruption.

Signed-off-by: Manoj Chourasia <mchourasia@nvidia.com>
Tested-by: Peter Wu <lekensteyn@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: battery: don't do DMA from stack

commit 6c2794a2984f4c17a58117a68703cc7640f01c5a upstream.

Instead of using data from stack for DMA in hidinput_get_battery_property(),
allocate the buffer dynamically.

Reported-by: Richard Ryniker <ryniker@alum.mit.edu>
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: picolcd: Prevent NULL pointer dereference on _remove()

commit 1cde501bb4655e98fb832194beb88ac73be5a05d upstream.

When picolcd is switched into bootloader mode (for FW flashing) make
sure not to try to dereference NULL-pointers of feature-devices during
unplug/unbind.

This fixes following BUG:
  BUG: unable to handle kernel NULL pointer dereference at 00000298
  IP: [<f811f56b>] picolcd_exit_framebuffer+0x1b/0x80 [hid_picolcd]
  *pde = 00000000
  Oops: 0000 [#1]
  Modules linked in: hid_picolcd syscopyarea sysfillrect sysimgblt fb_sys_fops
  CPU: 0 PID: 15 Comm: khubd Not tainted 3.11.0-rc7-00002-g50d62d4 #2
  EIP: 0060:[<f811f56b>] EFLAGS: 00010292 CPU: 0
  EIP is at picolcd_exit_framebuffer+0x1b/0x80 [hid_picolcd]
  Call Trace:
   [<f811d1ab>] picolcd_remove+0xcb/0x120 [hid_picolcd]
   [<c1469b09>] hid_device_remove+0x59/0xc0
   [<c13464ca>] __device_release_driver+0x5a/0xb0
   [<c134653f>] device_release_driver+0x1f/0x30
   [<c134603d>] bus_remove_device+0x9d/0xd0
   [<c13439a5>] device_del+0xd5/0x150
   [<c14696a4>] hid_destroy_device+0x24/0x60
   [<c1474cbb>] usbhid_disconnect+0x1b/0x40
   ...

Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: ntrig: validate feature report details

commit 875b4e3763dbc941f15143dd1a18d10bb0be303b upstream.

A HID device could send a malicious feature report that would cause the
ntrig HID driver to trigger a NULL dereference during initialization:

[57383.031190] usb 3-1: New USB device found, idVendor=1b96, idProduct=0001
...
[57383.315193] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
[57383.315308] IP: [<ffffffffa08102de>] ntrig_probe+0x25e/0x420 [hid_ntrig]

CVE-2013-2896

Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Rafi Rubin <rafi@seas.upenn.edu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: picolcd_core: validate output report details

commit 1e87a2456b0227ca4ab881e19a11bb99d164e792 upstream.

A HID device could send a malicious output report that would cause the
picolcd HID driver to trigger a NULL dereference during attr file writing.

[jkosina@suse.cz: changed

report->maxfield < 1

to

report->maxfield != 1

as suggested by Bruno].

CVE-2013-2899

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Bruno Prémont <bonbons@linux-vserver.org>
Acked-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: validate HID report id size

commit 43622021d2e2b82ea03d883926605bdd0525e1d1 upstream.

The "Report ID" field of a HID report is used to build indexes of
reports. The kernel's index of these is limited to 256 entries, so any
malicious device that sets a Report ID greater than 255 will trigger
memory corruption on the host:

[ 1347.156239] BUG: unable to handle kernel paging request at ffff88094958a878
[ 1347.156261] IP: [<ffffffff813e4da0>] hid_register_report+0x2a/0x8b

CVE-2013-2888

Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: sensor-hub: validate feature report details

commit 9e8910257397372633e74b333ef891f20c800ee4 upstream.

A HID device could send a malicious feature report that would cause the
sensor-hub HID driver to read past the end of heap allocation, leaking
kernel memory contents to the caller.

CVE-2013-2898

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: Fix Speedlink VAD Cezanne support for some devices

commit 06bb5219118fb098f4b0c7dcb484b28a52bf1c14 upstream.

Some devices of the "Speedlink VAD Cezanne" model need more aggressive fixing
than already done.

I made sure through testing that this patch would not interfere with the proper
working of a device that is bug-free. (The driver drops EV_REL events with
abs(val) >= 256, which are not achievable even on the highest laser resolution
hardware setting.)

Signed-off-by: Stefan Kriwanek <mail@stefankriwanek.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: wiimote: work around broken DRM_KAI on GEN10

commit a6be8569b6705cbc26e7ae1a8be476067cc5a78b upstream.

GEN10 and earlier devices seem to not support DRM_KAI if we run in basic
IR mode. Use DRM_KAIE instead. This might increases overhead slightly as
the extension port is read and streamed but we stream accelerometer data
constantly, too, so this is negligible.

Note that our parsers are hardcoded on IR-formats, so we cannot actually
use 96-bit IR DRMs for basic IR data. We would have to adjust the parsers.
But as only GEN20 and newer support this, we simply avoid mixed DRMs.

This fixes a bug where GEN10 devices didn't provide IR data if
accelerometer and IR are enabled simultaneously. As a workaround, you can
enable DRM_KAIE without this patch via (disables device power-management):
  echo "37" >/sys/kernel/debug/hid/<dev>/drm

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reported-by: Nicolas Adenis-Lamarre <nicolas.adenis.lamarre@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: kye: Add report fixup for Genius Gx Imperator Keyboard

commit 0adb9c2c5ed42f199cb2a630c37d18dee385fae2 upstream.

Genius Gx Imperator Keyboard presents the same problem in its report
descriptors than Genius Gila Gaming Mouse.
Use the same fixup for both.

Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=928561

Reported-and-tested-by: Honza Brazdil <jbrazdil@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: pantherlord: validate output report details

commit 412f30105ec6735224535791eed5cdc02888ecb4 upstream.

A HID device could send a malicious output report that would cause the
pantherlord HID driver to write beyond the output report allocation
during initialization, causing a heap overflow:

[  310.939483] usb 1-1: New USB device found, idVendor=0e8f, idProduct=0003
...
[  315.980774] BUG kmalloc-192 (Tainted: G        W   ): Redzone overwritten

CVE-2013-2892

Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: Correct the USB IDs for the new Macbook Air 6

commit 8c89cc17b91992845bd635813cd162fe8dfcec6e upstream.

A recent patch (9d9a04ee) added support for the new machine, but got
the sequence of USB ids wrong. Reports from both Ian and Linus T show
that the 0x0291 id is for ISO, not ANSI, which should have the missing
number 0x0290. This patchs moves the three numbers accordingly, fixing
the problem.

Reported-and-tested-by: Ian Munsie <darkstarsword@gmail.com>
Tested-by: Linus G Thiel <linus@hanssonlarsson.se>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: mvneta: properly disable HW PHY polling and ensure adjust_link() works

commit 714086029116b6b0a34e67ba1dd2f0d1cf26770c upstream.

This commit fixes a long-standing bug that has been reported by many
users: on some Armada 370 platforms, only the network interface that
has been used in U-Boot to tftp the kernel works properly in
Linux. The other network interfaces can see a 'link up', but are
unable to transmit data. The reports were generally made on the Armada
370-based Mirabox, but have also been given on the Armada 370-RD
board.

The network MAC in the Armada 370/XP (supported by the mvneta driver
in Linux) has a functionality that allows it to continuously poll the
PHY and directly update the MAC configuration accordingly (speed,
duplex, etc.). The very first versions of the driver submitted for
review were using this hardware mechanism, but due to this, the driver
was not integrated with the kernel phylib. Following reviews, the
driver was changed to use the phylib, and therefore a software based
polling. In software based polling, Linux regularly talks to the PHY
over the MDIO bus, and sees if the link status has changed. If it's
the case then the adjust_link() callback of the driver is called to
update the MAC configuration accordingly.

However, it turns out that the adjust_link() callback was not
configuring the hardware in a completely correct way: while it was
setting the speed and duplex bits correctly, it wasn't telling the
hardware to actually take into account those bits rather than what the
hardware-based PHY polling mechanism has concluded. So, in fact the
adjust_link() callback was basically a no-op.

However, the network happened to be working because on the network
interfaces used by U-Boot for tftp on Armada 370 platforms because the
hardware PHY polling was enabled by the bootloader, and left enabled
by Linux. However, the second network interface not used for tftp (or
both network interfaces if the kernel is loaded from USB, NAND or SD
card) didn't had the hardware PHY polling enabled.

This patch fixes this situation by:

 (1) Making sure that the hardware PHY polling is disabled by clearing
     the MVNETA_PHY_POLLING_ENABLE bit in the MVNETA_UNIT_CONTROL
     register in the driver ->probe() function.

 (2) Making sure that the duplex and speed selections made by the
     adjust_link() callback are taken into account by clearing the
     MVNETA_GMAC_AN_SPEED_EN and MVNETA_GMAC_AN_DUPLEX_EN bits in the
     MVNETA_GMAC_AUTONEG_CONFIG register.

This patch has been tested on Armada 370 Mirabox, and now both network
interfaces are usable after boot.

[ Problem introduced by commit c5aff18 ("net: mvneta: driver for
  Marvell Armada 370/XP network unit") ]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Jochen De Smet <jochen.armkernel@leahnim.org>
Cc: Peter Sanford <psanford@nearbuy.io>
Cc: Ethan Tuttle <ethan@ethantuttle.com>
Cc: Chény Yves-Gael <yves@cheny.fr>
Cc: Ryan Press <ryan@presslab.us>
Cc: Simon Guinot <simon.guinot@sequanux.org>
Cc: vdonnefort@lacie.com
Acked-by: Jason Cooper <jason@lakedaemon.net>
Tested-by: Vincent Donnefort <vdonnefort@gmail.com>
Tested-by: Yves-Gael Cheny <yves@cheny.fr>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ath9k: avoid accessing MRC registers on single-chain devices

commit a1c781bb20ac1e03280e420abd47a99eb8bbdd3b upstream.

They are not implemented, and accessing them might trigger errors

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ath9k: fix rx descriptor related race condition

commit e96542e55a2aacf4bdeccfe2f17b77c4895b4df2 upstream.

Similar to a race condition that exists in the tx path, the hardware
might re-read the 'next' pointer of a descriptor of the last completed
frame. This only affects non-EDMA (pre-AR93xx) devices.

To deal with this race, defer clearing and re-linking a completed rx
descriptor until the next one has been processed.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ath9k: always clear ps filter bit on new assoc

commit 026d5b07c03458f9c0ccd19c3850564a5409c325 upstream.

Otherwise in some cases, EAPOL frames might be filtered during the
initial handshake, causing delays and assoc failures.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()

commit 67d0cf50bd32b66eab709871714e55725ee30ce4 upstream.

The driver fails to check the results of DMA mapping in twp places,
which results in the following warning:

[   28.078515] ------------[ cut here ]------------
[   28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930()
[   28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver failed to check map error[device address=0x00000000b5d60d6c] [size=1876 bytes] [mapped as
 single]
[   28.078536] Modules linked in: bnep bluetooth vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu rtl8192c_common rtlwifi mac802
11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer snd_seq_device snd k8temp
 cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4 jbd2 mbcache crc1
6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_amd
[   28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted: G           O 3.10.0-rc7-wl+ #42
[   28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook PC/30D6, BIOS F.27 11/27/2008
[   28.078607]  0000000000000009 ffff8800bbb03ad8 ffffffff8144f898 ffff8800bbb03b18
[   28.078612]  ffffffff8103e1eb 0000000000000002 ffff8800b719f480 ffff8800b7b9c010
[   28.078617]  ffffffff824204c0 ffffffff81754d57 0000000000000754 ffff8800bbb03b78
[   28.078622] Call Trace:
[   28.078624]  <IRQ>  [<ffffffff8144f898>] dump_stack+0x19/0x1b
[   28.078634]  [<ffffffff8103e1eb>] warn_slowpath_common+0x6b/0xa0
[   28.078638]  [<ffffffff8103e2c1>] warn_slowpath_fmt+0x41/0x50
[   28.078650]  [<ffffffff8122d7ae>] check_unmap+0x47e/0x930
[   28.078655]  [<ffffffff8122de4c>] debug_dma_unmap_page+0x5c/0x70
[   28.078679]  [<ffffffffa04a808c>] dma64_getnextrxp+0x10c/0x190 [brcmsmac]
[   28.078691]  [<ffffffffa04a9042>] dma_rx+0x62/0x240 [brcmsmac]
[   28.078707]  [<ffffffffa0479101>] brcms_c_dpc+0x211/0x9d0 [brcmsmac]
[   28.078717]  [<ffffffffa046d927>] ? brcms_dpc+0x27/0xf0 [brcmsmac]
[   28.078731]  [<ffffffffa046d947>] brcms_dpc+0x47/0xf0 [brcmsmac]
[   28.078736]  [<ffffffff81047dcc>] tasklet_action+0x6c/0xf0
--snip--
[   28.078974]  [<ffffffff813891bd>] SyS_sendmsg+0xd/0x20
[   28.078979]  [<ffffffff81455c24>] tracesys+0xdd/0xe2
[   28.078982] ---[ end trace 6164d1a08148e9c8 ]---
[   28.078984] Mapped at:
[   28.078985]  [<ffffffff8122c8fd>] debug_dma_map_page+0x9d/0x150
[   28.078989]  [<ffffffffa04a9322>] dma_rxfill+0x102/0x3d0 [brcmsmac]
[   28.079001]  [<ffffffffa047a13d>] brcms_c_init+0x87d/0x1100 [brcmsmac]
[   28.079010]  [<ffffffffa046d851>] brcms_init+0x21/0x30 [brcmsmac]
[   28.079018]  [<ffffffffa04786e0>] brcms_c_up+0x150/0x430 [brcmsmac]

As the patch adds a new failure mechanism to dma_rxfill(). When I changed the
comment at the start of the routine to add that information, I also polished
the wording.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Brett Rudley <brudley@broadcom.com>
Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Cc: Hante Meuleman <meuleman@broadcom.com>
Cc: brcm80211-dev-list@broadcom.com
Acked-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mac80211: ignore (E)CSA in probe response frames

commit d70b7616d9080ec9f868fbd31db5fd4341435d61 upstream.

Seth reports that some APs, notably the Netgear WNDAP360, send
invalid ECSA IEs in probe response frames with the operating
class and channel number both set to zero, even when no channel
switch is being done. As a result, any scan while connected to
such an AP results in the connection being dropped.

Fix this by ignoring any channel switch announcment in probe
response frames entirely, since we're connected to the AP we
will be receiving a beacon (and maybe even an action frame) if
a channel switch is done, which is sufficient.

Reported-by: Seth Forshee <seth.forshee@canonical.com>
Tested-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: simplify truncation code in ext4_setattr()

commit 5208386c501276df18fee464e21d3c58d2d79517 upstream.

Merge conditions in ext4_setattr() handling inode size changes, also
move ext4_begin_ordered_truncate() call somewhat earlier because it
simplifies error recovery in case of failure. Also add error handling in
case i_disksize update fails.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix ext4_writepages() in presence of truncate

commit 5f1132b2ba8c873f25982cf45917e8455fb6c962 upstream.

Inode size can arbitrarily change while writeback is in progress. When
ext4_writepages() has prepared a long extent for mapping and truncate
then reduces i_size, mpage_map_and_submit_buffers() will always map just
one buffer in a page instead of all of them due to lblk < blocks check.
So we end up not using all blocks we've allocated (thus leaking them)
and also delalloc accounting goes wrong manifesting as a warning like:

ext4_da_release_space:1333: ext4_da_release_space: ino 12, to_free 1
with only 0 reserved data blocks

Note that the problem can happen only when blocksize < pagesize because
otherwise we have only a single buffer in the page.

Fix the problem by removing the size check from the mapping loop. We
have an extent allocated so we have to use it all before checking for
i_size. We also rename add_page_bufs_to_extent() to
mpage_process_page_bufs() and make that function submit the page for IO
if all buffers (upto EOF) in it are mapped.

Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Zheng Liu <gnehzuil.liu@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: move test whether extent to map can be extended to one place

commit 09930042a2e94cf8ee79d22943915612c1e4ba51 upstream.

Currently the logic whether the current buffer can be added to an extent
of buffers to map is split between mpage_add_bh_to_extent() and
add_page_bufs_to_extent(). Move the whole logic to
mpage_add_bh_to_extent() which makes things a bit more straightforward
and make following i_size fixes easier.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pinctrl: at91: fix get_pullup/down function return

commit 05d3534a321d7fe4524b3b83bb20318282f3ec2c upstream.

In PIO_PUSR and PIO_PPDSR register if a given bit is set 1 this means the
pullup/down for this pin (pin is represented as a bit position) is
disabled.

Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda - Add Toshiba Satellite C870 to MSI blacklist

commit 83f72151352791836a1b9c1542614cc9bf71ac61 upstream.

Toshiba Satellite C870 shows interrupt problems occasionally when
certain mixer controls like "Mic Switch" is toggled.  This seems
worked around by not using MSI.

Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=833585
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda - hdmi: Fallback to ALSA allocation when selecting CA

commit 18e391862cceaf43ddb8eb5cca05e1a83abdebaa upstream.

hdmi_channel_allocation() tries to find a HDMI channel allocation that
matches the number channels in the playback stream and contains only
speakers that the HDMI sink has reported as available via EDID. If no
such allocation is found, 0 (stereo audio) is used.

Using CA 0 causes the audio causes the sink to discard everything except
the first two channels (front left and front right).

However, the sink may be capable of receiving more channels than it has
speakers (and then perform downmix or discard the extra channels), in
which case it is preferable to use a CA that contains extra channels
than to use CA 0 which discards all the non-stereo channels.

Additionally, it seems that HBR (HD) passthrough output does not work on
Intel HDMI codecs when CA is set to 0 (possibly the codec zeroes
channels not present in CA). This happens with all receivers that report
a 5.1 speaker mask since a HBR stream is carried on 8 channels to the
codec.

Add a fallback in the CA selection so that the CA channel count at least
matches the stream channel count, even if the stream contains channels
not present in the sink speaker descriptor.

Thanks to GrimGriefer at OpenELEC forums for discovering that changing
the sink speaker mask allowed HBR output.

Reported-by: GrimGriefer
Reported-by: Ashecrow
Reported-by: Frank Zafka <kafkaesque1978@gmail.com>
Reported-by: Peter Frühberger <fritsch@xbmc.org>
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda - Re-setup HDMI pin and audio infoframe on stream switches

commit b054087dbacee30a9dddaef2c9a96312146be04e upstream.

When the transcoder:port mapping on Haswell HDMI/DP audio is changed
during the stream playback, the sound gets lost.  Typically this
problem is seen when the user switches the graphics mode from eDP+DP
to DP-only configuration, where CRTC 1 is used for DP in the former
while CRTC 0 is used for the latter.

The graphics controller notifies the change via the normal ELD update
procedure, so we get the intrinsic event.  For enabling the sound
again, the HDMI audio driver needs to reset the pin and set up the
audio infoframe again.

This patch achieves it by:
- keep the current status of channels and info frame setup in per_pin
  struct,
- check the reconnection in the intrinsic event handler,
- reset the pin and the re-invoke hdmi_setup_audio_infoframe()
  accordingly.

The hdmi_setup_audio_infoframe() function has been changed, too, so
that it can be invoked without passing the substream instance.

The patch is mostly based on the work by Mengdong Lin.

Cc: Mengdong Lin <mengdong.lin@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sched/x86: Optimize switch_mm() for multi-threaded workloads

commit 8f898fbbe5ee5e20a77c4074472a1fd088dc47d1 upstream.

Dick Fowles, Don Zickus and Joe Mario have been working on
improvements to perf, and noticed heavy cache line contention
on the mm_cpumask, running linpack on a 60 core / 120 thread
system.

The cause turned out to be unnecessary atomic accesses to the
mm_cpumask. When in lazy TLB mode, the CPU is only removed from
the mm_cpumask if there is a TLB flush event.

Most of the time, no such TLB flush happens, and the kernel
skips the TLB reload. It can also skip the atomic memory
set & test.

Here is a summary of Joe's test results:

 * The __schedule function dropped from 24% of all program cycles down
   to 5.5%.

 * The cacheline contention/hotness for accesses to that bitmask went
   from being the 1st/2nd hottest - down to the 84th hottest (0.3% of
   all shared misses which is now quite cold)

 * The average load latency for the bit-test-n-set instruction in
   __schedule dropped from 10k-15k cycles down to an average of 600 cycles.

 * The linpack program results improved from 133 GFlops to 144 GFlops.
   Peak GFlops rose from 133 to 153.

Reported-by: Don Zickus <dzickus@redhat.com>
Reported-by: Joe Mario <jmario@redhat.com>
Tested-by: Joe Mario <jmario@redhat.com>
Signed-off-by: Rik van Riel <riel@redhat.com>
Reviewed-by: Paul Turner <pjt@google.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20130731221421.616d3d20@annuminas.surriel.com
[ Made the comments consistent around the modified code. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/mce: Pay no attention to 'F' bit in MCACOD when parsing 'UC' errors

commit 0ca06c0857aee11911f91621db14498496f2c2cd upstream.

The 0x1000 bit of the MCACOD field of machine check MCi_STATUS
registers is only defined for corrected errors (where it means
that hardware may be filtering errors see SDM section 15.9.2.1).

For uncorrected errors it may, or may not be set - so we should mask
it out when checking for the architecturaly defined recoverable
error signatures (see SDM 15.9.3.1 and 15.9.3.2)

Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86, amd_nb: Clarify F15h, model 30h GART and L3 support

commit 7d64ac6422092adbbdaa279ab32f9d4c90a84558 upstream.

F15h, models 0x30 and later don't have a GART. Note that. Also check
CPUID leaf 0x80000006 for L3 prescence because there are models which
don't sport an L3 cache.

Signed-off-by: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
[ Boris: rewrite commit message, cleanup comments. ]
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pci_ids: Add PCI device ID functions 3 and 4 for newer F15h models.

commit 6bdaa63c2957ac04e8d596880f732b79f9c06c3c upstream.

Add PCI device IDs for AMD F15h, model 30h. They will be used in
amd_nb.c and amd64_edac.c

Signed-off-by: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Introduce [compat_]save_altstack_ex() to unbreak x86 SMAP

commit bd1c149aa9915b9abb6d83d0f01dfd2ace0680b5 upstream.

For performance reasons, when SMAP is in use, SMAP is left open for an
entire put_user_try { ... } put_user_catch(); block, however, calling
__put_user() in the middle of that block will close SMAP as the
STAC..CLAC constructs intentionally do not nest.

Furthermore, using __put_user() rather than put_user_ex() here is bad
for performance.

Thus, introduce new [compat_]save_altstack_ex() helpers that replace
__[compat_]save_altstack() for x86, being currently the only
architecture which supports put_user_try { ... } put_user_catch().

Reported-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/n/tip-es5p6y64if71k8p5u08agv9n@git.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86, smap: Handle csum_partial_copy_*_user()

commit 7263dda41b5a28ae6566fd126d9b06ada73dd721 upstream.

Add SMAP annotations to csum_partial_copy_to/from_user().  These
functions legitimately access user space and thus need to set the AC
flag.

TODO: add explicit checks that the side with the kernel space pointer
really points into kernel space.

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/n/tip-2aps0u00eer658fd5xyanan7@git.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: mc13783: add spi errata fix

commit 9f6f0afbb9fdabf6dcac642dfec457f28981e3f8 upstream.

The MC13783 Chip Errata, Rev. 4 says, that depending on SPI clock
and main audio clock speed, the Audio Codec or Stereo DAC do sometimes
not start when programmed to do so. This is due to an internal clock
timing issue related to the loading of the SPI bits into the audio block.

On an i.MX27 based system, this issue lead to switched audio channels under
certain circumstances: RTC + Touch + Audio are used and loaded at startup.

The mentioned workaround of writing registers 40 and 41 two times is implemented
here.

Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: wm8960: Fix PLL register writes

commit 85fa532b6ef920b32598df86b194571a7059a77c upstream.

Bit 9 of PLL2,3 and 4 is reserved as '0'. The 24bit fractional part
should be split across each register in 8bit chunks.

Signed-off-by: Mike Dyer <mike.dyer@md-soft.co.uk>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rculist: list_first_or_null_rcu() should use list_entry_rcu()

commit c34ac00caefbe49d40058ae7200bd58725cebb45 upstream.

list_first_or_null() should test whether the list is empty and return
pointer to the first entry if not in a RCU safe manner.  It's broken
in several ways.

* It compares __kernel @__ptr with __rcu @__next triggering the
  following sparse warning.

  net/core/dev.c:4331:17: error: incompatible types in comparison expression (different address spaces)

* It doesn't perform rcu_dereference*() and computes the entry address
  using container_of() directly from the __rcu pointer which is
  inconsitent with other rculist interface.  As a result, all three
  in-kernel users - net/core/dev.c, macvlan, cgroup - are buggy.  They
  dereference the pointer w/o going through read barrier.

* While ->next dereference passes through list_next_rcu(), the
  compiler is still free to fetch ->next more than once and thus
  nullify the "__ptr != __next" condition check.

Fix it by making list_first_or_null_rcu() dereference ->next directly
using ACCESS_ONCE() and then use list_entry_rcu() on it like other
rculist accessors.

v2: Paul pointed out that the compiler may fetch the pointer more than
    once nullifying the condition check.  ACCESS_ONCE() added on
    ->next dereference.

v3: Restored () around macro param which was accidentally removed.
    Spotted by Paul.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Li Zefan <lizefan@huawei.com>
Cc: Patrick McHardy <kaber@trash.net>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: don't check pm qos NO_POWER_OFF flag in usb_port_suspend()

commit 98a4f1ff7bea8002ab79d6776e30d27932e88244 upstream.

The pm qos NO_POWER_OFF flag is checked twice during usb device suspend
to see if the usb port power off condition is met. This is redundant and
also will prevent the port from being powered off if the NO_POWER_OFF
flag is changed to 1 from 0 after the device was already suspended.

More detail in the following link.
http://marc.info/?l=linux-usb&m=136543949130865&w=2

This patch should be backported to kernels as old as 3.7, that
contain the commit f7ac7787ad361e31a7972e2854ed8dc2eedfac3b "usb/acpi:
Use ACPI methods to power off ports."

Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: handle LPM errors during device suspend correctly

commit aa5ceae24bf8dff1d6fe87c6c4b08e69c6d33550 upstream.

The hub driver's usb_port_suspend() routine doesn't handle errors
related to Link Power Management properly.  It always returns failure,
it doesn't try to clean up the wakeup setting, (in the case of system
sleep) it doesn't try to go ahead with the port suspend regardless,
and it doesn't try to apply the new power-off mechanism.

This patch fixes these problems.

Note: Sarah fixed this patch to apply against 3.11, since the original
commit (4fae6f0fa86f92e6bc7429371b1e177ad0aaac66 "USB: handle LPM errors
during device suspend correctly") called usb_disable_remote_wakeup,
which won't be added until 3.12.

This patch should be backported to kernels as old as 3.5, that
contain the commit 8306095fd2c1100e8244c09bf560f97aca5a311d "USB:
Disable USB 3.0 LPM in critical sections.".  There will be merge
conflicts, since LTM wasn't added until 3.6.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: config->desc.bLength may not exceed amount of data returned by the device

commit b4f17a488ae2e09bfcf95c0e0b4219c246f1116a upstream.

While reading the config parsing code I noticed this check is missing, without
this check config->desc.wTotalLength can end up with a value larger then the
dev->rawdescriptors length for the config, and when userspace then tries to
get the rawdescriptors bad things may happen.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: fix build error when CONFIG_PM_SLEEP isn't enabled

commit 9d8924297cd9c256c23c02abae40202563452453 upstream.

This patch fixes a build error that occurs when CONFIG_PM is enabled
and CONFIG_PM_SLEEP isn't:

>> drivers/usb/host/ohci-pci.c:294:10: error: 'usb_hcd_pci_pm_ops' undeclared here (not in a function)
      .pm = &usb_hcd_pci_pm_ops

Since the usb_hcd_pci_pm_ops structure is defined and used when
CONFIG_PM is enabled, its declaration should not be protected by
CONFIG_PM_SLEEP.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: Don't fail port power resume on device disconnect.

commit d49dad3e11638f66be4e16573ffaa8c46a09e3b3 upstream.

Userspace can tell the kernel to power off any USB port, including ones
that are visible and connectible to users.  When an attached USB device
goes into suspend, the port will be powered off if the
pm_qos_no_port_poweroff file for its port is set to 0, the device does
not have remote wakeup enabled, and the device is marked as persistent.

If the user disconnects the USB device while the port is powered off,
the current code does not handle that properly.  If you disconnect a
device, and then run `lsusb -v -s` for the device, the device disconnect
does not get handled by the USB core.  The runtime resume of the port
fails, because hub_port_debounce_be_connected() returns -ETIMEDOUT.

This means the port resume fails and khubd doesn't handle the USB device
disconnect.  This leaves the device listed in lsusb, and the port's
runtime_status will be permanently marked as "error".

Fix this by ignoring the return value of hub_port_debounce_be_connected.
Users can disconnect USB devices while the ports are powered off, and we
must be able to handle that.

This patch should be backported to kernels as old as 3.9, that
contain the commit ad493e5e580546e6c3024b76a41535476da1546a "usb: add
usb port auto power off mechanism"

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Lan Tianyu <tianyu.lan@intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: uvc: Fix error handling in uvc_queue_buffer()

commit ebe864a6cb8e087ede047fa1fa6b6d06fcb9a9e4 upstream.

The conversion to videobuf2 failed to check the return value of
vb2_qbuf(). Fix it.

Reported-by: Michael Grzeschik <mgr@pengutronix.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-By: Michael Grzeschik <mgr@pengutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: cdc-wdm: fix race between interrupt handler and tasklet

commit 6dd433e6cf2475ce8abec1b467720858c24450eb upstream.

Both could want to submit the same URB. Some checks of the flag
intended to prevent that were missing.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: ehci-mxc: check for pdata before dereferencing

commit f375fc520d4df0cd9fcb570f33c103c6c0311f9e upstream.

Commit 7e8d5cd93fac ("USB: Add EHCI support for MX27 and MX31 based
boards") introduced code that could potentially lead to a NULL pointer
dereference on driver removal.

Fix this by checking for the value of pdata before dereferencing it.

Signed-off-by: Daniel Mack <zonque@gmail.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: mos7720: fix big-endian control requests

commit 3b716caf190ccc6f2a09387210e0e6a26c1d81a4 upstream.

Fix endianess bugs in parallel-port code which caused corrupt
control-requests to be issued on big-endian machines.

Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: mos7720: use GFP_ATOMIC under spinlock

commit d0bd9a41186e076ea543c397ad8a67a6cf604b55 upstream.

The write_parport_reg_nonblock() function shouldn't sleep because it's
called with spinlocks held.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ACPI / LPSS: don't crash if a device has no MMIO resources

commit af65cfe9aeae03e0682bebdf4db94582d75562dd upstream.

Intel LPSS devices that are enumerated from ACPI have both MMIO and IRQ
resources returned in their _CRS method. However, Apple Macbook Air with
Haswell has LPSS devices enumerated from PCI bus instead and _CRS method
returns only an interrupt number (but the device has _HID set that causes
the scan handler to match it).

The current ACPI / LPSS code sets pdata->dev_desc only when MMIO resource
is found for the device and in case of Macbook Air it is never found. That
leads to a NULL pointer dereference in register_device_clock().

Correct this by always setting the pdata->dev_desc.

Reported-and-tested-by: Imre Kaloz <kaloz@openwrt.org>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI/ACPI: Fix _OSC ordering to allow PCIe hotplug use when available

commit 3dc48af310709b85d07c8b0d3aa8f1ead02829d3 upstream.

This fixes the problem of acpiphp claiming slots that should be managed
by pciehp, which may keep ExpressCard slots from working.

The acpiphp driver claims PCIe slots unless the BIOS has granted us
control of PCIe native hotplug via _OSC.  Prior to v3.10, the acpiphp
.add method (add_bridge()) was always called *after* we had requested
native hotplug control with _OSC.

But after 3b63aaa70e ("PCI: acpiphp: Do not use ACPI PCI subdriver
mechanism"), which appeared in v3.10, acpiphp initialization is done
during the bus scan via the pcibios_add_bus() hook, and this happens
*before* we request native hotplug control.

Therefore, acpiphp doesn't know yet whether the BIOS will grant control,
and it claims slots that we should be handling with native hotplug.

This patch requests native hotplug control earlier, so we know whether
the BIOS granted it to us before we initialize acpiphp.

To avoid reintroducing the ASPM issue fixed by b8178f130e ('Revert
"PCI/ACPI: Request _OSC control before scanning PCI root bus"'), we run
_OSC earlier but defer the actual ASPM calls until after the bus scan is
complete.

Tested successfully by myself.

[bhelgaas: changelog, mark for stable]
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=60736
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
CC: Len Brown <lenb@kernel.org>
CC: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: comedi: dt282x: dt282x_ai_insn_read() always fails

commit 2c4283ca7cdcc6605859c836fc536fcd83a4525f upstream.

In dt282x_ai_insn_read() we call this macro like:
wait_for(!mux_busy(), comedi_error(dev, "timeout\n"); return -ETIME;);
Because the if statement doesn't have curly braces it means we always
return -ETIME and the function never succeeds.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

regmap: debugfs: Fix continued read from registers file

commit 26ee47411ae22caa07d3f3b63ca6d097cba6681b upstream.

The regmap_debugfs_get_dump_start() function maps from a file offset to the
register that can be found at that position in the file. This is done using a
look-up table. Commit d6814a7d ("regmap: debugfs: Suppress cache for partial
register files") added a check to bypass the look-up table for partial register
files, since the offsets in that table are only correct for the full register
file. The check incorrectly uses the file offset instead of the register base
address and returns it. This will cause the file offset to be interpreted as a
register address which will result in a incorrect output from the registers file
for all reads except at position 0.

The issue can easily be reproduced by doing small reads the registers file, e.g.
`dd if=registers bs=10 count=5`.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: OHCI: Allow runtime PM without system sleep

commit 69820e01aa756b8d228143d997f71523c1e97984 upstream.

Since ohci-hcd supports runtime PM, the .pm field in its pci_driver
structure should be protected by CONFIG_PM rather than
CONFIG_PM_SLEEP.

Without this change, OHCI controllers won't do runtime suspend if
system suspend or hibernation isn't enabled.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

CIFS: Fix missing lease break

commit 933d4b36576c951d0371bbfed05ec0135d516a6e upstream.

If a server sends a lease break to a connection that doesn't have
opens with a lease key specified in the server response, we can't
find an open file to send an ack. Fix this by walking through
all connections we have.

Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

CIFS: Fix a memory leak when a lease break comes

commit 1a05096de82f3cd672c76389f63964952678506f upstream.

This happens when we receive a lease break from a server, then
find an appropriate lease key in opened files and schedule the
oplock_break slow work. lw pointer isn't freed in this case.

Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cifs: ensure that srv_mutex is held when dealing with ssocket pointer

commit 73e216a8a42c0ef3d08071705c946c38fdbe12b0 upstream.

Oleksii reported that he had seen an oops similar to this:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
IP: [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
PGD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: ipt_MASQUERADE xt_REDIRECT xt_tcpudp iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables carl9170 ath usb_storage f2fs nfnetlink_log nfnetlink md4 cifs dns_resolver hid_generic usbhid hid af_packet uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev rfcomm btusb bnep bluetooth qmi_wwan qcserial cdc_wdm usb_wwan usbnet usbserial mii snd_hda_codec_hdmi snd_hda_codec_realtek iwldvm mac80211 coretemp intel_powerclamp kvm_intel kvm iwlwifi snd_hda_intel cfg80211 snd_hda_codec xhci_hcd e1000e ehci_pci snd_hwdep sdhci_pci snd_pcm ehci_hcd microcode psmouse sdhci thinkpad_acpi mmc_core i2c_i801 pcspkr usbcore hwmon snd_timer snd_page_alloc snd ptp rfkill pps_core soundcore evdev usb_common vboxnetflt(O) vboxdrv(O)Oops#2 Part8
 loop tun binfmt_misc fuse msr acpi_call(O) ipv6 autofs4
CPU: 0 PID: 21612 Comm: kworker/0:1 Tainted: G        W  O 3.10.1SIGN #28
Hardware name: LENOVO 2306CTO/2306CTO, BIOS G2ET92WW (2.52 ) 02/22/2013
Workqueue: cifsiod cifs_echo_request [cifs]
task: ffff8801e1f416f0 ti: ffff880148744000 task.ti: ffff880148744000
RIP: 0010:[<ffffffff814dcc13>]  [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
RSP: 0000:ffff880148745b00  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff880148745b78 RCX: 0000000000000048
RDX: ffff880148745c90 RSI: ffff880181864a00 RDI: ffff880148745b78
RBP: ffff880148745c48 R08: 0000000000000048 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff880181864a00
R13: ffff880148745c90 R14: 0000000000000048 R15: 0000000000000048
FS:  0000000000000000(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000088 CR3: 000000020c42c000 CR4: 00000000001407b0
Oops#2 Part7
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Stack:
 ffff880148745b30 ffffffff810c4af9 0000004848745b30 ffff880181864a00
 ffffffff81ffbc40 0000000000000000 ffff880148745c90 ffffffff810a5aab
 ffff880148745bc0 ffffffff81ffbc40 ffff880148745b60 ffffffff815a9fb8
Call Trace:
 [<ffffffff810c4af9>] ? finish_task_switch+0x49/0xe0
 [<ffffffff810a5aab>] ? lock_timer_base.isra.36+0x2b/0x50
 [<ffffffff815a9fb8>] ? _raw_spin_unlock_irqrestore+0x18/0x40
 [<ffffffff810a673f>] ? try_to_del_timer_sync+0x4f/0x70
 [<ffffffff815aa38f>] ? _raw_spin_unlock_bh+0x1f/0x30
 [<ffffffff814dcc87>] kernel_sendmsg+0x37/0x50
 [<ffffffffa081a0e0>] smb_send_kvec+0xd0/0x1d0 [cifs]
 [<ffffffffa081a263>] smb_send_rqst+0x83/0x1f0 [cifs]
 [<ffffffffa081ab6c>] cifs_call_async+0xec/0x1b0 [cifs]
 [<ffffffffa08245e0>] ? free_rsp_buf+0x40/0x40 [cifs]
Oops#2 Part6
 [<ffffffffa082606e>] SMB2_echo+0x8e/0xb0 [cifs]
 [<ffffffffa0808789>] cifs_echo_request+0x79/0xa0 [cifs]
 [<ffffffff810b45b3>] process_one_work+0x173/0x4a0
 [<ffffffff810b52a1>] worker_thread+0x121/0x3a0
 [<ffffffff810b5180>] ? manage_workers.isra.27+0x2b0/0x2b0
 [<ffffffff810bae00>] kthread+0xc0/0xd0
 [<ffffffff810bad40>] ? kthread_create_on_node+0x120/0x120
 [<ffffffff815b199c>] ret_from_fork+0x7c/0xb0
 [<ffffffff810bad40>] ? kthread_create_on_node+0x120/0x120
Code: 84 24 b8 00 00 00 4c 89 f1 4c 89 ea 4c 89 e6 48 89 df 4c 89 60 18 48 c7 40 28 00 00 00 00 4c 89 68 30 44 89 70 14 49 8b 44 24 28 <ff> 90 88 00 00 00 3d ef fd ff ff 74 10 48 8d 65 e0 5b 41 5c 41
 RIP  [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
 RSP <ffff880148745b00>
CR2: 0000000000000088

The client was in the middle of trying to send a frame when the
server->ssocket pointer got zeroed out. In most places, that we access
that pointer, the srv_mutex is held. There's only one spot that I see
that the server->ssocket pointer gets set and the srv_mutex isn't held.
This patch corrects that.

The upstream bug report was here:

    https://bugzilla.kernel.org/show_bug.cgi?id=60557

Reported-by: Oleksii Shevchuk <alxchk@gmail.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tty: disassociate_ctty() sends the extra SIGCONT

commit 03e1261778cca782d41a3d8e3945ca88cf93e01e upstream.

Starting from v3.10 (probably commit f91e2590410b: "tty: Signal
foreground group processes in hangup") disassociate_ctty() sends SIGCONT
if tty && on_exit.  This breaks LSB test-suite, in particular test8 in
_exit.c and test40 in sigcon5.c.

Put the "!on_exit" check back to restore the old behaviour.

Review by Peter Hurley:
 "Yes, this regression was introduced by me in that commit.  The effect
  of the regression is that ptys will receive a SIGCONT when, in similar
  circumstances, ttys would not.

  The fact that two test vectors accidentally tripped over this
  regression suggests that some other apps may as well.

  Thanks for catching this"

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Karel Srot <ksrot@redhat.com>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: gadget: don't request IRQs in atomic

commit b0d7ffd44ba9cd2dfbf299674418193a5f9ed21a upstream.

We cannot request an IRQ with spinlocks held
as that would trigger a sleeping inside
spinlock warning.

Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci: fix port BESL LPM capability checking

commit dcf06a036848b4e8e6c8220f2e00b9adf6f84918 upstream.

Wrong capability bit was checked for best effort service latency.
bit 20 indicate port is BESL LPM capable (BLC),
bit 19 is hardware LPM capable (HLC)

This patch should be backported to kernels as old as 3.11, that
contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci:
add USB2 Link power management BESL support"

Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Steve Cotton <steve@s.cotton.clara.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: xhci: Disable runtime PM suspend for quirky controllers

commit c8476fb855434c733099079063990e5bfa7ecad6 upstream.

If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
a reset will be performed upon runtime resume. Any previously suspended
devices attached to the controller will be re-enumerated at this time.
This will cause problems, for example, if an open system call on the
device triggered the resume (the open call will fail).

Note that this change is only relevant when persist_enabled is not set
for USB devices.

This patch should be backported to kernels as old as 3.0, that
contain the commit c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9 "xhci: Add
reset on resume quirk for asrock p67 host".

Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci-plat: Don't enable legacy PCI interrupts.

commit 52fb61250a7a132b0cfb9f4a1060a1f3c49e5a25 upstream.

The xHCI platform driver calls into usb_add_hcd to register the irq for
its platform device.  It does not want the xHCI generic driver to
register an interrupt for it at all.  The original code did that by
setting the XHCI_BROKEN_MSI quirk, which tells the xHCI driver to not
enable MSI or MSI-X for a PCI host.

Unfortunately, if CONFIG_PCI is enabled, and CONFIG_USB_DW3 is enabled,
the xHCI generic driver will attempt to register a legacy PCI interrupt
for the xHCI platform device in xhci_try_enable_msi().  This will result
in a bogus irq being registered, since the underlying device is a
platform_device, not a pci_device, and thus the pci_device->irq pointer
will be bogus.

Add a new quirk, XHCI_PLAT, so that the xHCI generic driver can
distinguish between a PCI device that can't handle MSI or MSI-X, and a
platform device that should not have its interrupts touched at all.
This quirk may be useful in the future, in case other corner cases like
this arise.

This patch should be backported to kernels as old as 3.9, that
contain the commit 00eed9c814cb8f281be6f0f5d8f45025dc0a97eb "USB: xhci:
correctly enable interrupts".

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Yu Y Wang <yu.y.wang@intel.com>
Tested-by: Yu Y Wang <yu.y.wang@intel.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: PPC: Book3S: Fix compile error in XICS emulation

commit 7bfa9ad55d691f2b836b576769b11eca2cf50816 upstream.

Commit 8e44ddc3f3 ("powerpc/kvm/book3s: Add support for H_IPOLL and
H_XIRR_X in XICS emulation") added a call to get_tb() but didn't
include the header that defines it, and on some configs this means
book3s_xics.c fails to compile:

arch/powerpc/kvm/book3s_xics.c: In function ‘kvmppc_xics_hcall’:
arch/powerpc/kvm/book3s_xics.c:812:3: error: implicit declaration of function ‘get_tb’ [-Werror=implicit-function-declaration]

Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: PCI: versatile: Fix SMAP register offsets

commit 99f2b130370b904ca5300079243fdbcafa2c708b upstream.

The SMAP register offsets in the versatile PCI controller code were
all off by four.  (This didn't have any observable bad effects
because on this board PHYS_OFFSET is zero, and (a) writing zero to
the flags register at offset 0x10 has no effect and (b) the reset
value of the SMAP register is zero anyway, so failing to write SMAP2
didn't matter.)

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: PCI: versatile: Fix PCI I/O

commit 829f9fedee30cde2ec15e88d57ec11074db791e2 upstream.

The versatile PCI controller code was confused between the
PCI I/O window (at 0x43000000) and the first PCI memory
window (at 0x44000000). Pass the correct base address to
pci_remap_io() so that PCI I/O accesses work.

Since the first PCI memory window isn't used at all (it's
an odd size), rename the associated variables and labels
so that it's clear that it isn't related to the I/O window.

This has been tested and confirmed to fix PCI I/O accesses
both on physical PB926+PCI backplane hardware and on QEMU.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: PCI: versatile: Fix map_irq function to match hardware

commit f9b71fef12f0d6ac5c7051cfd87f7700f78c56b6 upstream.

The PCI controller code for the Versatile board has never had the
correct IRQ mapping for hardware.  For many years it had an odd
mapping ("all interrupts are int 27") which aligned with the
equivalent bug in QEMU.  However as of commit 1bc39ac5dab265
the mapping changed and no longer matched either hardware or QEMU,
with the result that any PCI card beyond the first in QEMU would
not have functioning interrupts; for example a boot with a SCSI
controller would time out as follows:

 ------------
 sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92
 sym0: SCSI BUS has been reset.
 scsi0 : sym-2.2.3
 [...]
 scsi 0:0:0:0: ABORT operation started
 scsi 0:0:0:0: ABORT operation timed-out.
 scsi 0:0:0:0: DEVICE RESET operation started
 scsi 0:0:0:0: DEVICE RESET operation timed-out.
 scsi 0:0:0:0: BUS RESET operation started
 scsi 0:0:0:0: BUS RESET operation timed-out.
 scsi 0:0:0:0: HOST RESET operation started
 sym0: SCSI BUS has been reset
 ------------

Fix the mapping so that it matches real hardware (checked against the
schematics for PB926 and backplane, and tested against the hardware).
This allows PCI cards using interrupts to work on hardware for the
first time; this change will also work with QEMU 1.5 or later, where
the equivalent bugs in the modelling of the hardware have been fixed.

Although QEMU will attempt to autodetect whether the kernel is
expecting the long-standing "everything is int 27" mapping or the one
hardware has, for certainty we force it into "definitely behave like
hardware mode"; this will avoid unexpected surprises later if we
implement sparse irqs. This is harmless on hardware.

Thanks to Paul Gortmaker for bisecting the problem and finding an initial
solution, to Russell King for providing the correct interrupt mapping,
and to Guenter Roeck for providing an initial version of this patch
and prodding me into relocating the hardware and retesting everything.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: perf: fix ARMv8 EVTYPE_MASK to include NSH bit

commit 178cd9ce377232518ec17ff2ecab2e80fa60784c upstream.

This is a port of f2fe09b055e2 ("ARM: 7663/1: perf: fix ARMv7 EVTYPE_MASK
to include NSH bit") to arm64, which fixes the broken evtype mask to
include the NSH bit, allowing profiling at EL2.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: perf: fix group validation when using enable_on_exec

commit 8455e6ec70f33b0e8c3ffd47067e00481f09f454 upstream.

This is a port of cb2d8b342aa0 ("ARM: 7698/1: perf: fix group validation
when using enable_on_exec") to arm64, which fixes the event validation
checking so that events in the OFF state are still considered when
enable_on_exec is true.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cpuidle: coupled: fix race condition between pokes and safe state

commit 9e19b73c30a5fa42a53583a1f7817dd857126156 upstream.

The coupled cpuidle waiting loop clears pending pokes before
entering the safe state.  If a poke arrives just before the
pokes are cleared, but after the while loop condition checks,
the poke will be lost and the cpu will stay in the safe state
until another interrupt arrives.  This may cause the cpu that
sent the poke to spin in the ready loop with interrupts off
until another cpu receives an interrupt, and if no other cpus
have interrupts routed to them it can spin forever.

Change the return value of cpuidle_coupled_clear_pokes to
return if a poke was cleared, and move the need_resched()
checks into the callers.  In the waiting loop, if
a poke was cleared restart the loop to repeat the while
condition checks.

Reported-by: Neil Zhang <zhangwm@marvell.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cpuidle: coupled: abort idle if pokes are pending

commit f983827bcb9d2c34c4d8935861a1e9128aec2baf upstream.

Joseph Lo <josephl@nvidia.com> reported a lockup on Tegra20 caused
by a race condition in coupled cpuidle.  When two or more cpus
enter idle at the same time, the first cpus to arrive may go to the
ready loop without processing pending pokes from the last cpu to
arrive.

This patch adds a check for pending pokes once all cpus have been
synchronized in the ready loop and resets the coupled state and
retries if any cpus failed to handle their pending poke.

Retrying on all cpus may trigger the same issue again, so this patch
also adds a check to ensure that each cpu has received at least one
poke between when it enters the waiting loop and when it moves on to
the ready loop.

Reported-and-tested-by: Joseph Lo <josephl@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: xen: only set pm function ptrs for Xen guests

commit 9dd4b2944c46e1fdbd0a516c221c8a2670cbf005 upstream.

xen_pm_init was unconditionally setting pm_power_off and arm_pm_restart
function pointers. This breaks multi-platform kernels. Make this
conditional on running as a Xen guest and make it a late_initcall to
ensure it is setup after platform code for Dom0.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xen-gnt: prevent adding duplicate gnt callbacks

commit 5f338d9001094a56cf87bd8a280b4e7ff953bb59 upstream.

With the current implementation, the callback in the tail of the list
can be added twice, because the check done in
gnttab_request_free_callback is bogus, callback->next can be NULL if
it is the last callback in the list. If we add the same callback twice
we end up with an infinite loop, were callback == callback->next.

Replace this check with a proper one that iterates over the list to
see if the callback has already been added.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Matt Wilson <msw@amazon.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

powerpc: Default arch idle could cede processor on pseries

commit 363edbe2614aa90df706c0f19ccfa2a6c06af0be upstream.

When adding cpuidle support to pSeries, we introduced two
regressions:

  - The new cpuidle backend driver only works under hypervisors
    supporting the "SLPLAR" option, which isn't the case of the
    old POWER4 hypervisor and the HV "light" used on js2x blades

  - The cpuidle driver registers fairly late, meaning that for
    a significant portion of the boot process, we end up having
    all threads spinning. This slows down the boot process and
    increases the overall resource usage if the hypervisor has
    shared processors.

This fixes both by implementing a "default" idle that will cede
to the hypervisor when possible, in a very simple way without
all the bells and whisles of cpuidle.

Reported-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Acked-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

powerpc: Handle unaligned ldbrx/stdbrx

commit 230aef7a6a23b6166bd4003bfff5af23c9bd381f upstream.

Normally when we haven't implemented an alignment handler for
a load or store instruction the process will be terminated.

The alignment handler uses the DSISR (or a pseudo one) to locate
the right handler. Unfortunately ldbrx and stdbrx overlap lfs and
stfs so we incorrectly think ldbrx is an lfs and stdbrx is an
stfs.

This bug is particularly nasty - instead of terminating the
process we apply an incorrect fixup and continue on.

With more and more overlapping instructions we should stop
creating a pseudo DSISR and index using the instruction directly,
but for now add a special case to catch ldbrx/stdbrx.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

s390/bpf,jit: fix address randomization

commit 4784955a5270f30c569fa95899979fd1805caf6c upstream.

Add misssing braces to hole calculation. This resulted in an addition
instead of an substraction. Which in turn means that the jit compiler
could try to write out of bounds of the allocated piece of memory.

This bug was introduced with aa2d2c73 "s390/bpf,jit: address randomize
and write protect jit code".

Fixes this one:

[   37.320956] Unable to handle kernel pointer dereference at virtual kernel address 000003ff80231000
[   37.320984] Oops: 0011 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[   37.320993] Modules linked in: dm_multipath scsi_dh eadm_sch dm_mod ctcm fsm autofs4
[   37.321007] CPU: 28 PID: 6443 Comm: multipathd Not tainted 3.10.9-61.x.20130829-s390xdefault #1
[   37.321011] task: 0000004ada778000 ti: 0000004ae3304000 task.ti: 0000004ae3304000
[   37.321014] Krnl PSW : 0704c00180000000 000000000012d1de (bpf_jit_compile+0x198e/0x23d0)
[   37.321022]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
               Krnl GPRS: 000000004350207d 0000004a00000001 0000000000000007 000003ff80231002
[   37.321029]            0000000000000007 000003ff80230ffe 00000000a7740000 000003ff80230f76
[   37.321032]            000003ffffffffff 000003ff00000000 000003ff0000007d 000000000071e820
[   37.321035]            0000004adbe99950 000000000071ea18 0000004af3d9e7c0 0000004ae3307b80
[   37.321046] Krnl Code: 000000000012d1d0: 41305004            la      %r3,4(%r5)
                          000000000012d1d4: e330f0f80021        clg     %r3,248(%r15)
                         #000000000012d1da: a7240009            brc     2,12d1ec
                         >000000000012d1de: 50805000            st      %r8,0(%r5)
                          000000000012d1e2: e330f0f00004        lg      %r3,240(%r15)
                          000000000012d1e8: 41303004            la      %r3,4(%r3)
                          000000000012d1ec: e380f0e00004        lg      %r8,224(%r15)
                          000000000012d1f2: e330f0f00024        stg     %r3,240(%r15)
[   37.321074] Call Trace:
[   37.321077] ([<000000000012da78>] bpf_jit_compile+0x2228/0x23d0)
[   37.321083]  [<00000000006007c2>] sk_attach_filter+0xfe/0x214
[   37.321090]  [<00000000005d2d92>] sock_setsockopt+0x926/0xbdc
[   37.321097]  [<00000000005cbfb6>] SyS_setsockopt+0x8a/0xe8
[   37.321101]  [<00000000005ccaa8>] SyS_socketcall+0x264/0x364
[   37.321106]  [<0000000000713f1c>] sysc_nr_ok+0x22/0x28
[   37.321113]  [<000003fffce10ea8>] 0x3fffce10ea8
[   37.321118] INFO: lockdep is turned off.
[   37.321121] Last Breaking-Event-Address:
[   37.321124]  [<000000000012d192>] bpf_jit_compile+0x1942/0x23d0
[   37.321132]
[   37.321135] Kernel panic - not syncing: Fatal exception: panic_on_oops

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: api - Fix race condition in larval lookup

commit 77dbd7a95e4a4f15264c333a9e9ab97ee27dc2aa upstream.

crypto_larval_lookup should only return a larval if it created one.
Any larval created by another entity must be processed through
crypto_larval_wait before being returned.

Otherwise this will lead to a larval being killed twice, which
will most likely lead to a crash.

Reported-by: Kees Cook <keescook@chromium.org>
Tested-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

SCSI: sd: Fix potential out-of-bounds access

commit 984f1733fcee3fbc78d47e26c5096921c5d9946a upstream.

This patch fixes an out-of-bounds error in sd_read_cache_type(), found
by Google's AddressSanitizer tool.  When the loop ends, we know that
"offset" lies beyond the end of the data in the buffer, so no Caching
mode page was found.  In theory it may be present, but the buffer size
is limited to 512 bytes.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

UBI: Fix PEB leak in wear_leveling_worker()

commit 5ef4414f4bc26a19cfd5cd11aee9697a863e4d51 upstream.

get_peb_for_wl() removes the PEB from the free list.
If the WL subsystem detects that no wear leveling is needed
it cancels the operation and drops the gained PEB.
In this case we have to put the PEB back into the free list.

This issue was introduced with commit ed4b7021c
(UBI: remove PEB from free tree in get_peb_for_wl()).

Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

zram: don't grab mutex in zram_slot_free_noity

commit a0c516cbfc7452c8cbd564525fef66d9f20b46d1 upstream.

[1] introduced down_write in zram_slot_free_notify to prevent race
between zram_slot_free_notify and zram_bvec_[read|write]. The race
could happen if somebody who has right permission to open swap device
is reading swap device while it is used by swap in parallel.

However, zram_slot_free_notify is called with holding spin_lock of
swap layer so we shouldn't avoid holing mutex. Otherwise, lockdep
warns it.

This patch adds new list to handle free slot and workqueue
so zram_slot_free_notify just registers slot index to be freed and
registers the request to workqueue. If workqueue is expired,
it holds mutex_lock so there is no problem any more.

If any I/O is issued, zram handles pending slot-free request
caused by zram_slot_free_notify right before handling issued
request because workqueue wouldn't be expired yet so zram I/O
request handling function can miss it.

Lastly, when zram is reset, flush_work could handle all of pending
free request so we shouldn't have memory leak.

NOTE: If zram_slot_free_notify's kmalloc with GFP_ATOMIC would be
failed, the slot will be freed when next write I/O write the slot.

[1] [57ab0485, zram: use zram->lock to protect zram_free_page()
    in swap free notify path]

* from v2
  * refactoring

* from v1
  * totally redesign

Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

zram: fix invalid memory access

commit 2b86ab9cc29fcd435cde9378c3b9ffe8b5c76128 upstream.

[1] tried to fix invalid memory access on zram->disk but it didn't
fix properly because get_disk failed during module exit path.

Actually, we don't need to reset zram->disk's capacity to zero
in module exit path so that this patch introduces new argument
"reset_capacity" on zram_reset_divice and it only reset it when
reset_store is called.

[1] 6030ea9b,  zram: avoid invalid memory access in zram_exit()

Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

firmware loader: fix pending_fw_head list corruption

commit 1eeeef153c02f5856ec109fa532eb5f31c39f85c upstream.

Got the following oops just before reboot:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
[<8028d300>] (__list_del_entry+0x44/0xac)
[<802e3320>] (__fw_load_abort.part.13+0x1c/0x50)
[<802e337c>] (fw_shutdown_notify+0x28/0x50)
[<80034f80>] (notifier_call_chain.isra.1+0x5c/0x9c)
[<800350ec>] (__blocking_notifier_call_chain+0x44/0x58)
[<80035114>] (blocking_notifier_call_chain+0x14/0x18)
[<80035d64>] (kernel_restart_prepare+0x14/0x38)
[<80035d94>] (kernel_restart+0xc/0x50)

The following race condition triggers here:

  _request_firmware_load()
  device_create_file(...)
  kobject_uevent(...)
  (schedule)
                                       (resume)
                                       firmware_loading_store(1)
                                       firmware_loading_store(0)
                                       list_del_init(&buf->pending_list)
                                       (schedule)
  (resume)
  list_add(&buf->pending_list, &pending_fw_head);
  wait_for_completion(&buf->completion);

causing an oops later when walking pending_list after the firmware has
been released.

The proposed fix is to move the list_add() before sysfs attribute
creation.

Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
Acked-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915: make user mode sync polarity setting explicit

commit 2960bc9cceecb5d556ce1c07656a6609e2f7e8b0 upstream.

Userspace can pass a mode with an unspecified vsync/hsync polarity
setting. All encoders in the Intel driver take this to mean a negative
polarity setting. The HW readout/state checker code on the other hand
needs these flags to be explicitly set, otherwise the state checker will
WARN about the mismatch.

Get rid of the WARN by making the polarity setting explicit in the
adjusted mode flags based on the requested mode flags. This will keep
the existing behavior otherwise.

Note that we could guess from the other timing parameters whether the
user wanted a VESA or other standard mode and set the polarity
accordingly. This is what the NV driver does
(drivers/gpu/drm/nouveau/dispnv04/crtc.c), but I think that's not very
exact and would change the existing behavior of the Intel driver.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65442
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: cancan,feng <cancan.feng@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

SCSI: Allow MPT Fusion SAS 3.0 driver to be built into the kernel

commit 9807b4d94911be4e4efb9a08481b24292a9edf8a upstream.

Right now the Makefile for the mpt3sas driver does not even allow the
driver to be built into the kernel.  So fix that up, as there doesn't
seem to be any obvious reason why this shouldn't be done.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sreekanth Reddy <Sreekanth.Reddy@lsi.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

xtensa: Fix broken allmodconfig build

commit 8872366df396444d7655287c79ed182d8f47cba6 upstream.

xtansa allmodbuild fails with:

arch/xtensa/kernel/xtensa_ksyms.c:129:1: error: '_mcount' undeclared here (not in a function)
make[2]: *** [arch/xtensa/kernel/xtensa_ksyms.o] Error 1
make[1]: *** [arch/xtensa/kernel] Error 2

The breakage is due to commit 478ba61af (xtensa: add static function tracer
support) which exports _mcount without declaring it.

Cc: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ipc/msg.c: Fix lost wakeup in msgsnd().

commit bebcb928c820d0ee83aca4b192adc195e43e66a2 upstream.

The check if the queue is full and adding current to the wait queue of
pending msgsnd() operations (ss_add()) must be atomic.

Otherwise:
 - the thread that performs msgsnd() finds a full queue and decides to
   sleep.
 - the thread that performs msgrcv() first reads all messages from the
   queue and then sleeps, because the queue is empty.
 - the msgrcv() calls do not perform any wakeups, because the msgsnd()
   task has not yet called ss_add().
 - then the msgsnd()-thread first calls ss_add() and then sleeps.

Net result: msgsnd() and msgrcv() both sleep forever.

Observed with msgctl08 from ltp with a preemptible kernel.

Fix: Call ipc_lock_object() before performing the check.

The patch also moves security_msg_queue_msgsnd() under ipc_lock_object:
 - msgctl(IPC_SET) explicitely mentions that it tries to expunge any
   pending operations that are not allowed anymore with the new
   permissions.  If security_msg_queue_msgsnd() is called without locks,
   then there might be races.
 - it makes the patch much simpler.

Reported-and-tested-by: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Acked-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARC: SMP failed to boot due to missing IVT setup

commit c3567f8a359b7917dcffa442301f88ed0a75211f upstream.

Commit 05b016ecf5e7a "ARC: Setup Vector Table Base in early boot" moved
the Interrupt vector Table setup out of arc_init_IRQ() which is called
for all CPUs, to entry point of boot cpu only, breaking booting of others.

Fix by adding the same to entry point of non-boot CPUs too.

read_arc_build_cfg_regs() printing IVT Base Register didn't help the
casue since it prints a synthetic value if zero which is totally bogus,
so fix that to print the exact Register.

[vgupta: Remove the now stale comment from header of arc_init_IRQ and
also added the commentary for halt-on-reset]

Cc: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Noam Camus <noamc@ezchip.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Linux 3.11.1

mwifiex: do not create AP and P2P interfaces upon driver loading

commit 1211c961170cedb21c30d5bb7e2033c8720b38db upstream.

Bug 60747 - 1286:2044 [Microsoft Surface Pro]
    Marvell 88W8797 wifi show 3 interface under network
https://bugzilla.kernel.org/show_bug.cgi?id=60747

This issue was also reported previously by OLPC and some folks from
the community.

There are 3 network interfaces with different types being created
when mwifiex driver is loaded:

1. mlan0 (infra. STA)
2. uap0 (AP)
3. p2p0 (P2P_CLIENT)

The Network Manager attempts to use all 3 interfaces above without
filtering the managed interface type. As the result, 3 identical
interfaces are displayed under network manager. If user happens to
click on an entry under which its interface is uap0 or p2p0, the
association will fail.

Work around it by removing the creation of AP and P2P interfaces
at driver loading time. These interfaces can be added with 'iw' or
other applications manually when they are needed.

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drivers/rtc/rtc-max77686.c: Fix wrong register

commit 1748cbf7f7c464593232cde914f5a103181a83b5 upstream.

Fix a read of the wrong register when checking whether the RTC timer has
reached the alarm time.

Signed-off-by: Sangjung Woo <sangjung.woo@samsung.com>
Signed-off-by: Myugnjoo Ham <myungjoo.ham@samsung.com>
Reviewed-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: xor - Check for osxsave as well as avx in crypto/xor

commit edb6f29464afc65fc73767540b854abf63ae7144 upstream.

This affects xen pv guests with sufficiently old versions of xen and
sufficiently new hardware.  On such a system, a guest with a btrfs
root won't even boot.

Signed-off-by: John Haxby <john.haxby@oracle.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Reported-by: Michael Marineau <michael.marineau@coreos.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

imx-drm: imx-drm-core: Export imx_drm_encoder_get_mux_id

commit ea8d15832016b0d07a8121159904e6b1d21b5b8b upstream.

When building imx_v6_v7_defconfig with imx-drm drivers selected as modules, we
get the following build error:

ERROR: "imx_drm_encoder_get_mux_id" [drivers/staging/imx-drm/imx-ldb.ko] undefined!

Export the required function to avoid this problem.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: fsl: Fix module build

commit 3f1a91aa25579ba5e7268a47a73d2a83e4802c62 upstream.

Building imx_v6_v7_defconfig with all audio drivers as modules results in
the folowing build error:

ERROR: "imx_pcm_fiq_init" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
ERROR: "imx_pcm_dma_init" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
ERROR: "imx_pcm_fiq_exit" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
ERROR: "imx_pcm_dma_exit" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
ERROR: "imx_pcm_dma_init" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined!
ERROR: "imx_pcm_dma_exit" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined!

Fix this by allowing SND_SOC_IMX_PCM_FIQ and SND_SOC_IMX_PCM_DMA to be also
built as modules and by using 'IS_ENABLED' to cover the module case.

Reported-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
[Guenter Roeck: back-ported to 3.11]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drivers/misc/hpilo: Correct panic when an AUX iLO is detected

commit eefbc594abbb1b7e6e7eeadb65ae7c7538474210 upstream.

 Using an uninitialized variable 'devnum' after 'goto out;' was causing
 panic.  Just go ahead and return, we need to ignore AUX iLO devs.

 Oops: 0002 [#1] SMP
   .
   .
   .
 RIP  [<ffffffffa033e270>] ilo_probe+0xec/0xe7c [hpilo]

Signed-off-by: Mark Rusk <mark.rusk@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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>

Drivers: hv: vmbus: Fix a bug in the handling of channel offers

commit 42dceebe34600b2d02a38baa3e869009ba3d14c7 upstream.

The channel state should be correctly set before registering the device. In the current
code the driver probe would fail for channels that have been rescinded and subsequently
re-offered. Fix the bug.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

hwmon: (k10temp) Add support for Fam16h (Kabini)

commit 30b146d1cb5e7560192057098eb705118bd5511f upstream.

The temperature reporting interface stays the same, so we just
add the PCI-ID to the list.

Verified on AMD Olive Hill.

Signed-off-by: Wei Hu <wei@aristanetworks.com>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>