netdev - Re: [PATCH net-next v4 12/12] net: homa: create Makefile and Kconfig

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXJAmyufo2j2zbooDM5uqrFSkkH-SDoJicq=K=SYDJAoZzeDw@mail.gmail.com>
Date: Mon, 6 Jan 2025 13:53:51 -0800
From: John Ousterhout <ouster@...stanford.edu>
To: Andrew Lunn <andrew@...n.ch>
Cc: kernel test robot <oliver.sang@...el.com>, oe-lkp@...ts.linux.dev, lkp@...el.com, 
	netdev@...r.kernel.org, pabeni@...hat.com, edumazet@...gle.com, 
	horms@...nel.org, kuba@...nel.org
Subject: Re: [PATCH net-next v4 12/12] net: homa: create Makefile and Kconfig

On Mon, Jan 6, 2025 at 11:09 AM Andrew Lunn <andrew@...n.ch> wrote:
>
> On Mon, Jan 06, 2025 at 09:27:24AM -0800, John Ousterhout wrote:
> > I have pored over this message for a while and can't figure out how
> > Homa code could participate in this deadlock, other than by calling
> > hrtimer_init (which is done without holding any locks). If anyone else
> > can figure out exactly what this message means and how it relates to
> > Homa, I'd love to hear it. Otherwise I'm going to assume it's either a
> > false positive or a problem elsewhere in the Linux kernel.
>
> The problem with ignoring these splats is that after the first splat,
> you don't get any more. So if Homa does have a real deadlock, you
> might never get it reported, you just deadlock.
>
> Have you reproduced this?

If there is actually a problem, I'd definitely like to fix it.
However, I have not been able to reproduce this.

> > > [   11.585197][  T133] -> #0 ((console_sem).lock){-...}-{2:2}:
> > > [ 11.585197][ T133] check_prev_add (kernel/locking/lockdep.c:3162)
> > > [ 11.585197][ T133] validate_chain (kernel/locking/lockdep.c:3281 kernel/locking/lockdep.c:3904)
> > > [ 11.585197][ T133] __lock_acquire (kernel/locking/lockdep.c:5226)
> > > [ 11.585197][ T133] lock_acquire (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814)
> > > [ 11.585197][ T133] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)
> > > [ 11.585197][ T133] down_trylock (kernel/locking/semaphore.c:140)
> > > [ 11.585197][ T133] __down_trylock_console_sem (kernel/printk/printk.c:326)
> > > [ 11.585197][ T133] console_trylock_spinning (kernel/printk/printk.c:2852 kernel/printk/printk.c:2009)
> > > [ 11.585197][ T133] vprintk_emit (kernel/printk/printk.c:2431 kernel/printk/printk.c:2378)
> > > [ 11.585197][ T133] vprintk (kernel/printk/printk_safe.c:86)
> > > [ 11.585197][ T133] _printk (kernel/printk/printk.c:2452)
> > > [ 11.585197][ T133] lookup_object_or_alloc+0x3d4/0x590
> > > [ 11.585197][ T133] __debug_object_init (lib/debugobjects.c:744)
> > > [ 11.585197][ T133] hrtimer_init (kernel/time/hrtimer.c:456 kernel/time/hrtimer.c:1606)
> > > [ 11.585197][ T133] homa_timer_main (net/homa/homa_plumbing.c:971)
> > > [ 11.585197][ T133] kthread (kernel/kthread.c:389)
> > > [ 11.585197][ T133] ret_from_fork (arch/x86/kernel/process.c:153)
> > > [ 11.585197][ T133] ret_from_fork_asm (arch/x86/entry/entry_64.S:254)
>
> Do you see something in the console log at this point?

No: when I "sudo insmod homa.ko" I see nothing in the log other than a
"Homa module loading" message, which occurs well before
homa_timer_main starts up in its own thread.

> I find it odd that hrtimer_init() results in a console message. Maybe
> the console message itself is a clue, there is something wrong with
> the timer setup. If you can avoid the console message, you might then
> avoid the later lock inversion.

Yep, this seems odd to me as well.  I think Jakub's message below may
explain the problem.


-John-