From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751619AbdJTAkC (ORCPT ); Thu, 19 Oct 2017 20:40:02 -0400 Received: from mx2.suse.de ([195.135.220.15]:46202 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751191AbdJTAkA (ORCPT ); Thu, 19 Oct 2017 20:40:00 -0400 From: NeilBrown To: James Simmons Date: Fri, 20 Oct 2017 11:39:50 +1100 Cc: Oleg Drokin , Greg Kroah-Hartman , Andreas Dilger , Linux Kernel Mailing List , Alexander Viro , Lustre Development List Subject: Re: [lustre-devel] [PATCH 0/6] dcache/namei fixes for lustre In-Reply-To: References: <150164273003.13199.7841976922211510658.stgit@noble> Message-ID: <87k1zqfy95.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, Aug 20 2017, James Simmons wrote: >> This series is a revised version of two patches I sent >> previously (one of which was sadly broken). >> That patch has been broken into multiple parts for easy >> review. The other is included unchanged as the last of >> this series. >>=20 >> I was drawn to look at this code due to the tests on >> DCACHE_DISCONNECTED which are often wrong, and it turns out >> they are used wrongly in lustre too. Fixing one led to some >> clean-up. Fixing the other is straight forward. >>=20 >> A particular change here from the previous posting is >> the first patch which tests for DCACHE_PAR_LOOKUP in ll_dcompare(). >> Without this patch, two threads can be looking up the same >> name in a given directory in parallel. This parallelism lead >> to my concerns about needing improved locking in ll_splice_alias(). >> Instead of improving the locking, I now avoid the need for it >> by fixing ll_dcompare. >>=20 >> This code passes basic "smoke tests". >>=20 >> Note that the cast to "struct dentry *" in the first patch is because >> we have a "const struct dentry *" but d_in_lookup() requires a >> pointer to a non-const structure. I'll send a separate patch to >> change d_in_lookup(). > > To let you know this patch has been under going testing and we have a > ticket open to track the progess: > > https://jira.hpdd.intel.com/browse/LU-9868 > > Your patch did reveal that a piece of a fix landed earlier is missing :-( > So currently the client can oops. I will send the fix shortly but this > work will have to rebased after. As soon as we can get some cycles we will > figure out what is going on. Thanks for helping out. Hi, what happened about this? I had a look around the ticket and couldn't find anything about an oops. If there is still a problem I'd be very happy to help work out what it is - but I don't know where to look. Thanks, NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAlnpRdcACgkQOeye3VZi gblbthAAvgU6zwyP891iJnQN7xJQoG868wzAw9cdOJ+0wydcIqMCWcSt6ebvq5Gg BteGSTWjMc/J6WJb3dxiukfKPxPtDrTNIQiRn93UIbGaEt3xmJS5pj7EY6C0mMsz DVmW3oXZ++fPL8Q98K7vUVlUNObonzHZcQkjrV5vVAaPtdy4WPo9Z0XPhzXvlutV 633MS5L6DjiViHsPyNAdWpezH+V3F7S1Qp63lNx0M6jxJKMV9iVIoPdYL2VlVLmu dzIopbc46oq8xUKXuelOYmv83tXydV774uXgbR3b4MoG8ymLx7ekZwsrvbbXJS92 tlTYMi95zCRbog8JHTZjRVFFLVZd9afwYVEeLNXvhy9NS38rUI/LmzIKldHpSJ/i AFJ0bNSbAVNfvniAUgDpKlUJu/mgpTdONQFwuZxmeHOlZ9Xw/ZyM5qbxybSb2M6N P9qb6a/Mw+K/ddwkn9i+zNNqGuLSpKsk8eK+ob2AdQvvTaOK0Q3DTuNN2ezlgY/l jGCPTFArxToTTSxbAPldm0/ngMvti+cmbibrU7aMxM6P7scx2k0RTi6ElxPMfmJc +Y1sBgdOqOqQ7G6YXugVB4Iu9zWqJ1+1OT5h+KzjaBadxkt3zQv394Lrb4S4UMnQ tQwZBu+63x3JuIqVZjEPPOgBtzht5lFWoF2F5aQdMGplMUj2mF0= =QDGe -----END PGP SIGNATURE----- --=-=-=--