netdev - Re: xfrm_state locking regression...

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20080902.231035.163736332.davem@davemloft.net>
Date:	Tue, 02 Sep 2008 23:10:35 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	timo.teras@....fi
Cc:	herbert@...dor.apana.org.au, netdev@...r.kernel.org
Subject: Re: xfrm_state locking regression...

From: Timo Teräs <timo.teras@....fi>
Date: Wed, 03 Sep 2008 08:07:33 +0300

> Also alternatively the xfrm_state_all could be protected by a
> different lock than xfrm_state_lock.

Before your changes the state destroy was protected by no central
locks at all.  There was no need.

Since the reference goes to zero, there are no external references
to this object.

But this is exactly what you added, an external references that is
not reference counted.

This is yet another reason all of Herbert's objections to your
location for ->all list add and removal are sound.

So we now have to take a centralized lock twice when getting rid of an
XFRM state object.  Which is potentially a scalability performance
regression.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html