From nobody Fri Oct 24 13:12:18 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 4ctNc54Gtlz6DQP6 for ; Fri, 24 Oct 2025 13:12:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 4ctNc52BxWz43Ms for ; Fri, 24 Oct 2025 13:12:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-7a265a02477so1574966b3a.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=RyJIyv5yWf3ExDAOBKcArIqsfsEGHQYP35aYCdiZp1lmZ6E10h4AfVouvoGfwwY678 Ed1Iec98vDWZ4zF1ZHjhQJwTglMwqP4iVjwKwnEih5gzVrXxOEHRDJDiCWcP3ykWU7vW rj+1DdmlEh5Ci499s+T59hBxMA8xcc+WEKhgGW0uyveD+PWi892M0MA+C/WuR+u6fbmY VuXK0O0hOZBZz8dTdkMFwPEXLYFeLUOIoJHB+P6/xQZtOUEL7IXULGomp9cPGpFUTW8l xfQBN/mNfmv8qJcy5SlnmEUz3F9N+OQ9Y5Nf1h+/p12bbdHl6/BOLy8jtI8OtZMgF7Lr w8nA== X-Forwarded-Encrypted: i=1; AJvYcCU8W5fcMk6Db/WZSa7lrE70egrscymrvl9m3kf6z86tiE2kyfWIfh9RvWMVBmfQ+hZ9jN5PVh80PD7xfDoUVEc/Onml@freebsd.org X-Gm-Message-State: AOJu0YwIWj4pwFylUSynwbSa7N9XFDACprfrhdvxYQsFt7ZoSqzaYLA8 J/g2Y/vppPG3bTQ63mBRHoK85x7nTGoK9mKpqs3Z5Es71EXFEAnr8cH2lkjxoPk3vZXF1cJPAOt nJ5bdaHLu3M0MV6H8grM4jkkue+RVbhvA29t6cmQRfg== X-Gm-Gg: ASbGnctmrLjvqA2ppaUMZ+3yb0MycM/bl9fQeGYPBWQT481VmN8+AX9fEtM6j3a7m7Z TBQFWOOnA0WC1NHjgO+ktnj+c4GSMbXhXc0/9JGL4oBLa9R/xYAHOfAtDZlPN4vA7SjY9lCNEZA x2/X7njdlVEfNrjUFEDGki9LawevBIIBAkfjTTliNU1tzBeipoFueNys+li6XbQw9TK41zfJ1Lq ZL90lpDdS+TFtFvk0UQWXk4dzLuxF0AgeTTRzF377DDZfFblg6k7TCNu+BUBQ== 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 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 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: 4ctNc52BxWz43Ms --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--