Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Abhishek Bapat" <abhishekbapat@google.com>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Hao Ge" <hao.ge@linux.dev>,
	"Andrew Morton" <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/4] alloc_tag: Extend allocinfo_filter to support tracing queries
Date: Tue, 20 Oct 2026 20:00:58 +0000	[thread overview]
Message-ID: <sashiko-outbox-179524@kernel.org> (raw)
In-Reply-To: <9e49a8f68e4e7d25c5a9a73c1926f68e468ef320.1792439751.git.abhishekbapat@google.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] alloc_tag: UAPI ABI break in allocinfo_ioctl() from growing allocinfo_filter
--

commit 93a7b2baed26770ea553f10bf7e51ee61056c1ff
Author: Abhishek Bapat <abhishekbapat@google.com>

alloc_tag: Extend allocinfo_filter to support tracing queries

This commit extends the /proc/allocinfo ioctl interface to report whether a
codetag has tracing enabled and to filter tags based on their trace state.

> diff --git a/include/uapi/linux/alloc_tag.h b/include/uapi/linux/alloc_tag.h
> index dafcba2f7e2c1..a96054ac22376 100644
> --- a/include/uapi/linux/alloc_tag.h
> +++ b/include/uapi/linux/alloc_tag.h
> @@ -38,7 +38,8 @@ struct allocinfo_counter {
>  	__u64 bytes;
>  	__u64 calls;
>  	__u8 accurate;
> -	__u8 pad[7];
> +	__u8 trace_on;
> +	__u8 pad[6];
>  } __attribute__((aligned(8)));
>  
>  struct allocinfo_tag_data {
> @@ -54,7 +55,8 @@ enum {
>  	ALLOCINFO_FILTER_INACCURATE,
>  	ALLOCINFO_FILTER_MIN_SIZE,
>  	ALLOCINFO_FILTER_MAX_SIZE,
> -	__ALLOCINFO_FILTER_LAST = ALLOCINFO_FILTER_MAX_SIZE
> +	ALLOCINFO_FILTER_TRACE_ON,
> +	__ALLOCINFO_FILTER_LAST = ALLOCINFO_FILTER_TRACE_ON
>  };
>  
>  #define ALLOCINFO_FILTER_MASK_MODNAME		(1 << ALLOCINFO_FILTER_MODNAME)
> @@ -64,6 +66,7 @@ enum {
>  #define ALLOCINFO_FILTER_MASK_INACCURATE	(1 << ALLOCINFO_FILTER_INACCURATE)
>  #define ALLOCINFO_FILTER_MASK_MIN_SIZE		(1 << ALLOCINFO_FILTER_MIN_SIZE)
>  #define ALLOCINFO_FILTER_MASK_MAX_SIZE		(1 << ALLOCINFO_FILTER_MAX_SIZE)
> +#define ALLOCINFO_FILTER_MASK_TRACE_ON		(1 << ALLOCINFO_FILTER_TRACE_ON)
>  
>  #define ALLOCINFO_FILTER_MASKS \
>  	((1 << (__ALLOCINFO_FILTER_LAST + 1)) - 1)
> @@ -75,6 +78,7 @@ struct allocinfo_filter {
>  	__u64 max_size;
>  	/* filter criteria only; see allocinfo_counter.accurate for actual accuracy */
>  	__u64 inaccurate;
> +	__u64 tracing;
>  };
>  
>  struct allocinfo_get_at {

[Severity: High]
Does appending tracing to struct allocinfo_filter break the UAPI ABI for
ALLOCINFO_IOC_GET_AT?

struct allocinfo_filter and struct allocinfo_get_at were introduced in commit
1d581ab2348c ("alloc_tag: add ioctl to /proc/allocinfo"), commit 5732a4e4c18a
("alloc_tag: add ioctl filters to /proc/allocinfo"), commit 6f6769ea88f8
("alloc_tag: add size based filtering to ioctl"), and commit 33588e0b81df
("alloc_tag: add accuracy based filtering to ioctl").

Unlike struct allocinfo_counter, where trace_on consumes a byte of pad[] to
keep the structure size unchanged, struct allocinfo_filter has no reserved
padding. Appending __u64 tracing increases sizeof(struct allocinfo_filter)
from 232 to 240 bytes.

Because struct allocinfo_get_at embeds struct allocinfo_filter by value before
the output field data:

include/uapi/linux/alloc_tag.h:
    struct allocinfo_get_at {
            /* inputs */
            __u64 pos;
            struct allocinfo_filter filter;
            /* output */
            struct allocinfo_tag_data data;
    };
    ...
    #define ALLOCINFO_IOC_GET_AT _IOWR(ALLOCINFO_IOC_BASE, _ALLOCINFO_IOC_GET_AT, \
                                       struct allocinfo_get_at)

growing struct allocinfo_filter shifts the offset of data by 8 bytes,
increases sizeof(struct allocinfo_get_at) from 464 to 472 bytes, and changes
the size encoded into ALLOCINFO_IOC_GET_AT (as well as struct
allocinfo_toggle_traces and ALLOCINFO_IOC_TOGGLE_TRACE).

In mm/alloc_tag.c, allocinfo_ioctl() -> allocinfo_ioctl_get_at() only matches
the new ALLOCINFO_IOC_GET_AT command value and copies sizeof(params):

mm/alloc_tag.c:allocinfo_ioctl() {
    ...
    switch (cmd) {
    ...
    case ALLOCINFO_IOC_GET_AT:
            ret = allocinfo_ioctl_get_at(file->private_data, arg);
            break;
    ...
    default:
            ret = -ENOIOCTLCMD;
            break;
    }
}

mm/alloc_tag.c:allocinfo_ioctl_get_at() {
    ...
    if (copy_from_user(&params, arg, sizeof(params)))
            return -EFAULT;
    ...
}

When existing userspace binaries built against the previous UAPI header invoke
ioctl(fd, ALLOCINFO_IOC_GET_AT, &arg) on /proc/allocinfo, won't
allocinfo_ioctl() fail to match cmd and return -ENOIOCTLCMD (-ENOTTY)?

Since matches_filter() only evaluates filter->inaccurate as a boolean via
!!(filter->inaccurate), could the boolean filter criteria be encoded without
growing struct allocinfo_filter, or could allocinfo_ioctl() handle the legacy
command size so existing binaries continue to work?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1792439751.git.abhishekbapat@google.com?part=3


  reply	other threads:[~2026-10-20 20:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 20:00 [PATCH v3 0/4] alloc_tag: Introduce selective tracing for MAP Abhishek Bapat
2026-10-19 20:00 ` [PATCH v3 1/4] alloc_tag: Add trace events for tracing allocations Abhishek Bapat
2026-10-21  7:36   ` Hao Ge
2026-10-19 20:00 ` [PATCH v3 2/4] alloc_tag: Introduce IOCTLs to toggle allocation tracepoints Abhishek Bapat
2026-10-21  7:37   ` Hao Ge
2026-10-19 20:00 ` [PATCH v3 3/4] alloc_tag: Extend allocinfo_filter to support tracing queries Abhishek Bapat
2026-10-20 20:00   ` sashiko-bot [this message]
2026-10-21  7:44   ` Hao Ge
2026-10-19 20:00 ` [PATCH v3 4/4] alloc_tag: Add a test for trace state toggle and filtering Abhishek Bapat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-179524@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=abhishekbapat@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=hao.ge@linux.dev \
    --cc=linux-mm@kvack.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=surenb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox