search for: lockdep_hardirqs_on

On Tue, Aug 11, 2020 at 11:20:54AM +0200, peterz at infradead.org wrote: > On Tue, Aug 11, 2020 at 10:38:50AM +0200, J?rgen Gro? wrote: > > In case you don't want to do it I can send the patch for the Xen > > variants. > > I might've opened a whole new can of worms here. I'm not sure we > can/want to fix the entire fallout this release :/ > > Let me

On Tue, Aug 11, 2020 at 11:20:54AM +0200, peterz at infradead.org wrote: > On Tue, Aug 11, 2020 at 10:38:50AM +0200, J?rgen Gro? wrote: > > In case you don't want to do it I can send the patch for the Xen > > variants. > > I might've opened a whole new can of worms here. I'm not sure we > can/want to fix the entire fallout this release :/ > > Let me

...w+0xc0/0xc0 [nouveau] [ 1143.134159] ? drm_ioctl_kernel+0x91/0xe0 [drm] [ 1143.134170] drm_ioctl_kernel+0x91/0xe0 [drm] [ 1143.134182] drm_ioctl+0x2db/0x380 [drm] [ 1143.134211] ? nouveau_gem_ioctl_new+0xc0/0xc0 [nouveau] [ 1143.134217] ? _raw_spin_unlock_irqrestore+0x47/0x60 [ 1143.134222] ? lockdep_hardirqs_on+0x78/0x100 [ 1143.134226] ? _raw_spin_unlock_irqrestore+0x34/0x60 [ 1143.134257] nouveau_drm_ioctl+0x56/0xb0 [nouveau] [ 1143.134263] __x64_sys_ioctl+0x8e/0xd0 [ 1143.134267] ? lockdep_hardirqs_on+0x78/0x100 [ 1143.134271] do_syscall_64+0x33/0x40 [ 1143.134276] entry_SYSCALL_64_after_hwframe+...

...ext_owner+0x400/0x400 [ 138.131329] do_group_exit+0x8a/0x140 [ 138.135006] get_signal+0x25b/0x1080 [ 138.138606] do_signal+0x8c/0xa90 [ 138.141928] ? _raw_spin_unlock_irq+0x24/0x30 [ 138.146292] ? mark_held_locks+0x24/0x90 [ 138.150219] ? _raw_spin_unlock_irq+0x24/0x30 [ 138.154580] ? lockdep_hardirqs_on+0x190/0x280 [ 138.159026] ? setup_sigcontext+0x260/0x260 [ 138.163210] ? sigprocmask+0x10b/0x150 [ 138.166965] ? __x64_sys_rt_sigsuspend+0xe0/0xe0 [ 138.171594] ? __x64_sys_rt_sigprocmask+0xfb/0x180 [ 138.176394] ? __ia32_compat_sys_rt_sigprocmask+0x190/0x190 [ 138.181965] ? entry_SYSCA...

On 3/17/20 5:59 AM, Christoph Hellwig wrote: > On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote: >> I've been using v7 of Ralph's tester and it is working well - it has >> DEVICE_PRIVATE support so I think it can test this flow too. Ralph are >> you able? >> >> This hunk seems trivial enough to me, can we include it now? > > I can send

...x330/0x330 [ 1295.059971] drm_ioctl+0x308/0x530 [ 1295.063384] ? drm_version+0x150/0x150 [ 1295.067153] ? find_held_lock+0xac/0xd0 [ 1295.070996] ? __pm_runtime_resume+0x3f/0xa0 [ 1295.075285] ? mark_held_locks+0x29/0xa0 [ 1295.079230] ? _raw_spin_unlock_irqrestore+0x3c/0x50 [ 1295.084232] ? lockdep_hardirqs_on+0x17d/0x250 [ 1295.088768] nouveau_drm_ioctl+0x9a/0x100 [nouveau] [ 1295.093661] do_vfs_ioctl+0x137/0x9a0 [ 1295.097341] ? ioctl_preallocate+0x140/0x140 [ 1295.101623] ? match_held_lock+0x1b/0x230 [ 1295.105646] ? match_held_lock+0x1b/0x230 [ 1295.109660] ? find_held_lock+0xac/0xd0 [ 1295.113...

...x330/0x330 [ 1295.059971] drm_ioctl+0x308/0x530 [ 1295.063384] ? drm_version+0x150/0x150 [ 1295.067153] ? find_held_lock+0xac/0xd0 [ 1295.070996] ? __pm_runtime_resume+0x3f/0xa0 [ 1295.075285] ? mark_held_locks+0x29/0xa0 [ 1295.079230] ? _raw_spin_unlock_irqrestore+0x3c/0x50 [ 1295.084232] ? lockdep_hardirqs_on+0x17d/0x250 [ 1295.088768] nouveau_drm_ioctl+0x9a/0x100 [nouveau] [ 1295.093661] do_vfs_ioctl+0x137/0x9a0 [ 1295.097341] ? ioctl_preallocate+0x140/0x140 [ 1295.101623] ? match_held_lock+0x1b/0x230 [ 1295.105646] ? match_held_lock+0x1b/0x230 [ 1295.109660] ? find_held_lock+0xac/0xd0 [ 1295.113...

...q_save(irq_state->flags); + lockdep_hardirqs_off(CALLER_ADDR0); + } } -void kcsan_restore_irqtrace(struct task_struct *task) +void kcsan_restore_irqtrace(struct kcsan_irq_state *irq_state) { + if (!kcsan_interrupt_watcher) { +#ifdef CONFIG_TRACE_IRQFLAGS + if (irq_state->hardirqs) { + lockdep_hardirqs_on_prepare(CALLER_ADDR0); + lockdep_hardirqs_on(CALLER_ADDR0); + } +#endif + raw_local_irq_restore(irq_state->flags); + } #ifdef CONFIG_TRACE_IRQFLAGS - task->irqtrace = task->kcsan_save_irqtrace; + task->irqtrace = irq_state->irqtrace; #endif } @@ -350,11 +383,13 @@ static noi...

...36702] ? __cgroup1_procs_write.constprop.21+0xf3/0x150 [ 70.136712] __cgroup1_procs_write.constprop.21+0xf3/0x150 [ 70.136722] cgroup_file_write+0x64/0x210 [ 70.136728] kernfs_fop_write+0x117/0x1b0 [ 70.136735] vfs_write+0xe8/0x240 [ 70.136741] ksys_write+0x87/0xc0 [ 70.136746] ? lockdep_hardirqs_on+0x85/0x110 [ 70.136752] do_syscall_64+0x33/0x40 [ 70.136758] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 70.136764] RIP: 0033:0x7efc17533deb [ 70.136770] Code: 53 48 89 d5 48 89 f3 48 83 ec 18 48 89 7c 24 08 e8 5a fd ff ff 48 89 ea 41 89 c0 48 89 de 48 8b 7c 24 08 b8 01 00 00 00 0f 05 <...

...nvkm_uvmm_mthd+0x4d5/0xbe0 [nouveau] [ 98.948787] ? mutex_lock_io_nested+0xbc0/0xbc0 [ 98.953357] ? stack_trace_save+0x8a/0xb0 [ 98.957385] ? stack_trace_consume_entry+0x80/0x80 [ 98.962187] ? mark_lock+0xac/0x9f0 [ 98.965751] ? nvkm_uvmm_mthd+0x4d5/0xbe0 [nouveau] [ 98.970651] ? lockdep_hardirqs_on+0x190/0x280 [ 98.975171] nvkm_uvmm_mthd+0x4d5/0xbe0 [nouveau] [ 98.979892] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 98.984601] ? nvkm_uvmm_dtor+0x20/0x20 [nouveau] [ 98.989322] ? retint_kernel+0x10/0x10 [ 98.993146] ? nvkm_ioctl_mthd+0x94/0xe0 [nouveau] [ 98.998001] nvkm_ioctl+0x18b/...

...x330/0x330 [ 1295.059971] drm_ioctl+0x308/0x530 [ 1295.063384] ? drm_version+0x150/0x150 [ 1295.067153] ? find_held_lock+0xac/0xd0 [ 1295.070996] ? __pm_runtime_resume+0x3f/0xa0 [ 1295.075285] ? mark_held_locks+0x29/0xa0 [ 1295.079230] ? _raw_spin_unlock_irqrestore+0x3c/0x50 [ 1295.084232] ? lockdep_hardirqs_on+0x17d/0x250 [ 1295.088768] nouveau_drm_ioctl+0x9a/0x100 [nouveau] [ 1295.093661] do_vfs_ioctl+0x137/0x9a0 [ 1295.097341] ? ioctl_preallocate+0x140/0x140 [ 1295.101623] ? match_held_lock+0x1b/0x230 [ 1295.105646] ? match_held_lock+0x1b/0x230 [ 1295.109660] ? find_held_lock+0xac/0xd0 [ 1295.113...

...nouveau/nouveau_gem.c:680) ? _raw_spin_unlock_irqrestore (/home/kas/linux/torvalds/arch/x86/include/asm/irqflags.h:41 /home/kas/linux/torvalds/arch/x86/include/asm/irqflags.h:84 /home/kas/linux/torvalds/include/linux/spinlock_api_smp.h:160 /home/kas/linux/torvalds/kernel/locking/spinlock.c:191) ? lockdep_hardirqs_on (/home/kas/linux/torvalds/kernel/locking/lockdep.c:3727 (discriminator 3)) ? _raw_spin_unlock_irqrestore (/home/kas/linux/torvalds/arch/x86/include/asm/preempt.h:102 /home/kas/linux/torvalds/include/linux/spinlock_api_smp.h:161 /home/kas/linux/torvalds/kernel/locking/spinlock.c:191) nouveau_drm_i...

...eau] jul 28 17:16:25 localhost.localdomain kernel: drm_ioctl_kernel+0xaa/0xf0 [drm] jul 28 17:16:25 localhost.localdomain kernel: drm_ioctl+0x208/0x390 [drm] jul 28 17:16:25 localhost.localdomain kernel: ? nouveau_gem_ioctl_new+0xe0/0xe0 [nouveau] jul 28 17:16:25 localhost.localdomain kernel: ? lockdep_hardirqs_on+0xf0/0x180 jul 28 17:16:25 localhost.localdomain kernel: nouveau_drm_ioctl+0x63/0xb0 [nouveau] jul 28 17:16:25 localhost.localdomain kernel: do_vfs_ioctl+0x411/0x750 jul 28 17:16:25 localhost.localdomain kernel: ksys_ioctl+0x5e/0x90 jul 28 17:16:25 localhost.localdomain kernel: __x64_sys_ioctl+...

In nouveau_dmem_pages_alloc(), the drm->dmem->mutex is unlocked before calling nouveau_dmem_chunk_alloc(). Reacquire the lock before continuing to the next page. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> --- I found this while testing Jason Gunthorpe's hmm tree but this is independant of those changes. I guess it could go through David Airlie's tree for nouveau

...e.constprop.21+0xf3/0x150 > [ 70.136712] __cgroup1_procs_write.constprop.21+0xf3/0x150 > [ 70.136722] cgroup_file_write+0x64/0x210 > [ 70.136728] kernfs_fop_write+0x117/0x1b0 > [ 70.136735] vfs_write+0xe8/0x240 > [ 70.136741] ksys_write+0x87/0xc0 > [ 70.136746] ? lockdep_hardirqs_on+0x85/0x110 > [ 70.136752] do_syscall_64+0x33/0x40 > [ 70.136758] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 70.136764] RIP: 0033:0x7efc17533deb > [ 70.136770] Code: 53 48 89 d5 48 89 f3 48 83 ec 18 48 89 7c 24 08 e8 5a > fd ff ff 48 89 ea 41 89 c0 48 89 de 48 8b 7c 24 08...

All functions referenced via __PV_IS_CALLEE_SAVE() need to be assembler functions, as those functions calls are hidden from gcc. In case the kernel is compiled with "-fzero-call-used-regs" the compiler will clobber caller-saved registers at the end of C functions, which will result in unexpectedly zeroed registers at the call site of the related paravirt functions. Replace the C

...nouveau_gem.c:680) > ? _raw_spin_unlock_irqrestore (/home/kas/linux/torvalds/arch/x86/include/asm/irqflags.h:41 /home/kas/linux/torvalds/arch/x86/include/asm/irqflags.h:84 /home/kas/linux/torvalds/include/linux/spinlock_api_smp.h:160 /home/kas/linux/torvalds/kernel/locking/spinlock.c:191) > ? lockdep_hardirqs_on (/home/kas/linux/torvalds/kernel/locking/lockdep.c:3727 (discriminator 3)) > ? _raw_spin_unlock_irqrestore (/home/kas/linux/torvalds/arch/x86/include/asm/preempt.h:102 /home/kas/linux/torvalds/include/linux/spinlock_api_smp.h:161 /home/kas/linux/torvalds/kernel/locking/spinlock.c:191) > nouve...

Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() family of modifiers to handle broken userspace Xorg modesetting and Mesa drivers. Tested with Xorg 1.20 modesetting driver, weston at c46c70dac84a4b3030cd05b380f9f410536690fc, gnome & KDE wayland desktops from Ubuntu 18.04, and sway 1.5 Signed-off-by: James Jones <jajones at nvidia.com> --- drivers/gpu/drm/nouveau/nouveau_display.c | 26

On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote: > On Wed, Aug 05, 2020 at 03:42PM +0200, peterz at infradead.org wrote: > > Shouldn't we __always_inline those? They're going to be really small. > > I can send a v2, and you can choose. For reference, though: > > ffffffff86271ee0 <arch_local_save_flags>: > ffffffff86271ee0: 0f 1f 44 00 00

On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote: > On Wed, Aug 05, 2020 at 03:42PM +0200, peterz at infradead.org wrote: > > Shouldn't we __always_inline those? They're going to be really small. > > I can send a v2, and you can choose. For reference, though: > > ffffffff86271ee0 <arch_local_save_flags>: > ffffffff86271ee0: 0f 1f 44 00 00