Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

83 participants
123770 discussions

by linux-stable-mirror＠lists.linaro.org

Hi there! I regret to inform you about some sad news for you. Approximately a month or two ago I have succeeded to gain a total access to all your devices utilized for browsing internet. Moving forward, I have started observing your internet activities on continuous basis. Go ahead and take a look at the sequence of events provided below for your reference: Initially I bought an exclusive access from hackers to a long list of email accounts (in today's world, that is really a common thing, which can arranged via internet). Evidently, it wasn't hard for me to proceed with logging in your email account linux-stable- mirror(a)lists.linaro.org. Within the same week, I moved on with installing a Trojan virus in Operating Systems for all devices that you use to login to email. Frankly speaking, it wasn't a challenging task for me at all (since you were kind enough to click some of the links in your inbox emails before). Yeah, geniuses are among us. Because of this Trojan I am able to gain access to entire set of controllers in devices (e.g., your video camera, keyboard, microphone and others). As result, I effortlessly downloaded all data, as well as photos, web browsing history and other types of data to my servers. Moreover, I have access to all social networks accounts that you regularly use, including emails, including chat history, messengers, contacts list etc. My unique virus is incessantly refreshing its signatures (due to control by a driver), and hence remains undetected by any type of antiviruses. Hence, I guess by now you can already see the reason why I always remained undetected until this very letter... During the process of compilation of all the materials associated with you, I also noticed that you are a huge supporter and regular user of websites hosting nasty adult content. Turns out to be, you really love visiting porn websites, as well as watching exciting videos and enduring unforgettable pleasures. As a matter of fact, I was not able to withstand the temptation, but to record certain nasty solo action with you in main role, and later produced a few videos exposing your masturbation and cumming scenes. If until now you don't believe me, all I need is one-two mouse clicks to make all those videos with everyone you know, including your friends, colleagues, relatives and others. Moreover, I am able to upload all that video content online for everyone to see. I sincerely think, you certainly would not wish such incidents to take place, in view of the lustful things demonstrated in your commonly watched videos, (you absolutely know what I mean by that) it will cause a huge adversity for you. There is still a solution to this matter, and here is what you need to do: You make a transaction of 950 USD to my account (an equivalent in bitcoins, which recorded depending on the exchange rate at the date of funds transfer), hence upon receiving the transfer, I will immediately get rid of all those lustful videos without delay. After that we can make it look like there was nothing happening beforehand. Additionally, I can confirm that all the Trojan software is going to be disabled and erased from all devices that you use. You have nothing to worry about, because I keep my word at all times. That is indeed a beneficial bargain that comes with a relatively reduced price, taking into consideration that your profile and traffic were under close monitoring during a long time frame. If you are still unclear regarding how to buy and perform transactions with bitcoins - everything is available online. The amount: 950 USD The Address Part 1: 3D42CBNFwifmjT4rH The Address Part 2: nW3BmvrFwdUNpgi1Q So, you have to manually copy + paste Part1 and Part2 in one string made of 34 characters with no space between the parts that start with "3" and end with "Q" is the actually address where you should send the money to. All you have is 48 hours and the countdown begins once this email is opened (in other words 2 days). The following list includes things you should remember and avoid doing: - There's no point to try replying my email (since this email and return address were created inside your inbox). - There's no point in calling police or any other types of security services either. Furthermore, don't you dare sharing this info with any of your friends. If I discover that (taking into consideration my skills, it will be really simple, because I control all your systems and continuously monitor them) your nasty clip will be shared with public straight away. - There's no point in looking for me too - it won't result in any success. Transactions with cryptocurrency are completely anonymous and untraceable. - There's no point in reinstalling your OS on devices or trying to throw them away. That won't solve the issue, since all clips with you as main character are already uploaded on remote servers. Things that may be concerning you: - That funds transfer won't be delivered to me. Breathe out, I can track down everything right away, so once funds transfer is finished, I will know for sure, since I interminably track down all activities done by you (my Trojan virus controls all processes remotely, just as TeamViewer). - That your videos will be distributed, even though you have completed money transfer to my wallet. Trust me, it is worthless for me to still bother you after money transfer is successful. Moreover, if that was ever part of my plan, I would do make it happen way earlier! We are going to approach and deal with it in a clear manner! In conclusion, I'd like to recommend one more thing... after this you need to make certain you don't get involved in similar kind of unpleasant events anymore! My recommendation - ensure all your passwords are replaced with new ones on a regular basis.

1 day, 3 hours

FAILED: patch "[PATCH] NFSD: NFSv4 file creation neglects setting ACL" 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 913f7cf77bf14c13cfea70e89bcb6d0b22239562 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025122941-civic-revered-b250@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 913f7cf77bf14c13cfea70e89bcb6d0b22239562 Mon Sep 17 00:00:00 2001 From: Chuck Lever <chuck.lever(a)oracle.com> Date: Tue, 18 Nov 2025 19:51:19 -0500 Subject: [PATCH] NFSD: NFSv4 file creation neglects setting ACL MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit An NFSv4 client that sets an ACL with a named principal during file creation retrieves the ACL afterwards, and finds that it is only a default ACL (based on the mode bits) and not the ACL that was requested during file creation. This violates RFC 8881 section 6.4.1.3: "the ACL attribute is set as given". The issue occurs in nfsd_create_setattr(), which calls nfsd_attrs_valid() to determine whether to call nfsd_setattr(). However, nfsd_attrs_valid() checks only for iattr changes and security labels, but not POSIX ACLs. When only an ACL is present, the function returns false, nfsd_setattr() is skipped, and the POSIX ACL is never applied to the inode. Subsequently, when the client retrieves the ACL, the server finds no POSIX ACL on the inode and returns one generated from the file's mode bits rather than returning the originally-specified ACL. Reported-by: Aurélien Couderc <aurelien.couderc2002(a)gmail.com> Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs") Cc: Roland Mainz <roland.mainz(a)nrubsig.org> Cc: stable(a)vger.kernel.org Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> diff --git a/fs/nfsd/vfs.h b/fs/nfsd/vfs.h index fa46f8b5f132..1dd3ae3ceb3a 100644 --- a/fs/nfsd/vfs.h +++ b/fs/nfsd/vfs.h @@ -67,7 +67,8 @@ static inline bool nfsd_attrs_valid(struct nfsd_attrs *attrs) struct iattr *iap = attrs->na_iattr; return (iap->ia_valid || (attrs->na_seclabel && - attrs->na_seclabel->len)); + attrs->na_seclabel->len) || + attrs->na_pacl || attrs->na_dpacl); } __be32 nfserrno (int errno);

1 day, 6 hours

[PATCH 0/4] drm: Revert and fix enable/disable sequence

by Tomi Valkeinen

Changing the enable/disable sequence in commit c9b1150a68d9 ("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable") has caused regressions on multiple platforms: R-Car, MCDE, Rockchip. This is an alternate series to Linus' series: https://lore.kernel.org/all/20251202-mcde-drm-regression-thirdfix-v6-0-f1bf… This series first reverts the original commit and reverts a fix for mediatek which is no longer needed. It then exposes helper functions from DRM core, and finally implements the new sequence only in the tidss driver. There is one more fix in upstream for the original commit, commit 5d91394f2361 ("drm/exynos: fimd: Guard display clock control with runtime PM calls"), but I have not reverted that one as it looks like a valid patch in its own. I added Cc stable v6.17+ to all patches, but I didn't add Fixes tags, as I wasn't sure what should they point to. But I could perhaps add Fixes: <original commit> to all of these. Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com> --- Linus Walleij (1): drm/atomic-helper: Export and namespace some functions Tomi Valkeinen (3): Revert "drm/atomic-helper: Re-order bridge chain pre-enable and post-disable" Revert "drm/mediatek: dsi: Fix DSI host and panel bridge pre-enable order" drm/tidss: Fix enable/disable order drivers/gpu/drm/drm_atomic_helper.c | 122 ++++++++++++++---- drivers/gpu/drm/mediatek/mtk_dsi.c | 6 - drivers/gpu/drm/tidss/tidss_kms.c | 30 ++++- include/drm/drm_atomic_helper.h | 22 ++++ include/drm/drm_bridge.h | 249 ++++++++++-------------------------- 5 files changed, 214 insertions(+), 215 deletions(-) --- base-commit: 88e721ab978a86426aa08da520de77430fa7bb84 change-id: 20251205-drm-seq-fix-b4ed1f56604b Best regards, -- Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com>

1 day, 7 hours

+ mm-zswap-fix-error-pointer-free-in-zswap_cpu_comp_prepare.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/zswap: fix error pointer free in zswap_cpu_comp_prepare() has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-zswap-fix-error-pointer-free-in-zswap_cpu_comp_prepare.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: Pavel Butsykin <pbutsykin(a)cloudlinux.com> Subject: mm/zswap: fix error pointer free in zswap_cpu_comp_prepare() Date: Wed, 31 Dec 2025 11:46:38 +0400 crypto_alloc_acomp_node() may return ERR_PTR(), but the fail path checks only for NULL and can pass an error pointer to crypto_free_acomp(). Use IS_ERR_OR_NULL() to only free valid acomp instances. Link: https://lkml.kernel.org/r/20251231074638.2564302-1-pbutsykin@cloudlinux.com Fixes: 779b9955f643 ("mm: zswap: move allocations during CPU init outside the lock") Signed-off-by: Pavel Butsykin <pbutsykin(a)cloudlinux.com> Reviewed-by: SeongJae Park <sj(a)kernel.org> Acked-by: Yosry Ahmed <yosry.ahmed(a)linux.dev> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Nhat Pham <nphamcs(a)gmail.com> Cc: Chengming Zhou <chengming.zhou(a)linux.dev> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/zswap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/zswap.c~mm-zswap-fix-error-pointer-free-in-zswap_cpu_comp_prepare +++ a/mm/zswap.c @@ -787,7 +787,7 @@ static int zswap_cpu_comp_prepare(unsign return 0; fail: - if (acomp) + if (!IS_ERR_OR_NULL(acomp)) crypto_free_acomp(acomp); kfree(buffer); return ret; _ Patches currently in -mm which might be from pbutsykin(a)cloudlinux.com are mm-zswap-fix-error-pointer-free-in-zswap_cpu_comp_prepare.patch

1 day, 8 hours

+ fs-writeback-skip-as_no_data_integrity-mappings-in-wait_sb_inodes.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: fs/writeback: skip AS_NO_DATA_INTEGRITY mappings in wait_sb_inodes() has been added to the -mm mm-hotfixes-unstable branch. Its filename is fs-writeback-skip-as_no_data_integrity-mappings-in-wait_sb_inodes.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: Joanne Koong <joannelkoong(a)gmail.com> Subject: fs/writeback: skip AS_NO_DATA_INTEGRITY mappings in wait_sb_inodes() Date: Sun, 14 Dec 2025 19:00:43 -0800 Skip waiting on writeback for inodes that belong to mappings that do not have data integrity guarantees (denoted by the AS_NO_DATA_INTEGRITY mapping flag). This restores fuse back to prior behavior where syncs are no-ops. This is needed because otherwise, if a system is running a faulty fuse server that does not reply to issued write requests, this will cause wait_sb_inodes() to wait forever. Link: https://lkml.kernel.org/r/20251215030043.1431306-2-joannelkoong@gmail.com Fixes: 0c58a97f919c ("fuse: remove tmp folio for writebacks and internal rb tree") Signed-off-by: Joanne Koong <joannelkoong(a)gmail.com> Reported-by: Athul Krishna <athul.krishna.kr(a)protonmail.com> Reported-by: J. Neusch��fer <j.neuschaefer(a)gmx.net> Cc: Bonaccorso Salvatore <carnil(a)debian.org> Cc: Jonathan Neuschaefer <j.neuschaefer(a)gmx.net> Cc: Miklos Szeredi <miklos(a)szeredi.hu> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Jan Kara <jack(a)suse.cz> Cc: "Matthew Wilcox (Oracle)" <willy(a)infradead.org> Cc: David Hildenbrand <david(a)kernel.org> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: "Liam R. Howlett" <Liam.Howlett(a)oracle.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/fs-writeback.c | 3 ++- fs/fuse/file.c | 4 +++- include/linux/pagemap.h | 11 +++++++++++ 3 files changed, 16 insertions(+), 2 deletions(-) --- a/fs/fs-writeback.c~fs-writeback-skip-as_no_data_integrity-mappings-in-wait_sb_inodes +++ a/fs/fs-writeback.c @@ -2751,7 +2751,8 @@ static void wait_sb_inodes(struct super_ * do not have the mapping lock. Skip it here, wb completion * will remove it. */ - if (!mapping_tagged(mapping, PAGECACHE_TAG_WRITEBACK)) + if (!mapping_tagged(mapping, PAGECACHE_TAG_WRITEBACK) || + mapping_no_data_integrity(mapping)) continue; spin_unlock_irq(&sb->s_inode_wblist_lock); --- a/fs/fuse/file.c~fs-writeback-skip-as_no_data_integrity-mappings-in-wait_sb_inodes +++ a/fs/fuse/file.c @@ -3200,8 +3200,10 @@ void fuse_init_file_inode(struct inode * inode->i_fop = &fuse_file_operations; inode->i_data.a_ops = &fuse_file_aops; - if (fc->writeback_cache) + if (fc->writeback_cache) { mapping_set_writeback_may_deadlock_on_reclaim(&inode->i_data); + mapping_set_no_data_integrity(&inode->i_data); + } INIT_LIST_HEAD(&fi->write_files); INIT_LIST_HEAD(&fi->queued_writes); --- a/include/linux/pagemap.h~fs-writeback-skip-as_no_data_integrity-mappings-in-wait_sb_inodes +++ a/include/linux/pagemap.h @@ -210,6 +210,7 @@ enum mapping_flags { AS_WRITEBACK_MAY_DEADLOCK_ON_RECLAIM = 9, AS_KERNEL_FILE = 10, /* mapping for a fake kernel file that shouldn't account usage to user cgroups */ + AS_NO_DATA_INTEGRITY = 11, /* no data integrity guarantees */ /* Bits 16-25 are used for FOLIO_ORDER */ AS_FOLIO_ORDER_BITS = 5, AS_FOLIO_ORDER_MIN = 16, @@ -345,6 +346,16 @@ static inline bool mapping_writeback_may return test_bit(AS_WRITEBACK_MAY_DEADLOCK_ON_RECLAIM, &mapping->flags); } +static inline void mapping_set_no_data_integrity(struct address_space *mapping) +{ + set_bit(AS_NO_DATA_INTEGRITY, &mapping->flags); +} + +static inline bool mapping_no_data_integrity(const struct address_space *mapping) +{ + return test_bit(AS_NO_DATA_INTEGRITY, &mapping->flags); +} + static inline gfp_t mapping_gfp_mask(const struct address_space *mapping) { return mapping->gfp_mask; _ Patches currently in -mm which might be from joannelkoong(a)gmail.com are fs-writeback-skip-as_no_data_integrity-mappings-in-wait_sb_inodes.patch

1 day, 8 hours

+ arm64-kernel-initialize-missing-kexec_buf-random-field.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: arm64: kernel: initialize missing kexec_buf->random field has been added to the -mm mm-hotfixes-unstable branch. Its filename is arm64-kernel-initialize-missing-kexec_buf-random-field.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: Yeoreum Yun <yeoreum.yun(a)arm.com> Subject: arm64: kernel: initialize missing kexec_buf->random field Date: Mon, 1 Dec 2025 10:51:18 +0000 Commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") introduced the kexec_buf->random field to enable random placement of kexec_buf. However, this field was never properly initialized for kexec images that do not need to be placed randomly, leading to the following UBSAN warning: [ +0.364528] ------------[ cut here ]------------ [ +0.000019] UBSAN: invalid-load in ./include/linux/kexec.h:210:12 [ +0.000131] load of value 2 is not a valid value for type 'bool' (aka '_Bool') [ +0.000003] CPU: 4 UID: 0 PID: 927 Comm: kexec Not tainted 6.18.0-rc7+ #3 PREEMPT(full) [ +0.000002] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 [ +0.000000] Call trace: [ +0.000001] show_stack+0x24/0x40 (C) [ +0.000006] __dump_stack+0x28/0x48 [ +0.000002] dump_stack_lvl+0x7c/0xb0 [ +0.000002] dump_stack+0x18/0x34 [ +0.000001] ubsan_epilogue+0x10/0x50 [ +0.000002] __ubsan_handle_load_invalid_value+0xc8/0xd0 [ +0.000003] locate_mem_hole_callback+0x28c/0x2a0 [ +0.000003] kexec_locate_mem_hole+0xf4/0x2f0 [ +0.000001] kexec_add_buffer+0xa8/0x178 [ +0.000002] image_load+0xf0/0x258 [ +0.000001] __arm64_sys_kexec_file_load+0x510/0x718 [ +0.000002] invoke_syscall+0x68/0xe8 [ +0.000001] el0_svc_common+0xb0/0xf8 [ +0.000002] do_el0_svc+0x28/0x48 [ +0.000001] el0_svc+0x40/0xe8 [ +0.000002] el0t_64_sync_handler+0x84/0x140 [ +0.000002] el0t_64_sync+0x1bc/0x1c0 To address this, initialise kexec_buf->random field properly. Link: https://lkml.kernel.org/r/20251201105118.2786335-1-yeoreum.yun@arm.com Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Signed-off-by: Yeoreum Yun <yeoreum.yun(a)arm.com> Suggested-by: Breno Leitao <leitao(a)debian.org> Reviewed-by: Breno Leitao <leitao(a)debian.org> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Coiby Xu <coxu(a)redhat.com> Cc: levi.yun <yeoreum.yun(a)arm.com> Cc: Marc Rutland <mark.rutland(a)arm.com> Cc: Will Deacon <will(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/arm64/kernel/kexec_image.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm64/kernel/kexec_image.c~arm64-kernel-initialize-missing-kexec_buf-random-field +++ a/arch/arm64/kernel/kexec_image.c @@ -41,7 +41,7 @@ static void *image_load(struct kimage *i struct arm64_image_header *h; u64 flags, value; bool be_image, be_kernel; - struct kexec_buf kbuf; + struct kexec_buf kbuf = {}; unsigned long text_offset, kernel_segment_number; struct kexec_segment *kernel_segment; int ret; _ Patches currently in -mm which might be from yeoreum.yun(a)arm.com are arm64-kernel-initialize-missing-kexec_buf-random-field.patch

1 day, 9 hours

[PATCH 0/4] mm/damon/sysfs: free setup failures generated zombie sub-sub dirs

by SeongJae Park

Some DAMON sysfs directory setup functions generates its sub and sub-sub directories. For example, 'monitoring_attrs/' directory setup creates 'intervals/' and 'intervals/intervals_goal/' directories under 'monitoring_attrs/' directory. When such sub-sub directories are successfully made but followup setup is failed, the setup function should recursively clean up the subdirectories. However, such setup functions are only dereferencing sub directory reference counters. As a result, under certain setup failures, the sub-sub directories keep having non-zero reference counters. It means the directories cannot be removed like zombies, and the memory for the directories cannot be freed. The user impact of this issue is limited due to the following reasons. When the issue happens, the zombie directories are still taking the path. Hence attempts to generate the directories again will fail, without additional memory leak. This means the upper bound memory leak is limited. Nonetheless this also implies controlling DAMON with a feature that requires the setup-failed sysfs files will be impossible until the system reboots. Also, the setup operations are quite simple. The certain failures would hence only rarely happen, and are difficult to artificially trigger. SeongJae Park (4): mm/damon/sysfs: cleanup intervals subdirs on attrs dir setup failure mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure mm/damon/sysfs-scheme: cleanup quotas subdirs on scheme dir setup failure mm/damon/sysfs-scheme: cleanup access_pattern subdirs on scheme dir setup failure mm/damon/sysfs-schemes.c | 10 ++++++---- mm/damon/sysfs.c | 9 ++++++--- 2 files changed, 12 insertions(+), 7 deletions(-) base-commit: 6d039da6a260dd7919bebc70ebb65d250bb9c24e -- 2.47.3

1 day, 9 hours

[PATCH] USB: OHCI/UHCI: Add soft dependencies on ehci_hcd

by Huacai Chen

Commit 9beeee6584b9aa4f ("USB: EHCI: log a warning if ehci-hcd is not loaded first") said that ehci-hcd should be loaded before ohci-hcd and uhci-hcd. However, commit 05c92da0c52494ca ("usb: ohci/uhci - add soft dependencies on ehci_pci") only makes ohci-pci/uhci-pci depend on ehci- pci, which is not enough and we may still see the warnings in boot log. So fix it by also making ohci-hcd/uhci-hcd depend on ehci-hcd. Cc: stable(a)vger.kernel.org Reported-by: Shengwen Xiao <atzlinux(a)sina.com> Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> --- drivers/usb/host/ohci-hcd.c | 1 + drivers/usb/host/uhci-hcd.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c index 9c7f3008646e..549c965b7fbe 100644 --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -1355,4 +1355,5 @@ static void __exit ohci_hcd_mod_exit(void) clear_bit(USB_OHCI_LOADED, &usb_hcds_loaded); } module_exit(ohci_hcd_mod_exit); +MODULE_SOFTDEP("pre: ehci_hcd"); diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c index 14e6dfef16c6..e1a27d01bdbc 100644 --- a/drivers/usb/host/uhci-hcd.c +++ b/drivers/usb/host/uhci-hcd.c @@ -939,3 +939,4 @@ module_exit(uhci_hcd_cleanup); MODULE_AUTHOR(DRIVER_AUTHOR); MODULE_DESCRIPTION(DRIVER_DESC); MODULE_LICENSE("GPL"); +MODULE_SOFTDEP("pre: ehci_hcd"); -- 2.47.3

1 day, 9 hours

[PATCH v2] LoongArch: BPF: Zero-extend bpf_tail_call() index

by Aaron Yang

From: Hengqi Chen <hengqi.chen(a)gmail.com> The bpf_tail_call() index should be treated as a u32 value. Let's zero-extend it to avoid calling wrong BPF progs. See similar fixes for x86 [1]) and arm64 ([2]) for more details. [1]: https://github.com/torvalds/linux/commit/90caccdd8cc0215705f18b92771b449b01… [2]: https://github.com/torvalds/linux/commit/16338a9b3ac30740d49f5dfed81bac0ffa… Cc: stable(a)vger.kernel.org Fixes: 5dc615520c4d ("LoongArch: Add BPF JIT support") Signed-off-by: Hengqi Chen <hengqi.chen(a)gmail.com> Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> --- arch/loongarch/net/bpf_jit.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c index 5352d0c30fb2..766ded335fd8 100644 --- a/arch/loongarch/net/bpf_jit.c +++ b/arch/loongarch/net/bpf_jit.c @@ -280,6 +280,8 @@ static int emit_bpf_tail_call(struct jit_ctx *ctx, int insn) * goto out; */ tc_ninsn = insn ? ctx->offset[insn+1] - ctx->offset[insn] : ctx->offset[0]; + emit_zext_32(ctx, a2, true); + off = offsetof(struct bpf_array, map.max_entries); emit_insn(ctx, ldwu, t1, a1, off); /* bgeu $a2, $t1, jmp_offset */ -- 2.43.0

1 day, 18 hours

[PATCH v1] LoongArch: BPF: Zero-extend bpf_tail_call() index

by Aaron Yang

1 day, 18 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror