From nobody Wed Apr 17 03:53:06 2024 X-Original-To: arch@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 4VK6Sw1BjWz5Hkwq for ; Wed, 17 Apr 2024 03:53:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VK6Sv6VRNz4Z5l for ; Wed, 17 Apr 2024 03:53:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-563cb3ba9daso5115229a12.3 for ; Tue, 16 Apr 2024 20:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1713325998; x=1713930798; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tlNDMJejlzh9ISbBW+NDEwghDc6NRoCqV8Dm6sAuZmw=; b=hxOtEn3AqZ2B3GH5lyrYu417Vqf4Bl8y1uxzx5mjD2+kpvVkgyatrORXPlRqk4cXcg kHmC8Kj2APNks7S/R8hJ9255C6KrR2LmhK43kFoi1KcoJIJuMB0G12iMvwOHTEYF20co s51rBXNspEbkPHqgxZ9Jrdhm/N1CV5552ZB7CVQOK37nSP4xsvtuetywPbvYpnWG3uGV rc9tslx/6ck/GyA7lmbvnwJDsl9f9WUUCtHcziZWPJVhR1mV1cR/dQj37PIFMmfp0iO2 fMhRKh7RtLWpzJ4fyVsyV/vRVFcC7wsA4ug6GqDCn1fF1jeKUQ+lFVNAKkG0X3CC++ky 0HHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713325998; x=1713930798; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tlNDMJejlzh9ISbBW+NDEwghDc6NRoCqV8Dm6sAuZmw=; b=F2ozQHA/WhcGgZg8AyWaMrsH6UaXJL6YAbnLESV1XTTzbp/IKCiVk3KkvU/pVytYYH f/MtDax/ivesJY5EdNHY9ew8IEC32tfHizVj9HblKI0cdUbKYyLuXLAttYhm4hUneuBn C+BHfv2i4KwY0UjX/8IYAETlEzeNcTwtO5zb689aZppkWZxXh8fPmzgU008OpC+rUKYV IV4sdhDh1Z3ERGh3zqcHyhRyIi7W9Txu+HJQ7B1ttruzqcKD3+zc7qL0+kJYN6fagBAN VMk09MFgNNMCgv+WCdCEYdX0pfnNXbpqwcqnld/McbbIiWe4WI2jHaRVvBxBTg2NJJdK GsNg== X-Forwarded-Encrypted: i=1; AJvYcCWxh51W7qxevwjuQOCfb+fdim4FmRT2K8jip/84R5t6WZ4+pAeyItQUvZA5+edCMA7MXp4BNvoXgCW+dq/NBYkM X-Gm-Message-State: AOJu0YwWvz4BDvQxNMATblmzWVHuwBONwg9iP+9L3MxUJVZTjEqLHlYE ZBaDa/iiT3d/YXAgX35NbWAFpL0iUOxnAEQDiVaK11/W4YXE0VTUM0hzXOPChfK5nuMFHQoIgrz RZMQv+mGiMfpJWXRVvJfOyHFigaFx+JrOJ0Zlow== X-Google-Smtp-Source: AGHT+IFUse/KDkxzKEVmK0Go2Dm04fKepszoUl16ych361J6cEQacKUWsB8j9MlzUFZ/AHYYVonf8o4TugUZ7nKLDAY= X-Received: by 2002:a17:907:7daa:b0:a55:57bb:35d6 with SMTP id oz42-20020a1709077daa00b00a5557bb35d6mr447793ejc.36.1713325998183; Tue, 16 Apr 2024 20:53:18 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 References: <0100018ee9e8a381-2e0a8845-5321-4841-bfaf-184376e88112-000000@email.amazonses.com> In-Reply-To: <0100018ee9e8a381-2e0a8845-5321-4841-bfaf-184376e88112-000000@email.amazonses.com> From: Warner Losh Date: Tue, 16 Apr 2024 21:53:06 -0600 Message-ID: Subject: Re: enable INVARIANT_SUPPORT in GENERIC in release builds To: Colin Percival Cc: Lexi Winter , arch@freebsd.org Content-Type: multipart/alternative; boundary="00000000000081b52d061642cba9" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4VK6Sv6VRNz4Z5l --00000000000081b52d061642cba9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 16, 2024 at 8:35=E2=80=AFPM Colin Percival wrote: > On 4/16/24 14:00, Lexi Winter wrote: > > currently release version of GENERIC (or GENERIC-NODEBUG in main) does > > not have INVARIANT_SUPPORT enabled. > > > > unfortunately, the presence or absense of this option breaks the KABI > > because, as i understand it, modules built with INVARIANTS won't load o= n > > a kernel without INVARIANT_SUPPORT. > > > > is there a reason INVARIANT_SUPPORT can't just be enabled by default? > > I think while it had much lower overhead than INVARIANTS, there was still > a significant overhead cost at least in the early days. Maybe that's no > longer the case. > I thought it had no overhead (despite the comments saying it does). It only increases runtime from what I can see if INVARIANTS or WITNESS are defined. > > this would remove one roadblock to separating kernel modules from the > > kernel config in both pkgbase and ports, because there would be no need > > to build a KABI-incompatible kernel just to build a single module with > > INVARIANTS. > > If the overhead cost of INVARIANT_SUPPORT is no longer relevant, I'd be > fine with including it in stable/15. Of course we can't turn it on for > stable/1[34] for the ABI reasons you just mentioned > I think that it just exports more functions, so that's something that could be exported. Warner --00000000000081b52d061642cba9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 16, 2024 at 8:35=E2=80=AF= PM Colin Percival <cperciva@tars= nap.com> wrote:
On 4/16/24 14:00, Lexi Winter wrote:
> currently release version of GENERIC (or GENERIC-NODEBUG in main) does=
> not have INVARIANT_SUPPORT enabled.
>
> unfortunately, the presence or absense of this option breaks the KABI<= br> > because, as i understand it, modules built with INVARIANTS won't l= oad on
> a kernel without INVARIANT_SUPPORT.
>
> is there a reason INVARIANT_SUPPORT can't just be enabled by defau= lt?

I think while it had much lower overhead than INVARIANTS, there was still a significant overhead cost at least in the early days.=C2=A0 Maybe that= 9;s no
longer the case.

I thought it had no ov= erhead (despite the comments saying it does). It
only increases r= untime from what I can see if INVARIANTS or WITNESS
are defined.<= br>
=C2=A0
> this would remove one roadblock to separating kernel modules from the<= br> > kernel config in both pkgbase and ports, because there would be no nee= d
> to build a KABI-incompatible kernel just to build a single module with=
> INVARIANTS.

If the overhead cost of INVARIANT_SUPPORT is no longer relevant, I'd be=
fine with including it in stable/15.=C2=A0 Of course we can't turn it o= n for
stable/1[34] for the ABI reasons you just mentioned
I think that it just exports more functions, so that's som= ething that could be exported.

Warner
--00000000000081b52d061642cba9--