All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xiubo Li <xiubli@redhat.com>
To: Jeff Layton <jlayton@kernel.org>, Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org, ceph-devel@vger.kernel.org
Subject: Re: [deadlock or dead code] ceph_encode_dentry_release() misuse of dget()
Date: Fri, 17 Nov 2023 08:15:57 +0800	[thread overview]
Message-ID: <3a5ed688-898c-7620-e06e-ab2ff2cfdca2@redhat.com> (raw)
In-Reply-To: <e96818f94a6ba3a040004b2cadd569fc2f224554.camel@kernel.org>


On 11/17/23 00:50, Jeff Layton wrote:
> On Thu, 2023-11-16 at 16:28 +0000, Al Viro wrote:
>> On Thu, Nov 16, 2023 at 07:50:03AM -0500, Jeff Layton wrote:
>>
>>>> Am I missing something subtle here?  Looks like that dget() is never
>>>> reached...
>>> No, I think you're correct. That looks like dead code to me too.
>>> Probably we can just remove that "if (!dir)" condition altogether.
>>>
>>> Did you want to send a patch, or would you rather Xiubo or I do it?
>> Up to you...  AFAICS, it had been dead code since ca6c8ae0f793 "ceph: pass
>> parent inode info to ceph_encode_dentry_release if we have it".  In other
>> words, that "if we have it" had already been true at that point.  Prior
>> to that commit dget() in there had been unconditional (and really a deadlock
>> fodder); making it conditional had made it actually unreachable and that
>> fixed the actual bug.
> That makes sense.
>
> Xiubo, would you mind spinning up a patch for this? You're probably in
> the best position to make sure it gets tested these days.

Hi Jeff, Al

Sure, I will fix this. Thanks very much.

- Xiubo


> Thanks!


      reply	other threads:[~2023-11-17  0:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-16  8:19 [deadlock or dead code] ceph_encode_dentry_release() misuse of dget() Al Viro
2023-11-16 12:50 ` Jeff Layton
2023-11-16 16:28   ` Al Viro
2023-11-16 16:50     ` Jeff Layton
2023-11-17  0:15       ` Xiubo Li [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3a5ed688-898c-7620-e06e-ab2ff2cfdca2@redhat.com \
    --to=xiubli@redhat.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.