Re: [linux-yocto] Trial merge of v5.15.151 v6.1.81 for linux-yocto
In message: Trial merge of v5.15.151 v6.1.81 for linux-yocto on 07/03/2024 Kevin Hao wrote: > Hi Bruce, > > This is a trial merge of the stable kernel v5.15.151 v6.1.81 for the > following branches in the linux-yocto. > ccbd1ffa2151 v5.15/standard/sdkv5.10/axxia > 45a604286a8a v5.15/standard/preempt-rt/sdkv5.10/axxia > ed7ee8867f98 v5.15/standard/base > 303f3510d546 v5.15/standard/preempt-rt/base > e6a8d690b275 v5.15/standard/cn-sdkv5.4/octeon >#Have textual conflicts > cdda1db17978 v5.15/standard/preempt-rt/cn-sdkv5.4/octeon >#Have textual conflicts > 7ad665e2ee6f v5.15/standard/cn-sdkv5.15/octeon > 4d507e265800 v5.15/standard/preempt-rt/cn-sdkv5.15/octeon > 60fb18180138 v5.15/standard/ti-sdk-5.10/ti-j72xx > cc8931885d08 v5.15/standard/preempt-rt/ti-sdk-5.10/ti-j72xx > 992450ca5997 v5.15/standard/nxp-sdk-5.15/nxp-soc >#Have textual conflicts > 26dcbff9fd5d v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-soc >#Have textual conflicts > a83c41757863 v5.15/standard/bcm-2xxx-rpi > c81d74769a8b v5.15/standard/preempt-rt/bcm-2xxx-rpi > 35f83bf4a29f v5.15/standard/nxp-sdk-5.15/nxp-s32g > 247fbcf91f26 v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g > c3685522cc88 v5.15/standard/intel-sdk-5.15/intel-socfpga > 20baa09a7ecf v5.15/standard/preempt-rt/intel-sdk-5.15/intel-socfpga > 84503d026331 v5.15/standard/x86 > 7fb9e90bd815 v5.15/standard/preempt-rt/x86 > 45a39a5bbc88 v5.15/standard/sdkv5.15/xlnx-soc > 88d987b19134 v5.15/standard/preempt-rt/sdkv5.15/xlnx-soc > b465e20123b2 v6.1/standard/sdkv5.10/axxia > 897727c08b89 v6.1/standard/preempt-rt/sdkv5.10/axxia > 8cc0832f0045 v6.1/standard/base > 84148641e4f7 v6.1/standard/preempt-rt/base > 843d29790aa3 v6.1/standard/ti-sdk-6.1/ti-j7xxx > 9c2153dd26a7 v6.1/standard/preempt-rt/ti-sdk-6.1/ti-j7xxx > 7db771328510 v6.1/standard/nxp-sdk-6.1/nxp-soc >#Have textual conflicts > c874ecb3d42d v6.1/standard/preempt-rt/nxp-sdk-6.1/nxp-soc >#Have textual conflicts > 9d281c5fc7a8 v6.1/standard/cn-sdkv5.15/octeon > 246b977c v6.1/standard/preempt-rt/cn-sdkv5.15/octeon > 5952aa1031b1 v6.1/standard/microchip-polarfire-soc > 51a32a5a3f57 v6.1/standard/preempt-rt/microchip-polarfire-soc > 523d2c24f34e v6.1/standard/bcm-2xxx-rpi > b9eb9d3f6560 v6.1/standard/preempt-rt/bcm-2xxx-rpi > 231cd33078f4 v6.1/standard/nxp-sdk-5.15/nxp-s32g > 951687466ba3 v6.1/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g > 848e8f4c70cc v6.1/standard/intel-sdk-6.1/intel-socfpga > 7f1938fe7822 v6.1/standard/preempt-rt/intel-sdk-6.1/intel-socfpga > 13210ab6c69e v6.1/standard/x86 > 56832dd8c568 v6.1/standard/preempt-rt/x86 > aaa9e44db471 v6.1/standard/sdkv6.1/xlnx-soc > e500c6b3be9f v6.1/standard/preempt-rt/sdkv6.1/xlnx-soc > > - There are several minor merge conflicts on v5.15 cn96xx and nxp branches. > - Some nasty merge conflicts on the v6.1 nxp branches. Thanks Kevin, I held off on the 5.15 merge while working through the partition issues with the older -stable merges. But since that seems better now, I've gone ahead and updated 5.15 to .151 Bruce > > All the branches have passed my build test. I have pushed all these branches > to: > https://github.com/haokexin/linux > > You can use this as a reference for the linux-yocto stable kernel bump. > > Thanks, > Kevin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13677): https://lists.yoctoproject.org/g/linux-yocto/message/13677 Mute This Topic: https://lists.yoctoproject.org/mt/104783790/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [linux-yocto v6.5 1/1] neighbour: Fix __randomize_layout crash in struct neighbour
merged.
I'm not updating the 6.5 SRCREVs very often now, so
if you need this sooner rather than later, I'd suggest
bumping your SRCREVs locally.
Bruce
In message: [linux-yocto v6.5 1/1] neighbour: Fix __randomize_layout crash in
struct neighbour
on 12/03/2024 Jon Mason wrote:
> From: "Gustavo A. R. Silva"
>
> Previously, one-element and zero-length arrays were treated as true
> flexible arrays, even though they are actually "fake" flex arrays.
> The __randomize_layout would leave them untouched at the end of the
> struct, similarly to proper C99 flex-array members.
>
> However, this approach changed with commit 1ee60356c2dc ("gcc-plugins:
> randstruct: Only warn about true flexible arrays"). Now, only C99
> flexible-array members will remain untouched at the end of the struct,
> while one-element and zero-length arrays will be subject to randomization.
>
> Fix a `__randomize_layout` crash in `struct neighbour` by transforming
> zero-length array `primary_key` into a proper C99 flexible-array member.
>
> Fixes: 1ee60356c2dc ("gcc-plugins: randstruct: Only warn about true flexible
> arrays")
> Closes:
> https://lore.kernel.org/linux-hardening/20231124102458.gb1503...@e124191.cambridge.arm.com/
> Signed-off-by: Gustavo A. R. Silva
> Reviewed-by: Kees Cook
> Tested-by: Joey Gouly
> Link: https://lore.kernel.org/r/ZWJoRsJGnCPdJ3+2@work
> Signed-off-by: Paolo Abeni
> ---
> include/net/neighbour.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/net/neighbour.h b/include/net/neighbour.h
> index 07022bb0d44d..0d28172193fa 100644
> --- a/include/net/neighbour.h
> +++ b/include/net/neighbour.h
> @@ -162,7 +162,7 @@ struct neighbour {
> struct rcu_head rcu;
> struct net_device *dev;
> netdevice_tracker dev_tracker;
> - u8 primary_key[0];
> + u8 primary_key[];
> } __randomize_layout;
>
> struct neigh_ops {
> --
> 2.30.2
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13676):
https://lists.yoctoproject.org/g/linux-yocto/message/13676
Mute This Topic: https://lists.yoctoproject.org/mt/104893318/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto][v5.10/standard/base && v5.10/standard/preempt-rt/base][PATCH 1/2] blk-mq: Introduce the BLK_MQ_F_NO_SCHED_BY_DEFAULT flag
Since this is requested for the common branches and
hence all BSPs (This is the right place for a patch
like this) ... can you provide some extra context
about how they were identified (and tested).
Similar to my earlier comment, these in theory should
be nominated for -stable.
Bruce
In message: [linux-yocto][v5.10/standard/base &&
v5.10/standard/preempt-rt/base][PATCH 1/2] blk-mq: Introduce the
BLK_MQ_F_NO_SCHED_BY_DEFAULT flag
on 12/03/2024 Wentao Zhang wrote:
> From: Bart Van Assche
>
> commit 90b7198001f23ea37d3b46dc631bdaa2357a20b1 upstream.
>
> elevator_get_default() uses the following algorithm to select an I/O
> scheduler from inside add_disk():
> - In case of a single hardware queue or if sharing hardware queues across
> multiple request queues (BLK_MQ_F_TAG_HCTX_SHARED), use mq-deadline.
> - Otherwise, use 'none'.
>
> This is a good choice for most but not for all block drivers. Make it
> possible to override the selection of mq-deadline with a new flag,
> namely BLK_MQ_F_NO_SCHED_BY_DEFAULT.
>
> Cc: Christoph Hellwig
> Cc: Ming Lei
> Cc: Tetsuo Handa
> Cc: Martijn Coenen
> Cc: Jaegeuk Kim
> Signed-off-by: Bart Van Assche
> Link: https://lore.kernel.org/r/20210805174200.3250718-2-bvanass...@acm.org
> Signed-off-by: Jens Axboe
> Signed-off-by: Wentao Zhang
> ---
> block/elevator.c | 3 +++
> include/linux/blk-mq.h | 6 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/block/elevator.c b/block/elevator.c
> index 2f962662c32a..f762b2af1d2a 100644
> --- a/block/elevator.c
> +++ b/block/elevator.c
> @@ -622,6 +622,9 @@ static inline bool elv_support_iosched(struct
> request_queue *q)
> */
> static struct elevator_type *elevator_get_default(struct request_queue *q)
> {
> + if (q->tag_set && q->tag_set->flags & BLK_MQ_F_NO_SCHED_BY_DEFAULT)
> + return NULL;
> +
> if (q->nr_hw_queues != 1)
> return NULL;
>
> diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
> index f8ea27423d1d..39526279fbd3 100644
> --- a/include/linux/blk-mq.h
> +++ b/include/linux/blk-mq.h
> @@ -398,7 +398,13 @@ enum {
> BLK_MQ_F_STACKING = 1 << 2,
> BLK_MQ_F_TAG_HCTX_SHARED = 1 << 3,
> BLK_MQ_F_BLOCKING = 1 << 5,
> + /* Do not allow an I/O scheduler to be configured. */
> BLK_MQ_F_NO_SCHED = 1 << 6,
> + /*
> + * Select 'none' during queue registration in case of a single hwq
> + * or shared hwqs instead of 'mq-deadline'.
> + */
> + BLK_MQ_F_NO_SCHED_BY_DEFAULT= 1 << 7,
> BLK_MQ_F_ALLOC_POLICY_START_BIT = 8,
> BLK_MQ_F_ALLOC_POLICY_BITS = 1,
>
> --
> 2.31.1
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13675):
https://lists.yoctoproject.org/g/linux-yocto/message/13675
Mute This Topic: https://lists.yoctoproject.org/mt/104880299/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto][linux-yocto v5.15] kernel code for marvell cn96xx
In message: [linux-yocto][linux-yocto v5.15] kernel code for marvell cn96xx on 11/03/2024 Ruiqiang Hao via lists.yoctoproject.org wrote: > Hi Bruce, > > Please help to merge this patch into our linux-yocto repo. > > repo: > linux-yocto > branch: > v5.15/standard/cn-sdkv5.15/octeon > v5.15/standard/preempt-rt/cn-sdkv5.15/octeon merged. Bruce > > Thanks, > Ruiqiang > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13674): https://lists.yoctoproject.org/g/linux-yocto/message/13674 Mute This Topic: https://lists.yoctoproject.org/mt/104859344/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto][v5.15/standard/base][PATCH] locking/rwsem: Disable preemption while trying for rwsem lock
In message: [linux-yocto][v5.15/standard/base][PATCH] locking/rwsem: Disable
preemption while trying for rwsem lock
on 10/03/2024 Li Wang via lists.yoctoproject.org wrote:
> From: Gokul krishna Krishnakumar
>
> commit 48dfb5d2560d36fb16c7d430c229d1604ea7d185 upstream
>
> Make the region inside the rwsem_write_trylock non preemptible.
>
> We observe RT task is hogging CPU when trying to acquire rwsem lock
> which was acquired by a kworker task but before the rwsem owner was set.
>
> Here is the scenario:
> 1. CFS task (affined to a particular CPU) takes rwsem lock.
>
> 2. CFS task gets preempted by a RT task before setting owner.
>
> 3. RT task (FIFO) is trying to acquire the lock, but spinning until
> RT throttling happens for the lock as the lock was taken by CFS task.
>
> This patch attempts to fix the above issue by disabling preemption
> until owner is set for the lock. While at it also fix the issues
> at the places where rwsem_{set,clear}_owner() are called.
>
> This also adds lockdep annotation of preemption disable in
> rwsem_{set,clear}_owner() on Peter Z. suggestion.
Any thoughts on why this hasn't been picked up by -stable ?
Bruce
>
> Signed-off-by: Gokul krishna Krishnakumar
> Signed-off-by: Mukesh Ojha
> Signed-off-by: Peter Zijlstra (Intel)
> Reviewed-by: Waiman Long
> Link:
> https://lore.kernel.org/r/1662661467-24203-1-git-send-email-quic_mo...@quicinc.com
> Signed-off-by: Beniamin Sandu
> Signed-off-by: Li Wang
> ---
> kernel/locking/rwsem.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c
> index f0287a16b4ec..4a38d32b89fa 100644
> --- a/kernel/locking/rwsem.c
> +++ b/kernel/locking/rwsem.c
> @@ -133,14 +133,19 @@
> * the owner value concurrently without lock. Read from owner, however,
> * may not need READ_ONCE() as long as the pointer value is only used
> * for comparison and isn't being dereferenced.
> + *
> + * Both rwsem_{set,clear}_owner() functions should be in the same
> + * preempt disable section as the atomic op that changes sem->count.
> */
> static inline void rwsem_set_owner(struct rw_semaphore *sem)
> {
> + lockdep_assert_preemption_disabled();
> atomic_long_set(>owner, (long)current);
> }
>
> static inline void rwsem_clear_owner(struct rw_semaphore *sem)
> {
> + lockdep_assert_preemption_disabled();
> atomic_long_set(>owner, 0);
> }
>
> @@ -251,13 +256,16 @@ static inline bool rwsem_read_trylock(struct
> rw_semaphore *sem, long *cntp)
> static inline bool rwsem_write_trylock(struct rw_semaphore *sem)
> {
> long tmp = RWSEM_UNLOCKED_VALUE;
> + bool ret = false;
>
> + preempt_disable();
> if (atomic_long_try_cmpxchg_acquire(>count, ,
> RWSEM_WRITER_LOCKED)) {
> rwsem_set_owner(sem);
> - return true;
> + ret = true;
> }
>
> - return false;
> + preempt_enable();
> + return ret;
> }
>
> /*
> @@ -1341,8 +1349,10 @@ static inline void __up_write(struct rw_semaphore *sem)
> DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) &&
> !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE), sem);
>
> + preempt_disable();
> rwsem_clear_owner(sem);
> tmp = atomic_long_fetch_add_release(-RWSEM_WRITER_LOCKED, >count);
> + preempt_enable();
> if (unlikely(tmp & RWSEM_FLAG_WAITERS))
> rwsem_wake(sem);
> }
> --
> 2.25.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13673):
https://lists.yoctoproject.org/g/linux-yocto/message/13673
Mute This Topic: https://lists.yoctoproject.org/mt/104857955/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [linux-yocto v6.5 1/1] neighbour: Fix __randomize_layout crash in struct neighbour
From: "Gustavo A. R. Silva"
Previously, one-element and zero-length arrays were treated as true
flexible arrays, even though they are actually "fake" flex arrays.
The __randomize_layout would leave them untouched at the end of the
struct, similarly to proper C99 flex-array members.
However, this approach changed with commit 1ee60356c2dc ("gcc-plugins:
randstruct: Only warn about true flexible arrays"). Now, only C99
flexible-array members will remain untouched at the end of the struct,
while one-element and zero-length arrays will be subject to randomization.
Fix a `__randomize_layout` crash in `struct neighbour` by transforming
zero-length array `primary_key` into a proper C99 flexible-array member.
Fixes: 1ee60356c2dc ("gcc-plugins: randstruct: Only warn about true flexible
arrays")
Closes:
https://lore.kernel.org/linux-hardening/20231124102458.gb1503...@e124191.cambridge.arm.com/
Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Kees Cook
Tested-by: Joey Gouly
Link: https://lore.kernel.org/r/ZWJoRsJGnCPdJ3+2@work
Signed-off-by: Paolo Abeni
---
include/net/neighbour.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index 07022bb0d44d..0d28172193fa 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -162,7 +162,7 @@ struct neighbour {
struct rcu_head rcu;
struct net_device *dev;
netdevice_tracker dev_tracker;
- u8 primary_key[0];
+ u8 primary_key[];
} __randomize_layout;
struct neigh_ops {
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13672):
https://lists.yoctoproject.org/g/linux-yocto/message/13672
Mute This Topic: https://lists.yoctoproject.org/mt/104893318/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [linux-yocto v6.5 0/1] backport Fix __randomize_layout crash in struct neighbour
Linux kernel commit 9aea191c29e18f7c044a2f95a2da7f7b7fdd0449, “gcc-plugins: randstruct: Only warn about true flexible arrays” (backported to 6.5.13 as part of the stable process) introduces a bug, which is preventing networking from functioning (and logging lots of errors in dmesg). Linux kernel commit 45b3fae4675dc1d4ee2d7aefa19d85ee4f891377 resolves the issue. The fix was originally added to the v6.7 kernel and has been back ported to the v6.6 kernel, but not the v6.5 kernel (yet). A quick search shows the initial (buggy) patch only brought back to v6.5. So, this is only being seen on nanbield. The errors being seen are networking related. For example, on the fvp-base machine in meta-arm, I see the following: … Configuring network interfaces... [ cut here ] refcount_t: underflow; use-after-free. WARNING: CPU: 7 PID: 0 at /lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148 Modules linked in: CPU: 7 PID: 0 Comm: swapper/7 Tainted: GT 6.5.13-yocto-standard #1 Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.10 10/01/2023 pstate: 6149 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : refcount_warn_saturate+0xf4/0x148 lr : refcount_warn_saturate+0xf4/0x148 sp : ffc081703e10 x29: ffc081703e10 x28: ff88ff5d2b38 x27: 000a x26: x25: ffc0810d0008 x24: ffc0815d1518 x23: 0009 x22: ffc0814b8ac0 x21: ff88803e x20: x19: ff8882d44f00 x18: ffc082ddbc28 x17: ffc87e4f x16: ffc08170 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720 x11: 0720072007200720 x10: ffc08149d368 x9 : ffc0800ae968 x8 : ffc081445368 x7 : efff x6 : 8000f000 x5 : x4 : x3 : x2 : x1 : x0 : ff88803e Call trace: refcount_warn_saturate+0xf4/0x148 ip6_dst_destroy+0x1c4/0x1e8 dst_destroy+0x48/0x1b8 dst_destroy_rcu+0x1c/0x30 rcu_core+0x2e8/0xa50 rcu_core_si+0x18/0x30 __do_softirq+0x118/0x394 do_softirq+0x18/0x30 call_on_irq_stack+0x24/0x58 do_softirq_own_stack+0x24/0x38 irq_exit_rcu+0x98/0xd8 el1_interrupt+0x38/0x68 el1h_64_irq_handler+0x18/0x28 el1h_64_irq+0x64/0x68 default_idle_call+0x74/0x140 do_idle+0x218/0x278 cpu_startup_entry+0x40/0x50 secondary_start_kernel+0x128/0x158 __secondary_switched+0xb8/0xc0 ---[ end trace ]--- done. Starting system message bus: dbus. Starting Connection Manager Starting Xserver Starting Dropbear SSH server: dropbear. Starting rpcbind daemon... X.Org X Server 1.21.1.11 X Protocol Version 11, Revision 0 Current Operating System: Linux fvp-base 6.5.13-yocto-standard #1 SMP PREEMPT Thu Dec 14 16:41:11 UTC 2023 aarch64 Kernel command line: BOOT_IMAGE=/Image root=PARTUUID=0fb89d8b-b627-4ac1-9e0d-474bb65140d2 rootwait rootwait rootfstype=ext4 Current version of pixman: 0.42.2 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Tue Mar 12 19:41:29 2024 (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) Fatal server error: (EE) no screens found(EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file. done. [ cut here ] WARNING: CPU: 5 PID: 467 at /include/net/neighbour.h:522 ip6_finish_output2+0x5e4/0x768 Modules linked in: CPU: 5 PID: 467 Comm: xinit Tainted: GW T 6.5.13-yocto-standard #1 Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.10 10/01/2023 pstate: a149 (NzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : ip6_finish_output2+0x5e4/0x768 lr : ip6_finish_output2+0x490/0x768 sp : ffc082e236f0 x29: ffc082e23730 x28: 2800 x27: ffc082e239b0 x26: ff8883f98000 x25: ff8880d745f0 x24: ff8880d74608 x23: ff8882de80e0 x22: dfdfdfd0 x21: dfdfdfcf x20: x19: ff88809f62a0 x18: 0014 x17: ca50a0b9 x16: 4f93a896 x15: 043a3fc2 x14: 966530e2 x13: 0100 x12: x11: a4790321 x10: 0003 x9 : ffc080c92fa0 x8 : x7 : f18eea13 x6 : de53d701 x5 : a4790321 x4 : 63ba84c0 x3 : ffc0815ab640 x2 : ff8882ff6740 x1 : 00f0 x0 : ff8880d745f0 Call trace: ip6_finish_output2+0x5e4/0x768 ip6_finish_output+0x1d8/0x388 ip6_output+0x80/0x1d0 ip6_xmit+0x47c/0x6e8
Re: [yocto] [meta-lts-mixins][kirkstone/rust][PATCH 10/11] rust: reproducibility issue fix with v1.75
On Tue, 12 Mar 2024, Jose Quaresma wrote:
> Hi Sundeep,
>
> Sundeep KOKKONDA escreveu (terça,
> 12/03/2024 à(s) 03:45):
>
> > Hello,
> >
> > FYI. There is a V2 available for this patch with upstream fix backport.
> > You can consider that.
> >
> > https://lists.openembedded.org/g/openembedded-core/message/196856
>
>
> Sure, when this one is integrated on the master branch I can create a
> backport for it too.
> Thanks for the notification.
I got back from a couple of weeks out of the office (conference followed
by vacation) yesterday, I aim to test the patch series locally and merge
it to kirkstone/rust in the next couple of days. We now seem to need
newer than Rust 1.70 for a recipe in AGL, so I'll likely be switching AGL
to using kirkstone/rust as well.
Thanks,
Scott
> > On 11-Mar-24 21:54, Jose Quaresma wrote:
> > > CAUTION: This email comes from a non Wind River email account!
> > > Do not click links or open attachments unless you recognize the sender
> > and know the content is safe.
> > >
> > > From: Yash Shinde
> > >
> > > With 1.75 rust release, the '.rustc' section of shared object libs are
> > embedded with absolute path names which is casuing reproducibiluty issues.
> > > This change will fix the path name format back to '/rust/$hash' as in
> > earlier versions.
> > >
> > > Below are the links for detailed bug description & discusssion with
> > upstream rust.
> > > https://github.com/rust-lang/rust/issues/120825#issuecomment-1964307219
> > > https://github.com/rust-lang/rust/issues/120825#issuecomment-1964652656
> > >
> > > Signed-off-by: Sundeep KOKKONDA
> > > Signed-off-by: Yash Shinde
> > > Signed-off-by: Richard Purdie
> > > Signed-off-by: Jose Quaresma
> > > ---
> > > .../files/repro-issue-fix-with-v175.patch | 23 +++
> > > recipes-devtools/rust/rust-source.inc | 1 +
> > > 2 files changed, 24 insertions(+)
> > > create mode 100644
> > recipes-devtools/rust/files/repro-issue-fix-with-v175.patch
> > >
> > > diff --git a/recipes-devtools/rust/files/repro-issue-fix-with-v175.patch
> > b/recipes-devtools/rust/files/repro-issue-fix-with-v175.patch
> > > new file mode 100644
> > > index 000..6840baf
> > > --- /dev/null
> > > +++ b/recipes-devtools/rust/files/repro-issue-fix-with-v175.patch
> > > @@ -0,0 +1,23 @@
> > > +rust: reproducibility issue fix with v1.75
> > > +
> > > +With 1.75 rust release, the '.rustc' section of shared object libs are
> > embedded with absolute path names which is casuing reproducibiluty issues.
> > > +This change will fix the path name format back to '/rust/$hash' as in
> > earlier versions.
> > > +
> > > +Below are the links for detailed bug description & discusssion with
> > upstream rust.
> > > +https://github.com/rust-lang/rust/issues/120825#issuecomment-1964307219
> > > +https://github.com/rust-lang/rust/issues/120825#issuecomment-1964652656
> > > +
> > > +Upstream-Status: Inappropriate [patches need rework]
> > > +Signed-off-by: Sundeep KOKKONDA
> > > +---
> > > +--- a/compiler/rustc_session/src/session.rs2023-12-21
> > 08:55:28.0 -0800
> > > b/compiler/rustc_session/src/session.rs2024-02-26
> > 07:29:15.527577022 -0800
> > > +@@ -1269,7 +1269,7 @@
> > > + | CrateType::Rlib
> > > + | CrateType::Staticlib
> > > + | CrateType::Cdylib => continue,
> > > +-CrateType::ProcMacro => return false,
> > > ++CrateType::ProcMacro => return true,
> > > + }
> > > + }
> > > +
> > > diff --git a/recipes-devtools/rust/rust-source.inc
> > b/recipes-devtools/rust/rust-source.inc
> > > index 8ae8add..6bef990 100644
> > > --- a/recipes-devtools/rust/rust-source.inc
> > > +++ b/recipes-devtools/rust/rust-source.inc
> > > @@ -12,6 +12,7 @@ SRC_URI += "
> > https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n
> > > file://rustc-bootstrap.patch;patchdir=${RUSTSRC} \
> > > file://target-build-value.patch;patchdir=${RUSTSRC} \
> > >
> >
> > file://0001-Handle-vendored-sources-when-remapping-paths.patch;patchdir=${RUSTSRC}
> > \
> > > +file://repro-issue-fix-with-v175.patch;patchdir=${RUSTSRC} \
> > > "
> > > SRC_URI[rust.sha256sum] =
> > "4526f786d673e4859ff2afa0bab2ba13c918b796519a25c1acce06dba9542340"
> > >
> > > --
> > > 2.44.0
> > >
> >
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62747): https://lists.yoctoproject.org/g/yocto/message/62747
Mute This Topic: https://lists.yoctoproject.org/mt/104866719/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [meta-lts-mixins][kirkstone/rust][PATCH 10/11] rust: reproducibility issue fix with v1.75
Hi Sundeep,
Sundeep KOKKONDA escreveu (terça,
12/03/2024 à(s) 03:45):
> Hello,
>
> FYI. There is a V2 available for this patch with upstream fix backport.
> You can consider that.
>
> https://lists.openembedded.org/g/openembedded-core/message/196856
Sure, when this one is integrated on the master branch I can create a
backport for it too.
Thanks for the notification.
Jose
>
>
>
> Thanks,
>
> Sundeep K.
>
> On 11-Mar-24 21:54, Jose Quaresma wrote:
> > CAUTION: This email comes from a non Wind River email account!
> > Do not click links or open attachments unless you recognize the sender
> and know the content is safe.
> >
> > From: Yash Shinde
> >
> > With 1.75 rust release, the '.rustc' section of shared object libs are
> embedded with absolute path names which is casuing reproducibiluty issues.
> > This change will fix the path name format back to '/rust/$hash' as in
> earlier versions.
> >
> > Below are the links for detailed bug description & discusssion with
> upstream rust.
> > https://github.com/rust-lang/rust/issues/120825#issuecomment-1964307219
> > https://github.com/rust-lang/rust/issues/120825#issuecomment-1964652656
> >
> > Signed-off-by: Sundeep KOKKONDA
> > Signed-off-by: Yash Shinde
> > Signed-off-by: Richard Purdie
> > Signed-off-by: Jose Quaresma
> > ---
> > .../files/repro-issue-fix-with-v175.patch | 23 +++
> > recipes-devtools/rust/rust-source.inc | 1 +
> > 2 files changed, 24 insertions(+)
> > create mode 100644
> recipes-devtools/rust/files/repro-issue-fix-with-v175.patch
> >
> > diff --git a/recipes-devtools/rust/files/repro-issue-fix-with-v175.patch
> b/recipes-devtools/rust/files/repro-issue-fix-with-v175.patch
> > new file mode 100644
> > index 000..6840baf
> > --- /dev/null
> > +++ b/recipes-devtools/rust/files/repro-issue-fix-with-v175.patch
> > @@ -0,0 +1,23 @@
> > +rust: reproducibility issue fix with v1.75
> > +
> > +With 1.75 rust release, the '.rustc' section of shared object libs are
> embedded with absolute path names which is casuing reproducibiluty issues.
> > +This change will fix the path name format back to '/rust/$hash' as in
> earlier versions.
> > +
> > +Below are the links for detailed bug description & discusssion with
> upstream rust.
> > +https://github.com/rust-lang/rust/issues/120825#issuecomment-1964307219
> > +https://github.com/rust-lang/rust/issues/120825#issuecomment-1964652656
> > +
> > +Upstream-Status: Inappropriate [patches need rework]
> > +Signed-off-by: Sundeep KOKKONDA
> > +---
> > +--- a/compiler/rustc_session/src/session.rs2023-12-21
> 08:55:28.0 -0800
> > b/compiler/rustc_session/src/session.rs2024-02-26
> 07:29:15.527577022 -0800
> > +@@ -1269,7 +1269,7 @@
> > + | CrateType::Rlib
> > + | CrateType::Staticlib
> > + | CrateType::Cdylib => continue,
> > +-CrateType::ProcMacro => return false,
> > ++CrateType::ProcMacro => return true,
> > + }
> > + }
> > +
> > diff --git a/recipes-devtools/rust/rust-source.inc
> b/recipes-devtools/rust/rust-source.inc
> > index 8ae8add..6bef990 100644
> > --- a/recipes-devtools/rust/rust-source.inc
> > +++ b/recipes-devtools/rust/rust-source.inc
> > @@ -12,6 +12,7 @@ SRC_URI += "
> https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n
> > file://rustc-bootstrap.patch;patchdir=${RUSTSRC} \
> > file://target-build-value.patch;patchdir=${RUSTSRC} \
> >
>
> file://0001-Handle-vendored-sources-when-remapping-paths.patch;patchdir=${RUSTSRC}
> \
> > +file://repro-issue-fix-with-v175.patch;patchdir=${RUSTSRC} \
> > "
> > SRC_URI[rust.sha256sum] =
> "4526f786d673e4859ff2afa0bab2ba13c918b796519a25c1acce06dba9542340"
> >
> > --
> > 2.44.0
> >
>
--
Best regards,
José Quaresma
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62742): https://lists.yoctoproject.org/g/yocto/message/62742
Mute This Topic: https://lists.yoctoproject.org/mt/104866719/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Cannot ssh into qemu guest
On 09.03.24 19:58, Xylopyrographer via lists.yoctoproject.org wrote: > Thanks for the reply. > > Still a bit green with all this but from the QEMU VM, *sshd* is running > and port 22 is open. > > Checked by running: > *ps aux | grep sshd > *and > *netstat -plant | grep :22 > > *as well, I can telnet in to the VM itself by running (from within the VM): > * > telnet localhost 22* > > which returns: > *Connected to localhost* > *SSH-2.0-OpenSSH_9.5* > > So I think all is as it should be on the QEMU side of things? If you pass the option `slirp` to runqemu, it forwards the ssh port to to the outside. Check with `ss -tlp`. [1]: https://docs.yoctoproject.org/dev/dev-manual/qemu.html#runqemu-command-line-options Kind regards Jörg Sommer -- Navimatix GmbH Tatzendpromenade 2 D-07745 Jena Geschäftsführer: Steffen Späthe, Jan Rommeley Registergericht: Amtsgericht Jena, HRB 501480 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62741): https://lists.yoctoproject.org/g/yocto/message/62741 Mute This Topic: https://lists.yoctoproject.org/mt/104819558/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v5.10/standard/base && v5.10/standard/preempt-rt/base][PATCH 2/2] loop: Select I/O scheduler 'none' from inside add_disk()
From: Bart Van Assche commit 2112f5c1330a671fa852051d85cb9eadc05d7eb7 upstream. We noticed that the user interface of Android devices becomes very slow under memory pressure. This is because Android uses the zram driver on top of the loop driver for swapping, because under memory pressure the swap code alternates reads and writes quickly, because mq-deadline is the default scheduler for loop devices and because mq-deadline delays writes by five seconds for such a workload with default settings. Fix this by making the kernel select I/O scheduler 'none' from inside add_disk() for loop devices. This default can be overridden at any time from user space, e.g. via a udev rule. This approach has an advantage compared to changing the I/O scheduler from userspace from 'mq-deadline' into 'none', namely that synchronize_rcu() does not get called. This patch changes the default I/O scheduler for loop devices from 'mq-deadline' into 'none'. Additionally, this patch reduces the Android boot time on my test setup with 0.5 seconds compared to configuring the loop I/O scheduler from user space. Cc: Christoph Hellwig Cc: Ming Lei Cc: Tetsuo Handa Cc: Martijn Coenen Cc: Jaegeuk Kim Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20210805174200.3250718-3-bvanass...@acm.org Signed-off-by: Jens Axboe Signed-off-by: Wentao Zhang --- drivers/block/loop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 0cdeeb0c5ece..ad3f06d5e986 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -2128,7 +2128,7 @@ static int loop_add(struct loop_device **l, int i) lo->tag_set.numa_node = NUMA_NO_NODE; lo->tag_set.cmd_size = sizeof(struct loop_cmd); lo->tag_set.flags = BLK_MQ_F_SHOULD_MERGE | BLK_MQ_F_STACKING | - BLK_MQ_F_NO_SCHED; + BLK_MQ_F_NO_SCHED_BY_DEFAULT; lo->tag_set.driver_data = lo; err = blk_mq_alloc_tag_set(>tag_set); -- 2.31.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13670): https://lists.yoctoproject.org/g/linux-yocto/message/13670 Mute This Topic: https://lists.yoctoproject.org/mt/104880302/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v5.10/standard/base && v5.10/standard/preempt-rt/base][PATCH 1/2] blk-mq: Introduce the BLK_MQ_F_NO_SCHED_BY_DEFAULT flag
From: Bart Van Assche
commit 90b7198001f23ea37d3b46dc631bdaa2357a20b1 upstream.
elevator_get_default() uses the following algorithm to select an I/O
scheduler from inside add_disk():
- In case of a single hardware queue or if sharing hardware queues across
multiple request queues (BLK_MQ_F_TAG_HCTX_SHARED), use mq-deadline.
- Otherwise, use 'none'.
This is a good choice for most but not for all block drivers. Make it
possible to override the selection of mq-deadline with a new flag,
namely BLK_MQ_F_NO_SCHED_BY_DEFAULT.
Cc: Christoph Hellwig
Cc: Ming Lei
Cc: Tetsuo Handa
Cc: Martijn Coenen
Cc: Jaegeuk Kim
Signed-off-by: Bart Van Assche
Link: https://lore.kernel.org/r/20210805174200.3250718-2-bvanass...@acm.org
Signed-off-by: Jens Axboe
Signed-off-by: Wentao Zhang
---
block/elevator.c | 3 +++
include/linux/blk-mq.h | 6 ++
2 files changed, 9 insertions(+)
diff --git a/block/elevator.c b/block/elevator.c
index 2f962662c32a..f762b2af1d2a 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -622,6 +622,9 @@ static inline bool elv_support_iosched(struct request_queue
*q)
*/
static struct elevator_type *elevator_get_default(struct request_queue *q)
{
+ if (q->tag_set && q->tag_set->flags & BLK_MQ_F_NO_SCHED_BY_DEFAULT)
+ return NULL;
+
if (q->nr_hw_queues != 1)
return NULL;
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index f8ea27423d1d..39526279fbd3 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -398,7 +398,13 @@ enum {
BLK_MQ_F_STACKING = 1 << 2,
BLK_MQ_F_TAG_HCTX_SHARED = 1 << 3,
BLK_MQ_F_BLOCKING = 1 << 5,
+ /* Do not allow an I/O scheduler to be configured. */
BLK_MQ_F_NO_SCHED = 1 << 6,
+ /*
+* Select 'none' during queue registration in case of a single hwq
+* or shared hwqs instead of 'mq-deadline'.
+*/
+ BLK_MQ_F_NO_SCHED_BY_DEFAULT= 1 << 7,
BLK_MQ_F_ALLOC_POLICY_START_BIT = 8,
BLK_MQ_F_ALLOC_POLICY_BITS = 1,
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13669):
https://lists.yoctoproject.org/g/linux-yocto/message/13669
Mute This Topic: https://lists.yoctoproject.org/mt/104880299/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
