Re: [PATCH] iomap: hide iomap_sector with CONFIG_BLOCK=n

[Christoph Hellwig]

On Fri, Jul 19, 2019 at 11:19:15AM +0900, Masahiro Yamada wrote:
> I started to think
> compiling all headers is more painful than useful.
> 
> 
> MW is closing, so I am thinking of disabling it for now
> to take time to re-think.

For now this seems like the best idea.  In the long run maybe we can
limit the tests to certain configs, e.g.


headers-$(CONFIG_IOMAP) += iomap.h

in include/linux/Kbuild

and base it off that?

Re: [PATCH v4 12/24] PM / devfreq: tegra30: Inline all one-line functions

[Chanwoo Choi]

On 19. 7. 19. 오전 11:14, Dmitry Osipenko wrote:
> В Fri, 19 Jul 2019 10:27:16 +0900
> Chanwoo Choi  пишет:
> 
>> On 19. 7. 19. 오전 10:24, Chanwoo Choi wrote:
>>> On 19. 7. 19. 오전 10:22, Dmitry Osipenko wrote:  
 В Thu, 18 Jul 2019 18:09:05 +0900
 Chanwoo Choi  пишет:
  
> On 19. 7. 16. 오후 10:35, Dmitry Osipenko wrote:  
>> 16.07.2019 15:26, Chanwoo Choi пишет:
>>> Hi Dmitry,
>>>
>>> I'm not sure that it is necessary.
>>> As I knew, usally, the 'inline' is used on header file
>>> to define the empty functions.
>>>
>>> Do we have to change it with 'inline' keyword?
>>
>> The 'inline' attribute tells compiler that instead of jumping
>> into the function, it should take the function's code and
>> replace the function's invocation with that code. This is done
>> in order to help compiler optimize code properly, please see
>> [1]. There is absolutely no need to create a function call into
>> a function that consists of a single instruction.
>>
>> [1] https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Inline.html
>> 
>
> If you want to add 'inline' keyword, I recommend that 
> you better to remove the modified function in this patch
> and then just call the 'write_relaxed or read_relaxed' function
> directly. It is same result when using inline keyword.  

 That could be done, but it makes code less readable.

 See the difference:

 device_writel(dev, ACTMON_INTR_STATUS_CLEAR,
 ACTMON_DEV_INTR_STATUS);

 writel_relaxed(ACTMON_INTR_STATUS_CLEAR,
   dev->regs + ACTMON_DEV_INTR_STATUS);  
>>>
>>> No problem if you add the detailed comment and you want to use
>>> the 'inline' keyword.  
>>
>> Basically, I think that 'inline' keyword is not necessary.
> 
> Sure, but I'm finding that it's always nicer to explicitly inline a very
> simple functions because compiler may not do it properly itself in some
> cases.
> 
>> But if you want to use 'inline' keyword, I recommend
>> that call the 'write_relaxed or read_relaxed' function directly
>> with detailed description. 
> 
> Could you please reword this sentence? Not sure that I'm understanding
> it correctly.
> 

If you want to used 'inline' keyword,
Instead, I recommend that remove 'actmon_readl/writel' wrapper functions
and then you calls 'write_relaxed or read_relaxed' function directly
with detailed description.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH] mm/Kconfig: additional help text for HMM_MIRROR option

[Christoph Hellwig]

On Thu, Jul 18, 2019 at 06:32:53PM -0700, john.hubb...@gmail.com wrote:
> +   HMM_MIRROR provides a way to mirror ranges of the CPU page tables
> +   of a process into a device page table. Here, mirror means "keep
> +   synchronized". Prerequisites: the device must provide the ability
> +   to write-protect its page tables (at PAGE_SIZE granularity), and
> +   must be able to recover from the resulting potential page faults.
> +
> +   Select HMM_MIRROR if you have hardware that meets the above
> +   description. An early, partial list of such hardware is:
> +   an NVIDIA GPU >= Pascal, Mellanox IB >= mlx5, or an AMD GPU.

Nevermind that the Nvidia support is stagaging and looks rather broken,
there is no Mellanox user of this either at this point.

But either way this has no business in a common kconfig help.  Just
drop the fine grained details and leave it to the overview.

Re: [RFC PATCH v3 00/16] Core scheduling v3

[Aaron Lu]

On Thu, Jul 18, 2019 at 04:27:19PM -0700, Tim Chen wrote:
> 
> 
> On 7/18/19 3:07 AM, Aaron Lu wrote:
> > On Wed, Jun 19, 2019 at 02:33:02PM -0400, Julien Desfossez wrote:
> 
> > 
> > With the below patch on top of v3 that makes use of util_avg to decide
> > which task win, I can do all 8 steps and the final scores of the 2
> > workloads are: 1796191 and 2199586. The score number are not close,
> > suggesting some unfairness, but I can finish the test now...
> 
> Aaron,
> 
> Do you still see high variance in terms of workload throughput that
> was a problem with the previous version?

Any suggestion how to measure this?
It's not clear how Aubrey did his test, will need to take a look at
sysbench.

> >
> >  
> >  }
> > +
> > +bool cfs_prio_less(struct task_struct *a, struct task_struct *b)
> > +{
> > +   struct sched_entity *sea = >se;
> > +   struct sched_entity *seb = >se;
> > +   bool samecore = task_cpu(a) == task_cpu(b);
> 
> 
> Probably "samecpu" instead of "samecore" will be more accurate.
> I think task_cpu(a) and task_cpu(b)
> can be different, but still belong to the same cpu core.

Right, definitely, guess I'm brain damaged.

> 
> > +   struct task_struct *p;
> > +   s64 delta;
> > +
> > +   if (samecore) {
> > +   /* vruntime is per cfs_rq */
> > +   while (!is_same_group(sea, seb)) {
> > +   int sea_depth = sea->depth;
> > +   int seb_depth = seb->depth;
> > +
> > +   if (sea_depth >= seb_depth)
> 
> Should this be strictly ">" instead of ">=" ?

Same depth doesn't necessarily mean same group while the purpose here is
to make sure they are in the same cfs_rq. When they are of the same
depth but in different cfs_rqs, we will continue to go up till we reach
rq->cfs.

> 
> > +   sea = parent_entity(sea);
> > +   if (sea_depth <= seb_depth)
> 
> Should use "<" ?

Ditto here.
When they are of the same depth but no in the same cfs_rq, both se will
move up.

> > +   seb = parent_entity(seb);
> > +   }
> > +
> > +   delta = (s64)(sea->vruntime - seb->vruntime);
> > +   }
> > +

Thanks.

KASAN: slab-out-of-bounds Write in check_noncircular

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:22051d9c Merge tag 'platform-drivers-x86-v5.3-2' of git://..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14090a3460
kernel config:  https://syzkaller.appspot.com/x/.config?x=135cb826ac59d7fc
dashboard link: https://syzkaller.appspot.com/bug?extid=e2416b38b581ad58bc1e
compiler:   clang version 9.0.0 (/home/glider/llvm/clang  
80fee25776c2fb61e74c1ecb1a523375c2500b69)

syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1397afe060

The bug was bisected to:

commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend 
Date:   Sat Jun 30 13:17:47 2018 +

bpf: sockhash fix omitted bucket lock in sock_close

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=131928f460
final crash:https://syzkaller.appspot.com/x/report.txt?x=109928f460
console output: https://syzkaller.appspot.com/x/log.txt?x=171928f460

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e2416b38b581ad58b...@syzkaller.appspotmail.com
Fixes: e9db4ef6bf4c ("bpf: sockhash fix omitted bucket lock in sock_close")

==
BUG: KASAN: slab-out-of-bounds in check_noncircular+0x91/0x560  
/kernel/locking/lockdep.c:1722

Write of size 56 at addr 88809752a1a0 by task syz-executor.2/9504

CPU: 1 PID: 9504 Comm: syz-executor.2 Not tainted 5.2.0+ #34
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:

Allocated by task 2258096832:
[ cut here ]
kernel BUG at mm/slab.c:4179!
invalid opcode:  [#1] PREEMPT SMP KASAN
CPU: 1 PID: 9504 Comm: syz-executor.2 Not tainted 5.2.0+ #34
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:__check_heap_object+0xcb/0xd0 /mm/slab.c:4203
Code: 4c 89 d1 4d 89 c8 e8 34 a6 07 00 5b 41 5e 5d c3 49 8b 73 58 41 0f b6  
d0 48 c7 c7 0f eb 7e 88 4c 89 d1 4d 89 c8 e8 d5 a6 07 00 <0f> 0b 0f 1f 00  
55 48 89 e5 53 48 83 ff 10 0f 84 90 00 00 00 48 85

RSP: 0018:8880975297a0 EFLAGS: 00010046
RAX: 0fc5 RBX: 11e0 RCX: 000c
RDX: 000c RSI: 0002 RDI: 0001
RBP: 8880975297b0 R08:  R09: f940004ba941
R10: 8880975298a0 R11: 8880aa5918c0 R12: 8880975298a2
R13: 01fffc010200 R14: 8880975286c0 R15: 8880975298a0
FS:  56816940() GS:8880aeb0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 8aff8f88 CR3: 8586d000 CR4: 001406e0
Call Trace:
Modules linked in:
---[ end trace 35842f070e95906d ]---
RIP: 0010:__check_heap_object+0xcb/0xd0 /mm/slab.c:4203
Code: 4c 89 d1 4d 89 c8 e8 34 a6 07 00 5b 41 5e 5d c3 49 8b 73 58 41 0f b6  
d0 48 c7 c7 0f eb 7e 88 4c 89 d1 4d 89 c8 e8 d5 a6 07 00 <0f> 0b 0f 1f 00  
55 48 89 e5 53 48 83 ff 10 0f 84 90 00 00 00 48 85

RSP: 0018:8880975297a0 EFLAGS: 00010046
RAX: 0fc5 RBX: 11e0 RCX: 000c
RDX: 000c RSI: 0002 RDI: 0001
RBP: 8880975297b0 R08:  R09: f940004ba941
R10: 8880975298a0 R11: 8880aa5918c0 R12: 8880975298a2
R13: 01fffc010200 R14: 8880975286c0 R15: 8880975298a0
FS:  56816940() GS:8880aeb0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 8aff8f88 CR3: 8586d000 CR4: 001406e0


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

KASAN: use-after-free Write in tlb_finish_mmu

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:22051d9c Merge tag 'platform-drivers-x86-v5.3-2' of git://..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=130c6ad060
kernel config:  https://syzkaller.appspot.com/x/.config?x=d831b9cbe82e79e4
dashboard link: https://syzkaller.appspot.com/bug?extid=8267e9af795434ffadad
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
userspace arch: i386
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=10d5878460

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+8267e9af795434ffa...@syzkaller.appspotmail.com

==
BUG: KASAN: use-after-free in atomic_dec  
/./include/asm-generic/atomic-instrumented.h:329 [inline]
BUG: KASAN: use-after-free in dec_tlb_flush_pending  
/./include/linux/mm_types.h:598 [inline]
BUG: KASAN: use-after-free in tlb_finish_mmu+0x136/0x3b0  
/mm/mmu_gather.c:279

Write of size 4 at addr 8880912433f4 by task syz-executor.0/9266

CPU: 1 PID: 9266 Comm: syz-executor.0 Not tainted 5.2.0+ #61
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack /lib/dump_stack.c:77 [inline]
 dump_stack+0x172/0x1f0 /lib/dump_stack.c:113
 print_address_description.cold+0xd4/0x306 /mm/kasan/report.c:351
 __kasan_report.cold+0x1b/0x36 /mm/kasan/report.c:482
 kasan_report+0x12/0x17 /mm/kasan/common.c:612
 check_memory_region_inline /mm/kasan/generic.c:185 [inline]
 check_memory_region+0x134/0x1a0 /mm/kasan/generic.c:192
 __kasan_check_write+0x14/0x20 /mm/kasan/common.c:98
 atomic_dec /./include/asm-generic/atomic-instrumented.h:329 [inline]
 dec_tlb_flush_pending /./include/linux/mm_types.h:598 [inline]
 tlb_finish_mmu+0x136/0x3b0 /mm/mmu_gather.c:279
 exit_mmap+0x2da/0x530 /mm/mmap.c:3147
 __mmput /kernel/fork.c:1064 [inline]
 mmput+0x179/0x4d0 /kernel/fork.c:1085
 exit_mm /kernel/exit.c:547 [inline]
 do_exit+0x84e/0x2ea0 /kernel/exit.c:864
 do_group_exit+0x135/0x360 /kernel/exit.c:981
 get_signal+0x47c/0x2500 /kernel/signal.c:2728
 do_signal+0x87/0x1670 /arch/x86/kernel/signal.c:815
 exit_to_usermode_loop+0x286/0x380 /arch/x86/entry/common.c:159
 prepare_exit_to_usermode /arch/x86/entry/common.c:194 [inline]
 syscall_return_slowpath /arch/x86/entry/common.c:274 [inline]
 do_syscall_32_irqs_on /arch/x86/entry/common.c:347 [inline]
 do_fast_syscall_32+0xb87/0xdb3 /arch/x86/entry/common.c:403
 entry_SYSENTER_compat+0x70/0x7f /arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7f139c9
Code: d3 83 c4 10 5b 5e 5d c3 ba 80 96 98 00 eb a9 8b 04 24 c3 8b 34 24 c3  
8b 3c 24 c3 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90  
90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90

RSP: 002b:f7eee0cc EFLAGS: 0296 ORIG_RAX: 0036
RAX:  RBX: 0003 RCX: 4028af11
RDX: 200023c0 RSI:  RDI: 
RBP:  R08:  R09: 
R10:  R11:  R12: 
R13:  R14:  R15: 

Allocated by task 9107:
 save_stack+0x23/0x90 /mm/kasan/common.c:69
 set_track /mm/kasan/common.c:77 [inline]
 __kasan_kmalloc /mm/kasan/common.c:487 [inline]
 __kasan_kmalloc.constprop.0+0xcf/0xe0 /mm/kasan/common.c:460
 kasan_slab_alloc+0xf/0x20 /mm/kasan/common.c:495
 slab_post_alloc_hook /mm/slab.h:520 [inline]
 slab_alloc /mm/slab.c:3319 [inline]
 kmem_cache_alloc+0x121/0x710 /mm/slab.c:3483
 dup_mm+0x8a/0x1430 /kernel/fork.c:1337
 copy_mm /kernel/fork.c:1402 [inline]
 copy_process+0x28b7/0x6b00 /kernel/fork.c:2017
 _do_fork+0x146/0xfa0 /kernel/fork.c:2369
 __do_compat_sys_x86_clone /arch/x86/ia32/sys_ia32.c:253 [inline]
 __se_compat_sys_x86_clone /arch/x86/ia32/sys_ia32.c:236 [inline]
 __ia32_compat_sys_x86_clone+0x188/0x260 /arch/x86/ia32/sys_ia32.c:236
 do_syscall_32_irqs_on /arch/x86/entry/common.c:332 [inline]
 do_fast_syscall_32+0x27b/0xdb3 /arch/x86/entry/common.c:403
 entry_SYSENTER_compat+0x70/0x7f /arch/x86/entry/entry_64_compat.S:139

Freed by task 9107:
 save_stack+0x23/0x90 /mm/kasan/common.c:69
 set_track /mm/kasan/common.c:77 [inline]
 __kasan_slab_free+0x102/0x150 /mm/kasan/common.c:449
 kasan_slab_free+0xe/0x10 /mm/kasan/common.c:457
 __cache_free /mm/slab.c:3425 [inline]
 kmem_cache_free+0x86/0x320 /mm/slab.c:3693
 __mmdrop+0x238/0x320 /kernel/fork.c:683
 mmdrop /./include/linux/sched/mm.h:49 [inline]
 finish_task_switch+0x457/0x720 /kernel/sched/core.c:3123
 context_switch /kernel/sched/core.c:3257 [inline]
 __schedule+0x75d/0x1580 /kernel/sched/core.c:3880
 schedule+0xa8/0x270 /kernel/sched/core.c:3944
 freezable_schedule /./include/linux/freezer.h:172 [inline]
 do_nanosleep+0x201/0x6a0 /kernel/time/hrtimer.c:1679
 hrtimer_nanosleep+0x2a6/0x570 /kernel/time/hrtimer.c:1733
 __do_sys_nanosleep_time32 /kernel/time/hrtimer.c:1787 

KASAN: use-after-free Read in finish_task_switch (2)

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:22051d9c Merge tag 'platform-drivers-x86-v5.3-2' of git://..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12dab5a460
kernel config:  https://syzkaller.appspot.com/x/.config?x=135cb826ac59d7fc
dashboard link: https://syzkaller.appspot.com/bug?extid=7f067c796eee2acbc57a
compiler:   clang version 9.0.0 (/home/glider/llvm/clang  
80fee25776c2fb61e74c1ecb1a523375c2500b69)

syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=12c1898fa0

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+7f067c796eee2acbc...@syzkaller.appspotmail.com

IPv6: ADDRCONF(NETDEV_CHANGE): hsr0: link becomes ready
8021q: adding VLAN 0 to HW filter on device batadv0
==
BUG: KASAN: use-after-free in atomic_read  
/./include/asm-generic/atomic-instrumented.h:26 [inline]
BUG: KASAN: use-after-free in membarrier_mm_sync_core_before_usermode  
/./include/linux/sched/mm.h:365 [inline]
BUG: KASAN: use-after-free in finish_task_switch+0x331/0x550  
/kernel/sched/core.c:3122

Read of size 4 at addr 88808e6c18f8 by task syz-executor.0/8218

CPU: 0 PID: 8218 Comm: syz-executor.0 Not tainted 5.2.0+ #34
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack /lib/dump_stack.c:77 [inline]
 dump_stack+0x1d8/0x2f8 /lib/dump_stack.c:113
 print_address_description+0x75/0x5b0 /mm/kasan/report.c:351
 __kasan_report+0x14b/0x1c0 /mm/kasan/report.c:482
 kasan_report+0x26/0x50 /mm/kasan/common.c:612
 check_memory_region_inline /mm/kasan/generic.c:182 [inline]
 check_memory_region+0x2cf/0x2e0 /mm/kasan/generic.c:192
 __kasan_check_read+0x11/0x20 /mm/kasan/common.c:92
 atomic_read /./include/asm-generic/atomic-instrumented.h:26 [inline]
 membarrier_mm_sync_core_before_usermode /./include/linux/sched/mm.h:365  
[inline]

 finish_task_switch+0x331/0x550 /kernel/sched/core.c:3122
 context_switch /kernel/sched/core.c:3257 [inline]
 __schedule+0x8be/0xcd0 /kernel/sched/core.c:3880
 schedule+0x131/0x1e0 /kernel/sched/core.c:3944
 freezable_schedule /./include/linux/freezer.h:172 [inline]
 do_nanosleep+0x295/0x7d0 /kernel/time/hrtimer.c:1679
 hrtimer_nanosleep+0x3c2/0x5d0 /kernel/time/hrtimer.c:1733
 __do_sys_nanosleep /kernel/time/hrtimer.c:1767 [inline]
 __se_sys_nanosleep /kernel/time/hrtimer.c:1754 [inline]
 __x64_sys_nanosleep+0x1ef/0x230 /kernel/time/hrtimer.c:1754
 do_syscall_64+0xfe/0x140 /arch/x86/entry/common.c:296
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457cc0
Code: c0 5b 5d c3 66 0f 1f 44 00 00 8b 04 24 48 83 c4 18 5b 5d c3 66 0f 1f  
44 00 00 83 3d 91 ea 61 00 00 75 14 b8 23 00 00 00 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 24 d3 fb ff c3 48 83 ec 08 e8 ea 46 00 00

RSP: 002b:7ffc89355738 EFLAGS: 0246 ORIG_RAX: 0023
RAX: ffda RBX: ea43 RCX: 00457cc0
RDX:  RSI:  RDI: 7ffc89355740
RBP: 000b R08: 0001 R09: 559bf940
R10:  R11: 0246 R12: 0007
R13: 7ffc89355790 R14: e9c0 R15: 7ffc893557a0

Allocated by task 8218:
 save_stack /mm/kasan/common.c:69 [inline]
 set_track /mm/kasan/common.c:77 [inline]
 __kasan_kmalloc+0x11c/0x1b0 /mm/kasan/common.c:487
 kasan_slab_alloc+0xf/0x20 /mm/kasan/common.c:495
 slab_post_alloc_hook /mm/slab.h:520 [inline]
 slab_alloc /mm/slab.c:3319 [inline]
 kmem_cache_alloc+0x1f5/0x2e0 /mm/slab.c:3483
 dup_mm+0x29/0x340 /kernel/fork.c:1337
 copy_mm /kernel/fork.c:1402 [inline]
 copy_process+0x25ef/0x5bc0 /kernel/fork.c:2017
 _do_fork+0x179/0x630 /kernel/fork.c:2369
 __do_sys_clone /kernel/fork.c:2524 [inline]
 __se_sys_clone /kernel/fork.c:2505 [inline]
 __x64_sys_clone+0x247/0x2b0 /kernel/fork.c:2505
 do_syscall_64+0xfe/0x140 /arch/x86/entry/common.c:296
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 8244:
 save_stack /mm/kasan/common.c:69 [inline]
 set_track /mm/kasan/common.c:77 [inline]
 __kasan_slab_free+0x12a/0x1e0 /mm/kasan/common.c:449
 kasan_slab_free+0xe/0x10 /mm/kasan/common.c:457
 __cache_free /mm/slab.c:3425 [inline]
 kmem_cache_free+0x81/0xf0 /mm/slab.c:3693
 __mmdrop+0x2c4/0x3b0 /kernel/fork.c:683
 mmdrop /./include/linux/sched/mm.h:49 [inline]
 __mmput+0x373/0x3a0 /kernel/fork.c:1074
 mmput+0x5d/0x70 /kernel/fork.c:1085
 exit_mm+0x585/0x640 /kernel/exit.c:547
 do_exit+0x5d0/0x2310 /kernel/exit.c:864
 do_group_exit+0x15c/0x2b0 /kernel/exit.c:981
 get_signal+0x51c/0x1dd0 /kernel/signal.c:2728
 do_signal+0x7b/0x720 /arch/x86/kernel/signal.c:815
 exit_to_usermode_loop /arch/x86/entry/common.c:159 [inline]
 prepare_exit_to_usermode+0x303/0x580 /arch/x86/entry/common.c:194
 syscall_return_slowpath+0x113/0x4a0 /arch/x86/entry/common.c:274
 do_syscall_64+0x126/0x140 /arch/x86/entry/common.c:299
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

The buggy 

Re: [PATCHv4 1/2] media: docs-rst: Document memory-to-memory video decoder interface

[Tomasz Figa]

On Wed, Jul 17, 2019 at 9:18 PM Nicolas Dufresne  wrote:
>
> Hello,
>
> there is one little detail/proposal, see inline .
>
> Le lundi 03 juin 2019 à 13:28 +0200, Hans Verkuil a écrit :
> > From: Tomasz Figa 
> >
> > Due to complexity of the video decoding process, the V4L2 drivers of
> > stateful decoder hardware require specific sequences of V4L2 API calls
> > to be followed. These include capability enumeration, initialization,
> > decoding, seek, pause, dynamic resolution change, drain and end of
> > stream.
> >
> > Specifics of the above have been discussed during Media Workshops at
> > LinuxCon Europe 2012 in Barcelona and then later Embedded Linux
> > Conference Europe 2014 in Düsseldorf. The de facto Codec API that
> > originated at those events was later implemented by the drivers we already
> > have merged in mainline, such as s5p-mfc or coda.
> >
> > The only thing missing was the real specification included as a part of
> > Linux Media documentation. Fix it now and document the decoder part of
> > the Codec API.
> >
> > Signed-off-by: Tomasz Figa 
> > Signed-off-by: Hans Verkuil 
> > ---
> >  Documentation/media/uapi/v4l/dev-decoder.rst  | 1084 +
> >  Documentation/media/uapi/v4l/dev-mem2mem.rst  |8 +-
> >  Documentation/media/uapi/v4l/pixfmt-v4l2.rst  |5 +
> >  Documentation/media/uapi/v4l/v4l2.rst |   10 +-
> >  .../media/uapi/v4l/vidioc-decoder-cmd.rst |   41 +-
> >  5 files changed, 1132 insertions(+), 16 deletions(-)
> >  create mode 100644 Documentation/media/uapi/v4l/dev-decoder.rst
> >
> > diff --git a/Documentation/media/uapi/v4l/dev-decoder.rst 
> > b/Documentation/media/uapi/v4l/dev-decoder.rst
> > new file mode 100644
> > index ..b106f2d97c48
> > --- /dev/null
> > +++ b/Documentation/media/uapi/v4l/dev-decoder.rst
> > @@ -0,0 +1,1084 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
> > +.. _decoder:
> > +
> > +*
> > +Memory-to-memory Stateful Video Decoder Interface
> > +*
> > +
> > +A stateful video decoder takes complete chunks of the bitstream (e.g. 
> > Annex-B
> > +H.264/HEVC stream, raw VP8/9 stream) and decodes them into raw video 
> > frames in
> > +display order. The decoder is expected not to require any additional 
> > information
> > +from the client to process these buffers.
> > +
> > +Performing software parsing, processing etc. of the stream in the driver in
> > +order to support this interface is strongly discouraged. In case such
> > +operations are needed, use of the Stateless Video Decoder Interface (in
> > +development) is strongly advised.
> > +
> > +Conventions and notation used in this document
> > +==
> > +
> > +1. The general V4L2 API rules apply if not specified in this document
> > +   otherwise.
> > +
> > +2. The meaning of words "must", "may", "should", etc. is as per `RFC
> > +   2119 `_.
> > +
> > +3. All steps not marked "optional" are required.
> > +
> > +4. :c:func:`VIDIOC_G_EXT_CTRLS` and :c:func:`VIDIOC_S_EXT_CTRLS` may be 
> > used
> > +   interchangeably with :c:func:`VIDIOC_G_CTRL` and 
> > :c:func:`VIDIOC_S_CTRL`,
> > +   unless specified otherwise.
> > +
> > +5. Single-planar API (see :ref:`planar-apis`) and applicable structures 
> > may be
> > +   used interchangeably with multi-planar API, unless specified otherwise,
> > +   depending on decoder capabilities and following the general V4L2 
> > guidelines.
> > +
> > +6. i = [a..b]: sequence of integers from a to b, inclusive, i.e. i =
> > +   [0..2]: i = 0, 1, 2.
> > +
> > +7. Given an ``OUTPUT`` buffer A, then A’ represents a buffer on the 
> > ``CAPTURE``
> > +   queue containing data that resulted from processing buffer A.
> > +
> > +.. _decoder-glossary:
> > +
> > +Glossary
> > +
> > +
> > +CAPTURE
> > +   the destination buffer queue; for decoders, the queue of buffers 
> > containing
> > +   decoded frames; for encoders, the queue of buffers containing an encoded
> > +   bitstream; ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` or
> > +   ``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE``; data is captured from the 
> > hardware
> > +   into ``CAPTURE`` buffers.
> > +
> > +client
> > +   the application communicating with the decoder or encoder implementing
> > +   this interface.
> > +
> > +coded format
> > +   encoded/compressed video bitstream format (e.g. H.264, VP8, etc.); see
> > +   also: raw format.
> > +
> > +coded height
> > +   height for given coded resolution.
> > +
> > +coded resolution
> > +   stream resolution in pixels aligned to codec and hardware requirements;
> > +   typically visible resolution rounded up to full macroblocks;
> > +   see also: visible resolution.
> > +
> > +coded width
> > +   width for given coded resolution.
> > +
> > +decode order
> > +   the order in which frames are decoded; may differ from display order if 
> > the
> > +   coded format 

Re: [PATCH v3] nvme-pci: Support shared tags across queues for Apple 2018 controllers

[Balbir Singh]

On Fri, Jul 19, 2019 at 3:31 PM Benjamin Herrenschmidt
 wrote:
>
> From 8dcba2ef5b1466b023b88b4eca463b30de78d9eb Mon Sep 17 00:00:00 2001
> From: Benjamin Herrenschmidt 
> Date: Fri, 19 Jul 2019 15:03:06 +1000
> Subject:
>
> Another issue with the Apple T2 based 2018 controllers seem to be
> that they blow up (and shut the machine down) if there's a tag
> collision between the IO queue and the Admin queue.
>
> My suspicion is that they use our tags for their internal tracking
> and don't mix them with the queue id. They also seem to not like
> when tags go beyond the IO queue depth, ie 128 tags.
>
> This adds a quirk that marks tags 0..31 of the IO queue reserved
>
> Signed-off-by: Benjamin Herrenschmidt 
> ---

Reviewed-by: Balbir Singh 

Здравствуйте! Вас интересуют клиентские базы данных?

[jyb2011]

Здравствуйте! Вас интересуют клиентские базы данных?

[PATCH v3] nvme-pci: Support shared tags across queues for Apple 2018 controllers

[Benjamin Herrenschmidt]

>From 8dcba2ef5b1466b023b88b4eca463b30de78d9eb Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt 
Date: Fri, 19 Jul 2019 15:03:06 +1000
Subject: 

Another issue with the Apple T2 based 2018 controllers seem to be
that they blow up (and shut the machine down) if there's a tag
collision between the IO queue and the Admin queue.

My suspicion is that they use our tags for their internal tracking
and don't mix them with the queue id. They also seem to not like
when tags go beyond the IO queue depth, ie 128 tags.

This adds a quirk that marks tags 0..31 of the IO queue reserved

Signed-off-by: Benjamin Herrenschmidt 
---

Thanks Damien, reserved tags work and make this a lot simpler !

 drivers/nvme/host/nvme.h |  5 +
 drivers/nvme/host/pci.c  | 19 ++-
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index ced0e0a7e039..8732da6df555 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -102,6 +102,11 @@ enum nvme_quirks {
 * Use non-standard 128 bytes SQEs.
 */
NVME_QUIRK_128_BYTES_SQES   = (1 << 11),
+
+   /*
+* Prevent tag overlap between queues
+*/
+   NVME_QUIRK_SHARED_TAGS  = (1 << 12),
 };
 
 /*
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 7088971d4c42..fc74395a028b 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2106,6 +2106,14 @@ static int nvme_setup_io_queues(struct nvme_dev *dev)
unsigned long size;
 
nr_io_queues = max_io_queues();
+
+   /*
+* If tags are shared with admin queue (Apple bug), then
+* make sure we only use one IO queue.
+*/
+   if (dev->ctrl.quirks & NVME_QUIRK_SHARED_TAGS)
+   nr_io_queues = 1;
+
result = nvme_set_queue_count(>ctrl, _io_queues);
if (result < 0)
return result;
@@ -2278,6 +2286,14 @@ static int nvme_dev_add(struct nvme_dev *dev)
dev->tagset.flags = BLK_MQ_F_SHOULD_MERGE;
dev->tagset.driver_data = dev;
 
+   /*
+* Some Apple controllers requires tags to be unique
+* across admin and IO queue, so reserve the first 32
+* tags of the IO queue.
+*/
+   if (dev->ctrl.quirks & NVME_QUIRK_SHARED_TAGS)
+   dev->tagset.reserved_tags = NVME_AQ_DEPTH;
+
ret = blk_mq_alloc_tag_set(>tagset);
if (ret) {
dev_warn(dev->ctrl.device,
@@ -3057,7 +3073,8 @@ static const struct pci_device_id nvme_id_table[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2003) },
{ PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2005),
.driver_data = NVME_QUIRK_SINGLE_VECTOR |
-   NVME_QUIRK_128_BYTES_SQES },
+   NVME_QUIRK_128_BYTES_SQES |
+   NVME_QUIRK_SHARED_TAGS },
{ 0, }
 };
 MODULE_DEVICE_TABLE(pci, nvme_id_table);

Re: [PATCH v2 1/3] tools/perf: Move kvm-stat header file from conditional inclusion to common include section

[Ravi Bangoria]

LGTM. For the series,

Reviewed-By: Ravi Bangoria 

Re: [PATCH v2] nvme-pci: Support shared tags across queues for Apple 2018 controllers

[Benjamin Herrenschmidt]

On Fri, 2019-07-19 at 05:01 +, Damien Le Moal wrote:
> > I suppose that would work and be simpler. I honestly don't know much
> > about the block layer and tag allocation so I stayed away from it :-)
> > 
> > I'll dig, but a hint would be welcome :)
> 
> Uuuh.. Never played with the tag management code directly myself either. A 
> quick
> look seem to indicate that blk_mq_get/put_tag() is what you should be using. 
> But
> further looking, struct blk_mq_tags has the field nr_reserved_tags which is 
> used
> as an offset start point for searching free tags, which is exactly what you
> would need.

Yup. I was getting there, it's just that we use the tagset mess which I
had to untangle a bit first :-)

Cheers,
Ben.

Re: [PATCH] mm/Kconfig: additional help text for HMM_MIRROR option

[John Hubbard]

On 7/18/19 9:34 PM, Ira Weiny wrote:
> On Thu, Jul 18, 2019 at 06:32:53PM -0700, john.hubb...@gmail.com wrote:
>> From: John Hubbard 
...
>> +  Select HMM_MIRROR if you have hardware that meets the above
>> +  description. An early, partial list of such hardware is:
>> +  an NVIDIA GPU >= Pascal, Mellanox IB >= mlx5, or an AMD GPU.
> 
> I don't think we want to put device information here.  If we want that
> information in Kconfig best to put it in the devices themselves.  Otherwise
> this list will get stale.
> 
> Other than that, looks good.
> 
> Reviewed-by: Ira Weiny 
> 

Hi Ira, thanks for the review, I'll remove that last sentence. I'll post a v2
with your reviewed by tag, in a new email thread. But first I'll wait to see 
if there are other replies.

thanks,
-- 
John Hubbard
NVIDIA

[PATCH] PCI: Add ACS quirk for Cavium ThunderX 2 root port devices

[Shannon Zhao]

From: Shannon Zhao 

Like commit f2ddaf8(PCI: Apply Cavium ThunderX ACS quirk to more Root
Ports), it should apply ACS quirk to ThunderX 2 root port devices.

Signed-off-by: Shannon Zhao 
---
 drivers/pci/quirks.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 28c64f8..ea7848b 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4224,10 +4224,12 @@ static bool pci_quirk_cavium_acs_match(struct pci_dev 
*dev)
 * family by 0xf800 mask (which represents 8 SoCs), while the lower
 * bits of device ID are used to indicate which subdevice is used
 * within the SoC.
+* Effectively selects the ThunderX 2 root ports whose device ID
+* is 0xaf84.
 */
return (pci_is_pcie(dev) &&
(pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT) &&
-   ((dev->device & 0xf800) == 0xa000));
+   ((dev->device & 0xf800) == 0xa000 || dev->device == 0xaf84));
 }
 
 static int pci_quirk_cavium_acs(struct pci_dev *dev, u16 acs_flags)
-- 
1.8.3.1

Re: [PATCH] [RFC] dmaengine: add fifo_size member

[Vinod Koul]

On 05-07-19, 11:45, Sameer Pujar wrote:
> Hi Vinod,
> 
> What are your final thoughts regarding this?

Hi sameer,

Sorry for the delay in replying

On this, I am inclined to think that dma driver should not be involved.
The ADMAIF needs this configuration and we should take the path of
dma_router for this piece and add features like this to it

> 
> Thanks,
> Sameer.
> 
> > > Where does ADMAIF driver reside in kernel, who configures it for normal
> > > dma txns..?
> > Not yet, we are in the process of upstreaming ADMAIF driver.
> > To describe briefly, audio subsystem is using ALSA SoC(ASoC) layer.
> > ADMAIF is
> > registered as platform driver and exports DMA functionality. It
> > registers PCM
> > devices for each Rx/Tx ADMAIF channel. During PCM playback/capture
> > operations,
> > ALSA callbacks configure DMA channel using API dmaengine_slave_config().
> > RFC patch proposed, is to help populate FIFO_SIZE value as well during
> > above
> > call, since ADMA requires it.
> > > 
> > > Also it wold have helped the long discussion if that part was made clear
> > > rather than talking about peripheral all this time :(
> > Thought it was clear, though should have avoided using 'peripheral' in
> > the
> > discussions. Sorry for the confusion.

-- 
~Vinod

Re: [PATCH v2] nvme-pci: Support shared tags across queues for Apple 2018 controllers

[Damien Le Moal]

On 2019/07/19 13:49, Benjamin Herrenschmidt wrote:
> On Fri, 2019-07-19 at 04:43 +, Damien Le Moal wrote:
>> On 2019/07/19 13:37, Benjamin Herrenschmidt wrote:
>>> Another issue with the Apple T2 based 2018 controllers seem to be
>>> that they blow up (and shut the machine down) if there's a tag
>>> collision between the IO queue and the Admin queue.
>>>
>>> My suspicion is that they use our tags for their internal tracking
>>> and don't mix them with the queue id. They also seem to not like
>>> when tags go beyond the IO queue depth, ie 128 tags.
>>>
>>> This adds a quirk that offsets all the tags in the IO queue by 32
>>> to avoid those collisions. It also limits the number of IO queues
>>> to 1 since the code wouldn't otherwise make sense (the device
>>> supports only one queue anyway but better safe than sorry) and
>>> reduces the size of the IO queue
>>
>> What about keeping the IO queue QD at 128, but marking the first 32 tags as
>> "allocated" when the device is initialized ? This way, these tags numbers are
>> never used for regular IOs and you can avoid the entire tag +/- offset dance 
>> at
>> runtime. The admin queue uses tags 0-31 and the IO queue uses tags 32-127. 
>> No ?
> 
> I suppose that would work and be simpler. I honestly don't know much
> about the block layer and tag allocation so I stayed away from it :-)
> 
> I'll dig, but a hint would be welcome :)

Uuuh.. Never played with the tag management code directly myself either. A quick
look seem to indicate that blk_mq_get/put_tag() is what you should be using. But
further looking, struct blk_mq_tags has the field nr_reserved_tags which is used
as an offset start point for searching free tags, which is exactly what you
would need.


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH v2] nvme-pci: Support shared tags across queues for Apple 2018 controllers

[Benjamin Herrenschmidt]

On Fri, 2019-07-19 at 14:49 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2019-07-19 at 04:43 +, Damien Le Moal wrote:
> > On 2019/07/19 13:37, Benjamin Herrenschmidt wrote:
> > > Another issue with the Apple T2 based 2018 controllers seem to be
> > > that they blow up (and shut the machine down) if there's a tag
> > > collision between the IO queue and the Admin queue.
> > > 
> > > My suspicion is that they use our tags for their internal
> > > tracking
> > > and don't mix them with the queue id. They also seem to not like
> > > when tags go beyond the IO queue depth, ie 128 tags.
> > > 
> > > This adds a quirk that offsets all the tags in the IO queue by 32
> > > to avoid those collisions. It also limits the number of IO queues
> > > to 1 since the code wouldn't otherwise make sense (the device
> > > supports only one queue anyway but better safe than sorry) and
> > > reduces the size of the IO queue
> > 
> > What about keeping the IO queue QD at 128, but marking the first 32
> > tags as
> > "allocated" when the device is initialized ? This way, these tags
> > numbers are
> > never used for regular IOs and you can avoid the entire tag +/-
> > offset dance at
> > runtime. The admin queue uses tags 0-31 and the IO queue uses tags
> > 32-127. No ?
> 
> I suppose that would work and be simpler. I honestly don't know much
> about the block layer and tag allocation so I stayed away from it :-)
> 
> I'll dig, but a hint would be welcome :)

Hrm .. tagset->reserved_tags ?

> Cheers,
> Ben.
> 
> > > 
> > > Signed-off-by: Benjamin Herrenschmidt 
> > > ---
> > > 
> > > Note: One thing I noticed is how we have nvme_completion as
> > > volatile.
> > > 
> > > I don't think we really need that, it's forcing the compiler to
> > > constantly
> > > reload things which makes no sense once we have established that
> > > an
> > > entry is valid.
> > > 
> > > And since we have a data & control dependency from
> > > nvme_cqe_pending(),
> > > we know that reading the CQE is going to depend on it being
> > > valid. I
> > > don't really see what volatile is buying us here other than cargo
> > > culting.
> > > 
> > > Cheers,
> > > Ben.
> > > 
> > >  drivers/nvme/host/nvme.h |  5 
> > >  drivers/nvme/host/pci.c  | 52 +-
> > > --
> > >  2 files changed, 49 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
> > > index ced0e0a7e039..7c6de398de7d 100644
> > > --- a/drivers/nvme/host/nvme.h
> > > +++ b/drivers/nvme/host/nvme.h
> > > @@ -102,6 +102,11 @@ enum nvme_quirks {
> > >* Use non-standard 128 bytes SQEs.
> > >*/
> > >   NVME_QUIRK_128_BYTES_SQES   = (1 << 11),
> > > +
> > > + /*
> > > +  * Prevent tag overlap between queues
> > > +  */
> > > + NVME_QUIRK_SHARED_TAGS  = (1 << 12),
> > >  };
> > >  
> > >  /*
> > > diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> > > index 7088971d4c42..c38e946ad8ca 100644
> > > --- a/drivers/nvme/host/pci.c
> > > +++ b/drivers/nvme/host/pci.c
> > > @@ -178,6 +178,7 @@ struct nvme_queue {
> > >   u16 cq_head;
> > >   u16 last_cq_head;
> > >   u16 qid;
> > > + u16 tag_offset;
> > >   u8 cq_phase;
> > >   u8 sqes;
> > >   unsigned long flags;
> > > @@ -490,6 +491,7 @@ static void nvme_submit_cmd(struct nvme_queue
> > > *nvmeq, struct nvme_command *cmd,
> > >   bool write_sq)
> > >  {
> > >   spin_lock(>sq_lock);
> > > + cmd->common.command_id += nvmeq->tag_offset;
> > >   memcpy(nvmeq->sq_cmds + (nvmeq->sq_tail << nvmeq->sqes),
> > >  cmd, sizeof(*cmd));
> > >   if (++nvmeq->sq_tail == nvmeq->q_depth)
> > > @@ -951,9 +953,10 @@ static inline void
> > > nvme_ring_cq_doorbell(struct nvme_queue *nvmeq)
> > >  static inline void nvme_handle_cqe(struct nvme_queue *nvmeq, u16
> > > idx)
> > >  {
> > >   volatile struct nvme_completion *cqe = >cqes[idx];
> > > + u16 ctag = cqe->command_id - nvmeq->tag_offset;
> > >   struct request *req;
> > >  
> > > - if (unlikely(cqe->command_id >= nvmeq->q_depth)) {
> > > + if (unlikely(ctag >= nvmeq->q_depth)) {
> > >   dev_warn(nvmeq->dev->ctrl.device,
> > >   "invalid id %d completed on queue %d\n",
> > >   cqe->command_id, le16_to_cpu(cqe->sq_id));
> > > @@ -966,14 +969,13 @@ static inline void nvme_handle_cqe(struct
> > > nvme_queue *nvmeq, u16 idx)
> > >* aborts.  We don't even bother to allocate a struct request
> > >* for them but rather special case them here.
> > >*/
> > > - if (unlikely(nvmeq->qid == 0 &&
> > > - cqe->command_id >= NVME_AQ_BLK_MQ_DEPTH)) {
> > > + if (unlikely(nvmeq->qid == 0 && ctag >= NVME_AQ_BLK_MQ_DEPTH))
> > > {
> > >   nvme_complete_async_event(>dev->ctrl,
> > >   cqe->status, >result);
> > >   return;
> > >   }
> > >  
> > > - req = blk_mq_tag_to_rq(*nvmeq->tags, cqe->command_id);
> > > + req = blk_mq_tag_to_rq(*nvmeq->tags, ctag);
> > >   

Re: [PATCH v3 8/9] x86/mm/tlb: Remove UV special case

[Nadav Amit]

> On Jul 18, 2019, at 7:25 PM, Mike Travis  wrote:
> 
> It is a fact that the UV is still the UV and SGI is now part of HPE. The 
> current external product is known as SuperDome Flex.  It is both up to date 
> as well as very well maintained.  The ACK I provided was an okay to change 
> the code, but please make the description accurate.

Indeed. Sorry for that - I will update it in v4. I guess you will be ok with
me copy-pasting parts of your response into the commit log.

Re: [PATCH] arm64: Explicitly set pstate.ssbs for el0 on kernel entry

[Neeraj Upadhyay]

Hi Marc,


On 7/9/19 7:52 PM, Marc Zyngier wrote:

On 09/07/2019 15:18, Neeraj Upadhyay wrote:

Hi Marc,

On 7/9/19 6:38 PM, Marc Zyngier wrote:

Hi Neeraj,

On 09/07/2019 12:22, Neeraj Upadhyay wrote:

For cpus which do not support pstate.ssbs feature, el0
might not retain spsr.ssbs. This is problematic, if this
task migrates to a cpu supporting this feature, thus
relying on its state to be correct. On kernel entry,
explicitly set spsr.ssbs, so that speculation is enabled
for el0, when this task migrates to a cpu supporting
ssbs feature. Restoring state at kernel entry ensures
that el0 ssbs state is always consistent while we are
in el1.

As alternatives are applied by boot cpu, at the end of smp
init, presence/absence of ssbs feature on boot cpu, is used
for deciding, whether the capability is uniformly provided.

I've seen the same issue, but went for a slightly different
approach, see below.


Signed-off-by: Neeraj Upadhyay 
---
   arch/arm64/kernel/cpu_errata.c | 16 
   arch/arm64/kernel/entry.S  | 26 +-
   2 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index ca11ff7..c84a56d 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -336,6 +336,22 @@ void __init arm64_enable_wa2_handling(struct alt_instr 
*alt,
*updptr = cpu_to_le32(aarch64_insn_gen_nop());
   }
   
+void __init arm64_restore_ssbs_state(struct alt_instr *alt,

+__le32 *origptr, __le32 *updptr,
+int nr_inst)
+{
+   BUG_ON(nr_inst != 1);
+   /*
+* Only restore EL0 SSBS state on EL1 entry if cpu does not
+* support the capability and capability is present for at
+* least one cpu and if the SSBD state allows it to
+* be changed.
+*/
+   if (!this_cpu_has_cap(ARM64_SSBS) && cpus_have_cap(ARM64_SSBS) &&
+   arm64_get_ssbd_state() != ARM64_SSBD_FORCE_ENABLE)
+   *updptr = cpu_to_le32(aarch64_insn_gen_nop());
+}
+
   void arm64_set_ssbd_mitigation(bool state)
   {
if (!IS_ENABLED(CONFIG_ARM64_SSBD)) {
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 9cdc459..7e79305 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -143,6 +143,25 @@ alternative_cb_end
   #endif
.endm
   
+	// This macro updates spsr. It also corrupts the condition

+   // codes state.
+   .macro  restore_ssbs_state, saved_spsr, tmp
+#ifdef CONFIG_ARM64_SSBD
+alternative_cb arm64_restore_ssbs_state
+   b   .L__asm_ssbs_skip\@
+alternative_cb_end
+   ldr \tmp, [tsk, #TSK_TI_FLAGS]
+   tbnz\tmp, #TIF_SSBD, .L__asm_ssbs_skip\@
+   tst \saved_spsr, #PSR_MODE32_BIT// native task?
+   b.ne.L__asm_ssbs_compat\@
+   orr \saved_spsr, \saved_spsr, #PSR_SSBS_BIT
+   b   .L__asm_ssbs_skip\@
+.L__asm_ssbs_compat\@:
+   orr \saved_spsr, \saved_spsr, #PSR_AA32_SSBS_BIT
+.L__asm_ssbs_skip\@:
+#endif
+   .endm

Although this is in keeping with the rest of entry.S (perfectly
unreadable ;-), I think we can do something a bit simpler, that
doesn't rely on patching. Also, this doesn't seem to take the
SSBD options such as ARM64_SSBD_FORCE_ENABLE into account.

arm64_restore_ssbs_state has a check for ARM64_SSBD_FORCE_ENABLE,

does that look wrong?

No, I just focused on the rest of the asm code and missed it, apologies.


+
.macro  kernel_entry, el, regsize = 64
.if \regsize == 32
mov w0, w0  // zero upper 32 bits of x0
@@ -182,8 +201,13 @@ alternative_cb_end
str x20, [tsk, #TSK_TI_ADDR_LIMIT]
/* No need to reset PSTATE.UAO, hardware's already set it to 0 for us */
.endif /* \el == 0 */
-   mrs x22, elr_el1
mrs x23, spsr_el1
+
+   .if \el == 0
+   restore_ssbs_state x23, x22
+   .endif
+
+   mrs x22, elr_el1
stp lr, x21, [sp, #S_LR]
   
   	/*



How about the patch below?

Looks good; was just going to mention PF_KTHREAD check, but Mark R. has
already

given detailed information about it.

Yup, well spotted. I'll respin it shortly and we can then work out
whether that's really a better approach.


Did you get chance to recheck it?


Thanks

Neeraj



Thanks,

M.


--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v2] nvme-pci: Support shared tags across queues for Apple 2018 controllers

[Benjamin Herrenschmidt]

On Fri, 2019-07-19 at 04:43 +, Damien Le Moal wrote:
> On 2019/07/19 13:37, Benjamin Herrenschmidt wrote:
> > Another issue with the Apple T2 based 2018 controllers seem to be
> > that they blow up (and shut the machine down) if there's a tag
> > collision between the IO queue and the Admin queue.
> > 
> > My suspicion is that they use our tags for their internal tracking
> > and don't mix them with the queue id. They also seem to not like
> > when tags go beyond the IO queue depth, ie 128 tags.
> > 
> > This adds a quirk that offsets all the tags in the IO queue by 32
> > to avoid those collisions. It also limits the number of IO queues
> > to 1 since the code wouldn't otherwise make sense (the device
> > supports only one queue anyway but better safe than sorry) and
> > reduces the size of the IO queue
> 
> What about keeping the IO queue QD at 128, but marking the first 32 tags as
> "allocated" when the device is initialized ? This way, these tags numbers are
> never used for regular IOs and you can avoid the entire tag +/- offset dance 
> at
> runtime. The admin queue uses tags 0-31 and the IO queue uses tags 32-127. No 
> ?

I suppose that would work and be simpler. I honestly don't know much
about the block layer and tag allocation so I stayed away from it :-)

I'll dig, but a hint would be welcome :)

Cheers,
Ben.

> > 
> > Signed-off-by: Benjamin Herrenschmidt 
> > ---
> > 
> > Note: One thing I noticed is how we have nvme_completion as volatile.
> > 
> > I don't think we really need that, it's forcing the compiler to constantly
> > reload things which makes no sense once we have established that an
> > entry is valid.
> > 
> > And since we have a data & control dependency from nvme_cqe_pending(),
> > we know that reading the CQE is going to depend on it being valid. I
> > don't really see what volatile is buying us here other than cargo culting.
> > 
> > Cheers,
> > Ben.
> > 
> >  drivers/nvme/host/nvme.h |  5 
> >  drivers/nvme/host/pci.c  | 52 +---
> >  2 files changed, 49 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
> > index ced0e0a7e039..7c6de398de7d 100644
> > --- a/drivers/nvme/host/nvme.h
> > +++ b/drivers/nvme/host/nvme.h
> > @@ -102,6 +102,11 @@ enum nvme_quirks {
> >  * Use non-standard 128 bytes SQEs.
> >  */
> > NVME_QUIRK_128_BYTES_SQES   = (1 << 11),
> > +
> > +   /*
> > +* Prevent tag overlap between queues
> > +*/
> > +   NVME_QUIRK_SHARED_TAGS  = (1 << 12),
> >  };
> >  
> >  /*
> > diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> > index 7088971d4c42..c38e946ad8ca 100644
> > --- a/drivers/nvme/host/pci.c
> > +++ b/drivers/nvme/host/pci.c
> > @@ -178,6 +178,7 @@ struct nvme_queue {
> > u16 cq_head;
> > u16 last_cq_head;
> > u16 qid;
> > +   u16 tag_offset;
> > u8 cq_phase;
> > u8 sqes;
> > unsigned long flags;
> > @@ -490,6 +491,7 @@ static void nvme_submit_cmd(struct nvme_queue *nvmeq, 
> > struct nvme_command *cmd,
> > bool write_sq)
> >  {
> > spin_lock(>sq_lock);
> > +   cmd->common.command_id += nvmeq->tag_offset;
> > memcpy(nvmeq->sq_cmds + (nvmeq->sq_tail << nvmeq->sqes),
> >cmd, sizeof(*cmd));
> > if (++nvmeq->sq_tail == nvmeq->q_depth)
> > @@ -951,9 +953,10 @@ static inline void nvme_ring_cq_doorbell(struct 
> > nvme_queue *nvmeq)
> >  static inline void nvme_handle_cqe(struct nvme_queue *nvmeq, u16 idx)
> >  {
> > volatile struct nvme_completion *cqe = >cqes[idx];
> > +   u16 ctag = cqe->command_id - nvmeq->tag_offset;
> > struct request *req;
> >  
> > -   if (unlikely(cqe->command_id >= nvmeq->q_depth)) {
> > +   if (unlikely(ctag >= nvmeq->q_depth)) {
> > dev_warn(nvmeq->dev->ctrl.device,
> > "invalid id %d completed on queue %d\n",
> > cqe->command_id, le16_to_cpu(cqe->sq_id));
> > @@ -966,14 +969,13 @@ static inline void nvme_handle_cqe(struct nvme_queue 
> > *nvmeq, u16 idx)
> >  * aborts.  We don't even bother to allocate a struct request
> >  * for them but rather special case them here.
> >  */
> > -   if (unlikely(nvmeq->qid == 0 &&
> > -   cqe->command_id >= NVME_AQ_BLK_MQ_DEPTH)) {
> > +   if (unlikely(nvmeq->qid == 0 && ctag >= NVME_AQ_BLK_MQ_DEPTH)) {
> > nvme_complete_async_event(>dev->ctrl,
> > cqe->status, >result);
> > return;
> > }
> >  
> > -   req = blk_mq_tag_to_rq(*nvmeq->tags, cqe->command_id);
> > +   req = blk_mq_tag_to_rq(*nvmeq->tags, ctag);
> > trace_nvme_sq(req, cqe->sq_head, nvmeq->sq_tail);
> > nvme_end_request(req, cqe->status, cqe->result);
> >  }
> > @@ -1004,7 +1006,10 @@ static inline int nvme_process_cq(struct nvme_queue 
> > *nvmeq, u16 *start,
> >  
> > *start = nvmeq->cq_head;
> > while (nvme_cqe_pending(nvmeq)) {
> > -   if (tag 

Re: [PATCH v2] nvme-pci: Support shared tags across queues for Apple 2018 controllers

[Damien Le Moal]

On 2019/07/19 13:37, Benjamin Herrenschmidt wrote:
> Another issue with the Apple T2 based 2018 controllers seem to be
> that they blow up (and shut the machine down) if there's a tag
> collision between the IO queue and the Admin queue.
> 
> My suspicion is that they use our tags for their internal tracking
> and don't mix them with the queue id. They also seem to not like
> when tags go beyond the IO queue depth, ie 128 tags.
> 
> This adds a quirk that offsets all the tags in the IO queue by 32
> to avoid those collisions. It also limits the number of IO queues
> to 1 since the code wouldn't otherwise make sense (the device
> supports only one queue anyway but better safe than sorry) and
> reduces the size of the IO queue

What about keeping the IO queue QD at 128, but marking the first 32 tags as
"allocated" when the device is initialized ? This way, these tags numbers are
never used for regular IOs and you can avoid the entire tag +/- offset dance at
runtime. The admin queue uses tags 0-31 and the IO queue uses tags 32-127. No ?

> 
> Signed-off-by: Benjamin Herrenschmidt 
> ---
> 
> Note: One thing I noticed is how we have nvme_completion as volatile.
> 
> I don't think we really need that, it's forcing the compiler to constantly
> reload things which makes no sense once we have established that an
> entry is valid.
> 
> And since we have a data & control dependency from nvme_cqe_pending(),
> we know that reading the CQE is going to depend on it being valid. I
> don't really see what volatile is buying us here other than cargo culting.
> 
> Cheers,
> Ben.
> 
>  drivers/nvme/host/nvme.h |  5 
>  drivers/nvme/host/pci.c  | 52 +---
>  2 files changed, 49 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
> index ced0e0a7e039..7c6de398de7d 100644
> --- a/drivers/nvme/host/nvme.h
> +++ b/drivers/nvme/host/nvme.h
> @@ -102,6 +102,11 @@ enum nvme_quirks {
>* Use non-standard 128 bytes SQEs.
>*/
>   NVME_QUIRK_128_BYTES_SQES   = (1 << 11),
> +
> + /*
> +  * Prevent tag overlap between queues
> +  */
> + NVME_QUIRK_SHARED_TAGS  = (1 << 12),
>  };
>  
>  /*
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index 7088971d4c42..c38e946ad8ca 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -178,6 +178,7 @@ struct nvme_queue {
>   u16 cq_head;
>   u16 last_cq_head;
>   u16 qid;
> + u16 tag_offset;
>   u8 cq_phase;
>   u8 sqes;
>   unsigned long flags;
> @@ -490,6 +491,7 @@ static void nvme_submit_cmd(struct nvme_queue *nvmeq, 
> struct nvme_command *cmd,
>   bool write_sq)
>  {
>   spin_lock(>sq_lock);
> + cmd->common.command_id += nvmeq->tag_offset;
>   memcpy(nvmeq->sq_cmds + (nvmeq->sq_tail << nvmeq->sqes),
>  cmd, sizeof(*cmd));
>   if (++nvmeq->sq_tail == nvmeq->q_depth)
> @@ -951,9 +953,10 @@ static inline void nvme_ring_cq_doorbell(struct 
> nvme_queue *nvmeq)
>  static inline void nvme_handle_cqe(struct nvme_queue *nvmeq, u16 idx)
>  {
>   volatile struct nvme_completion *cqe = >cqes[idx];
> + u16 ctag = cqe->command_id - nvmeq->tag_offset;
>   struct request *req;
>  
> - if (unlikely(cqe->command_id >= nvmeq->q_depth)) {
> + if (unlikely(ctag >= nvmeq->q_depth)) {
>   dev_warn(nvmeq->dev->ctrl.device,
>   "invalid id %d completed on queue %d\n",
>   cqe->command_id, le16_to_cpu(cqe->sq_id));
> @@ -966,14 +969,13 @@ static inline void nvme_handle_cqe(struct nvme_queue 
> *nvmeq, u16 idx)
>* aborts.  We don't even bother to allocate a struct request
>* for them but rather special case them here.
>*/
> - if (unlikely(nvmeq->qid == 0 &&
> - cqe->command_id >= NVME_AQ_BLK_MQ_DEPTH)) {
> + if (unlikely(nvmeq->qid == 0 && ctag >= NVME_AQ_BLK_MQ_DEPTH)) {
>   nvme_complete_async_event(>dev->ctrl,
>   cqe->status, >result);
>   return;
>   }
>  
> - req = blk_mq_tag_to_rq(*nvmeq->tags, cqe->command_id);
> + req = blk_mq_tag_to_rq(*nvmeq->tags, ctag);
>   trace_nvme_sq(req, cqe->sq_head, nvmeq->sq_tail);
>   nvme_end_request(req, cqe->status, cqe->result);
>  }
> @@ -1004,7 +1006,10 @@ static inline int nvme_process_cq(struct nvme_queue 
> *nvmeq, u16 *start,
>  
>   *start = nvmeq->cq_head;
>   while (nvme_cqe_pending(nvmeq)) {
> - if (tag == -1U || nvmeq->cqes[nvmeq->cq_head].command_id == tag)
> + u16 ctag = nvmeq->cqes[nvmeq->cq_head].command_id;
> +
> + ctag -= nvmeq->tag_offset;
> + if (tag == -1U || ctag == tag)
>   found++;
>   nvme_update_cq_head(nvmeq);
>   }
> @@ -1487,6 +1492,10 @@ static int nvme_alloc_queue(struct nvme_dev *dev, int 
> qid, int 

Re: [PATCH 4.14 00/80] 4.14.134-stable review

[Bharath Vedartham]

Built and booted on my x86 machine. No dmesg regressions.

Thank you
Bharath

Re: [PATCH 4.4 00/40] 4.4.186-stable review

[Bharath Vedartham]

Built and booted on my x86 system. No dmesg regressions found.

Thank you
Bharath

Re: [PATCH 5.1 00/54] 5.1.19-stable review

[Bharath Vedartham]

Built and booted on my x86 machine. No dmesg regressions found.

Thank you
Bharath

Re: [PATCH 4.9 00/54] 4.9.186-stable review

[Bharath Vedartham]

Built and booted in my x86 test machine. No regressions found.

Thank you
Bharath

[PATCH AUTOSEL 5.2 009/171] drm/bochs: Fix connector leak during driver unload

[Sasha Levin]

From: Sam Bobroff 

[ Upstream commit 3c6b8625dde82600fd03ad1fcba223f1303ee535 ]

When unloading the bochs-drm driver, a warning message is printed by
drm_mode_config_cleanup() because a reference is still held to one of
the drm_connector structs.

Correct this by calling drm_atomic_helper_shutdown() in
bochs_pci_remove().

Fixes: 6579c39594ae ("drm/bochs: atomic: switch planes to atomic, wire up 
helpers.")
Signed-off-by: Sam Bobroff 
Link: 
http://patchwork.freedesktop.org/patch/msgid/93b363ad62f4938d9ddf3e05b2a61e3f66b2dcd3.1558416473.git.sbobr...@linux.ibm.com
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/bochs/bochs_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index b86cc705138c..d8b945596b09 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "bochs.h"
 
@@ -171,6 +172,7 @@ static void bochs_pci_remove(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
 
+   drm_atomic_helper_shutdown(dev);
drm_dev_unregister(dev);
bochs_unload(dev);
drm_dev_put(dev);
-- 
2.20.1

[PATCH AUTOSEL 5.2 008/171] staging: vt6656: use meaningful error code during buffer allocation

[Sasha Levin]

From: Quentin Deslandes 

[ Upstream commit d8c2869300ab5f7a19bf6f5a04fe473c5c9887e3 ]

Check on called function's returned value for error and return 0 on
success or a negative errno value on error instead of a boolean value.

Signed-off-by: Quentin Deslandes 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/staging/vt6656/main_usb.c | 42 ---
 1 file changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/vt6656/main_usb.c 
b/drivers/staging/vt6656/main_usb.c
index ccafcc2c87ac..70433f756d8e 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -402,16 +402,19 @@ static void vnt_free_int_bufs(struct vnt_private *priv)
kfree(priv->int_buf.data_buf);
 }
 
-static bool vnt_alloc_bufs(struct vnt_private *priv)
+static int vnt_alloc_bufs(struct vnt_private *priv)
 {
+   int ret = 0;
struct vnt_usb_send_context *tx_context;
struct vnt_rcb *rcb;
int ii;
 
for (ii = 0; ii < priv->num_tx_context; ii++) {
tx_context = kmalloc(sizeof(*tx_context), GFP_KERNEL);
-   if (!tx_context)
+   if (!tx_context) {
+   ret = -ENOMEM;
goto free_tx;
+   }
 
priv->tx_context[ii] = tx_context;
tx_context->priv = priv;
@@ -419,16 +422,20 @@ static bool vnt_alloc_bufs(struct vnt_private *priv)
 
/* allocate URBs */
tx_context->urb = usb_alloc_urb(0, GFP_KERNEL);
-   if (!tx_context->urb)
+   if (!tx_context->urb) {
+   ret = -ENOMEM;
goto free_tx;
+   }
 
tx_context->in_use = false;
}
 
for (ii = 0; ii < priv->num_rcb; ii++) {
priv->rcb[ii] = kzalloc(sizeof(*priv->rcb[ii]), GFP_KERNEL);
-   if (!priv->rcb[ii])
+   if (!priv->rcb[ii]) {
+   ret = -ENOMEM;
goto free_rx_tx;
+   }
 
rcb = priv->rcb[ii];
 
@@ -436,39 +443,46 @@ static bool vnt_alloc_bufs(struct vnt_private *priv)
 
/* allocate URBs */
rcb->urb = usb_alloc_urb(0, GFP_KERNEL);
-   if (!rcb->urb)
+   if (!rcb->urb) {
+   ret = -ENOMEM;
goto free_rx_tx;
+   }
 
rcb->skb = dev_alloc_skb(priv->rx_buf_sz);
-   if (!rcb->skb)
+   if (!rcb->skb) {
+   ret = -ENOMEM;
goto free_rx_tx;
+   }
 
rcb->in_use = false;
 
/* submit rx urb */
-   if (vnt_submit_rx_urb(priv, rcb))
+   ret = vnt_submit_rx_urb(priv, rcb);
+   if (ret)
goto free_rx_tx;
}
 
priv->interrupt_urb = usb_alloc_urb(0, GFP_KERNEL);
-   if (!priv->interrupt_urb)
+   if (!priv->interrupt_urb) {
+   ret = -ENOMEM;
goto free_rx_tx;
+   }
 
priv->int_buf.data_buf = kmalloc(MAX_INTERRUPT_SIZE, GFP_KERNEL);
if (!priv->int_buf.data_buf) {
-   usb_free_urb(priv->interrupt_urb);
-   goto free_rx_tx;
+   ret = -ENOMEM;
+   goto free_rx_tx_urb;
}
 
-   return true;
+   return 0;
 
+free_rx_tx_urb:
+   usb_free_urb(priv->interrupt_urb);
 free_rx_tx:
vnt_free_rx_bufs(priv);
-
 free_tx:
vnt_free_tx_bufs(priv);
-
-   return false;
+   return ret;
 }
 
 static void vnt_tx_80211(struct ieee80211_hw *hw,
-- 
2.20.1

[PATCH AUTOSEL 5.2 026/171] drm/amd/display: Disable ABM before destroy ABM struct

[Sasha Levin]

From: Paul Hsieh 

[ Upstream commit 1090d58d4815b1fcd95a80987391006c86398b4c ]

[Why]
When disable driver, OS will set backlight optimization
then do stop device.  But this flag will cause driver to
enable ABM when driver disabled.

[How]
Send ABM disable command before destroy ABM construct

Signed-off-by: Paul Hsieh 
Reviewed-by: Anthony Koo 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/display/dc/dce/dce_abm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c
index da96229db53a..2959c3c9390b 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c
@@ -473,6 +473,8 @@ void dce_abm_destroy(struct abm **abm)
 {
struct dce_abm *abm_dce = TO_DCE_ABM(*abm);
 
+   abm_dce->base.funcs->set_abm_immediate_disable(*abm);
+
kfree(abm_dce);
*abm = NULL;
 }
-- 
2.20.1

[PATCH AUTOSEL 5.2 011/171] tty: max310x: Fix invalid baudrate divisors calculator

[Sasha Levin]

From: Serge Semin 

[ Upstream commit 35240ba26a932b279a513f66fa4cabfd7af55221 ]

Current calculator doesn't do it' job quite correct. First of all the
max310x baud-rates generator supports the divisor being less than 16.
In this case the x2/x4 modes can be used to double or quadruple
the reference frequency. But the current baud-rate setter function
just filters all these modes out by the first condition and setups
these modes only if there is a clocks-baud division remainder. The former
doesn't seem right at all, since enabling the x2/x4 modes causes the line
noise tolerance reduction and should be only used as a last resort to
enable a requested too high baud-rate.

Finally the fraction is supposed to be calculated from D = Fref/(c*baud)
formulae, but not from D % 16, which causes the precision loss. So to speak
the current baud-rate calculator code works well only if the baud perfectly
fits to the uart reference input frequency.

Lets fix the calculator by implementing the algo fully compliant with
the fractional baud-rate generator described in the datasheet:
D = Fref / (c*baud), where c={16,8,4} is the x1/x2/x4 rate mode
respectively, Fref - reference input frequency. The divisor fraction is
calculated from the same formulae, but making sure it is found with a
resolution of 0.0625 (four bits).

Signed-off-by: Serge Semin 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/tty/serial/max310x.c | 51 ++--
 1 file changed, 31 insertions(+), 20 deletions(-)

diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index e5aebbf5f302..c3afd128b8fc 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -496,37 +496,48 @@ static bool max310x_reg_precious(struct device *dev, 
unsigned int reg)
 
 static int max310x_set_baud(struct uart_port *port, int baud)
 {
-   unsigned int mode = 0, clk = port->uartclk, div = clk / baud;
+   unsigned int mode = 0, div = 0, frac = 0, c = 0, F = 0;
 
-   /* Check for minimal value for divider */
-   if (div < 16)
-   div = 16;
-
-   if (clk % baud && (div / 16) < 0x8000) {
+   /*
+* Calculate the integer divisor first. Select a proper mode
+* in case if the requested baud is too high for the pre-defined
+* clocks frequency.
+*/
+   div = port->uartclk / baud;
+   if (div < 8) {
+   /* Mode x4 */
+   c = 4;
+   mode = MAX310X_BRGCFG_4XMODE_BIT;
+   } else if (div < 16) {
/* Mode x2 */
+   c = 8;
mode = MAX310X_BRGCFG_2XMODE_BIT;
-   clk = port->uartclk * 2;
-   div = clk / baud;
-
-   if (clk % baud && (div / 16) < 0x8000) {
-   /* Mode x4 */
-   mode = MAX310X_BRGCFG_4XMODE_BIT;
-   clk = port->uartclk * 4;
-   div = clk / baud;
-   }
+   } else {
+   c = 16;
}
 
-   max310x_port_write(port, MAX310X_BRGDIVMSB_REG, (div / 16) >> 8);
-   max310x_port_write(port, MAX310X_BRGDIVLSB_REG, div / 16);
-   max310x_port_write(port, MAX310X_BRGCFG_REG, (div % 16) | mode);
+   /* Calculate the divisor in accordance with the fraction coefficient */
+   div /= c;
+   F = c*baud;
+
+   /* Calculate the baud rate fraction */
+   if (div > 0)
+   frac = (16*(port->uartclk % F)) / F;
+   else
+   div = 1;
+
+   max310x_port_write(port, MAX310X_BRGDIVMSB_REG, div >> 8);
+   max310x_port_write(port, MAX310X_BRGDIVLSB_REG, div);
+   max310x_port_write(port, MAX310X_BRGCFG_REG, frac | mode);
 
-   return DIV_ROUND_CLOSEST(clk, div);
+   /* Return the actual baud rate we just programmed */
+   return (16*port->uartclk) / (c*(16*div + frac));
 }
 
 static int max310x_update_best_err(unsigned long f, long *besterr)
 {
/* Use baudrate 115200 for calculate error */
-   long err = f % (115200 * 16);
+   long err = f % (460800 * 16);
 
if ((*besterr < 0) || (*besterr > err)) {
*besterr = err;
-- 
2.20.1

[PATCH AUTOSEL 5.2 031/171] PCI: Return error if cannot probe VF

[Sasha Levin]

From: Alex Williamson 

[ Upstream commit 76002d8b48c4b08c9bd414517dd295e132ad910b ]

Commit 0e7df22401a3 ("PCI: Add sysfs sriov_drivers_autoprobe to control
VF driver binding") allows the user to specify that drivers for VFs of
a PF should not be probed, but it actually causes pci_device_probe() to
return success back to the driver core in this case.  Therefore by all
sysfs appearances the device is bound to a driver, the driver link from
the device exists as does the device link back from the driver, yet the
driver's probe function is never called on the device.  We also fail to
do any sort of cleanup when we're prohibited from probing the device,
the IRQ setup remains in place and we even hold a device reference.

Instead, abort with errno before any setup or references are taken when
pci_device_can_probe() prevents us from trying to probe the device.

Link: 
https://lore.kernel.org/lkml/155672991496.20698.4279330795743262888.st...@gimli.home
Fixes: 0e7df22401a3 ("PCI: Add sysfs sriov_drivers_autoprobe to control VF 
driver binding")
Signed-off-by: Alex Williamson 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Sasha Levin 
---
 drivers/pci/pci-driver.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index ca3793002e2f..74c3df250d9c 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -414,6 +414,9 @@ static int pci_device_probe(struct device *dev)
struct pci_dev *pci_dev = to_pci_dev(dev);
struct pci_driver *drv = to_pci_driver(dev->driver);
 
+   if (!pci_device_can_probe(pci_dev))
+   return -ENODEV;
+
pci_assign_irq(pci_dev);
 
error = pcibios_alloc_irq(pci_dev);
@@ -421,12 +424,10 @@ static int pci_device_probe(struct device *dev)
return error;
 
pci_dev_get(pci_dev);
-   if (pci_device_can_probe(pci_dev)) {
-   error = __pci_device_probe(drv, pci_dev);
-   if (error) {
-   pcibios_free_irq(pci_dev);
-   pci_dev_put(pci_dev);
-   }
+   error = __pci_device_probe(drv, pci_dev);
+   if (error) {
+   pcibios_free_irq(pci_dev);
+   pci_dev_put(pci_dev);
}
 
return error;
-- 
2.20.1

[PATCH AUTOSEL 5.2 038/171] f2fs: Fix accounting for unusable blocks

[Sasha Levin]

From: Daniel Rosenberg 

[ Upstream commit a4c3ecaaadac5693f555cfef1c9eecf4c39df818 ]

Fixes possible underflows when dealing with unusable blocks.

Signed-off-by: Daniel Rosenberg 
Reviewed-by: Chao Yu 
Signed-off-by: Jaegeuk Kim 
Signed-off-by: Sasha Levin 
---
 fs/f2fs/f2fs.h | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index d1b64cb77326..9e6721e15b24 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1767,8 +1767,12 @@ static inline int inc_valid_block_count(struct 
f2fs_sb_info *sbi,
 
if (!__allow_reserved_blocks(sbi, inode, true))
avail_user_block_count -= F2FS_OPTION(sbi).root_reserved_blocks;
-   if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED)))
-   avail_user_block_count -= sbi->unusable_block_count;
+   if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED))) {
+   if (avail_user_block_count > sbi->unusable_block_count)
+   avail_user_block_count -= sbi->unusable_block_count;
+   else
+   avail_user_block_count = 0;
+   }
if (unlikely(sbi->total_valid_block_count > avail_user_block_count)) {
diff = sbi->total_valid_block_count - avail_user_block_count;
if (diff > *count)
@@ -1968,7 +1972,7 @@ static inline int inc_valid_node_count(struct 
f2fs_sb_info *sbi,
struct inode *inode, bool is_inode)
 {
block_t valid_block_count;
-   unsigned int valid_node_count;
+   unsigned int valid_node_count, user_block_count;
int err;
 
if (is_inode) {
@@ -1995,10 +1999,11 @@ static inline int inc_valid_node_count(struct 
f2fs_sb_info *sbi,
 
if (!__allow_reserved_blocks(sbi, inode, false))
valid_block_count += F2FS_OPTION(sbi).root_reserved_blocks;
+   user_block_count = sbi->user_block_count;
if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED)))
-   valid_block_count += sbi->unusable_block_count;
+   user_block_count -= sbi->unusable_block_count;
 
-   if (unlikely(valid_block_count > sbi->user_block_count)) {
+   if (unlikely(valid_block_count > user_block_count)) {
spin_unlock(>stat_lock);
goto enospc;
}
-- 
2.20.1

[PATCH AUTOSEL 5.2 044/171] i2c: nvidia-gpu: resume ccgx i2c client

[Sasha Levin]

From: Ajay Gupta 

[ Upstream commit 9f2e244d0a39eb437f98324ac315e605e48636db ]

Cypress USB Type-C CCGx controller firmware version 3.1.10
(which is being used in many NVIDIA GPU cards) has known issue of
not triggering interrupt when a USB device is hot plugged to runtime
resume the controller. If any GPU card gets latest kernel with runtime
pm support but does not get latest fixed firmware then also it should
continue to work and therefore a workaround is required to check for
any connector change event

The workaround is to request runtime resume of i2c client
which is UCSI Cypress CCGx driver. CCG driver will call the ISR
for any connector change event only if NVIDIA GPU has old
CCG firmware with the known issue.

Signed-off-by: Ajay Gupta 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
---
 drivers/i2c/busses/i2c-nvidia-gpu.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-nvidia-gpu.c 
b/drivers/i2c/busses/i2c-nvidia-gpu.c
index 1c8f708f212b..ee2412b7459c 100644
--- a/drivers/i2c/busses/i2c-nvidia-gpu.c
+++ b/drivers/i2c/busses/i2c-nvidia-gpu.c
@@ -51,6 +51,7 @@ struct gpu_i2c_dev {
void __iomem *regs;
struct i2c_adapter adapter;
struct i2c_board_info *gpu_ccgx_ucsi;
+   struct i2c_client *ccgx_client;
 };
 
 static void gpu_enable_i2c_bus(struct gpu_i2c_dev *i2cd)
@@ -261,8 +262,6 @@ static const struct property_entry ccgx_props[] = {
 
 static int gpu_populate_client(struct gpu_i2c_dev *i2cd, int irq)
 {
-   struct i2c_client *ccgx_client;
-
i2cd->gpu_ccgx_ucsi = devm_kzalloc(i2cd->dev,
   sizeof(*i2cd->gpu_ccgx_ucsi),
   GFP_KERNEL);
@@ -274,8 +273,8 @@ static int gpu_populate_client(struct gpu_i2c_dev *i2cd, 
int irq)
i2cd->gpu_ccgx_ucsi->addr = 0x8;
i2cd->gpu_ccgx_ucsi->irq = irq;
i2cd->gpu_ccgx_ucsi->properties = ccgx_props;
-   ccgx_client = i2c_new_device(>adapter, i2cd->gpu_ccgx_ucsi);
-   if (!ccgx_client)
+   i2cd->ccgx_client = i2c_new_device(>adapter, i2cd->gpu_ccgx_ucsi);
+   if (!i2cd->ccgx_client)
return -ENODEV;
 
return 0;
@@ -354,6 +353,13 @@ static __maybe_unused int gpu_i2c_resume(struct device 
*dev)
struct gpu_i2c_dev *i2cd = dev_get_drvdata(dev);
 
gpu_enable_i2c_bus(i2cd);
+   /*
+* Runtime resume ccgx client so that it can see for any
+* connector change event. Old ccg firmware has known
+* issue of not triggering interrupt when a device is
+* connected to runtime resume the controller.
+*/
+   pm_request_resume(>ccgx_client->dev);
return 0;
 }
 
-- 
2.20.1

[PATCH AUTOSEL 5.2 039/171] f2fs: Lower threshold for disable_cp_again

[Sasha Levin]

From: Daniel Rosenberg 

[ Upstream commit ae4ad7ea09d32ff1b6fb908ff12f8c1bd5241b29 ]

The existing threshold for allowable holes at checkpoint=disable time is
too high. The OVP space contains reserved segments, which are always in
the form of free segments. These must be subtracted from the OVP value.

The current threshold is meant to be the maximum value of holes of a
single type we can have and still guarantee that we can fill the disk
without failing to find space for a block of a given type.

If the disk is full, ignoring current reserved, which only helps us,
the amount of unused blocks is equal to the OVP area. Of that, there
are reserved segments, which must be free segments, and the rest of the
ovp area, which can come from either free segments or holes. The maximum
possible amount of holes is OVP-reserved.

Now, consider the disk when mounting with checkpoint=disable.
We must be able to fill all available free space with either data or
node blocks. When we start with checkpoint=disable, holes are locked to
their current type. Say we have H of one type of hole, and H+X of the
other. We can fill H of that space with arbitrary typed blocks via SSR.
For the remaining H+X blocks, we may not have any of a given block type
left at all. For instance, if we were to fill the disk entirely with
blocks of the type with fewer holes, the H+X blocks of the opposite type
would not be used. If H+X > OVP-reserved, there would be more holes than
could possibly exist, and we would have failed to find a suitable block
earlier on, leading to a crash in update_sit_entry.

If H+X <= OVP-reserved, then the holes end up effectively masked by the OVP
region in this case.

Signed-off-by: Daniel Rosenberg 
Reviewed-by: Chao Yu 
Signed-off-by: Jaegeuk Kim 
Signed-off-by: Sasha Levin 
---
 fs/f2fs/segment.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index a96b9e964733..8903b61457e7 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -876,7 +876,9 @@ void f2fs_dirty_to_prefree(struct f2fs_sb_info *sbi)
 int f2fs_disable_cp_again(struct f2fs_sb_info *sbi)
 {
struct dirty_seglist_info *dirty_i = DIRTY_I(sbi);
-   block_t ovp = overprovision_segments(sbi) << sbi->log_blocks_per_seg;
+   int ovp_hole_segs =
+   (overprovision_segments(sbi) - reserved_segments(sbi));
+   block_t ovp_holes = ovp_hole_segs << sbi->log_blocks_per_seg;
block_t holes[2] = {0, 0};  /* DATA and NODE */
struct seg_entry *se;
unsigned int segno;
@@ -891,10 +893,10 @@ int f2fs_disable_cp_again(struct f2fs_sb_info *sbi)
}
mutex_unlock(_i->seglist_lock);
 
-   if (holes[DATA] > ovp || holes[NODE] > ovp)
+   if (holes[DATA] > ovp_holes || holes[NODE] > ovp_holes)
return -EAGAIN;
if (is_sbi_flag_set(sbi, SBI_CP_DISABLED_QUICK) &&
-   dirty_segments(sbi) > overprovision_segments(sbi))
+   dirty_segments(sbi) > ovp_hole_segs)
return -EAGAIN;
return 0;
 }
-- 
2.20.1

[PATCH AUTOSEL 5.2 048/171] tty/serial: digicolor: Fix digicolor-usart already registered warning

[Sasha Levin]

From: Kefeng Wang 

[ Upstream commit c7ad9ba0611c53cfe194223db02e3bca015f0674 ]

When modprobe/rmmod/modprobe module, if platform_driver_register() fails,
the kernel complained,

  proc_dir_entry 'driver/digicolor-usart' already registered
  WARNING: CPU: 1 PID: 5636 at fs/proc/generic.c:360 proc_register+0x19d/0x270

Fix this by adding uart_unregister_driver() when platform_driver_register() 
fails.

Reported-by: Hulk Robot 
Signed-off-by: Kefeng Wang 
Acked-by: Baruch Siach 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/tty/serial/digicolor-usart.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/digicolor-usart.c 
b/drivers/tty/serial/digicolor-usart.c
index f460cca139e2..13ac36e2da4f 100644
--- a/drivers/tty/serial/digicolor-usart.c
+++ b/drivers/tty/serial/digicolor-usart.c
@@ -541,7 +541,11 @@ static int __init digicolor_uart_init(void)
if (ret)
return ret;
 
-   return platform_driver_register(_uart_platform);
+   ret = platform_driver_register(_uart_platform);
+   if (ret)
+   uart_unregister_driver(_uart);
+
+   return ret;
 }
 module_init(digicolor_uart_init);
 
-- 
2.20.1

[PATCH AUTOSEL 5.2 046/171] drm/omap: don't check dispc timings for DSI

[Sasha Levin]

From: Sebastian Reichel 

[ Upstream commit ad9df7d91b4a6e8f4b20c2bf539ac09b3b2ad6eb ]

While most display types only forward their VM to the DISPC, this
is not true for DSI. DSI calculates the VM for DISPC based on its
own, but it's not identical. Actually the DSI VM is not even a valid
DISPC VM making this check fail. Let's restore the old behaviour
and avoid checking the DISPC VM for DSI here.

Fixes: 7c27fa57ef31 ("drm/omap: Call dispc timings check operation directly")
Acked-by: Pavel Machek 
Tested-by: Tony Lindgren 
Tested-by: Pavel Machek 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 8712af79a49c..4c43dd282acc 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -384,10 +384,20 @@ static enum drm_mode_status omap_crtc_mode_valid(struct 
drm_crtc *crtc,
int r;
 
drm_display_mode_to_videomode(mode, );
-   r = priv->dispc_ops->mgr_check_timings(priv->dispc, omap_crtc->channel,
-  );
-   if (r)
-   return r;
+
+   /*
+* DSI might not call this, since the supplied mode is not a
+* valid DISPC mode. DSI will calculate and configure the
+* proper DISPC mode later.
+*/
+   if (omap_crtc->pipe->output->next == NULL ||
+   omap_crtc->pipe->output->next->type != OMAP_DISPLAY_TYPE_DSI) {
+   r = priv->dispc_ops->mgr_check_timings(priv->dispc,
+  omap_crtc->channel,
+  );
+   if (r)
+   return r;
+   }
 
/* Check for bandwidth limit */
if (priv->max_bandwidth) {
-- 
2.20.1

[PATCH AUTOSEL 5.2 041/171] drm/crc-debugfs: User irqsafe spinlock in drm_crtc_add_crc_entry

[Sasha Levin]

From: Daniel Vetter 

[ Upstream commit 1882018a70e06376234133e69ede9dd743b4dbd9 ]

We can be called from any context, we need to be prepared.

Noticed this while hacking on vkms, which calls this function from a
normal worker. Which really upsets lockdep.

Cc: Rodrigo Siqueira 
Cc: Tomeu Vizoso 
Cc: Emil Velikov 
Cc: Benjamin Gaignard 
Reviewed-by: Benjamin Gaignard 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190605194556.16744-1-daniel.vet...@ffwll.ch
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_debugfs_crc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
b/drivers/gpu/drm/drm_debugfs_crc.c
index 00e743153e94..1a6a5b78e30f 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -389,8 +389,9 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool 
has_frame,
struct drm_crtc_crc *crc = >crc;
struct drm_crtc_crc_entry *entry;
int head, tail;
+   unsigned long flags;
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
 
/* Caller may not have noticed yet that userspace has stopped reading */
if (!crc->entries) {
@@ -421,7 +422,7 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool 
has_frame,
head = (head + 1) & (DRM_CRC_ENTRIES_NR - 1);
crc->head = head;
 
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 
wake_up_interruptible(>wq);
 
-- 
2.20.1

[PATCH AUTOSEL 5.2 047/171] memstick: Fix error cleanup path of memstick_init

[Sasha Levin]

From: Wang Hai 

[ Upstream commit 65f1a0d39c289bb6fc85635528cd36c4b07f560e ]

If bus_register fails. On its error handling path, it has cleaned up
what it has done. There is no need to call bus_unregister again.
Otherwise, if bus_unregister is called, issues such as null-ptr-deref
will arise.

Syzkaller report this:

kobject_add_internal failed for memstick (error: -12 parent: bus)
BUG: KASAN: null-ptr-deref in sysfs_remove_file_ns+0x1b/0x40 fs/sysfs/file.c:467
Read of size 8 at addr 0078 by task syz-executor.0/4460

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xa9/0x10e lib/dump_stack.c:113
 __kasan_report+0x171/0x18d mm/kasan/report.c:321
 kasan_report+0xe/0x20 mm/kasan/common.c:614
 sysfs_remove_file_ns+0x1b/0x40 fs/sysfs/file.c:467
 sysfs_remove_file include/linux/sysfs.h:519 [inline]
 bus_remove_file+0x6c/0x90 drivers/base/bus.c:145
 remove_probe_files drivers/base/bus.c:599 [inline]
 bus_unregister+0x6e/0x100 drivers/base/bus.c:916 ? 0xc159
 memstick_init+0x7a/0x1000 [memstick]
 do_one_initcall+0xb9/0x3b5 init/main.c:914
 do_init_module+0xe0/0x330 kernel/module.c:3468
 load_module+0x38eb/0x4270 kernel/module.c:3819
 __do_sys_finit_module+0x162/0x190 kernel/module.c:3909
 do_syscall_64+0x72/0x2a0 arch/x86/entry/common.c:298
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Fixes: baf8532a147d ("memstick: initial commit for Sony MemoryStick support")
Reported-by: Hulk Robot 
Signed-off-by: Wang Hai 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin 
---
 drivers/memstick/core/memstick.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/memstick/core/memstick.c b/drivers/memstick/core/memstick.c
index 6cfb293396f2..693ee73eb291 100644
--- a/drivers/memstick/core/memstick.c
+++ b/drivers/memstick/core/memstick.c
@@ -625,13 +625,18 @@ static int __init memstick_init(void)
return -ENOMEM;
 
rc = bus_register(_bus_type);
-   if (!rc)
-   rc = class_register(_host_class);
+   if (rc)
+   goto error_destroy_workqueue;
 
-   if (!rc)
-   return 0;
+   rc = class_register(_host_class);
+   if (rc)
+   goto error_bus_unregister;
+
+   return 0;
 
+error_bus_unregister:
bus_unregister(_bus_type);
+error_destroy_workqueue:
destroy_workqueue(workqueue);
 
return rc;
-- 
2.20.1

[PATCH AUTOSEL 5.2 065/171] iio: adxl372: fix iio_triggered_buffer_{pre,post}enable positions

[Sasha Levin]

From: Alexandru Ardelean 

[ Upstream commit 0e4f0b42f42d88507b48282c8915f502551534e4 ]

The iio_triggered_buffer_{predisable,postenable} functions attach/detach
the poll functions.

For the predisable hook, the disable code should occur before detaching
the poll func, and for the postenable hook, the poll func should be
attached before the enable code.

Signed-off-by: Alexandru Ardelean 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin 
---
 drivers/iio/accel/adxl372.c | 27 ---
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
index 3b84cb243a87..055227cb3d43 100644
--- a/drivers/iio/accel/adxl372.c
+++ b/drivers/iio/accel/adxl372.c
@@ -782,10 +782,14 @@ static int adxl372_buffer_postenable(struct iio_dev 
*indio_dev)
unsigned int mask;
int i, ret;
 
-   ret = adxl372_set_interrupts(st, ADXL372_INT1_MAP_FIFO_FULL_MSK, 0);
+   ret = iio_triggered_buffer_postenable(indio_dev);
if (ret < 0)
return ret;
 
+   ret = adxl372_set_interrupts(st, ADXL372_INT1_MAP_FIFO_FULL_MSK, 0);
+   if (ret < 0)
+   goto err;
+
mask = *indio_dev->active_scan_mask;
 
for (i = 0; i < ARRAY_SIZE(adxl372_axis_lookup_table); i++) {
@@ -793,8 +797,10 @@ static int adxl372_buffer_postenable(struct iio_dev 
*indio_dev)
break;
}
 
-   if (i == ARRAY_SIZE(adxl372_axis_lookup_table))
-   return -EINVAL;
+   if (i == ARRAY_SIZE(adxl372_axis_lookup_table)) {
+   ret = -EINVAL;
+   goto err;
+   }
 
st->fifo_format = adxl372_axis_lookup_table[i].fifo_format;
st->fifo_set_size = bitmap_weight(indio_dev->active_scan_mask,
@@ -814,26 +820,25 @@ static int adxl372_buffer_postenable(struct iio_dev 
*indio_dev)
if (ret < 0) {
st->fifo_mode = ADXL372_FIFO_BYPASSED;
adxl372_set_interrupts(st, 0, 0);
-   return ret;
+   goto err;
}
 
-   return iio_triggered_buffer_postenable(indio_dev);
+   return 0;
+
+err:
+   iio_triggered_buffer_predisable(indio_dev);
+   return ret;
 }
 
 static int adxl372_buffer_predisable(struct iio_dev *indio_dev)
 {
struct adxl372_state *st = iio_priv(indio_dev);
-   int ret;
-
-   ret = iio_triggered_buffer_predisable(indio_dev);
-   if (ret < 0)
-   return ret;
 
adxl372_set_interrupts(st, 0, 0);
st->fifo_mode = ADXL372_FIFO_BYPASSED;
adxl372_configure_fifo(st);
 
-   return 0;
+   return iio_triggered_buffer_predisable(indio_dev);
 }
 
 static const struct iio_buffer_setup_ops adxl372_buffer_ops = {
-- 
2.20.1

[PATCH AUTOSEL 5.2 066/171] serial: imx: fix locking in set_termios()

[Sasha Levin]

From: Sergey Organov 

[ Upstream commit 4e828c3e09201512be5ee162393f334321f7cf01 ]

imx_uart_set_termios() called imx_uart_rts_active(), or
imx_uart_rts_inactive() before taking port->port.lock.

As a consequence, sport->port.mctrl that these functions modify
could have been changed without holding port->port.lock.

Moved locking of port->port.lock above the calls to fix the issue.

Signed-off-by: Sergey Organov 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/tty/serial/imx.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 8b752e895053..10db3e54ac9e 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -383,6 +383,7 @@ static void imx_uart_ucrs_restore(struct imx_port *sport,
 }
 #endif
 
+/* called with port.lock taken and irqs caller dependent */
 static void imx_uart_rts_active(struct imx_port *sport, u32 *ucr2)
 {
*ucr2 &= ~(UCR2_CTSC | UCR2_CTS);
@@ -391,6 +392,7 @@ static void imx_uart_rts_active(struct imx_port *sport, u32 
*ucr2)
mctrl_gpio_set(sport->gpios, sport->port.mctrl);
 }
 
+/* called with port.lock taken and irqs caller dependent */
 static void imx_uart_rts_inactive(struct imx_port *sport, u32 *ucr2)
 {
*ucr2 &= ~UCR2_CTSC;
@@ -400,6 +402,7 @@ static void imx_uart_rts_inactive(struct imx_port *sport, 
u32 *ucr2)
mctrl_gpio_set(sport->gpios, sport->port.mctrl);
 }
 
+/* called with port.lock taken and irqs caller dependent */
 static void imx_uart_rts_auto(struct imx_port *sport, u32 *ucr2)
 {
*ucr2 |= UCR2_CTSC;
@@ -1549,6 +1552,16 @@ imx_uart_set_termios(struct uart_port *port, struct 
ktermios *termios,
old_csize = CS8;
}
 
+   del_timer_sync(>timer);
+
+   /*
+* Ask the core to calculate the divisor for us.
+*/
+   baud = uart_get_baud_rate(port, termios, old, 50, port->uartclk / 16);
+   quot = uart_get_divisor(port, baud);
+
+   spin_lock_irqsave(>port.lock, flags);
+
if ((termios->c_cflag & CSIZE) == CS8)
ucr2 = UCR2_WS | UCR2_SRST | UCR2_IRTS;
else
@@ -1592,16 +1605,6 @@ imx_uart_set_termios(struct uart_port *port, struct 
ktermios *termios,
ucr2 |= UCR2_PROE;
}
 
-   del_timer_sync(>timer);
-
-   /*
-* Ask the core to calculate the divisor for us.
-*/
-   baud = uart_get_baud_rate(port, termios, old, 50, port->uartclk / 16);
-   quot = uart_get_divisor(port, baud);
-
-   spin_lock_irqsave(>port.lock, flags);
-
sport->port.read_status_mask = 0;
if (termios->c_iflag & INPCK)
sport->port.read_status_mask |= (URXD_FRMERR | URXD_PRERR);
-- 
2.20.1

[PATCH AUTOSEL 5.2 061/171] dma-remap: Avoid de-referencing NULL atomic_pool

[Sasha Levin]

From: Florian Fainelli 

[ Upstream commit 4b4b077cbd0a998aebaa72c199e06b8a4c8dcfee ]

With architectures allowing the kernel to be placed almost arbitrarily
in memory (e.g.: ARM64), it is possible to have the kernel resides at
physical addresses above 4GB, resulting in neither the default CMA area,
nor the atomic pool from successfully allocating. This does not prevent
specific peripherals from working though, one example is XHCI, which
still operates correctly.

Trouble comes when the XHCI driver gets suspended and resumed, since we
can now trigger the following NPD:

[   12.664170] usb usb1: root hub lost power or was reset
[   12.669387] usb usb2: root hub lost power or was reset
[   12.674662] Unable to handle kernel NULL pointer dereference at virtual 
address 0008
[   12.682896] pgd = ffc1365a7000
[   12.686386] [0008] *pgd=00013653, *pud=00013653, 
*pmd=
[   12.694897] Internal error: Oops: 9606 [#1] SMP
[   12.699843] Modules linked in:
[   12.702980] CPU: 0 PID: 1499 Comm: pml Not tainted 4.9.135-1.13pre #51
[   12.709577] Hardware name: BCM97268DV (DT)
[   12.713736] task: ffc136bb6540 task.stack: ffc1366cc000
[   12.719740] PC is at addr_in_gen_pool+0x4/0x48
[   12.724253] LR is at __dma_free+0x64/0xbc
[   12.728325] pc : [] lr : [] pstate: 
6145
[   12.735825] sp : ffc1366cf990
[   12.739196] x29: ffc1366cf990 x28: ffc1366cc000
[   12.744608] x27:  x26: ffc13a8568c8
[   12.750020] x25:  x24: ff80098f9000
[   12.755433] x23: 00013a5ff000 x22: ff8009c57000
[   12.760844] x21: ffc13a856810 x20: 
[   12.766255] x19: 1000 x18: 000a
[   12.771667] x17: 007f917553e0 x16: 1002
[   12.777078] x15: 000a36cb x14: ff80898feb77
[   12.782490] x13:  x12: 0030
[   12.787899] x11: fffe x10: ff80098feb7f
[   12.793311] x9 : 05f5e0ff x8 : 65776f702074736f
[   12.798723] x7 : 6c2062756820746f x6 : ff80098febb1
[   12.804134] x5 : ff800809797c x4 : 
[   12.809545] x3 : 00013a5ff000 x2 : 0fff
[   12.814955] x1 : ff8009c57000 x0 : 
[   12.820363]
[   12.821907] Process pml (pid: 1499, stack limit = 0xffc1366cc020)
[   12.828421] Stack: (0xffc1366cf990 to 0xffc1366d)
[   12.834240] f980:   ffc1366cf9e0 
ff80086004d0
[   12.842186] f9a0: ffc13ab08238 0010 ff80097c2218 
ffc13a856810
[   12.850131] f9c0: ff8009c57000 00013a5ff000 0008 
00013a5ff000
[   12.858076] f9e0: ffc1366cfa50 ff80085f9250 ffc13ab08238 
0004
[   12.866021] fa00: ffc13ab08000 ff80097b6000 ffc13ab08130 
0001
[   12.873966] fa20: 0008 ffc13a8568c8  
ffc1366cc000
[   12.881911] fa40: ffc13ab08130 0001 ffc1366cfa90 
ff80085e3de8
[   12.889856] fa60: ffc13ab08238  ffc136b75b00 

[   12.897801] fa80: 0010 ff80089ccb92 ffc1366cfac0 
ff80084ad040
[   12.905746] faa0: ffc13a856810  ff80084ad004 
ff80084b91a8
[   12.913691] fac0: ffc1366cfae0 ff80084b91b4 ffc13a856810 
ff80080db5cc
[   12.921636] fae0: ffc1366cfb20 ff80084b96bc ffc13a856810 
0010
[   12.929581] fb00: ffc13a856870  ffc13a856810 
ff800984d2b8
[   12.937526] fb20: ffc1366cfb50 ff80084baa70 ff8009932ad0 
ff800984d260
[   12.945471] fb40: 0010 0002eff0a065 ffc1366cfbb0 
ff80084bafbc
[   12.953415] fb60: 0010 0003 ff80098fe000 

[   12.961360] fb80: ff80097b6000 ff80097b6dc8 ff80098c12b8 
ff80098c12f8
[   12.969306] fba0: ff8008842000 ff80097b6dc8 ffc1366cfbd0 
ff80080e0d88
[   12.977251] fbc0: fffb ff80080e10bc ffc1366cfc60 
ff80080e16a8
[   12.985196] fbe0:  0003 ff80097b6000 
ff80098fe9f0
[   12.993140] fc00: ff80097d4000 ff8008983802 0123 
0040
[   13.001085] fc20: ff8008842000 ffc1366cc000 ff80089803c2 

[   13.009029] fc40:   ffc1366cfc60 
00040987
[   13.016974] fc60: ffc1366cfcc0 ff80080dfd08 0003 
0004
[   13.024919] fc80: 0003 ff80098fea08 ffc136577ec0 
ff80089803c2
[   13.032864] fca0: 0123 0001 00050002 
00040987
[   13.040809] fcc0: ffc1366cfd00 ff80083a89d4 0004 
ffc136577ec0
[   13.048754] fce0: ffc136610cc0 ffea ffc1366cfeb0 
ffc136610cd8
[   13.056700] fd00: ffc1366cfd10 ff800822a614 

[PATCH AUTOSEL 5.2 064/171] iio:core: Fix bug in length of event info_mask and catch unhandled bits set in masks.

[Sasha Levin]

From: Young Xiao <92siuy...@gmail.com>

[ Upstream commit 936d3e536dcf88ce80d27bdb637009b13dba6d8c ]

The incorrect limit for the for_each_set_bit loop was noticed whilst fixing
this other case.  Note that as we only have 3 possible entries a the moment
and the value was set to 4, the bug would not have any effect currently.
It will bite fairly soon though, so best fix it now.

See commit ef4b4856593f ("iio:core: Fix bug in length of event info_mask and
catch unhandled bits set in masks.") for details.

Signed-off-by: Young Xiao <92siuy...@gmail.com>
Reviewed-by: Alexandru Ardelean 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin 
---
 drivers/iio/industrialio-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 245b5844028d..2da099badce6 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -1104,6 +1104,8 @@ static int iio_device_add_info_mask_type_avail(struct 
iio_dev *indio_dev,
char *avail_postfix;
 
for_each_set_bit(i, infomask, sizeof(*infomask) * 8) {
+   if (i >= ARRAY_SIZE(iio_chan_info_postfix))
+   return -EINVAL;
avail_postfix = kasprintf(GFP_KERNEL,
  "%s_available",
  iio_chan_info_postfix[i]);
-- 
2.20.1

[PATCH AUTOSEL 5.2 073/171] mmc: sdhci: sdhci-pci-o2micro: Check if controller supports 8-bit width

[Sasha Levin]

From: Raul E Rangel 

[ Upstream commit de23f0b757766d9fae59df97da6e8bdc5b231351 ]

The O2 controller supports 8-bit EMMC access.

JESD84-B51 section A.6.3.a defines the bus testing procedure that
`mmc_select_bus_width()` implements. This is used to determine the actual
bus width of the eMMC.

Signed-off-by: Raul E Rangel 
Acked-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin 
---
 drivers/mmc/host/sdhci-pci-o2micro.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pci-o2micro.c 
b/drivers/mmc/host/sdhci-pci-o2micro.c
index dd21315922c8..9dc4548271b4 100644
--- a/drivers/mmc/host/sdhci-pci-o2micro.c
+++ b/drivers/mmc/host/sdhci-pci-o2micro.c
@@ -395,11 +395,21 @@ int sdhci_pci_o2_probe_slot(struct sdhci_pci_slot *slot)
 {
struct sdhci_pci_chip *chip;
struct sdhci_host *host;
-   u32 reg;
+   u32 reg, caps;
int ret;
 
chip = slot->chip;
host = slot->host;
+
+   caps = sdhci_readl(host, SDHCI_CAPABILITIES);
+
+   /*
+* mmc_select_bus_width() will test the bus to determine the actual bus
+* width.
+*/
+   if (caps & SDHCI_CAN_DO_8BIT)
+   host->mmc->caps |= MMC_CAP_8_BIT_DATA;
+
switch (chip->pdev->device) {
case PCI_DEVICE_ID_O2_SDS0:
case PCI_DEVICE_ID_O2_SEABIRD0:
-- 
2.20.1

[PATCH AUTOSEL 5.2 071/171] kvm: vmx: fix limit checking in get_vmx_mem_address()

[Sasha Levin]

From: Eugene Korenevsky 

[ Upstream commit c1a9acbc5295e278d788e9f7510f543bc9864fa2 ]

Intel SDM vol. 3, 5.3:
The processor causes a
general-protection exception (or, if the segment is SS, a stack-fault
exception) any time an attempt is made to access the following addresses
in a segment:
- A byte at an offset greater than the effective limit
- A word at an offset greater than the (effective-limit – 1)
- A doubleword at an offset greater than the (effective-limit – 3)
- A quadword at an offset greater than the (effective-limit – 7)

Therefore, the generic limit checking error condition must be

exn = (off > limit + 1 - access_len) = (off + access_len - 1 > limit)

but not

exn = (off + access_len > limit)

as for now.

Also avoid integer overflow of `off` at 32-bit KVM by casting it to u64.

Note: access length is currently sizeof(u64) which is incorrect. This
will be fixed in the subsequent patch.

Signed-off-by: Eugene Korenevsky 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Sasha Levin 
---
 arch/x86/kvm/vmx/nested.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 46af3a5e9209..7958189ee702 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -4115,7 +4115,7 @@ int get_vmx_mem_address(struct kvm_vcpu *vcpu, unsigned 
long exit_qualification,
 */
if (!(s.base == 0 && s.limit == 0x &&
 ((s.type & 8) || !(s.type & 4
-   exn = exn || (off + sizeof(u64) > s.limit);
+   exn = exn || ((u64)off + sizeof(u64) - 1 > s.limit);
}
if (exn) {
kvm_queue_exception_e(vcpu,
-- 
2.20.1

[PATCH AUTOSEL 5.2 063/171] platform/x86: asus-wmi: Increase input buffer size of WMI methods

[Sasha Levin]

From: Yurii Pavlovskyi 

[ Upstream commit 98e865a522983f2afde075648ec9d15ea4bb9194 ]

The asus-nb-wmi driver is matched by WMI alias but fails to load on TUF
Gaming series laptops producing multiple ACPI errors in the kernel log.

The input buffer for WMI method invocation size is 2 dwords, whereas
3 are expected by this model.

FX505GM:
..
Method (WMNB, 3, Serialized)
{
P8XH (Zero, 0x11)
CreateDWordField (Arg2, Zero, IIA0)
CreateDWordField (Arg2, 0x04, IIA1)
CreateDWordField (Arg2, 0x08, IIA2)
Local0 = (Arg1 & 0x)
...

Compare with older K54C:
...
Method (WMNB, 3, NotSerialized)
{
CreateDWordField (Arg2, 0x00, IIA0)
CreateDWordField (Arg2, 0x04, IIA1)
Local0 = (Arg1 & 0x)
...

Increase buffer size to 3 dwords. No negative consequences of this change
are expected, as the input buffer size is not verified. The original
function is replaced by a wrapper for a new method passing value 0 for the
last parameter. The new function will be used to control RGB keyboard
backlight.

Signed-off-by: Yurii Pavlovskyi 
Reviewed-by: Daniel Drake 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Sasha Levin 
---
 drivers/platform/x86/asus-wmi.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 9b18a184e0aa..abfa99d18fea 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -85,6 +85,7 @@ static bool ashs_present(void)
 struct bios_args {
u32 arg0;
u32 arg1;
+   u32 arg2; /* At least TUF Gaming series uses 3 dword input buffer. */
 } __packed;
 
 /*
@@ -211,11 +212,13 @@ static void asus_wmi_input_exit(struct asus_wmi *asus)
asus->inputdev = NULL;
 }
 
-int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1, u32 *retval)
+static int asus_wmi_evaluate_method3(u32 method_id,
+   u32 arg0, u32 arg1, u32 arg2, u32 *retval)
 {
struct bios_args args = {
.arg0 = arg0,
.arg1 = arg1,
+   .arg2 = arg2,
};
struct acpi_buffer input = { (acpi_size) sizeof(args),  };
struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
@@ -247,6 +250,11 @@ int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 
arg1, u32 *retval)
 
return 0;
 }
+
+int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1, u32 *retval)
+{
+   return asus_wmi_evaluate_method3(method_id, arg0, arg1, 0, retval);
+}
 EXPORT_SYMBOL_GPL(asus_wmi_evaluate_method);
 
 static int asus_wmi_evaluate_method_agfn(const struct acpi_buffer args)
-- 
2.20.1

[PATCH AUTOSEL 5.2 067/171] serial: uartps: Use the same dynamic major number for all ports

[Sasha Levin]

From: Shubhrajyoti Datta 

[ Upstream commit ab262666018de6f4e206b021386b93ed0c164316 ]

Let kernel to find out major number dynamically for the first device and
then reuse it for other instances.
This fixes the issue that each uart is registered with a
different major number.

After the patch:
crw---1 root root  253,   0 Jun 10 08:31 /dev/ttyPS0
crw--w1 root root  253,   1 Jan  1  1970 /dev/ttyPS1

Fixes: 024ca329bfb9 ("serial: uartps: Register own uart console and driver 
structures")
Signed-off-by: Shubhrajyoti Datta 
Signed-off-by: Michal Simek 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/tty/serial/xilinx_uartps.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c 
b/drivers/tty/serial/xilinx_uartps.c
index 605354fd60b1..9dcc4d855ddd 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -29,12 +29,12 @@
 
 #define CDNS_UART_TTY_NAME "ttyPS"
 #define CDNS_UART_NAME "xuartps"
-#define CDNS_UART_MAJOR0   /* use dynamic node allocation 
*/
 #define CDNS_UART_FIFO_SIZE64  /* FIFO size */
 #define CDNS_UART_REGISTER_SPACE   0x1000
 
 /* Rx Trigger level */
 static int rx_trigger_level = 56;
+static int uartps_major;
 module_param(rx_trigger_level, uint, S_IRUGO);
 MODULE_PARM_DESC(rx_trigger_level, "Rx trigger level, 1-63 bytes");
 
@@ -1517,7 +1517,7 @@ static int cdns_uart_probe(struct platform_device *pdev)
cdns_uart_uart_driver->owner = THIS_MODULE;
cdns_uart_uart_driver->driver_name = driver_name;
cdns_uart_uart_driver->dev_name = CDNS_UART_TTY_NAME;
-   cdns_uart_uart_driver->major = CDNS_UART_MAJOR;
+   cdns_uart_uart_driver->major = uartps_major;
cdns_uart_uart_driver->minor = cdns_uart_data->id;
cdns_uart_uart_driver->nr = 1;
 
@@ -1546,6 +1546,7 @@ static int cdns_uart_probe(struct platform_device *pdev)
goto err_out_id;
}
 
+   uartps_major = cdns_uart_uart_driver->tty_driver->major;
cdns_uart_data->cdns_uart_driver = cdns_uart_uart_driver;
 
/*
-- 
2.20.1

[PATCH AUTOSEL 5.2 074/171] KVM: nVMX: Intercept VMWRITEs to GUEST_{CS,SS}_AR_BYTES

[Sasha Levin]

From: Sean Christopherson 

[ Upstream commit b643780562af5378ef7fe731c65b8f93e49c59c6 ]

VMMs frequently read the guest's CS and SS AR bytes to detect 64-bit
mode and CPL respectively, but effectively never write said fields once
the VM is initialized.  Intercepting VMWRITEs for the two fields saves
~55 cycles in copy_shadow_to_vmcs12().

Because some Intel CPUs, e.g. Haswell, drop the reserved bits of the
guest access rights fields on VMWRITE, exposing the fields to L1 for
VMREAD but not VMWRITE leads to inconsistent behavior between L1 and L2.
On hardware that drops the bits, L1 will see the stripped down value due
to reading the value from hardware, while L2 will see the full original
value as stored by KVM.  To avoid such an inconsistency, emulate the
behavior on all CPUS, but only for intercepted VMWRITEs so as to avoid
introducing pointless latency into copy_shadow_to_vmcs12(), e.g. if the
emulation were added to vmcs12_write_any().

Since the AR_BYTES emulation is done only for intercepted VMWRITE, if a
future patch (re)exposed AR_BYTES for both VMWRITE and VMREAD, then KVM
would end up with incosistent behavior on pre-Haswell hardware, e.g. KVM
would drop the reserved bits on intercepted VMWRITE, but direct VMWRITE
to the shadow VMCS would not drop the bits.  Add a WARN in the shadow
field initialization to detect any attempt to expose an AR_BYTES field
without updating vmcs12_write_any().

Note, emulation of the AR_BYTES reserved bit behavior is based on a
patch[1] from Jim Mattson that applied the emulation to all writes to
vmcs12 so that live migration across different generations of hardware
would not introduce divergent behavior.  But given that live migration
of nested state has already been enabled, that ship has sailed (not to
mention that no sane VMM will be affected by this behavior).

[1] https://patchwork.kernel.org/patch/10483321/

Cc: Jim Mattson 
Cc: Liran Alon 
Signed-off-by: Sean Christopherson 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Sasha Levin 
---
 arch/x86/kvm/vmx/nested.c | 15 +++
 arch/x86/kvm/vmx/vmcs_shadow_fields.h |  4 ++--
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 7958189ee702..4c0aa676f843 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -91,6 +91,10 @@ static void init_vmcs_shadow_fields(void)
pr_err("Missing field from shadow_read_write_field 
%x\n",
   field + 1);
 
+   WARN_ONCE(field >= GUEST_ES_AR_BYTES &&
+ field <= GUEST_TR_AR_BYTES,
+ "Update vmcs12_write_any() to expose AR_BYTES RW");
+
/*
 * PML and the preemption timer can be emulated, but the
 * processor cannot vmwrite to fields that don't exist
@@ -4496,6 +4500,17 @@ static int handle_vmwrite(struct kvm_vcpu *vcpu)
vmcs12 = get_shadow_vmcs12(vcpu);
}
 
+   /*
+* Some Intel CPUs intentionally drop the reserved bits of the AR byte
+* fields on VMWRITE.  Emulate this behavior to ensure consistent KVM
+* behavior regardless of the underlying hardware, e.g. if an AR_BYTE
+* field is intercepted for VMWRITE but not VMREAD (in L1), then VMREAD
+* from L1 will return a different value than VMREAD from L2 (L1 sees
+* the stripped down value, L2 sees the full value as stored by KVM).
+*/
+   if (field >= GUEST_ES_AR_BYTES && field <= GUEST_TR_AR_BYTES)
+   field_value &= 0x1f0ff;
+
if (vmcs12_write_any(vmcs12, field, field_value) < 0)
return nested_vmx_failValid(vcpu,
VMXERR_UNSUPPORTED_VMCS_COMPONENT);
diff --git a/arch/x86/kvm/vmx/vmcs_shadow_fields.h 
b/arch/x86/kvm/vmx/vmcs_shadow_fields.h
index 132432f375c2..97dd5295be31 100644
--- a/arch/x86/kvm/vmx/vmcs_shadow_fields.h
+++ b/arch/x86/kvm/vmx/vmcs_shadow_fields.h
@@ -40,14 +40,14 @@ SHADOW_FIELD_RO(VM_EXIT_INSTRUCTION_LEN)
 SHADOW_FIELD_RO(IDT_VECTORING_INFO_FIELD)
 SHADOW_FIELD_RO(IDT_VECTORING_ERROR_CODE)
 SHADOW_FIELD_RO(VM_EXIT_INTR_ERROR_CODE)
+SHADOW_FIELD_RO(GUEST_CS_AR_BYTES)
+SHADOW_FIELD_RO(GUEST_SS_AR_BYTES)
 SHADOW_FIELD_RW(CPU_BASED_VM_EXEC_CONTROL)
 SHADOW_FIELD_RW(EXCEPTION_BITMAP)
 SHADOW_FIELD_RW(VM_ENTRY_EXCEPTION_ERROR_CODE)
 SHADOW_FIELD_RW(VM_ENTRY_INTR_INFO_FIELD)
 SHADOW_FIELD_RW(VM_ENTRY_INSTRUCTION_LEN)
 SHADOW_FIELD_RW(TPR_THRESHOLD)
-SHADOW_FIELD_RW(GUEST_CS_AR_BYTES)
-SHADOW_FIELD_RW(GUEST_SS_AR_BYTES)
 SHADOW_FIELD_RW(GUEST_INTERRUPTIBILITY_INFO)
 SHADOW_FIELD_RW(VMX_PREEMPTION_TIMER_VALUE)
 
-- 
2.20.1

[PATCH AUTOSEL 5.2 076/171] drm/msm/adreno: Ensure that the zap shader region is big enough

[Sasha Levin]

From: Jordan Crouse 

[ Upstream commit 6672e11cad662ce6631e04c38f92a140a99c042c ]

Before loading the zap shader we should ensure that the reserved memory
region is big enough to hold the loaded file.

Signed-off-by: Jordan Crouse 
Reviewed-by: Bjorn Andersson 
Reviewed-by: Jeffrey Hugo 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index a9c0ac937b00..9acbbc0f3232 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -56,7 +56,6 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const 
char *fwname,
return ret;
 
mem_phys = r.start;
-   mem_size = resource_size();
 
/* Request the MDT file for the firmware */
fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
@@ -72,6 +71,13 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const 
char *fwname,
goto out;
}
 
+   if (mem_size > resource_size()) {
+   DRM_DEV_ERROR(dev,
+   "memory region is too small to load the MDT\n");
+   ret = -E2BIG;
+   goto out;
+   }
+
/* Allocate memory for the firmware image */
mem_region = memremap(mem_phys, mem_size,  MEMREMAP_WC);
if (!mem_region) {
-- 
2.20.1

[PATCH AUTOSEL 5.2 083/171] i2c: stm32f7: fix the get_irq error cases

[Sasha Levin]

From: Fabrice Gasnier 

[ Upstream commit 79b4499524ed659fb76323efc30f3dc03967c88f ]

During probe, return the "get_irq" error value instead of -EINVAL which
allows the driver to be deferred probed if needed.
Fix also the case where of_irq_get() returns a negative value.
Note :
On failure of_irq_get() returns 0 or a negative value while
platform_get_irq() returns a negative value.

Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver")
Reviewed-by: Pierre-Yves MORDRET 
Signed-off-by: Fabien Dessenne 
Signed-off-by: Fabrice Gasnier 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
---
 drivers/i2c/busses/i2c-stm32f7.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index 48337bef5b87..3d90c0bb049e 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -1816,15 +1815,14 @@ static struct i2c_algorithm stm32f7_i2c_algo = {
 
 static int stm32f7_i2c_probe(struct platform_device *pdev)
 {
-   struct device_node *np = pdev->dev.of_node;
struct stm32f7_i2c_dev *i2c_dev;
const struct stm32f7_i2c_setup *setup;
struct resource *res;
-   u32 irq_error, irq_event, clk_rate, rise_time, fall_time;
+   u32 clk_rate, rise_time, fall_time;
struct i2c_adapter *adap;
struct reset_control *rst;
dma_addr_t phy_addr;
-   int ret;
+   int irq_error, irq_event, ret;
 
i2c_dev = devm_kzalloc(>dev, sizeof(*i2c_dev), GFP_KERNEL);
if (!i2c_dev)
@@ -1836,16 +1834,20 @@ static int stm32f7_i2c_probe(struct platform_device 
*pdev)
return PTR_ERR(i2c_dev->base);
phy_addr = (dma_addr_t)res->start;
 
-   irq_event = irq_of_parse_and_map(np, 0);
-   if (!irq_event) {
-   dev_err(>dev, "IRQ event missing or invalid\n");
-   return -EINVAL;
+   irq_event = platform_get_irq(pdev, 0);
+   if (irq_event <= 0) {
+   if (irq_event != -EPROBE_DEFER)
+   dev_err(>dev, "Failed to get IRQ event: %d\n",
+   irq_event);
+   return irq_event ? : -ENOENT;
}
 
-   irq_error = irq_of_parse_and_map(np, 1);
-   if (!irq_error) {
-   dev_err(>dev, "IRQ error missing or invalid\n");
-   return -EINVAL;
+   irq_error = platform_get_irq(pdev, 1);
+   if (irq_error <= 0) {
+   if (irq_error != -EPROBE_DEFER)
+   dev_err(>dev, "Failed to get IRQ error: %d\n",
+   irq_error);
+   return irq_error ? : -ENOENT;
}
 
i2c_dev->clk = devm_clk_get(>dev, NULL);
-- 
2.20.1

[PATCH AUTOSEL 5.2 084/171] iio: st_accel: fix iio_triggered_buffer_{pre,post}enable positions

[Sasha Levin]

From: Alexandru Ardelean 

[ Upstream commit 05b8bcc96278c9ef927a6f25a98e233e55de42e1 ]

The iio_triggered_buffer_{predisable,postenable} functions attach/detach
the poll functions.

For the predisable hook, the disable code should occur before detaching
the poll func, and for the postenable hook, the poll func should be
attached before the enable code.

Signed-off-by: Alexandru Ardelean 
Acked-by: Denis Ciocca 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin 
---
 drivers/iio/accel/st_accel_buffer.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/iio/accel/st_accel_buffer.c 
b/drivers/iio/accel/st_accel_buffer.c
index 54f2ae91f614..0205c0167cdd 100644
--- a/drivers/iio/accel/st_accel_buffer.c
+++ b/drivers/iio/accel/st_accel_buffer.c
@@ -45,17 +45,19 @@ static int st_accel_buffer_postenable(struct iio_dev 
*indio_dev)
goto allocate_memory_error;
}
 
-   err = st_sensors_set_axis_enable(indio_dev,
-   (u8)indio_dev->active_scan_mask[0]);
+   err = iio_triggered_buffer_postenable(indio_dev);
if (err < 0)
goto st_accel_buffer_postenable_error;
 
-   err = iio_triggered_buffer_postenable(indio_dev);
+   err = st_sensors_set_axis_enable(indio_dev,
+   (u8)indio_dev->active_scan_mask[0]);
if (err < 0)
-   goto st_accel_buffer_postenable_error;
+   goto st_sensors_set_axis_enable_error;
 
return err;
 
+st_sensors_set_axis_enable_error:
+   iio_triggered_buffer_predisable(indio_dev);
 st_accel_buffer_postenable_error:
kfree(adata->buffer_data);
 allocate_memory_error:
@@ -64,20 +66,22 @@ static int st_accel_buffer_postenable(struct iio_dev 
*indio_dev)
 
 static int st_accel_buffer_predisable(struct iio_dev *indio_dev)
 {
-   int err;
+   int err, err2;
struct st_sensor_data *adata = iio_priv(indio_dev);
 
-   err = iio_triggered_buffer_predisable(indio_dev);
-   if (err < 0)
-   goto st_accel_buffer_predisable_error;
-
err = st_sensors_set_axis_enable(indio_dev, ST_SENSORS_ENABLE_ALL_AXIS);
if (err < 0)
goto st_accel_buffer_predisable_error;
 
err = st_sensors_set_enable(indio_dev, false);
+   if (err < 0)
+   goto st_accel_buffer_predisable_error;
 
 st_accel_buffer_predisable_error:
+   err2 = iio_triggered_buffer_predisable(indio_dev);
+   if (!err)
+   err = err2;
+
kfree(adata->buffer_data);
return err;
 }
-- 
2.20.1

[PATCH AUTOSEL 5.2 080/171] staging: ks7010: Fix build error

[Sasha Levin]

From: YueHaibing 

[ Upstream commit 3e5bc68fa596874500e8c718605aa44d5e42a34c ]

when CRYPTO is m and KS7010 is y, building fails:

drivers/staging/ks7010/ks_hostif.o: In function `michael_mic.constprop.13':
ks_hostif.c:(.text+0x560): undefined reference to `crypto_alloc_shash'
ks_hostif.c:(.text+0x580): undefined reference to `crypto_shash_setkey'
ks_hostif.c:(.text+0x5e0): undefined reference to `crypto_destroy_tfm'
ks_hostif.c:(.text+0x614): undefined reference to `crypto_shash_update'
ks_hostif.c:(.text+0x62c): undefined reference to `crypto_shash_update'
ks_hostif.c:(.text+0x648): undefined reference to `crypto_shash_finup'

Add CRYPTO and CRYPTO_HASH dependencies to fix this.

Reported-by: Hulk Robot 
Fixes: 8b523f20417d ("staging: ks7010: removed custom Michael MIC 
implementation.")
Signed-off-by: YueHaibing 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/staging/ks7010/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/ks7010/Kconfig b/drivers/staging/ks7010/Kconfig
index 0987fdc2f70d..9d7cbc8b12df 100644
--- a/drivers/staging/ks7010/Kconfig
+++ b/drivers/staging/ks7010/Kconfig
@@ -5,6 +5,7 @@ config KS7010
select WIRELESS_EXT
select WEXT_PRIV
select FW_LOADER
+   depends on CRYPTO && CRYPTO_HASH
help
  This is a driver for KeyStream KS7010 based SDIO WIFI cards. It is
  found on at least later Spectec SDW-821 (FCC-ID "S2Y-WLAN-11G-K" only,
-- 
2.20.1

[PATCH AUTOSEL 5.2 095/171] fixdep: check return value of printf() and putchar()

[Sasha Levin]

From: Masahiro Yamada 

[ Upstream commit 6f9ac9f4427ec0470ccffbf852cfaf326677cc21 ]

When there is not enough space on your storage device, the build will
fail with 'No space left on device' error message.

The reason is obvious from the message, so you will free up some disk
space, then you will resume the build.

However, sometimes you may still see a mysterious error message:

  unterminated call to function 'wildcard': missing ')'.

If you run out of the disk space, fixdep may end up with generating
incomplete .*.cmd files.

For example, if the disk-full error occurs while fixdep is running
print_dep(), the .*.cmd might be truncated like this:

   $(wildcard include/config/

When you run 'make' next time, this broken .*.cmd will be included,
then Make will terminate parsing since it is a wrong syntax.

Once this happens, you need to run 'make clean' or delete the broken
.*.cmd file manually.

Even if you do not see any error message, the .*.cmd files after any
error could be potentially incomplete, and unreliable. You may miss
the re-compilation due to missing header dependency.

If printf() cannot output the string for disk shortage or whatever
reason, it returns a negative value, but currently fixdep does not
check it at all. Consequently, fixdep *successfully* generates a
broken .*.cmd file. Make never notices that since fixdep exits with 0,
which means success.

Given the intended usage of fixdep, it must respect the return value
of not only malloc(), but also printf() and putchar().

This seems a long-standing issue since the introduction of fixdep.

In old days, Kbuild tried to provide an extra safety by letting fixdep
output to a temporary file and renaming it after everything is done:

  scripts/basic/fixdep $(depfile) $@ '$(make-cmd)' > $(dot-target).tmp;\
  rm -f $(depfile);\
  mv -f $(dot-target).tmp $(dot-target).cmd)

It was no help to avoid the current issue; fixdep successfully created
a truncated tmp file, which would be renamed to a .*.cmd file.

This problem should be fixed by propagating the error status to the
build system because:

[1] Since commit 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special
target"), Make will delete the target automatically on any failure
in the recipe.

[2] Since commit 392885ee82d3 ("kbuild: let fixdep directly write to
.*.cmd files"), .*.cmd file is included only when the corresponding
target already exists.

Signed-off-by: Masahiro Yamada 
Signed-off-by: Sasha Levin 
---
 scripts/basic/fixdep.c | 51 +-
 1 file changed, 41 insertions(+), 10 deletions(-)

diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index facbd603adf6..9ba47b0a47b9 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -99,6 +99,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -109,6 +110,36 @@ static void usage(void)
exit(1);
 }
 
+/*
+ * In the intended usage of this program, the stdout is redirected to .*.cmd
+ * files. The return value of printf() and putchar() must be checked to catch
+ * any error, e.g. "No space left on device".
+ */
+static void xprintf(const char *format, ...)
+{
+   va_list ap;
+   int ret;
+
+   va_start(ap, format);
+   ret = vprintf(format, ap);
+   if (ret < 0) {
+   perror("fixdep");
+   exit(1);
+   }
+   va_end(ap);
+}
+
+static void xputchar(int c)
+{
+   int ret;
+
+   ret = putchar(c);
+   if (ret == EOF) {
+   perror("fixdep");
+   exit(1);
+   }
+}
+
 /*
  * Print out a dependency path from a symbol name
  */
@@ -116,7 +147,7 @@ static void print_dep(const char *m, int slen, const char 
*dir)
 {
int c, prev_c = '/', i;
 
-   printf("$(wildcard %s/", dir);
+   xprintf("$(wildcard %s/", dir);
for (i = 0; i < slen; i++) {
c = m[i];
if (c == '_')
@@ -124,10 +155,10 @@ static void print_dep(const char *m, int slen, const char 
*dir)
else
c = tolower(c);
if (c != '/' || prev_c != '/')
-   putchar(c);
+   xputchar(c);
prev_c = c;
}
-   printf(".h) \\\n");
+   xprintf(".h) \\\n");
 }
 
 struct item {
@@ -324,13 +355,13 @@ static void parse_dep_file(char *m, const char *target)
 */
if (!saw_any_target) {
saw_any_target = 1;
-   printf("source_%s := %s\n\n",
-  target, m);
-   printf("deps_%s := \\\n", target);
+   xprintf("source_%s := %s\n\n",
+   target, m);
+   

[PATCH AUTOSEL 5.2 077/171] powerpc/pci/of: Fix OF flags parsing for 64bit BARs

[Sasha Levin]

From: Alexey Kardashevskiy 

[ Upstream commit df5be5be8735ef2ae80d5ae1f2453cd81a035c4b ]

When the firmware does PCI BAR resource allocation, it passes the assigned
addresses and flags (prefetch/64bit/...) via the "reg" property of
a PCI device device tree node so the kernel does not need to do
resource allocation.

The flags are stored in resource::flags - the lower byte stores
PCI_BASE_ADDRESS_SPACE/etc bits and the other bytes are IORESOURCE_IO/etc.
Some flags from PCI_BASE_ADDRESS_xxx and IORESOURCE_xxx are duplicated,
such as PCI_BASE_ADDRESS_MEM_PREFETCH/PCI_BASE_ADDRESS_MEM_TYPE_64/etc.
When parsing the "reg" property, we copy the prefetch flag but we skip
on PCI_BASE_ADDRESS_MEM_TYPE_64 which leaves the flags out of sync.

The missing IORESOURCE_MEM_64 flag comes into play under 2 conditions:
1. we remove PCI_PROBE_ONLY for pseries (by hacking pSeries_setup_arch()
or by passing "/chosen/linux,pci-probe-only");
2. we request resource alignment (by passing pci=resource_alignment=
via the kernel cmd line to request PAGE_SIZE alignment or defining
ppc_md.pcibios_default_alignment which returns anything but 0). Note that
the alignment requests are ignored if PCI_PROBE_ONLY is enabled.

With 1) and 2), the generic PCI code in the kernel unconditionally
decides to:
- reassign the BARs in pci_specified_resource_alignment() (works fine)
- write new BARs to the device - this fails for 64bit BARs as the generic
code looks at IORESOURCE_MEM_64 (not set) and writes only lower 32bits
of the BAR and leaves the upper 32bit unmodified which breaks BAR mapping
in the hypervisor.

This fixes the issue by copying the flag. This is useful if we want to
enforce certain BAR alignment per platform as handling subpage sized BARs
is proven to cause problems with hotplug (SLOF already aligns BARs to 64k).

Signed-off-by: Alexey Kardashevskiy 
Reviewed-by: Sam Bobroff 
Reviewed-by: Oliver O'Halloran 
Reviewed-by: Shawn Anastasio 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/pci_of_scan.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/kernel/pci_of_scan.c 
b/arch/powerpc/kernel/pci_of_scan.c
index 24522aa37665..c63c53b37e8e 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -42,6 +42,8 @@ unsigned int pci_parse_of_flags(u32 addr0, int bridge)
if (addr0 & 0x0200) {
flags = IORESOURCE_MEM | PCI_BASE_ADDRESS_SPACE_MEMORY;
flags |= (addr0 >> 22) & PCI_BASE_ADDRESS_MEM_TYPE_64;
+   if (flags & PCI_BASE_ADDRESS_MEM_TYPE_64)
+   flags |= IORESOURCE_MEM_64;
flags |= (addr0 >> 28) & PCI_BASE_ADDRESS_MEM_TYPE_1M;
if (addr0 & 0x4000)
flags |= IORESOURCE_PREFETCH
-- 
2.20.1

[PATCH AUTOSEL 5.2 088/171] phy: meson-g12a-usb3-pcie: disable locking for cr_regmap

[Sasha Levin]

From: Neil Armstrong 

[ Upstream commit 5fc2aa3ec9efad97dd7c316f3c8e4c6268bbed9b ]

Locking is not needed for the phy_g12a_usb3_pcie_cr_bus_read/write() and
currently it causes the following BUG because of the usage of the
regmap_read_poll_timeout() running in spinlock_irq, configured by regmap 
fast_io.

Simply disable locking in the cr_regmap config since it's only used from the
PHY init callback function.

BUG: sleeping function called from invalid context at 
drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c:85
in_atomic(): 1, irqs_disabled(): 128, pid: 60, name: kworker/3:1
[snip]
Workqueue: events deferred_probe_work_func
Call trace:
 dump_backtrace+0x0/0x190
 show_stack+0x14/0x20
 dump_stack+0x90/0xb4
 ___might_sleep+0xec/0x110
 __might_sleep+0x50/0x88
 phy_g12a_usb3_pcie_cr_bus_addr.isra.0+0x80/0x1a8
 phy_g12a_usb3_pcie_cr_bus_read+0x34/0x1d8
 _regmap_read+0x60/0xe0
 _regmap_update_bits+0xc4/0x110
 regmap_update_bits_base+0x60/0x90
 phy_g12a_usb3_pcie_init+0xdc/0x210
 phy_init+0x74/0xd0
 dwc3_meson_g12a_probe+0x2cc/0x4d0
 platform_drv_probe+0x50/0xa0
 really_probe+0x20c/0x3b8
 driver_probe_device+0x68/0x150
 __device_attach_driver+0xa8/0x170
 bus_for_each_drv+0x64/0xc8
 __device_attach+0xd8/0x158
 device_initial_probe+0x10/0x18
 bus_probe_device+0x90/0x98
 deferred_probe_work_func+0x94/0xe8
 process_one_work+0x1e0/0x338
 worker_thread+0x230/0x458
 kthread+0x134/0x138
 ret_from_fork+0x10/0x1c

Fixes: 36077e16c050 ("phy: amlogic: Add Amlogic G12A USB3 + PCIE Combo PHY 
Driver")
Signed-off-by: Neil Armstrong 
Tested-by: Kevin Hilman 
Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sasha Levin 
---
 drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c 
b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
index 6233a7979a93..ac322d643c7a 100644
--- a/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
+++ b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
@@ -188,7 +188,7 @@ static const struct regmap_config 
phy_g12a_usb3_pcie_cr_regmap_conf = {
.reg_read = phy_g12a_usb3_pcie_cr_bus_read,
.reg_write = phy_g12a_usb3_pcie_cr_bus_write,
.max_register = 0x,
-   .fast_io = true,
+   .disable_locking = true,
 };
 
 static int phy_g12a_usb3_init(struct phy *phy)
-- 
2.20.1

[PATCH AUTOSEL 5.2 072/171] usb: gadget: storage: Remove warning message

[Sasha Levin]

From: EJ Hsu 

[ Upstream commit e70b3f5da00119e057b7faa557753fee7f786f17 ]

This change is to fix below warning message in following scenario:
usb_composite_setup_continue: Unexpected call

When system tried to enter suspend, the fsg_disable() will be called to
disable fsg driver and send a signal to fsg_main_thread. However, at
this point, the fsg_main_thread has already been frozen and can not
respond to this signal. So, this signal will be pended until
fsg_main_thread wakes up.

Once system resumes from suspend, fsg_main_thread will detect a signal
pended and do some corresponding action (in handle_exception()). Then,
host will send some setup requests (get descriptor, set configuration...)
to UDC driver trying to enumerate this device. During the handling of "set
configuration" request, it will try to sync up with fsg_main_thread by
sending a signal (which is the same as the signal sent by fsg_disable)
to it. In a similar manner, once the fsg_main_thread receives this
signal, it will call handle_exception() to handle the request.

However, if the fsg_main_thread wakes up from suspend a little late and
"set configuration" request from Host arrives a little earlier,
fsg_main_thread might come across the request from "set configuration"
when it handles the signal from fsg_disable(). In this case, it will
handle this request as well. So, when fsg_main_thread tries to handle
the signal sent from "set configuration" later, there will nothing left
to do and warning message "Unexpected call" is printed.

Acked-by: Alan Stern 
Signed-off-by: EJ Hsu 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
---
 drivers/usb/gadget/function/f_mass_storage.c | 21 ++--
 drivers/usb/gadget/function/storage_common.h |  1 +
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/function/f_mass_storage.c 
b/drivers/usb/gadget/function/f_mass_storage.c
index 043f97ad8f22..982c3e89eb0d 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -2293,8 +2293,7 @@ static int fsg_set_alt(struct usb_function *f, unsigned 
intf, unsigned alt)
 static void fsg_disable(struct usb_function *f)
 {
struct fsg_dev *fsg = fsg_from_func(f);
-   fsg->common->new_fsg = NULL;
-   raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE);
+   raise_exception(fsg->common, FSG_STATE_DISCONNECT);
 }
 
 
@@ -2307,6 +2306,7 @@ static void handle_exception(struct fsg_common *common)
enum fsg_state  old_state;
struct fsg_lun  *curlun;
unsigned intexception_req_tag;
+   struct fsg_dev  *fsg;
 
/*
 * Clear the existing signals.  Anything but SIGUSR1 is converted
@@ -2413,9 +2413,19 @@ static void handle_exception(struct fsg_common *common)
break;
 
case FSG_STATE_CONFIG_CHANGE:
-   do_set_interface(common, common->new_fsg);
-   if (common->new_fsg)
+   fsg = common->new_fsg;
+   /*
+* Add a check here to double confirm if a disconnect event
+* occurs and common->new_fsg has been cleared.
+*/
+   if (fsg) {
+   do_set_interface(common, fsg);
usb_composite_setup_continue(common->cdev);
+   }
+   break;
+
+   case FSG_STATE_DISCONNECT:
+   do_set_interface(common, NULL);
break;
 
case FSG_STATE_EXIT:
@@ -2989,8 +2999,7 @@ static void fsg_unbind(struct usb_configuration *c, 
struct usb_function *f)
 
DBG(fsg, "unbind\n");
if (fsg->common->fsg == fsg) {
-   fsg->common->new_fsg = NULL;
-   raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE);
+   raise_exception(fsg->common, FSG_STATE_DISCONNECT);
/* FIXME: make interruptible or killable somehow? */
wait_event(common->fsg_wait, common->fsg != fsg);
}
diff --git a/drivers/usb/gadget/function/storage_common.h 
b/drivers/usb/gadget/function/storage_common.h
index e5e3a2553aaa..12687f7e3de9 100644
--- a/drivers/usb/gadget/function/storage_common.h
+++ b/drivers/usb/gadget/function/storage_common.h
@@ -161,6 +161,7 @@ enum fsg_state {
FSG_STATE_ABORT_BULK_OUT,
FSG_STATE_PROTOCOL_RESET,
FSG_STATE_CONFIG_CHANGE,
+   FSG_STATE_DISCONNECT,
FSG_STATE_EXIT,
FSG_STATE_TERMINATED
 };
-- 
2.20.1

[PATCH AUTOSEL 5.2 075/171] kvm: vmx: segment limit check: use access length

[Sasha Levin]

From: Eugene Korenevsky 

[ Upstream commit fdb28619a8f033c13f5d9b9e8b5536bb6e68a2c3 ]

There is an imperfection in get_vmx_mem_address(): access length is ignored
when checking the limit. To fix this, pass access length as a function argument.
The access length is usually obvious since it is used by callers after
get_vmx_mem_address() call, but for vmread/vmwrite it depends on the
state of 64-bit mode.

Signed-off-by: Eugene Korenevsky 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Sasha Levin 
---
 arch/x86/kvm/vmx/nested.c | 28 
 arch/x86/kvm/vmx/nested.h |  2 +-
 arch/x86/kvm/vmx/vmx.c|  3 ++-
 3 files changed, 19 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 4c0aa676f843..749125a3539e 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -4012,7 +4012,7 @@ void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 
exit_reason,
  * #UD or #GP.
  */
 int get_vmx_mem_address(struct kvm_vcpu *vcpu, unsigned long 
exit_qualification,
-   u32 vmx_instruction_info, bool wr, gva_t *ret)
+   u32 vmx_instruction_info, bool wr, int len, gva_t *ret)
 {
gva_t off;
bool exn;
@@ -4119,7 +4119,7 @@ int get_vmx_mem_address(struct kvm_vcpu *vcpu, unsigned 
long exit_qualification,
 */
if (!(s.base == 0 && s.limit == 0x &&
 ((s.type & 8) || !(s.type & 4
-   exn = exn || ((u64)off + sizeof(u64) - 1 > s.limit);
+   exn = exn || ((u64)off + len - 1 > s.limit);
}
if (exn) {
kvm_queue_exception_e(vcpu,
@@ -4138,7 +4138,8 @@ static int nested_vmx_get_vmptr(struct kvm_vcpu *vcpu, 
gpa_t *vmpointer)
struct x86_exception e;
 
if (get_vmx_mem_address(vcpu, vmcs_readl(EXIT_QUALIFICATION),
-   vmcs_read32(VMX_INSTRUCTION_INFO), false, ))
+   vmcs_read32(VMX_INSTRUCTION_INFO), false,
+   sizeof(*vmpointer), ))
return 1;
 
if (kvm_read_guest_virt(vcpu, gva, vmpointer, sizeof(*vmpointer), )) {
@@ -4390,6 +4391,7 @@ static int handle_vmread(struct kvm_vcpu *vcpu)
u64 field_value;
unsigned long exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
u32 vmx_instruction_info = vmcs_read32(VMX_INSTRUCTION_INFO);
+   int len;
gva_t gva = 0;
struct vmcs12 *vmcs12;
 
@@ -4427,12 +4429,12 @@ static int handle_vmread(struct kvm_vcpu *vcpu)
kvm_register_writel(vcpu, (((vmx_instruction_info) >> 3) & 0xf),
field_value);
} else {
+   len = is_64_bit_mode(vcpu) ? 8 : 4;
if (get_vmx_mem_address(vcpu, exit_qualification,
-   vmx_instruction_info, true, ))
+   vmx_instruction_info, true, len, ))
return 1;
/* _system ok, nested_vmx_check_permission has verified cpl=0 */
-   kvm_write_guest_virt_system(vcpu, gva, _value,
-   (is_long_mode(vcpu) ? 8 : 4), NULL);
+   kvm_write_guest_virt_system(vcpu, gva, _value, len, NULL);
}
 
return nested_vmx_succeed(vcpu);
@@ -4442,6 +,7 @@ static int handle_vmread(struct kvm_vcpu *vcpu)
 static int handle_vmwrite(struct kvm_vcpu *vcpu)
 {
unsigned long field;
+   int len;
gva_t gva;
struct vcpu_vmx *vmx = to_vmx(vcpu);
unsigned long exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
@@ -4467,11 +4470,11 @@ static int handle_vmwrite(struct kvm_vcpu *vcpu)
field_value = kvm_register_readl(vcpu,
(((vmx_instruction_info) >> 3) & 0xf));
else {
+   len = is_64_bit_mode(vcpu) ? 8 : 4;
if (get_vmx_mem_address(vcpu, exit_qualification,
-   vmx_instruction_info, false, ))
+   vmx_instruction_info, false, len, ))
return 1;
-   if (kvm_read_guest_virt(vcpu, gva, _value,
-   (is_64_bit_mode(vcpu) ? 8 : 4), )) {
+   if (kvm_read_guest_virt(vcpu, gva, _value, len, )) {
kvm_inject_page_fault(vcpu, );
return 1;
}
@@ -4630,7 +4633,8 @@ static int handle_vmptrst(struct kvm_vcpu *vcpu)
if (unlikely(to_vmx(vcpu)->nested.hv_evmcs))
return 1;
 
-   if (get_vmx_mem_address(vcpu, exit_qual, instr_info, true, ))
+   if (get_vmx_mem_address(vcpu, exit_qual, instr_info,
+   true, sizeof(gpa_t), ))
return 1;
/* *_system ok, nested_vmx_check_permission has verified cpl=0 */
if (kvm_write_guest_virt_system(vcpu, gva, (void *)_vmptr,
@@ -4676,7 

[PATCH AUTOSEL 5.2 097/171] mfd: cros_ec: Register cros_ec_lid_angle driver when presented

[Sasha Levin]

From: Gwendal Grignou 

[ Upstream commit 1bb407f17c5316888c3c446e26cb2bb78943f236 ]

Register driver when EC indicates has precise lid angle calculation code
running.
Fix incorrect extra resource allocation in cros_ec_sensors_register().

Signed-off-by: Gwendal Grignou 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin 
---
 drivers/mfd/cros_ec_dev.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index a5391f96eafd..607383b67cf1 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -285,13 +285,15 @@ static void cros_ec_sensors_register(struct cros_ec_dev 
*ec)
 
resp = (struct ec_response_motion_sense *)msg->data;
sensor_num = resp->dump.sensor_count;
-   /* Allocate 1 extra sensors in FIFO are needed */
-   sensor_cells = kcalloc(sensor_num + 1, sizeof(struct mfd_cell),
+   /*
+* Allocate 2 extra sensors if lid angle sensor and/or FIFO are needed.
+*/
+   sensor_cells = kcalloc(sensor_num + 2, sizeof(struct mfd_cell),
   GFP_KERNEL);
if (sensor_cells == NULL)
goto error;
 
-   sensor_platforms = kcalloc(sensor_num + 1,
+   sensor_platforms = kcalloc(sensor_num,
   sizeof(struct cros_ec_sensor_platform),
   GFP_KERNEL);
if (sensor_platforms == NULL)
@@ -351,6 +353,11 @@ static void cros_ec_sensors_register(struct cros_ec_dev 
*ec)
sensor_cells[id].name = "cros-ec-ring";
id++;
}
+   if (cros_ec_check_features(ec,
+   EC_FEATURE_REFINED_TABLET_MODE_HYSTERESIS)) {
+   sensor_cells[id].name = "cros-ec-lid-angle";
+   id++;
+   }
 
ret = mfd_add_devices(ec->dev, 0, sensor_cells, id,
  NULL, 0, NULL);
-- 
2.20.1

[PATCH AUTOSEL 5.2 090/171] iio: iio-utils: Fix possible incorrect mask calculation

[Sasha Levin]

From: Bastien Nocera 

[ Upstream commit 208a68c8393d6041a9086299f3d7943d44d6 ]

On some machines, iio-sensor-proxy was returning all 0's for IIO sensor
values. It turns out that the bits_used for this sensor is 32, which makes
the mask calculation:

*mask = (1 << 32) - 1;

If the compiler interprets the 1 literals as 32-bit ints, it generates
undefined behavior depending on compiler version and optimization level.
On my system, it optimizes out the shift, so the mask value becomes

*mask = (1) - 1;

With a mask value of 0, iio-sensor-proxy will always return 0 for every axis.

Avoid incorrect 0 values caused by compiler optimization.

See original fix by Brett Dutro  in
iio-sensor-proxy:
https://github.com/hadess/iio-sensor-proxy/commit/9615ceac7c134d838660e209726cd86aa2064fd3

Signed-off-by: Bastien Nocera 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin 
---
 tools/iio/iio_utils.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/iio/iio_utils.c b/tools/iio/iio_utils.c
index a22b6e8fad46..7399eb7f1378 100644
--- a/tools/iio/iio_utils.c
+++ b/tools/iio/iio_utils.c
@@ -156,9 +156,9 @@ int iioutils_get_type(unsigned *is_signed, unsigned *bytes, 
unsigned *bits_used,
*be = (endianchar == 'b');
*bytes = padint / 8;
if (*bits_used == 64)
-   *mask = ~0;
+   *mask = ~(0ULL);
else
-   *mask = (1ULL << *bits_used) - 1;
+   *mask = (1ULL << *bits_used) - 1ULL;
 
*is_signed = (signchar == 's');
if (fclose(sysfsfp)) {
-- 
2.20.1

[PATCH AUTOSEL 5.2 093/171] powerpc/xmon: Fix disabling tracing while in xmon

[Sasha Levin]

From: "Naveen N. Rao" 

[ Upstream commit aaf06665f7ea3ee9f9754e16c1a507a89f1de5b1 ]

Commit ed49f7fd6438d ("powerpc/xmon: Disable tracing when entering
xmon") added code to disable recording trace entries while in xmon. The
commit introduced a variable 'tracing_enabled' to record if tracing was
enabled on xmon entry, and used this to conditionally enable tracing
during exit from xmon.

However, we are not checking the value of 'fromipi' variable in
xmon_core() when setting 'tracing_enabled'. Due to this, when secondary
cpus enter xmon, they will see tracing as being disabled already and
tracing won't be re-enabled on exit. Fix the same.

Fixes: ed49f7fd6438d ("powerpc/xmon: Disable tracing when entering xmon")
Signed-off-by: Naveen N. Rao 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/xmon/xmon.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index d0620d762a5a..4a721fd62406 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -465,8 +465,10 @@ static int xmon_core(struct pt_regs *regs, int fromipi)
local_irq_save(flags);
hard_irq_disable();
 
-   tracing_enabled = tracing_is_on();
-   tracing_off();
+   if (!fromipi) {
+   tracing_enabled = tracing_is_on();
+   tracing_off();
+   }
 
bp = in_breakpoint_table(regs->nip, );
if (bp != NULL) {
-- 
2.20.1

[PATCH AUTOSEL 5.2 092/171] powerpc/cacheflush: fix variable set but not used

[Sasha Levin]

From: Qian Cai 

[ Upstream commit 04db3ede40ae4fc23a5c4237254c4a53bbe4c1f2 ]

The powerpc's flush_cache_vmap() is defined as a macro and never use
both of its arguments, so it will generate a compilation warning,

lib/ioremap.c: In function 'ioremap_page_range':
lib/ioremap.c:203:16: warning: variable 'start' set but not used
[-Wunused-but-set-variable]

Fix it by making it an inline function.

Signed-off-by: Qian Cai 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/include/asm/cacheflush.h | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/cacheflush.h 
b/arch/powerpc/include/asm/cacheflush.h
index 74d60cfe8ce5..fd318f7c3eed 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -29,9 +29,12 @@
  * not expect this type of fault. flush_cache_vmap is not exactly the right
  * place to put this, but it seems to work well enough.
  */
-#define flush_cache_vmap(start, end)   do { asm volatile("ptesync" ::: 
"memory"); } while (0)
+static inline void flush_cache_vmap(unsigned long start, unsigned long end)
+{
+   asm volatile("ptesync" ::: "memory");
+}
 #else
-#define flush_cache_vmap(start, end)   do { } while (0)
+static inline void flush_cache_vmap(unsigned long start, unsigned long end) { }
 #endif
 
 #define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
-- 
2.20.1

[PATCH AUTOSEL 5.2 089/171] PCI: xilinx-nwl: Fix Multi MSI data programming

[Sasha Levin]

From: Bharat Kumar Gogada 

[ Upstream commit 181fa434d0514e40ebf6e9721f2b72700287b6e2 ]

According to the PCI Local Bus specification Revision 3.0,
section 6.8.1.3 (Message Control for MSI), endpoints that
are Multiple Message Capable as defined by bits [3:1] in
the Message Control for MSI can request a number of vectors
that is power of two aligned.

As specified in section 6.8.1.6 "Message data for MSI", the Multiple
Message Enable field (bits [6:4] of the Message Control register)
defines the number of low order message data bits the function is
permitted to modify to generate its system software allocated
vectors.

The MSI controller in the Xilinx NWL PCIe controller supports a number
of MSI vectors specified through a bitmap and the hwirq number for an
MSI, that is the value written in the MSI data TLP is determined by
the bitmap allocation.

For instance, in a situation where two endpoints sitting on
the PCI bus request the following MSI configuration, with
the current PCI Xilinx bitmap allocation code (that does not
align MSI vector allocation on a power of two boundary):

Endpoint #1: Requesting 1 MSI vector - allocated bitmap bits 0
Endpoint #2: Requesting 2 MSI vectors - allocated bitmap bits [1,2]

The bitmap value(s) corresponds to the hwirq number that is programmed
into the Message Data for MSI field in the endpoint MSI capability
and is detected by the root complex to fire the corresponding
MSI irqs. The value written in Message Data for MSI field corresponds
to the first bit allocated in the bitmap for Multi MSI vectors.

The current Xilinx NWL MSI allocation code allows a bitmap allocation
that is not a power of two boundaries, so endpoint #2, is allowed to
toggle Message Data bit[0] to differentiate between its two vectors
(meaning that the MSI data will be respectively 0x0 and 0x1 for the two
vectors allocated to endpoint #2).

This clearly aliases with the Endpoint #1 vector allocation, resulting
in a broken Multi MSI implementation.

Update the code to allocate MSI bitmap ranges with a power of two
alignment, fixing the bug.

Fixes: ab597d35ef11 ("PCI: xilinx-nwl: Add support for Xilinx NWL PCIe Host 
Controller")
Suggested-by: Marc Zyngier 
Signed-off-by: Bharat Kumar Gogada 
[lorenzo.pieral...@arm.com: updated commit log]
Signed-off-by: Lorenzo Pieralisi 
Acked-by: Marc Zyngier 
Signed-off-by: Sasha Levin 
---
 drivers/pci/controller/pcie-xilinx-nwl.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/controller/pcie-xilinx-nwl.c 
b/drivers/pci/controller/pcie-xilinx-nwl.c
index 3b031f00a94a..45c0f344ccd1 100644
--- a/drivers/pci/controller/pcie-xilinx-nwl.c
+++ b/drivers/pci/controller/pcie-xilinx-nwl.c
@@ -482,15 +482,13 @@ static int nwl_irq_domain_alloc(struct irq_domain 
*domain, unsigned int virq,
int i;
 
mutex_lock(>lock);
-   bit = bitmap_find_next_zero_area(msi->bitmap, INT_PCI_MSI_NR, 0,
-nr_irqs, 0);
-   if (bit >= INT_PCI_MSI_NR) {
+   bit = bitmap_find_free_region(msi->bitmap, INT_PCI_MSI_NR,
+ get_count_order(nr_irqs));
+   if (bit < 0) {
mutex_unlock(>lock);
return -ENOSPC;
}
 
-   bitmap_set(msi->bitmap, bit, nr_irqs);
-
for (i = 0; i < nr_irqs; i++) {
irq_domain_set_info(domain, virq + i, bit + i, _irq_chip,
domain->host_data, handle_simple_irq,
@@ -508,7 +506,8 @@ static void nwl_irq_domain_free(struct irq_domain *domain, 
unsigned int virq,
struct nwl_msi *msi = >msi;
 
mutex_lock(>lock);
-   bitmap_clear(msi->bitmap, data->hwirq, nr_irqs);
+   bitmap_release_region(msi->bitmap, data->hwirq,
+ get_count_order(nr_irqs));
mutex_unlock(>lock);
 }
 
-- 
2.20.1

[PATCH AUTOSEL 5.2 086/171] kbuild: Add -Werror=unknown-warning-option to CLANG_FLAGS

[Sasha Levin]

From: Nathan Chancellor 

[ Upstream commit 589834b3a0097a4908f4112eac0ca2feb486fa32 ]

In commit ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI
drift"), the arm64 Makefile added -Wno-psabi to KBUILD_CFLAGS, which is
a GCC only option so clang rightfully complains:

warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option]

https://clang.llvm.org/docs/DiagnosticsReference.html#wunknown-warning-option

However, by default, this is merely a warning so the build happily goes
on with a slew of these warnings in the process.

Commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to cc-option to
support clang") worked around this behavior in cc-option by adding
-Werror so that unknown flags cause an error. However, this all happens
silently and when an unknown flag is added to the build unconditionally
like -Wno-psabi, cc-option will always fail because there is always an
unknown flag in the list of flags. This manifested as link time failures
in the arm64 libstub because -fno-stack-protector didn't get added to
KBUILD_CFLAGS.

To avoid these weird cryptic failures in the future, make clang behave
like gcc and immediately error when it encounters an unknown flag by
adding -Werror=unknown-warning-option to CLANG_FLAGS. This can be added
unconditionally for clang because it is supported by at least 3.0.0,
according to godbolt [1] and 4.0.0, according to its documentation [2],
which is far earlier than we typically support.

[1]: https://godbolt.org/z/7F7rm3
[2]: 
https://releases.llvm.org/4.0.0/tools/clang/docs/DiagnosticsReference.html#wunknown-warning-option

Link: https://github.com/ClangBuiltLinux/linux/issues/511
Link: https://github.com/ClangBuiltLinux/linux/issues/517
Suggested-by: Peter Smith 
Signed-off-by: Nathan Chancellor 
Tested-by: Nick Desaulniers 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Sasha Levin 
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index d8f5dbfd6b76..f02079b98e7e 100644
--- a/Makefile
+++ b/Makefile
@@ -528,6 +528,7 @@ ifneq ($(GCC_TOOLCHAIN),)
 CLANG_FLAGS+= --gcc-toolchain=$(GCC_TOOLCHAIN)
 endif
 CLANG_FLAGS+= -no-integrated-as
+CLANG_FLAGS+= -Werror=unknown-warning-option
 KBUILD_CFLAGS  += $(CLANG_FLAGS)
 KBUILD_AFLAGS  += $(CLANG_FLAGS)
 export CLANG_FLAGS
-- 
2.20.1

[PATCH v2] nvme-pci: Support shared tags across queues for Apple 2018 controllers

[Benjamin Herrenschmidt]

Another issue with the Apple T2 based 2018 controllers seem to be
that they blow up (and shut the machine down) if there's a tag
collision between the IO queue and the Admin queue.

My suspicion is that they use our tags for their internal tracking
and don't mix them with the queue id. They also seem to not like
when tags go beyond the IO queue depth, ie 128 tags.

This adds a quirk that offsets all the tags in the IO queue by 32
to avoid those collisions. It also limits the number of IO queues
to 1 since the code wouldn't otherwise make sense (the device
supports only one queue anyway but better safe than sorry) and
reduces the size of the IO queue

Signed-off-by: Benjamin Herrenschmidt 
---

Note: One thing I noticed is how we have nvme_completion as volatile.

I don't think we really need that, it's forcing the compiler to constantly
reload things which makes no sense once we have established that an
entry is valid.

And since we have a data & control dependency from nvme_cqe_pending(),
we know that reading the CQE is going to depend on it being valid. I
don't really see what volatile is buying us here other than cargo culting.

Cheers,
Ben.

 drivers/nvme/host/nvme.h |  5 
 drivers/nvme/host/pci.c  | 52 +---
 2 files changed, 49 insertions(+), 8 deletions(-)

diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index ced0e0a7e039..7c6de398de7d 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -102,6 +102,11 @@ enum nvme_quirks {
 * Use non-standard 128 bytes SQEs.
 */
NVME_QUIRK_128_BYTES_SQES   = (1 << 11),
+
+   /*
+* Prevent tag overlap between queues
+*/
+   NVME_QUIRK_SHARED_TAGS  = (1 << 12),
 };
 
 /*
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 7088971d4c42..c38e946ad8ca 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -178,6 +178,7 @@ struct nvme_queue {
u16 cq_head;
u16 last_cq_head;
u16 qid;
+   u16 tag_offset;
u8 cq_phase;
u8 sqes;
unsigned long flags;
@@ -490,6 +491,7 @@ static void nvme_submit_cmd(struct nvme_queue *nvmeq, 
struct nvme_command *cmd,
bool write_sq)
 {
spin_lock(>sq_lock);
+   cmd->common.command_id += nvmeq->tag_offset;
memcpy(nvmeq->sq_cmds + (nvmeq->sq_tail << nvmeq->sqes),
   cmd, sizeof(*cmd));
if (++nvmeq->sq_tail == nvmeq->q_depth)
@@ -951,9 +953,10 @@ static inline void nvme_ring_cq_doorbell(struct nvme_queue 
*nvmeq)
 static inline void nvme_handle_cqe(struct nvme_queue *nvmeq, u16 idx)
 {
volatile struct nvme_completion *cqe = >cqes[idx];
+   u16 ctag = cqe->command_id - nvmeq->tag_offset;
struct request *req;
 
-   if (unlikely(cqe->command_id >= nvmeq->q_depth)) {
+   if (unlikely(ctag >= nvmeq->q_depth)) {
dev_warn(nvmeq->dev->ctrl.device,
"invalid id %d completed on queue %d\n",
cqe->command_id, le16_to_cpu(cqe->sq_id));
@@ -966,14 +969,13 @@ static inline void nvme_handle_cqe(struct nvme_queue 
*nvmeq, u16 idx)
 * aborts.  We don't even bother to allocate a struct request
 * for them but rather special case them here.
 */
-   if (unlikely(nvmeq->qid == 0 &&
-   cqe->command_id >= NVME_AQ_BLK_MQ_DEPTH)) {
+   if (unlikely(nvmeq->qid == 0 && ctag >= NVME_AQ_BLK_MQ_DEPTH)) {
nvme_complete_async_event(>dev->ctrl,
cqe->status, >result);
return;
}
 
-   req = blk_mq_tag_to_rq(*nvmeq->tags, cqe->command_id);
+   req = blk_mq_tag_to_rq(*nvmeq->tags, ctag);
trace_nvme_sq(req, cqe->sq_head, nvmeq->sq_tail);
nvme_end_request(req, cqe->status, cqe->result);
 }
@@ -1004,7 +1006,10 @@ static inline int nvme_process_cq(struct nvme_queue 
*nvmeq, u16 *start,
 
*start = nvmeq->cq_head;
while (nvme_cqe_pending(nvmeq)) {
-   if (tag == -1U || nvmeq->cqes[nvmeq->cq_head].command_id == tag)
+   u16 ctag = nvmeq->cqes[nvmeq->cq_head].command_id;
+
+   ctag -= nvmeq->tag_offset;
+   if (tag == -1U || ctag == tag)
found++;
nvme_update_cq_head(nvmeq);
}
@@ -1487,6 +1492,10 @@ static int nvme_alloc_queue(struct nvme_dev *dev, int 
qid, int depth)
nvmeq->qid = qid;
dev->ctrl.queue_count++;
 
+   if (qid && (dev->ctrl.quirks & NVME_QUIRK_SHARED_TAGS))
+   nvmeq->tag_offset = NVME_AQ_DEPTH;
+   else
+   nvmeq->tag_offset = 0;
return 0;
 
  free_cqdma:
@@ -2106,6 +2115,14 @@ static int nvme_setup_io_queues(struct nvme_dev *dev)
unsigned long size;
 
nr_io_queues = max_io_queues();
+
+   /*
+* If tags are shared with admin queue (Apple bug), then
+ 

[PATCH AUTOSEL 5.2 107/171] powerpc/mm: mark more tlb functions as __always_inline

[Sasha Levin]

From: Masahiro Yamada 

[ Upstream commit 6d3ca7e73642ce17398f4cd5df1780da4a1ccdaf ]

With CONFIG_OPTIMIZE_INLINING enabled, Laura Abbott reported error
with gcc 9.1.1:

  arch/powerpc/mm/book3s64/radix_tlb.c: In function '_tlbiel_pid':
  arch/powerpc/mm/book3s64/radix_tlb.c:104:2: warning: asm operand 3 probably 
doesn't match constraints
104 |  asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1)
|  ^~~
  arch/powerpc/mm/book3s64/radix_tlb.c:104:2: error: impossible constraint in 
'asm'

Fixing _tlbiel_pid() is enough to address the warning above, but I
inlined more functions to fix all potential issues.

To meet the "i" (immediate) constraint for the asm operands, functions
propagating "ric" must be always inlined.

Fixes: 9012d011660e ("compiler: allow all arches to enable 
CONFIG_OPTIMIZE_INLINING")
Reported-by: Laura Abbott 
Signed-off-by: Masahiro Yamada 
Reviewed-by: Christophe Leroy 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/mm/book3s64/hash_native.c |  2 +-
 arch/powerpc/mm/book3s64/radix_tlb.c   | 32 +-
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/mm/book3s64/hash_native.c 
b/arch/powerpc/mm/book3s64/hash_native.c
index 30d62ffe3310..1322c59cb5dd 100644
--- a/arch/powerpc/mm/book3s64/hash_native.c
+++ b/arch/powerpc/mm/book3s64/hash_native.c
@@ -56,7 +56,7 @@ static inline void tlbiel_hash_set_isa206(unsigned int set, 
unsigned int is)
  * tlbiel instruction for hash, set invalidation
  * i.e., r=1 and is=01 or is=10 or is=11
  */
-static inline void tlbiel_hash_set_isa300(unsigned int set, unsigned int is,
+static __always_inline void tlbiel_hash_set_isa300(unsigned int set, unsigned 
int is,
unsigned int pid,
unsigned int ric, unsigned int prs)
 {
diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c 
b/arch/powerpc/mm/book3s64/radix_tlb.c
index bb9835681315..d0cd5271a57c 100644
--- a/arch/powerpc/mm/book3s64/radix_tlb.c
+++ b/arch/powerpc/mm/book3s64/radix_tlb.c
@@ -25,7 +25,7 @@
  * tlbiel instruction for radix, set invalidation
  * i.e., r=1 and is=01 or is=10 or is=11
  */
-static inline void tlbiel_radix_set_isa300(unsigned int set, unsigned int is,
+static __always_inline void tlbiel_radix_set_isa300(unsigned int set, unsigned 
int is,
unsigned int pid,
unsigned int ric, unsigned int prs)
 {
@@ -146,8 +146,8 @@ static __always_inline void __tlbie_lpid(unsigned long 
lpid, unsigned long ric)
trace_tlbie(lpid, 0, rb, rs, ric, prs, r);
 }
 
-static inline void __tlbiel_lpid_guest(unsigned long lpid, int set,
-   unsigned long ric)
+static __always_inline void __tlbiel_lpid_guest(unsigned long lpid, int set,
+   unsigned long ric)
 {
unsigned long rb,rs,prs,r;
 
@@ -163,8 +163,8 @@ static inline void __tlbiel_lpid_guest(unsigned long lpid, 
int set,
 }
 
 
-static inline void __tlbiel_va(unsigned long va, unsigned long pid,
-  unsigned long ap, unsigned long ric)
+static __always_inline void __tlbiel_va(unsigned long va, unsigned long pid,
+   unsigned long ap, unsigned long ric)
 {
unsigned long rb,rs,prs,r;
 
@@ -179,8 +179,8 @@ static inline void __tlbiel_va(unsigned long va, unsigned 
long pid,
trace_tlbie(0, 1, rb, rs, ric, prs, r);
 }
 
-static inline void __tlbie_va(unsigned long va, unsigned long pid,
- unsigned long ap, unsigned long ric)
+static __always_inline void __tlbie_va(unsigned long va, unsigned long pid,
+  unsigned long ap, unsigned long ric)
 {
unsigned long rb,rs,prs,r;
 
@@ -195,8 +195,8 @@ static inline void __tlbie_va(unsigned long va, unsigned 
long pid,
trace_tlbie(0, 0, rb, rs, ric, prs, r);
 }
 
-static inline void __tlbie_lpid_va(unsigned long va, unsigned long lpid,
- unsigned long ap, unsigned long ric)
+static __always_inline void __tlbie_lpid_va(unsigned long va, unsigned long 
lpid,
+   unsigned long ap, unsigned long ric)
 {
unsigned long rb,rs,prs,r;
 
@@ -235,7 +235,7 @@ static inline void fixup_tlbie_lpid(unsigned long lpid)
 /*
  * We use 128 set in radix mode and 256 set in hpt mode.
  */
-static inline void _tlbiel_pid(unsigned long pid, unsigned long ric)
+static __always_inline void _tlbiel_pid(unsigned long pid, unsigned long ric)
 {
int set;
 
@@ -337,7 +337,7 @@ static inline void _tlbie_lpid(unsigned long lpid, unsigned 
long ric)
asm volatile("eieio; tlbsync; ptesync": : :"memory");
 }
 
-static inline void _tlbiel_lpid_guest(unsigned long lpid, unsigned long ric)
+static __always_inline void _tlbiel_lpid_guest(unsigned long lpid, unsigned 
long ric)
 {
   

[PATCH AUTOSEL 5.2 098/171] mfd: madera: Add missing of table registration

[Sasha Levin]

From: Daniel Gomez 

[ Upstream commit 5aa3709c0a5c026735b0ddd4ec80810a23d65f5b ]

MODULE_DEVICE_TABLE(of, ) should be called to complete DT
OF mathing mechanism and register it.

Before this patch:
modinfo ./drivers/mfd/madera.ko | grep alias

After this patch:
modinfo ./drivers/mfd/madera.ko | grep alias
alias:  of:N*T*Ccirrus,wm1840C*
alias:  of:N*T*Ccirrus,wm1840
alias:  of:N*T*Ccirrus,cs47l91C*
alias:  of:N*T*Ccirrus,cs47l91
alias:  of:N*T*Ccirrus,cs47l90C*
alias:  of:N*T*Ccirrus,cs47l90
alias:  of:N*T*Ccirrus,cs47l85C*
alias:  of:N*T*Ccirrus,cs47l85
alias:  of:N*T*Ccirrus,cs47l35C*
alias:  of:N*T*Ccirrus,cs47l35

Reported-by: Javier Martinez Canillas 
Signed-off-by: Daniel Gomez 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin 
---
 drivers/mfd/madera-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mfd/madera-core.c b/drivers/mfd/madera-core.c
index 2a77988d0462..826b971ccb86 100644
--- a/drivers/mfd/madera-core.c
+++ b/drivers/mfd/madera-core.c
@@ -286,6 +286,7 @@ const struct of_device_id madera_of_match[] = {
{ .compatible = "cirrus,wm1840", .data = (void *)WM1840 },
{}
 };
+MODULE_DEVICE_TABLE(of, madera_of_match);
 EXPORT_SYMBOL_GPL(madera_of_match);
 
 static int madera_get_reset_gpio(struct madera *madera)
-- 
2.20.1

[PATCH AUTOSEL 5.2 096/171] recordmcount: Fix spurious mcount entries on powerpc

[Sasha Levin]

From: "Naveen N. Rao" 

[ Upstream commit 80e5302e4bc85a6b685b7668c36c6487b5f90e9a ]

An impending change to enable HAVE_C_RECORDMCOUNT on powerpc leads to
warnings such as the following:

  # modprobe kprobe_example
  ftrace-powerpc: Not expected bl: opcode is 3c4c0001
  WARNING: CPU: 0 PID: 227 at kernel/trace/ftrace.c:2001 ftrace_bug+0x90/0x318
  Modules linked in:
  CPU: 0 PID: 227 Comm: modprobe Not tainted 5.2.0-rc6-00678-g1c329100b942 #2
  NIP:  c0264318 LR: c025d694 CTR: c0f5cd30
  REGS: c1f2b7b0 TRAP: 0700   Not tainted  
(5.2.0-rc6-00678-g1c329100b942)
  MSR:  90010282b033   CR: 
28228222  XER: 
  CFAR: c02642fc IRQMASK: 0
  
  NIP [c0264318] ftrace_bug+0x90/0x318
  LR [c025d694] ftrace_process_locs+0x4f4/0x5e0
  Call Trace:
  [c1f2ba40] [0004] 0x4 (unreliable)
  [c1f2bad0] [c025d694] ftrace_process_locs+0x4f4/0x5e0
  [c1f2bb90] [c020ff10] load_module+0x25b0/0x30c0
  [c1f2bd00] [c0210cb0] sys_finit_module+0xc0/0x130
  [c1f2be20] [c000bda4] system_call+0x5c/0x70
  Instruction dump:
  419e0018 2f83 419e00bc 2f83ffea 409e00cc 481c 0fe0 3c62ff96
  3901 3940 386386d0 48c4 <0fe0> 3ce20003 3901 3c62ff96
  ---[ end trace 4c438d5cebf78381 ]---
  ftrace failed to modify
  [] 0xc008012a0008
   actual:   01:00:4c:3c
  Initializing ftrace call sites
  ftrace record flags: 200
   (0)
   expected tramp: c006af4c

Looking at the relocation records in __mcount_loc shows a few spurious
entries:

  RELOCATION RECORDS FOR [__mcount_loc]:
  OFFSET   TYPE  VALUE
   R_PPC64_ADDR64.text.unlikely+0x0008
  0008 R_PPC64_ADDR64.text.unlikely+0x0014
  0010 R_PPC64_ADDR64.text.unlikely+0x0060
  0018 R_PPC64_ADDR64.text.unlikely+0x00b4
  0020 R_PPC64_ADDR64.init.text+0x0008
  0028 R_PPC64_ADDR64.init.text+0x0014

The first entry in each section is incorrect. Looking at the
relocation records, the spurious entries correspond to the
R_PPC64_ENTRY records:

  RELOCATION RECORDS FOR [.text.unlikely]:
  OFFSET   TYPE  VALUE
   R_PPC64_REL64 .TOC.-0x0008
  0008 R_PPC64_ENTRY *ABS*
  0014 R_PPC64_REL24 _mcount
  

The problem is that we are not validating the return value from
get_mcountsym() in sift_rel_mcount(). With this entry, mcountsym is 0,
but Elf_r_sym(relp) also ends up being 0. Fix this by ensuring
mcountsym is valid before processing the entry.

Signed-off-by: Naveen N. Rao 
Acked-by: Steven Rostedt (VMware) 
Tested-by: Satheesh Rajendran 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 scripts/recordmcount.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
index 13c5e6c8829c..47fca2c69a73 100644
--- a/scripts/recordmcount.h
+++ b/scripts/recordmcount.h
@@ -325,7 +325,8 @@ static uint_t *sift_rel_mcount(uint_t *mlocp,
if (!mcountsym)
mcountsym = get_mcountsym(sym0, relp, str0);
 
-   if (mcountsym == Elf_r_sym(relp) && !is_fake_mcount(relp)) {
+   if (mcountsym && mcountsym == Elf_r_sym(relp) &&
+   !is_fake_mcount(relp)) {
uint_t const addend =
_w(_w(relp->r_offset) - recval + mcount_adjust);
mrelp->r_offset = _w(offbase
-- 
2.20.1

[PATCH AUTOSEL 5.2 101/171] mfd: hi655x-pmic: Fix missing return value check for devm_regmap_init_mmio_clk

[Sasha Levin]

From: Axel Lin 

[ Upstream commit 7efd105c27fd2323789b41b64763a0e33ed79c08 ]

Since devm_regmap_init_mmio_clk can fail, add return value checking.

Signed-off-by: Axel Lin 
Acked-by: Chen Feng 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin 
---
 drivers/mfd/hi655x-pmic.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/hi655x-pmic.c b/drivers/mfd/hi655x-pmic.c
index f1c51ce309fa..7e3959aaa285 100644
--- a/drivers/mfd/hi655x-pmic.c
+++ b/drivers/mfd/hi655x-pmic.c
@@ -109,6 +109,8 @@ static int hi655x_pmic_probe(struct platform_device *pdev)
 
pmic->regmap = devm_regmap_init_mmio_clk(dev, NULL, base,
 _regmap_config);
+   if (IS_ERR(pmic->regmap))
+   return PTR_ERR(pmic->regmap);
 
regmap_read(pmic->regmap, HI655X_BUS_ADDR(HI655X_VER_REG), >ver);
if ((pmic->ver < PMU_VER_START) || (pmic->ver > PMU_VER_END)) {
-- 
2.20.1

[PATCH AUTOSEL 5.2 109/171] serial: sh-sci: Terminate TX DMA during buffer flushing

[Sasha Levin]

From: Geert Uytterhoeven 

[ Upstream commit 775b7ffd7d6d5db320d99b0a485c51e04dfcf9f1 ]

While the .flush_buffer() callback clears sci_port.tx_dma_len since
commit 1cf4a7efdc71cab8 ("serial: sh-sci: Fix race condition causing
garbage during shutdown"), it does not terminate a transmit DMA
operation that may be in progress.

Fix this by terminating any pending DMA operations, and resetting the
corresponding cookie.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Eugeniu Rosca 
Tested-by: Eugeniu Rosca 

Link: https://lore.kernel.org/r/20190624123540.20629-3-geert+rene...@glider.be
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/tty/serial/sh-sci.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index abc705716aa0..1d25c4e2d0d2 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1648,11 +1648,18 @@ static void sci_free_dma(struct uart_port *port)
 
 static void sci_flush_buffer(struct uart_port *port)
 {
+   struct sci_port *s = to_sci_port(port);
+
/*
 * In uart_flush_buffer(), the xmit circular buffer has just been
-* cleared, so we have to reset tx_dma_len accordingly.
+* cleared, so we have to reset tx_dma_len accordingly, and stop any
+* pending transfers
 */
-   to_sci_port(port)->tx_dma_len = 0;
+   s->tx_dma_len = 0;
+   if (s->chan_tx) {
+   dmaengine_terminate_async(s->chan_tx);
+   s->cookie_tx = -EINVAL;
+   }
 }
 #else /* !CONFIG_SERIAL_SH_SCI_DMA */
 static inline void sci_request_dma(struct uart_port *port)
-- 
2.20.1

[PATCH AUTOSEL 5.2 112/171] powerpc/mm: Handle page table allocation failures

[Sasha Levin]

From: "Aneesh Kumar K.V" 

[ Upstream commit 2230ebf6e6dd0b7751e2921b40f6cfe34f09bb16 ]

This fixes kernel crash that arises due to not handling page table allocation
failures while allocating hugetlb page table.

Fixes: e2b3d202d1db ("powerpc: Switch 16GB and 16MB explicit hugepages to a 
different page table format")
Signed-off-by: Aneesh Kumar K.V 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/mm/hugetlbpage.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index b5d92dc32844..1de0f43a68e5 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -130,6 +130,8 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long 
addr, unsigned long sz
} else {
pdshift = PUD_SHIFT;
pu = pud_alloc(mm, pg, addr);
+   if (!pu)
+   return NULL;
if (pshift == PUD_SHIFT)
return (pte_t *)pu;
else if (pshift > PMD_SHIFT) {
@@ -138,6 +140,8 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long 
addr, unsigned long sz
} else {
pdshift = PMD_SHIFT;
pm = pmd_alloc(mm, pu, addr);
+   if (!pm)
+   return NULL;
if (pshift == PMD_SHIFT)
/* 16MB hugepage */
return (pte_t *)pm;
@@ -154,12 +158,16 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long 
addr, unsigned long sz
} else {
pdshift = PUD_SHIFT;
pu = pud_alloc(mm, pg, addr);
+   if (!pu)
+   return NULL;
if (pshift >= PUD_SHIFT) {
ptl = pud_lockptr(mm, pu);
hpdp = (hugepd_t *)pu;
} else {
pdshift = PMD_SHIFT;
pm = pmd_alloc(mm, pu, addr);
+   if (!pm)
+   return NULL;
ptl = pmd_lockptr(mm, pm);
hpdp = (hugepd_t *)pm;
}
-- 
2.20.1

[PATCH AUTOSEL 5.2 122/171] perf test mmap-thread-lookup: Initialize variable to suppress memory sanitizer warning

[Sasha Levin]

From: Numfor Mbiziwo-Tiapo 

[ Upstream commit 4e4cf62b37da5ff45c904a3acf242ab29ed5881d ]

Running the 'perf test' command after building perf with a memory
sanitizer causes a warning that says:

  WARNING: MemorySanitizer: use-of-uninitialized-value... in 
mmap-thread-lookup.c

Initializing the go variable to 0 silences this harmless warning.

Committer warning:

This was harmless, just a simple test writing whatever was at that
sizeof(int) memory area just to signal another thread blocked reading
that file created with pipe(). Initialize it tho so that we don't get
this warning.

Signed-off-by: Numfor Mbiziwo-Tiapo 
Cc: Alexander Shishkin 
Cc: Ian Rogers 
Cc: Jiri Olsa 
Cc: Mark Drayton 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Song Liu 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/r/20190702173716.181223-1-n...@google.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/tests/mmap-thread-lookup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/tests/mmap-thread-lookup.c 
b/tools/perf/tests/mmap-thread-lookup.c
index ba87e6e8d18c..0a4301a5155c 100644
--- a/tools/perf/tests/mmap-thread-lookup.c
+++ b/tools/perf/tests/mmap-thread-lookup.c
@@ -53,7 +53,7 @@ static void *thread_fn(void *arg)
 {
struct thread_data *td = arg;
ssize_t ret;
-   int go;
+   int go = 0;
 
if (thread_init(td))
return NULL;
-- 
2.20.1

[PATCH AUTOSEL 5.2 117/171] PCI: mobiveil: Fix PCI base address in MEM/IO outbound windows

[Sasha Levin]

From: Hou Zhiqiang 

[ Upstream commit f99536e9d2f55996038158a6559d4254a7cc1693 ]

The outbound memory windows PCI base addresses should be taken
from the 'ranges' property of DT node to setup MEM/IO outbound
windows decoding correctly instead of being hardcoded to zero.

Update the code to retrieve the PCI base address for each range
and use it to program the outbound windows address decoders

Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP driver")
Signed-off-by: Hou Zhiqiang 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Minghuan Lian 
Reviewed-by: Subrahmanya Lingappa 
Signed-off-by: Sasha Levin 
---
 drivers/pci/controller/pcie-mobiveil.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/pcie-mobiveil.c 
b/drivers/pci/controller/pcie-mobiveil.c
index 77052a0712d0..03d697b63e2a 100644
--- a/drivers/pci/controller/pcie-mobiveil.c
+++ b/drivers/pci/controller/pcie-mobiveil.c
@@ -552,8 +552,9 @@ static int mobiveil_host_init(struct mobiveil_pcie *pcie)
if (type) {
/* configure outbound translation window */
program_ob_windows(pcie, pcie->ob_wins_configured,
-   win->res->start, 0, type,
-   resource_size(win->res));
+  win->res->start,
+  win->res->start - win->offset,
+  type, resource_size(win->res));
}
}
 
-- 
2.20.1

[PATCH AUTOSEL 5.2 116/171] KVM: nVMX: Stash L1's CR3 in vmcs01.GUEST_CR3 on nested entry w/o EPT

[Sasha Levin]

From: Sean Christopherson 

[ Upstream commit f087a02941feacf7d6f097522bc67c602fda18e6 ]

KVM does not have 100% coverage of VMX consistency checks, i.e. some
checks that cause VM-Fail may only be detected by hardware during a
nested VM-Entry.  In such a case, KVM must restore L1's state to the
pre-VM-Enter state as L2's state has already been loaded into KVM's
software model.

L1's CR3 and PDPTRs in particular are loaded from vmcs01.GUEST_*.  But
when EPT is disabled, the associated fields hold KVM's shadow values,
not L1's "real" values.  Fortunately, when EPT is disabled the PDPTRs
come from memory, i.e. are not cached in the VMCS.  Which leaves CR3
as the sole anomaly.

A previously applied workaround to handle CR3 was to force nested early
checks if EPT is disabled:

  commit 2b27924bb1d48 ("KVM: nVMX: always use early vmcs check when EPT
 is disabled")

Forcing nested early checks is undesirable as doing so adds hundreds of
cycles to every nested VM-Entry.  Rather than take this performance hit,
handle CR3 by overwriting vmcs01.GUEST_CR3 with L1's CR3 during nested
VM-Entry when EPT is disabled *and* nested early checks are disabled.
By stuffing vmcs01.GUEST_CR3, nested_vmx_restore_host_state() will
naturally restore the correct vcpu->arch.cr3 from vmcs01.GUEST_CR3.

These shenanigans work because nested_vmx_restore_host_state() does a
full kvm_mmu_reset_context(), i.e. unloads the current MMU, which
guarantees vmcs01.GUEST_CR3 will be rewritten with a new shadow CR3
prior to re-entering L1.

vcpu->arch.root_mmu.root_hpa is set to INVALID_PAGE via:

nested_vmx_restore_host_state() ->
kvm_mmu_reset_context() ->
kvm_mmu_unload() ->
kvm_mmu_free_roots()

kvm_mmu_unload() has WARN_ON(root_hpa != INVALID_PAGE), i.e. we can bank
on 'root_hpa == INVALID_PAGE' unless the implementation of
kvm_mmu_reset_context() is changed.

On the way into L1, VMCS.GUEST_CR3 is guaranteed to be written (on a
successful entry) via:

vcpu_enter_guest() ->
kvm_mmu_reload() ->
kvm_mmu_load() ->
kvm_mmu_load_cr3() ->
vmx_set_cr3()

Stuff vmcs01.GUEST_CR3 if and only if nested early checks are disabled
as a "late" VM-Fail should never happen win that case (KVM WARNs), and
the conditional write avoids the need to restore the correct GUEST_CR3
when nested_vmx_check_vmentry_hw() fails.

Signed-off-by: Sean Christopherson 
Message-Id: <20190607185534.24368-1-sean.j.christopher...@intel.com>
Signed-off-by: Paolo Bonzini 
Signed-off-by: Sasha Levin 
---
 arch/x86/include/uapi/asm/vmx.h |  1 -
 arch/x86/kvm/vmx/nested.c   | 44 +
 2 files changed, 23 insertions(+), 22 deletions(-)

diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
index d213ec5c3766..f0b0c90dd398 100644
--- a/arch/x86/include/uapi/asm/vmx.h
+++ b/arch/x86/include/uapi/asm/vmx.h
@@ -146,7 +146,6 @@
 
 #define VMX_ABORT_SAVE_GUEST_MSR_FAIL1
 #define VMX_ABORT_LOAD_HOST_PDPTE_FAIL   2
-#define VMX_ABORT_VMCS_CORRUPTED 3
 #define VMX_ABORT_LOAD_HOST_MSR_FAIL 4
 
 #endif /* _UAPIVMX_H */
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 749125a3539e..0d7377b1487a 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -2968,6 +2968,25 @@ int nested_vmx_enter_non_root_mode(struct kvm_vcpu 
*vcpu, bool from_vmentry)
!(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_BNDCFGS))
vmx->nested.vmcs01_guest_bndcfgs = vmcs_read64(GUEST_BNDCFGS);
 
+   /*
+* Overwrite vmcs01.GUEST_CR3 with L1's CR3 if EPT is disabled *and*
+* nested early checks are disabled.  In the event of a "late" VM-Fail,
+* i.e. a VM-Fail detected by hardware but not KVM, KVM must unwind its
+* software model to the pre-VMEntry host state.  When EPT is disabled,
+* GUEST_CR3 holds KVM's shadow CR3, not L1's "real" CR3, which causes
+* nested_vmx_restore_host_state() to corrupt vcpu->arch.cr3.  Stuffing
+* vmcs01.GUEST_CR3 results in the unwind naturally setting arch.cr3 to
+* the correct value.  Smashing vmcs01.GUEST_CR3 is safe because nested
+* VM-Exits, and the unwind, reset KVM's MMU, i.e. vmcs01.GUEST_CR3 is
+* guaranteed to be overwritten with a shadow CR3 prior to re-entering
+* L1.  Don't stuff vmcs01.GUEST_CR3 when using nested early checks as
+* KVM modifies vcpu->arch.cr3 if and only if the early hardware checks
+* pass, and early VM-Fails do not reset KVM's MMU, i.e. the VM-Fail
+* path would need to manually save/restore vmcs01.GUEST_CR3.
+*/
+   if (!enable_ept && !nested_early_check)
+   vmcs_writel(GUEST_CR3, vcpu->arch.cr3);
+
vmx_switch_vmcs(vcpu, >nested.vmcs02);
 
prepare_vmcs02_early(vmx, vmcs12);
@@ -3779,18 +3798,8 @@ static void 

[PATCH AUTOSEL 5.2 120/171] PCI: mobiveil: Initialize Primary/Secondary/Subordinate bus numbers

[Sasha Levin]

From: Hou Zhiqiang 

[ Upstream commit 6f3ab451aa5c2cbff33197d82fe8489cbd55ad91 ]

The reset value of Primary, Secondary and Subordinate bus numbers is
zero which is a broken setup.

Program a sensible default value for Primary/Secondary/Subordinate
bus numbers.

Signed-off-by: Hou Zhiqiang 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Minghuan Lian 
Reviewed-by: Subrahmanya Lingappa 
Signed-off-by: Sasha Levin 
---
 drivers/pci/controller/pcie-mobiveil.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/pci/controller/pcie-mobiveil.c 
b/drivers/pci/controller/pcie-mobiveil.c
index 88e9b70081fc..e4a1964e1b43 100644
--- a/drivers/pci/controller/pcie-mobiveil.c
+++ b/drivers/pci/controller/pcie-mobiveil.c
@@ -501,6 +501,12 @@ static int mobiveil_host_init(struct mobiveil_pcie *pcie)
return err;
}
 
+   /* setup bus numbers */
+   value = csr_readl(pcie, PCI_PRIMARY_BUS);
+   value &= 0xff00;
+   value |= 0x00ff0100;
+   csr_writel(pcie, value, PCI_PRIMARY_BUS);
+
/*
 * program Bus Master Enable Bit in Command Register in PAB Config
 * Space
-- 
2.20.1

[PATCH AUTOSEL 5.2 113/171] IB/ipoib: Add child to parent list only if device initialized

[Sasha Levin]

From: Valentine Fatiev 

[ Upstream commit 91b01061fef9c57d2f5b712a6322ef51061f4efd ]

Despite failure in ipoib_dev_init() we continue with initialization flow
and creation of child device. It causes to the situation where this child
device is added too early to parent device list.

Change the logic, so in case of failure we properly return error from
ipoib_dev_init() and add child only in success path.

Fixes: eaeb39842508 ("IB/ipoib: Move init code to ndo_init")
Signed-off-by: Valentine Fatiev 
Reviewed-by: Feras Daoud 
Signed-off-by: Leon Romanovsky 
Reviewed-by: Jason Gunthorpe 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/ulp/ipoib/ipoib_main.c | 34 +--
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c 
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 9b5e11d3fb85..bb904ec511be 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -1893,12 +1893,6 @@ static void ipoib_child_init(struct net_device *ndev)
struct ipoib_dev_priv *priv = ipoib_priv(ndev);
struct ipoib_dev_priv *ppriv = ipoib_priv(priv->parent);
 
-   dev_hold(priv->parent);
-
-   down_write(>vlan_rwsem);
-   list_add_tail(>list, >child_intfs);
-   up_write(>vlan_rwsem);
-
priv->max_ib_mtu = ppriv->max_ib_mtu;
set_bit(IPOIB_FLAG_SUBINTERFACE, >flags);
memcpy(priv->dev->dev_addr, ppriv->dev->dev_addr, INFINIBAND_ALEN);
@@ -1941,6 +1935,17 @@ static int ipoib_ndo_init(struct net_device *ndev)
if (rc) {
pr_warn("%s: failed to initialize device: %s port %d (ret = 
%d)\n",
priv->ca->name, priv->dev->name, priv->port, rc);
+   return rc;
+   }
+
+   if (priv->parent) {
+   struct ipoib_dev_priv *ppriv = ipoib_priv(priv->parent);
+
+   dev_hold(priv->parent);
+
+   down_write(>vlan_rwsem);
+   list_add_tail(>list, >child_intfs);
+   up_write(>vlan_rwsem);
}
 
return 0;
@@ -1958,6 +1963,14 @@ static void ipoib_ndo_uninit(struct net_device *dev)
 */
WARN_ON(!list_empty(>child_intfs));
 
+   if (priv->parent) {
+   struct ipoib_dev_priv *ppriv = ipoib_priv(priv->parent);
+
+   down_write(>vlan_rwsem);
+   list_del(>list);
+   up_write(>vlan_rwsem);
+   }
+
ipoib_neigh_hash_uninit(dev);
 
ipoib_ib_dev_cleanup(dev);
@@ -1969,15 +1982,8 @@ static void ipoib_ndo_uninit(struct net_device *dev)
priv->wq = NULL;
}
 
-   if (priv->parent) {
-   struct ipoib_dev_priv *ppriv = ipoib_priv(priv->parent);
-
-   down_write(>vlan_rwsem);
-   list_del(>list);
-   up_write(>vlan_rwsem);
-
+   if (priv->parent)
dev_put(priv->parent);
-   }
 }
 
 static int ipoib_set_vf_link_state(struct net_device *dev, int vf, int 
link_state)
-- 
2.20.1

[PATCH AUTOSEL 5.2 110/171] serial: sh-sci: Fix TX DMA buffer flushing and workqueue races

[Sasha Levin]

From: Geert Uytterhoeven 

[ Upstream commit 8493eab02608b0e82f67b892aa72882e510c31d0 ]

When uart_flush_buffer() is called, the .flush_buffer() callback zeroes
the tx_dma_len field.  This may race with the work queue function
handling transmit DMA requests:

  1. If the buffer is flushed before the first DMA API call,
 dmaengine_prep_slave_single() may be called with a zero length,
 causing the DMA request to never complete, leading to messages
 like:

rcar-dmac e730.dma-controller: Channel Address Error happen

 and, with debug enabled:

sh-sci e6e88000.serial: sci_dma_tx_work_fn: 800639b55000: 0...0, 
cookie 126

 and DMA timeouts.

  2. If the buffer is flushed after the first DMA API call, but before
 the second, dma_sync_single_for_device() may be called with a zero
 length, causing the transmit data not to be flushed to RAM, and
 leading to stale data being output.

Fix this by:
  1. Letting sci_dma_tx_work_fn() return immediately if the transmit
 buffer is empty,
  2. Extending the critical section to cover all DMA preparational work,
 so tx_dma_len stays consistent for all of it,
  3. Using local copies of circ_buf.head and circ_buf.tail, to make sure
 they match the actual operation above.

Reported-by: Eugeniu Rosca 
Suggested-by: Yoshihiro Shimoda 
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Eugeniu Rosca 
Tested-by: Eugeniu Rosca 
Link: https://lore.kernel.org/r/20190624123540.20629-2-geert+rene...@glider.be
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/tty/serial/sh-sci.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 1d25c4e2d0d2..d18c680aa64b 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1398,6 +1398,7 @@ static void sci_dma_tx_work_fn(struct work_struct *work)
struct circ_buf *xmit = >state->xmit;
unsigned long flags;
dma_addr_t buf;
+   int head, tail;
 
/*
 * DMA is idle now.
@@ -1407,16 +1408,23 @@ static void sci_dma_tx_work_fn(struct work_struct *work)
 * consistent xmit buffer state.
 */
spin_lock_irq(>lock);
-   buf = s->tx_dma_addr + (xmit->tail & (UART_XMIT_SIZE - 1));
+   head = xmit->head;
+   tail = xmit->tail;
+   buf = s->tx_dma_addr + (tail & (UART_XMIT_SIZE - 1));
s->tx_dma_len = min_t(unsigned int,
-   CIRC_CNT(xmit->head, xmit->tail, UART_XMIT_SIZE),
-   CIRC_CNT_TO_END(xmit->head, xmit->tail, UART_XMIT_SIZE));
-   spin_unlock_irq(>lock);
+   CIRC_CNT(head, tail, UART_XMIT_SIZE),
+   CIRC_CNT_TO_END(head, tail, UART_XMIT_SIZE));
+   if (!s->tx_dma_len) {
+   /* Transmit buffer has been flushed */
+   spin_unlock_irq(>lock);
+   return;
+   }
 
desc = dmaengine_prep_slave_single(chan, buf, s->tx_dma_len,
   DMA_MEM_TO_DEV,
   DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!desc) {
+   spin_unlock_irq(>lock);
dev_warn(port->dev, "Failed preparing Tx DMA descriptor\n");
goto switch_to_pio;
}
@@ -1424,18 +1432,18 @@ static void sci_dma_tx_work_fn(struct work_struct *work)
dma_sync_single_for_device(chan->device->dev, buf, s->tx_dma_len,
   DMA_TO_DEVICE);
 
-   spin_lock_irq(>lock);
desc->callback = sci_dma_tx_complete;
desc->callback_param = s;
-   spin_unlock_irq(>lock);
s->cookie_tx = dmaengine_submit(desc);
if (dma_submit_error(s->cookie_tx)) {
+   spin_unlock_irq(>lock);
dev_warn(port->dev, "Failed submitting Tx DMA descriptor\n");
goto switch_to_pio;
}
 
+   spin_unlock_irq(>lock);
dev_dbg(port->dev, "%s: %p: %d...%d, cookie %d\n",
-   __func__, xmit->buf, xmit->tail, xmit->head, s->cookie_tx);
+   __func__, xmit->buf, tail, head, s->cookie_tx);
 
dma_async_issue_pending(chan);
return;
-- 
2.20.1

[PATCH AUTOSEL 5.2 114/171] arm64: assembler: Switch ESB-instruction with a vanilla nop if !ARM64_HAS_RAS

[Sasha Levin]

From: James Morse 

[ Upstream commit 2b68a2a963a157f024c67c0697b16f5f792c8a35 ]

The ESB-instruction is a nop on CPUs that don't implement the RAS
extensions. This lets us use it in places like the vectors without
having to use alternatives.

If someone disables CONFIG_ARM64_RAS_EXTN, this instruction still has
its RAS extensions behaviour, but we no longer read DISR_EL1 as this
register does depend on alternatives.

This could go wrong if we want to synchronize an SError from a KVM
guest. On a CPU that has the RAS extensions, but the KConfig option
was disabled, we consume the pending SError with no chance of ever
reading it.

Hide the ESB-instruction behind the CONFIG_ARM64_RAS_EXTN option,
outputting a regular nop if the feature has been disabled.

Reported-by: Julien Thierry 
Signed-off-by: James Morse 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin 
---
 arch/arm64/include/asm/assembler.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/include/asm/assembler.h 
b/arch/arm64/include/asm/assembler.h
index 570d195a184d..e3a15c751b13 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -96,7 +96,11 @@
  * RAS Error Synchronization barrier
  */
.macro  esb
+#ifdef CONFIG_ARM64_RAS_EXTN
hint#16
+#else
+   nop
+#endif
.endm
 
 /*
-- 
2.20.1

[PATCH AUTOSEL 5.2 119/171] kallsyms: exclude kasan local symbols on s390

[Sasha Levin]

From: Vasily Gorbik 

[ Upstream commit 33177f01ca3fe550146bb9001bec2fd806b2f40c ]

gcc asan instrumentation emits the following sequence to store frame pc
when the kernel is built with CONFIG_RELOCATABLE:
debug/vsprintf.s:
.section.data.rel.ro.local,"aw"
.align  8
.LC3:
.quad   .LASANPC4826@GOTOFF
.text
.align  8
.type   number, @function
number:
.LASANPC4826:

and in case reloc is issued for LASANPC label it also gets into .symtab
with the same address as actual function symbol:
$ nm -n vmlinux | grep 01397150
01397150 t .LASANPC4826
01397150 t number

In the end kernel backtraces are almost unreadable:
[  143.748476] Call Trace:
[  143.748484] ([<2da3e62c>] .LASANPC2671+0x114/0x190)
[  143.748492]  [<2eca1a58>] .LASANPC2612+0x110/0x160
[  143.748502]  [<2de9d830>] print_address_description+0x80/0x3b0
[  143.748511]  [<2de9dd64>] __kasan_report+0x15c/0x1c8
[  143.748521]  [<2ecb56d4>] strrchr+0x34/0x60
[  143.748534]  [<03ff800a9a40>] kasan_strings+0xb0/0x148 [test_kasan]
[  143.748547]  [<03ff800a9bba>] kmalloc_tests_init+0xe2/0x528 [test_kasan]
[  143.748555]  [<2da2117c>] .LASANPC4069+0x354/0x748
[  143.748563]  [<2dbfbb16>] do_init_module+0x136/0x3b0
[  143.748571]  [<2dbff3f4>] .LASANPC3191+0x2164/0x25d0
[  143.748580]  [<2dbffc4c>] .LASANPC3196+0x184/0x1b8
[  143.748587]  [<2ecdf2ec>] system_call+0xd8/0x2d8

Since LASANPC labels are not even unique and get into .symtab only due
to relocs filter them out in kallsyms.

Signed-off-by: Vasily Gorbik 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Sasha Levin 
---
 scripts/kallsyms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index e17837f1d3f2..ae6504d07fd6 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -150,6 +150,9 @@ static int read_symbol(FILE *in, struct sym_entry *s)
/* exclude debugging symbols */
else if (stype == 'N' || stype == 'n')
return -1;
+   /* exclude s390 kasan local symbols */
+   else if (!strncmp(sym, ".LASANPC", 8))
+   return -1;
 
/* include the type field in the symbol name, so that it gets
 * compressed together */
-- 
2.20.1

[PATCH AUTOSEL 5.2 136/171] nvme-pci: limit max_hw_sectors based on the DMA max mapping size

[Sasha Levin]

From: Christoph Hellwig 

[ Upstream commit 7637de311bd2124b298a072852448b940d8a34b9 ]

When running a NVMe device that is attached to a addressing
challenged PCIe root port that requires bounce buffering, our
request sizes can easily overflow the swiotlb bounce buffer
size.  Limit the maximum I/O size to the limit exposed by
the DMA mapping subsystem.

Signed-off-by: Christoph Hellwig 
Reported-by: Atish Patra 
Tested-by: Atish Patra 
Reviewed-by: Sagi Grimberg 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/host/pci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 5dfa067f6506..5c45f4cab060 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2515,7 +2515,8 @@ static void nvme_reset_work(struct work_struct *work)
 * Limit the max command size to prevent iod->sg allocations going
 * over a single page.
 */
-   dev->ctrl.max_hw_sectors = NVME_MAX_KB_SZ << 1;
+   dev->ctrl.max_hw_sectors = min_t(u32,
+   NVME_MAX_KB_SZ << 1, dma_max_mapping_size(dev->dev) >> 9);
dev->ctrl.max_segments = NVME_MAX_SEGS;
 
/*
-- 
2.20.1

[PATCH AUTOSEL 5.2 111/171] IB/mlx5: Fixed reporting counters on 2nd port for Dual port RoCE

[Sasha Levin]

From: Parav Pandit 

[ Upstream commit 2f40cf30c8644360d37287861d5288f00eab35e5 ]

Currently during dual port IB device registration in below code flow,

ib_register_device()
  ib_device_register_sysfs()
ib_setup_port_attrs()
  add_port()
get_counter_table()
  get_perf_mad()
process_mad()
  mlx5_ib_process_mad()

mlx5_ib_process_mad() fails on 2nd port when both the ports are not fully
setup at the device level (because 2nd port is unaffiliated).

As a result, get_perf_mad() registers different PMA counter group for 1st
and 2nd port, namely pma_counter_ext and pma_counter. However both ports
have the same capability and counter offsets.

Due to this when counters are read by the user via sysfs in below code
flow, counters are queried from wrong location from the device mainly from
PPCNT instead of VPORT counters.

show_pma_counter()
  get_perf_mad()
process_mad()
  mlx5_ib_process_mad()
process_pma_cmd()

This shows all zero counters for 2nd port.

To overcome this, process_pma_cmd() is invoked, and when unaffiliated port
is not yet setup during device registration phase, make the query on the
first port.  while at it, only process_pma_cmd() needs to work on the
native port number and underlying mdev, so shift the get, put calls to
where its needed inside process_pma_cmd().

Fixes: 212f2a87b74f ("IB/mlx5: Route MADs for dual port RoCE")
Signed-off-by: Parav Pandit 
Reviewed-by: Daniel Jurgens 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/hw/mlx5/mad.c | 60 +++-
 1 file changed, 36 insertions(+), 24 deletions(-)

diff --git a/drivers/infiniband/hw/mlx5/mad.c b/drivers/infiniband/hw/mlx5/mad.c
index 6c529e6f3a01..348c1df69cdc 100644
--- a/drivers/infiniband/hw/mlx5/mad.c
+++ b/drivers/infiniband/hw/mlx5/mad.c
@@ -200,19 +200,33 @@ static void pma_cnt_assign(struct ib_pma_portcounters 
*pma_cnt,
 vl_15_dropped);
 }
 
-static int process_pma_cmd(struct mlx5_core_dev *mdev, u8 port_num,
+static int process_pma_cmd(struct mlx5_ib_dev *dev, u8 port_num,
   const struct ib_mad *in_mad, struct ib_mad *out_mad)
 {
-   int err;
+   struct mlx5_core_dev *mdev;
+   bool native_port = true;
+   u8 mdev_port_num;
void *out_cnt;
+   int err;
 
+   mdev = mlx5_ib_get_native_port_mdev(dev, port_num, _port_num);
+   if (!mdev) {
+   /* Fail to get the native port, likely due to 2nd port is still
+* unaffiliated. In such case default to 1st port and attached
+* PF device.
+*/
+   native_port = false;
+   mdev = dev->mdev;
+   mdev_port_num = 1;
+   }
/* Declaring support of extended counters */
if (in_mad->mad_hdr.attr_id == IB_PMA_CLASS_PORT_INFO) {
struct ib_class_port_info cpi = {};
 
cpi.capability_mask = IB_PMA_CLASS_CAP_EXT_WIDTH;
memcpy((out_mad->data + 40), , sizeof(cpi));
-   return IB_MAD_RESULT_SUCCESS | IB_MAD_RESULT_REPLY;
+   err = IB_MAD_RESULT_SUCCESS | IB_MAD_RESULT_REPLY;
+   goto done;
}
 
if (in_mad->mad_hdr.attr_id == IB_PMA_PORT_COUNTERS_EXT) {
@@ -221,11 +235,13 @@ static int process_pma_cmd(struct mlx5_core_dev *mdev, u8 
port_num,
int sz = MLX5_ST_SZ_BYTES(query_vport_counter_out);
 
out_cnt = kvzalloc(sz, GFP_KERNEL);
-   if (!out_cnt)
-   return IB_MAD_RESULT_FAILURE;
+   if (!out_cnt) {
+   err = IB_MAD_RESULT_FAILURE;
+   goto done;
+   }
 
err = mlx5_core_query_vport_counter(mdev, 0, 0,
-   port_num, out_cnt, sz);
+   mdev_port_num, out_cnt, sz);
if (!err)
pma_cnt_ext_assign(pma_cnt_ext, out_cnt);
} else {
@@ -234,20 +250,23 @@ static int process_pma_cmd(struct mlx5_core_dev *mdev, u8 
port_num,
int sz = MLX5_ST_SZ_BYTES(ppcnt_reg);
 
out_cnt = kvzalloc(sz, GFP_KERNEL);
-   if (!out_cnt)
-   return IB_MAD_RESULT_FAILURE;
+   if (!out_cnt) {
+   err = IB_MAD_RESULT_FAILURE;
+   goto done;
+   }
 
-   err = mlx5_core_query_ib_ppcnt(mdev, port_num,
+   err = mlx5_core_query_ib_ppcnt(mdev, mdev_port_num,
   out_cnt, sz);
if (!err)
pma_cnt_assign(pma_cnt, out_cnt);
-   }
-
+   }
kvfree(out_cnt);
-   if (err)
-   return IB_MAD_RESULT_FAILURE;
-
-   return IB_MAD_RESULT_SUCCESS | 

[PATCH AUTOSEL 5.2 127/171] perf session: Fix potential NULL pointer dereference found by the smatch tool

[Sasha Levin]

From: Leo Yan 

[ Upstream commit f3c8d90757724982e5f07cd77d315eb64ca145ac ]

Based on the following report from Smatch, fix the potential
NULL pointer dereference check.

  tools/perf/util/session.c:1252
  dump_read() error: we previously assumed 'evsel' could be null
  (see line 1249)

  tools/perf/util/session.c
  1240 static void dump_read(struct perf_evsel *evsel, union perf_event *event)
  1241 {
  1242 struct read_event *read_event = >read;
  1243 u64 read_format;
  1244
  1245 if (!dump_trace)
  1246 return;
  1247
  1248 printf(": %d %d %s %" PRIu64 "\n", event->read.pid, 
event->read.tid,
  1249evsel ? perf_evsel__name(evsel) : "FAIL",
  1250event->read.value);
  1251
  1252 read_format = evsel->attr.read_format;
 ^^^

'evsel' could be NULL pointer, for this case this patch directly bails
out without dumping read_event.

Signed-off-by: Leo Yan 
Acked-by: Jiri Olsa 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Alexey Budankov 
Cc: Alexios Zavras 
Cc: Andi Kleen 
Cc: Changbin Du 
Cc: David S. Miller 
Cc: Davidlohr Bueso 
Cc: Eric Saint-Etienne 
Cc: Jin Yao 
Cc: Konstantin Khlebnikov 
Cc: Mathieu Poirier 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Rasmus Villemoes 
Cc: Song Liu 
Cc: Suzuki Poulouse 
Cc: Thomas Gleixner 
Cc: Thomas Richter 
Cc: linux-arm-ker...@lists.infradead.org
Link: http://lkml.kernel.org/r/20190702103420.27540-9-leo@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/util/session.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 54cf163347f7..2e61dd6a3574 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1249,6 +1249,9 @@ static void dump_read(struct perf_evsel *evsel, union 
perf_event *event)
   evsel ? perf_evsel__name(evsel) : "FAIL",
   event->read.value);
 
+   if (!evsel)
+   return;
+
read_format = evsel->attr.read_format;
 
if (read_format & PERF_FORMAT_TOTAL_TIME_ENABLED)
-- 
2.20.1

[PATCH AUTOSEL 5.2 133/171] perf intel-bts: Fix potential NULL pointer dereference found by the smatch tool

[Sasha Levin]

From: Leo Yan 

[ Upstream commit 1d481458816d9424c8a05833ce0ebe72194a350e ]

Based on the following report from Smatch, fix the potential NULL
pointer dereference check.

  tools/perf/util/intel-bts.c:898
  intel_bts_process_auxtrace_info() error: we previously assumed
  'session->itrace_synth_opts' could be null (see line 894)

  tools/perf/util/intel-bts.c:899
  intel_bts_process_auxtrace_info() warn: variable dereferenced before
  check 'session->itrace_synth_opts' (see line 898)

  tools/perf/util/intel-bts.c
  894 if (session->itrace_synth_opts && 
session->itrace_synth_opts->set) {
  895 bts->synth_opts = *session->itrace_synth_opts;
  896 } else {
  897 itrace_synth_opts__set_default(>synth_opts,
  898 
session->itrace_synth_opts->default_no_sample);
  ^^
  899 if (session->itrace_synth_opts)
  ^^
  900 bts->synth_opts.thread_stack =
  901 session->itrace_synth_opts->thread_stack;
  902 }

'session->itrace_synth_opts' is impossible to be a NULL pointer in
intel_bts_process_auxtrace_info(), thus this patch removes the NULL test
for 'session->itrace_synth_opts'.

Signed-off-by: Leo Yan 
Acked-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Mathieu Poirier 
Cc: Namhyung Kim 
Cc: Suzuki Poulouse 
Cc: linux-arm-ker...@lists.infradead.org
Link: http://lkml.kernel.org/r/20190708143937.7722-3-leo@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/util/intel-bts.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/intel-bts.c b/tools/perf/util/intel-bts.c
index e32dbffebb2f..625ad3639a7e 100644
--- a/tools/perf/util/intel-bts.c
+++ b/tools/perf/util/intel-bts.c
@@ -891,13 +891,12 @@ int intel_bts_process_auxtrace_info(union perf_event 
*event,
if (dump_trace)
return 0;
 
-   if (session->itrace_synth_opts && session->itrace_synth_opts->set) {
+   if (session->itrace_synth_opts->set) {
bts->synth_opts = *session->itrace_synth_opts;
} else {
itrace_synth_opts__set_default(>synth_opts,
session->itrace_synth_opts->default_no_sample);
-   if (session->itrace_synth_opts)
-   bts->synth_opts.thread_stack =
+   bts->synth_opts.thread_stack =
session->itrace_synth_opts->thread_stack;
}
 
-- 
2.20.1

[PATCH AUTOSEL 5.2 115/171] PCI: tegra: Enable Relaxed Ordering only for Tegra20 & Tegra30

[Sasha Levin]

From: Vidya Sagar 

[ Upstream commit 7be142caabc4780b13a522c485abc806de5c4114 ]

The PCI Tegra controller conversion to a device tree configurable
driver in commit d1523b52bff3 ("PCI: tegra: Move PCIe driver
to drivers/pci/host") implied that code for the driver can be
compiled in for a kernel supporting multiple platforms.

Unfortunately, a blind move of the code did not check that some of the
quirks that were applied in arch/arm (eg enabling Relaxed Ordering on
all PCI devices - since the quirk hook erroneously matches PCI_ANY_ID
for both Vendor-ID and Device-ID) are now applied in all kernels that
compile the PCI Tegra controlled driver, DT and ACPI alike.

This is completely wrong, in that enablement of Relaxed Ordering is only
required by default in Tegra20 platforms as described in the Tegra20
Technical Reference Manual (available at
https://developer.nvidia.com/embedded/downloads#?search=tegra%202 in
Section 34.1, where it is mentioned that Relaxed Ordering bit needs to
be enabled in its root ports to avoid deadlock in hardware) and in the
Tegra30 platforms for the same reasons (unfortunately not documented
in the TRM).

There is no other strict requirement on PCI devices Relaxed Ordering
enablement on any other Tegra platforms or PCI host bridge driver.

Fix this quite upsetting situation by limiting the vendor and device IDs
to which the Relaxed Ordering quirk applies to the root ports in
question, reported above.

Signed-off-by: Vidya Sagar 
[lorenzo.pieral...@arm.com: completely rewrote the commit log/fixes tag]
Signed-off-by: Lorenzo Pieralisi 
Acked-by: Thierry Reding 
Signed-off-by: Sasha Levin 
---
 drivers/pci/controller/pci-tegra.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/pci-tegra.c 
b/drivers/pci/controller/pci-tegra.c
index 464ba2538d52..bc7be369c1b3 100644
--- a/drivers/pci/controller/pci-tegra.c
+++ b/drivers/pci/controller/pci-tegra.c
@@ -545,12 +545,15 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0bf1, 
tegra_pcie_fixup_class);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0e1c, tegra_pcie_fixup_class);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0e1d, tegra_pcie_fixup_class);
 
-/* Tegra PCIE requires relaxed ordering */
+/* Tegra20 and Tegra30 PCIE requires relaxed ordering */
 static void tegra_pcie_relax_enable(struct pci_dev *dev)
 {
pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_RELAX_EN);
 }
-DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, tegra_pcie_relax_enable);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, 0x0bf0, tegra_pcie_relax_enable);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, 0x0bf1, tegra_pcie_relax_enable);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, 0x0e1c, tegra_pcie_relax_enable);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, 0x0e1d, tegra_pcie_relax_enable);
 
 static int tegra_pcie_request_resources(struct tegra_pcie *pcie)
 {
-- 
2.20.1

[PATCH AUTOSEL 5.2 158/171] mm/mincore.c: fix race between swapoff and mincore

[Sasha Levin]

From: Huang Ying 

[ Upstream commit aeb309b81c6bada783c3695528a3e10748e97285 ]

Via commit 4b3ef9daa4fc ("mm/swap: split swap cache into 64MB trunks"),
after swapoff, the address_space associated with the swap device will be
freed.  So swap_address_space() users which touch the address_space need
some kind of mechanism to prevent the address_space from being freed
during accessing.

When mincore processes an unmapped range for swapped shmem pages, it
doesn't hold the lock to prevent swap device from being swapped off.  So
the following race is possible:

CPU1CPU2
do_mincore()swapoff()
  walk_page_range()
mincore_unmapped_range()
  __mincore_unmapped_range
mincore_page
  as = swap_address_space()
  ... exit_swap_address_space()
  ...   kvfree(spaces)
  find_get_page(as)

The address space may be accessed after being freed.

To fix the race, get_swap_device()/put_swap_device() is used to enclose
find_get_page() to check whether the swap entry is valid and prevent the
swap device from being swapoff during accessing.

Link: http://lkml.kernel.org/r/20190611020510.28251-1-ying.hu...@intel.com
Fixes: 4b3ef9daa4fc ("mm/swap: split swap cache into 64MB trunks")
Signed-off-by: "Huang, Ying" 
Reviewed-by: Andrew Morton 
Acked-by: Michal Hocko 
Cc: Hugh Dickins 
Cc: Paul E. McKenney 
Cc: Minchan Kim 
Cc: Johannes Weiner 
Cc: Tim Chen 
Cc: Mel Gorman 
Cc: Jérôme Glisse 
Cc: Andrea Arcangeli 
Cc: Yang Shi 
Cc: David Rientjes 
Cc: Rik van Riel 
Cc: Jan Kara 
Cc: Dave Jiang 
Cc: Daniel Jordan 
Cc: Andrea Parri 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
---
 mm/mincore.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/mm/mincore.c b/mm/mincore.c
index c3f058bd0faf..4fe91d497436 100644
--- a/mm/mincore.c
+++ b/mm/mincore.c
@@ -68,8 +68,16 @@ static unsigned char mincore_page(struct address_space 
*mapping, pgoff_t pgoff)
 */
if (xa_is_value(page)) {
swp_entry_t swp = radix_to_swp_entry(page);
-   page = find_get_page(swap_address_space(swp),
-swp_offset(swp));
+   struct swap_info_struct *si;
+
+   /* Prevent swap device to being swapoff under us */
+   si = get_swap_device(swp);
+   if (si) {
+   page = find_get_page(swap_address_space(swp),
+swp_offset(swp));
+   put_swap_device(si);
+   } else
+   page = NULL;
}
} else
page = find_get_page(mapping, pgoff);
-- 
2.20.1

[PATCH AUTOSEL 5.2 138/171] io_uring: fix io_sq_thread_stop running in front of io_sq_thread

[Sasha Levin]

From: Jackie Liu 

[ Upstream commit a4c0b3decb33fb4a2b5ecc6234a50680f0b21e7d ]

INFO: task syz-executor.5:8634 blocked for more than 143 seconds.
   Not tainted 5.2.0-rc5+ #3
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor.5  D25632  8634   8224 0x4004
Call Trace:
  context_switch kernel/sched/core.c:2818 [inline]
  __schedule+0x658/0x9e0 kernel/sched/core.c:3445
  schedule+0x131/0x1d0 kernel/sched/core.c:3509
  schedule_timeout+0x9a/0x2b0 kernel/time/timer.c:1783
  do_wait_for_common+0x35e/0x5a0 kernel/sched/completion.c:83
  __wait_for_common kernel/sched/completion.c:104 [inline]
  wait_for_common kernel/sched/completion.c:115 [inline]
  wait_for_completion+0x47/0x60 kernel/sched/completion.c:136
  kthread_stop+0xb4/0x150 kernel/kthread.c:559
  io_sq_thread_stop fs/io_uring.c:2252 [inline]
  io_finish_async fs/io_uring.c:2259 [inline]
  io_ring_ctx_free fs/io_uring.c:2770 [inline]
  io_ring_ctx_wait_and_kill+0x268/0x880 fs/io_uring.c:2834
  io_uring_release+0x5d/0x70 fs/io_uring.c:2842
  __fput+0x2e4/0x740 fs/file_table.c:280
  fput+0x15/0x20 fs/file_table.c:313
  task_work_run+0x17e/0x1b0 kernel/task_work.c:113
  tracehook_notify_resume include/linux/tracehook.h:185 [inline]
  exit_to_usermode_loop arch/x86/entry/common.c:168 [inline]
  prepare_exit_to_usermode+0x402/0x4f0 arch/x86/entry/common.c:199
  syscall_return_slowpath+0x110/0x440 arch/x86/entry/common.c:279
  do_syscall_64+0x126/0x140 arch/x86/entry/common.c:304
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x412fb1
Code: 80 3b 7c 0f 84 c7 02 00 00 c7 85 d0 00 00 00 00 00 00 00 48 8b 05 cf
a6 24 00 49 8b 14 24 41 b9 cb 2a 44 00 48 89 ee 48 89 df <48> 85 c0 4c 0f
45 c8 45 31 c0 31 c9 e8 0e 5b 00 00 85 c0 41 89 c7
RSP: 002b:7ffe7ee6a180 EFLAGS: 0293 ORIG_RAX: 0003
RAX:  RBX: 0004 RCX: 00412fb1
RDX: 001b2d92 RSI:  RDI: 0003
RBP: 0001 R08: f3a3e1f8 R09: f3a3e1fc
R10: 7ffe7ee6a260 R11: 0293 R12: 0075c9a0
R13: 0075c9a0 R14: 00024c00 R15: 0075bf2c

=

There is an wrong logic, when kthread_park running
in front of io_sq_thread.

CPU#0   CPU#1

io_sq_thread_stop:  int kthread(void *_create):

kthread_park()
__kthread_parkme(self);  <<< Wrong
kthread_stop()
<< wait for self->exited
<< clear_bit KTHREAD_SHOULD_PARK

ret = threadfn(data);
   |
   |- io_sq_thread
   |- kthread_should_park() << false
   |- schedule() <<< nobody wake up

stuck CPU#0 stuck CPU#1

So, use a new variable sqo_thread_started to ensure that io_sq_thread
run first, then io_sq_thread_stop.

Reported-by: syzbot+94324416c485d422f...@syzkaller.appspotmail.com
Suggested-by: Jens Axboe 
Signed-off-by: Jackie Liu 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 fs/io_uring.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 4ef62a45045d..fef2cd44b2ac 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -231,6 +231,7 @@ struct io_ring_ctx {
struct task_struct  *sqo_thread;/* if using sq thread polling */
struct mm_struct*sqo_mm;
wait_queue_head_t   sqo_wait;
+   struct completion   sqo_thread_started;
 
struct {
/* CQ ring */
@@ -403,6 +404,7 @@ static struct io_ring_ctx *io_ring_ctx_alloc(struct 
io_uring_params *p)
ctx->flags = p->flags;
init_waitqueue_head(>cq_wait);
init_completion(>ctx_done);
+   init_completion(>sqo_thread_started);
mutex_init(>uring_lock);
init_waitqueue_head(>wait);
for (i = 0; i < ARRAY_SIZE(ctx->pending_async); i++) {
@@ -2009,6 +2011,8 @@ static int io_sq_thread(void *data)
unsigned inflight;
unsigned long timeout;
 
+   complete(>sqo_thread_started);
+
old_fs = get_fs();
set_fs(USER_DS);
 
@@ -2243,6 +2247,7 @@ static int io_sqe_files_unregister(struct io_ring_ctx 
*ctx)
 static void io_sq_thread_stop(struct io_ring_ctx *ctx)
 {
if (ctx->sqo_thread) {
+   wait_for_completion(>sqo_thread_started);
/*
 * The park is a bit of a work-around, without it we get
 * warning spews on shutdown with SQPOLL set and affinity
-- 
2.20.1

[PATCH AUTOSEL 5.2 140/171] powerpc/irq: Don't WARN continuously in arch_local_irq_restore()

[Sasha Levin]

From: Michael Ellerman 

[ Upstream commit 0fc12c022ad25532b66bf6f6c818ee1c1d63e702 ]

When CONFIG_PPC_IRQ_SOFT_MASK_DEBUG is enabled (uncommon), we have a
series of WARN_ON's in arch_local_irq_restore().

These are "should never happen" conditions, but if they do happen they
can flood the console and render the system unusable. So switch them
to WARN_ON_ONCE().

Fixes: e2b36d591720 ("powerpc/64: Don't trace code that runs with the soft irq 
mask unreconciled")
Fixes: 9b81c0211c24 ("powerpc/64s: make PACA_IRQ_HARD_DIS track MSR[EE] 
closely")
Fixes: 7c0482e3d055 ("powerpc/irq: Fix another case of lazy IRQ state getting 
out of sync")
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20190708061046.7075-1-...@ellerman.id.au
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/irq.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index bc68c53af67c..5645bc9cbc09 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -255,7 +255,7 @@ notrace void arch_local_irq_restore(unsigned long mask)
irq_happened = get_irq_happened();
if (!irq_happened) {
 #ifdef CONFIG_PPC_IRQ_SOFT_MASK_DEBUG
-   WARN_ON(!(mfmsr() & MSR_EE));
+   WARN_ON_ONCE(!(mfmsr() & MSR_EE));
 #endif
return;
}
@@ -268,7 +268,7 @@ notrace void arch_local_irq_restore(unsigned long mask)
 */
if (!(irq_happened & PACA_IRQ_HARD_DIS)) {
 #ifdef CONFIG_PPC_IRQ_SOFT_MASK_DEBUG
-   WARN_ON(!(mfmsr() & MSR_EE));
+   WARN_ON_ONCE(!(mfmsr() & MSR_EE));
 #endif
__hard_irq_disable();
 #ifdef CONFIG_PPC_IRQ_SOFT_MASK_DEBUG
@@ -279,7 +279,7 @@ notrace void arch_local_irq_restore(unsigned long mask)
 * warn if we are wrong. Only do that when IRQ tracing
 * is enabled as mfmsr() can be costly.
 */
-   if (WARN_ON(mfmsr() & MSR_EE))
+   if (WARN_ON_ONCE(mfmsr() & MSR_EE))
__hard_irq_disable();
 #endif
}
-- 
2.20.1

[PATCH AUTOSEL 5.2 161/171] memcg, fsnotify: no oom-kill for remote memcg charging

[Sasha Levin]

From: Shakeel Butt 

[ Upstream commit ec165450968b26298bd1c373de37b0ab6d826b33 ]

Commit d46eb14b735b ("fs: fsnotify: account fsnotify metadata to
kmemcg") added remote memcg charging for fanotify and inotify event
objects.  The aim was to charge the memory to the listener who is
interested in the events but without triggering the OOM killer.
Otherwise there would be security concerns for the listener.

At the time, oom-kill trigger was not in the charging path.  A parallel
work added the oom-kill back to charging path i.e.  commit 29ef680ae7c2
("memcg, oom: move out_of_memory back to the charge path").  So to not
trigger oom-killer in the remote memcg, explicitly add
__GFP_RETRY_MAYFAIL to the fanotigy and inotify event allocations.

Link: http://lkml.kernel.org/r/20190514212259.156585-2-shake...@google.com
Signed-off-by: Shakeel Butt 
Reviewed-by: Roman Gushchin 
Acked-by: Jan Kara 
Cc: Johannes Weiner 
Cc: Vladimir Davydov 
Cc: Michal Hocko 
Cc: Amir Goldstein 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
---
 fs/notify/fanotify/fanotify.c| 5 -
 fs/notify/inotify/inotify_fsnotify.c | 8 ++--
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index b428c295d13f..5778d1347b35 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -288,10 +288,13 @@ struct fanotify_event *fanotify_alloc_event(struct 
fsnotify_group *group,
/*
 * For queues with unlimited length lost events are not expected and
 * can possibly have security implications. Avoid losing events when
-* memory is short.
+* memory is short. For the limited size queues, avoid OOM killer in the
+* target monitoring memcg as it may have security repercussion.
 */
if (group->max_events == UINT_MAX)
gfp |= __GFP_NOFAIL;
+   else
+   gfp |= __GFP_RETRY_MAYFAIL;
 
/* Whoever is interested in the event, pays for the allocation. */
memalloc_use_memcg(group->memcg);
diff --git a/fs/notify/inotify/inotify_fsnotify.c 
b/fs/notify/inotify/inotify_fsnotify.c
index 2fda08b2b885..d510223d302c 100644
--- a/fs/notify/inotify/inotify_fsnotify.c
+++ b/fs/notify/inotify/inotify_fsnotify.c
@@ -90,9 +90,13 @@ int inotify_handle_event(struct fsnotify_group *group,
i_mark = container_of(inode_mark, struct inotify_inode_mark,
  fsn_mark);
 
-   /* Whoever is interested in the event, pays for the allocation. */
+   /*
+* Whoever is interested in the event, pays for the allocation. Do not
+* trigger OOM killer in the target monitoring memcg as it may have
+* security repercussion.
+*/
memalloc_use_memcg(group->memcg);
-   event = kmalloc(alloc_len, GFP_KERNEL_ACCOUNT);
+   event = kmalloc(alloc_len, GFP_KERNEL_ACCOUNT | __GFP_RETRY_MAYFAIL);
memalloc_unuse_memcg();
 
if (unlikely(!event)) {
-- 
2.20.1

[PATCH AUTOSEL 5.2 153/171] nvme: fix NULL deref for fabrics options

[Sasha Levin]

From: Minwoo Im 

[ Upstream commit 7d30c81b80ea9b0812d27030a46a5bf4c4e328f5 ]

git://git.infradead.org/nvme.git nvme-5.3 branch now causes the
following NULL deref oops.  Check the ctrl->opts first before the deref.

[   16.337581] BUG: kernel NULL pointer dereference, address: 0056
[   16.338551] #PF: supervisor read access in kernel mode
[   16.338551] #PF: error_code(0x) - not-present page
[   16.338551] PGD 0 P4D 0
[   16.338551] Oops:  [#1] SMP PTI
[   16.338551] CPU: 2 PID: 1035 Comm: kworker/u16:5 Not tainted 5.2.0-rc6+ #1
[   16.338551] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org 04/01/2014
[   16.338551] Workqueue: nvme-wq nvme_scan_work [nvme_core]
[   16.338551] RIP: 0010:nvme_validate_ns+0xc9/0x7e0 [nvme_core]
[   16.338551] Code: c0 49 89 c5 0f 84 00 07 00 00 48 8b 7b 58 e8 be 48 39 c1 
48 3d 00 f0 ff ff 49 89 45 18 0f 87 a4 06 00 00 48 8b 93 70 0a 00 00 <80> 7a 56 
00 74 0c 48 8b 40 68 83 48 3c 08 49 8b 45 18 48 89 c6 bf
[   16.338551] RSP: 0018:c900024c7d10 EFLAGS: 00010283
[   16.338551] RAX: 888135a30720 RBX: 88813a4fd1f8 RCX: 0007
[   16.338551] RDX:  RSI: 8256dd38 RDI: 888135a30720
[   16.338551] RBP: 0001 R08: 0007 R09: 88813aa6a840
[   16.338551] R10: 0001 R11: 0002d060 R12: 88813a4fd1f8
[   16.338551] R13: 88813a77f800 R14: 88813aa35180 R15: 0001
[   16.338551] FS:  () GS:88813ba8() 
knlGS:
[   16.338551] CS:  0010 DS:  ES:  CR0: 80050033
[   16.338551] CR2: 0056 CR3: 0240a002 CR4: 00360ee0
[   16.338551] DR0:  DR1:  DR2: 
[   16.338551] DR3:  DR6: fffe0ff0 DR7: 0400
[   16.338551] Call Trace:
[   16.338551]  nvme_scan_work+0x2c0/0x340 [nvme_core]
[   16.338551]  ? __switch_to_asm+0x40/0x70
[   16.338551]  ? _raw_spin_unlock_irqrestore+0x18/0x30
[   16.338551]  ? try_to_wake_up+0x408/0x450
[   16.338551]  process_one_work+0x20b/0x3e0
[   16.338551]  worker_thread+0x1f9/0x3d0
[   16.338551]  ? cancel_delayed_work+0xa0/0xa0
[   16.338551]  kthread+0x117/0x120
[   16.338551]  ? kthread_stop+0xf0/0xf0
[   16.338551]  ret_from_fork+0x3a/0x50
[   16.338551] Modules linked in: nvme nvme_core
[   16.338551] CR2: 0056
[   16.338551] ---[ end trace b9bf761a93e62d84 ]---
[   16.338551] RIP: 0010:nvme_validate_ns+0xc9/0x7e0 [nvme_core]
[   16.338551] Code: c0 49 89 c5 0f 84 00 07 00 00 48 8b 7b 58 e8 be 48 39 c1 
48 3d 00 f0 ff ff 49 89 45 18 0f 87 a4 06 00 00 48 8b 93 70 0a 00 00 <80> 7a 56 
00 74 0c 48 8b 40 68 83 48 3c 08 49 8b 45 18 48 89 c6 bf
[   16.338551] RSP: 0018:c900024c7d10 EFLAGS: 00010283
[   16.338551] RAX: 888135a30720 RBX: 88813a4fd1f8 RCX: 0007
[   16.338551] RDX:  RSI: 8256dd38 RDI: 888135a30720
[   16.338551] RBP: 0001 R08: 0007 R09: 88813aa6a840
[   16.338551] R10: 0001 R11: 0002d060 R12: 88813a4fd1f8
[   16.338551] R13: 88813a77f800 R14: 88813aa35180 R15: 0001
[   16.338551] FS:  () GS:88813ba8() 
knlGS:
[   16.338551] CS:  0010 DS:  ES:  CR0: 80050033
[   16.338551] CR2: 0056 CR3: 0240a002 CR4: 00360ee0
[   16.338551] DR0:  DR1:  DR2: 
[   16.338551] DR3:  DR6: fffe0ff0 DR7: 0400

Fixes: 958f2a0f8121 ("nvme-tcp: set the STABLE_WRITES flag when data digests 
are enabled")
Cc: Christoph Hellwig 
Cc: Keith Busch 
Reviewed-by: Sagi Grimberg 
Signed-off-by: Minwoo Im 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/host/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index b4048748551e..db5731657529 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -3257,7 +3257,7 @@ static int nvme_alloc_ns(struct nvme_ctrl *ctrl, unsigned 
nsid)
goto out_free_ns;
}
 
-   if (ctrl->opts->data_digest)
+   if (ctrl->opts && ctrl->opts->data_digest)
ns->queue->backing_dev_info->capabilities
|= BDI_CAP_STABLE_WRITES;
 
-- 
2.20.1

Re: [PATCH] mm/Kconfig: additional help text for HMM_MIRROR option

[Ira Weiny]

On Thu, Jul 18, 2019 at 06:32:53PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard 
> 
> The HMM_MIRROR option in Kconfig is a little underdocumented and
> mysterious, and leaves people wondering whether to enable it.
> 
> Add text explaining just a little bit more about HMM, and also
> mention which hardware would benefit from having HMM_MIRROR
> enabled.
> 
> Suggested-by: Pavel Machek 
> Cc: Balbir Singh 
> Cc: Dan Williams 
> Cc: Jason Gunthorpe 
> Cc: Jerome Glisse 
> Cc: Christoph Hellwig 
> Signed-off-by: John Hubbard 
> ---
> 
> Hi Pavel and all, does this help? I've tried to capture the key missing bits
> of documentation, but still keep it small, for Kconfig.
> 
> thanks,
> John Hubbard
> NVIDIA
> 
>  mm/Kconfig | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 56cec636a1fc..2fcb92e7f696 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -681,11 +681,18 @@ config HMM_MIRROR
>   depends on MMU && 64BIT
>   select MMU_NOTIFIER
>   help
> -   Select HMM_MIRROR if you want to mirror range of the CPU page table 
> of a
> -   process into a device page table. Here, mirror means "keep 
> synchronized".
> -   Prerequisites: the device must provide the ability to write-protect 
> its
> -   page tables (at PAGE_SIZE granularity), and must be able to recover 
> from
> -   the resulting potential page faults.
> +   This is Heterogeneous Memory Management (HMM) process address space
> +   mirroring.
> +
> +   HMM_MIRROR provides a way to mirror ranges of the CPU page tables
> +   of a process into a device page table. Here, mirror means "keep
> +   synchronized". Prerequisites: the device must provide the ability
> +   to write-protect its page tables (at PAGE_SIZE granularity), and
> +   must be able to recover from the resulting potential page faults.
> +
> +   Select HMM_MIRROR if you have hardware that meets the above
> +   description. An early, partial list of such hardware is:
> +   an NVIDIA GPU >= Pascal, Mellanox IB >= mlx5, or an AMD GPU.

I don't think we want to put device information here.  If we want that
information in Kconfig best to put it in the devices themselves.  Otherwise
this list will get stale.

Other than that, looks good.

Reviewed-by: Ira Weiny 

Ira

>  
>  config DEVICE_PRIVATE
>   bool "Unaddressable device memory (GPU memory, ...)"
> -- 
> 2.22.0
> 

[PATCH AUTOSEL 5.2 134/171] RDMA/core: Fix race when resolving IP address

[Sasha Levin]

From: Dag Moxnes 

[ Upstream commit d8d9ec7dc5abbb3f11d866e983c4984f5c2de9d6 ]

Use the neighbour lock when copying the MAC address from the neighbour
data struct in dst_fetch_ha.

When not using the lock, it is possible for the function to race with
neigh_update(), causing it to copy an torn MAC address:

rdma_resolve_addr()
  rdma_resolve_ip()
addr_resolve()
  addr_resolve_neigh()
fetch_ha()
  dst_fetch_ha()
 memcpy(dev_addr->dst_dev_addr, n->ha, MAX_ADDR_LEN)

and

net_ioctl()
  arp_ioctl()
arp_rec_delete()
  arp_invalidate()
neigh_update()
  __neigh_update()
memcpy(>ha, lladdr, dev->addr_len)

It is possible to provoke this error by calling rdma_resolve_addr() in a
tight loop, while deleting the corresponding ARP entry in another tight
loop.

Fixes: 51d45974515c ("infiniband: addr: Consolidate code to fetch neighbour 
hardware address from dst.")
Signed-off-by: Dag Moxnes 
Signed-off-by: Håkon Bugge 
Reviewed-by: Jason Gunthorpe 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/core/addr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index 2f7d14159841..9b76a8fcdd24 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -337,7 +337,7 @@ static int dst_fetch_ha(const struct dst_entry *dst,
neigh_event_send(n, NULL);
ret = -ENODATA;
} else {
-   memcpy(dev_addr->dst_dev_addr, n->ha, MAX_ADDR_LEN);
+   neigh_ha_snapshot(dev_addr->dst_dev_addr, n, dst->dev);
}
 
neigh_release(n);
-- 
2.20.1

[PATCH AUTOSEL 5.2 148/171] powerpc/eeh: Handle hugepages in ioremap space

[Sasha Levin]

From: Oliver O'Halloran 

[ Upstream commit 33439620680be5225c1b8806579a291e0d761ca0 ]

In commit 4a7b06c157a2 ("powerpc/eeh: Handle hugepages in ioremap
space") support for using hugepages in the vmalloc and ioremap areas was
enabled for radix. Unfortunately this broke EEH MMIO error checking.

Detection works by inserting a hook which checks the results of the
ioreadXX() set of functions.  When a read returns a 0xFFs response we
need to check for an error which we do by mapping the (virtual) MMIO
address back to a physical address, then mapping physical address to a
PCI device via an interval tree.

When translating virt -> phys we currently assume the ioremap space is
only populated by PAGE_SIZE mappings. If a hugepage mapping is found we
emit a WARN_ON(), but otherwise handles the check as though a normal
page was found. In pathalogical cases such as copying a buffer
containing a lot of 0xFFs from BAR memory this can result in the system
not booting because it's too busy printing WARN_ON()s.

There's no real reason to assume huge pages can't be present and we're
prefectly capable of handling them, so do that.

Fixes: 4a7b06c157a2 ("powerpc/eeh: Handle hugepages in ioremap space")
Reported-by: Sachin Sant 
Signed-off-by: Oliver O'Halloran 
Tested-by: Sachin Sant 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20190710150517.27114-1-ooh...@gmail.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/eeh.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index f192d57db47d..c0e4b73191f3 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -354,10 +354,19 @@ static inline unsigned long eeh_token_to_phys(unsigned 
long token)
ptep = find_init_mm_pte(token, _shift);
if (!ptep)
return token;
-   WARN_ON(hugepage_shift);
-   pa = pte_pfn(*ptep) << PAGE_SHIFT;
 
-   return pa | (token & (PAGE_SIZE-1));
+   pa = pte_pfn(*ptep);
+
+   /* On radix we can do hugepage mappings for io, so handle that */
+   if (hugepage_shift) {
+   pa <<= hugepage_shift;
+   pa |= token & ((1ul << hugepage_shift) - 1);
+   } else {
+   pa <<= PAGE_SHIFT;
+   pa |= token & (PAGE_SIZE - 1);
+   }
+
+   return pa;
 }
 
 /*
-- 
2.20.1

[PATCH AUTOSEL 5.2 139/171] nvme-tcp: set the STABLE_WRITES flag when data digests are enabled

[Sasha Levin]

From: Mikhail Skorzhinskii 

[ Upstream commit 958f2a0f8121ae36a5cbff383ab94fadf1fba5eb ]

There was a few false alarms sighted on target side about wrong data
digest while performing high throughput load to XFS filesystem shared
through NVMoF TCP.

This flag tells the rest of the kernel to ensure that the data buffer
does not change while the write is in flight.  It incurs a performance
penalty, so only enable it when it is actually needed, i.e. when we are
calculating data digests.

Although even with this change in place, ext2 users can steel experience
false positives, as ext2 is not respecting this flag. This may be apply
to vfat as well.

Signed-off-by: Mikhail Skorzhinskii 
Signed-off-by: Mike Playle 
Reviewed-by: Sagi Grimberg 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/host/core.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 120fb593d1da..b4048748551e 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -3256,6 +3257,10 @@ static int nvme_alloc_ns(struct nvme_ctrl *ctrl, 
unsigned nsid)
goto out_free_ns;
}
 
+   if (ctrl->opts->data_digest)
+   ns->queue->backing_dev_info->capabilities
+   |= BDI_CAP_STABLE_WRITES;
+
blk_queue_flag_set(QUEUE_FLAG_NONROT, ns->queue);
if (ctrl->ops->flags & NVME_F_PCI_P2PDMA)
blk_queue_flag_set(QUEUE_FLAG_PCI_P2PDMA, ns->queue);
-- 
2.20.1

[PATCH AUTOSEL 5.2 157/171] 9p: pass the correct prototype to read_cache_page

[Sasha Levin]

From: Christoph Hellwig 

[ Upstream commit f053cbd4366051d7eb6ba1b8d529d20f719c2963 ]

Fix the callback 9p passes to read_cache_page to actually have the
proper type expected.  Casting around function pointers can easily
hide typing bugs, and defeats control flow protection.

Link: http://lkml.kernel.org/r/20190520055731.24538-5-...@lst.de
Signed-off-by: Christoph Hellwig 
Reviewed-by: Kees Cook 
Cc: Sami Tolvanen 
Cc: Nick Desaulniers 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
---
 fs/9p/vfs_addr.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/9p/vfs_addr.c b/fs/9p/vfs_addr.c
index bc57ae9e2963..cce9ace651a2 100644
--- a/fs/9p/vfs_addr.c
+++ b/fs/9p/vfs_addr.c
@@ -35,8 +35,9 @@
  * @page: structure to page
  *
  */
-static int v9fs_fid_readpage(struct p9_fid *fid, struct page *page)
+static int v9fs_fid_readpage(void *data, struct page *page)
 {
+   struct p9_fid *fid = data;
struct inode *inode = page->mapping->host;
struct bio_vec bvec = {.bv_page = page, .bv_len = PAGE_SIZE};
struct iov_iter to;
@@ -107,7 +108,8 @@ static int v9fs_vfs_readpages(struct file *filp, struct 
address_space *mapping,
if (ret == 0)
return ret;
 
-   ret = read_cache_pages(mapping, pages, (void *)v9fs_vfs_readpage, filp);
+   ret = read_cache_pages(mapping, pages, v9fs_fid_readpage,
+   filp->private_data);
p9_debug(P9_DEBUG_VFS, "  = %d\n", ret);
return ret;
 }
-- 
2.20.1

[PATCH AUTOSEL 5.2 143/171] rds: Accept peer connection reject messages due to incompatible version

[Sasha Levin]

From: Gerd Rausch 

[ Upstream commit 8c6166cfc9cd48e93d9176561e50b63cef4330d5 ]

Prior to
commit d021fabf525ff ("rds: rdma: add consumer reject")

function "rds_rdma_cm_event_handler_cmn" would always honor a rejected
connection attempt by issuing a "rds_conn_drop".

The commit mentioned above added a "break", eliminating
the "fallthrough" case and made the "rds_conn_drop" rather conditional:

Now it only happens if a "consumer defined" reject (i.e. "rdma_reject")
carries an integer-value of "1" inside "private_data":

  if (!conn)
break;
err = (int *)rdma_consumer_reject_data(cm_id, event, );
if (!err || (err && ((*err) == RDS_RDMA_REJ_INCOMPAT))) {
  pr_warn("RDS/RDMA: conn <%pI6c, %pI6c> rejected, dropping connection\n",
  >c_laddr, >c_faddr);
  conn->c_proposed_version = RDS_PROTOCOL_COMPAT_VERSION;
  rds_conn_drop(conn);
}
rdsdebug("Connection rejected: %s\n",
 rdma_reject_msg(cm_id, event->status));
break;
/* FALLTHROUGH */
A number of issues are worth mentioning here:
   #1) Previous versions of the RDS code simply rejected a connection
   by calling "rdma_reject(cm_id, NULL, 0);"
   So the value of the payload in "private_data" will not be "1",
   but "0".

   #2) Now the code has become dependent on host byte order and sizing.
   If one peer is big-endian, the other is little-endian,
   or there's a difference in sizeof(int) (e.g. ILP64 vs LP64),
   the *err check does not work as intended.

   #3) There is no check for "len" to see if the data behind *err is even valid.
   Luckily, it appears that the "rdma_reject(cm_id, NULL, 0)" will always
   carry 148 bytes of zeroized payload.
   But that should probably not be relied upon here.

   #4) With the added "break;",
   we might as well drop the misleading "/* FALLTHROUGH */" comment.

This commit does _not_ address issue #2, as the sender would have to
agree on a byte order as well.

Here is the sequence of messages in this observed error-scenario:
   Host-A is pre-QoS changes (excluding the commit mentioned above)
   Host-B is post-QoS changes (including the commit mentioned above)

   #1 Host-B
  issues a connection request via function "rds_conn_path_transition"
  connection state transitions to "RDS_CONN_CONNECTING"

   #2 Host-A
  rejects the incompatible connection request (from #1)
  It does so by calling "rdma_reject(cm_id, NULL, 0);"

   #3 Host-B
  receives an "RDMA_CM_EVENT_REJECTED" event (from #2)
  But since the code is changed in the way described above,
  it won't drop the connection here, simply because "*err == 0".

   #4 Host-A
  issues a connection request

   #5 Host-B
  receives an "RDMA_CM_EVENT_CONNECT_REQUEST" event
  and ends up calling "rds_ib_cm_handle_connect".
  But since the state is already in "RDS_CONN_CONNECTING"
  (as of #1) it will end up issuing a "rdma_reject" without
  dropping the connection:
 if (rds_conn_state(conn) == RDS_CONN_CONNECTING) {
 /* Wait and see - our connect may still be succeeding */
 rds_ib_stats_inc(s_ib_connect_raced);
 }
 goto out;

   #6 Host-A
  receives an "RDMA_CM_EVENT_REJECTED" event (from #5),
  drops the connection and tries again (goto #4) until it gives up.

Tested-by: Zhu Yanjun 
Signed-off-by: Gerd Rausch 
Signed-off-by: Santosh Shilimkar 
Signed-off-by: Sasha Levin 
---
 net/rds/rdma_transport.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/rds/rdma_transport.c b/net/rds/rdma_transport.c
index 46bce8389066..9db455d02255 100644
--- a/net/rds/rdma_transport.c
+++ b/net/rds/rdma_transport.c
@@ -112,7 +112,9 @@ static int rds_rdma_cm_event_handler_cmn(struct rdma_cm_id 
*cm_id,
if (!conn)
break;
err = (int *)rdma_consumer_reject_data(cm_id, event, );
-   if (!err || (err && ((*err) == RDS_RDMA_REJ_INCOMPAT))) {
+   if (!err ||
+   (err && len >= sizeof(*err) &&
+((*err) <= RDS_RDMA_REJ_INCOMPAT))) {
pr_warn("RDS/RDMA: conn <%pI6c, %pI6c> rejected, 
dropping connection\n",
>c_laddr, >c_faddr);
conn->c_proposed_version = RDS_PROTOCOL_COMPAT_VERSION;
@@ -122,7 +124,6 @@ static int rds_rdma_cm_event_handler_cmn(struct rdma_cm_id 
*cm_id,
rdsdebug("Connection rejected: %s\n",
 rdma_reject_msg(cm_id, event->status));
break;
-   /* FALLTHROUGH */
case RDMA_CM_EVENT_ADDR_ERROR:
case RDMA_CM_EVENT_ROUTE_ERROR:
case RDMA_CM_EVENT_CONNECT_ERROR:
-- 
2.20.1

[PATCH AUTOSEL 5.2 151/171] platform/x86: Fix PCENGINES_APU2 Kconfig warning

[Sasha Levin]

From: YueHaibing 

[ Upstream commit 7d67c8ac25fbc66ee254aa3e33329d1c9bc152ce ]

Fix Kconfig warning for PCENGINES_APU2 symbol:

WARNING: unmet direct dependencies detected for GPIO_AMD_FCH
  Depends on [n]: GPIOLIB [=n] && HAS_IOMEM [=y]
  Selected by [y]:
  - PCENGINES_APU2 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && INPUT [=y] 
&& INPUT_KEYBOARD [=y] && LEDS_CLASS [=y]

WARNING: unmet direct dependencies detected for KEYBOARD_GPIO_POLLED
  Depends on [n]: !UML && INPUT [=y] && INPUT_KEYBOARD [=y] && GPIOLIB [=n]
  Selected by [y]:
  - PCENGINES_APU2 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && INPUT [=y] 
&& INPUT_KEYBOARD [=y] && LEDS_CLASS [=y]

Add GPIOLIB dependency to fix it.

Reported-by: Hulk Robot 
Fixes: f8eb0235f659 ("x86: pcengines apuv2 gpio/leds/keys platform driver")
Signed-off-by: YueHaibing 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Sasha Levin 
---
 drivers/platform/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 5d5cc6111081..7c2fd1d72e18 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1317,7 +1317,7 @@ config HUAWEI_WMI
 
 config PCENGINES_APU2
tristate "PC Engines APUv2/3 front button and LEDs driver"
-   depends on INPUT && INPUT_KEYBOARD
+   depends on INPUT && INPUT_KEYBOARD && GPIOLIB
depends on LEDS_CLASS
select GPIO_AMD_FCH
select KEYBOARD_GPIO_POLLED
-- 
2.20.1

[PATCH AUTOSEL 5.2 155/171] net/mlx5: E-Switch, Fix default encap mode

[Sasha Levin]

From: Maor Gottlieb 

[ Upstream commit 9a64144d683a4395f57562d90247c61a0bf5105f ]

Encap mode is related to switchdev mode only. Move the init of
the encap mode to eswitch_offloads. Before this change, we reported
that eswitch supports encap, even tough the device was in non
SRIOV mode.

Fixes: 7768d1971de67 ('net/mlx5: E-Switch, Add control for encapsulation')
Signed-off-by: Maor Gottlieb 
Reviewed-by: Roi Dayan 
Signed-off-by: Saeed Mahameed 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/mellanox/mlx5/core/eswitch.c  | 5 -
 drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 7 +++
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c 
b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index 6a921e24cd5e..e9339e7d6a18 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -1882,11 +1882,6 @@ int mlx5_eswitch_init(struct mlx5_core_dev *dev)
esw->enabled_vports = 0;
esw->mode = SRIOV_NONE;
esw->offloads.inline_mode = MLX5_INLINE_MODE_NONE;
-   if (MLX5_CAP_ESW_FLOWTABLE_FDB(dev, reformat) &&
-   MLX5_CAP_ESW_FLOWTABLE_FDB(dev, decap))
-   esw->offloads.encap = DEVLINK_ESWITCH_ENCAP_MODE_BASIC;
-   else
-   esw->offloads.encap = DEVLINK_ESWITCH_ENCAP_MODE_NONE;
 
dev->priv.eswitch = esw;
return 0;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c 
b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index 47b446d30f71..c2beadc41c40 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -1840,6 +1840,12 @@ int esw_offloads_init(struct mlx5_eswitch *esw, int 
vf_nvports,
 {
int err;
 
+   if (MLX5_CAP_ESW_FLOWTABLE_FDB(esw->dev, reformat) &&
+   MLX5_CAP_ESW_FLOWTABLE_FDB(esw->dev, decap))
+   esw->offloads.encap = DEVLINK_ESWITCH_ENCAP_MODE_BASIC;
+   else
+   esw->offloads.encap = DEVLINK_ESWITCH_ENCAP_MODE_NONE;
+
err = esw_offloads_steering_init(esw, vf_nvports, total_nvports);
if (err)
return err;
@@ -1901,6 +1907,7 @@ void esw_offloads_cleanup(struct mlx5_eswitch *esw)
esw_offloads_devcom_cleanup(esw);
esw_offloads_unload_all_reps(esw, num_vfs);
esw_offloads_steering_cleanup(esw);
+   esw->offloads.encap = DEVLINK_ESWITCH_ENCAP_MODE_NONE;
 }
 
 static int esw_mode_from_devlink(u16 mode, u16 *mlx5_mode)
-- 
2.20.1

[PATCH AUTOSEL 5.2 149/171] s390/dasd: Make layout analysis ESE compatible

[Sasha Levin]

From: Jan Höppner 

[ Upstream commit ce6915f5343f5f2a2a937b683d8ffbf12dab3ad4 ]

The disk layout and volume information of a DASD reside in the first two
tracks of cylinder 0. When a DASD is set online, currently the first
three tracks are read and analysed to confirm an expected layout.

For CDL (Compatible Disk Layout) only count area data of the first track
is evaluated and checked against expected key and data lengths. For LDL
(Linux Disk Layout) the first and third track is evaluated. However,
an LDL formatted volume is expected to be in the same format across all
tracks. Checking the third track therefore doesn't have any more value
than checking any other track at random.

Now, an Extent Space Efficient (ESE) DASD is initialised by only
formatting the first two tracks, as those tracks always contain all
information necessarry.

Checking the third track on an ESE volume will therefore most likely
fail with a record not found error, as the third track will be empty.
This in turn leads to the device being recognised with a volume size of
0. Attempts to write volume information on the first two tracks then
fail with "no space left on device" errors.

Initialising the first three tracks for an ESE volume is not a viable
solution, because the third track is already a regular track and could
contain user data. With that there is potential for data corruption.

Instead, always only analyse the first two tracks, as it is sufficiant
for both CDL and LDL, and allow ESE volumes to be recognised as well.

Signed-off-by: Jan Höppner 
Reviewed-by: Stefan Haberland 
Signed-off-by: Vasily Gorbik 
Signed-off-by: Sasha Levin 
---
 drivers/s390/block/dasd_eckd.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/s390/block/dasd_eckd.c b/drivers/s390/block/dasd_eckd.c
index c09039eea707..c7aec1b44b7c 100644
--- a/drivers/s390/block/dasd_eckd.c
+++ b/drivers/s390/block/dasd_eckd.c
@@ -157,7 +157,7 @@ static const int sizes_trk0[] = { 28, 148, 84 };
 #define LABEL_SIZE 140
 
 /* head and record addresses of count_area read in analysis ccw */
-static const int count_area_head[] = { 0, 0, 0, 0, 2 };
+static const int count_area_head[] = { 0, 0, 0, 0, 1 };
 static const int count_area_rec[] = { 1, 2, 3, 4, 1 };
 
 static inline unsigned int
@@ -1823,8 +1823,8 @@ dasd_eckd_analysis_ccw(struct dasd_device *device)
if (IS_ERR(cqr))
return cqr;
ccw = cqr->cpaddr;
-   /* Define extent for the first 3 tracks. */
-   define_extent(ccw++, cqr->data, 0, 2,
+   /* Define extent for the first 2 tracks. */
+   define_extent(ccw++, cqr->data, 0, 1,
  DASD_ECKD_CCW_READ_COUNT, device, 0);
LO_data = cqr->data + sizeof(struct DE_eckd_data);
/* Locate record for the first 4 records on track 0. */
@@ -1843,9 +1843,9 @@ dasd_eckd_analysis_ccw(struct dasd_device *device)
count_data++;
}
 
-   /* Locate record for the first record on track 2. */
+   /* Locate record for the first record on track 1. */
ccw[-1].flags |= CCW_FLAG_CC;
-   locate_record(ccw++, LO_data++, 2, 0, 1,
+   locate_record(ccw++, LO_data++, 1, 0, 1,
  DASD_ECKD_CCW_READ_COUNT, device, 0);
/* Read count ccw. */
ccw[-1].flags |= CCW_FLAG_CC;
@@ -1967,7 +1967,7 @@ static int dasd_eckd_end_analysis(struct dasd_block 
*block)
}
}
if (i == 3)
-   count_area = >count_area[4];
+   count_area = >count_area[3];
 
if (private->uses_cdl == 0) {
for (i = 0; i < 5; i++) {
-- 
2.20.1

[PATCH AUTOSEL 5.1 002/141] iio: adc: stm32-dfsdm: manage the get_irq error case

[Sasha Levin]

From: Fabien Dessenne 

[ Upstream commit 3e53ef91f826957dec013c47707ffc1bb42b42d7 ]

During probe, check the "get_irq" error value.

Signed-off-by: Fabien Dessenne 
Acked-by: Fabrice Gasnier 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin 
---
 drivers/iio/adc/stm32-dfsdm-adc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c 
b/drivers/iio/adc/stm32-dfsdm-adc.c
index fcd4a1c00ca0..15a115210108 100644
--- a/drivers/iio/adc/stm32-dfsdm-adc.c
+++ b/drivers/iio/adc/stm32-dfsdm-adc.c
@@ -1144,6 +1144,12 @@ static int stm32_dfsdm_adc_probe(struct platform_device 
*pdev)
 * So IRQ associated to filter instance 0 is dedicated to the Filter 0.
 */
irq = platform_get_irq(pdev, 0);
+   if (irq < 0) {
+   if (irq != -EPROBE_DEFER)
+   dev_err(dev, "Failed to get IRQ: %d\n", irq);
+   return irq;
+   }
+
ret = devm_request_irq(dev, irq, stm32_dfsdm_irq,
   0, pdev->name, adc);
if (ret < 0) {
-- 
2.20.1

[PATCH AUTOSEL 5.1 010/141] pinctrl: rockchip: fix leaked of_node references

[Sasha Levin]

From: Wen Yang 

[ Upstream commit 3c89c70634bb0b6f48512de873e7a45c7e1fbaa5 ]

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/pinctrl/pinctrl-rockchip.c:3221:2-8: ERROR: missing of_node_put; 
acquired a node pointer with refcount incremented on line 3196, but without a 
corresponding object release within this function.
./drivers/pinctrl/pinctrl-rockchip.c:3223:1-7: ERROR: missing of_node_put; 
acquired a node pointer with refcount incremented on line 3196, but without a 
corresponding object release within this function.

Signed-off-by: Wen Yang 
Cc: Linus Walleij 
Cc: Heiko Stuebner 
Cc: linux-g...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
---
 drivers/pinctrl/pinctrl-rockchip.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index 16bf21bf69a2..64363363fe27 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -3212,6 +3212,7 @@ static int rockchip_get_bank_data(struct 
rockchip_pin_bank *bank,
base,
_regmap_config);
}
+   of_node_put(node);
}
 
bank->irq = irq_of_parse_and_map(bank->of_node, 0);
-- 
2.20.1

[PATCH AUTOSEL 5.1 004/141] drm/virtio: set seqno for dma-fence

[Sasha Levin]

From: Chia-I Wu 

[ Upstream commit efe2bf965522bf0796d413b47a2abbf81d471d6f ]

This is motivated by having meaningful ftrace events, but it also
fixes use cases where dma_fence_is_later is called, such as in
sync_file_merge.

In other drivers, fence creation and cmdbuf submission normally
happen atomically,

  mutex_lock();
  fence = dma_fence_create(..., ++timeline->seqno);
  submit_cmdbuf();
  mutex_unlock();

and have no such issue.  But in our driver, because most ioctls
queue commands into ctrlq, we do not want to grab a lock.  Instead,
we set seqno to 0 when a fence is created, and update it when the
command is finally queued and the seqno is known.

Signed-off-by: Chia-I Wu 
Reviewed-by: Emil Velikov 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20190429220825.156644-1-olva...@gmail.com
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/virtio/virtgpu_drv.h   |  1 -
 drivers/gpu/drm/virtio/virtgpu_fence.c | 17 ++---
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index d577cb76f5ad..eaa19c338f68 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -85,7 +85,6 @@ struct virtio_gpu_fence {
struct dma_fence f;
struct virtio_gpu_fence_driver *drv;
struct list_head node;
-   uint64_t seq;
 };
 #define to_virtio_fence(x) \
container_of(x, struct virtio_gpu_fence, f)
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c 
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index 21bd4c4a32d1..216ab005e224 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -40,16 +40,14 @@ static bool virtio_signaled(struct dma_fence *f)
 {
struct virtio_gpu_fence *fence = to_virtio_fence(f);
 
-   if (atomic64_read(>drv->last_seq) >= fence->seq)
+   if (atomic64_read(>drv->last_seq) >= fence->f.seqno)
return true;
return false;
 }
 
 static void virtio_fence_value_str(struct dma_fence *f, char *str, int size)
 {
-   struct virtio_gpu_fence *fence = to_virtio_fence(f);
-
-   snprintf(str, size, "%llu", fence->seq);
+   snprintf(str, size, "%llu", f->seqno);
 }
 
 static void virtio_timeline_value_str(struct dma_fence *f, char *str, int size)
@@ -76,6 +74,11 @@ struct virtio_gpu_fence *virtio_gpu_fence_alloc(struct 
virtio_gpu_device *vgdev)
return fence;
 
fence->drv = drv;
+
+   /* This only partially initializes the fence because the seqno is
+* unknown yet.  The fence must not be used outside of the driver
+* until virtio_gpu_fence_emit is called.
+*/
dma_fence_init(>f, _fence_ops, >lock, drv->context, 
0);
 
return fence;
@@ -89,13 +92,13 @@ int virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
unsigned long irq_flags;
 
spin_lock_irqsave(>lock, irq_flags);
-   fence->seq = ++drv->sync_seq;
+   fence->f.seqno = ++drv->sync_seq;
dma_fence_get(>f);
list_add_tail(>node, >fences);
spin_unlock_irqrestore(>lock, irq_flags);
 
cmd_hdr->flags |= cpu_to_le32(VIRTIO_GPU_FLAG_FENCE);
-   cmd_hdr->fence_id = cpu_to_le64(fence->seq);
+   cmd_hdr->fence_id = cpu_to_le64(fence->f.seqno);
return 0;
 }
 
@@ -109,7 +112,7 @@ void virtio_gpu_fence_event_process(struct 
virtio_gpu_device *vgdev,
spin_lock_irqsave(>lock, irq_flags);
atomic64_set(>fence_drv.last_seq, last_seq);
list_for_each_entry_safe(fence, tmp, >fences, node) {
-   if (last_seq < fence->seq)
+   if (last_seq < fence->f.seqno)
continue;
dma_fence_signal_locked(>f);
list_del(>node);
-- 
2.20.1

[PATCH AUTOSEL 5.1 006/141] staging: vt6656: use meaningful error code during buffer allocation

[Sasha Levin]

From: Quentin Deslandes 

[ Upstream commit d8c2869300ab5f7a19bf6f5a04fe473c5c9887e3 ]

Check on called function's returned value for error and return 0 on
success or a negative errno value on error instead of a boolean value.

Signed-off-by: Quentin Deslandes 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/staging/vt6656/main_usb.c | 42 ---
 1 file changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/vt6656/main_usb.c 
b/drivers/staging/vt6656/main_usb.c
index ccafcc2c87ac..70433f756d8e 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -402,16 +402,19 @@ static void vnt_free_int_bufs(struct vnt_private *priv)
kfree(priv->int_buf.data_buf);
 }
 
-static bool vnt_alloc_bufs(struct vnt_private *priv)
+static int vnt_alloc_bufs(struct vnt_private *priv)
 {
+   int ret = 0;
struct vnt_usb_send_context *tx_context;
struct vnt_rcb *rcb;
int ii;
 
for (ii = 0; ii < priv->num_tx_context; ii++) {
tx_context = kmalloc(sizeof(*tx_context), GFP_KERNEL);
-   if (!tx_context)
+   if (!tx_context) {
+   ret = -ENOMEM;
goto free_tx;
+   }
 
priv->tx_context[ii] = tx_context;
tx_context->priv = priv;
@@ -419,16 +422,20 @@ static bool vnt_alloc_bufs(struct vnt_private *priv)
 
/* allocate URBs */
tx_context->urb = usb_alloc_urb(0, GFP_KERNEL);
-   if (!tx_context->urb)
+   if (!tx_context->urb) {
+   ret = -ENOMEM;
goto free_tx;
+   }
 
tx_context->in_use = false;
}
 
for (ii = 0; ii < priv->num_rcb; ii++) {
priv->rcb[ii] = kzalloc(sizeof(*priv->rcb[ii]), GFP_KERNEL);
-   if (!priv->rcb[ii])
+   if (!priv->rcb[ii]) {
+   ret = -ENOMEM;
goto free_rx_tx;
+   }
 
rcb = priv->rcb[ii];
 
@@ -436,39 +443,46 @@ static bool vnt_alloc_bufs(struct vnt_private *priv)
 
/* allocate URBs */
rcb->urb = usb_alloc_urb(0, GFP_KERNEL);
-   if (!rcb->urb)
+   if (!rcb->urb) {
+   ret = -ENOMEM;
goto free_rx_tx;
+   }
 
rcb->skb = dev_alloc_skb(priv->rx_buf_sz);
-   if (!rcb->skb)
+   if (!rcb->skb) {
+   ret = -ENOMEM;
goto free_rx_tx;
+   }
 
rcb->in_use = false;
 
/* submit rx urb */
-   if (vnt_submit_rx_urb(priv, rcb))
+   ret = vnt_submit_rx_urb(priv, rcb);
+   if (ret)
goto free_rx_tx;
}
 
priv->interrupt_urb = usb_alloc_urb(0, GFP_KERNEL);
-   if (!priv->interrupt_urb)
+   if (!priv->interrupt_urb) {
+   ret = -ENOMEM;
goto free_rx_tx;
+   }
 
priv->int_buf.data_buf = kmalloc(MAX_INTERRUPT_SIZE, GFP_KERNEL);
if (!priv->int_buf.data_buf) {
-   usb_free_urb(priv->interrupt_urb);
-   goto free_rx_tx;
+   ret = -ENOMEM;
+   goto free_rx_tx_urb;
}
 
-   return true;
+   return 0;
 
+free_rx_tx_urb:
+   usb_free_urb(priv->interrupt_urb);
 free_rx_tx:
vnt_free_rx_bufs(priv);
-
 free_tx:
vnt_free_tx_bufs(priv);
-
-   return false;
+   return ret;
 }
 
 static void vnt_tx_80211(struct ieee80211_hw *hw,
-- 
2.20.1