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

From: Jan Kara

Date: Wed Apr 01 2026 - 06:51:28 EST


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