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

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