linux.git, branch v3.18.32

Linux 3.18.32

2016-04-23T20:46:40+00:00

Signed-off-by: Sasha Levin

tcp_cubic: do not set epoch_start in the future

2016-04-23T20:45:18+00:00

[ Upstream commit c2e7204d180f8efc80f27959ca9cf16fa17f67db ]

Tracking idle time in bictcp_cwnd_event() is imprecise, as epoch_start
is normally set at ACK processing time, not at send time.

Doing a proper fix would need to add an additional state variable,
and does not seem worth the trouble, given CUBIC bug has been there
forever before Jana noticed it.

Let's simply not set epoch_start in the future, otherwise
bictcp_update() could overflow and CUBIC would again
grow cwnd too fast.

This was detected thanks to a packetdrill test Neal wrote that was flaky
before applying this fix.

Fixes: 30927520dbae ("tcp_cubic: better follow cubic curve after idle period")
Signed-off-by: Eric Dumazet 
Signed-off-by: Neal Cardwell 
Signed-off-by: Yuchung Cheng 
Cc: Jana Iyengar 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

Btrfs: fix list transaction->pending_ordered corruption

2016-04-23T00:38:30+00:00

[ Upstream commit d3efe08400317888f559bbedf0e42cd31575d0ef ]

When we call btrfs_commit_transaction(), we splice the list "ordered"
of our transaction handle into the transaction's "pending_ordered"
list, but we don't re-initialize the "ordered" list of our transaction
handle, this means it still points to the same elements it used to
before the splice. Then we check if the current transaction's state is
>= TRANS_STATE_COMMIT_START and if it is we end up calling
btrfs_end_transaction() which simply splices again the "ordered" list
of our handle into the transaction's "pending_ordered" list, leaving
multiple pointers to the same ordered extents which results in list
corruption when we are iterating, removing and freeing ordered extents
at btrfs_wait_pending_ordered(), resulting in access to dangling
pointers / use-after-free issues.
Similarly, btrfs_end_transaction() can end up in some cases calling
btrfs_commit_transaction(), and both did a list splice of the transaction
handle's "ordered" list into the transaction's "pending_ordered" without
re-initializing the handle's "ordered" list, resulting in exactly the
same problem.

This produces the following warning on a kernel with linked list
debugging enabled:

[109749.265416] ------------[ cut here ]------------
[109749.266410] WARNING: CPU: 7 PID: 324 at lib/list_debug.c:59 __list_del_entry+0x5a/0x98()
[109749.267969] list_del corruption. prev->next should be ffff8800ba087e20, but was fffffff8c1f7c35d
(...)
[109749.287505] Call Trace:
[109749.288135]  [] dump_stack+0x4f/0x7b
[109749.298080]  [] ? console_unlock+0x356/0x3a2
[109749.331605]  [] warn_slowpath_common+0xa1/0xbb
[109749.334849]  [] ? __list_del_entry+0x5a/0x98
[109749.337093]  [] warn_slowpath_fmt+0x46/0x48
[109749.337847]  [] __list_del_entry+0x5a/0x98
[109749.338678]  [] btrfs_wait_pending_ordered+0x46/0xdb [btrfs]
[109749.340145]  [] ? __btrfs_run_delayed_items+0x149/0x163 [btrfs]
[109749.348313]  [] btrfs_commit_transaction+0x36b/0xa10 [btrfs]
[109749.349745]  [] ? trace_hardirqs_on+0xd/0xf
[109749.350819]  [] btrfs_sync_file+0x36f/0x3fc [btrfs]
[109749.351976]  [] vfs_fsync_range+0x8f/0x9e
[109749.360341]  [] vfs_fsync+0x1c/0x1e
[109749.368828]  [] do_fsync+0x34/0x4e
[109749.369790]  [] SyS_fsync+0x10/0x14
[109749.370925]  [] system_call_fastpath+0x12/0x6f
[109749.382274] ---[ end trace 48e0d07f7c03d95a ]---

On a non-debug kernel this leads to invalid memory accesses, causing a
crash. Fix this by using list_splice_init() instead of list_splice() in
btrfs_commit_transaction() and btrfs_end_transaction().

Cc: stable@vger.kernel.org
Fixes: 50d9aa99bd35 ("Btrfs: make sure logged extents complete in the current transaction V3"
Signed-off-by: Filipe Manana 
Reviewed-by: David Sterba 
Signed-off-by: Sasha Levin

Correct backport of fa3c776 ("Thermal: Ignore invalid trip points")

2016-04-23T00:38:23+00:00

Backport of 81ad4276b505e987dd8ebbdf63605f92cd172b52 failed to adjust
for intervening ->get_trip_temp() argument type change, thus causing
stack protector to panic.

drivers/thermal/thermal_core.c: In function ‘thermal_zone_device_register’:
drivers/thermal/thermal_core.c:1569:41: warning: passing argument 3 of
‘tz->ops->get_trip_temp’ from incompatible pointer type [-Wincompatible-pointer-types]
   if (tz->ops->get_trip_temp(tz, count, &trip_temp))
                                         ^
drivers/thermal/thermal_core.c:1569:41: note: expected ‘long unsigned int *’
but argument is of type ‘int *’

CC:  #3.18,#4.1
Signed-off-by: Mike Galbraith

usb: musb: cppi41: correct the macro name EP_MODE_AUTOREG_*

2016-04-21T11:58:08+00:00

[ Upstream commit 0149b07a9e28b0d8bd2fc1c238ffe7d530c2673f ]

The macro EP_MODE_AUTOREG_* should be called EP_MODE_AUTOREQ_*, as they
are used for register AUTOREQ.

Signed-off-by: Bin Liu 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin

tcp_cubic: better follow cubic curve after idle period

2016-04-20T13:41:08+00:00

[ Upstream commit 30927520dbae297182990bb21d08762bcc35ce1d ]

Jana Iyengar found an interesting issue on CUBIC :

The epoch is only updated/reset initially and when experiencing losses.
The delta "t" of now - epoch_start can be arbitrary large after app idle
as well as the bic_target. Consequentially the slope (inverse of
ca->cnt) would be really large, and eventually ca->cnt would be
lower-bounded in the end to 2 to have delayed-ACK slow-start behavior.

This particularly shows up when slow_start_after_idle is disabled
as a dangerous cwnd inflation (1.5 x RTT) after few seconds of idle
time.

Jana initial fix was to reset epoch_start if app limited,
but Neal pointed out it would ask the CUBIC algorithm to recalculate the
curve so that we again start growing steeply upward from where cwnd is
now (as CUBIC does just after a loss). Ideally we'd want the cwnd growth
curve to be the same shape, just shifted later in time by the amount of
the idle period.

Reported-by: Jana Iyengar 
Signed-off-by: Eric Dumazet 
Signed-off-by: Yuchung Cheng 
Signed-off-by: Neal Cardwell 
Cc: Stephen Hemminger 
Cc: Sangtae Ha 
Cc: Lawrence Brakmo 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

usb: hcd: out of bounds access in for_each_companion

2016-04-20T13:41:07+00:00

[ Upstream commit e86103a75705c7c530768f4ffaba74cf382910f2 ]

On BXT platform Host Controller and Device Controller figure as
same PCI device but with different device function. HCD should
not pass data to Device Controller but only to Host Controllers.
Checking if companion device is Host Controller, otherwise skip.

Cc: 
Signed-off-by: Robert Dobrowolski 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

USB: uas: Add a new NO_REPORT_LUNS quirk

2016-04-20T13:41:07+00:00

[ Upstream commit 1363074667a6b7d0507527742ccd7bbed5e3ceaa ]

Add a new NO_REPORT_LUNS quirk and set it for Seagate drives with
an usb-id of: 0bc2:331a, as these will fail to respond to a
REPORT_LUNS command.

Cc: stable@vger.kernel.org
Reported-and-tested-by: David Webb 
Signed-off-by: Hans de Goede 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

xhci: fix 10 second timeout on removal of PCI hotpluggable xhci controllers

2016-04-20T13:41:06+00:00

[ Upstream commit 98d74f9ceaefc2b6c4a6440050163a83be0abede ]

PCI hotpluggable xhci controllers such as some Alpine Ridge solutions will
remove the xhci controller from the PCI bus when the last USB device is
disconnected.

Add a flag to indicate that the host is being removed to avoid queueing
configure_endpoint commands for the dropped endpoints.
For PCI hotplugged controllers this will prevent 5 second command timeouts
For static xhci controllers the configure_endpoint command is not needed
in the removal case as everything will be returned, freed, and the
controller is reset.

For now the flag is only set for PCI connected host controllers.

Cc: 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: xhci: fix xhci locking up during hcd remove

2016-04-20T13:41:06+00:00

[ Upstream commit ad6b1d914a9e07f3b9a9ae3396f3c840d0070539 ]

The problem seems to be that if a new device is detected
while we have already removed the shared HCD, then many of the
xhci operations (e.g.  xhci_alloc_dev(), xhci_setup_device())
hang as command never completes.

I don't think XHCI can operate without the shared HCD as we've
already called xhci_halt() in xhci_only_stop_hcd() when shared HCD
goes away. We need to prevent new commands from being queued
not only when HCD is dying but also when HCD is halted.

The following lockup was detected while testing the otg state
machine.

[  178.199951] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[  178.205799] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
[  178.214458] xhci-hcd xhci-hcd.0.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010
[  178.223619] xhci-hcd xhci-hcd.0.auto: irq 400, io mem 0x48890000
[  178.230677] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[  178.237796] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[  178.245358] usb usb1: Product: xHCI Host Controller
[  178.250483] usb usb1: Manufacturer: Linux 4.0.0-rc1-00024-g6111320 xhci-hcd
[  178.257783] usb usb1: SerialNumber: xhci-hcd.0.auto
[  178.267014] hub 1-0:1.0: USB hub found
[  178.272108] hub 1-0:1.0: 1 port detected
[  178.278371] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[  178.284171] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
[  178.294038] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[  178.301183] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[  178.308776] usb usb2: Product: xHCI Host Controller
[  178.313902] usb usb2: Manufacturer: Linux 4.0.0-rc1-00024-g6111320 xhci-hcd
[  178.321222] usb usb2: SerialNumber: xhci-hcd.0.auto
[  178.329061] hub 2-0:1.0: USB hub found
[  178.333126] hub 2-0:1.0: 1 port detected
[  178.567585] dwc3 48890000.usb: usb_otg_start_host 0
[  178.572707] xhci-hcd xhci-hcd.0.auto: remove, state 4
[  178.578064] usb usb2: USB disconnect, device number 1
[  178.586565] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
[  178.592585] xhci-hcd xhci-hcd.0.auto: remove, state 1
[  178.597924] usb usb1: USB disconnect, device number 1
[  178.603248] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[  190.597337] INFO: task kworker/u4:0:6 blocked for more than 10 seconds.
[  190.604273]       Not tainted 4.0.0-rc1-00024-g6111320 #1058
[  190.610228] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  190.618443] kworker/u4:0    D c05c0ac0     0     6      2 0x00000000
[  190.625120] Workqueue: usb_otg usb_otg_work
[  190.629533] [] (__schedule) from [] (schedule+0x34/0x98)
[  190.636915] [] (schedule) from [] (schedule_preempt_disabled+0xc/0x10)
[  190.645591] [] (schedule_preempt_disabled) from [] (mutex_lock_nested+0x1ac/0x3fc)
[  190.655353] [] (mutex_lock_nested) from [] (usb_disconnect+0x3c/0x208)
[  190.664043] [] (usb_disconnect) from [] (_usb_remove_hcd+0x98/0x1d8)
[  190.672535] [] (_usb_remove_hcd) from [] (usb_otg_start_host+0x50/0xf4)
[  190.681299] [] (usb_otg_start_host) from [] (otg_set_protocol+0x5c/0xd0)
[  190.690153] [] (otg_set_protocol) from [] (otg_set_state+0x170/0xbfc)
[  190.698735] [] (otg_set_state) from [] (otg_statemachine+0x12c/0x470)
[  190.707326] [] (otg_statemachine) from [] (process_one_work+0x1b4/0x4a0)
[  190.716162] [] (process_one_work) from [] (worker_thread+0x154/0x44c)
[  190.724742] [] (worker_thread) from [] (kthread+0xd4/0xf0)
[  190.732328] [] (kthread) from [] (ret_from_fork+0x14/0x24)
[  190.739898] 5 locks held by kworker/u4:0/6:
[  190.744274]  #0:  ("%s""usb_otg"){.+.+.+}, at: [] process_one_work+0x124/0x4a0
[  190.752799]  #1:  ((&otgd->work)){+.+.+.}, at: [] process_one_work+0x124/0x4a0
[  190.761326]  #2:  (&otgd->fsm.lock){+.+.+.}, at: [] otg_statemachine+0x18/0x470
[  190.769934]  #3:  (usb_bus_list_lock){+.+.+.}, at: [] _usb_remove_hcd+0x90/0x1d8
[  190.778635]  #4:  (&dev->mutex){......}, at: [] usb_disconnect+0x3c/0x208
[  190.786700] INFO: task kworker/1:0:14 blocked for more than 10 seconds.
[  190.793633]       Not tainted 4.0.0-rc1-00024-g6111320 #1058
[  190.799567] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  190.807783] kworker/1:0     D c05c0ac0     0    14      2 0x00000000
[  190.814457] Workqueue: usb_hub_wq hub_event
[  190.818866] [] (__schedule) from [] (schedule+0x34/0x98)
[  190.826252] [] (schedule) from [] (schedule_timeout+0x13c/0x1ec)
[  190.834377] [] (schedule_timeout) from [] (wait_for_common+0xbc/0x150)
[  190.843062] [] (wait_for_common) from [] (xhci_setup_device+0x164/0x5cc [xhci_hcd])
[  190.852986] [] (xhci_setup_device [xhci_hcd]) from [] (hub_port_init+0x3f4/0xb10)
[  190.862667] [] (hub_port_init) from [] (hub_event+0x704/0x1018)
[  190.870704] [] (hub_event) from [] (process_one_work+0x1b4/0x4a0)
[  190.878919] [] (process_one_work) from [] (worker_thread+0x154/0x44c)
[  190.887503] [] (worker_thread) from [] (kthread+0xd4/0xf0)
[  190.895076] [] (kthread) from [] (ret_from_fork+0x14/0x24)
[  190.902650] 5 locks held by kworker/1:0/14:
[  190.907023]  #0:  ("usb_hub_wq"){.+.+.+}, at: [] process_one_work+0x124/0x4a0
[  190.915454]  #1:  ((&hub->events)){+.+.+.}, at: [] process_one_work+0x124/0x4a0
[  190.924070]  #2:  (&dev->mutex){......}, at: [] hub_event+0x30/0x1018
[  190.931768]  #3:  (&port_dev->status_lock){+.+.+.}, at: [] hub_event+0x6f0/0x1018
[  190.940558]  #4:  (&bus->usb_address0_mutex){+.+.+.}, at: [] hub_port_init+0x58/0xb10

Signed-off-by: Roger Quadros 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin