From owner-freebsd-arch@freebsd.org Fri Mar 23 10:38:49 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 1B24DF5DCBE; Fri, 23 Mar 2018 10:38:49 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) (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 9DA876C543; Fri, 23 Mar 2018 10:38:48 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f50.google.com with SMTP id o102-v6so17555142lfg.8; Fri, 23 Mar 2018 03:38:48 -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=RnkJwCPMB8DlCuQU/E3+vvPcKP34ZPwz99FZCPBfc5c=; b=fhZXjHrLMS6SluBMOJu7DGQEm0zjmpPithEAssHBs4f58mDbyVDlP1yuftHL0C4QM4 oqa5hQT3gSs45DXyHzhI+fYrneepWhZ4INxX5QC7qVABUIeDKR4W+73+bxfdkrZmq1h6 au1hfva9iK/0v3qnMrVBZ3M1P6zOLQ6B3cu7uNiF6B2Zot6z4sxAsAa5q/u9dlr325Eu 3UeDlWZxULq+z6LqjZLhdgeAliWinl51pluMjBA9oT/YmTdvlGCVAO1aR9nQVOkMNG6d DRsMb7WpriQi+7hXf/4DdJ6bxLXQ1vvL74S3OsJxuBBbshvMHKiO5ngR0+9Ugzjx5LkI ZhoA== X-Gm-Message-State: AElRT7GNLQIs+fiW5eVxZoEiEx2KLGRqWGqXSeLcTKads72GFC2xjzAO hrLh1kFrQUD5YRewNES5OAzwdJcTbb8= X-Google-Smtp-Source: AG47ELudZztuJ+KMhwsk6ykow8i8drgXxR2h2TslPx9uij9f0syZ2JYJwqaDPyFJjGgcdQI4fMWVaQ== X-Received: by 2002:a19:1754:: with SMTP id n81-v6mr16898162lfi.113.1521801526843; Fri, 23 Mar 2018 03:38:46 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id a9-v6sm2100794lfk.80.2018.03.23.03.38.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Mar 2018 03:38:45 -0700 (PDT) Subject: Re: geom->access problem and workaround To: Poul-Henning Kamp , Warner Losh Cc: "freebsd-arch@freebsd.org" , freebsd-geom@freebsd.org References: <809d9254-ee56-59d8-69a4-08838e985cea@FreeBSD.org> <56619.1520878022@critter.freebsd.dk> From: Andriy Gapon Message-ID: <5e416eb6-0e79-1419-f09a-eb747215dc28@FreeBSD.org> Date: Fri, 23 Mar 2018 12:38:44 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <56619.1520878022@critter.freebsd.dk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 10:38:49 -0000 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 cpuid = 0 curthread: 0xfffff80008e1c000 time = 1521652565 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff804670bb = db_trace_self_wrapper+0x2b/frame 0xfffffe07e1886750 kdb_backtrace() at 0xffffffff806d4c79 = kdb_backtrace+0x39/frame 0xfffffe07e1886800 vpanic() at 0xffffffff80699da6 = vpanic+0x166/frame 0xfffffe07e1886840 kassert_panic() at 0xffffffff80699adb = kassert_panic+0x16b/frame 0xfffffe07e18868b0 sleepq_add() at 0xffffffff806e1902 = sleepq_add+0x342/frame 0xfffffe07e1886910 _sleep() at 0xffffffff806a41f7 = _sleep+0x2b7/frame 0xfffffe07e18869b0 cam_periph_ccbwait() at 0xffffffff802b53ad = cam_periph_ccbwait+0x5d/frame 0xfffffe07e18869e0 cam_periph_runccb() at 0xffffffff802b51d8 = cam_periph_runccb+0xb8/frame 0xfffffe07e1886a40 cdrunccb() at 0xffffffff802d52fc = cdrunccb+0x3c/frame 0xfffffe07e1886a60 cdprevent() at 0xffffffff802d4beb = cdprevent+0x7b/frame 0xfffffe07e1886aa0 cdcheckmedia() at 0xffffffff802d48b2 = cdcheckmedia+0x22/frame 0xfffffe07e1886af0 cdstrategy() at 0xffffffff802d2a36 = cdstrategy+0x56/frame 0xfffffe07e1886b20 g_disk_start() at 0xffffffff80608330 = g_disk_start+0x170/frame 0xfffffe07e1886b70 g_io_schedule_down() at 0xffffffff8060c1db = g_io_schedule_down+0x1eb/frame 0xfffffe07e1886b90 g_down_procbody() at 0xffffffff8060cbdd = g_down_procbody+0x6d/frame 0xfffffe07e1886ba0 fork_exit() at 0xffffffff8065e410 = fork_exit+0xd0/frame 0xfffffe07e1886bf0 fork_trampoline() at 0xffffffff808e4aee = fork_trampoline+0xe/frame 0xfffffe07e1886bf0 But maybe I am overgeneralizing. Maybe it's just silly that cdstrategy tries perform media manipulations instead of just failing a request. Apparently the device was already opened, but the prevent-allow bit was changed by something else (e.g. via the pass device) and that allowed to get the tray opened. What do you think? -- Andriy Gapon