From owner-freebsd-geom@freebsd.org Tue Mar 27 17:17:12 2018 Return-Path: Delivered-To: freebsd-geom@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 583C5F6C8AE for ; Tue, 27 Mar 2018 17:17:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 028D772F56 for ; Tue, 27 Mar 2018 17:17:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x235.google.com with SMTP id k135-v6so176576ite.2 for ; Tue, 27 Mar 2018 10:17:10 -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=htZ3c5ckamE/9tMtANru4YOOM7xskRKeMlvbPUe0XpY=; b=eyDILg3DpxHQm4iTai1KVMlcrkzWJATnKxEN6lud8AujfCWuj+1AlV1K6Fs7qqZj/2 mM7+asGOVKjnRlF/yG0ivwhNVSA5UvmOvV3tdwackVJb8S8b/8bLhyXeabiAQBFkHOFI zYLLC659TRn7Bn59ex1zp0GgpmK52v3jDSDl1FYUWYvqG3ZVtv5PMCqGQxf5wpoGG+5c AsnFmBgS4amKrGjnUoqfdQKoVRFYD10pR2vpscKQKYQWZ6zbvQRu5gliA2rwa1x+kKiI qOgTcJ2z1Wg8V8OsBYZLeBGYOsP1/91cc9ZOKhNgwWB3yiMoVx1d7oSbzAyBPgUnPx1Q XZ/w== 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=htZ3c5ckamE/9tMtANru4YOOM7xskRKeMlvbPUe0XpY=; b=tAAR4bVnS4lUk3t37WZ8xSzpe+dusg+v0E3v7p4UXht87tGkvm/4sBYq8zwPAPtKuy tmt2kRD8kZPUWfNvSHcaatdPpXL4d9gOjs5598lwObrp8IL5gVVNM6zGeJ5+SQeaUjFZ R9pZqQ+JI9uYikqbLGg4aTGEngrMQXmclGKEcM2OR4jM8HvcUeDEDiFBNmU2F71IdBrO HS0606Il9MJHjVYE51xmpHCDEMSa8l6BAKGo4hjwx+UuoPTeYNdCCALQz+Lscjs6jcx5 ThNSjF4b+uPAi+lxp/2wWOXqPlp0/p0YDqIBdYDIUhBTvfvqs+otIM7FQWqPWIE9cQY7 o5Dg== X-Gm-Message-State: AElRT7HfaNodP74H9OziDAHKYjOovN0nsniK8d6f3Are45UOmVyxrmWN X2oLoJs4F+K/uYvJlbWPmw9vtjplaF8XHgsWCFFO3Q== X-Google-Smtp-Source: AIpwx4+fNJxtgPXf2Apn7l9gOT6WtjBCjfKJyT8go0iEQeZH71GSt7N5VXfbIErH6k/bK7AFyAd0ZiF848+8BXGzNms= X-Received: by 2002:a24:b649:: with SMTP id d9-v6mr117608itj.51.1522171029929; Tue, 27 Mar 2018 10:17:09 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Tue, 27 Mar 2018 10:17:08 -0700 (PDT) X-Originating-IP: [192.173.67.1] Received: by 10.79.203.196 with HTTP; Tue, 27 Mar 2018 10:17:08 -0700 (PDT) In-Reply-To: <356b875d-baee-c60b-fa76-531d3de22676@FreeBSD.org> References: <809d9254-ee56-59d8-69a4-08838e985cea@FreeBSD.org> <56619.1520878022@critter.freebsd.dk> <5e416eb6-0e79-1419-f09a-eb747215dc28@FreeBSD.org> <356b875d-baee-c60b-fa76-531d3de22676@FreeBSD.org> From: Warner Losh Date: Tue, 27 Mar 2018 10:17:08 -0700 X-Google-Sender-Auth: 5AzV3bO-RwvZyu47HZQ9x6j32yw 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-geom@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 17:17:12 -0000 On Mar 27, 2018 7:09 AM, "Andriy Gapon" wrote: 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? Yes. Something like that. If we have to restart the discovery state machine, that has to freeze the queues until that is done. Warner