Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   NeilBrown <neilb@suse.com>
To:     James Simmons <jsimmons@infradead.org>
Date:   Tue, 15 May 2018 11:37:56 +1000
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        devel@driverdev.osuosl.org,
        Andreas Dilger <andreas.dilger@intel.com>,
        Oleg Drokin <oleg.drokin@intel.com>,
        Lai Siyao <lai.siyao@intel.com>,
        Jinshan Xiong <jinshan.xiong@intel.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Lustre Development List <lustre-devel@lists.lustre.org>
Subject: Re: [PATCH 4/4] staging: lustre: obdclass: change object lookup to no wait mode
In-Reply-To: <alpine.LFD.2.21.1805150133430.576@casper.infradead.org>
References: <1525285308-15347-1-git-send-email-jsimmons@infradead.org> <1525285308-15347-5-git-send-email-jsimmons@infradead.org> <876044fcgg.fsf@notabene.neil.brown.name> <alpine.LFD.2.21.1805150133430.576@casper.infradead.org>
Message-ID: <87efid7l6z.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
Precedence: bulk

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, May 15 2018, James Simmons wrote:

>> On Wed, May 02 2018, James Simmons wrote:
>>=20
>> > From: Lai Siyao <lai.siyao@intel.com>
>> >
>> > Currently we set LU_OBJECT_HEARD_BANSHEE on object when we want
>> > to remove object from cache, but this may lead to deadlock, because
>> > when other process lookup such object, it needs to wait for this
>> > object until release (done at last refcount put), while that process
>> > maybe already hold an LDLM lock.
>> >
>> > Now that current code can handle dying object correctly, we can just
>> > return such object in lookup, thus the above deadlock can be avoided.
>>=20
>> I think one of the reasons that I didn't apply this to mainline myself
>> is that "Now that" comment.  When is the "now" that it is referring to?
>> Are were sure that all code in mainline "can handle dying objects
>> correctly"??
>
> So I talked to Lai and he posted the LU-9049 ticket what patches need to
> land before this one. Only one patch is of concern and its for LU-9203
> which doesn't apply to the staging tree since we don't have the LNet SMP
> updates in our tree. I saved notes about making sure LU-9203 lands=20
> together with the future LNet SMP changes. As it stands it is safe to
> land to staging.

Thanks a lot for looking into this.  Nice to have the safety of this
change confirmed.

What do you think of:

>> > @@ -713,36 +691,46 @@ struct lu_object *lu_object_find_at(const struct=
 lu_env *env,
>> >  	 * It is unnecessary to perform lookup-alloc-lookup-insert, instead,
>> >  	 * just alloc and insert directly.
>> >  	 *
>> > +	 * If dying object is found during index search, add @waiter to the
>> > +	 * site wait-queue and return ERR_PTR(-EAGAIN).
>>=20
>> It seems odd to add this comment here, when it seems to describe code
>> that is being removed.
>> I can see that this comment is added by the upstream patch
>> Commit: fa14bdf6b648 ("LU-9049 obdclass: change object lookup to no wait=
 mode")
>> but I cannot see what it refers to.
>>=20

??

Am I misunderstanding something, or is that comment wrong?

Thanks,
NeilBrown

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAlr6OfQACgkQOeye3VZi
gbl7RA//VDzBj1UncUhWv/9vthIv2Vm46k/h5SN4iAmnnIaVRNVWcKkGyoCj62hQ
e1Q1fJ83Xbe2xkEWiuYhjoKd8fJWsG1eaxxlNI6HWEEv1BxbmHyhjYIQ3RbaIapA
wf9GIU2q21CMUvLsGlrLb+yN9Upa10Vyb9LNKqenLq9C9yxKBHy12F7d0XYYUQ6H
js8IjlUWsWO8NgOKzb4WnDbHW3iKIpHISpxaLHvkmA8oLm8dkC6NqLyLkDa1n3Fz
lyZrxeMyx/caZf4ePeyendU4zBnnIuKbTU4GhnAyPaYVfRfrXxqI0JZqje5XxM/y
J+rZ/5Uxhgg7rH+q3Y5+Xeadn9MhbZRxbGWJn//S6IA8Y1lEjRbrU/VbTQrBu2kN
E3xuYtX71oaJOf9iwnBl5oCs81LT7qVNYBUV4cbawJ9EPVVKVpDx5G6jBWH0utyk
5/eGdTCKpjrxf+f25zXfS47KQL/7tPwuCHyJSocHrnE7DMwE/FEgbDu/KTjIP0zG
wUROiDsA/x1oKlKBMTwBnLPqmxL2CSkCZq5ptsf+iuUZqBboE6dPX4Yqt8K5YFJc
h52wPp50BrFaMs6lsmhPdO7wYBFIAQtvVVFvA8Puyc/8sTma9PZoWW/NrJu3n9RJ
AVSnSD75SWaVrnfrR+tZKYF31rjG0qJAhx3FJjV5MY/k1N+fqK0=
=8ybm
-----END PGP SIGNATURE-----
--=-=-=--