From nobody Sun Jul 2 10:18:35 2023 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 4Qv4lX33Nwz4lYRF; Sun, 2 Jul 2023 10:18:48 +0000 (UTC) (envelope-from khng300@gmail.com) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 4Qv4lW2z5Rz3nMr; Sun, 2 Jul 2023 10:18:47 +0000 (UTC) (envelope-from khng300@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=Gvtg6a38; spf=pass (mx1.freebsd.org: domain of khng300@gmail.com designates 2607:f8b0:4864:20::62f as permitted sender) smtp.mailfrom=khng300@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pl1-x62f.google.com with SMTP id d9443c01a7336-1b7dd061e9aso18997485ad.2; Sun, 02 Jul 2023 03:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688293126; x=1690885126; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hRNf9qwLtqD5ZCp7cv4WfsCFx/hZUczftuWi+PsVNBQ=; b=Gvtg6a38zXVamcGDRb2NzE/xkPTCNjJL2Tk3A4qZnOy16vs7fyH6ng1qpgw3eatJUh j1OfgEwH4jhiX6lLo38c0RXBDRMW1/RcjxrES78mhfIgmwIsPDR8Tkw9cSbIOIYa4NRO 3Nj9jwej2ETwS+Pev+FU8cHSM7xKcYHPB2or6U9HmxvPqBvERsxwYvMc8tqqsIZIAftI ruPLNEplOssCxYYpfmYBGuoNIkR6juIpeZVv6mw89Uq/yDef76wHtdsz+m28lqOFW0lf zMo6CFOj8L7vtkv1sksHRyDIjCmO/fR6LqZgpafJU52TkEcCk91+Q6bXO6/LXEcVTlyF 1eHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688293126; x=1690885126; 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=hRNf9qwLtqD5ZCp7cv4WfsCFx/hZUczftuWi+PsVNBQ=; b=lMJxMsNohb1A2jqm07kFUA21WwMfm/6dYcI6mF/e9yGopvnQwhO9bFRj8hRH038sWf d0g/Xu/KKClWB2xXrqk2E47rEWHHG5CzBWw/jBbJM0cD+d+nvD19IAIQ1Bl3X16plROo vjq55qKDPuSRxcZmkYcl62CzMkIdo6Y7xvNoVsCxUacWIPkozdU4u53mQOBpuFBYdMvi MV8JXj2icCJsQr1U0zLQwusjRbZi2Y4FmKC+X07CF42vLsMXyTL/jdcGD94nFEnqFl8D Lvg7wmDdWVW5z0GYvAjxm0bvHSb0+cvWYYzCSmC0HxeKOJLqJnN77E6XT1pw8ducrzsp dtEQ== X-Gm-Message-State: ABy/qLaAVbmiWBlv8/aTwkjglcKjkwzwG6UjWwWMMF9VQ7tEQJtzRG4Y Zl/3/q7CLf53YJ0qmDDrtLA5YbayKAKoQ+yp1rrADTWzt72FWq9e X-Google-Smtp-Source: APBJJlFM2ontNDtPb7oKJdny35aSlCy492liE6+Yv7gj1HBib/cg7/i9DrJ5sai8oG7R+rASv/h5Vc5aIbarkkqwHk0= X-Received: by 2002:a17:902:ea08:b0:1b8:8262:7333 with SMTP id s8-20020a170902ea0800b001b882627333mr3112959plg.51.1688293125947; Sun, 02 Jul 2023 03:18:45 -0700 (PDT) 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 References: <202307012259.361MxM4i017090@gitrepo.freebsd.org> In-Reply-To: From: Ka Ho Ng Date: Sun, 2 Jul 2023 06:18:35 -0400 Message-ID: Subject: Re: git: 005aa1743b42 - main - modules: bzero the modspecific_t To: Konstantin Belousov Cc: Ka Ho Ng , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="0000000000000c84c705ff7e6065" X-Spamd-Result: default: False [-0.71 / 15.00]; NEURAL_SPAM_MEDIUM(0.95)[0.948]; NEURAL_HAM_SHORT(-0.85)[-0.852]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; NEURAL_SPAM_LONG(0.20)[0.196]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org,dev-commits-src-main@freebsd.org]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::62f:from]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4Qv4lW2z5Rz3nMr X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N --0000000000000c84c705ff7e6065 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jul 2, 2023 at 6:03=E2=80=AFAM Ka Ho Ng wrote: > On Sat, Jul 1, 2023 at 7:13=E2=80=AFPM Konstantin Belousov > wrote: > >> On Sat, Jul 01, 2023 at 10:59:22PM +0000, Ka Ho Ng wrote: >> > The branch main has been updated by khng: >> > >> > URL: >> https://cgit.FreeBSD.org/src/commit/?id=3D005aa1743b42b52fbd49b9d5ec4481= 6902b6ee9f >> > >> > commit 005aa1743b42b52fbd49b9d5ec44816902b6ee9f >> > Author: Ka Ho Ng >> > AuthorDate: 2023-07-01 19:41:53 +0000 >> > Commit: Ka Ho Ng >> > CommitDate: 2023-07-01 22:58:46 +0000 >> > >> > modules: bzero the modspecific_t >> > >> > Per https://reviews.llvm.org/D68115, only the first field is >> > zero-initialized, meanwhile other fields are undef. >> This is not true. >> >> > >> > The pattern can be observed on clang as well, that when >> > -ftrivial-auto-var-init=3Dpattern is specified 0xaa is filled for >> > non-active fields, otherwise they are zero-initialized. >> What are non-active fields? >> All fields with implicit initializers >> "shall be initialized implicitly the same as >> objects that have static storage duration." >> >> I do not think this is required for padding. >> > In that case, modspecific_t ms did become 0xaaaaaaaa00000000 on amd64 if > -ftrivial-auto-var-init=3Dpattern was specified. > > >> >> > Technically both are acceptable when using clang. However it >> > would be good to simply bzero the modspecific_t in such case to >> > be strict to the standard. >> > >> > MFC with: 2cab2d43b83b >> > MFC after: 1 day >> Min MFC period is 3 days. >> >> > Sponsored by: Juniper Networks, Inc. >> > Reviewed by: delphij >> > Differential Revision: https://reviews.freebsd.org/D40830 >> > --- >> > sys/kern/kern_syscalls.c | 3 ++- >> > 1 file changed, 2 insertions(+), 1 deletion(-) >> > >> > diff --git a/sys/kern/kern_syscalls.c b/sys/kern/kern_syscalls.c >> > index 234e51cfd280..0b51edf5e985 100644 >> > --- a/sys/kern/kern_syscalls.c >> > +++ b/sys/kern/kern_syscalls.c >> > @@ -173,9 +173,10 @@ kern_syscall_module_handler(struct sysent >> *sysents, struct module *mod, >> > int what, void *arg) >> > { >> > struct syscall_module_data *data =3D arg; >> > - modspecific_t ms =3D { 0 }; >> > + modspecific_t ms; >> > int error; >> > >> > + bzero(&ms, sizeof(ms)); >> > switch (what) { >> > case MOD_LOAD: >> > error =3D kern_syscall_register(sysents, data->offset, > > > Ka Ho > Since I missed the reply-all button just now, I resend this email. Reading on N2716 one of the footnote stated: "Note that aggregate type does not include union type because an object with union type can only contain one member at a time" And below at 6.7.9.21 only aggregate was mentioned but not union, which matched what I observed with an `cc -ftrivial-auto-var-init=3Dpattern` invocation. Ka Ho --0000000000000c84c705ff7e6065 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jul 2, 2023 at 6:03=E2=80=AFAM Ka= Ho Ng <khng300@gmail.com> w= rote:
On Sat, Jul 1, 2023 at 7= :13=E2=80=AFPM Konstantin Belousov <kostikbel@gmail.com> wrote:
On Sat, = Jul 01, 2023 at 10:59:22PM +0000, Ka Ho Ng wrote:
> The branch main has been updated by khng:
>
> URL: https://= cgit.FreeBSD.org/src/commit/?id=3D005aa1743b42b52fbd49b9d5ec44816902b6ee9f<= /a>
>
> commit 005aa1743b42b52fbd49b9d5ec44816902b6ee9f
> Author:=C2=A0 =C2=A0 =C2=A0Ka Ho Ng <khng@FreeBSD.org>
> AuthorDate: 2023-07-01 19:41:53 +0000
> Commit:=C2=A0 =C2=A0 =C2=A0Ka Ho Ng <khng@FreeBSD.org>
> CommitDate: 2023-07-01 22:58:46 +0000
>
>=C2=A0 =C2=A0 =C2=A0modules: bzero the modspecific_t
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0Per https://reviews.llvm.org/D68115, only= the first field is
>=C2=A0 =C2=A0 =C2=A0zero-initialized, meanwhile other fields are undef.=
This is not true.

>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0The pattern can be observed on clang as well, that = when
>=C2=A0 =C2=A0 =C2=A0-ftrivial-auto-var-init=3Dpattern is specified 0xaa= is filled for
>=C2=A0 =C2=A0 =C2=A0non-active fields, otherwise they are zero-initiali= zed.
What are non-active fields?
All fields with implicit initializers
"shall be initialized implicitly the same as
objects that have static storage duration."

I do not think this is required for padding.
In that c= ase, modspecific_t ms did become 0xaaaaaaaa00000000 on amd64 if -ftrivial-a= uto-var-init=3Dpattern was specified.
=C2=A0

>=C2=A0 =C2=A0 =C2=A0Technically both are acceptable when using clang. H= owever it
>=C2=A0 =C2=A0 =C2=A0would be good to simply bzero the modspecific_t in = such case to
>=C2=A0 =C2=A0 =C2=A0be strict to the standard.
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0MFC with:=C2=A0 =C2=A0 =C2=A0 =C2=A02cab2d43b83b >=C2=A0 =C2=A0 =C2=A0MFC after:=C2=A0 =C2=A0 =C2=A0 1 day
Min MFC period is 3 days.

>=C2=A0 =C2=A0 =C2=A0Sponsored by:=C2=A0 =C2=A0Juniper Networks, Inc. >=C2=A0 =C2=A0 =C2=A0Reviewed by:=C2=A0 =C2=A0 delphij
>=C2=A0 =C2=A0 =C2=A0Differential Revision:=C2=A0 https://revie= ws.freebsd.org/D40830
> ---
>=C2=A0 sys/kern/kern_syscalls.c | 3 ++-
>=C2=A0 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/sys/kern/kern_syscalls.c b/sys/kern/kern_syscalls.c
> index 234e51cfd280..0b51edf5e985 100644
> --- a/sys/kern/kern_syscalls.c
> +++ b/sys/kern/kern_syscalls.c
> @@ -173,9 +173,10 @@ kern_syscall_module_handler(struct sysent *sysent= s, struct module *mod,
>=C2=A0 =C2=A0 =C2=A0 int what, void *arg)
>=C2=A0 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0struct syscall_module_data *data =3D arg; > -=C2=A0 =C2=A0 =C2=A0modspecific_t ms =3D { 0 };
> +=C2=A0 =C2=A0 =C2=A0modspecific_t ms;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0int error;
>=C2=A0
> +=C2=A0 =C2=A0 =C2=A0bzero(&ms, sizeof(ms));
>=C2=A0 =C2=A0 =C2=A0 =C2=A0switch (what) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0case MOD_LOAD:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0error =3D kern_s= yscall_register(sysents, data->offset,

K= a Ho
Since I missed the reply-all button= just now, I resend this=C2=A0email.

Reading on N2= 716 one of the footnote stated:
"Note that aggregate type does not = include union type because an object with union type can only contain one m= ember at a time"

And below at 6.7.9.21 only aggregat= e was mentioned but not union, which matched what I observed with an `cc -f= trivial-auto-var-init=3Dpattern` invocation.

Ka Ho= =C2=A0
--0000000000000c84c705ff7e6065--