netdev - Re: [PATCH net-next v6 08/12] net: homa: create homa

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] [day] [month] [year] [list]

Message-ID: <32afcb33-84f3-4f08-862a-6c1687314841@lunn.ch>
Date: Thu, 6 Feb 2025 02:49:21 +0100
From: Andrew Lunn <andrew@...n.ch>
To: John Ousterhout <ouster@...stanford.edu>
Cc: Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
	edumazet@...gle.com, horms@...nel.org, kuba@...nel.org
Subject: Re: [PATCH net-next v6 08/12] net: homa: create homa_incoming.c

On Wed, Feb 05, 2025 at 03:56:36PM -0800, John Ousterhout wrote:
> On Mon, Feb 3, 2025 at 9:58 AM Andrew Lunn <andrew@...n.ch> wrote:
> >
> > > > > If that happens then it could grab the lock instead of the desired
> > > > > application, which would defeat the performance optimization and delay the
> > > > > application a bit. This would be no worse than if the APP_NEEDS_LOCK
> > > > > mechanism were not present.
> > > >
> > > > Then I suggest using plain unlock/lock() with no additional spinning in
> > > > between.
> > >
> > > My concern here is that the unlock/lock sequence will happen so fast
> > > that the other thread never actually has a chance to get the lock. I
> > > will do some measurements to see what actually happens; if lock
> > > ownership is successfully transferred in the common case without a
> > > spin, then I'll remove it.
> >
> > https://docs.kernel.org/locking/mutex-design.html
> >
> > If there is a thread waiting for the lock, it will spin for a while
> > trying to acquire it. The document also mentions that when there are
> > multiple waiters, the algorithm tries to be fair. So if there is a
> > fast unlock/lock, it should act fairly with the other waiter.
> 
> The link above refers to mutexes, whereas the code in question uses spinlocks.

Ah, sorry, could not see that from the context in the email.

> * With the call to homa_spin the handoff fails 0.3-1% of the time.
> This happens because of delays in the needy thread, typically an
> interrupt that keeps it from retrying the lock quickly. This surprised
> me as I thought that interrupts  were disabled by spinlocks, but I
> definitely see the interrupts happening; maybe only *some* interrupts
> (softirqs?) are disabled by spinlocks?

By defaults, spinlocks don't disable interrupts. Which is why you
cannot use them in interrupt handlers. There is however

spin_lock_irqsave(lock, flags);
spin_unlock_irqrestore(lock, flags);

which saves the current interrupt state into flags, and disable
interrupts if needed. The state is then restore when you unlock.

Also, when PREEMPT_RT is enabled for real time support, spinlocks get
turned into mutexes.

	Andrew