From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751749AbdJXWgE (ORCPT ); Tue, 24 Oct 2017 18:36:04 -0400 Received: from mx2.suse.de ([195.135.220.15]:39144 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751535AbdJXWgC (ORCPT ); Tue, 24 Oct 2017 18:36:02 -0400 From: NeilBrown To: James Simmons Date: Wed, 25 Oct 2017 09:35:48 +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> <87k1zqfy95.fsf@notabene.neil.brown.name> Message-ID: <87a80gdvi3.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 Tue, Oct 24 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. >>=20 >> 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. > > The oops is specific to the in kernel client. Some where along the way the > calls to ll_d_init() were removed from ll_splice_alias(). It was unnoticed > until your patch came along. I do have a fix that I will be pushing to=20 > the next staging tree very shortly. ll_d_init() doesn't need to be called from anywhere. It is called by __d_alloc (dentry->d_op->d_init) whenever a dentry is allocated. That is all that is needed. > > I have been testing the patch series and for me I don't see any issue. Ou= r=20 > test suite is reporting failures with this patch which I'm attempting to= =20 > figure out how to reproduce locally on my test system. Once I have a=20 > reproducer I can send it to you.=20 Can I see the failure report? Or the oops? I cannot find anything at the jira.hpdd.intel.com link you gave, or the review.whamcloud.com that is linked from there. Maybe it is behind testing.hpdd.intel.com that I need a login for (I've registered and am waiting) .... Thanks, NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAlnvwEYACgkQOeye3VZi gbm0EhAAlrI7PdasAjbtYqonAnr02lGYy72aINyLHUAry8MS2RAzQqqAYLAHeXUh QxkOaPXXZhkZFTmt7OHxuX0+5wqkno8bS54b3EGksc7sSi38qTYNULq2Ins4WVaH VEb5CaUGAs/qox0bRAqRr005rTXdxcZCrBqvNijUe7HHEPlrmdYBA5ynvGcdWOdB iBrRj5zRemmnUOvS1FMsuL4FIb/6l36xw3EUY5+g1CWtiFixjgPUtxLJx6hWelSG kcFajKSQUsNmTcpTPC4sJNdyBs9uehvB+AY1nSQ5gqDooWEf+w1eGcLaDzZ8oF/9 q+Dp4pfvv4sA4Sic3JbsSeCmPfkx6g5YSgU+Q76ZGG/zKq+cTxfNKV5vGLCTrA5S l/w3wWVLEZvHKCJXWlYCjDEtTkU8ZSG+i+haJVlBL8favWUctbHCIa1do/nwm0Oc tqHOLA2QJH7jP/tCQtlpFP3Ux92gONm+/3VQaG6yE70B8qeOSC4ZmUO2g4EWR14L pEFSfZK2Hqx/RHDEhOMvxyDQ5KnRl/jcsGLpQXZAVMwh5Z4WLyOKyRrcXykLBSg1 NWkP8FzWb/EHTXwmJYBDn3XuPjD6jLrr1pGEY8ixm9Wq+VT6RxnCtUxiZPLbL0eR GHcTGKd8w+WqkGPNkjzT2V/qHGv6PXgajU8I2z4jQ/KrIVbcgT4= =62bY -----END PGP SIGNATURE----- --=-=-=--