Date: Sat, 25 Oct 2025 12:27:45 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, src-committers <src-committers@freebsd.org>, "<dev-commits-src-all@freebsd.org>" <dev-commits-src-all@freebsd.org>, "<dev-commits-src-main@freebsd.org>" <dev-commits-src-main@freebsd.org> Subject: Re: git: 2612f1b8649b - main - deadfs: Return ENXIO instead of EIO when the device is gone. Message-ID: <aPyYEVAMCoUQ_Oay@kib.kiev.ua> In-Reply-To: <CANCZdfpx9HP4u3gQAio5ombyesmua4fEvM34Kv2PdiFwXgegcg@mail.gmail.com> References: <202510240741.59O7fBAe041995@gitrepo.freebsd.org> <aPs27Dc_w10t3ENH@kib.kiev.ua> <202510241012.59OACUDA002781@critter.freebsd.dk> <aPtWo1UP-UpPdsVf@kib.kiev.ua> <202510241116.59OBG1ii003074@critter.freebsd.dk> <aPtnt9siqT5R_32l@kib.kiev.ua> <CANCZdfrCa7PXtXEPU-O5Lgn3CkY86u-%2BP=pxVz%2BszAVxij9Hgw@mail.gmail.com> <aPujStfcOBful7z2@kib.kiev.ua> <CANCZdfpx9HP4u3gQAio5ombyesmua4fEvM34Kv2PdiFwXgegcg@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aPyYEVAMCoUQ_Oay>