6.12.17-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 118/154 mm/migrate_device: dont add folio to be freed to LRU in migrate_device_finalize()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Hildenbrand <[email protected]>
commit 41cddf83d8b00f29fd105e7a0777366edc69a5cf upstream.
If migration succeeded, we called folio_migrate_flags()->mem_cgroup_migrate() to migrate the memcg from the old to the new folio. This will set memcg_data of the old folio to 0.
Similarly, if migration failed, memcg_data of the dst folio is left unset.
If we call folio_putback_lru() on such folios (memcg_data == 0), we will add the folio to be freed to the LRU, making memcg code unhappy. Running the hmm selftests:
# ./hmm-tests ... # RUN hmm.hmm_device_private.migrate ... [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00 [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff) [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9 [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000 [ 102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled()) [ 102.087230][T14893] ------------[ cut here ]------------ [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.090478][T14893] Modules linked in: [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151 [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.096104][T14893] Code: ... [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293 [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426 [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880 [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8 [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000 [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0 [ 102.113478][T14893] PKRU: 55555554 [ 102.114172][T14893] Call Trace: [ 102.114805][T14893] <TASK> [ 102.115397][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.116547][T14893] ? __warn.cold+0x110/0x210 [ 102.117461][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.118667][T14893] ? report_bug+0x1b9/0x320 [ 102.119571][T14893] ? handle_bug+0x54/0x90 [ 102.120494][T14893] ? exc_invalid_op+0x17/0x50 [ 102.121433][T14893] ? asm_exc_invalid_op+0x1a/0x20 [ 102.122435][T14893] ? __wake_up_klogd.part.0+0x76/0xd0 [ 102.123506][T14893] ? dump_page+0x4f/0x60 [ 102.124352][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.125500][T14893] folio_batch_move_lru+0xd4/0x200 [ 102.126577][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.127505][T14893] __folio_batch_add_and_move+0x391/0x720 [ 102.128633][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.129550][T14893] folio_putback_lru+0x16/0x80 [ 102.130564][T14893] migrate_device_finalize+0x9b/0x530 [ 102.131640][T14893] dmirror_migrate_to_device.constprop.0+0x7c5/0xad0 [ 102.133047][T14893] dmirror_fops_unlocked_ioctl+0x89b/0xc80
Likely, nothing else goes wrong: putting the last folio reference will remove the folio from the LRU again. So besides memcg complaining, adding the folio to be freed to the LRU is just an unnecessary step.
The new flow resembles what we have in migrate_folio_move(): add the dst to the lru, remove migration ptes, unlock and unref dst.
--- mm/migrate_device.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-)
mm/migrate_device.c +4 -9
@@ -840,20 +840,15 @@ void migrate_device_finalize(unsigned lo dst = src; } +if (!folio_is_zone_device (dst)) +folio_add_lru (dst);remove_migration_ptes (src, dst,0 );folio_unlock (src); - -if (folio_is_zone_device (src)) -folio_put (src); -else -folio_putback_lru (src); +folio_put (src);if (dst != src) {folio_unlock (dst); -if (folio_is_zone_device (dst)) -folio_put (dst); -else -folio_putback_lru (dst); +folio_put (dst); } } }
Greg Kroah-Hartman
maintainerPATCH 119/154 arm64: dts: rockchip: Fix broken tsadc pinctrl names for rk3588
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Shiyan <[email protected]>
commit 5c8f9a05336cf5cadbd57ad461621b386aadb762 upstream.
The tsadc driver does not handle pinctrl "gpio" and "otpout". Let's use the correct pinctrl names "default" and "sleep". Additionally, Alexey Charkov's testing [1] has established that it is necessary for pinctrl state to reference the &tsadc_shut_org configuration rather than &tsadc_shut for the driver to function correctly.
[1] https://lkml.org/lkml/2025/1/24/966
--- arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi +3 -3
@@ -2626,9 +2626,9 @@ 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_org>; + pinctrl-1 = <&tsadc_gpio_func>; + pinctrl-names = "default", "sleep"; #thermal-sensor-cells = <1>; status = "disabled"; };
Greg Kroah-Hartman
maintainerPATCH 120/154 arm64: dts: rockchip: Move uart5 pin configuration to px30 ringneck SoM
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lukasz Czechowski <[email protected]>
commit 4eee627ea59304cdd66c5d4194ef13486a6c44fc upstream.
In the PX30-uQ7 (Ringneck) SoM, the hardware CTS and RTS pins for uart5 cannot be used for the UART CTS/RTS, because they are already allocated for different purposes. CTS pin is routed to SUS_S3# signal, while RTS pin is used internally and is not available on Q7 connector. Move definition of the pinctrl-0 property from px30-ringneck-haikou.dts to px30-ringneck.dtsi.
This commit is a dependency to next commit in the patch series, that disables DMA for uart5.
--- arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts | 1 - arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi | 4 ++++ 2 files changed, 4 insertions(+), 1 deletion(-)
arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts +0 -1
@@ -226,7 +226,6 @@ }; &uart5 { - pinctrl-0 = <&uart5_xfer>; rts-gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>; status = "okay"; };
arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi +4 -0
@@ -373,6 +373,10 @@ status = "okay"; }; +&uart5 { + pinctrl-0 = <&uart5_xfer>; +}; + /* Mule UCAN */ &usb_host0_ehci { status = "okay";
Greg Kroah-Hartman
maintainerPATCH 121/154 arm64: dts: rockchip: Disable DMA for uart5 on px30-ringneck
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lukasz Czechowski <[email protected]>
commit 5ae4dca718eacd0a56173a687a3736eb7e627c77 upstream.
UART controllers without flow control seem to behave unstable in case DMA is enabled. The issues were indicated in the message:
https://lore.kernel.org/linux-arm-kernel/CAMdYzYpXtMocCtCpZLU_xuWmOp2Ja_v0Aj0e6YFNRA-yV7u14g@mail.gmail.com/
In case of PX30-uQ7 Ringneck SoM, it was noticed that after couple of hours of UART communication, the CPU stall was occurring, leading to the system becoming unresponsive.
After disabling the DMA, extensive UART communication tests for up to two weeks were performed, and no issues were further observed.
The flow control pins for uart5 are not available on PX30-uQ7 Ringneck, as configured by pinctrl-0, so the DMA nodes were removed on SoM dtsi.
--- arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi | 2 ++ 1 file changed, 2 insertions(+)
arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi +2 -0
@@ -374,6 +374,8 @@ }; &uart5 { + /delete-property/ dmas; + /delete-property/ dma-names; pinctrl-0 = <&uart5_xfer>; };
Greg Kroah-Hartman
maintainerPATCH 122/154 soc: loongson: loongson2_guts: Add check for devm_kstrdup()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haoxiang Li <[email protected]>
commit e31e3f6c0ce473f7ce1e70d54ac8e3ed190509f8 upstream.
Add check for the return value of devm_kstrdup() in loongson2_guts_probe() to catch potential exception.
--- drivers/soc/loongson/loongson2_guts.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/soc/loongson/loongson2_guts.c +4 -1
@@ -114,8 +114,11 @@ static int loongson2_guts_probe(struct pif (of_property_read_string (root,"model" , &machine))of_property_read_string_index (root,"compatible" ,0 , &machine);of_node_put (root); -if (machine) +if (machine) { soc_dev_attr.machine =devm_kstrdup (dev, machine,GFP_KERNEL ); +if (!soc_dev_attr.machine) +return -ENOMEM ; + } svr =loongson2_guts_get_svr (); soc_die =loongson2_soc_die_match (svr, loongson2_soc_die);
Greg Kroah-Hartman
maintainerPATCH 123/154 s390/boot: Fix ESSA detection
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiko Carstens <[email protected]>
commit c3a589fd9fcbf295a7402a4b188dc9277d505f4f upstream.
The cmma_test_essa() inline assembly uses tmp as input and output, however tmp is specified as output only, which allows the compiler to optimize the initialization of tmp away.
Therefore the ESSA detection may or may not work depending on previous contents of the register that the compiler selected for tmp.
Fix this by using the correct constraint modifier.
--- arch/s390/boot/startup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/s390/boot/startup.c +1 -1
@@ -75,7 +75,7 @@ static int cmma_test_essa(void) : [reg1] "=&d" (reg1), [reg2] "=&a" (reg2), [rc] "+&d" (rc), - [tmp] "=&d" (tmp), + [tmp] "+&d" (tmp), "+Q" (get_lowcore()->program_new_psw), "=Q" (old) : [psw_old] "a" (&old),
Greg Kroah-Hartman
maintainerPATCH 124/154 xfs: fix online repair probing when CONFIG_XFS_ONLINE_REPAIR=n
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Darrick J. Wong <[email protected]>
commit 66314e9a57a050f95cb0ebac904f5ab047a8926e upstream.
I received a report from the release engineering side of the house that xfs_scrub without the -n flag (aka fix it mode) would try to fix a broken filesystem even on a kernel that doesn't have online repair built into it:
# xfs_scrub -dTvn /mnt/test EXPERIMENTAL xfs_scrub program in use! Use at your own risk! Phase 1: Find filesystem geometry. /mnt/test: using 1 threads to scrub. Phase 1: Memory used: 132k/0k (108k/25k), time: 0.00/ 0.00/ 0.00s <snip> Phase 4: Repair filesystem. <snip> Info: /mnt/test/some/victimdir directory entries: Attempting repair. (repair.c line 351) Corruption: /mnt/test/some/victimdir directory entries: Repair unsuccessful; offline repair required. (repair.c line 204)
Source: https://blogs.oracle.com/linux/post/xfs-online-filesystem-repair
It is strange that xfs_scrub doesn't refuse to run, because the kernel is supposed to return EOPNOTSUPP if we actually needed to run a repair, and xfs_io's repair subcommand will perror that. And yet:
# xfs_io -x -c 'repair probe' /mnt/test #
The first problem is commit dcb660f9222fd9 (4.15) which should have had xchk_probe set the CORRUPT OFLAG so that any of the repair machinery will get called at all.
It turns out that some refactoring that happened in the 6.6-6.8 era broke the operation of this corner case. What we *really* want to happen is that all the predicates that would steer xfs_scrub_metadata() towards calling xrep_attempt() should function the same way that they do when repair is compiled in; and then xrep_attempt gets to return the fatal EOPNOTSUPP error code that causes the probe to fail.
Instead, commit 8336a64eb75cba (6.6) started the failwhale swimming by hoisting OFLAG checking logic into a helper whose non-repair stub always returns false, causing scrub to return "repair not needed" when in fact the repair is not supported. Prior to that commit, the oflag checking that was open-coded in scrub.c worked correctly.
Similarly, in commit 4bdfd7d15747b1 (6.8) we hoisted the IFLAG_REPAIR and ALREADY_FIXED logic into a helper whose non-repair stub always returns false, so we never enter the if test body that would have called xrep_attempt, let alone fail to decode the OFLAGs correctly.
The final insult (yes, we're doing The Naked Gun now) is commit 48a72f60861f79 (6.8) in which we hoisted the "are we going to try a repair?" predicate into yet another function with a non-repair stub always returns false.
Fix xchk_probe to trigger xrep_probe if repair is enabled, or return EOPNOTSUPP directly if it is not. For all the other scrub types, we need to fix the header predicates so that the ->repair functions (which are all xrep_notsupported) get called to return EOPNOTSUPP. Commit 48a72 is tagged here because the scrub code prior to LTS 6.12 are incomplete and not worth patching.
--- fs/xfs/scrub/common.h | 5 ----- fs/xfs/scrub/repair.h | 11 ++++++++++- fs/xfs/scrub/scrub.c | 12 ++++++++++++ 3 files changed, 22 insertions(+), 6 deletions(-)
fs/xfs/scrub/common.h +0 -5
@@ -179,7 +179,6 @@ static inline bool xchk_skip_xref(structbool xchk_dir_looks_zapped (struct xfs_inode *dp);bool xchk_pptr_looks_zapped (struct xfs_inode *ip); -#ifdef CONFIG_XFS_ONLINE_REPAIR /* Decide if a repair is required. */ static inline bool xchk_needs_repair (const struct xfs_scrub_metadata *sm) {
@@ -199,10 +198,6 @@ static inline bool xchk_could_repair(conreturn (sc->sm->sm_flags &XFS_SCRUB_IFLAG_REPAIR ) && !(sc->flags &XREP_ALREADY_FIXED ); } -#else -# define xchk_needs_repair (sc) (false) -# define xchk_could_repair (sc) (false) -#endif /* CONFIG_XFS_ONLINE_REPAIR */ int xchk_metadata_inode_forks (struct xfs_scrub *sc);
fs/xfs/scrub/repair.h +10 -1
@@ -163,7 +163,16 @@ bool xrep_buf_verify_struct(struct xfs_b#else #define xrep_ino_dqattach (sc) (0) -#define xrep_will_attempt (sc) (false) + +/* +* When online repair is not built into the kernel, we still want to attempt +* the repair so that the stub xrep_attempt below will return EOPNOTSUPP. +*/ +static inline bool xrep_will_attempt (const struct xfs_scrub *sc) +{ +return (sc->sm->sm_flags &XFS_SCRUB_IFLAG_FORCE_REBUILD ) || +xchk_needs_repair (sc->sm); +}static inline int xrep_attempt(
fs/xfs/scrub/scrub.c +12 -0
@@ -149,6 +149,18 @@ xchk_probe(if (xchk_should_terminate (sc, &error))return error; +/* +* If the caller is probing to see if repair works but repair isn't +* built into the kernel, return EOPNOTSUPP because that's the signal +* that userspace expects. If online repair is built in, set the +* CORRUPT flag (without any of the usual tracing/logging) to force us +* into xrep_probe. +*/ +if (xchk_could_repair (sc)) { +if (!IS_ENABLED (CONFIG_XFS_ONLINE_REPAIR )) +return -EOPNOTSUPP ; + sc->sm->sm_flags |=XFS_SCRUB_OFLAG_CORRUPT ; + }return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 125/154 lib/iov_iter: fix import_iovec_ubuf iovec management
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Begunkov <[email protected]>
commit f4b78260fc678ccd7169f32dc9f3bfa3b93931c7 upstream.
import_iovec() says that it should always be fine to kfree the iovec returned in @iovp regardless of the error code. __import_iovec_ubuf() never reallocates it and thus should clear the pointer even in cases when copy_iovec_*() fail.
--- lib/iov_iter.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
lib/iov_iter.c +2 -1
@@ -1428,6 +1428,8 @@ static ssize_t __import_iovec_ubuf(int tstruct iovec *iov = *iovp;ssize_t ret; + *iovp =NULL ; +if (compat) ret =copy_compat_iovec_from_user (iov, uvec,1 );else
@@ -1438,7 +1440,6 @@ static ssize_t __import_iovec_ubuf(int t ret =import_ubuf (type, iov->iov_base, iov->iov_len, i);if (unlikely (ret))return ret; - *iovp =NULL ;return i->count; }
Greg Kroah-Hartman
maintainerPATCH 126/154 smb: client: fix chmod(2) regression with ATTR_READONLY
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paulo Alcantara <[email protected]>
commit 654292a0b264e9b8c51b98394146218a21612aa1 upstream.
When the user sets a file or directory as read-only (e.g. ~S_IWUGO), the client will set the ATTR_READONLY attribute by sending an SMB2_SET_INFO request to the server in cifs_setattr_{,nounix}(), but cifsInodeInfo::cifsAttrs will be left unchanged as the client will only update the new file attributes in the next call to {smb311_posix,cifs}_get_inode_info() with the new metadata filled in @data parameter.
Commit a18280e7fdea ("smb: cilent: set reparse mount points as automounts") mistakenly removed the @data NULL check when calling is_inode_cache_good(), which broke the above case as the new ATTR_READONLY attribute would end up not being updated on files with a read lease.
Fix this by updating the inode whenever we have cached metadata in @data parameter.
--- fs/smb/client/inode.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/smb/client/inode.c +2 -2
@@ -1381,7 +1381,7 @@ int cifs_get_inode_info(struct inode **istruct cifs_fattr fattr = {};int rc; -if (is_inode_cache_good (*inode)) { +if (!data &&is_inode_cache_good (*inode)) {cifs_dbg (FYI ,"No need to revalidate cached inode sizes\n" );return 0 ; }
@@ -1480,7 +1480,7 @@ int smb311_posix_get_inode_info(struct istruct cifs_fattr fattr = {};int rc; -if (is_inode_cache_good (*inode)) { +if (!data &&is_inode_cache_good (*inode)) {cifs_dbg (FYI ,"No need to revalidate cached inode sizes\n" );return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 127/154 nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haoxiang Li <[email protected]>
commit 878e7b11736e062514e58f3b445ff343e6705537 upstream.
Add check for the return value of nfp_app_ctrl_msg_alloc() in nfp_bpf_cmsg_alloc() to prevent null pointer dereference.
--- drivers/net/ethernet/netronome/nfp/bpf/cmsg.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ethernet/netronome/nfp/bpf/cmsg.c +2 -0
@@ -20,6 +20,8 @@ nfp_bpf_cmsg_alloc(struct nfp_app_bpf *bstruct sk_buff *skb; skb =nfp_app_ctrl_msg_alloc (bpf->app, size,GFP_KERNEL ); +if (!skb) +return NULL ;skb_put (skb, size);return skb;
Greg Kroah-Hartman
maintainerPATCH 128/154 gve: set xdp redirect target only when it is available
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joshua Washington <[email protected]>
commit 415cadd505464d9a11ff5e0f6e0329c127849da5 upstream.
Before this patch the NETDEV_XDP_ACT_NDO_XMIT XDP feature flag is set by default as part of driver initialization, and is never cleared. However, this flag differs from others in that it is used as an indicator for whether the driver is ready to perform the ndo_xdp_xmit operation as part of an XDP_REDIRECT. Kernel helpers xdp_features_(set|clear)_redirect_target exist to convey this meaning.
This patch ensures that the netdev is only reported as a redirect target when XDP queues exist to forward traffic.
--- drivers/net/ethernet/google/gve/gve.h | 10 ++++++++++ drivers/net/ethernet/google/gve/gve_main.c | 6 +++++- 2 files changed, 15 insertions(+), 1 deletion(-)
drivers/net/ethernet/google/gve/gve.h +10 -0
@@ -1110,6 +1110,16 @@ static inline u32 gve_xdp_tx_start_queuereturn gve_xdp_tx_queue_id (priv,0 ); } +static inline bool gve_supports_xdp_xmit (struct gve_priv *priv) +{ +switch (priv->queue_format) { +case GVE_GQI_QPL_FORMAT : +return true; +default : +return false; + } +} +/* gqi napi handler defined in gve_main.c */ int gve_napi_poll (struct napi_struct *napi,int budget);
drivers/net/ethernet/google/gve/gve_main.c +5 -1
@@ -1895,6 +1895,8 @@ static void gve_turndown(struct gve_priv/* Stop tx queues */ netif_tx_disable (priv->dev); +xdp_features_clear_redirect_target (priv->dev); +gve_clear_napi_enabled (priv);gve_clear_report_stats (priv);
@@ -1955,6 +1957,9 @@ static void gve_turnup(struct gve_priv *napi_schedule (&block->napi); } +if (priv->num_xdp_queues &&gve_supports_xdp_xmit (priv)) +xdp_features_set_redirect_target (priv->dev, false); +gve_set_napi_enabled (priv); }
@@ -2229,7 +2234,6 @@ static void gve_set_netdev_xdp_features(if (priv->queue_format ==GVE_GQI_QPL_FORMAT ) { xdp_features =NETDEV_XDP_ACT_BASIC ; xdp_features |=NETDEV_XDP_ACT_REDIRECT ; - xdp_features |=NETDEV_XDP_ACT_NDO_XMIT ; xdp_features |=NETDEV_XDP_ACT_XSK_ZEROCOPY ; }else { xdp_features =0 ;
Greg Kroah-Hartman
maintainerPATCH 129/154 ASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Ujfalusi <[email protected]>
commit d8d99c3b5c485f339864aeaa29f76269cc0ea975 upstream.
The nullity of sps->cstream should be checked similarly as it is done in sof_set_stream_data_offset() function.
Assuming that it is not NULL if sps->stream is NULL is incorrect and can lead to NULL pointer dereference.
--- sound/soc/sof/stream-ipc.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
sound/soc/sof/stream-ipc.c +5 -1
@@ -43,7 +43,7 @@ int sof_ipc_msg_data(struct snd_sof_devreturn -ESTRPIPE ; posn_offset = stream->posn_offset; - }else { + }else if (sps->cstream) {struct sof_compr_stream *sstream = sps->cstream->runtime->private_data;
@@ -51,6 +51,10 @@ int sof_ipc_msg_data(struct snd_sof_devreturn -ESTRPIPE ; posn_offset = sstream->posn_offset; + + }else { +dev_err (sdev->dev,"%s: No stream opened\n" , __func__); +return -EINVAL ; }snd_sof_dsp_mailbox_read (sdev, posn_offset, p, sz);
Greg Kroah-Hartman
maintainerPATCH 130/154 ASoC: fsl_micfil: Enable default case in micfil_set_quality()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikita Zhandarovich <[email protected]>
commit a8c9a453387640dbe45761970f41301a6985e7fa upstream.
If 'micfil->quality' received from micfil_quality_set() somehow ends up with an unpredictable value, switch() operator will fail to initialize local variable qsel before regmap_update_bits() tries to utilize it.
While it is unlikely, play it safe and enable a default case that returns -EINVAL error.
Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.
--- sound/soc/fsl/fsl_micfil.c | 2 ++ 1 file changed, 2 insertions(+)
sound/soc/fsl/fsl_micfil.c +2 -0
@@ -156,6 +156,8 @@ static int micfil_set_quality(struct fslcase QUALITY_VLOW2 : qsel =MICFIL_QSEL_VLOW2_QUALITY ;break ; +default : +return -EINVAL ; } return regmap_update_bits(micfil->regmap, REG_MICFIL_CTRL2,
Greg Kroah-Hartman
maintainerPATCH 131/154 ALSA: hda: Add error check for snd_ctl_rename_id() in snd_hda_create_dig_out_ctls()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wentao Liang <[email protected]>
commit 822b7ec657e99b44b874e052d8540d8b54fe8569 upstream.
Check the return value of snd_ctl_rename_id() in snd_hda_create_dig_out_ctls(). Ensure that failures are properly handled.
[ Note: the error cannot happen practically because the only error
condition in snd_ctl_rename_id() is the missing ID, but this is a rename, hence it must be present. But for the code consistency, it's safer to have always the proper return check -- tiwai ]
--- sound/pci/hda/hda_codec.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
sound/pci/hda/hda_codec.c +3 -1
@@ -2470,7 +2470,9 @@ int snd_hda_create_dig_out_ctls(struct hbreak ; id = kctl->id; id.index = spdif_index; -snd_ctl_rename_id (codec->card, &kctl->id, &id); + err =snd_ctl_rename_id (codec->card, &kctl->id, &id); +if (err <0 ) +return err; } bus->primary_dig_out_type =HDA_PCM_TYPE_HDMI ; }
Greg Kroah-Hartman
maintainerPATCH 132/154 ALSA: hda/conexant: Add quirk for HP ProBook 450 G4 mute LED
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Veness <[email protected]>
commit 6d1f86610f23b0bc334d6506a186f21a98f51392 upstream.
Allows the LED on the dedicated mute button on the HP ProBook 450 G4 laptop to change colour correctly.
--- sound/pci/hda/patch_conexant.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_conexant.c +1 -0
@@ -1080,6 +1080,7 @@ static const struct hda_quirk cxt5066_fiSND_PCI_QUIRK (0x103c ,0x814f ,"HP ZBook 15u G3" ,CXT_FIXUP_MUTE_LED_GPIO ),SND_PCI_QUIRK (0x103c ,0x8174 ,"HP Spectre x360" ,CXT_FIXUP_HP_SPECTRE ),SND_PCI_QUIRK (0x103c ,0x822e ,"HP ProBook 440 G4" ,CXT_FIXUP_MUTE_LED_GPIO ), +SND_PCI_QUIRK (0x103c ,0x8231 ,"HP ProBook 450 G4" ,CXT_FIXUP_MUTE_LED_GPIO ),SND_PCI_QUIRK (0x103c ,0x828c ,"HP EliteBook 840 G4" ,CXT_FIXUP_HP_DOCK ),SND_PCI_QUIRK (0x103c ,0x8299 ,"HP 800 G3 SFF" ,CXT_FIXUP_HP_MIC_NO_PRESENCE ), SND_PCI_QUIRK(0x103c, 0x829a, "HP 800 G3 DM", CXT_FIXUP_HP_MIC_NO_PRESENCE),
Greg Kroah-Hartman
maintainerPATCH 133/154 ASoC: SOF: pcm: Clear the susbstream pointer to NULL on close
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Ujfalusi <[email protected]>
commit 46c7b901e2a03536df5a3cb40b3b26e2be505df6 upstream.
The spcm->stream[substream->stream].substream is set during open and was left untouched. After the first PCM stream it will never be NULL and we have code which checks for substream NULLity as indication if the stream is active or not.
For the compressed cstream pointer the same has been done, this change will correct the handling of PCM streams.
--- sound/soc/sof/pcm.c | 2 ++ 1 file changed, 2 insertions(+)
sound/soc/sof/pcm.c +2 -0
@@ -511,6 +511,8 @@ static int sof_pcm_close(struct snd_soc_*/ } + spcm->stream[substream->stream].substream =NULL ; +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 134/154 acct: perform last write from workqueue
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Brauner <[email protected]>
commit 56d5f3eba3f5de0efdd556de4ef381e109b973a9 upstream.
In [1] it was reported that the acct(2) system call can be used to trigger NULL deref in cases where it is set to write to a file that triggers an internal lookup. This can e.g., happen when pointing acc(2) to /sys/power/resume. At the point the where the write to this file happens the calling task has already exited and called exit_fs(). A lookup will thus trigger a NULL-deref when accessing current->fs.
Reorganize the code so that the the final write happens from the workqueue but with the caller's credentials. This preserves the (strange) permission model and has almost no regression risk.
This api should stop to exist though.
--- kernel/acct.c | 120 +++++++++++++++++++++++++++++++++------------------------- 1 file changed, 70 insertions(+), 50 deletions(-)
kernel/acct.c +70 -50
@@ -103,48 +103,50 @@ struct bsd_acct_struct {atomic_long_t count;struct rcu_head rcu;struct mutex lock; -int active; +bool active; +bool check_space;unsigned long needcheck;struct file *file;struct pid_namespace *ns;struct work_struct work;struct completion done; +acct_t ac; }; -static void do_acct_process (struct bsd_acct_struct *acct); +static void fill_ac (struct bsd_acct_struct *acct); +static void acct_write_process (struct bsd_acct_struct *acct);/* * Check the amount of free space and suspend/resume accordingly. */ -static int check_free_space (struct bsd_acct_struct *acct) +static bool check_free_space (struct bsd_acct_struct *acct) {struct kstatfs sbuf; -if (time_is_after_jiffies (acct->needcheck)) - goto out; +if (!acct->check_space) +return acct->active;/* May block */ if (vfs_statfs (&acct->file->f_path, &sbuf)) - goto out; +return acct->active;if (acct->active) {u64 suspend = sbuf.f_blocks *SUSPEND ;do_div (suspend,100 );if (sbuf.f_bavail <= suspend) { - acct->active =0 ; + acct->active = false;pr_info ("Process accounting paused\n" ); } }else {u64 resume = sbuf.f_blocks *RESUME ;do_div (resume,100 );if (sbuf.f_bavail >= resume) { - acct->active =1 ; + acct->active = true;pr_info ("Process accounting resumed\n" ); } } acct->needcheck = jiffies +ACCT_TIMEOUT *HZ ; -out:return acct->active; }
@@ -189,7 +191,11 @@ static void acct_pin_kill(struct fs_pin {struct bsd_acct_struct *acct =to_acct (pin);mutex_lock (&acct->lock); -do_acct_process (acct); +/* +* Fill the accounting struct with the exiting task's info +* before punting to the workqueue. +*/ +fill_ac (acct);schedule_work (&acct->work);wait_for_completion (&acct->done);cmpxchg (&acct->ns->bacct, pin,NULL );
@@ -202,6 +208,9 @@ static void close_work(struct work_struc { struct bsd_acct_struct *acct = container_of(work, struct bsd_acct_struct, work);struct file *file = acct->file; + +/* We were fired by acct_pin_kill() which holds acct->lock. */ +acct_write_process (acct);if (file->f_op->flush) file->f_op->flush (file,NULL );__fput_sync (file);
@@ -430,13 +439,27 @@ static u32 encode_float(u64 value)* do_exit() or when switching to a different output file. */ -static void fill_ac (acct_t *ac) +static void fill_ac (struct bsd_acct_struct *acct) {struct pacct_struct *pacct = ¤t->signal->pacct; +struct file *file = acct->file; +acct_t *ac = &acct->ac;u64 elapsed, run_time;time64_t btime;struct tty_struct *tty; +lockdep_assert_held (&acct->lock); + +if (time_is_after_jiffies (acct->needcheck)) { + acct->check_space = false; + +/* Don't fill in @ac if nothing will be written. */ +if (!acct->active) +return ; + }else { + acct->check_space = true; + } +/* * Fill the accounting struct with the needed info as recorded * by the different kernel functions.
@@ -484,64 +507,61 @@ static void fill_ac(acct_t *ac) ac->ac_majflt =encode_comp_t (pacct->ac_majflt); ac->ac_exitcode = pacct->ac_exitcode;spin_unlock_irq (¤t->sighand->siglock); -} -/* -* do_acct_process does all actual work. Caller holds the reference to file. -*/ -static void do_acct_process (struct bsd_acct_struct *acct) -{ -acct_t ac; -unsigned long flim; -const struct cred *orig_cred; -struct file *file = acct->file; - -/* -* Accounting records are not subject to resource limits. -*/ - flim =rlimit (RLIMIT_FSIZE ); - current->signal->rlim[RLIMIT_FSIZE ].rlim_cur =RLIM_INFINITY ; -/* Perform file operations on behalf of whoever enabled accounting */ - orig_cred =override_creds (file->f_cred); -/* -* First check to see if there is enough free_space to continue -* the process accounting system. -*/ -if (!check_free_space (acct)) - goto out; - -fill_ac (&ac);/* we really need to bite the bullet and change layout */ - ac.ac_uid =from_kuid_munged (file->f_cred->user_ns, orig_cred->uid); - ac.ac_gid =from_kgid_munged (file->f_cred->user_ns, orig_cred->gid); + ac->ac_uid =from_kuid_munged (file->f_cred->user_ns,current_uid ()); + ac->ac_gid =from_kgid_munged (file->f_cred->user_ns,current_gid ());#if ACCT_VERSION ==1 ||ACCT_VERSION ==2 /* backward-compatible 16 bit fields */ - ac.ac_uid16 = ac.ac_uid; - ac.ac_gid16 = ac.ac_gid; + ac->ac_uid16 = ac->ac_uid; + ac->ac_gid16 = ac->ac_gid;#elif ACCT_VERSION ==3 {struct pid_namespace *ns = acct->ns; - ac.ac_pid =task_tgid_nr_ns (current, ns); + ac->ac_pid =task_tgid_nr_ns (current, ns);rcu_read_lock (); - ac.ac_ppid =task_tgid_nr_ns (rcu_dereference (current->real_parent), - ns); + ac->ac_ppid =task_tgid_nr_ns (rcu_dereference (current->real_parent), ns);rcu_read_unlock (); }#endif +} + +static void acct_write_process (struct bsd_acct_struct *acct) +{ +struct file *file = acct->file; +const struct cred *cred; +acct_t *ac = &acct->ac; + +/* Perform file operations on behalf of whoever enabled accounting */ + cred =override_creds (file->f_cred); +/* -* Get freeze protection. If the fs is frozen, just skip the write -* as we could deadlock the system otherwise. +* First check to see if there is enough free_space to continue +* the process accounting system. Then get freeze protection. If +* the fs is frozen, just skip the write as we could deadlock +* the system otherwise. */ -if (file_start_write_trylock (file)) { +if (check_free_space (acct) &&file_start_write_trylock (file)) {/* it's been opened O_APPEND, so position is irrelevant */ loff_t pos =0 ; -__kernel_write (file, &ac,sizeof (acct_t), &pos); +__kernel_write (file, ac,sizeof (acct_t), &pos);file_end_write (file); } -out: + +revert_creds (cred); +} + +static void do_acct_process (struct bsd_acct_struct *acct) +{ +unsigned long flim; + +/* Accounting records are not subject to resource limits. */ + flim =rlimit (RLIMIT_FSIZE ); + current->signal->rlim[RLIMIT_FSIZE ].rlim_cur =RLIM_INFINITY ; +fill_ac (acct); +acct_write_process (acct); current->signal->rlim[RLIMIT_FSIZE ].rlim_cur = flim; -revert_creds (orig_cred); }/**
Greg Kroah-Hartman
maintainerPATCH 135/154 acct: block access to kernel internal filesystems
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Brauner <[email protected]>
commit 890ed45bde808c422c3c27d3285fc45affa0f930 upstream.
There's no point in allowing anything kernel internal nor procfs or sysfs.
--- kernel/acct.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
kernel/acct.c +14 -0
@@ -243,6 +243,20 @@ static int acct_on(struct filename *pathreturn -EACCES ; } +/* Exclude kernel kernel internal filesystems. */ +if (file_inode (file)->i_sb->s_flags & (SB_NOUSER |SB_KERNMOUNT )) { +kfree (acct); +filp_close (file,NULL ); +return -EINVAL ; + } + +/* Exclude procfs and sysfs. */ +if (file_inode (file)->i_sb->s_iflags &SB_I_USERNS_VISIBLE ) { +kfree (acct); +filp_close (file,NULL ); +return -EINVAL ; + } +if (!(file->f_mode &FMODE_CAN_WRITE )) {kfree (acct);filp_close (file,NULL );
Greg Kroah-Hartman
maintainerPATCH 136/154 mm,madvise,hugetlb: check for 0-length range after end address adjustment
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ricardo Cañuelo Navarro <[email protected]>
commit 2ede647a6fde3e54a6bfda7cf01c716649655900 upstream.
Add a sanity check to madvise_dontneed_free() to address a corner case in madvise where a race condition causes the current vma being processed to be backed by a different page size.
During a madvise(MADV_DONTNEED) call on a memory region registered with a userfaultfd, there's a period of time where the process mm lock is temporarily released in order to send a UFFD_EVENT_REMOVE and let userspace handle the event. During this time, the vma covering the current address range may change due to an explicit mmap done concurrently by another thread.
If, after that change, the memory region, which was originally backed by 4KB pages, is now backed by hugepages, the end address is rounded down to a hugepage boundary to avoid data loss (see "Fixes" below). This rounding may cause the end address to be truncated to the same address as the start.
Make this corner case follow the same semantics as in other similar cases where the requested region has zero length (ie. return 0).
This will make madvise_walk_vmas() continue to the next vma in the range (this time holding the process mm lock) which, due to the prev pointer becoming stale because of the vma change, will be the same hugepage-backed vma that was just checked before. The next time madvise_dontneed_free() runs for this vma, if the start address isn't aligned to a hugepage boundary, it'll return -EINVAL, which is also in line with the madvise api.
Quoted 1 line
From userspace perspective,
madvise()will return EINVAL because the start
address isn't aligned according to the new vma alignment requirements (hugepage), even though it was correctly page-aligned when the call was issued.
--- mm/madvise.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
mm/madvise.c +10 -1
@@ -920,7 +920,16 @@ static long madvise_dontneed_free(struct*/ end = vma->vm_end; } -VM_WARN_ON (start >= end); +/* +* If the memory region between start and end was +* originally backed by 4kB pages and then remapped to +* be backed by hugepages while mmap_lock was dropped, +* the adjustment for hugetlb vma above may have rounded +* end down to the start address. +*/ +if (start == end) +return 0 ; +VM_WARN_ON (start > end); }if (behavior ==MADV_DONTNEED || behavior ==MADV_DONTNEED_LOCKED )
Greg Kroah-Hartman
maintainerPATCH 137/154 mtd: spi-nor: sst: Fix SST write failure
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amit Kumar Mahapatra <[email protected]>
commit 539bd20352832b9244238a055eb169ccf1c41ff6 upstream.
'commit 18bcb4aa54ea ("mtd: spi-nor: sst: Factor out common write operation to sst_nor_write_data()")' introduced a bug where only one byte of data is written, regardless of the number of bytes passed to sst_nor_write_data(), causing a kernel crash during the write operation. Ensure the correct number of bytes are written as passed to sst_nor_write_data().
Call trace: [ 57.400180] ------------[ cut here ]------------ [ 57.404842] While writing 2 byte written 1 bytes [ 57.409493] WARNING: CPU: 0 PID: 737 at drivers/mtd/spi-nor/sst.c:187 sst_nor_write_data+0x6c/0x74 [ 57.418464] Modules linked in: [ 57.421517] CPU: 0 UID: 0 PID: 737 Comm: mtd_debug Not tainted 6.12.0-g5ad04afd91f9 #30 [ 57.429517] Hardware name: Xilinx Versal A2197 Processor board revA - x-prc-02 revA (DT) [ 57.437600] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 57.444557] pc : sst_nor_write_data+0x6c/0x74 [ 57.448911] lr : sst_nor_write_data+0x6c/0x74 [ 57.453264] sp : ffff80008232bb40 [ 57.456570] x29: ffff80008232bb40 x28: 0000000000010000 x27: 0000000000000001 [ 57.463708] x26: 000000000000ffff x25: 0000000000000000 x24: 0000000000000000 [ 57.470843] x23: 0000000000010000 x22: ffff80008232bbf0 x21: ffff000816230000 [ 57.477978] x20: ffff0008056c0080 x19: 0000000000000002 x18: 0000000000000006 [ 57.485112] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80008232b580 [ 57.492246] x14: 0000000000000000 x13: ffff8000816d1530 x12: 00000000000004a4 [ 57.499380] x11: 000000000000018c x10: ffff8000816fd530 x9 : ffff8000816d1530 [ 57.506515] x8 : 00000000fffff7ff x7 : ffff8000816fd530 x6 : 0000000000000001 [ 57.513649] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 57.520782] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0008049b0000 [ 57.527916] Call trace: [ 57.530354] sst_nor_write_data+0x6c/0x74 [ 57.534361] sst_nor_write+0xb4/0x18c [ 57.538019] mtd_write_oob_std+0x7c/0x88 [ 57.541941] mtd_write_oob+0x70/0xbc [ 57.545511] mtd_write+0x68/0xa8 [ 57.548733] mtdchar_write+0x10c/0x290 [ 57.552477] vfs_write+0xb4/0x3a8 [ 57.555791] ksys_write+0x74/0x10c [ 57.559189] __arm64_sys_write+0x1c/0x28 [ 57.563109] invoke_syscall+0x54/0x11c [ 57.566856] el0_svc_common.constprop.0+0xc0/0xe0 [ 57.571557] do_el0_svc+0x1c/0x28 [ 57.574868] el0_svc+0x30/0xcc [ 57.577921] el0t_64_sync_handler+0x120/0x12c [ 57.582276] el0t_64_sync+0x190/0x194 [ 57.585933] ---[ end trace 0000000000000000 ]---
--- drivers/mtd/spi-nor/sst.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/spi-nor/sst.c +1 -1
@@ -174,7 +174,7 @@ static int sst_nor_write_data(struct spi_nor *nor, loff_t to, size_t len,int ret; nor->program_opcode = op; - ret =spi_nor_write_data (nor, to,1 , buf); + ret =spi_nor_write_data (nor, to, len, buf);if (ret <0 )return ret;WARN (ret != len,"While writing %zu byte written %i bytes\n" , len, ret);
Signature · 1 line
2.48.1
Greg Kroah-Hartman
maintainerPATCH 138/154 mtd: rawnand: cadence: fix error code in cadence_nand_init()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Niravkumar L Rabara <[email protected]>
commit 2b9df00cded911e2ca2cfae5c45082166b24f8aa upstream.
Replace dma_request_channel() with dma_request_chan_by_mask() and use helper functions to return proper error code instead of fixed -EBUSY.
--- drivers/mtd/nand/raw/cadence-nand-controller.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
drivers/mtd/nand/raw/cadence-nand-controller.c +4 -5
@@ -2904,11 +2904,10 @@ static int cadence_nand_init(struct cdnsdma_cap_set (DMA_MEMCPY , mask);if (cdns_ctrl->caps1->has_dma) { - cdns_ctrl->dmac =dma_request_channel (mask,NULL ,NULL ); -if (!cdns_ctrl->dmac) { -dev_err (cdns_ctrl->dev, -"Unable to get a DMA channel\n" ); - ret = -EBUSY ; + cdns_ctrl->dmac =dma_request_chan_by_mask (&mask); +if (IS_ERR (cdns_ctrl->dmac)) { + ret =dev_err_probe (cdns_ctrl->dev,PTR_ERR (cdns_ctrl->dmac), +"%d: Failed to get a DMA channel\n" , ret); goto disable_irq; } }
Greg Kroah-Hartman
maintainerPATCH 139/154 mtd: rawnand: cadence: use dma_map_resource for sdma address
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Niravkumar L Rabara <[email protected]>
commit d76d22b5096c5b05208fd982b153b3f182350b19 upstream.
Remap the slave DMA I/O resources to enhance driver portability. Using a physical address causes DMA translation failure when the ARM SMMU is enabled.
--- drivers/mtd/nand/raw/cadence-nand-controller.c | 29 +++++++++++++++++++++---- 1 file changed, 25 insertions(+), 4 deletions(-)
drivers/mtd/nand/raw/cadence-nand-controller.c +25 -4
@@ -471,6 +471,8 @@ struct cdns_nand_ctrl {struct {void __iomem *virt;dma_addr_t dma; +dma_addr_t iova_dma; +u32 size; } io;int irq;
@@ -1835,11 +1837,11 @@ static int cadence_nand_slave_dma_transf }if (dir ==DMA_FROM_DEVICE ) { - src_dma = cdns_ctrl->io.dma; + src_dma = cdns_ctrl->io.iova_dma; dst_dma = buf_dma; }else { src_dma = buf_dma; - dst_dma = cdns_ctrl->io.dma; + dst_dma = cdns_ctrl->io.iova_dma; } tx = dmaengine_prep_dma_memcpy(cdns_ctrl->dmac, dst_dma, src_dma, len,
@@ -2869,6 +2871,7 @@ cadence_nand_irq_cleanup(int irqnum, strstatic int cadence_nand_init (struct cdns_nand_ctrl *cdns_ctrl) {dma_cap_mask_t mask; +struct dma_device *dma_dev = cdns_ctrl->dmac->device;int ret; cdns_ctrl->cdma_desc = dma_alloc_coherent(cdns_ctrl->dev,
@@ -2912,6 +2915,16 @@ static int cadence_nand_init(struct cdns } } + cdns_ctrl->io.iova_dma =dma_map_resource (dma_dev->dev, cdns_ctrl->io.dma, + cdns_ctrl->io.size, +DMA_BIDIRECTIONAL ,0 ); + + ret =dma_mapping_error (dma_dev->dev, cdns_ctrl->io.iova_dma); +if (ret) { +dev_err (cdns_ctrl->dev,"Failed to map I/O resource to DMA\n" ); + goto dma_release_chnl; + } +nand_controller_init (&cdns_ctrl->controller);INIT_LIST_HEAD (&cdns_ctrl->chips);
@@ -2922,18 +2935,22 @@ static int cadence_nand_init(struct cdnsif (ret) {dev_err (cdns_ctrl->dev,"Failed to register MTD: %d\n" , ret); - goto dma_release_chnl; + goto unmap_dma_resource; }kfree (cdns_ctrl->buf); cdns_ctrl->buf =kzalloc (cdns_ctrl->buf_size,GFP_KERNEL );if (!cdns_ctrl->buf) { ret = -ENOMEM ; - goto dma_release_chnl; + goto unmap_dma_resource; }return 0 ; +unmap_dma_resource: +dma_unmap_resource (dma_dev->dev, cdns_ctrl->io.iova_dma, + cdns_ctrl->io.size,DMA_BIDIRECTIONAL ,0 ); + dma_release_chnl:if (cdns_ctrl->dmac)dma_release_channel (cdns_ctrl->dmac);
@@ -2955,6 +2972,8 @@ free_buf_desc:static void cadence_nand_remove (struct cdns_nand_ctrl *cdns_ctrl) {cadence_nand_chips_cleanup (cdns_ctrl); +dma_unmap_resource (cdns_ctrl->dmac->device->dev, cdns_ctrl->io.iova_dma, + cdns_ctrl->io.size,DMA_BIDIRECTIONAL ,0 );cadence_nand_irq_cleanup (cdns_ctrl->irq, cdns_ctrl);kfree (cdns_ctrl->buf); dma_free_coherent(cdns_ctrl->dev, sizeof(struct cadence_nand_cdma_desc),
@@ -3019,7 +3038,9 @@ static int cadence_nand_dt_probe(struct cdns_ctrl->io.virt =devm_platform_get_and_ioremap_resource (ofdev,1 , &res);if (IS_ERR (cdns_ctrl->io.virt))return PTR_ERR (cdns_ctrl->io.virt); + cdns_ctrl->io.dma = res->start; + cdns_ctrl->io.size =resource_size (res); dt->clk =devm_clk_get (cdns_ctrl->dev,"nf_clk" );if (IS_ERR (dt->clk))
Greg Kroah-Hartman
maintainerPATCH 140/154 mtd: rawnand: cadence: fix incorrect device in dma_unmap_single
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Niravkumar L Rabara <[email protected]>
commit f37d135b42cb484bdecee93f56b9f483214ede78 upstream.
dma_map_single is using physical/bus device (DMA) but dma_unmap_single is using framework device(NAND controller), which is incorrect. Fixed dma_unmap_single to use correct physical/bus device.
--- drivers/mtd/nand/raw/cadence-nand-controller.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/mtd/nand/raw/cadence-nand-controller.c +2 -2
@@ -1863,12 +1863,12 @@ static int cadence_nand_slave_dma_transfdma_async_issue_pending (cdns_ctrl->dmac);wait_for_completion (&finished); -dma_unmap_single (cdns_ctrl->dev, buf_dma, len, dir); +dma_unmap_single (dma_dev->dev, buf_dma, len, dir);return 0 ; err_unmap: -dma_unmap_single (cdns_ctrl->dev, buf_dma, len, dir); +dma_unmap_single (dma_dev->dev, buf_dma, len, dir); err:dev_dbg (cdns_ctrl->dev,"Fall back to CPU I/O\n" );
Greg Kroah-Hartman
maintainerPATCH 141/154 perf/x86/intel: Fix event constraints for LNC
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kan Liang <[email protected]>
commit 782cffeec9ad96daa64ffb2d527b2a052fb02552 upstream.
According to the latest event list, update the event constraint tables for Lion Cove core.
The general rule (the event codes < 0x90 are restricted to counters 0-3.) has been removed. There is no restriction for most of the performance monitoring events.
--- arch/x86/events/intel/core.c | 20 +++++++------------- arch/x86/events/intel/ds.c | 2 +- 2 files changed, 8 insertions(+), 14 deletions(-)
arch/x86/events/intel/core.c +7 -13
@@ -397,34 +397,28 @@ static struct event_constraint intel_lncMETRIC_EVENT_CONSTRAINT (INTEL_TD_METRIC_FETCH_LAT ,6 ),METRIC_EVENT_CONSTRAINT (INTEL_TD_METRIC_MEM_BOUND ,7 ), +INTEL_EVENT_CONSTRAINT (0x20 ,0xf ), + +INTEL_UEVENT_CONSTRAINT (0x012a ,0xf ), +INTEL_UEVENT_CONSTRAINT (0x012b ,0xf ),INTEL_UEVENT_CONSTRAINT (0x0148 ,0x4 ),INTEL_UEVENT_CONSTRAINT (0x0175 ,0x4 ),INTEL_EVENT_CONSTRAINT (0x2e ,0x3ff ),INTEL_EVENT_CONSTRAINT (0x3c ,0x3ff ), -/* -* Generally event codes < 0x90 are restricted to counters 0-3. -* The 0x2E and 0x3C are exception, which has no restriction. -*/ -INTEL_EVENT_CONSTRAINT_RANGE (0x01 ,0x8f ,0xf ), -INTEL_UEVENT_CONSTRAINT (0x01a3 ,0xf ), -INTEL_UEVENT_CONSTRAINT (0x02a3 ,0xf ),INTEL_UEVENT_CONSTRAINT (0x08a3 ,0x4 ),INTEL_UEVENT_CONSTRAINT (0x0ca3 ,0x4 ),INTEL_UEVENT_CONSTRAINT (0x04a4 ,0x1 ),INTEL_UEVENT_CONSTRAINT (0x08a4 ,0x1 ),INTEL_UEVENT_CONSTRAINT (0x10a4 ,0x1 ),INTEL_UEVENT_CONSTRAINT (0x01b1 ,0x8 ), +INTEL_UEVENT_CONSTRAINT (0x01cd ,0x3fc ),INTEL_UEVENT_CONSTRAINT (0x02cd ,0x3 ), -INTEL_EVENT_CONSTRAINT (0xce ,0x1 ),INTEL_EVENT_CONSTRAINT_RANGE (0xd0 ,0xdf ,0xf ), -/* -* Generally event codes >= 0x90 are likely to have no restrictions. -* The exception are defined as above. -*/ -INTEL_EVENT_CONSTRAINT_RANGE (0x90 ,0xfe ,0x3ff ), + +INTEL_UEVENT_CONSTRAINT (0x00e0 ,0xf ),EVENT_CONSTRAINT_END };
arch/x86/events/intel/ds.c +1 -1
@@ -1178,7 +1178,7 @@ struct event_constraint intel_lnc_pebs_eINTEL_FLAGS_UEVENT_CONSTRAINT (0x100 ,0x100000000ULL ),/* INST_RETIRED.PREC_DIST */ INTEL_FLAGS_UEVENT_CONSTRAINT (0x0400 ,0x800000000ULL ), -INTEL_HYBRID_LDLAT_CONSTRAINT (0x1cd ,0x3ff ), +INTEL_HYBRID_LDLAT_CONSTRAINT (0x1cd ,0x3fc ),INTEL_HYBRID_STLAT_CONSTRAINT (0x2cd ,0x3 ),INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_LD (0x11d0 ,0xf ),/* MEM_INST_RETIRED.STLB_MISS_LOADS */ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_ST(0x12d0, 0xf), /* MEM_INST_RETIRED.STLB_MISS_STORES */
Greg Kroah-Hartman
maintainerPATCH 142/154 irqchip/gic-v3: Fix rk3399 workaround when secure interrupts are enabled
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <[email protected]>
commit 4cb77793842a351b39a030f77caebace3524840e upstream.
Christoph reports that their rk3399 system dies since commit 773c05f417fa1 ("irqchip/gic-v3: Work around insecure GIC integrations").
It appears that some rk3399 have secure payloads, and that the firmware sets SCR_EL3.FIQ==1. Obivously, disabling security in that configuration leads to even more problems.
Revisit the workaround by:
- making it rk3399 specific
- checking whether Group-0 is available, which is a good proxy for SCR_EL3.FIQ being 0
- either apply the workaround if Group-0 is available, or disable pseudo-NMIs if not
Note that this doesn't mean that the secure side is able to receive interrupts, as all interrupts are made non-secure anyway.
Clearly, nobody ever tested secure interrupts on this platform.
--- drivers/irqchip/irq-gic-v3.c | 49 ++++++++++++++++++++++++++++-------- 1 file changed, 38 insertions(+), 11 deletions(-)
drivers/irqchip/irq-gic-v3.c +38 -11
@@ -44,6 +44,7 @@ static u8 dist_prio_nmi __ro_after_init = GICV3_PRIO_NMI;#define FLAGS_WORKAROUND_GICR_WAKER_MSM8996 (1ULL << 0)#define FLAGS_WORKAROUND_CAVIUM_ERRATUM_38539 (1ULL << 1)#define FLAGS_WORKAROUND_ASR_ERRATUM_8601001 (1ULL << 2) +#define FLAGS_WORKAROUND_INSECURE (1ULL << 3)#define GIC_IRQ_TYPE_PARTITION (GIC_IRQ_TYPE_LPI + 1)
@@ -83,6 +84,8 @@ static DEFINE_STATIC_KEY_TRUE(supports_deactivate_key);#define GIC_LINE_NR min(GICD_TYPER_SPIS(gic_data.rdists.gicd_typer), 1020U)#define GIC_ESPI_NR GICD_TYPER_ESPIS(gic_data.rdists.gicd_typer) +static bool nmi_support_forbidden; +/* * There are 16 SGIs, though we only actually use 8 in Linux. The other 8 SGIs * are potentially stolen by the secure side. Some code, especially code dealing
@@ -163,21 +166,27 @@ static void __init gic_prio_init(void) {bool ds; + cpus_have_group0 =gic_has_group0 (); + ds =gic_dist_security_disabled (); -if (!ds) { -u32 val; +if ((gic_data.flags &FLAGS_WORKAROUND_INSECURE ) && !ds) { +if (cpus_have_group0) { +u32 val; - val =readl_relaxed (gic_data.dist_base +GICD_CTLR ); - val |=GICD_CTLR_DS ; -writel_relaxed (val, gic_data.dist_base +GICD_CTLR ); + val =readl_relaxed (gic_data.dist_base +GICD_CTLR ); + val |=GICD_CTLR_DS ; +writel_relaxed (val, gic_data.dist_base +GICD_CTLR ); - ds =gic_dist_security_disabled (); -if (ds) -pr_warn ("Broken GIC integration, security disabled" ); + ds =gic_dist_security_disabled (); +if (ds) +pr_warn ("Broken GIC integration, security disabled\n" ); + }else { +pr_warn ("Broken GIC integration, pNMI forbidden\n" ); + nmi_support_forbidden = true; + } } cpus_have_security_disabled = ds; - cpus_have_group0 =gic_has_group0 ();/* * How priority values are used by the GIC depends on two things:
@@ -209,7 +218,7 @@ static void __init gic_prio_init(void)* be in the non-secure range, we program the non-secure values into * the distributor to match the PMR values we want. */ -if (cpus_have_group0 & !cpus_have_security_disabled) { +if (cpus_have_group0 && !cpus_have_security_disabled) { dist_prio_irq =__gicv3_prio_to_ns (dist_prio_irq); dist_prio_nmi =__gicv3_prio_to_ns (dist_prio_nmi); }
@@ -1922,6 +1931,18 @@ static bool gic_enable_quirk_arm64_2941627(void *data)return true; } +static bool gic_enable_quirk_rk3399 (void *data) +{ +struct gic_chip_data *d = data; + +if (of_machine_is_compatible ("rockchip,rk3399" )) { + d->flags |=FLAGS_WORKAROUND_INSECURE ; +return true; + } + +return false; +} +static bool rd_set_non_coherent (void *data) {struct gic_chip_data *d = data;
@@ -1996,6 +2017,12 @@ static const struct gic_quirk gic_quirks[] = { .property = "dma-noncoherent", .init = rd_set_non_coherent, }, + { + .desc = "GICv3: Insecure RK3399 integration", + .iidr = 0x0000043b, + .mask = 0xff000fff, + .init = gic_enable_quirk_rk3399, + }, { } };
@@ -2004,7 +2031,7 @@ static void gic_enable_nmi_support(void) {int i; -if (!gic_prio_masking_enabled ()) +if (!gic_prio_masking_enabled () || nmi_support_forbidden)return ; rdist_nmi_refs = kcalloc(gic_data.ppi_nr + SGI_NR,
Signature · 1 line
2.48.1
Greg Kroah-Hartman
maintainerPATCH 143/154 smb: client: Add check for next_buffer in receive_encrypted_standard()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haoxiang Li <[email protected]>
commit 860ca5e50f73c2a1cef7eefc9d39d04e275417f7 upstream.
Add check for the return value of cifs_buf_get() and cifs_small_buf_get() in receive_encrypted_standard() to prevent null pointer dereference.
--- fs/smb/client/smb2ops.c | 4 ++++ 1 file changed, 4 insertions(+)
fs/smb/client/smb2ops.c +4 -0
@@ -4991,6 +4991,10 @@ one_more: next_buffer = (char *)cifs_buf_get (); else next_buffer = (char *)cifs_small_buf_get (); +if (!next_buffer) { +cifs_server_dbg (VFS ,"No memory for (large) SMB response\n" ); +return -1 ; + }memcpy (next_buffer, buf + next_cmd, pdu_length - next_cmd); }
Greg Kroah-Hartman
maintainerPATCH 144/154 EDAC/qcom: Correct interrupt enable register configuration
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Komal Bajaj <[email protected]>
commit c158647c107358bf1be579f98e4bb705c1953292 upstream.
The previous implementation incorrectly configured the cmn_interrupt_2_enable register for interrupt handling. Using cmn_interrupt_2_enable to configure Tag, Data RAM ECC interrupts would lead to issues like double handling of the interrupts (EL1 and EL3) as cmn_interrupt_2_enable is meant to be configured for interrupts which needs to be handled by EL3.
EL1 LLCC EDAC driver needs to use cmn_interrupt_0_enable register to configure Tag, Data RAM ECC interrupts instead of cmn_interrupt_2_enable.
--- drivers/edac/qcom_edac.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/edac/qcom_edac.c +2 -2
@@ -95,7 +95,7 @@ static int qcom_llcc_core_setup(struct l* Configure interrupt enable registers such that Tag, Data RAM related * interrupts are propagated to interrupt controller for servicing */ - ret =regmap_update_bits (llcc_bcast_regmap, drv->edac_reg_offset->cmn_interrupt_2_enable, + ret =regmap_update_bits (llcc_bcast_regmap, drv->edac_reg_offset->cmn_interrupt_0_enable,TRP0_INTERRUPT_ENABLE ,TRP0_INTERRUPT_ENABLE );if (ret)
@@ -113,7 +113,7 @@ static int qcom_llcc_core_setup(struct lif (ret)return ret; - ret =regmap_update_bits (llcc_bcast_regmap, drv->edac_reg_offset->cmn_interrupt_2_enable, + ret =regmap_update_bits (llcc_bcast_regmap, drv->edac_reg_offset->cmn_interrupt_0_enable,DRP0_INTERRUPT_ENABLE ,DRP0_INTERRUPT_ENABLE );if (ret)
Greg Kroah-Hartman
maintainerPATCH 145/154 ftrace: Correct preemption accounting for function tracing.
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Andrzej Siewior <[email protected]>
commit 57b76bedc5c52c66968183b5ef57234894c25ce7 upstream.
The function tracer should record the preemption level at the point when the function is invoked. If the tracing subsystem decrement the preemption counter it needs to correct this before feeding the data into the trace buffer. This was broken in the commit cited below while shifting the preempt-disabled section.
Use tracing_gen_ctx_dec() which properly subtracts one from the preemption counter on a preemptible kernel.
--- kernel/trace/trace_functions.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
kernel/trace/trace_functions.c +2 -4
@@ -193,7 +193,7 @@ function_trace_call(unsigned long ip, unif (bit <0 )return ; - trace_ctx =tracing_gen_ctx (); + trace_ctx =tracing_gen_ctx_dec (); cpu =smp_processor_id (); data =per_cpu_ptr (tr->array_buffer.data, cpu);
@@ -298,7 +298,6 @@ function_no_repeats_trace_call(unsignedstruct trace_array *tr = op->private;struct trace_array_cpu *data;unsigned int trace_ctx; -unsigned long flags;int bit;int cpu;
@@ -325,8 +324,7 @@ function_no_repeats_trace_call(unsignedif (is_repeat_check (tr, last_info, ip, parent_ip)) goto out; -local_save_flags (flags); - trace_ctx =tracing_gen_ctx_flags (flags); + trace_ctx =tracing_gen_ctx_dec ();process_repeats (tr, ip, parent_ip, last_info, trace_ctx);trace_function (tr, ip, parent_ip, trace_ctx);
Greg Kroah-Hartman
maintainerPATCH 146/154 ftrace: Fix accounting of adding subops to a manager ops
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <[email protected]>
commit 38b14061947fa546491656e3f5e388d4fedf8dba upstream.
Function graph uses a subops and manager ops mechanism to attach to ftrace. The manager ops connects to ftrace and the functions it connects to is defined by a list of subops that it manages.
The function hash that defines what the above ops attaches to limits the functions to attach if the hash has any content. If the hash is empty, it means to trace all functions.
The creation of the manager ops hash is done by iterating over all the subops hashes. If any of the subops hashes is empty, it means that the manager ops hash must trace all functions as well.
The issue is in the creation of the manager ops. When a second subops is attached, a new hash is created by starting it as NULL and adding the subops one at a time. But the NULL ops is mistaken as an empty hash, and once an empty hash is found, it stops the loop of subops and just enables all functions.
# echo "f:myevent1 kernel_clone" >> /sys/kernel/tracing/dynamic_events # cat /sys/kernel/tracing/enabled_functions kernel_clone (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60
# echo "f:myevent2 schedule_timeout" >> /sys/kernel/tracing/dynamic_events # cat /sys/kernel/tracing/enabled_functions trace_initcall_start_cb (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 run_init_process (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 try_to_run_init_process (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 x86_pmu_show_pmu_cap (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 cleanup_rapl_pmus (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 uncore_free_pcibus_map (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 uncore_types_exit (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 uncore_pci_exit.part.0 (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 kvm_shutdown (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 vmx_dump_msrs (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 vmx_cleanup_l1d_flush (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 [..]
Fix this by initializing the new hash to NULL and if the hash is NULL do not treat it as an empty hash but instead allocate by copying the content of the first sub ops. Then on subsequent iterations, the new hash will not be NULL, but the content of the previous subops. If that first subops attached to all functions, then new hash may assume that the manager ops also needs to attach to all functions.
--- kernel/trace/ftrace.c | 33 ++++++++++++++++++++++----------- 1 file changed, 22 insertions(+), 11 deletions(-)
kernel/trace/ftrace.c +22 -11
@@ -3219,15 +3219,22 @@ static struct ftrace_hash *copy_hash(str* The filter_hash updates uses just the append_hash() function * and the notrace_hash does not. */ -static int append_hash (struct ftrace_hash **hash,struct ftrace_hash *new_hash) +static int append_hash (struct ftrace_hash **hash,struct ftrace_hash *new_hash, +int size_bits) {struct ftrace_func_entry *entry;int size;int i; -/* An empty hash does everything */ -if (ftrace_hash_empty (*hash)) -return 0 ; +if (*hash) { +/* An empty hash does everything */ +if (ftrace_hash_empty (*hash)) +return 0 ; + }else { + *hash =alloc_ftrace_hash (size_bits); +if (!*hash) +return -ENOMEM ; + }/* If new_hash has everything make hash have everything */ if (ftrace_hash_empty (new_hash)) {
@@ -3291,16 +3298,18 @@ static int intersect_hash(struct ftrace_/* Return a new hash that has a union of all @ops->filter_hash entries */ static struct ftrace_hash *append_hashes (struct ftrace_ops *ops) { -struct ftrace_hash *new_hash; +struct ftrace_hash *new_hash =NULL ;struct ftrace_ops *subops; +int size_bits;int ret; - new_hash =alloc_ftrace_hash (ops->func_hash->filter_hash->size_bits); -if (!new_hash) -return NULL ; +if (ops->func_hash->filter_hash) + size_bits = ops->func_hash->filter_hash->size_bits; +else + size_bits =FTRACE_HASH_DEFAULT_BITS ;list_for_each_entry (subops, &ops->subop_list, list) { - ret =append_hash (&new_hash, subops->func_hash->filter_hash); + ret =append_hash (&new_hash, subops->func_hash->filter_hash, size_bits);if (ret <0 ) {free_ftrace_hash (new_hash);return NULL ;
@@ -3309,7 +3318,8 @@ static struct ftrace_hash *append_hashesif (ftrace_hash_empty (new_hash))break ; } -return new_hash; +/* Can't return NULL as that means this failed */ +return new_hash ? :EMPTY_HASH ; }/* Make @ops trace evenything except what all its subops do not trace */
@@ -3504,7 +3514,8 @@ int ftrace_startup_subops(struct ftrace_ filter_hash =alloc_and_copy_ftrace_hash (size_bits, ops->func_hash->filter_hash);if (!filter_hash)return -ENOMEM ; - ret =append_hash (&filter_hash, subops->func_hash->filter_hash); + ret =append_hash (&filter_hash, subops->func_hash->filter_hash, + size_bits);if (ret <0 ) {free_ftrace_hash (filter_hash);return ret;
Greg Kroah-Hartman
maintainerPATCH 147/154 ftrace: Do not add duplicate entries in subops manager ops
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <[email protected]>
commit 8eb4b09e0bbd30981305643229fe7640ad41b667 upstream.
Check if a function is already in the manager ops of a subops. A manager ops contains multiple subops, and if two or more subops are tracing the same function, the manager ops only needs a single entry in its hash.
--- kernel/trace/ftrace.c | 3 +++ 1 file changed, 3 insertions(+)
kernel/trace/ftrace.c +3 -0
@@ -5758,6 +5758,9 @@ __ftrace_match_addr(struct ftrace_hash *return -ENOENT ;free_hash_entry (hash, entry);return 0 ; + }else if (__ftrace_lookup_ip (hash, ip) !=NULL ) { +/* Already exists */ +return 0 ; } entry =add_hash_entry (hash, ip);
Greg Kroah-Hartman
maintainerPATCH 148/154 tracing: Fix using ret variable in tracing_set_tracer()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <[email protected]>
commit 22bec11a569983f39c6061cb82279e7de9e3bdfc upstream.
When the function tracing_set_tracer() switched over to using the guard() infrastructure, it did not need to save the 'ret' variable and would just return the value when an error arised, instead of setting ret and jumping to an out label.
When CONFIG_TRACER_SNAPSHOT is enabled, it had code that expected the "ret" variable to be initialized to zero and had set 'ret' while holding an arch_spin_lock() (not used by guard), and then upon releasing the lock it would check 'ret' and exit if set. But because ret was only set when an error occurred while holding the locks, 'ret' would be used uninitialized if there was no error. The code in the CONFIG_TRACER_SNAPSHOT block should be self contain. Make sure 'ret' is also set when no error occurred.
--- kernel/trace/trace.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
kernel/trace/trace.c +1 -2
@@ -6125,8 +6125,7 @@ int tracing_set_tracer(struct trace_arraif (t->use_max_tr) {local_irq_disable ();arch_spin_lock (&tr->max_lock); -if (tr->cond_snapshot) - ret = -EBUSY ; + ret = tr->cond_snapshot ? -EBUSY :0 ;arch_spin_unlock (&tr->max_lock);local_irq_enable ();if (ret)
Greg Kroah-Hartman
maintainerPATCH 149/154 net: pse-pd: Fix deadlock in current limit functions
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kory Maincent <[email protected]>
commit 488fb6effe03e20f38d34da7425de77bbd3e2665 upstream.
Fix a deadlock in pse_pi_get_current_limit and pse_pi_set_current_limit caused by consecutive mutex_lock calls. One in the function itself and another in pse_pi_get_voltage.
Resolve the issue by using the unlocked version of pse_pi_get_voltage instead.
--- drivers/net/pse-pd/pse_core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/pse-pd/pse_core.c +2 -2
@@ -309,7 +309,7 @@ static int pse_pi_get_current_limit(stru goto out; mW = ret; - ret =pse_pi_get_voltage (rdev); + ret =_pse_pi_get_voltage (rdev);if (!ret) {dev_err (pcdev->dev,"Voltage null\n" ); ret = -ERANGE ;
@@ -346,7 +346,7 @@ static int pse_pi_set_current_limit(stru id =rdev_get_id (rdev);mutex_lock (&pcdev->lock); - ret =pse_pi_get_voltage (rdev); + ret =_pse_pi_get_voltage (rdev);if (!ret) {dev_err (pcdev->dev,"Voltage null\n" ); ret = -ERANGE ;
Greg Kroah-Hartman
maintainerPATCH 150/154 sched_ext: Fix incorrect assumption about migration disabled tasks in task_can_run_on_remote_rq()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit f3f08c3acfb8860e07a22814a344e83c99ad7398 upstream.
While fixing migration disabled task handling, 32966821574c ("sched_ext: Fix migration disabled handling in targeted dispatches") assumed that a migration disabled task's ->cpus_ptr would only have the pinned CPU. While this is eventually true for migration disabled tasks that are switched out, ->cpus_ptr update is performed by migrate_disable_switch() which is called right before context_switch() in __scheduler(). However, the task is enqueued earlier during pick_next_task() via put_prev_task_scx(), so there is a race window where another CPU can see the task on a DSQ.
If the CPU tries to dispatch the migration disabled task while in that window, task_allowed_on_cpu() will succeed and task_can_run_on_remote_rq() will subsequently trigger SCHED_WARN(is_migration_disabled()).
WARNING: CPU: 8 PID: 1837 at kernel/sched/ext.c:2466 task_can_run_on_remote_rq+0x12e/0x140 Sched_ext: layered (enabled+all), task: runnable_at=-10ms RIP: 0010:task_can_run_on_remote_rq+0x12e/0x140 ... <TASK> consume_dispatch_q+0xab/0x220 scx_bpf_dsq_move_to_local+0x58/0xd0 bpf_prog_84dd17b0654b6cf0_layered_dispatch+0x290/0x1cfa bpf__sched_ext_ops_dispatch+0x4b/0xab balance_one+0x1fe/0x3b0 balance_scx+0x61/0x1d0 prev_balance+0x46/0xc0 __pick_next_task+0x73/0x1c0 __schedule+0x206/0x1730 schedule+0x3a/0x160 __do_sys_sched_yield+0xe/0x20 do_syscall_64+0xbb/0x1e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Fix it by converting the SCHED_WARN() back to a regular failure path. Also, perform the migration disabled test before task_allowed_on_cpu() test so that BPF schedulers which fail to handle migration disabled tasks can be noticed easily.
While at it, adjust scx_ops_error() message for !task_allowed_on_cpu() case for brevity and consistency.
--- kernel/sched/ext.c | 29 +++++++++++++++++++++-------- 1 file changed, 21 insertions(+), 8 deletions(-)
kernel/sched/ext.c +21 -8
@@ -2311,6 +2311,25 @@ static bool task_can_run_on_remote_rq(stSCHED_WARN_ON (task_cpu (p) == cpu);/* +* If @p has migration disabled, @p->cpus_ptr is updated to contain only +* the pinned CPU in migrate_disable_switch() while @p is being switched +* out. However, put_prev_task_scx() is called before @p->cpus_ptr is +* updated and thus another CPU may see @p on a DSQ inbetween leading to +* @p passing the below task_allowed_on_cpu() check while migration is +* disabled. +* +* Test the migration disabled state first as the race window is narrow +* and the BPF scheduler failing to check migration disabled state can +* easily be masked if task_allowed_on_cpu() is done first. +*/ +if (unlikely (is_migration_disabled (p))) { +if (trigger_error) +scx_ops_error ("SCX_DSQ_LOCAL[_ON] cannot move migration disabled %s[%d] from CPU %d to %d" , + p->comm, p->pid,task_cpu (p), cpu); +return false; + } + +/* * We don't require the BPF scheduler to avoid dispatching to offline * CPUs mostly for convenience but also because CPUs can go offline * between scx_bpf_dispatch() calls and here. Trigger error iff the
@@ -2318,17 +2337,11 @@ static bool task_can_run_on_remote_rq(st*/ if (!task_allowed_on_cpu (p, cpu)) {if (trigger_error) -scx_ops_error ("SCX_DSQ_LOCAL[_ON] verdict target cpu %d not allowed for %s[%d]" , -cpu_of (rq), p->comm, p->pid); +scx_ops_error ("SCX_DSQ_LOCAL[_ON] target CPU %d not allowed for %s[%d]" , + cpu, p->comm, p->pid);return false; } -/* -* If @p has migration disabled, @p->cpus_ptr only contains its current -* CPU and the above task_allowed_on_cpu() test should have failed. -*/ -SCHED_WARN_ON (is_migration_disabled (p)); -if (!scx_rq_online (rq))return false;
Greg Kroah-Hartman
maintainerPATCH 151/154 selftests/mm: build with -O2
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kevin Brodsky <[email protected]>
commit 46036188ea1f5266df23a6149dea0df1c77cd1c7 upstream.
The mm kselftests are currently built with no optimisation (-O0). It's unclear why, and besides being obviously suboptimal, this also prevents the pkeys tests from working as intended. Let's build all the tests with -O2.
[ Yifei: This commit also fix the failure of pkey_sighandler_tests_64,
which is also in linux-6.12.y, thus backport this commit. ]
--- tools/testing/selftests/mm/Makefile | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
tools/testing/selftests/mm/Makefile +8 -1
@@ -33,9 +33,16 @@ endif # LDLIBS. MAKEFLAGS += --no-builtin-rules -CFLAGS = -Wall -I $(top_srcdir) $(EXTRA_CFLAGS) $(KHDR_INCLUDES) $(TOOLS_INCLUDES) +CFLAGS = -Wall -O2 -I $(top_srcdir) $(EXTRA_CFLAGS) $(KHDR_INCLUDES) $(TOOLS_INCLUDES) LDLIBS = -lrt -lpthread -lm +# Some distributions (such as Ubuntu) configure GCC so that _FORTIFY_SOURCE is +# automatically enabled at -O1 or above. This triggers various unused-result +# warnings where functions such as read() or write() are called and their +# return value is not checked. Disable _FORTIFY_SOURCE to silence those +# warnings. +CFLAGS += -U_FORTIFY_SOURCE + TEST_GEN_FILES = cow TEST_GEN_FILES += compaction_test TEST_GEN_FILES += gup_longterm
Greg Kroah-Hartman
maintainerPATCH 152/154 arm64: dts: rockchip: change eth phy mode to rgmii-id for orangepi r1 plus lts
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tianling Shen <[email protected]>
commit a6a7cba17c544fb95d5a29ab9d9ed4503029cb29 upstream.
In general the delay should be added by the PHY instead of the MAC, and this improves network stability on some boards which seem to need different delay.
--- arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus-lts.dts | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus-lts.dts +4 -2
@@ -15,9 +15,11 @@ }; &gmac2io { + /delete-property/ tx_delay; + /delete-property/ rx_delay; + phy-handle = <&yt8531c>; - tx_delay = <0x19>; - rx_delay = <0x05>; + phy-mode = "rgmii-id"; mdio { /delete-node/ ethernet-phy@1;
Greg Kroah-Hartman
maintainerPATCH 153/154 drm/amdgpu/gfx9: manually control gfxoff for CS on RV
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit b35eb9128ebeec534eed1cefd6b9b1b7282cf5ba upstream.
When mesa started using compute queues more often we started seeing additional hangs with compute queues. Disabling gfxoff seems to mitigate that. Manually control gfxoff and gfx pg with command submissions to avoid any issues related to gfxoff. KFD already does the same thing for these chips.
v2: limit to compute
v3: limit to APUs
v4: limit to Raven/PCO
v5: only update the compute ring_funcs
v6: Disable GFX PG
v7: adjust order
--- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 32 ++++++++++++++++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +30 -2
@@ -7415,6 +7415,34 @@ static void gfx_v9_0_ring_emit_cleaner_samdgpu_ring_write (ring,0 );/* RESERVED field, programmed to zero */ } +static void gfx_v9_0_ring_begin_use_compute (struct amdgpu_ring *ring) +{ +struct amdgpu_device *adev = ring->adev; + +amdgpu_gfx_enforce_isolation_ring_begin_use (ring); + +/* Raven and PCO APUs seem to have stability issues +* with compute and gfxoff and gfx pg. Disable gfx pg during +* submission and allow again afterwards. +*/ +if (amdgpu_ip_version (adev,GC_HWIP ,0 ) ==IP_VERSION (9 ,1 ,0 )) +gfx_v9_0_set_powergating_state (adev,AMD_PG_STATE_UNGATE ); +} + +static void gfx_v9_0_ring_end_use_compute (struct amdgpu_ring *ring) +{ +struct amdgpu_device *adev = ring->adev; + +/* Raven and PCO APUs seem to have stability issues +* with compute and gfxoff and gfx pg. Disable gfx pg during +* submission and allow again afterwards. +*/ +if (amdgpu_ip_version (adev,GC_HWIP ,0 ) ==IP_VERSION (9 ,1 ,0 )) +gfx_v9_0_set_powergating_state (adev,AMD_PG_STATE_GATE ); + +amdgpu_gfx_enforce_isolation_ring_end_use (ring); +} +static const struct amd_ip_funcs gfx_v9_0_ip_funcs = { .name ="gfx_v9_0" , .early_init = gfx_v9_0_early_init,
@@ -7591,8 +7619,8 @@ static const struct amdgpu_ring_funcs gf .emit_wave_limit = gfx_v9_0_emit_wave_limit, .reset = gfx_v9_0_reset_kcq, .emit_cleaner_shader = gfx_v9_0_ring_emit_cleaner_shader, - .begin_use = amdgpu_gfx_enforce_isolation_ring_begin_use, - .end_use = amdgpu_gfx_enforce_isolation_ring_end_use, + .begin_use = gfx_v9_0_ring_begin_use_compute, + .end_use = gfx_v9_0_ring_end_use_compute, };static const struct amdgpu_ring_funcs gfx_v9_0_ring_funcs_kiq = {
Greg Kroah-Hartman
maintainerPATCH 154/154 drm/amdgpu: bump version for RV/PCO compute fix
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 55ed2b1b50d029dd7e49a35f6628ca64db6d75d8 upstream.
Bump the driver version for RV/PCO compute stability fix so mesa can use this check to enable compute queues on RV/PCO.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +2 -1
@@ -119,9 +119,10 @@* - 3.58.0 - Add GFX12 DCC support * - 3.59.0 - Cleared VRAM * - 3.60.0 - Add AMDGPU_TILING_GFX12_DCC_WRITE_COMPRESS_DISABLE (Vulkan requirement) +* - 3.61.0 - Contains fix for RV/PCO compute queues */ #define KMS_DRIVER_MAJOR 3 -#define KMS_DRIVER_MINOR 60 +#define KMS_DRIVER_MINOR 61#define KMS_DRIVER_PATCHLEVEL 0/*
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.17 release. There are 154 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Feb 2025 14:25:29 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.17-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Am 24.02.2025 um 15:33 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.12.17 release. There are 154 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.17 release. There are 154 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Feb 2025 14:25:29 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.17-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Jon Hunter
maintainerQuoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.17 release. There are 154 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Feb 2025 14:25:29 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.17-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Failures detected for Tegra ...
Test results for stable-v6.12:
10 builds: 10 pass, 0 fail
32 boots: 26 pass, 6 fail
72 tests: 64 pass, 8 failLinux version: 6.12.17-rc1-g497e403c6ee0
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Boot failures: tegra124-jetson-tk1, tegra210-p2371-2180,
tegra30-cardhu-a04
Test failures: tegra20-ventana: devices
tegra20-ventana: tegra-audio-boot-sanity.sh
tegra210-p3450-0000: devices
tegra210-p3450-0000: mmc-dd-urandom.shJon
Jon Hunter
maintainerQuoted 32 lines · Jon Hunter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.17 release. There are 154 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Feb 2025 14:25:29 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.17-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Failures detected for Tegra ...
Test results for stable-v6.12:
10 builds: 10 pass, 0 fail 32 boots: 26 pass, 6 fail 72 tests: 64 pass, 8 failLinux version: 6.12.17-rc1-g497e403c6ee0
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-0000, tegra30-cardhu-a04
Quoted 7 lines
Boot failures: tegra124-jetson-tk1, tegra210-p2371-2180,
tegra30-cardhu-a04Test failures: tegra20-ventana: devices
tegra20-ventana: tegra-audio-boot-sanity.sh tegra210-p3450-0000: devices tegra210-p3450-0000: mmc-dd-urandom.sh
I am seeing some gpio related failures ...
[ 2.524869] gpiochip_add_data_with_key: GPIOs 0..255 (tegra-gpio) failed to register, -22 [ 2.533066] tegra-gpio 6000d000.gpio: probe with driver tegra-gpio failed with error -22
So I am wondering if this is the same issue Mark reported?
Jon
Signature · 1 line
nvpublic
Greg Kroah-Hartman
maintainerQuoted 43 lines · Jon Hunter
Quoted 32 lines · Jon Hunter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.17 release. There are 154 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Feb 2025 14:25:29 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.17-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Failures detected for Tegra ...
Test results for stable-v6.12:
10 builds: 10 pass, 0 fail 32 boots: 26 pass, 6 fail 72 tests: 64 pass, 8 failLinux version: 6.12.17-rc1-g497e403c6ee0
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-0000, tegra30-cardhu-a04Quoted 7 lines
Boot failures: tegra124-jetson-tk1, tegra210-p2371-2180,
tegra30-cardhu-a04Test failures: tegra20-ventana: devices
tegra20-ventana: tegra-audio-boot-sanity.sh tegra210-p3450-0000: devices tegra210-p3450-0000: mmc-dd-urandom.sh
Quoted 6 lines
I am seeing some gpio related failures ...
[ 2.524869] gpiochip_add_data_with_key: GPIOs 0..255 (tegra-gpio) failed to register, -22 [ 2.533066] tegra-gpio 6000d000.gpio: probe with driver tegra-gpio failed with error -22So I am wondering if this is the same issue Mark reported?
Probably, I'll go drop this and push out a -rc2
thanks,
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.17 release. There are 154 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Feb 2025 14:25:29 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.17-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).