Re: [PATCH] splice: prevent deadlock when splicing a file to itself

[Deepanshu Kartikey]

On Wed, Apr 1, 2026 at 4:17 PM Jan Kara <jack@xxxxxxx> wrote:
>
> On Wed 01-04-26 14:02:27, Deepanshu Kartikey wrote:
> > On Wed, Apr 01, 2026, Jan Kara wrote:
> > > Hum, I'm probably missing something but I just
> > > don't see how the proposed deadlock is supposed
> > > to happen.
> >
> > You are correct, I apologize for the incorrect
> > analysis in the patch description.
> >
> > After looking more carefully at the code, the
> > actual deadlock involves sendfile() and a
> > concurrent fallocate() on the same inode:
> >
> > 1. sendfile() write side calls blkdev_write_iter()
> >    which acquires inode_lock_shared().
> >
> > 2. Concurrent fallocate() calls blkdev_fallocate()
> >    which tries inode_lock() (exclusive) and blocks
> >    waiting for the shared lock to be released.
> >
> > 3. sendfile() read side then calls
> >    blkdev_read_iter() which tries
> >    inode_lock_shared() but is blocked because
> >    rwsem prevents new readers when a writer
> >    is waiting.
> >
> > This creates a circular dependency where nobody
> > can proceed, causing the hung task.
>
> I'm afraid you're using some LLM for your analysis and it's doing a bad
> job. Please verify in the code whether what LLM says to you is in fact
> correct (and if you are unable to do that then please learn more before
> submitting kernel patches). As a hint, sendfile() for block devices never
> ends up calling blkdev_read_iter() (plus there are other bogus things in
> the analysis).
>
>                                                                 Honza
> --
> Jan Kara <jack@xxxxxxxx>
> SUSE Labs, CR

Noted. I will do proper code analysis myself before sending any
further patches or replies.

Thank you for the guidance.