Re: git: 2612f1b8649b - main - deadfs: Return ENXIO instead of EIO when the device is gone.

On Fri, Oct 24, 2025 at 05:40:36PM -0400, Warner Losh wrote:
> On Fri, Oct 24, 2025 at 12:03 PM Konstantin Belousov <kostikbel@gmail.com>
> wrote:
> 
> > On Fri, Oct 24, 2025 at 09:12:18AM -0400, Warner Losh wrote:
> > > On Fri, Oct 24, 2025, 7:49 AM Konstantin Belousov <kostikbel@gmail.com>
> > > wrote:
> > >
> > > > On Fri, Oct 24, 2025 at 11:16:01AM +0000, Poul-Henning Kamp wrote:
> > > > > --------
> > > > > Konstantin Belousov writes:
> > > > >
> > > > > > On Fri, Oct 24, 2025 at 10:12:30AM +0000, Poul-Henning Kamp wrote:
> > > > >
> > > > > > I do not think that DRM really affects the code path for io.
> > > > >
> > > > > 100% agreement.
> > > > >
> > > > > But it can change the order of thread/interrupt/event-handling
> > > > > scheduling.
> > > > >
> > > > > When I tested the ENXIO patch, I started booting an unmodified
> > > > > kernel in single-user and immediately got ENXIO when I pulled
> > > > > the USB stick - quite to my surprise.
> > > > >
> > > > > Then I kldloaded i915kms, still in single-user, and now I got
> > > > > the observed bad EIO behaviour.
> > > > >
> > > > > With a fixed kernel and i915kms loaded, I saw four or five reads
> > > > > return EIO before one got ENXIO and terminated recoverdisk.
> > > > >
> > > > > Getting a handful of EIO's before the ENXIO finally appears
> > > > > strongly suggests that some of the eventhandling related to
> > > > > the disappearing USB stick is being held up by something.
> > > > >
> > > > > As soon as I can, I'll try to gather more data.
> > > >
> > > > It might make sense to annotate CAM EIOs with EXTERROR().
> > > > But then, we probably need to add something to copy that
> > > > extended data between threads and possibly extend struct buf/bio
> > > > witg the place for exterror data besides b_error.
> > > >
> > >
> > > Given the contexts cam runs in, managing the storage for that can be
> > hard.
> >
> > Which storage?
> >
> > EXTERROR() does not allocate any memory.  It was designed to be safe for
> > using in any context, including real interrupt (not just non-sleepable
> > threads).
> >
> 
> So I don't know curthread of the transaction that scheduled the I/O. That's
> how I was, impricely, using the word 'context'. So how does EXTERROR make
> it's way back to curthread for system call return from something like gup
> or some direct dispatch that wakes up the sleeper for the I/O?

I started the WIP that does exactly this:
> > > > But then, we probably need to add something to copy that
> > > > extended data between threads and possibly extend struct buf/bio
> > > > witg the place for exterror data besides b_error.

See https://reviews.freebsd.org/D53351
It is very beginning.