From nobody Fri Oct 24 13:12:18 2025 X-Original-To: dev-commits-src-main@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 4ctNc54GsRz6DQNt for ; Fri, 24 Oct 2025 13:12:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 4ctNc52bJSz43BC for ; Fri, 24 Oct 2025 13:12:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x530.google.com with SMTP id 41be03b00d2f7-b67684e2904so1485593a12.2 for ; Fri, 24 Oct 2025 06:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1761311551; x=1761916351; 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=9DWnlSDuQCRrzquYSqmRO0BK3ObuZX4yN8Ajh6pQVY8=; b=axZGOx6U2z1sUdVlXksQdS6MbhLgKm2g6INtYO8dnk+fxejm3qEA4QdRcciV7UIgx3 mEcf6C2HhvPcpldeHYtuCimWTYmXApzC1HKKN1E/5DnS6RglLIvnxPdc73aZlo3R3rey I2KDcfOHbj3EeT5ATwx/ZCP1KsvRnM56USfu+0PP0BinHoLPPdS0OywDQisfx+ZyDFVQ Ah/h9eokJFvqKqFQ2rMOh70Uieqvgw9+PbB5vprNf1VAXgxmJP5IFncL4qxJk2dKoZoC YOTDTHebnontATpYZPbKXnSAlvz3PX1KycbuKrjKIifoeTR28GroLi4UiAwsValiHsdH Ozmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761311551; x=1761916351; 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=9DWnlSDuQCRrzquYSqmRO0BK3ObuZX4yN8Ajh6pQVY8=; b=w4gp/HfUmayRgMMeTI+HPPdJyAX2We5Z5AT/vTvRUrNG7gK/3A7P7yfMpN3pUhg/Sc 3OWXqnFkFk9QHyf9RRKU/8BGZUQoojVhVhkRX9Vdqj9t0xz1kcZQElL0yMIDqQ0Pg3Rl MiEjdx+pO6GTb+b4iO13MyEiCkosmFI9PEBGNTaiAJqKN2c21UTkHx87f0z7vCxJvS+a +ngbNBvVvSJxQ4S6nDi1XUzsbPtkdRguNSXq0/FO+UtVTgJTQZX+6O5P95qAFEhSHEB/ 9crIkM7+VmiKpyxcJKRugRgMkAlo6BxmO9UK6a4Pa7eNjVvkxD0axAtLN+JZB5b1zTDF mylw== X-Forwarded-Encrypted: i=1; AJvYcCX6BhQXMo8mpGb6zEexJPzQgSBSa1lJDkxE2gL+Zpi8ZHOF/m8d50NSscu6aEDwDgF1jjzxbIGn/WB7mLsMSmaZs7epVg==@freebsd.org X-Gm-Message-State: AOJu0Yy1WazLuBL/0Woe9W+Y1rfExH5SgbnFJvM9tbAkg28qhH8ROH6I cefSRNpkUzsNQcfYhaQ39b/38A0xNPXS/Ud5PitJzzJtEE17Jvowluc59Gv8yg7P280yVV74qt5 AvGpAQmfi1AGxhofmou1EBS1D+Bq7hhtW9eX/JmIHifr5mhs5G9Rs X-Gm-Gg: ASbGncuo1ETCRNqOVeA6wnwyM5EKVB2uXHzBcS2emNK0JvmQ+zwVEJkjXJsr6z7qWNx 4y00LRCSxoaSUyJ2kk0ZbaulJnLlBYUolaITCNFV+z5wGp/lQVJhXsktq0cTz42uNxKZ9bGrlQG KE5+9yM9ZBi9uw+GM0/cxe/2jBX/dHcS03S8eoiI3YR8bBba+sTFzTRpytvdH17FiiC26Ips6Rq NJ3BXa/pX77SEZjFIht9o2d05jtf7CvNMeuKKnQPsDBWt7Wsbt+Psl26PATNw== X-Google-Smtp-Source: AGHT+IFiITbqzThFcp+upC68WrDLUYqpD7kTBA3WIFtAuIGXI0f1qHfIOWwoDBG/BO4TJtDiXzs42+8g8mTLgSLCPfI= X-Received: by 2002:a17:903:1c9:b0:250:643e:c947 with SMTP id d9443c01a7336-2948ba0d434mr30896565ad.28.1761311550970; Fri, 24 Oct 2025 06:12:30 -0700 (PDT) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@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 09:12:18 -0400 X-Gm-Features: AS18NWC7Fqtjcw_s75lLwOi2ObAAygpzB7d3fyOCwr-dU_SxPAvJNy8cEvaW_X8 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="00000000000055a7830641e74d98" 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: 4ctNc52bJSz43BC --00000000000055a7830641e74d98 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. Warner > --00000000000055a7830641e74d98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 24, 2025, 7:49=E2=80= =AFAM Konstantin Belousov <kostik= bel@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 run= s in, managing the storage for that can be hard.
Warner
--00000000000055a7830641e74d98--