linux-stable.git/drivers, branch v3.18.22

lpfc: Fix scsi prep dma buf error.

2015-09-28T22:57:02+00:00

[ Upstream commit 5116fbf136ea21b8678a85eee5c03508736ada9f ]

Didn't check for less-than-or-equal zero. Means we may later call
scsi_dma_unmap() even though we don't have valid mappings.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
Signed-off-by: James Bottomley 
Signed-off-by: Sasha Levin

net/mlx4_core: Fix wrong index in propagating port change event to VFs

2015-09-28T22:57:02+00:00

[ Upstream commit 1c1bf34951e8d17941bf708d1901c47e81b15d55 ]

The port-change event processing in procedure mlx4_eq_int() uses "slave"
as the vf_oper array index. Since the value of "slave" is the PF function
index, the result is that the PF link state is used for deciding to
propagate the event for all the VFs. The VF link state should be used,
so the VF function index should be used here.

Fixes: 948e306d7d64 ('net/mlx4: Add VF link state support')
Signed-off-by: Jack Morgenstein 
Signed-off-by: Matan Barak 
Signed-off-by: Or Gerlitz 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

bonding: correct the MAC address for "follow" fail_over_mac policy

2015-09-28T22:57:01+00:00

[ Upstream commit a951bc1e6ba58f11df5ed5ddc41311e10f5fd20b ]

The "follow" fail_over_mac policy is useful for multiport devices that
either become confused or incur a performance penalty when multiple
ports are programmed with the same MAC address, but the same MAC
address still may happened by this steps for this policy:

1) echo +eth0 > /sys/class/net/bond0/bonding/slaves
   bond0 has the same mac address with eth0, it is MAC1.

2) echo +eth1 > /sys/class/net/bond0/bonding/slaves
   eth1 is backup, eth1 has MAC2.

3) ifconfig eth0 down
   eth1 became active slave, bond will swap MAC for eth0 and eth1,
   so eth1 has MAC1, and eth0 has MAC2.

4) ifconfig eth1 down
   there is no active slave, and eth1 still has MAC1, eth2 has MAC2.

5) ifconfig eth0 up
   the eth0 became active slave again, the bond set eth0 to MAC1.

Something wrong here, then if you set eth1 up, the eth0 and eth1 will have the same
MAC address, it will break this policy for ACTIVE_BACKUP mode.

This patch will fix this problem by finding the old active slave and
swap them MAC address before change active slave.

Signed-off-by: Ding Tianhong 
Tested-by: Nikolay Aleksandrov 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

bonding: fix destruction of bond with devices different from arphrd_ether

2015-09-28T22:57:01+00:00

[ Upstream commit 06f6d1094aa0992432b1e2a0920b0ee86ccd83bf ]

When the bonding is being unloaded and the netdevice notifier is
unregistered it executes NETDEV_UNREGISTER for each device which should
remove the bond's proc entry but if the device enslaved is not of
ARPHRD_ETHER type and is in front of the bonding, it may execute
bond_release_and_destroy() first which would release the last slave and
destroy the bond device leaving the proc entry and thus we will get the
following error (with dynamic debug on for bond_netdev_event to see the
events order):
[  908.963051] eql: event: 9
[  908.963052] eql: IFF_SLAVE
[  908.963054] eql: event: 2
[  908.963056] eql: IFF_SLAVE
[  908.963058] eql: event: 6
[  908.963059] eql: IFF_SLAVE
[  908.963110] bond0: Releasing active interface eql
[  908.976168] bond0: Destroying bond bond0
[  908.976266] bond0 (unregistering): Released all slaves
[  908.984097] ------------[ cut here ]------------
[  908.984107] WARNING: CPU: 0 PID: 1787 at fs/proc/generic.c:575
remove_proc_entry+0x112/0x160()
[  908.984110] remove_proc_entry: removing non-empty directory
'net/bonding', leaking at least 'bond0'
[  908.984111] Modules linked in: bonding(-) eql(O) 9p nfsd auth_rpcgss
oid_registry nfs_acl nfs lockd grace fscache sunrpc crct10dif_pclmul
crc32_pclmul crc32c_intel ghash_clmulni_intel ppdev qxl drm_kms_helper
snd_hda_codec_generic aesni_intel ttm aes_x86_64 glue_helper pcspkr lrw
gf128mul ablk_helper cryptd snd_hda_intel virtio_console snd_hda_codec
psmouse serio_raw snd_hwdep snd_hda_core 9pnet_virtio 9pnet evdev joydev
drm virtio_balloon snd_pcm snd_timer snd soundcore i2c_piix4 i2c_core
pvpanic acpi_cpufreq parport_pc parport processor thermal_sys button
autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid hid sg sr_mod cdrom
ata_generic virtio_blk virtio_net floppy ata_piix e1000 libata ehci_pci
virtio_pci scsi_mod uhci_hcd ehci_hcd virtio_ring virtio usbcore
usb_common [last unloaded: bonding]

[  908.984168] CPU: 0 PID: 1787 Comm: rmmod Tainted: G        W  O
4.2.0-rc2+ #8
[  908.984170] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  908.984172]  0000000000000000 ffffffff81732d41 ffffffff81525b34
ffff8800358dfda8
[  908.984175]  ffffffff8106c521 ffff88003595af78 ffff88003595af40
ffff88003e3a4280
[  908.984178]  ffffffffa058d040 0000000000000000 ffffffff8106c59a
ffffffff8172ebd0
[  908.984181] Call Trace:
[  908.984188]  [] ? dump_stack+0x40/0x50
[  908.984193]  [] ? warn_slowpath_common+0x81/0xb0
[  908.984196]  [] ? warn_slowpath_fmt+0x4a/0x50
[  908.984199]  [] ? remove_proc_entry+0x112/0x160
[  908.984205]  [] ? bond_destroy_proc_dir+0x26/0x30
[bonding]
[  908.984208]  [] ? bond_net_exit+0x8e/0xa0 [bonding]
[  908.984217]  [] ? ops_exit_list.isra.4+0x37/0x70
[  908.984225]  [] ?
unregister_pernet_operations+0x8d/0xd0
[  908.984228]  [] ?
unregister_pernet_subsys+0x1d/0x30
[  908.984232]  [] ? bonding_exit+0x23/0xdba [bonding]
[  908.984236]  [] ? SyS_delete_module+0x18a/0x250
[  908.984241]  [] ? task_work_run+0x89/0xc0
[  908.984244]  [] ?
entry_SYSCALL_64_fastpath+0x16/0x75
[  908.984247] ---[ end trace 7c006ed4abbef24b ]---

Thus remove the proc entry manually if bond_release_and_destroy() is
used. Because of the checks in bond_remove_proc_entry() it's not a
problem for a bond device to change namespaces (the bug fixed by the
Fixes commit) but since commit
f9399814927ad ("bonding: Don't allow bond devices to change network
namespaces.") that can't happen anyway.

Reported-by: Carol Soto 
Signed-off-by: Nikolay Aleksandrov 
Fixes: a64d49c3dd50 ("bonding: Manage /proc/net/bonding/ entries from
                      the netdev events")
Tested-by: Carol L Soto 
Signed-off-by: David S. Miller 

Signed-off-by: Sasha Levin

isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

2015-09-28T22:57:00+00:00

[ Upstream commit fd98e9419d8d622a4de91f76b306af6aa627aa9c ]

Commit 79901317ce80 ("n_tty: Don't flush buffer when closing ldisc"),
first merged in kernel release 3.10, caused the following regression
in the Gigaset M101 driver:

Before that commit, when closing the N_TTY line discipline in
preparation to switching to N_GIGASET_M101, receive_room would be
reset to a non-zero value by the call to n_tty_flush_buffer() in
n_tty's close method. With the removal of that call, receive_room
might be left at zero, blocking data reception on the serial line.

The present patch fixes that regression by setting receive_room
to an appropriate value in the ldisc open method.

Fixes: 79901317ce80 ("n_tty: Don't flush buffer when closing ldisc")
Signed-off-by: Tilman Schmidt 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

drm/radeon: fix hotplug race at startup

2015-09-27T16:18:53+00:00

[ Upstream commit 7f98ca454ad373fc1b76be804fa7138ff68c1d27 ]

We apparantly get a hotplug irq before we've initialised
modesetting,

[drm] Loading R100 Microcode
BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [] __mutex_lock_slowpath+0x23/0x91
*pde = 00000000
Oops: 0002 [#1]
Modules linked in: radeon(+) drm_kms_helper ttm drm i2c_algo_bit backlight pcspkr psmouse evdev sr_mod input_leds led_class cdrom sg parport_pc parport floppy intel_agp intel_gtt lpc_ich acpi_cpufreq processor button mfd_core agpgart uhci_hcd ehci_hcd rng_core snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm usbcore usb_common i2c_i801 i2c_core snd_timer snd soundcore thermal_sys
CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted 4.2.0-rc7-00015-gbf67402 #111
Hardware name: MicroLink                               /D850MV                         , BIOS MV85010A.86A.0067.P24.0304081124 04/08/2003
Workqueue: events radeon_hotplug_work_func [radeon]
task: f6ca5900 ti: f6d3e000 task.ti: f6d3e000
EIP: 0060:[] EFLAGS: 00010282 CPU: 0
EIP is at __mutex_lock_slowpath+0x23/0x91
EAX: 00000000 EBX: f5e900fc ECX: 00000000 EDX: fffffffe
ESI: f6ca5900 EDI: f5e90100 EBP: f5e90000 ESP: f6d3ff0c
 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
CR0: 8005003b CR2: 00000000 CR3: 36f61000 CR4: 000006d0
Stack:
 f5e90100 00000000 c103c4c1 f6d2a5a0 f5e900fc f6df394c c125f162 f8b0faca
 f6d2a5a0 c138ca00 f6df394c f7395600 c1034741 00d40000 00000000 f6d2a5a0
 c138ca00 f6d2a5b8 c138ca10 c1034b58 00000001 f6d40000 f6ca5900 f6d0c940
Call Trace:
 [] ? dequeue_task_fair+0xa4/0xb7
 [] ? mutex_lock+0x9/0xa
 [] ? radeon_hotplug_work_func+0x17/0x57 [radeon]
 [] ? process_one_work+0xfc/0x194
 [] ? worker_thread+0x18d/0x218
 [] ? rescuer_thread+0x1d5/0x1d5
 [] ? kthread+0x7b/0x80
 [] ? ret_from_kernel_thread+0x20/0x30
 [] ? init_completion+0x18/0x18
Code: 42 08 e8 8e a6 dd ff c3 57 56 53 83 ec 0c 8b 35 48 f7 37 c1 8b 10 4a 74 1a 89 c3 8d 78 04 8b 40 08 89 63

Reported-and-Tested-by: Meelis Roos 
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin

mfd: lpc_ich: Assign subdevice ids automatically

2015-09-27T16:18:53+00:00

[ Upstream commit 1abf25a25b86dcfe28d243a5af71bd1c9d6de1ef ]

Using -1 as platform device id means that the platform driver core will not
assign any id to the device (the device name will not have id at all). This
results problems on systems that have multiple PCHs (Platform Controller
HUBs) because all of them also include their own copy of LPC device.

All the subsequent device creations will fail because there already exists
platform device with the same name.

Fix this by passing PLATFORM_DEVID_AUTO as platform device id. This makes
the platform device core to allocate new ids automatically.

Signed-off-by: Mika Westerberg 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

HID: usbhid: add Chicony/Pixart usb optical mouse that needs QUIRK_ALWAYS_POLL

2015-09-27T16:18:52+00:00

[ Upstream commit 7250dc3fee806eb2b7560ab7d6072302e7ae8cf8 ]

I received a report from an user of following mouse which needs this quirk:

usb 1-1.6: USB disconnect, device number 58
usb 1-1.6: new low speed USB device number 59 using ehci_hcd
usb 1-1.6: New USB device found, idVendor=04f2, idProduct=1053
usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.6: Product: USB Optical Mouse
usb 1-1.6: Manufacturer: PixArt
usb 1-1.6: configuration #1 chosen from 1 choice
input: PixArt USB Optical Mouse as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input5887
generic-usb 0003:04F2:1053.16FE: input,hidraw2: USB HID v1.11 Mouse [PixArt USB Optical Mouse] on usb-0000:00:1a.0-1.6/input0

The quirk was tested by the reporter and it fixed the frequent disconnections etc.

[jkosina@suse.cz: reorder the position in hid-ids.h]
Signed-off-by: Herton R. Krzesinski 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 

Signed-off-by: Sasha Levin

SCSI: Fix NULL pointer dereference in runtime PM

2015-09-27T16:18:51+00:00

[ Upstream commit 49718f0fb8c9af192b33d8af3a2826db04025371 ]

The routines in scsi_rpm.c assume that if a runtime-PM callback is
invoked for a SCSI device, it can only mean that the device's driver
has asked the block layer to handle the runtime power management (by
calling blk_pm_runtime_init(), which among other things sets q->dev).

However, this assumption turns out to be wrong for things like the ses
driver.  Normally ses devices are not allowed to do runtime PM, but
userspace can override this setting.  If this happens, the kernel gets
a NULL pointer dereference when blk_post_runtime_resume() tries to use
the uninitialized q->dev pointer.

This patch fixes the problem by calling the block layer's runtime-PM
routines only if the device's driver really does have a runtime-PM
callback routine.  Since ses doesn't define any such callbacks, the
crash won't occur.

This fixes Bugzilla #101371.

Signed-off-by: Alan Stern 
Reported-by: Stanisław Pitucha 
Reported-by: Ilan Cohen 
Tested-by: Ilan Cohen 
Reviewed-by: Johannes Thumshirn 
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley 
Signed-off-by: Sasha Levin

Add factory recertified Crucial M500s to blacklist

2015-09-22T19:20:20+00:00

[ Upstream commit 7a7184b01aa9deb86df661c6f7cbcf69a95b728c ]

The Crucial M500 is known to have issues with queued TRIM commands, the
factory recertified SSDs use a different model number naming convention
which causes them to get ignored by the blacklist.

The new naming convention boils down to: s/Crucial_/FC/

Signed-off-by: Guillermo A. Amaral 
Signed-off-by: Tejun Heo 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin