From owner-freebsd-arch@freebsd.org Tue Mar 27 14:09:17 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 DAC0DF57189; Tue, 27 Mar 2018 14:09:16 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) (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 50C4487365; Tue, 27 Mar 2018 14:09:16 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f51.google.com with SMTP id e5-v6so33553827lfb.7; Tue, 27 Mar 2018 07:09:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pm5W21szaK9mjKeKernvK6J9t5H35csrSsNI0hje+mY=; b=c7ZC6mkZpFqT5BjX5OAG3nJz9Vaxg4EjyjU7DtGoJs/BlZmglJi8tgiOdr+JdzRQ7A eGZaYOZntaXRAgHNh1yNwTgdpif1nbEHWgg7Q2fOZJazbaN7orDFOvKi6DpD8lrMcqHC BNLFBBwI6svqFEvHtHn8bsDdWKcfTC6PvL9OfvhlusCKNpGZqnh57Oelg2UI6fN6N5as 2D7dfG1rLED3spGSZmLnJHzsDg07YGY1h8hgcPs0BJ6V54MmXHeBjHQXB37G/Cs2Qx6i E+LkpxiiUXEPopmT/WGMW6HUCSujG8GNjPbDqPGMPCZw5eicSeHDshRurwsb3/K9WmH3 G/oA== X-Gm-Message-State: AElRT7FIxQ7z6VvrK13qOsyUW18U/f2j49SJn1+JsSBEcK2fsjukKDLj QdNJ9EJA8llooTN8tvMAnLIUL8Uv X-Google-Smtp-Source: AG47ELsTQXhTzxUEHjT3u31wvMJkYtTVlTkmjrDTw9n+4VrARG9IzUPtn8e/ovX88ewT/jNKT4/o8Q== X-Received: by 10.46.4.149 with SMTP id a21mr30870864ljf.138.1522159749011; Tue, 27 Mar 2018 07:09:09 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id 1sm238322lje.38.2018.03.27.07.09.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Mar 2018 07:09:07 -0700 (PDT) Subject: Re: geom->access problem and workaround To: Warner Losh Cc: Poul-Henning Kamp , "freebsd-arch@freebsd.org" , freebsd-geom@freebsd.org References: <809d9254-ee56-59d8-69a4-08838e985cea@FreeBSD.org> <56619.1520878022@critter.freebsd.dk> <5e416eb6-0e79-1419-f09a-eb747215dc28@FreeBSD.org> From: Andriy Gapon Message-ID: <356b875d-baee-c60b-fa76-531d3de22676@FreeBSD.org> Date: Tue, 27 Mar 2018 17:09:06 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Tue, 27 Mar 2018 14:09:17 -0000 On 23/03/2018 15:31, Warner Losh wrote: > > > 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. I guess that what you suggest is that cdstrategy should place the incoming request on a queue and then start a state machine for issuing management commands and handling their completions. After the state machine goes back to the normal state only then the driver would start processing queued I/O requests. Something like that? -- Andriy Gapon