From nobody Thu Feb 08 17:52:50 2024 X-Original-To: dev-commits-src-main@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 4TW4MT5g1Nz5B6W8; Thu, 8 Feb 2024 17:52:53 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4TW4MT50x2z4dsL; Thu, 8 Feb 2024 17:52:53 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707414773; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=L4MMfVyAY1l/I2jrMTHtDD1yve+1bJwZtD1GlR1qFQk=; b=PaLUlKKBsox1b98nJfZzE7ITpvPIoMCUkp1k5mqeqs4R51tJKyRgzhMVUTTB3eSxbig+6m clUGlHwb2M3CyFgBlbOwN5rreIfyWRpj5zaW06LznQrt3CrOs7ido5oUhHVbUv+ASIFwPo VsWwCX5fQGeR4YUUeJH7qK4RiCaD0XTHDWWryTpraGin9wXGwY7+ywFklDgINXPRFWl8IS nFaijp5dh86NzLcd52FxiuwO1yMH1ayxaFLAsPV5OFRn1SxP9hFBKDieIrxeWA5awvInKe bIaaXH4vlSywj1fi4HvkvBeskfxa1kxlcbTCeC6Ysstg6mbwqzDZM2uB4p5zlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707414773; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=L4MMfVyAY1l/I2jrMTHtDD1yve+1bJwZtD1GlR1qFQk=; b=xrmcEmNsi2MmcQ16KdQja9kPMoGWSilp8ACSTNyLRgobAoVVGb49lhvP95F5zFuJae1NE2 rLa3I+Sb1wdeSMLo1yiJIwmklMYQO38i//DaPkXqgMtk2G5sAd06CCZqLVk7HPgsfALCu9 WXyugkz97R0XKT2T8KAnPMyF93JNTaHmnpOZZLbp80XHkezdnmlxqKdgqVK4Qp+ilQ/L+H Aul74tgJVcqXXiLTdHmOxOE6fHaZuDFAQzdcyNCa/cnGZoZvG7bQiKFAPt+nwQrvG++R9o Ffj5z/qvhAGkyg8/ggWL8nPEz0VfxFS1smNqEwO2tV3qSax2zf+xOuoYM2EBHQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707414773; a=rsa-sha256; cv=none; b=ZV+r6OXMw6U9QqVXxMwDmlP5SHpm9FtcCuLTaUXb/B3JOscJbjnib6MDNCrVTw/9Zm1iiz mjTk+GERgaHb2EfPN7ixE6BH1KEY1pmFAL1mlx2goK6Fzx3gtb3alL1Fwm0DVyvqdVJxtJ 6i2m5OoIBN675y8BkiWCEU+HUjnGLXlVmr98Z2fdddwvj1Ms7sstibPyuxU5CUPt7DOrYn 4w6ESICbtZMt8mpxTGPfUrMSVesnxJVoHozMwncnbVD1Ctm/8Y8hy5lCDKSTGfVLTXrwRu S3LhbHJacFRDgBam7AcKlotdSTd2xl+HOw1AFZCWrXaNE+chOFmnA2lTsTemog== Received: from [IPV6:2601:644:937c:5920:4c63:23c7:5c22:d7ba] (unknown [IPv6:2601:644:937c:5920:4c63:23c7:5c22:d7ba]) (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 did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TW4MT0y1PzY65; Thu, 8 Feb 2024 17:52:53 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <175dce9b-ee44-434c-b6b2-20717a04f6aa@FreeBSD.org> Date: Thu, 8 Feb 2024 09:52:50 -0800 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: e4ab361e5394 - main - fix poweroff regression from 9cdf326b4f by delaying shutdown_halt Content-Language: en-US To: Andriy Gapon , src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org References: <72def5a9-ffcc-4dcc-9b85-875ba7f46539@FreeBSD.org> From: John Baldwin In-Reply-To: <72def5a9-ffcc-4dcc-9b85-875ba7f46539@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/6/24 2:13 AM, Andriy Gapon wrote: > On 06/02/2024 11:41, Andriy Gapon wrote: >> The branch main has been updated by avg: >> >> URL: https://cgit.FreeBSD.org/src/commit/?id=e4ab361e53945a6c3e9d68c5e5ffc11de40a35f2 >> >> commit e4ab361e53945a6c3e9d68c5e5ffc11de40a35f2 >> Author: Andriy Gapon >> AuthorDate: 2024-02-06 08:55:13 +0000 >> Commit: Andriy Gapon >> CommitDate: 2024-02-06 08:55:13 +0000 >> >> fix poweroff regression from 9cdf326b4f by delaying shutdown_halt >> >> The regression affected ACPI-based systems without EFI poweroff support >> (including VMs). >> >> The key reason for the regression is that I overlooked that poweroff is >> requested by RB_POWEROFF | RB_HALT combination of flags. In my opinion, >> that command is a bit bipolar, but since we've been doing that forever, >> then so be it. Because of that flag combination, the order of >> shutdown_final handlers that check for either flag does matter. >> >> Some additional complexity comes from platform-specific shutdown_final >> handlers that aim to handle multiple reboot options at once. E.g., >> acpi_shutdown_final handles both poweroff and reboot / reset. As >> explained in 9cdf326b4f, such a handler must run after shutdown_panic to >> give it a chance. But as the change revealed, the handler must also run >> before shutdown_halt, so that the system can actually power off before >> entering the halt limbo. >> >> Previously, shutdown_panic and shutdown_halt had the same priority which >> appears to be incompatible with handlers that can do both poweroff and >> reset. > > I want to add that having many handlers with priorities expressed like > SHUTDOWN_PRI_LAST ± N while some of those handlers have implicit > inter-dependencies (interactions, interference) also does not help to see a > clear picture. > > Perhaps it would be better to handle all (reasonable) RB flag combinations > centrally in kern_reboot and then dispatch events like shutdown_reset, > shutdown_poweroff, etc. Handlers for those events would have a single and > simple job of performing that one action (perhaps failing and letting another > handler try). I think having separate eventhandlers for shutdown, reset, and poweroff seems sensible. It also permits a given driver to use different priorities (maybe it wants to be first for poweroff but last for reset, etc.) > Also, I would split reboot howto into command and flag portions, so that only > one command can be specified at a time. E.g., I would consider RB_AUTOBOOT > ("RB_REBOOT"), RB_POWEROFF, RB_HALT to be distinct commands. Then, flags like > RB_NOSYNC or RB_DUMP could be optional flags. > > As an aside, some flags documented for reboot(2) do not seem to have much to do > with reboot. E.g., RB_DFLTROOT affects how a system boots up, but not how the > system goes for a reboot. Not surprisingly, that option is not handled by > anything kicked off with reboot(2). > Maybe, it would make more sense if we had fast reboot support and the running > kernel could instruct the next kernel directly. But, it's still a bit weird > that flags like RB_POWEROFF and RB_DFLTROOT belong in the same domain and can be > set together. I would suggest deprecating flags that are no-ops. In modern systems if you want to control the next boot you do it via other means (nextboot, efibootmgr, etc.) and reboot(2) is not a good API for that. It might be hard to fully cleanup some of the hackiness here, but if you can at least isolate the flag weirdness handling in kern_reboot by having the more specific eventhandlers then that might fix most of the ugliness. -- John Baldwin