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

[Jens Axboe]

On 3/31/26 9:21 AM, Christoph Hellwig wrote:
> On Tue, Mar 31, 2026 at 09:15:07AM -0600, Jens Axboe wrote:
>> On 3/31/26 9:10 AM, Christoph Hellwig wrote:
>>> On Fri, Mar 20, 2026 at 06:36:15PM +0530, Deepanshu Kartikey wrote:
>>>> Fix this by checking if the input and output files share the
>>>> same inode before proceeding, returning -EINVAL if they do.
>>>> This mirrors the existing check in do_splice() for the
>>>> pipe-to-pipe case where ipipe == opipe.
>>>
>>> While restricting splice to be between difference inodes sounds like a
>>> nice simplification, I'm not sure we can add it 20 years after the
>>> syscall was added.
>>
>> Well if we could break splice all over with:
>>
>> 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops")
> 
> Well, that had an easy way out by converting instances people actually
> used to the iter ops.  Which we ended up doing for a few.

Sure, and it was the right thing to do, but you still end up with a
broken kernel for that user. Until it gets reported, fixed, and bubbles
back to a kernel that they can use.

IOW, no different than this one.

>> then surely this one would be OK too?
> 
> While this has no way out.  Not that I would complain if it worked,
> but splicing into the same file doesn't seem like a too outlandish
> idea.  OTOH it probably already didn't work for file systems that
> take i_rwsem in the read path like XFS or these days the block
> device node.

There is a way out, it's reverting it. I'd be surprised if this didn't
trigger issues already, like the flagged one.

Thing is, I don't really see an alternative fix to this...

-- 
Jens Axboe