Changes

arm/mach-at91/pm : fix possible object reference leak
of_find_device_by_node() takes a reference to the struct device when it
finds a match via get_device. When returning error we should call
put_device.
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Signed-off-by: Peng Hao
<peng.hao2@zte.com.cn> Signed-off-by: Ludovic Desroches
<ludovic.desroches@microchip.com>

mm/compaction.c: correct zone boundary handling when resetting pageblock
skip hints
Mikhail Gavrilo reported the following bug being triggered in a Fedora 
kernel based on 5.1-rc1 but it is relevant to a vanilla kernel.
 kernel: page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
kernel: ------------[ cut here ]------------
kernel: kernel BUG at include/linux/mm.h:1021!
kernel: invalid opcode: 0000 [#1] SMP NOPTI
kernel: CPU: 6 PID: 116 Comm: kswapd0 Tainted: G         C       
5.1.0-0.rc1.git1.3.fc31.x86_64 #1
kernel: Hardware name: System manufacturer System Product Name/ROG STRIX
X470-I GAMING, BIOS 1201 12/07/2018
kernel: RIP: 0010:__reset_isolation_pfn+0x244/0x2b0
kernel: Code: fe 06 e8 0f 8e fc ff 44 0f b6 4c 24 04 48 85 c0 0f 85 dc
fe ff ff e9 68 fe ff ff 48 c7 c6 58 b7 2e 8c 4c 89 ff e8 0c 75 00 00
<0f> 0b 48 c7 c6 58 b7 2e 8c e8 fe 74 00 00 0f 0b 48 89 fa 41 b8 01
kernel: RSP: 0018:ffff9e2d03f0fde8 EFLAGS: 00010246
kernel: RAX: 0000000000000034 RBX: 000000000081f380 RCX:
ffff8cffbddd6c20
kernel: RDX: 0000000000000000 RSI: 0000000000000006 RDI:
ffff8cffbddd6c20
kernel: RBP: 0000000000000001 R08: 0000009898b94613 R09:
0000000000000000
kernel: R10: 0000000000000000 R11: 0000000000000000 R12:
0000000000100000
kernel: R13: 0000000000100000 R14: 0000000000000001 R15:
ffffca7de07ce000
kernel: FS:  0000000000000000(0000) GS:ffff8cffbdc00000(0000)
knlGS:0000000000000000
kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 00007fc1670e9000 CR3: 00000007f5276000 CR4:
00000000003406e0
kernel: Call Trace:
kernel:  __reset_isolation_suitable+0x62/0x120
kernel:  reset_isolation_suitable+0x3b/0x40
kernel:  kswapd+0x147/0x540
kernel:  ? finish_wait+0x90/0x90
kernel:  kthread+0x108/0x140
kernel:  ? balance_pgdat+0x560/0x560
kernel:  ? kthread_park+0x90/0x90
kernel:  ret_from_fork+0x27/0x50
He bisected it down to e332f741a8dd ("mm, compaction: be selective about 
what pageblocks to clear skip hints").  The problem is that the patch in 
question was sloppy with respect to the handling of zone boundaries.  In 
some instances, it was possible for PFNs outside of a zone to be
examined and if those were not properly initialised or poisoned then it
would trigger the VM_BUG_ON.  This patch corrects the zone boundary
issues when resetting pageblock skip hints and Mikhail reported that the
bug did not trigger after 30 hours of testing.
Link: http://lkml.kernel.org/r/20190327085424.GL3189@techsingularity.net 
Fixes: e332f741a8dd ("mm, compaction: be selective about what pageblocks
to clear skip hints") Reported-by: Mikhail Gavrilov
<mikhail.v.gavrilov@gmail.com> Tested-by: Mikhail Gavrilov
<mikhail.v.gavrilov@gmail.com> Cc: Daniel Jordan
<daniel.m.jordan@oracle.com> Cc: Qian Cai <cai@lca.pw> Cc: Vlastimil
Babka <vbabka@suse.cz> Signed-off-by: Mel Gorman
<mgorman@techsingularity.net>

mm/compaction.c: abort search if isolation fails
Running LTP oom01 in a tight loop or memory stress testing put the
system in a low-memory situation could triggers random memory corruption
like page flag corruption below due to in fast_isolate_freepages(), if 
isolation fails, next_search_order() does not abort the search
immediately could lead to improper accesses.
UBSAN: Undefined behaviour in ./include/linux/mm.h:1195:50 index 7 is
out of range for type 'zone [5]' Call Trace:
dump_stack+0x62/0x9a
ubsan_epilogue+0xd/0x7f
__ubsan_handle_out_of_bounds+0x14d/0x192
__isolate_free_page+0x52c/0x600
compaction_alloc+0x886/0x25f0
unmap_and_move+0x37/0x1e70
migrate_pages+0x2ca/0xb20
compact_zone+0x19cb/0x3620
kcompactd_do_work+0x2df/0x680
kcompactd+0x1d8/0x6c0
kthread+0x32c/0x3f0
ret_from_fork+0x35/0x40
------------[ cut here ]------------ kernel BUG at mm/page_alloc.c:3124! 
invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI RIP:
0010:__isolate_free_page+0x464/0x600 RSP: 0000:ffff888b9e1af848 EFLAGS:
00010007 RAX: 0000000030000000 RBX: ffff888c39fcf0f8 RCX:
0000000000000000 RDX: 1ffff111873f9e25 RSI: 0000000000000004 RDI:
ffffed1173c35ef6 RBP: ffff888b9e1af898 R08: fffffbfff4fc2461 R09:
fffffbfff4fc2460 R10: fffffbfff4fc2460 R11: ffffffffa7e12303 R12:
0000000000000008 R13: dffffc0000000000 R14: 0000000000000000 R15:
0000000000000007 FS:  0000000000000000(0000) GS:ffff888ba8e80000(0000) 
knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 
CR2: 00007fc7abc00000 CR3: 0000000752416004 CR4: 00000000001606a0 DR0:
0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3:
0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:
compaction_alloc+0x886/0x25f0
unmap_and_move+0x37/0x1e70
migrate_pages+0x2ca/0xb20
compact_zone+0x19cb/0x3620
kcompactd_do_work+0x2df/0x680
kcompactd+0x1d8/0x6c0
kthread+0x32c/0x3f0
ret_from_fork+0x35/0x40
Link: http://lkml.kernel.org/r/20190320192648.52499-1-cai@lca.pw Fixes:
dbe2d4e4f12e ("mm, compaction: round-robin the order while searching the
free lists for a target") Signed-off-by: Qian Cai <cai@lca.pw> Acked-by:
Mel Gorman <mgorman@techsingularity.net> Cc: Daniel Jordan
<daniel.m.jordan@oracle.com> Cc: Mikhail Gavrilov
<mikhail.v.gavrilov@gmail.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc:
Pavel Tatashin <pasha.tatashin@soleen.com> Signed-off-by: Mel Gorman
<mgorman@techsingularity.net>

ALSA: xen-front: Do not use stream buffer size before it is set
This fixes the regression introduced while moving to Xen shared buffer
implementation.
Fixes: 58f9d806d16a ("ALSA: xen-front: Use Xen common shared buffer
implementation") Reviewed-by: Juergen Gross <jgross@suse.com> 
Signed-off-by: Oleksandr Andrushchenko
<oleksandr_andrushchenko@epam.com> Cc: <stable@vger.kernel.org> # v5.0+ 
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ptrace: Remove maxargs from task_current_syscall()
task_current_syscall() has a single user that passes in 6 for maxargs,
which is the maximum arguments that can be used to get system calls from 
syscall_get_arguments(). Instead of passing in a number of arguments to 
grab, just get 6 arguments. The args argument even specifies that it's
an array of 6 items.
This will also allow changing syscall_get_arguments() to not get a
variable number of arguments, but always grab 6.
Linus also suggested not passing in a bunch of arguments to 
task_current_syscall() but to instead pass in a pointer to a structure,
and just fill the structure. struct seccomp_data has almost all the
parameters that is needed except for the stack pointer (sp). As
seccomp_data is part of uapi, and I'm afraid to change it, a new
structure was created
"syscall_info", which includes seccomp_data and adds the "sp" field.
Link: http://lkml.kernel.org/r/20161107213233.466776454@goodmis.org
Cc: Andy Lutomirski <luto@kernel.org> Cc: Alexey Dobriyan
<adobriyan@gmail.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Kees Cook
<keescook@chromium.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc:
linux-fsdevel@vger.kernel.org Reviewed-by: Thomas Gleixner
<tglx@linutronix.de> Signed-off-by: Steven Rostedt (VMware)
<rostedt@goodmis.org>

tracing/syscalls: Pass in hardcoded 6 into syscall_get_arguments()
The only users that calls syscall_get_arguments() with a variable and
not a hard coded '6' is ftrace_syscall_enter(). syscall_get_arguments()
can be optimized by removing a variable input, and always grabbing 6
arguments regardless of what the system call actually uses.
Change ftrace_syscall_enter() to pass the 6 args into a local stack
array and copy the necessary arguments into the trace event as needed.
This is needed to remove two parameters from syscall_get_arguments().
Link: http://lkml.kernel.org/r/20161107213233.627583542@goodmis.org
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

flow_dissector: rst'ify documentation
Rename bpf_flow_dissector.txt to bpf_flow_dissector.rst and fix 
formatting. Also, link it from the Documentation/networking/index.rst.
Tested with 'make htmldocs' to make sure it looks reasonable.
Fixes: ae82899bbe92 ("flow_dissector: document BPF flow dissector
environment") Signed-off-by: Stanislav Fomichev <sdf@google.com> 
Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Daniel Borkmann
<daniel@iogearbox.net>

riscv: Fix syscall_get_arguments() and syscall_set_arguments()
RISC-V syscall arguments are located in orig_a0,a1..a5 fields of struct
pt_regs.
Due to an off-by-one bug and a bug in pointer arithmetic 
syscall_get_arguments() was reading s3..s7 fields instead of a1..a5. 
Likewise, syscall_set_arguments() was writing s3..s7 fields instead of
a1..a5.
Link: http://lkml.kernel.org/r/20190329171221.GA32456@altlinux.org
Fixes: e2c0cdfba7f69 ("RISC-V: User-facing API") Cc: Ingo Molnar
<mingo@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: Andy
Lutomirski <luto@amacapital.net> Cc: Will Drewry <wad@chromium.org> Cc:
Albert Ou <aou@eecs.berkeley.edu> Cc: linux-riscv@lists.infradead.org 
Cc: stable@vger.kernel.org # v4.15+ Acked-by: Palmer Dabbelt
<palmer@sifive.com> Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> 
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

csky: Fix syscall_get_arguments() and syscall_set_arguments()
C-SKY syscall arguments are located in orig_a0,a1,a2,a3,regs[0],regs[1] 
fields of struct pt_regs.
Due to an off-by-one bug and a bug in pointer arithmetic 
syscall_get_arguments() was reading orig_a0,regs[1..5] fields instead. 
Likewise, syscall_set_arguments() was writing orig_a0,regs[1..5] fields 
instead.
Link: http://lkml.kernel.org/r/20190329171230.GB32456@altlinux.org
Fixes: 4859bfca11c7d ("csky: System Call") Cc: Ingo Molnar
<mingo@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: Andy
Lutomirski <luto@amacapital.net> Cc: Will Drewry <wad@chromium.org> Cc:
stable@vger.kernel.org # v4.20+ Tested-by: Guo Ren <ren_guo@c-sky.com> 
Acked-by: Guo Ren <ren_guo@c-sky.com> Signed-off-by: Dmitry V. Levin
<ldv@altlinux.org> Signed-off-by: Steven Rostedt (VMware)
<rostedt@goodmis.org>

blk-mq: do not reset plug->rq_count before the list is sorted
We would never be able to sort the list if we first reset plug->rq_count 
which is used in conditional check later.
Fixes: ce5b009cff19 ("block: improve logic around when to sort a plug
list") Reviewed-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Dongli
Zhang <dongli.zhang@oracle.com> Signed-off-by: Jens Axboe
<axboe@kernel.dk>

arm64: fix wrong check of on_sdei_stack in nmi context
When doing unwind_frame() in the context of pseudo nmi (need enable 
CONFIG_ARM64_PSEUDO_NMI), reaching the bottom of the stack (fp == 0, pc
!= 0), function on_sdei_stack() will return true while the sdei acpi 
table is not inited in fact. This will cause a "NULL pointer
dereference" oops when going on.
Reviewed-by: Julien Thierry <julien.thierry@arm.com> Signed-off-by: Wei
Li <liwei391@huawei.com> Signed-off-by: Catalin Marinas
<catalin.marinas@arm.com>

drm/amdkfd: Add picasso pci id
Picasso is a new raven variant.
Reviewed-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex
Deucher <alexander.deucher@amd.com>

drm/amdgpu: Adjust IB test timeout for XGMI configuration
On XGMI configuration the ib test may take longer to finish
Signed-off-by: shaoyunl <shaoyun.liu@amd.com> Reviewed-by: Christian
König <christian.koenig@amd.com> Signed-off-by: Alex Deucher
<alexander.deucher@amd.com>

drm/amdgpu: amdgpu_device_recover_vram always failed if only one node in
shadow_list
amdgpu_bo_restore_shadow would assign zero to r if succeeded. r would
remain zero if there is only one node in shadow_list. current code would
always return failure when r <= 0. restart the timeout for each wait was
a rather problematic bug as well. The value of tmo SHOULD be changed,
otherwise we wait tmo jiffies on each loop.
Signed-off-by: Wentao Lou <Wentao.Lou@amd.com> Reviewed-by: Christian
König <christian.koenig@amd.com> Signed-off-by: Alex Deucher
<alexander.deucher@amd.com>

drm/amd/display: fix cursor black issue
[Why] the member sdr_white_level of struct dc_cursor_attributes was not 
initialized, then the random value result that 
dcn10_set_cursor_sdr_white_level() set error hw_scale value
0x20D9(normal value is 0x3c00), this cause the black cursor issue.
[how] just initilize the obj of struct dc_cursor_attributes to zero to
avoid the random value.
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> 
Signed-off-by: Tianci Yin <tianci.yin@amd.com> Signed-off-by: Alex
Deucher <alexander.deucher@amd.com>

btrfs: prop: fix zstd compression parameter validation
We let pass zstd compression parameter even if it is not fully valid. 
For example:
  $ btrfs prop set /btrfs compression zst
 $ btrfs prop get /btrfs compression
    compression=zst
zlib and lzo are fine.
Fix it by checking the correct prefix length.
Fixes: 5c1aab1dd544 ("btrfs: Add zstd support") CC:
stable@vger.kernel.org # 4.14+ Reviewed-by: Nikolay Borisov
<nborisov@suse.com> Signed-off-by: Anand Jain <anand.jain@oracle.com> 
Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba
<dsterba@suse.com>

btrfs: prop: fix vanished compression property after failed set
The compression property resets to NULL, instead of the old value if we 
fail to set the new compression parameter.
  $ btrfs prop get /btrfs compression
   compression=lzo
 $ btrfs prop set /btrfs compression zli
   ERROR: failed to set compression for /btrfs: Invalid argument
 $ btrfs prop get /btrfs compression
This is because the compression property ->validate() is successful for
'zli' as the strncmp() used the length passed from the userspace.
Fix it by using the expected string length in strncmp().
Fixes: 63541927c8d1 ("Btrfs: add support for inode properties") Fixes:
5c1aab1dd544 ("btrfs: Add zstd support") CC: stable@vger.kernel.org #
4.14+ Reviewed-by: Nikolay Borisov <nborisov@suse.com> Signed-off-by:
Anand Jain <anand.jain@oracle.com> Reviewed-by: David Sterba
<dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

net: hns: fix KASAN: use-after-free in hns_nic_net_xmit_hw()
This patch is trying to fix the issue due to:
[27237.844750] BUG: KASAN: use-after-free in
hns_nic_net_xmit_hw+0x708/0xa18[hns_enet_drv]
After hnae_queue_xmit() in hns_nic_net_xmit_hw(), can be interrupted by
interruptions, and than call hns_nic_tx_poll_one() to handle the new
packets, and free the skb. So, when turn back to hns_nic_net_xmit_hw(),
calling skb->len will cause use-after-free.
This patch update tx ring statistics in hns_nic_tx_poll_one() to fix the
bug.
Signed-off-by: Liubin Shu <shuliubin@huawei.com> Signed-off-by: Zhen Lei
<thunder.leizhen@huawei.com> Signed-off-by: Yonglong Liu
<liuyonglong@huawei.com> Signed-off-by: Peng Li <lipeng321@huawei.com> 
Signed-off-by: David S. Miller <davem@davemloft.net>

net: hns: Use NAPI_POLL_WEIGHT for hns driver
When the HNS driver loaded, always have an error print:
"netif_napi_add() called with weight 256"
This is because the kernel checks the NAPI polling weights requested by
drivers and it prints an error message if a driver requests a weight
bigger than 64.
So use NAPI_POLL_WEIGHT to fix it.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com> Signed-off-by: Peng
Li <lipeng321@huawei.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

net: hns: Fix probabilistic memory overwrite when HNS driver initialized
When reboot the system again and again, may cause a memory overwrite.
[   15.638922] systemd[1]: Reached target Swap.
[   15.667561] tun: Universal TUN/TAP device driver, 1.6
[   15.676756] Bridge firewalling registered
[   17.344135] Unable to handle kernel paging request at virtual address
0000000200000040
[   17.352179] Mem abort info:
[   17.355007]   ESR = 0x96000004
[   17.358105]   Exception class = DABT (current EL), IL = 32 bits
[   17.364112]   SET = 0, FnV = 0
[   17.367209]   EA = 0, S1PTW = 0
[   17.370393] Data abort info:
[   17.373315]   ISV = 0, ISS = 0x00000004
[   17.377206]   CM = 0, WnR = 0
[   17.380214] user pgtable: 4k pages, 48-bit VAs, pgdp =
(____ptrval____)
[   17.386926] [0000000200000040] pgd=0000000000000000
[   17.391878] Internal error: Oops: 96000004 [#1] SMP
[   17.396824] CPU: 23 PID: 95 Comm: kworker/u130:0 Tainted: G          
 E     4.19.25-1.2.78.aarch64 #1
[   17.414175] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.54
08/16/2018
[   17.425615] Workqueue: events_unbound async_run_entry_fn
[   17.435151] pstate: 00000005 (nzcv daif -PAN -UAO)
[   17.444139] pc : __mutex_lock.isra.1+0x74/0x540
[   17.453002] lr : __mutex_lock.isra.1+0x3c/0x540
[   17.461701] sp : ffff000100d9bb60
[   17.469146] x29: ffff000100d9bb60 x28: 0000000000000000
[   17.478547] x27: 0000000000000000 x26: ffff802fb8945000
[   17.488063] x25: 0000000000000000 x24: ffff802fa32081a8
[   17.497381] x23: 0000000000000002 x22: ffff801fa2b15220
[   17.506701] x21: ffff000009809000 x20: ffff802fa23a0888
[   17.515980] x19: ffff801fa2b15220 x18: 0000000000000000
[   17.525272] x17: 0000000200000000 x16: 0000000200000000
[   17.534511] x15: 0000000000000000 x14: 0000000000000000
[   17.543652] x13: ffff000008d95db8 x12: 000000000000000d
[   17.552780] x11: ffff000008d95d90 x10: 0000000000000b00
[   17.561819] x9 : ffff000100d9bb90 x8 : ffff802fb89d6560
[   17.570829] x7 : 0000000000000004 x6 : 00000004a1801d05
[   17.579839] x5 : 0000000000000000 x4 : 0000000000000000
[   17.588852] x3 : ffff802fb89d5a00 x2 : 0000000000000000
[   17.597734] x1 : 0000000200000000 x0 : 0000000200000000
[   17.606631] Process kworker/u130:0 (pid: 95, stack limit =
0x(____ptrval____))
[   17.617438] Call trace:
[   17.623349]  __mutex_lock.isra.1+0x74/0x540
[   17.630927]  __mutex_lock_slowpath+0x24/0x30
[   17.638602]  mutex_lock+0x50/0x60
[   17.645295]  drain_workqueue+0x34/0x198
[   17.652623]  __sas_drain_work+0x7c/0x168
[   17.659903]  sas_drain_work+0x60/0x68
[   17.666947]  hisi_sas_scan_finished+0x30/0x40 [hisi_sas_main]
[   17.676129]  do_scsi_scan_host+0x70/0xb0
[   17.683534]  do_scan_async+0x20/0x228
[   17.690586]  async_run_entry_fn+0x4c/0x1d0
[   17.697997]  process_one_work+0x1b4/0x3f8
[   17.705296]  worker_thread+0x54/0x470
Every time the call trace is not the same, but the overwrite address is
always the same: Unable to handle kernel paging request at virtual
address 0000000200000040
The root cause is, when write the reg XGMAC_MAC_TX_LF_RF_CONTROL_REG, 
didn't use the io_base offset.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>

net: hns: fix ICMP6 neighbor solicitation messages discard problem
ICMP6 neighbor solicitation messages will be discard by the Hip06 chips,
because of not setting forwarding pool. Enable promisc mode has the same
problem.
This patch fix the wrong forwarding table configs for the multicast 
vague matching when enable promisc mode, and add forwarding pool for the
forwarding table.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>

net: hns: Fix WARNING when remove HNS driver with SMMU enabled
When enable SMMU, remove HNS driver will cause a WARNING:
[  141.924177] WARNING: CPU: 36 PID: 2708 at
drivers/iommu/dma-iommu.c:443 __iommu_dma_unmap+0xc0/0xc8
[  141.954673] Modules linked in: hns_enet_drv(-)
[  141.963615] CPU: 36 PID: 2708 Comm: rmmod Tainted: G        W        
5.0.0-rc1-28723-gb729c57de95c-dirty #32
[  141.983593] Hardware name: Huawei D05/D05, BIOS Hisilicon D05 UEFI
Nemo 1.8 RC0 08/31/2017
[  142.000244] pstate: 60000005 (nZCv daif -PAN -UAO)
[  142.009886] pc : __iommu_dma_unmap+0xc0/0xc8
[  142.018476] lr : __iommu_dma_unmap+0xc0/0xc8
[  142.027066] sp : ffff000013533b90
[  142.033728] x29: ffff000013533b90 x28: ffff8013e6983600
[  142.044420] x27: 0000000000000000 x26: 0000000000000000
[  142.055113] x25: 0000000056000000 x24: 0000000000000015
[  142.065806] x23: 0000000000000028 x22: ffff8013e66eee68
[  142.076499] x21: ffff8013db919800 x20: 0000ffffefbff000
[  142.087192] x19: 0000000000001000 x18: 0000000000000007
[  142.097885] x17: 000000000000000e x16: 0000000000000001
[  142.108578] x15: 0000000000000019 x14: 363139343a70616d
[  142.119270] x13: 6e75656761705f67 x12: 0000000000000000
[  142.129963] x11: 00000000ffffffff x10: 0000000000000006
[  142.140656] x9 : 1346c1aa88093500 x8 : ffff0000114de4e0
[  142.151349] x7 : 6662666578303d72 x6 : ffff0000105ffec8
[  142.162042] x5 : 0000000000000000 x4 : 0000000000000000
[  142.172734] x3 : 00000000ffffffff x2 : ffff0000114de500
[  142.183427] x1 : 0000000000000000 x0 : 0000000000000035
[  142.194120] Call trace:
[  142.199030]  __iommu_dma_unmap+0xc0/0xc8
[  142.206920]  iommu_dma_unmap_page+0x20/0x28
[  142.215335]  __iommu_unmap_page+0x40/0x60
[  142.223399]  hnae_unmap_buffer+0x110/0x134
[  142.231639]  hnae_free_desc+0x6c/0x10c
[  142.239177]  hnae_fini_ring+0x14/0x34
[  142.246540]  hnae_fini_queue+0x2c/0x40
[  142.254080]  hnae_put_handle+0x38/0xcc
[  142.261619]  hns_nic_dev_remove+0x54/0xfc [hns_enet_drv]
[  142.272312]  platform_drv_remove+0x24/0x64
[  142.280552]  device_release_driver_internal+0x17c/0x20c
[  142.291070]  driver_detach+0x4c/0x90
[  142.298259]  bus_remove_driver+0x5c/0xd8
[  142.306148]  driver_unregister+0x2c/0x54
[  142.314037]  platform_driver_unregister+0x10/0x18
[  142.323505]  hns_nic_dev_driver_exit+0x14/0xf0c [hns_enet_drv]
[  142.335248]  __arm64_sys_delete_module+0x214/0x25c
[  142.344891]  el0_svc_common+0xb0/0x10c
[  142.352430]  el0_svc_handler+0x24/0x80
[  142.359968]  el0_svc+0x8/0x7c0
[  142.366104] ---[ end trace 60ad1cd58e63c407 ]---
The tx ring buffer map when xmit and unmap when xmit done. So in 
hnae_init_ring() did not map tx ring buffer, but in hnae_fini_ring() 
have a unmap operation for tx ring buffer, which is already unmapped 
when xmit done, than cause this WARNING.
The hnae_alloc_buffers() is called in hnae_init_ring(), so the
hnae_free_buffers() should be in hnae_fini_ring(), not in 
hnae_free_desc().
In hnae_fini_ring(), adds a check is_rx_ring() as in hnae_init_ring(). 
When the ring buffer is tx ring, adds a piece of code to ensure that the
tx ring is unmap.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com> Signed-off-by: Peng
Li <lipeng321@huawei.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

net: hns: Fix sparse: some warnings in HNS drivers
There are some sparse warnings in the HNS drivers:
warning: incorrect type in assignment (different address spaces)
   expected void [noderef] <asn:2> *io_base
   got void *vaddr warning: cast removes address space '<asn:2>' of
expression
[...]
Add __iomem and change all the u8 __iomem to void __iomem to fix these
kind of  warnings.
warning: incorrect type in argument 1 (different address spaces)
   expected void [noderef] <asn:2> *base
   got unsigned char [usertype] *base_addr warning: cast to restricted
__le16 warning: incorrect type in assignment (different base types)
   expected unsigned int [usertype] tbl_tcam_data_high
   got restricted __le32 [usertype] warning: cast to restricted __le32
[...]
These variables used u32/u16 as their type, and finally as a parameter
of writel(), writel() will do the cpu_to_le32 coversion so remove the
little endian covert code to fix these kind of warnings.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>

net: thunderx: fix NULL pointer dereference in nicvf_open/nicvf_stop
When a bpf program is uploaded, the driver computes the number of xdp tx
queues resulting in the allocation of additional qsets. Starting from
commit '2ecbe4f4a027 ("net: thunderx: replace global nicvf_rx_mode_wq
work queue for all VFs to private for each of them")' the driver runs
link state polling for each VF resulting in the following NULL pointer
dereference:
[   56.169256] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000020
[   56.178032] Mem abort info:
[   56.180834]   ESR = 0x96000005
[   56.183877]   Exception class = DABT (current EL), IL = 32 bits
[   56.189792]   SET = 0, FnV = 0
[   56.192834]   EA = 0, S1PTW = 0
[   56.195963] Data abort info:
[   56.198831]   ISV = 0, ISS = 0x00000005
[   56.202662]   CM = 0, WnR = 0
[   56.205619] user pgtable: 64k pages, 48-bit VAs, pgdp =
0000000021f0c7a0
[   56.212315] [0000000000000020] pgd=0000000000000000,
pud=0000000000000000
[   56.219094] Internal error: Oops: 96000005 [#1] SMP
[   56.260459] CPU: 39 PID: 2034 Comm: ip Not tainted 5.1.0-rc3+ #3
[   56.266452] Hardware name: GIGABYTE R120-T33/MT30-GS1, BIOS T49
02/02/2018
[   56.273315] pstate: 80000005 (Nzcv daif -PAN -UAO)
[   56.278098] pc : __ll_sc___cmpxchg_case_acq_64+0x4/0x20
[   56.283312] lr : mutex_lock+0x2c/0x50
[   56.286962] sp : ffff0000219af1b0
[   56.290264] x29: ffff0000219af1b0 x28: ffff800f64de49a0
[   56.295565] x27: 0000000000000000 x26: 0000000000000015
[   56.300865] x25: 0000000000000000 x24: 0000000000000000
[   56.306165] x23: 0000000000000000 x22: ffff000011117000
[   56.311465] x21: ffff800f64dfc080 x20: 0000000000000020
[   56.316766] x19: 0000000000000020 x18: 0000000000000001
[   56.322066] x17: 0000000000000000 x16: ffff800f2e077080
[   56.327367] x15: 0000000000000004 x14: 0000000000000000
[   56.332667] x13: ffff000010964438 x12: 0000000000000002
[   56.337967] x11: 0000000000000000 x10: 0000000000000c70
[   56.343268] x9 : ffff0000219af120 x8 : ffff800f2e077d50
[   56.348568] x7 : 0000000000000027 x6 : 000000062a9d6a84
[   56.353869] x5 : 0000000000000000 x4 : ffff800f2e077480
[   56.359169] x3 : 0000000000000008 x2 : ffff800f2e077080
[   56.364469] x1 : 0000000000000000 x0 : 0000000000000020
[   56.369770] Process ip (pid: 2034, stack limit = 0x00000000c862da3a)
[   56.376110] Call trace:
[   56.378546]  __ll_sc___cmpxchg_case_acq_64+0x4/0x20
[   56.383414]  drain_workqueue+0x34/0x198
[   56.387247]  nicvf_open+0x48/0x9e8 [nicvf]
[   56.391334]  nicvf_open+0x898/0x9e8 [nicvf]
[   56.395507]  nicvf_xdp+0x1bc/0x238 [nicvf]
[   56.399595]  dev_xdp_install+0x68/0x90
[   56.403333]  dev_change_xdp_fd+0xc8/0x240
[   56.407333]  do_setlink+0x8e0/0xbe8
[   56.410810]  __rtnl_newlink+0x5b8/0x6d8
[   56.414634]  rtnl_newlink+0x54/0x80
[   56.418112]  rtnetlink_rcv_msg+0x22c/0x2f8
[   56.422199]  netlink_rcv_skb+0x60/0x120
[   56.426023]  rtnetlink_rcv+0x28/0x38
[   56.429587]  netlink_unicast+0x1c8/0x258
[   56.433498]  netlink_sendmsg+0x1b4/0x350
[   56.437410]  sock_sendmsg+0x4c/0x68
[   56.440887]  ___sys_sendmsg+0x240/0x280
[   56.444711]  __sys_sendmsg+0x68/0xb0
[   56.448275]  __arm64_sys_sendmsg+0x2c/0x38
[   56.452361]  el0_svc_handler+0x9c/0x128
[   56.456186]  el0_svc+0x8/0xc
[   56.459056] Code: 35ffff91 2a1003e0 d65f03c0 f9800011 (c85ffc10)
[   56.465166] ---[ end trace 4a57fdc27b0a572c ]---
[   56.469772] Kernel panic - not syncing: Fatal exception
Fix it by checking nicvf_rx_mode_wq pointer in nicvf_open and nicvf_stop
Fixes: 2ecbe4f4a027 ("net: thunderx: replace global nicvf_rx_mode_wq
work queue for all VFs to private for each of them") Fixes: 2c632ad8bc74
("net: thunderx: move link state polling function to VF") Reported-by:
Matteo Croce <mcroce@redhat.com> Signed-off-by: Lorenzo Bianconi
<lorenzo.bianconi@redhat.com> Tested-by: Matteo Croce
<mcroce@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>

net/sched: act_sample: fix divide by zero in the traffic path
the control path of 'sample' action does not validate the value of
'rate' provided by the user, but then it uses it as divisor in the
traffic path. Validate it in tcf_sample_init(), and return -EINVAL with
a proper extack message in case that value is zero, to fix a splat with
the script below:
 # tc f a dev test0 egress matchall action sample rate 0 group 1 index 2
# tc -s a s action sample
total acts 1
         action order 0: sample rate 1/0 group 1 pipe
         index 2 ref 1 bind 1 installed 19 sec used 19 sec
        Action statistics:
        Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
        backlog 0b 0p requeues 0
# ping 192.0.2.1 -I test0 -c1 -q
 divide error: 0000 [#1] SMP PTI
CPU: 1 PID: 6192 Comm: ping Not tainted 5.1.0-rc2.diag2+ #591
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:tcf_sample_act+0x9e/0x1e0 [act_sample]
Code: 6a f1 85 c0 74 0d 80 3d 83 1a 00 00 00 0f 84 9c 00 00 00 4d 85 e4
0f 84 85 00 00 00 e8 9b d7 9c f1 44 8b 8b e0 00 00 00 31 d2 <41> f7 f1
85 d2 75 70 f6 85 83 00 00 00 10 48 8b 45 10 8b 88 08 01
RSP: 0018:ffffae320190ba30 EFLAGS: 00010246
RAX: 00000000b0677d21 RBX: ffff8af1ed9ec000 RCX: 0000000059a9fe49
RDX: 0000000000000000 RSI: 000000000c7e33b7 RDI: ffff8af23daa0af0
RBP: ffff8af1ee11b200 R08: 0000000074fcaf7e R09: 0000000000000000
R10: 0000000000000050 R11: ffffffffb3088680 R12: ffff8af232307f80
R13: 0000000000000003 R14: ffff8af1ed9ec000 R15: 0000000000000000
FS:  00007fe9c6d2f740(0000) GS:ffff8af23da80000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fff6772f000 CR3: 00000000746a2004 CR4: 00000000001606e0
Call Trace:
 tcf_action_exec+0x7c/0x1c0
 tcf_classify+0x57/0x160
 __dev_queue_xmit+0x3dc/0xd10
 ip_finish_output2+0x257/0x6d0
 ip_output+0x75/0x280
 ip_send_skb+0x15/0x40
 raw_sendmsg+0xae3/0x1410
 sock_sendmsg+0x36/0x40
 __sys_sendto+0x10e/0x140
 __x64_sys_sendto+0x24/0x30
 do_syscall_64+0x60/0x210
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
 [...]
 Kernel panic - not syncing: Fatal exception in interrupt
Add a TDC selftest to document that 'rate' is now being validated.
Reported-by: Matteo Croce <mcroce@redhat.com> Fixes: 5c5670fae430
("net/sched: Introduce sample tc action") Signed-off-by: Davide Caratti
<dcaratti@redhat.com> Acked-by: Yotam Gigi <yotam.gi@gmail.com> 
Signed-off-by: David S. Miller <davem@davemloft.net>

tcp: Ensure DCTCP reacts to losses
RFC8257 §3.5 explicitly states that "A DCTCP sender MUST react to loss
episodes in the same way as conventional TCP".
Currently, Linux DCTCP performs no cwnd reduction when losses are
encountered. Optionally, the dctcp_clamp_alpha_on_loss resets alpha to
its maximal value if a RTO happens. This behavior is sub-optimal for at
least two reasons: i) it ignores losses triggering fast retransmissions;
and ii) it causes unnecessary large cwnd reduction in the future if the
loss was isolated as it resets the historical term of DCTCP's alpha EWMA
to its maximal value (i.e., denoting a total congestion). The second
reason has an especially noticeable effect when using DCTCP in high BDP
environments, where alpha normally stays at low values.
This patch replace the clamping of alpha by setting ssthresh to half of
cwnd for both fast retransmissions and RTOs, at most once per RTT.
Consequently, the dctcp_clamp_alpha_on_loss module parameter has been
removed.
The table below shows experimental results where we measured the drop
probability of a PIE AQM (not applying ECN marks) at a bottleneck in the
presence of a single TCP flow with either the alpha-clamping option
enabled or the cwnd halving proposed by this patch. Results using reno
or cubic are given for comparison.
                          |  Link   |   RTT    |    Drop
                TCP CC   |  speed  | base+AQM | probability
       ==================|=========|==========|============
                   CUBIC |  40Mbps |  7+20ms  |    0.21%
                    RENO |         |          |    0.19%
       DCTCP-CLAMP-ALPHA |         |          |   25.80%
        DCTCP-HALVE-CWND |         |          |    0.22%
       ------------------|---------|----------|------------
                   CUBIC | 100Mbps |  7+20ms  |    0.03%
                    RENO |         |          |    0.02%
       DCTCP-CLAMP-ALPHA |         |          |   23.30%
        DCTCP-HALVE-CWND |         |          |    0.04%
       ------------------|---------|----------|------------
                   CUBIC | 800Mbps |   1+1ms  |    0.04%
                    RENO |         |          |    0.05%
       DCTCP-CLAMP-ALPHA |         |          |   18.70%
        DCTCP-HALVE-CWND |         |          |    0.06%
We see that, without halving its cwnd for all source of losses, DCTCP
drives the AQM to large drop probabilities in order to keep the queue
length under control (i.e., it repeatedly faces RTOs). Instead, if DCTCP
reacts to all source of losses, it can then be controlled by the AQM
using similar drop levels than cubic or reno.
Signed-off-by: Koen De Schepper <koen.de_schepper@nokia-bell-labs.com> 
Signed-off-by: Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com> Cc:
Bob Briscoe <research@bobbriscoe.net> Cc: Lawrence Brakmo
<brakmo@fb.com> Cc: Florian Westphal <fw@strlen.de> Cc: Daniel Borkmann
<borkmann@iogearbox.net> Cc: Yuchung Cheng <ycheng@google.com> Cc: Neal
Cardwell <ncardwell@google.com> Cc: Eric Dumazet <edumazet@google.com> 
Cc: Andrew Shewmaker <agshew@gmail.com> Cc: Glenn Judd
<glenn.judd@morganstanley.com> Acked-by: Florian Westphal <fw@strlen.de> 
Acked-by: Neal Cardwell <ncardwell@google.com> Acked-by: Daniel Borkmann
<daniel@iogearbox.net> Signed-off-by: David S. Miller
<davem@davemloft.net>

sch_cake: Use tc_skb_protocol() helper for getting packet protocol
We shouldn't be using skb->protocol directly as that will miss cases
with hardware-accelerated VLAN tags. Use the helper instead to get the
right protocol number.
Reported-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> 
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>

sch_cake: Make sure we can write the IP header before changing DSCP bits
There is not actually any guarantee that the IP headers are valid before
we access the DSCP bits of the packets. Fix this using the same approach
taken in sch_dsmark.
Reported-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> 
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>

MIPS: generic: Add switchdev, pinctrl and fit to ocelot_defconfig
Some of the configuration were not selected by default anymore,
therefore enable them again. Also remove some configs which are used for
MSCC Ocelot.
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> 
Signed-off-by: Paul Burton <paul.burton@mips.com> Cc:
<alexandre.belloni@bootlin.com> Cc: <UNGLinuxDriver@microchip.com> Cc:
<ralf@linux-mips.org> Cc: <jhogan@kernel.org> Cc:
<linux-mips@vger.kernel.org> Cc: <linux-kernel@vger.kernel.org>

xtensa: fix return_address
return_address returns the address that is one level higher in the call 
stack than requested in its argument, because level 0 corresponds to its 
caller's return address. Use requested level as the number of stack 
frames to skip.
This fixes the address reported by might_sleep and friends.
Cc: stable@vger.kernel.org Signed-off-by: Max Filippov
<jcmvbkbc@gmail.com>

dm: disable DISCARD if the underlying storage no longer supports it
Storage devices which report supporting discard commands like 
WRITE_SAME_16 with unmap, but reject discard commands sent to the 
storage device.  This is a clear storage firmware bug but it doesn't 
change the fact that should a program cause discards to be sent to a 
multipath device layered on this buggy storage, all paths can end up 
failed at the same time from the discards, causing possible I/O loss.
The first discard to a path will fail with Illegal Request, Invalid 
field in cdb, e.g.:
kernel: sd 8:0:8:19: [sdfn] tag#0 FAILED Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
kernel: sd 8:0:8:19: [sdfn] tag#0 Sense Key : Illegal Request [current]
kernel: sd 8:0:8:19: [sdfn] tag#0 Add. Sense: Invalid field in cdb
kernel: sd 8:0:8:19: [sdfn] tag#0 CDB: Write same(16) 93 08 00 00 00 00
00 a0 08 00 00 00 80 00 00 00
kernel: blk_update_request: critical target error, dev sdfn, sector
10487808
The SCSI layer converts this to the BLK_STS_TARGET error number, the sd 
device disables its support for discard on this path, and because of the 
BLK_STS_TARGET error multipath fails the discard without failing any 
path or retrying down a different path.  But subsequent discards can 
cause path failures.  Any discards sent to the path which already failed 
a discard ends up failing with EIO from blk_cloned_rq_check_limits with 
an "over max size limit" error since the discard limit was set to 0 by 
the sd driver for the path.  As the error is EIO, this now fails the 
path and multipath tries to send the discard down the next path.  This 
cycle continues as discards are sent until all paths fail.
Fix this by training DM core to disable DISCARD if the underlying 
storage already did so.
Also, fix branching in dm_done() and clone_endio() to reflect the 
mutually exclussive nature of the IO operations in question.
Cc: stable@vger.kernel.org Reported-by: David Jeffery
<djeffery@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>

mtd: cfi: fix deadloop in cfi_cmdset_0002.c do_write_buffer
In function do_write_buffer(), in the for loop, there is a case 
chip_ready() returns 1 while chip_good() returns 0, so it never break
the loop. To fix this, chip_good() is enough and it should timeout if it
stay bad for a while.
Fixes: dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check
correct value") Signed-off-by: Yi Huaijie <yihuaijie@huawei.com> 
Signed-off-by: Liu Jian <liujian56@huawei.com> Reviewed-by: Tokunori
Ikegami <ikegami_to@yahoo.co.jp> Signed-off-by: Richard Weinberger
<richard@nod.at>

aio: use kmem_cache_free() instead of kfree()
memory allocated by kmem_cache_alloc() should be freed using 
kmem_cache_free(), not kfree().
Fixes: fa0ca2aee3be ("deal with get_reqs_available() in aio_get_req()
itself") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> 
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

vlan: conditional inclusion of FCoE hooks to match netdevice.h and bnx2x
Way back in 3c9c36bcedd426f2be2826da43e5163de61735f7 the 
ndo_fcoe_get_wwn pointer was switched from depending on CONFIG_FCOE to 
CONFIG_LIBFCOE in order to allow building FCoE support into the bnx2x 
driver and used by bnx2fc without including the generic software fcoe 
module.
But, FCoE is generally used over an 802.1q VLAN, and the implementation 
of ndo_fcoe_get_wwn in the 8021q module was not similarly changed.  The 
result is that if CONFIG_FCOE is disabled, then bnz2fc cannot make a 
call to ndo_fcoe_get_wwn through the 8021q interface to the underlying 
bnx2x interface.  The bnx2fc driver then falls back to a potentially 
different mapping of Ethernet MAC to Fibre Channel WWN, creating an 
incompatibility with the fabric and target configurations when compared 
to the WWNs used by pre-boot firmware and differently-configured 
kernels.
So make the conditional inclusion of FCoE code in 8021q match the 
conditional inclusion in netdevice.h
Signed-off-by: Chris Leech <cleech@redhat.com> Signed-off-by: David S.
Miller <davem@davemloft.net>

libcxgb: fix incorrect ppmax calculation
BITS_TO_LONGS() uses DIV_ROUND_UP() because of this ppmax value can be
greater than available per cpu page pods.
This patch removes BITS_TO_LONGS() to fix this issue.
Signed-off-by: Varun Prakash <varun@chelsio.com> Signed-off-by: David S.
Miller <davem@davemloft.net>

net: bridge: always clear mcast matching struct on reports and leaves
We need to be careful and always zero the whole br_ip struct when it is 
used for matching since the rhashtable change. This patch fixes all the 
places which didn't properly clear it which in turn might've caused 
mismatches.
Thanks for the great bug report with reproducing steps and bisection.
Steps to reproduce (from the bug report): ip link add br0 type bridge
mcast_querier 1 ip link set br0 up
ip link add v2 type veth peer name v3 ip link set v2 master br0 ip link
set v2 up ip link set v3 up ip addr add 3.0.0.2/24 dev v3
ip netns add test ip link add v1 type veth peer name v1 netns test ip
link set v1 master br0 ip link set v1 up ip -n test link set v1 up ip -n
test addr add 3.0.0.1/24 dev v1
# Multicast receiver ip netns exec test socat 
UDP4-RECVFROM:5588,ip-add-membership=224.224.224.224:3.0.0.1,fork -
# Multicast sender echo hello | nc -u -s 3.0.0.2 224.224.224.224 5588
Reported-by: liam.mcbirnie@boeing.com Fixes: 19e3a9c90c53 ("net: bridge:
convert multicast to generic rhashtable") Signed-off-by: Nikolay
Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

extcon: ptn5150: fix COMPILE_TEST dependencies
The PTN5150 dependencies look like they were meant to do the right
thing, but they actually should not allow building without I2C for
compile testing, as that results in a Kconfig warning and subsequent
build failure:
WARNING: unmet direct dependencies detected for REGMAP_I2C
 Depends on [m]: I2C [=m]
 Selected by [y]:
 - EXTCON_PTN5150 [=y] && EXTCON [=y] && (I2C [=m] && GPIOLIB [=y] ||
COMPILE_TEST [=y])
 Selected by [m]:
 - EEPROM_AT24 [=m] && I2C [=m] && SYSFS [=y]
 - KEYBOARD_CAP11XX [=m] && !UML && INPUT [=y] && INPUT_KEYBOARD [=y] &&
OF [=y] && I2C [=m]
 - INPUT_DRV260X_HAPTICS [=m] && !UML && INPUT_MISC [=y] && INPUT [=y]
&& I2C [=m] && (GPIOLIB [=y] || COMPILE_TEST [=y])
 - ... [many others]
Add parentheses around the expression so we can compile-test without
GPIOLIB but not without I2C.
Fixes: 4ed754de2d66 ("extcon: Add support for ptn5150 extcon driver") 
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Chanwoo Choi
<cw00.choi@samsung.com>

ipv6: sit: reset ip header pointer in ipip6_rcv
ipip6 tunnels run iptunnel_pull_header on received skbs. This can 
determine the following use-after-free accessing iph pointer since the
packet will be 'uncloned' running pskb_expand_head if it is a cloned gso
skb (e.g if the packet has been sent though a veth device)
[  706.369655] BUG: KASAN: use-after-free in ipip6_rcv+0x1678/0x16e0
[sit]
[  706.449056] Read of size 1 at addr ffffe01b6bd855f5 by task
ksoftirqd/1/=
[  706.669494] Hardware name: HPE ProLiant m400 Server/ProLiant m400
Server, BIOS U02 08/19/2016
[  706.771839] Call trace:
[  706.801159]  dump_backtrace+0x0/0x2f8
[  706.845079]  show_stack+0x24/0x30
[  706.884833]  dump_stack+0xe0/0x11c
[  706.925629]  print_address_description+0x68/0x260
[  706.982070]  kasan_report+0x178/0x340
[  707.025995]  __asan_report_load1_noabort+0x30/0x40
[  707.083481]  ipip6_rcv+0x1678/0x16e0 [sit]
[  707.132623]  tunnel64_rcv+0xd4/0x200 [tunnel4]
[  707.185940]  ip_local_deliver_finish+0x3b8/0x988
[  707.241338]  ip_local_deliver+0x144/0x470
[  707.289436]  ip_rcv_finish+0x43c/0x14b0
[  707.335447]  ip_rcv+0x628/0x1138
[  707.374151]  __netif_receive_skb_core+0x1670/0x2600
[  707.432680]  __netif_receive_skb+0x28/0x190
[  707.482859]  process_backlog+0x1d0/0x610
[  707.529913]  net_rx_action+0x37c/0xf68
[  707.574882]  __do_softirq+0x288/0x1018
[  707.619852]  run_ksoftirqd+0x70/0xa8
[  707.662734]  smpboot_thread_fn+0x3a4/0x9e8
[  707.711875]  kthread+0x2c8/0x350
[  707.750583]  ret_from_fork+0x10/0x18
[  707.811302] Allocated by task 16982:
[  707.854182]  kasan_kmalloc.part.1+0x40/0x108
[  707.905405]  kasan_kmalloc+0xb4/0xc8
[  707.948291]  kasan_slab_alloc+0x14/0x20
[  707.994309]  __kmalloc_node_track_caller+0x158/0x5e0
[  708.053902]  __kmalloc_reserve.isra.8+0x54/0xe0
[  708.108280]  __alloc_skb+0xd8/0x400
[  708.150139]  sk_stream_alloc_skb+0xa4/0x638
[  708.200346]  tcp_sendmsg_locked+0x818/0x2b90
[  708.251581]  tcp_sendmsg+0x40/0x60
[  708.292376]  inet_sendmsg+0xf0/0x520
[  708.335259]  sock_sendmsg+0xac/0xf8
[  708.377096]  sock_write_iter+0x1c0/0x2c0
[  708.424154]  new_sync_write+0x358/0x4a8
[  708.470162]  __vfs_write+0xc4/0xf8
[  708.510950]  vfs_write+0x12c/0x3d0
[  708.551739]  ksys_write+0xcc/0x178
[  708.592533]  __arm64_sys_write+0x70/0xa0
[  708.639593]  el0_svc_handler+0x13c/0x298
[  708.686646]  el0_svc+0x8/0xc
[  708.739019] Freed by task 17:
[  708.774597]  __kasan_slab_free+0x114/0x228
[  708.823736]  kasan_slab_free+0x10/0x18
[  708.868703]  kfree+0x100/0x3d8
[  708.905320]  skb_free_head+0x7c/0x98
[  708.948204]  skb_release_data+0x320/0x490
[  708.996301]  pskb_expand_head+0x60c/0x970
[  709.044399]  __iptunnel_pull_header+0x3b8/0x5d0
[  709.098770]  ipip6_rcv+0x41c/0x16e0 [sit]
[  709.146873]  tunnel64_rcv+0xd4/0x200 [tunnel4]
[  709.200195]  ip_local_deliver_finish+0x3b8/0x988
[  709.255596]  ip_local_deliver+0x144/0x470
[  709.303692]  ip_rcv_finish+0x43c/0x14b0
[  709.349705]  ip_rcv+0x628/0x1138
[  709.388413]  __netif_receive_skb_core+0x1670/0x2600
[  709.446943]  __netif_receive_skb+0x28/0x190
[  709.497120]  process_backlog+0x1d0/0x610
[  709.544169]  net_rx_action+0x37c/0xf68
[  709.589131]  __do_softirq+0x288/0x1018
[  709.651938] The buggy address belongs to the object at
ffffe01b6bd85580
               which belongs to the cache kmalloc-1024 of size 1024
[  709.804356] The buggy address is located 117 bytes inside of
               1024-byte region [ffffe01b6bd85580, ffffe01b6bd85980)
[  709.946340] The buggy address belongs to the page:
[  710.003824] page:ffff7ff806daf600 count:1 mapcount:0
mapping:ffffe01c4001f600 index:0x0
[  710.099914] flags: 0xfffff8000000100(slab)
[  710.149059] raw: 0fffff8000000100 dead000000000100 dead000000000200
ffffe01c4001f600
[  710.242011] raw: 0000000000000000 0000000000380038 00000001ffffffff
0000000000000000
[  710.334966] page dumped because: kasan: bad access detected
Fix it resetting iph pointer after iptunnel_pull_header
Fixes: a09a4c8dd1ec ("tunnels: Remove encapsulation offloads on decap") 
Tested-by: Jianlin Shi <jishi@redhat.com> Signed-off-by: Lorenzo
Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

ibmvnic: Fix completion structure initialization
Fix device initialization completion handling for vNIC adapters. 
Initialize the completion structure on probe and reinitialize when
needed. This also fixes a race condition during kdump where the driver
can attempt to access the completion struct before it is initialized:
Unable to handle kernel paging request for data at address 0x00000000 
Faulting instruction address: 0xc0000000081acbe0 Oops: Kernel access of
bad area, sig: 11 [#1] LE SMP NR_CPUS=2048 NUMA pSeries Modules linked
in: ibmvnic(+) ibmveth sunrpc overlay squashfs loop CPU: 19 PID: 301
Comm: systemd-udevd Not tainted 4.18.0-64.el8.ppc64le #1 NIP: 
c0000000081acbe0 LR: c0000000081ad964 CTR: c0000000081ad900 REGS:
c000000027f3f990 TRAP: 0300   Not tainted  (4.18.0-64.el8.ppc64le) MSR: 
800000010280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 28228288 
XER: 00000006 CFAR: c000000008008934 DAR: 0000000000000000 DSISR:
40000000 IRQMASK: 1 GPR00: c0000000081ad964 c000000027f3fc10
c0000000095b5800 c0000000221b4e58 GPR04: 0000000000000003
0000000000000001 000049a086918581 00000000000000d4 GPR08:
0000000000000007 0000000000000000 ffffffffffffffe8 d0000000014dde28 
GPR12: c0000000081ad900 c000000009a00c00 0000000000000001
0000000000000100 GPR16: 0000000000000038 0000000000000007
c0000000095e2230 0000000000000006 GPR20: 0000000000400140
0000000000000001 c00000000910c880 0000000000000000 GPR24:
0000000000000000 0000000000000006 0000000000000000 0000000000000003 
GPR28: 0000000000000001 0000000000000001 c0000000221b4e60
c0000000221b4e58 NIP [c0000000081acbe0] __wake_up_locked+0x50/0x100 LR
[c0000000081ad964] complete+0x64/0xa0 Call Trace:
[c000000027f3fc10] [c000000027f3fc60] 0xc000000027f3fc60 (unreliable)
[c000000027f3fc60] [c0000000081ad964] complete+0x64/0xa0
[c000000027f3fca0] [d0000000014dad58] ibmvnic_handle_crq+0xce0/0x1160
[ibmvnic]
[c000000027f3fd50] [d0000000014db270] ibmvnic_tasklet+0x98/0x130
[ibmvnic]
[c000000027f3fda0] [c00000000813f334]
tasklet_action_common.isra.3+0xc4/0x1a0
[c000000027f3fe00] [c000000008cd13f4] __do_softirq+0x164/0x400
[c000000027f3fef0] [c00000000813ed64] irq_exit+0x184/0x1c0
[c000000027f3ff20] [c0000000080188e8] __do_irq+0xb8/0x210
[c000000027f3ff90] [c00000000802d0a4] call_do_irq+0x14/0x24
[c000000026a5b010] [c000000008018adc] do_IRQ+0x9c/0x130
[c000000026a5b060] [c000000008008ce4]
hardware_interrupt_common+0x114/0x120
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net>

xtensa: fix format string warning in init_pmd
Use %lu instead of %zu to fix the following warning introduced with 
recent memblock refactoring:
 xtensa/mm/mmu.c:36:9: warning: format '%zu' expects argument of type
 'size_t', but argument 3 has type 'long unsigned int
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>

ASoC: cs35l35: Disable regulators on driver removal
The chips main power supplies VA and VP are enabled during probe but 
then never disabled, this will cause warnings from the regulator 
framework on driver removal. Fix this by adding a remove callback and 
disabling the supplies, whilst doing so follow best practice and put the 
chip back into reset as well.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> 
Signed-off-by: Mark Brown <broonie@kernel.org>

ASoC: intel: skylake: add remove() callback for component driver
Topology is not unloaded in the core during unregister_component() 
anymore. So, add the remove() callback that will unload the topology.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> 
Signed-off-by: Mark Brown <broonie@kernel.org>

KVM: PPC: Book3S HV: Perserve PSSCR FAKE_SUSPEND bit on guest exit
There is a hardware bug in some POWER9 processors where a treclaim in 
fake suspend mode can cause an inconsistency in the XER[SO] bit across 
the threads of a core, the workaround being to force the core into SMT4 
when doing the treclaim.
The FAKE_SUSPEND bit (bit 10) in the PSSCR is used to control whether a 
thread is in fake suspend or real suspend. The important difference here 
being that thread reconfiguration is blocked in real suspend but not 
fake suspend mode.
When we exit a guest which was in fake suspend mode, we force the core 
into SMT4 while we do the treclaim in kvmppc_save_tm_hv(). However on
the new exit path introduced with the function kvmhv_run_single_vcpu()
we restore the host PSSCR before calling kvmppc_save_tm_hv() which means
that if we were in fake suspend mode we put the thread into real suspend
mode when we clear the PSSCR[FAKE_SUSPEND] bit. This means that we block
thread reconfiguration and the thread which is trying to get the core
into SMT4 before it can do the treclaim spins forever since it itself is
blocking thread reconfiguration. The result is that that core is
essentially lost.
This results in a trace such as:
[   93.512904] CPU: 7 PID: 13352 Comm: qemu-system-ppc Not tainted 5.0.0
#4
[   93.512905] NIP:  c000000000098a04 LR: c0000000000cc59c CTR:
0000000000000000
[   93.512908] REGS: c000003fffd2bd70 TRAP: 0100   Not tainted  (5.0.0)
[   93.512908] MSR:  9000000302883033
<SF,HV,VEC,VSX,FP,ME,IR,DR,RI,LE,TM[SE]>  CR: 22222444  XER: 00000000
[   93.512914] CFAR: c000000000098a5c IRQMASK: 3
[   93.512915] PACATMSCRATCH: 0000000000000001
[   93.512916] GPR00: 0000000000000001 c000003f6cc1b830 c000000001033100
0000000000000004
[   93.512928] GPR04: 0000000000000004 0000000000000002 0000000000000004
0000000000000007
[   93.512930] GPR08: 0000000000000000 0000000000000004 0000000000000000
0000000000000004
[   93.512932] GPR12: c000203fff7fc000 c000003fffff9500 0000000000000000
0000000000000000
[   93.512935] GPR16: 2000000000300375 000000000000059f 0000000000000000
0000000000000000
[   93.512951] GPR20: 0000000000000000 0000000000080053 004000000256f41f
c000003f6aa88ef0
[   93.512953] GPR24: c000003f6aa89100 0000000000000010 0000000000000000
0000000000000000
[   93.512956] GPR28: c000003f9e9a0800 0000000000000000 0000000000000001
c000203fff7fc000
[   93.512959] NIP [c000000000098a04]
pnv_power9_force_smt4_catch+0x1b4/0x2c0
[   93.512960] LR [c0000000000cc59c] kvmppc_save_tm_hv+0x40/0x88
[   93.512960] Call Trace:
[   93.512961] [c000003f6cc1b830] [0000000000080053] 0x80053
(unreliable)
[   93.512965] [c000003f6cc1b8a0] [c00800001e9cb030]
kvmhv_p9_guest_entry+0x508/0x6b0 [kvm_hv]
[   93.512967] [c000003f6cc1b940] [c00800001e9cba44]
kvmhv_run_single_vcpu+0x2dc/0xb90 [kvm_hv]
[   93.512968] [c000003f6cc1ba10] [c00800001e9cc948]
kvmppc_vcpu_run_hv+0x650/0xb90 [kvm_hv]
[   93.512969] [c000003f6cc1bae0] [c00800001e8f620c]
kvmppc_vcpu_run+0x34/0x48 [kvm]
[   93.512971] [c000003f6cc1bb00] [c00800001e8f2d4c]
kvm_arch_vcpu_ioctl_run+0x2f4/0x400 [kvm]
[   93.512972] [c000003f6cc1bb90] [c00800001e8e3918]
kvm_vcpu_ioctl+0x460/0x7d0 [kvm]
[   93.512974] [c000003f6cc1bd00] [c0000000003ae2c0]
do_vfs_ioctl+0xe0/0x8e0
[   93.512975] [c000003f6cc1bdb0] [c0000000003aeb24]
ksys_ioctl+0x64/0xe0
[   93.512978] [c000003f6cc1be00] [c0000000003aebc8] sys_ioctl+0x28/0x80
[   93.512981] [c000003f6cc1be20] [c00000000000b3a4]
system_call+0x5c/0x70
[   93.512983] Instruction dump:
[   93.512986] 419dffbc e98c0000 2e8b0000 38000001 60000000 60000000
60000000 40950068
[   93.512993] 392bffff 39400000 79290020 39290001 <7d2903a6> 60000000
60000000 7d235214
To fix this we preserve the PSSCR[FAKE_SUSPEND] bit until we call 
kvmppc_save_tm_hv() which will mean the core can get into SMT4 and 
perform the treclaim. Note kvmppc_save_tm_hv() clears the 
PSSCR[FAKE_SUSPEND] bit again so there is no need to explicitly do that.
Fixes: 95a6432ce9038 ("KVM: PPC: Book3S HV: Streamlined guest entry/exit
path on P9 for radix guests")
Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> 
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>

KVM: PPC: Book3S: Protect memslots while validating user address
Guest physical to user address translation uses KVM memslots and reading 
these requires holding the kvm->srcu lock. However recently introduced 
kvmppc_tce_validate() broke the rule (see the lockdep warning below).
This moves srcu_read_lock(&vcpu->kvm->srcu) earlier to protect 
kvmppc_tce_validate() as well.
============================= WARNING: suspicious RCU usage 
5.1.0-rc2-le_nv2_aikATfstn1-p1 #380 Not tainted
----------------------------- include/linux/kvm_host.h:605 suspicious
rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1 1 lock held by
qemu-system-ppc/8020:
#0: 0000000094972fe9 (&vcpu->mutex){+.+.}, at: kvm_vcpu_ioctl+0xdc/0x850
[kvm]
stack backtrace: CPU: 44 PID: 8020 Comm: qemu-system-ppc Not tainted
5.1.0-rc2-le_nv2_aikATfstn1-p1 #380 Call Trace:
[c000003fece8f740] [c000000000bcc134] dump_stack+0xe8/0x164 (unreliable)
[c000003fece8f790] [c000000000181be0] lockdep_rcu_suspicious+0x130/0x170
[c000003fece8f810] [c0000000000d5f50] kvmppc_tce_to_ua+0x280/0x290
[c000003fece8f870] [c00800001a7e2c78] kvmppc_tce_validate+0x80/0x1b0
[kvm]
[c000003fece8f8e0] [c00800001a7e3fac] kvmppc_h_put_tce+0x94/0x3e4 [kvm]
[c000003fece8f9a0] [c00800001a8baac4]
kvmppc_pseries_do_hcall+0x30c/0xce0 [kvm_hv]
[c000003fece8fa10] [c00800001a8bd89c] kvmppc_vcpu_run_hv+0x694/0xec0
[kvm_hv]
[c000003fece8fae0] [c00800001a7d95dc] kvmppc_vcpu_run+0x34/0x48 [kvm]
[c000003fece8fb00] [c00800001a7d56bc]
kvm_arch_vcpu_ioctl_run+0x2f4/0x400 [kvm]
[c000003fece8fb90] [c00800001a7c3618] kvm_vcpu_ioctl+0x460/0x850 [kvm]
[c000003fece8fd00] [c00000000041c4f4] do_vfs_ioctl+0xe4/0x930
[c000003fece8fdb0] [c00000000041ce04] ksys_ioctl+0xc4/0x110
[c000003fece8fe00] [c00000000041ce78] sys_ioctl+0x28/0x80
[c000003fece8fe20] [c00000000000b5a4] system_call+0x5c/0x70
Fixes: 42de7b9e2167 ("KVM: PPC: Validate TCEs against preregistered
memory page sizes", 2018-09-10) Signed-off-by: Alexey Kardashevskiy
<aik@ozlabs.ru> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>

xen: use struct_size() helper in kzalloc()
struct privcmd_buf_vma_private has a zero-sized array at the end
(pages), use the new struct_size() helper to determine the proper 
allocation size and avoid potential type mistakes.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Reviewed-by:
Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross
<jgross@suse.com>

xen: Prevent buffer overflow in privcmd ioctl
The "call" variable comes from the user in privcmd_ioctl_hypercall(). 
It's an offset into the hypercall_page[] which has (PAGE_SIZE / 32) 
elements.  We need to put an upper bound on it to prevent an out of 
bounds access.
Cc: stable@vger.kernel.org Fixes: 1246ae0bb992 ("xen: add variable
hypercall caller") Signed-off-by: Dan Carpenter
<dan.carpenter@oracle.com> Reviewed-by: Boris Ostrovsky
<boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross
<jgross@suse.com>

Revert "Documentation/gpu/meson: Remove link to meson_canvas.c"
This reverts commit a3f98bb22cbfaaf67717e156f79e2bfeb42d4cac.
Patch "Documentation/gpu/meson: Remove link to meson_canvas.c" was 
incorrectly applied on the wrong branch not containing the fixed commit
2bf6b5b0e374 ("drm/meson: exclusively use the canvas provider module")
Acked-by: Sean Paul <sean@poorly.run> Signed-off-by: Neil Armstrong
<narmstrong@baylibre.com> Signed-off-by: Maxime Ripard
<maxime.ripard@bootlin.com> Link:
https://patchwork.freedesktop.org/patch/msgid/20190404144342.15238-1-narmstrong@baylibre.com

drm/sun4i: DW HDMI: Lower max. supported rate for H6
Currently resolutions with pixel clock higher than 340 MHz don't work 
with H6 HDMI controller. They just produce a blank screen.
Limit maximum pixel clock rate to 340 MHz until scrambling is supported.
Cc: stable@vger.kernel.org # 5.0 Fixes: 40bb9d3147b2 ("drm/sun4i: Add
support for H6 DW HDMI controller") Signed-off-by: Jernej Skrabec
<jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard
<maxime.ripard@bootlin.com> Link:
https://patchwork.freedesktop.org/patch/msgid/20190324190609.32721-1-jernej.skrabec@siol.net

objtool: Add rewind_stack_do_exit() to the noreturn list
This fixes the following warning seen on GCC 7.3:
  arch/x86/kernel/dumpstack.o: warning: objtool: oops_end() falls
through to next function show_regs()
Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Josh
Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Thomas Gleixner
<tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Link:
https://lkml.kernel.org/r/3418ebf5a5a9f6ed7e80954c741c0b904b67b5dc.1554398240.git.jpoimboe@redhat.com

ALSA: seq: Fix OOB-reads from strlcpy
When ioctl calls are made with non-null-terminated userspace strings, 
strlcpy causes an OOB-read from within strlen. Fix by changing to use 
strscpy instead.
Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-by: Guenter
Roeck <groeck@chromium.org> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de>

irqchip/irq-ls1x: Missing error code in ls1x_intc_of_init()
Currently, when irq_domain_add_linear() fails, the error code does not
get set so it returns zero which is wrong.  Fix it by setting the
appropriate error code.
Fixes: 9e543e22e204 ("irqchip: Add driver for Loongson-1 interrupt
controller") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> 
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Mukesh
Ojha <mojha@codeaurora.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc:
Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: Jason Cooper
<jason@lakedaemon.net> Cc: kernel-janitors@vger.kernel.org Link:
https://lkml.kernel.org/r/20190329062136.GQ32613@kadam

genirq: Initialize request_mutex if CONFIG_SPARSE_IRQ=n
When CONFIG_SPARSE_IRQ is disable, the request_mutex in struct irq_desc 
is not initialized which causes malfunction.
Fixes: 9114014cf4e6 ("genirq: Add mutex to irq desc to serialize
request/free_irq()") Signed-off-by: Kefeng Wang
<wangkefeng.wang@huawei.com> Signed-off-by: Thomas Gleixner
<tglx@linutronix.de> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Cc:
Marc Zyngier <marc.zyngier@arm.com> Cc:
<linux-arm-kernel@lists.infradead.org> Cc: stable@vger.kernel.org Link:
https://lkml.kernel.org/r/20190404074512.145533-1-wangkefeng.wang@huawei.com

syscalls: Remove start and number from syscall_get_arguments() args
At Linux Plumbers, Andy Lutomirski approached me and pointed out that
the function call syscall_get_arguments() implemented in x86 was
horribly written and not optimized for the standard case of passing in 0
and 6 for the starting index and the number of system calls to get. When
looking at all the users of this function, I discovered that all
instances pass in only 0 and 6 for these arguments. Instead of having
this function handle different cases that are never used, simply rewrite
it to return the first 6 arguments of a system call.
This should help out the performance of tracing system calls by ptrace, 
ftrace and perf.
Link: http://lkml.kernel.org/r/20161107213233.754809394@goodmis.org
Cc: Oleg Nesterov <oleg@redhat.com> Cc: Kees Cook
<keescook@chromium.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc:
Dominik Brodowski <linux@dominikbrodowski.net> Cc: Dave Martin
<dave.martin@arm.com> Cc: "Dmitry V. Levin" <ldv@altlinux.org> Cc:
x86@kernel.org Cc: linux-snps-arc@lists.infradead.org Cc:
linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org 
Cc: linux-c6x-dev@linux-c6x.org Cc:
uclinux-h8-devel@lists.sourceforge.jp Cc: linux-hexagon@vger.kernel.org 
Cc: linux-ia64@vger.kernel.org Cc: linux-mips@vger.kernel.org Cc:
nios2-dev@lists.rocketboards.org Cc: openrisc@lists.librecores.org Cc:
linux-parisc@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc:
linux-riscv@lists.infradead.org Cc: linux-s390@vger.kernel.org Cc:
linux-sh@vger.kernel.org Cc: sparclinux@vger.kernel.org Cc:
linux-um@lists.infradead.org Cc: linux-xtensa@linux-xtensa.org Cc:
linux-arch@vger.kernel.org Acked-by: Paul Burton <paul.burton@mips.com>
# MIPS parts Acked-by: Max Filippov <jcmvbkbc@gmail.com> # For xtensa
changes Acked-by: Will Deacon <will.deacon@arm.com> # For the arm64 bits 
Reviewed-by: Thomas Gleixner <tglx@linutronix.de> # for x86 Reviewed-by:
Dmitry V. Levin <ldv@altlinux.org> Reported-by: Andy Lutomirski
<luto@amacapital.net> Signed-off-by: Steven Rostedt (VMware)
<rostedt@goodmis.org>

syscalls: Remove start and number from syscall_set_arguments() args
After removing the start and count arguments of syscall_get_arguments()
it seems reasonable to remove them from syscall_set_arguments(). Note,
as of today, there are no users of syscall_set_arguments(). But we are
told that there will be soon. But for now, at least make it consistent
with syscall_get_arguments().
Link: http://lkml.kernel.org/r/20190327222014.GA32540@altlinux.org
Cc: Oleg Nesterov <oleg@redhat.com> Cc: Kees Cook
<keescook@chromium.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc:
Dominik Brodowski <linux@dominikbrodowski.net> Cc: Dave Martin
<dave.martin@arm.com> Cc: "Dmitry V. Levin" <ldv@altlinux.org> Cc:
x86@kernel.org Cc: linux-snps-arc@lists.infradead.org Cc:
linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org 
Cc: linux-c6x-dev@linux-c6x.org Cc:
uclinux-h8-devel@lists.sourceforge.jp Cc: linux-hexagon@vger.kernel.org 
Cc: linux-ia64@vger.kernel.org Cc: linux-mips@vger.kernel.org Cc:
nios2-dev@lists.rocketboards.org Cc: openrisc@lists.librecores.org Cc:
linux-parisc@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc:
linux-riscv@lists.infradead.org Cc: linux-s390@vger.kernel.org Cc:
linux-sh@vger.kernel.org Cc: sparclinux@vger.kernel.org Cc:
linux-um@lists.infradead.org Cc: linux-xtensa@linux-xtensa.org Cc:
linux-arch@vger.kernel.org Acked-by: Max Filippov <jcmvbkbc@gmail.com> #
For xtensa changes Acked-by: Will Deacon <will.deacon@arm.com> # For the
arm64 bits Reviewed-by: Thomas Gleixner <tglx@linutronix.de> # for x86 
Reviewed-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Steven
Rostedt (VMware) <rostedt@goodmis.org>

paride/pcd: Fix potential NULL pointer dereference and mem leak
Syzkaller report this:
pcd: pcd version 1.07, major 46, nice 0 pcd0: Autoprobe failed pcd: No
CD-ROM drive found kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could
be caused by NULL-ptr deref or user memory access general protection
fault: 0000 [#1] SMP KASAN PTI CPU: 1 PID: 4525 Comm: syz-executor.0 Not
tainted 5.1.0-rc3+ #8 Hardware name: QEMU Standard PC (i440FX + PIIX,
1996), BIOS 1.10.2-1ubuntu1 04/01/2014 RIP: 0010:pcd_init+0x95c/0x1000
[pcd] Code: c4 ab f7 48 89 d8 48 c1 e8 03 80 3c 28 00 74 08 48 89 df e8
56 a3 da f7 4c 8b 23 49 8d bc 24 80 05 00 00 48 89 f8 48 c1 e8 03 <80>
3c 28 00 74 05 e8 39 a3 da f7 49 8b bc 24 80 05 00 00 e8 cc b2 RSP:
0018:ffff8881e84df880 EFLAGS: 00010202 RAX: 00000000000000b0 RBX:
ffffffffc155a088 RCX: ffffffffc1508935 RDX: 0000000000040000 RSI:
ffffc900014f0000 RDI: 0000000000000580 RBP: dffffc0000000000 R08:
ffffed103ee658b8 R09: ffffed103ee658b8 R10: 0000000000000001 R11:
ffffed103ee658b7 R12: 0000000000000000 R13: ffffffffc155a778 R14:
ffffffffc155a4a8 R15: 0000000000000003 FS:  00007fe71bee3700(0000)
GS:ffff8881f7300000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES:
0000 CR0: 0000000080050033 CR2: 000055a7334441a8 CR3: 00000001e9674003
CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400 PKRU: 55555554 Call Trace:
? 0xffffffffc1508000
? 0xffffffffc1508000
do_one_initcall+0xbc/0x47d init/main.c:901
do_init_module+0x1b5/0x547 kernel/module.c:3456
load_module+0x6405/0x8c10 kernel/module.c:3804
__do_sys_finit_module+0x162/0x190 kernel/module.c:3898
do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x462e99 Code: f7 d8
64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6
48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73
01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fe71bee2c58
EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX:
000000000073bf00 RCX: 0000000000462e99 RDX: 0000000000000000 RSI:
0000000020000180 RDI: 0000000000000003 RBP: 00007fe71bee2c70 R08:
0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
0000000000000246 R12: 00007fe71bee36bc R13: 00000000004bcefa R14:
00000000006f6fb0 R15: 0000000000000004 Modules linked in: pcd(+) paride
solos_pci atm ts_fsm rtc_mt6397 mac80211 nhc_mobility nhc_udp nhc_ipv6
nhc_hop nhc_dest nhc_fragment nhc_routing 6lowpan rtc_cros_ec memconsole
intel_xhci_usb_role_switch roles rtc_wm8350 usbcore
industrialio_triggered_buffer kfifo_buf industrialio asc7621 dm_era
dm_persistent_data dm_bufio dm_mod tpm gnss_ubx gnss_serial serdev gnss
max2165 cpufreq_dt hid_penmount hid menf21bmc_wdt rc_core n_tracesink
ide_gd_mod cdns_csi2tx v4l2_fwnode videodev media pinctrl_lewisburg
pinctrl_intel iptable_security iptable_raw iptable_mangle iptable_nat
nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter
bpfilter ip6_vti ip_vti ip_gre ipip sit tunnel4 ip_tunnel hsr veth
netdevsim vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon dummy
team bonding vcan bridge stp llc ip6_gre gre ip6_tunnel tunnel6 tun
joydev mousedev ppdev kvm_intel kvm irqbypass crct10dif_pclmul
crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64
crypto_simd
ide_pci_generic piix input_leds cryptd glue_helper psmouse ide_core
intel_agp serio_raw intel_gtt ata_generic i2c_piix4 agpgart pata_acpi
parport_pc parport floppy rtc_cmos sch_fq_codel ip_tables x_tables
sha1_ssse3 sha1_generic ipv6 [last unloaded: bmc150_magn] Dumping ftrace
buffer:
  (ftrace buffer empty)
---[ end trace d873691c3cd69f56 ]---
If alloc_disk fails in pcd_init_units, cd->disk will be NULL, however in
pcd_detect and pcd_exit, it's not check this before free.It may result a
NULL pointer dereference.
Also when register_blkdev failed, blk_cleanup_queue() and 
blk_mq_free_tag_set() should be called to free resources.
Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 81b74ac68c28
("paride/pcd: cleanup queues when detection fails") Signed-off-by:
YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

block: Revert v5.0 blk_mq_request_issue_directly() changes
blk_mq_try_issue_directly() can return BLK_STS*_RESOURCE for requests
that have been queued. If that happens when blk_mq_try_issue_directly()
is called by the dm-mpath driver then dm-mpath will try to resubmit a
request that is already queued and a kernel crash follows. Since it is
nontrivial to fix blk_mq_request_issue_directly(), revert the
blk_mq_request_issue_directly() changes that went into kernel v5.0.
This patch reverts the following commits:
* d6a51a97c0b2 ("blk-mq: replace and kill
blk_mq_request_issue_directly") # v5.0.
* 5b7a6f128aad ("blk-mq: issue directly with bypass 'false' in
blk_mq_sched_insert_requests") # v5.0.
* 7f556a44e61d ("blk-mq: refactor the code of issue request directly") #
v5.0.
Cc: Christoph Hellwig <hch@infradead.org> Cc: Ming Lei
<ming.lei@redhat.com> Cc: Jianchao Wang <jianchao.w.wang@oracle.com> Cc:
Hannes Reinecke <hare@suse.com> Cc: Johannes Thumshirn
<jthumshirn@suse.de> Cc: James Smart <james.smart@broadcom.com> Cc:
Dongli Zhang <dongli.zhang@oracle.com> Cc: Laurence Oberman
<loberman@redhat.com> Cc: <stable@vger.kernel.org> Reported-by: Laurence
Oberman <loberman@redhat.com> Tested-by: Laurence Oberman
<loberman@redhat.com> Fixes: 7f556a44e61d ("blk-mq: refactor the code of
issue request directly") # v5.0. Signed-off-by: Bart Van Assche
<bvanassche@acm.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>

genirq: Respect IRQCHIP_SKIP_SET_WAKE in irq_chip_set_wake_parent()
If a child irqchip calls irq_chip_set_wake_parent() but its parent
irqchip has the IRQCHIP_SKIP_SET_WAKE flag set an error is returned.
This is inconsistent behaviour vs. set_irq_wake_real() which returns 0
when the irqchip has the IRQCHIP_SKIP_SET_WAKE flag set. It doesn't
attempt to walk the chain of parents and set irq wake on any chips that
don't have the flag set either. If the intent is to call the
.irq_set_wake() callback of the parent irqchip, then we expect irqchip
implementations to omit the IRQCHIP_SKIP_SET_WAKE flag and implement an
.irq_set_wake() function that calls irq_chip_set_wake_parent().
The problem has been observed on a Qualcomm sdm845 device where set wake 
fails on any GPIO interrupts after applying work in progress wakeup irq 
patches to the GPIO driver. The chain of chips looks like this:
     QCOM GPIO -> QCOM PDC (SKIP) -> ARM GIC (SKIP)
The GPIO controllers parent is the QCOM PDC irqchip which in turn has
ARM GIC as parent.  The QCOM PDC irqchip has the IRQCHIP_SKIP_SET_WAKE
flag set, and so does the grandparent ARM GIC.
The GPIO driver doesn't know if the parent needs to set wake or not, so
it unconditionally calls irq_chip_set_wake_parent() causing this
function to return a failure because the parent irqchip (PDC) doesn't
have the
.irq_set_wake() callback set. Returning 0 instead makes everything work
and irqs from the GPIO controller can be configured for wakeup.
Make it consistent by returning 0 (success) from
irq_chip_set_wake_parent() when a parent chip has IRQCHIP_SKIP_SET_WAKE
set.
[ tglx: Massaged changelog ]
Fixes: 08b55e2a9208e ("genirq: Add irqchip_set_wake_parent") 
Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Thomas
Gleixner <tglx@linutronix.de> Acked-by: Marc Zyngier
<marc.zyngier@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc:
linux-gpio@vger.kernel.org Cc: Lina Iyer <ilina@codeaurora.org> Cc:
stable@vger.kernel.org Link:
https://lkml.kernel.org/r/20190325181026.247796-1-swboyd@chromium.org

tty: mark Siemens R3964 line discipline as BROKEN
The n_r3964 line discipline driver was written in a different time, when 
SMP machines were rare, and users were trusted to do the right thing. 
Since then, the world has moved on but not this code, it has stayed 
rooted in the past with its lovely hand-crafted list structures and 
loads of "interesting" race conditions all over the place.
After attempting to clean up most of the issues, I just gave up and am 
now marking the driver as BROKEN so that hopefully someone who has this 
hardware will show up out of the woodwork (I know you are out there!) 
and will help with debugging a raft of changes that I had laying around 
for the code, but was too afraid to commit as odds are they would break 
things.
Many thanks to Jann and Linus for pointing out the initial problems in 
this codebase, as well as many reviews of my attempts to fix the issues. 
It was a case of whack-a-mole, and as you can see, the mole won.
Reported-by: Jann Horn <jannh@google.com> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

kvm: svm: fix potential get_num_contig_pages overflow
get_num_contig_pages() could potentially overflow int so make its type 
consistent with its usage.
Reported-by: Cfir Cohen <cfir@google.com> Cc: stable@vger.kernel.org 
Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Paolo
Bonzini <pbonzini@redhat.com>

KVM: SVM: prevent DBG_DECRYPT and DBG_ENCRYPT overflow
This ensures that the address and length provided to DBG_DECRYPT and 
DBG_ENCRYPT do not cause an overflow.
At the same time, pass the actual number of pages pinned in memory to 
sev_unpin_memory() as a cleanup.
Reported-by: Cfir Cohen <cfir@google.com> Signed-off-by: David Rientjes
<rientjes@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

KVM: x86: nVMX: close leak of L0's x2APIC MSRs (CVE-2019-3887)
The nested_vmx_prepare_msr_bitmap() function doesn't directly guard the 
x2APIC MSR intercepts with the "virtualize x2APIC mode" MSR. As a 
result, we discovered the potential for a buggy or malicious L1 to get 
access to L0's x2APIC MSRs, via an L2, as follows.
1. L1 executes WRMSR(IA32_SPEC_CTRL, 1). This causes the spec_ctrl 
variable, in nested_vmx_prepare_msr_bitmap() to become true. 2. L1
disables "virtualize x2APIC mode" in VMCS12. 3. L1 enables
"APIC-register virtualization" in VMCS12.
Now, KVM will set VMCS02's x2APIC MSR intercepts from VMCS12, and then 
set "virtualize x2APIC mode" to 0 in VMCS02. Oops.
This patch closes the leak by explicitly guarding VMCS02's x2APIC MSR 
intercepts with VMCS12's "virtualize x2APIC mode" control.
The scenario outlined above and fix prescribed here, were verified with 
a related patch in kvm-unit-tests titled "Add leak scenario to 
virt_x2apic_mode_test".
Note, it looks like this issue may have been introduced inadvertently 
during a merge---see 15303ba5d1cd.
Signed-off-by: Marc Orr <marcorr@google.com> Reviewed-by: Jim Mattson
<jmattson@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

KVM: x86: nVMX: fix x2APIC VTPR read intercept
Referring to the "VIRTUALIZING MSR-BASED APIC ACCESSES" chapter of the 
SDM, when "virtualize x2APIC mode" is 1 and "APIC-register 
virtualization" is 0, a RDMSR of 808H should return the VTPR from the 
virtual APIC page.
However, for nested, KVM currently fails to disable the read intercept 
for this MSR. This means that a RDMSR exit takes precedence over
"virtualize x2APIC mode", and KVM passes through L1's TPR to L2, instead
of sourcing the value from L2's virtual APIC page.
This patch fixes the issue by disabling the read intercept, in VMCS02, 
for the VTPR when "APIC-register virtualization" is 0.
The issue described above and fix prescribed here, were verified with a
related patch in kvm-unit-tests titled "Test VMX's virtualize x2APIC 
mode w/ nested".
Signed-off-by: Marc Orr <marcorr@google.com> Reviewed-by: Jim Mattson
<jmattson@google.com> Fixes: c992384bde84f ("KVM: vmx: speed up MSR
bitmap merge") Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

PCI: Add function 1 DMA alias quirk for Marvell 9170 SATA controller
There is a Marvell 88SE9170 PCIe SATA controller I found on a board
here. Some quick testing with the ARM SMMU enabled reveals that it
suffers from the same requester ID mixup problems as the other Marvell
chips listed already.
Add the PCI vendor/device ID to the list of chips which need the 
workaround.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org

dm integrity: fix deadlock with overlapping I/O
dm-integrity will deadlock if overlapping I/O is issued to it, the bug 
was introduced by commit 724376a04d1a ("dm integrity: implement fair 
range locks").  Users rarely use overlapping I/O so this bug went 
undetected until now.
Fix this bug by correcting, likely cut-n-paste, typos in 
ranges_overlap() and also remove a flawed ranges_overlap() check in 
remove_range_unlocked().  This condition could leave unprocessed bios 
hanging on wait_list forever.
Cc: stable@vger.kernel.org # v4.19+ Fixes: 724376a04d1a ("dm integrity:
implement fair range locks") Signed-off-by: Mikulas Patocka
<mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>

sunrpc: don't mark uninitialised items as VALID.
A recent commit added a call to cache_fresh_locked() when an expired
item was found. The call sets the CACHE_VALID flag, so it is important 
that the item actually is valid. There are two ways it could be valid: 
1/ If ->update has been called to fill in relevant content 2/ if
CACHE_NEGATIVE is set, to say that content doesn't exist.
An expired item that is waiting for an update will be neither. Setting
CACHE_VALID will mean that a subsequent call to cache_put() will be
likely to dereference uninitialised pointers.
So we must make sure the item is valid, and we already have code to do 
that in try_to_negate_entry().  This takes the hash lock and so cannot 
be used directly, so take out the two lines that we need and use them.
Now cache_fresh_locked() is certain to be called only on a valid item.
Cc: stable@kernel.org # 2.6.35 Fixes: 4ecd55ea0742 ("sunrpc: fix
cache_head leak due to queued request") Signed-off-by: NeilBrown
<neilb@suse.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>

nfsd/nfsd3_proc_readdir: fix buffer count and page pointers
After this commit
 f875a79 nfsd: allow nfsv3 readdir request to be larger. nfsv3 readdir
request size can be larger than PAGE_SIZE. So if the directory been read
is large enough, we can use multiple pages in rq_respages. Update buffer
count and page pointers like we do in readdirplus to make this happen.
Now listing a directory within 3000 files will panic because we are
counting in a wrong way and would write on random page.
Fixes: f875a79 "nfsd: allow nfsv3 readdir request to be larger" 
Signed-off-by: Murphy Zhou <jencce.kernel@gmail.com> Signed-off-by: J.
Bruce Fields <bfields@redhat.com>

lib/string.c: implement a basic bcmp
A recent optimization in Clang (r355672) lowers comparisons of the 
return value of memcmp against zero to comparisons of the return value 
of bcmp against zero.  This helps some platforms that implement bcmp 
more efficiently than memcmp.  glibc simply aliases bcmp to memcmp, but 
an optimized implementation is in the works.
This results in linkage failures for all targets with Clang due to the 
undefined symbol.  For now, just implement bcmp as a tailcail to memcmp 
to unbreak the build.  This routine can be further optimized in the 
future.
Other ideas discussed:
 * A weak alias was discussed, but breaks for architectures that define
  their own implementations of memcmp since aliases to declarations are
  not permitted (only definitions). Arch-specific memcmp
  implementations typically declare memcmp in C headers, but implement
  them in assembly.
 * -ffreestanding also is used sporadically throughout the kernel.
 * -fno-builtin-bcmp doesn't work when doing LTO.
Link: https://bugs.llvm.org/show_bug.cgi?id=41035 Link:
https://code.woboq.org/userspace/glibc/string/memcmp.c.html#bcmp Link:
https://github.com/llvm/llvm-project/commit/8e16d73346f8091461319a7dfc4ddd18eedcff13 
Link: https://github.com/ClangBuiltLinux/linux/issues/416 Link:
http://lkml.kernel.org/r/20190313211335.165605-1-ndesaulniers@google.com 
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reported-by:
Nathan Chancellor <natechancellor@gmail.com> Reported-by: Adhemerval
Zanella <adhemerval.zanella@linaro.org> Suggested-by: Arnd Bergmann
<arnd@arndb.de> Suggested-by: James Y Knight <jyknight@google.com> 
Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com> 
Suggested-by: Nathan Chancellor <natechancellor@gmail.com> Suggested-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Acked-by: Steven Rostedt
(VMware) <rostedt@goodmis.org> Reviewed-by: Nathan Chancellor
<natechancellor@gmail.com> Tested-by: Nathan Chancellor
<natechancellor@gmail.com> Reviewed-by: Masahiro Yamada
<yamada.masahiro@socionext.com> Reviewed-by: Andy Shevchenko
<andriy.shevchenko@linux.intel.com> Cc: David Laight
<David.Laight@ACULAB.COM> Cc: Rasmus Villemoes
<linux@rasmusvillemoes.dk> Cc: Namhyung Kim <namhyung@kernel.org> Cc:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alexander Shishkin
<alexander.shishkin@linux.intel.com> Cc: Dan Williams
<dan.j.williams@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

kmemleak: powerpc: skip scanning holes in the .bss section
Commit 2d4f567103ff ("KVM: PPC: Introduce kvm_tmp framework") adds 
kvm_tmp[] into the .bss section and then free the rest of unused spaces 
back to the page allocator.
kernel_init
 kvm_guest_init
   kvm_free_tmp
     free_reserved_area
       free_unref_page
         free_unref_page_prepare
With DEBUG_PAGEALLOC=y, it will unmap those pages from kernel.  As the 
result, kmemleak scan will trigger a panic when it scans the .bss 
section with unmapped pages.
This patch creates dedicated kmemleak objects for the .data, .bss and 
potentially .data..ro_after_init sections to allow partial freeing via 
the kmemleak_free_part() in the powerpc kvm_free_tmp() function.
Link:
http://lkml.kernel.org/r/20190321171917.62049-1-catalin.marinas@arm.com 
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Reported-by:
Qian Cai <cai@lca.pw> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
(powerpc) Tested-by: Qian Cai <cai@lca.pw> Cc: Paul Mackerras
<paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> 
Cc: Avi Kivity <avi@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> 
Cc: Radim Krcmar <rkrcmar@redhat.com> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

include/linux/bitrev.h: fix constant bitrev
clang points out with hundreds of warnings that the bitrev macros have a 
problem with constant input:
  drivers/hwmon/sht15.c:187:11: error: variable '__x' is uninitialized
when used within its own initialization
       [-Werror,-Wuninitialized]
         u8 crc = bitrev8(data->val_status & 0x0F);
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 include/linux/bitrev.h:102:21: note: expanded from macro 'bitrev8'
         __constant_bitrev8(__x) :                       \
         ~~~~~~~~~~~~~~~~~~~^~~~
 include/linux/bitrev.h:67:11: note: expanded from macro
'__constant_bitrev8'
         u8 __x = x;                     \
            ~~~   ^
Both the bitrev and the __constant_bitrev macros use an internal 
variable named __x, which goes horribly wrong when passing one to the 
other.
The obvious fix is to rename one of the variables, so this adds an extra
'_'.
It seems we got away with this because
 - there are only a few drivers using bitrev macros
 - usually there are no constant arguments to those
 - when they are constant, they tend to be either 0 or (unsigned)-1
  (drivers/isdn/i4l/isdnhdlc.o, drivers/iio/amplifiers/ad8366.c) and
  give the correct result by pure chance.
In fact, the only driver that I could find that gets different results 
with this is drivers/net/wan/slic_ds26522.c, which in turn is a driver 
for fairly rare hardware (adding the maintainer to Cc for testing).
Link: http://lkml.kernel.org/r/20190322140503.123580-1-arnd@arndb.de 
Fixes: 556d2f055bf6 ("ARM: 8187/1: add CONFIG_HAVE_ARCH_BITREVERSE to
support rbit instruction") Signed-off-by: Arnd Bergmann <arnd@arndb.de> 
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Cc: Zhao Qiang
<qiang.zhao@nxp.com> Cc: Yalin Wang <yalin.wang@sonymobile.com> Cc:
<stable@vger.kernel.org> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

lib/lzo: fix bugs for very short or empty input
For very short input data (0 - 1 bytes), lzo-rle was not behaving 
correctly.  Fix this behaviour and update documentation accordingly.
For zero-length input, lzo v0 outputs an end-of-stream marker only, 
which was misinterpreted by lzo-rle as a bitstream version number. 
Ensure bitstream versions > 0 require a minimum stream length of 5.
Also fixes a bug in handling the tail for very short inputs when a 
bitstream version is present.
Link:
http://lkml.kernel.org/r/20190326165857.34613-1-dave.rodgman@arm.com 
Signed-off-by: Dave Rodgman <dave.rodgman@arm.com> Signed-off-by: Andrew
Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

mm: fix vm_fault_t cast in VM_FAULT_GET_HINDEX()
Symmetrically to VM_FAULT_SET_HINDEX(), we need a force-cast in 
VM_FAULT_GET_HINDEX() to tell sparse that this is intentional.
Sparse complains about the current code when building a kernel with 
CONFIG_MEMORY_FAILURE:
  arch/x86/mm/fault.c:1058:53: warning: restricted vm_fault_t degrades
to integer
Link: http://lkml.kernel.org/r/20190327204117.35215-1-jannh@google.com 
Fixes: 3d3539018d2c ("mm: create the new vm_fault_t type") 
Signed-off-by: Jann Horn <jannh@google.com> Reviewed-by: Andrew Morton
<akpm@linux-foundation.org> Cc: Souptick Joarder <jrdr.linux@gmail.com> 
Cc: Matthew Wilcox <willy@infradead.org> Cc: Vlastimil Babka
<vbabka@suse.cz> Cc: "Kirill A. Shutemov"
<kirill.shutemov@linux.intel.com> Cc: Rik van Riel <riel@surriel.com> 
Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>

hugetlbfs: fix memory leak for resv_map
When mknod is used to create a block special file in hugetlbfs, it will 
allocate an inode and kmalloc a 'struct resv_map' via resv_map_alloc(). 
inode->i_mapping->private_data will point the newly allocated resv_map. 
However, when the device special file is opened bd_acquire() will set 
inode->i_mapping to bd_inode->i_mapping.  Thus the pointer to the 
allocated resv_map is lost and the structure is leaked.
Programs to reproduce:
       mount -t hugetlbfs nodev hugetlbfs
       mknod hugetlbfs/dev b 0 0
       exec 30<> hugetlbfs/dev
       umount hugetlbfs/
resv_map structures are only needed for inodes which can have associated 
page allocations.  To fix the leak, only allocate resv_map for those 
inodes which could possibly be associated with page allocations.
Link:
http://lkml.kernel.org/r/20190401213101.16476-1-mike.kravetz@oracle.com 
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com> Reviewed-by:
Andrew Morton <akpm@linux-foundation.org> Reported-by: Yufen Yu
<yuyufen@huawei.com> Suggested-by: Yufen Yu <yuyufen@huawei.com> 
Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>

mm/huge_memory.c: fix modifying of page protection by insert_pfn_pmd()
With some architectures like ppc64, set_pmd_at() cannot cope with a 
situation where there is already some (different) valid entry present.
Use pmdp_set_access_flags() instead to modify the pfn which is built to 
deal with modifying existing PMD entries.
This is similar to commit cae85cb8add3 ("mm/memory.c: fix modifying of 
page protection by insert_pfn()")
We also do similar update w.r.t insert_pfn_pud eventhough ppc64 don't 
support pud pfn entries now.
Without this patch we also see the below message in kernel log "BUG: 
non-zero pgtables_bytes on freeing mm:"
Link:
http://lkml.kernel.org/r/20190402115125.18803-1-aneesh.kumar@linux.ibm.com 
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> 
Reported-by: Chandan Rajendra <chandan@linux.ibm.com> Reviewed-by: Jan
Kara <jack@suse.cz> Cc: Dan Williams <dan.j.williams@intel.com> Cc:
<stable@vger.kernel.org> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

psi: clarify the units used in pressure files
The output of the PSI files show a bunch of numbers with no unit.  The 
psi.txt documentation file also does not indicate what units are used. 
One can only find out by looking at the source code.  The units are 
percentage for the averages and useconds for the total.  Make the 
information easier to find by documenting the units in psi.txt.
Link: http://lkml.kernel.org/r/20190402193810.3450-1-longman@redhat.com 
Signed-off-by: Waiman Long <longman@redhat.com> Acked-by: Johannes
Weiner <hannes@cmpxchg.org> Cc: "Peter Zijlstra (Intel)"
<peterz@infradead.org> Cc: Tejun Heo <tj@kernel.org> Cc: Jonathan Corbet
<corbet@lwn.net> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

mm: writeback: use exact memcg dirty counts
Since commit a983b5ebee57 ("mm: memcontrol: fix excessive complexity in 
memory.stat reporting") memcg dirty and writeback counters are managed 
as:
 1) per-memcg per-cpu values in range of [-32..32]
 2) per-memcg atomic counter
When a per-cpu counter cannot fit in [-32..32] it's flushed to the 
atomic.  Stat readers only check the atomic.  Thus readers such as 
balance_dirty_pages() may see a nontrivial error margin: 32 pages per 
cpu.
Assuming 100 cpus:
  4k x86 page_size:  13 MiB error per memcg
 64k ppc page_size: 200 MiB error per memcg
Considering that dirty+writeback are used together for some decisions
the errors double.
This inaccuracy can lead to undeserved oom kills.  One nasty case is 
when all per-cpu counters hold positive values offsetting an atomic 
negative value (i.e.  per_cpu[*]=32, atomic=n_cpu*-32). 
balance_dirty_pages() only consults the atomic and does not consider 
throttling the next n_cpu*32 dirty pages.  If the file_lru is in the 
13..200 MiB range then there's absolutely no dirty throttling, which 
burdens vmscan with only dirty+writeback pages thus resorting to oom 
kill.
It could be argued that tiny containers are not supported, but it's more 
subtle.  It's the amount the space available for file lru that matters. 
If a container has memory.max-200MiB of non reclaimable memory, then it 
will also suffer such oom kills on a 100 cpu machine.
The following test reliably ooms without this patch.  This patch avoids 
oom kills.
  $ cat test
 mount -t cgroup2 none /dev/cgroup
 cd /dev/cgroup
 echo +io +memory > cgroup.subtree_control
 mkdir test
 cd test
 echo 10M > memory.max
 (echo $BASHPID > cgroup.procs && exec /memcg-writeback-stress /foo)
 (echo $BASHPID > cgroup.procs && exec dd if=/dev/zero of=/foo bs=2M
count=100)
  $ cat memcg-writeback-stress.c
 /*
  * Dirty pages from all but one cpu.
  * Clean pages from the non dirtying cpu.
  * This is to stress per cpu counter imbalance.
  * On a 100 cpu machine:
  * - per memcg per cpu dirty count is 32 pages for each of 99 cpus
  * - per memcg atomic is -99*32 pages
  * - thus the complete dirty limit: sum of all counters 0
  * - balance_dirty_pages() only sees atomic count -99*32 pages, which
  *   it max()s to 0.
  * - So a workload can dirty -99*32 pages before balance_dirty_pages()
  *   cares.
  */
 #define _GNU_SOURCE
 #include <err.h>
 #include <fcntl.h>
 #include <sched.h>
 #include <stdlib.h>
 #include <stdio.h>
 #include <sys/stat.h>
 #include <sys/sysinfo.h>
 #include <sys/types.h>
 #include <unistd.h>
  static char *buf;
 static int bufSize;
  static void set_affinity(int cpu)
 {
 	cpu_set_t affinity;
  	CPU_ZERO(&affinity);
 	CPU_SET(cpu, &affinity);
 	if (sched_setaffinity(0, sizeof(affinity), &affinity))
 		err(1, "sched_setaffinity");
 }
  static void dirty_on(int output_fd, int cpu)
 {
 	int i, wrote;
  	set_affinity(cpu);
 	for (i = 0; i < 32; i++) {
 		for (wrote = 0; wrote < bufSize; ) {
 			int ret = write(output_fd, buf+wrote,
bufSize-wrote);
 			if (ret == -1)
 				err(1, "write");
 			wrote += ret;
 		}
 	}
 }
  int main(int argc, char **argv)
 {
 	int cpu, flush_cpu = 1, output_fd;
 	const char *output;
  	if (argc != 2)
 		errx(1, "usage: output_file");
  	output = argv[1];
 	bufSize = getpagesize();
 	buf = malloc(getpagesize());
 	if (buf == NULL)
 		errx(1, "malloc failed");
  	output_fd = open(output, O_CREAT|O_RDWR);
 	if (output_fd == -1)
 		err(1, "open(%s)", output);
  	for (cpu = 0; cpu < get_nprocs(); cpu++) {
 		if (cpu != flush_cpu)
 			dirty_on(output_fd, cpu);
 	}
  	set_affinity(flush_cpu);
 	if (fsync(output_fd))
 		err(1, "fsync(%s)", output);
 	if (close(output_fd))
 		err(1, "close(%s)", output);
 	free(buf);
 }
Make balance_dirty_pages() and wb_over_bg_thresh() work harder to 
collect exact per memcg counters.  This avoids the aforementioned oom 
kills.
This does not affect the overhead of memory.stat, which still reads the 
single atomic counter.
Why not use percpu_counter? memcg already handles cpus going offline, so 
no need for that overhead from percpu_counter.  And the percpu_counter 
spinlocks are more heavyweight than is required.
It probably also makes sense to use exact dirty and writeback counters 
in memcg oom reports.  But that is saved for later.
Link:
http://lkml.kernel.org/r/20190329174609.164344-1-gthelen@google.com 
Signed-off-by: Greg Thelen <gthelen@google.com> Reviewed-by: Roman
Gushchin <guro@fb.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> 
Cc: Michal Hocko <mhocko@kernel.org> Cc: Vladimir Davydov
<vdavydov.dev@gmail.com> Cc: Tejun Heo <tj@kernel.org> Cc:
<stable@vger.kernel.org>	[4.16+] Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

MAINTAINERS: fix bad pattern in ARM/NUVOTON NPCM
In the process of upstreaming architecture support for ARM/NUVOTON NPCM 
include/dt-bindings/clock/nuvoton,npcm7xx-clks.h was renamed 
include/dt-bindings/clock/nuvoton,npcm7xx-clock.h without updating 
MAINTAINERS.  This updates the MAINTAINERS pattern to match the new name 
of this file.
Link:
http://lkml.kernel.org/r/20190328235752.334462-1-tmaimon77@gmail.com 
Fixes: 6a498e06ba22 ("MAINTAINERS: Add entry for the Nuvoton NPCM
architecture") Signed-off-by: Brendan Higgins
<brendanhiggins@google.com> Signed-off-by: Tomer Maimon
<tmaimon77@gmail.com> Reported-by: Joe Perches <joe@perches.com> 
Reviewed-by: Benjamin Fair <benjaminfair@google.com> Cc: Avi Fishman
<avifishman70@gmail.com> Cc: Mukesh Ojha <mojha@codeaurora.org> Cc:
Nancy Yuen <yuenn@google.com> Cc: Patrick Venture <venture@google.com> 
Cc: Tali Perry <tali.perry1@gmail.com> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

MAINTAINERS: add maintainer and replacing reviewer ARM/NUVOTON NPCM
Add Tali Perry as Nuvoton NPCM maintainer, replace Brendan Higgins 
Nuvoton NPCM reviewer with Benjamin Fair.
Link:
http://lkml.kernel.org/r/20190328235752.334462-2-tmaimon77@gmail.com 
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com> Reviewed-by: Brendan
Higgins <brendanhiggins@google.com> Reviewed-by: Benjamin Fair
<benjaminfair@google.com> Reviewed-by: Mukesh Ojha
<mojha@codeaurora.org> Cc: Joe Perches <joe@perches.com> Cc: Avi Fishman
<avifishman70@gmail.com> Cc: Patrick Venture <venture@google.com> Cc:
Nancy Yuen <yuenn@google.com> Cc: Tali Perry <tali.perry1@gmail.com> 
Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>

sh: fix multiple function definition build errors
Many of the sh CPU-types have their own plat_irq_setup() and 
arch_init_clk_ops() functions, so these same (empty) functions in 
arch/sh/boards/of-generic.c are not needed and cause build errors.
If there is some case where these empty functions are needed, they can 
be retained by marking them as "__weak" while at the same time making 
builds that do not need them succeed.
Fixes these build errors:
arch/sh/boards/of-generic.o: In function `plat_irq_setup':
(.init.text+0x134): multiple definition of `plat_irq_setup' 
arch/sh/kernel/cpu/sh2/setup-sh7619.o:(.init.text+0x30): first defined
here arch/sh/boards/of-generic.o: In function `arch_init_clk_ops':
(.init.text+0x118): multiple definition of `arch_init_clk_ops' 
arch/sh/kernel/cpu/sh2/clock-sh7619.o:(.init.text+0x0): first defined
here
Link:
http://lkml.kernel.org/r/9ee4e0c5-f100-86a2-bd4d-1d3287ceab31@infradead.org 
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kbuild
test robot <lkp@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Cc:
Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Rich Felker
<dalias@libc.org> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

mm/util.c: fix strndup_user() comment
The kerneldoc misdescribes strndup_user()'s return value.
Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Timur Tabi
<timur@freescale.com> Cc: Mihai Caraman <mihai.caraman@freescale.com> 
Cc: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

kernel/sysctl.c: fix out-of-bounds access when setting file-max
Commit 32a5ad9c2285 ("sysctl: handle overflow for file-max") hooked up 
min/max values for the file-max sysctl parameter via the .extra1 and
.extra2 fields in the corresponding struct ctl_table entry.
Unfortunately, the minimum value points at the global 'zero' variable, 
which is an int.  This results in a KASAN splat when accessed as a long 
by proc_doulongvec_minmax on 64-bit architectures:
  | BUG: KASAN: global-out-of-bounds in
__do_proc_doulongvec_minmax+0x5d8/0x6a0
 | Read of size 8 at addr ffff2000133d1c20 by task systemd/1
 |
 | CPU: 0 PID: 1 Comm: systemd Not tainted 5.1.0-rc3-00012-g40b114779944
#2
 | Hardware name: linux,dummy-virt (DT)
 | Call trace:
 |  dump_backtrace+0x0/0x228
 |  show_stack+0x14/0x20
 |  dump_stack+0xe8/0x124
 |  print_address_description+0x60/0x258
 |  kasan_report+0x140/0x1a0
 |  __asan_report_load8_noabort+0x18/0x20
 |  __do_proc_doulongvec_minmax+0x5d8/0x6a0
 |  proc_doulongvec_minmax+0x4c/0x78
 |  proc_sys_call_handler.isra.19+0x144/0x1d8
 |  proc_sys_write+0x34/0x58
 |  __vfs_write+0x54/0xe8
 |  vfs_write+0x124/0x3c0
 |  ksys_write+0xbc/0x168
 |  __arm64_sys_write+0x68/0x98
 |  el0_svc_common+0x100/0x258
 |  el0_svc_handler+0x48/0xc0
 |  el0_svc+0x8/0xc
 |
 | The buggy address belongs to the variable:
 |  zero+0x0/0x40
 |
 | Memory state around the buggy address:
 |  ffff2000133d1b00: 00 00 00 00 00 00 00 00 fa fa fa fa 04 fa fa fa
 |  ffff2000133d1b80: fa fa fa fa 04 fa fa fa fa fa fa fa 04 fa fa fa
 | >ffff2000133d1c00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
 |                                ^
 |  ffff2000133d1c80: fa fa fa fa 00 fa fa fa fa fa fa fa 00 00 00 00
 |  ffff2000133d1d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Fix the splat by introducing a unsigned long 'zero_ul' and using that 
instead.
Link:
http://lkml.kernel.org/r/20190403153409.17307-1-will.deacon@arm.com 
Fixes: 32a5ad9c2285 ("sysctl: handle overflow for file-max") 
Signed-off-by: Will Deacon <will.deacon@arm.com> Acked-by: Christian
Brauner <christian@brauner.io> Cc: Kees Cook <keescook@chromium.org> Cc:
Alexey Dobriyan <adobriyan@gmail.com> Cc: Matteo Croce
<mcroce@redhat.com> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

x86/asm: Use stricter assembly constraints in bitops
There's a number of problems with how arch/x86/include/asm/bitops.h is
currently using assembly constraints for the memory region bitops are
modifying:
1) Use memory clobber in bitops that touch arbitrary memory
Certain bit operations that read/write bits take a base pointer and an 
arbitrarily large offset to address the bit relative to that base. 
Inline assembly constraints aren't expressive enough to tell the 
compiler that the assembly directive is going to touch a specific memory 
location of unknown size, therefore we have to use the "memory" clobber 
to indicate that the assembly is going to access memory locations other 
than those listed in the inputs/outputs.
To indicate that BTR/BTS instructions don't necessarily touch the first 
sizeof(long) bytes of the argument, we also move the address to assembly 
inputs.
This particular change leads to size increase of 124 kernel functions in 
a defconfig build. For some of them the diff is in NOP operations, other 
end up re-reading values from memory and may potentially slow down the 
execution. But without these clobbers the compiler is free to cache the
contents of the bitmaps and use them as if they weren't changed by the
inline assembly.
2) Use byte-sized arguments for operations touching single bytes.
Passing a long value to ANDB/ORB/XORB instructions makes the compiler 
treat sizeof(long) bytes as being clobbered, which isn't the case. This 
may theoretically lead to worse code in the case of heavy optimization.
Practical impact:
I've built a defconfig kernel and looked through some of the functions 
generated by GCC 7.3.0 with and without this clobber, and didn't spot 
any miscompilations.
However there is a (trivial) theoretical case where this code leads to 
miscompilation:
  https://lkml.org/lkml/2019/3/28/393
using just GCC 8.3.0 with -O2.  It isn't hard to imagine someone writes 
such a function in the kernel someday.
So the primary motivation is to fix an existing misuse of the asm 
directive, which happens to work in certain configurations now, but 
isn't guaranteed to work under different circumstances.
[ --mingo: Added -stable tag because defconfig only builds a fraction
 of the kernel and the trivial testcase looks normal enough to
 be used in existing or in-development code. ]
Signed-off-by: Alexander Potapenko <glider@google.com> Cc:
<stable@vger.kernel.org> Cc: Andy Lutomirski <luto@kernel.org> Cc:
Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc:
Denys Vlasenko <dvlasenk@redhat.com> Cc: Dmitry Vyukov
<dvyukov@google.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: James Y
Knight <jyknight@google.com> Cc: Linus Torvalds
<torvalds@linux-foundation.org> Cc: Paul E. McKenney
<paulmck@linux.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc:
Thomas Gleixner <tglx@linutronix.de> Link:
http://lkml.kernel.org/r/20190402112813.193378-1-glider@google.com
[ Edited the changelog, tidied up one of the defines. ] Signed-off-by:
Ingo Molnar <mingo@kernel.org>

i2c: imx: don't leak the i2c adapter on error
Make sure to free the i2c adapter on the error exit path.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Reviewed-by:
Mukesh Ojha <mojha@codeaurora.org> Reviewed-by: Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> Fixes: e1ab9a468e3b ("i2c: imx: improve
the error handling in i2c_imx_dma_request()") Signed-off-by: Wolfram
Sang <wsa@the-dreams.de>

null_blk: prevent crash from bad home_node value
At module load, if the selected home_node value is greater than the
available numa nodes, the system will crash in
__alloc_pages_nodemask() due to a bad paging request.  Prevent this user
error crash by detecting the bad value, logging an error, and setting
g_home_node back to the default of NUMA_NO_NODE.
Signed-off-by: John Pittman <jpittman@redhat.com> Signed-off-by: Jens
Axboe <axboe@kernel.dk>

xsysace: Fix error handling in ace_setup
If xace hardware reports a bad version number, the error handling code 
in ace_setup() calls put_disk(), followed by queue cleanup. However,
since the disk data structure has the queue pointer set, put_disk() also 
cleans and releases the queue. This results in blk_cleanup_queue() 
accessing an already released data structure, which in turn may result 
in a crash such as the following.
[   10.681671] BUG: Kernel NULL pointer dereference at 0x00000040
[   10.681826] Faulting instruction address: 0xc0431480
[   10.682072] Oops: Kernel access of bad area, sig: 11 [#1]
[   10.682251] BE PAGE_SIZE=4K PREEMPT Xilinx Virtex440
[   10.682387] Modules linked in:
[   10.682528] CPU: 0 PID: 1 Comm: swapper Tainted: G        W        
5.0.0-rc6-next-20190218+ #2
[   10.682733] NIP:  c0431480 LR: c043147c CTR: c0422ad8
[   10.682863] REGS: cf82fbe0 TRAP: 0300   Tainted: G        W         
(5.0.0-rc6-next-20190218+)
[   10.683065] MSR:  00029000 <CE,EE,ME>  CR: 22000222  XER: 00000000
[   10.683236] DEAR: 00000040 ESR: 00000000
[   10.683236] GPR00: c043147c cf82fc90 cf82ccc0 00000000 00000000
00000000 00000002 00000000
[   10.683236] GPR08: 00000000 00000000 c04310bc 00000000 22000222
00000000 c0002c54 00000000
[   10.683236] GPR16: 00000000 00000001 c09aa39c c09021b0 c09021dc
00000007 c0a68c08 00000000
[   10.683236] GPR24: 00000001 ced6d400 ced6dcf0 c0815d9c 00000000
00000000 00000000 cedf0800
[   10.684331] NIP [c0431480] blk_mq_run_hw_queue+0x28/0x114
[   10.684473] LR [c043147c] blk_mq_run_hw_queue+0x24/0x114
[   10.684602] Call Trace:
[   10.684671] [cf82fc90] [c043147c] blk_mq_run_hw_queue+0x24/0x114
(unreliable)
[   10.684854] [cf82fcc0] [c04315bc] blk_mq_run_hw_queues+0x50/0x7c
[   10.685002] [cf82fce0] [c0422b24] blk_set_queue_dying+0x30/0x68
[   10.685154] [cf82fcf0] [c0423ec0] blk_cleanup_queue+0x34/0x14c
[   10.685306] [cf82fd10] [c054d73c] ace_probe+0x3dc/0x508
[   10.685445] [cf82fd50] [c052d740] platform_drv_probe+0x4c/0xb8
[   10.685592] [cf82fd70] [c052abb0] really_probe+0x20c/0x32c
[   10.685728] [cf82fda0] [c052ae58] driver_probe_device+0x68/0x464
[   10.685877] [cf82fdc0] [c052b500] device_driver_attach+0xb4/0xe4
[   10.686024] [cf82fde0] [c052b5dc] __driver_attach+0xac/0xfc
[   10.686161] [cf82fe00] [c0528428] bus_for_each_dev+0x80/0xc0
[   10.686314] [cf82fe30] [c0529b3c] bus_add_driver+0x144/0x234
[   10.686457] [cf82fe50] [c052c46c] driver_register+0x88/0x15c
[   10.686610] [cf82fe60] [c09de288] ace_init+0x4c/0xac
[   10.686742] [cf82fe80] [c0002730] do_one_initcall+0xac/0x330
[   10.686888] [cf82fee0] [c09aafd0] kernel_init_freeable+0x34c/0x478
[   10.687043] [cf82ff30] [c0002c6c] kernel_init+0x18/0x114
[   10.687188] [cf82ff40] [c000f2f0] ret_from_kernel_thread+0x14/0x1c
[   10.687349] Instruction dump:
[   10.687435] 3863ffd4 4bfffd70 9421ffd0 7c0802a6 93c10028 7c9e2378
93e1002c 38810008
[   10.687637] 7c7f1b78 90010034 4bfffc25 813f008c <81290040> 75290100
4182002c 80810008
[   10.688056] ---[ end trace 13c9ff51d41b9d40 ]---
Fix the problem by setting the disk queue pointer to NULL before calling 
put_disk(). A more comprehensive fix might be to rearrange the code to
check the hardware version before initializing data structures, but I
don't know if this would have undesirable side effects, and it would
increase the complexity of backporting the fix to older kernels.
Fixes: 74489a91dd43a ("Add support for Xilinx SystemACE CompactFlash
interface") Acked-by: Michal Simek <michal.simek@xilinx.com> 
Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Jens
Axboe <axboe@kernel.dk>

fs: stream_open - opener for stream-like files so that read and write
can run simultaneously without deadlock
Commit 9c225f2655e3 ("vfs: atomic f_pos accesses as per POSIX") added 
locking for file.f_pos access and in particular made concurrent read and 
write not possible - now both those functions take f_pos lock for the 
whole run, and so if e.g. a read is blocked waiting for data, write will 
deadlock waiting for that read to complete.
This caused regression for stream-like files where previously read and 
write could run simultaneously, but after that patch could not do so 
anymore. See e.g. commit 581d21a2d02a ("xenbus: fix deadlock on writes 
to /proc/xen/xenbus") which fixes such regression for particular case of
/proc/xen/xenbus.
The patch that added f_pos lock in 2014 did so to guarantee POSIX thread 
safety for read/write/lseek and added the locking to file descriptors of 
all regular files. In 2014 that thread-safety problem was not new as it 
was already discussed earlier in 2006.
However even though 2006'th version of Linus's patch was adding f_pos 
locking "only for files that are marked seekable with FMODE_LSEEK (thus 
avoiding the stream-like objects like pipes and sockets)", the 2014 
version - the one that actually made it into the tree as 9c225f2655e3 - 
is doing so irregardless of whether a file is seekable or not.
See
    https://lore.kernel.org/lkml/53022DB1.4070805@gmail.com/
   https://lwn.net/Articles/180387
   https://lwn.net/Articles/180396
for historic context.
The reason that it did so is, probably, that there are many files that 
are marked non-seekable, but e.g. their read implementation actually 
depends on knowing current position to correctly handle the read. Some 
examples:
	kernel/power/user.c		snapshot_read
fs/debugfs/file.c		u32_array_read
fs/fuse/control.c		fuse_conn_waiting_read + ...
drivers/hwmon/asus_atk0110.c	atk_debugfs_ggrp_read
arch/s390/hypfs/inode.c		hypfs_read_iter
...
Despite that, many nonseekable_open users implement read and write with 
pure stream semantics - they don't depend on passed ppos at all. And for 
those cases where read could wait for something inside, it creates a 
situation similar to xenbus - the write could be never made to go until 
read is done, and read is waiting for some, potentially external, event, 
for potentially unbounded time -> deadlock.
Besides xenbus, there are 14 such places in the kernel that I've found 
with semantic patch (see below):
	drivers/xen/evtchn.c:667:8-24: ERROR: evtchn_fops: .read() can
deadlock .write()
drivers/isdn/capi/capi.c:963:8-24: ERROR: capi_fops: .read() can
deadlock .write()
drivers/input/evdev.c:527:1-17: ERROR: evdev_fops: .read() can deadlock
.write()
drivers/char/pcmcia/cm4000_cs.c:1685:7-23: ERROR: cm4000_fops: .read()
can deadlock .write()
net/rfkill/core.c:1146:8-24: ERROR: rfkill_fops: .read() can deadlock
.write()
drivers/s390/char/fs3270.c:488:1-17: ERROR: fs3270_fops: .read() can
deadlock .write()
drivers/usb/misc/ldusb.c:310:1-17: ERROR: ld_usb_fops: .read() can
deadlock .write()
drivers/hid/uhid.c:635:1-17: ERROR: uhid_fops: .read() can deadlock
.write()
net/batman-adv/icmp_socket.c:80:1-17: ERROR: batadv_fops: .read() can
deadlock .write()
drivers/media/rc/lirc_dev.c:198:1-17: ERROR: lirc_fops: .read() can
deadlock .write()
drivers/leds/uleds.c:77:1-17: ERROR: uleds_fops: .read() can deadlock
.write()
drivers/input/misc/uinput.c:400:1-17: ERROR: uinput_fops: .read() can
deadlock .write()
drivers/infiniband/core/user_mad.c:985:7-23: ERROR: umad_fops: .read()
can deadlock .write()
drivers/gnss/core.c:45:1-17: ERROR: gnss_fops: .read() can deadlock
.write()
In addition to the cases above another regression caused by f_pos 
locking is that now FUSE filesystems that implement open with 
FOPEN_NONSEEKABLE flag, can no longer implement bidirectional 
stream-like files - for the same reason as above e.g. read can deadlock 
write locking on file.f_pos in the kernel.
FUSE's FOPEN_NONSEEKABLE was added in 2008 in a7c1b990f715 ("fuse: 
implement nonseekable open") to support OSSPD. OSSPD implements /dev/dsp 
in userspace with FOPEN_NONSEEKABLE flag, with corresponding read and 
write routines not depending on current position at all, and with both 
read and write being potentially blocking operations:
See
    https://github.com/libfuse/osspd
   https://lwn.net/Articles/308445
    https://github.com/libfuse/osspd/blob/14a9cff0/osspd.c#L1406
   https://github.com/libfuse/osspd/blob/14a9cff0/osspd.c#L1438-L1477
   https://github.com/libfuse/osspd/blob/14a9cff0/osspd.c#L1479-L1510
Corresponding libfuse example/test also describes FOPEN_NONSEEKABLE as
"somewhat pipe-like files ..." with read handler not using offset. 
However that test implements only read without write and cannot exercise 
the deadlock scenario:
   
https://github.com/libfuse/libfuse/blob/fuse-3.4.2-3-ga1bff7d/example/poll.c#L124-L131
  
https://github.com/libfuse/libfuse/blob/fuse-3.4.2-3-ga1bff7d/example/poll.c#L146-L163
  
https://github.com/libfuse/libfuse/blob/fuse-3.4.2-3-ga1bff7d/example/poll.c#L209-L216
I've actually hit the read vs write deadlock for real while implementing 
my FUSE filesystem where there is /head/watch file, for which open 
creates separate bidirectional socket-like stream in between filesystem 
and its user with both read and write being later performed 
simultaneously. And there it is semantically not easy to split the 
stream into two separate read-only and write-only channels:
   
https://lab.nexedi.com/kirr/wendelin.core/blob/f13aa600/wcfs/wcfs.go#L88-169
Let's fix this regression. The plan is:
1. We can't change nonseekable_open to include &~FMODE_ATOMIC_POS -
  doing so would break many in-kernel nonseekable_open users which
  actually use ppos in read/write handlers.
2. Add stream_open() to kernel to open stream-like non-seekable file
  descriptors. Read and write on such file descriptors would never use
  nor change ppos. And with that property on stream-like files read and
  write will be running without taking f_pos lock - i.e. read and write
  could be running simultaneously.
3. With semantic patch search and convert to stream_open all in-kernel
  nonseekable_open users for which read and write actually do not
  depend on ppos and where there is no other methods in file_operations
  which assume @offset access.
4. Add FOPEN_STREAM to fs/fuse/ and open in-kernel file-descriptors via
  steam_open if that bit is present in filesystem open reply.
   It was tempting to change fs/fuse/ open handler to use stream_open
  instead of nonseekable_open on just FOPEN_NONSEEKABLE flags, but
  grepping through Debian codesearch shows users of FOPEN_NONSEEKABLE,
  and in particular GVFS which actually uses offset in its read and
  write handlers
	https://codesearch.debian.net/search?q=-%3Enonseekable+%3D
https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1080
https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1247-1346
https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1399-1481
   so if we would do such a change it will break a real user.
5. Add stream_open and FOPEN_STREAM handling to stable kernels starting
  from v3.14+ (the kernel where 9c225f2655 first appeared).
   This will allow to patch OSSPD and other FUSE filesystems that
  provide stream-like files to return FOPEN_STREAM | FOPEN_NONSEEKABLE
  in their open handler and this way avoid the deadlock on all kernel
  versions. This should work because fs/fuse/ ignores unknown open
  flags returned from a filesystem and so passing FOPEN_STREAM to a
  kernel that is not aware of this flag cannot hurt. In turn the kernel
  that is not aware of FOPEN_STREAM will be < v3.14 where just
  FOPEN_NONSEEKABLE is sufficient to implement streams without read vs
  write deadlock.
This patch adds stream_open, converts /proc/xen/xenbus to it and adds 
semantic patch to automatically locate in-kernel places that are either 
required to be converted due to read vs write deadlock, or that are just 
safe to be converted because read and write do not use ppos and there 
are no other funky methods in file_operations.
Regarding semantic patch I've verified each generated change manually - 
that it is correct to convert - and each other nonseekable_open instance 
left - that it is either not correct to convert there, or that it is not 
converted due to current stream_open.cocci limitations.
The script also does not convert files that should be valid to convert, 
but that currently have .llseek = noop_llseek or generic_file_llseek for 
unknown reason despite file being opened with nonseekable_open (e.g. 
drivers/input/mousedev.c)
Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Yongzhi Pan
<panyongzhi@gmail.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: David
Vrabel <david.vrabel@citrix.com> Cc: Juergen Gross <jgross@suse.com> Cc:
Miklos Szeredi <miklos@szeredi.hu> Cc: Tejun Heo <tj@kernel.org> Cc:
Kirill Tkhai <ktkhai@virtuozzo.com> Cc: Arnd Bergmann <arnd@arndb.de> 
Cc: Christoph Hellwig <hch@lst.de> Cc: Greg Kroah-Hartman
<gregkh@linuxfoundation.org> Cc: Julia Lawall <Julia.Lawall@lip6.fr> Cc:
Nikolaus Rath <Nikolaus@rath.org> Cc: Han-Wen Nienhuys
<hanwen@google.com> Signed-off-by: Kirill Smelkov <kirr@nexedi.com> 
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Revert: parisc: Use F_EXTEND() macro in iosapic code
Revert parts of commit 97d7e2e3fd8a ("parisc: Use F_EXTEND() macro in 
iosapic code"). It breaks booting the 32-bit kernel on some machines.
Reported-by: Sven Schnelle <svens@stackframe.org> Tested-by: Sven
Schnelle <svens@stackframe.org> Fixes: 97d7e2e3fd8a ("parisc: Use
F_EXTEND() macro in iosapic code") Signed-off-by: Helge Deller
<deller@gmx.de>

parisc: regs_return_value() should return gpr28
While working on kretprobes for PA-RISC I was wondering while the 
kprobes sanity test always fails on kretprobes. This is caused by 
returning gpr20 instead of gpr28.
Signed-off-by: Sven Schnelle <svens@stackframe.org> Signed-off-by: Helge
Deller <deller@gmx.de> Cc: stable@vger.kernel.org # 4.14+

parisc: also set iaoq_b in instruction_pointer_set()
When setting the instruction pointer on PA-RISC we also need to set the
back of the instruction queue to the new offset, otherwise we will
execute on instruction from the new location, and jumping back to the
old location stored in iaoq_b.
Signed-off-by: Sven Schnelle <svens@stackframe.org> Signed-off-by: Helge
Deller <deller@gmx.de> Fixes: 75ebedf1d263 ("parisc: Add
HAVE_REGS_AND_STACK_ACCESS_API feature") Cc: stable@vger.kernel.org #
4.19+

parisc: Detect QEMU earlier in boot process
While adding LASI support to QEMU, I noticed that the QEMU detection in 
the kernel happens much too late. For example, when a LASI chip is found 
by the kernel, it registers the LASI LED driver as well.  But when we 
run on QEMU it makes sense to avoid spending unnecessary CPU cycles, so 
we need to access the running_on_QEMU flag earlier than before.
This patch now makes the QEMU detection the fist task of the Linux 
kernel by moving it to where the kernel enters the C-coding.
Fixes: 310d82784fb4 ("parisc: qemu idle sleep support") Signed-off-by:
Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v4.14+

NFC: nci: Add some bounds checking in nci_hci_cmd_received()
This is similar to commit 674d9de02aa7 ("NFC: Fix possible memory 
corruption when handling SHDLC I-Frame commands").
I'm not totally sure, but I think that commit description may have 
overstated the danger.  I was under the impression that this data came 
from the firmware?  If you can't trust your networking firmware, then 
you're already in trouble.
Anyway, these days we add bounds checking where ever we can and we call 
it kernel hardening.  Better safe than sorry.
Fixes: 11f54f228643 ("NFC: nci: Add HCI over NCI protocol support") 
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
David S. Miller <davem@davemloft.net>

nfc: nci: Potential off by one in ->pipes[] array
This is similar to commit e285d5bfb7e9 ("NFC: Fix the number of pipes") 
where we changed NFC_HCI_MAX_PIPES from 127 to 128.
As the comment next to the define explains, the pipe identifier is 7 
bits long.  The highest possible pipe is 127, but the number of possible 
pipes is 128.  As the code is now, then there is potential for an out of
bounds array access:
    net/nfc/nci/hci.c:297 nci_hci_cmd_received() warn: array off by one?
   'ndev->hci_dev->pipes[pipe]' '0-127 == 127'
Fixes: 11f54f228643 ("NFC: nci: Add HCI over NCI protocol support") 
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
David S. Miller <davem@davemloft.net>

powerpc/vdso32: fix CLOCK_MONOTONIC on PPC64
Commit b5b4453e7912 ("powerpc/vdso64: Fix CLOCK_MONOTONIC 
inconsistencies across Y2038") changed the type of wtom_clock_sec to s64
on PPC64. Therefore, VDSO32 needs to read it with a 4 bytes shift in
order to retrieve the lower part of it.
Fixes: b5b4453e7912 ("powerpc/vdso64: Fix CLOCK_MONOTONIC
inconsistencies across Y2038") Reported-by: Christian Zigotzky
<chzigotzky@xenosoft.de> Signed-off-by: Christophe Leroy
<christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman
<mpe@ellerman.id.au>

libnvdimm/pmem: fix a possible OOB access when read and write pmem
If offset is not zero and length is bigger than PAGE_SIZE, this will
cause to out of boundary access to a page memory
Fixes: 98cc093cba1e ("block, THP: make block_device_operations.rw_page
support THP") Co-developed-by: Liang ZhiCheng <liangzhicheng@baidu.com> 
Signed-off-by: Liang ZhiCheng <liangzhicheng@baidu.com> Signed-off-by:
Li RongQing <lirongqing@baidu.com> Reviewed-by: Ira Weiny
<ira.weiny@intel.com> Reviewed-by: Jeff Moyer <jmoyer@redhat.com> 
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

dt-bindings: cpu: Fix JSON schema
Commit fd73403a4862 ("dt-bindings: arm: Add SMP enable-method for 
Milbeaut") added support for a new cpu enable-method, but did so using 
tabulations to ident. This is however invalid in the syntax, and
resulted in a failure when trying to use that schemas for validation.
Use spaces instead of tabs to indent to fix this.
Fixes: fd73403a4862 ("dt-bindings: arm: Add SMP enable-method for
Milbeaut") Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> 
Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Sugaya Taichi
<sugaya.taichi@socionext.com> Signed-off-by: Olof Johansson
<olof@lixom.net>

Revert "ARM: dts: nomadik: Fix polarity of SPI CS"
This reverts commit fa9463564e77067df81b0b8dec91adbbbc47bfb4.
Per Linus Walleij:
Dear ARM SoC maintainers,
can you please revert this patch. It was the wrong solution to the wrong
problem, and I must have acted in stress. Andrey fixed the real bug in a
proper way in these commits:
commit e5545c94e43b8f6599ffc01df8d1aedf18ee912a
"gpio: of: Check propname before applying "cs-gpios" quirks" commit
7ce40277bf848391705011ba37eac2e377cbd9e6
"gpio: of: Check for "spi-cs-high" in child instead of parent node"
Signed-off-by: Olof Johansson <olof@lixom.net>

ARM: orion: don't use using 64-bit DMA masks
clang warns about statically defined DMA masks from the DMA_BIT_MASK 
macro with length 64:
arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
               .coherent_dma_mask      = DMA_BIT_MASK(64),
                                         ^~~~~~~~~~~~~~~~ 
include/linux/dma-mapping.h:141:54: note: expanded from macro
'DMA_BIT_MASK'
#define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
The ones in orion shouldn't really be 64 bit masks, so changing them to
what the driver can support avoids the warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Olof
Johansson <olof@lixom.net>

ARM: iop: don't use using 64-bit DMA masks
clang warns about statically defined DMA masks from the DMA_BIT_MASK 
macro with length 64:
 arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of
type [-Werror,-Wshift-count-overflow]
static u64 iop13xx_adma_dmamask = DMA_BIT_MASK(64);
                                 ^~~~~~~~~~~~~~~~
include/linux/dma-mapping.h:141:54: note: expanded from macro
'DMA_BIT_MASK'
#define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
                                                     ^ ~~~
The ones in iop shouldn't really be 64 bit masks, so changing them to
what the driver can support avoids the warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Olof
Johansson <olof@lixom.net>

ARM: milbeaut: fix build with !CONFIG_HOTPLUG_CPU
When HOTPLUG_CPU is disabled, some fields in the smp operations are not
available or needed:
arch/arm/mach-milbeaut/platsmp.c:90:3: error: field designator 'cpu_die'
does not refer to any field in type
     'struct smp_operations'
       .cpu_die                = m10v_cpu_die,
        ^ arch/arm/mach-milbeaut/platsmp.c:91:3: error: field designator
'cpu_kill' does not refer to any field in type
     'struct smp_operations'
       .cpu_kill               = m10v_cpu_kill,
        ^
Hide them in an #ifdef like the other platforms do.
Fixes: 9fb29c734f9e ("ARM: milbeaut: Add basic support for Milbeaut m10v
SoC") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Olof
Johansson <olof@lixom.net>

Linux 5.1-rc4

selftests: add a tc matchall test case
This is a follow up of the commit 0db6f8befc32 ("net/sched: fix ->get 
helper of the matchall cls").
To test it:
$ cd tools/testing/selftests/tc-testing
$ ln -s ../plugin-lib/nsPlugin.py plugins/20-nsPlugin.py
$ ./tdc.py -n -e 2638
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> 
Signed-off-by: David S. Miller <davem@davemloft.net>

drm/i915/gvt: Annotate iomem usage
Fix the sparse warning for blithely using iomem with normal memcpy:
drivers/gpu/drm/i915/gvt/kvmgt.c:916:21: warning: incorrect type in
assignment (different address spaces) 
drivers/gpu/drm/i915/gvt/kvmgt.c:916:21:    expected void *aperture_va 
drivers/gpu/drm/i915/gvt/kvmgt.c:916:21:    got void [noderef] <asn:2> * 
drivers/gpu/drm/i915/gvt/kvmgt.c:927:26: warning: incorrect type in
argument 1 (different address spaces) 
drivers/gpu/drm/i915/gvt/kvmgt.c:927:26:    expected void [noderef]
<asn:2> *vaddr drivers/gpu/drm/i915/gvt/kvmgt.c:927:26:    got void
*aperture_va
Fixes: d480b28a41a6 ("drm/i915/gvt: Fix aperture read/write emulation
when enable x-no-mmap=on") Reviewed-by: Zhenyu Wang
<zhenyuw@linux.intel.com> Signed-off-by: Chris Wilson
<chris@chris-wilson.co.uk> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc:
Changbin Du <changbin.du@intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> 
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

drm/i915/gvt: Prevent use-after-free in ppgtt_free_all_spt()
ppgtt_free_all_spt() iterates the radixtree as it is deleting it, 
forgoing all protection against the leaves being freed in the process
(leaving the iter pointing into the void).
A minimal fix seems to be to use the available post_shadow_list to 
decompose the tree into a list prior to destroying the radixtree.
Alerted by the sparse warnings:
drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in
assignment (different address spaces) 
drivers/gpu/drm/i915/gvt/gtt.c:757:9:    expected void **slot 
drivers/gpu/drm/i915/gvt/gtt.c:757:9:    got void [noderef] <asn:4> ** 
drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in
assignment (different address spaces) 
drivers/gpu/drm/i915/gvt/gtt.c:757:9:    expected void **slot 
drivers/gpu/drm/i915/gvt/gtt.c:757:9:    got void [noderef] <asn:4> ** 
drivers/gpu/drm/i915/gvt/gtt.c:758:45: warning: incorrect type in
argument 1 (different address spaces) 
drivers/gpu/drm/i915/gvt/gtt.c:758:45:    expected void [noderef]
<asn:4> **slot drivers/gpu/drm/i915/gvt/gtt.c:758:45:    got void **slot 
drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in
argument 1 (different address spaces) 
drivers/gpu/drm/i915/gvt/gtt.c:757:9:    expected void [noderef] <asn:4>
**slot drivers/gpu/drm/i915/gvt/gtt.c:757:9:    got void **slot 
drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in
assignment (different address spaces) 
drivers/gpu/drm/i915/gvt/gtt.c:757:9:    expected void **slot 
drivers/gpu/drm/i915/gvt/gtt.c:757:9:    got void [noderef] <asn:4> **
This would also have been loudly warning if run through CI for the 
invalid RCU dereferences.
Fixes: b6c126a39345 ("drm/i915/gvt: Manage shadow pages with radix
tree") Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Changbin Du
<changbin.du@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc:
Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang
<zhenyuw@linux.intel.com>

slab: fix a crash by reading /proc/slab_allocators
The commit 510ded33e075 ("slab: implement slab_root_caches list") 
changes the name of the list node within "struct kmem_cache" from "list" 
to "root_caches_node", but leaks_show() still use the "list" which 
causes a crash when reading /proc/slab_allocators.
You need to have CONFIG_SLAB=y and CONFIG_MEMCG=y to see the problem, 
because without MEMCG all slab caches are root caches, and the "list" 
node happens to be the right one.
Fixes: 510ded33e075 ("slab: implement slab_root_caches list") 
Signed-off-by: Qian Cai <cai@lca.pw> Reviewed-by: Tobin C. Harding
<tobin@kernel.org> Cc: Tejun Heo <tj@kernel.org> Cc: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org>

net: vrf: Fix ping failed when vrf mtu is set to 0
When the mtu of a vrf device is set to 0, it would cause ping failed. So
I think we should limit vrf mtu in a reasonable range to solve this
problem. I set dev->min_mtu to IPV6_MIN_MTU, so it will works for both
ipv4 and ipv6. And if dev->max_mtu still be 0 can be confusing, so I set
dev->max_mtu to ETH_MAX_MTU.
Here is the reproduce step:
1.Config vrf interface and set mtu to 0: 3: enp4s0:
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master vrf1
state UP mode DEFAULT group default qlen 1000
   link/ether 52:54:00:9e:dd:c1 brd ff:ff:ff:ff:ff:ff
2.Ping peer: 3: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
fq_codel master vrf1 state UP group default qlen 1000
   link/ether 52:54:00:9e:dd:c1 brd ff:ff:ff:ff:ff:ff
   inet 10.0.0.1/16 scope global enp4s0
      valid_lft forever preferred_lft forever connect: Network is
unreachable
3.Set mtu to default value, ping works: PING 10.0.0.2 (10.0.0.2) 56(84)
bytes of data. 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=1.88 ms
Fixes: ad49bc6361ca2 ("net: vrf: remove MTU limits for vrf device") 
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Reviewed-by: David
Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

drm/udl: add a release method and delay modeset teardown
If we unplug a udl device, the usb callback with deinit the mode_config
struct, however userspace will still have an open file descriptor and a
framebuffer on that device. When userspace closes the fd, we'll oops
because it'll try and look stuff up in the object idr which we've
destroyed.
This punts destroying the mode objects until release time instead.
Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter
<daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com> 
Link:
https://patchwork.freedesktop.org/patch/msgid/20190405031715.5959-2-airlied@gmail.com

ASoC: topology: Use the correct dobj to free enum control values and
texts
The control values and texts of the enum kcontrol associated with a
widget need to be freed when the widget is removed. However, both struct
snd_soc_dapm_widget and struct soc_enum contain a dobj member, which
resulted in a confusion. The existing code generates a null pointer
dereference by attempting to free the values and texts from the dobj
which belongs to the widget instead of the dobj belonging to the enum
kcontrol.
The suggested fix is to use the correct dobj member (se->dobj) of the
enum kcontrol.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> 
Signed-off-by: Mark Brown <broonie@kernel.org>

ASoC: stm32: fix sai driver name initialisation
This patch fixes the sai driver structure overwriting which results in a
cpu dai name equal NULL.
Fixes: 3e086ed ("ASoC: stm32: add SAI driver")
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Signed-off-by:
Mark Brown <broonie@kernel.org>

crypto: x86/poly1305 - fix overflow during partial reduction
The x86_64 implementation of Poly1305 produces the wrong result on some 
inputs because poly1305_4block_avx2() incorrectly assumes that when 
partially reducing the accumulator, the bits carried from limb 'd4' to 
limb 'h0' fit in a 32-bit integer.  This is true for poly1305-generic 
which processes only one block at a time.  However, it's not true for 
the AVX2 implementation, which processes 4 blocks at a time and 
therefore can produce intermediate limbs about 4x larger.
Fix it by making the relevant calculations use 64-bit arithmetic rather 
than 32-bit.  Note that most of the carries already used 64-bit 
arithmetic, but the d4 -> h0 carry was different for some reason.
To be safe I also made the same change to the corresponding SSE2 code, 
though that only operates on 1 or 2 blocks at a time.  I don't think 
it's really needed for poly1305_block_sse2(), but it doesn't hurt 
because it's already x86_64 code.  It *might* be needed for 
poly1305_2block_sse2(), but overflows aren't easy to reproduce there.
This bug was originally detected by my patches that improve testmgr to 
fuzz algorithms against their generic implementation.  But also add a 
test vector which reproduces it directly (in the AVX2 case).
Fixes: b1ccc8f4b631 ("crypto: poly1305 - Add a four block AVX2 variant
for x86_64") Fixes: c70f4abef07a ("crypto: poly1305 - Add a SSE2 SIMD
variant for x86_64") Cc: <stable@vger.kernel.org> # v4.3+ Cc: Martin
Willi <martin@strongswan.org> Cc: Jason A. Donenfeld <Jason@zx2c4.com> 
Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Martin
Willi <martin@strongswan.org> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au>

ASoC: core: conditionally increase module refcount on component open
Recently, for Intel platforms the "ignore_module_refcount" field was
introduced for the component driver. In order to avoid a deadlock
preventing the PCI modules from being removed even when the card was
idle, the refcounts were not incremented for the device driver module
during component probe.
However, this change introduced a nasty side effect: the device driver
module can be unloaded while a pcm stream is open.
This patch proposes to change the field to be renamed as
"module_get_upon_open". When this field is set, the module refcount
should be incremented on pcm open amd decremented upon pcm close. This
will enable modules to be removed when no PCM playback/capture happens
and prevent removal when the component is actually in use.
Also, align with the skylake component driver with the new name.
Fixes: b450b878('ASoC: core: don't increase component module refcount
                unconditionally' Signed-off-by: Ranjani Sridharan
<ranjani.sridharan@linux.intel.com> Acked-by: Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown
<broonie@kernel.org>

ASoC: pcm: update module refcount if module_get_upon_open is set
Setting the module_get_upon_open field for component driver prevents the
module refcount from being incremented during component probe(). This
could lead to the module being allowed to be unloaded when a pcm stream
is open. So, if this field is set, the module's refcount should be 
incremented during pcm open to prevent module removal when the component
is in use. And, the refcount should be decremented upon pcm close.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> 
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> 
Signed-off-by: Mark Brown <broonie@kernel.org>

drm/sun4i: tcon top: Fix NULL/invalid pointer dereference in
sun8i_tcon_top_un/bind
There are two problems here:
1. Not all clk_data->hws[] need to be initialized, depending on various
  configured quirks. This leads to NULL ptr deref in
  clk_hw_unregister_gate() in sun8i_tcon_top_unbind() 2. If there is
error when registering the clk_data->hws[],
  err_unregister_gates error path will try to unregister
  IS_ERR()=true (invalid) pointer.
For problem (1) I have this stack trace:
Unable to handle kernel NULL pointer dereference at virtual
 address 0000000000000008 Call trace:
clk_hw_unregister+0x8/0x18
clk_hw_unregister_gate+0x14/0x28
sun8i_tcon_top_unbind+0x2c/0x60
component_unbind.isra.4+0x2c/0x50
component_bind_all+0x1d4/0x230
sun4i_drv_bind+0xc4/0x1a0
try_to_bring_up_master+0x164/0x1c0
__component_add+0xa0/0x168
component_add+0x10/0x18
sun8i_dw_hdmi_probe+0x18/0x20
platform_drv_probe+0x3c/0x70
really_probe+0xcc/0x278
driver_probe_device+0x34/0xa8
Problem (2) was identified by head scratching.
Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Maxime
Ripard <maxime.ripard@bootlin.com> Link:
https://patchwork.freedesktop.org/patch/msgid/20190405233048.3823-1-megous@megous.com

cfg80211: add ratelimited variants of err and warn
wiphy_{err,warn}_ratelimited will be used by rt2x00
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>

mac80211_hwsim: calculate if_combination.max_interfaces
If we just set this to 2048, and have multiple limits you can select
from, the total number might run over and cause a warning in cfg80211.
This doesn't make sense, so we just calculate the total max_interfaces
now.
Reported-by: syzbot+8f91bd563bbff230d0ee@syzkaller.appspotmail.com 
Fixes: 99e3a44bac37 ("mac80211_hwsim: allow setting iftype support") 
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

mac80211: make ieee80211_schedule_txq schedule empty TXQs
Currently there is no way for the driver to signal to mac80211 that it
should schedule a TXQ even if there are no packets on the mac80211 part
of that queue. This is problematic if the driver has an internal retry
queue to deal with software A-MPDU retry.
This patch changes the behavior of ieee80211_schedule_txq to always
schedule the queue, as its only user (ath9k) seems to expect such
behavior already: it calls this function on tx status and on powersave
wakeup whenever its internal retry queue is not empty.
Also add an extra argument to ieee80211_return_txq to get the same
behavior.
This fixes an issue on ath9k where tx queues with packets to retry (and
no new packets in mac80211) would not get serviced.
Fixes: 89cea7493a346 ("ath9k: Switch to mac80211 TXQ scheduling and
airtime APIs") Signed-off-by: Felix Fietkau <nbd@nbd.name> Acked-by:
Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: Johannes Berg
<johannes.berg@intel.com>

powerpc/64s/radix: Fix radix segment exception handling
Commit 48e7b76957 ("powerpc/64s/hash: Convert SLB miss handlers to C") 
broke the radix-mode segment exception handler. In radix mode, this is 
exception is not an SLB miss, rather it signals that the EA is outside 
the range translated by any page table.
The commit lost the radix feature alternate code patch, which can cause
faults to some EAs to kernel BUG at arch/powerpc/mm/slb.c:639!
The original radix code would send faults to slb_miss_large_addr, which
would end up faulting due to slb_addr_limit being 0. This patch sends
radix directly to do_bad_slb_fault, which is a bit clearer.
Fixes: 48e7b7695745 ("powerpc/64s/hash: Convert SLB miss handlers to C") 
Cc: stable@vger.kernel.org # v4.20+ Reported-by: Anton Blanchard
<anton@samba.org> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> 
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> 
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

ALSA: hda - Add two more machines to the power_save_blacklist
Recently we set CONFIG_SND_HDA_POWER_SAVE_DEFAULT to 1 when configuring
the kernel, then two machines were reported to have noise after
installing the new kernel. Put them in the blacklist, the noise
disappears.
https://bugs.launchpad.net/bugs/1821663 Cc: <stable@vger.kernel.org> 
Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi
Iwai <tiwai@suse.de>

virtio_pci: fix a NULL pointer reference in vp_del_vqs
If the msix_affinity_masks is alloced failed, then we'll try to free
some resources in vp_free_vectors() that may access it directly.
We met the following stack in our production:
[   29.296767] BUG: unable to handle kernel NULL pointer dereference at 
(null)
[   29.311151] IP: [<ffffffffc04fe35a>] vp_free_vectors+0x6a/0x150
[virtio_pci]
[   29.324787] PGD 0
[   29.333224] Oops: 0000 [#1] SMP
[...]
[   29.425175] RIP: 0010:[<ffffffffc04fe35a>]  [<ffffffffc04fe35a>]
vp_free_vectors+0x6a/0x150 [virtio_pci]
[   29.441405] RSP: 0018:ffff9a55c2dcfa10  EFLAGS: 00010206
[   29.453491] RAX: 0000000000000000 RBX: ffff9a55c322c400 RCX:
0000000000000000
[   29.467488] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
ffff9a55c322c400
[   29.481461] RBP: ffff9a55c2dcfa20 R08: 0000000000000000 R09:
ffffc1b6806ff020
[   29.495427] R10: 0000000000000e95 R11: 0000000000aaaaaa R12:
0000000000000000
[   29.509414] R13: 0000000000010000 R14: ffff9a55bd2d9e98 R15:
ffff9a55c322c400
[   29.523407] FS:  00007fdcba69f8c0(0000) GS:ffff9a55c2840000(0000)
knlGS:0000000000000000
[   29.538472] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   29.551621] CR2: 0000000000000000 CR3: 000000003ce52000 CR4:
00000000003607a0
[   29.565886] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[   29.580055] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[   29.594122] Call Trace:
[   29.603446]  [<ffffffffc04fe8a2>] vp_request_msix_vectors+0xe2/0x260
[virtio_pci]
[   29.618017]  [<ffffffffc04fedc5>] vp_try_to_find_vqs+0x95/0x3b0
[virtio_pci]
[   29.632152]  [<ffffffffc04ff117>] vp_find_vqs+0x37/0xb0 [virtio_pci]
[   29.645582]  [<ffffffffc057bf63>] init_vq+0x153/0x260 [virtio_blk]
[   29.658831]  [<ffffffffc057c1e8>] virtblk_probe+0xe8/0x87f
[virtio_blk]
[...]
Cc: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Longpeng
<longpeng2@huawei.com> Signed-off-by: Michael S. Tsirkin
<mst@redhat.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com>

MAiNTAINERS: add Paolo, Stefan for virtio blk/scsi
Jason doesn't really have the time to review blk/scsi patches. Paolo and
Setfan agreed to help out.
Thanks guys!
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

block: don't use for-inside-for in bio_for_each_segment_all
Commit 6dc4f100c175 ("block: allow bio_for_each_segment_all() to iterate
over multi-page bvec") changes bio_for_each_segment_all() to use
for-inside-for.
This way breaks all bio_for_each_segment_all() call with error out 
branch via 'break', since now 'break' can only break from the inner 
loop.
Fixes this issue by implementing bio_for_each_segment_all() via single
'for' loop, and now the logic is very similar with normal bvec iterator.
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com> Cc: linux-btrfs@vger.kernel.org 
Cc: linux-fsdevel@vger.kernel.org Cc: Omar Sandoval <osandov@fb.com> 
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> 
Reported-and-Tested-by: Qu Wenruo <quwenruo.btrfs@gmx.com> Fixes:
6dc4f100c175 ("block: allow bio_for_each_segment_all() to iterate over
multi-page bvec") Reviewed-by: Christoph Hellwig <hch@lst.de> 
Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe
<axboe@kernel.dk>

drm/amd/display: Fix negative cursor pos programming (v2)
[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.
v2: add hunk that got dropped accidently when this patch was originally 
committed. (Alex) Fixes: 0921c41e1902831 ("drm/amd/display: Fix negative
cursor pos programming")
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/i915: Fix pipe_bpp readout for BXT/GLK DSI
The only bpc information in pipe registers for BXT/GLK DSI is the
PIPEMISC dither bpc. Let's try to use that to read out pipe_bpp on these
platforms. However, I'm not sure if this will be correctly populated by
the GOP since bspec suggests it's only needed if dithering is actually
enabled. If not I guess we'll have to go one step further and extract
pipe_bpp from the DSI pixel format when dithering is disabled.
Cc: Hans de Goede <hdegoede@redhat.com> Fixes: ca0b04db14a5
("drm/i915/dsi: Fix pipe_bpp for handling for 6 bpc pixel-formats") 
References: https://bugs.freedesktop.org/show_bug.cgi?id=109516 
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> 
Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula
<jani.nikula@intel.com> Link:
https://patchwork.freedesktop.org/patch/msgid/20190405141349.11950-1-ville.syrjala@linux.intel.com
(cherry picked from commit 499653501baf27d26e73cb5ce744869df3400509) 
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

ARC: memset: fix build with L1_CACHE_SHIFT != 6
In case of 'L1_CACHE_SHIFT != 6' we define dummy assembly macroses 
PREALLOC_INSTR and PREFETCHW_INSTR without arguments. However we pass
arguments to them in code which cause build errors. Fix that.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Cc:
<stable@vger.kernel.org>    [5.0] Signed-off-by: Vineet Gupta
<vgupta@synopsys.com>

arm64/ftrace: fix inadvertent BUG() in trampoline check
The ftrace trampoline code (which deals with modules loaded out of BL
range of the core kernel) uses plt_entries_equal() to check whether the
per-module trampoline equals a zero buffer, to decide whether the 
trampoline has already been initialized.
This triggers a BUG() in the opcode manipulation code, since we end up
checking the ADRP offset of a 0x0 opcode, which is not an ADRP 
instruction.
So instead, add a helper to check whether a PLT is initialized, and call
that from the frace code.
Cc: <stable@vger.kernel.org> # v5.0 Fixes: bdb85cd1d206 ("arm64/module:
switch to ADRP/ADD sequences for PLT entries") Acked-by: Mark Rutland
<mark.rutland@arm.com> Signed-off-by: Ard Biesheuvel
<ard.biesheuvel@linaro.org> Signed-off-by: Will Deacon
<will.deacon@arm.com>

RDMA/vmw_pvrdma: Fix memory leak on pvrdma_pci_remove
Make sure to free the DSR on pvrdma_pci_remove() to avoid the memory
leak.
Fixes: 29c8d9eba550 ("IB: Add vmw_pvrdma driver") Signed-off-by: Kamal
Heib <kamalheib1@gmail.com> Acked-by: Adit Ranadive <aditr@vmware.com> 
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>

RDMA/hns: Fix bug that caused srq creation to fail
Due to the incorrect use of the seg and obj information, the position of 
the mtt is calculated incorrectly, and the free space of the page is not 
enough to store the entire mtt, resulting in access to the next page.
This patch fixes this problem.
 Unable to handle kernel paging request at virtual address
ffff00006e3cd000
...
Call trace:
 hns_roce_write_mtt+0x154/0x2f0 [hns_roce]
 hns_roce_buf_write_mtt+0xa8/0xd8 [hns_roce]
 hns_roce_create_srq+0x74c/0x808 [hns_roce]
 ib_create_srq+0x28/0xc8
Fixes: 0203b14c4f32 ("RDMA/hns: Unify the calculation for hem index in
hip08") Signed-off-by: chenglang <chenglang@huawei.com> Signed-off-by:
Lijun Ou <oulijun@huawei.com> Signed-off-by: Jason Gunthorpe
<jgg@mellanox.com>

tools/testing/nvdimm: Retain security state after overwrite
Overwrite retains the security state after completion of operation.  Fix 
nfit_test to reflect this so that the kernel can test the behavior it is 
more likely to see in practice.
Fixes: 926f74802cb1 ("tools/testing/nvdimm: Add overwrite support for
nfit_test") Signed-off-by: Dave Jiang <dave.jiang@intel.com> 
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

RDMA/hns: Bugfix for SCC hem free
The method of hem free for SCC context is different from qp context.
In the current version, if free SCC hem during the execution of qp free, 
there may be smmu error as below:
 arm-smmu-v3 arm-smmu-v3.1.auto: event 0x10 received:
arm-smmu-v3 arm-smmu-v3.1.auto:  0x00007d0000000010
arm-smmu-v3 arm-smmu-v3.1.auto:  0x000012000000017c
arm-smmu-v3 arm-smmu-v3.1.auto:  0x00000000000009e0
arm-smmu-v3 arm-smmu-v3.1.auto:  0x0000000000000000
As SCC context is still used by hardware after qp free, we can solve
this problem by removing SCC hem free from hns_roce_qp_free.
Fixes: 6a157f7d1b14 ("RDMA/hns: Add SCC context allocation support for
hip08") Signed-off-by: Yangyang Li <liyangyang20@huawei.com> 
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>

nfsd: Don't release the callback slot unless it was actually held
If there are multiple callbacks queued, waiting for the callback slot
when the callback gets shut down, then they all currently end up acting
as if they hold the slot, and call nfsd4_cb_sequence_done() resulting in
interesting side-effects.
In addition, the 'retry_nowait' path in nfsd4_cb_sequence_done() causes
a loop back to nfsd4_cb_prepare() without first freeing the slot, which
causes a deadlock when nfsd41_cb_get_slot() gets called a second time.
This patch therefore adds a boolean to track whether or not the callback
did pick up the slot, so that it can do the right thing in these 2
cases.
Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust
<trond.myklebust@hammerspace.com> Signed-off-by: J. Bruce Fields
<bfields@redhat.com>

tools/io_uring: remove IOCQE_FLAG_CACHEHIT
This ended up not being included in the mainline version of io_uring, so
drop it from the test app as well.
Signed-off-by: Jens Axboe <axboe@kernel.dk>

io_uring: restrict IORING_SETUP_SQPOLL to root
This options spawns a kernel side thread that will poll for submissions
(and completions, if IORING_SETUP_IOPOLL is set). As this allows a user 
to potentially use more cycles outside of the normal hierarchy, restrict
the use of this feature to root.
Signed-off-by: Jens Axboe <axboe@kernel.dk>

arm64: backtrace: Don't bother trying to unwind the userspace stack
Calling dump_backtrace() with a pt_regs argument corresponding to 
userspace doesn't make any sense and our unwinder will simply print
"Call trace:" before unwinding the stack looking for user frames.
Rather than go through this song and dance, just return early if we're 
passed a user register state.
Cc: <stable@vger.kernel.org> Fixes: 1149aad10b1e ("arm64: Add
dump_backtrace() in show_regs") Reported-by: Kefeng Wang
<wangkefeng.wang@huawei.com> Signed-off-by: Will Deacon
<will.deacon@arm.com>

MAINTAINERS: ieee802154: update documentation file pattern
When moving the documentation for the ieee802154 subsystem from plain
text to rst the file pattern in the MAINTAINERS file got wrong. Updating
it here to fix scripts using this file.
Reported-by: Joe Perches <joe@perches.com> Signed-off-by: Stefan Schmidt
<stefan@datenfreihafen.org> Signed-off-by: David S. Miller
<davem@davemloft.net>

virtio: Honour 'may_reduce_num' in vring_create_virtqueue
vring_create_virtqueue() allows the caller to specify via the 
may_reduce_num parameter whether the vring code is allowed to allocate a
smaller ring than specified.
However, the split ring allocation code tries to allocate a smaller ring
on allocation failure regardless of what the caller specified. This may
cause trouble for e.g. virtio-pci in legacy mode, which does not support
ring resizing. (The packed ring code does not resize in any case.)
Let's fix this by bailing out immediately in the split ring code if the
requested size cannot be allocated and may_reduce_num has not been
specified.
While at it, fix a typo in the usage instructions.
Fixes: 2a2d1382fe9d ("virtio: Add improved queue allocation API") Cc:
stable@vger.kernel.org # v4.6+ Signed-off-by: Cornelia Huck
<cohuck@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> 
Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Jens
Freimann <jfreimann@redhat.com>

r8169: disable ASPM again
There's a significant number of reports that re-enabling ASPM causes 
different issues, ranging from decreased performance to system not 
booting at all. This affects only a minority of users, but the number of
affected users is big enough that we better switch off ASPM again.
This will hurt notebook users who are not affected by the issues, they 
may see decreased battery runtime w/o ASPM. With the PCI core folks is 
being discussed to add generic sysfs attributes to control ASPM. Once
this is in place brave enough users can re-enable ASPM on their system.
Fixes: a99790bf5c7f ("r8169: Reinstate ASPM Support") Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

tpm: turn on TPM on suspend for TPM 1.x
tpm_chip_start/stop() should be also called for TPM 1.x devices on 
suspend. Add that functionality back. Do not lock the chip because it is
unnecessary as there are no multiple threads using it when doing the
suspend.
Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of
tpm_transmit()") Reported-by: Paul Zimmerman <pauldzim@gmail.com> 
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> 
Tested-by: Domenico Andreoli <domenico.andreoli@linux.com> 
Signed-off-by: James Morris <james.morris@microsoft.com>

tpm: fix an invalid condition in tpm_common_poll
The poll condition should only check response_length, because reads
should only be issued if there is data to read. The response_read flag
only prevents double writes. The problem was that the write set the
response_read to false, enqued a tpm job, and returned. Then application
called poll which checked the response_read flag and returned EPOLLIN. 
Then the application called read, but got nothing. After all that the
async_work kicked in. Added also mutex_lock around the poll check to
prevent other possible race conditions.
Fixes: 9488585b21bef0df12 ("tpm: add support for partial reads") 
Reported-by: Mantas Mikulėnas <grawity@gmail.com> Tested-by: Mantas
Mikulėnas <grawity@gmail.com> Signed-off-by: Tadeusz Struk
<tadeusz.struk@intel.com> Reviewed-by: Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> Signed-off-by: James Morris
<james.morris@microsoft.com>

KEYS: trusted: allow trusted.ko to initialize w/o a TPM
Allow trusted.ko to initialize w/o a TPM. This commit also adds checks 
to the exported functions to fail when a TPM is not available.
Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip
structure...") Cc: James Morris <jmorris@namei.org> Reported-by: Dan
Williams <dan.j.williams@intel.com> Tested-by: Dan Williams
<dan.j.williams@intel.com> Signed-off-by: Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> Signed-off-by: James Morris
<james.morris@microsoft.com>

tpm: Fix the type of the return value in calc_tpm2_event_size()
calc_tpm2_event_size() has an invalid signature because it returns a
'size_t' where as its signature says that it returns 'int'.
Cc: <stable@vger.kernel.org> Fixes: 4d23cc323cdb ("tpm: add securityfs
support for TPM 2.0 firmware event log") Suggested-by: Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> Signed-off-by: Yue Haibing
<yuehaibing@huawei.com> Reviewed-by: Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> Signed-off-by: James Morris
<james.morris@microsoft.com>

KEYS: trusted: fix -Wvarags warning
Fixes the warning reported by Clang: security/keys/trusted.c:146:17:
warning: passing an object that undergoes default
     argument promotion to 'va_start' has undefined behavior [-Wvarargs]
       va_start(argp, h3);
                      ^ security/keys/trusted.c:126:37: note: parameter
of type 'unsigned char' is declared here unsigned char *h2, unsigned
char h3, ...)
                              ^ Specifically, it seems that both the C90
(4.8.1.1) and C11 (7.16.1.4) standards explicitly call this out as
undefined behavior:
The parameter parmN is the identifier of the rightmost parameter in the
variable parameter list in the function definition (the one just before
the ...). If the parameter parmN is declared with ... or with a type
that is not compatible with the type that results after application of
the default argument promotions, the behavior is undefined.
Link: https://github.com/ClangBuiltLinux/linux/issues/41 Link:
https://www.eskimo.com/~scs/cclass/int/sx11c.html Suggested-by: David
Laight <David.Laight@aculab.com> Suggested-by: Denis Kenzior
<denkenz@gmail.com> Suggested-by: James Bottomley
<jejb@linux.vnet.ibm.com> Suggested-by: Nathan Chancellor
<natechancellor@gmail.com> Signed-off-by: Nick Desaulniers
<ndesaulniers@google.com> Reviewed-by: Nathan Chancellor
<natechancellor@gmail.com> Tested-by: Nathan Chancellor
<natechancellor@gmail.com> Reviewed-by: Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> Signed-off-by: James Morris
<james.morris@microsoft.com>

selftests/tpm2: Extend tests to cover partial reads
Three new tests added: 1. Send get random cmd, read header in 1st read,
read the rest in second
  read - expect success 2. Send get random cmd, read only part of the
response, send another
  get random command, read the response - expect success 3. Send get
random cmd followed by another get random cmd, without
  reading the first response - expect the second cmd to fail with -EBUSY
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com> Reviewed-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Tested-by: Jarkko
Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko
Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: James Morris
<james.morris@microsoft.com>

selftests/tpm2: Open tpm dev in unbuffered mode
In order to have control over how many bytes are read or written the
device needs to be opened in unbuffered mode.
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com> Reviewed-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Tested-by: Jarkko
Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko
Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: James Morris
<james.morris@microsoft.com>

net: ip_gre: fix possible use-after-free in erspan_rcv
erspan tunnels run __iptunnel_pull_header on received skbs to remove gre
and erspan headers. This can determine a possible use-after-free 
accessing pkt_md pointer in erspan_rcv since the packet will be
'uncloned' running pskb_expand_head if it is a cloned gso skb (e.g if
the packet has been sent though a veth device). Fix it resetting pkt_md
pointer after
__iptunnel_pull_header
Fixes: 1d7e2ed22f8d ("net: erspan: refactor existing erspan code") 
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> 
Signed-off-by: David S. Miller <davem@davemloft.net>

net: ip6_gre: fix possible use-after-free in ip6erspan_rcv
erspan_v6 tunnels run __iptunnel_pull_header on received skbs to remove 
erspan header. This can determine a possible use-after-free accessing 
pkt_md pointer in ip6erspan_rcv since the packet will be 'uncloned' 
running pskb_expand_head if it is a cloned gso skb (e.g if the packet
has been sent though a veth device). Fix it resetting pkt_md pointer
after
__iptunnel_pull_header
Fixes: 1d7e2ed22f8d ("net: erspan: refactor existing erspan code") 
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> 
Signed-off-by: David S. Miller <davem@davemloft.net>

ethtool: avoid signed-unsigned comparison in ethtool_validate_speed()
When building C++ userspace code that includes ethtool.h with "-Werror
-Wall", g++ complains about signed-unsigned comparison in 
ethtool_validate_speed() due to definition of SPEED_UNKNOWN as -1.
Explicitly cast SPEED_UNKNOWN to __u32 to match type of 
ethtool_validate_speed() argument.
Signed-off-by: Michael Zhivich <mzhivich@akamai.com> Signed-off-by:
David S. Miller <davem@davemloft.net>

broadcom: tg3: fix use of SPEED_UNKNOWN ethtool constant
tg3 driver uses u16 to store SPEED_UKNOWN ethtool constant, which is
defined as -1, resulting in value truncation and thus incorrect test
results against SPEED_UNKNOWN.
For example, the following test will print "False":
	u16 speed = SPEED_UNKNOWN;
	if (speed == SPEED_UNKNOWN)
    printf("True");
else
    printf("False");
Change storage of speed to use u32 to avoid this issue.
Signed-off-by: Michael Zhivich <mzhivich@akamai.com> Reviewed-by: Andrew
Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller
<davem@davemloft.net>

qlogic: qlcnic: fix use of SPEED_UNKNOWN ethtool constant
qlcnic driver uses u16 to store SPEED_UKNOWN ethtool constant, which is
defined as -1, resulting in value truncation and thus incorrect test
results against SPEED_UNKNOWN.
For example, the following test will print "False":
    u16 speed = SPEED_UNKNOWN;
    if (speed == SPEED_UNKNOWN)
       printf("True");
   else
       printf("False");
Change storage of speed to use u32 to avoid this issue.
Signed-off-by: Michael Zhivich <mzhivich@akamai.com> Reviewed-by: Andrew
Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller
<davem@davemloft.net>

net: macb driver, check for SKBTX_HW_TSTAMP
Make sure SKBTX_HW_TSTAMP (i.e. SOF_TIMESTAMPING_TX_HARDWARE) has been 
enabled for this skb. It does fix the issue where normal socks that 
aren't expecting a timestamp will not wake up on select, but when a user
does want a SOF_TIMESTAMPING_TX_HARDWARE it does work.
Signed-off-by: Paul Thomas <pthomas8589@gmail.com> Signed-off-by: David
S. Miller <davem@davemloft.net>

bnxt_en: Improve RX consumer index validity check.
There is logic to check that the RX/TPA consumer index is the expected 
index to work around a hardware problem.  However, the potentially bad 
consumer index is first used to index into an array to reference an
entry. This can potentially crash if the bad consumer index is beyond
legal range.  Improve the logic to use the consumer index for
dereferencing after the validity check and log an error message.
Fixes: fa7e28127a5a ("bnxt_en: Add workaround to detect bad opaque in rx
completion (part 2)") Signed-off-by: Michael Chan
<michael.chan@broadcom.com> Signed-off-by: David S. Miller
<davem@davemloft.net>

bnxt_en: Reset device on RX buffer errors.
If the RX completion indicates RX buffers errors, the RX ring will be 
disabled by firmware and no packets will be received on that ring from 
that point on.  Recover by resetting the device.
Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") 
Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net>

scsi: csiostor: fix missing data copy in csio_scsi_err_handler()
If scsi cmd sglist is not suitable for DDP then csiostor driver uses 
preallocated buffers for DDP, because of this data copy is required from 
DDP buffer to scsi cmd sglist before calling ->scsi_done().
Signed-off-by: Varun Prakash <varun@chelsio.com> Signed-off-by: Martin
K. Petersen <martin.petersen@oracle.com>

drm/i915: Get power refs in encoder->get_power_domains()
Push getting the reference for the encoders' power domains into the 
encoder get_power_domains() hook instead of doing this from the caller. 
This way the encoder can store away the corresponding wakerefs.
This fixes the DSI encoder disabling, which didn't release these power
references it acquired during HW state readout.
Note that longtime ownership for the corresponding wakerefs can be thus 
acquired / released in two ways. Nevertheless there is always only one 
owner for them:
After HW readout (booting/system resume):
- encoder->get_power_domains() acquires
- encoder->disable*() releases
After a modeset (calling intel_atomic_commit()):
- encoder->enable*() acquires
- encoder->disable*() releases
* can be any of the encoder enable/disable hooks.
v2:
- Check that the DSI io_wakerefs are unset both during encoder HW
 readout and enabling. (Chris)
Fixes: 0e6e0be4c9523 ("drm/i915: Markup paired operations on display
power domains") Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak
<imre.deak@intel.com> Reviewed-by: Chris Wilson
<chris@chris-wilson.co.uk> Link:
https://patchwork.freedesktop.org/patch/msgid/20190407124655.31536-1-imre.deak@intel.com
(cherry picked from commit 3a52fb7e7953f0b13df8c05d0d74b56a66888f30) 
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/mediatek: fix possible object reference leak
The call to of_parse_phandle returns a node pointer with refcount 
incremented thus it must be explicitly decremented after the last usage.
Detected by coccinelle with the following warnings: 
drivers/gpu/drm/mediatek/mtk_hdmi.c:1521:2-8: ERROR: missing
of_node_put; acquired a node pointer with refcount incremented on line
1509, but without a corresponding object release within this function. 
drivers/gpu/drm/mediatek/mtk_hdmi.c:1524:1-7: ERROR: missing
of_node_put; acquired a node pointer with refcount incremented on line
1509, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Cc: CK Hu
<ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc:
David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc:
Matthias Brugger <matthias.bgg@gmail.com> Cc:
dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org 
Cc: linux-mediatek@lists.infradead.org Cc: linux-kernel@vger.kernel.org 
Signed-off-by: CK Hu <ck.hu@mediatek.com>

ACPICA: Namespace: remove address node from global list after method
termination
ACPICA commit b233720031a480abd438f2e9c643080929d144c3
ASL operation_regions declare a range of addresses that it uses. In a 
perfect world, the range of addresses should be used exclusively by the
AML interpreter. The OS can use this information to decide which drivers
to load so that the AML interpreter and device drivers use different
regions of memory.
During table load, the address information is added to a global address
range list. Each node in this list contains an address range as well as
a namespace node of the operation_region. This list is deleted at ACPI
shutdown.
Unfortunately, ASL operation_regions can be declared inside of control 
methods. Although this is not recommended, modern firmware contains such
code. New module level code changes unintentionally removed the 
functionality of adding and removing nodes to the global address range
list.
A few months ago, support for adding addresses has been re- implemented.
However, the removal of the address range list was missed and resulted
in some systems to crash due to the address list containing bogus
namespace nodes from operation_regions declared in control methods. In
order to fix the crash, this change removes dynamic operation_regions
after control method termination.
Link: https://github.com/acpica/acpica/commit/b2337200 Link:
https://bugzilla.kernel.org/show_bug.cgi?id=202475 Fixes: 4abb951b73ff
("ACPICA: AML interpreter: add region addresses in global list during
initialization") Reported-by: Michael J Gruber <mjg@fedoraproject.org> 
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by:
Bob Moore <robert.moore@intel.com> Cc: 4.20+ <stable@vger.kernel.org> #
4.20+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

drm/mediatek: fix the rate and divder of hdmi phy for MT2701
Due to a clerical error,there is one zero less for 12800000. Fix it for
128000000 Fixes: 0fc721b2968e ("drm/mediatek: add hdmi driver for MT2701
and MT7623")
Signed-off-by: Wangyan Wang <wangyan.wang@mediatek.com> Signed-off-by:
CK Hu <ck.hu@mediatek.com>

drm/mediatek: make implementation of recalc_rate() for MT2701 hdmi phy
Recalculate the rate of this clock, by querying hardware to make
implementation of recalc_rate() to match the definition.
Signed-off-by: Wangyan Wang <wangyan.wang@mediatek.com> Signed-off-by:
CK Hu <ck.hu@mediatek.com>

drm/mediatek: remove flag CLK_SET_RATE_PARENT for MT2701 hdmi phy
This is the first step to make MT2701 hdmi stable. The parent rate of
hdmi phy had set by DPI driver. We should not set or change the parent
rate of MT2701 hdmi phy, as a result we should remove the flags of
"CLK_SET_RATE_PARENT" from the clock of MT2701 hdmi phy.
Signed-off-by: Wangyan Wang <wangyan.wang@mediatek.com> Signed-off-by:
CK Hu <ck.hu@mediatek.com>

drm/mediatek: using new factor for tvdpll for MT2701 hdmi phy
This is the second step to make MT2701 HDMI stable. The factor depends
on the divider of DPI in MT2701, therefore, we should fix this factor to
the right and new one. Test: search ok
Signed-off-by: Wangyan Wang <wangyan.wang@mediatek.com> Signed-off-by:
CK Hu <ck.hu@mediatek.com>

drm/mediatek: no change parent rate in round_rate() for MT2701 hdmi phy
This is the third step to make MT2701 HDMI stable. We should not change
the rate of parent for hdmi phy when doing round_rate for this clock.
The parent clock of hdmi phy must be the same as it. We change it when
doing set_rate only.
Signed-off-by: Wangyan Wang <wangyan.wang@mediatek.com> Signed-off-by:
CK Hu <ck.hu@mediatek.com>

mac80211: Honor SW_CRYPTO_CONTROL for unicast keys in AP VLAN mode
Restore SW_CRYPTO_CONTROL operation on AP_VLAN interfaces for unicast 
keys, the original override was intended to be done for group keys as 
those are treated specially by mac80211 and would always have been 
rejected.
Now the situation is that AP_VLAN support must be enabled by the driver 
if it can support it (meaning it can support software crypto GTK TX).
Thus, also simplify the code - if we get here with AP_VLAN and non- 
pairwise key, software crypto must be used (driver doesn't know about 
the interface) and can be used (driver must've advertised AP_VLAN if it
also uses SW_CRYPTO_CONTROL).
Fixes: db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on crypto
controlled devices") Signed-off-by: Alexander Wetzel
<alexander@wetzel-home.de>
[rewrite commit message] Signed-off-by: Johannes Berg
<johannes.berg@intel.com>