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 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.

Hi Jens,

Can you drop or revert the patchset of "loop: improve loop aio perf by IOCB_NOWAIT"
from for-6.19/block?


Thanks,
Ming