From nobody Wed Apr 12 21:33:22 2023 X-Original-To: freebsd-hackers@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 4PxbYV4NLNz44p2G for ; Wed, 12 Apr 2023 21:33:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PxbYV3McZz3nxf; Wed, 12 Apr 2023 21:33:34 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681335214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4W4+d0gJ4EIHKJJWed4h9OrlVpagUacm6HwLC95+bi8=; b=n8uWBqKzOF1nG0wRthE3y7oSJKwDSOrfk0WxF08b3I0ZAO3UrVK/91E7plWpPgsI8Q0xmC 7QZCB7X23hKuc3xbc230NrkeNv/TsMGokMIBMhE1ydvalNAPaY6qN9C1NmJLIxxKrjGtjn m9ir1FN3lHK8Rh3kNJwSxbhEwYrdSYkooa3BCoITANRR06DIEIEYPefP8htG/hzY1/HBjA nFMn2WNdX1uOwMTo4+ITDPL1BWG5m+QwUG+IvePdnUNMiFcKLOiEb/ny2YEPcPpu+p0X8J SAkzcWbEGCHQdoInuUa3NxpkLkG8ISUgbVjmI1hjiLMsY2IJw3htVWE4A7VC+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681335214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4W4+d0gJ4EIHKJJWed4h9OrlVpagUacm6HwLC95+bi8=; b=De+OYmjocNbnraZXJIQoa5WMuxqvOD0llVUOFxdupqrU3PJIgzSIyAcUlFwiv98taMNmXO rzzBVTNSSJbYKP3Q3LRmVFxXUVkRhLesXzmlsUMgBvFL7RLCxKRo5CsIPNDy+0nDa8iqGP os6wcGQ7G1zUZqf97OIW2GK80GPrZxM5wribKx+dHcwH7Gd54YyYyC5J1Xe5ssd9UCGDzN FtM+LohCPC8Qr1DtBbS5JTsw/bAl3MIoObEtxgIUEgjl5oTPvGGAFcSDuF8B7CScPhAelD PZ4ardGWk3/w1ddKgZj8oyY+X6PDlfvqlQDo29ke2ltQBsW+1hHyI+3pxK5LYg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681335214; a=rsa-sha256; cv=none; b=LPVjlivPtMrHQg2a88Diu+aBanwQpAJZobxF5Vh5f/mOdldKSn0JheGiHZwzDCQYPCCYDq 1XOfhkIC7MCUhLhEd6yELVApOE+cfdIQ1i10Y3xO1CrmqZwcIw3ukZ8tnmYIxdBHrBsod7 K9p7auAK31glVC37/amiwRCH+Ty+FX/MhYQLdAirxnFwFqPgjeuSr4m/FNbrw5shvICYx/ ufzj9JciGQgc5Wcu3Ot8ObyGu8ogGfNZfgDvLTKv8ZYTILvU1IIr6hvz+f/fWNesSQwc/F GXpmfeYa7twmxBws2BeaP0oa4fyeN5k51HAg20ANGatn1YjTY39QMGyNL7YyOQ== Received: from mail-qk1-f173.google.com (mail-qk1-f173.google.com [209.85.222.173]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PxbYV2HZBzNY6; Wed, 12 Apr 2023 21:33:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f173.google.com with SMTP id bi39so11503267qkb.13; Wed, 12 Apr 2023 14:33:34 -0700 (PDT) X-Gm-Message-State: AAQBX9dBFFYMZqVEKHBghFQsVAwGr01bSX2DxrIVnS0CZhIQZWLB9KAY Nkujg9d4xKlzHn3ZO+vz3b7SaL4H5WdE+sDVlAE= X-Google-Smtp-Source: AKy350YmhwpZlV++jJBg/LaNFk92ewQJ2ciMYtGTsjoALe7CYMA2WWVQAFxp6xrEFso1AM4HbEUBM0nHYa9BBMi5IPk= X-Received: by 2002:a05:620a:4082:b0:748:5b93:ec65 with SMTP id f2-20020a05620a408200b007485b93ec65mr1333623qko.13.1681335213784; Wed, 12 Apr 2023 14:33:33 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <4ed85151-09e8-db3e-0e0b-d0a8f3bb937c@FreeBSD.org> In-Reply-To: <4ed85151-09e8-db3e-0e0b-d0a8f3bb937c@FreeBSD.org> From: Kyle Evans Date: Wed, 12 Apr 2023 16:33:22 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Handling panics inside vt(4) callbacks To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-ThisMailContainsUnwantedMimeParts: N On Wed, Apr 12, 2023 at 3:45=E2=80=AFPM Jean-S=C3=A9bastien P=C3=A9dron wrote: > > Hi! > > While working on the DRM drivers, I don't always get a kernel core dump > in case of a panic. > > My hypothesis is that if the DRM driver code called by vt(4) panics, > then the panic code might not go through successfully. The reason is > because panic(9) prints the reason, a stacktrace and possibly some > progress to the console, which calls vt(4) and the DRM driver code again. > > I played with the following patch: > https://gist.github.com/dumbbell/88d77789bfeb38869268c84c40575f49 > > The idea is that before calling "vt_flush()" in "vtterm_done()", I set a > global flag to true to indicate that vt(4) is called as part of kdb or a > panic. If another panic occurs inside vt_flush(), typically the > underlying DRM driver code, "vtterm_done()" is called recursively and > "vt_flush()" might trigger the same panic again. If the flag is set, the > entire function is skipped instead. > > I test the patch by adding a panic(9) just before "vt_flush()" and I > trigger the initial panic with debug.kdb.panic=3D1. I don't even load a > DRM driver. My problem is that in this case, the laptop reboots > immediately. However, if I replace panic(9) with a simple printf(9), it > works as expected and I get a kernel dump. > > I could not find something in panic(9) code that would reboot the > computer in case of a nested panic. > > Previous versions of the patch called doadump() and rebooted the > computer explicitly if the flag was set, but it didn't work either and I > thought I could simplify that patch and let panic(9) handle recursion. > In other words, I just want to skip most of vt(4) code if vt(4) or DRM > crash. > > Does someone spot something wrong in my hypothesis or methodology? > FWIW, I have a related patch that I maintain in my tree that I simply haven't found time to try and upstream. When the system panics, it tries to switch back to ttyv0, but it calls into vd_postswitch() with the vt lock still held. In my case, with i915kms, the vd_postswitch implementation attempts to sleep with the lock still held and everything goes off the rails. See below. Thanks, Kyle Evans diff --git a/sys/dev/vt/vt_core.c b/sys/dev/vt/vt_core.c index 267dd7bf2489..b57370beae7b 100644 --- a/sys/dev/vt/vt_core.c +++ b/sys/dev/vt/vt_core.c @@ -592,10 +592,10 @@ vt_window_switch(struct vt_window *vw) * switch to console mode when panicking, making sure the p= anic * is readable (even when a GUI was using ttyv0). */ + VT_UNLOCK(vd); if ((kdb_active || KERNEL_PANICKED()) && vd->vd_driver->vd_postswitch) vd->vd_driver->vd_postswitch(vd); - VT_UNLOCK(vd); return (0); } if (!(vw->vw_flags & (VWF_OPENED|VWF_CONSOLE))) {