From mboxrd@z Thu Jan 1 00:00:00 1970 From: NeilBrown Subject: Re: [PATCH - revised] rhashtable: detect when object movement might have invalidated a lookup Date: Fri, 20 Jul 2018 16:30:34 +1000 Message-ID: <87va9aqv05.fsf@notabene.neil.brown.name> References: <20180711.224658.2077863065492745521.davem@davemloft.net> <20180711.224801.1129067473269289703.davem@davemloft.net> <87fu0kt5m0.fsf@notabene.neil.brown.name> <20180719.051440.931407144963903326.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Cc: herbert@gondor.apana.org.au, tgraf@suug.ch, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, eric.dumazet@gmail.com To: David Miller Return-path: In-Reply-To: <20180719.051440.931407144963903326.davem@davemloft.net> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, Jul 19 2018, David Miller wrote: > From: NeilBrown > Date: Mon, 16 Jul 2018 09:57:11 +1000 > >> Some users of rhashtable might need to change the key >> of an object and move it to a different location in the table. >> Other users might want to allocate objects using >> SLAB_TYPESAFE_BY_RCU which can result in the same memory allocation >> being used for a different (type-compatible) purpose and similarly >> end up in a different hash-chain. >>=20 >> To support these, we store a unique NULLS_MARKER at the end of >> each chain, and when a search fails to find a match, we check >> if the NULLS marker found was the expected one. If not, >> the search is repeated. >>=20 >> The unique NULLS_MARKER is derived from the address of the >> head of the chain. >>=20 >> If an object is removed and re-added to the same hash chain, we won't >> notice by looking that the NULLS marker. In this case we must be sure >> that it was not re-added *after* its original location, or a lookup may >> incorrectly fail. The easiest solution is to ensure it is inserted at >> the start of the chain. insert_slow() already does that, >> insert_fast() does not. So this patch changes insert_fast to always >> insert at the head of the chain. >>=20 >> Note that such a user must do their own double-checking of >> the object found by rhashtable_lookup_fast() after ensuring >> mutual exclusion which anything that might change the key, such as >> successfully taking a new reference. >>=20 >> Signed-off-by: NeilBrown > > Neil I have to be honest with you. Thank you. > > During this whole ordeal I was under the impression that this was all > going to be used for something in-tree. But now I see that you want > to use all of this stuff for lustre which is out of tree. > > It would be extremely hard for me to accept adding this kind of > complexity and weird semantics to an already extremely complicated > and delicate piece of infrastructure if something in-tree would use > it. > > But for something out-of-tree? I'm sorry, no way. That's unfortunate, but I can live with it. null-list support is just a nice-to-have for me. I'll resend the patch with the unwanted complexity removed. Does this ruling also apply to the bit-spin-lock changes and the per-cpu-counter changes that I have proposed? These improve scalability when updates dominate. Not having these in mainline would mean I need to carry a separate rhashtables implementation for lustre, which means code diversion which isn't healthy in the long run. (Note that, in my mind, lustre is only temporarily out-of-tree. It is coming back, hopefully this year). Thanks, NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAltRgYoACgkQOeye3VZi gbn8tRAAo363kUgnVbRsWfhBHeu2w9FGOaGOf0NXgNcDn7PByfecdX066JqQntVW CWNJ6QpnWeVrQ0GOW6nsnyPzvzozI30VwXr+yunprQnfzWRfg/xwS8hiXpbtHt11 IOca1Lc9Jv2iF8MngDPiEcz70N/6EQ6K1Kn2MmH/23vWqER9wXev7db5PPWydHrF uDhVykiL6I7xKo/5TZPUwz+FKVNgAIFL32jSdn4DPq7Cp6fkrOagAG+Z+QRTLiKV Oe1qa23VCT8mH/gwTIB/YJY7Mut8XQx+fawAzxb15bm0c22hQ1WMaBKr8SdUlnly 5Of+N/6laxn37lpjmqr+N1bmmBwelZ21aCFl5Bw9Mf2H3bUEAYVSwa1Uqtd6UPKx 3qGyDuBM9JjEx9NCjSDiMsqb1YXs1z3UKjQMtgof34N9j5R2h95pBc4e0w+0dTq1 XrAtzfJRecINTpcEOhjH/PAZ3k6g0WdF7i7l6BcFrpZvWlsFHsNCgLubVYFNe+cL KA/bxtiZHcQnCvP6X3Vcb11cpFTHKdG+R0W9re0rckuTsje8lkU1u0brDLLATy86 OrRIvtYujdc9tUP05BhdT8ISWYt6P/4F/pNGge2IMi7dABhsKGJxGzWS++/GLfx2 32yc3hqEm5hCH7GlXWEmUtghFJW0Jse302n+tUaJg8QcW1NIyPk= =GPUD -----END PGP SIGNATURE----- --=-=-=--