Re: calling into file systems directly from ->queue_rq, was Re: [PATCH V5 0/6] loop: improve loop aio perf by IOCB_NOWAIT

[Ming Lei <ming.lei@redhat.com>]

On Tue, Nov 25, 2025 at 03:26:39PM +0800, Gao Xiang wrote:
> Hi Ming and Christoph,
> 
> On 2025/11/25 11:00, Ming Lei wrote:
> > On Mon, Nov 24, 2025 at 01:05:46AM -0800, Christoph Hellwig wrote:
> > > On Mon, Nov 24, 2025 at 05:02:03PM +0800, Ming Lei wrote:
> > > > On Sun, Nov 23, 2025 at 10:12:24PM -0800, Christoph Hellwig wrote:
> > > > > FYI, with this series I'm seeing somewhat frequent stack overflows when
> > > > > using loop on top of XFS on top of stacked block devices.
> > > > 
> > > > Can you share your setting?
> > > > 
> > > > BTW, there are one followup fix:
> > > > 
> > > > https://lore.kernel.org/linux-block/20251120160722.3623884-1-ming.lei@redhat.com/
> > > > 
> > > > I just run 'xfstests -q quick' on loop on top of XFS on top of dm-stripe,
> > > > not see stack overflow with the above fix against -next.
> > > 
> > > This was with a development tree with lots of local code.  So the
> > > messages aren't applicable (and probably a hint I need to reduce my
> > > stack usage).  The observations is that we now stack through from block
> > > submission context into the file system write path, which is bad for a
> > > lot of reasons.  journal_info being the most obvious one.
> > > 
> > > > > In other words:  I don't think issuing file system I/O from the
> > > > > submission thread in loop can work, and we should drop this again.
> > > > 
> > > > I don't object to drop it one more time.
> > > > 
> > > > However, can we confirm if it is really a stack overflow because of
> > > > calling into FS from ->queue_rq()?
> > > 
> > > Yes.
> > > 
> > > > If yes, it could be dead end to improve loop in this way, then I can give up.
> > > 
> > > I think calling directly into the lower file system without a context
> > > switch is very problematic, so IMHO yes, it is a dead end.
> I've already explained the details in
> https://lore.kernel.org/r/8c596737-95c1-4274-9834-1fe06558b431@linux.alibaba.com
> 
> to zram folks why block devices act like this is very
> risky (in brief, because virtual block devices don't
> have any way (unlike the inner fs itself) to know enough
> about whether the inner fs already did something without
> context save (a.k.a side effect) so a new task context
> is absolutely necessary for virtual block devices to
> access backing fses for stacked usage.
> 
> So whether a nested fs can success is intrinsic to
> specific fses (because either they assure no complex
> journal_info access or save all effected contexts before
> transiting to the block layer.  But that is not bdev can
> do since they need to do any block fs.

IMO, task stack overflow could be the biggest trouble.

block layer has current->blk_plug/current->bio_list, which are
dealt with in the following patches:

https://lore.kernel.org/linux-block/20251120160722.3623884-4-ming.lei@redhat.com/
https://lore.kernel.org/linux-block/20251120160722.3623884-5-ming.lei@redhat.com/

I am curious why FS task context can't be saved/restored inside block
layer when calling into new FS IO? Given it is just per-task info.


Thanks,
Ming