May 2025 - Linux-stable-mirror

[PATCH v1 RESEND stable tags] nvmem: layouts: u-boot-env: remove crc32 endianness conversion

by Michael C. Pratt

On 11 Oct 2022, it was reported that the crc32 verification of the u-boot environment failed only on big-endian systems for the u-boot-env nvmem layout driver with the following error. Invalid calculated CRC32: 0x88cd6f09 (expected: 0x096fcd88) This problem has been present since the driver was introduced, and before it was made into a layout driver. The suggested fix at the time was to use further endianness conversion macros in order to have both the stored and calculated crc32 values to compare always represented in the system's endianness. This was not accepted due to sparse warnings and some disagreement on how to handle the situation. Later on in a newer revision of the patch, it was proposed to use cpu_to_le32() for both values to compare instead of le32_to_cpu() and store the values as __le32 type to remove compilation errors. The necessity of this is based on the assumption that the use of crc32() requires endianness conversion because the algorithm uses little-endian, however, this does not prove to be the case and the issue is unrelated. Upon inspecting the current kernel code, there already is an existing use of le32_to_cpu() in this driver, which suggests there already is special handling for big-endian systems, however, it is big-endian systems that have the problem. This, being the only functional difference between architectures in the driver combined with the fact that the suggested fix was to use the exact same endianness conversion for the values brings up the possibility that it was not necessary to begin with, as the same endianness conversion for two values expected to be the same is expected to be equivalent to no conversion at all. After inspecting the u-boot environment of devices of both endianness and trying to remove the existing endianness conversion, the problem is resolved in an equivalent way as the other suggested fixes. Ultimately, it seems that u-boot is agnostic to endianness at least for the purpose of environment variables. In other words, u-boot reads and writes the stored crc32 value with the same endianness that the crc32 value is calculated with in whichever endianness a certain architecture runs on. Therefore, the u-boot-env driver does not need to convert endianness. Remove the usage of endianness macros in the u-boot-env driver, and change the type of local variables to maintain the same return type. If there is a special situation in the case of endianness, it would be a corner case and should be handled by a unique "compatible". Even though it is not necessary to use endianness conversion macros here, it may be useful to use them in the future for consistent error printing. Fixes: d5542923f200 ("nvmem: add driver handling U-Boot environment variables") Reported-by: INAGAKI Hiroshi <musashino.open(a)gmail.com> Link: https://lore.kernel.org/all/20221011024928.1807-1-musashino.open@gmail.com Cc: <stable(a)vger.kernel.org> # 6.12.x Cc: <stable(a)vger.kernel.org> # 6.6.x: f4cf4e5: Revert "nvmem: add new config option" Cc: <stable(a)vger.kernel.org> # 6.6.x: 7f38b70: of: device: Export of_device_make_bus_id() Cc: <stable(a)vger.kernel.org> # 6.6.x: 4a1a402: nvmem: Move of_nvmem_layout_get_container() in another header Cc: <stable(a)vger.kernel.org> # 6.6.x: fc29fd8: nvmem: core: Rework layouts to become regular devices Cc: <stable(a)vger.kernel.org> # 6.6.x: 0331c61: nvmem: core: Expose cells through sysfs Cc: <stable(a)vger.kernel.org> # 6.6.x: 401df0d: nvmem: layouts: refactor .add_cells() callback arguments Cc: <stable(a)vger.kernel.org> # 6.6.x: 6d0ca4a: nvmem: layouts: store owner from modules with nvmem_layout_driver_register() Cc: <stable(a)vger.kernel.org> # 6.6.x: 5f15811: nvmem: layouts: add U-Boot env layout Cc: <stable(a)vger.kernel.org> # 6.6.x Signed-off-by: Michael C. Pratt <mcpratt(a)pm.me> --- drivers/nvmem/layouts/u-boot-env.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/nvmem/layouts/u-boot-env.c b/drivers/nvmem/layouts/u-boot-env.c index 731e6f4f12b2..21f6dcf905dd 100644 --- a/drivers/nvmem/layouts/u-boot-env.c +++ b/drivers/nvmem/layouts/u-boot-env.c @@ -92,7 +92,7 @@ int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem, size_t crc32_data_offset; size_t crc32_data_len; size_t crc32_offset; - __le32 *crc32_addr; + uint32_t *crc32_addr; size_t data_offset; size_t data_len; size_t dev_size; @@ -143,8 +143,8 @@ int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem, goto err_kfree; } - crc32_addr = (__le32 *)(buf + crc32_offset); - crc32 = le32_to_cpu(*crc32_addr); + crc32_addr = (uint32_t *)(buf + crc32_offset); + crc32 = *crc32_addr; crc32_data_len = dev_size - crc32_data_offset; data_len = dev_size - data_offset; base-commit: 38fec10eb60d687e30c8c6b5420d86e8149f7557 -- 2.30.2

1 week, 1 day

1
0
0 0

[PATCH v2 net 0/1] e1000e: fix heap overflow in e1000_set_eeprom()

by Mikael Wessel

v2: patch the correct write helper and add bounds-checking; v1 mistakenly guarded e1000_get_eeprom() (read path). --- Mikael Wessel (1): e1000e: fix heap overflow in e1000_set_eeprom() drivers/net/ethernet/intel/e1000e/ethtool.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.48.1

1 week, 2 days

4
5
0 0

Series for -Wunterminated-string-initialization in 6.14 and 6.12

by Nathan Chancellor

Hi Greg and Sasha, Please find attatched backports for 6.14 and 6.12 (which have -Wextra enabled by default) to turn off a new warning from -Wextra in GCC 15 and Clang 21, -Wunterminated-string-initialization, which is fatal when CONFIG_WERROR is enabled. Please let me know if there are any issues or questions. Cheers, Nathan

1 week, 2 days

2
1
0 0

[SRU] [Noble] [PATCH 1/1] net: usb: usbnet: restore usb%d name exception for local mac addresses

by Jianlin Lv

From: Dominique Martinet <dominique.martinet(a)atmark-techno.com> BugLink: https://bugs.launchpad.net/bugs/2111592 commit 8a7d12d674ac ("net: usb: usbnet: fix name regression") assumed that local addresses always came from the kernel, but some devices hand out local mac addresses so we ended up with point-to-point devices with a mac set by the driver, renaming to eth%d when they used to be named usb%d. Userspace should not rely on device name, but for the sake of stability restore the local mac address check portion of the naming exception: point to point devices which either have no mac set by the driver or have a local mac handed out by the driver will keep the usb%d name. (some USB LTE modems are known to hand out a stable mac from the locally administered range; that mac appears to be random (different for mulitple devices) and can be reset with device-specific commands, so while such devices would benefit from getting a OUI reserved, we have to deal with these and might as well preserve the existing behavior to avoid breaking fragile openwrt configurations and such on upgrade.) Link: https://lkml.kernel.org/r/20241203130457.904325-1-asmadeus@codewreck.org Fixes: 8a7d12d674ac ("net: usb: usbnet: fix name regression") Cc: stable(a)vger.kernel.org Tested-by: Ahmed Naseef <naseefkm(a)gmail.com> Signed-off-by: Dominique Martinet <dominique.martinet(a)atmark-techno.com> Acked-by: Oliver Neukum <oneukum(a)suse.com> Link: https://patch.msgid.link/20250326-usbnet_rename-v2-1-57eb21fcff26@atmark-te… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> (cherry picked from commit 2ea396448f26d0d7d66224cb56500a6789c7ed07) Signed-off-by: Jianlin Lv <iecedge(a)gmail.com> --- drivers/net/usb/usbnet.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c index 9f66c47dc58b..08cbc8e4b361 100644 --- a/drivers/net/usb/usbnet.c +++ b/drivers/net/usb/usbnet.c @@ -178,6 +178,17 @@ int usbnet_get_ethernet_addr(struct usbnet *dev, int iMACAddress) } EXPORT_SYMBOL_GPL(usbnet_get_ethernet_addr); +static bool usbnet_needs_usb_name_format(struct usbnet *dev, struct net_device *net) +{ + /* Point to point devices which don't have a real MAC address + * (or report a fake local one) have historically used the usb%d + * naming. Preserve this.. + */ + return (dev->driver_info->flags & FLAG_POINTTOPOINT) != 0 && + (is_zero_ether_addr(net->dev_addr) || + is_local_ether_addr(net->dev_addr)); +} + static void intr_complete (struct urb *urb) { struct usbnet *dev = urb->context; @@ -1766,13 +1777,11 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod) if (status < 0) goto out1; - // heuristic: "usb%d" for links we know are two-host, - // else "eth%d" when there's reasonable doubt. userspace - // can rename the link if it knows better. + /* heuristic: rename to "eth%d" if we are not sure this link + * is two-host (these links keep "usb%d") + */ if ((dev->driver_info->flags & FLAG_ETHER) != 0 && - ((dev->driver_info->flags & FLAG_POINTTOPOINT) == 0 || - /* somebody touched it*/ - !is_zero_ether_addr(net->dev_addr))) + !usbnet_needs_usb_name_format(dev, net)) strscpy(net->name, "eth%d", sizeof(net->name)); /* WLAN devices should always be named "wlan%d" */ if ((dev->driver_info->flags & FLAG_WLAN) != 0) -- 2.34.1

1 week, 2 days

2
1
0 0

Re: Patch "btrfs: properly limit inline data extent according to block size" has been added to the 6.12-stable tree

by Qu Wenruo

在 2025/5/23 07:31, Sasha Levin 写道: > This is a note to let you know that I've just added the patch titled > > btrfs: properly limit inline data extent according to block size > > to the 6.12-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > btrfs-properly-limit-inline-data-extent-according-to.patch > and it can be found in the queue-6.12 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. Please drop this patch from all stable trees. This is only for a debug feature, 2K block size, and it will never be exposed to end users (only to allow people without a 64K page sized system to test subpage routine on x86_64). Thanks, Qu > > > > commit a5afc96d757771c992eb3af4629a562ec52ba1dc > Author: Qu Wenruo <wqu(a)suse.com> > Date: Tue Feb 25 14:30:44 2025 +1030 > > btrfs: properly limit inline data extent according to block size > > [ Upstream commit 23019d3e6617a8ec99a8d2f5947aa3dd8a74a1b8 ] > > Btrfs utilizes inline data extent for the following cases: > > - Regular small files > - Symlinks > > And "btrfs check" detects any file extents that are too large as an > error. > > It's not a problem for 4K block size, but for the incoming smaller > block sizes (2K), it can cause problems due to bad limits: > > - Non-compressed inline data extents > We do not allow a non-compressed inline data extent to be as large as > block size. > > - Symlinks > Currently the only real limit on symlinks are 4K, which can be larger > than 2K block size. > > These will result btrfs-check to report too large file extents. > > Fix it by adding proper size checks for the above cases. > > Signed-off-by: Qu Wenruo <wqu(a)suse.com> > Reviewed-by: David Sterba <dsterba(a)suse.com> > Signed-off-by: David Sterba <dsterba(a)suse.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c > index 9ce1270addb04..0da2611fb9c85 100644 > --- a/fs/btrfs/inode.c > +++ b/fs/btrfs/inode.c > @@ -623,6 +623,10 @@ static bool can_cow_file_range_inline(struct btrfs_inode *inode, > if (size > fs_info->sectorsize) > return false; > > + /* We do not allow a non-compressed extent to be as large as block size. */ > + if (data_len >= fs_info->sectorsize) > + return false; > + > /* We cannot exceed the maximum inline data size. */ > if (data_len > BTRFS_MAX_INLINE_DATA_SIZE(fs_info)) > return false; > @@ -8691,7 +8695,12 @@ static int btrfs_symlink(struct mnt_idmap *idmap, struct inode *dir, > struct extent_buffer *leaf; > > name_len = strlen(symname); > - if (name_len > BTRFS_MAX_INLINE_DATA_SIZE(fs_info)) > + /* > + * Symlinks utilize uncompressed inline extent data, which should not > + * reach block size. > + */ > + if (name_len > BTRFS_MAX_INLINE_DATA_SIZE(fs_info) || > + name_len >= fs_info->sectorsize) > return -ENAMETOOLONG; > > inode = new_inode(dir->i_sb);

1 week, 2 days

2
1
0 0

Re: Patch "btrfs: zoned: exit btrfs_can_activate_zone if BTRFS_FS_NEED_ZONE_FINISH is set" has been added to the 6.14-stable tree

by Johannes Thumshirn

On 22.05.25 23:06, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > btrfs: zoned: exit btrfs_can_activate_zone if BTRFS_FS_NEED_ZONE_FINISH is set > > to the 6.14-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > btrfs-zoned-exit-btrfs_can_activate_zone-if-btrfs_fs.patch > and it can be found in the queue-6.14 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > Hey Sasha, this patch is just a readability cleanup, no reason to backport it. Thanks, Johannes > > > commit 1136d333d91088ecf2d5189367540a84e60449a0 > Author: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> > Date: Wed Feb 12 15:05:00 2025 +0100 > > btrfs: zoned: exit btrfs_can_activate_zone if BTRFS_FS_NEED_ZONE_FINISH is set > > [ Upstream commit 26b38e28162ef4ceb1e0482299820fbbd7dbcd92 ] > > If BTRFS_FS_NEED_ZONE_FINISH is already set for the whole filesystem, exit > early in btrfs_can_activate_zone(). There's no need to check if > BTRFS_FS_NEED_ZONE_FINISH needs to be set if it is already set. > > Reviewed-by: Naohiro Aota <naohiro.aota(a)wdc.com> > Signed-off-by: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> > Reviewed-by: David Sterba <dsterba(a)suse.com> > Signed-off-by: David Sterba <dsterba(a)suse.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c > index f39656668967c..4a3e02b49f295 100644 > --- a/fs/btrfs/zoned.c > +++ b/fs/btrfs/zoned.c > @@ -2344,6 +2344,9 @@ bool btrfs_can_activate_zone(struct btrfs_fs_devices *fs_devices, u64 flags) > if (!btrfs_is_zoned(fs_info)) > return true; > > + if (test_bit(BTRFS_FS_NEED_ZONE_FINISH, &fs_info->flags)) > + return false; > + > /* Check if there is a device with active zones left */ > mutex_lock(&fs_info->chunk_mutex); > spin_lock(&fs_info->zone_active_bgs_lock); >

1 week, 2 days

2
1
0 0

[SRU] [Noble] [PATCH 1/1] net: usb: usbnet: restore usb%d name exception for local mac addresses

by Jianlin Lv

From: Dominique Martinet <dominique.martinet(a)atmark-techno.com> commit 8a7d12d674ac ("net: usb: usbnet: fix name regression") assumed that local addresses always came from the kernel, but some devices hand out local mac addresses so we ended up with point-to-point devices with a mac set by the driver, renaming to eth%d when they used to be named usb%d. Userspace should not rely on device name, but for the sake of stability restore the local mac address check portion of the naming exception: point to point devices which either have no mac set by the driver or have a local mac handed out by the driver will keep the usb%d name. (some USB LTE modems are known to hand out a stable mac from the locally administered range; that mac appears to be random (different for mulitple devices) and can be reset with device-specific commands, so while such devices would benefit from getting a OUI reserved, we have to deal with these and might as well preserve the existing behavior to avoid breaking fragile openwrt configurations and such on upgrade.) Link: https://lkml.kernel.org/r/20241203130457.904325-1-asmadeus@codewreck.org Fixes: 8a7d12d674ac ("net: usb: usbnet: fix name regression") Cc: stable(a)vger.kernel.org Tested-by: Ahmed Naseef <naseefkm(a)gmail.com> Signed-off-by: Dominique Martinet <dominique.martinet(a)atmark-techno.com> Acked-by: Oliver Neukum <oneukum(a)suse.com> Link: https://patch.msgid.link/20250326-usbnet_rename-v2-1-57eb21fcff26@atmark-te… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> (cherry picked from commit 2ea396448f26d0d7d66224cb56500a6789c7ed07) Signed-off-by: Jianlin Lv <iecedge(a)gmail.com> --- drivers/net/usb/usbnet.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c index 9f66c47dc58b..08cbc8e4b361 100644 --- a/drivers/net/usb/usbnet.c +++ b/drivers/net/usb/usbnet.c @@ -178,6 +178,17 @@ int usbnet_get_ethernet_addr(struct usbnet *dev, int iMACAddress) } EXPORT_SYMBOL_GPL(usbnet_get_ethernet_addr); +static bool usbnet_needs_usb_name_format(struct usbnet *dev, struct net_device *net) +{ + /* Point to point devices which don't have a real MAC address + * (or report a fake local one) have historically used the usb%d + * naming. Preserve this.. + */ + return (dev->driver_info->flags & FLAG_POINTTOPOINT) != 0 && + (is_zero_ether_addr(net->dev_addr) || + is_local_ether_addr(net->dev_addr)); +} + static void intr_complete (struct urb *urb) { struct usbnet *dev = urb->context; @@ -1766,13 +1777,11 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod) if (status < 0) goto out1; - // heuristic: "usb%d" for links we know are two-host, - // else "eth%d" when there's reasonable doubt. userspace - // can rename the link if it knows better. + /* heuristic: rename to "eth%d" if we are not sure this link + * is two-host (these links keep "usb%d") + */ if ((dev->driver_info->flags & FLAG_ETHER) != 0 && - ((dev->driver_info->flags & FLAG_POINTTOPOINT) == 0 || - /* somebody touched it*/ - !is_zero_ether_addr(net->dev_addr))) + !usbnet_needs_usb_name_format(dev, net)) strscpy(net->name, "eth%d", sizeof(net->name)); /* WLAN devices should always be named "wlan%d" */ if ((dev->driver_info->flags & FLAG_WLAN) != 0) -- 2.34.1

1 week, 2 days

2
1
0 0

About patch "remoteproc: qcom_wcnss: Handle platforms with only single power domain" in stable queue

by Matti Lehtimäki

Hi Patch "remoteproc: qcom_wcnss: Handle platforms with only single power domain" was added to stable queue for 6.14, 6.12, 6.6, 6.1 and 5.15 but the patch has an issue which was fixed in upstream commit 4ca45af0a56d00b86285d6fdd720dca3215059a7 (https://lore.kernel.org/linux-arm-msm/20250511234026.94735-1-matti.lehtimak…). Either the patch"remoteproc: qcom_wcnss: Handle platforms with only single power domain" should not be included in stable releases or the fix should be included as well. Adding "remoteproc: qcom_wcnss: Handle platforms with only single power domain" to stable releases is probably not really necessary anyway. Thanks, Matti

1 week, 2 days

2
1
0 0

Re: Patch "bpf: Prevent unsafe access to the sock fields in the BPF timestamping callback" has been added to the 6.1-stable tree

by Jason Xing

On Fri, May 23, 2025 at 7:17 AM Sasha Levin <sashal(a)kernel.org> wrote: > > This is a note to let you know that I've just added the patch titled > > bpf: Prevent unsafe access to the sock fields in the BPF timestamping callback > > to the 6.1-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > bpf-prevent-unsafe-access-to-the-sock-fields-in-the-.patch > and it can be found in the queue-6.1 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. Hi, I'm notified that this patch has been added into many branches, which is against my expectations. The BPF timestaping feature was implemented in 6.14 and the patch you are handling is just one of them. The function of this patch prevents unexpected bpf programs using this feature from triggering fatal problems. So, IMHO, we don't need this patch in all the older/stable branches:) Thanks, Jason > > > > commit 00b709040e0fdf5949dfbf02f38521e0b10943ac > Author: Jason Xing <kerneljasonxing(a)gmail.com> > Date: Thu Feb 20 15:29:31 2025 +0800 > > bpf: Prevent unsafe access to the sock fields in the BPF timestamping callback > > [ Upstream commit fd93eaffb3f977b23bc0a48d4c8616e654fcf133 ] > > The subsequent patch will implement BPF TX timestamping. It will > call the sockops BPF program without holding the sock lock. > > This breaks the current assumption that all sock ops programs will > hold the sock lock. The sock's fields of the uapi's bpf_sock_ops > requires this assumption. > > To address this, a new "u8 is_locked_tcp_sock;" field is added. This > patch sets it in the current sock_ops callbacks. The "is_fullsock" > test is then replaced by the "is_locked_tcp_sock" test during > sock_ops_convert_ctx_access(). > > The new TX timestamping callbacks added in the subsequent patch will > not have this set. This will prevent unsafe access from the new > timestamping callbacks. > > Potentially, we could allow read-only access. However, this would > require identifying which callback is read-safe-only and also requires > additional BPF instruction rewrites in the covert_ctx. Since the BPF > program can always read everything from a socket (e.g., by using > bpf_core_cast), this patch keeps it simple and disables all read > and write access to any socket fields through the bpf_sock_ops > UAPI from the new TX timestamping callback. > > Moreover, note that some of the fields in bpf_sock_ops are specific > to tcp_sock, and sock_ops currently only supports tcp_sock. In > the future, UDP timestamping will be added, which will also break > this assumption. The same idea used in this patch will be reused. > Considering that the current sock_ops only supports tcp_sock, the > variable is named is_locked_"tcp"_sock. > > Signed-off-by: Jason Xing <kerneljasonxing(a)gmail.com> > Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> > Link: https://patch.msgid.link/20250220072940.99994-4-kerneljasonxing@gmail.com > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/include/linux/filter.h b/include/linux/filter.h > index f3ef1a8965bb2..09cc8fb735f02 100644 > --- a/include/linux/filter.h > +++ b/include/linux/filter.h > @@ -1319,6 +1319,7 @@ struct bpf_sock_ops_kern { > void *skb_data_end; > u8 op; > u8 is_fullsock; > + u8 is_locked_tcp_sock; > u8 remaining_opt_len; > u64 temp; /* temp and everything after is not > * initialized to 0 before calling > diff --git a/include/net/tcp.h b/include/net/tcp.h > index 83e0362e3b721..63caa3181dfe6 100644 > --- a/include/net/tcp.h > +++ b/include/net/tcp.h > @@ -2409,6 +2409,7 @@ static inline int tcp_call_bpf(struct sock *sk, int op, u32 nargs, u32 *args) > memset(&sock_ops, 0, offsetof(struct bpf_sock_ops_kern, temp)); > if (sk_fullsock(sk)) { > sock_ops.is_fullsock = 1; > + sock_ops.is_locked_tcp_sock = 1; > sock_owned_by_me(sk); > } > > diff --git a/net/core/filter.c b/net/core/filter.c > index 497b41ac399da..5c9f3fcb957bb 100644 > --- a/net/core/filter.c > +++ b/net/core/filter.c > @@ -10240,10 +10240,10 @@ static u32 sock_ops_convert_ctx_access(enum bpf_access_type type, > } \ > *insn++ = BPF_LDX_MEM(BPF_FIELD_SIZEOF( \ > struct bpf_sock_ops_kern, \ > - is_fullsock), \ > + is_locked_tcp_sock), \ > fullsock_reg, si->src_reg, \ > offsetof(struct bpf_sock_ops_kern, \ > - is_fullsock)); \ > + is_locked_tcp_sock)); \ > *insn++ = BPF_JMP_IMM(BPF_JEQ, fullsock_reg, 0, jmp); \ > if (si->dst_reg == si->src_reg) \ > *insn++ = BPF_LDX_MEM(BPF_DW, reg, si->src_reg, \ > @@ -10328,10 +10328,10 @@ static u32 sock_ops_convert_ctx_access(enum bpf_access_type type, > temp)); \ > *insn++ = BPF_LDX_MEM(BPF_FIELD_SIZEOF( \ > struct bpf_sock_ops_kern, \ > - is_fullsock), \ > + is_locked_tcp_sock), \ > reg, si->dst_reg, \ > offsetof(struct bpf_sock_ops_kern, \ > - is_fullsock)); \ > + is_locked_tcp_sock)); \ > *insn++ = BPF_JMP_IMM(BPF_JEQ, reg, 0, 2); \ > *insn++ = BPF_LDX_MEM(BPF_FIELD_SIZEOF( \ > struct bpf_sock_ops_kern, sk),\ > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > index db1a99df29d55..16f4a41a068e4 100644 > --- a/net/ipv4/tcp_input.c > +++ b/net/ipv4/tcp_input.c > @@ -168,6 +168,7 @@ static void bpf_skops_parse_hdr(struct sock *sk, struct sk_buff *skb) > memset(&sock_ops, 0, offsetof(struct bpf_sock_ops_kern, temp)); > sock_ops.op = BPF_SOCK_OPS_PARSE_HDR_OPT_CB; > sock_ops.is_fullsock = 1; > + sock_ops.is_locked_tcp_sock = 1; > sock_ops.sk = sk; > bpf_skops_init_skb(&sock_ops, skb, tcp_hdrlen(skb)); > > @@ -184,6 +185,7 @@ static void bpf_skops_established(struct sock *sk, int bpf_op, > memset(&sock_ops, 0, offsetof(struct bpf_sock_ops_kern, temp)); > sock_ops.op = bpf_op; > sock_ops.is_fullsock = 1; > + sock_ops.is_locked_tcp_sock = 1; > sock_ops.sk = sk; > /* sk with TCP_REPAIR_ON does not have skb in tcp_finish_connect */ > if (skb) > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c > index 40568365cdb3b..2f109f1968253 100644 > --- a/net/ipv4/tcp_output.c > +++ b/net/ipv4/tcp_output.c > @@ -509,6 +509,7 @@ static void bpf_skops_hdr_opt_len(struct sock *sk, struct sk_buff *skb, > sock_owned_by_me(sk); > > sock_ops.is_fullsock = 1; > + sock_ops.is_locked_tcp_sock = 1; > sock_ops.sk = sk; > } > > @@ -554,6 +555,7 @@ static void bpf_skops_write_hdr_opt(struct sock *sk, struct sk_buff *skb, > sock_owned_by_me(sk); > > sock_ops.is_fullsock = 1; > + sock_ops.is_locked_tcp_sock = 1; > sock_ops.sk = sk; > } >

1 week, 2 days

3
2
0 0

[ANNOUNCE] AUTOSEL: Modern AI-powered Linux Kernel Stable Backport Classifier

by Sasha Levin

Hello folks, I'm pleased to announce the release of AUTOSEL, a complete rewrite of the stable kernel patch selection tool that Julia Lawall and I presented back in 2018[1]. Unlike the previous version that relied on word statistics and older neural network techniques, AUTOSEL leverages modern large language models and embedding technology to provide significantly more accurate recommendations. ## What is AUTOSEL? AUTOSEL automatically analyzes Linux kernel commits to determine whether they should be backported to stable kernel trees. It examines commit messages, code changes, and historical backporting patterns to make intelligent recommendations. This is a complete rewrite of the original tool[1], with several major improvements: 1. Uses large language models (Claude, OpenAI, NVIDIA models) for semantic understanding 2. Implements embeddings-based similar commit retrieval for better context 3. Provides detailed explanations for each recommendation 4. Supports batch processing for efficient analysis of multiple commits ## Key Features - Support for multiple LLM providers (Claude, OpenAI, NVIDIA) - Self-contained embeddings using Candle - Optional CUDA acceleration for faster analysis - Detailed explanations of backporting decisions - Extensive test coverage and validation ## Getting Started ``` git clone https://git.sr.ht/~sashal/autosel cd autosel cargo build --release ``` To analyze a specific commit: ``` ./target/release/autosel --kernel-repo ~/linux --models claude --commit <SHA> ``` For more information, see the README.md file in the repository. [1] https://lwn.net/Articles/764647/ -- Thanks, Sasha

1 week, 2 days

2
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2025