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

Message-ID: <9a3a38c2-3752-4ad2-a473-4d8f47ce7bc6@lunn.ch>
Date: Mon, 3 Feb 2025 18:58:17 +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

> > > 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.

	Andrew