From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1E6E935E1AA for ; Wed, 7 Oct 2026 22:51:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791413497; cv=none; b=ALNjz+1sposD8qcDcFZt513vbt+EDxNL7o6wbkkL8aXmeuRsTQ45px4NVxrgh+59eUO+xfwkYutt3r9EH1tc4r7lqbZc09P/+l6aFa7iXGgBO1UnH5RtHJ6Xqqg7XVyBGw5IL4z2C8rZx0qrT6dy2XZfR8zmHd4nvSBR4EAxn7U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791413497; c=relaxed/simple; bh=ousAeBFCpOZtzCQeMDR8GA45dLQ+aJvDrlx/7i6mUXQ=; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type: Date; b=dYDnos4aQDe0TK8JHXG5hTGLhJo/VFlvZE33O07nG1aLpXGk7vrX+wnIZTNTZtjBnEPIYTGEiUF/3Ra9npjOH/dRVL8Rmg6rwkkXQp69k6ctG+/5oweSXza6b7PIBRxO42GTehrXH++K/Twpx8qbLQPamB7Pexrj+ruXCiWqFY8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EuLonAZ+; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EuLonAZ+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 894591F000FF; Wed, 7 Oct 2026 22:51:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791413495; bh=yF2U3L/BAsM05ljO0gWo3v1ULNj99CxEV0YZFub4ZHk=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=EuLonAZ+FE4O4Kw7KjKraLJPbsGAtj6RHFl6JxQF9Vl6gg+ufHKrZqe5ahShlqcZU lqAmBrEglUI8udlaKjcbweOiLew4uFBTlerqmNakgJZ4pr5Z6MWPONG6++HcItNqn7 /pEDbPxl/TtLhQmu9VVqbnhTWI6jbD3zdq1l+XPRLIHx6HNE1iXi3IAekLtnpW1g/V 4IQ1+NRNVjBsf0gD2IPY4/u8JjUBDSQJyl+XOXvl6HSQ6iQLGnmUYrQ/Y4p6YaoXKV 9nSF5cPxLzyG2e+VC3GA/aKIWmpCkhg0nKKo9op+d5VZxVALnGeTa7o862iChunCiI 7zGWj0D2po3gQ== Message-ID: From: sashiko-bot@kernel.org Subject: Re: [PATCH v2 2/4] alloc_tag: Introduce IOCTLs to toggle allocation tracepoints Reply-To: sashiko-reviews@lists.linux.dev To: "Abhishek Bapat" Cc: linux-trace-kernel@vger.kernel.org In-Reply-To: <1f77364a04d0ae20cf07efaca779756f92ec39f6.1791410886.git.abhishekbapat@google.com> References: <1f77364a04d0ae20cf07efaca779756f92ec39f6.1791410886.git.abhishekbapat@google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 07 Oct 2026 22:51:35 +0000 Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [Medium] abi: UAPI struct layout mismatch for 32-bit compat userspace bre= aks IOCTLs -- commit 8d88f08e2268b0340428c21059f2534d77368ca5 Author: Abhishek Bapat alloc_tag: Introduce IOCTLs to toggle allocation tracepoints Introduce a new IOCTL (ALLOCINFO_IOC_TOGGLE_TRACE) to selectively toggle tracing on allocation call sites. Userspace tools can use the existing filtering mechanism to specify the set of tags to toggle tracing for. > diff --git a/include/uapi/linux/alloc_tag.h b/include/uapi/linux/alloc_ta= g.h > index 7d4618bea0434..dafcba2f7e2c1 100644 > --- a/include/uapi/linux/alloc_tag.h > +++ b/include/uapi/linux/alloc_tag.h > @@ -85,9 +85,20 @@ struct allocinfo_get_at { > struct allocinfo_tag_data data; > }; > =20 > +struct allocinfo_toggle_traces { > + /* inputs */ > + /* > + * Tags matching the filter are toggled; an empty mask selects all tags. > + * Size criteria are checked once, against the tag's size at call time. > + */ > + struct allocinfo_filter filter; [Severity: Medium] The new struct allocinfo_toggle_traces embeds struct allocinfo_filter. Does this struct layout introduce a UAPI mismatch regression for 32-bit com= pat userspace? The struct allocinfo_filter contains struct allocinfo_tag (196 bytes) directly followed by __u64 min_size: include/uapi/linux/alloc_tag.h: struct allocinfo_filter { __u64 mask; struct allocinfo_tag fields; __u64 min_size; ... }; On 32-bit architectures like i386, __u64 has a 4-byte alignment requirement, placing min_size at offset 204. On 64-bit architectures, __u64 has an 8-byte alignment requirement, inserting 4 bytes of padding and placing min_size at offset 208. Because of this size disparity (236 bytes vs 240 bytes for struct allocinfo_toggle_traces), the IOCTL command number generated by _IOW() in userspace will differ between 32-bit and 64-bit builds. Since the pre-existing allocinfo_compat_ioctl() directly passes the 32-bit IOCTL command number to the native allocinfo_ioctl() switch statement without translation: mm/alloc_tag.c:allocinfo_compat_ioctl() { return allocinfo_ioctl(file, cmd, (unsigned long)compat_ptr(arg)); } Won't the new ALLOCINFO_IOC_TOGGLE_TRACE command fall through to default in allocinfo_ioctl() and return -ENOIOCTLCMD, breaking the feature for 32-bit userspace tools on 64-bit kernels? > + __u64 enable; > +}; > + --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/cover.1791410885.gi= t.abhishekbapat@google.com?part=3D2