Commit Graph

826447 Commits

Author SHA1 Message Date
Linus Torvalds 73fdb2c908 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf fixes from Ingo Molnar:
 "Six kernel side fixes: three related to NMI handling on AMD systems, a
  race fix, a kexec initialization fix and a PEBS sampling fix"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/core: Fix perf_event_disable_inatomic() race
  x86/perf/amd: Remove need to check "running" bit in NMI handler
  x86/perf/amd: Resolve NMI latency issues for active PMCs
  x86/perf/amd: Resolve race condition when disabling PMC
  perf/x86/intel: Initialize TFA MSR
  perf/x86/intel: Fix handling of wakeup_events for multi-entry PEBS
2019-04-12 20:42:30 -07:00
Linus Torvalds 26e2b81977 Merge branch 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull locking fix from Ingo Molnar:
 "Fixes a crash when accessing /proc/lockdep"

* 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  locking/lockdep: Zap lock classes even with lock debugging disabled
2019-04-12 20:31:08 -07:00
Linus Torvalds 6a022984c3 Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull irq fixes from Ingo Molnar:
 "Two genirq fixes, plus an irqchip driver error handling fix"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  genirq: Respect IRQCHIP_SKIP_SET_WAKE in irq_chip_set_wake_parent()
  genirq: Initialize request_mutex if CONFIG_SPARSE_IRQ=n
  irqchip/irq-ls1x: Missing error code in ls1x_intc_of_init()
2019-04-12 20:21:59 -07:00
Linus Torvalds 54c63a7558 Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull core fixes from Ingo Molnar:
 "Fix an objtool warning plus fix a u64_to_user_ptr() macro expansion
  bug"

* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  objtool: Add rewind_stack_do_exit() to the noreturn list
  linux/kernel.h: Use parentheses around argument in u64_to_user_ptr()
2019-04-12 20:13:13 -07:00
Stephen Suryaputra ed0de45a10 ipv4: recompile ip options in ipv4_link_failure
Recompile IP options since IPCB may not be valid anymore when
ipv4_link_failure is called from arp_error_report.

Refer to the commit 3da1ed7ac3 ("net: avoid use IPCB in cipso_v4_error")
and the commit before that (9ef6b42ad6) for a similar issue.

Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 17:23:46 -07:00
David S. Miller 9e550f0153 Merge branch 'rxrpc-fixes'
David Howells says:

====================
rxrpc: Fixes

Here is a collection of fixes for rxrpc:

 (1) rxrpc_error_report() needs to call sock_error() to clear the error
     code from the UDP transport socket, lest it be unexpectedly revisited
     on the next kernel_sendmsg() call.  This has been causing all sorts of
     weird effects in AFS as the effects have typically been felt by the
     wrong RxRPC call.

 (2) Allow a kernel user of AF_RXRPC to easily detect if an rxrpc call has
     completed.

 (3) Allow errors incurred by attempting to transmit data through the UDP
     socket to get back up the stack to AFS.

 (4) Make AFS use (2) to abort the synchronous-mode call waiting loop if
     the rxrpc-level call completed.

 (5) Add a missing tracepoint case for tracing abort reception.

 (6) Fix detection and handling of out-of-order ACKs.

====================

Tested-by: Jonathan Billings <jsbillin@umich.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 16:57:23 -07:00
Jeffrey Altman 1a2391c30c rxrpc: Fix detection of out of order acks
The rxrpc packet serial number cannot be safely used to compute out of
order ack packets for several reasons:

 1. The allocation of serial numbers cannot be assumed to imply the order
    by which acks are populated and transmitted.  In some rxrpc
    implementations, delayed acks and ping acks are transmitted
    asynchronously to the receipt of data packets and so may be transmitted
    out of order.  As a result, they can race with idle acks.

 2. Serial numbers are allocated by the rxrpc connection and not the call
    and as such may wrap independently if multiple channels are in use.

In any case, what matters is whether the ack packet provides new
information relating to the bounds of the window (the firstPacket and
previousPacket in the ACK data).

Fix this by discarding packets that appear to wind back the window bounds
rather than on serial number procession.

Fixes: 298bc15b20 ("rxrpc: Only take the rwind and mtu values from latest ACK")
Signed-off-by: Jeffrey Altman <jaltman@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 16:57:23 -07:00
David Howells 39ce675575 rxrpc: Trace received connection aborts
Trace received calls that are aborted due to a connection abort, typically
because of authentication failure.  Without this, connection aborts don't
show up in the trace log.

Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 16:57:23 -07:00
Marc Dionne f7f1dd3162 afs: Check for rxrpc call completion in wait loop
Check the state of the rxrpc call backing an afs call in each iteration of
the call wait loop in case the rxrpc call has already been terminated at
the rxrpc layer.

Interrupt the wait loop and mark the afs call as complete if the rxrpc
layer call is complete.

There were cases where rxrpc errors were not passed up to afs, which could
result in this loop waiting forever for an afs call to transition to
AFS_CALL_COMPLETE while the rx call was already complete.

Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 16:57:23 -07:00
Marc Dionne 8e8715aaa9 rxrpc: Allow errors to be returned from rxrpc_queue_packet()
Change rxrpc_queue_packet()'s signature so that it can return any error
code it may encounter when trying to send the packet.

This allows the caller to eventually do something in case of error - though
it should be noted that the packet has been queued and a resend is
scheduled.

Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 16:57:23 -07:00
Marc Dionne 4611da30d6 rxrpc: Make rxrpc_kernel_check_life() indicate if call completed
Make rxrpc_kernel_check_life() pass back the life counter through the
argument list and return true if the call has not yet completed.

Suggested-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 16:57:23 -07:00
Marc Dionne 56d282d9db rxrpc: Clear socket error
When an ICMP or ICMPV6 error is received, the error will be attached
to the socket (sk_err) and the report function will get called.
Clear any pending error here by calling sock_error().

This would cause the following attempt to use the socket to fail with
the error code stored by the ICMP error, resulting in unexpected errors
with various side effects depending on the context.

Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Jonathan Billings <jsbillin@umich.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 16:57:23 -07:00
Colin Ian King 1dc2b3d655 qede: fix write to free'd pointer error and double free of ptp
The err2 error return path calls qede_ptp_disable that cleans up
on an error and frees ptp. After this, the free'd ptp is dereferenced
when ptp->clock is set to NULL and the code falls-through to error
path err1 that frees ptp again.

Fix this by calling qede_ptp_disable and exiting via an error
return path that does not set ptp->clock or kfree ptp.

Addresses-Coverity: ("Write to pointer after free")
Fixes: 035744975a ("qede: Add support for PTP resource locking.")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 16:55:47 -07:00
Colin Ian King 0a2c34f18c vxge: fix return of a free'd memblock on a failed dma mapping
Currently if a pci dma mapping failure is detected a free'd
memblock address is returned rather than a NULL (that indicates
an error). Fix this by ensuring NULL is returned on this error case.

Addresses-Coverity: ("Use after free")
Fixes: 528f727279 ("vxge: code cleanup and reorganization")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 16:54:41 -07:00
Leonard Crestez f89b9e1be7 clk: imx: Fix PLL_1416X not rounding rates
Code which initializes the "clk_init_data.ops" checks pll->rate_table
before that field is ever assigned to so it always picks
"clk_pll1416x_min_ops".

This breaks dynamic rate rounding for features such as cpufreq.

Fix by checking pll_clk->rate_table instead, here pll_clk refers to
the constant initialization data coming from per-soc clk driver.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Fixes: 8646d4dcc7 ("clk: imx: Add PLLs driver for imx8mm soc")
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-04-12 14:21:43 -07:00
Kalle Valo 832bc250d7 Second batch of iwlwifi fixes intended for v5.1
* fix for a potential deadlock in the TX path;
 * a fix for offloaded rate-control;
 * support new PCI HW IDs which use a new FW;
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEF3LNfgb2BPWm68smoUecoho8xfoFAlyka8EACgkQoUecoho8
 xfqbpg//dTiEkkB5vMeUYfsgyO4JdCmzCQg7ZYh7FfRtxP8EnRCD4CSQJHmU0K/G
 /K+cRn7nA06STbvshtmGQRJ9KJ8nLJ4wt1cZMXSi6O2bH6jdwKpBE6hCq71Kw99d
 zWns40Db3JFKE4/+OIRVAo1bdThjLquxrponGAr0CC7PzAo1BdG1ux34PlXev0Av
 n7rk/sLqPH/sfEOuVVU6WBNkhAAy0vSUfcZ2FOMuebx9Qkap7VFwSxGyuJI0mdPZ
 wQiAg4aCVUnbxscQB2ag82wMWui5HLtgdCh5aCgZNsCkWodr6iZXL32uhg8v09LZ
 yYnPWtyztm4t4InzeF3dmBfT/aKMeYn5C/tmi3oSIU0swUJdBeTuqYzKcuon4Ths
 +DJob2Gq8q1PEC6kSVfcJ7xZDt6bawfFdM9MwOSYYk2AYhyaPfSTud7w44NkqpKk
 fnfJHmFskYcz4pqld8/kjSHMTr/fZCRn3jDBaPoNZpJpZaPQ3y1jymyQ8/9d9OKM
 f44TDDMkRUw1rOiHm3IZQZiMXaUgY8ZHFF7z6sITwogPJVXSqG8d+kLfo0WBVk1B
 Bt/8ApuuyRm52CZPE+lYLP9rINdoMJFmOHA73sj6/RXWNYJ4QWzqzM4Fgld3ZuIh
 nldyeSWO/uFmlKcydT1wBNTqi63zn2PWIC0ejlwqDJ9L0KCSgMc=
 =EfCY
 -----END PGP SIGNATURE-----

Merge tag 'iwlwifi-for-kalle-2019-04-03' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes

Second batch of iwlwifi fixes intended for v5.1

* fix for a potential deadlock in the TX path;
* a fix for offloaded rate-control;
* support new PCI HW IDs which use a new FW;
2019-04-12 21:34:27 +03:00
Stanislaw Gruszka bafdf85dfa mt76x02: avoid status_list.lock and sta->rate_ctrl_lock dependency
Move ieee80211_tx_status_ext() outside of status_list lock section
in order to avoid locking dependency and possible deadlock reposed by
LOCKDEP in below warning.

Also do mt76_tx_status_lock() just before it's needed.

[  440.224832] WARNING: possible circular locking dependency detected
[  440.224833] 5.1.0-rc2+ #22 Not tainted
[  440.224834] ------------------------------------------------------
[  440.224835] kworker/u16:28/2362 is trying to acquire lock:
[  440.224836] 0000000089b8cacf (&(&q->lock)->rlock#2){+.-.}, at: mt76_wake_tx_queue+0x4c/0xb0 [mt76]
[  440.224842]
               but task is already holding lock:
[  440.224842] 000000002cfedc59 (&(&sta->lock)->rlock){+.-.}, at: ieee80211_stop_tx_ba_cb+0x32/0x1f0 [mac80211]
[  440.224863]
               which lock already depends on the new lock.

[  440.224863]
               the existing dependency chain (in reverse order) is:
[  440.224864]
               -> #3 (&(&sta->lock)->rlock){+.-.}:
[  440.224869]        _raw_spin_lock_bh+0x34/0x40
[  440.224880]        ieee80211_start_tx_ba_session+0xe4/0x3d0 [mac80211]
[  440.224894]        minstrel_ht_get_rate+0x45c/0x510 [mac80211]
[  440.224906]        rate_control_get_rate+0xc1/0x140 [mac80211]
[  440.224918]        ieee80211_tx_h_rate_ctrl+0x195/0x3c0 [mac80211]
[  440.224930]        ieee80211_xmit_fast+0x26d/0xa50 [mac80211]
[  440.224942]        __ieee80211_subif_start_xmit+0xfc/0x310 [mac80211]
[  440.224954]        ieee80211_subif_start_xmit+0x38/0x390 [mac80211]
[  440.224956]        dev_hard_start_xmit+0xb8/0x300
[  440.224957]        __dev_queue_xmit+0x7d4/0xbb0
[  440.224968]        ip6_finish_output2+0x246/0x860 [ipv6]
[  440.224978]        mld_sendpack+0x1bd/0x360 [ipv6]
[  440.224987]        mld_ifc_timer_expire+0x1a4/0x2f0 [ipv6]
[  440.224989]        call_timer_fn+0x89/0x2a0
[  440.224990]        run_timer_softirq+0x1bd/0x4d0
[  440.224992]        __do_softirq+0xdb/0x47c
[  440.224994]        irq_exit+0xfa/0x100
[  440.224996]        smp_apic_timer_interrupt+0x9a/0x220
[  440.224997]        apic_timer_interrupt+0xf/0x20
[  440.224999]        cpuidle_enter_state+0xc1/0x470
[  440.225000]        do_idle+0x21a/0x260
[  440.225001]        cpu_startup_entry+0x19/0x20
[  440.225004]        start_secondary+0x135/0x170
[  440.225006]        secondary_startup_64+0xa4/0xb0
[  440.225007]
               -> #2 (&(&sta->rate_ctrl_lock)->rlock){+.-.}:
[  440.225009]        _raw_spin_lock_bh+0x34/0x40
[  440.225022]        rate_control_tx_status+0x4f/0xb0 [mac80211]
[  440.225031]        ieee80211_tx_status_ext+0x142/0x1a0 [mac80211]
[  440.225035]        mt76x02_send_tx_status+0x2e4/0x340 [mt76x02_lib]
[  440.225037]        mt76x02_tx_status_data+0x31/0x40 [mt76x02_lib]
[  440.225040]        mt76u_tx_status_data+0x51/0xa0 [mt76_usb]
[  440.225042]        process_one_work+0x237/0x5d0
[  440.225043]        worker_thread+0x3c/0x390
[  440.225045]        kthread+0x11d/0x140
[  440.225046]        ret_from_fork+0x3a/0x50
[  440.225047]
               -> #1 (&(&list->lock)->rlock#8){+.-.}:
[  440.225049]        _raw_spin_lock_bh+0x34/0x40
[  440.225052]        mt76_tx_status_skb_add+0x51/0x100 [mt76]
[  440.225054]        mt76x02u_tx_prepare_skb+0xbd/0x116 [mt76x02_usb]
[  440.225056]        mt76u_tx_queue_skb+0x5f/0x180 [mt76_usb]
[  440.225058]        mt76_tx+0x93/0x190 [mt76]
[  440.225070]        ieee80211_tx_frags+0x148/0x210 [mac80211]
[  440.225081]        __ieee80211_tx+0x75/0x1b0 [mac80211]
[  440.225092]        ieee80211_tx+0xde/0x110 [mac80211]
[  440.225105]        __ieee80211_tx_skb_tid_band+0x72/0x90 [mac80211]
[  440.225122]        ieee80211_send_auth+0x1f3/0x360 [mac80211]
[  440.225141]        ieee80211_auth.cold.40+0x6c/0x100 [mac80211]
[  440.225156]        ieee80211_mgd_auth.cold.50+0x132/0x15f [mac80211]
[  440.225171]        cfg80211_mlme_auth+0x149/0x360 [cfg80211]
[  440.225181]        nl80211_authenticate+0x273/0x2e0 [cfg80211]
[  440.225183]        genl_family_rcv_msg+0x196/0x3a0
[  440.225184]        genl_rcv_msg+0x47/0x8e
[  440.225185]        netlink_rcv_skb+0x3a/0xf0
[  440.225187]        genl_rcv+0x24/0x40
[  440.225188]        netlink_unicast+0x16d/0x210
[  440.225189]        netlink_sendmsg+0x204/0x3b0
[  440.225191]        sock_sendmsg+0x36/0x40
[  440.225193]        ___sys_sendmsg+0x259/0x2b0
[  440.225194]        __sys_sendmsg+0x47/0x80
[  440.225196]        do_syscall_64+0x60/0x1f0
[  440.225197]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  440.225198]
               -> #0 (&(&q->lock)->rlock#2){+.-.}:
[  440.225200]        lock_acquire+0xb9/0x1a0
[  440.225202]        _raw_spin_lock_bh+0x34/0x40
[  440.225204]        mt76_wake_tx_queue+0x4c/0xb0 [mt76]
[  440.225215]        ieee80211_agg_start_txq+0xe8/0x2b0 [mac80211]
[  440.225225]        ieee80211_stop_tx_ba_cb+0xb8/0x1f0 [mac80211]
[  440.225235]        ieee80211_ba_session_work+0x1c1/0x2f0 [mac80211]
[  440.225236]        process_one_work+0x237/0x5d0
[  440.225237]        worker_thread+0x3c/0x390
[  440.225239]        kthread+0x11d/0x140
[  440.225240]        ret_from_fork+0x3a/0x50
[  440.225240]
               other info that might help us debug this:

[  440.225241] Chain exists of:
                 &(&q->lock)->rlock#2 --> &(&sta->rate_ctrl_lock)->rlock --> &(&sta->lock)->rlock

[  440.225243]  Possible unsafe locking scenario:

[  440.225244]        CPU0                    CPU1
[  440.225244]        ----                    ----
[  440.225245]   lock(&(&sta->lock)->rlock);
[  440.225245]                                lock(&(&sta->rate_ctrl_lock)->rlock);
[  440.225246]                                lock(&(&sta->lock)->rlock);
[  440.225247]   lock(&(&q->lock)->rlock#2);
[  440.225248]
                *** DEADLOCK ***

[  440.225249] 5 locks held by kworker/u16:28/2362:
[  440.225250]  #0: 0000000048fcd291 ((wq_completion)phy0){+.+.}, at: process_one_work+0x1b5/0x5d0
[  440.225252]  #1: 00000000f1c6828f ((work_completion)(&sta->ampdu_mlme.work)){+.+.}, at: process_one_work+0x1b5/0x5d0
[  440.225254]  #2: 00000000433d2b2c (&sta->ampdu_mlme.mtx){+.+.}, at: ieee80211_ba_session_work+0x5c/0x2f0 [mac80211]
[  440.225265]  #3: 000000002cfedc59 (&(&sta->lock)->rlock){+.-.}, at: ieee80211_stop_tx_ba_cb+0x32/0x1f0 [mac80211]
[  440.225276]  #4: 000000009d7b9a44 (rcu_read_lock){....}, at: ieee80211_agg_start_txq+0x33/0x2b0 [mac80211]
[  440.225286]
               stack backtrace:
[  440.225288] CPU: 2 PID: 2362 Comm: kworker/u16:28 Not tainted 5.1.0-rc2+ #22
[  440.225289] Hardware name: LENOVO 20KGS23S0P/20KGS23S0P, BIOS N23ET55W (1.30 ) 08/31/2018
[  440.225300] Workqueue: phy0 ieee80211_ba_session_work [mac80211]
[  440.225301] Call Trace:
[  440.225304]  dump_stack+0x85/0xc0
[  440.225306]  print_circular_bug.isra.38.cold.58+0x15c/0x195
[  440.225307]  check_prev_add.constprop.48+0x5f0/0xc00
[  440.225309]  ? check_prev_add.constprop.48+0x39d/0xc00
[  440.225311]  ? __lock_acquire+0x41d/0x1100
[  440.225312]  __lock_acquire+0xd98/0x1100
[  440.225313]  ? __lock_acquire+0x41d/0x1100
[  440.225315]  lock_acquire+0xb9/0x1a0
[  440.225317]  ? mt76_wake_tx_queue+0x4c/0xb0 [mt76]
[  440.225319]  _raw_spin_lock_bh+0x34/0x40
[  440.225321]  ? mt76_wake_tx_queue+0x4c/0xb0 [mt76]
[  440.225323]  mt76_wake_tx_queue+0x4c/0xb0 [mt76]
[  440.225334]  ieee80211_agg_start_txq+0xe8/0x2b0 [mac80211]
[  440.225344]  ieee80211_stop_tx_ba_cb+0xb8/0x1f0 [mac80211]
[  440.225354]  ieee80211_ba_session_work+0x1c1/0x2f0 [mac80211]
[  440.225356]  process_one_work+0x237/0x5d0
[  440.225358]  worker_thread+0x3c/0x390
[  440.225359]  ? wq_calc_node_cpumask+0x70/0x70
[  440.225360]  kthread+0x11d/0x140
[  440.225362]  ? kthread_create_on_node+0x40/0x40
[  440.225363]  ret_from_fork+0x3a/0x50

Cc: stable@vger.kernel.org
Fixes: 88046b2c9f ("mt76: add support for reporting tx status with skb")
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-12 21:32:40 +03:00
Vijayakumar Durai 746ba11f17 rt2x00: do not increment sequence number while re-transmitting
Currently rt2x00 devices retransmit the management frames with
incremented sequence number if hardware is assigning the sequence.

This is HW bug fixed already for non-QOS data frames, but it should
be fixed for management frames except beacon.

Without fix retransmitted frames have wrong SN:

 AlphaNet_e8:fb:36 Vivotek_52:31:51 Authentication, SN=1648, FN=0, Flags=........C Frame is not being retransmitted 1648 1
 AlphaNet_e8:fb:36 Vivotek_52:31:51 Authentication, SN=1649, FN=0, Flags=....R...C Frame is being retransmitted 1649 1
 AlphaNet_e8:fb:36 Vivotek_52:31:51 Authentication, SN=1650, FN=0, Flags=....R...C Frame is being retransmitted 1650 1

With the fix SN stays correctly the same:

 88:6a:e3:e8:f9:a2 8c:f5:a3:88:76:87 Authentication, SN=1450, FN=0, Flags=........C
 88:6a:e3:e8:f9:a2 8c:f5:a3:88:76:87 Authentication, SN=1450, FN=0, Flags=....R...C
 88:6a:e3:e8:f9:a2 8c:f5:a3:88:76:87 Authentication, SN=1450, FN=0, Flags=....R...C

Cc: stable@vger.kernel.org
Signed-off-by: Vijayakumar Durai <vijayakumar.durai1@vivint.com>
[sgruszka: simplify code, change comments and changelog]
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-12 21:31:07 +03:00
Felix Fietkau 9dc27bcbe7 mt76: mt7603: send BAR after powersave wakeup
Now that the sequence number allocation is fixed, we can finally send a BAR
at powersave wakeup time to refresh the receiver side reorder window

Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-12 21:28:26 +03:00
Felix Fietkau aa3cb24be1 mt76: mt7603: fix sequence number assignment
If the MT_TXD3_SN_VALID flag is not set in the tx descriptor, the hardware
assigns the sequence number. However, the rest of the code assumes that the
sequence number specified in the 802.11 header gets transmitted.
This was causing issues with the aggregation setup, which worked for the
initial one (where the sequence numbers were still close), but not for
further teardown/re-establishing of sessions.

Additionally, the overwrite of the TID sequence number in WTBL2 was resetting
the hardware assigned sequence numbers, causing them to drift further apart.

Fix this by using the software assigned sequence numbers

Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-12 21:28:26 +03:00
Felix Fietkau 2170e2157d mt76: mt7603: add missing initialization for dev->ps_lock
Fixes lockdep complaint and a potential race condition

Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-12 21:28:25 +03:00
Tetsuo Handa bddc028a4f udpv6: Check address length before reading address family
KMSAN will complain if valid address length passed to udpv6_pre_connect()
is shorter than sizeof("struct sockaddr"->sa_family) bytes.

(This patch is bogus if it is guaranteed that udpv6_pre_connect() is
always called after checking "struct sockaddr"->sa_family. In that case,
we want a comment why we don't need to check valid address length here.)

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Song Liu <songliubraving@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 10:25:03 -07:00
Tetsuo Handa ba024f2574 bpf: Check address length before reading address family
KMSAN will complain if valid address length passed to bpf_bind() is
shorter than sizeof("struct sockaddr"->sa_family) bytes.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Andrey Ignatov <rdna@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 10:25:03 -07:00
Tetsuo Handa c68e747d0a llc: Check address length before reading address field
KMSAN will complain if valid address length passed to bind() is shorter
than sizeof(struct sockaddr_llc) bytes.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 10:25:03 -07:00
Tetsuo Handa bd7d46ddca Bluetooth: Check address length before reading address field
KMSAN will complain if valid address length passed to bind() is shorter
than sizeof(struct sockaddr_sco) bytes.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 10:25:03 -07:00
Tetsuo Handa a9107a14a9 rxrpc: Check address length before reading srx_service field
KMSAN will complain if valid address length passed to bind() is shorter
than sizeof(struct sockaddr_rxrpc) bytes.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 10:25:03 -07:00
Tetsuo Handa d852be8477 net: netlink: Check address length before reading groups field
KMSAN will complain if valid address length passed to bind() is shorter
than sizeof(struct sockaddr_nl) bytes.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 10:25:03 -07:00
Tetsuo Handa 175f7c1f01 sctp: Check address length before reading address family
KMSAN will complain if valid address length passed to connect() is shorter
than sizeof("struct sockaddr"->sa_family) bytes.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 10:25:03 -07:00
Tetsuo Handa 238ffdc49e mISDN: Check address length before reading address family
KMSAN will complain if valid address length passed to bind() is shorter
than sizeof("struct sockaddr_mISDN"->family) bytes.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 10:25:03 -07:00
Tetsuo Handa dd3ac9a684 net/rds: Check address length before reading address family
syzbot is reporting uninitialized value at rds_connect() [1] and
rds_bind() [2]. This is because syzbot is passing ulen == 0 whereas
these functions expect that it is safe to access sockaddr->family field
in order to determine minimal address length for validation.

[1] https://syzkaller.appspot.com/bug?id=f4e61c010416c1e6f0fa3ffe247561b60a50ad71
[2] https://syzkaller.appspot.com/bug?id=a4bf9e41b7e055c3823fdcd83e8c58ca7270e38f

Reported-by: syzbot <syzbot+0049bebbf3042dbd2e8f@syzkaller.appspotmail.com>
Reported-by: syzbot <syzbot+915c9f99f3dbc4bd6cd1@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-12 10:25:03 -07:00
Weiyi Lu b3cf181c65 clk: mediatek: fix clk-gate flag setting
CLK_SET_RATE_PARENT would be dropped.
Merge two flag setting together to correct the error.

Fixes: 5a1cc4c27a ("clk: mediatek: Add flags to mtk_gate")
Cc: <stable@vger.kernel.org>
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-04-12 09:41:49 -07:00
Alex Deucher 1925e7d3d4 drm/amdgpu/gmc9: fix VM_L2_CNTL3 programming
Got accidently dropped when 2+1 level support was added.

Fixes: 6a42fd6fbf ("drm/amdgpu: implement 2+1 PD support for Raven v3")
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2019-04-12 11:24:16 -05:00
wentalou b575f10dbd drm/amdgpu: shadow in shadow_list without tbo.mem.start cause page fault in sriov TDR
shadow was added into shadow_list by amdgpu_bo_create_shadow.
meanwhile, shadow->tbo.mem was not fully configured.
tbo.mem would be fully configured by amdgpu_vm_sdma_map_table until calling amdgpu_vm_clear_bo.
If sriov TDR occurred between amdgpu_bo_create_shadow and amdgpu_vm_sdma_map_table,
amdgpu_device_recover_vram would deal with shadow without tbo.mem.start.

Signed-off-by: Wentao Lou <Wentao.Lou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-04-12 11:23:49 -05:00
Linus Torvalds 8ee15f3248 dma-mapping fixes for 5.1
Fix a sparc64 sun4v_pci regression introduced in this merged window,
 and a dma-debug stracktrace regression from the big refactor last
 merge window.
 -----BEGIN PGP SIGNATURE-----
 
 iQI/BAABCgApFiEEgdbnc3r/njty3Iq9D55TZVIEUYMFAlywq+gLHGhjaEBsc3Qu
 ZGUACgkQD55TZVIEUYPXSg//XPtl1nRBygmt4USrcwU7n0sSB5/THnh4uVUF/ugW
 wus6lJ+AIwoSpUv2VTGAifx0GOYIC7SHtEaGxBUkklwMygD+GhOm6uPtjsczI466
 aUt3R1w88Anz0bTFLSZ4z3ESlAejHN7IgZZXjLEpmsTgvz5JwXCN/DbEc8wBNMfe
 NF9QbEk4i6RaVHr1PA5dao8jQ2BIO7WLNOxZjm8IRHs2+wgX3vAs4ohjLQyFc6dp
 TdVcP3oe9Ere8pkvFp1om/fr185pnEKn01fuG7lf3QA3JFkY7KAa9FxVOumzHZhh
 tt/0rnoCYgzOjg+SVYEadqaH9rneNriKER+JBz9J5OOhRP/W5OuSsJkd9V6qSUEp
 xO/Ie9tqF1KZI8+hDh70OE18h3+b1g/aGpS8KxOqa3J548TbzOcKnzfsL3T5rIlH
 zW+mw1Z14PZ4Z0cXSH214fkVoZphF80A9cdZMYKiR9GKo1Jw0jBkw4qMvBocP3r+
 zf53nXQewbRrnQ5Rn1dFDlWTUdazS+kXFXFmt69i22JEBjbTd8ljT53uLzlP+8BW
 sW9Nuc1yybgtW83F8kLLuetY+z8fo9SurxSE31ogUhVRV+hWCPsv8I6HtLZYbKFQ
 Ygc1xdjL+d6N5ywnZ2s5fDAtHA/TKE+6wDGTHlD3GoNpfNvOLVDl8EjLcUuK/uW9
 uOE=
 =Ohx3
 -----END PGP SIGNATURE-----

Merge tag 'dma-mapping-5.1-1' of git://git.infradead.org/users/hch/dma-mapping

Pull dma-mapping fixes from Christoph Hellwig:
 "Fix a sparc64 sun4v_pci regression introduced in this merged window,
  and a dma-debug stracktrace regression from the big refactor last
  merge window"

* tag 'dma-mapping-5.1-1' of git://git.infradead.org/users/hch/dma-mapping:
  dma-debug: only skip one stackframe entry
  sparc64/pci_sun4v: fix ATU checks for large DMA masks
2019-04-12 08:25:16 -07:00
Linus Torvalds 4876191cbe IOMMU Fix for Linux v5.1-rc5
- Fix an AMD IOMMU issue where the driver didn't correctly setup the
 	  exclusion range in the hardware registers, resulting in exclusion
 	  ranges being one page too big. This can cause data corruption of the
 	  address of that last page is used by DMA operations.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEr9jSbILcajRFYWYyK/BELZcBGuMFAlywkkwACgkQK/BELZcB
 GuOUMg//dYTFTvZot5L/AgMndzDN1dbR/5ZYV1E4QpjsinKLOyyB0nYY/GHni/+Z
 WgMil5d8boAy5b2wcmpA4VYlZdh4v8/e2nVsBPilt5QqXfiS4KGqqvfsvASLE81W
 Z68cW3qADscdxjhlSozQAGMfu5tb0nqFJRo/oparMGwA3h1sMcVYbC+qpRDciBsW
 +d13cvMXxlTHRuFKn/9HS9tHNCyB2X9QiVfjUhRJGOXnpn05HzabYtBVV11e6L/O
 bW8MopA4hIHI+cY40uBFDtUD7ovxgPs450O8QCsmwoJvwyX1XaVMFlecmlsPj3Cm
 DdJurdMfzfeXmB861FRy1ZOmUYelwStXteta5VeQE9tFtW1hoX8RPn6sf4xvFkOS
 OyVDqdZV02yRRKZhnQMvdslHLdalfSkI2zFs+0YZ4Q/QuN2qpWecmmGc0whUevYQ
 tjFCk50Y89GMmseZuobNyKw53hxoKOcAC3AuMTwNLCcXKW9vb9mP5uO5BUmzvmuh
 n3gYzQgEZumIVD8Dt3piXwDppkCqDiOz+u4NdVhnVVbTBtUBXSojo4DTSNYhwbGe
 sHrDwOcVVn3XVR0FQo3WhqEsEt4rSWu8yDlioobapi4H7LLe6QgWEsGeRL1RfGIY
 ESgT67TNgeAGXulE/fOCBrHqLVzPaCP1x9IOrmr6PoF7RIOxJNo=
 =ct7y
 -----END PGP SIGNATURE-----

Merge tag 'iommu-fix-v5.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu

Pull IOMMU fix from Joerg Roedel:
 "Fix an AMD IOMMU issue where the driver didn't correctly setup the
  exclusion range in the hardware registers, resulting in exclusion
  ranges being one page too big.

  This can cause data corruption of the address of that last page is
  used by DMA operations"

* tag 'iommu-fix-v5.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
  iommu/amd: Set exclusion range correctly
2019-04-12 08:21:15 -07:00
Linus Torvalds 8e72d95d99 The usual roughly-per-release .clang-format macro list update
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEPjU5OPd5QIZ9jqqOGXyLc2htIW0FAlywbmEACgkQGXyLc2ht
 IW2xYxAA3IPXr5MPgi4HwZEi195SJ+bZYae/I87zqX3qeWqzEIDP/1WiH1SaZ+6t
 TRk3k73M9m9me75a93J+DZzxnHUXf6C1JK/NEpLZ4SFnJvBHVPyi6H1yra3pJMhU
 DSSrFaIPXVQCmkCIc0vXAhNXxpOvFX1MW7f25ynDX3GBOcy6Dfrwqk/sVMUK+2dK
 rmZdcUoic0xYGu4LdRn9tXmDOQeghry/y5SaQM4JairzwVdrAzbcpTDn00WYhMou
 6dXHUSwZjiOjU7ObpWYqIVQHmVp74Huaei2xwdfDR6c2sDkyTpEQ/O+QcPv6hMEK
 92SZrJzHbPF5i2AEbhYB/JxAMFj0jYSqJkBBhh02r1RyqhL5u91QP5nP1fXdjtMK
 wjBaJvKiGPwyVcO9FfpNYqKr1GfXyts1AaHlevzg5zQ66wbdpO6VH7Ok6J/nMMR7
 0VJxYeSdNX+KFLiu7RAnQuphUtJ8fW/Vkl3b2PblN05KeJwzMycDqVv8DlaH5vU7
 TJsf18z9fFTQuGT96etsru7KWEe5tAWYF6uc2Cx8fPZu/Eie5WkgcMW3xOCqX7U+
 AH0tMA96aN+Q2xPThTQWXJRZFmVHxATmzpvt6ReNcmk2X+MyGvrsIJJOkQamVZ7K
 Dui27FDA6YSboK7ckxFZJIsQSAiFoq083vp02tqs/RvnBTEOhKY=
 =yhz1
 -----END PGP SIGNATURE-----

Merge tag 'clang-format-for-linus-v5.1-rc5' of git://github.com/ojeda/linux

Pull clang-format update from Miguel Ojeda:
 "The usual roughly-per-release .clang-format macro list update"

* tag 'clang-format-for-linus-v5.1-rc5' of git://github.com/ojeda/linux:
  clang-format: Update with the latest for_each macro list
2019-04-12 08:18:37 -07:00
Linus Torvalds ea951a943f MMC host:
- alcor: Stabilize data write requests
  - sdhci-omap: Fix command error path during tuning
 -----BEGIN PGP SIGNATURE-----
 
 iQJLBAABCgA1FiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAlywfaUXHHVsZi5oYW5z
 c29uQGxpbmFyby5vcmcACgkQ/iaEJXNYjCmB0hAApomaOKmKsFHyFn5nQ2QM+UIr
 SFDG+m/zHZoJo4bbH3pIQ2/eXUMwQMWfsyvrfVci4dO/CGMRlNSdXr+to5+l8qZT
 CrfKbqGSoWA7nirqc4d4We1p1MSTycevc/fuNx4Gk777QI2t0CwMJF+fCkm30J6i
 JIAKrtn+0cCpPGQhhyPu1BHOKHXOtumcuFq+R6VmN30q6Ab6nN3MdNLusEwEu9CK
 5766SEFttY3OQsydv/bsFNbR+W3MCrsfeU7epP4+CkSN+279IVElP9u8AQ/Tzu/5
 bv7Q/v3J7a6jRYSscLtO3nEwxBKJfJd4+RoPM5BsjEb3niZiWs1hRFyGfJhX7r3A
 RuZCO9mvvSj9/O1s6UtXefAKlDYpLpTrxVzHttEsoXVXCaxehhEP49JVYc8JA7CC
 vwGjxbbMmdDcrAhOyJcfk31gQTzPmLesyEs+8IWsiehfxBTFqqrcKxgw3LAMjhjI
 1+hgpURSD6bKzMO8dCZ8uXHFRGdJ7r0WkufayuiphP/MV91Ok+GVyL9EJOH8FeCM
 uuZy5mVHK8QnYfo8u0+4ABLCIRaHDOvDGMxrcrdvHN2yPan+m+lqwVLfca4BRXwq
 W8c4QRH4zSZu4uYswwTTQKhyyuG44P/vaxnxUpzg5n1ugv+9FTMTsFHXbLz7UH/l
 yr1PJJCz0wwTmp6Dkjo=
 =N8+A
 -----END PGP SIGNATURE-----

Merge tag 'mmc-v5.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc

Pull MMC host fixes from Ulf Hansson:

 - alcor: Stabilize data write requests

 - sdhci-omap: Fix command error path during tuning

* tag 'mmc-v5.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
  mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
  mmc: alcor: don't write data before command has completed
2019-04-12 08:16:40 -07:00
Linus Torvalds 372686e60c sound fixes for 5.1-rc5
Well, this one became unpleasantly larger than previous pull requests,
 but it's a kind of usual pattern: now it contains a collection of ASoC
 fixes, and nothing to worry too much.
 
 The fixes for ASoC core (DAPM, DPCM, topology) are all small and just
 covering corner cases.  The rest changes are driver-specific, many of
 which are for x86 platforms and new drivers like STM32, in addition to
 the usual fixups for HD-audio.
 -----BEGIN PGP SIGNATURE-----
 
 iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAlyvTfEOHHRpd2FpQHN1
 c2UuZGUACgkQLtJE4w1nLE/82RAAoKeeIF/V1Y24+aJhp5HwuxqOCeoVeiFijjiO
 oPzEbbi6iuAXj3Rwb5xo19jbpgxCIuU/ZKCVB23xJgSKSklCxbb7cY76e+/SEDlj
 +WvLpQdrYLZzwQ5xWZA+Vpxh67sI8NhPQh0n4WFAH8eajHxpf6v0ZS2Wms802k8M
 VTjpza9J/fDoE67vyL2SB44H9NlShL6P/tpoX3eEvhm5mU3mftnVkVgnCYsdbfrv
 rIvswfeMya/EgfdEpcbMwzGBLVP5V2NNodaPDqUTZJmXS02533b+Ufh/5bYuNenf
 Wxxapdqgki8sypw8r3GS1Eq9pCukoCcmlRFF47NpUOzCoZQtdFLsZCXTTpCXUt41
 PKGRYRP+4cobXFpr0swoozLhMGREEGh9S94ixLwnDcrkIxmUSaRqgSSYYTgQp3Jw
 +XfscNEDr0eVLN614oW6v+hAgcSTuTO4Ctk0miePNvBcvM3aHbKYichgFFVFXiki
 JXw8N+dmQMaHxa0t+QaVm7zfD7TA4H8+N99VJGq8AtS/lRYZ+mEsZleJze7juoam
 gJEHm7FyjiEa3LlR0Mp2fH+sR5QvGasRShopAPj4GcT7Bf7CgLRm4MoLS4QAqmXJ
 1/lipj0HVZvP2PJ+XtqDBSwFHupYt3PTzCDvXQMjufyROkgNIqw5FHwoohKqXbbI
 OOKRIBo=
 =aZdP
 -----END PGP SIGNATURE-----

Merge tag 'sound-5.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "Well, this one became unpleasantly larger than previous pull requests,
  but it's a kind of usual pattern: now it contains a collection of ASoC
  fixes, and nothing to worry too much.

  The fixes for ASoC core (DAPM, DPCM, topology) are all small and just
  covering corner cases. The rest changes are driver-specific, many of
  which are for x86 platforms and new drivers like STM32, in addition to
  the usual fixups for HD-audio"

* tag 'sound-5.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (66 commits)
  ASoC: wcd9335: Fix missing regmap requirement
  ALSA: hda: Fix racy display power access
  ASoC: pcm: fix error handling when try_module_get() fails.
  ASoC: stm32: sai: fix master clock management
  ASoC: Intel: kbl: fix wrong number of channels
  ALSA: hda - Add two more machines to the power_save_blacklist
  ASoC: pcm: update module refcount if module_get_upon_open is set
  ASoC: core: conditionally increase module refcount on component open
  ASoC: stm32: fix sai driver name initialisation
  ASoC: topology: Use the correct dobj to free enum control values and texts
  ALSA: seq: Fix OOB-reads from strlcpy
  ASoC: intel: skylake: add remove() callback for component driver
  ASoC: cs35l35: Disable regulators on driver removal
  ALSA: xen-front: Do not use stream buffer size before it is set
  ASoC: rockchip: pdm: change dma burst to 8
  ASoC: rockchip: pdm: fix regmap_ops hang issue
  ASoC: simple-card: don't select DPCM via simple-audio-card
  ASoC: audio-graph-card: don't select DPCM via audio-graph-card
  ASoC: tlv320aic32x4: Change author's name
  ALSA: hda/realtek - Add quirk for Tuxedo XC 1509
  ...
2019-04-12 08:11:59 -07:00
Linus Torvalds f2a7346955 ACPI fix for 5.1-rc5
Fix an ACPICA issue introduced during the 4.20 development cycle and
 causing some systems to crash because of leftover operation region
 data still maintained after the operation region in question has gone
 away (Erik Schmauss).
 -----BEGIN PGP SIGNATURE-----
 
 iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAlywRPcSHHJqd0Byand5
 c29ja2kubmV0AAoJEILEb/54YlRxiG8P/1LncuzTWRjL5Xkp+tcipD4DKSEQDHr0
 /cDalNwUFp6zHyudXRwrm7WOUFItm7sxRme71eB8FpktXfzZj2Hf8eK2QJi5D8vC
 0KohHs3SVAD+8aYrIKzZzPnpeWELP4+NeSHGDc4zRSfJyevJJoCn9SJoWrZK9KsA
 hsOW/zKiGvTWyWMCkbOB/30u9D0MOrqo1qqhV+qPLryMYuQ0iIYPNCeAPaAeFM93
 elmVuwoiS/ZbtbQY1tn1ZWpMF4yy3LGd6CT+nkb8GOtyc/kboA6RRAIRbMpd/fY9
 GuFkuaTPvADopfNhycPyq22vwWy7SDBkwbKQ+wQiNnYJsqvfm99sjcboSZXLXJL8
 9V2Gv5JnWoHveT2a35xvVsxE/RBEx3uUvTT4nkO7DjMEBy9ggItG5hJm0ifVa681
 /o7aSWGw6Cg/UjX4KjlDyaTi78Ml/I6uzQNqfWCDqwVDDi0vkGrI7dcK/peC36RL
 xcpK2iaSl5T0ooc7/4XvUe1kkjJ1fNrsI6V02J4KTY39rUKuPoXpxU68uy1BPcxX
 S3jbWtChKedW2vfTbk9CN1wy2v/ZuYBYWD6H7mlNau9CzLS3fpC1L0TtSc2AYccI
 bE/hTm4UTEo8NHWymw9vHCz9QmEZ1YdUttLn/hC6Lo8lVuc2qkRKXt9yr9h8U8yY
 yPqvpLRMIBSx
 =e+lC
 -----END PGP SIGNATURE-----

Merge tag 'acpi-5.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull ACPI fix from Rafael Wysocki:
 "Fix an ACPICA issue introduced during the 4.20 development cycle and
  causing some systems to crash because of leftover operation region
  data still maintained after the operation region in question has gone
  away (Erik Schmauss)"

* tag 'acpi-5.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPICA: Namespace: remove address node from global list after method termination
2019-04-12 08:07:46 -07:00
Linus Torvalds 58890f31f9 drm i915, amd, dw-hdmi, omap, mediatek, tegra, udl fixes
-----BEGIN PGP SIGNATURE-----
 
 iQIcBAABAgAGBQJcsAlJAAoJEAx081l5xIa+ZCgP/1a9/2Kb4wKEKg4WSQCuAZm+
 mtCF2GvhN0bOk+XreUyXAboox1ldswB8woIb5pX6WjlzwRyYPT/7EKeLL4C1Fgtm
 gjFBCpJVeJJ3Vf0usMSSmXG3BNZaPIzjkZvVvDb5tMI78MjgUujzCcjAqCPRoQTC
 /wMK9qyX3mzQPrDhwF4ahc2O4gBSCQMT/xclnPDK2TJ3fJFIvWZHHBWCQgv+K9ty
 pDhqVGaR9YUn6bNjEt4l7Y5m4gK08kfB4ah/GRAYgkxKR3PmlJ0Mtd8S+niSJHk6
 4Yt/Aw+wgrY/iO/Pt/2+e8/rGBQTMvR1km+urfYdG85jRb7xYbyZZpBIRhoSNhDZ
 QLDyPPRFVWjrqzCf+o25KfKP9Be1pwBGiQx/WZ6g403mohjbzrQq9lr7OA1VrkzQ
 LhRq2lzlLtEOWVMoXZx85OrFuI+EgMQglWIxhXoNqePUMj3MoFVFIypHupu7Z36X
 Onz19FJMaY225mGl5acdrQ8N8fYagympkp/TW5Lk6N8pnPWI0/gtGkJspKJALusP
 9zJOU/iVQ5yXV5vXgYPLmAoNIwStn9sQvRsgKxa7z9FOWYoKSfO23V5N4y5gnH1f
 cTPDFe3twZD5r9kEgV+ovnfYJQ88C8LX1A//YVS7xj9tPZVDgkgWL4ZrpZGKH/ro
 OmQMQ7oG7+izulcbVcGP
 =6JCc
 -----END PGP SIGNATURE-----

Merge tag 'drm-fixes-2019-04-12' of git://anongit.freedesktop.org/drm/drm

Pull drm fixes from Dave Airlie:
 "Fixes across the driver spectrum this week, the mediatek fbdev support
  might be a bit late for this round, but I looked over it and it's not
  very large and seems like a useful feature for them.

  Otherwise the main thing is a regression fix for i915 5.0 bug that
  caused black screens on a bunch of Dell XPS 15s I think, I know at
  least Fedora is waiting for this to land, and the udl fix is also for
  a regression since 5.0 where unplugging the device would end badly.

  core:
   - make atomic hooks optional

  i915:
   - Revert a 5.0 regression where some eDP panels stopped working
   - DSI related fixes for platforms up to IceLake
   - GVT (regression fix, warning fix, use-after free fix)

  amdgpu:
   - Cursor fixes
   - missing PCI ID fix for KFD
   - XGMI fix
   - shadow buffer handling after reset fix

  udl:
   - fix unplugging device crashes.

  mediatek:
   - stabilise MT2701 HDMI support
   - fbdev support

  tegra:
   - fix for build regression in rc1.

  sun4i:
   - Allwinner A6 max freq improvements
   - null ptr deref fix

  dw-hdmi:
   - SCDC configuration improvements

  omap:
   - CEC clock management policy fix"

* tag 'drm-fixes-2019-04-12' of git://anongit.freedesktop.org/drm/drm: (32 commits)
  gpu: host1x: Fix compile error when IOMMU API is not available
  drm/i915/gvt: Roundup fb->height into tile's height at calucation fb->size
  drm/i915/dp: revert back to max link rate and lane count on eDP
  drm/i915/icl: Fix port disable sequence for mipi-dsi
  drm/i915/icl: Ungate ddi clocks before IO enable
  drm/mediatek: no change parent rate in round_rate() for MT2701 hdmi phy
  drm/mediatek: using new factor for tvdpll for MT2701 hdmi phy
  drm/mediatek: remove flag CLK_SET_RATE_PARENT for MT2701 hdmi phy
  drm/mediatek: make implementation of recalc_rate() for MT2701 hdmi phy
  drm/mediatek: fix the rate and divder of hdmi phy for MT2701
  drm/mediatek: fix possible object reference leak
  drm/i915: Get power refs in encoder->get_power_domains()
  drm/i915: Fix pipe_bpp readout for BXT/GLK DSI
  drm/amd/display: Fix negative cursor pos programming (v2)
  drm/sun4i: tcon top: Fix NULL/invalid pointer dereference in sun8i_tcon_top_un/bind
  drm/udl: add a release method and delay modeset teardown
  drm/i915/gvt: Prevent use-after-free in ppgtt_free_all_spt()
  drm/i915/gvt: Annotate iomem usage
  drm/sun4i: DW HDMI: Lower max. supported rate for H6
  Revert "Documentation/gpu/meson: Remove link to meson_canvas.c"
  ...
2019-04-12 08:04:01 -07:00
Will Deacon 045afc2412 arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result value
Rather embarrassingly, our futex() FUTEX_WAKE_OP implementation doesn't
explicitly set the return value on the non-faulting path and instead
leaves it holding the result of the underlying atomic operation. This
means that any FUTEX_WAKE_OP atomic operation which computes a non-zero
value will be reported as having failed. Regrettably, I wrote the buggy
code back in 2011 and it was upstreamed as part of the initial arm64
support in 2012.

The reasons we appear to get away with this are:

  1. FUTEX_WAKE_OP is rarely used and therefore doesn't appear to get
     exercised by futex() test applications

  2. If the result of the atomic operation is zero, the system call
     behaves correctly

  3. Prior to version 2.25, the only operation used by GLIBC set the
     futex to zero, and therefore worked as expected. From 2.25 onwards,
     FUTEX_WAKE_OP is not used by GLIBC at all.

Fix the implementation by ensuring that the return value is either 0
to indicate that the atomic operation completed successfully, or -EFAULT
if we encountered a fault when accessing the user mapping.

Cc: <stable@kernel.org>
Fixes: 6170a97460 ("arm64: Atomic operations")
Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-12 15:04:33 +01:00
Joerg Roedel 3c677d2062 iommu/amd: Set exclusion range correctly
The exlcusion range limit register needs to contain the
base-address of the last page that is part of the range, as
bits 0-11 of this register are treated as 0xfff by the
hardware for comparisons.

So correctly set the exclusion range in the hardware to the
last page which is _in_ the range.

Fixes: b2026aa2dc ('x86, AMD IOMMU: add functions for programming IOMMU MMIO space')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-04-12 12:59:45 +02:00
Miguel Ojeda f16628d6e8 clang-format: Update with the latest for_each macro list
Re-run the shell fragment that generated the original list now that
there are two dozens of new entries after v5.1's merge window.

Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
2019-04-12 12:49:54 +02:00
Peter Zijlstra 1d54ad9440 perf/core: Fix perf_event_disable_inatomic() race
Thomas-Mich Richter reported he triggered a WARN()ing from event_function_local()
on his s390. The problem boils down to:

	CPU-A				CPU-B

	perf_event_overflow()
	  perf_event_disable_inatomic()
	    @pending_disable = 1
	    irq_work_queue();

	sched-out
	  event_sched_out()
	    @pending_disable = 0

					sched-in
					perf_event_overflow()
					  perf_event_disable_inatomic()
					    @pending_disable = 1;
					    irq_work_queue(); // FAILS

	irq_work_run()
	  perf_pending_event()
	    if (@pending_disable)
	      perf_event_disable_local(); // WHOOPS

The problem exists in generic, but s390 is particularly sensitive
because it doesn't implement arch_irq_work_raise(), nor does it call
irq_work_run() from it's PMU interrupt handler (nor would that be
sufficient in this case, because s390 also generates
perf_event_overflow() from pmu::stop). Add to that the fact that s390
is a virtual architecture and (virtual) CPU-A can stall long enough
for the above race to happen, even if it would self-IPI.

Adding a irq_work_sync() to event_sched_in() would work for all hardare
PMUs that properly use irq_work_run() but fails for software PMUs.

Instead encode the CPU number in @pending_disable, such that we can
tell which CPU requested the disable. This then allows us to detect
the above scenario and even redirect the IPI to make up for the failed
queue.

Reported-by: Thomas-Mich Richter <tmricht@linux.ibm.com>
Tested-by: Thomas Richter <tmricht@linux.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-04-12 08:55:55 +02:00
Eric Dumazet e305845096 dctcp: more accurate tracking of packets delivery
After commit e21db6f69a ("tcp: track total bytes delivered with ECN CE marks")
core TCP stack does a very good job tracking ECN signals.

The "sender's best estimate of CE information" Yuchung mentioned in his
patch is indeed the best we can do.

DCTCP can use tp->delivered_ce and tp->delivered to not duplicate the logic,
and use the existing best estimate.

This solves some problems, since current DCTCP logic does not deal with losses
and/or GRO or ack aggregation very well.

This also removes a dubious use of inet_csk(sk)->icsk_ack.rcv_mss
(this should have been tp->mss_cache), and a 64 bit divide.

Finally, we can see that the DCTCP logic, calling dctcp_update_alpha() for
every ACK could be done differently, calling it only once per RTT.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Soheil Hassas Yeganeh <soheil@google.com>
Cc: Florian Westphal <fw@strlen.de>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Lawrence Brakmo <brakmo@fb.com>
Cc: Abdul Kabbani <akabbani@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-11 21:31:03 -07:00
Dave Airlie 788f07ebe0 - Revert back to max link rate and lane count on eDP.
- DSI related fixes for all platforms including Ice Lake.
 - GVT Fixes including one vGPU display plane size regression fix,
 one for preventing use-after-free in ppgtt shadow free function,
 and another warning fix for iomem access annotation.
 -----BEGIN PGP SIGNATURE-----
 
 iQEcBAABAgAGBQJcr9SYAAoJEPpiX2QO6xPKKhMIALQRWEEeTW4gEdwEx4CDnbSn
 PfzY6TxE5smbqqWXMYZizozGjeN9xKfBnIdloQtBnPyAgJxT43HDGct3JS5f6Mqa
 0riF49WKI7uc1EFqV+J3AyhGua/EB9uuaK0SmBaqQvsUfKV4goLBEVsIE+XFYTPJ
 hwQ7srCzbAcLcDno3BmrCvQg8Uz6IiWwMoq0pEtWi9vctJQWtsgOkT8THvWFUW2r
 vELl6sZPqWquYXR2/+W62zi4CXi/ABIdcxe4fiortZd28Sw6MROCmSl7aTxAjO9p
 8f2oJBbKV0CtvtOMmUdTiJ+MFnQrSrGmrEt2slb3qfwWJHEClT/wBOT6JrBdeHs=
 =qXqh
 -----END PGP SIGNATURE-----

Merge tag 'drm-intel-fixes-2019-04-11' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

- Revert back to max link rate and lane count on eDP.
- DSI related fixes for all platforms including Ice Lake.
- GVT Fixes including one vGPU display plane size regression fix,
one for preventing use-after-free in ppgtt shadow free function,
and another warning fix for iomem access annotation.

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190411235832.GA6476@intel.com
2019-04-12 13:39:32 +10:00
Jason Yan a89afe58f1 block: fix the return errno for direct IO
If the last bio returned is not dio->bio, the status of the bio will
not assigned to dio->bio if it is error. This will cause the whole IO
status wrong.

    ksoftirqd/21-117   [021] ..s.  4017.966090:   8,0    C   N 4883648 [0]
          <idle>-0     [018] ..s.  4017.970888:   8,0    C  WS 4924800 + 1024 [0]
          <idle>-0     [018] ..s.  4017.970909:   8,0    D  WS 4935424 + 1024 [<idle>]
          <idle>-0     [018] ..s.  4017.970924:   8,0    D  WS 4936448 + 321 [<idle>]
    ksoftirqd/21-117   [021] ..s.  4017.995033:   8,0    C   R 4883648 + 336 [65475]
    ksoftirqd/21-117   [021] d.s.  4018.001988: myprobe1: (blkdev_bio_end_io+0x0/0x168) bi_status=7
    ksoftirqd/21-117   [021] d.s.  4018.001992: myprobe: (aio_complete_rw+0x0/0x148) x0=0xffff802f2595ad80 res=0x12a000 res2=0x0

We always have to assign bio->bi_status to dio->bio.bi_status because we
will only check dio->bio.bi_status when we return the whole IO to
the upper layer.

Fixes: 542ff7bf18 ("block: new direct I/O implementation")
Cc: stable@vger.kernel.org
Cc: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-04-11 21:22:21 -06:00
Linus Torvalds 2d06b23581 for-5.1-rc4-tag
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEE8rQSAMVO+zA4DBdWxWXV+ddtWDsFAlyveOkACgkQxWXV+ddt
 WDvb3g//RTIy+8o1PwPihGT9z0wWaFTxJF9Ea3SDzgMVsOaWzZIM29Q0XCwGyR5s
 xdwJlNrum4eJwcLRuvvZtZ6e9h6vdgmNxi7ULem0r2ik58rvgZf3TQp/t78qMMLo
 Z8Qp/jQPHOOhwGURFsUd2TwCYQ+3yyEhzoObDDQ5OAyeCgneLe2hLNvyMMF7YNkl
 joaWY5iAwDY61UaRxggwx8OI7TkhCA/ZA27zyjc6oomCQglIM/KmdvmjHpiBs0j/
 1Ij4SDmSo9nqGES/SfubW/l3fpg42hoQWBMuI3/WLr3CBKN08wuRe+BKoDmVyoex
 eVTy3+AnBp6KsjyOmN9h5Am+r1lyToJ1ZpsjkKQzo5SRlYC/SA0oFlxhHKygoft6
 tEEJf+hbySiod/ZX0KItS6Myo1xsHsX8LnidAO+7pK0S5e5D59QPXtw6oJIp0JX/
 kAKrng6bX3+7bSrF8h62nKqpFq/NUTjF8zxB6gwMwnrtroU36r8AFE4+bcyX5Z5g
 +JoJcZ9VFsFcA4GCTzYWTYQ2RfCU6Vnbvh4wTLHiR+IDvbkNFxMUE4z5O+fwqhkl
 6nv8G2EgK3ORZS/4mNAjmanB71gPwbovhTQhju8LQGEmlmwBrF1mQ+YhrBlMrMv9
 XspCzNktqzbGj70tMPbPSB2A5H9oi+5Oabzq2MPFUVBkA9ztpSA=
 =fYo9
 -----END PGP SIGNATURE-----

Merge tag 'for-5.1-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux

Pull btrfs fixes from David Sterba:

 - fix parsing of compression algorithm when set as a inode property,
   this could end up with eg. 'zst' or 'zli' in the value

 - don't allow trim on a filesystem with unreplayed log, this could
   cause data loss if there are pending updates to the block groups that
   would not be subject to trim after replay

* tag 'for-5.1-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
  btrfs: prop: fix vanished compression property after failed set
  btrfs: prop: fix zstd compression parameter validation
  Btrfs: do not allow trimming when a fs is mounted with the nologreplay option
2019-04-11 14:19:02 -07:00
David Ahern a5f622984a selftests: fib_tests: Fix 'Command line is not complete' errors
A couple of tests are verifying a route has been removed. The helper
expects the prefix as the first part of the expected output. When
checking that a route has been deleted the prefix is empty leading
to an invalid ip command:

  $ ip ro ls match
  Command line is not complete. Try option "help"

Fix by moving the comparison of expected output and output to a new
function that is used by both check_route and check_route6. Use the
new helper for the 2 checks on route removal.

Also, remove the reset of 'set -x' in route_setup which overrides the
user managed setting.

Fixes: d69faad765 ("selftests: fib_tests: Add prefix route tests with metric")
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-11 14:17:59 -07:00
YueHaibing d3706566ae net: netrom: Fix error cleanup path of nr_proto_init
Syzkaller report this:

BUG: unable to handle kernel paging request at fffffbfff830524b
PGD 237fe8067 P4D 237fe8067 PUD 237e64067 PMD 1c9716067 PTE 0
Oops: 0000 [#1] SMP KASAN PTI
CPU: 1 PID: 4465 Comm: syz-executor.0 Not tainted 5.0.0+ #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
RIP: 0010:__list_add_valid+0x21/0xe0 lib/list_debug.c:23
Code: 8b 0c 24 e9 17 fd ff ff 90 55 48 89 fd 48 8d 7a 08 53 48 89 d3 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 48 83 ec 08 <80> 3c 02 00 0f 85 8b 00 00 00 48 8b 53 08 48 39 f2 75 35 48 89 f2
RSP: 0018:ffff8881ea2278d0 EFLAGS: 00010282
RAX: dffffc0000000000 RBX: ffffffffc1829250 RCX: 1ffff1103d444ef4
RDX: 1ffffffff830524b RSI: ffffffff85659300 RDI: ffffffffc1829258
RBP: ffffffffc1879250 R08: fffffbfff0acb269 R09: fffffbfff0acb269
R10: ffff8881ea2278f0 R11: fffffbfff0acb268 R12: ffffffffc1829250
R13: dffffc0000000000 R14: 0000000000000008 R15: ffffffffc187c830
FS:  00007fe0361df700(0000) GS:ffff8881f7300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff830524b CR3: 00000001eb39a001 CR4: 00000000007606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 __list_add include/linux/list.h:60 [inline]
 list_add include/linux/list.h:79 [inline]
 proto_register+0x444/0x8f0 net/core/sock.c:3375
 nr_proto_init+0x73/0x4b3 [netrom]
 ? 0xffffffffc1628000
 ? 0xffffffffc1628000
 do_one_initcall+0xbc/0x47d init/main.c:887
 do_init_module+0x1b5/0x547 kernel/module.c:3456
 load_module+0x6405/0x8c10 kernel/module.c:3804
 __do_sys_finit_module+0x162/0x190 kernel/module.c:3898
 do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462e99
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fe0361dec58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
RDX: 0000000000000000 RSI: 0000000020000100 RDI: 0000000000000003
RBP: 00007fe0361dec70 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe0361df6bc
R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
Modules linked in: netrom(+) ax25 fcrypt pcbc af_alg arizona_ldo1 v4l2_common videodev media v4l2_dv_timings hdlc ide_cd_mod snd_soc_sigmadsp_regmap snd_soc_sigmadsp intel_spi_platform intel_spi mtd spi_nor snd_usbmidi_lib usbcore lcd ti_ads7950 hi6421_regulator snd_soc_kbl_rt5663_max98927 snd_soc_hdac_hdmi snd_hda_ext_core snd_hda_core snd_soc_rt5663 snd_soc_core snd_pcm_dmaengine snd_compress snd_soc_rl6231 mac80211 rtc_rc5t583 spi_slave_time leds_pwm hid_gt683r hid industrialio_triggered_buffer kfifo_buf industrialio ir_kbd_i2c rc_core led_class_flash dwc_xlgmac snd_ymfpci gameport snd_mpu401_uart snd_rawmidi snd_ac97_codec snd_pcm ac97_bus snd_opl3_lib snd_timer snd_seq_device snd_hwdep snd soundcore iptable_security iptable_raw iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_vti ip_gre ipip sit tunnel4 ip_tunnel hsr veth netdevsim vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon dummy team bonding vcan
 bridge stp llc ip6_gre gre ip6_tunnel tunnel6 tun joydev mousedev ppdev tpm kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ide_pci_generic piix aesni_intel aes_x86_64 crypto_simd cryptd glue_helper ide_core psmouse input_leds i2c_piix4 serio_raw intel_agp intel_gtt ata_generic agpgart pata_acpi parport_pc rtc_cmos parport floppy sch_fq_codel ip_tables x_tables sha1_ssse3 sha1_generic ipv6 [last unloaded: rxrpc]
Dumping ftrace buffer:
   (ftrace buffer empty)
CR2: fffffbfff830524b
---[ end trace 039ab24b305c4b19 ]---

If nr_proto_init failed, it may forget to call proto_unregister,
tiggering this issue.This patch rearrange code of nr_proto_init
to avoid such issues.

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-11 13:59:49 -07:00