Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Critical] uapi: ALLOCINFO_IOC_GET_AT ioctl ABI breakage due to struct size increase --
commit e19f22c2c2fb6885ec1ef8ea1659cf1ff9f8e3ae Author: Abhishek Bapat <[email protected]> alloc_tag: extend allocinfo_filter to support tracing queries The commit extends the allocinfo filtering system to allow filtering by tracing state. It adds a trace_on property to struct allocinfo_counter and a tracing property to struct allocinfo_filter. > diff --git a/include/uapi/linux/alloc_tag.h b/include/uapi/linux/alloc_tag.h > index 069ab8341e87b..e65c32afceee2 100644 > --- a/include/uapi/linux/alloc_tag.h > +++ b/include/uapi/linux/alloc_tag.h [ ... ] > @@ -75,6 +78,7 @@ struct allocinfo_filter { > __u64 max_size; > /* filter criteria only; see allocinfo_counter.accurate for actual > accuracy */ > __u64 inaccurate; > + __u64 tracing; > }; [Severity: Critical] Does adding __u64 tracing here cause an ioctl ABI regression for existing userspace applications? Since struct allocinfo_filter is embedded in struct allocinfo_get_at, adding this field increases the size of struct allocinfo_get_at by 8 bytes. The ioctl command ALLOCINFO_IOC_GET_AT is defined using _IOWR() which incorporates the size of struct allocinfo_get_at into the command number: include/uapi/linux/alloc_tag.h: #define ALLOCINFO_IOC_GET_AT \ _IOWR(ALLOCINFO_IOC_BASE, _ALLOCINFO_IOC_GET_AT, struct allocinfo_get_at) When older userspace tools send the previous ioctl command number, will it fail to match the new ALLOCINFO_IOC_GET_AT value in the switch statement in allocinfo_ioctl(): 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; } } and cause requests to fall through to the default handler? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3
