mainline inclusion
from mainline-4.20
commit 6db92468
category: bugfix
bugzilla: 6186
CVE: NA

-------------------------------------------------

When a failure occurs in rtnl_configure_link(), the current code
calls unregister_netdevice() to roll back the earlier call to
register_netdevice(), and jumps to errout, which calls
vxlan_fdb_destroy().

However unregister_netdevice() calls transitively ndo_uninit, which is
vxlan_uninit(), and that already takes care of deleting the default FDB
entry by calling vxlan_fdb_delete_default(). Since the entry added
earlier in __vxlan_dev_create() is exactly the default entry, the
cleanup code in the errout block always leads to double free and thus a
panic.

Besides, since vxlan_fdb_delete_default() always destroys the FDB entry
with notification enabled, the deletion of the default entry is notified
even before the addition was notified.

Instead, move the unregister_netdevice() call after the manual destroy,
which solves both problems.

Fixes: 0241b836 ("vxlan: fix default fdb entry netlink notify ordering during netdev create")
Signed-off-by: NPetr Machata <petrm@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NMao Wenan <maowenan@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0
commit 2a61d8b883bb
category: bugfix
bugzilla: 6202
CVE: NA

-------------------------------------------------

A proc_remove() can sleep. so that it can't be inside of spin_lock.
Hence proc_remove() is moved to outside of spin_lock. and it also
adds mutex to sync create and remove of proc entry(config->pde).

test commands:
SHELL#1
   %while :; do iptables -A INPUT -p udp -i enp2s0 -d 192.168.1.100 \
	   --dport 9000  -j CLUSTERIP --new --hashmode sourceip \
	   --clustermac 01:00:5e:00:00:21 --total-nodes 3 --local-node 3; \
	   iptables -F; done

SHELL#2
   %while :; do echo +1 > /proc/net/ipt_CLUSTERIP/192.168.1.100; \
	   echo -1 > /proc/net/ipt_CLUSTERIP/192.168.1.100; done

[ 2949.569864] BUG: sleeping function called from invalid context at kernel/sched/completion.c:99
[ 2949.579944] in_atomic(): 1, irqs_disabled(): 0, pid: 5472, name: iptables
[ 2949.587920] 1 lock held by iptables/5472:
[ 2949.592711]  #0: 000000008f0ebcf2 (&(&cn->lock)->rlock){+...}, at: refcount_dec_and_lock+0x24/0x50
[ 2949.603307] CPU: 1 PID: 5472 Comm: iptables Tainted: G        W         4.19.0-rc5+ #16
[ 2949.604212] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 07/08/2015
[ 2949.604212] Call Trace:
[ 2949.604212]  dump_stack+0xc9/0x16b
[ 2949.604212]  ? show_regs_print_info+0x5/0x5
[ 2949.604212]  ___might_sleep+0x2eb/0x420
[ 2949.604212]  ? set_rq_offline.part.87+0x140/0x140
[ 2949.604212]  ? _rcu_barrier_trace+0x400/0x400
[ 2949.604212]  wait_for_completion+0x94/0x710
[ 2949.604212]  ? wait_for_completion_interruptible+0x780/0x780
[ 2949.604212]  ? __kernel_text_address+0xe/0x30
[ 2949.604212]  ? __lockdep_init_map+0x10e/0x5c0
[ 2949.604212]  ? __lockdep_init_map+0x10e/0x5c0
[ 2949.604212]  ? __init_waitqueue_head+0x86/0x130
[ 2949.604212]  ? init_wait_entry+0x1a0/0x1a0
[ 2949.604212]  proc_entry_rundown+0x208/0x270
[ 2949.604212]  ? proc_reg_get_unmapped_area+0x370/0x370
[ 2949.604212]  ? __lock_acquire+0x4500/0x4500
[ 2949.604212]  ? complete+0x18/0x70
[ 2949.604212]  remove_proc_subtree+0x143/0x2a0
[ 2949.708655]  ? remove_proc_entry+0x390/0x390
[ 2949.708655]  clusterip_tg_destroy+0x27a/0x630 [ipt_CLUSTERIP]
[ ... ]

Fixes: b3e456fc ("netfilter: ipt_CLUSTERIP: fix a race condition of proc file creation")
Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: NShangli <shangli1@huawei.com>
Signed-off-by: NMao Wenan <maowenan@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-4.20
commit d701d8117200
category: bugfix
bugzilla: 6224
CVE: NA

-------------------------------------------------

Zero pad private area, otherwise we expose private kernel pointer to
userspace. This patch also zeroes the tail area after the ->matchsize
and ->targetsize that results from XT_ALIGN().

Fixes: 0ca743a5 ("netfilter: nf_tables: add compatibility layer for x_tables")
Reported-by: NFlorian Westphal <fw@strlen.de>
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: NShangli <shangli1@huawei.com>
Signed-off-by: NMao Wenan <maowenan@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

euler inclusion
category: bugfix
bugzilla: 4279
CVE: NA

-------------------------------------------------------------------------

When we register kretprobe, data_size used to allocate space
for storing per-instance private data.

If we use a negative values as data_size, It will register
successfully, then cause slab-out-of-bounds which can be
found by KASAN.

The call trace as below :

	=============================================================
	BUG: KASAN: slab-out-of-bounds in trampoline_probe_handler
	+0xb4/0x2f0 at addr ffff8000b732a7a0
	Read of size 8 by task sh/1945
	=============================================================
	BUG kmalloc-64 (Tainted: G    B   W  OE  ):
	kasan: bad access detected
	-------------------------------------------------------------
	INFO: Allocated in register_kretprobe+0x12c/0x350
	age=157 cpu=4 pid=1947
	......
	INFO: Freed in do_one_initcall+0x110/0x260
	age=169 cpu=4 pid=1947
	......
	INFO: Slab 0xffff7bffc2dcca80 objects=21 used=10
	fp=0xffff8000b732aa80 flags=0x7fff00000004080
	INFO: Object 0xffff8000b732a780 @offset=1920 fp=0x     (null)

	CPU: 7 PID: 1945 Comm: sh Tainted: G    B   W  OE   4.1.46 #8
	Hardware name: linux,dummy-virt (DT)
	Call trace:
	[<0008d2a0>] dump_backtrace+0x0/0x220
	[<0008d4e0>] show_stack+0x20/0x30
	[<00ff2278>] dump_stack+0xa8/0xcc
	[<002dc6c8>] print_trailer+0xf8/0x160
	[<002e20d8>] object_err+0x48/0x60
	[<002e48dc>] kasan_report+0x26c/0x5a0
	[<002e39a0>] __asan_load8+0x60/0x80
	[<01000054>] trampoline_probe_handler+0xb4/0x2f0
	[<00ffff38>] kretprobe_trampoline+0x54/0xbc
	Memory state around the buggy address:
 	b732a680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 	b732a700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
	>b732a780: 00 00 00 00 07 fc fc fc fc fc fc fc fc fc fc fc
                               ^

If data_size is invalid, then we should not register it.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reported-by: NKong ZhangHuan <kongzhanghuan@huawei.com>
Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: NMao Wenan <maowenan@huawei.com>
Signed-off-by: NHui Wang <john.wanghui@huawei.com>
Signed-off-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com>

Conflicts: kernel/kprobes.c
Signed-off-by: NXuefeng Wang <wxf.wang@hisilicon.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

euler inclusion
category: bugfix
bugzilla: 2535
CVE: N/A

push_dl_task() pick the first pushable task and find an eligible
lowest_rq, then double_lock_balance(rq, lowest_rq). So if
double_lock_balance() unlock the rq (when double_lock_balance() return
1), we have to check if this task is still on the rq.

The problem is that the check conditions are not sufficient:

if (unlikely(task_rq(task) != rq ||
             !cpumask_test_cpu(later_rq->cpu, &task->cpus_allowed) ||
             task_running(rq, task) ||
             !dl_task(task) ||
             !task_on_rq_queued(task))) {

cpu2                                cpu1                    cpu0
push_dl_task(rq1)
  pick task_A on rq1
  find rq0
    double_lock_balance(rq1, rq0)
      unlock(rq1)
                            rq1 __schedule
                              pick task_A run
                            task_A sleep (dequeued)
      lock(rq0)
      lock(rq1)
    do_above_check(task_A)
      task_rq(task_A) == rq1
      cpus_allowed unchanged
      task_running == false
      dl_task(task_A) == true
                                                    try_to_wake_up(task_A)
                                                      select_cpu = cpu3
                                                      enqueue(rq3, task_A)
                                                      task_A->on_rq = 1
      task_on_rq_queued(task_A)
    above_check passed, return rq0
    ...
    migrate task_A from rq1 to rq0

So we can't rely on these checks of task_A to make sure the task_A is
still on the rq1, even though we hold the rq1->lock. This patch will
repick the first pushable task to be sure the task is still on the rq.
Signed-off-by: NLi Bin <huawei.libin@huawei.com>
Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: NXuefeng Wang <wxf.wang@hisilicon.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

euler inclusion
category: bugfix
bugzilla: 2535
CVE: N/A

-------------------------------------------------

push_rt_task() pick the first pushable task and find an eligible
lowest_rq, then double_lock_balance(rq, lowest_rq). So if
double_lock_balance() unlock the rq (when double_lock_balance() return 1),
we have to check if this task is still on the rq.

The problem is that the check conditions are not sufficient:

if (unlikely(task_rq(task) != rq ||
	     !cpumask_test_cpu(lowest_rq->cpu, &task->cpus_allowed) ||
	     task_running(rq, task) ||
	     !rt_task(task) ||
	     !task_on_rq_queued(task))) {

cpu2				cpu1			cpu0
push_rt_task(rq1)
  pick task_A on rq1
  find rq0
    double_lock_balance(rq1, rq0)
      unlock(rq1)
				rq1 __schedule
				  pick task_A run
				task_A sleep (dequeued)
      lock(rq0)
      lock(rq1)
    do_above_check(task_A)
      task_rq(task_A) == rq1
      cpus_allowed unchanged
      task_running == false
      rt_task(task_A) == true
							try_to_wake_up(task_A)
							  select_cpu = cpu3
							  enqueue(rq3, task_A)
							  task_A->on_rq = 1
      task_on_rq_queued(task_A)
    above_check passed, return rq0
    ...
    migrate task_A from rq1 to rq0

So we can't rely on these checks of task_A to make sure the task_A is
still on the rq1, even though we hold the rq1->lock. This patch will
repick the first pushable task to be sure the task is still on the rq.
Signed-off-by: NZhou Chengming <zhouchengming1@huawei.com>
Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NHui Wang <john.wanghui@huawei.com>
Signed-off-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com>

Conflicts: kernel/sched/rt.c
Signed-off-by: NXuefeng Wang <wxf.wang@hisilicon.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0
commit 0919871ac37f
category: bugfix
bugzilla: 7088
CVE: NA

-------------------------------------------------

Possible race accessing memdev structures after dropping the
mutex. Dan Williams says this could race against another thread
that is doing:

 # echo "ACPI0012:00" > /sys/bus/acpi/drivers/nfit/unbind
Reported-by: NJane Chu <jane.chu@oracle.com>
Fixes: 23222f8f ("acpi, nfit: Add function to look up nvdimm...")
Signed-off-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NHanjun Guo <guohanjun@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0
commit d2fd6e81912a
category: bugfix
bugzilla: 7064
CVE: NA

-------------------------------------------------

The disable_acs_redir parameter stores a pointer to the string passed to
pci_setup().  However, the string passed to PCI setup is actually a
temporary copy allocated in static __initdata memory.  After init, once the
memory is freed, it is no longer valid to reference this pointer.

This bug was noticed in v5.0-rc1 after a change in commit c5eb1190074c
("PCI / PM: Allow runtime PM without callback functions") caused
pci_disable_acs_redir() to be called during shutdown which manifested
as an unable to handle kernel paging request at:

  RIP: 0010:pci_enable_acs+0x3f/0x1e0
  Call Trace:
     pci_restore_state.part.44+0x159/0x3c0
     pci_restore_standard_config+0x33/0x40
     pci_pm_runtime_resume+0x2b/0xd0
     ? pci_restore_standard_config+0x40/0x40
     __rpm_callback+0xbc/0x1b0
     rpm_callback+0x1f/0x70
     ? pci_restore_standard_config+0x40/0x40
      rpm_resume+0x4f9/0x710
     ? pci_conf1_read+0xb6/0xf0
     ? pci_conf1_write+0xb2/0xe0
     __pm_runtime_resume+0x47/0x70
     pci_device_shutdown+0x1e/0x60
     device_shutdown+0x14a/0x1f0
     kernel_restart+0xe/0x50
     __do_sys_reboot+0x1ee/0x210
     ? __fput+0x144/0x1d0
     do_writev+0x5e/0xf0
     ? do_writev+0x5e/0xf0
     do_syscall_64+0x48/0xf0
     entry_SYSCALL_64_after_hwframe+0x44/0xa9

It was also likely possible to trigger this bug when hotplugging PCI
devices.

To fix this, instead of storing a pointer, we use kstrdup() to copy the
disable_acs_redir_param to its own buffer which will never be freed.

Fixes: aaca43fd ("PCI: Add "pci=disable_acs_redir=" parameter for peer-to-peer support")
Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NLogan Gunthorpe <logang@deltatee.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NHanjun Guo <guohanjun@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0
commit 2f661962
category: bugfix
bugzilla: 6898
CVE: NA

-------------------------------------------------

cpuinfo_cur_freq gets current CPU frequency as detected by hardware
while scaling_cur_freq last known CPU frequency. Some platforms may not
allow checking the CPU frequency of an offline CPU or the associated
resources may have been released via cpufreq_exit when the CPU gets
offlined, in which case the policy would have been invalidated already.
If we attempt to get current frequency from the hardware, it may result
in hang or crash.

For example on Juno, I see:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000188
[0000000000000188] pgd=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP
Modules linked in:
CPU: 5 PID: 4202 Comm: cat Not tainted 4.20.0-08251-ga0f2c0318a15-dirty #87
Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform
pstate: 40000005 (nZcv daif -PAN -UAO)
pc : scmi_cpufreq_get_rate+0x34/0xb0
lr : scmi_cpufreq_get_rate+0x34/0xb0
Call trace:
 scmi_cpufreq_get_rate+0x34/0xb0
 __cpufreq_get+0x34/0xc0
 show_cpuinfo_cur_freq+0x24/0x78
 show+0x40/0x60
 sysfs_kf_seq_show+0xc0/0x148
 kernfs_seq_show+0x44/0x50
 seq_read+0xd4/0x480
 kernfs_fop_read+0x15c/0x208
 __vfs_read+0x60/0x188
 vfs_read+0x94/0x150
 ksys_read+0x6c/0xd8
 __arm64_sys_read+0x24/0x30
 el0_svc_common+0x78/0x100
 el0_svc_handler+0x38/0x78
 el0_svc+0x8/0xc
---[ end trace 3d1024e58f77f6b2 ]---

So fix the issue by checking if the policy is invalid early in
__cpufreq_get before attempting to get the current frequency.
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NHanjun Guo <guohanjun@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-4.20
commit dc8af3a8
category: bugfix
bugzilla: 6651
CVE: NA

-------------------------------------------------

The VMD removal path calls pci_stop_root_busi(), which tears down the pcie
tree, including detaching all of the attached drivers. During driver
detachment, devices may use pci_release_region() to release resources.
This path relies on the resource being accessible in resource tree.

By detaching the child domain from the parent resource domain prior to
stopping the bus, we are preventing the list traversal from finding the
resource to be freed. If we instead detach the resource after stopping
the bus, we will have properly freed the resource and detaching is
simply accounting at that point.

Without this order, the resource is never freed and is orphaned on VMD
removal, leading to a warning:

[  181.940162] Trying to free nonexistent resource <e5a10000-e5a13fff>

Fixes: 2c2c5c5c ("x86/PCI: VMD: Attach VMD resources to parent domain's resource tree")
Signed-off-by: NJon Derrick <jonathan.derrick@intel.com>
[lorenzo.pieralisi@arm.com: updated commit log]
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NHanjun Guo <guohanjun@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-4.20
commit 17c91487364f
category: bugfix
bugzilla: 6314
CVE: NA

-------------------------------------------------

Now that ASPM is configured for *all* PCIe devices at boot, a problem is
seen with systems that set the FADT NO_ASPM bit.  This bit indicates that
the OS should not alter the ASPM state, but when
pcie_aspm_init_link_state() runs it only checks for !aspm_support_enabled.
This misses the ACPI_FADT_NO_ASPM case because that is setting
aspm_disabled.

The result is systems may hang at boot after 1302fcf0; avoidable if they
boot with pcie_aspm=off (sets !aspm_support_enabled).

Fix this by having aspm_init_link_state() check for either
!aspm_support_enabled or acpm_disabled.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=201001
Fixes: 1302fcf0 ("PCI: Configure *all* devices, not just hot-added ones")
Signed-off-by: NPatrick Talbert <ptalbert@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NHanjun Guo <guohanjun@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-4.20
commit 5f26bdce
category: bugfix
bugzilla: 6468
CVE: NA

-------------------------------------------------

If the CPU exits the "polling" state due to the time limit in the
loop in poll_idle(), this is not a real wakeup and it just means
that the "polling" state selection was not adequate.  The governor
mispredicted short idle duration, but had a more suitable state been
selected, the CPU might have spent more time in it.  In fact, there
is no reason to expect that there would have been a wakeup event
earlier than the next timer in that case.

Handling such cases as regular wakeups in menu_update() may cause the
menu governor to make suboptimal decisions going forward, but ignoring
them altogether would not be correct either, because every time
menu_select() is invoked, it makes a separate new attempt to predict
the idle duration taking distinct time to the closest timer event as
input and the outcomes of all those attempts should be recorded.

For this reason, make menu_update() always assume that if the
"polling" state was exited due to the time limit, the next proper
wakeup event for the CPU would be the next timer event (not
including the tick).

Fixes: a37b969a "cpuidle: poll_state: Add time limit to poll_idle()"
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NHanjun Guo <guohanjun@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0
commit f941d3e4
category: bugfix
bugzilla: 6273
CVE: NA

-------------------------------------------------

There are systems in which non-wakeup GPEs fire during the "noirq"
suspend stage of suspending devices and that effectively prevents the
system that tries to suspend to idle from entering any low-power
state at all.  If the offending GPE fires regularly and often enough,
the system appears to be suspended, but in fact it is in a tight loop
over "noirq" suspend and "noirq" resume of devices all the time.

To prevent that from happening, disable all non-wakeup GPEs except
for the EC GPE for suspend-to-idle (the EC GPE is special, because
on some systems it has to be enabled for power button wakeup events
to be generated as expected).

Fixes: 147a7d9d (ACPI / PM: Do not reconfigure GPEs for suspend-to-idle)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=201987Reported-by: NZhang Rui <rui.zhang@intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NHanjun Guo <guohanjun@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0-rc1
commit c6d6e9b0
category: bugfix
bugzilla: 5879
CVE: NA
---------------------------

Update DM to set the bdi's io_pages.  This fixes reads to be capped at
the device's max request size (even if user's read IO exceeds the
established readahead setting).

Conflicts:
	drivers/md/dm-table.c

Fixes: 9491ae4a ("mm: don't cap request size based on read-ahead setting")
Cc: stable@vger.kernel.org
Reviewed-by: NJens Axboe <axboe@kernel.dk>
Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Signed-off-by: NYufen Yu <yuyufen@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-4.20-rc1
commit 059421e0
category: bugfix
bugzilla: 5837
CVE: NA
---------------------------

Commit 35bfc521 ("md: allow metadata update while suspending.")
added support for allowing md_check_recovery() to still perform
metadata updates while the array is entering the 'suspended' state.
This is needed to allow the processes of entering the state to
complete.

Unfortunately, the patch doesn't really work.  The test for
"mddev->suspended" at the start of md_check_recovery() means that the
function doesn't try to do anything at all while entering suspend.

This patch moves the code of updating the metadata while suspending to
*before* the test on mddev->suspended.
Reported-by: NJeff Mahoney <jeffm@suse.com>
Fixes: 35bfc521 ("md: allow metadata update while suspending.")
Signed-off-by: NNeilBrown <neilb@suse.com>
Signed-off-by: NShaohua Li <shli@fb.com>
Signed-off-by: NYufen Yu <yuyufen@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0-rc3
commit d1f38d99
category: bugfix
bugzilla: 5896
CVE: NA

---------------------------

This was apparently forgotten in
894169db ("scsi: megaraid_sas: Use 63-bit DMA addressing").
Signed-off-by: NTomas Henzl <thenzl@redhat.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Nzhengbin <zhengbin13@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0-rc1
commit 894169db
category: bugfix
bugzilla: 5896
CVE: NA

---------------------------

Although MegaRAID controllers support 64-bit DMA addressing, as per
hardware design, DMA address with all 64-bits set
(0xFFFFFFFF-FFFFFFFF) results in a firmware fault.

Driver will set 63-bit DMA mask to ensure the above address will not be
used.

Cc: stable@vger.kernel.org
Signed-off-by: NShivasharan S <shivasharan.srikanteshwara@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Nzhengbin <zhengbin13@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

euler inclusion
category: bugfix
bugzilla: 3305
CVE: N/A

-------------------------------------------------

Add support of port isolation for QLogic HBA cards.
Signed-off-by: NXishi Qiu <qiuxishi@huawei.com>
Signed-off-by: NFang Ying <fangying1@huawei.com>
Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NHui Wang <john.wanghui@huawei.com>
Signed-off-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com>

Confilicts:
	drivers/pci/quirks.c
Signed-off-by: NXuefeng Wang <wxf.wang@hisilicon.com>
Reviewed-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-4.20
commit b16503ba
category: bugfix
bugzilla: 6354
CVE: NA
-------------------------------------------------

Now that send_signal always delivers SEND_SIG_PRIV signals to a pid
namespace init it is no longer necessary to use SEND_SIG_FORCED when
calling do_send_sig_info to ensure that pid namespace inits are
signaled and possibly killed.  Using SEND_SIG_PRIV is sufficient.

So use SEND_SIG_PRIV so that userspace when it receives a SIGTERM can
tell that the kernel sent the signal and not some random userspace
application.

Fixes: b82c3287 ("sysrq: use SEND_SIG_FORCED instead of force_sig()")
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: NHongbo Yao <yaohongbo@huawei.com>
Reviewed-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-4.20-rc1
commit b90cd6f2
category: bugfix
bugzilla: 5811
CVE: NA

---------------------------

When the lldd is processing the complete sas task in interrupt and set the
task stat as SAS_TASK_STATE_DONE, the smp timeout timer is able to be
triggered at the same time. And smp_task_timedout() will complete the task
wheter the SAS_TASK_STATE_DONE is set or not. Then the sas task may freed
before lldd end the interrupt process. Thus a use-after-free will happen.

Fix this by calling the complete() only when SAS_TASK_STATE_DONE is not
set. And remove the check of the return value of the del_timer(). Once the
LLDD sets DONE, it must call task->done(), which will call
smp_task_done()->complete() and the task will be completed and freed
correctly.
Reported-by: Nchenxiang <chenxiang66@hisilicon.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
CC: John Garry <john.garry@huawei.com>
CC: Johannes Thumshirn <jthumshirn@suse.de>
CC: Ewan Milne <emilne@redhat.com>
CC: Christoph Hellwig <hch@lst.de>
CC: Tomas Henzl <thenzl@redhat.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: Hannes Reinecke <hare@suse.com>
Reviewed-by: NHannes Reinecke <hare@suse.com>
Reviewed-by: NJohn Garry <john.garry@huawei.com>
Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Nzhengbin <zhengbin13@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0-rc5
commit 4ea899ea
category: bugfix
bugzilla: 7376
CVE: NA

---------------------------

Introduce a local wait_for_completion variable to avoid an access to the
potentially freed dio struture after dropping the last reference count.

Also use the chance to document the completion behavior to make the
refcounting clear to the reader of the code.

Fixes: ff6a9292 ("iomap: implement direct I/O")
Reported-by: NChandan Rajendra <chandan@linux.ibm.com>
Reported-by: NDarrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Tested-by: NChandan Rajendra <chandan@linux.ibm.com>
Tested-by: NDarrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Nzhengbin <zhengbin13@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0-rc5
commit 8e47a457321ca1a74ad194ab5dcbca764bc70731
category: bugfix
bugzilla: 7377
CVE: NA

---------------------------

migrate_page_move_mapping() expects pages with private data set to have
a page_count elevated by 1.  This is what used to happen for xfs through
the buffer_heads code before the switch to iomap in commit 82cb1417
("xfs: add support for sub-pagesize writeback without buffer_heads").
Not having the count elevated causes move_pages() to fail on memory
mapped files coming from xfs.

Make iomap compatible with the migrate_page_move_mapping() assumption by
elevating the page count as part of iomap_page_create() and lowering it
in iomap_page_release().

It causes the move_pages() syscall to misbehave on memory mapped files
from xfs.  It does not not move any pages, which I suppose is "just" a
perf issue, but it also ends up returning a positive number which is out
of spec for the syscall.  Talking to Michal Hocko, it sounds like
returning positive numbers might be a necessary update to move_pages()
anyway though.

Fixes: 82cb1417 ("xfs: add support for sub-pagesize writeback without buffer_heads")
Signed-off-by: NPiotr Jaroszynski <pjaroszynski@nvidia.com>
[hch: actually get/put the page iomap_migrate_page() to make it work
      properly]
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Nzhengbin <zhengbin13@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-
commit 80ff0017
category: bugfix
bugzilla: 7227
CVE: NA

-------------------------------------------------

There is a NULL pointer dereference of dev_name in nfs_parse_devname()

The oops looks something like:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
  ...
  RIP: 0010:nfs_fs_mount+0x3b6/0xc20 [nfs]
  ...
  Call Trace:
   ? ida_alloc_range+0x34b/0x3d0
   ? nfs_clone_super+0x80/0x80 [nfs]
   ? nfs_free_parsed_mount_data+0x60/0x60 [nfs]
   mount_fs+0x52/0x170
   ? __init_waitqueue_head+0x3b/0x50
   vfs_kern_mount+0x6b/0x170
   do_mount+0x216/0xdc0
   ksys_mount+0x83/0xd0
   __x64_sys_mount+0x25/0x30
   do_syscall_64+0x65/0x220
   entry_SYSCALL_64_after_hwframe+0x49/0xbe

Fix this by adding a NULL check on dev_name
Signed-off-by: NYao Liu <yotta.liu@ucloud.cn>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: NZhangXiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: NMiao Xie <miaoxie@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0
commit 8a68d3da
category: bugfix
bugzilla: 5846
CVE: NA

-------------------------------------------------

Drop LIST_HEAD where the variable it declares is never used.

This was introduced in c5c707f9 ("nfsd: implement pNFS
layout recalls"), but was not used even in that commit.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// </smpl>

Fixes: c5c707f9 ("nfsd: implement pNFS layout recalls")
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
Signed-off-by: NZhangXiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: Nyangerkun <yangerkun@huawei.com>
Reviewed-by: NMiao Xie <miaoxie@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-v5.0-rc4-4-g9bda8723
commit 9bda8723
category: bugfix
bugzilla: 7426
CVE: NA

-------------------------------------------------

Allocation of a page array for non-cached IO was separated from
allocation of rdata and wdata structures and this introduced memory
leaks and a possible null pointer dereference. This patch fixes
these problems.

conflict:
	fs/cifs/file.c

Cc: <stable@vger.kernel.org>
Signed-off-by: NPavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: NSteve French <stfrench@microsoft.com>
Signed-off-by: NZhangXiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: NMiao Xie <miaoxie@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0
commit 73aaf920cc72
category: bugfix
bugzilla: 7230
CVE: NA

-------------------------------------------------

The call to SMB2_queary_acl can allocate memory to pntsd and also
return a failure via a call to SMB2_query_acl (and then query_info).
This occurs when query_info allocates the structure and then in
query_info the call to smb2_validate_and_copy_iov fails. Currently the
failure just returns without kfree'ing pntsd hence causing a memory
leak.

Currently, *data is allocated if it's not already pointing to a buffer,
so it needs to be kfree'd only if was allocated in query_info, so the
fix adds an allocated flag to track this.  Also set *dlen to zero on
an error just to be safe since *data is kfree'd.

Also set errno to -ENOMEM if the allocation of *data fails.

conflict:
	fs/cifs/smb2pdu.c
conflict with:c5a5f38f075c
	cifs: add a smb2_compound_op and change QUERY_INFO to use it
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NSteve French <stfrench@microsoft.com>
Reviewed-by: NDan Carpener <dan.carpenter@oracle.com>
Signed-off-by: NZhangXiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: NMiao Xie <miaoxie@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-4.20
commit 32a1fb36f6e5
category: bugfix
bugzilla: 5875
CVE: NA

-------------------------------------------------

Change these free functions to allow passing NULL as the argument and
treat it as a no-op just like free(NULL) would.
Or, if rqst->rq_iov is NULL.

The second scenario could happen for smb2_queryfs() if the call
to SMB2_query_info_init() fails and we go to qfs_exit to clean up
and free all resources.
In that case we have not yet assigned rqst[2].rq_iov and thus
the rq_iov dereference in SMB2_close_free() will cause a NULL pointer
dereference.

Fixes:  1eb9fb52 ("cifs: create SMB2_open_init()/SMB2_open_free() helpers")

conflict:
	fs/cifs/smb2pdu.c
 ba8ca1168 cifs: create helpers for SMB2_set_info_init/free()
Signed-off-by: NRonnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: NSteve French <stfrench@microsoft.com>
Reviewed-by: NAurelien Aptel <aaptel@suse.com>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: NZhangXiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: NMiao Xie <miaoxie@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0
commit 0544b324e62c
category: bugfix
bugzilla: 5840
CVE: NA

-------------------------------------------------

kzalloc can return NULL so an additional check is needed. While there
is a check for ret_buf there is no check for the allocation of
ret_buf->crfid.fid - this check is thus added. Both call-sites
of tconInfoAlloc() check for NULL return of tconInfoAlloc()
so returning NULL on failure of kzalloc() here seems appropriate.
As the kzalloc() is the only thing here that can fail it is
moved to the beginning so as not to initialize other resources
on failure of kzalloc.

Fixes: 3d4ef9a1 ("smb3: fix redundant opens on root")

conflict:
	fs/cifs/misc.c
由于未合入 fae8044c03 smb3: show number of current open files in
/proc/fs/cifs/Stats,导致冲突
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NSteve French <stfrench@microsoft.com>
Signed-off-by: NZhangXiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: NMiao Xie <miaoxie@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-4.20
commit 94c13f66e13ca0f3d5b7b9e7e385fe5db35abe3c
category: bugfix
bugzilla: 6257
CVE: NA

---------------------------

The code uses a bitmap to check for duplicate tokens during parsing, and
that doesn't work at all for the negative Opt_err token case.

There is absolutely no reason to make Opt_err be negative, and in fact
it only confuses things, since some of the affected functions actually
return a positive Opt_xyz enum _or_ a regular negative error code (eg
-EINVAL), and using -1 for Opt_err makes no sense.

There are similar problems in ima_policy.c and key encryption, but they
don't have the immediate bug wrt bitmap handing, and ima_policy.c in
particular needs a different patch to make the enum values match the
token array index.  Mimi is sending that separately.

Reported-by: syzbot+a22e0dc07567662c50bc@syzkaller.appspotmail.com
Reported-by: NEric Biggers <ebiggers@kernel.org>
Fixes: 5208cc83 ("keys, trusted: fix: *do not* allow duplicate key options")
Fixes: 00d60fd3b932 ("KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]")
Cc: James Morris James Morris <jmorris@namei.org>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Conflicts:
	security/keys/keyctl_pkey.c

commit 00d60fd3b932 ("KEYS: Provide keyctls to drive the new key type ops for
asymmetric keys [ver #2]") has not been merged to 4.19, so no file
security/keys/keyctl_pkey.c at all.
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Reviewed-by: NZhang xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0-rc1
commit 0ac6b8fb23c724b015d9ca70a89126e8d1563166
category: bugfix
bugzilla: 6249
CVE: NA

---------------------------

CRYPTO_MSG_GETALG in NLM_F_DUMP mode sometimes doesn't return all
registered crypto algorithms, because it doesn't support incremental
dumps.  crypto_dump_report() only permits itself to be called once, yet
the netlink subsystem allocates at most ~64 KiB for the skb being dumped
to.  Thus only the first recvmsg() returns data, and it may only include
a subset of the crypto algorithms even if the user buffer passed to
recvmsg() is large enough to hold all of them.

Fix this by using one of the arguments in the netlink_callback structure
to keep track of the current position in the algorithm list.  Then
userspace can do multiple recvmsg() on the socket after sending the dump
request.  This is the way netlink dumps work elsewhere in the kernel;
it's unclear why this was different (probably just an oversight).

Also fix an integer overflow when calculating the dump buffer size hint.

Fixes: a38f7907 ("crypto: Add userspace configuration API")
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Reviewed-by: NZhang xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-4.20-rc1
commit 3944f139d5592790b70bc64f197162e643a8512b
category: bugfix
bugzilla: 6250
CVE: NA

---------------------------

The encryption mode of pkcs1pad never uses out_sg and out_buf, so
there's no need to allocate the buffer, which presently is not even
being freed.

CC: Herbert Xu <herbert@gondor.apana.org.au>
CC: linux-crypto@vger.kernel.org
CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: NDan Aloni <dan@kernelim.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Reviewed-by: NZhang xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0-rc1
commit b1e3874c75ab15288f573b3532e507c37e8e7656
category: bugfix
bugzilla: 6251
CVE: nA

---------------------------

Passing string 'name' as the format specifier is potentially hazardous
because name could (although very unlikely to) have a format specifier
embedded in it causing issues when parsing the non-existent arguments
to these.  Follow best practice by using the "%s" format string for
the string 'name'.

Cleans up clang warning:
crypto/pcrypt.c:397:40: warning: format string is not a string literal
(potentially insecure) [-Wformat-security]

Fixes: a3fb1e33 ("pcrypt: Added sysfs interface to pcrypt")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Reviewed-by: NZhang xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-4.20-rc1
commit 22a8118d329334833cd30f2ceb36d28e8cae8a4f
category: bugfix
bugzilla: 6258
CVE: NA

---------------------------

After allocation, output and decomp_output both point to memory chunks of
size COMP_BUF_SIZE. Then, only the first bytes are zeroed out using
sizeof(COMP_BUF_SIZE) as parameter to memset(), because
sizeof(COMP_BUF_SIZE) provides the size of the constant and not the size of
allocated memory.

Instead, the whole allocated memory is meant to be zeroed out. Use
COMP_BUF_SIZE as parameter to memset() directly in order to accomplish
this.

Fixes: 33607384 ("crypto: testmgr - Allow different compression results")
Signed-off-by: NMichael Schupikov <michael@schupikov.de>
Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Reviewed-by: NZhang xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-4.20-rc1
commit 2ecefa0a15fd0ef88b9cd5d15ceb813008136431
category: bugfix
bugzilla: 5563
CVE: NA

---------------------------

The keyctl_dh_params struct in uapi/linux/keyctl.h contains the symbol
"private" which means that the header file will cause compilation failure
if #included in to a C++ program.  Further, the patch that added the same
struct to the keyutils package named the symbol "priv", not "private".

The previous attempt to fix this (commit 8a2336e5) did so by simply
renaming the kernel's copy of the field to dh_private, but this then breaks
existing userspace and as such has been reverted (commit 8c0f9f5b).

[And note, to those who think that wrapping the struct in extern "C" {}
 will work: it won't; that only changes how symbol names are presented to
 the assembler and linker.].

Instead, insert an anonymous union around the "private" member and add a
second member in there with the name "priv" to match the one in the
keyutils package.  The "private" member is then wrapped in !__cplusplus
cpp-conditionals to hide it from C++.

Fixes: ddbb4114 ("KEYS: Add KEYCTL_DH_COMPUTE command")
Fixes: 8a2336e5 ("uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name")
Signed-off-by: NDavid Howells <dhowells@redhat.com>
cc: Randy Dunlap <rdunlap@infradead.org>
cc: Lubomir Rintel <lkundrak@v3.sk>
cc: James Morris <jmorris@namei.org>
cc: Mat Martineau <mathew.j.martineau@linux.intel.com>
cc: Stephan Mueller <smueller@chronox.de>
cc: Andrew Morton <akpm@linux-foundation.org>
cc: Linus Torvalds <torvalds@linux-foundation.org>
cc: stable@vger.kernel.org
Signed-off-by: NJames Morris <james.morris@microsoft.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Reviewed-by: NZhang xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0-rc6
commit 10098709
category: bugfix
bugzilla: 6450
CVE: NA

---------------------------

The H6 main pin controller has four banks of interrupt-triggering pins.
The driver as originally submitted only specified three, but had pin
descriptions referencing a fourth bank. This results in a out-of-bounds
access into .irq_array of struct sunxi_pinctrl. This however did not
result in a crash until v4.20, with commit a66d9724 ("devres: Align
data[] to ARCH_KMALLOC_MINALIGN"), which changed the alignment of memory
region returned by devm_kcalloc(). The increase likely moved the
out-of-bounds access into the next, unmapped page.

With KASAN on, the bug is quite clear:

    BUG: KASAN: slab-out-of-bounds in sunxi_pinctrl_init_with_variant+0x49c/0x12b8
    Write of size 4 at addr ffff80002c680280 by task swapper/0/1

    CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc1-00016-gc480a5e6a077 #3
    Hardware name: OrangePi Lite2 (DT)
    Call trace:
     dump_backtrace+0x0/0x220
     show_stack+0x14/0x20
     dump_stack+0xac/0xd4
     print_address_description+0x60/0x25c
     kasan_report+0x14c/0x1ac
     __asan_store4+0x80/0xa0
     sunxi_pinctrl_init_with_variant+0x49c/0x12b8
     h6_pinctrl_probe+0x18/0x20
     platform_drv_probe+0x6c/0xc8
     really_probe+0x244/0x4b0
     driver_probe_device.part.4+0x11c/0x164
     __driver_attach+0x120/0x190
     bus_for_each_dev+0xe8/0x158
     driver_attach+0x30/0x40
     bus_add_driver+0x308/0x318
     driver_register+0xbc/0x1d0
     __platform_driver_register+0x7c/0x88
     h6_pinctrl_driver_init+0x18/0x20
     do_one_initcall+0xd4/0x208
     kernel_init_freeable+0x230/0x2c8
     kernel_init+0x10/0x108
     ret_from_fork+0x10/0x1c

    Allocated by task 1:
     kasan_kmalloc.part.0+0x4c/0x100
     kasan_kmalloc+0xc4/0xe8
     kasan_slab_alloc+0x14/0x20
     __kmalloc_track_caller+0x130/0x238
     devm_kmalloc+0x34/0xd0
     sunxi_pinctrl_init_with_variant+0x1d8/0x12b8
     h6_pinctrl_probe+0x18/0x20
     platform_drv_probe+0x6c/0xc8
     really_probe+0x244/0x4b0
     driver_probe_device.part.4+0x11c/0x164
     __driver_attach+0x120/0x190
     bus_for_each_dev+0xe8/0x158
     driver_attach+0x30/0x40
     bus_add_driver+0x308/0x318
     driver_register+0xbc/0x1d0
     __platform_driver_register+0x7c/0x88
     h6_pinctrl_driver_init+0x18/0x20
     do_one_initcall+0xd4/0x208
     kernel_init_freeable+0x230/0x2c8
     kernel_init+0x10/0x108
     ret_from_fork+0x10/0x1c

    Freed by task 0:
    (stack is not available)

    The buggy address belongs to the object at ffff80002c680080
     which belongs to the cache kmalloc-512 of size 512
    The buggy address is located 0 bytes to the right of
     512-byte region [ffff80002c680080, ffff80002c680280)
    The buggy address belongs to the page:
    page:ffff7e0000b1a000 count:1 mapcount:0 mapping:ffff80002e00c780 index:0xffff80002c683c80 compound_mapcount: 0
    flags: 0x10200(slab|head)
    raw: 0000000000010200 ffff80002e003a10 ffff80002e003a10 ffff80002e00c780
    raw: ffff80002c683c80 0000000000100001 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected

    Memory state around the buggy address:
     ffff80002c680180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     ffff80002c680200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >ffff80002c680280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
		       ^
     ffff80002c680300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff80002c680380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

Correct the number of IRQ banks so there are no more mismatches.

Fixes: c8a83090 ("pinctrl: sunxi: add support for the Allwinner H6 main pin controller")
Cc: <stable@vger.kernel.org>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Tested-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Reviewed-by: Nzhengbin <zhengbin13@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0-rc1
commit 7b0c03ecc42fb223baf015877fee9d517c2c8af1
category: bugfix
bugzilla: 6517
CVE: NA

---------------------------

This patch adds a new device-tree property that allows to
specify the dma protection control bits for the all of the
DMA controller's channel uniformly.

Setting the "correct" bits can have a huge impact on the
PPC460EX and APM82181 that use this DMA engine in combination
with a DesignWare' SATA-II core (sata_dwc_460ex driver).

In the OpenWrt Forum, the user takimata reported that:
|It seems your patch unleashed the full power of the SATA port.
|Where I was previously hitting a really hard limit at around
|82 MB/s for reading and 27 MB/s for writing, I am now getting this:
|
|root@OpenWrt:/mnt# time dd if=/dev/zero of=tempfile bs=1M count=1024
|1024+0 records in
|1024+0 records out
|real    0m 13.65s
|user    0m 0.01s
|sys     0m 11.89s
|
|root@OpenWrt:/mnt# time dd if=tempfile of=/dev/null bs=1M count=1024
|1024+0 records in
|1024+0 records out
|real    0m 8.41s
|user    0m 0.01s
|sys     0m 4.70s
|
|This means: 121 MB/s reading and 75 MB/s writing!
|
|The drive is a WD Green WD10EARX taken from an older MBL Single.
|I repeated the test a few times with even larger files to rule out
|any caching, I'm still seeing the same great performance. OpenWrt is
|now completely on par with the original MBL firmware's performance.

Another user And.short reported:
|I can report that your fix worked! Boots up fine with two
|drives even with more partitions, and no more reboot on
|concurrent disk access!

A closer look into the sata_dwc_460ex code revealed that
the driver did initally set the correct protection control
bits. However, this feature was lost when the sata_dwc_460ex
driver was converted to the generic DMA driver framework.

BugLink: https://forum.openwrt.org/t/wd-mybook-live-duo-two-disks/16195/55
BugLink: https://forum.openwrt.org/t/wd-mybook-live-duo-two-disks/16195/50
Fixes: 8b344485 ("sata_dwc_460ex: move to generic DMA driver")
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NChristian Lamparter <chunkeey@gmail.com>
Signed-off-by: NVinod Koul <vkoul@kernel.org>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Reviewed-by: Nzhengbin <zhengbin13@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-4.20-rc1
commit 97a103e6
category: bugfix
bugzilla: 6325
CVE: NA

---------------------------

Shifting unsigned char b by an int type can lead to sign-extension
overflow. For example, if b is 0xff and the shift is 24, then top
bit is sign-extended so the final value passed to writeq has all
the upper 32 bits set.  Fix this by casting b to a 64 bit unsigned
before the shift.

Detected by CoverityScan, CID#1465246 ("Unintended sign extension")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Reviewed-by: Nzhengbin <zhengbin13@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-4.20-rc1
commit 060e8fb5
category: bugfix
bugzilla: 6326
CVE: NA

---------------------------

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/char/ipmi/ipmi_msghandler.c: In function 'ipmi_set_my_LUN':
drivers/char/ipmi/ipmi_msghandler.c:1335:13: warning:
 variable 'rv' set but not used [-Wunused-but-set-variable]
  int index, rv = 0;

'rv' should be the correct return value.

Fixes: 048f7c3e ("ipmi: Properly release srcu locks on error conditions")
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Reviewed-by: Nzhengbin <zhengbin13@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0-rc1
commit 1ecc07fd
category: bugfix
bugzilla: 6292
CVE: NA

---------------------------

pages_correctly_probed is missing new lines which means that the line is
not printed rightaway but it rather waits for additional printks.

Add \n to all three messages in pages_correctly_probed.

Link: http://lkml.kernel.org/r/20181218162307.10518-1-mhocko@kernel.org
Fixes: b77eab70 ("mm/memory_hotplug: optimize probe routine")
Signed-off-by: NMichal Hocko <mhocko@suse.com>
Reviewed-by: NOscar Salvador <osalvador@suse.de>
Reviewed-by: NWei Yang <richard.weiyang@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Reviewed-by: Nzhengbin <zhengbin13@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

mainline inclusion
from mainline-5.0-rc1
commit f569da8c
category: bugfix
bugzilla: 6386
CVE: NA

---------------------------

Sync documentation with code.

Fixes: 07bb80d4 (device property: Add support for remote endpoints)
Signed-off-by: NMarco Felsch <m.felsch@pengutronix.de>
Acked-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Reviewed-by: Nzhengbin <zhengbin13@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>