Changes

signal: Restore the stop PTRACE_EVENT_EXIT
In the middle of do_exit() there is there is a call
"ptrace_event(PTRACE_EVENT_EXIT, code);" That call places the process in
TACKED_TRACED aka "(TASK_WAKEKILL | __TASK_TRACED)" and waits for for
the debugger to release the task or SIGKILL to be delivered.
Skipping past dequeue_signal when we know a fatal signal has already 
been delivered resulted in SIGKILL remaining pending and TIF_SIGPENDING
remaining set.  This in turn caused the scheduler to not sleep in
PTACE_EVENT_EXIT as it figured a fatal signal was pending.  This also
caused ptrace_freeze_traced in ptrace_check_attach to fail because it
left a per thread SIGKILL pending which is what fatal_signal_pending
tests for.
This difference in signal state caused strace to report strace: Exit of
unknown pid NNNNN ignored
Therefore update the signal handling state like dequeue_signal would
when removing a per thread SIGKILL, by removing SIGKILL from the per
thread signal mask and clearing TIF_SIGPENDING.
Acked-by: Oleg Nesterov <oleg@redhat.com> Reported-by: Oleg Nesterov
<oleg@redhat.com> Reported-by: Ivan Delalande <colona@arista.com> Cc:
stable@vger.kernel.org Fixes: 35634ffa1751 ("signal: Always notice
exiting tasks") Signed-off-by: "Eric W. Biederman"
<ebiederm@xmission.com>

drm/amdgpu/psp11: TA firmware is optional (v3)
Don't warn or fail if it's missing.
v2: handle xgmi case more gracefully. v3: handle older kernels properly
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Tested-by: James Zhu
<James.Zhu@amd.com> Signed-off-by: Alex Deucher
<alexander.deucher@amd.com>

netfilter: nft_compat: use-after-free when deleting targets
Fetch pointer to module before target object is released.
Fixes: 29e3880109e3 ("netfilter: nf_tables: fix use-after-free when
deleting compat expressions") Fixes: 0ca743a55991 ("netfilter:
nf_tables: add compatibility layer for x_tables") Signed-off-by: Pablo
Neira Ayuso <pablo@netfilter.org>

KVM: nVMX: Restore a preemption timer consistency check
A recently added preemption timer consistency check was unintentionally 
dropped when the consistency checks were being reorganized to match the 
SDM's ordering.
Fixes: 461b4ba4c7ad ("KVM: nVMX: Move the checks for VM-Execution
Control Fields to a separate helper function") Cc: Krish Sadhukhan
<krish.sadhukhan@oracle.com> Signed-off-by: Sean Christopherson
<sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini
<pbonzini@redhat.com>

net/mlx5e: Fix NULL pointer derefernce in set channels error flow
New channels are applied to the priv channels only after they are
successfully opened. Then, the indirection table should be built 
according to the new number of channels. Currently, such build is
preformed independently of whether the channels opening is successful,
and is not reverted on failure.
The bug is caused due to removal of rss params from channels struct and
moving it to priv struct. That change cause to independency between 
channels and rss params. This causes a crash on a later point, when
accessing rqn of a non existing channel.
This patch fixes it by moving the indirection table build right before 
switching the priv channels to new channels struct, after the new set of 
channels was successfully opened.
Fixes: bbeb53b8b2c9 ("net/mlx5e: Move RSS params to a dedicated struct") 
Signed-off-by: Maria Pasechnik <mariap@mellanox.com> Reviewed-by: Tariq
Toukan <tariqt@mellanox.com> Signed-off-by: Saeed Mahameed
<saeedm@mellanox.com>

net/mlx5: No command allowed when command interface is not ready
When EEH is injected and PCI bus stalls, mlx5's pci error detect 
function is called to deactivate the command interface and tear down the
device. The issue is that there can be a thread that already passed
MLX5_DEVICE_STATE_INTERNAL_ERROR check, it will send the command and
stuck in the wait_func.
Solution: Add function mlx5_cmd_flush to disable command interface and
clear all the pending commands. When device state is set to 
MLX5_DEVICE_STATE_INTERNAL_ERROR, call mlx5_cmd_flush to ensure all 
pending threads waiting for firmware commands completion are terminated.
Fixes: c1d4d2e92ad6 ("net/mlx5: Avoid calling sleeping function by the
health poll thread") Signed-off-by: Huy Nguyen <huyn@mellanox.com> 
Reviewed-by: Daniel Jurgens <danielj@mellanox.com> Signed-off-by: Saeed
Mahameed <saeedm@mellanox.com>

net/mlx5: Fix a compilation warning in events.c
Eliminate the following compilation warning:
drivers/net/ethernet/mellanox/mlx5/core/events.c: warning: 'error_str' 
may be used uninitialized in this function [-Wuninitialized]:  => 238:3
Fixes: c2fb3db22d35 ("net/mlx5: Rework handling of port module events") 
Signed-off-by: Tariq Toukan <tariqt@mellanox.com> Reviewed-by: Mikhael
Goikhman <migo@mellanox.com> Signed-off-by: Saeed Mahameed
<saeedm@mellanox.com>

net/mlx5e: XDP, fix redirect resources availability check
Currently mlx5 driver creates xdp redirect hw queues unconditionally on 
netdevice open, This is great until someone starts redirecting XDP
traffic via ndo_xdp_xmit on mlx5 device and changes the device
configuration at the same time, this might cause crashes, since the
other device's napi is not aware of the mlx5 state change (resources
un-availability).
To fix this we must synchronize with other devices napi's on the system. 
Added a new flag under mlx5e_priv to determine XDP TX resources are 
available, set/clear it up when necessary and use synchronize_rcu() when
the flag is turned off, so other napi's are in-sync with it, before we
actually cleanup the hw resources.
The flag is tested prior to committing to transmit on mlx5e_xdp_xmit,
and it is sufficient to determine if it safe to transmit or not. The
other two internal flags (MLX5E_STATE_OPENED and MLX5E_SQ_STATE_ENABLED)
become unnecessary. Thus, they are removed from data path.
Fixes: 58b99ee3e3eb ("net/mlx5e: Add support for XDP_REDIRECT in
device-out side") Reported-by: Toke Høiland-Jørgensen <toke@redhat.com> 
Reviewed-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: Saeed
Mahameed <saeedm@mellanox.com>

sctp: call gso_reset_checksum when computing checksum in
sctp_gso_segment
Jianlin reported a panic when running sctp gso over gre over vlan
device:
  [   84.772930] RIP: 0010:do_csum+0x6d/0x170
 [   84.790605] Call Trace:
 [   84.791054]  csum_partial+0xd/0x20
 [   84.791657]  gre_gso_segment+0x2c3/0x390
 [   84.792364]  inet_gso_segment+0x161/0x3e0
 [   84.793071]  skb_mac_gso_segment+0xb8/0x120
 [   84.793846]  __skb_gso_segment+0x7e/0x180
 [   84.794581]  validate_xmit_skb+0x141/0x2e0
 [   84.795297]  __dev_queue_xmit+0x258/0x8f0
 [   84.795949]  ? eth_header+0x26/0xc0
 [   84.796581]  ip_finish_output2+0x196/0x430
 [   84.797295]  ? skb_gso_validate_network_len+0x11/0x80
 [   84.798183]  ? ip_finish_output+0x169/0x270
 [   84.798875]  ip_output+0x6c/0xe0
 [   84.799413]  ? ip_append_data.part.50+0xc0/0xc0
 [   84.800145]  iptunnel_xmit+0x144/0x1c0
 [   84.800814]  ip_tunnel_xmit+0x62d/0x930 [ip_tunnel]
 [   84.801699]  gre_tap_xmit+0xac/0xf0 [ip_gre]
 [   84.802395]  dev_hard_start_xmit+0xa5/0x210
 [   84.803086]  sch_direct_xmit+0x14f/0x340
 [   84.803733]  __dev_queue_xmit+0x799/0x8f0
 [   84.804472]  ip_finish_output2+0x2e0/0x430
 [   84.805255]  ? skb_gso_validate_network_len+0x11/0x80
 [   84.806154]  ip_output+0x6c/0xe0
 [   84.806721]  ? ip_append_data.part.50+0xc0/0xc0
 [   84.807516]  sctp_packet_transmit+0x716/0xa10 [sctp]
 [   84.808337]  sctp_outq_flush+0xd7/0x880 [sctp]
It was caused by SKB_GSO_CB(skb)->csum_start not set in
sctp_gso_segment. sctp_gso_segment() calls skb_segment() with 'feature |
NETIF_F_HW_CSUM', which causes SKB_GSO_CB(skb)->csum_start not to be set
in skb_segment().
For TCP/UDP, when feature supports HW_CSUM, CHECKSUM_PARTIAL will be set 
and gso_reset_checksum will be called to set
SKB_GSO_CB(skb)->csum_start.
So SCTP should do the same as TCP/UDP, to call gso_reset_checksum() when 
computing checksum in sctp_gso_segment.
Reported-by: Jianlin Shi <jishi@redhat.com> Signed-off-by: Xin Long
<lucien.xin@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> 
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> 
Signed-off-by: David S. Miller <davem@davemloft.net>

sctp: set stream ext to NULL after freeing it in
sctp_stream_outq_migrate
In sctp_stream_init(), after sctp_stream_outq_migrate() freed the 
surplus streams' ext, but sctp_stream_alloc_out() returns -ENOMEM, 
stream->outcnt will not be set to 'outcnt'.
With the bigger value on stream->outcnt, when closing the assoc and 
freeing its streams, the ext of those surplus streams will be freed 
again since those stream exts were not set to NULL after freeing in 
sctp_stream_outq_migrate(). Then the invalid-free issue reported by 
syzbot would be triggered.
We fix it by simply setting them to NULL after freeing.
Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations") 
Reported-by: syzbot+58e480e7b28f2d890bfd@syzkaller.appspotmail.com 
Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Neil Horman
<nhorman@tuxdriver.com> Acked-by: Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

net: phy: fix interrupt handling in non-started states
phylib enables interrupts before phy_start() has been called, and if we
receive an interrupt in a non-started state, the interrupt handler 
returns IRQ_NONE. This causes problems with at least one Marvell chip as
reported by Andrew. Fix this by handling interrupts the same as in
phy_mac_interrupt(), basically always running the phylib state machine.
It knows when it has to do something and when not. This change allows to
handle interrupts gracefully even if they occur in a non-started state.
Fixes: 2b3e88ea6528 ("net: phy: improve phy state checking") 
Reported-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Heiner Kallweit
<hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> 
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>

dsa: mv88e6xxx: Ensure all pending interrupts are handled prior to exit
The GPIO interrupt controller on the espressobin board only supports
edge interrupts. If one enables the use of hardware interrupts in the
device tree for the 88E6341, it is possible to miss an edge.  When this
happens, the INTn pin on the Marvell switch is stuck low and no further
interrupts occur.
I found after adding debug statements to mv88e6xxx_g1_irq_thread_work()
that there is a race in handling device interrupts (e.g. PHY link
interrupts).  Some interrupts are directly cleared by reading the Global
1 status register.  However, the device interrupt flag, for example, is
not cleared until all the unmasked SERDES and PHY ports are serviced. 
This is done by reading the relevant SERDES and PHY status register.
The code only services interrupts whose status bit is set at the time of
reading its status register.  If an interrupt event occurs after its
status is read and before all interrupts are serviced, then this event
will not be serviced and the INTn output pin will remain low.
This is not a problem with polling or level interrupts since the handler
will be called again to process the event.  However, it's a big problem
when using level interrupts.
The fix presented here is to add a loop around the code servicing switch
interrupts.  If any pending interrupts remain after the current set has
been handled, we loop and process the new set.  If there are no pending
interrupts after servicing, we are sure that INTn has gone high and we
will get an edge when a new event occurs.
Tested on espressobin board.
Fixes: dc30c35be720 ("net: dsa: mv88e6xxx: Implement interrupt
support.") Signed-off-by:  John David Anglin <dave.anglin@bell.net> 
Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller
<davem@davemloft.net>

net: fix possible overflow in __sk_mem_raise_allocated()
With many active TCP sockets, fat TCP sockets could fool
__sk_mem_raise_allocated() thanks to an overflow.
They would increase their share of the memory, instead of decreasing it.
Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David
S. Miller <davem@davemloft.net>

net: dsa: bcm_sf2: potential array overflow in bcm_sf2_sw_suspend()
The value of ->num_ports comes from bcm_sf2_sw_probe() and it is less 
than or equal to DSA_MAX_PORTS.  The ds->ports[] array is used inside 
the dsa_is_user_port() and dsa_is_cpu_port() functions.  The ds->ports[] 
array is allocated in dsa_switch_alloc() and it has ds->num_ports 
elements so this leads to a static checker warning about a potential out 
of bounds read.
Fixes: 8cfa94984c9c ("net: dsa: bcm_sf2: add suspend/resume callbacks") 
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

ALSA: hda/realtek - Headset microphone and internal speaker support for
System76 oryp5
On the System76 Oryx Pro (oryp5), there is a headset microphone input 
attached to 0x19 that does not have a jack detect. In order to get it 
working, the pin configuration needs to be set correctly, and the 
ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC fixup needs to be applied. This is 
similar to the MIC_NO_PRESENCE fixups for some Dell laptops, except we 
have a separate microphone jack that is already configured correctly.
Since the ALC1220 does not have a fixup similar to 
ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC, I have exposed the fixup from the 
ALC269 in a way that it can be accessed from the 
alc1220_fixup_system76_oryp5 function. In addition, the 
alc1220_fixup_clevo_p950 needs to be applied to gain speaker output.
Signed-off-by: Jeremy Soller <jeremy@system76.com> Cc:
<stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda/realtek: Disable PC beep in passthrough on alc285
It is reported that there's a constant background "hum/whitenoise" in
the headset on the Lenovo X1 machines with the codec alc285, and it is
confirmed that if we run the command below, the noise will stop.
sudo hda-verb /dev/snd/hwC0D0 0x1d SET_PIN_WIDGET_CONTROL 0x0
Then I consulted this issue with Kailang, he told me the pin 0x1d on 
this codec is used for PC beep in, the noise probably comes from this 
pin and we can also disable the PC beep in passthrough, then the PC beep
in will not affect other sound playback.
Fixes: c4cfcf6f4297 ("ALSA: hda/realtek - fix the pop noise on headphone
for lenovo laptops") Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1660581 Cc:
<stable@vger.kernel.org> Signed-off-by: Kailang Yang
<kailang@realtek.com> Signed-off-by: Hui Wang <hui.wang@canonical.com> 
Signed-off-by: Takashi Iwai <tiwai@suse.de>

gpio: pxa: avoid attempting to set pin direction via pinctrl on MMP2
Similarly to PXA3xx, pinctrl-single can't set pin direction on MMP2
either. See also: commit 9dabfdd84bdfa ("gpio: pxa: disable pinctrl
calls for PXA3xx")
Cc: stable@vger.kernel.org Fixes: a770d946371e ("gpio: pxa: add pin
control gpio direction and request") Signed-off-by: Lubomir Rintel
<lkundrak@v3.sk> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>

x86/CPU: Add Icelake model number
Add the CPUID model number of Icelake (ICL) mobile processors to the 
Intel family list. Icelake U/Y series uses model number 0x7E.
Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com> 
Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Shevchenko
<andriy.shevchenko@linux.intel.com> Cc: Dave Hansen
<dave.hansen@linux.intel.com> Cc: "David E. Box" <david.e.box@intel.com> 
Cc: dvhart@infradead.org Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo
Molnar <mingo@redhat.com> Cc: Kan Liang <kan.liang@linux.intel.com> Cc:
Peter Zijlstra <peterz@infradead.org> Cc:
platform-driver-x86@vger.kernel.org Cc: Qiuxu Zhuo
<qiuxu.zhuo@intel.com> Cc: Srinivas Pandruvada
<srinivas.pandruvada@linux.intel.com> Cc: Thomas Gleixner
<tglx@linutronix.de> Cc: x86-ml <x86@kernel.org> Link:
https://lkml.kernel.org/r/20190214115712.19642-2-rajneesh.bhardwaj@linux.intel.com

KVM: x86: Recompute PID.ON when clearing PID.SN
Some Posted-Interrupts from passthrough devices may be lost or 
overwritten when the vCPU is in runnable state.
The SN (Suppress Notification) of PID (Posted Interrupt Descriptor) will 
be set when the vCPU is preempted (vCPU in KVM_MP_STATE_RUNNABLE state
but not running on physical CPU). If a posted interrupt comes at this
time, the irq remapping facility will set the bit of PIR (Posted
Interrupt Requests) but not ON (Outstanding Notification).  Then, the
interrupt will not be seen by KVM, which always expects PID.ON=1 if
PID.PIR=1 as documented in the Intel processor SDM but not in the VT-d
specification. To fix this, restore the invariant after PID.SN is
cleared.
Signed-off-by: Luwei Kang <luwei.kang@intel.com> Signed-off-by: Paolo
Bonzini <pbonzini@redhat.com>

kvm: vmx: Fix entry number check for add_atomic_switch_msr()
Commit ca83b4a7f2d068da79a0 ("x86/KVM/VMX: Add find_msr() helper
function") introduces the helper function find_msr(), which returns
-ENOENT when not find the msr in vmx->msr_autoload.guest/host. Correct
checking contion of no more available entry in vmx->msr_autoload.
Fixes: ca83b4a7f2d0 ("x86/KVM/VMX: Add find_msr() helper function") Cc:
stable@vger.kernel.org Signed-off-by: Xiaoyao Li
<xiaoyao.li@linux.intel.com> Signed-off-by: Paolo Bonzini
<pbonzini@redhat.com>

selftests: fix timestamping Makefile
The clean target in the makefile conflicts with the generic kselftests
lib.mk, and fails to properly remove the compiled test programs.
Remove the redundant rule, the TEST_GEN_FILES will be already removed by
the CLEAN macro in lib.mk.
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com> Acked-by: Shuah
Khan <shuah@kernel.org> Signed-off-by: David S. Miller
<davem@davemloft.net>

net: phy: don't use locking in phy_is_started
Russell suggested to remove the locking from phy_is_started() because 
the read is atomic anyway and actually the locking may be more 
misleading.
Fixes: 2b3e88ea6528 ("net: phy: improve phy state checking") 
Suggested-by: Russell King - ARM Linux admin <linux@armlinux.org.uk> 
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

net: phy: fix potential race in the phylib state machine
Russell reported the following race in the phylib state machine
(quoting from his mail):
if (phy_polling_mode(phydev) && phy_is_started(phydev))
phy_queue_state_machine(phydev, PHY_STATE_TIME);
state = PHY_UP thread 0			thread 1
			phy_disconnect()
			+-phy_is_started() phy_is_started()                |
			`-phy_stop()
			  +-phydev->state = PHY_HALTED
			  `-phy_stop_machine()
			    `-cancel_delayed_work_sync() 
phy_queue_state_machine()
`-mod_delayed_work()
At this point, the phydev->state_queue() has been added back onto the 
system workqueue despite phy_stop_machine() having been called and 
cancel_delayed_work_sync() called on it.
Fix this by protecting the complete operation in thread 0.
Fixes: 2b3e88ea6528 ("net: phy: improve phy state checking") 
Reported-by: Russell King - ARM Linux admin <linux@armlinux.org.uk> 
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

mm: page_alloc: fix ref bias in page_frag_alloc() for 1-byte allocs
The basic idea behind ->pagecnt_bias is: If we pre-allocate the maximum 
number of references that we might need to create in the fastpath later, 
the bump-allocation fastpath only has to modify the non-atomic bias
value that tracks the number of extra references we hold instead of the
atomic refcount. The maximum number of allocations we can serve (under
the assumption that no allocation is made with size 0) is nc->size, so
that's the bias used.
However, even when all memory in the allocation has been given away, a 
reference to the page is still held; and in the `offset < 0` slowpath,
the page may be reused if everyone else has dropped their references. 
This means that the necessary number of references is actually
`nc->size+1`.
Luckily, from a quick grep, it looks like the only path that can call 
page_frag_alloc(fragsz=1) is TAP with the IFF_NAPI_FRAGS flag, which 
requires CAP_NET_ADMIN in the init namespace and is only intended to be 
used for kernel testing and fuzzing.
To test for this issue, put a `WARN_ON(page_ref_count(page) == 0)` in
the
`offset < 0` path, below the virt_to_page() call, and then repeatedly
call writev() on a TAP device with
IFF_TAP|IFF_NO_PI|IFF_NAPI_FRAGS|IFF_NAPI, with a vector consisting of
15 elements containing 1 byte each.
Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: David S.
Miller <davem@davemloft.net>

net: hns: Fix object reference leaks in hns_dsaf_roce_reset()
The of_find_device_by_node() takes a reference to the underlying device 
structure, we should release that reference.
Signed-off-by: Huang Zijiang <huang.zijiang@zte.com.cn> Signed-off-by:
David S. Miller <davem@davemloft.net>

Revert "nfsd4: return default lease period"
This reverts commit d6ebf5088f09472c1136cd506bdc27034a6763f8.
I forgot that the kernel's default lease period should never be 
decreased!
After a kernel upgrade, the kernel has no way of knowing on its own what 
the previous lease time was.  Unless userspace tells it otherwise, it 
will assume the previous lease period was the same.
So if we decrease this value in a kernel upgrade, we end up enforcing a 
grace period that's too short, and clients will fail to reclaim state in 
time.  Symptoms may include EIO and log messages like "NFS: 
nfs4_reclaim_open_state: Lock reclaim failed!"
There was no real justification for the lease period decrease anyway.
Reported-by: Donald Buczek <buczek@molgen.mpg.de> Fixes: d6ebf5088f09
"nfsd4: return default lease period" Cc: stable@vger.kernel.org 
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

net: ethernet: freescale: set FEC ethtool regs version
Currently the ethtool_regs version is set to 0 for FEC devices.
Use this field to store the register dump version exposed by the kernel.
The choosen version 2 corresponds to the kernel compile test:
        #if defined(CONFIG_M523x) || defined(CONFIG_M527x)
       || defined(CONFIG_M528x) || defined(CONFIG_M520x)
       || defined(CONFIG_M532x) || defined(CONFIG_ARM)
       || defined(CONFIG_ARM64) || defined(CONFIG_COMPILE_TEST)
and version 1 corresponds to the opposite. Binaries of ethtool unaware 
of this version will dump the whole set as usual.
Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>

Revert "gfs2: read journal in large chunks to locate the head"
This reverts commit 2a5f14f279f59143139bcd1606903f2f80a34241.
This patch causes xfstests generic/311 to fail. Reverting this for now
until we have a proper fix.
Signed-off-by: Abhi Das <adas@redhat.com> Signed-off-by: Bob Peterson
<rpeterso@redhat.com> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

Revert "exec: load_script: don't blindly truncate shebang string"
This reverts commit 8099b047ecc431518b9bb6bdbba3549bbecdc343.
It turns out that people do actually depend on the shebang string being 
truncated, and on the fact that an interpreter (like perl) will often 
just re-interpret it entirely to get the full argument list.
Reported-by: Samuel Dionne-Riel <samuel@dionne-riel.com> Acked-by: Kees
Cook <keescook@chromium.org> Cc: Oleg Nesterov <oleg@redhat.com> 
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

dm thin: fix bug where bio that overwrites thin block ignores FUA
When provisioning a new data block for a virtual block, either because 
the block was previously unallocated or because we are breaking sharing, 
if the whole block of data is being overwritten the bio that triggered 
the provisioning is issued immediately, skipping copying or zeroing of 
the data block.
When this bio completes the new mapping is inserted in to the pool's 
metadata by process_prepared_mapping(), where the bio completion is 
signaled to the upper layers.
This completion is signaled without first committing the metadata.  If 
the bio in question has the REQ_FUA flag set and the system crashes 
right after its completion and before the next metadata commit, then the 
write is lost despite the REQ_FUA flag requiring that I/O completion for 
this request must only be signaled after the data has been committed to 
non-volatile storage.
Fix this by deferring the completion of overwrite bios, with the REQ_FUA 
flag set, until after the metadata has been committed.
Cc: stable@vger.kernel.org Signed-off-by: Nikos Tsironis
<ntsironis@arrikto.com> Acked-by: Joe Thornber <ejt@redhat.com> 
Acked-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike
Snitzer <snitzer@redhat.com>

drm: Use array_size() when creating lease
Passing an object_count of sufficient size will make object_count * 4
wrap around to be very small, then a later function will happily iterate
off the end of the object_ids array.  Using array_size() will saturate
at SIZE_MAX, the kmalloc() will fail and we'll return an -ENOMEM to the
norty userspace.
Fixes: 62884cd386b8 ("drm: Add four ioctls for managing drm mode object
leases [v7]") Signed-off-by: Matthew Wilcox <willy@infradead.org> 
Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Daniel Vetter
<daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # v4.15+ 
Signed-off-by: Dave Airlie <airlied@redhat.com>

i2c: cadence: Fix the hold bit setting
In case the hold bit is not needed we are carrying the old values. Fix
the same by resetting the bit when not needed.
Fixes the sporadic i2c bus lockups on National Instruments Zynq-based
devices.
Fixes: df8eb5691c48 ("i2c: Add driver for Cadence I2C controller") 
Reported-by: Kyle Roeschley <kyle.roeschley@ni.com> Acked-by: Michal
Simek <michal.simek@xilinx.com> Signed-off-by: Shubhrajyoti Datta
<shubhrajyoti.datta@xilinx.com> Tested-by: Kyle Roeschley
<kyle.roeschley@ni.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

i2c: bcm2835: Clear current buffer pointers and counts after a transfer
The driver's interrupt handler checks whether a message is currently 
being handled with the curr_msg pointer. When it is NULL, the interrupt 
is considered to be unexpected. Similarly, the i2c_start_transfer 
routine checks for the remaining number of messages to handle in 
num_msgs.
However, these values are never cleared and always keep the message and 
number relevant to the latest transfer (which might be done already and 
the underlying message memory might have been freed).
When an unexpected interrupt hits with the DONE bit set, the isr will 
then try to access the flags field of the curr_msg structure, leading to
a fatal page fault.
The msg_buf and msg_buf_remaining fields are also never cleared at the 
end of the transfer, which can lead to similar pitfalls.
Fix these issues by introducing a cleanup function and always calling it
after a transfer is finished.
Fixes: e2474541032d ("i2c: bcm2835: Fix hang for writing messages larger
than 16 bytes") Signed-off-by: Paul Kocialkowski
<paul.kocialkowski@bootlin.com> Acked-by: Stefan Wahren
<stefan.wahren@i2se.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

mac80211: Use linked list instead of rhashtable walk for mesh tables
The mesh table code walks over hash tables for two purposes.  First of 
all it's used as part of a netlink dump process, but it is also used for
looking up entries to delete using criteria other than the hash key.
The second purpose is directly contrary to the design specification of
rhashtable walks.  It is only meant for use by netlink dumps.
This is because rhashtable is resizable and you cannot obtain a stable
walk over it during a resize process.
In fact mesh's use of rhashtable for dumping is bogus too.  Rather than
using rhashtable walk's iterator to keep track of the current position,
it always converts the current position to an integer which defeats the
purpose of the iterator.
Therefore this patch converts all uses of rhashtable walk into a simple
linked list.
This patch also adds a new spin lock to protect the hash table 
insertion/removal as well as the walk list modifications.  In fact the
previous code was buggy as the removals can race with each other,
potentially resulting in a double-free.
Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Johannes Berg
<johannes.berg@intel.com>

mac80211: Free mpath object when rhashtable insertion fails
When rhashtable insertion fails the mesh table code doesn't free the
now-orphan mesh path object.  This patch fixes that.
Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Johannes Berg
<johannes.berg@intel.com>

mac80211: Restore vif beacon interval if start ap fails
The starting of AP interface can fail due to invalid beacon interval,
which does not match the minimum gcd requirement set by the wifi driver.
In such case, the beacon interval of that interface gets updated with 
that invalid beacon interval.
The next time that interface is brought up in AP mode, an interface
combination check is performed and the beacon interval is taken from the
previously set value.
In a case where an invalid beacon interval, i.e. a beacon interval value
which does not satisfy the minimum gcd criteria set by the driver, is
set, all the subsequent trials to bring that interface in AP mode will
fail, even if the subsequent trials have a valid beacon interval.
To avoid this, in case of a failure in bringing up an interface in AP
mode due to interface combination error, the interface beacon interval
which is stored in bss conf, needs to be restored with the last working
value of beacon interval.
Tested on ath10k using WCN3990.
Cc: stable@vger.kernel.org Fixes: 0c317a02ca98 ("cfg80211: support
virtual interfaces with different beacon intervals") Signed-off-by:
Rakesh Pillai <pillair@codeaurora.org> Signed-off-by: Johannes Berg
<johannes.berg@intel.com>

x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls
Calls into UV firmware must be protected against concurrency, expose the 
efi_runtime_lock to the UV platform, and use it to serialise UV BIOS 
calls.
Signed-off-by: Hedi Berriche <hedi.berriche@hpe.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by: Ard Biesheuvel
<ard.biesheuvel@linaro.org> Reviewed-by: Russ Anderson <rja@hpe.com> 
Reviewed-by: Dimitri Sivanich <sivanich@hpe.com> Reviewed-by: Mike
Travis <mike.travis@hpe.com> Cc: Andy Shevchenko <andy@infradead.org> 
Cc: Bhupesh Sharma <bhsharma@redhat.com> Cc: Darren Hart
<dvhart@infradead.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo
Molnar <mingo@redhat.com> Cc: linux-efi <linux-efi@vger.kernel.org> Cc:
platform-driver-x86@vger.kernel.org Cc: stable@vger.kernel.org # v4.9+ 
Cc: Steve Wahl <steve.wahl@hpe.com> Cc: Thomas Gleixner
<tglx@linutronix.de> Cc: x86-ml <x86@kernel.org> Link:
https://lkml.kernel.org/r/20190213193413.25560-5-hedi.berriche@hpe.com

netfilter: nf_tables: fix flush after rule deletion in the same batch
Flush after rule deletion bogusly hits -ENOENT. Skip rules that have 
been already from nft_delrule_by_chain() which is always called from the 
flush path.
Fixes: cf9dc09d0949 ("netfilter: nf_tables: fix missing rules flushing
per table") Reported-by: Phil Sutter <phil@nwl.cc> Acked-by: Phil Sutter
<phil@nwl.cc> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

cxgb4: Export sge_host_page_size to ulds
Export the sge_host_page_size field to ULDs via cxgb4_lld_info, so that 
iw_cxgb4 can make use of this in calculating the correct qp/cq mask.
Fixes: 2391b0030e24 ("cxgb4: Remove SGE_HOST_PAGE_SIZE dependency on
page size") Signed-off-by: Raju Rangoju <rajur@chelsio.com> 
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>

iw_cxgb4: cq/qp mask depends on bar2 pages in a host page
Adjust the cq/qp mask based on the number of bar2 pages in a host page.
For user-mode rdma, the granularity of the BAR2 memory mapped to a user 
rdma process during queue allocation must be based on the host page 
size. The lld attributes udb_density and ucq_density are used to figure 
out how many sge contexts are in a bar2 page. So the rdev->qpmask and 
rdev->cqmask in iw_cxgb4 need to now be adjusted based on how many sge 
bar2 pages are in a host page.
Otherwise the device fails to work on non 4k page size systems.
Fixes: 2391b0030e24 ("cxgb4: Remove SGE_HOST_PAGE_SIZE dependency on
page size") Signed-off-by: Raju Rangoju <rajur@chelsio.com> 
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>

kprobe: Do not use uaccess functions to access kernel memory that can
fault
The userspace can ask kprobe to intercept strings at any memory address, 
including invalid kernel address. In this case, fetch_store_strlen() 
would crash since it uses general usercopy function, and user access 
functions are no longer allowed to access kernel memory.
For example, we can crash the kernel by doing something as below:
$ sudo kprobe 'p:do_sys_open +0(+0(%si)):string'
[  103.620391] BUG: GPF in non-whitelisted uaccess (non-canonical
address?)
[  103.622104] general protection fault: 0000 [#1] SMP PTI
[  103.623424] CPU: 10 PID: 1046 Comm: cat Not tainted
5.0.0-rc3-00130-gd73aba1-dirty #96
[  103.625321] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.12.0-2-g628b2e6-dirty-20190104_103505-linux 04/01/2014
[  103.628284] RIP: 0010:process_fetch_insn+0x1ab/0x4b0
[  103.629518] Code: 10 83 80 28 2e 00 00 01 31 d2 31 ff 48 8b 74 24 28
eb 0c 81 fa ff 0f 00 00 7f 1c 85 c0 75 18 66 66 90 0f ae e8 48 63
ca 89 f8 <8a> 0c 31 66 66 90 83 c2 01 84 c9 75 dc 89 54 24 34 89 44 24
28 48
[  103.634032] RSP: 0018:ffff88845eb37ce0 EFLAGS: 00010246
[  103.635312] RAX: 0000000000000000 RBX: ffff888456c4e5a8 RCX:
0000000000000000
[  103.637057] RDX: 0000000000000000 RSI: 2e646c2f6374652f RDI:
0000000000000000
[  103.638795] RBP: 0000000000000000 R08: 0000000000000000 R09:
0000000000000000
[  103.640556] R10: 0000000000000001 R11: 0000000000000000 R12:
0000000000000000
[  103.642297] R13: 0000000000000000 R14: 0000000000000000 R15:
0000000000000000
[  103.644040] FS:  0000000000000000(0000) GS:ffff88846f000000(0000)
knlGS:0000000000000000
[  103.646019] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  103.647436] CR2: 00007ffc79758038 CR3: 0000000463360006 CR4:
0000000000020ee0
[  103.649147] Call Trace:
[  103.649781]  ? sched_clock_cpu+0xc/0xa0
[  103.650747]  ? do_sys_open+0x5/0x220
[  103.651635]  kprobe_trace_func+0x303/0x380
[  103.652645]  ? do_sys_open+0x5/0x220
[  103.653528]  kprobe_dispatcher+0x45/0x50
[  103.654682]  ? do_sys_open+0x1/0x220
[  103.655875]  kprobe_ftrace_handler+0x90/0xf0
[  103.657282]  ftrace_ops_assist_func+0x54/0xf0
[  103.658564]  ? __call_rcu+0x1dc/0x280
[  103.659482]  0xffffffffc00000bf
[  103.660384]  ? __ia32_sys_open+0x20/0x20
[  103.661682]  ? do_sys_open+0x1/0x220
[  103.662863]  do_sys_open+0x5/0x220
[  103.663988]  do_syscall_64+0x60/0x210
[  103.665201]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  103.666862] RIP: 0033:0x7fc22fadccdd
[  103.668034] Code: 48 89 54 24 e0 41 83 e2 40 75 32 89 f0 25 00 00 41
00 3d 00 00 41 00 74 24 89 f2 b8 01 01 00 00 48 89 fe bf 9c ff ff
ff 0f 05 <48> 3d 00 f0 ff ff 77 33 f3 c3 66 0f 1f 84 00 00 00 00 00 48
8d 44
[  103.674029] RSP: 002b:00007ffc7972c3a8 EFLAGS: 00000287 ORIG_RAX:
0000000000000101
[  103.676512] RAX: ffffffffffffffda RBX: 0000562f86147a21 RCX:
00007fc22fadccdd
[  103.678853] RDX: 0000000000080000 RSI: 00007fc22fae1428 RDI:
00000000ffffff9c
[  103.681151] RBP: ffffffffffffffff R08: 0000000000000000 R09:
0000000000000000
[  103.683489] R10: 0000000000000000 R11: 0000000000000287 R12:
00007fc22fce90a8
[  103.685774] R13: 0000000000000001 R14: 0000000000000000 R15:
0000000000000000
[  103.688056] Modules linked in:
[  103.689131] ---[ end trace 43792035c28984a1 ]---
This can be fixed by using probe_mem_read() instead, as it can handle
faulting kernel memory addresses, which kprobes can legitimately do.
Link:
http://lkml.kernel.org/r/20190125151051.7381-1-changbin.du@gmail.com
Cc: stable@vger.kernel.org Fixes: 9da3f2b7405 ("x86/fault: BUG() when
uaccess helpers fault on kernel addresses") Signed-off-by: Changbin Du
<changbin.du@gmail.com> Signed-off-by: Steven Rostedt (VMware)
<rostedt@goodmis.org>

tracing: Fix number of entries in trace header
The following commit
  441dae8f2f29 ("tracing: Add support for display of tgid in trace
output")
removed the call to print_event_info() from print_func_help_header_irq() 
which results in the ftrace header not reporting the number of entries 
written in the buffer. As this wasn't the original intent of the patch, 
re-introduce the call to print_event_info() to restore the orginal 
behaviour.
Link:
http://lkml.kernel.org/r/20190214152950.4179-1-quentin.perret@arm.com
Acked-by: Joel Fernandes <joelaf@google.com> Cc: stable@vger.kernel.org 
Fixes: 441dae8f2f29 ("tracing: Add support for display of tgid in trace
output") Signed-off-by: Quentin Perret <quentin.perret@arm.com> 
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

auxdisplay: ht16k33: fix potential user-after-free on module unload
On module unload/remove, we need to ensure that work does not run after
we have freed resources. Concretely, cancel_delayed_work() may return
while the callback function is still running.
From kernel/workqueue.c:
    The work callback function may still be running on return,
   unless it returns true and the work doesn't re-arm itself.
   Explicitly flush or use cancel_delayed_work_sync() to wait on it.
Link:
https://lore.kernel.org/lkml/20190204220952.30761-1-TheSven73@googlemail.com/ 
Reported-by: Sven Van Asbroeck <thesven73@gmail.com> Reviewed-by: Dmitry
Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Sven Van Asbroeck
<TheSven73@gmail.com> Acked-by: Robin van der Gracht <robin@protonic.nl> 
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>

lib/crc32.c: mark crc32_le_base/__crc32c_le_base aliases as __pure
The upcoming GCC 9 release extends the -Wmissing-attributes warnings
(enabled by -Wall) to C and aliases: it warns when particular function 
attributes are missing in the aliases but not in their target.
In particular, it triggers here because crc32_le_base/__crc32c_le_base 
aren't __pure while their target crc32_le/__crc32c_le are.
These aliases are used by architectures as a fallback in accelerated 
versions of CRC32. See commit 9784d82db3eb ("lib/crc32: make core
crc32() routines weak so they can be overridden").
Therefore, being fallbacks, it is likely that even if the aliases were
called from C, there wouldn't be any optimizations possible. Currently,
the only user is arm64, which calls this from asm.
Still, marking the aliases as __pure makes sense and is a good idea for
documentation purposes and possible future optimizations, which also
silences the warning.
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Laura
Abbott <labbott@redhat.com> Signed-off-by: Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com>

Compiler Attributes: add support for __copy (gcc >= 9)
From the GCC manual:
  copy
 copy(function)
    The copy attribute applies the set of attributes with which function
   has been declared to the declaration of the function to which
   the attribute is applied. The attribute is designed for libraries
   that define aliases or function resolvers that are expected
   to specify the same set of attributes as their targets. The copy
   attribute can be used with functions, variables, or types. However,
   the kind of symbol to which the attribute is applied (either
   function or variable) must match the kind of symbol to which
   the argument refers. The copy attribute copies only syntactic and
   semantic attributes but not attributes that affect a symbol’s
   linkage or visibility such as alias, visibility, or weak.
   The deprecated attribute is also not copied.
  https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
The upcoming GCC 9 release extends the -Wmissing-attributes warnings
(enabled by -Wall) to C and aliases: it warns when particular function 
attributes are missing in the aliases but not in their target, e.g.:
    void __cold f(void) {}
   void __alias("f") g(void);
diagnoses:
    warning: 'g' specifies less restrictive attribute than
   its target 'f': 'cold' [-Wmissing-attributes]
Using __copy(f) we can copy the __cold attribute from f to g:
    void __cold f(void) {}
   void __copy(f) __alias("f") g(void);
This attribute is most useful to deal with situations where an alias is
declared but we don't know the exact attributes the target has.
For instance, in the kernel, the widely used module_init/exit macros 
define the init/cleanup_module aliases, but those cannot be marked 
always as __init/__exit since some modules do not have their functions
marked as such.
Suggested-by: Martin Sebor <msebor@gcc.gnu.org> Reviewed-by: Nick
Desaulniers <ndesaulniers@google.com> Signed-off-by: Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com>

include/linux/module.h: copy __init/__exit attrs to init/cleanup_module
The upcoming GCC 9 release extends the -Wmissing-attributes warnings
(enabled by -Wall) to C and aliases: it warns when particular function 
attributes are missing in the aliases but not in their target.
In particular, it triggers for all the init/cleanup_module aliases in
the kernel (defined by the module_init/exit macros), ending up being
very noisy.
These aliases point to the __init/__exit functions of a module, which
are defined as __cold (among other attributes). However, the aliases
themselves do not have the __cold attribute.
Since the compiler behaves differently when compiling a __cold function
as well as when compiling paths leading to calls to __cold functions,
the warning is trying to point out the possibly-forgotten attribute in
the alias.
In order to keep the warning enabled, we decided to silence this case.
Ideally, we would mark the aliases directly as __init/__exit. However,
there are currently around 132 modules in the kernel which are missing
__init/__exit in their init/cleanup functions (either because they are
missing, or for other reasons, e.g. the functions being called from
somewhere else); and a section mismatch is a hard error.
A conservative alternative was to mark the aliases as __cold only. 
However, since we would like to eventually enforce __init/__exit to be
always marked,  we chose to use the new __copy function attribute
(introduced by GCC 9 as well to deal with this). With it, we copy the
attributes used by the target functions into the aliases. This way,
functions that were not marked as __init/__exit won't have their aliases
marked either, and therefore there won't be a section mismatch.
Note that the warning would go away marking either the extern 
declaration, the definition, or both. However, we only mark the
definition of the alias, since we do not want callers
(which only see the declaration) to be compiled as if the function was
__cold (and therefore the paths leading to those calls would be assumed
to be unlikely).
Link: https://lore.kernel.org/lkml/20190123173707.GA16603@gmail.com/ 
Link: https://lore.kernel.org/lkml/20190206175627.GA20399@gmail.com/ 
Suggested-by: Martin Sebor <msebor@gcc.gnu.org> Acked-by: Jessica Yu
<jeyu@kernel.org> Signed-off-by: Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com>

sunrpc: fix 4 more call sites that were using stack memory with a
scatterlist
While trying to reproduce a reported kernel panic on arm64, I discovered 
that AUTH_GSS basically doesn't work at all with older enctypes on arm64 
systems with CONFIG_VMAP_STACK enabled.  It turns out there still a few 
places using stack memory with scatterlists, causing krb5_encrypt() and 
krb5_decrypt() to produce incorrect results (or a BUG if CONFIG_DEBUG_SG 
is enabled).
Tested with cthon on v4.0/v4.1/v4.2 with krb5/krb5i/krb5p using 
des3-cbc-sha1 and arcfour-hmac-md5.
Signed-off-by: Scott Mayhew <smayhew@redhat.com> Cc:
stable@vger.kernel.org Signed-off-by: J. Bruce Fields
<bfields@redhat.com>

KEYS: allow reaching the keys quotas exactly
If the sysctl 'kernel.keys.maxkeys' is set to some number n, then 
actually users can only add up to 'n - 1' keys.  Likewise for
'kernel.keys.maxbytes' and the root_* versions of these sysctls.  But 
these sysctls are apparently supposed to be *maximums*, as per their 
names and all documentation I could find -- the keyrings(7) man page, 
Documentation/security/keys/core.rst, and all the mentions of EDQUOT 
meaning that the key quota was *exceeded* (as opposed to reached).
Thus, fix the code to allow reaching the quotas exactly.
Fixes: 0b77f5bfb45c ("keys: make the keyring quotas controllable through
/proc/sys") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers
<ebiggers@google.com> Signed-off-by: David Howells <dhowells@redhat.com> 
Signed-off-by: James Morris <james.morris@microsoft.com>

assoc_array: Fix shortcut creation
Fix the creation of shortcuts for which the length of the index key
value is an exact multiple of the machine word size.  The problem is
that the code that blanks off the unused bits of the shortcut value
malfunctions if the number of bits in the last word equals machine word
size.  This is due to the "<<" operator being given a shift of zero in
this case, and so the mask that should be all zeros is all ones instead.
 This causes the subsequent masking operation to clear everything rather
than clearing nothing.
Ordinarily, the presence of the hash at the beginning of the tree index
key makes the issue very hard to test for, but in this case, it was
encountered due to a development mistake that caused the hash output to
be either 0
(keyring) or 1 (non-keyring) only.  This made it susceptible to the 
keyctl/unlink/valid test in the keyutils package.
The fix is simply to skip the blanking if the shift would be 0.  For 
example, an index key that is 64 bits long would produce a 0 shift and
thus a 'blank' of all 1s.  This would then be inverted and AND'd onto
the index_key, incorrectly clearing the entire last word.
Fixes: 3cb989501c26 ("Add a generic associative array implementation.") 
Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: James
Morris <james.morris@microsoft.com>

keys: Fix dependency loop between construction record and auth key
In the request_key() upcall mechanism there's a dependency loop by which
if a key type driver overrides the ->request_key hook and the userspace
side manages to lose the authorisation key, the auth key and the
internal construction record (struct key_construction) can keep each
other pinned.
Fix this by the following changes:
 (1) Killing off the construction record and using the auth key instead.
 (2) Including the operation name in the auth key payload and making the
    payload available outside of security/keys/.
 (3) The ->request_key hook is given the authkey instead of the cons
    record and operation name.
Changes (2) and (3) allow the auth key to naturally be cleaned up if the 
keyring it is in is destroyed or cleared or the auth key is unlinked.
Fixes: 7ee02a316600 ("keys: Fix dependency loop between construction
record and auth key") Signed-off-by: David Howells <dhowells@redhat.com> 
Signed-off-by: James Morris <james.morris@microsoft.com>

keys: Timestamp new keys
Set the timestamp on new keys rather than leaving it unset.
Fixes: 31d5a79d7f3d ("KEYS: Do LRU discard in full keyrings") 
Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: James
Morris <james.morris@microsoft.com>

MIPS: eBPF: Always return sign extended 32b values
The function prototype used to call JITed eBPF code (ie. the type of the 
struct bpf_prog bpf_func field) returns an unsigned int. The MIPS n64 
ABI that MIPS64 kernels target defines that 32 bit integers should 
always be sign extended when passed in registers as either arguments or 
return values.
This means that when returning any value which may not already be sign 
extended (ie. of type REG_64BIT or REG_32BIT_ZERO_EX) we need to perform 
that sign extension in order to comply with the n64 ABI. Without this we 
see strange looking test failures from test_bpf.ko, such as:
  test_bpf: #65 ALU64_MOV_X:
   dst = 4294967295 jited:1 ret -1 != -1 FAIL (1 times)
Although the return value printed matches the expected value, this is 
only because printf is only examining the least significant 32 bits of 
the 64 bit register value we returned. The register holding the expected 
value is sign extended whilst the v0 register was set to a zero extended 
value by our JITed code, so when compared by a conditional branch 
instruction the values are not equal.
We already handle this when the return value register is of type 
REG_32BIT_ZERO_EX, so simply extend this to also cover REG_64BIT.
Signed-off-by: Paul Burton <paul.burton@mips.com> Fixes: b6bd53f9c4e8
("MIPS: Add missing file for eBPF JIT.") Cc: stable@vger.kernel.org #
v4.13+ Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

MIPS: eBPF: Remove REG_32BIT_ZERO_EX
REG_32BIT_ZERO_EX and REG_64BIT are always handled in exactly the same 
way, and reg_val_propagate_range() never actually sets any register to 
type REG_32BIT_ZERO_EX.
Remove the redundant & unused REG_32BIT_ZERO_EX.
Signed-off-by: Paul Burton <paul.burton@mips.com> Signed-off-by: Daniel
Borkmann <daniel@iogearbox.net>

scsi: libiscsi: Fix race between iscsi_xmit_task and iscsi_complete_task
When a target sends Check Condition, whilst initiator is busy xmiting 
re-queued data, could lead to race between iscsi_complete_task() and 
iscsi_xmit_task() and eventually crashing with the following kernel 
backtrace.
[3326150.987523] ALERT: BUG: unable to handle kernel NULL pointer
dereference at 0000000000000078
[3326150.987549] ALERT: IP: [<ffffffffa05ce70d>]
iscsi_xmit_task+0x2d/0xc0 [libiscsi]
[3326150.987571] WARN: PGD 569c8067 PUD 569c9067 PMD 0
[3326150.987582] WARN: Oops: 0002 [#1] SMP
[3326150.987593] WARN: Modules linked in: tun nfsv3 nfs fscache
dm_round_robin
[3326150.987762] WARN: CPU: 2 PID: 8399 Comm: kworker/u32:1 Tainted: G O
4.4.0+2 #1
[3326150.987774] WARN: Hardware name: Dell Inc. PowerEdge R720/0W7JN5,
BIOS 2.5.4 01/22/2016
[3326150.987790] WARN: Workqueue: iscsi_q_13 iscsi_xmitworker [libiscsi]
[3326150.987799] WARN: task: ffff8801d50f3800 ti: ffff8801f5458000
task.ti: ffff8801f5458000
[3326150.987810] WARN: RIP: e030:[<ffffffffa05ce70d>]
[<ffffffffa05ce70d>] iscsi_xmit_task+0x2d/0xc0 [libiscsi]
[3326150.987825] WARN: RSP: e02b:ffff8801f545bdb0 EFLAGS: 00010246
[3326150.987831] WARN: RAX: 00000000ffffffc3 RBX: ffff880282d2ab20 RCX:
ffff88026b6ac480
[3326150.987842] WARN: RDX: 0000000000000000 RSI: 00000000fffffe01 RDI:
ffff880282d2ab20
[3326150.987852] WARN: RBP: ffff8801f545bdc8 R08: 0000000000000000 R09:
0000000000000008
[3326150.987862] WARN: R10: 0000000000000000 R11: 000000000000fe88 R12:
0000000000000000
[3326150.987872] WARN: R13: ffff880282d2abe8 R14: ffff880282d2abd8 R15:
ffff880282d2ac08
[3326150.987890] WARN: FS: 00007f5a866b4840(0000)
GS:ffff88028a640000(0000) knlGS:0000000000000000
[3326150.987900] WARN: CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[3326150.987907] WARN: CR2: 0000000000000078 CR3: 0000000070244000 CR4:
0000000000042660
[3326150.987918] WARN: Stack:
[3326150.987924] WARN: ffff880282d2ad58 ffff880282d2ab20
ffff880282d2abe8 ffff8801f545be18
[3326150.987938] WARN: ffffffffa05cea90 ffff880282d2abf8
ffff88026b59cc80 ffff88026b59cc00
[3326150.987951] WARN: ffff88022acf32c0 ffff880289491800
ffff880255a80800 0000000000000400
[3326150.987964] WARN: Call Trace:
[3326150.987975] WARN: [<ffffffffa05cea90>] iscsi_xmitworker+0x2f0/0x360
[libiscsi]
[3326150.987988] WARN: [<ffffffff8108862c>] process_one_work+0x1fc/0x3b0
[3326150.987997] WARN: [<ffffffff81088f95>] worker_thread+0x2a5/0x470
[3326150.988006] WARN: [<ffffffff8159cad8>] ? __schedule+0x648/0x870
[3326150.988015] WARN: [<ffffffff81088cf0>] ? rescuer_thread+0x300/0x300
[3326150.988023] WARN: [<ffffffff8108ddf5>] kthread+0xd5/0xe0
[3326150.988031] WARN: [<ffffffff8108dd20>] ? kthread_stop+0x110/0x110
[3326150.988040] WARN: [<ffffffff815a0bcf>] ret_from_fork+0x3f/0x70
[3326150.988048] WARN: [<ffffffff8108dd20>] ? kthread_stop+0x110/0x110
[3326150.988127] ALERT: RIP [<ffffffffa05ce70d>]
iscsi_xmit_task+0x2d/0xc0 [libiscsi]
[3326150.988138] WARN: RSP <ffff8801f545bdb0>
[3326150.988144] WARN: CR2: 0000000000000078
[3326151.020366] WARN: ---[ end trace 1c60974d4678d81b ]---
Commit 6f8830f5bbab ("scsi: libiscsi: add lock around task lists to fix 
list corruption regression") introduced "taskqueuelock" to fix list 
corruption during the race, but this wasn't enough.
Re-setting of conn->task to NULL, could race with iscsi_xmit_task(). 
iscsi_complete_task()
{
   ....
   if (conn->task == task)
       conn->task = NULL;
}
conn->task in iscsi_xmit_task() could be NULL and so will be task.
__iscsi_get_task(task) will crash (NullPtr de-ref), trying to access 
refcount.
iscsi_xmit_task()
{
   struct iscsi_task *task = conn->task;
    __iscsi_get_task(task);
}
This commit will take extra conn->session->back_lock in
iscsi_xmit_task() to ensure iscsi_xmit_task() waits for
iscsi_complete_task(), if iscsi_complete_task() wins the race.  If
iscsi_xmit_task() wins the race, iscsi_xmit_task() increments
task->refcount
(__iscsi_get_task) ensuring iscsi_complete_task() will not
iscsi_free_task().
Signed-off-by: Anoob Soman <anoob.soman@citrix.com> Signed-off-by: Bob
Liu <bob.liu@oracle.com> Acked-by: Lee Duncan <lduncan@suse.com> 
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: sd_zbc: Fix sd_zbc_report_zones() buffer allocation
The function sd_zbc_do_report_zones() issues a REPORT ZONES command with
a buffer size calculated based on the number of zones requested by the 
caller. This value should however not exceed the capabilities of the 
hardware maximum command size, that is, should not exceed the 
max_hw_sectors limit of the device. This problem leads to failures of 
report zones commands when re-validating disks with some SAS HBAs.
Fix this by limiting a report zone command buffer size to the minimum of 
the device max_hw_sectors and calculated value based on the requested 
number of zones. This does not change the semantic of the report_zones
file operation as report zones can always return less zone reports than 
requested. Short reports are handled using a loop execution of the 
report_zones file operation in the function blk_report_zones().
[Damien] Before patch 'e76239a3748c ("block: add a report_zones
method")', report zones buffer allocation was limited to max_sectors
when allocated in blk_report_zones(). This however does not consider the
actual format of the device reply which is interface dependent. 
Limiting the allocation based on the size of the expected reply format
rather than the size of the array of generic sturct blkzone passed by
blk_report_zones() makes more sense.
Fixes: e76239a3748c ("block: add a report_zones method") Cc:
stable@vger.kernel.org Signed-off-by: Masato Suzuki
<masato.suzuki@wdc.com> Signed-off-by: Damien Le Moal
<damien.lemoal@wdc.com> Signed-off-by: Martin K. Petersen
<martin.petersen@oracle.com>

scsi: libsas: Fix rphy phy_identifier for PHYs with end devices attached
The sysfs phy_identifier attribute for a sas_end_device comes from the
rphy phy_identifier value.
Currently this is not being set for rphys with an end device attached,
so we see incorrect symlinks from systemd disk/by-path:
root@localhost:~# ls -l /dev/disk/by-path/ total 0 lrwxrwxrwx 1 root
root  9 Feb 13 12:26
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy0-lun-0 -> ../../sdb 
lrwxrwxrwx 1 root root 10 Feb 13 12:26
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy0-lun-0-part1 ->
../../sdb1 lrwxrwxrwx 1 root root 10 Feb 13 12:26
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy0-lun-0-part2 ->
../../sdb2 lrwxrwxrwx 1 root root 10 Feb 13 12:26
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy0-lun-0-part3 ->
../../sdc3
Indeed, each sas_end_device phy_identifier value is 0:
root@localhost:/# more
sys/class/sas_device/end_device-0\:0\:2/phy_identifier 0 
root@localhost:/# more
sys/class/sas_device/end_device-0\:0\:10/phy_identifier 0
This patch fixes the discovery code to set the phy_identifier.  With
this, we now get proper symlinks:
root@localhost:~# ls -l /dev/disk/by-path/ total 0 lrwxrwxrwx 1 root
root  9 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy10-lun-0 -> ../../sdg 
lrwxrwxrwx 1 root root  9 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy11-lun-0 -> ../../sdh 
lrwxrwxrwx 1 root root  9 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy2-lun-0 -> ../../sda 
lrwxrwxrwx 1 root root 10 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy2-lun-0-part1 ->
../../sda1 lrwxrwxrwx 1 root root  9 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy3-lun-0 -> ../../sdb 
lrwxrwxrwx 1 root root 10 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy3-lun-0-part1 ->
../../sdb1 lrwxrwxrwx 1 root root 10 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy3-lun-0-part2 ->
../../sdb2 lrwxrwxrwx 1 root root  9 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy4-lun-0 -> ../../sdc 
lrwxrwxrwx 1 root root 10 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy4-lun-0-part1 ->
../../sdc1 lrwxrwxrwx 1 root root 10 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy4-lun-0-part2 ->
../../sdc2 lrwxrwxrwx 1 root root 10 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy4-lun-0-part3 ->
../../sdc3 lrwxrwxrwx 1 root root  9 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy5-lun-0 -> ../../sdd 
lrwxrwxrwx 1 root root  9 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy7-lun-0 -> ../../sde 
lrwxrwxrwx 1 root root 10 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy7-lun-0-part1 ->
../../sde1 lrwxrwxrwx 1 root root 10 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy7-lun-0-part2 ->
../../sde2 lrwxrwxrwx 1 root root 10 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy7-lun-0-part3 ->
../../sde3 lrwxrwxrwx 1 root root  9 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy8-lun-0 -> ../../sdf 
lrwxrwxrwx 1 root root 10 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy8-lun-0-part1 ->
../../sdf1 lrwxrwxrwx 1 root root 10 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy8-lun-0-part2 ->
../../sdf2 lrwxrwxrwx 1 root root 10 Feb 13 11:53
platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy8-lun-0-part3 ->
../../sdf3
Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver") Reported-by: dann
frazier <dann.frazier@canonical.com> Signed-off-by: John Garry
<john.garry@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> 
Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>

scsi: core: reset host byte in DID_NEXUS_FAILURE case
Up to 4.12, __scsi_error_from_host_byte() would reset the host byte to 
DID_OK for various cases including DID_NEXUS_FAILURE.  Commit 
2a842acab109 ("block: introduce new block status code type") replaced
this function with scsi_result_to_blk_status() and removed the host-byte 
resetting code for the DID_NEXUS_FAILURE case.  As the line 
set_host_byte(cmd, DID_OK) was preserved for the other cases, I suppose 
this was an editing mistake.
The fact that the host byte remains set after 4.13 is causing problems
with the sg_persist tool, which now returns success rather then exit
status 24 when a RESERVATION CONFLICT error is encountered.
Fixes: 2a842acab109 "block: introduce new block status code type" 
Signed-off-by: Martin Wilck <mwilck@suse.com> Reviewed-by: Hannes
Reinecke <hare@suse.com> Reviewed-by: Christoph Hellwig <hch@lst.de> 
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

net: ip6_gre: initialize erspan_ver just for erspan tunnels
After commit c706863bc890 ("net: ip6_gre: always reports o_key to 
userspace"), ip6gre and ip6gretap tunnels started reporting TUNNEL_KEY 
output flag even if it is not configured. ip6gre_fill_info checks
erspan_ver value to add TUNNEL_KEY for erspan tunnels, however in commit
84581bdae9587 ("erspan: set erspan_ver to 1 by default when adding an
erspan dev") erspan_ver is initialized to 1 even for ip6gre or ip6gretap 
Fix the issue moving erspan_ver initialization in a dedicated routine
Fixes: c706863bc890 ("net: ip6_gre: always reports o_key to userspace") 
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> 
Reviewed-by: Greg Rose <gvrose8192@gmail.com> Signed-off-by: David S.
Miller <davem@davemloft.net>

net: phy: xgmiitorgmii: Support generic PHY status read
Some PHY drivers like the generic one do not provide a read_status 
callback on their own but rely on genphy_read_status being called 
directly.
With the current code, this results in a NULL function pointer call. 
Call genphy_read_status instead when there is no specific callback.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> 
Signed-off-by: David S. Miller <davem@davemloft.net>

net: Fix for_each_netdev_feature on Big endian
The features attribute is of type u64 and stored in the native endianes
on the system. The for_each_set_bit() macro takes a pointer to a 32 bit
array and goes over the bits in this area. On little Endian systems this
also works with an u64 as the most significant bit is on the highest
address, but on big endian the words are swapped. When we expect bit 15
here we get bit 47 (15 + 32).
This patch converts it more or less to its own for_each_set_bit() 
implementation which works on 64 bit integers directly. This is then 
completely in host endianness and should work like expected.
Fixes: fd867d51f ("net/core: generic support for disabling netdev
features down stack") Signed-off-by: Hauke Mehrtens
<hauke.mehrtens@intel.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

net: validate untrusted gso packets without csum offload
Syzkaller again found a path to a kernel crash through bad gso input. By
building an excessively large packet to cause an skb field to wrap.
If VIRTIO_NET_HDR_F_NEEDS_CSUM was set this would have been dropped in 
skb_partial_csum_set.
GSO packets that do not set checksum offload are suspicious and rare. 
Most callers of virtio_net_hdr_to_skb already pass them to 
skb_probe_transport_header.
Move that test forward, change it to detect parse failure and drop 
packets on failure as those cleary are not one of the legitimate 
VIRTIO_NET_HDR_GSO types.
Fixes: bfd5f4a3d605 ("packet: Add GSO/csum offload support.") Fixes:
f43798c27684 ("tun: Allow GSO using virtio_net_hdr") Reported-by: syzbot
<syzkaller@googlegroups.com> Signed-off-by: Willem de Bruijn
<willemb@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> 
Signed-off-by: David S. Miller <davem@davemloft.net>

net: dsa: b53: Fix default VLAN ID
We were not consistent in how the default VID of a given port was 
defined, b53_br_leave() would make sure the VLAN ID would be either 0/1 
depending on the switch generation, but b53_configure_vlan(), which is 
the default configuration would unconditionally set it to 1. The correct 
value is 1 for 5325/5365 series and 0 otherwise. To avoid repeating that 
mistake ever again, introduce a helper function: b53_default_pvid() to 
factor that out.
Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom
RoboSwitch") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> 
Signed-off-by: David S. Miller <davem@davemloft.net>

net: dsa: b53: Properly account for VLAN filtering
VLAN filtering can be built into the kernel, and also dynamically turned 
on/off through the bridge master device. Allow re-configuring the switch 
appropriately to account for that by deciding whether VLAN table
(v_table) misses should lead to a drop or forward.
Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support") 
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>

net: systemport: Fix reception of BPDUs
SYSTEMPORT has its RXCHK parser block that attempts to validate the 
packet structures, unfortunately setting the L2 header check bit will 
cause Bridge PDUs (BPDUs) to be incorrectly rejected because they look 
like LLC/SNAP packets with a non-IPv4 or non-IPv6 Ethernet Type.
Fixes: 4e8aedfe78c7 ("net: systemport: Turn on offloads by default") 
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>

net: dsa: bcm_sf2: Do not assume DSA master supports WoL
We assume in the bcm_sf2 driver that the DSA master network device 
supports ethtool_ops::{get,set}_wol operations, which is not a given. 
Avoid de-referencing potentially non-existent function pointers and 
check them as we should.
Fixes: 96e65d7f3f88 ("net: dsa: bcm_sf2: add support for Wake-on-LAN") 
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>

net: dsa: b53: Do not program CPU port's PVID
The CPU port is special and does not need to obey VLAN restrictions as 
far as untagged traffic goes, also, having the CPU port be part of a 
particular PVID is against the idea of keeping it tagged in all VLANs.
Fixes: ca8931948344 ("net: dsa: b53: Keep CPU port as tagged in all
VLANs") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> 
Signed-off-by: David S. Miller <davem@davemloft.net>

ipvs: fix warning on unused variable
When CONFIG_IP_VS_IPV6 is not defined, build produced this warning:
net/netfilter/ipvs/ip_vs_ctl.c:899:6: warning: unused variable ‘ret’
[-Wunused-variable]
 int ret = 0;
     ^~~
Fix this by moving the declaration of 'ret' in the CONFIG_IP_VS_IPV6 
section in the same function.
While at it, drop its unneeded initialisation.
Fixes: 098e13f5b21d ("ipvs: fix dependency on nf_defrag_ipv6") 
Reported-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: Andrea
Claudi <aclaudi@redhat.com> Reviewed-by: Stefano Brivio
<sbrivio@redhat.com> Signed-off-by: Pablo Neira Ayuso
<pablo@netfilter.org>

arm64, mm, efi: Account for GICv3 LPI tables in static memblock reserve
table
In the irqchip and EFI code, we have what basically amounts to a quirk 
to work around a peculiarity in the GICv3 architecture, which permits 
the system memory address of LPI tables to be programmable only once 
after a CPU reset. This means kexec kernels must use the same memory as
the first kernel, and thus ensure that this memory has not been given
out for other purposes by the time the ITS init code runs, which is not
very early for secondary CPUs.
On systems with many CPUs, these reservations could overflow the 
memblock reservation table, and this was addressed in commit:
  eff896288872 ("efi/arm: Defer persistent reservations until after
paging_init()")
However, this turns out to have made things worse, since the allocation 
of page tables and heap space for the resized memblock reservation table 
itself may overwrite the regions we are attempting to reserve, which may 
cause all kinds of corruption, also considering that the ITS will still 
be poking bits into that memory in response to incoming MSIs.
So instead, let's grow the static memblock reservation table on such 
systems so it can accommodate these reservations at an earlier time. 
This will permit us to revert the above commit in a subsequent patch.
[ mingo: Minor cleanups. ]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Mike
Rapoport <rppt@linux.ibm.com> Acked-by: Will Deacon
<will.deacon@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Cc:
Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds
<torvalds@linux-foundation.org> Cc: Peter Zijlstra
<peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc:
linux-arm-kernel@lists.infradead.org Cc: linux-efi@vger.kernel.org Link:
http://lkml.kernel.org/r/20190215123333.21209-2-ard.biesheuvel@linaro.org 
Signed-off-by: Ingo Molnar <mingo@kernel.org>

efi/arm: Revert "Defer persistent reservations until after
paging_init()"
This reverts commit eff896288872d687d9662000ec9ae11b6d61766f, which 
deferred the processing of persistent memory reservations to a point 
where the memory may have already been allocated and overwritten, 
defeating the purpose.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Will
Deacon <will.deacon@arm.com> Cc: Linus Torvalds
<torvalds@linux-foundation.org> Cc: Marc Zyngier <marc.zyngier@arm.com> 
Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Peter Zijlstra
<peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc:
linux-arm-kernel@lists.infradead.org Cc: linux-efi@vger.kernel.org Link:
http://lkml.kernel.org/r/20190215123333.21209-3-ard.biesheuvel@linaro.org 
Signed-off-by: Ingo Molnar <mingo@kernel.org>

net: Add header for usage of fls64()
Fixes: 3b89ea9c5902 ("net: Fix for_each_netdev_feature on Big endian") 
Suggested-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David
S. Miller <davem@davemloft.net>

powerpc/64s: Fix possible corruption on big endian due to
pgd/pud_present()
In v4.20 we changed our pgd/pud_present() to check for _PAGE_PRESENT 
rather than just checking that the value is non-zero, e.g.:
  static inline int pgd_present(pgd_t pgd)
 {
-       return !pgd_none(pgd);
+       return (pgd_raw(pgd) & cpu_to_be64(_PAGE_PRESENT));
 }
Unfortunately this is broken on big endian, as the result of the bitwise
& is truncated to int, which is always zero because
_PAGE_PRESENT is 0x8000000000000000ul. This means pgd_present() and 
pud_present() are always false at compile time, and the compiler elides
the subsequent code.
Remarkably with that bug present we are still able to boot and run with
few noticeable effects. However under some work loads we are able to
trigger a warning in the ext4 code:
  WARNING: CPU: 11 PID: 29593 at fs/ext4/inode.c:3927
.ext4_set_page_dirty+0x70/0xb0
 CPU: 11 PID: 29593 Comm: debugedit Not tainted 4.20.0-rc1 #1
 ...
 NIP .ext4_set_page_dirty+0x70/0xb0
 LR  .set_page_dirty+0xa0/0x150
 Call Trace:
  .set_page_dirty+0xa0/0x150
  .unmap_page_range+0xbf0/0xe10
  .unmap_vmas+0x84/0x130
  .unmap_region+0xe8/0x190
  .__do_munmap+0x2f0/0x510
  .__vm_munmap+0x80/0x110
  .__se_sys_munmap+0x14/0x30
  system_call+0x5c/0x70
The fix is simple, we need to convert the result of the bitwise & to an
int before returning it.
Thanks to Erhard, Jan Kara and Aneesh for help with debugging.
Fixes: da7ad366b497 ("powerpc/mm/book3s: Update pmd_present to look at
_PAGE_PRESENT bit") Cc: stable@vger.kernel.org # v4.20+ Reported-by:
Erhard F. <erhard_f@mailbox.org> Reviewed-by: Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> Signed-off-by: Michael Ellerman
<mpe@ellerman.id.au>

Input: apanel - switch to using brightness_set_blocking()
Now that LEDs core allows "blocking" flavor of "set brightness" method
we can use it and get rid of private work item. As a bonus, we are no
longer forgetting to cancel it when we unbind the driver.
Reviewed-by: Sven Van Asbroeck <TheSven73@gmail.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: st-keyscan - fix potential zalloc NULL dereference
This patch fixes the following static checker warning:
drivers/input/keyboard/st-keyscan.c:156 keyscan_probe() error: potential
zalloc NULL dereference: 'keypad_data->input_dev'
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Gabriel Fernandez <gabriel.fernandez@st.com> Signed-off-by: Dmitry
Torokhov <dmitry.torokhov@gmail.com>

Input: elan_i2c - add ACPI ID for touchpad in Lenovo V330-15ISK
This adds ELAN0617 to the ACPI table to support Elan touchpad found in 
Lenovo V330-15ISK.
Signed-off-by: Mauro Ciancio <mauro@acadeu.com> Cc:
stable@vger.kernel.org Signed-off-by: Dmitry Torokhov
<dmitry.torokhov@gmail.com>

mlxsw: __mlxsw_sp_port_headroom_set(): Fix a use of local variable
The function-local variable "delay" enters the loop interpreted as delay 
in bits. However, inside the loop it gets overwritten by the result of 
mlxsw_sp_pg_buf_delay_get(), and thus leaves the loop as quantity in 
cells. Thus on second and further loop iterations, the headroom for a 
given priority is configured with a wrong size.
Fix by introducing a loop-local variable, delay_cells. Rename thres to 
thres_cells for consistency.
Fixes: f417f04da589 ("mlxsw: spectrum: Refactor port buffer
configuration") Signed-off-by: Petr Machata <petrm@mellanox.com> 
Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel
<idosch@mellanox.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

pinctrl: meson: meson8b: fix the sdxc_a data 1..3 pins
Fix the mismatch between the "sdxc_d13_1_a" pin group definition from 
meson8b_cbus_groups and the entry in sdxc_a_groups ("sdxc_d0_13_1_a"). 
This makes it possible to use "sdxc_d13_1_a" in device-tree files to 
route the MMC data 1..3 pins to GPIOX_1..3.
Fixes: 0fefcb6876d0d6 ("pinctrl: Add support for Meson8b") 
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> 
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Documentation: change linux-4.x references to 5.x
As linux-5.0.x is coming up soon, the documentation should match, in
particular the README.rst file, so change all 4.x references 
accordingly. There was a mix of lowercase and uppercase X here, which I
changed to using lowercase consistently.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jonathan
Corbet <corbet@lwn.net>

doc: Mention MSG_ZEROCOPY implementation for UDP
MSG_ZEROCOPY implementation for UDP was merged in v5.0, 6e360f733113
("Merge branch 'udp-msg_zerocopy'").
Signed-off-by: Petr Vorel <pvorel@suse.cz> Signed-off-by: David S.
Miller <davem@davemloft.net>

net: stmmac: handle endianness in dwmac4_get_timestamp
GMAC IP is little-endian and used on several kind of CPU (big or little 
endian). Main callbacks functions of the stmmac drivers take care about 
it. It was not the case for dwmac4_get_timestamp function.
Fixes: ba1ffd74df74 ("stmmac: fix PTP support for GMAC4") Signed-off-by:
Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by: David S.
Miller <davem@davemloft.net>

qmi_wwan: apply SET_DTR quirk to Sierra WP7607
The 1199:68C0 USB ID is reused by Sierra WP7607 which requires the DTR 
quirk to be detected. Apply QMI_QUIRK_SET_DTR unconditionally as already
done for other IDs shared between different devices.
Signed-off-by: Beniamino Galvani <bgalvani@redhat.com> Acked-by: Bjørn
Mork <bjorn@mork.no> Signed-off-by: David S. Miller
<davem@davemloft.net>

net: mv643xx_eth: disable clk on error path in
mv643xx_eth_shared_probe()
If mv643xx_eth_shared_of_probe() fails, mv643xx_eth_shared_probe() 
leaves clk enabled.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
David S. Miller <davem@davemloft.net>

tcp: clear icsk_backoff in tcp_write_queue_purge()
soukjin bae reported a crash in tcp_v4_err() handling ICMP_DEST_UNREACH
after tcp_write_queue_head(sk) returned a NULL pointer.
Current logic should have prevented this :
  if (seq != tp->snd_una  || !icsk->icsk_retransmits ||
     !icsk->icsk_backoff || fastopen)
     break;
Problem is the write queue might have been purged and icsk_backoff has
not been cleared.
Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: soukjin
bae <soukjin.bae@samsung.com> Acked-by: Neal Cardwell
<ncardwell@google.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

tcp: tcp_v4_err() should be more careful
ICMP handlers are not very often stressed, we should make them more
resilient to bugs that might surface in the future.
If there is no packet in retransmit queue, we should avoid a NULL deref.
Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: soukjin
bae <soukjin.bae@samsung.com> Acked-by: Neal Cardwell
<ncardwell@google.com> Acked-by: Soheil Hassas Yeganeh
<soheil@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>

mm: Use fixed constant in page_frag_alloc instead of size + 1
This patch replaces the size + 1 value introduced with the recent fix
for 1 byte allocs with a constant value.
The idea here is to reduce code overhead as the previous logic would
have to read size into a register, then increment it, and write it back
to whatever field was being used. By using a constant we can avoid those 
memory reads and arithmetic operations in favor of just encoding the 
maximum value into the operation itself.
Fixes: 2c2ade81741c ("mm: page_alloc: fix ref bias in page_frag_alloc()
for 1-byte allocs") Signed-off-by: Alexander Duyck
<alexander.h.duyck@linux.intel.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

net: Do not allocate page fragments that are not skb aligned
This patch addresses the fact that there are drivers, specifically tun, 
that will call into the network page fragment allocators with buffer
sizes that are not cache aligned. Doing this could result in data
alignment and DMA performance issues as these fragment pools are also
shared with the skb allocator and any other devices that will use
napi_alloc_frags or netdev_alloc_frags.
Fixes: ffde7328a36d ("net: Split netdev_alloc_frag into
__alloc_page_frag and add __napi_alloc_frag") Reported-by: Jann Horn
<jannh@google.com> Signed-off-by: Alexander Duyck
<alexander.h.duyck@linux.intel.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

Linux 5.0-rc7

xfrm: Fix inbound traffic via XFRM interfaces across network namespaces
After moving an XFRM interface to another namespace it stays associated 
with the original namespace (net in `struct xfrm_if` and the list keyed 
with `xfrmi_net_id`), allowing processes in the new namespace to use 
SAs/policies that were created in the original namespace.  For instance, 
this allows a keying daemon in one namespace to establish IPsec SAs for 
other namespaces without processes there having access to the keys or
IKE credentials.
This worked fine for outbound traffic, however, for inbound traffic the 
lookup for the interfaces and the policies used the incorrect namespace
(the one the XFRM interface was moved to).
Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces") Signed-off-by:
Tobias Brunner <tobias@strongswan.org> Signed-off-by: Steffen Klassert
<steffen.klassert@secunet.com>

arm64: fix SSBS sanitization
In valid_user_regs() we treat SSBS as a RES0 bit, and consequently it is 
unexpectedly cleared when we restore a sigframe or fiddle with GPRs via 
ptrace.
This patch fixes valid_user_regs() to account for this, updating the 
function to refer to the latest ARM ARM (ARM DDI 0487D.a). For AArch32 
tasks, SSBS appears in bit 23 of SPSR_EL1, matching its position in the 
AArch32-native PSR format, and we don't need to translate it as we have 
to for DIT.
There are no other bit assignments that we need to account for today. As
the recent documentation describes the DIT bit, we can drop our comment
regarding DIT.
While removing SSBS from the RES0 masks, existing inconsistent 
whitespace is corrected.
Fixes: d71be2b6c0e19180 ("arm64: cpufeature: Detect SSBS and advertise
to userspace") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc:
Catalin Marinas <catalin.marinas@arm.com> Cc: Suzuki K Poulose
<suzuki.poulose@arm.com> Cc: Will Deacon <will.deacon@arm.com> 
Signed-off-by: Will Deacon <will.deacon@arm.com>

arm64/neon: Disable -Wincompatible-pointer-types when building with
Clang
After commit cc9f8349cb33 ("arm64: crypto: add NEON accelerated XOR 
implementation"), Clang builds for arm64 started failing with the 
following error message.
arch/arm64/lib/xor-neon.c:58:28: error: incompatible pointer types 
assigning to 'const unsigned long *' from 'uint64_t *' (aka 'unsigned 
long long *') [-Werror,-Wincompatible-pointer-types]
               v3 = veorq_u64(vld1q_u64(dp1 +  6), vld1q_u64(dp2 + 6));
                                        ^~~~~~~~
/usr/lib/llvm-9/lib/clang/9.0.0/include/arm_neon.h:7538:47: note: 
expanded from macro 'vld1q_u64'
 __ret = (uint64x2_t) __builtin_neon_vld1q_v(__p0, 51); \
                                             ^~~~
There has been quite a bit of debate and triage that has gone into 
figuring out what the proper fix is, viewable at the link below, which 
is still ongoing. Ard suggested disabling this warning with Clang with a 
pragma so no neon code will have this type of error. While this is not 
at all an ideal solution, this build error is the only thing preventing 
KernelCI from having successful arm64 defconfig and allmodconfig builds 
on linux-next. Getting continuous integration running is more important 
so new warnings/errors or boot failures can be caught and fixed quickly.
Link: https://github.com/ClangBuiltLinux/linux/issues/283 Suggested-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Ard Biesheuvel
<ard.biesheuvel@linaro.org> Signed-off-by: Nathan Chancellor
<natechancellor@gmail.com> Signed-off-by: Will Deacon
<will.deacon@arm.com>

mailbox: Export mbox_flush()
The mbox_flush() function can be used by drivers that are built as 
modules, so the function needs to be exported.
Reported-by: Mark Brown <broonie@kernel.org> Signed-off-by: Thierry
Reding <treding@nvidia.com> Signed-off-by: Jassi Brar
<jaswinder.singh@linaro.org>

mailbox: bcm-flexrm-mailbox: Fix FlexRM ring flush timeout issue
RING_CONTROL reg was not written due to wrong address, hence all the
subsequent ring flush was timing out.
Fixes: a371c10ea4b3 ("mailbox: bcm-flexrm-mailbox: Fix FlexRM ring flush
sequence")
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> 
Signed-off-by: Ray Jui <ray.jui@broadcom.com> Reviewed-by: Scott Branden
<scott.branden@broadcom.com> Signed-off-by: Jassi Brar
<jaswinder.singh@linaro.org>

libceph: handle an empty authorize reply
The authorize reply can be empty, for example when the ticket used to 
build the authorizer is too old and TAG_BADAUTHORIZER is returned from 
the service.  Calling ->verify_authorizer_reply() results in an attempt 
to decrypt and validate (somewhat) random data in au->buf (most likely 
the signature block from calc_signature()), which fails and ends up in 
con_fault_finish() with !con->auth_retry.  The ticket isn't invalidated 
and the connection is retried again and again until a new ticket is 
obtained from the monitor:
  libceph: osd2 192.168.122.1:6809 bad authorize reply
 libceph: osd2 192.168.122.1:6809 bad authorize reply
 libceph: osd2 192.168.122.1:6809 bad authorize reply
 libceph: osd2 192.168.122.1:6809 bad authorize reply
Let TAG_BADAUTHORIZER handler kick in and increment con->auth_retry.
Cc: stable@vger.kernel.org Fixes: 5c056fdc5b47 ("libceph: verify
authorize reply on connect") Link: https://tracker.ceph.com/issues/20164 
Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Sage Weil
<sage@redhat.com>

ceph: avoid repeatedly adding inode to mdsc->snap_flush_list
Otherwise, mdsc->snap_flush_list may get corrupted.
Cc: stable@vger.kernel.org Signed-off-by: "Yan, Zheng" <zyan@redhat.com> 
Reviewed-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Ilya
Dryomov <idryomov@gmail.com>

ASoC: topology: free created components in tplg load error
Topology resources are no longer needed if any element failed to load.
Signed-off-by: Bard liao <yung-chuan.liao@linux.intel.com> 
Signed-off-by: Mark Brown <broonie@kernel.org>

ASoC: simple-card: fixup refcount_t underflow
commit da215354eb55c ("ASoC: simple-card: merge simple-scu-card") merged
simple-card and simple-scu-card. Then it had refcount underflow bug.
This patch fixup it. We will get below error without this patch.
	OF: ERROR: Bad of_node_put() on /sound
CPU: 3 PID: 237 Comm: kworker/3:1 Not tainted 5.0.0-rc6+ #1514
Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+
(DT)
Workqueue: events deferred_probe_work_func
Call trace:
 dump_backtrace+0x0/0x150
 show_stack+0x24/0x30
 dump_stack+0xb0/0xec
 of_node_release+0xd0/0xd8
 kobject_put+0x74/0xe8
 of_node_put+0x24/0x30
 __of_get_next_child+0x50/0x70
 of_get_next_child+0x40/0x68
 asoc_simple_card_probe+0x604/0x730
 platform_drv_probe+0x58/0xa8
 ... Reported-by: Vicente Bergas <vicencb@gmail.com> Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

net: crypto set sk to NULL when af_alg_release.
KASAN has found use-after-free in sockfs_setattr. The existed commit
6d8c50dcb029 ("socket: close race condition between sock_close() and
sockfs_setattr()") is to fix this simillar issue, but it seems to ignore 
that crypto module forgets to set the sk to NULL after af_alg_release.
KASAN report details as below: BUG: KASAN: use-after-free in
sockfs_setattr+0x120/0x150 Write of size 4 at addr ffff88837b956128 by
task syz-executor0/4186
CPU: 2 PID: 4186 Comm: syz-executor0 Not tainted xxx + #1 Hardware name:
QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 
Call Trace:
dump_stack+0xca/0x13e
print_address_description+0x79/0x330
? vprintk_func+0x5e/0xf0
kasan_report+0x18a/0x2e0
? sockfs_setattr+0x120/0x150
sockfs_setattr+0x120/0x150
? sock_register+0x2d0/0x2d0
notify_change+0x90c/0xd40
? chown_common+0x2ef/0x510
chown_common+0x2ef/0x510
? chmod_common+0x3b0/0x3b0
? __lock_is_held+0xbc/0x160
? __sb_start_write+0x13d/0x2b0
? __mnt_want_write+0x19a/0x250
do_fchownat+0x15c/0x190
? __ia32_sys_chmod+0x80/0x80
? trace_hardirqs_on_thunk+0x1a/0x1c
__x64_sys_fchownat+0xbf/0x160
? lockdep_hardirqs_on+0x39a/0x5e0
do_syscall_64+0xc8/0x580
entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x462589 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:00007fb4b2c83c58
EFLAGS: 00000246 ORIG_RAX: 0000000000000104 RAX: ffffffffffffffda RBX:
000000000072bfa0 RCX: 0000000000462589 RDX: 0000000000000000 RSI:
00000000200000c0 RDI: 0000000000000007 RBP: 0000000000000005 R08:
0000000000001000 R09: 0000000000000000 R10: 0000000000000000 R11:
0000000000000246 R12: 00007fb4b2c846bc R13: 00000000004bc733 R14:
00000000006f5138 R15: 00000000ffffffff
Allocated by task 4185:
kasan_kmalloc+0xa0/0xd0
__kmalloc+0x14a/0x350
sk_prot_alloc+0xf6/0x290
sk_alloc+0x3d/0xc00
af_alg_accept+0x9e/0x670
hash_accept+0x4a3/0x650
__sys_accept4+0x306/0x5c0
__x64_sys_accept4+0x98/0x100
do_syscall_64+0xc8/0x580
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 4184:
__kasan_slab_free+0x12e/0x180
kfree+0xeb/0x2f0
__sk_destruct+0x4e6/0x6a0
sk_destruct+0x48/0x70
__sk_free+0xa9/0x270
sk_free+0x2a/0x30
af_alg_release+0x5c/0x70
__sock_release+0xd3/0x280
sock_close+0x1a/0x20
__fput+0x27f/0x7f0
task_work_run+0x136/0x1b0
exit_to_usermode_loop+0x1a7/0x1d0
do_syscall_64+0x461/0x580
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Syzkaller reproducer: r0 = perf_event_open(&(0x7f0000000000)={0x0, 0x70,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
@perf_config_ext}, 0x0, 0x0, 0xffffffffffffffff, 0x0) r1 =
socket$alg(0x26, 0x5, 0x0) getrusage(0x0, 0x0) bind(r1,
&(0x7f00000001c0)=@alg={0x26, 'hash\x00', 0x0, 0x0,
'sha256-ssse3\x00'}, 0x80) r2 = accept(r1, 0x0, 0x0) r3 =
accept4$unix(r2, 0x0, 0x0, 0x0) r4 = dup3(r3, r0, 0x0) fchownat(r4,
&(0x7f00000000c0)='\x00', 0x0, 0x0, 0x1000)
Fixes: 6d8c50dcb029 ("socket: close race condition between sock_close()
and sockfs_setattr()") Signed-off-by: Mao Wenan <maowenan@huawei.com> 
Signed-off-by: David S. Miller <davem@davemloft.net>

net/mlx4_en: fix spelling mistake: "quiting" -> "quitting"
There is a spelling mistake in a en_err error message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

bpf/test_run: fix unkillable BPF_PROG_TEST_RUN
Syzbot found out that running BPF_PROG_TEST_RUN with repeat=0xffffffff 
makes process unkillable. The problem is that when CONFIG_PREEMPT is 
enabled, we never see need_resched() return true. This is due to the 
fact that preempt_enable() (which we do in bpf_test_run_one on each 
iteration) now handles resched if it's needed.
Let's disable preemption for the whole run, not per test. In this case 
we can properly see whether resched is needed. Let's also properly
return -EINTR to the userspace in case of a signal interrupt.
See recent discussion: 
http://lore.kernel.org/netdev/CAH3MdRWHr4N8jei8jxDppXjmw-Nw=puNDLbu1dQOFQHxfU2onA@mail.gmail.com
I'll follow up with the same fix bpf_prog_test_run_flow_dissector in 
bpf-next.
Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by:
Stanislav Fomichev <sdf@google.com> Signed-off-by: Daniel Borkmann
<daniel@iogearbox.net>

mac80211: mesh: fix missing unlock on error in table_path_del()
spin_lock_bh() is used in table_path_del() but rcu_read_unlock() is used
for unlocking. Fix it by using spin_unlock_bh() instead of
rcu_read_unlock() in the error handling case.
Fixes: b4c3fbe63601 ("mac80211: Use linked list instead of rhashtable
walk for mesh tables") Acked-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Wei Yongjun
<weiyongjun1@huawei.com> Signed-off-by: Johannes Berg
<johannes.berg@intel.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

r8152: Add support for MAC address pass through on RTL8153-BD
RTL8153-BD is used in Dell DA300 type-C dongle. It should be added to
the whitelist of devices to activate MAC address pass through.
Per confirming with Realtek all devices containing RTL8153-BD should 
activate MAC pass through and there won't use pass through bit on efuse 
like in RTL8153-AD.
Signed-off-by: David Chen <david.chen7@dell.com> Signed-off-by: David S.
Miller <davem@davemloft.net>

exec: load_script: Do not exec truncated interpreter path
Commit 8099b047ecc4 ("exec: load_script: don't blindly truncate shebang
string") was trying to protect against a confused exec of a truncated
interpreter path. However, it was overeager and also refused to truncate
arguments as well, which broke userspace, and it was reverted. This
attempts the protection again, but allows arguments to remain truncated.
In an effort to improve readability, helper functions and comments have
been added.
Co-developed-by: Linus Torvalds <torvalds@linux-foundation.org> 
Signed-off-by: Kees Cook <keescook@chromium.org> Cc: Andrew Morton
<akpm@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc:
Samuel Dionne-Riel <samuel@dionne-riel.com> Cc: Richard Weinberger
<richard.weinberger@gmail.com> Cc: Graham Christensen
<graham@grahamc.com> Cc: Michal Hocko <mhocko@suse.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>

powerpc/powernv/sriov: Register IOMMU groups for VFs
The compound IOMMU group rework moved iommu_register_group() together in
pnv_pci_ioda_setup_iommu_api() (which is a part of 
ppc_md.pcibios_fixup). As the result, pnv_ioda_setup_bus_iommu_group() 
does not create groups any more, it only adds devices to groups.
This works fine for boot time devices. However IOMMU groups for SRIOV's
VFs were added by pnv_ioda_setup_bus_iommu_group() so this got broken:
pnv_tce_iommu_bus_notifier() expects a group to be registered for VF and
it is not.
This adds missing group registration and adds a NULL pointer check into
the bus notifier so we won't crash if there is no group, although it is
not expected to happen now because of the change above.
Example oops seen prior to this patch:
  $ echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/sriov_numvfs
 Unable to handle kernel paging request for data at address 0x00000030
 Faulting instruction address: 0xc0000000004a6018
 Oops: Kernel access of bad area, sig: 11 [#1]
 LE SMP NR_CPUS=2048 NUMA PowerNV
 CPU: 46 PID: 7006 Comm: bash Not tainted 4.15-ish
 NIP:  c0000000004a6018 LR: c0000000004a6014 CTR: 0000000000000000
 REGS: c000008fc876b400 TRAP: 0300   Not tainted  (4.15-ish)
 MSR:  900000000280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>
 CFAR: c000000000d0be20 DAR: 0000000000000030 DSISR: 40000000 SOFTE: 1
 ...
 NIP sysfs_do_create_link_sd.isra.0+0x68/0x150
 LR  sysfs_do_create_link_sd.isra.0+0x64/0x150
 Call Trace:
   pci_dev_type+0x0/0x30 (unreliable)
   iommu_group_add_device+0x8c/0x600
   iommu_add_device+0xe8/0x180
   pnv_tce_iommu_bus_notifier+0xb0/0xf0
   notifier_call_chain+0x9c/0x110
   blocking_notifier_call_chain+0x64/0xa0
   device_add+0x524/0x7d0
   pci_device_add+0x248/0x450
   pci_iov_add_virtfn+0x294/0x3e0
   pci_enable_sriov+0x43c/0x580
   mlx5_core_sriov_configure+0x15c/0x2f0 [mlx5_core]
   sriov_numvfs_store+0x180/0x240
   dev_attr_store+0x3c/0x60
   sysfs_kf_write+0x64/0x90
   kernfs_fop_write+0x1ac/0x240
   __vfs_write+0x3c/0x70
   vfs_write+0xd8/0x220
   SyS_write+0x6c/0x110
   system_call+0x58/0x6c
Fixes: 0bd971676e68 ("powerpc/powernv/npu: Add compound IOMMU groups") 
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reported-by:
Santwana Samantray <santwana.samantray@in.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au>

qed: Fix iWARP buffer size provided for syn packet processing.
The assumption that the maximum size of a syn packet is 128 bytes is
wrong. Tunneling headers were not accounted for. Allocate buffers large
enough for mtu.
Signed-off-by: Ariel Elior <ariel.elior@marvell.com> Signed-off-by:
Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by: David S.
Miller <davem@davemloft.net>

qed: Fix iWARP syn packet mac address validation.
The ll2 forwards all syn packets to the driver without validating the
mac address. Add validation check in the driver's iWARP listener flow
and drop the packet if it isn't intended for the device.
Signed-off-by: Ariel Elior <ariel.elior@marvell.com> Signed-off-by:
Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by: David S.
Miller <davem@davemloft.net>

net: stmmac: Fix a race in EEE enable callback
We are saving the status of EEE even before we try to enable it. This 
leads to a race with XMIT function that tries to arm EEE timer before we 
set it up.
Fix this by only saving the EEE parameters after all operations are 
performed with success.
Signed-off-by: Jose Abreu <joabreu@synopsys.com> Fixes: d765955d2ae0
("stmmac: add the Energy Efficient Ethernet support") Cc: Joao Pinto
<jpinto@synopsys.com> Cc: David S. Miller <davem@davemloft.net> Cc:
Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Alexandre Torgue
<alexandre.torgue@st.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

net: hns: Fixes the missing put_device in positive leg for roce reset
This patch fixes the missing device reference release-after-use in the
positive leg of the roce reset API of the HNS DSAF.
Fixes: c969c6e7ab8c ("net: hns: Fix object reference leaks in
hns_dsaf_roce_reset()") Reported-by: John Garry <john.garry@huawei.com> 
Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: David
S. Miller <davem@davemloft.net>

net: netcp: Fix ethss driver probe issue
Recent commit below has introduced a bug in netcp driver that causes the
ethss driver probe failure and thus break the networking function on K2
SoCs such as K2HK, K2L, K2E etc. This patch fixes the issue to restore
networking on the above SoCs.
Fixes: 21c328dcecfc ("net: ethernet: Convert to using %pOFn instead of
device_node.name") Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> 
Signed-off-by: David S. Miller <davem@davemloft.net>

cpufreq: scmi: Fix use-after-free in scmi_cpufreq_exit()
This issue was detected with the help of Coccinelle. So change the order
of function calls to fix it.
Fixes: 1690d8bb91e37 (cpufreq: scpi/scmi: Fix freeing of dynamic OPPs)
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Acked-by: Viresh Kumar
<viresh.kumar@linaro.org> Acked-by: Sudeep Holla <sudeep.holla@arm.com> 
Cc: 4.20+ <stable@vger.kernel.org> # 4.20+ Signed-off-by: Rafael J.
Wysocki <rafael.j.wysocki@intel.com>

ARM: dts: armada-xp: fix Armada XP boards NAND description
Commit 3b79919946cd2cf4dac47842afc9a893acec4ed7 ("ARM: dts: 
armada-370-xp: update NAND node with new bindings") updated some Marvell
Armada DT description to use the new NAND controller bindings, but did
it incorrectly for a number of boards: armada-xp-gp, armada-xp-db and
armada-xp-lenovo-ix4-300d. Due to this, the NAND is no longer detected
on those platforms.
This commit fixes that by properly using the new NAND DT binding. This 
commit was runtime-tested on Armada XP GP, the two other platforms are 
only compile-tested.
Fixes: 3b79919946cd2 ("ARM: dts: armada-370-xp: update NAND node with
new bindings") Cc: Miquel Raynal <miquel.raynal@bootlin.com> 
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> 
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>

arm64: dts: clearfog-gt-8k: fix SGMII PHY reset signal
The PHY reset signal goes to mpp43 on CP0.
Fixes: babc5544c293 ("arm64: dts: clearfog-gt-8k: 1G eth PHY reset
signal") Reported-by: Denis Odintsov <oversun@me.com> Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Signed-off-by: Gregory CLEMENT
<gregory.clement@bootlin.com>

ARM: dts: am335x-evmsk: Fix PHY mode for ethernet
The PHY must add both tx and rx delay and not only on the tx clock. The
board uses AR8031_AL1A PHY where the rx delay is enabled by default, the
tx dealy is disabled.
The reason why rgmii-txid worked because the rx delay was not disabled
by the driver so essentially we ended up with rgmii-id PHY mode.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com>

ARM: dts: am335x-evm: Fix PHY mode for ethernet
The PHY must add both tx and rx delay and not only on the tx clock. The
board uses AR8031_AL1A PHY where the rx delay is enabled by default, the
tx dealy is disabled.
The reason why rgmii-txid worked because the rx delay was not disabled
by the driver so essentially we ended up with rgmii-id PHY mode.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com>

gpu: drm: radeon: Set DPM_FLAG_NEVER_SKIP when enabling PM-runtime
On HP ProBook 4540s, if PM-runtime is enabled in the radeon driver and
the direct-complete optimization is used for the radeon device during
system-wide suspend, the system doesn't resume.
Preventing direct-complete from being used with the radeon device by 
setting the DPM_FLAG_NEVER_SKIP driver flag for it makes the problem go
away, which indicates that direct-complete is not safe for the radeon
driver in general and should not be used with it (at least for now).
This fixes a regression introduced by commit c62ec4610c40
("PM / core: Fix direct_complete handling for devices with no 
callbacks") which allowed direct-complete to be applied to devices
without PM callbacks (again) which in turn unlocked direct-complete for
radeon on HP ProBook 4540s.
Fixes: c62ec4610c40 ("PM / core: Fix direct_complete handling for
devices with no callbacks") Link:
https://bugzilla.kernel.org/show_bug.cgi?id=201519 Reported-by: Ярослав
Семченко <ukrkyi@gmail.com> Tested-by: Ярослав Семченко
<ukrkyi@gmail.com> Signed-off-by: Rafael J. Wysocki
<rafael.j.wysocki@intel.com> Signed-off-by: Alex Deucher
<alexander.deucher@amd.com> Cc: stable@vger.kernel.org

drm/amdgpu: Set DPM_FLAG_NEVER_SKIP when enabling PM-runtime
Based on a similar patch from Rafael for radeon.
When using ATPX to control dGPU power, the state is not retained across
suspend and resume cycles by default.  This can probably be loosened for
Hybrid Graphics (_PR3) laptops where I think the state is properly
retained.
Fixes: c62ec4610c40 ("PM / core: Fix direct_complete handling for
devices with no callbacks") Cc: Rafael J. Wysocki
<rafael.j.wysocki@intel.com> Acked-by: Rafael J. Wysocki
<rafael.j.wysocki@intel.com> Signed-off-by: Alex Deucher
<alexander.deucher@amd.com> Cc: stable@vger.kernel.org

drm/amdgpu: Update sdma golden setting for vega20
According to hardware engineer, WRITE_BURST_LENGTH [9:8] in register 
SDMA0_CHICKEN_BITS need to change to 3 for better performance
Signed-off-by: shaoyunl <shaoyun.liu@amd.com> Acked-by: Alex Deucher
<alexander.deucher@amd.com> Signed-off-by: Alex Deucher
<alexander.deucher@amd.com>

drm/amd/display: Fix MST reboot/poweroff sequence
[Why]
drm_dp_mst_topology_mgr_suspend() is added into the new reboot sequence,
which disables the UP request at the beginning. Therefore sideband
messages are blocked.
[How]
Finish MST sideband message transaction before UP request is suppressed.
Signed-off-by: Leo (Hanghong) Ma <hanghong.ma@amd.com> Reviewed-by:
Roman Li <Roman.Li@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> 
Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc:
stable@vger.kernel.org

drm/amd/display: Raise dispclk value for dce11
[Why] The visual corruption due to low display clock value. Observed on
Carrizo 4K@60Hz.
[How] There was earlier patch for dce_update_clocks: Adding +15%
workaround also to to dce11_update_clocks
Signed-off-by: Roman Li <Roman.Li@amd.com> Reviewed-by: Nicholas
Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Leo Li
<sunpeng.li@amd.com> Signed-off-by: Alex Deucher
<alexander.deucher@amd.com>

vhost: correctly check the return value of translate_desc() in
log_used()
When fail, translate_desc() returns negative value, otherwise the number
of iovs. So we should fail when the return value is negative instead of
a blindly check against zero.
Detected by CoverityScan, CID# 1442593:  Control flow issues  (DEADCODE)
Fixes: cc5e71075947 ("vhost: log dirty page correctly") Acked-by:
Michael S. Tsirkin <mst@redhat.com> Reported-by: Stephen Hemminger
<stephen@networkplumber.org> Signed-off-by: Jason Wang
<jasowang@redhat.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

sky2: Increase D3 delay again
Another platform requires even longer delay to make the device work 
correctly after S3.
So increase the delay to 300ms.
BugLink: https://bugs.launchpad.net/bugs/1798921
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> 
Signed-off-by: David S. Miller <davem@davemloft.net>

drm/i915/fbdev: Actually configure untiled displays
If we skipped all the connectors that were not part of a tile, we would 
leave conn_seq=0 and conn_configured=0, convincing ourselves that we had
stagnated in our configuration attempts. Avoid this situation by 
starting conn_seq=ALL_CONNECTORS, and repeating until we find no more 
connectors to configure.
Fixes: 754a76591b12 ("drm/i915/fbdev: Stop repeating tile configuration
on stagnation") Reported-by: Maarten Lankhorst
<maarten.lankhorst@linux.intel.com> Signed-off-by: Chris Wilson
<chris@chris-wilson.co.uk> Cc: Maarten Lankhorst
<maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst
<maarten.lankhorst@linux.intel.com> Link:
https://patchwork.freedesktop.org/patch/msgid/20190215123019.32283-1-chris@chris-wilson.co.uk 
Cc: <stable@vger.kernel.org> # v3.19+
(cherry picked from commit d9b308b1f8a1acc0c3279f443d4fe0f9f663252e) 
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

arm64: Relax GIC version check during early boot
Updates to the GIC architecture allow ID_AA64PFR0_EL1.GIC to have values
other than 0 or 1. At the moment, Linux is quite strict in the way it
handles this field at early boot stage (cpufeature is fine) and will
refuse to use the system register CPU interface if it doesn't find the
value 1.
Fixes: 021f653791ad17e03f98aaa7fb933816ae16f161 ("irqchip: gic-v3:
Initial support for GICv3") Reported-by: Chase Conklin
<Chase.Conklin@arm.com> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> 
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com>

ARM: tegra: Restore DT ABI on Tegra124 Chromebooks
Commit 482997699ef0 ("ARM: tegra: Fix unit_address_vs_reg DTC warnings 
for /memory") inadventently broke device tree ABI by adding a unit- 
address to the "/memory" node because the device tree compiler flagged 
the missing unit-address as a warning.
Tegra124 Chromebooks (a.k.a. Nyan) use a bootloader that relies on the 
full name of the memory node in device tree being exactly "/memory". It 
can be argued whether this was a good decision or not, and some other 
bootloaders (such as U-Boot) do accept a unit-address in the name of the 
node, but the device tree is an ABI and we can't break existing setups 
just because the device tree compiler considers it bad practice to omit 
the unit-address nowadays.
This partially reverts the offending commit and restores device tree ABI 
compatibility.
Fixes: 482997699ef0 ("ARM: tegra: Fix unit_address_vs_reg DTC warnings
for /memory") Reported-by: Tristan Bastian <tristan-c.bastian@gmx.de> 
Signed-off-by: Thierry Reding <treding@nvidia.com> Tested-by: Tristan
Bastian <tristan-c.bastian@gmx.de> Signed-off-by: Arnd Bergmann
<arnd@arndb.de>

net: dsa: fix unintended change of bridge interface STP state
When a DSA port is added to a bridge and brought up, the resulting STP 
state programmed into the hardware depends on the order that these 
operations are performed.  However, the Linux bridge code believes that 
the port is in disabled mode.
If the DSA port is first added to a bridge and then brought up, it will 
be in blocking mode.  If it is brought up and then added to the bridge, 
it will be in disabled mode.
This difference is caused by DSA always setting the STP mode in 
dsa_port_enable() whether or not this port is part of a bridge.  Since 
bridge always sets the STP state when the port is added, brought up or 
taken down, it is unnecessary for us to manipulate the STP state.
Apparently, this code was copied from Rocker, and the very next day a 
similar fix for Rocker was merged but was not propagated to DSA.  See 
e47172ab7e41 ("rocker: put port in FORWADING state after leaving
bridge")
Fixes: b73adef67765 ("net: dsa: integrate with SWITCHDEV for HW
bridging") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> 
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

clk: at91: fix at91sam9x5 peripheral clock number
nck() looks at the last id in an array and unfortunately, 
at91sam9x35_periphck has a sentinel, hence the id is 0 and the
calculated number of peripheral clocks is 1 instead of a maximum of 31.
Fixes: 1eabdc2f9dd8 ("clk: at91: add at91sam9x5 PMCs driver") 
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Cc:
<stable@vger.kernel.org> # v4.20+ Signed-off-by: Stephen Boyd
<sboyd@kernel.org>

clk: at91: fix masterck name
The master clock is actually named masterck earlier in the driver.
Having
"mck" in the parent list means that it can never be selected.
Fixes: 1eabdc2f9dd8 ("clk: at91: add at91sam9x5 PMCs driver") Fixes:
a2038077de9a ("clk: at91: add sama5d2 PMC driver") Fixes: 084b696bb509
("clk: at91: add sama5d4 pmc driver") Signed-off-by: Alexandre Belloni
<alexandre.belloni@bootlin.com> Acked-by: Nicolas Ferre
<nicolas.ferre@microchip.com> Cc: <stable@vger.kernel.org> # v4.20+ 
Signed-off-by: Stephen Boyd <sboyd@kernel.org>

orangefs: remove two un-needed BUG_ONs...
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

drm/amd/display: Fix negative cursor pos programming
[Why] If the cursor pos passed from DM is less than the
plane_state->dst_rect top left corner then the unsigned cursor pos wraps
around to a large positive number since cursor pos is a u32.
There was an attempt to guard against this in hubp1_cursor_set_position 
by checking the src_x_offset and src_y_offset and offseting the cursor
hotspot within hubp1_cursor_set_position.
However, the cursor position itself is still being programmed 
incorrectly as a large value.
This manifests itself visually as the cursor disappearing or containing 
strange artifacts near the middle of the screen on raven.
[How] Don't subtract the destination rect top left corner from the pos
but add it to the hotspot instead. This happens before the pos gets 
passed into hubp1_cursor_set_position.
This achieves the same result but avoids the subtraction wrap around. 
With this fix the original cursor programming logic can be used again.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> 
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com> Acked-by: Leo Li
<sunpeng.li@amd.com> Acked-by: Murton Liu <Murton.Liu@amd.com> 
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amd/display: fix optimize_bandwidth func pointer for dce80
[Why] optimize_bandwidth was using dce100_prepare_bandwidth this is
incorrect
[How] change it to dce100_optimize_bandwidth
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> 
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com> Acked-by: Leo Li
<sunpeng.li@amd.com> Signed-off-by: Alex Deucher
<alexander.deucher@amd.com> Cc: stable@vger.kernel.org

drm/amd/display: set clocks to 0 on suspend on dce80
[Why] When a dce80 asic was suspended, the clocks were not set to 0. 
Upon resume, the new clock was compared to the existing clock, they were
found to be the same, and so the clock was not set. This resulted in a
blackscreen.
[How] In atomic commit, check to see if there are any active pipes. If
no, set clocks to 0
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> 
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by:
Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher
<alexander.deucher@amd.com> Cc: stable@vger.kernel.org

drm/amdgpu: disable bulk moves for now
The changes to fix those are two invasive for backporting.
Just disable the feature in 4.20 and 5.0.
Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Christian König <christian.koenig@amd.com> Cc: <stable@vger.kernel.org> 
  [4.20+] Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

net: marvell: mvneta: fix DMA debug warning
Booting 4.20 on SolidRun Clearfog issues this warning with DMA API debug
enabled:
WARNING: CPU: 0 PID: 555 at kernel/dma/debug.c:1230
check_sync+0x514/0x5bc mvneta f1070000.ethernet: DMA-API: device driver
tries to sync DMA memory it has not allocated [device
address=0x000000002dd7dc00] [size=240 bytes] Modules linked in: ahci
mv88e6xxx dsa_core xhci_plat_hcd xhci_hcd devlink armada_thermal
marvell_cesa des_generic ehci_orion phy_armada38x_comphy mcp3021
spi_orion evbug sfp mdio_i2c ip_tables x_tables CPU: 0 PID: 555 Comm:
bridge-network- Not tainted 4.20.0+ #291 Hardware name: Marvell Armada
380/385 (Device Tree)
[<c0019638>] (unwind_backtrace) from [<c0014888>] (show_stack+0x10/0x14)
[<c0014888>] (show_stack) from [<c07f54e0>] (dump_stack+0x9c/0xd4)
[<c07f54e0>] (dump_stack) from [<c00312bc>] (__warn+0xf8/0x124)
[<c00312bc>] (__warn) from [<c00313b0>] (warn_slowpath_fmt+0x38/0x48)
[<c00313b0>] (warn_slowpath_fmt) from [<c00b0370>]
(check_sync+0x514/0x5bc)
[<c00b0370>] (check_sync) from [<c00b04f8>]
(debug_dma_sync_single_range_for_cpu+0x6c/0x74)
[<c00b04f8>] (debug_dma_sync_single_range_for_cpu) from [<c051bd14>]
(mvneta_poll+0x298/0xf58)
[<c051bd14>] (mvneta_poll) from [<c0656194>] (net_rx_action+0x128/0x424)
[<c0656194>] (net_rx_action) from [<c000a230>] (__do_softirq+0xf0/0x540)
[<c000a230>] (__do_softirq) from [<c00386e0>] (irq_exit+0x124/0x144)
[<c00386e0>] (irq_exit) from [<c009b5e0>]
(__handle_domain_irq+0x58/0xb0)
[<c009b5e0>] (__handle_domain_irq) from [<c03a63c4>]
(gic_handle_irq+0x48/0x98)
[<c03a63c4>] (gic_handle_irq) from [<c0009a10>] (__irq_svc+0x70/0x98)
...
This appears to be caused by mvneta_rx_hwbm() calling 
dma_sync_single_range_for_cpu() with the wrong struct device pointer, as
the buffer manager device pointer is used to map and unmap the buffer. 
Fix this.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net>

missing barriers in some of unix_sock ->addr and ->path accesses
Several u->addr and u->path users are not holding any locks in common
with unix_bind().  unix_state_lock() is useless for those purposes.
u->addr is assign-once and *(u->addr) is fully set up by the time we set
u->addr (all under unix_table_lock).  u->path is also set in the same
critical area, also before setting u->addr, and any unix_sock with
->path filled will have non-NULL ->addr.
So setting ->addr with smp_store_release() is all we need for those
"lockless" users - just have them fetch ->addr with smp_load_acquire() 
and don't even bother looking at ->path if they see NULL ->addr.
Users of ->addr and ->path fall into several classes now:
   1) ones that do smp_load_acquire(u->addr) and access *(u->addr) and
u->path only if smp_load_acquire() has returned non-NULL.
   2) places holding unix_table_lock.  These are guaranteed that
*(u->addr) is seen fully initialized.  If unix_sock is in one of the
"bound" chains, so's ->path.
   3) unix_sock_destructor() using ->addr is safe.  All places that set
u->addr are guaranteed to have seen all stores *(u->addr) while holding
a reference to u and unix_sock_destructor() is called when (atomic)
refcount hits zero.
   4) unix_release_sock() using ->path is safe.  unix_bind() is
serialized wrt unix_release() (normally - by struct file refcount), and
for the instances that had ->path set by unix_bind() unix_release_sock()
comes from unix_release(), so they are fine. Instances that had it set
in unix_stream_connect() either end up attached to a socket (in
unix_accept()), in which case the call chain to unix_release_sock() and
serialization are the same as in the previous case, or they never get
accept'ed and unix_release_sock() is called when the listener is shut
down and its queue gets purged. In that case the listener's queue lock
provides the barriers needed - unix_stream_connect() shoves our
unix_sock into listener's queue under that lock right after having set
->path and eventual unix_release_sock() caller picks them from that
queue under the same lock right before calling unix_release_sock().
   5) unix_find_other() use of ->path is pointless, but safe - it
happens with successful lookup by (abstract) name, so ->path.dentry is
guaranteed to be NULL there.
earlier-variant-reviewed-by: "Paul E. McKenney" <paulmck@linux.ibm.com> 
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S.
Miller <davem@davemloft.net>

PM-runtime: Fix deadlock when canceling hrtimer
When rpm_resume() desactivates the autosuspend timer, it should only try
to cancel hrtimer but not wait for the handler to finish, because both
rpm_resume() and pm_suspend_timer_fn() take the power.lock.
A deadlock is possible as follows:
CPU0                              CPU1 rpm_resume()
 spin_lock_irqsave
                                 pm_suspend_timer_fn()
                                   spin_lock_irqsave
 pm_runtime_deactivate_timer()
   hrtimer_cancel()
It is sufficient to call hrtimer_try_to_cancel() from 
pm_runtime_deactivate_timer(), because dev->power.timer_expires reset to
0 by it, so use that function instead of hrtimer_cancel().
Fixes: 8234f6734c5d ("PM-runtime: Switch autosuspend over to using
hrtimers") Reported-by: Sunzhaosheng Sun(Zhaosheng)
<sunzhaosheng@hisilicon.com> Signed-off-by: Vincent Guittot
<vincent.guittot@linaro.org>
[ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki
<rafael.j.wysocki@intel.com>

Revert "xsk: simplify AF_XDP socket teardown"
This reverts commit e2ce3674883ecba2605370404208c9d4a07ae1c3.
It turns out that the sock destructor xsk_destruct was needed after all.
The cleanup simplification broke the skb transmit cleanup path, due to
that the umem was prematurely destroyed.
The umem cannot be destroyed until all outstanding skbs are freed, which
means that we cannot remove the umem until the sk_destruct has been
called.
Signed-off-by: Björn Töpel <bjorn.topel@intel.com> Signed-off-by: Daniel
Borkmann <daniel@iogearbox.net>

revert "initramfs: cleanup incomplete rootfs"
Revert ff1522bb7d9845 ("initramfs: cleanup incomplete rootfs").
Andy reports
: This breaks my setup where I have U-boot provided more size of
initramfs
: than needed.  This allows a bit of flexibility to increase or decrease
: initramfs compressed image without taking care of bootloader.  The
proper
: solution is to do this if we sure that we didn't get enough memory,
: otherwise I can't consider the error fatal to clean up rootfs.
Fixes: ff1522bb7d9845 ("initramfs: cleanup incomplete rootfs") 
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com> Tested-by: Andy
Shevchenko <andy.shevchenko@gmail.com> Cc: David Engraf
<david.engraf@sysgo.com> Cc: Dominik Brodowski
<linux@dominikbrodowski.net> Cc: Greg Kroah-Hartman
<gregkh@linuxfoundation.org> Cc: Philippe Ombredanne
<pombredanne@nexb.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Luc Van
Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

numa: change get_mempolicy() to use nr_node_ids instead of MAX_NUMNODES
The system call, get_mempolicy() [1], passes an unsigned long *nodemask 
pointer and an unsigned long maxnode argument which specifies the length 
of the user's nodemask array in bits (which is rounded up).  The manual 
page says that if the maxnode value is too small, get_mempolicy will 
return EINVAL but there is no system call to return this minimum value. 
To determine this value, some programs search /proc/<pid>/status for a 
line starting with "Mems_allowed:" and use the number of digits in the 
mask to determine the minimum value.  A recent change to the way this
line is formatted [2] causes these programs to compute a value less than 
MAX_NUMNODES so get_mempolicy() returns EINVAL.
Change get_mempolicy(), the older compat version of get_mempolicy(), and 
the copy_nodes_to_user() function to use nr_node_ids instead of 
MAX_NUMNODES, thus preserving the defacto method of computing the
minimum size for the nodemask array and the maxnode argument.
[1] http://man7.org/linux/man-pages/man2/get_mempolicy.2.html
[2]
https://lore.kernel.org/lkml/1545405631-6808-1-git-send-email-longman@redhat.com
Link:
http://lkml.kernel.org/r/20190211180245.22295-1-rcampbell@nvidia.com 
Fixes: 4fb8e5b89bcbbbb ("include/linux/nodemask.h: use nr_node_ids (not
MAX_NUMNODES) in __nodemask_pr_numnodes()") Signed-off-by: Ralph
Campbell <rcampbell@nvidia.com> Suggested-by: Alexander Duyck
<alexander.duyck@gmail.com> Cc: Waiman Long <longman@redhat.com> Cc:
<stable@vger.kernel.org> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

kasan: fix assigning tags twice
When an object is kmalloc()'ed, two hooks are called: kasan_slab_alloc() 
and kasan_kmalloc().  Right now we assign a tag twice, once in each of
the hooks.  Fix it by assigning a tag only in the former hook.
Link:
http://lkml.kernel.org/r/ce8c6431da735aa7ec051fd6497153df690eb021.1549921721.git.andreyknvl@google.com 
Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Cc: Alexander
Potapenko <glider@google.com> Cc: Andrey Ryabinin
<aryabinin@virtuozzo.com> Cc: Catalin Marinas <catalin.marinas@arm.com> 
Cc: Christoph Lameter <cl@linux.com> Cc: David Rientjes
<rientjes@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Evgeniy
Stepanov <eugenis@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> 
Cc: Kostya Serebryany <kcc@google.com> Cc: Pekka Enberg
<penberg@kernel.org> Cc: Qian Cai <cai@lca.pw> Cc: Vincenzo Frascino
<vincenzo.frascino@arm.com> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

kasan, kmemleak: pass tagged pointers to kmemleak
Right now we call kmemleak hooks before assigning tags to pointers in 
KASAN hooks.  As a result, when an objects gets allocated, kmemleak sees
a differently tagged pointer, compared to the one it sees when the
object gets freed.  Fix it by calling KASAN hooks before kmemleak's
ones.
Link:
http://lkml.kernel.org/r/cd825aa4897b0fc37d3316838993881daccbe9f5.1549921721.git.andreyknvl@google.com 
Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Reported-by:
Qian Cai <cai@lca.pw> Cc: Alexander Potapenko <glider@google.com> Cc:
Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Catalin Marinas
<catalin.marinas@arm.com> Cc: Christoph Lameter <cl@linux.com> Cc: David
Rientjes <rientjes@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> 
Cc: Evgeniy Stepanov <eugenis@google.com> Cc: Joonsoo Kim
<iamjoonsoo.kim@lge.com> Cc: Kostya Serebryany <kcc@google.com> Cc:
Pekka Enberg <penberg@kernel.org> Cc: Vincenzo Frascino
<vincenzo.frascino@arm.com> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

kmemleak: account for tagged pointers when calculating pointer range
kmemleak keeps two global variables, min_addr and max_addr, which store 
the range of valid (encountered by kmemleak) pointer values, which it 
later uses to speed up pointer lookup when scanning blocks.
With tagged pointers this range will get bigger than it needs to be. 
This patch makes kmemleak untag pointers before saving them to min_addr
and max_addr and when performing a lookup.
Link:
http://lkml.kernel.org/r/16e887d442986ab87fe87a755815ad92fa431a5f.1550066133.git.andreyknvl@google.com 
Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Tested-by: Qian
Cai <cai@lca.pw> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Cc:
Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin
<aryabinin@virtuozzo.com> Cc: Christoph Lameter <cl@linux.com> Cc: David
Rientjes <rientjes@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> 
Cc: Evgeniy Stepanov <eugenis@google.com> Cc: Joonsoo Kim
<iamjoonsoo.kim@lge.com> Cc: Kostya Serebryany <kcc@google.com> Cc:
Pekka Enberg <penberg@kernel.org> Cc: Vincenzo Frascino
<vincenzo.frascino@arm.com> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

kasan, slub: move kasan_poison_slab hook before page_address
With tag based KASAN page_address() looks at the page flags to see
whether the resulting pointer needs to have a tag set.  Since we don't
want to set a tag when page_address() is called on SLAB pages, we call 
page_kasan_tag_reset() in kasan_poison_slab().  However in
allocate_slab() page_address() is called before kasan_poison_slab(). 
Fix it by changing the order.
[andreyknvl@google.com: fix compilation error when CONFIG_SLUB_DEBUG=n]
 Link:
http://lkml.kernel.org/r/ac27cc0bbaeb414ed77bcd6671a877cf3546d56e.1550066133.git.andreyknvl@google.com 
Link:
http://lkml.kernel.org/r/cd895d627465a3f1c712647072d17f10883be2a1.1549921721.git.andreyknvl@google.com 
Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Cc: Alexander
Potapenko <glider@google.com> Cc: Andrey Ryabinin
<aryabinin@virtuozzo.com> Cc: Catalin Marinas <catalin.marinas@arm.com> 
Cc: Christoph Lameter <cl@linux.com> Cc: David Rientjes
<rientjes@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Evgeniy
Stepanov <eugenis@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> 
Cc: Kostya Serebryany <kcc@google.com> Cc: Pekka Enberg
<penberg@kernel.org> Cc: Qian Cai <cai@lca.pw> Cc: Vincenzo Frascino
<vincenzo.frascino@arm.com> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

kasan, slub: fix conflicts with CONFIG_SLAB_FREELIST_HARDENED
CONFIG_SLAB_FREELIST_HARDENED hashes freelist pointer with the address
of the object where the pointer gets stored.  With tag based KASAN we
don't account for that when building freelist, as we call
set_freepointer() with the first argument untagged.  This patch changes
the code to properly propagate tags throughout the loop.
Link:
http://lkml.kernel.org/r/3df171559c52201376f246bf7ce3184fe21c1dc7.1549921721.git.andreyknvl@google.com 
Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Reported-by:
Qian Cai <cai@lca.pw> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc:
Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov
<dvyukov@google.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc:
Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> 
Cc: David Rientjes <rientjes@google.com> Cc: Joonsoo Kim
<iamjoonsoo.kim@lge.com> Cc: Vincenzo Frascino
<vincenzo.frascino@arm.com> Cc: Kostya Serebryany <kcc@google.com> Cc:
Evgeniy Stepanov <eugenis@google.com> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

kasan, slub: fix more conflicts with CONFIG_SLAB_FREELIST_HARDENED
When CONFIG_KASAN_SW_TAGS is enabled, ptr_addr might be tagged. 
Normally, this doesn't cause any issues, as both set_freepointer() and 
get_freepointer() are called with a pointer with the same tag.  However, 
there are some issues with CONFIG_SLUB_DEBUG code.  For example, when
__free_slub() iterates over objects in a cache, it passes untagged 
pointers to check_object().  check_object() in turns calls 
get_freepointer() with an untagged pointer, which causes the freepointer 
to be restored incorrectly.
Add kasan_reset_tag to freelist_ptr(). Also add a detailed comment.
Link:
http://lkml.kernel.org/r/bf858f26ef32eb7bd24c665755b3aee4bc58d0e4.1550103861.git.andreyknvl@google.com 
Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Reported-by:
Qian Cai <cai@lca.pw> Tested-by: Qian Cai <cai@lca.pw> Cc: Andrey
Ryabinin <aryabinin@virtuozzo.com> Cc: Alexander Potapenko
<glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> 
Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>

slub: fix SLAB_CONSISTENCY_CHECKS + KASAN_SW_TAGS
Enabling SLUB_DEBUG's SLAB_CONSISTENCY_CHECKS with KASAN_SW_TAGS 
triggers endless false positives during boot below due to 
check_valid_pointer() checks tagged pointers which have no addresses 
that is valid within slab pages:
  BUG radix_tree_node (Tainted: G    B            ): Freelist Pointer
check fails

-----------------------------------------------------------------------------
  INFO: Slab objects=69 used=69 fp=0x          (null)
flags=0x7ffffffc000200
 INFO: Object @offset=15060037153926966016 fp=0x
  Redzone: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 18 6b 06 00 08 80 ff d0 
.........k......
 Object : 18 6b 06 00 08 80 ff d0 00 00 00 00 00 00 00 00 
.k..............
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
 Redzone: bb bb bb bb bb bb bb bb                          ........
 Padding: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 
ZZZZZZZZZZZZZZZZ
 CPU: 0 PID: 0 Comm: swapper/0 Tainted: G    B             5.0.0-rc5+
#18
 Call trace:
   dump_backtrace+0x0/0x450
   show_stack+0x20/0x2c
   __dump_stack+0x20/0x28
   dump_stack+0xa0/0xfc
   print_trailer+0x1bc/0x1d0
   object_err+0x40/0x50
   alloc_debug_processing+0xf0/0x19c
   ___slab_alloc+0x554/0x704
   kmem_cache_alloc+0x2f8/0x440
   radix_tree_node_alloc+0x90/0x2fc
   idr_get_free+0x1e8/0x6d0
   idr_alloc_u32+0x11c/0x2a4
   idr_alloc+0x74/0xe0
   worker_pool_assign_id+0x5c/0xbc
   workqueue_init_early+0x49c/0xd50
   start_kernel+0x52c/0xac4
 FIX radix_tree_node: Marking all objects used
Link: http://lkml.kernel.org/r/20190209044128.3290-1-cai@lca.pw 
Signed-off-by: Qian Cai <cai@lca.pw> Reviewed-by: Andrey Konovalov
<andreyknvl@google.com> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka
Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc:
Joonsoo Kim <iamjoonsoo.kim@lge.com> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

proc, oom: do not report alien mms when setting oom_score_adj
Tetsuo has reported that creating a thousands of processes sharing MM 
without SIGHAND (aka alien threads) and setting
/proc/<pid>/oom_score_adj will swamp the kernel log and takes ages [1] 
to finish.  This is especially worrisome that all that printing is done 
under RCU lock and this can potentially trigger RCU stall or softlockup 
detector.
The primary reason for the printk was to catch potential users who might 
depend on the behavior prior to 44a70adec910 ("mm, oom_adj: make sure 
processes sharing mm have same view of oom_score_adj") but after more 
than 2 years without a single report I guess it is safe to simply remove 
the printk altogether.
The next step should be moving oom_score_adj over to the mm struct and 
remove all the tasks crawling as suggested by [2]
[1]
http://lkml.kernel.org/r/97fce864-6f75-bca5-14bc-12c9f890e740@i-love.sakura.ne.jp
[2] http://lkml.kernel.org/r/20190117155159.GA4087@dhcp22.suse.cz
Link: http://lkml.kernel.org/r/20190212102129.26288-1-mhocko@kernel.org 
Signed-off-by: Michal Hocko <mhocko@suse.com> Reported-by: Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> Acked-by: Johannes Weiner
<hannes@cmpxchg.org> Cc: David Rientjes <rientjes@google.com> Cc:
Yong-Taek Lee <ytk.lee@samsung.com> Cc: <stable@vger.kernel.org> 
Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>

mm/debug.c: fix __dump_page() for poisoned pages
Evaluating page_mapping() on a poisoned page ends up dereferencing junk 
and making PF_POISONED_CHECK() considerably crashier than intended:
    Unable to handle kernel NULL pointer dereference at virtual address
0000000000000006
   Mem abort info:
     ESR = 0x96000005
     Exception class = DABT (current EL), IL = 32 bits
     SET = 0, FnV = 0
     EA = 0, S1PTW = 0
   Data abort info:
     ISV = 0, ISS = 0x00000005
     CM = 0, WnR = 0
   user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c2f6ac38
   [0000000000000006] pgd=0000000000000000, pud=0000000000000000
   Internal error: Oops: 96000005 [#1] PREEMPT SMP
   Modules linked in:
   CPU: 2 PID: 491 Comm: bash Not tainted 5.0.0-rc1+ #1
   Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno
Development Platform, BIOS EDK II Dec 17 2018
   pstate: 00000005 (nzcv daif -PAN -UAO)
   pc : page_mapping+0x18/0x118
   lr : __dump_page+0x1c/0x398
   Process bash (pid: 491, stack limit = 0x000000004ebd4ecd)
   Call trace:
    page_mapping+0x18/0x118
    __dump_page+0x1c/0x398
    dump_page+0xc/0x18
    remove_store+0xbc/0x120
    dev_attr_store+0x18/0x28
    sysfs_kf_write+0x40/0x50
    kernfs_fop_write+0x130/0x1d8
    __vfs_write+0x30/0x180
    vfs_write+0xb4/0x1a0
    ksys_write+0x60/0xd0
    __arm64_sys_write+0x18/0x20
    el0_svc_common+0x94/0xf8
    el0_svc_handler+0x68/0x70
    el0_svc+0x8/0xc
   Code: f9400401 d1000422 f240003f 9a801040 (f9400402)
   ---[ end trace cdb5eb5bf435cecb ]---
Fix that by not inspecting the mapping until we've determined that it's 
likely to be valid.  Now the above condition still ends up stopping the 
kernel, but in the correct manner:
    page:ffffffbf20000000 is uninitialized and poisoned
   raw: ffffffffffffffff ffffffffffffffff ffffffffffffffff
ffffffffffffffff
   raw: ffffffffffffffff ffffffffffffffff ffffffffffffffff
ffffffffffffffff
   page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
   ------------[ cut here ]------------
   kernel BUG at ./include/linux/mm.h:1006!
   Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
   Modules linked in:
   CPU: 1 PID: 483 Comm: bash Not tainted 5.0.0-rc1+ #3
   Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno
Development Platform, BIOS EDK II Dec 17 2018
   pstate: 40000005 (nZcv daif -PAN -UAO)
   pc : remove_store+0xbc/0x120
   lr : remove_store+0xbc/0x120
   ...
Link:
http://lkml.kernel.org/r/03b53ee9d7e76cda4b9b5e1e31eea080db033396.1550071778.git.robin.murphy@arm.com 
Fixes: 1c6fb1d89e73 ("mm: print more information about mapping in
__dump_page") Signed-off-by: Robin Murphy <robin.murphy@arm.com> 
Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

mm, page_alloc: fix a division by zero error when boosting watermarks v2
Yury Norov reported that an arm64 KVM instance could not boot since 
after v5.0-rc1 and could addressed by reverting the patches
  1c30844d2dfe272d58c ("mm: reclaim small amounts of memory when an
external
 73444bc4d8f92e46a20 ("mm, page_alloc: do not wake kswapd with zone lock
held")
The problem is that a division by zero error is possible if boosting 
occurs very early in boot if the system has very little memory.  This 
patch avoids the division by zero error.
Link: http://lkml.kernel.org/r/20190213143012.GT9565@techsingularity.net 
Fixes: 1c30844d2dfe ("mm: reclaim small amounts of memory when an
external fragmentation event occurs") Signed-off-by: Mel Gorman
<mgorman@techsingularity.net> Reported-by: Yury Norov
<yury.norov@gmail.com> Tested-by: Yury Norov <yury.norov@gmail.com> 
Tested-by: Will Deacon <will.deacon@arm.com> Acked-by: Vlastimil Babka
<vbabka@suse.cz> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David
Rientjes <rientjes@google.com> Cc: Michal Hocko <mhocko@kernel.org> Cc:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

mm: handle lru_add_drain_all for UP properly
Since for_each_cpu(cpu, mask) added by commit 2d3854a37e8b767a
("cpumask: introduce new API, without changing anything") did not 
evaluate the mask argument if NR_CPUS == 1 due to CONFIG_SMP=n, 
lru_add_drain_all() is hitting WARN_ON() at __flush_work() added by 
commit 4d43d395fed12463 ("workqueue: Try to catch flush_work() without 
INIT_WORK().") by unconditionally calling flush_work() [1].
Workaround this issue by using CONFIG_SMP=n specific lru_add_drain_all 
implementation.  There is no real need to defer the implementation to 
the workqueue as the draining is going to happen on the local cpu.  So 
alias lru_add_drain_all to lru_add_drain which does all the necessary 
work.
[akpm@linux-foundation.org: fix various build warnings]
[1]
https://lkml.kernel.org/r/18a30387-6aa5-6123-e67c-57579ecc3f38@roeck-us.net 
Link: http://lkml.kernel.org/r/20190213124334.GH4525@dhcp22.suse.cz 
Signed-off-by: Michal Hocko <mhocko@suse.com> Reported-by: Guenter Roeck
<linux@roeck-us.net> Debugged-by: Tetsuo Handa
<penguin-kernel@I-love.SAKURA.ne.jp> Cc: Tejun Heo <tj@kernel.org> 
Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>

psi: avoid divide-by-zero crash inside virtual machines
We've been seeing hard-to-trigger psi crashes when running inside VM 
instances:
    divide error: 0000 [#1] SMP PTI
   Modules linked in: [...]
   CPU: 0 PID: 212 Comm: kworker/0:2 Not tainted
4.16.18-119_fbk9_3817_gfe944c98d695 #119
   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0
02/06/2015
   Workqueue: events psi_clock
   RIP: 0010:psi_update_stats+0x270/0x490
   RSP: 0018:ffffc90001117e10 EFLAGS: 00010246
   RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff8800a35a13f8
   RDX: 0000000000000000 RSI: ffff8800a35a1340 RDI: 0000000000000000
   RBP: 0000000000000658 R08: ffff8800a35a1470 R09: 0000000000000000
   R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
   R13: 0000000000000000 R14: 0000000000000000 R15: 00000000000f8502
   FS:  0000000000000000(0000) GS:ffff88023fc00000(0000)
knlGS:0000000000000000
   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
   CR2: 00007fbe370fa000 CR3: 00000000b1e3a000 CR4: 00000000000006f0
   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
   Call Trace:
    psi_clock+0x12/0x50
    process_one_work+0x1e0/0x390
    worker_thread+0x2b/0x3c0
    ? rescuer_thread+0x330/0x330
    kthread+0x113/0x130
    ? kthread_create_worker_on_cpu+0x40/0x40
    ? SyS_exit_group+0x10/0x10
    ret_from_fork+0x35/0x40
   Code: 48 0f 47 c7 48 01 c2 45 85 e4 48 89 16 0f 85 e6 00 00 00 4c 8b
49 10 4c 8b 51 08 49 69 d9 f2 07 00 00 48 6b c0 64 4c 8b 29 31 d2 <48>
f7 f7 49 69 d5 8d 06 00 00 48 89 c5 4c 69 f0 00 98 0b 00 48
The Code-line points to `period` being 0 inside update_stats(), and we 
divide by that when calculating that period's pressure percentage.
The elapsed period should never be 0.  The reason this can happen is due 
to an off-by-one in the idle time / missing period calculation combined 
with a coarse sched_clock() in the virtual machine.
The target time for aggregation is advanced into the future on a fixed 
grid to prevent clock drift.  So when an aggregation runs after some
idle period, we can not just set it to "now + psi_period", but have to 
calculate the downtime and advance the target time relative to itself.
However, if the aggregator was disabled exactly one psi_period (ns), we 
drop one idle period in the calculation due to a > when we should do >=. 
In that case, next_update will be advanced from 'now - psi_period' to
'now' when it should be moved to 'now + psi_period'.  The run finishes 
with last_update == next_update == sched_clock().
With hardware clocks, this exact nanosecond match isn't likely in the 
first place; but if it does happen, the clock will still have moved on
and the period non-zero by the time the worker runs.  A pointlessly
short period, but besides the extra work, no harm no foul.  However, a
slow sched_clock() like we have on VMs might not have advanced either by
the time the worker runs again.  And when we calculate the elapsed
period, the result, our pressure divisor, will be 0.  Ouch.
Fix this by correctly handling the situation when the elapsed time
between aggregation runs is precisely two periods, and advance the
expiration timestamp correctly to period into the future.
Link: http://lkml.kernel.org/r/20190214193157.15788-1-hannes@cmpxchg.org 
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Reported-by: Łukasz
Siudut <lsiudut@fb.com Reviewed-by: Andrew Morton
<akpm@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> 
Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>

tmpfs: fix link accounting when a tmpfile is linked in
tmpfs has a peculiarity of accounting hard links as if they were 
separate inodes: so that when the number of inodes is limited, as it is 
by default, a user cannot soak up an unlimited amount of unreclaimable 
dcache memory just by repeatedly linking a file.
But when v3.11 added O_TMPFILE, and the ability to use linkat() on the 
fd, we missed accommodating this new case in tmpfs: "df -i" shows that 
an extra "inode" remains accounted after the file is unlinked and the fd 
closed and the actual inode evicted.  If a user repeatedly links 
tmpfiles into a tmpfs, the limit will be hit (ENOSPC) even after they 
are deleted.
Just skip the extra reservation from shmem_link() in this case: there's 
a sense in which this first link of a tmpfile is then cheaper than a 
hard link of another file, but the accounting works out, and there's 
still good limiting, so no need to do anything more complicated.
Link:
http://lkml.kernel.org/r/alpine.LSU.2.11.1902182134370.7035@eggly.anvils 
Fixes: f4e0c30c191 ("allow the temp files created by open() to be linked
to") Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> 
Signed-off-by: Hugh Dickins <hughd@google.com> Reported-by: Matej
Kupljen <matej.kupljen@gmail.com> Acked-by: Al Viro
<viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

kasan: fix random seed generation for tag-based mode
There are two issues with assigning random percpu seeds right now:
1. We use for_each_possible_cpu() to iterate over cpus, but cpumask is
  not set up yet at the moment of kasan_init(), and thus we only set
  the seed for cpu #0.
2. A call to get_random_u32() always returns the same number and
produces
  a message in dmesg, since the random subsystem is not yet initialized.
Fix 1 by calling kasan_init_tags() after cpumask is set up.
Fix 2 by using get_cycles() instead of get_random_u32(). This gives us 
lower quality random numbers, but it's good enough, as KASAN is meant to 
be used as a debugging tool and not a mitigation.
Link:
http://lkml.kernel.org/r/1f815cc914b61f3516ed4cc9bfd9eeca9bd5d9de.1550677973.git.andreyknvl@google.com 
Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Cc: Catalin
Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> 
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Alexander Potapenko
<glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> 
Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>

kasan: prevent tracing of tags.c
Similarly to commit 0d0c8de8788b ("kasan: mark file common so ftrace 
doesn't trace it") add the -pg flag to mm/kasan/tags.c to prevent 
conflicts with tracing.
Link:
http://lkml.kernel.org/r/9c4c3ce5ccfb894c7fe66d91de7c1da2787b4da4.1550602886.git.andreyknvl@google.com 
Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Reported-by:
Qian Cai <cai@lca.pw> Tested-by: Qian Cai <cai@lca.pw> Cc: Andrey
Ryabinin <aryabinin@virtuozzo.com> Cc: Alexander Potapenko
<glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Catalin
Marinas <catalin.marinas@arm.com> Cc: Vincenzo Frascino
<vincenzo.frascino@arm.com> Cc: Kostya Serebryany <kcc@google.com> Cc:
Evgeniy Stepanov <eugenis@google.com> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

kasan, slab: fix conflicts with CONFIG_HARDENED_USERCOPY
Similarly to commit 96fedce27e13 ("kasan: make tag based mode work with 
CONFIG_HARDENED_USERCOPY"), we need to reset pointer tags in
__check_heap_object() in mm/slab.c before doing any pointer math.
Link:
http://lkml.kernel.org/r/9a5c0f958db10e69df5ff9f2b997866b56b7effc.1550602886.git.andreyknvl@google.com 
Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Tested-by: Qian
Cai <cai@lca.pw> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey
Ryabinin <aryabinin@virtuozzo.com> Cc: Catalin Marinas
<catalin.marinas@arm.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc:
Evgeniy Stepanov <eugenis@google.com> Cc: Kostya Serebryany
<kcc@google.com> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> 
Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>

kasan, slab: make freelist stored without tags
Similarly to "kasan, slub: move kasan_poison_slab hook before 
page_address", move kasan_poison_slab() before alloc_slabmgmt(), which 
calls page_address(), to make page_address() return value to be 
non-tagged.  This, combined with calling kasan_reset_tag() for off-slab 
slab management object, leads to freelist being stored non-tagged.
Link:
http://lkml.kernel.org/r/dfb53b44a4d00de3879a05a9f04c1f55e584f7a1.1550602886.git.andreyknvl@google.com 
Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Tested-by: Qian
Cai <cai@lca.pw> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey
Ryabinin <aryabinin@virtuozzo.com> Cc: Catalin Marinas
<catalin.marinas@arm.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc:
Evgeniy Stepanov <eugenis@google.com> Cc: Kostya Serebryany
<kcc@google.com> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> 
Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>

kasan, slab: remove redundant kasan_slab_alloc hooks
kasan_slab_alloc() calls in kmem_cache_alloc() and
kmem_cache_alloc_node() are redundant as they are already called via
slab_alloc/slab_alloc_node()-> 
slab_post_alloc_hook()->kasan_slab_alloc().  Remove them.
Link:
http://lkml.kernel.org/r/4ca1655cdcfc4379c49c50f7bf80f81c4ad01485.1550602886.git.andreyknvl@google.com 
Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Tested-by: Qian
Cai <cai@lca.pw> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey
Ryabinin <aryabinin@virtuozzo.com> Cc: Catalin Marinas
<catalin.marinas@arm.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc:
Evgeniy Stepanov <eugenis@google.com> Cc: Kostya Serebryany
<kcc@google.com> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> 
Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>

slub: fix a crash with SLUB_DEBUG + KASAN_SW_TAGS
In process_slab(), "p = get_freepointer()" could return a tagged 
pointer, but "addr = page_address()" always return a native pointer.  As 
the result, slab_index() is messed up here,
    return (p - addr) / s->size;
All other callers of slab_index() have the same situation where "addr" 
is from page_address(), so just need to untag "p".
    # cat /sys/kernel/slab/hugetlbfs_inode_cache/alloc_calls
    Unable to handle kernel paging request at virtual address
2bff808aa4856d48
   Mem abort info:
     ESR = 0x96000007
     Exception class = DABT (current EL), IL = 32 bits
     SET = 0, FnV = 0
     EA = 0, S1PTW = 0
   Data abort info:
     ISV = 0, ISS = 0x00000007
     CM = 0, WnR = 0
   swapper pgtable: 64k pages, 48-bit VAs, pgdp = 0000000002498338
   [2bff808aa4856d48] pgd=00000097fcfd0003, pud=00000097fcfd0003,
pmd=00000097fca30003, pte=00e8008b24850712
   Internal error: Oops: 96000007 [#1] SMP
   CPU: 3 PID: 79210 Comm: read_all Tainted: G             L   
5.0.0-rc7+ #84
   Hardware name: HPE Apollo 70             /C01_APACHE_MB         ,
BIOS L50_5.13_1.0.6 07/10/2018
   pstate: 00400089 (nzcv daIf +PAN -UAO)
   pc : get_map+0x78/0xec
   lr : get_map+0xa0/0xec
   sp : aeff808989e3f8e0
   x29: aeff808989e3f940 x28: ffff800826200000
   x27: ffff100012d47000 x26: 9700000000002500
   x25: 0000000000000001 x24: 52ff8008200131f8
   x23: 52ff8008200130a0 x22: 52ff800820013098
   x21: ffff800826200000 x20: ffff100013172ba0
   x19: 2bff808a8971bc00 x18: ffff1000148f5538
   x17: 000000000000001b x16: 00000000000000ff
   x15: ffff1000148f5000 x14: 00000000000000d2
   x13: 0000000000000001 x12: 0000000000000000
   x11: 0000000020000002 x10: 2bff808aa4856d48
   x9 : 0000020000000000 x8 : 68ff80082620ebb0
   x7 : 0000000000000000 x6 : ffff1000105da1dc
   x5 : 0000000000000000 x4 : 0000000000000000
   x3 : 0000000000000010 x2 : 2bff808a8971bc00
   x1 : ffff7fe002098800 x0 : ffff80082620ceb0
   Process read_all (pid: 79210, stack limit = 0x00000000f65b9361)
   Call trace:
    get_map+0x78/0xec
    process_slab+0x7c/0x47c
    list_locations+0xb0/0x3c8
    alloc_calls_show+0x34/0x40
    slab_attr_show+0x34/0x48
    sysfs_kf_seq_show+0x2e4/0x570
    kernfs_seq_show+0x12c/0x1a0
    seq_read+0x48c/0xf84
    kernfs_fop_read+0xd4/0x448
    __vfs_read+0x94/0x5d4
    vfs_read+0xcc/0x194
    ksys_read+0x6c/0xe8
    __arm64_sys_read+0x68/0xb0
    el0_svc_handler+0x230/0x3bc
    el0_svc+0x8/0xc
   Code: d3467d2a 9ac92329 8b0a0e6a f9800151 (c85f7d4b)
   ---[ end trace a383a9a44ff13176 ]---
   Kernel panic - not syncing: Fatal exception
   SMP: stopping secondary CPUs
   SMP: failed to stop secondary CPUs 1-7,32,40,127
   Kernel Offset: disabled
   CPU features: 0x002,20000c18
   Memory Limit: none
   ---[ end Kernel panic - not syncing: Fatal exception ]---
Link: http://lkml.kernel.org/r/20190220020251.82039-1-cai@lca.pw 
Signed-off-by: Qian Cai <cai@lca.pw> Reviewed-by: Andrey Konovalov
<andreyknvl@google.com> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

mm: don't let userspace spam allocations warnings
memdump_user usually gets fed unchecked userspace input.  Blasting a 
full backtrace into dmesg every time is a bit excessive - I'm not sure 
on the kernel rule in general, but at least in drm we're trying not to 
let unpriviledge userspace spam the logs freely.  Definitely not entire 
warning backtraces.
It also means more filtering for our CI, because our testsuite exercises 
these corner cases and so hits these a lot.
Link:
http://lkml.kernel.org/r/20190220204058.11676-1-daniel.vetter@ffwll.ch 
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by:
Andrew Morton <akpm@linux-foundation.org> Acked-by: Michal Hocko
<mhocko@suse.com> Reviewed-by: Kees Cook <keescook@chromium.org> Cc:
Mike Rapoport <rppt@linux.vnet.ibm.com> Cc: Roman Gushchin <guro@fb.com> 
Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Jan Stancek
<jstancek@redhat.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc:
"Michael S. Tsirkin" <mst@redhat.com> Cc: Huang Ying
<ying.huang@intel.com> Cc: Bartosz Golaszewski <brgl@bgdev.pl> 
Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>

mm, memory_hotplug: fix off-by-one in is_pageblock_removable
Rong Chen has reported the following boot crash:
    PGD 0 P4D 0
   Oops: 0000 [#1] PREEMPT SMP PTI
   CPU: 1 PID: 239 Comm: udevd Not tainted 5.0.0-rc4-00149-gefad4e4 #1
   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1
04/01/2014
   RIP: 0010:page_mapping+0x12/0x80
   Code: 5d c3 48 89 df e8 0e ad 02 00 85 c0 75 da 89 e8 5b 5d c3 0f 1f
44 00 00 53 48 89 fb 48 8b 43 08 48 8d 50 ff a8 01 48 0f 45 da <48> 8b
53 08 48 8d 42 ff 83 e2 01 48 0f 44 c3 48 83 38 ff 74 2f 48
   RSP: 0018:ffff88801fa87cd8 EFLAGS: 00010202
   RAX: ffffffffffffffff RBX: fffffffffffffffe RCX: 000000000000000a
   RDX: fffffffffffffffe RSI: ffffffff820b9a20 RDI: ffff88801e5c0000
   RBP: 6db6db6db6db6db7 R08: ffff88801e8bb000 R09: 0000000001b64d13
   R10: ffff88801fa87cf8 R11: 0000000000000001 R12: ffff88801e640000
   R13: ffffffff820b9a20 R14: ffff88801f145258 R15: 0000000000000001
   FS:  00007fb2079817c0(0000) GS:ffff88801dd00000(0000)
knlGS:0000000000000000
   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
   CR2: 0000000000000006 CR3: 000000001fa82000 CR4: 00000000000006a0
   Call Trace:
    __dump_page+0x14/0x2c0
    is_mem_section_removable+0x24c/0x2c0
    removable_show+0x87/0xa0
    dev_attr_show+0x25/0x60
    sysfs_kf_seq_show+0xba/0x110
    seq_read+0x196/0x3f0
    __vfs_read+0x34/0x180
    vfs_read+0xa0/0x150
    ksys_read+0x44/0xb0
    do_syscall_64+0x5e/0x4a0
    entry_SYSCALL_64_after_hwframe+0x49/0xbe
and bisected it down to commit efad4e475c31 ("mm, memory_hotplug: 
is_mem_section_removable do not pass the end of a zone").
The reason for the crash is that the mapping is garbage for poisoned
(uninitialized) page.  This shouldn't happen as all pages in the zone's 
boundary should be initialized.
Later debugging revealed that the actual problem is an off-by-one when 
evaluating the end_page.  'start_pfn + nr_pages' resp 'zone_end_pfn' 
refers to a pfn after the range and as such it might belong to a 
differen memory section.
This along with CONFIG_SPARSEMEM then makes the loop condition 
completely bogus because a pointer arithmetic doesn't work for pages 
from two different sections in that memory model.
Fix the issue by reworking is_pageblock_removable to be pfn based and 
only use struct page where necessary.  This makes the code slightly 
easier to follow and we will remove the problematic pointer arithmetic 
completely.
Link: http://lkml.kernel.org/r/20190218181544.14616-1-mhocko@kernel.org 
Fixes: efad4e475c31 ("mm, memory_hotplug: is_mem_section_removable do
not pass the end of a zone") Signed-off-by: Michal Hocko
<mhocko@suse.com> Reported-by: <rong.a.chen@intel.com> Tested-by:
<rong.a.chen@intel.com> Acked-by: Mike Rapoport <rppt@linux.ibm.com> 
Reviewed-by: Oscar Salvador <osalvador@suse.de> Cc: Matthew Wilcox
<willy@infradead.org> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

ipv6: route: enforce RCU protection in rt6_update_exception_stamp_rt()
We must access rt6_info->from under RCU read lock: move the dereference
under such lock, with proper annotation.
v1 -> v2:
- avoid using multiple, racy, fetch operations for rt->from
Fixes: a68886a69180 ("net/ipv6: Make from in rt6_info rcu protected") 
Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: David Ahern
<dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>

ipv6: route: enforce RCU protection in ip6_route_check_nh_onlink()
We need a RCU critical section around rt6_info->from deference, and 
proper annotation.
Fixes: 4ed591c8ab44 ("net/ipv6: Allow onlink routes to have a device
mismatch if it is the default route") Signed-off-by: Paolo Abeni
<pabeni@redhat.com> Reviewed-by: David Ahern <dsahern@gmail.com> 
Signed-off-by: David S. Miller <davem@davemloft.net>

net/smc: fix smc_poll in SMC_INIT state
smc_poll() returns with mask bit EPOLLPRI if the connection urg_state is
SMC_URG_VALID. Since SMC_URG_VALID is zero, smc_poll signals EPOLLPRI
errorneously if called in state SMC_INIT before the connection is
created, for instance in a non-blocking connect scenario.
This patch switches to non-zero values for the urg states.
Reviewed-by: Karsten Graul <kgraul@linux.ibm.com> Fixes: de8474eb9d50
("net/smc: urgent data support") Signed-off-by: Ursula Braun
<ubraun@linux.ibm.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

ixgbe: fix older devices that do not support IXGBE_MRQC_L3L4TXSWEN
The enabling L3/L4 filtering for transmit switched packets for all 
devices caused unforeseen issue on older devices when trying to send UDP 
traffic in an ordered sequence.  This bit was originally intended for
X550 devices, which supported this feature, so limit the scope of this
bit to only X550 devices.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com>

i40e: fix potential RX buffer starvation for AF_XDP
When the RX rings are created they are also populated with buffers so
that packets can be received. Usually these are kernel buffers, but for
AF_XDP in zero-copy mode, these are user-space buffers and in this case
the application might not have sent down any buffers to the driver at
this point. And if no buffers are allocated at ring creation time, no
packets can be received and no interrupts will be generated so the NAPI
poll function that allocates buffers to the rings will never get
executed.
To rectify this, we kick the NAPI context of any queue with an attached
AF_XDP zero-copy socket in two places in the code. Once after an XDP
program has loaded and once after the umem is registered. This take care
of both cases: XDP program gets loaded first then AF_XDP socket is
created, and the reverse, AF_XDP socket is created first, then XDP
program is loaded.
Fixes: 0a714186d3c0 ("i40e: add AF_XDP zero-copy Rx support") 
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher
<jeffrey.t.kirsher@intel.com>

ixgbe: fix potential RX buffer starvation for AF_XDP
When the RX rings are created they are also populated with buffers so 
that packets can be received. Usually these are kernel buffers, but for
AF_XDP in zero-copy mode, these are user-space buffers and in this case
the application might not have sent down any buffers to the driver at
this point. And if no buffers are allocated at ring creation time, no
packets can be received and no interrupts will be generated so the NAPI
poll function that allocates buffers to the rings will never get
executed.
To rectify this, we kick the NAPI context of any queue with an attached
AF_XDP zero-copy socket in two places in the code. Once after an XDP
program has loaded and once after the umem is registered.  This take
care of both cases: XDP program gets loaded first then AF_XDP socket is
created, and the reverse, AF_XDP socket is created first, then XDP
program is loaded.
Fixes: d0bcacd0a130 ("ixgbe: add AF_XDP zero-copy Rx support") 
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher
<jeffrey.t.kirsher@intel.com>

ARCv2: Enable unaligned access in early ASM code
It is currently done in arc_init_IRQ() which might be too late 
considering gcc 7.3.1 onwards (GNU 2018.03) generates unaligned memory
accesses by default
Cc: stable@vger.kernel.org #4.4+ Signed-off-by: Eugeniy Paltsev
<Eugeniy.Paltsev@synopsys.com> Signed-off-by: Vineet Gupta
<vgupta@synopsys.com>
[vgupta: rewrote changelog]

ARCv2: lib: memcpy: fix doing prefetchw outside of buffer
ARCv2 optimized memcpy uses PREFETCHW instruction for prefetching the 
next cache line but doesn't ensure that the line is not past the end of 
the buffer. PRETECHW changes the line ownership and marks it dirty, 
which can cause data corruption if this area is used for DMA IO.
Fix the issue by avoiding the PREFETCHW. This leads to performance 
degradation but it is OK as we'll introduce new memcpy implementation 
optimized for unaligned memory access using.
We also cut off all PREFETCH instructions at they are quite useless 
here:
* we call PREFETCH right before LOAD instruction call.
* we copy 16 or 32 bytes of data (depending on CONFIG_ARC_HAS_LL64)
  in a main logical loop. so we call PREFETCH 4 times (or 2 times)
  for each L1 cache line (in case of 64B L1 cache Line which is
  default case). Obviously this is not optimal.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> 
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

ARC: fix actionpoints configuration detection
Fix reversed logic while actionpoints configuration (full/min) 
detection.
Fixies: 7dd380c338f1e ("ARC: boot log: print Action point details") 
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> 
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

ARC: uacces: remove lp_start, lp_end from clobber list
Newer ARC gcc handles lp_start, lp_end in a different way and doesn't 
like them in the clobber list.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

ARCv2: support manual regfile save on interrupts
There's a hardware bug which affects the HSDK platform, triggered by 
micro-ops for auto-saving regfile on taken interrupt. The workaround is 
to inhibit autosave.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

ARC: U-boot: check arguments paranoidly
Handle U-boot arguments paranoidly:
* don't allow to pass unknown tag.
* try to use external device tree blob only if corresponding tag
  (TAG_DTB) is set.
* don't check uboot_tag if kernel build with no ARC_UBOOT_SUPPORT.
NOTE: If U-boot args are invalid we skip them and try to use embedded
device tree blob. We can't panic on invalid U-boot args as we really
pass invalid args due to bug in U-boot code. This happens if we don't
provide external DTB to U-boot and don't set 'bootargs' U-boot
environment variable (which is default case at least for HSDK board) In
that case we will pass
{r0 = 1 (bootargs in r2); r1 = 0; r2 = 0;} to linux which is invalid.
While I'm at it refactor U-boot arguments handling code.
Cc: stable@vger.kernel.org Tested-by: Corentin LABBE
<clabbe@baylibre.com> Signed-off-by: Eugeniy Paltsev
<Eugeniy.Paltsev@synopsys.com> Signed-off-by: Vineet Gupta
<vgupta@synopsys.com>

ARC: enable uboot support unconditionally
After reworking U-boot args handling code and adding paranoid arguments
check we can eliminate CONFIG_ARC_UBOOT_SUPPORT and enable uboot support
unconditionally.
For JTAG case we can assume that core registers will come up reset value
of 0 or in worst case we rely on user passing
'-on=clear_regs' to Metaware debugger.
Cc: stable@vger.kernel.org Tested-by: Corentin LABBE
<clabbe@baylibre.com> Signed-off-by: Eugeniy Paltsev
<Eugeniy.Paltsev@synopsys.com> Signed-off-by: Vineet Gupta
<vgupta@synopsys.com>

ARC: define ARCH_SLAB_MINALIGN = 8
The default value of ARCH_SLAB_MINALIGN in "include/linux/slab.h" is
"__alignof__(unsigned long long)" which for ARC unexpectedly turns out 
to be 4. This is not a compiler bug, but as defined by ARC ABI [1]
Thus slab allocator would allocate a struct which is 32-bit aligned, 
which is generally OK even if struct has long long members. There was
however potetial problem when it had any atomic64_t which use
LLOCKD/SCONDD instructions which are required by ISA to take 64-bit
addresses. This is the problem we ran into
[    4.015732] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    4.167881] Misaligned Access
[    4.172356] Path: /bin/busybox.nosuid
[    4.176004] CPU: 2 PID: 171 Comm: rm Not tainted
4.19.14-yocto-standard #1
[    4.182851]
[    4.182851] [ECR   ]: 0x000d0000 => Check Programmer's Manual
[    4.190061] [EFA   ]: 0xbeaec3fc
[    4.190061] [BLINK ]: ext4_delete_entry+0x210/0x234
[    4.190061] [ERET  ]: ext4_delete_entry+0x13e/0x234
[    4.202985] [STAT32]: 0x80080002 : IE K
[    4.207236] BTA: 0x9009329c   SP: 0xbe5b1ec4  FP: 0x00000000
[    4.212790] LPS: 0x9074b118  LPE: 0x9074b120 LPC: 0x00000000
[    4.218348] r00: 0x00000040  r01: 0x00000021 r02: 0x00000001
...
...
[    4.270510] Stack Trace:
[    4.274510]   ext4_delete_entry+0x13e/0x234
[    4.278695]   ext4_rmdir+0xe0/0x238
[    4.282187]   vfs_rmdir+0x50/0xf0
[    4.285492]   do_rmdir+0x9e/0x154
[    4.288802]   EV_Trap+0x110/0x114
The fix is to make sure slab allocations are 64-bit aligned.
Do note that atomic64_t is __attribute__((aligned(8)) which means gcc 
does generate 64-bit aligned references, relative to beginning of 
container struct. However the issue is if the container itself is not 
64-bit aligned, atomic64_t ends up unaligned which is what this patch 
ensures.
[1]
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/wiki/files/ARCv2_ABI.pdf
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc:
<stable@vger.kernel.org> # 4.8+ Signed-off-by: Vineet Gupta
<vgupta@synopsys.com>
[vgupta: reworked changelog, added dependency on LL64+LLSC]

i40e: fix XDP_REDIRECT/XDP xmit ring cleanup race
When the driver clears the XDP xmit ring due to re-configuration or 
teardown, in-progress ndo_xdp_xmit must be taken into consideration.
The ndo_xdp_xmit function is typically called from a NAPI context that 
the driver does not control. Therefore, we must be careful not to clear
the XDP ring, while the call is on-going. This patch adds a 
synchronize_rcu() to wait for napi(s) (preempt-disable regions and 
softirqs), prior clearing the queue. Further, the __I40E_CONFIG_BUSY 
flag is checked in the ndo_xdp_xmit implementation to avoid touching the
XDP xmit queue during re-configuration.
Fixes: d9314c474d4f ("i40e: add support for XDP_REDIRECT") Fixes:
123cecd427b6 ("i40e: added queue pair disable/enable functions") 
Reported-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> 
Signed-off-by: Björn Töpel <bjorn.topel@intel.com> Signed-off-by: Jeff
Kirsher <jeffrey.t.kirsher@intel.com>

parisc: Fix ptrace syscall number modification
Commit 910cd32e552e ("parisc: Fix and enable seccomp filter support") 
introduced a regression in ptrace-based syscall tampering: when tracer 
changes syscall number to -1, the kernel fails to initialize %r28 with
-ENOSYS and subsequently fails to return the error code of the failed 
syscall to userspace.
This erroneous behaviour could be observed with a simple strace syscall 
fault injection command which is expected to print something like this:
$ strace -a0 -ewrite -einject=write:error=enospc echo hello write(1,
"hello\n", 6) = -1 ENOSPC (No space left on device) (INJECTED) write(2,
"echo: ", 6) = -1 ENOSPC (No space left on device) (INJECTED) write(2,
"write error", 11) = -1 ENOSPC (No space left on device) (INJECTED) 
write(2, "\n", 1) = -1 ENOSPC (No space left on device) (INJECTED)
+++ exited with 1 +++
After commit 910cd32e552ea09caa89cdbe328e468979b030dd it loops printing 
something like this instead:
write(1, "hello\n", 6../strace: Failed to tamper with process 12345:
unexpectedly got no error (return value 0, error 0)
) = 0 (INJECTED)
This bug was found by strace test suite.
Fixes: 910cd32e552e ("parisc: Fix and enable seccomp filter support") 
Cc: stable@vger.kernel.org # v4.5+ Signed-off-by: Dmitry V. Levin
<ldv@altlinux.org> Tested-by: Helge Deller <deller@gmx.de> 
Signed-off-by: Helge Deller <deller@gmx.de>

ixgbe: don't do any AF_XDP zero-copy transmit if netif is not OK
An issue has been found while testing zero-copy XDP that causes a reset
to be triggered. As it takes some time to turn the carrier on after
setting zc, and we already start trying to transmit some packets,
watchdog considers this as an erroneous state and triggers a reset.
Don't do any work if netif carrier is not OK.
Fixes: 8221c5eba8c13 (ixgbe: add AF_XDP zero-copy Tx support) 
Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>

CREDITS/MAINTAINERS: Retire parisc-linux.org email domain
Retire the parisc-linux.org email domain and provide alternative email 
addresses for the remaining users, as agreed upon with them.
Signed-off-by: Helge Deller <deller@gmx.de>

MAINTAINERS: mark CAIF as orphan
The listed address for the CAIF maintainer bounces with
"553 5.3.0 <dmitry.tarnyagin@lockless.no>... No such user here", and the 
only existing email address of the maintainer in git history hasn't 
responded in a week. Therefore, remove the listed maintainer and mark
CAIF as orphan.
Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: David S.
Miller <davem@davemloft.net>

net: vrf: remove MTU limits for vrf device
Similiar to commit e94cd8113ce63 ("net: remove MTU limits for dummy and 
ifb device"), MTU is irrelevant for VRF device. We init it as 64K while 
limit it to [68, 1500] may make users feel confused.
Reported-by: Jianlin Shi <jishi@redhat.com> Signed-off-by: Hangbin Liu
<liuhangbin@gmail.com> Reviewed-by: David Ahern <dsahern@gmail.com> 
Signed-off-by: David S. Miller <davem@davemloft.net>

bonding: fix PACKET_ORIGDEV regression
This patch fixes a subtle PACKET_ORIGDEV regression which was a side 
effect of fixes introduced by:
6a9e461f6fe4 bonding: pass link-local packets to bonding master also.
... to:
b89f04c61efe bonding: deliver link-local packets with skb->dev set to
link that packets arrived on
While 6a9e461f6fe4 restored pre-b89f04c61efe presence of link-local 
packets on bonding masters (which is required e.g. by linux bridges 
participating in spanning tree or needed for lab-like setups created 
with group_fwd_mask) it also caused the originating device information
to be lost due to cloning.
Maciej Żenczykowski proposed another solution that doesn't require 
packet cloning and retains original device information - instead of 
returning RX_HANDLER_PASS for all link-local packets it's now limited 
only to packets from inactive slaves.
At the same time, packets passed to bonding masters retain correct 
information about the originating device and PACKET_ORIGDEV can be used 
to determine it.
This elegantly solves all issues so far:
- link-local packets that were removed from bonding masters
- LLDP daemons being forced to explicitly bind to slave interfaces
- PACKET_ORIGDEV having no effect on bond interfaces
Fixes: 6a9e461f6fe4 (bonding: pass link-local packets to bonding master
also.) Reported-by: Vincent Bernat <vincent@bernat.ch> Signed-off-by:
Michal Soltys <soltys@ziu.info> Signed-off-by: Maciej Żenczykowski
<maze@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>