From nobody Fri Oct 24 16:03:22 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 4ctSPR4HGZz6Dmx0; Fri, 24 Oct 2025 16:03:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ctSPQ4JXqz3VBN; Fri, 24 Oct 2025 16:03:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 59OG3M7n072120; Fri, 24 Oct 2025 19:03:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 59OG3M7n072120 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 59OG3MN4072119; Fri, 24 Oct 2025 19:03:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 24 Oct 2025 19:03:22 +0300 From: Konstantin Belousov To: Warner Losh Cc: Poul-Henning Kamp , src-committers , "" , "" Subject: Re: git: 2612f1b8649b - main - deadfs: Return ENXIO instead of EIO when the device is gone. Message-ID: References: <202510240741.59O7fBAe041995@gitrepo.freebsd.org> <202510241012.59OACUDA002781@critter.freebsd.dk> <202510241116.59OBG1ii003074@critter.freebsd.dk> 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4ctSPQ4JXqz3VBN On Fri, Oct 24, 2025 at 09:12:18AM -0400, Warner Losh wrote: > On Fri, Oct 24, 2025, 7:49 AM 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).