RE: [PATCH v2] ceph: fix deadlock bugs by making iput() calls asynchronous

[Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>]

On Wed, 2025-09-17 at 21:06 +0200, Max Kellermann wrote:
> On Wed, Sep 17, 2025 at 7:55 PM Viacheslav Dubeyko
> <Slava.Dubeyko@ibm.com> wrote:
> > > +     doutc(ceph_inode_to_fs_client(inode)->client, "%p %llx.%llx\n", inode, ceph_vinop(inode));
> > 
> > What's about this?
> > 
> > struct ceph_fs_client *fsc = ceph_inode_to_fs_client(inode);
> > 
> > doutc(fsc, "%p %llx.%llx\n", inode, ceph_vinop(inode));
> 
> That means I have to declare this variable at the beginning of the
> function because the kernel unfortunately still doesn't allow C99
> rules (declare variables where they are used). And that means paying
> the overhead for chasing 3 layers of pointers for all callers, even
> those 99.99% who return early. Or declare the variable but initialize
> it later in an extra line. Is that the preferred coding style?

My worries here that it is too long statement. Maybe, we can make it as two
lines statement then? For example:

doutc(ceph_inode_to_fs_client(inode)->client, "%p %llx.%llx\n",
      inode, ceph_vinop(inode));

> 
> > > +     WARN_ON_ONCE(!queue_work(ceph_inode_to_fs_client(inode)->inode_wq,
> > > +                              &ceph_inode(inode)->i_work));
> > 
> > This function looks like ceph_queue_inode_work() [1]. Can we use
> > ceph_queue_inode_work()?
> 
> No, we can not, because that function adds an inode reference (instead
> of donating the existing reference) and there's no way we can safely
> get rid of it (even if we would accept paying the overhead of two
> extra atomic operations).

This function can call iput() too. Should we rework it, then? Also, as a result,
we will have two similar functions. And it could be confusing.

Thanks,
Slava.