From nobody Tue Oct 06 19:23:49 2026 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 4hzmQc2Dcfz6Z5Yq for ; Tue, 06 Oct 2026 19:24:08 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzmQZ4ZDjz4PKc for ; Tue, 06 Oct 2026 19:24:06 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20251104 header.b=DVMXzXRe; spf=pass (mx1.freebsd.org: domain of yaneurabeya@gmail.com designates 2607:f8b0:4864:20::1035 as permitted sender) smtp.mailfrom=yaneurabeya@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-3a4c47bb6e3so634001a91.1 for ; Tue, 06 Oct 2026 12:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791314644; x=1791919444; darn=freebsd.org; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type :message-id:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=GTUYSE9bWN6//R72JW8Zv/pSmvBwH25gMTtvtXe3fic=; b=DVMXzXRe/rRNO6ZvP7EoZ9Mg9fh1Ky6nHfyW3bKlJ5H48Jp1WJRBbF0E0wfNY/YiXW S4cbDFdgZjbY99bT4jC2RXc8uLRal23TrAbriwpV4W2MHDuvLzuNW9DwdL+FUUW0apPq xmRMgH4rqoLpIcgy6uHukRhzhwutzYBxX/TKfp5ndJffessovyl+/hME6DcJJ8zaeouP l/9SayDS4JJVlSv6ossvVageC8VJGldiDdPmX0vp99Yvub8BFJzRRy4KZY/Ln3eq4lFA yjI9yftsW6T60zRUUWWA17bfubctlBO3mHkFpCtHvR1VXwxI0M0QJgsNFRGYoaUCte5N GLtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791314644; x=1791919444; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type :message-id:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=GTUYSE9bWN6//R72JW8Zv/pSmvBwH25gMTtvtXe3fic=; b=XUN2D7dpalYigyZMeJuqh4ci6I1VnvBnJR++hDBDfu94lExm7CbHuTyEj5d5pL3T11 DoDU2smK7349jt+JXPGGnhSsyW+QFMIG+JyGmEDomdoUCP2Xb/GeBZhhaqGYqog/I9sF 2WNFeTBht0oB3uX2NNv5Ypl6l7tepUnR3Mo2JDQu5QCyEJx+e94266xW187m2GmExa/U 6y8heW6D8AyhDAAIryigvzlPfUNlmSWrK5FwJ7+9W6OsvK6e6yGalo/iBDFljYt5p/QF VtKE13+eOC5dxUzoRiCsL4m9qBzCkJlbSlQ4Oi+DRZVFzmQS1v/xh+NMLgJoQUORyctp HY/g== X-Forwarded-Encrypted: i=1; AKwUvBwGpcMe7WPuQtloC9AXc57urKO0Vop913zD/yCQfc4jNZMRFehq8Tm2o4JmPWmM9eQL63E425Ad88pV6RbGt6xeOUeUow==@freebsd.org X-Gm-Message-State: AFq9FYKkHH5XindqSMyyrNdXfNdxdVvrgULZivUrsbMZtcjWRUdcbUMh L0Nm618XZplFOePDoMfXOLMtNK0pbgwmiz/od/8Ind2I9+nYWN/C+vchu8XzXGqx X-Gm-Gg: AYBFou2D3O7DtsSWQFZ7/MHK5G55Us+z8Pd0x4Y3MAWhdVIO6nMxizUdo3Re487aHSY x0jfCs29NZIvRzZCZgab6YRwAH92q04S2V6qzQBOzoMkbLIFVuD0/CMdRy+KDIvim5sN+3yNwro FYsxJUUmZlChuqmMcVV4y5RmYL6BtpPMRZyMNoJZjYKGWkMXOe4djN7YtMnDJdl9DVmZCT29P/v y4N4hTfekLwSdbvGG3NlzPxnDIQcqLfH+qBEdbMm6h9jD4HBXDsQk+5JH9W+zXe73qB+qfmde7Y a7Y6k272KQmh61dnklHprqmx2DcD6irgGeU8jm5IkhtDrFWcT0t5Phwwgi080atHvqaWGusilA9 TAySLP31xUQ5rG8VXAK37iDaj6mBICi0C+PohDPX1HEpDHVE+tj1iTatrHih/mXj4odcV4gaJQO MgOXY3IizBbZmScoOM0fSvNEKFL1pZYk4Wt5KNUw+qU1QVu/F6cOW1jWGcmsZflzrjKMLJ5TAIW lSP/BQPAO4N9eXOqTTg X-Received: by 2002:a17:90b:3c50:b0:3a4:948d:9dc3 with SMTP id 98e67ed59e1d1-3a8a197fb81mr163481a91.21.1791314643804; Tue, 06 Oct 2026 12:24:03 -0700 (PDT) Received: from smtpclient.apple ([187.15.153.55]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3a85437f740sm6331732a91.11.2026.10.06.12.24.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2026 12:24:02 -0700 (PDT) From: "Enji Cooper (yaneurabeya)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_2124B0A8-1BBA-488D-AE58-D2ED1562C789"; protocol="application/pgp-signature"; micalg=pgp-sha256 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: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.700.51.1.3\)) Subject: Re: git: bb5f10e51bd5 - main - linux: implement sched_getattr() Date: Tue, 6 Oct 2026 12:23:49 -0700 In-Reply-To: <05459a0a-8b33-410b-a391-af94384e84b7@FreeBSD.org> Cc: Mark Johnston , Enji Cooper , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org To: John Baldwin References: <6ac42979.2608d.d368a5e@gitrepo.freebsd.org> <05459a0a-8b33-410b-a391-af94384e84b7@FreeBSD.org> X-Mailer: Apple Mail (2.3864.700.51.1.3) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.60 / 15.00]; SIGNED_PGP(-2.00)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20251104]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4864::/56:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1035:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[dev-commits-src-main@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4hzmQZ4ZDjz4PKc --Apple-Mail=_2124B0A8-1BBA-488D-AE58-D2ED1562C789 Content-Type: multipart/alternative; boundary="Apple-Mail=_26541C16-BA63-4085-B07D-38D4DFDDE099" --Apple-Mail=_26541C16-BA63-4085-B07D-38D4DFDDE099 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 6, 2026, at 11:36=E2=80=AFAM, John Baldwin = wrote: >=20 > On 10/6/26 10:42, Enji Cooper (yaneurabeya) wrote: >> ... >>>> + attr.size =3D MIN(args->size, sizeof(attr)); >> =E2=80=A6 >>>> + return (copyout(&attr, args->attr, args->size)); >>>=20 >>> So, this lets the caller decide how much stack data they want to = copy >>> out, independent of sizeof(attr). The only constraint is the >>> `args->size > PAGE_SIZE` check at the beginning of the function. >> I eliminated a duplicate calculation in the copyout which = contradicted the [Linux] documented interface [1]. >=20 > .. and introduced a kernel stack disclosure (the kind of thing we = normally > have to ship an SA for). Using attr.size for the length here is the > correct solution. Yeah. I figured out that I typoed `args->size` instead of `attr.size` in = this commit when I was rereading the Differential: = https://reviews.freebsd.org/D60214?id=3D188351#inline-356758 (it took me = longer to figure out what @markj was originally pointing out was wrong = in this change). FWIW, I agree that the unsanitized user-provided value = shouldn=E2=80=99t have been used. To protect against making that mistake in the future, I renamed = variables to hopefully make their use clearer and make the variables a = bit more unique. It helps me personally because my brain sometimes blurs = details when there are a lot of commonalities with words (both written = and phonetic). ... >> The interface documented by Linux allows the user to specify the = amount of data to copy out = (https://www.man7.org/linux/man-pages/man2/sched_getattr.2.html): >>> The fields of the sched_attr structure are as follows: >>>=20 >>> size This field should be set to the size of the structure in >> bytes, as in sizeof(struct sched_attr). If the provided >> structure is smaller than the kernel structure, any >> additional fields are assumed to be '0'. If the provided >> structure is larger than the kernel structure, the kernel >> verifies that all additional fields are 0; if they are not, >> sched_setattr() fails with the error E2BIG and updates size >> to contain the size of the kernel structure. >=20 > Right, so the extra bytes in the case that args->size is >> sizeof(attr) are supposed to be all zeroes already (and you > are supposed to check that in the syscall if you aren't already) > so you don't need to copy them back out again, only the > sizeof(attr) bytes including the updated size. >=20 > This is not all that weird, and is similar to how we handle > cpuset masks which also can be differently sized than the > kernel's representation. Ok. I guess my earlier statement demonstrates how little experience I = have in this area. Thank you, -Enji= --Apple-Mail=_26541C16-BA63-4085-B07D-38D4DFDDE099 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On= Oct 6, 2026, at 11:36=E2=80=AFAM, John Baldwin <jhb@FreeBSD.org> = wrote:

On 10/6/26 = 10:42, Enji Cooper (yaneurabeya) wrote:
...
+= attr.size =3D MIN(args->size, = sizeof(attr));
=E2=80=A6
+ return (copyout(&attr, = args->attr, args->size));

So, this lets the = caller decide how much stack data they want to copy
out, independent = of sizeof(attr).  The only constraint is the
`args->size > = PAGE_SIZE` check at the beginning of the function.
I = eliminated a duplicate calculation in the copyout which contradicted the = [Linux] documented interface [1].

.. and introduced = a kernel stack disclosure (the kind of thing we normally
have to ship = an SA for).  Using attr.size for the length here is the
correct = solution.

Yeah. I figured out = that I typoed `args->size` instead of `attr.size` in this commit when = I was rereading the Differential: http= s://reviews.freebsd.org/D60214?id=3D188351#inline-356758 (it = took me longer to figure out what @markj was originally pointing out was = wrong in this change). FWIW, I agree that the unsanitized user-provided = value shouldn=E2=80=99t have been used.

To = protect against making that mistake in the future, I renamed variables = to hopefully make their use clearer and make the variables a bit more = unique. It helps me personally because my brain sometimes blurs details = when there are a lot of commonalities with words (both written and = phonetic).

...

The interface = documented by Linux allows the user to specify the amount of data to = copy out = (https://www.man7.org/linux/man-pages/man2/sched_getattr.2.html):
 The fields of the sched_attr structure are = as follows:

size This field should be set to the size of the = structure in
bytes, as in sizeof(struct sched_attr). If = the provided
structure is smaller than the kernel structure, = any
additional fields are assumed to be '0'. If the = provided
structure is larger than the kernel structure, the = kernel
verifies that all additional fields are 0; if they are = not,
sched_setattr() fails with the error E2BIG and updates = size
to contain the size of the kernel = structure.

Right, so the extra bytes in the case = that args->size is
sizeof(attr) are = supposed to be all zeroes already (and you
are supposed = to check that in the syscall if you aren't already)
so you don't need = to copy them back out again, only the
sizeof(attr) bytes including = the updated size.

This is not all that weird, and is similar to = how we handle
cpuset masks which also can be differently sized than = the
kernel's = representation.

Ok. I guess = my earlier statement demonstrates how little experience I have in this = area.

Thank = you,
-Enji
= --Apple-Mail=_26541C16-BA63-4085-B07D-38D4DFDDE099-- --Apple-Mail=_2124B0A8-1BBA-488D-AE58-D2ED1562C789 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkHfexGRJ3gYRdA2gGpE5DjPsNJgFAmrFSsYACgkQGpE5DjPs NJiUFw//RV5dd9lBRCgH/MgVyY48IBwwSokDh010FfpKcJG7ANJX9aS9jwku/Nr0 I8IPKzstQCWLnbBZPXjsPUo6jjGMmur7zSyEyUKGp0YAQUskW+KNe1n25XH20FG4 699E5qw6t43fAj2XdZtYwqGLYNnurYszWWiFv51rhQTIAn02FOwnDUS92l2Yi+u5 9kjIuJMu2v0g1ycVKcqACWqblVUju1bInD0xBZ+/+MRBm7GRfHqUow/d+i6on1S+ k81U7vYGnJmQDYmlIqspmvo3FStLwAGGtjndZmjaWVuQYqVjQTg8EmxSSwqA/WQ9 waTtr57HkfxHiTEsdrZvegYtrnRfev9jF99ZF2uK/7zxEe7DnEvivb1d8AVEv3G4 1hFcyy4AblerfF9eQACy3pRFziQ64b3SJizT7yPBD4fKEbdu2qakd9ZPR5gdMr/C oQ8kQwfWxh+UQcnmfqfTUfjDztrGQgZF+9Z2umxuS8b9da6n8b7hc487SLEEQ8d+ huoIsvVtjZ5kgTbAJ1CRjV87FNKwZ9Kw4N3bKdqhzv3UXwFYNG0QHHF3uV9gnnYO ljgEsJijN+cSXJTItXZ7mbtDaTJ70ZMj/MSabFo1tIALBtxFvnT8tyQYslI+2otU HmwV4Es/Xo6k7Oi9y1q09lsDfVZwfc6F83SnWGdrO/gJjSDCpKE= =EFuA -----END PGP SIGNATURE----- --Apple-Mail=_2124B0A8-1BBA-488D-AE58-D2ED1562C789--