January 2025 - Linux-stable-mirror

[PATCH] arm64: dts: rockchip: Fix broken tsadc pinctrl binding for rk3588

by Alexander Shiyan

There is no pinctrl "gpio" and "otpout" (probably designed as "output") handling in the tsadc driver. Let's use proper binding "default" and "sleep". Fixes: 32641b8ab1a5 ("arm64: dts: rockchip: add rk3588 thermal sensor") Cc: stable(a)vger.kernel.org Signed-off-by: Alexander Shiyan <eagle.alexander923(a)gmail.com> --- arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi index a337f3fb8377..f141065eb69d 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi @@ -2667,9 +2667,9 @@ tsadc: tsadc@fec00000 { rockchip,hw-tshut-temp = <120000>; rockchip,hw-tshut-mode = <0>; /* tshut mode 0:CRU 1:GPIO */ rockchip,hw-tshut-polarity = <0>; /* tshut polarity 0:LOW 1:HIGH */ - pinctrl-0 = <&tsadc_gpio_func>; - pinctrl-1 = <&tsadc_shut>; - pinctrl-names = "gpio", "otpout"; + pinctrl-0 = <&tsadc_shut>; + pinctrl-1 = <&tsadc_gpio_func>; + pinctrl-names = "default", "sleep"; #thermal-sensor-cells = <1>; status = "disabled"; }; -- 2.39.1

2 days, 9 hours

4
23
0 0

S/PDIF not detected anymore / regression on recent kernel 6.7 ?

by Serge SIMON

Dear Kernel maintainers, I think i'm encountering (for the first time in years !) a regression with the "6.7.arch3-1" kernel (whereas no issues with "6.6.10.arch1-1", on which i reverted). I'm running a (up-to-date, and non-LTS) ARCHLINUX desktop, on a ASUS B560-I motherboard, with 3 monitors (attached to a 4-HDMI outputs card), plus an audio S/PDIF optic output at motherboard level. With the latest kernel, the S/PIDF optic output of the motherboard is NOT detected anymore (and i haven't been able to see / find anything in the logs at quick glance, neither journalctl -xe nor dmesg). Once reverted to 6.6.10, everything is fine again. For example, in a working situation (6.6.10), i have : cat /proc/asound/pcm 00-00: ALC1220 Analog : ALC1220 Analog : playback 1 : capture 1 00-01: ALC1220 Digital : ALC1220 Digital : playback 1 00-02: ALC1220 Alt Analog : ALC1220 Alt Analog : capture 1 01-03: HDMI 0 : HDMI 0 : playback 1 01-07: HDMI 1 : HDMI 1 : playback 1 01-08: HDMI 2 : HDMI 2 : playback 1 01-09: HDMI 3 : HDMI 3 : playback 1 Whereas while on the latest 6.7 kernel, i only had the 4 HDMI lines (linked to a NVIDIA T600 card, with 4 HDMI outputs) and not the three first ones (attached to the motherboard). (of course i did several tests with 6.7, reboot, ... without any changes) Any idea ? Best regards -- Serge.

4 days, 8 hours

4
7
0 0

[PATCH v2] ARM: dts: socfpga: sodia: Fix mdio bus probe and PHY address

by Nobuhiro Iwamatsu

On SoCFPGA/Sodia board, mdio bus cannot be probed, so the PHY cannot be found and the network device does not work. ``` stmmaceth ff702000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19) ``` To probe the mdio bus, add "snps,dwmac-mdio" as compatible string of the mdio bus. Also the PHY address connected to this board is 4. Therefore, change to 4. Cc: stable(a)vger.kernel.org # 6.3+ Signed-off-by: Nobuhiro Iwamatsu <iwamatsu(a)nigauri.org> --- v2: Update commit message from 'ID' to 'address'. Drop Fixes tag, because that commit is not the cause. arch/arm/boot/dts/intel/socfpga/socfpga_cyclone5_sodia.dts | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/intel/socfpga/socfpga_cyclone5_sodia.dts b/arch/arm/boot/dts/intel/socfpga/socfpga_cyclone5_sodia.dts index ce0d6514eeb571..e4794ccb8e413f 100644 --- a/arch/arm/boot/dts/intel/socfpga/socfpga_cyclone5_sodia.dts +++ b/arch/arm/boot/dts/intel/socfpga/socfpga_cyclone5_sodia.dts @@ -66,8 +66,10 @@ &gmac1 { mdio0 { #address-cells = <1>; #size-cells = <0>; - phy0: ethernet-phy@0 { - reg = <0>; + compatible = "snps,dwmac-mdio"; + + phy0: ethernet-phy@4 { + reg = <4>; rxd0-skew-ps = <0>; rxd1-skew-ps = <0>; rxd2-skew-ps = <0>; -- 2.45.2

1 month

2
3
0 0

FAILED: patch "[PATCH] fs: relax assertions on failure to encode file handles" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 974e3fe0ac61de85015bbe5a4990cf4127b304b2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025011112-racing-handbrake-a317@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 974e3fe0ac61de85015bbe5a4990cf4127b304b2 Mon Sep 17 00:00:00 2001 From: Amir Goldstein <amir73il(a)gmail.com> Date: Thu, 19 Dec 2024 12:53:01 +0100 Subject: [PATCH] fs: relax assertions on failure to encode file handles Encoding file handles is usually performed by a filesystem >encode_fh() method that may fail for various reasons. The legacy users of exportfs_encode_fh(), namely, nfsd and name_to_handle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle. There are a few other users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when ->encode_fh() fails. Relax those assertions because they are wrong. The second linked bug report states commit 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles") in v6.6 as the regressing commit, but this is not accurate. The aforementioned commit only increases the chances of the assertion and allows triggering the assertion with the reproducer using overlayfs, inotify and drop_caches. Triggering this assertion was always possible with other filesystems and other reasons of ->encode_fh() failures and more particularly, it was also possible with the exact same reproducer using overlayfs that is mounted with options index=on,nfs_export=on also on kernels < v6.6. Therefore, I am not listing the aforementioned commit as a Fixes commit. Backport hint: this patch will have a trivial conflict applying to v6.6.y, and other trivial conflicts applying to stable kernels < v6.6. Reported-by: syzbot+ec07f6f5ce62b858579f(a)syzkaller.appspotmail.com Tested-by: syzbot+ec07f6f5ce62b858579f(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-unionfs/671fd40c.050a0220.4735a.024f.GAE@goog… Reported-by: Dmitry Safonov <dima(a)arista.com> Closes: https://lore.kernel.org/linux-fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3… Cc: stable(a)vger.kernel.org Signed-off-by: Amir Goldstein <amir73il(a)gmail.com> Link: https://lore.kernel.org/r/20241219115301.465396-1-amir73il@gmail.com Signed-off-by: Christian Brauner <brauner(a)kernel.org> diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c index dec553034027..e933f9c65d90 100644 --- a/fs/notify/fdinfo.c +++ b/fs/notify/fdinfo.c @@ -47,10 +47,8 @@ static void show_mark_fhandle(struct seq_file *m, struct inode *inode) size = f->handle_bytes >> 2; ret = exportfs_encode_fid(inode, (struct fid *)f->f_handle, &size); - if ((ret == FILEID_INVALID) || (ret < 0)) { - WARN_ONCE(1, "Can't encode file handler for inotify: %d\n", ret); + if ((ret == FILEID_INVALID) || (ret < 0)) return; - } f->handle_type = ret; f->handle_bytes = size * sizeof(u32); diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c index 3601ddfeddc2..56eee9f23ea9 100644 --- a/fs/overlayfs/copy_up.c +++ b/fs/overlayfs/copy_up.c @@ -442,9 +442,8 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real, buflen = (dwords << 2); err = -EIO; - if (WARN_ON(fh_type < 0) || - WARN_ON(buflen > MAX_HANDLE_SZ) || - WARN_ON(fh_type == FILEID_INVALID)) + if (fh_type < 0 || fh_type == FILEID_INVALID || + WARN_ON(buflen > MAX_HANDLE_SZ)) goto out_err; fh->fb.version = OVL_FH_VERSION;

1 month

7
14
0 0

[PATCH 6.1&6.6 0/3] kbuild: Avoid weak external linkage where possible

by Huacai Chen

Backport this series to 6.1&6.6 because LoongArch gets build errors with latest binutils which has commit 599df6e2db17d1c4 ("ld, LoongArch: print error about linking without -fPIC or -fPIE flag in more detail"). CC .vmlinux.export.o UPD include/generated/utsversion.h CC init/version-timestamp.o LD .tmp_vmlinux.kallsyms1 loongarch64-unknown-linux-gnu-ld: kernel/kallsyms.o:(.text+0): relocation R_LARCH_PCALA_HI20 against `kallsyms_markers` can not be used when making a PIE object; recompile with -fPIE loongarch64-unknown-linux-gnu-ld: kernel/crash_core.o:(.init.text+0x984): relocation R_LARCH_PCALA_HI20 against `kallsyms_names` can not be used when making a PIE object; recompile with -fPIE loongarch64-unknown-linux-gnu-ld: kernel/bpf/btf.o:(.text+0xcc7c): relocation R_LARCH_PCALA_HI20 against `__start_BTF` can not be used when making a PIE object; recompile with -fPIE loongarch64-unknown-linux-gnu-ld: BFD (GNU Binutils) 2.43.50.20241126 assertion fail ../../bfd/elfnn-loongarch.c:2673 In theory 5.10&5.15 also need this, but since LoongArch get upstream at 5.19, so I just ignore them because there is no error report about other archs now. Weak external linkage is intended for cases where a symbol reference can remain unsatisfied in the final link. Taking the address of such a symbol should yield NULL if the reference was not satisfied. Given that ordinary RIP or PC relative references cannot produce NULL, some kind of indirection is always needed in such cases, and in position independent code, this results in a GOT entry. In ordinary code, it is arch specific but amounts to the same thing. While unavoidable in some cases, weak references are currently also used to declare symbols that are always defined in the final link, but not in the first linker pass. This means we end up with worse codegen for no good reason. So let's clean this up, by providing preliminary definitions that are only used as a fallback. Ard Biesheuvel (3): kallsyms: Avoid weak references for kallsyms symbols vmlinux: Avoid weak reference to notes section btf: Avoid weak external references Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> --- include/asm-generic/vmlinux.lds.h | 28 ++++++++++++++++++ kernel/bpf/btf.c | 7 +++-- kernel/bpf/sysfs_btf.c | 6 ++-- kernel/kallsyms.c | 6 ---- kernel/kallsyms_internal.h | 30 ++++++++------------ kernel/ksysfs.c | 4 +-- lib/buildid.c | 4 +-- 7 files changed, 52 insertions(+), 33 deletions(-) --- 2.27.0

1 month

9
19
0 0

[GIT PULL] USB chipidea patches for linux-5.15.y and linux-6.1.y

by Xu Yang

Hi Greg, The below two patches are needed on linux-5.15.y and linux-6.1.y, please help to add them to the stable tree. b7a62611fab7 usb: chipidea: add USB PHY event 87ed257acb09 usb: phy: mxs: disconnect line when USB charger is attached They are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git branch usb-testing Thanks, Xu Yang

2 months, 1 week

4
5
0 0

linux-6.6.y regression on amd-pstate

by Mario Limonciello

+ stable + regressions New subject Great news. Greg, Sasha, Can you please pull in these 3 commits specifically to 6.6.y to fix a regression that was reported by Morgan in 6.6.y: commit 12753d71e8c5 ("ACPI: CPPC: Add helper to get the highest performance value") commit ed429c686b79 ("cpufreq: amd-pstate: Enable amd-pstate preferred core support") commit 3d291fe47fe1 ("cpufreq: amd-pstate: fix the highest frequency issue which limits performance") Further details are below. Thanks! On 9/5/2024 16:09, Jones, Morgan wrote: > Mario, > > Confirmed. Thank you for the help! Slightly different refs on my end: > > Remotes: > > next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (fetch) > next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (push) > origin git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git (fetch) > origin git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git (push) > superm1 https://git.kernel.org/pub/scm/linux/kernel/git/superm1/linux.git/ (fetch) > superm1 https://git.kernel.org/pub/scm/linux/kernel/git/superm1/linux.git/ (push) > torvalds git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (fetch) > torvalds git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (push) > > Patches: > > git format-patch 12753d71e8c5^..12753d71e8c5 > git format-patch f3a052391822b772b4e27f2594526cf1eb103cab^..f3a052391822b772b4e27f2594526cf1eb103cab > git format-patch bf202e654bfa57fb8cf9d93d4c6855890b70b9c4^..bf202e654bfa57fb8cf9d93d4c6855890b70b9c4 > > Results: > > Linux redact 6.6.48 #1-NixOS SMP PREEMPT_DYNAMIC Tue Jan 1 00:00:00 UTC 1980 x86_64 GNU/Linux > > analyzing CPU 56: > driver: amd-pstate-epp > CPUs which run at the same hardware frequency: 56 > CPUs which need to have their frequency coordinated by software: 56 > maximum transition latency: Cannot determine or is not supported. > hardware limits: 400 MHz - 3.35 GHz > available cpufreq governors: performance powersave > current policy: frequency should be within 400 MHz and 3.35 GHz. > The governor "performance" may decide which speed to use > within this range. > current CPU frequency: Unable to call hardware > current CPU frequency: 2.09 GHz (asserted by call to kernel) > boost state support: > Supported: yes > Active: yes > AMD PSTATE Highest Performance: 255. Maximum Frequency: 3.35 GHz. > AMD PSTATE Nominal Performance: 152. Nominal Frequency: 2.00 GHz. > AMD PSTATE Lowest Non-linear Performance: 115. Lowest Non-linear Frequency: 1.51 GHz. > AMD PSTATE Lowest Performance: 31. Lowest Frequency: 400 MHz. > > And our builds are back to being fast with `amd_pstate=active amd_prefcore=enable amd_pstate.shared_mem=1`. > > Morgan > > -----Original Message----- > From: Mario Limonciello <mario.limonciello(a)amd.com> > Sent: Thursday, September 5, 2024 8:12 AM > To: Jones, Morgan <Morgan.Jones(a)viasat.com> > Cc: linux-pm(a)vger.kernel.org; linux-kernel(a)vger.kernel.org; David Arcari <darcari(a)redhat.com>; Dhananjay Ugwekar <Dhananjay.Ugwekar(a)amd.com>; rafael(a)kernel.org; viresh.kumar(a)linaro.org; gautham.shenoy(a)amd.com; perry.yuan(a)amd.com; skhan(a)linuxfoundation.org; li.meng(a)amd.com; ray.huang(a)amd.com > Subject: Re: [EXTERNAL] Re: [PATCH v2 2/2] cpufreq/amd-pstate: Fix the scaling_max_freq setting on shared memory CPPC systems > > Hi Morgan, > > Please apply these 3 commits: > > commit 12753d71e8c5 ("ACPI: CPPC: Add helper to get the highest performance value") commit ed429c686b79 ("cpufreq: amd-pstate: Enable amd-pstate preferred core support") commit 3d291fe47fe1 ("cpufreq: amd-pstate: fix the highest frequency issue which limits performance") > > The first two should help your system, the third will prevent introducing a regression on a different one. > > Assuming that works we should ask @stable to pull all 3 in to fix this regression. > > Thanks, > > On 9/4/2024 08:57, Mario Limonciello wrote: >> Morgan, >> >> I was referring specfiically to the version that landed in Linus' tree: >> https://urldefense.us/v3/__https://git.kernel.org/torvalds/c/8164f7433 >> 264__;!!C5Asm8uRnZQmlRln!aIZEDEbIUKD7OrxN0b0KjoqKYDL2yMkwk4EK7x_oSnyHQ >> 6MEq7yt6JHjd0TD9DgEYEWDcF58OKL8c7G11bT3dSqL8eM$ >> >> But yeah it's effectively the same thing. In any case, it's not the >> solution. >> >> We had some internal discussion and suspect this is due to missing >> prefcore patches in 6.6 as that feature landed in 6.9. We'll try to >> reproduce this on a Rome system and come back with our findings and >> suggestions what to do. >> >> Thanks, >> >

2 months, 1 week

4
5
0 0

[PATCH] drm/panthor: Fix memory leak in panthor_ioctl_group_create()

by Jann Horn

When bailing out due to group_priority_permit() failure, the queue_args need to be freed. Fix it by rearranging the function to use the goto-on-error pattern, such that the success case flows straight without indentation while error cases jump forward to cleanup. Cc: stable(a)vger.kernel.org Fixes: 5f7762042f8a ("drm/panthor: Restrict high priorities on group_create") Signed-off-by: Jann Horn <jannh(a)google.com> --- testcase: ``` #include <err.h> #include <fcntl.h> #include <stddef.h> #include <sys/ioctl.h> #include <drm/panthor_drm.h> #define SYSCHK(x) ({ \ typeof(x) __res = (x); \ if (__res == (typeof(x))-1) \ err(1, "SYSCHK(" #x ")"); \ __res; \ }) #define GPU_PATH "/dev/dri/by-path/platform-fb000000.gpu-card" int main(void) { int fd = SYSCHK(open(GPU_PATH, O_RDWR)); while (1) { struct drm_panthor_queue_create qc[16] = {}; struct drm_panthor_group_create gc = { .queues = { .stride = sizeof(struct drm_panthor_queue_create), .count = 16, .array = (unsigned long)qc }, .priority = PANTHOR_GROUP_PRIORITY_HIGH+1/*invalid*/ }; ioctl(fd, DRM_IOCTL_PANTHOR_GROUP_CREATE, &gc); } } ``` I have tested that without this patch, after running the testcase for a few seconds and then manually killing it, 2G of RAM in kmalloc-128 have been leaked. With the patch applied, the memory leak is gone. (By the way, get_maintainer.pl suggests that I also send this patch to the general DRM maintainers and the DRM-misc maintainers; looking at MAINTAINERS, it looks like it is normal that the general DRM maintainers are listed for everything under drivers/gpu/, but DRM-misc has exclusion rules for a bunch of drivers but not panthor. I don't know if that is intentional.) --- drivers/gpu/drm/panthor/panthor_drv.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c index c520f156e2d73f7e735f8bf2d6d8e8efacec9362..815c23cff25f305d884e8e3e263fa22888f7d5ce 100644 --- a/drivers/gpu/drm/panthor/panthor_drv.c +++ b/drivers/gpu/drm/panthor/panthor_drv.c @@ -1032,14 +1032,15 @@ static int panthor_ioctl_group_create(struct drm_device *ddev, void *data, ret = group_priority_permit(file, args->priority); if (ret) - return ret; + goto out; ret = panthor_group_create(pfile, args, queue_args); - if (ret >= 0) { - args->group_handle = ret; - ret = 0; - } + if (ret < 0) + goto out; + args->group_handle = ret; + ret = 0; +out: kvfree(queue_args); return ret; } --- base-commit: 9f8e716d46c68112484a23d1742d9ec725e082fc change-id: 20241113-panthor-fix-gcq-bailout-2d9ac36590ed -- Jann Horn <jannh(a)google.com>

2 months, 3 weeks

4
4
0 0

FAILED: patch "[PATCH] kbuild: rpm-pkg: simplify installkernel %post" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x 358de8b4f201bc05712484b15f0109b1ae3516a8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024021932-lavish-expel-58e5@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: 358de8b4f201 ("kbuild: rpm-pkg: simplify installkernel %post") 0df8e9708594 ("scripts: clean up IA-64 code") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 358de8b4f201bc05712484b15f0109b1ae3516a8 Mon Sep 17 00:00:00 2001 From: Jose Ignacio Tornos Martinez <jtornosm(a)redhat.com> Date: Mon, 29 Jan 2024 10:28:19 +0100 Subject: [PATCH] kbuild: rpm-pkg: simplify installkernel %post The new installkernel application that is now included in systemd-udev package allows installation although destination files are already present in the boot directory of the kernel package, but is failing with the implemented workaround for the old installkernel application from grubby package. For the new installkernel application, as Davide says: <<The %post currently does a shuffling dance before calling installkernel. This isn't actually necessary afaict, and the current implementation ends up triggering downstream issues such as https://github.com/systemd/systemd/issues/29568 This commit simplifies the logic to remove the shuffling. For reference, the original logic was added in commit 3c9c7a14b627("rpm-pkg: add %post section to create initramfs and grub hooks").>> But we need to keep the old behavior as well, because the old installkernel application from grubby package, does not allow this simplification and we need to be backward compatible to avoid issues with the different packages. Mimic Fedora shipping process and store vmlinuz, config amd System.map in the module directory instead of the boot directory. In this way, we will avoid the commented problem for all the cases, because the new destination files are not going to exist in the boot directory of the kernel package. Replace installkernel tool with kernel-install tool, because the latter is more complete. Besides, after installkernel tool execution, check to complete if the correct package files vmlinuz, System.map and config files are present in /boot directory, and if necessary, copy manually for install operation. In this way, take into account if files were not previously copied from /usr/lib/kernel/install.d/* scripts and if the suitable files for the requested package are present (it could be others if the rpm files were replace with a new pacakge with the same release and a different build). Tested with Fedora 38, Fedora 39, RHEL 9, Oracle Linux 9.3, openSUSE Tumbleweed and openMandrive ROME, using dnf/zypper and rpm tools. cc: stable(a)vger.kernel.org Co-Developed-by: Davide Cavalca <dcavalca(a)meta.com> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm(a)redhat.com> Signed-off-by: Masahiro Yamada <masahiroy(a)kernel.org> diff --git a/scripts/package/kernel.spec b/scripts/package/kernel.spec index 89298983a169..f58726671fb3 100644 --- a/scripts/package/kernel.spec +++ b/scripts/package/kernel.spec @@ -55,12 +55,12 @@ patch -p1 < %{SOURCE2} %{make} %{makeflags} KERNELRELEASE=%{KERNELRELEASE} KBUILD_BUILD_VERSION=%{release} %install -mkdir -p %{buildroot}/boot -cp $(%{make} %{makeflags} -s image_name) %{buildroot}/boot/vmlinuz-%{KERNELRELEASE} +mkdir -p %{buildroot}/lib/modules/%{KERNELRELEASE} +cp $(%{make} %{makeflags} -s image_name) %{buildroot}/lib/modules/%{KERNELRELEASE}/vmlinuz %{make} %{makeflags} INSTALL_MOD_PATH=%{buildroot} modules_install %{make} %{makeflags} INSTALL_HDR_PATH=%{buildroot}/usr headers_install -cp System.map %{buildroot}/boot/System.map-%{KERNELRELEASE} -cp .config %{buildroot}/boot/config-%{KERNELRELEASE} +cp System.map %{buildroot}/lib/modules/%{KERNELRELEASE} +cp .config %{buildroot}/lib/modules/%{KERNELRELEASE}/config ln -fns /usr/src/kernels/%{KERNELRELEASE} %{buildroot}/lib/modules/%{KERNELRELEASE}/build %if %{with_devel} %{make} %{makeflags} run-command KBUILD_RUN_COMMAND='${srctree}/scripts/package/install-extmod-build %{buildroot}/usr/src/kernels/%{KERNELRELEASE}' @@ -70,13 +70,14 @@ ln -fns /usr/src/kernels/%{KERNELRELEASE} %{buildroot}/lib/modules/%{KERNELRELEA rm -rf %{buildroot} %post -if [ -x /sbin/installkernel -a -r /boot/vmlinuz-%{KERNELRELEASE} -a -r /boot/System.map-%{KERNELRELEASE} ]; then -cp /boot/vmlinuz-%{KERNELRELEASE} /boot/.vmlinuz-%{KERNELRELEASE}-rpm -cp /boot/System.map-%{KERNELRELEASE} /boot/.System.map-%{KERNELRELEASE}-rpm -rm -f /boot/vmlinuz-%{KERNELRELEASE} /boot/System.map-%{KERNELRELEASE} -/sbin/installkernel %{KERNELRELEASE} /boot/.vmlinuz-%{KERNELRELEASE}-rpm /boot/.System.map-%{KERNELRELEASE}-rpm -rm -f /boot/.vmlinuz-%{KERNELRELEASE}-rpm /boot/.System.map-%{KERNELRELEASE}-rpm +if [ -x /usr/bin/kernel-install ]; then + /usr/bin/kernel-install add %{KERNELRELEASE} /lib/modules/%{KERNELRELEASE}/vmlinuz fi +for file in vmlinuz System.map config; do + if ! cmp --silent "/lib/modules/%{KERNELRELEASE}/${file}" "/boot/${file}-%{KERNELRELEASE}"; then + cp "/lib/modules/%{KERNELRELEASE}/${file}" "/boot/${file}-%{KERNELRELEASE}" + fi +done %preun if [ -x /sbin/new-kernel-pkg ]; then @@ -94,7 +95,6 @@ fi %defattr (-, root, root) /lib/modules/%{KERNELRELEASE} %exclude /lib/modules/%{KERNELRELEASE}/build -/boot/* %files headers %defattr (-, root, root)

3 months, 2 weeks

5
8
0 0

[PATCH 0/1] disable __counted_by for clang < 19.1.3

by Jan Hendrik Farr

Hi Kees, Bill's PR to disable __counted_by for "whole struct" __bdos cases has now been merged into 19.1.3 [1], so here's the patch to disable __counted_by for clang versions < 19.1.3 in the kernel. Hopefully in the near future __counted_by for whole struct __bdos can be enabled once again in coordination between the kernel, gcc, and clang. There has been recent progress on this in [2] thanks to Tavian. Also see previous discussion on the mailing list [3] Thanks to everyone for moving this issue along. In particular, Bill for his PR to clang/llvm, Kees and Thorsten for reproducers of the two issues, Nathan for Kconfig-ifying this patch, and Miguel for reviewing. Info for the stable team: This patch should be backported to kernels >= 6.6 to make sure that those build correctly with the effected clang versions. This patch cherry-picks cleanly onto linux-6.11.y. For linux-6.6.y three prerequiste commits are neded: 16c31dd7fdf6: Compiler Attributes: counted_by: bump min gcc version 2993eb7a8d34: Compiler Attributes: counted_by: fixup clang URL 231dc3f0c936: lkdtm/bugs: Improve warning message for compilers without counted_by support There are still two merge conflicts even with those prerequistes. Here's the correct resolution: 1. include/linux/compiler_types.h: use the incoming change until before (but not including) the "Apply __counted_by() when the Endianness matches to increase test coverage." comment 2. lib/overflow_kunit.c: HEAD is correct [1] https://github.com/llvm/llvm-project/pull/112786 [2] https://github.com/llvm/llvm-project/pull/112636 [3] https://lore.kernel.org/lkml/3E304FB2-799D-478F-889A-CDFC1A52DCD8@toblux.co… Best Regards Jan Jan Hendrik Farr (1): Compiler Attributes: disable __counted_by for clang < 19.1.3 drivers/misc/lkdtm/bugs.c | 2 +- include/linux/compiler_attributes.h | 13 ------------- include/linux/compiler_types.h | 19 +++++++++++++++++++ init/Kconfig | 9 +++++++++ lib/overflow_kunit.c | 2 +- 5 files changed, 30 insertions(+), 15 deletions(-) -- 2.47.0

3 months, 4 weeks

6
7
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2025