From owner-freebsd-arch@freebsd.org Fri Mar 23 13:31:16 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8B24F6C882 for ; Fri, 23 Mar 2018 13:31:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 248347407E for ; Fri, 23 Mar 2018 13:31:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id 141so15150578iou.12 for ; Fri, 23 Mar 2018 06:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AoVRnoozLtO9SyxnFjtFKt13Uy2kljmz15rSsGuHkb0=; b=JUYg5+AjbNM+JV/xPuewpGnEofVeWRqGHOiZYyXJ5Im/D6lbeol3IZXBvv2XEJVDnh ERXGwmNBSORK4Tn32MgZw6nWU+JuugIqHrB/KtzZ0CccnrSNbFe9lVWE4bQlSKs7CzC/ KWMsodcPxxJ5SxHF/y03QuTvaHuwF8jAjWZVM/8EDhEjmRxF/MTfJ0Rr+UzmM99sC1oq yAF9NwRTa20ZdyPgV8V5zKJEhLkSe3p0UsAjD7daeFcvm81m8kEDvOev+V/A3RL06WhI Zb1vkEL2AVjrNW8Fdf+1Jjpy25DGvHajP48UOhGmXpgQ7wTZXtkQxvFEoPS0N3x27S/K YwRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AoVRnoozLtO9SyxnFjtFKt13Uy2kljmz15rSsGuHkb0=; b=QLctfXqoCwe6oSqjf8w0XGpmclhMtgnbZiM2LV6IN9wFduLmtTf4pfaGF6dfV0gyaU pyv4nACalKxsA+chwo6Q11ubQkb8h9HrXU9cFryso6QyXb+D3/viInikFh2YzKN5rb2d 3hvsBjCryZXB2T9xlNYB4IlRDgrMqJgrk0pcxZdxX8KAVoch/ZN7PL6rEUHgvLX8NrV+ Srid4rUt7NM5cgZhH0qdvicuM2GzdwRWRVoCQf5AO684YuKIhgvbuLfAeOwmKBUnLJLZ RNLQ0GIJ/GUyl5ECk4OX4cq5HI6phUQ9GiQiX/BzZvZqheCepM8S5RJ1vRyefZCXfDlf 6SCw== X-Gm-Message-State: AElRT7Eg1wiwu5OUsZShSoo2a+PPpFWijSie7UAF1VVKuhOKaHDFGFtC 9jYS6P4R9cSW7591F4oKGAhRd1+0o5+l9AxSM4V4Xg== X-Google-Smtp-Source: AG47ELtXbkgrg7zfkIR7FsHvb9H9FB9VjaN8Xz4UXcIoJ5IrzzbJ663ui6agaZnp03sVFaZjug+dqFm7/rl58o8nWHQ= X-Received: by 10.107.58.134 with SMTP id h128mr29447583ioa.299.1521811875502; Fri, 23 Mar 2018 06:31:15 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Fri, 23 Mar 2018 06:31:14 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: <5e416eb6-0e79-1419-f09a-eb747215dc28@FreeBSD.org> References: <809d9254-ee56-59d8-69a4-08838e985cea@FreeBSD.org> <56619.1520878022@critter.freebsd.dk> <5e416eb6-0e79-1419-f09a-eb747215dc28@FreeBSD.org> From: Warner Losh Date: Fri, 23 Mar 2018 07:31:14 -0600 X-Google-Sender-Auth: kpEyGCL0IYYV3dHyl3t97cIGIjk Message-ID: Subject: Re: geom->access problem and workaround To: Andriy Gapon Cc: Poul-Henning Kamp , "freebsd-arch@freebsd.org" , freebsd-geom@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 13:31:17 -0000 On Fri, Mar 23, 2018 at 4:38 AM, Andriy Gapon wrote: > On 12/03/2018 20:07, Poul-Henning Kamp wrote: > > If we want to have an architectural sound way to do slow operations > > before any "user-I/O" is initiated, the right way to do so is to > > define new BIO_OPEN and BIO_CLOSE operation, and insist via asserts > > than all BIO_{READ|WRITE|DELETE} are wrapped in these. > > > In support of this proposal I want to add another example. > The problem is not only with doing I/O in access, but also with doing > blocking > I/O in the normal I/O path. > The following happened when a userland program tried to read from a CD-ROM > while > its tray was open: > > panic: sleepq_add: td 0xfffff80008e1c000 to sleep on wchan > 0xfffff801e58b8048 > with sleeping prohibited > cdstrategy shouldn't be sleeping. It can start I/O, but it can't wait for it to finish. strategy has been a no-sleep-zone since at least v6. The fact it's waiting for prevent is the bug here. Waner