From nobody Fri Oct 24 21:40:36 2025 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ctbtW36bXz6Cy2g for ; Fri, 24 Oct 2025 21:40:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ctbtW0V2Rz3Hyh for ; Fri, 24 Oct 2025 21:40:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-32ec291a325so1996024a91.1 for ; Fri, 24 Oct 2025 14:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1761342048; x=1761946848; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nGaz+B3fEJ0WJmJrsHErZdNkloh9cvhgZMyGNzOidqc=; b=t51uxUc/2IzJQC81YfAdaTjrym3YA4tjrGOLLoQTxCkZeY13zTRjzct68Ut1OlJ1IR qVtpFzc+nRMUHtdH0bR/+nt0C2d0B/hOspiGhvyQZWgCEsENfxPwhQ5nB9Ed+EkshU64 XFOkFZepzUNg0bFfUkzbezd0GwO3buW3htrj5nN+or/owxLvsc+AhCAm2ngXMJglT00v Wh33IDObb1NGSCj8kkKyC0wCC1jhjFHWAmrV/rwzMlprmRLO4nyN6ZZCwEV3HR0zLomB HmE9m4s5CcIb0ynJ5Wj9VkaTqZn8c9wIwLNalrHAjdy0aTMiK0E4/dnspWu2y37KeHct sBXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761342048; x=1761946848; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nGaz+B3fEJ0WJmJrsHErZdNkloh9cvhgZMyGNzOidqc=; b=Ks8Tz08G52a9lEObuhQTUVIO84GKw1Bk+O0UXLsBBNPWl3J1p1zqhLRgaDlRFAaQKE A6bgzf6qQPYbnV+T/+QULu08eBXDMFkfq01zVAgOd07+NAWbIr6OZw09w0cWcM/O4VJV gV8d8Kqqk1Q4HE77r5B8Lg4mcL87mazF3wRos0NYmmpu+1FBRGFnBkNQTMm7VUtcWhkJ KFTTTV81VqWfQ2CHQbUEjCnGAS2fsFDOLX/BzMSir4xltbzEm/tdDEqO5nA513p+d4AO Hq0X01lhytW/FHJl6HTDUpCf2r/hzMHJ5qa1BWNUjFgM25ZVk+eUlZIOHQ7hvWSoy368 CACA== X-Forwarded-Encrypted: i=1; AJvYcCUcspuqsyo2RCD0TMydRfjSPo2Fc0AzgoCWcrYg7TTRyl7PzJiFO+ggiJSRRYuI0ycETYFu9iU4rNn0b1CH6NsaQ9af@freebsd.org X-Gm-Message-State: AOJu0Yy+SR4JWejCovJbH0PYMWpSB78fwWN/zHk5GvLCe55UIACKZieq On+DshqL+jyxWLQY94jgTl8+4cPIk9/u+RZqlSjCNOgatkIfZir9hDWLCRLbYdZpPAyMsfhvWSh xkxq52U/mknek/y1kSdM8RzfD22I56wl5HZSgQqYWtQ== X-Gm-Gg: ASbGncso2HoQakhh+aTUAn3Lr1/qdNbwkEaBFyaJlpAXMBKhw9iz/NvGdFl8zc7jVo1 r2b5s04f2tApuAqVSzDf55YwVTnLJ5OZgZIqlNK+9RJz+e4Lst7HfswxpfsyX+yjI+TRYALCzXW yG9HNoaBKkhvccoOLNhvc8TTKh8DneuWlxkSDwqK3UvRyduVMZG2DVxgPUrqAUieXmGW25ySAVY dleIWTm+bKJXK3PI5nP0H4fTQX6keAhfY/N41K8atmf45HrtileqkujdDOsX/T6BkEl/943 X-Google-Smtp-Source: AGHT+IHIoJEIA/AV8jgJ0xXaETvYzsbDeGm66D+vhdbB5VjMdWPuhEq/6Z891+qBe09CWD1YDO0i8bAeelhfMhzbamU= X-Received: by 2002:a17:90a:ec8b:b0:335:2934:e217 with SMTP id 98e67ed59e1d1-33bcf86c0a9mr38279214a91.10.1761342048363; Fri, 24 Oct 2025 14:40:48 -0700 (PDT) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 References: <202510240741.59O7fBAe041995@gitrepo.freebsd.org> <202510241012.59OACUDA002781@critter.freebsd.dk> <202510241116.59OBG1ii003074@critter.freebsd.dk> In-Reply-To: From: Warner Losh Date: Fri, 24 Oct 2025 17:40:36 -0400 X-Gm-Features: AS18NWAFrpyICRMTQ9NTbJkx9vS7qH2wMEjYLUc7c2BpglRrGrLHeOoTOxxm3yc Message-ID: Subject: Re: git: 2612f1b8649b - main - deadfs: Return ENXIO instead of EIO when the device is gone. To: Konstantin Belousov Cc: Poul-Henning Kamp , src-committers , "" , "" Content-Type: multipart/alternative; boundary="0000000000001ef73a0641ee6764" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4ctbtW0V2Rz3Hyh --0000000000001ef73a0641ee6764 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 24, 2025 at 12:03=E2=80=AFPM Konstantin Belousov wrote: > On Fri, Oct 24, 2025 at 09:12:18AM -0400, Warner Losh wrote: > > On Fri, Oct 24, 2025, 7:49=E2=80=AFAM Konstantin Belousov > > 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? Warner --0000000000001ef73a0641ee6764 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 24,= 2025 at 12:03=E2=80=AFPM 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=E2=80=AFAM Konstantin Belousov <kostikbel@gmail.com&g= t;
> 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 fo= r io.
> > >
> > > 100% agreement.
> > >
> > > But it can change the order of thread/interrupt/event-handli= ng
> > > scheduling.
> > >
> > > When I tested the ENXIO patch, I started booting an unmodifi= ed
> > > kernel in single-user and immediately got ENXIO when I pulle= d
> > > the USB stick - quite to my surprise.
> > >
> > > Then I kldloaded i915kms, still in single-user, and now I go= t
> > > the observed bad EIO behaviour.
> > >
> > > With a fixed kernel and i915kms loaded, I saw four or five r= eads
> > > return EIO before one got ENXIO and terminated recoverdisk.<= br> > > >
> > > Getting a handful of EIO's before the ENXIO finally appe= ars
> > > strongly suggests that some of the eventhandling related to<= br> > > > 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<= br> > > witg the place for exterror data besides b_error.
> >
>
> Given the contexts cam runs in, managing the storage for that can be h= ard.

Which storage?

EXTERROR() does not allocate any memory.=C2=A0 It was designed to be safe f= or
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 di= rect dispatch that wakes up the sleeper for the I/O?

Warner=C2=A0
--0000000000001ef73a0641ee6764--