[linux-yocto] [PATCH v6.6/v6.1 0/1] backport of drm/bridge/adv7511 for CVE-2024-26876
From: Paul Gortmaker It would seem that a trivial change in surrounding context prevented the linux-stable team from backporting this change to v6.6 and v6.1. The same commit with updated context applies to both v6.6 and v6.1 cleanly. The "Fixes:" line indicates that it could also be relevant to v5.15 but after a quick look/test there, I decided the unwind code in the probe was sufficiently different that it is best we just leave it alone. Build tested on v6.6 baseline. Paul. -- Mads Bligaard Nielsen (1): drm/bridge: adv7511: fix crash on irq during probe drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 22 ++-- 1 file changed, 11 insertions(+), 11 deletions(-) -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13870): https://lists.yoctoproject.org/g/linux-yocto/message/13870 Mute This Topic: https://lists.yoctoproject.org/mt/105732451/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 1/1] drm/bridge: adv7511: fix crash on irq during probe
From: Mads Bligaard Nielsen
commit aeedaee5ef5468caf59e2bb1265c2116e0c9a924 upstream.
Moved IRQ registration down to end of adv7511_probe().
If an IRQ already is pending during adv7511_probe
(before adv7511_cec_init) then cec_received_msg_ts
could crash using uninitialized data:
Unable to handle kernel read from unreadable memory at virtual address
03d5
Internal error: Oops: 9604 [#1] PREEMPT_RT SMP
Call trace:
cec_received_msg_ts+0x48/0x990 [cec]
adv7511_cec_irq_process+0x1cc/0x308 [adv7511]
adv7511_irq_process+0xd8/0x120 [adv7511]
adv7511_irq_handler+0x1c/0x30 [adv7511]
irq_thread_fn+0x30/0xa0
irq_thread+0x14c/0x238
kthread+0x190/0x1a8
Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
Signed-off-by: Mads Bligaard Nielsen
Signed-off-by: Alvin Šipraga
Reviewed-by: Robert Foss
Signed-off-by: Robert Foss
Link:
https://patchwork.freedesktop.org/patch/msgid/20240219-adv7511-cec-irq-crash-fix-v2-1-245e53c4b...@bang-olufsen.dk
Signed-off-by: Paul Gortmaker
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 22 ++--
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 2611afd2c1c13..ef2b6ce544d0a 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1291,17 +1291,6 @@ static int adv7511_probe(struct i2c_client *i2c)
INIT_WORK(>hpd_work, adv7511_hpd_work);
- if (i2c->irq) {
- init_waitqueue_head(>wq);
-
- ret = devm_request_threaded_irq(dev, i2c->irq, NULL,
- adv7511_irq_handler,
- IRQF_ONESHOT, dev_name(dev),
- adv7511);
- if (ret)
- goto err_unregister_cec;
- }
-
adv7511_power_off(adv7511);
i2c_set_clientdata(i2c, adv7511);
@@ -1325,6 +1314,17 @@ static int adv7511_probe(struct i2c_client *i2c)
adv7511_audio_init(dev, adv7511);
+ if (i2c->irq) {
+ init_waitqueue_head(>wq);
+
+ ret = devm_request_threaded_irq(dev, i2c->irq, NULL,
+ adv7511_irq_handler,
+ IRQF_ONESHOT, dev_name(dev),
+ adv7511);
+ if (ret)
+ goto err_unregister_audio;
+ }
+
if (adv7511->type == ADV7533 || adv7511->type == ADV7535) {
ret = adv7533_attach_dsi(adv7511);
if (ret)
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13869):
https://lists.yoctoproject.org/g/linux-yocto/message/13869
Mute This Topic: https://lists.yoctoproject.org/mt/105732450/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 1/1] reiserfs: Avoid touching renamed directory if parent does not change
From: Jan Kara
commit 49db9b1b86a82448dfaf3fcfefcf678dee56c8ed upstream.
The VFS will not be locking moved directory if its parent does not
change. Change reiserfs rename code to avoid touching renamed directory
if its parent does not change as without locking that can corrupt the
filesystem.
Signed-off-by: Jan Kara
Signed-off-by: Al Viro
Signed-off-by: Paul Gortmaker
---
fs/reiserfs/namei.c | 54 -
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/fs/reiserfs/namei.c b/fs/reiserfs/namei.c
index b916859992ec8..9a622bb135a80 100644
--- a/fs/reiserfs/namei.c
+++ b/fs/reiserfs/namei.c
@@ -1325,8 +1325,8 @@ static int reiserfs_rename(struct user_namespace
*mnt_userns,
struct inode *old_inode, *new_dentry_inode;
struct reiserfs_transaction_handle th;
int jbegin_count;
- umode_t old_inode_mode;
unsigned long savelink = 1;
+ bool update_dir_parent = false;
struct timespec64 ctime;
if (flags & ~RENAME_NOREPLACE)
@@ -1377,8 +1377,7 @@ static int reiserfs_rename(struct user_namespace
*mnt_userns,
return -ENOENT;
}
- old_inode_mode = old_inode->i_mode;
- if (S_ISDIR(old_inode_mode)) {
+ if (S_ISDIR(old_inode->i_mode)) {
/*
* make sure that directory being renamed has correct ".."
* and that its new parent directory has not too many links
@@ -1391,24 +1390,28 @@ static int reiserfs_rename(struct user_namespace
*mnt_userns,
}
}
- /*
-* directory is renamed, its parent directory will be changed,
-* so find ".." entry
-*/
- dot_dot_de.de_gen_number_bit_string = NULL;
- retval =
- reiserfs_find_entry(old_inode, "..", 2, _dot_entry_path,
+ if (old_dir != new_dir) {
+ /*
+* directory is renamed, its parent directory will be
+* changed, so find ".." entry
+*/
+ dot_dot_de.de_gen_number_bit_string = NULL;
+ retval =
+ reiserfs_find_entry(old_inode, "..", 2,
+ _dot_entry_path,
_dot_de);
- pathrelse(_dot_entry_path);
- if (retval != NAME_FOUND) {
- reiserfs_write_unlock(old_dir->i_sb);
- return -EIO;
- }
+ pathrelse(_dot_entry_path);
+ if (retval != NAME_FOUND) {
+ reiserfs_write_unlock(old_dir->i_sb);
+ return -EIO;
+ }
- /* inode number of .. must equal old_dir->i_ino */
- if (dot_dot_de.de_objectid != old_dir->i_ino) {
- reiserfs_write_unlock(old_dir->i_sb);
- return -EIO;
+ /* inode number of .. must equal old_dir->i_ino */
+ if (dot_dot_de.de_objectid != old_dir->i_ino) {
+ reiserfs_write_unlock(old_dir->i_sb);
+ return -EIO;
+ }
+ update_dir_parent = true;
}
}
@@ -1488,7 +1491,7 @@ static int reiserfs_rename(struct user_namespace
*mnt_userns,
reiserfs_prepare_for_journal(old_inode->i_sb, new_de.de_bh, 1);
- if (S_ISDIR(old_inode->i_mode)) {
+ if (update_dir_parent) {
if ((retval =
search_by_entry_key(new_dir->i_sb,
_dot_de.de_entry_key,
@@ -1536,14 +1539,14 @@ static int reiserfs_rename(struct user_namespace
*mnt_userns,
new_de.de_bh);
reiserfs_restore_prepared_buffer(old_inode->i_sb,
old_de.de_bh);
- if (S_ISDIR(old_inode_mode))
+ if (update_dir_parent)
reiserfs_restore_prepared_buffer(old_inode->
i_sb,
dot_dot_de.
de_bh);
continue;
}
- if (S_ISDIR(old_inode_mode)) {
+ if (update_dir_parent) {
if (item_moved(_dot_ih, _dot_entry_path) ||
!entry_points_to_object("..",
[linux-yocto] [PATCH v5.15/v6.1 0/1] reiserfs namei.c backport for CVE-2023-52591
From: Paul Gortmaker I was ready to put this CVE in the ignore pile, since IMHO the reiserfs only continues to exist as a curiousity and possibly as a back compatibility test for the VFS layer. Pretty sure nobody has used it in earnest in the last 15-ish years? However, the "conflict" was a trivial one in the variable declaration block (from addition of struct timespec64 ctime) and the same "fixed up" commit applies to both v5.15 and v6.1 kernels. So we might as well take the easy ones, I guess. Nothing for v6.6.x as it already has a backport. Build tested only. Obviously zero rush to merge this, given the subject matter and essentially zero user base. It can sit for a month+ if there are other things going on, and nobody will care (including me). Paul. -- Jan Kara (1): reiserfs: Avoid touching renamed directory if parent does not change fs/reiserfs/namei.c | 54 - 1 file changed, 29 insertions(+), 25 deletions(-) -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13867): https://lists.yoctoproject.org/g/linux-yocto/message/13867 Mute This Topic: https://lists.yoctoproject.org/mt/105724660/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 1/2] ipv6: annotate some data-races around sk->sk_prot
From: Eric Dumazet
commit 086d49058cd8471046ae9927524708820f5fd1c7 upstream.
IPv6 has this hack changing sk->sk_prot when an IPv6 socket
is 'converted' to an IPv4 one with IPV6_ADDRFORM option.
This operation is only performed for TCP and UDP, knowing
their 'struct proto' for the two network families are populated
in the same way, and can not disappear while a reader
might use and dereference sk->sk_prot.
If we think about it all reads of sk->sk_prot while
either socket lock or RTNL is not acquired should be using READ_ONCE().
Also note that other layers like MPTCP, XFRM, CHELSIO_TLS also
write over sk->sk_prot.
BUG: KCSAN: data-race in inet6_recvmsg / ipv6_setsockopt
write to 0x8881386f7aa8 of 8 bytes by task 26932 on cpu 0:
do_ipv6_setsockopt net/ipv6/ipv6_sockglue.c:492 [inline]
ipv6_setsockopt+0x3758/0x3910 net/ipv6/ipv6_sockglue.c:1019
udpv6_setsockopt+0x85/0x90 net/ipv6/udp.c:1649
sock_common_setsockopt+0x5d/0x70 net/core/sock.c:3489
__sys_setsockopt+0x209/0x2a0 net/socket.c:2180
__do_sys_setsockopt net/socket.c:2191 [inline]
__se_sys_setsockopt net/socket.c:2188 [inline]
__x64_sys_setsockopt+0x62/0x70 net/socket.c:2188
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
read to 0x8881386f7aa8 of 8 bytes by task 26911 on cpu 1:
inet6_recvmsg+0x7a/0x210 net/ipv6/af_inet6.c:659
sys_recvmsg+0x16c/0x320
___sys_recvmsg net/socket.c:2674 [inline]
do_recvmmsg+0x3f5/0xae0 net/socket.c:2768
__sys_recvmmsg net/socket.c:2847 [inline]
__do_sys_recvmmsg net/socket.c:2870 [inline]
__se_sys_recvmmsg net/socket.c:2863 [inline]
__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2863
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
value changed: 0x85e0e980 -> 0x85e01580
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 26911 Comm: syz-executor.3 Not tainted
5.17.0-rc2-syzkaller-00316-g0457e5153e0e-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Reported-by: syzbot
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Paul Gortmaker
---
net/ipv6/af_inet6.c | 24 ++--
net/ipv6/ipv6_sockglue.c | 6 --
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 8e0c33b683010..bbfa5d3a16f01 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -452,11 +452,14 @@ int inet6_bind(struct socket *sock, struct sockaddr
*uaddr, int addr_len)
{
struct sock *sk = sock->sk;
u32 flags = BIND_WITH_LOCK;
+ const struct proto *prot;
int err = 0;
+ /* IPV6_ADDRFORM can change sk->sk_prot under us. */
+ prot = READ_ONCE(sk->sk_prot);
/* If the socket has its own bind function then use it. */
- if (sk->sk_prot->bind)
- return sk->sk_prot->bind(sk, uaddr, addr_len);
+ if (prot->bind)
+ return prot->bind(sk, uaddr, addr_len);
if (addr_len < SIN6_LEN_RFC2133)
return -EINVAL;
@@ -572,6 +575,7 @@ int inet6_ioctl(struct socket *sock, unsigned int cmd,
unsigned long arg)
void __user *argp = (void __user *)arg;
struct sock *sk = sock->sk;
struct net *net = sock_net(sk);
+ const struct proto *prot;
switch (cmd) {
case SIOCADDRT:
@@ -589,9 +593,11 @@ int inet6_ioctl(struct socket *sock, unsigned int cmd,
unsigned long arg)
case SIOCSIFDSTADDR:
return addrconf_set_dstaddr(net, argp);
default:
- if (!sk->sk_prot->ioctl)
+ /* IPV6_ADDRFORM can change sk->sk_prot under us. */
+ prot = READ_ONCE(sk->sk_prot);
+ if (!prot->ioctl)
return -ENOIOCTLCMD;
- return sk->sk_prot->ioctl(sk, cmd, arg);
+ return prot->ioctl(sk, cmd, arg);
}
/*NOTREACHED*/
return 0;
@@ -653,11 +659,14 @@ INDIRECT_CALLABLE_DECLARE(int udpv6_sendmsg(struct sock
*, struct msghdr *,
int inet6_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
{
struct sock *sk = sock->sk;
+ const struct proto *prot;
if (unlikely(inet_send_prepare(sk)))
return -EAGAIN;
- return INDIRECT_CALL_2(sk->sk_prot->sendmsg, tcp_sendmsg, udpv6_sendmsg,
+ /* IPV6_ADDRFORM can change sk->sk_prot under us. */
+ prot = READ_ONCE(sk->sk_prot);
+ return INDIRECT_CALL_2(prot->sendmsg, tcp_sendmsg, udpv6_sendmsg,
sk, msg, size);
}
@@ -667,13 +676,16 @@ int inet6_recvmsg(struct socket *sock, struct msghdr
*msg, size_t size,
int flags)
{
struct sock *
[linux-yocto] [PATCH v5.15 0/2] Backports for IPv6 CVE-2022-3567
From: Paul Gortmaker The commit log of "the fix" identifies an earlier commit as "part 1" of of the fix. But when we go back as far as v5.15, we find neither are there. So this CVE has two commits. Built and boot tested on top of CVE-2022-3566 fix sent yesterday: https://lists.yoctoproject.org/g/linux-yocto/message/13856 Once again, v6.1+ kernels have both commits by default, so nothing for us to do there. No rush for integration of these - they have been lingering since 2022. Paul. -- Eric Dumazet (1): ipv6: annotate some data-races around sk->sk_prot Kuniyuki Iwashima (1): ipv6: Fix data races around sk->sk_prot. net/core/sock.c | 6 -- net/ipv4/af_inet.c | 23 --- net/ipv6/af_inet6.c | 24 ++-- net/ipv6/ipv6_sockglue.c | 6 -- 4 files changed, 42 insertions(+), 17 deletions(-) -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13865): https://lists.yoctoproject.org/g/linux-yocto/message/13865 Mute This Topic: https://lists.yoctoproject.org/mt/105709263/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 2/2] ipv6: Fix data races around sk->sk_prot.
From: Kuniyuki Iwashima
commit 364f997b5cfe1db0d63a390fe7c801fa2b3115f6 upstream.
Commit 086d49058cd8 ("ipv6: annotate some data-races around sk->sk_prot")
fixed some data-races around sk->sk_prot but it was not enough.
Some functions in inet6_(stream|dgram)_ops still access sk->sk_prot
without lock_sock() or rtnl_lock(), so they need READ_ONCE() to avoid
load tearing.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Kuniyuki Iwashima
Signed-off-by: Jakub Kicinski
Signed-off-by: Paul Gortmaker
---
net/core/sock.c | 6 --
net/ipv4/af_inet.c | 23 ---
net/ipv6/ipv6_sockglue.c | 4 ++--
3 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 6f761f3c272aa..b41d5e6953c7f 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -3413,7 +3413,8 @@ int sock_common_getsockopt(struct socket *sock, int
level, int optname,
{
struct sock *sk = sock->sk;
- return sk->sk_prot->getsockopt(sk, level, optname, optval, optlen);
+ /* IPV6_ADDRFORM can change sk->sk_prot under us. */
+ return READ_ONCE(sk->sk_prot)->getsockopt(sk, level, optname, optval,
optlen);
}
EXPORT_SYMBOL(sock_common_getsockopt);
@@ -3440,7 +3441,8 @@ int sock_common_setsockopt(struct socket *sock, int
level, int optname,
{
struct sock *sk = sock->sk;
- return sk->sk_prot->setsockopt(sk, level, optname, optval, optlen);
+ /* IPV6_ADDRFORM can change sk->sk_prot under us. */
+ return READ_ONCE(sk->sk_prot)->setsockopt(sk, level, optname, optval,
optlen);
}
EXPORT_SYMBOL(sock_common_setsockopt);
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 487f75993bf4f..110ac22d3ce20 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -565,22 +565,27 @@ int inet_dgram_connect(struct socket *sock, struct
sockaddr *uaddr,
int addr_len, int flags)
{
struct sock *sk = sock->sk;
+ const struct proto *prot;
int err;
if (addr_len < sizeof(uaddr->sa_family))
return -EINVAL;
+
+ /* IPV6_ADDRFORM can change sk->sk_prot under us. */
+ prot = READ_ONCE(sk->sk_prot);
+
if (uaddr->sa_family == AF_UNSPEC)
- return sk->sk_prot->disconnect(sk, flags);
+ return prot->disconnect(sk, flags);
if (BPF_CGROUP_PRE_CONNECT_ENABLED(sk)) {
- err = sk->sk_prot->pre_connect(sk, uaddr, addr_len);
+ err = prot->pre_connect(sk, uaddr, addr_len);
if (err)
return err;
}
if (data_race(!inet_sk(sk)->inet_num) && inet_autobind(sk))
return -EAGAIN;
- return sk->sk_prot->connect(sk, uaddr, addr_len);
+ return prot->connect(sk, uaddr, addr_len);
}
EXPORT_SYMBOL(inet_dgram_connect);
@@ -743,10 +748,11 @@ EXPORT_SYMBOL(inet_stream_connect);
int inet_accept(struct socket *sock, struct socket *newsock, int flags,
bool kern)
{
- struct sock *sk1 = sock->sk;
+ struct sock *sk1 = sock->sk, *sk2;
int err = -EINVAL;
- struct sock *sk2 = sk1->sk_prot->accept(sk1, flags, , kern);
+ /* IPV6_ADDRFORM can change sk->sk_prot under us. */
+ sk2 = READ_ONCE(sk1->sk_prot)->accept(sk1, flags, , kern);
if (!sk2)
goto do_err;
@@ -834,12 +840,15 @@ ssize_t inet_sendpage(struct socket *sock, struct page
*page, int offset,
size_t size, int flags)
{
struct sock *sk = sock->sk;
+ const struct proto *prot;
if (unlikely(inet_send_prepare(sk)))
return -EAGAIN;
- if (sk->sk_prot->sendpage)
- return sk->sk_prot->sendpage(sk, page, offset, size, flags);
+ /* IPV6_ADDRFORM can change sk->sk_prot under us. */
+ prot = READ_ONCE(sk->sk_prot);
+ if (prot->sendpage)
+ return prot->sendpage(sk, page, offset, size, flags);
return sock_no_sendpage(sock, page, offset, size, flags);
}
EXPORT_SYMBOL(inet_sendpage);
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 6d08ebf753b36..a1a92480e935f 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -475,7 +475,7 @@ static int do_ipv6_setsockopt(struct sock *sk, int level,
int optname,
sock_prot_inuse_add(net, sk->sk_prot, -1);
sock_prot_inuse_add(net, _prot, 1);
local_bh_enable();
- /* Paired with READ_ONCE(sk->sk_prot) in
net/ipv6/af_inet6.c */
+ /* Paired with READ_ONCE(sk->sk_prot) in
inet6_stream_ops */
WRITE_ONCE(sk->sk_prot, _prot);
[linux-yocto] [PATCH v5.15 0/1] backport of TCP fix for CVE-2022-3566
From: Paul Gortmaker Mainline commit f49cd2f4d6 is listed as the fix for CVE-2022-3566. I guess the linux-stable team skipped over it since it didn't apply? Maybe enough other stuff has since been backported such that it does apply now - hands free with "wiggle" (the original AI if you ask me). Build and boot tested on v5.15/standard/base - ssh'd in and nothing to see in dmesg - nice and clean. It is already present in v6.1+ so nothing for us to do there. No rush on this - it has been hanging around since 2022! Paul. -- Kuniyuki Iwashima (1): tcp: Fix data races around icsk->icsk_af_ops. net/ipv4/tcp.c | 10 ++ net/ipv6/ipv6_sockglue.c | 3 ++- net/ipv6/tcp_ipv6.c | 6 -- 3 files changed, 12 insertions(+), 7 deletions(-) -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13856): https://lists.yoctoproject.org/g/linux-yocto/message/13856 Mute This Topic: https://lists.yoctoproject.org/mt/105689820/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 1/1] tcp: Fix data races around icsk->icsk_af_ops.
From: Kuniyuki Iwashima
commit f49cd2f4d6170d27a2c61f1fecb03d8a70c91f57 upstream.
setsockopt(IPV6_ADDRFORM) and tcp_v6_connect() change icsk->icsk_af_ops
under lock_sock(), but tcp_(get|set)sockopt() read it locklessly. To
avoid load/store tearing, we need to add READ_ONCE() and WRITE_ONCE()
for the reads and writes.
Thanks to Eric Dumazet for providing the syzbot report:
BUG: KCSAN: data-race in tcp_setsockopt / tcp_v6_connect
write to 0x88813c624518 of 8 bytes by task 23936 on cpu 0:
tcp_v6_connect+0x5b3/0xce0 net/ipv6/tcp_ipv6.c:240
__inet_stream_connect+0x159/0x6d0 net/ipv4/af_inet.c:660
inet_stream_connect+0x44/0x70 net/ipv4/af_inet.c:724
__sys_connect_file net/socket.c:1976 [inline]
__sys_connect+0x197/0x1b0 net/socket.c:1993
__do_sys_connect net/socket.c:2003 [inline]
__se_sys_connect net/socket.c:2000 [inline]
__x64_sys_connect+0x3d/0x50 net/socket.c:2000
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
read to 0x88813c624518 of 8 bytes by task 23937 on cpu 1:
tcp_setsockopt+0x147/0x1c80 net/ipv4/tcp.c:3789
sock_common_setsockopt+0x5d/0x70 net/core/sock.c:3585
__sys_setsockopt+0x212/0x2b0 net/socket.c:2252
__do_sys_setsockopt net/socket.c:2263 [inline]
__se_sys_setsockopt net/socket.c:2260 [inline]
__x64_sys_setsockopt+0x62/0x70 net/socket.c:2260
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
value changed: 0x8539af68 -> 0x8539aff8
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 23937 Comm: syz-executor.5 Not tainted
6.0.0-rc4-syzkaller-00331-g4ed9c1e971b1-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 08/26/2022
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot
Reported-by: Eric Dumazet
Signed-off-by: Kuniyuki Iwashima
Signed-off-by: Jakub Kicinski
Signed-off-by: Paul Gortmaker
---
net/ipv4/tcp.c | 10 ++
net/ipv6/ipv6_sockglue.c | 3 ++-
net/ipv6/tcp_ipv6.c | 6 --
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 16fd3da68e9f6..17033e0cfecb7 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3704,8 +3704,9 @@ int tcp_setsockopt(struct sock *sk, int level, int
optname, sockptr_t optval,
const struct inet_connection_sock *icsk = inet_csk(sk);
if (level != SOL_TCP)
- return icsk->icsk_af_ops->setsockopt(sk, level, optname,
-optval, optlen);
+ /* Paired with WRITE_ONCE() in do_ipv6_setsockopt() and
tcp_v6_connect() */
+ return READ_ONCE(icsk->icsk_af_ops)->setsockopt(sk, level,
optname,
+ optval, optlen);
return do_tcp_setsockopt(sk, level, optname, optval, optlen);
}
EXPORT_SYMBOL(tcp_setsockopt);
@@ -4303,8 +4304,9 @@ int tcp_getsockopt(struct sock *sk, int level, int
optname, char __user *optval,
struct inet_connection_sock *icsk = inet_csk(sk);
if (level != SOL_TCP)
- return icsk->icsk_af_ops->getsockopt(sk, level, optname,
-optval, optlen);
+ /* Paired with WRITE_ONCE() in do_ipv6_setsockopt() and
tcp_v6_connect() */
+ return READ_ONCE(icsk->icsk_af_ops)->getsockopt(sk, level,
optname,
+ optval, optlen);
return do_tcp_getsockopt(sk, level, optname, optval, optlen);
}
EXPORT_SYMBOL(tcp_getsockopt);
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 197e12d5607f1..faf9ec9355d9a 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -476,7 +476,8 @@ static int do_ipv6_setsockopt(struct sock *sk, int level,
int optname,
sock_prot_inuse_add(net, _prot, 1);
local_bh_enable();
sk->sk_prot = _prot;
- icsk->icsk_af_ops = _specific;
+ /* Paired with READ_ONCE() in
tcp_(get|set)sockopt() */
+ WRITE_ONCE(icsk->icsk_af_ops, _specific);
sk->sk_socket->ops = _stream_ops;
sk->sk_family = PF_INET;
tcp_sync_mss(sk, icsk->icsk_pmtu_cookie);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index c18fdddbfa09d..29c8d386274bf 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -237,7 +237,8 @@ static int tcp_v6_connect(struct sock *sk, struct sockaddr
*uaddr,
sin.sin_port = usin->sin6_port;
sin.sin_addr.s_addr = usin->sin6_addr.s6_addr32[3];
-
Re: [linux-yocto] [PATCH v6.6/standard/base 0/5] Fix intermittent qemu-x86 boot hangs
On Mon, Apr 22, 2024 at 2:02 PM Bruce Ashfield via lists.yoctoproject.org wrote: > > > On Mon, Apr 22, 2024 at 1:38 PM Bruce Ashfield via lists.yoctoproject.org > wrote: > >> In message: [PATCH v6.6/standard/base 0/5] Fix intermittent qemu-x86 boot >> hangs >> on 19/04/2024 pa...@kernel.org wrote: >> >> > From: Paul Gortmaker >> > >> > Pretty much everything is documented here: >> > >> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=15463 >> > >> > ...other than I have since put the reverts onto the v6.6/standard/base >> > (v6.6.23-118-g2d01bc1d4eea) and ran boot tests on that for 150 >> > iterations w/o issue. >> > >> > We'll still need to let the linux-stable people know there is an issue, >> > and checking if mainline has the issue (vs. just being related to >> > backports) remains to be determined as well. >> > >> > But if there is a desire to move forward, and this is blocking, well >> > then at least there is an option. >> >> Thanks for the detailed explanation paul! >> >> I'm in favour of applying these to 6.6 and I'll deal with >> any -stable fallout later. >> >> That being said, when I apply these on top of v6.6/standard/base >> patch 2/5 is failing. I'm looking at resolving it now, but it does >> imply that I have a different baseline than you do! >> >> > Aha. My baseline is now 6.6.27, so there have been some more stacked > commits onto the common x86 entry point file. > Yeah, just luck of circumstances. I was using a devshell for compiling 'cause with crazy issues like this, I don't know if it is toolchain, or ... ? And hence I got the srcrevs from the build on master, which as per above was v6.6.23 based. Of course then along comes v6.6.26 with BHI ( https://lwn.net/Articles/969210/ ) and it goes and screws around with all the same low-level files the reverts are for. What are the friggin odds? The revert in #3 goes ker-pow even worse than #2. I'll have to go study the BHI changes and the reverts, fix it up manually, and then feed it into the test harness (again!) to have any confidence in it. Just when you thought you made it out of the cauldron, it seems a giant green warty arm reaches out of the soup and pulls you back in. Paul. -- > > I've been sitting on those -stable updates to let the release settle. > > You can see all my queued changes at: > > https://git.yoctoproject.org/poky-contrib/log/?h=zedd/kernel > > Bruce > > > >> Bruce >> >> > >> > Note that I did all the testing on qemux86 w/o KVM. I figure everyone >> > else tests qemux86-64 with KVM, right? >> > --- >> > >> > Paul Gortmaker (5): >> > Revert "x86/tdx: Allow 32-bit emulation by default" >> > Revert "x86/entry: Do not allow external 0x80 interrupts" >> > Revert "x86/entry: Convert INT 0x80 emulation to IDTENTRY" >> > Revert "x86/coco: Disable 32-bit emulation by default on TDX and SEV" >> > Revert "x86: Introduce ia32_enabled()" >> > >> > arch/x86/coco/tdx/tdx.c | 1 - >> > arch/x86/entry/common.c | 97 +--- >> > arch/x86/entry/entry_64_compat.S | 77 + >> > arch/x86/include/asm/ia32.h | 23 +--- >> > arch/x86/include/asm/idtentry.h | 4 -- >> > arch/x86/include/asm/proto.h | 4 ++ >> > arch/x86/kernel/idt.c| 2 +- >> > arch/x86/mm/mem_encrypt_amd.c| 11 >> > arch/x86/xen/enlighten_pv.c | 2 +- >> > arch/x86/xen/xen-asm.S | 2 +- >> > 10 files changed, 86 insertions(+), 137 deletions(-) >> > >> > -- >> > 2.44.0 >> > >> >> >> >> > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await thee > at its end > - "Use the force Harry" - Gandalf, Star Trek II > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13854): https://lists.yoctoproject.org/g/linux-yocto/message/13854 Mute This Topic: https://lists.yoctoproject.org/mt/105625698/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH v5.15-rt 00/11] Uprev from -rt61 to -rt72
From: Paul Gortmaker Bruce, So, I knew that i915 fix we dealt with on v6.1 was actually present in the v5.15-rt branch and not just floating out in space. So I figured I'd help out and also look at getting this older version caught up with the where the linux-stable-rt repository is today. We are currently at -rt61 and upstream is at -rt72 so it looks like: linux-stable-rt$git log --oneline --reverse --no-merges ^v5.15.96-rt61 ^v5.15.141 v5.15.141-rt72 22006998ccd1 Linux 5.15.107-rt62 03aa894822a7 Linux 5.15.111-rt63 05e341da6364 Linux 5.15.113-rt64 b850a37ed7e1 Linux 5.15.119-rt65 bc88aa9e2737 Linux 5.15.125-rt66 9157353f3ecf Linux 5.15.129-rt67 d535006be892 Linux 5.15.132-rt68 27b3564da988 Linux 5.15.133-rt69 f1bd52382dce io-mapping: don't disable preempt on RT in io_mapping_map_atomic_wc(). 47364f671cbe locking/rwbase: Mitigate indefinite writer starvation e94601d32f4d Revert "softirq: Let ksoftirqd do its job" ccf6bfd49a8a debugobject: Ensure pool refill (again) 1992720dff25 debugobjects,locking: Annotate debug_object_fill_pool() wait type violation 20616d2c54d5 sched: avoid false lockdep splat in put_task_struct() ef42a60e55bf locking/seqlock: Do the lockdep annotation before locking in do_write_seqcount_begin_nested() f9fec545dea4 mm/page_alloc: Use write_seqlock_irqsave() instead write_seqlock() + local_irq_save(). 87572f0f6aa8 bpf: Remove in_atomic() from bpf_link_put(). 71c09b1d6b07 posix-timers: Ensure timer ID search-loop limit is valid e6eb0105c206 drm/i915: Do not disable preemption for resets 594a4d80f59c Linux 5.15.133-rt70 0508c80fa70d Linux 5.15.137-rt71 e9e280348657 Linux 5.15.141-rt72 It was all pretty seamless, except for two. 1) We've already got ef42a60e55bf via linux-stable commit 07b569051f6e 2) f9fec545dea4 is all about the printk_deferred stuff. I had to stare at it for a while to figure out what is going on, and look at history. It turns out that we (Yocto) gutted all of the printk_deferred stuff: Author: John Ogness AuthorDate: Mon Nov 30 01:42:08 2020 +0106 Commit: Bruce Ashfield CommitDate: Thu Nov 4 16:06:31 2021 -0400 printk: remove deferred printing Since printing occurs either atomically or from the printing kthread, there is no need for any deferring or tracking possible recursion paths. Remove all printk defer functions and context tracking. Signed-off-by: John Ogness Signed-off-by: Thomas Gleixner ...and then a stable cleanup fix from Kevin in 63a865cbbc8 to remove the new instance added from linux-stable 0431e1323f42 [5.15.109] I'm not sure where the Ogness commit came from; the printk_deferred() removal, but it largely does not matter, as I'm not going to restore it on this old release! Leave well enough alone! With that knowledge, the f9fec545dea4 page_alloc in the list above essentially becomes a trivial no-op. But I left in anyway as a self-documenting commit, with an appropriate annotation I didn't bother with doing an individual commit per version tag. Just moved forward localversion-rt from 61 to 72 in a single commit. Testing: -sanity boot test on x86_64 (old AMD quad core) -sanity boot test on arm_64 (qemu) -check /proc/version for -rt72 -check that dmesg is clean -run some other random commands -test merge out to all BSPs (no conflicts) If it makes life easier for you, I can push a branch to contrib. Paul --- Joseph Salisbury (1): Linux 5.15.141-rt72 Paolo Abeni (1): Revert "softirq: Let ksoftirqd do its job" Peter Zijlstra (1): debugobjects,locking: Annotate debug_object_fill_pool() wait type violation Sebastian Andrzej Siewior (4): io-mapping: don't disable preempt on RT in io_mapping_map_atomic_wc(). locking/rwbase: Mitigate indefinite writer starvation mm/page_alloc: Use write_seqlock_irqsave() instead write_seqlock() + local_irq_save(). bpf: Remove in_atomic() from bpf_link_put(). Thomas Gleixner (2): debugobject: Ensure pool refill (again) posix-timers: Ensure timer ID search-loop limit is valid Tvrtko Ursulin (1): drm/i915: Do not disable preemption for resets Wander Lairson Costa (1): sched: avoid false lockdep splat in put_task_struct() drivers/gpu/drm/i915/gt/intel_reset.c | 12 +- include/linux/io-mapping.h| 20 + include/linux/lockdep.h | 14 include/linux/lockdep_types.h | 1 + include/linux/sched/signal.h | 2 +- include/linux/sched/task.h| 18 +++ kernel/bpf/syscall.c | 29 +--- kernel/locking/lockdep.c | 28 +-- kernel/locking/rwbase_rt.c| 9 kernel/softirq.c | 22 ++ kernel/time/posix-timers.c| 31 +++--- lib/debugobjects.c
[linux-yocto] [PATCH v5.15-rt 10/11] drm/i915: Do not disable preemption for resets
From: Tvrtko Ursulin
commit e6eb0105c20694af5642c77bf63c9509e4f9bb28 in linux-stable-rt
[commit 40cd2835ced288789a685aa4aa7bc04b492dcd45 in linux-rt-devel]
Commit ade8a0f59844 ("drm/i915: Make all GPU resets atomic") added a
preempt disable section over the hardware reset callback to prepare the
driver for being able to reset from atomic contexts.
In retrospect I can see that the work item at a time was about removing
the struct mutex from the reset path. Code base also briefly entertained
the idea of doing the reset under stop_machine in order to serialize
userspace mmap and temporary glitch in the fence registers (see
eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex"),
but that never materialized and was soon removed in 2caffbf11762
("drm/i915: Revoke mmaps and prevent access to fence registers across
reset") and replaced with a SRCU based solution.
As such, as far as I can see, today we still have a requirement that
resets must not sleep (invoked from submission tasklets), but no need to
support invoking them from a truly atomic context.
Given that the preemption section is problematic on RT kernels, since the
uncore lock becomes a sleeping lock and so is invalid in such section,
lets try and remove it. Potential downside is that our short waits on GPU
to complete the reset may get extended if CPU scheduling interferes, but
in practice that probably isn't a deal breaker.
In terms of mechanics, since the preemption disabled block is being
removed we just need to replace a few of the wait_for_atomic macros into
busy looping versions which will work (and not complain) when called from
non-atomic sections.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Paul Gortmaker
Cc: Sebastian Andrzej Siewior
Acked-by: Sebastian Andrzej Siewior
Link:
https://lore.kernel.org/r/20230705093025.3689748-1-tvrtko.ursu...@linux.intel.com
Signed-off-by: Sebastian Andrzej Siewior
[PG: backport from v6.4-rt ; minor context fixup caused by b7d70b8b06ed]
Signed-off-by: Paul Gortmaker
Signed-off-by: Clark Williams
(cherry picked from commit 1a80b572f783a15327663bf9e7d71163976e8d6a
v6.1-rt)
Signed-off-by: Joseph Salisbury
Signed-off-by: Paul Gortmaker
---
drivers/gpu/drm/i915/gt/intel_reset.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 9dc244b70ce4..06ab730dc9a8 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -167,13 +167,13 @@ static int i915_do_reset(struct intel_gt *gt,
/* Assert reset for at least 20 usec, and wait for acknowledgement. */
pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE);
udelay(50);
- err = wait_for_atomic(i915_in_reset(pdev), 50);
+ err = _wait_for_atomic(i915_in_reset(pdev), 50, 0);
/* Clear the reset request. */
pci_write_config_byte(pdev, I915_GDRST, 0);
udelay(50);
if (!err)
- err = wait_for_atomic(!i915_in_reset(pdev), 50);
+ err = _wait_for_atomic(!i915_in_reset(pdev), 50, 0);
return err;
}
@@ -193,7 +193,7 @@ static int g33_do_reset(struct intel_gt *gt,
struct pci_dev *pdev = to_pci_dev(gt->i915->drm.dev);
pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE);
- return wait_for_atomic(g4x_reset_complete(pdev), 50);
+ return _wait_for_atomic(g4x_reset_complete(pdev), 50, 0);
}
static int g4x_do_reset(struct intel_gt *gt,
@@ -210,7 +210,7 @@ static int g4x_do_reset(struct intel_gt *gt,
pci_write_config_byte(pdev, I915_GDRST,
GRDOM_MEDIA | GRDOM_RESET_ENABLE);
- ret = wait_for_atomic(g4x_reset_complete(pdev), 50);
+ ret = _wait_for_atomic(g4x_reset_complete(pdev), 50, 0);
if (ret) {
GT_TRACE(gt, "Wait for media reset failed\n");
goto out;
@@ -218,7 +218,7 @@ static int g4x_do_reset(struct intel_gt *gt,
pci_write_config_byte(pdev, I915_GDRST,
GRDOM_RENDER | GRDOM_RESET_ENABLE);
- ret = wait_for_atomic(g4x_reset_complete(pdev), 50);
+ ret = _wait_for_atomic(g4x_reset_complete(pdev), 50, 0);
if (ret) {
GT_TRACE(gt, "Wait for render reset failed\n");
goto out;
@@ -736,9 +736,7 @@ int __intel_gt_reset(struct intel_gt *gt,
intel_engine_mask_t engine_mask)
intel_uncore_forcewake_get(gt->uncore, FORCEWAKE_ALL);
for (retry = 0; ret == -ETIMEDOUT && retry < retries; retry++) {
GT_TRACE(gt, "engine_mask=%x\n", engine_mask);
- preempt_disable();
ret = reset(gt, engine_mask, retry);
- preempt_enable();
}
intel_uncore_forcewake_put(gt->uncore, FORCEWAKE_ALL);
--
2.40.0
-=-=-=-=-=-=-=-=-=
[linux-yocto] [PATCH v5.15-rt 11/11] Linux 5.15.141-rt72
From: Joseph Salisbury commit e9e280348657bf29b5f35e37e34e4da26821116c in linux-stable-rt Signed-off-by: Joseph Salisbury Signed-off-by: Paul Gortmaker --- localversion-rt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localversion-rt b/localversion-rt index 9b7de9345ef4..2c95a3cdbcb8 100644 --- a/localversion-rt +++ b/localversion-rt @@ -1 +1 @@ --rt61 +-rt72 -- 2.40.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13412): https://lists.yoctoproject.org/g/linux-yocto/message/13412 Mute This Topic: https://lists.yoctoproject.org/mt/103055700/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH v5.15-rt 09/11] posix-timers: Ensure timer ID search-loop limit is valid
From: Thomas Gleixner
commit 71c09b1d6b07a7e4d8d1c686b53f8d1442f8ec14 in linux-stable-rt
posix_timer_add() tries to allocate a posix timer ID by starting from the
cached ID which was stored by the last successful allocation.
This is done in a loop searching the ID space for a free slot one by
one. The loop has to terminate when the search wrapped around to the
starting point.
But that's racy vs. establishing the starting point. That is read out
lockless, which leads to the following problem:
CPU0 CPU1
posix_timer_add()
start = sig->posix_timer_id;
lock(hash_lock);
... posix_timer_add()
if (++sig->posix_timer_id < 0)
start = sig->posix_timer_id;
sig->posix_timer_id = 0;
So CPU1 can observe a negative start value, i.e. -1, and the loop break
never happens because the condition can never be true:
if (sig->posix_timer_id == start)
break;
While this is unlikely to ever turn into an endless loop as the ID space is
huge (INT_MAX), the racy read of the start value caught the attention of
KCSAN and Dmitry unearthed that incorrectness.
Rewrite it so that all id operations are under the hash lock.
Reported-by: syzbot+5c54bd3eb218bb595...@syzkaller.appspotmail.com
Reported-by: Dmitry Vyukov
Signed-off-by: Thomas Gleixner
Reviewed-by: Frederic Weisbecker
Link: https://lore.kernel.org/r/87bkhzdn6g.ffs@tglx
(cherry picked from commit 8ce8849dd1e78dadcee0ec9acbd259d239b7069f)
Signed-off-by: Joseph Salisbury
Signed-off-by: Paul Gortmaker
---
include/linux/sched/signal.h | 2 +-
kernel/time/posix-timers.c | 31 ++-
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/include/linux/sched/signal.h b/include/linux/sched/signal.h
index 5f0e8403e8ce..9743f7d173a0 100644
--- a/include/linux/sched/signal.h
+++ b/include/linux/sched/signal.h
@@ -125,7 +125,7 @@ struct signal_struct {
#ifdef CONFIG_POSIX_TIMERS
/* POSIX.1b Interval Timers */
- int posix_timer_id;
+ unsigned intnext_posix_timer_id;
struct list_headposix_timers;
/* ITIMER_REAL timer for the process */
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index ed3c4a954398..2d6cf93ca370 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -140,25 +140,30 @@ static struct k_itimer *posix_timer_by_id(timer_t id)
static int posix_timer_add(struct k_itimer *timer)
{
struct signal_struct *sig = current->signal;
- int first_free_id = sig->posix_timer_id;
struct hlist_head *head;
- int ret = -ENOENT;
+ unsigned int cnt, id;
- do {
+ /*
+* FIXME: Replace this by a per signal struct xarray once there is
+* a plan to handle the resulting CRIU regression gracefully.
+*/
+ for (cnt = 0; cnt <= INT_MAX; cnt++) {
spin_lock(_lock);
- head = _timers_hashtable[hash(sig, sig->posix_timer_id)];
- if (!__posix_timers_find(head, sig, sig->posix_timer_id)) {
+ id = sig->next_posix_timer_id;
+
+ /* Write the next ID back. Clamp it to the positive space */
+ sig->next_posix_timer_id = (id + 1) & INT_MAX;
+
+ head = _timers_hashtable[hash(sig, id)];
+ if (!__posix_timers_find(head, sig, id)) {
hlist_add_head_rcu(>t_hash, head);
- ret = sig->posix_timer_id;
+ spin_unlock(_lock);
+ return id;
}
- if (++sig->posix_timer_id < 0)
- sig->posix_timer_id = 0;
- if ((sig->posix_timer_id == first_free_id) && (ret == -ENOENT))
- /* Loop over all possible ids completed */
- ret = -EAGAIN;
spin_unlock(_lock);
- } while (ret == -ENOENT);
- return ret;
+ }
+ /* POSIX return code when no timer ID could be allocated */
+ return -EAGAIN;
}
static inline void unlock_timer(struct k_itimer *timr, unsigned long flags)
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13411):
https://lists.yoctoproject.org/g/linux-yocto/message/13411
Mute This Topic: https://lists.yoctoproject.org/mt/103055699/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH v5.15-rt 08/11] bpf: Remove in_atomic() from bpf_link_put().
From: Sebastian Andrzej Siewior
commit 87572f0f6aa8cbb3c69a7085fae70786cd217653 in linux-stable-rt
bpf_free_inode() is invoked as a RCU callback. Usually RCU callbacks are
invoked within softirq context. By setting rcutree.use_softirq=0 boot
option the RCU callbacks will be invoked in a per-CPU kthread with
bottom halves disabled which implies a RCU read section.
On PREEMPT_RT the context remains fully preemptible. The RCU read
section however does not allow schedule() invocation. The latter happens
in mutex_lock() performed by bpf_trampoline_unlink_prog() originated
from bpf_link_put().
It was pointed out that the bpf_link_put() invocation should not be
delayed if originated from close(). It was also pointed out that other
invocations from within a syscall should also avoid the workqueue.
Everyone else should use workqueue by default to remain safe in the
future (while auditing the code, every caller was preemptible except for
the RCU case).
Let bpf_link_put() use the worker unconditionally. Add
bpf_link_put_direct() which will directly free the resources and is used
by close() and from within __sys_bpf().
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Andrii Nakryiko
Link: https://lore.kernel.org/bpf/20230614083430.oenaw...@linutronix.de
(cherry picked from commit ab5d47bd41b1db82c295b0e751e2b822b43a4b5a)
Signed-off-by: Joseph Salisbury
Signed-off-by: Paul Gortmaker
---
kernel/bpf/syscall.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index ad41b8230780..bcc01f9881cf 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -2454,27 +2454,30 @@ static void bpf_link_put_deferred(struct work_struct
*work)
bpf_link_free(link);
}
-/* bpf_link_put can be called from atomic context, but ensures that resources
- * are freed from process context
+/* bpf_link_put might be called from atomic context. It needs to be called
+ * from sleepable context in order to acquire sleeping locks during the
process.
*/
void bpf_link_put(struct bpf_link *link)
{
if (!atomic64_dec_and_test(>refcnt))
return;
- if (in_atomic()) {
- INIT_WORK(>work, bpf_link_put_deferred);
- schedule_work(>work);
- } else {
- bpf_link_free(link);
- }
+ INIT_WORK(>work, bpf_link_put_deferred);
+ schedule_work(>work);
+}
+
+static void bpf_link_put_direct(struct bpf_link *link)
+{
+ if (!atomic64_dec_and_test(>refcnt))
+ return;
+ bpf_link_free(link);
}
static int bpf_link_release(struct inode *inode, struct file *filp)
{
struct bpf_link *link = filp->private_data;
- bpf_link_put(link);
+ bpf_link_put_direct(link);
return 0;
}
@@ -4351,7 +4354,7 @@ static int link_update(union bpf_attr *attr)
if (ret)
bpf_prog_put(new_prog);
out_put_link:
- bpf_link_put(link);
+ bpf_link_put_direct(link);
return ret;
}
@@ -4374,7 +4377,7 @@ static int link_detach(union bpf_attr *attr)
else
ret = -EOPNOTSUPP;
- bpf_link_put(link);
+ bpf_link_put_direct(link);
return ret;
}
@@ -4425,7 +4428,7 @@ static int bpf_link_get_fd_by_id(const union bpf_attr
*attr)
fd = bpf_link_new_fd(link);
if (fd < 0)
- bpf_link_put(link);
+ bpf_link_put_direct(link);
return fd;
}
@@ -4502,7 +4505,7 @@ static int bpf_iter_create(union bpf_attr *attr)
return PTR_ERR(link);
err = bpf_iter_new_fd(link);
- bpf_link_put(link);
+ bpf_link_put_direct(link);
return err;
}
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13409):
https://lists.yoctoproject.org/g/linux-yocto/message/13409
Mute This Topic: https://lists.yoctoproject.org/mt/103055697/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH v5.15-rt 05/11] debugobjects,locking: Annotate debug_object_fill_pool() wait type violation
From: Peter Zijlstra
commit 1992720dff250e9d7d99696588ab1b197160c6b6 in linux-stable-rt
There is an explicit wait-type violation in debug_object_fill_pool()
for PREEMPT_RT=n kernels which allows them to more easily fill the
object pool and reduce the chance of allocation failures.
Lockdep's wait-type checks are designed to check the PREEMPT_RT
locking rules even for PREEMPT_RT=n kernels and object to this, so
create a lockdep annotation to allow this to stand.
Specifically, create a 'lock' type that overrides the inner wait-type
while it is held -- allowing one to temporarily raise it, such that
the violation is hidden.
Reported-by: Vlastimil Babka
Reported-by: Qi Zheng
Signed-off-by: Peter Zijlstra (Intel)
Tested-by: Qi Zheng
Link:
https://lkml.kernel.org/r/20230429100614.ga1489...@hirez.programming.kicks-ass.net
(cherry picked from commit 0cce06ba859a515bd06224085d3addb870608b6d)
Signed-off-by: Joseph Salisbury
Signed-off-by: Paul Gortmaker
---
include/linux/lockdep.h | 14 ++
include/linux/lockdep_types.h | 1 +
kernel/locking/lockdep.c | 28 +---
lib/debugobjects.c| 15 +--
4 files changed, 49 insertions(+), 9 deletions(-)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 1935e4b24359..155a4947d870 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -342,6 +342,16 @@ extern void lock_unpin_lock(struct lockdep_map *lock,
struct pin_cookie);
#define lockdep_repin_lock(l,c)lock_repin_lock(&(l)->dep_map, (c))
#define lockdep_unpin_lock(l,c)lock_unpin_lock(&(l)->dep_map, (c))
+/*
+ * Must use lock_map_aquire_try() with override maps to avoid
+ * lockdep thinking they participate in the block chain.
+ */
+#define DEFINE_WAIT_OVERRIDE_MAP(_name, _wait_type)\
+ struct lockdep_map _name = {\
+ .name = #_name "-wait-type-override", \
+ .wait_type_inner = _wait_type, \
+ .lock_type = LD_LOCK_WAIT_OVERRIDE, }
+
#else /* !CONFIG_LOCKDEP */
static inline void lockdep_init_task(struct task_struct *task)
@@ -429,6 +439,9 @@ extern int lockdep_is_held(const void *);
#define lockdep_repin_lock(l, c) do { (void)(l); (void)(c); }
while (0)
#define lockdep_unpin_lock(l, c) do { (void)(l); (void)(c); }
while (0)
+#define DEFINE_WAIT_OVERRIDE_MAP(_name, _wait_type)\
+ struct lockdep_map __maybe_unused _name = {}
+
#endif /* !LOCKDEP */
enum xhlock_context_t {
@@ -571,6 +584,7 @@ do {
\
#define rwsem_release(l, i)lock_release(l, i)
#define lock_map_acquire(l)lock_acquire_exclusive(l, 0, 0,
NULL, _THIS_IP_)
+#define lock_map_acquire_try(l)
lock_acquire_exclusive(l, 0, 1, NULL, _THIS_IP_)
#define lock_map_acquire_read(l)
lock_acquire_shared_recursive(l, 0, 0, NULL, _THIS_IP_)
#define lock_map_acquire_tryread(l)
lock_acquire_shared_recursive(l, 0, 1, NULL, _THIS_IP_)
#define lock_map_release(l)lock_release(l, _THIS_IP_)
diff --git a/include/linux/lockdep_types.h b/include/linux/lockdep_types.h
index 3e726ace5c62..a5f1519489df 100644
--- a/include/linux/lockdep_types.h
+++ b/include/linux/lockdep_types.h
@@ -33,6 +33,7 @@ enum lockdep_wait_type {
enum lockdep_lock_type {
LD_LOCK_NORMAL = 0, /* normal, catch all */
LD_LOCK_PERCPU, /* percpu */
+ LD_LOCK_WAIT_OVERRIDE, /* annotation */
LD_LOCK_MAX,
};
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 44b78f63d5fe..f4f4593949a4 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -2210,6 +2210,9 @@ static inline bool usage_match(struct lock_list *entry,
void *mask)
static inline bool usage_skip(struct lock_list *entry, void *mask)
{
+ if (entry->class->lock_type == LD_LOCK_NORMAL)
+ return false;
+
/*
* Skip local_lock() for irq inversion detection.
*
@@ -2236,14 +2239,16 @@ static inline bool usage_skip(struct lock_list *entry,
void *mask)
* As a result, we will skip local_lock(), when we search for irq
* inversion bugs.
*/
- if (entry->class->lock_type == LD_LOCK_PERCPU) {
- if (DEBUG_LOCKS_WARN_ON(entry->class->wait_type_inner <
LD_WAIT_CONFIG))
- return false;
+ if (entry->class->lock_type == LD_LOCK_PERCPU &&
+ DEBUG_LOCKS_WARN_ON(entry->class->wait_type_inner < LD_WAIT_CONFIG))
+ return false;
- return true;
- }
+ /*
+* Skip WAIT_OVERRIDE for irq inversion detection -- it's not actually
+* a lock and only used to override the wait_type.
+*/
- return f
[linux-yocto] [PATCH v5.15-rt 06/11] sched: avoid false lockdep splat in put_task_struct()
From: Wander Lairson Costa
commit 20616d2c54d5db199f983ca9515630f361d5c995 in linux-stable-rt
In put_task_struct(), a spin_lock is indirectly acquired under the kernel
stock. When running the kernel in real-time (RT) configuration, the
operation is dispatched to a preemptible context call to ensure
guaranteed preemption. However, if PROVE_RAW_LOCK_NESTING is enabled
and __put_task_struct() is called while holding a raw_spinlock, lockdep
incorrectly reports an "Invalid lock context" in the stock kernel.
This false splat occurs because lockdep is unaware of the different
route taken under RT. To address this issue, override the inner wait
type to prevent the false lockdep splat.
Suggested-by: Oleg Nesterov
Suggested-by: Sebastian Andrzej Siewior
Suggested-by: Peter Zijlstra
Signed-off-by: Wander Lairson Costa
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lore.kernel.org/r/20230614122323.37957-3-wan...@redhat.com
(cherry picked from commit 893cdaaa3977be6afb3a7f756fbfd7be83f68d8c)
Signed-off-by: Joseph Salisbury
Signed-off-by: Paul Gortmaker
---
include/linux/sched/task.h | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h
index 0c2d00809915..75d52a9e7620 100644
--- a/include/linux/sched/task.h
+++ b/include/linux/sched/task.h
@@ -115,6 +115,19 @@ static inline void put_task_struct(struct task_struct *t)
if (!refcount_dec_and_test(>usage))
return;
+ /*
+* In !RT, it is always safe to call __put_task_struct().
+* Under RT, we can only call it in preemptible context.
+*/
+ if (!IS_ENABLED(CONFIG_PREEMPT_RT) || preemptible()) {
+ static DEFINE_WAIT_OVERRIDE_MAP(put_task_map, LD_WAIT_SLEEP);
+
+ lock_map_acquire_try(_task_map);
+ __put_task_struct(t);
+ lock_map_release(_task_map);
+ return;
+ }
+
/*
* under PREEMPT_RT, we can't call put_task_struct
* in atomic context because it will indirectly
@@ -135,10 +148,7 @@ static inline void put_task_struct(struct task_struct *t)
* when it fails to fork a process. Therefore, there is no
* way it can conflict with put_task_struct().
*/
- if (IS_ENABLED(CONFIG_PREEMPT_RT) && !preemptible())
- call_rcu(>rcu, __put_task_struct_rcu_cb);
- else
- __put_task_struct(t);
+ call_rcu(>rcu, __put_task_struct_rcu_cb);
}
static inline void put_task_struct_many(struct task_struct *t, int nr)
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13406):
https://lists.yoctoproject.org/g/linux-yocto/message/13406
Mute This Topic: https://lists.yoctoproject.org/mt/103055694/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH v5.15-rt 07/11] mm/page_alloc: Use write_seqlock_irqsave() instead write_seqlock() + local_irq_save().
From: Sebastian Andrzej Siewior
commit f9fec545dea4aac71dfb54e3a6d187cc92af9ea4 in linux-stable-rt
__build_all_zonelists() acquires zonelist_update_seq by first disabling
interrupts via local_irq_save() and then acquiring the seqlock with
write_seqlock(). This is troublesome and leads to problems on
PREEMPT_RT. The problem is that the inner spinlock_t becomes a sleeping
lock on PREEMPT_RT and must not be acquired with disabled interrupts.
The API provides write_seqlock_irqsave() which does the right thing in
one step.
printk_deferred_enter() has to be invoked in non-migrate-able context to
ensure that deferred printing is enabled and disabled on the same CPU.
This is the case after zonelist_update_seq has been acquired.
There was discussion on the first submission that the order should be:
local_irq_disable();
printk_deferred_enter();
write_seqlock();
to avoid pitfalls like having an unaccounted printk() coming from
write_seqlock_irqsave() before printk_deferred_enter() is invoked. The
only origin of such a printk() can be a lockdep splat because the
lockdep annotation happens after the sequence count is incremented.
This is exceptional and subject to change.
It was also pointed that PREEMPT_RT can be affected by the printk
problem since its write_seqlock_irqsave() does not really disable
interrupts. This isn't the case because PREEMPT_RT's printk
implementation differs from the mainline implementation in two important
aspects:
- Printing happens in a dedicated threads and not at during the
invocation of printk().
- In emergency cases where synchronous printing is used, a different
driver is used which does not use tty_port::lock.
Acquire zonelist_update_seq with write_seqlock_irqsave() and then defer
printk output.
Fixes: 1007843a91909 ("mm/page_alloc: fix potential deadlock on
zonelist_update_seq seqlock")
Acked-by: Michal Hocko
Reviewed-by: David Hildenbrand
Link: https://lore.kernel.org/r/20230623201517.yw286...@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior
(cherry picked from commit 4d1139baae8bc4fff3728d1d204bdb04c13dbe10)
Signed-off-by: Joseph Salisbury
[PG: this basically becomes a trivial no-op because Yocto has stripped
out all the printk_deferred stuff in 25f13bd1d07b and 63a865cbbc8a]
Signed-off-by: Paul Gortmaker
---
mm/page_alloc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 30be96ae9a34..189f097253e2 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6423,8 +6423,7 @@ static void __build_all_zonelists(void *data)
* to prevent any IRQ handler from calling into the page allocator
* (e.g. GFP_ATOMIC) that could hit zonelist_iter_begin and livelock.
*/
- local_irq_save(flags);
- write_seqlock(_update_seq);
+ write_seqlock_irqsave(_update_seq, flags);
#ifdef CONFIG_NUMA
memset(node_load, 0, sizeof(node_load));
@@ -6457,8 +6456,7 @@ static void __build_all_zonelists(void *data)
#endif
}
- write_sequnlock(_update_seq);
- local_irq_restore(flags);
+ write_sequnlock_irqrestore(_update_seq, flags);
}
static noinline void __init
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13408):
https://lists.yoctoproject.org/g/linux-yocto/message/13408
Mute This Topic: https://lists.yoctoproject.org/mt/103055696/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH v5.15-rt 04/11] debugobject: Ensure pool refill (again)
From: Thomas Gleixner
commit ccf6bfd49a8a7d25bacc8e84ec5dbdfe513c29c3 in linux-stable-rt
The recent fix to ensure atomicity of lookup and allocation inadvertently
broke the pool refill mechanism.
Prior to that change debug_objects_activate() and debug_objecs_assert_init()
invoked debug_objecs_init() to set up the tracking object for statically
initialized objects. That's not longer the case and debug_objecs_init() is
now the only place which does pool refills.
Depending on the number of statically initialized objects this can be
enough to actually deplete the pool, which was observed by Ido via a
debugobjects OOM warning.
Restore the old behaviour by adding explicit refill opportunities to
debug_objects_activate() and debug_objecs_assert_init().
Fixes: 63a759694eed ("debugobject: Prevent init race with static objects")
Reported-by: Ido Schimmel
Signed-off-by: Thomas Gleixner
Tested-by: Ido Schimmel
Link: https://lore.kernel.org/r/871qk05a9d.ffs@tglx
(cherry picked from commit 0af462f19e635ad522f28981238334620881badc)
Signed-off-by: Joseph Salisbury
Signed-off-by: Paul Gortmaker
---
lib/debugobjects.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index 579406c1e9ed..4c39678c03ee 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -590,6 +590,16 @@ static struct debug_obj *lookup_object_or_alloc(void
*addr, struct debug_bucket
return NULL;
}
+static void debug_objects_fill_pool(void)
+{
+ /*
+* On RT enabled kernels the pool refill must happen in preemptible
+* context:
+*/
+ if (!IS_ENABLED(CONFIG_PREEMPT_RT) || preemptible())
+ fill_pool();
+}
+
static void
__debug_object_init(void *addr, const struct debug_obj_descr *descr, int
onstack)
{
@@ -598,12 +608,7 @@ __debug_object_init(void *addr, const struct
debug_obj_descr *descr, int onstack
struct debug_obj *obj;
unsigned long flags;
- /*
-* On RT enabled kernels the pool refill must happen in preemptible
-* context:
-*/
- if (!IS_ENABLED(CONFIG_PREEMPT_RT) || preemptible())
- fill_pool();
+ debug_objects_fill_pool();
db = get_bucket((unsigned long) addr);
@@ -688,6 +693,8 @@ int debug_object_activate(void *addr, const struct
debug_obj_descr *descr)
if (!debug_objects_enabled)
return 0;
+ debug_objects_fill_pool();
+
db = get_bucket((unsigned long) addr);
raw_spin_lock_irqsave(>lock, flags);
@@ -897,6 +904,8 @@ void debug_object_assert_init(void *addr, const struct
debug_obj_descr *descr)
if (!debug_objects_enabled)
return;
+ debug_objects_fill_pool();
+
db = get_bucket((unsigned long) addr);
raw_spin_lock_irqsave(>lock, flags);
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13405):
https://lists.yoctoproject.org/g/linux-yocto/message/13405
Mute This Topic: https://lists.yoctoproject.org/mt/103055693/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH v5.15-rt 01/11] io-mapping: don't disable preempt on RT in io_mapping_map_atomic_wc().
From: Sebastian Andrzej Siewior
commit f1bd52382dcefb82cdc243575ab81f3966165b47 in linux-stable-rt
io_mapping_map_atomic_wc() disables preemption and pagefaults for
historical reasons. The conversion to io_mapping_map_local_wc(), which
only disables migration, cannot be done wholesale because quite some call
sites need to be updated to accommodate with the changed semantics.
On PREEMPT_RT enabled kernels the io_mapping_map_atomic_wc() semantics are
problematic due to the implicit disabling of preemption which makes it
impossible to acquire 'sleeping' spinlocks within the mapped atomic
sections.
PREEMPT_RT replaces the preempt_disable() with a migrate_disable() for
more than a decade. It could be argued that this is a justification to do
this unconditionally, but PREEMPT_RT covers only a limited number of
architectures and it disables some functionality which limits the coverage
further.
Limit the replacement to PREEMPT_RT for now. This is also done
kmap_atomic().
Link: https://lkml.kernel.org/r/20230310162905.o57pj...@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior
Reported-by: Richard Weinberger
Link:
https://lore.kernel.org/caflxgvw0wmxamqyqj5wgvvsbkhq2d2xcxtogmcpgq9ndc-m...@mail.gmail.com
Cc: Thomas Gleixner
Signed-off-by: Andrew Morton
(cherry picked from commit 7eb16f23b9a415f062db22739e59bb144e0b24ab)
Signed-off-by: Joseph Salisbury
Signed-off-by: Paul Gortmaker
---
include/linux/io-mapping.h | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index e9743cfd8585..b0f196e51dca 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -69,7 +69,10 @@ io_mapping_map_atomic_wc(struct io_mapping *mapping,
BUG_ON(offset >= mapping->size);
phys_addr = mapping->base + offset;
- preempt_disable();
+ if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+ preempt_disable();
+ else
+ migrate_disable();
pagefault_disable();
return __iomap_local_pfn_prot(PHYS_PFN(phys_addr), mapping->prot);
}
@@ -79,7 +82,10 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
{
kunmap_local_indexed((void __force *)vaddr);
pagefault_enable();
- preempt_enable();
+ if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+ preempt_enable();
+ else
+ migrate_enable();
}
static inline void __iomem *
@@ -168,7 +174,10 @@ static inline void __iomem *
io_mapping_map_atomic_wc(struct io_mapping *mapping,
unsigned long offset)
{
- preempt_disable();
+ if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+ preempt_disable();
+ else
+ migrate_disable();
pagefault_disable();
return io_mapping_map_wc(mapping, offset, PAGE_SIZE);
}
@@ -178,7 +187,10 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
{
io_mapping_unmap(vaddr);
pagefault_enable();
- preempt_enable();
+ if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+ preempt_enable();
+ else
+ migrate_enable();
}
static inline void __iomem *
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13401):
https://lists.yoctoproject.org/g/linux-yocto/message/13401
Mute This Topic: https://lists.yoctoproject.org/mt/103055689/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH v5.15-rt 02/11] locking/rwbase: Mitigate indefinite writer starvation
From: Sebastian Andrzej Siewior
commit 47364f671cbed35071551bd911dc7b89a1761804 in linux-stable-rt
On PREEMPT_RT, rw_semaphore and rwlock_t locks are unfair to writers.
Readers can indefinitely acquire the lock unless the writer fully acquired
the lock, which might never happen if there is always a reader in the
critical section owning the lock.
Mel Gorman reported that since LTP-20220121 the dio_truncate test case
went from having 1 reader to having 16 readers and that number of readers
is sufficient to prevent the down_write ever succeeding while readers
exist. Eventually the test is killed after 30 minutes as a failure.
Mel proposed a timeout to limit how long a writer can be blocked until
the reader is forced into the slowpath.
Thomas argued that there is no added value by providing this timeout. From
a PREEMPT_RT point of view, there are no critical rw_semaphore or rwlock_t
locks left where the reader must be preferred.
Mitigate indefinite writer starvation by forcing the READER into the
slowpath once the WRITER attempts to acquire the lock.
Reported-by: Mel Gorman
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Signed-off-by: Ingo Molnar
Acked-by: Mel Gorman
Link: https://lore.kernel.org/877cwbq4cq.ffs@tglx
Link: https://lore.kernel.org/r/20230321161140.hmcqe...@linutronix.de
Cc: Linus Torvalds
(cherry picked from commit 286deb7ec03d941664ac3ffaff58814b454adf65)
Signed-off-by: Joseph Salisbury
Signed-off-by: Paul Gortmaker
---
kernel/locking/rwbase_rt.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/kernel/locking/rwbase_rt.c b/kernel/locking/rwbase_rt.c
index 88191f6e252c..a28148a05383 100644
--- a/kernel/locking/rwbase_rt.c
+++ b/kernel/locking/rwbase_rt.c
@@ -73,15 +73,6 @@ static int __sched __rwbase_read_lock(struct rwbase_rt *rwb,
int ret;
raw_spin_lock_irq(>wait_lock);
- /*
-* Allow readers, as long as the writer has not completely
-* acquired the semaphore for write.
-*/
- if (atomic_read(>readers) != WRITER_BIAS) {
- atomic_inc(>readers);
- raw_spin_unlock_irq(>wait_lock);
- return 0;
- }
/*
* Call into the slow lock path with the rtmutex->wait_lock
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13402):
https://lists.yoctoproject.org/g/linux-yocto/message/13402
Mute This Topic: https://lists.yoctoproject.org/mt/103055690/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH v5.15-rt 03/11] Revert "softirq: Let ksoftirqd do its job"
From: Paolo Abeni
commit e94601d32f4d7fdc28da15a72fe5262c63a5755a in linux-stable-rt
This reverts the following commits:
4cd13c21b207 ("softirq: Let ksoftirqd do its job")
3c53776e29f8 ("Mark HI and TASKLET softirq synchronous")
1342d8080f61 ("softirq: Don't skip softirq execution when softirq thread is
parking")
in a single change to avoid known bad intermediate states introduced by a
patch series reverting them individually.
Due to the mentioned commit, when the ksoftirqd threads take charge of
softirq processing, the system can experience high latencies.
In the past a few workarounds have been implemented for specific
side-effects of the initial ksoftirqd enforcement commit:
commit 1ff688209e2e ("watchdog: core: make sure the watchdog_worker is not
deferred")
commit 8d5755b3f77b ("watchdog: softdog: fire watchdog even if softirqs do not
get to run")
commit 217f69743681 ("net: busy-poll: allow preemption in sk_busy_loop()")
commit 3c53776e29f8 ("Mark HI and TASKLET softirq synchronous")
But the latency problem still exists in real-life workloads, see the link
below.
The reverted commit intended to solve a live-lock scenario that can now be
addressed with the NAPI threaded mode, introduced with commit 29863d41bb6e
("net: implement threaded-able napi poll loop support"), which is nowadays
in a pretty stable status.
While a complete solution to put softirq processing under nice resource
control would be preferable, that has proven to be a very hard task. In
the short term, remove the main pain point, and also simplify a bit the
current softirq implementation.
Signed-off-by: Paolo Abeni
Signed-off-by: Thomas Gleixner
Tested-by: Jason Xing
Reviewed-by: Jakub Kicinski
Reviewed-by: Eric Dumazet
Reviewed-by: Sebastian Andrzej Siewior
Cc: "Paul E. McKenney"
Cc: Peter Zijlstra
Cc: net...@vger.kernel.org
Link:
https://lore.kernel.org/netdev/305d7742212cbe98621b16be782b0562f1012cb6.ca...@redhat.com
Link:
https://lore.kernel.org/r/57e66b364f1b6f09c9bc0316742c3b14f4ce83bd.1683526542.git.pab...@redhat.com
(cherry picked from commit d15121be7485655129101f3960ae6add40204463)
Signed-off-by: Joseph Salisbury
Signed-off-by: Paul Gortmaker
---
kernel/softirq.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 41f470929e99..398951403331 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -80,21 +80,6 @@ static void wakeup_softirqd(void)
wake_up_process(tsk);
}
-/*
- * If ksoftirqd is scheduled, we do not want to process pending softirqs
- * right now. Let ksoftirqd handle this at its own rate, to get fairness,
- * unless we're doing some of the synchronous softirqs.
- */
-#define SOFTIRQ_NOW_MASK ((1 << HI_SOFTIRQ) | (1 << TASKLET_SOFTIRQ))
-static bool ksoftirqd_running(unsigned long pending)
-{
- struct task_struct *tsk = __this_cpu_read(ksoftirqd);
-
- if (pending & SOFTIRQ_NOW_MASK)
- return false;
- return tsk && task_is_running(tsk) && !__kthread_should_park(tsk);
-}
-
#ifdef CONFIG_TRACE_IRQFLAGS
DEFINE_PER_CPU(int, hardirqs_enabled);
DEFINE_PER_CPU(int, hardirq_context);
@@ -236,7 +221,7 @@ void __local_bh_enable_ip(unsigned long ip, unsigned int
cnt)
goto out;
pending = local_softirq_pending();
- if (!pending || ksoftirqd_running(pending))
+ if (!pending)
goto out;
/*
@@ -419,9 +404,6 @@ static inline bool should_wake_ksoftirqd(void)
static inline void invoke_softirq(void)
{
- if (ksoftirqd_running(local_softirq_pending()))
- return;
-
if (!force_irqthreads() || !__this_cpu_read(ksoftirqd)) {
#ifdef CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK
/*
@@ -455,7 +437,7 @@ asmlinkage __visible void do_softirq(void)
pending = local_softirq_pending();
- if (pending && !ksoftirqd_running(pending))
+ if (pending)
do_softirq_own_stack();
local_irq_restore(flags);
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13404):
https://lists.yoctoproject.org/g/linux-yocto/message/13404
Mute This Topic: https://lists.yoctoproject.org/mt/103055692/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [v6.1/standard/preempt-rt/x86] Add drm/i915 reset -rt fix
Bruce,
This commit has lingered on a dead end branch in linux-stable-rt since August:
linux-stable-rt$git branch --contains 1a80b572f783a
v6.1-rt-next
linux-stable-rt$
I will contact the maintainer, but the updates are pretty slow over there.
Nothing wrong with the commit - in fact it is now upstream with just a
trivial comment change added to it.
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/commit/?id=1a80b572f783a1
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1e975e591a
I put x86 in the Subject 'cause it will only be functional there, but it
applies to v6.1/standard/preempt/base and so put it on one board or on
all -rt boards ; whatver makes your maintenance life easier.
It was added in v6.7 so I checked v6.5 and the -rt maintainer already
added it there (832fa067488), so nothing to do on v6.5 (yay!)
Thanks,
Paul
--
>From 1a80b572f783a15327663bf9e7d71163976e8d6a Mon Sep 17 00:00:00 2001
From: Tvrtko Ursulin
Date: Fri, 18 Aug 2023 22:45:25 -0400
Subject: [PATCH] drm/i915: Do not disable preemption for resets
[commit 40cd2835ced288789a685aa4aa7bc04b492dcd45 in linux-rt-devel]
Commit ade8a0f59844 ("drm/i915: Make all GPU resets atomic") added a
preempt disable section over the hardware reset callback to prepare the
driver for being able to reset from atomic contexts.
In retrospect I can see that the work item at a time was about removing
the struct mutex from the reset path. Code base also briefly entertained
the idea of doing the reset under stop_machine in order to serialize
userspace mmap and temporary glitch in the fence registers (see
eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex"),
but that never materialized and was soon removed in 2caffbf11762
("drm/i915: Revoke mmaps and prevent access to fence registers across
reset") and replaced with a SRCU based solution.
As such, as far as I can see, today we still have a requirement that
resets must not sleep (invoked from submission tasklets), but no need to
support invoking them from a truly atomic context.
Given that the preemption section is problematic on RT kernels, since the
uncore lock becomes a sleeping lock and so is invalid in such section,
lets try and remove it. Potential downside is that our short waits on GPU
to complete the reset may get extended if CPU scheduling interferes, but
in practice that probably isn't a deal breaker.
In terms of mechanics, since the preemption disabled block is being
removed we just need to replace a few of the wait_for_atomic macros into
busy looping versions which will work (and not complain) when called from
non-atomic sections.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Paul Gortmaker
Cc: Sebastian Andrzej Siewior
Acked-by: Sebastian Andrzej Siewior
Link:
https://lore.kernel.org/r/20230705093025.3689748-1-tvrtko.ursu...@linux.intel.com
Signed-off-by: Sebastian Andrzej Siewior
[PG: backport from v6.4-rt ; minor context fixup caused by b7d70b8b06ed]
Signed-off-by: Paul Gortmaker
Signed-off-by: Clark Williams
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 10b930eaa8cb..6108a449cd19 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -174,13 +174,13 @@ static int i915_do_reset(struct intel_gt *gt,
/* Assert reset for at least 20 usec, and wait for acknowledgement. */
pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE);
udelay(50);
- err = wait_for_atomic(i915_in_reset(pdev), 50);
+ err = _wait_for_atomic(i915_in_reset(pdev), 50, 0);
/* Clear the reset request. */
pci_write_config_byte(pdev, I915_GDRST, 0);
udelay(50);
if (!err)
- err = wait_for_atomic(!i915_in_reset(pdev), 50);
+ err = _wait_for_atomic(!i915_in_reset(pdev), 50, 0);
return err;
}
@@ -200,7 +200,7 @@ static int g33_do_reset(struct intel_gt *gt,
struct pci_dev *pdev = to_pci_dev(gt->i915->drm.dev);
pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE);
- return wait_for_atomic(g4x_reset_complete(pdev), 50);
+ return _wait_for_atomic(g4x_reset_complete(pdev), 50, 0);
}
static int g4x_do_reset(struct intel_gt *gt,
@@ -217,7 +217,7 @@ static int g4x_do_reset(struct intel_gt *gt,
pci_write_config_byte(pdev, I915_GDRST,
GRDOM_MEDIA | GRDOM_RESET_ENABLE);
- ret = wait_for_atomic(g4x_reset_complete(pdev), 50);
+ ret = _wait_for_atomic(g4x_reset_complete(pdev), 50, 0);
if (ret) {
GT_TRACE(gt, "Wait for media reset failed\n");
goto out;
@@ -225,7 +225,7 @@ static int g4x_do_reset(struct intel_gt *gt,
pci_write_config_byte(pdev, I915_GDRST,
GRDOM_RENDER | GRDOM_RESET_ENABLE);
- ret = wait_for_
[linux-yocto] [PATCH] features/ima: drop now retired IMA_TRUSTED_KEYRING option
From: Paul Gortmaker Unfortunately linux-stable backported this: Subject: ima: Remove deprecated IMA_TRUSTED_KEYRING Kconfig From: Nayna Jain [ Upstream commit 5087fd9e80e539d2163accd045b73da64de7de95 ] Time to remove "IMA_TRUSTED_KEYRING". ...to all releases still being maintained. stable-queue$git grep -l 5087fd9e80e539 releases/5.10.195/ima-remove-deprecated-ima_trusted_keyring-kconfig.patch releases/5.15.132/ima-remove-deprecated-ima_trusted_keyring-kconfig.patch releases/5.4.257/ima-remove-deprecated-ima_trusted_keyring-kconfig.patch releases/6.1.53/ima-remove-deprecated-ima_trusted_keyring-kconfig.patch releases/6.4.16/ima-remove-deprecated-ima_trusted_keyring-kconfig.patch releases/6.5.3/ima-remove-deprecated-ima_trusted_keyring-kconfig.patch So now when someone uses the feature, it triggers a do_kernel_configcheck warning when the audit runs. We added this file way back in 2019 so this fix will be needed on all active branches that are using an LTS linux-stable kernel listed above. Signed-off-by: Paul Gortmaker diff --git a/features/ima/ima.cfg b/features/ima/ima.cfg index acb5fd02986f..5fd3288e1986 100644 --- a/features/ima/ima.cfg +++ b/features/ima/ima.cfg @@ -13,7 +13,6 @@ CONFIG_IMA_APPRAISE_SIGNED_INIT=y CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y -CONFIG_IMA_TRUSTED_KEYRING=y CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y CONFIG_SIGNATURE=y CONFIG_IMA_WRITE_POLICY=y -- 2.40.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13387): https://lists.yoctoproject.org/g/linux-yocto/message/13387 Mute This Topic: https://lists.yoctoproject.org/mt/103013154/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] [PATCH 4/5] x86-64: use the defaults for number of CPUs
[RE: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs] On
30/11/2023 (Thu 21:43) Liu, Yongxin wrote:
> > -Original Message-
> > From: Gortmaker, Paul
> > Sent: Friday, December 1, 2023 10:27
> > To: Liu, Yongxin
> > Cc: Bruce Ashfield ; linux-
> > yo...@lists.yoctoproject.org
> > Subject: Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number
> > of CPUs
> >
> > [RE: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs]
> > On 30/11/2023 (Thu 20:12) Liu, Yongxin wrote:
> >
> > > > -Original Message-
> > > > From: linux-yocto@lists.yoctoproject.org > > > yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via
> > > > lists.yoctoproject.org
> > > > Sent: Friday, December 1, 2023 03:08
> > > > To: Bruce Ashfield
> > > > Cc: linux-yocto@lists.yoctoproject.org
> > > > Subject: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for
> > > > number of CPUs
> > > >
> > > > From: Paul Gortmaker
> > > >
> > > > The x86-64 BSP isn't quite the same as the "more specific" BSP like
> > > > a Beaglebone Black or the (now deleted) Edgerouter. Where we have
> > > > exact hardware specifics for boards like those, the x86-64 BSP is
> > > > more of a "generic" thing used as the baseline across an endless sea
> > of boards.
> > > >
> > > > To that end, this is somewhat a revert of commit bd77e1f904f6
> > > > ("bsp/intel-x86: change the supported maximum number of CPUs to 512
> > > > in 64- bit bsp")
> > > >
> > > > It is great that a handful of people out there are using Yocto on
> > > > these huge server machines, but that doesn't reflect 99% of the rest
> > > > of us who continue to lean towards the original "embedded theme" of
> > Yocto.
> > > >
> > > > That means a whole bunch of extra per-CPU jumping through hoops;
> > > > some can be mitigated by booting with "nr_cpus=4" (or whatever the
> > > > core count
> > > > is) but I guarantee largely nobody out there is doing that.
> > > >
> > > > Let those users with the crazy CPU count own that config
> > > > customization locally. The default is 64 which still seems way too
> > > > large IMHO, but at least we are moving in the right direction.
> > >
> > >
> > > This intel-x86-64 BSP is a generic one used from mobile to server.
> > >
> > > Customers need to customize not only the CPU number config but also
> > > other configs, like, removing unused drivers or adding debug options.
> > > From this point of view, there is no difference between 64 or 512.
>
> I changed 64 to 512. Because we have server machines with more than 64 CPU.
> I want the BSP support those machines by default.
But you still miss the point. It doesn't matter what you or any company
"want" in this case. Like it or not, it is a shared resource and so the
defaults have to be what is good for Yocto project and not for *you*
>
> >
> > So you've basically argued my case for me. If changes are inevitable,
> > then why do we change the default?
> >
> > > But it changes the "rule" that intel-x86-64 works for all supported
> > platforms.
> > > We need to do extra work for servers with large CPU number.
> >
> > No. There is no "rule" in Yocto like that. That is nonsense because
> > there is no way Yocto can commit to "support" all the crazy different
> > x86-64 variants out there.
>
>
> I think this "bsp/intel-x86" is used only by Wind River.
> So bsp/intel-x86 should work for all supported machines claimed by Wind River.
No. That is where you are dead wrong. Wind River does not own Yocto.
Think for a minute. A new Yocto user comes along and sees "intel-x86"
and because that name is so generic -- thinks "I'll build that for my old PC."
> If we need to do some local change to support some machine. That's not good.
> Because people usually build image with default configs and then complain
> something doesn't work.
Again, it is NOT the problem of the Yocto project what isn't good for YOU.
If you need EDAC and NUMA and 500+ CPU support, then make a proper BSP
with those settings and submit it as "bsp/mega-server-2000" or whatever.
Don't just be using intel-x86 as a dumping ground for whatever random
setting you need today. That isn't fair to all the oth
Re: [linux-yocto] [PATCH 3/5] x86-64: don't force EDAC support on everyone
[RE: [linux-yocto] [PATCH 3/5] x86-64: don't force EDAC support on everyone] On 30/11/2023 (Thu 19:29) Liu, Yongxin wrote: > > -Original Message- > > From: linux-yocto@lists.yoctoproject.org > yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via > > lists.yoctoproject.org > > Sent: Friday, December 1, 2023 03:08 > > To: Bruce Ashfield > > Cc: linux-yocto@lists.yoctoproject.org > > Subject: [linux-yocto] [PATCH 3/5] x86-64: don't force EDAC support on > > everyone > > > > From: Paul Gortmaker > > > > Similar to the argument of why we shouldn't force NUMA on everyone, the > > 9 chip registered ECC RAM type stuff also tends to be found mostly on > > larger server type stuff and less so on embedded targets. > > > > We already have a skeleton EDAC feature, so move the features over there. > > One could argue that we might want to separate into arch specific config > > fragments, but to me - that seems overkill at this point in time. > > > > Signed-off-by: Paul Gortmaker > > --- > > bsp/intel-x86/intel-x86-64.cfg | 13 - > > features/edac/edac.cfg | 8 > > 2 files changed, 8 insertions(+), 13 deletions(-) > > > > diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86- > > 64.cfg index f31711e73181..58b0fed637e8 100644 > > --- a/bsp/intel-x86/intel-x86-64.cfg > > +++ b/bsp/intel-x86/intel-x86-64.cfg > > @@ -3,19 +3,6 @@ > > # General setup > > # > > > > -# EDAC > > -CONFIG_EDAC=y > > -CONFIG_EDAC_DEBUG=y > > -CONFIG_EDAC_SBRIDGE=m > > -CONFIG_ACPI_APEI=y > > -CONFIG_ACPI_APEI_EINJ=m > > -CONFIG_ACPI_APEI_GHES=y > > -CONFIG_EDAC_PND2=m > > -CONFIG_EDAC_SKX=m > > -CONFIG_EDAC_I10NM=m > > -CONFIG_EDAC_IGEN6=m > > - > > - > > # ISH > > CONFIG_INTEL_ISH_HID=m > > > > diff --git a/features/edac/edac.cfg b/features/edac/edac.cfg index > > 9b3d3fc59eae..4f75d2f825ee 100644 > > --- a/features/edac/edac.cfg > > +++ b/features/edac/edac.cfg > > @@ -15,3 +15,11 @@ > > CONFIG_RAS=y > > CONFIG_EDAC=y > > CONFIG_EDAC_DEBUG=y > > +CONFIG_EDAC_SBRIDGE=m > > +CONFIG_ACPI_APEI=y > > +CONFIG_ACPI_APEI_EINJ=m > > +CONFIG_ACPI_APEI_GHES=y > > +CONFIG_EDAC_PND2=m > > +CONFIG_EDAC_SKX=m > > +CONFIG_EDAC_I10NM=m > > Other arch/bsp may include edac.scc. They clearly don't want EDAC drivers for > x86 platform. > And since CONFIG_EDAC_I10NM depends on X86_64, won't it cause warnings when > doing kernel_configcheck for other arch? Did you read the 0/5 or the commit log? I explicitly said we do this in master and then as we have the cushion of time, we see if there is demand for making an arch separation. At this point in time, my experience tells me we don't need it. Paul. -- > > > Thanks, > Yongxin > > > > +CONFIG_EDAC_IGEN6=m > > -- > > 2.40.0 > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13344): https://lists.yoctoproject.org/g/linux-yocto/message/13344 Mute This Topic: https://lists.yoctoproject.org/mt/102900653/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] [PATCH 4/5] x86-64: use the defaults for number of CPUs
[RE: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs] On
30/11/2023 (Thu 20:12) Liu, Yongxin wrote:
> > -Original Message-
> > From: linux-yocto@lists.yoctoproject.org > yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via
> > lists.yoctoproject.org
> > Sent: Friday, December 1, 2023 03:08
> > To: Bruce Ashfield
> > Cc: linux-yocto@lists.yoctoproject.org
> > Subject: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of
> > CPUs
> >
> > From: Paul Gortmaker
> >
> > The x86-64 BSP isn't quite the same as the "more specific" BSP like a
> > Beaglebone Black or the (now deleted) Edgerouter. Where we have exact
> > hardware specifics for boards like those, the x86-64 BSP is more of a
> > "generic" thing used as the baseline across an endless sea of boards.
> >
> > To that end, this is somewhat a revert of commit bd77e1f904f6
> > ("bsp/intel-x86: change the supported maximum number of CPUs to 512 in 64-
> > bit bsp")
> >
> > It is great that a handful of people out there are using Yocto on these
> > huge server machines, but that doesn't reflect 99% of the rest of us who
> > continue to lean towards the original "embedded theme" of Yocto.
> >
> > That means a whole bunch of extra per-CPU jumping through hoops; some can
> > be mitigated by booting with "nr_cpus=4" (or whatever the core count
> > is) but I guarantee largely nobody out there is doing that.
> >
> > Let those users with the crazy CPU count own that config customization
> > locally. The default is 64 which still seems way too large IMHO, but at
> > least we are moving in the right direction.
>
>
> This intel-x86-64 BSP is a generic one used from mobile to server.
>
> Customers need to customize not only the CPU number config but also other
> configs,
> like, removing unused drivers or adding debug options.
> From this point of view, there is no difference between 64 or 512.
So you've basically argued my case for me. If changes are inevitable,
then why do we change the default?
> But it changes the "rule" that intel-x86-64 works for all supported platforms.
> We need to do extra work for servers with large CPU number.
No. There is no "rule" in Yocto like that. That is nonsense because
there is no way Yocto can commit to "support" all the crazy different
x86-64 variants out there.
If a re-seller/integrator wants to take Yocto and tune it for platform
XYZ because there is customer demand and claim it is then "supported" by
them, then fine. But then to expect the Yocto project to own that? No.
Paul.
--
>
> Thanks,
> Yongxin
>
> >
> > Signed-off-by: Paul Gortmaker
> > ---
> > bsp/intel-x86/intel-x86-64.cfg | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86-
> > 64.cfg index 58b0fed637e8..da9bc7b57eca 100644
> > --- a/bsp/intel-x86/intel-x86-64.cfg
> > +++ b/bsp/intel-x86/intel-x86-64.cfg
> > @@ -31,6 +31,3 @@ CONFIG_CRYPTO_DEV_QAT_DH895xCCVF=m
> >
> > # x86 CPU resource control support
> > CONFIG_X86_CPU_RESCTRL=y
> > -
> > -# Processor type and features
> > -CONFIG_NR_CPUS=512
> > --
> > 2.40.0
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13343):
https://lists.yoctoproject.org/g/linux-yocto/message/13343
Mute This Topic: https://lists.yoctoproject.org/mt/102900654/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 5/5] BSP: remove from all - latencytop feature inclusion
From: Paul Gortmaker Consider this 5+ year old commit commit bcbc7bbc4fb967d8d4ae6333f71b73491a80b94e Author: Alexander Kanavin Date: Thu Mar 1 16:00:41 2018 +0200 latencytop: remove recipe Last commit and release were in 2009; website is down; it's a dead project. (From OE-Core rev: 36aae56e7f86a4d5ce93e4528e7dcc42f60c705e) Signed-off-by: Alexander Kanavin Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Given that, it seems sensible to drop it from default inclusion across the BSPs. I've left the feature itself, so anyone who still cares can easily manually add it still. Signed-off-by: Paul Gortmaker --- bsp/amd-x86/amd-x86-64.scc | 1 - bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.scc| 1 - bsp/common-pc/common-pc-preempt-rt.scc | 1 - bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-preempt-rt.scc | 1 - bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-standard.scc | 1 - bsp/intel-common/intel-developer-drivers.scc | 1 - bsp/intel-x86/intel-x86.scc | 1 - bsp/minnow/minnow-preempt-rt.scc | 1 - bsp/minnow/minnow-standard.scc | 1 - bsp/mti-malta32/mti-malta32.scc | 1 - bsp/mti-malta64/mti-malta64-be-developer.scc | 1 - bsp/qemu-ppc32/qemu-ppc32.scc| 1 - bsp/qemu-ppc64/qemu-ppc64-standard.scc | 3 --- bsp/qemumicroblaze/qemumicroblazeeb-standard.scc | 1 - bsp/qemumicroblaze/qemumicroblazeel-standard.scc | 1 - bsp/xilinx/zynq-standard.scc | 1 - 16 files changed, 18 deletions(-) diff --git a/bsp/amd-x86/amd-x86-64.scc b/bsp/amd-x86/amd-x86-64.scc index 8080eadcb462..87f23b51db70 100644 --- a/bsp/amd-x86/amd-x86-64.scc +++ b/bsp/amd-x86/amd-x86-64.scc @@ -9,7 +9,6 @@ include cfg/efi-ext.scc include cfg/virtio.scc include cfg/boot-live.scc include cfg/usb-mass-storage.scc -include features/latencytop/latencytop.scc include features/profiling/profiling.scc include features/netfilter/netfilter.scc diff --git a/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.scc b/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.scc index 42b9c6917593..8c654b99736f 100755 --- a/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.scc +++ b/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.scc @@ -3,7 +3,6 @@ kconf hardware bcm-2xxx-rpi.cfg include cfg/usb-mass-storage.scc include features/profiling/profiling.scc -include features/latencytop/latencytop.scc include features/hostapd/hostapd.scc include features/mac80211/mac80211.scc diff --git a/bsp/common-pc/common-pc-preempt-rt.scc b/bsp/common-pc/common-pc-preempt-rt.scc index cdba3bd014cc..7044022de9b9 100644 --- a/bsp/common-pc/common-pc-preempt-rt.scc +++ b/bsp/common-pc/common-pc-preempt-rt.scc @@ -12,6 +12,5 @@ include bsp/common-pc/common-pc.scc # default policy for preempt-rt kernels include cfg/boot-live.scc include cfg/usb-mass-storage.scc -include features/latencytop/latencytop.scc include features/profiling/profiling.scc include cfg/virtio.scc diff --git a/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-preempt-rt.scc b/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-preempt-rt.scc index 4f8bcf253f21..231d56542b7e 100644 --- a/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-preempt-rt.scc +++ b/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-preempt-rt.scc @@ -9,5 +9,4 @@ include ktypes/preempt-rt/preempt-rt.scc include fsl-mpc8315e-rdb.scc # default policy for preempt-rt kernels -include features/latencytop/latencytop.scc include features/profiling/profiling.scc diff --git a/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-standard.scc b/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-standard.scc index 0f00d23ed784..fa797badf622 100644 --- a/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-standard.scc +++ b/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-standard.scc @@ -10,5 +10,4 @@ branch fsl-mpc8315e-rdb include fsl-mpc8315e-rdb.scc # default policy for standard kernels -include features/latencytop/latencytop.scc include features/profiling/profiling.scc diff --git a/bsp/intel-common/intel-developer-drivers.scc b/bsp/intel-common/intel-developer-drivers.scc index 5bb73e3e1da2..090d05ed7d72 100644 --- a/bsp/intel-common/intel-developer-drivers.scc +++ b/bsp/intel-common/intel-developer-drivers.scc @@ -1,4 +1,3 @@ # SPDX-License-Identifier: MIT # Additional features for developer bsps -include features/latencytop/latencytop.scc include features/profiling/profiling.scc diff --git a/bsp/intel-x86/intel-x86.scc b/bsp/intel-x86/intel-x86.scc index a747961fdbd1..7825075d5dcc 100644 --- a/bsp/intel-x86/intel-x86.scc +++ b/bsp/intel-x86/intel-x86.scc @@ -29,7 +29,6 @@ include features/usb/uhci-hcd.scc include features/usb/ehci-hcd.scc include features/usb/xhci-hcd.scc include features/hostapd/hostapd.scc -include features/latencytop/latencytop.scc include features/uio/uio.scc include features/spi/spi.scc include features/mtd/mtd.scc diff --git a/bsp/minnow/minnow-preempt-rt.scc b/bsp/minnow/minnow-preempt-rt.scc index
[linux-yocto] [PATCH 3/5] x86-64: don't force EDAC support on everyone
From: Paul Gortmaker Similar to the argument of why we shouldn't force NUMA on everyone, the 9 chip registered ECC RAM type stuff also tends to be found mostly on larger server type stuff and less so on embedded targets. We already have a skeleton EDAC feature, so move the features over there. One could argue that we might want to separate into arch specific config fragments, but to me - that seems overkill at this point in time. Signed-off-by: Paul Gortmaker --- bsp/intel-x86/intel-x86-64.cfg | 13 - features/edac/edac.cfg | 8 2 files changed, 8 insertions(+), 13 deletions(-) diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86-64.cfg index f31711e73181..58b0fed637e8 100644 --- a/bsp/intel-x86/intel-x86-64.cfg +++ b/bsp/intel-x86/intel-x86-64.cfg @@ -3,19 +3,6 @@ # General setup # -# EDAC -CONFIG_EDAC=y -CONFIG_EDAC_DEBUG=y -CONFIG_EDAC_SBRIDGE=m -CONFIG_ACPI_APEI=y -CONFIG_ACPI_APEI_EINJ=m -CONFIG_ACPI_APEI_GHES=y -CONFIG_EDAC_PND2=m -CONFIG_EDAC_SKX=m -CONFIG_EDAC_I10NM=m -CONFIG_EDAC_IGEN6=m - - # ISH CONFIG_INTEL_ISH_HID=m diff --git a/features/edac/edac.cfg b/features/edac/edac.cfg index 9b3d3fc59eae..4f75d2f825ee 100644 --- a/features/edac/edac.cfg +++ b/features/edac/edac.cfg @@ -15,3 +15,11 @@ CONFIG_RAS=y CONFIG_EDAC=y CONFIG_EDAC_DEBUG=y +CONFIG_EDAC_SBRIDGE=m +CONFIG_ACPI_APEI=y +CONFIG_ACPI_APEI_EINJ=m +CONFIG_ACPI_APEI_GHES=y +CONFIG_EDAC_PND2=m +CONFIG_EDAC_SKX=m +CONFIG_EDAC_I10NM=m +CONFIG_EDAC_IGEN6=m -- 2.40.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13338): https://lists.yoctoproject.org/g/linux-yocto/message/13338 Mute This Topic: https://lists.yoctoproject.org/mt/102900653/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 2/5] x86-64: separate out the NUMA features to our existing NUMA scc/cfg
From: Paul Gortmaker A user reported getting NUMA warnings like the ones reported here: https://www.suse.com/support/kb/doc/?id=21040 "Fail to get numa node for CPU:0 bus:0 dev:0 fn:1" ...and repeated for every core on the platform. Distracting. When I asked if it was a crazy big server system with multiple CPU sockets and localized RAM near each socket - the answer was "no". Turns out they didn't choose NUMA support - rather we did it for them. Yocto has been and still remains more "embedded leaning". That is not to say we can't support NUMA. We just shouldn't be enabling it by default in the base x86-64 config fragment that everyone uses. Move the two NUMA settings that were not in our existing numa.cfg feature out of the BSP and into the feature. Signed-off-by: Paul Gortmaker --- bsp/intel-x86/intel-x86-64.cfg | 7 --- features/numa/numa.cfg | 2 ++ 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86-64.cfg index a8de30cae983..f31711e73181 100644 --- a/bsp/intel-x86/intel-x86-64.cfg +++ b/bsp/intel-x86/intel-x86-64.cfg @@ -2,13 +2,6 @@ # # General setup # -CONFIG_NUMA_BALANCING=y -CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y - -# -# ACPI NUMA -# -CONFIG_X86_64_ACPI_NUMA=y # EDAC CONFIG_EDAC=y diff --git a/features/numa/numa.cfg b/features/numa/numa.cfg index cc550c4c3c96..e925f90ea148 100644 --- a/features/numa/numa.cfg +++ b/features/numa/numa.cfg @@ -1,5 +1,7 @@ # SPDX-License-Identifier: MIT CONFIG_NUMA=y +CONFIG_NUMA_BALANCING=y +CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y CONFIG_X86_64_ACPI_NUMA=y CONFIG_NUMA_EMU=y CONFIG_NODES_SHIFT=6 -- 2.40.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13337): https://lists.yoctoproject.org/g/linux-yocto/message/13337 Mute This Topic: https://lists.yoctoproject.org/mt/102900652/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 0/5] kernel-cache: config cleanups
From: Paul Gortmaker Bruce, Here are a few things that have bugged me and finally added up to make a series possibly worthwhile. We've been forcing NUMA and EDAC and 512 CPU support on everyone: even people building for a point-of-sale terminal using an intel Atom. Doesn't make sense. Let those "big iron" server folks opt-in as they see fit using our features support. I didn't touch x86-32 in regards to the above changes, because I consider that "legacy EOL" -- which generally means "leave alone". Also, latencytop has "expired" years ago, so we catch up accordingly. Target branch is master so we have time to see if anyone complains. I don't see a lot of value in backporting to already released branches. Further details are in the commit logs. Thanks, Paul. -- Paul Gortmaker (5): x86-64: consolidate crypto options x86-64: separate out the NUMA features to our existing NUMA scc/cfg x86-64: don't force EDAC support on everyone x86-64: use the defaults for number of CPUs BSP: remove from all - latencytop feature inclusion bsp/amd-x86/amd-x86-64.scc| 1 - bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.scc | 1 - bsp/common-pc/common-pc-preempt-rt.scc| 1 - .../fsl-mpc8315e-rdb-preempt-rt.scc | 1 - .../fsl-mpc8315e-rdb-standard.scc | 1 - bsp/intel-common/intel-developer-drivers.scc | 1 - bsp/intel-x86/intel-x86-64.cfg| 31 +++ bsp/intel-x86/intel-x86.scc | 1 - bsp/minnow/minnow-preempt-rt.scc | 1 - bsp/minnow/minnow-standard.scc| 1 - bsp/mti-malta32/mti-malta32.scc | 1 - bsp/mti-malta64/mti-malta64-be-developer.scc | 1 - bsp/qemu-ppc32/qemu-ppc32.scc | 1 - bsp/qemu-ppc64/qemu-ppc64-standard.scc| 3 -- .../qemumicroblazeeb-standard.scc | 1 - .../qemumicroblazeel-standard.scc | 1 - bsp/xilinx/zynq-standard.scc | 1 - features/edac/edac.cfg| 8 + features/numa/numa.cfg| 2 ++ 19 files changed, 14 insertions(+), 45 deletions(-) -- 2.40.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13335): https://lists.yoctoproject.org/g/linux-yocto/message/13335 Mute This Topic: https://lists.yoctoproject.org/mt/102900650/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 1/5] x86-64: consolidate crypto options
From: Paul Gortmaker No functional change - just makes further reorganizations and refactoring more easy to review/parse. Signed-off-by: Paul Gortmaker --- bsp/intel-x86/intel-x86-64.cfg | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86-64.cfg index 682d5f9d125f..a8de30cae983 100644 --- a/bsp/intel-x86/intel-x86-64.cfg +++ b/bsp/intel-x86/intel-x86-64.cfg @@ -9,10 +9,6 @@ CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y # ACPI NUMA # CONFIG_X86_64_ACPI_NUMA=y -CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m -CONFIG_CRYPTO_SHA1_SSSE3=m -CONFIG_CRYPTO_SHA256_SSSE3=m -CONFIG_CRYPTO_SHA512_SSSE3=m # EDAC CONFIG_EDAC=y @@ -38,6 +34,10 @@ CONFIG_PCI_IOV=y CONFIG_CRYPTO=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_HMAC=y +CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m +CONFIG_CRYPTO_SHA1_SSSE3=m +CONFIG_CRYPTO_SHA256_SSSE3=m +CONFIG_CRYPTO_SHA512_SSSE3=m CONFIG_CRYPTO_AES_NI_INTEL=m # For different QAT devices -- 2.40.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13336): https://lists.yoctoproject.org/g/linux-yocto/message/13336 Mute This Topic: https://lists.yoctoproject.org/mt/102900651/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs
From: Paul Gortmaker
The x86-64 BSP isn't quite the same as the "more specific" BSP like a
Beaglebone Black or the (now deleted) Edgerouter. Where we have exact
hardware specifics for boards like those, the x86-64 BSP is more of a
"generic" thing used as the baseline across an endless sea of boards.
To that end, this is somewhat a revert of commit bd77e1f904f6
("bsp/intel-x86: change the supported maximum number of CPUs to 512 in 64-bit
bsp")
It is great that a handful of people out there are using Yocto on these
huge server machines, but that doesn't reflect 99% of the rest of us who
continue to lean towards the original "embedded theme" of Yocto.
That means a whole bunch of extra per-CPU jumping through hoops; some
can be mitigated by booting with "nr_cpus=4" (or whatever the core count
is) but I guarantee largely nobody out there is doing that.
Let those users with the crazy CPU count own that config customization
locally. The default is 64 which still seems way too large IMHO, but
at least we are moving in the right direction.
Signed-off-by: Paul Gortmaker
---
bsp/intel-x86/intel-x86-64.cfg | 3 ---
1 file changed, 3 deletions(-)
diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86-64.cfg
index 58b0fed637e8..da9bc7b57eca 100644
--- a/bsp/intel-x86/intel-x86-64.cfg
+++ b/bsp/intel-x86/intel-x86-64.cfg
@@ -31,6 +31,3 @@ CONFIG_CRYPTO_DEV_QAT_DH895xCCVF=m
# x86 CPU resource control support
CONFIG_X86_CPU_RESCTRL=y
-
-# Processor type and features
-CONFIG_NR_CPUS=512
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13339):
https://lists.yoctoproject.org/g/linux-yocto/message/13339
Mute This Topic: https://lists.yoctoproject.org/mt/102900654/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] [V2-revised] Microchip polarfire SoC - yocto-kernel-cache & linux-yocto V2 patch.
[Re: [linux-yocto] [V2-revised] Microchip polarfire SoC - yocto-kernel-cache & linux-yocto V2 patch.] On 16/11/2023 (Thu 18:24) Kadambathur Subramaniyam, Saravanan via lists.yoctoproject.org wrote: > Hi Bruce, > We have two requests, first one is for linux-yocto and the second one is for > Yocto-kernel-cache. I received your email about patch corruption and to > resend > V3 for the yocto-kernel-cache but this email is meant for linux-yocto. > > For the linux-yocto, since it has around 120+ patches i generated PR using > "git > request-pull" command and sent through email client(outlook). Saravanan.K.S, I am a bit concerned about your workflow, even if Bruce (or git) finally did manage to pipe your submission through w3m or ??? Firstly - "outlook" and then... > For the yocto-kernel-cache today i resent the patch twice to you through "git > send-email" but still its not delivered to you / linux-yocto mailing list... The e-mail is not instant. There are moderators involved when there are people sending who may not be subscribed - or if someone sends 100+ patches at once, a moderator might need to confirm it is not spam. If you don't wait, check, and confirm - then you risk filling the maintainer's mailbox with multiple copies, which is not nice. > PFB the log which i got from my git send-email command. I checked our build > server by sending git send-email to my email id and i received the email For the record, the git send-email doesn't really do a lot beyond looking for a Subject and Date and From line. Beyond that, you can fill the "to-send" files with complete random noise and they will send. That said, it really isn't for Bruce to review your process and find your issues. All this stuff has been solved on-line in hundreds (thousands?) of forums. But he gave you a giant hint - he wanted v3 in "plain text" - see here: https://lists.yoctoproject.org/g/linux-yocto/message/13293 There are pages in the kernel covering this: "No MIME, no links, no compression, no attachments. Just plain text" https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n280 When I opened your e-mail in gmail, this is what I saw: --_000_SJ0PR11MB82969FC0AEA199B8A587ADA1F1B0ASJ0PR11MB8296namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJ1Y2UsDQpXZSBoYXZlIHR3byByZXF1ZXN0cywgZmlyc3Qgb25lIGlzIGZvciBsaW51eC15 b2N0byBhbmQgdGhlIHNlY29uZCBvbmUgaXMgZm9yIFlvY3RvLWtlcm5lbC1jYWNoZS4gIEkgcmVj ZWl2ZWQgeW91ciBlbWFpbCBhYm91dCBwYXRjaCBjb3JydXB0aW9uIGFuZCB0byByZXNlbmQgVjMg Zm9yIHRoZSB5b2N0by1rZXJuZWwtY2FjaGUgYnV0IHRoaXMgZW1haWwgaXMgbWVhbnQgZm9yIGxp [thousands more similar unreadable lines...] See that "base64" line? That means it is not plain text. It is encoded. Once again, the kernel has some info on e-mail clients (like "outlook"). Even without that link, just scroll down your own v3 send. Notice the font size change between your mail and the one from Bruce? That tells you that you did not send plain text. > Let me check and retry sending the yocto-kernel-cache patches to you. > > In the meantime could you please help to merge the below pull request for > linux-yocto?. I'd suggest you do some more test sends with an internal co-worker before sending any more large patch series externally. Make 100% sure they are plain text - not HTML-mail or base64-mail. Bruce has been generous with his time by "unwinding" the base64 stuff this time, but we need to do better with future submissions. Thanks, Paul. -- > > Log: > skadamba@blr-linux-engg1$git send-email --annotate --subject-prefix="v3] > [yocto-kernel-cache yocto-6.1][PATCH" --to bruce.ashfi...@gmail.com > --suppress-cc=all --cc linux-yocto@lists.yoctoproject.org -M yocto-6.1 > /tmp/KrQspiQqYJ/0001-microchip-polarfire-soc-add-configure-file-for-micro.patch > OK. Log says: > Sendmail: /usr/sbin/sendmail -i bruce.ashfi...@gmail.com > linux-yocto@lists.yoctoproject.org > From: "Saravanan.K.S" > To: bruce.ashfi...@gmail.com > Cc: linux-yocto@lists.yoctoproject.org > Subject: [v3][yocto-kernel-cache yocto-6.1][PATCH] microchip-polarfire-soc: > add > configure file for microchip-polarfire-soc BSP in kernel-cache > Date: Thu, 16 Nov 2023 17:49:19 + > Message-Id: > <20231116174919.3056255-1-saravanan.kadambathursubramani...@windriver.com> > X-Mailer: git-send-email 2.40.0 > MIME-Version: 1.0 > Content-Transfer-Encoding: 8bit > > Result: OK > > --- > From: Bruce Ashfield > Sent: Thursday, November 16, 2023 11:30 PM > To: Kadambathur Subramaniyam, Saravanan > > Cc: linux-yocto@lists.yoctoproject.org > Subject: Re: [linux-yocto] [V2-revised] Microchip polarfire SoC - > yocto-kernel-cache & linux-yocto V2 patch. > > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender
Re: [linux-yocto][v5.10/standard/preempt-rt/base][PATCH] fix linux-yocto-rt compile error
[[linux-yocto][v5.10/standard/preempt-rt/base][PATCH] fix linux-yocto-rt compile error] On 22/10/2023 (Sun 19:21) Li Wang via lists.yoctoproject.org wrote: > kernel-source/include/net/sch_generic.h:198:17: error: implicit > declaration of function 'raw_write_seqcount_t_begin'; did you mean > 'raw_write_seqcount_begin'? [-Werror=implicit-function-declaration] Your commit seems reasonable, but it is missing one simple step. Running "git blame" on the unpatched file, which leads to: It isn't so much about the "blame" -- but knowing where the issure originated from, so we can direct it to other development streams if appropriate. So in doing so I see afe3f03a84d51: - commit afe3f03a84d5119b8a8af700e8360e4e4e2dc33c Author: Sebastian Andrzej Siewior AuthorDate: Tue Sep 8 16:57:11 2020 +0200 Commit: Bruce Ashfield CommitDate: Thu Dec 17 12:35:26 2020 -0500 net: Properly annotate the try-lock for the seqlock - So now we have more questions. This is an old commit from 2020. Why is it showing up as compile breakage today? Does the commit added to v5.10-yocto match the original in the linux-stable-rt repo, or did Bruce do a compile tweak for it on the fly back 3y ago and now upstream fixed the function name to not look like a typedef? Are we going to encounter the same issue on v5.15 in another 24 hours? Your job as submitter is not just to provide the "raw" fix to Bruce, but to ALSO provide the "how did we get here" story so he has a better idea of the scope of impact and can perhaps better react in the future by knowing what happened here so it can be prevented next time. Thanks, Paul. -- > > Signed-off-by: Li Wang > --- > include/net/sch_generic.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h > index 72be68652bb8..4574dd262efd 100644 > --- a/include/net/sch_generic.h > +++ b/include/net/sch_generic.h > @@ -195,7 +195,7 @@ static inline bool qdisc_run_begin(struct Qdisc *qdisc) >* Variant of write_seqcount_t_begin() telling lockdep that a >* trylock was attempted. >*/ > - raw_write_seqcount_t_begin(s); > + raw_write_seqcount_begin(s); > seqcount_acquire(>dep_map, 0, 1, _RET_IP_); > return true; > } > -- > 2.25.1 > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13222): https://lists.yoctoproject.org/g/linux-yocto/message/13222 Mute This Topic: https://lists.yoctoproject.org/mt/102114616/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] [PATCH] kernel/sched: Fix double free on invalid isolcpus/nohz_full params
[[linux-yocto] [PATCH] kernel/sched: Fix double free on invalid
isolcpus/nohz_full params] On 17/08/2023 (Thu 10:56) Adrian Cinal via
lists.yoctoproject.org wrote:
> A previous patch left behind a redundant call to free_bootmem_cpumask_var
> possibly leading to a double free (once in the if-branch and once in the
> unwind code at the end of the function) if the isolcpus= or nohz_full=
> kernel command line parameters failed validation, cf.:
>
> https://lists.yoctoproject.org/g/linux-yocto/message/12797
Once again, I wanted to know exactly how we got here. So here is how.
The key to this issue is this commit from v5.18:
commit 0cd3e59de1f53978873669c7c8225ec13e88c3ae
Author: Frederic Weisbecker
Date: Mon Feb 7 16:59:08 2022 +0100
sched/isolation: Consolidate error handling
Centralize the mask freeing and return value for the error path. This
makes potential leaks more visible.
Simple and common enough; it contains multiple instances of:
- free_bootmem_cpumask_var(non_housekeeping_mask);
- return 0;
+ goto free_non_housekeeping_mask;
But from a kernel version persepective, it means we have an "old style" free
and the "new style" free.
The patch sent to lkml was for post 5.18 kernels, and used the new style,
and was even documented as such in the 0/N (see asteriks):
-
This is a rebase and retest of two fixes I'd sent earlier[1].
The rebase is required due to conflicts in my patch #1 and where Frederic
updated the unwind code in housekeeping_setup in his series[2] and that series
is now in sched/core of tip[3].
So this update is against a baseline of ed3b362d54f0 found in sched/core as
"sched/isolation: Split housekeeping cpumask per isolation features" in tip.
**
Changes amount to "return 0" ---> "goto out_free" and adding a nod to PaulM's
observation that nohz_full w/o a cpuset is coming someday into the commit log.
**
[1]
https://lore.kernel.org/all/20211206145950.10927-1-paul.gortma...@windriver.com/
[2] https://lore.kernel.org/all/20220207155910.527133-1-frede...@kernel.org/
[3] git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
-
https://lore.kernel.org/lkml/20220221182009.1283-1-paul.gortma...@windriver.com/
Similarly, the submission for yocto for the v5.15 kernel (which was current
at the time) used the old style and everything was fine.
When yocto moved to v6.1, the uprev generally carries forward commits that
have not been merged to mainline or declared obsolete.
So the v5.15 old style commit was carried forward to v6.1, resulting in a
mix of old and new style free. Not ideal, but still functionally correct.
The double free risk comes from your change which deleted the "return 0"
underneath the old free:
https://lists.yoctoproject.org/g/linux-yocto/topic/99772129
It shouldn't have done that, and I missed it in review.
Bruce: the executive summary is that this delta fix is correct, and should
be placed on the 6.1/6.4 branches that got the previous commit from Adrian.
The yocto-kernel-cache can and should ignore all this churn, and simply
contain the post v5.18 "new style" version of the commit sent to lkml:
https://lore.kernel.org/lkml/20220221182009.1283-2-paul.gortma...@windriver.com/
Thanks,
Paul.
>
> Signed-off-by: Adrian Cinal
> ---
> kernel/sched/isolation.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
> index b97d6e05013d..7bebfdc42486 100644
> --- a/kernel/sched/isolation.c
> +++ b/kernel/sched/isolation.c
> @@ -133,7 +133,6 @@ static int __init housekeeping_setup(char *str, unsigned
> long flags)
>
> if (cpumask_empty(non_housekeeping_mask)) {
> pr_info("housekeeping: kernel parameter 'nohz_full=' or
> 'isolcpus=' has no valid CPUs.\n");
> - free_bootmem_cpumask_var(non_housekeeping_mask);
> goto free_non_housekeeping_mask;
> }
>
> --
> 2.41.0
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12998):
https://lists.yoctoproject.org/g/linux-yocto/message/12998
Mute This Topic: https://lists.yoctoproject.org/mt/100796885/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] [PATCH] kernel/sched: Fix uninitialized read in nohz_full/isolcpus setup
[Re: [linux-yocto] [PATCH] kernel/sched: Fix uninitialized read in
nohz_full/isolcpus setup] On 26/06/2023 (Mon 11:05) Paul Gortmaker wrote:
> [[linux-yocto] [PATCH] kernel/sched: Fix uninitialized read in
> nohz_full/isolcpus setup] On 25/06/2023 (Sun 18:50) Adrian Cinal via
> lists.yoctoproject.org wrote:
>
> > Fix reading uninitialized cpumask and using it to validate the nohz_full=
> > and isolcpus= kernel command line parameters.
> >
> > An older version of a patch from lkml was incorporated into linux-yocto,
> > whereas a newer, rebased version was later published. See:
> > https://lore.kernel.org/lkml/20220221182009.1283-1-paul.gortma...@windriver.com/
>
> Let me remind myself of what got merged upstream and what didn't and
> why, and I'll follow up shortly with a Yocto specific update.
Sorry for the delayed reply. The commit log kind of confused me for a
while until I had a quiet moment to get the cobwebs out of my head and
realize what happened.
Your fix is correct. The v6.1 (and v6.4) kernels are performing the
sanity tests on uninitialized memory and hence isolcpus= can randomly
reject perfectly valid inputs. Same for nohz_full= it seems.
I'd suggest we augment the commit log with this:
--
PG: To be more clear as to what happened here - it isn't a broken older
patch from lkml integrated into linux-yocto. It is a carry forward of
a correct commit from the v5.15 linux-yocto kernel:
https://git.yoctoproject.org/linux-yocto/commit/?id=97c96388922
...in which case the sanity checks are properly *after* the allocation
and processing of the bootargs into the cpumask.
However, it seems patch (or wiggle?) apparently decided to put the
sanity checks *before* the population of the cpumask during the
carry-forward and generation of the new v6.1 kernel. Meaning they are
validating uninitialized memory and hence nohz_full= and isolcpus= are
subject to random failures even for valid input ranges.
Acked-by: Paul Gortmaker
--
Bruce - both carry-forwards -- the v6.1 [d81fac6e842] and v6.4 kernels
[23b162bc3058] have this issue. The commit IDs above are in their
respective standard/base version and hence this fix will have to also
land there and be merged out to -rt and and all BSPs etc etc.
The copies in the yocto-kernel-cache also have the sanity checks above
the actual cpulist_parse(str, non_housekeeping_mask) which populates the
cpumask with the data to be validated and hence are also broken.
https://git.yoctoproject.org/yocto-kernel-cache/tree/features/clear_warn_once/sched-isolation-really-align-nohz_full-with-rcu_nocb.patch?h=yocto-6.1
https://git.yoctoproject.org/yocto-kernel-cache/tree/features/clear_warn_once/sched-isolation-really-align-nohz_full-with-rcu_nocb.patch?h=yocto-6.4
Thanks to Adrian for tracking this down and sending the fix!
Paul.
--
>
> Thanks,
> Paul.
> --
>
> >
> > Signed-off-by: Adrian Cinal
> > ---
> > kernel/sched/isolation.c | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
> > index 73386019efcb..b97d6e05013d 100644
> > --- a/kernel/sched/isolation.c
> > +++ b/kernel/sched/isolation.c
> > @@ -119,6 +119,12 @@ static int __init housekeeping_setup(char *str,
> > unsigned long flags)
> > }
> > }
> >
> > + alloc_bootmem_cpumask_var(_housekeeping_mask);
> > + if (cpulist_parse(str, non_housekeeping_mask) < 0) {
> > + pr_warn("Housekeeping: nohz_full= or isolcpus= incorrect CPU
> > range\n");
> > + goto free_non_housekeeping_mask;
> > + }
> > +
> > if (!cpumask_subset(non_housekeeping_mask, cpu_possible_mask)) {
> > pr_info("housekeeping: kernel parameter 'nohz_full=' or
> > 'isolcpus=' contains nonexistent CPUs.\n");
> > cpumask_and(non_housekeeping_mask, cpu_possible_mask,
> > @@ -128,12 +134,6 @@ static int __init housekeeping_setup(char *str,
> > unsigned long flags)
> > if (cpumask_empty(non_housekeeping_mask)) {
> > pr_info("housekeeping: kernel parameter 'nohz_full=' or
> > 'isolcpus=' has no valid CPUs.\n");
> > free_bootmem_cpumask_var(non_housekeeping_mask);
> > - return 0;
> > - }
> > -
> > - alloc_bootmem_cpumask_var(_housekeeping_mask);
> > - if (cpulist_parse(str, non_housekeeping_mask) < 0) {
> > - pr_warn("Housekeeping: nohz_full= or isolcpus= incorrect CPU
> > range\n");
> > goto free_non_housekeeping_mask;
> > }
> >
> > --
> > 2.41.0
> >
>
> >
> >
> >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12975):
https://lists.yoctoproject.org/g/linux-yocto/message/12975
Mute This Topic: https://lists.yoctoproject.org/mt/99772129/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] [PATCH] kernel/sched: Fix uninitialized read in nohz_full/isolcpus setup
[[linux-yocto] [PATCH] kernel/sched: Fix uninitialized read in
nohz_full/isolcpus setup] On 25/06/2023 (Sun 18:50) Adrian Cinal via
lists.yoctoproject.org wrote:
> Fix reading uninitialized cpumask and using it to validate the nohz_full=
> and isolcpus= kernel command line parameters.
>
> An older version of a patch from lkml was incorporated into linux-yocto,
> whereas a newer, rebased version was later published. See:
> https://lore.kernel.org/lkml/20220221182009.1283-1-paul.gortma...@windriver.com/
Let me remind myself of what got merged upstream and what didn't and
why, and I'll follow up shortly with a Yocto specific update.
Thanks,
Paul.
--
>
> Signed-off-by: Adrian Cinal
> ---
> kernel/sched/isolation.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
> index 73386019efcb..b97d6e05013d 100644
> --- a/kernel/sched/isolation.c
> +++ b/kernel/sched/isolation.c
> @@ -119,6 +119,12 @@ static int __init housekeeping_setup(char *str, unsigned
> long flags)
> }
> }
>
> + alloc_bootmem_cpumask_var(_housekeeping_mask);
> + if (cpulist_parse(str, non_housekeeping_mask) < 0) {
> + pr_warn("Housekeeping: nohz_full= or isolcpus= incorrect CPU
> range\n");
> + goto free_non_housekeeping_mask;
> + }
> +
> if (!cpumask_subset(non_housekeeping_mask, cpu_possible_mask)) {
> pr_info("housekeeping: kernel parameter 'nohz_full=' or
> 'isolcpus=' contains nonexistent CPUs.\n");
> cpumask_and(non_housekeeping_mask, cpu_possible_mask,
> @@ -128,12 +134,6 @@ static int __init housekeeping_setup(char *str, unsigned
> long flags)
> if (cpumask_empty(non_housekeeping_mask)) {
> pr_info("housekeeping: kernel parameter 'nohz_full=' or
> 'isolcpus=' has no valid CPUs.\n");
> free_bootmem_cpumask_var(non_housekeeping_mask);
> - return 0;
> - }
> -
> - alloc_bootmem_cpumask_var(_housekeeping_mask);
> - if (cpulist_parse(str, non_housekeeping_mask) < 0) {
> - pr_warn("Housekeeping: nohz_full= or isolcpus= incorrect CPU
> range\n");
> goto free_non_housekeeping_mask;
> }
>
> --
> 2.41.0
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12803):
https://lists.yoctoproject.org/g/linux-yocto/message/12803
Mute This Topic: https://lists.yoctoproject.org/mt/99772129/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] Trial merge of v5.15.111 v6.1.28 for linux-yocto
[[linux-yocto] Trial merge of v5.15.111 v6.1.28 for linux-yocto] On 12/05/2023 (Fri 10:19) Kevin Hao via lists.yoctoproject.org wrote: > Hi Bruce, > > This is a trial merge of the stable kernel v5.15.111 v6.1.28 for the > following branches in the linux-yocto. [...] > This is a much bigger stable cycle. There are 372 patches in v5.15.111 and > 611 patches in v6.1.28. That is a lot of conflicts. I hope most were semi-trivial. Sure would be nice if the stable cycles had the smaller footprint they had 10y ago. > So we got more merge conflicts than usual. There is one merge conflict in > kernel/workqueue.c on > v5.15 rt kernel, all the others are for various drivers. I believe I have > fixed all the mess and > all the merges have passed my build test. I have pushed these branches to: > https://github.com/haokexin/linux Thanks for helping out and doing this non-trivial amount of work. Paul. -- > > 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 (#12498): https://lists.yoctoproject.org/g/linux-yocto/message/12498 Mute This Topic: https://lists.yoctoproject.org/mt/98841823/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] [kernel-cache][PATCH 08/11] bsp/intel-corei7-64-preempt-rt: Add support for Time-Sensitive Network
[Re: [linux-yocto] [kernel-cache][PATCH 08/11] bsp/intel-corei7-64-preempt-rt: Add support for Time-Sensitive Network] On 07/03/2023 (Tue 16:30) Alexander Kanavin wrote: > On Tue, 7 Mar 2023 at 15:58, Paul Gortmaker > wrote: > > Unfortunately, not everything is a module. As to your "so what if the > > existing machines enable everything under the sun and install it onto > > the image" -- well obviously if people are evaluating Yocto for use in > > a system with limited storage, and the initrd is 2x bigger than their > > on-board storage size, then they are likely to just look elsewhere. > > Forgot to mention: exactly for this purpose we have poky-tiny, > linux-yocto-tiny, and core-image-initramfs-tiny. When those are > available, I'd rather have the default choices approximate binary > desktop distros as closely as possible - give me a rich command line > experience with fullest support for whatever hardware there is. I won't repeat what others have already said, but just to be clear, the kernel config for a platform is 100% independent from having "a rich command line experience" That is rootfs choice: "core-image-minimal" vs "core-image-full-cmdline". Paul. -- > > Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12235): https://lists.yoctoproject.org/g/linux-yocto/message/12235 Mute This Topic: https://lists.yoctoproject.org/mt/97420986/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] [kernel-cache][PATCH 08/11] bsp/intel-corei7-64-preempt-rt: Add support for Time-Sensitive Network
[Re: [linux-yocto] [kernel-cache][PATCH 08/11] bsp/intel-corei7-64-preempt-rt: Add support for Time-Sensitive Network] On 07/03/2023 (Tue 15:26) Alexander Kanavin wrote: > On Tue, 7 Mar 2023 at 12:07, Paul Gortmaker > wrote: > > Contrast that with attempting to maintain what amounts to an > > "intel-defconfig" setup - which will always try to please everyone > > across all boards and procfams -- and hence will never please anyone. > > ... > > > The directory name with "common" in it is an unfortunate bit of history > > that dates back to 2005 when support for a "common-pc" was modeled after > > a kernel defconfig and a COTS white-box Pentium4 home computer of the day. > > > > So, ignore the "common" -- the world has changed and so has intel -- there > > are now a wide range of x86 processors and platforms. The idea of > > having a "one config fits all" never really worked, but it definitely > > does not work in 2023. > > I beg to differ, strongly. > > I do enjoy meta-intel having only two (and a half) machine > definitions, and will resist attempts to degrade it to an arm-like zoo > of boards. The generic machines work pretty well and keep me pleased: > you can build any image against them, and that image will boot on any > reasonable x86 hardware, from the laptop in front of me to various > industrial PCs (I had three different customers with them just in the > past 6 months). You make some valid points, and I too still use the kernel's "defconfig" when I need to test something generic. But you didn't address any of the other concerns I raised - like ensuring that the x86 config doesn't go down the road to becoming a giant "allmodconfig" Maybe there is room for both - the best effort for "works for most" and also a more fine grained tuned platform config. > On the other hand, targeting specific boards will inevitably mean that > those targets will get less testing and QA, will break mysteriously > due to that, and will not be covering the complete list of what is out That is a good thing. If people aren't using something, it naturally ages out due to bitrot that nobody notices. If someone does care, they can compare the defconfig which works against the platform config and send an update. > there. And so what if the existing machines enable everything under > the sun and install it onto the image? If conserving disk space is a > business requirement, it can be addressed by replacing recommendations > with a targeted list of modules and firmwares. Unfortunately, not everything is a module. As to your "so what if the existing machines enable everything under the sun and install it onto the image" -- well obviously if people are evaluating Yocto for use in a system with limited storage, and the initrd is 2x bigger than their on-board storage size, then they are likely to just look elsewhere. I'm not looking to be argumentative or claiming I have the right answer; but I would like to see an open discussion on how to handle x86 platforms in a way that meets both needs and lets Yocto/OE benefit. Paul. -- > > Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12231): https://lists.yoctoproject.org/g/linux-yocto/message/12231 Mute This Topic: https://lists.yoctoproject.org/mt/97420986/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] [kernel-cache][PATCH 08/11] bsp/intel-corei7-64-preempt-rt: Add support for Time-Sensitive Network
[RE: [linux-yocto] [kernel-cache][PATCH 08/11] bsp/intel-corei7-64-preempt-rt: Add support for Time-Sensitive Network] On 07/03/2023 (Tue 03:29) Saini, Naveen Kumar wrote: > > > > -Original Message- > > From: linux-yocto@lists.yoctoproject.org > yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker > > Sent: Tuesday, March 7, 2023 12:20 AM > > To: Saini, Naveen Kumar > > Cc: linux-yocto@lists.yoctoproject.org > > Subject: Re: [linux-yocto] [kernel-cache][PATCH 08/11] bsp/intel-corei7-64- > > preempt-rt: Add support for Time-Sensitive Network > > > > [[linux-yocto] [kernel-cache][PATCH 08/11] bsp/intel-corei7-64-preempt-rt: > > Add support for Time-Sensitive Network] On 06/03/2023 (Mon 16:52) > > Naveen Saini via lists.yoctoproject.org wrote: > > > > > Signed-off-by: Naveen Saini > > > --- > > > bsp/intel-common/intel-corei7-64-preempt-rt.scc | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/bsp/intel-common/intel-corei7-64-preempt-rt.scc > > > b/bsp/intel-common/intel-corei7-64-preempt-rt.scc > > > index 8ec001cb..9ce0b97a 100644 > > > --- a/bsp/intel-common/intel-corei7-64-preempt-rt.scc > > > +++ b/bsp/intel-common/intel-corei7-64-preempt-rt.scc > > > @@ -11,3 +11,6 @@ include ktypes/preempt-rt/preempt-rt.scc include > > > intel-common-drivers.scc include intel-developer-drivers.scc include > > > intel-corei7-64.scc > > > + > > > +# Time-Sensitive Network > > > +include features/tsn/tsn.scc > > > > There is at least a decade worth of i7 CPU out there that don't have TSN > > support, IIRC. > > > > I can't help but think that this, and a lot of the other options you've > > enabled > > in this series are aimed at the latest and greatest, but will just add > > bloat to a > > lot of other lower end (and older) x86-64 platforms. > > Especially anything that lands in intel-common/intel-common-drivers.scc > > Thank you for reviewing. > > Yes, the goal was to enable newer features for more recent platforms from > last 2-3 years so meta-intel kernel with MACHINE values works without having > to add all these to KERNEL_FEATURES while building. OK - please use --cover-letter next time, and capture the details in the - template file so people know what you are trying to do. > > > > I can't really tell what the goal was, since your series didn't have the > > typical > > "[0/11] intel: add options for " explanation preamble. > > > > But it seems like perhaps maybe it is time to create a new file under the > > bsp/intel-common dir that reflects a certain board or family of products > > that > > have these features -- vs. being confined to the existing categorization > > dictated by existing files? > > That can be done. Are you suggesting that we add a MACHINE specific new file > here and enable these newer features in that file (like Wind River does it > using bsp/intel-x86?). But, even then won't we always have this problem > whenever we have a set of new features that need to be enabled? I'm open to whatever implementation specifics make sense. I can see how declaring a new MACHINE to cover a family of boards would work nicely. Imagine if you created a MACHINE for "Thin Canyon" NUC products from 2014 -- sadly now almost 10 years ago: https://www.intel.ca/content/www/ca/en/products/sku/78577/intel-nuc-kit-de3815tykhe/specifications.html?wapkw=DE3815TYKHE and called it intel-NUC-gen2 or whatever made sense at the time. People who care about that platform would hence - here and now - not be impacted by your driver additions on their low end/ low RAM machine. And you'll benefit on new hardware because you won't have to drag along old Kconfig settings only used by 10 year old platforms, or enable the lowest common denominator like CONFIG_MATOM on server boards. The old configs naturally age out as the user base diminishes and you are 100% free to set content for new stuff w/o handcuffs of history. Contrast that with attempting to maintain what amounts to an "intel-defconfig" setup - which will always try to please everyone across all boards and procfams -- and hence will never please anyone. > All these configuration fragments are being enabled in intel-x86/ config as > well and will be enabled in the new file we add so it just seems like a lot > of work will be duplicated to avoid having to create a new baseline/common > set of configs ... What if we create a intel- > common/intel-common-drivers-extra.scc which enables these configs so > intel-common-drivers.scc can continue to have a base set? The dire
Re: [linux-yocto] [kernel-cache][PATCH 08/11] bsp/intel-corei7-64-preempt-rt: Add support for Time-Sensitive Network
[[linux-yocto] [kernel-cache][PATCH 08/11] bsp/intel-corei7-64-preempt-rt: Add support for Time-Sensitive Network] On 06/03/2023 (Mon 16:52) Naveen Saini via lists.yoctoproject.org wrote: > Signed-off-by: Naveen Saini > --- > bsp/intel-common/intel-corei7-64-preempt-rt.scc | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/bsp/intel-common/intel-corei7-64-preempt-rt.scc > b/bsp/intel-common/intel-corei7-64-preempt-rt.scc > index 8ec001cb..9ce0b97a 100644 > --- a/bsp/intel-common/intel-corei7-64-preempt-rt.scc > +++ b/bsp/intel-common/intel-corei7-64-preempt-rt.scc > @@ -11,3 +11,6 @@ include ktypes/preempt-rt/preempt-rt.scc > include intel-common-drivers.scc > include intel-developer-drivers.scc > include intel-corei7-64.scc > + > +# Time-Sensitive Network > +include features/tsn/tsn.scc There is at least a decade worth of i7 CPU out there that don't have TSN support, IIRC. I can't help but think that this, and a lot of the other options you've enabled in this series are aimed at the latest and greatest, but will just add bloat to a lot of other lower end (and older) x86-64 platforms. Especially anything that lands in intel-common/intel-common-drivers.scc I can't really tell what the goal was, since your series didn't have the typical "[0/11] intel: add options for " explanation preamble. But it seems like perhaps maybe it is time to create a new file under the bsp/intel-common dir that reflects a certain board or family of products that have these features -- vs. being confined to the existing categorization dictated by existing files? Maybe you can describe what your end goal was, and we can go from there. Paul. -- > -- > 2.25.1 > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12226): https://lists.yoctoproject.org/g/linux-yocto/message/12226 Mute This Topic: https://lists.yoctoproject.org/mt/97420986/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] [PATCH v5.15] arm: Fix the "invalid constant" error when assembling entry-common.S
[[PATCH v5.15] arm: Fix the "invalid constant" error when assembling
entry-common.S] On 04/02/2023 (Sat 10:00) Kevin Hao wrote:
> From: Kevin Hao
>
> The commit 82f18d6a09c0 ("arm: merge fixup for duplicate
> TIF_NOTIFY_SIGNAL and other TIF_*") tried to fix the duplicate macro
> warning on rt kernel. But after that change, the new values of the TIF_*
> would cause the following assembler errors:
> arch/arm/kernel/entry-common.S: Assembler messages:
> arch/arm/kernel/entry-common.S:103: Error: invalid constant (1000e0) after
> fixup
> arch/arm/kernel/entry-common.S:286: Error: invalid constant (1000e0) after
> fixup
>
> So adjust the value of TIF_* to make the assembler happy. After this
> change, the TIF_* macros are the same as the ones in linux-6.2.y-rt.
Thanks Kevin - if the -rt version is now available and it solves the
toolchain issue as well, then we definitely want to align with that.
Paul.
--
>
> Signed-off-by: Kevin Hao
> ---
> Hi Bruce,
>
> Please help me merge this into the v5.15/standard/preempt-rt/base
> branch.
>
> arch/arm/include/asm/thread_info.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/include/asm/thread_info.h
> b/arch/arm/include/asm/thread_info.h
> index dc192d3bb4f8..d0ad47b598ee 100644
> --- a/arch/arm/include/asm/thread_info.h
> +++ b/arch/arm/include/asm/thread_info.h
> @@ -135,15 +135,15 @@ extern int vfp_restore_user_hwstate(struct user_vfp *,
> #define TIF_NOTIFY_RESUME2 /* callback before returning to user */
> #define TIF_UPROBE 3 /* breakpointed or singlestepping */
> #define TIF_NOTIFY_SIGNAL4 /* signal notifications exist */
> -#define TIF_SYSCALL_AUDIT5 /* syscall auditing active */
> -#define TIF_SYSCALL_TRACEPOINT 6 /* syscall tracepoint
> instrumentation */
> -#define TIF_SECCOMP 7 /* seccomp syscall filtering active */
> -#define TIF_NEED_RESCHED_LAZY8
> +#define TIF_NEED_RESCHED_LAZY5
>
> #define TIF_USING_IWMMXT 17
> #define TIF_MEMDIE 18 /* is terminating due to OOM killer */
> #define TIF_RESTORE_SIGMASK 19
> #define TIF_SYSCALL_TRACE20 /* syscall trace active */
> +#define TIF_SYSCALL_AUDIT21 /* syscall auditing active */
> +#define TIF_SYSCALL_TRACEPOINT 22 /* syscall tracepoint
> instrumentation */
> +#define TIF_SECCOMP 23 /* seccomp syscall filtering active */
>
>
> #define _TIF_SIGPENDING (1 << TIF_SIGPENDING)
> --
> 2.38.1
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12141):
https://lists.yoctoproject.org/g/linux-yocto/message/12141
Mute This Topic: https://lists.yoctoproject.org/mt/96737798/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH v5.15 nxp-soc] fsl_lpuart: remove another duplicate label
The v5.15 has a linux-stable specific fixup in
commit 068b51219362 ("serial: fixup backport of "serial: Deassert
Transmit Enable on probe in driver-specific way")
Unfortunately that fixup left us with a duplicate label on this
branch (and -rt branch), causing:
drivers/tty/serial/fsl_lpuart.c:2983:1: error: duplicate label
'failed_get_rs485'
| 2983 | failed_get_rs485:
| | ^~~~
|
drivers/tty/serial/fsl_lpuart.c:2975:1:
note: previous definition of 'failed_get_rs485' with type 'void'
| 2975 | failed_get_rs485:
| | ^~~~
Reading of the linux-stable fixup makes it reasonably clear that the
2nd instance of the label is the one that was meant to remain.
Signed-off-by: Paul Gortmaker
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 68a51e524f0f..aa52b3ff9279 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -2972,7 +2972,6 @@ static int lpuart_probe(struct platform_device *pdev)
return 0;
-failed_get_rs485:
uart_remove_one_port(_reg, >port);
failed_attach_port:
pm_runtime_disable(>dev);
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12136):
https://lists.yoctoproject.org/g/linux-yocto/message/12136
Mute This Topic: https://lists.yoctoproject.org/mt/96728644/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH v5.15-rt] arm: merge fixup for duplicate TIF_NOTIFY_SIGNAL and other TIF_*
This linux-stable backport: commit 855edc4ec64c197427e492c029dbf3230cc5f94c Author: Jens Axboe Date: Wed Jan 4 07:48:37 2023 -0700 ARM: renumber bits related to _TIF_WORK_MASK commit 191f8453fc99a537ea78b727acea739782378b0d upstream. conflicts with the preempt-lazy patches from the -rt folks, resulting in some post merge duplicates and compile failures like: arch/arm/include/asm/thread_info.h:141: error: "TIF_NOTIFY_SIGNAL" redefined [-Werror] Ideally I would have copied the thread_info directly from the v5.15-rt branch of linux-stable-rt[1] so that we'd stay exactly aligned with -rt upstream for when/if we integrate future updates from the preempt-rt people, but they haven't yet integrated the v5.15.87 with the offending change yet. [1] git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git Signed-off-by: Paul Gortmaker diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h index 37124cda2ca7..3c1c08b27580 100644 --- a/arch/arm/include/asm/thread_info.h +++ b/arch/arm/include/asm/thread_info.h @@ -134,16 +134,12 @@ extern int vfp_restore_user_hwstate(struct user_vfp *, #define TIF_SYSCALL_AUDIT 5 /* syscall auditing active */ #define TIF_SYSCALL_TRACEPOINT 6 /* syscall tracepoint instrumentation */ #define TIF_SECCOMP7 /* seccomp syscall filtering active */ -#define TIF_NOTIFY_SIGNAL 8 /* signal notifications exist */ -#define TIF_NEED_RESCHED_LAZY 9 +#define TIF_NEED_RESCHED_LAZY 8 #define TIF_USING_IWMMXT 17 #define TIF_MEMDIE 18 /* is terminating due to OOM killer */ #define TIF_RESTORE_SIGMASK19 #define TIF_SYSCALL_TRACE 20 /* syscall trace active */ -#define TIF_SYSCALL_AUDIT 21 /* syscall auditing active */ -#define TIF_SYSCALL_TRACEPOINT 22 /* syscall tracepoint instrumentation */ -#define TIF_SECCOMP23 /* seccomp syscall filtering active */ #define _TIF_SIGPENDING(1 << TIF_SIGPENDING) -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12123): https://lists.yoctoproject.org/g/linux-yocto/message/12123 Mute This Topic: https://lists.yoctoproject.org/mt/96573785/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 1/3] ixgbe: add the ability for the PF to disable VF link state
From: Slawomir Mrozowicz
commit f9ba6a893e5210b63c0f018d29a3c6186b5ab7f2 from
git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy
Add support for ndo_set_vf_link_state the Network Device Option that
allows the PF driver to control the virtual link state of the VF devices.
Without this change a VF cannot be disabled/enabled by the administrator.
In the implementation the auto state takes over PF link state to
VF link setting, the enable state is not supported, the disable state
shut off the VF link regardless of the PF setting.
Signed-off-by: Slawomir Mrozowicz
Tested-by: Konrad Jankowski
Signed-off-by: Tony Nguyen
CVE-2021-33061
(cherry picked from commit 366fd1000995d4cf64e1a61a0d78a051550b9841)
Signed-off-by: Cengiz Can
Acked-by: Stefan Bader
Acked-by: Tim Gardner
Signed-off-by: Stefan Bader
Signed-off-by: Paul Gortmaker
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 2 +
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 11 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 2 +
.../net/ethernet/intel/ixgbe/ixgbe_sriov.c| 207 ++
.../net/ethernet/intel/ixgbe/ixgbe_sriov.h| 4 +-
5 files changed, 182 insertions(+), 44 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index c375a5d54b40..861b2bed0cb0 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -177,6 +177,8 @@ struct vf_data_storage {
u16 pf_vlan; /* When set, guest VLAN config not allowed. */
u16 pf_qos;
u16 tx_rate;
+ int link_enable;
+ int link_state;
u8 spoofchk_enabled;
bool rss_query_enabled;
u8 trusted;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 8cb20af51ecd..61dba20fd29e 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -5682,6 +5682,9 @@ static void ixgbe_up_complete(struct ixgbe_adapter
*adapter)
ctrl_ext = IXGBE_READ_REG(hw, IXGBE_CTRL_EXT);
ctrl_ext |= IXGBE_CTRL_EXT_PFRSTD;
IXGBE_WRITE_REG(hw, IXGBE_CTRL_EXT, ctrl_ext);
+
+ /* update setting rx tx for all active vfs */
+ ixgbe_set_all_vfs(adapter);
}
void ixgbe_reinit_locked(struct ixgbe_adapter *adapter)
@@ -6139,11 +6142,8 @@ void ixgbe_down(struct ixgbe_adapter *adapter)
for (i = 0 ; i < adapter->num_vfs; i++)
adapter->vfinfo[i].clear_to_send = false;
- /* ping all the active vfs to let them know we are going down */
- ixgbe_ping_all_vfs(adapter);
-
- /* Disable all VFTE/VFRE TX/RX */
- ixgbe_disable_tx_rx(adapter);
+ /* update setting rx tx for all active vfs */
+ ixgbe_set_all_vfs(adapter);
}
/* disable transmits in the hardware now that interrupts are off */
@@ -10263,6 +10263,7 @@ static const struct net_device_ops ixgbe_netdev_ops = {
.ndo_set_vf_vlan= ixgbe_ndo_set_vf_vlan,
.ndo_set_vf_rate= ixgbe_ndo_set_vf_bw,
.ndo_set_vf_spoofchk= ixgbe_ndo_set_vf_spoofchk,
+ .ndo_set_vf_link_state = ixgbe_ndo_set_vf_link_state,
.ndo_set_vf_rss_query_en = ixgbe_ndo_set_vf_rss_query_en,
.ndo_set_vf_trust = ixgbe_ndo_set_vf_trust,
.ndo_get_vf_config = ixgbe_ndo_get_vf_config,
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
index a148534d7256..8f4316b19278 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
@@ -85,6 +85,8 @@ enum ixgbe_pfvf_api_rev {
#define IXGBE_VF_IPSEC_ADD 0x0d
#define IXGBE_VF_IPSEC_DEL 0x0e
+#define IXGBE_VF_GET_LINK_STATE 0x10 /* get vf link state */
+
/* length of permanent address message returned from PF */
#define IXGBE_VF_PERMADDR_MSG_LEN 4
/* word in permanent address message with the current multicast type */
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 0078ae592616..a1e69c734863 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -96,6 +96,7 @@ static int __ixgbe_enable_sriov(struct ixgbe_adapter *adapter,
for (i = 0; i < num_vfs; i++) {
/* enable spoof checking for all VFs */
adapter->vfinfo[i].spoofchk_enabled = true;
+ adapter->vfinfo[i].link_enable = true;
/* We support VF RSS querying only for 82599 and x540
* devices at the moment. These devices share RSS
@@ -823,6 +824,57 @@ static inline void ixgbe_write_qde(struct ixgbe_adapter
*adapter, u32 vf,
}
}
+/**
+ * ixgbe_set_vf_rx_tx - Set VF rx tx
+ * @adapter: Pointer to adapter struct
+ *
[linux-yocto] [PATCH 3/3] ixgbevf: add disable link state
From: Slawomir Mrozowicz
commit 16cf93f50f659c7eb0b3d0a6649a695023107515 from
git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy
Add possibility to disable link state if it is administratively
disabled in PF.
It is part of the general functionality that allows the PF driver
to control the state of the virtual link VF devices.
Signed-off-by: Slawomir Mrozowicz
Tested-by: Konrad Jankowski
Signed-off-by: Tony Nguyen
CVE-2021-33061
(backported from commit 443ebdd68b443ea0798c883e8aabf10d75268e92)
[cengizcan: IXGBE_VT_MSGTYPE_{NACK|ACK} were renamed in v5.17 with
commit 0edbecd57057 and the patch depends on new names. Add aliases
into `mbx.h` to fix compilation and preserve maintainability.]
Signed-off-by: Cengiz Can
Acked-by: Stefan Bader
Acked-by: Tim Gardner
Signed-off-by: Stefan Bader
Signed-off-by: Paul Gortmaker
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 2 +
.../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 11 -
drivers/net/ethernet/intel/ixgbevf/mbx.h | 12 ++
drivers/net/ethernet/intel/ixgbevf/vf.c | 42 +++
drivers/net/ethernet/intel/ixgbevf/vf.h | 1 +
5 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
index a0e325774819..89bfe4eb92f8 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
@@ -387,6 +387,8 @@ struct ixgbevf_adapter {
u32 *rss_key;
u8 rss_indir_tbl[IXGBEVF_X550_VFRETA_SIZE];
u32 flags;
+ bool link_state;
+
#define IXGBEVF_FLAGS_LEGACY_RXBIT(1)
#ifdef CONFIG_XFRM
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 7ef2e1241a76..c2e96e570f3b 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -2291,7 +2291,9 @@ static void ixgbevf_negotiate_api(struct ixgbevf_adapter
*adapter)
static void ixgbevf_up_complete(struct ixgbevf_adapter *adapter)
{
struct net_device *netdev = adapter->netdev;
+ struct pci_dev *pdev = adapter->pdev;
struct ixgbe_hw *hw = >hw;
+ bool state;
ixgbevf_configure_msix(adapter);
@@ -2304,6 +2306,11 @@ static void ixgbevf_up_complete(struct ixgbevf_adapter
*adapter)
spin_unlock_bh(>mbx_lock);
+ state = adapter->link_state;
+ hw->mac.ops.get_link_state(hw, >link_state);
+ if (state && state != adapter->link_state)
+ dev_info(>dev, "VF is administratively disabled\n");
+
smp_mb__before_atomic();
clear_bit(__IXGBEVF_DOWN, >state);
ixgbevf_napi_enable_all(adapter);
@@ -3073,6 +3080,8 @@ static int ixgbevf_sw_init(struct ixgbevf_adapter
*adapter)
adapter->tx_ring_count = IXGBEVF_DEFAULT_TXD;
adapter->rx_ring_count = IXGBEVF_DEFAULT_RXD;
+ adapter->link_state = true;
+
set_bit(__IXGBEVF_DOWN, >state);
return 0;
@@ -3305,7 +3314,7 @@ static void ixgbevf_watchdog_subtask(struct
ixgbevf_adapter *adapter)
ixgbevf_watchdog_update_link(adapter);
- if (adapter->link_up)
+ if (adapter->link_up && adapter->link_state)
ixgbevf_watchdog_link_is_up(adapter);
else
ixgbevf_watchdog_link_is_down(adapter);
diff --git a/drivers/net/ethernet/intel/ixgbevf/mbx.h
b/drivers/net/ethernet/intel/ixgbevf/mbx.h
index 853796c8ef0e..711dcebed3d0 100644
--- a/drivers/net/ethernet/intel/ixgbevf/mbx.h
+++ b/drivers/net/ethernet/intel/ixgbevf/mbx.h
@@ -51,6 +51,16 @@
/* bits 23:16 are used for exra info for certain messages */
#define IXGBE_VT_MSGINFO_MASK (0xFF << IXGBE_VT_MSGINFO_SHIFT)
+/* IXGBE_VT_MSGTYPE_NACK and IXGBE_VT_MSGTYPE_ACK were renamed to
+ * IXGBE_VT_MSGTYPE_FAILURE and IXGBE_VT_MSGTYPE_SUCCESS respectively
+ * with commit 0edbecd57057 upstream.
+ *
+ * One of the backported fixes use them with their new names. These
+ * aliases enable them to work with both older and newer names.
+ */
+#define IXGBE_VT_MSGTYPE_SUCCESS IXGBE_VT_MSGTYPE_ACK
+#define IXGBE_VT_MSGTYPE_FAILURE IXGBE_VT_MSGTYPE_NACK
+
/* definitions to support mailbox API version negotiation */
/* each element denotes a version of the API; existing numbers may not
@@ -97,6 +107,8 @@ enum ixgbe_pfvf_api_rev {
#define IXGBE_VF_IPSEC_ADD 0x0d
#define IXGBE_VF_IPSEC_DEL 0x0e
+#define IXGBE_VF_GET_LINK_STATE 0x10 /* get vf link state */
+
/* length of permanent address message returned from PF */
#define IXGBE_VF_PERMADDR_MSG_LEN 4
/* word in permanent address message with the current multicast type */
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c
b/drivers/net/ethernet/intel/ixgbevf/vf.c
index 5fc347abab3c..dbec5120d7a7 100644
--- a/drivers/net/ethernet/intel/ixgbevf
[linux-yocto] [PATCH v5.15 0/3] Backports to ixgbe for CVE-2021-33061
Bruce, Yocto kernel folks, This issue has been around for long enough that we can be reasonably confident that we won't get it fixed via linux-stable Part of that reason is that with a hands-free backport, one runs into some renaming changes between the mainline version and this older v5.15 We can see the three commits together in the netdev merge: $git log --oneline v5.18-rc1~136^2~153 ^v5.18-rc1~136^2~153~ b57b44f7496a Merge branch '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next -queue 443ebdd68b44 ixgbevf: add disable link state 008ca35f6e87 ixgbe: add improvement for MDD response functionality 366fd1000995 ixgbe: add the ability for the PF to disable VF link state ...and the same three commits were picked up by Ubuntu and SuSE: https://ubuntu.com/security/CVE-2021-33061 Ubuntu handled the renaming issues in a sensible fashion, so I decided to not reinvent the wheel and just use the versions from the Canonical folks. Build tested only, against today's v5.15/standard/base branch. Thanks, Paul. --- Slawomir Mrozowicz (3): ixgbe: add the ability for the PF to disable VF link state ixgbe: add improvement for MDD response functionality ixgbevf: add disable link state drivers/net/ethernet/intel/ixgbe/ixgbe.h | 6 + .../net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 21 ++ drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 39 +++- drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 2 + .../net/ethernet/intel/ixgbe/ixgbe_sriov.c| 207 ++ .../net/ethernet/intel/ixgbe/ixgbe_sriov.h| 4 +- drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 2 + .../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 11 +- drivers/net/ethernet/intel/ixgbevf/mbx.h | 12 + drivers/net/ethernet/intel/ixgbevf/vf.c | 42 drivers/net/ethernet/intel/ixgbevf/vf.h | 1 + 11 files changed, 301 insertions(+), 46 deletions(-) -- 2.33.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11875): https://lists.yoctoproject.org/g/linux-yocto/message/11875 Mute This Topic: https://lists.yoctoproject.org/mt/94964661/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 2/3] ixgbe: add improvement for MDD response functionality
From: Slawomir Mrozowicz
commit 64878765f925eb51d1e68a0e929c870088e42821 from
git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy
The 82599 PF driver disable VF driver after a special MDD event occurs.
Adds the option for administrators to control whether VFs are
automatically disabled after several MDD events.
The automatically disabling is now the default mode for 82599 PF driver,
as it is more reliable.
This addresses CVE-2021-33061.
Signed-off-by: Slawomir Mrozowicz
Tested-by: Konrad Jankowski
Signed-off-by: Tony Nguyen
CVE-2021-33061
(cherry picked from commit 008ca35f6e87be1d60b6af3d1ae247c6d5c2531d)
Signed-off-by: Cengiz Can
Acked-by: Stefan Bader
Acked-by: Tim Gardner
Signed-off-by: Stefan Bader
Signed-off-by: Paul Gortmaker
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 4 +++
.../net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 21 ++
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 28 ++-
3 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 861b2bed0cb0..72cb48665e82 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -184,6 +184,7 @@ struct vf_data_storage {
u8 trusted;
int xcast_mode;
unsigned int vf_api;
+ u8 primary_abort_count;
};
enum ixgbevf_xcast_modes {
@@ -555,6 +556,8 @@ struct ixgbe_mac_addr {
#define IXGBE_TRY_LINK_TIMEOUT (4 * HZ)
#define IXGBE_SFP_POLL_JIFFIES (2 * HZ)/* SFP poll every 2 seconds */
+#define IXGBE_PRIMARY_ABORT_LIMIT 5
+
/* board specific private data structure */
struct ixgbe_adapter {
unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
@@ -613,6 +616,7 @@ struct ixgbe_adapter {
#define IXGBE_FLAG2_RX_LEGACY BIT(16)
#define IXGBE_FLAG2_IPSEC_ENABLED BIT(17)
#define IXGBE_FLAG2_VF_IPSEC_ENABLED BIT(18)
+#define IXGBE_FLAG2_AUTO_DISABLE_VFBIT(19)
/* Tx fast path data */
int num_tx_queues;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index beda8e0ef7d4..0655f3b0c8c3 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -138,6 +138,8 @@ static const char
ixgbe_priv_flags_strings[][ETH_GSTRING_LEN] = {
"legacy-rx",
#define IXGBE_PRIV_FLAGS_VF_IPSEC_EN BIT(1)
"vf-ipsec",
+#define IXGBE_PRIV_FLAGS_AUTO_DISABLE_VF BIT(2)
+ "mdd-disable-vf",
};
#define IXGBE_PRIV_FLAGS_STR_LEN ARRAY_SIZE(ixgbe_priv_flags_strings)
@@ -3507,6 +3509,9 @@ static u32 ixgbe_get_priv_flags(struct net_device *netdev)
if (adapter->flags2 & IXGBE_FLAG2_VF_IPSEC_ENABLED)
priv_flags |= IXGBE_PRIV_FLAGS_VF_IPSEC_EN;
+ if (adapter->flags2 & IXGBE_FLAG2_AUTO_DISABLE_VF)
+ priv_flags |= IXGBE_PRIV_FLAGS_AUTO_DISABLE_VF;
+
return priv_flags;
}
@@ -3514,6 +3519,7 @@ static int ixgbe_set_priv_flags(struct net_device
*netdev, u32 priv_flags)
{
struct ixgbe_adapter *adapter = netdev_priv(netdev);
unsigned int flags2 = adapter->flags2;
+ unsigned int i;
flags2 &= ~IXGBE_FLAG2_RX_LEGACY;
if (priv_flags & IXGBE_PRIV_FLAGS_LEGACY_RX)
@@ -3523,6 +3529,21 @@ static int ixgbe_set_priv_flags(struct net_device
*netdev, u32 priv_flags)
if (priv_flags & IXGBE_PRIV_FLAGS_VF_IPSEC_EN)
flags2 |= IXGBE_FLAG2_VF_IPSEC_ENABLED;
+ flags2 &= ~IXGBE_FLAG2_AUTO_DISABLE_VF;
+ if (priv_flags & IXGBE_PRIV_FLAGS_AUTO_DISABLE_VF) {
+ if (adapter->hw.mac.type == ixgbe_mac_82599EB) {
+ /* Reset primary abort counter */
+ for (i = 0; i < adapter->num_vfs; i++)
+ adapter->vfinfo[i].primary_abort_count = 0;
+
+ flags2 |= IXGBE_FLAG2_AUTO_DISABLE_VF;
+ } else {
+ e_info(probe,
+ "Cannot set private flags: Operation not
supported\n");
+ return -EOPNOTSUPP;
+ }
+ }
+
if (flags2 != adapter->flags2) {
adapter->flags2 = flags2;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 61dba20fd29e..96987f9efd4a 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7611,6 +7611,27 @@ static void ixgbe_watchdog_flush_tx(struct ixgbe_adapter
*adapter)
}
#ifdef CONFIG_PCI_IOV
+static void ixgbe_bad_vf_abort(struct ixgbe_adapter *adapter, u32 vf)
+{
+ struct ixgbe_hw *hw = >hw;
+
+ if (adapter->hw.mac.type == ixgbe_mac_82599
[linux-yocto] [PATCH v5.15] bcm-2xxx-rpi: Fix select + depend CONFIG_PM Kconfig error
There is a Kconfig logic conflict as of 6ae22abe53d4 ("Merge branch
'v5.15/standard/base' into v5.15/standard/bcm-2xxx-rpi") between r-pi
SDK content:
commit b3d4b7b5af94def890f1d814414cfef9d16a7fa3
Author: Maxime Ripard
Date: Thu Aug 19 15:53:03 2021 +0200
drm/vc4: select PM
commit 39cf7db9b384a651d481d0b04d9dee540624302a from
https://github.com/raspberrypi/linux.git rpi-5.15.y
and the v5.15 backport of the upstream variant of the similar commit:
commit 80d46e73e8d3c935b6ac976caba9f5c5c6362b92
Author: Maxime Ripard
Date: Wed Jun 29 14:34:36 2022 +0200
drm/vc4: hdmi: Depends on CONFIG_PM
commit 72e2329e7c9bbe15e7a813670497ec9c6f919af3 upstream.
If you have both "depends" and "select" for the same variable, you get:
kernel/power/Kconfig:164:error: recursive dependency detected!
kernel/power/Kconfig:164: symbol PM is selected by DRM_VC4
drivers/gpu/drm/vc4/Kconfig:2: symbol DRM_VC4 depends on PM
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"
Delete the select from the SDK and keep the mainline backport depend.
Signed-off-by: Paul Gortmaker
---
Bruce: This is for v5.15/standard/bcm-2xxx-rpi branch. I would have
expected that it would be needed for the -rt variant as well, but for
some reason the -rt never got the original r-pi SDK "select" addition.
drivers/gpu/drm/vc4/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
index 4ed07b7cefe3..e2c147d4015e 100644
--- a/drivers/gpu/drm/vc4/Kconfig
+++ b/drivers/gpu/drm/vc4/Kconfig
@@ -10,7 +10,6 @@ config DRM_VC4
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
select DRM_PANEL_BRIDGE
- select PM
select SND_PCM
select SND_PCM_ELD
select SND_SOC_GENERIC_DMAENGINE_PCM
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11655):
https://lists.yoctoproject.org/g/linux-yocto/message/11655
Mute This Topic: https://lists.yoctoproject.org/mt/93637318/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] [kernel-cache][sp7021] sp7021 SoC flags update
[[linux-yocto] [kernel-cache][sp7021] sp7021 SoC flags update] On 09/09/2022 (Fri 18:24) Dvorkin Dmitry wrote: > --- > bsp/pentagram/hw_i2c.cfg | 4 ++-- > bsp/pentagram/net/sw_net.cfg | 6 - > bsp/pentagram/pentagram-debug.scc| 8 +-- > bsp/pentagram/pentagram-standard.scc | 13 +-- > bsp/pentagram/pentagram-tiny.scc | 4 > bsp/pentagram/pentagram.cfg | 33 ++-- > bsp/pentagram/sensors/hw_thermal.cfg | 6 - > bsp/pentagram/spi/sp_spi.cfg | 2 +- > bsp/pentagram/spi/spi.cfg| 2 +- > bsp/pentagram/tibbits/40_2.cfg | 1 + > bsp/pentagram/tibbits/40_2.scc | 1 + > bsp/pentagram/tibbits/42.cfg | 2 ++ > bsp/pentagram/tibbits/42.scc | 2 ++ > bsp/pentagram/tibbits/all.scc| 5 + > bsp/pentagram/usb/usb.cfg| 9 +--- > bsp/pentagram/wifi/tppg2_brcm.cfg| 2 +- > 16 files changed, 69 insertions(+), 31 deletions(-) > create mode 100644 bsp/pentagram/tibbits/40_2.cfg > create mode 100644 bsp/pentagram/tibbits/40_2.scc > create mode 100644 bsp/pentagram/tibbits/42.cfg > create mode 100644 bsp/pentagram/tibbits/42.scc > create mode 100644 bsp/pentagram/tibbits/all.scc > > diff --git a/bsp/pentagram/hw_i2c.cfg b/bsp/pentagram/hw_i2c.cfg > index 6b6b61f8..d59aada9 100644 > --- a/bsp/pentagram/hw_i2c.cfg > +++ b/bsp/pentagram/hw_i2c.cfg > @@ -1,8 +1,8 @@ > CONFIG_I2C_SUNPLUS=y > CONFIG_I2C_CHARDEV=y > -CONFIG_I2C_SMBUS=y > +## CONFIG_I2C_SMBUS=y > CONFIG_I2C_ALGOBIT=y > CONFIG_I2C_GPIO=y > CONFIG_I2C_BOARDINFO=y > -CONFIG_REGMAP_I2C=y > +## CONFIG_REGMAP_I2C=y These double-hash lines aren't one of the accepted formats for a disabled option (assuming that was your goal). If you are working with old and new kernels, the: # CONFIG_FOO is not set is the format in use for decades. If you are working exclusively with newer kernels, you can also use: CONFIG_FOO=n https://lore.kernel.org/all/20220226123755.85213-1-masahi...@kernel.org/ Paul. -- > # CONFIG_I2C_COMPAT is not set > diff --git a/bsp/pentagram/net/sw_net.cfg b/bsp/pentagram/net/sw_net.cfg > index 16788a70..39d03362 100644 > --- a/bsp/pentagram/net/sw_net.cfg > +++ b/bsp/pentagram/net/sw_net.cfg > @@ -6,6 +6,8 @@ CONFIG_PACKET=y > CONFIG_PACKET_DIAG=y > CONFIG_UNIX=y > CONFIG_INET=y > +CONFIG_TUN=m > +CONFIG_TAP=m > > CONFIG_IP_MULTICAST=y > CONFIG_IP_PNP=y > @@ -23,5 +25,7 @@ CONFIG_NETLINK_DIAG=y > CONFIG_CAN=m > CONFIG_CAIF=y > > -CONFIG_CAN_MCP25XXFD=y > +CONFIG_CAN_MCP251XFD=y > # CONFIG_NETFILTER is not set > +# debug > +## CONFIG_CAN_MCP251XFD_SANITY=y > diff --git a/bsp/pentagram/pentagram-debug.scc > b/bsp/pentagram/pentagram-debug.scc > index c1ed3cba..3bf44832 100644 > --- a/bsp/pentagram/pentagram-debug.scc > +++ b/bsp/pentagram/pentagram-debug.scc > @@ -6,6 +6,10 @@ include pentagram-standard.scc > > include debug/printk.scc > > +include debug/dyndbg.scc > + > #include debug/axi_mon.scc > -#include debug/pins0.scc > -#include debug/pins9.scc > +include debug/pins0.scc > +include debug/pins9.scc > + > +include features/ftrace/ftrace.scc > diff --git a/bsp/pentagram/pentagram-standard.scc > b/bsp/pentagram/pentagram-standard.scc > index 8ae7131d..bad4d5ee 100644 > --- a/bsp/pentagram/pentagram-standard.scc > +++ b/bsp/pentagram/pentagram-standard.scc > @@ -46,15 +46,14 @@ include media/video_usb.scc > include ui/vt.scc > include ui/gconsole.scc > > -#include sensors/thermal.scc > -#include sensors/hwmon.scc > +include sensors/hw_thermal.scc > +include sensors/hwmon.scc > > include features/can/can.scc > > include features/fuse/fuse.scc > > -# temporary there > -#include debug/pins0.scc > -#include debug/pins9.scc > -include debug/dyndbg.scc > -include debug/printk.scc > +include features/uio/uio.scc > +#include features/netfilter/netfilter.scc > + > +include tibbits/all.scc > diff --git a/bsp/pentagram/pentagram-tiny.scc > b/bsp/pentagram/pentagram-tiny.scc > index a9747fb3..af9564dd 100644 > --- a/bsp/pentagram/pentagram-tiny.scc > +++ b/bsp/pentagram/pentagram-tiny.scc > @@ -26,3 +26,7 @@ kconf non-hardware fs/ext4.cfg > include watchdog/sp.scc > > include sw_nls.scc > + > +# enabled for -debug. even in NOP mode it takes 12% of performance. > +# https://elinux.org/images/4/4b/Bird-Ftrace.pdf > +include features/ftrace/ftrace-function-tracer-disable.scc > diff --git a/bsp/pentagram/pentagram.cfg b/bsp/pentagram/pentagram.cfg > index 9f4ff708..c5e2eb2d 100644 > --- a/bsp/pentagram/pentagram.cfg > +++ b/bsp/pentagram/pentagram.cfg > @@ -51,8 +51,6 @@ CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1 > CONFIG_MAGIC_SYSRQ_SERIAL=y > CONFIG_SCHED_INFO=y > CONFIG_SCHEDSTATS=y > -# required for BLK_CGROUP > -CONFIG_CFQ_GROUP_IOSCHED=y > > # CONFIG_MEMCG_SWAP_ENABLED is not set > CONFIG_HIGHMEM=y > @@ -64,9 +62,6 @@ CONFIG_HAVE_ARCH_SECCOMP_FILTER=y > > CONFIG_CHECKPOINT_RESTORE=y > > -# is it required? > -CONFIG_BUILD_BIN2C=y >
Re: [linux-yocto][linux-yocto v5.15/standard/base][PATCH 1/1] mtd_blkdevs: add mtd_table_mutex lock back to blktrans_{open, release} to avoid race condition
[[linux-yocto][linux-yocto v5.15/standard/base][PATCH 1/1] mtd_blkdevs: add
mtd_table_mutex lock back to blktrans_{open, release} to avoid race condition]
On 09/09/2022 (Fri 16:26) LiweiSong wrote:
> without lock mtd_table_mutex in blktrans_{open, release}, there will
> be a race condition when access devices /dev/mtd1 and /dev/mtdblock1
> at the same time with a high frequency open and close test:
>
> kernel BUG at drivers/mtd/mtdcore.c:1221!
> Internal error: Oops - BUG: 0 1 PREEMPT_RT SMP
> CPU: 0 PID: 15349 Comm: mtd-test Not tainted 5.15.52-rt41-yocto-preempt-rt #1
> Hardware name: SoCFPGA Stratix 10 SoCDK (DT)
> pstate: 6005put_mtd_device+0x4c/0x84
> lr : blktrans_release+0xb0/0x120
> Call trace:
> __put_mtd_device+0x4c/0x84
> blktrans_release+0xb0/0x120
> blkdev_put+0xd4/0x210
> blkdev_close+0x34/0x50
> __fput+0x8c/0x240
> fput+0x1c/0x30
> task_work_run+0x98/00t_64_sync_handler+0xa4/0x130
> el0t_64_sync+0x1a0/0x1a4
In the interest of transparency - ongoing discussions continue on how
best to fix this in mainline - albeit slowly.
https://lore.kernel.org/all/cf66e306-f216-5247-7cff-36ce08eb4...@windriver.com/
So even while this may not be the eventual mainline solution, the
thought here is that it is a viable temporary one that resolves the
failing test case(s) for Yocto and has no known negative side effects.
Thanks,
Paul.
--
>
> since the original purpose of commit 799ae31c58ae ("mtd_blkdevs:
> don't hold del_mtd_blktrans_dev in blktrans_{open, release}") is
> to fix a DEADLOCK issue, here convert mutex_lock to mutex_trylock
> and return immediately if failed acquire mtd_table_mutex, then
> both race condition and DEADLOCK can be avoided.
>
> Fixes: 799ae31c58ae ("mtd_blkdevs: don't hold del_mtd_blktrans_dev in
> blktrans_{open, release}")
> Signed-off-by: Liwei Song
> ---
> drivers/mtd/mtd_blkdevs.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
> index b8ae1ec14e17..147e4a11dfe4 100644
> --- a/drivers/mtd/mtd_blkdevs.c
> +++ b/drivers/mtd/mtd_blkdevs.c
> @@ -188,6 +188,8 @@ static int blktrans_open(struct block_device *bdev,
> fmode_t mode)
>
> kref_get(>ref);
>
> + if (!mutex_trylock(_table_mutex))
> + return ret;
> mutex_lock(>lock);
>
> if (dev->open)
> @@ -212,6 +214,7 @@ static int blktrans_open(struct block_device *bdev,
> fmode_t mode)
> unlock:
> dev->open++;
> mutex_unlock(>lock);
> + mutex_unlock(_table_mutex);
> return ret;
>
> error_release:
> @@ -220,6 +223,7 @@ static int blktrans_open(struct block_device *bdev,
> fmode_t mode)
> error_put:
> module_put(dev->tr->owner);
> mutex_unlock(>lock);
> + mutex_unlock(_table_mutex);
> blktrans_dev_put(dev);
> return ret;
> }
> @@ -228,6 +232,8 @@ static void blktrans_release(struct gendisk *disk,
> fmode_t mode)
> {
> struct mtd_blktrans_dev *dev = disk->private_data;
>
> + if (!mutex_trylock(_table_mutex))
> + return;
> mutex_lock(>lock);
>
> if (--dev->open)
> @@ -242,6 +248,7 @@ static void blktrans_release(struct gendisk *disk,
> fmode_t mode)
> }
> unlock:
> mutex_unlock(>lock);
> + mutex_unlock(_table_mutex);
> blktrans_dev_put(dev);
> }
>
> --
> 2.36.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11642):
https://lists.yoctoproject.org/g/linux-yocto/message/11642
Mute This Topic: https://lists.yoctoproject.org/mt/93568504/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] [kernel-source][PATCH 1/1] LIN1021-3841 [PATCH] firmware: stratix10-svc: fix a conflict caused by introducing upstream commit
[[linux-yocto] [kernel-source][PATCH 1/1] LIN1021-3841 [PATCH] firmware:
stratix10-svc: fix a conflict caused by introducing upstream commit] On
12/07/2022 (Tue 12:01) Carlos Dominguez wrote:
> This building issue is caused by introducing upstream commit
> 5a0793ac66ac("firmware: stratix10-svc: fix a missing check on list iterator")
> that conflicts with sdk patch. So, adjust code to merge sdk patch and
> upstream commit together.
This doesn't specify what version it is meant for (v5.10, v5.15 ??) and
it doesn't specify which branch(es) on that version it should be applied
to. Also "conflicts with sdk patch" is vague. Please list the SDK
commit in standard format - 12 char of commit SHA followed by the
shortlog or subject.
If you don't specify that information clearly, then the maintainer has
no idea what to do with it. It isn't fair to ask them to play detective
and try and figure out what you had in mind. They have hundreds of
other submissions to merge.
Also don't include company specific internal information in external
submissions. The "LIN1021-3841" means nothing to linux-yocto readers.
Please fix and resend.
Thanks,
Paul.
--
>
> Signed-off-by: Meng Li
> Signed-off-by: Carlos Dominguez
> ---
> drivers/firmware/stratix10-svc.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/firmware/stratix10-svc.c
> b/drivers/firmware/stratix10-svc.c
> index 6e24649aa9bf..d9d1e00367ea 100644
> --- a/drivers/firmware/stratix10-svc.c
> +++ b/drivers/firmware/stratix10-svc.c
> @@ -1505,6 +1505,7 @@ void stratix10_svc_free_memory(struct
> stratix10_svc_chan *chan, void *kaddr)
>
> list_for_each_entry(pmem, _data_mem, node)
> if (pmem->vaddr == kaddr) {
> + memset(kaddr, 0, pmem->size);
> gen_pool_free(chan->ctrl->genpool,
> (unsigned long)kaddr, pmem->size);
> pmem->vaddr = NULL;
> @@ -1512,10 +1513,7 @@ void stratix10_svc_free_memory(struct
> stratix10_svc_chan *chan, void *kaddr)
> return;
> }
>
> - memset(kaddr, 0, size);
> - gen_pool_free(chan->ctrl->genpool, (unsigned long)kaddr, size);
> - pmem->vaddr = NULL;
> - list_del(>node);
> + list_del(_data_mem);
> }
> EXPORT_SYMBOL_GPL(stratix10_svc_free_memory);
>
> --
> 2.34.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11458):
https://lists.yoctoproject.org/g/linux-yocto/message/11458
Mute This Topic: https://lists.yoctoproject.org/mt/92329221/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 5.10/nxp-soc] drivers/char/Kconfig: remove extra endmenu from merge conflict
In 6e95cbda9d12e "Merge branch 'v5.10/standard/base' into
v5.10/standard/nxp-sdk-5.10/nxp-soc" there was a conflict between
linux-stable backport 4603a37f6eae ("random: credit cpu and bootloader
seeds by default") and commit 71e23f22b605 ("char: imx_amp: add sema4
driver support")
The merge left an extra endmenu in drivers/char/Kconfig resulting in:
drivers/char/Kconfig:514: 'menu' in different file than 'menu'
drivers/Kconfig:2: location of the 'menu'
drivers/Kconfig:241: syntax error
drivers/Kconfig:240: invalid statement
Signed-off-by: Paul Gortmaker
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 0faaeffc5d6c..6e8a58c3aa46 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -472,7 +472,6 @@ config ADI
driver include crash and makedumpfile.
source "drivers/char/imx_amp/Kconfig"
-endmenu
config RANDOM_TRUST_CPU
bool "Initialize RNG using CPU RNG instructions"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11450):
https://lists.yoctoproject.org/g/linux-yocto/message/11450
Mute This Topic: https://lists.yoctoproject.org/mt/92292603/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [v2][linux-yocto][linux-yocto v5.10/standard/nxp-sdk-5.10/nxp-soc & v5.10/standard/preempt-rt/nxp-sdk-5.10/nxp-soc][PATCH 1/1] crypto: caam: fix a build error 'needs_entropy_delay_adjustment' unde
[[v2][linux-yocto][linux-yocto v5.10/standard/nxp-sdk-5.10/nxp-soc &
v5.10/standard/preempt-rt/nxp-sdk-5.10/nxp-soc][PATCH 1/1] crypto: caam: fix a
build error 'needs_entropy_delay_adjustment' undefined] On 07/07/2022 (Thu
09:38) Xiaolei Wang wrote:
> Fix commit 3df7e5f2ccb8 merge conflict, refer to
> commit c013f7d1cd92 ("crypto: CAAM - fix i.mx6sx
> entry delay value"), needs_ entropy_ delay_ Adjustment
> function is referenced for this reason.
Looks good now - the maintainer can reference the commit IDs with the
"git branch --contains ..." command in addition to the subject to
confirm where the fix is supposed to go (instead of getting conflicting
information and confusion).
Thanks,
Paul.
--
>
> Signed-off-by: Xiaolei Wang
> ---
> drivers/crypto/caam/ctrl.c | 25 ++---
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
> index 679e182c3520..0d8c96d29299 100644
> --- a/drivers/crypto/caam/ctrl.c
> +++ b/drivers/crypto/caam/ctrl.c
> @@ -612,6 +612,13 @@ static void caam_dma_dev_unregister(void *data)
> platform_device_unregister(data);
> }
>
> +static bool needs_entropy_delay_adjustment(void)
> +{
> +if (of_machine_is_compatible("fsl,imx6sx"))
> +return true;
> +return false;
> +}
> +
> static int caam_ctrl_rng_init(struct device *dev)
> {
> struct caam_drv_private *ctrlpriv = dev_get_drvdata(dev);
> @@ -666,6 +673,8 @@ static int caam_ctrl_rng_init(struct device *dev)
>* Also, if a handle was instantiated, do not change
>* the TRNG parameters.
>*/
> + if (needs_entropy_delay_adjustment())
> + ent_delay = 12000;
> if (!(ctrlpriv->rng4_sh_init || inst_handles)) {
> dev_info(dev,
>"Entropy delay = %u\n",
> @@ -682,6 +691,15 @@ static int caam_ctrl_rng_init(struct device *dev)
>*/
> ret = instantiate_rng(dev, inst_handles,
> gen_sk);
> + /*
> + * Entropy delay is determined via TRNG
> characterization.
> + * TRNG characterization is run across different
> voltages
> + * and temperatures.
> + * If worst case value for ent_dly is identified,
> + * the loop can be skipped for that platform.
> + */
> +if (needs_entropy_delay_adjustment())
> +break;
> if (ret == -EAGAIN)
> /*
>* if here, the loop will rerun,
> @@ -835,13 +853,6 @@ static bool check_version(struct fsl_mc_version
> *mc_version, u32 major,
> }
> #endif
>
> -static bool needs_entropy_delay_adjustment(void)
> -{
> - if (of_machine_is_compatible("fsl,imx6sx"))
> - return true;
> - return false;
> -}
> -
> /* Probe routine for CAAM top (controller) level */
> static int caam_probe(struct platform_device *pdev)
> {
> --
> 2.25.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11443):
https://lists.yoctoproject.org/g/linux-yocto/message/11443
Mute This Topic: https://lists.yoctoproject.org/mt/92220186/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.10/standard/nxp-sdk-5.10/nxp-soc & v5.10/standard/preempt-rt/nxp-sdk-5.10/nxp-soc][PATCH 1/1] crypto: caam: fix a build error 'needs_entropy_delay_adjustment' undefine
[[linux-yocto][linux-yocto v5.10/standard/nxp-sdk-5.10/nxp-soc &
v5.10/standard/preempt-rt/nxp-sdk-5.10/nxp-soc][PATCH 1/1] crypto: caam: fix a
build error 'needs_entropy_delay_adjustment' undefined] On 05/07/2022 (Tue
22:04) Xiaolei Wang wrote:
> Fix commit f816aa7947c7 merge conflict, refer to
> commit dd36037d4ae7 ("crypto: CAAM - fix i.mx6sx
You didn't read my whole e-mail. You stopped after the subject line.
The above are still the v5.15 commit IDs.
linux-yocto$git branch --contains f816aa7947c7
v5.15/standard/nxp-sdk-5.15/nxp-soc
You need to update the two commit IDs above to be the parallel versions
found on the v5.10 branch.
Paul.
--
> entry delay value"), needs_ entropy_ delay_ Adjustment
> function is referenced for this reason.
>
> Signed-off-by: Xiaolei Wang
> ---
> drivers/crypto/caam/ctrl.c | 25 ++---
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
> index 6cd43ddb403b..37e01b0faf38 100644
> --- a/drivers/crypto/caam/ctrl.c
> +++ b/drivers/crypto/caam/ctrl.c
> @@ -612,6 +612,13 @@ static void caam_dma_dev_unregister(void *data)
> platform_device_unregister(data);
> }
>
> +static bool needs_entropy_delay_adjustment(void)
> +{
> +if (of_machine_is_compatible("fsl,imx6sx"))
> +return true;
> +return false;
> +}
> +
> static int caam_ctrl_rng_init(struct device *dev)
> {
> struct caam_drv_private *ctrlpriv = dev_get_drvdata(dev);
> @@ -666,6 +673,8 @@ static int caam_ctrl_rng_init(struct device *dev)
>* Also, if a handle was instantiated, do not change
>* the TRNG parameters.
>*/
> + if (needs_entropy_delay_adjustment())
> + ent_delay = 12000;
> if (!(ctrlpriv->rng4_sh_init || inst_handles)) {
> dev_info(dev,
>"Entropy delay = %u\n",
> @@ -682,6 +691,15 @@ static int caam_ctrl_rng_init(struct device *dev)
>*/
> ret = instantiate_rng(dev, inst_handles,
> gen_sk);
> + /*
> + * Entropy delay is determined via TRNG
> characterization.
> + * TRNG characterization is run across different
> voltages
> + * and temperatures.
> + * If worst case value for ent_dly is identified,
> + * the loop can be skipped for that platform.
> + */
> +if (needs_entropy_delay_adjustment())
> +break;
> if (ret == -EAGAIN)
> /*
>* if here, the loop will rerun,
> @@ -835,13 +853,6 @@ static bool check_version(struct fsl_mc_version
> *mc_version, u32 major,
> }
> #endif
>
> -static bool needs_entropy_delay_adjustment(void)
> -{
> - if (of_machine_is_compatible("fsl,imx6sx"))
> - return true;
> - return false;
> -}
> -
> /* Probe routine for CAAM top (controller) level */
> static int caam_probe(struct platform_device *pdev)
> {
> --
> 2.25.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11432):
https://lists.yoctoproject.org/g/linux-yocto/message/11432
Mute This Topic: https://lists.yoctoproject.org/mt/92185202/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.10/standard/nxp-sdk-5.10/nxp-soc & v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-soc][PATCH 1/1] crypto: caam: fix a build error 'needs_entropy_delay_adjustment' undefine
[[linux-yocto][linux-yocto v5.10/standard/nxp-sdk-5.10/nxp-soc &
v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-soc][PATCH 1/1] crypto: caam: fix a
build error 'needs_entropy_delay_adjustment' undefined] On 05/07/2022 (Tue
11:08) Xiaolei Wang wrote:
The above subject is confusing because Bruce already merged your v5.15
fix a week ago and now you'll waste his time having to re-check?
--
commit c3ab568b27719660fe2896c003cd1516f5832ade
(v5.15/standard/nxp-sdk-5.15/nxp-soc)
Author: Xiaolei Wang
AuthorDate: Wed Jun 29 14:03:53 2022 +0800
Commit: Bruce Ashfield
CommitDate: Wed Jun 29 18:16:59 2022 -0400
crypto: caam: fix a build error 'needs_entropy_delay_adjustment' undefined
commit ccb0a949e72605dc2b018101a54ba9600f2ed9bb
(v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-soc)
Author: Xiaolei Wang
AuthorDate: Wed Jun 29 14:03:53 2022 +0800
Commit: Bruce Ashfield
CommitDate: Wed Jun 29 18:16:42 2022 -0400
crypto: caam: fix a build error 'needs_entropy_delay_adjustment' undefined
--
> Fix commit f816aa7947c7 merge conflict, refer to
> commit dd36037d4ae7 ("crypto: CAAM - fix i.mx6sx
And these are the same old v5.15 IDs.
linux-yocto$git branch --contains f816aa7947c7
v5.15/standard/nxp-sdk-5.15/nxp-soc
You should have updated the above commit log to have the correct two
v5.10 commit IDs and sent the commit with a subject for v5.10 only.
Please be respectful of the maintainer's time. He has to process
hundreds of patches a week and he is not a mind reader. Clear
communication and attention to detail from you can mean the difference
between him spending two minutes on your merge or 30 minutes!
Thanks,
Paul.
--
> entry delay value"), needs_ entropy_ delay_ Adjustment
> function is referenced for this reason.
>
> Signed-off-by: Xiaolei Wang
> ---
> drivers/crypto/caam/ctrl.c | 25 ++---
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
> index 6cd43ddb403b..37e01b0faf38 100644
> --- a/drivers/crypto/caam/ctrl.c
> +++ b/drivers/crypto/caam/ctrl.c
> @@ -612,6 +612,13 @@ static void caam_dma_dev_unregister(void *data)
> platform_device_unregister(data);
> }
>
> +static bool needs_entropy_delay_adjustment(void)
> +{
> +if (of_machine_is_compatible("fsl,imx6sx"))
> +return true;
> +return false;
> +}
> +
> static int caam_ctrl_rng_init(struct device *dev)
> {
> struct caam_drv_private *ctrlpriv = dev_get_drvdata(dev);
> @@ -666,6 +673,8 @@ static int caam_ctrl_rng_init(struct device *dev)
>* Also, if a handle was instantiated, do not change
>* the TRNG parameters.
>*/
> + if (needs_entropy_delay_adjustment())
> + ent_delay = 12000;
> if (!(ctrlpriv->rng4_sh_init || inst_handles)) {
> dev_info(dev,
>"Entropy delay = %u\n",
> @@ -682,6 +691,15 @@ static int caam_ctrl_rng_init(struct device *dev)
>*/
> ret = instantiate_rng(dev, inst_handles,
> gen_sk);
> + /*
> + * Entropy delay is determined via TRNG
> characterization.
> + * TRNG characterization is run across different
> voltages
> + * and temperatures.
> + * If worst case value for ent_dly is identified,
> + * the loop can be skipped for that platform.
> + */
> +if (needs_entropy_delay_adjustment())
> +break;
> if (ret == -EAGAIN)
> /*
>* if here, the loop will rerun,
> @@ -835,13 +853,6 @@ static bool check_version(struct fsl_mc_version
> *mc_version, u32 major,
> }
> #endif
>
> -static bool needs_entropy_delay_adjustment(void)
> -{
> - if (of_machine_is_compatible("fsl,imx6sx"))
> - return true;
> - return false;
> -}
> -
> /* Probe routine for CAAM top (controller) level */
> static int caam_probe(struct platform_device *pdev)
> {
> --
> 2.25.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11429):
https://lists.yoctoproject.org/g/linux-yocto/message/11429
Mute This Topic: https://lists.yoctoproject.org/mt/92178631/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] [kernel-cache yocto-5.15] treewide: Drop the obsolete GPIO sysfs ABI
[[linux-yocto] [kernel-cache yocto-5.15] treewide: Drop the obsolete GPIO sysfs ABI] On 28/06/2022 (Tue 21:19) Kevin Hao wrote: > From: Kevin Hao > > The GPIO sysfs ABI has been marked as obsolete 6 years ago [1] and has > been scheduled to be removed in 2020. And then it is restricted to be > only available to expert users by commit [2]. This restriction triggers > config warning on several BSPs due to the CONFIG_EXPERT is not enabled. > Of course we can fix these warning by enabling the CONFIG_EXPERT, > but maybe it is the time to drop this obsolete option. FWIW, I agree 100%. Time to just rip off the Band-Aid and not play whack-a-mole with each BSP. Thanks, Paul. -- > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fe95046e960b > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3b4feb21158f8 > > Signed-off-by: Kevin Hao > --- > bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.cfg | 1 - > bsp/hsdk/hsdk.cfg | 1 - > bsp/intel-socfpga/intel-socfpga-64.cfg | 1 - > bsp/intel-x86/intel-x86.cfg| 1 - > bsp/minnow/minnow.cfg | 1 - > bsp/nxp-imx6/nxp-imx6.cfg | 2 -- > bsp/nxp-imx8/nxp-imx8.cfg | 1 - > bsp/renesas-rcar/renesas-rcar.cfg | 1 - > bsp/ti-am335x/ti-am335x.cfg| 1 - > bsp/ti-j72xx/ti-j72xx.cfg | 1 - > bsp/xilinx/soc/drivers-softip.cfg | 1 - > bsp/xilinx/soc/drivers-zynq.cfg| 1 - > features/minnow-io/minnow-io.cfg | 1 - > features/soc/baytrail/baytrail.cfg | 1 - > features/soc/broxton/broxton.cfg | 1 - > 15 files changed, 16 deletions(-) > > diff --git a/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.cfg > b/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.cfg > index 82a28a4e8fe2..1bd56a058399 100644 > --- a/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.cfg > +++ b/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.cfg > @@ -255,7 +255,6 @@ CONFIG_SND_SOC_WM8960=m > # GPIO Support > CONFIG_MFD_CORE=y > CONFIG_MFD_STMPE=y > -CONFIG_GPIO_SYSFS=y > CONFIG_GPIO_BCM_VIRT=y > CONFIG_MFD_ARIZONA_I2C=m > CONFIG_GPIO_ARIZONA=m > diff --git a/bsp/hsdk/hsdk.cfg b/bsp/hsdk/hsdk.cfg > index 1d75fb929456..38e97fd978fd 100644 > --- a/bsp/hsdk/hsdk.cfg > +++ b/bsp/hsdk/hsdk.cfg > @@ -42,7 +42,6 @@ CONFIG_MICREL_PHY=y > > # GPIO > CONFIG_GPIOLIB=y > -CONFIG_GPIO_SYSFS=y > CONFIG_GPIO_DWAPB=y > > # Video > diff --git a/bsp/intel-socfpga/intel-socfpga-64.cfg > b/bsp/intel-socfpga/intel-socfpga-64.cfg > index 4cfd894fcf95..2fa2405544f6 100644 > --- a/bsp/intel-socfpga/intel-socfpga-64.cfg > +++ b/bsp/intel-socfpga/intel-socfpga-64.cfg > @@ -84,7 +84,6 @@ CONFIG_SERIAL_8250_DW=y > CONFIG_SERIAL_OF_PLATFORM=y > > CONFIG_GPIOLIB=y > -CONFIG_GPIO_SYSFS=y > CONFIG_GPIO_DWAPB=y > CONFIG_GPIO_ALTERA=y > > diff --git a/bsp/intel-x86/intel-x86.cfg b/bsp/intel-x86/intel-x86.cfg > index 6b5d10463e4e..af528c39a8b4 100644 > --- a/bsp/intel-x86/intel-x86.cfg > +++ b/bsp/intel-x86/intel-x86.cfg > @@ -72,7 +72,6 @@ CONFIG_LPC_SCH=m > # GPIO drivers > # > CONFIG_GPIOLIB=y > -CONFIG_GPIO_SYSFS=y > CONFIG_GPIO_SCH=m > CONFIG_GPIO_ICH=m > CONFIG_GPIO_GENERIC_PLATFORM=m > diff --git a/bsp/minnow/minnow.cfg b/bsp/minnow/minnow.cfg > index 89a86e6df679..06d715f9cfa8 100644 > --- a/bsp/minnow/minnow.cfg > +++ b/bsp/minnow/minnow.cfg > @@ -48,7 +48,6 @@ CONFIG_SERIAL_PCH_UART_CONSOLE=y > ### Non-essential on-board features ### > > # GPIO Support > -CONFIG_GPIO_SYSFS=y > CONFIG_GPIOLIB=y > > CONFIG_GPIO_GENERIC=y > diff --git a/bsp/nxp-imx6/nxp-imx6.cfg b/bsp/nxp-imx6/nxp-imx6.cfg > index 3820031652c0..4a6382a6c17b 100644 > --- a/bsp/nxp-imx6/nxp-imx6.cfg > +++ b/bsp/nxp-imx6/nxp-imx6.cfg > @@ -84,8 +84,6 @@ CONFIG_SPI=y > CONFIG_SPI_IMX=y > CONFIG_SPI_GPIO=y > > -CONFIG_GPIO_SYSFS=y > - > CONFIG_POWER_SUPPLY=y > CONFIG_WATCHDOG=y > CONFIG_IMX2_WDT=y > diff --git a/bsp/nxp-imx8/nxp-imx8.cfg b/bsp/nxp-imx8/nxp-imx8.cfg > index 2b31fc1567ba..775f7ed211ae 100644 > --- a/bsp/nxp-imx8/nxp-imx8.cfg > +++ b/bsp/nxp-imx8/nxp-imx8.cfg > @@ -129,7 +129,6 @@ CONFIG_PINCTRL=y > CONFIG_PINCTRL_IMX8QM=y > CONFIG_PINCTRL_IMX8MQ=y > CONFIG_GPIOLIB=y > -CONFIG_GPIO_SYSFS=y > CONFIG_GPIO_MAX732X=y > CONFIG_GPIO_PCA953X=y > CONFIG_GPIO_PCA953X_IRQ=y > diff --git a/bsp/renesas-rcar/renesas-rcar.cfg > b/bsp/renesas-rcar/renesas-rcar.cfg > index 9d5461a22940..9da5849c86cb 100644 > --- a/bsp/renesas-rcar/renesas-rcar.cfg > +++ b/bsp/renesas-rcar/renesas-rcar.cfg > @@ -155,7 +155,6 @@ CONFIG_VIDEO_ADV7604_CEC=y > # GPIO configuration > CONFIG_GPIOLIB=y > CONFIG_OF_GPIO=y > -CONFIG_GPIO_SYSFS=y > CONFIG_GPIO_RCAR=y > CONFIG_GPIO_PCA953X=y > CONFIG_GPIO_PCA953X_IRQ=y > diff --git a/bsp/ti-am335x/ti-am335x.cfg b/bsp/ti-am335x/ti-am335x.cfg > index d5b9ee632185..bdf54c5d171e 100644 > --- a/bsp/ti-am335x/ti-am335x.cfg > +++ b/bsp/ti-am335x/ti-am335x.cfg > @@ -135,7 +135,6 @@ CONFIG_PINCTRL_SINGLE=y > CONFIG_GPIOLIB=y > CONFIG_OF_GPIO=y > CONFIG_GPIOLIB_IRQCHIP=y >
[linux-yocto] [PATCH 1/1] bpf: Disallow unprivileged bpf by default
From: Pawan Gupta
commit 8a03e56b253e9691c90bc52ca199323d71b96204 upstream.
Disabling unprivileged BPF would help prevent unprivileged users from
creating certain conditions required for potential speculative execution
side-channel attacks on unmitigated affected hardware.
A deep dive on such attacks and current mitigations is available here [0].
Sync with what many distros are currently applying already, and disable
unprivileged BPF by default. An admin can enable this at runtime, if
necessary, as described in 08389d888287 ("bpf: Add kconfig knob for
disabling unpriv bpf by default").
[0] "BPF and Spectre: Mitigating transient execution attacks", Daniel
Borkmann, eBPF Summit '21
https://ebpf.io/summit-2021-slides/eBPF_Summit_2021-Keynote-Daniel_Borkmann-BPF_and_Spectre.pdf
Signed-off-by: Pawan Gupta
Signed-off-by: Daniel Borkmann
Acked-by: Daniel Borkmann
Acked-by: Mark Rutland
Link:
https://lore.kernel.org/bpf/0ace9ce3f97656d5f62d11093ad7ee81190c3c25.1635535215.git.pawan.kumar.gu...@linux.intel.com
Signed-off-by: Paul Gortmaker
---
kernel/bpf/Kconfig | 7 +++
1 file changed, 7 insertions(+)
diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig
index a82d6de86522..d24d518ddd63 100644
--- a/kernel/bpf/Kconfig
+++ b/kernel/bpf/Kconfig
@@ -64,6 +64,7 @@ config BPF_JIT_DEFAULT_ON
config BPF_UNPRIV_DEFAULT_OFF
bool "Disable unprivileged BPF by default"
+ default y
depends on BPF_SYSCALL
help
Disables unprivileged BPF by default by setting the corresponding
@@ -72,6 +73,12 @@ config BPF_UNPRIV_DEFAULT_OFF
disable it by setting it to 1 (from which no other transition to
0 is possible anymore).
+ Unprivileged BPF could be used to exploit certain potential
+ speculative execution side-channel vulnerabilities on unmitigated
+ affected hardware.
+
+ If you are unsure how to answer this question, answer Y.
+
source "kernel/bpf/preload/Kconfig"
config BPF_LSM
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11303):
https://lists.yoctoproject.org/g/linux-yocto/message/11303
Mute This Topic: https://lists.yoctoproject.org/mt/91076844/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH v5.15 0/1] backport default eBPF setting from v5.16
I won't repeat what I already wrote for the parallel yocto-kernel-cache commit, other than to add that I did ask the stable team if they would consider backporting this and was told that "people are not creating new .config files for 5.15 anymore". I can understand their point, but that obviously isn't true from the point of view of Yocto. Since they aren't going to backport it, we do it ourselves to ensure we get the right setting if people aren't using the bpf.scc and for the self documenting factor in the source. Please apply to v5.15/standard/base whenever you have a chance. Thanks, Paul. --- Pawan Gupta (1): bpf: Disallow unprivileged bpf by default kernel/bpf/Kconfig | 7 +++ 1 file changed, 7 insertions(+) -- 2.32.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11304): https://lists.yoctoproject.org/g/linux-yocto/message/11304 Mute This Topic: https://lists.yoctoproject.org/mt/91076845/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [kernel-cache v5.15+] bpf: explicitly disable unpriv eBPF by default
This BPF_UNPRIV_DEFAULT_OFF option was introduced in v5.13 in
08389d888287 ("bpf: Add kconfig knob for disabling unpriv bpf by
default")
But it was added as one of those somewhat confusing double negative
things, and so the implicit "default n" that Kconfig processing meant
that unpriv eBPF was enabled by default in v5.13 through v5.15.
In v5.16 it was corrected with commit 8a03e56b253e ("bpf: Disallow
unprivileged bpf by default") since there were security concerns
relating to having it enabled.
In that commit we see "Sync with what many distros are currently
applying already, and disable unprivileged BPF by default."
In a generic x86-64 Yocto boot we currently see this in dmesg as:
Spectre V2 : WARNING: Unprivileged eBPF is enabled with eIBRS on,
data leaks possible via Spectre v2 BHB attacks!
I've suggested the stable team do a backport to v5.15, but in any
event, it probably makes sense for us to be explicit on our default.
Signed-off-by: Paul Gortmaker
diff --git a/features/bpf/bpf.cfg b/features/bpf/bpf.cfg
index b90e87a51e00..50c27ceb09c5 100644
--- a/features/bpf/bpf.cfg
+++ b/features/bpf/bpf.cfg
@@ -3,4 +3,5 @@ CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
CONFIG_BPF_JIT=y
CONFIG_BPF_EVENTS=y
+CONFIG_BPF_UNPRIV_DEFAULT_OFF=y
CONFIG_CGROUP_BPF=y
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11301):
https://lists.yoctoproject.org/g/linux-yocto/message/11301
Mute This Topic: https://lists.yoctoproject.org/mt/91070788/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH v5.10-rt] trace_events_trigger: fixup for v5.10.113 backport on -rt
The v5.10.113 brought a backport of commit ce33c845b030 "tracing:
Dump stacktrace trigger to the corresponding instance" and in that
backport it was switched from the three arg instance of __trace_stack()
to the 4 arg instance which was necessary for the older v5.10 baseline.
However the v5.10-rt has a pre-mainline snapshot of the trace reduction
args; commit 36590c50b2d0729952511129916beeea30d31d81 "tracing: Merge
irqflags + preempt counter." -- so it in fact needs the non-converted
mainline backport. So switch back to the 3 arg instance to solve:
kernel/trace/trace_events_trigger.c:1227:17: error: too many arguments
to function '__trace_stack'
Signed-off-by: Paul Gortmaker
diff --git a/kernel/trace/trace_events_trigger.c
b/kernel/trace/trace_events_trigger.c
index 4bc90965abb2..6e2e41f73d40 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -1224,7 +1224,7 @@ stacktrace_trigger(struct event_trigger_data *data, void
*rec,
if (file) {
local_save_flags(flags);
- __trace_stack(file->tr, flags, STACK_SKIP, preempt_count());
+ __trace_stack(file->tr, tracing_gen_ctx(), STACK_SKIP);
} else
trace_dump_stack(STACK_SKIP);
}
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11278):
https://lists.yoctoproject.org/g/linux-yocto/message/11278
Mute This Topic: https://lists.yoctoproject.org/mt/90939210/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/preempt-rt/nxp-sdk-5.10/nxp-s32g][PATCH] s32g: serdes: add new function get_lane_id to retrieve lane_id
[[linux-yocto][v5.15/standard/preempt-rt/nxp-sdk-5.10/nxp-s32g][PATCH] s32g:
serdes: add new function get_lane_id to retrieve lane_id] On 27/04/2022 (Wed
19:32) quanyang.wang wrote:
> From: Quanyang Wang
>
> The phy->id is an unique id under _ida after calling phy_create,
> but the s32g serdes driver uses it to save lane_id (0 or 1), this results
> that phy->id is not unique anymore and will trigger calltrace as below
> for being freed multiple times.
>
> [ 129.135513] ida_free called for id=0 which is not allocated.
> [ 129.135668] WARNING: CPU: 3 PID: 46 at lib/idr.c:524 ida_free+0x13c/0x150
> [ 129.135704] Modules linked in:
> [ 129.135718] CPU: 3 PID: 46 Comm: kworker/3:1 Tainted: GW
> 5.15.35-rt34-yocto
> -preempt-rt #21
[...]
> Let's introduce a new function get_lane_id to retrieve lane_id instead
> of saving it in phy->id.
[...]
>
> +static int get_lane_id(struct phy *phy)
> +{
> + struct serdes *serdes = phy_get_drvdata(phy);
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(serdes->phys); i++)
> + if (serdes->phys[i] == phy)
> + return i;
> +
> + WRAN_ON(i == ARRAY_SIZE(serdes->phys));
^^^
I think you better check that what you sent here to the list was
actually what you compiled and tested.
Maintainers can easily fix typos like this but it raises a lot of
doubt as to whether it was tested, or what was sent was not actually
a copy of what was tested and instead just being a "first pass".
Thanks,
Paul.
--
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11259):
https://lists.yoctoproject.org/g/linux-yocto/message/11259
Mute This Topic: https://lists.yoctoproject.org/mt/90728279/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 14/14] rcu: Avoid alloc_pages() when recording stack
From: Jun Miao
commit 300c0c5e721834f484b03fa3062602dd8ff48413 upstream.
The default kasan_record_aux_stack() calls stack_depot_save() with GFP_NOWAIT,
which in turn can then call alloc_pages(GFP_NOWAIT, ...). In general, however,
it is not even possible to use either GFP_ATOMIC nor GFP_NOWAIT in certain
non-preemptive contexts/RT kernel including raw_spin_locks (see gfp.h and
ab00db216c9c7).
Fix it by instructing stackdepot to not expand stack storage via alloc_pages()
in case it runs out by using kasan_record_aux_stack_noalloc().
Jianwei Hu reported:
BUG: sleeping function called from invalid context at
kernel/locking/rtmutex.c:969
in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 15319, name: python3
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last enabled at (0): [<>] 0x0
hardirqs last disabled at (0): [] copy_process+0xaf3/0x2590
softirqs last enabled at (0): [] copy_process+0xaf3/0x2590
softirqs last disabled at (0): [<>] 0x0
CPU: 6 PID: 15319 Comm: python3 Tainted: GW O 5.15-rc7-preempt-rt #1
Hardware name: Supermicro SYS-E300-9A-8C/A2SDi-8C-HLN4F, BIOS 1.1b 12/17/2018
Call Trace:
show_stack+0x52/0x58
dump_stack+0xa1/0xd6
___might_sleep.cold+0x11c/0x12d
rt_spin_lock+0x3f/0xc0
rmqueue+0x100/0x1460
rmqueue+0x100/0x1460
mark_usage+0x1a0/0x1a0
ftrace_graph_ret_addr+0x2a/0xb0
rmqueue_pcplist.constprop.0+0x6a0/0x6a0
__kasan_check_read+0x11/0x20
__zone_watermark_ok+0x114/0x270
get_page_from_freelist+0x148/0x630
is_module_text_address+0x32/0xa0
__alloc_pages_nodemask+0x2f6/0x790
__alloc_pages_slowpath.constprop.0+0x12d0/0x12d0
create_prof_cpu_mask+0x30/0x30
alloc_pages_current+0xb1/0x150
stack_depot_save+0x39f/0x490
kasan_save_stack+0x42/0x50
kasan_save_stack+0x23/0x50
kasan_record_aux_stack+0xa9/0xc0
__call_rcu+0xff/0x9c0
call_rcu+0xe/0x10
put_object+0x53/0x70
__delete_object+0x7b/0x90
kmemleak_free+0x46/0x70
slab_free_freelist_hook+0xb4/0x160
kfree+0xe5/0x420
kfree_const+0x17/0x30
kobject_cleanup+0xaa/0x230
kobject_put+0x76/0x90
netdev_queue_update_kobjects+0x17d/0x1f0
... ...
ksys_write+0xd9/0x180
__x64_sys_write+0x42/0x50
do_syscall_64+0x38/0x50
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Links:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/kasan.h?id=7cb3007ce2da27ec02a1a3211941e7fe6875b642
Fixes: 84109ab58590 ("rcu: Record kvfree_call_rcu() call stack for KASAN")
Fixes: 26e760c9a7c8 ("rcu: kasan: record and print call_rcu() call stack")
Reported-by: Jianwei Hu
Reviewed-by: Uladzislau Rezki (Sony)
Acked-by: Marco Elver
Tested-by: Juri Lelli
Signed-off-by: Jun Miao
Signed-off-by: Paul E. McKenney
Signed-off-by: Paul Gortmaker
---
kernel/rcu/tree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 4ca6d5b199e8..e61ff3b80a9a 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2985,7 +2985,7 @@ __call_rcu(struct rcu_head *head, rcu_callback_t func)
head->func = func;
head->next = NULL;
local_irq_save(flags);
- kasan_record_aux_stack(head);
+ kasan_record_aux_stack_noalloc(head);
rdp = this_cpu_ptr(_data);
/* Add the callback to our list. */
@@ -3550,7 +3550,7 @@ void kvfree_call_rcu(struct rcu_head *head,
rcu_callback_t func)
return;
}
- kasan_record_aux_stack(ptr);
+ kasan_record_aux_stack_noalloc(ptr);
success = add_ptr_to_bulk_krc_lock(, , ptr, !head);
if (!success) {
run_page_cache_worker(krcp);
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11159):
https://lists.yoctoproject.org/g/linux-yocto/message/11159
Mute This Topic: https://lists.yoctoproject.org/mt/90342157/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 13/14] kasan: test: silence intentional read overflow warnings
From: Kees Cook
commit cab71f7495f7aa639ca4b8508f4c3e426e9cb2f7 upstream.
As done in commit d73dad4eb5ad ("kasan: test: bypass __alloc_size
checks") for __write_overflow warnings, also silence some more cases
that trip the __read_overflow warnings seen in 5.16-rc1[1]:
In file included from include/linux/string.h:253,
from include/linux/bitmap.h:10,
from include/linux/cpumask.h:12,
from include/linux/mm_types_task.h:14,
from include/linux/mm_types.h:5,
from include/linux/page-flags.h:13,
from arch/arm64/include/asm/mte.h:14,
from arch/arm64/include/asm/pgtable.h:12,
from include/linux/pgtable.h:6,
from include/linux/kasan.h:29,
from lib/test_kasan.c:10:
In function 'memcmp',
inlined from 'kasan_memcmp' at lib/test_kasan.c:897:2:
include/linux/fortify-string.h:263:25: error: call to '__read_overflow'
declared with attribute error: detected read beyond size of object (1st
parameter)
263 | __read_overflow();
| ^
In function 'memchr',
inlined from 'kasan_memchr' at lib/test_kasan.c:872:2:
include/linux/fortify-string.h:277:17: error: call to '__read_overflow'
declared with attribute error: detected read beyond size of object (1st
parameter)
277 | __read_overflow();
| ^
[1] http://kisskb.ellerman.id.au/kisskb/buildresult/14660585/log/
Link: https://lkml.kernel.org/r/2026004111.3171781-1-keesc...@chromium.org
Fixes: d73dad4eb5ad ("kasan: test: bypass __alloc_size checks")
Signed-off-by: Kees Cook
Reviewed-by: Andrey Konovalov
Acked-by: Marco Elver
Cc: Andrey Ryabinin
Cc: Alexander Potapenko
Cc: Dmitry Vyukov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Paul Gortmaker
---
lib/test_kasan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index 5475fe396ff7..de300ab98096 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -869,6 +869,7 @@ static void kasan_memchr(struct kunit *test)
ptr = kmalloc(size, GFP_KERNEL | __GFP_ZERO);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);
+ OPTIMIZER_HIDE_VAR(size);
KUNIT_EXPECT_KASAN_FAIL(test,
kasan_ptr_result = memchr(ptr, '1', size + 1));
@@ -894,6 +895,7 @@ static void kasan_memcmp(struct kunit *test)
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);
memset(arr, 0, sizeof(arr));
+ OPTIMIZER_HIDE_VAR(size);
KUNIT_EXPECT_KASAN_FAIL(test,
kasan_int_result = memcmp(ptr, arr, size+1));
kfree(ptr);
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11158):
https://lists.yoctoproject.org/g/linux-yocto/message/11158
Mute This Topic: https://lists.yoctoproject.org/mt/90342156/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 08/14] kasan: test: add memcpy test that avoids out-of-bounds write
From: Peter Collingbourne
commit 758cabae312d3aded781aacc6d0c946b299c52df upstream.
With HW tag-based KASAN, error checks are performed implicitly by the
load and store instructions in the memcpy implementation. A failed
check results in tag checks being disabled and execution will keep
going. As a result, under HW tag-based KASAN, prior to commit
1b0668be62cf ("kasan: test: disable kmalloc_memmove_invalid_size for
HW_TAGS"), this memcpy would end up corrupting memory until it hits an
inaccessible page and causes a kernel panic.
This is a pre-existing issue that was revealed by commit 285133040e6c
("arm64: Import latest memcpy()/memmove() implementation") which changed
the memcpy implementation from using signed comparisons (incorrectly,
resulting in the memcpy being terminated early for negative sizes) to
using unsigned comparisons.
It is unclear how this could be handled by memcpy itself in a reasonable
way. One possibility would be to add an exception handler that would
force memcpy to return if a tag check fault is detected -- this would
make the behavior roughly similar to generic and SW tag-based KASAN.
However, this wouldn't solve the problem for asynchronous mode and also
makes memcpy behavior inconsistent with manually copying data.
This test was added as a part of a series that taught KASAN to detect
negative sizes in memory operations, see commit 8cceeff48f23 ("kasan:
detect negative size in memory operation function"). Therefore we
should keep testing for negative sizes with generic and SW tag-based
KASAN. But there is some value in testing small memcpy overflows, so
let's add another test with memcpy that does not destabilize the kernel
by performing out-of-bounds writes, and run it in all modes.
Link:
https://linux-review.googlesource.com/id/I048d1e6a9aff766c4a53f989fb0c83de68923882
Link: https://lkml.kernel.org/r/20210910211356.3603758-1-...@google.com
Signed-off-by: Peter Collingbourne
Reviewed-by: Andrey Konovalov
Acked-by: Marco Elver
Cc: Robin Murphy
Cc: Will Deacon
Cc: Catalin Marinas
Cc: Mark Rutland
Cc: Evgenii Stepanov
Cc: Alexander Potapenko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Paul Gortmaker
---
lib/test_kasan.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index 8835e0784578..aa8e42250219 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -493,7 +493,7 @@ static void kmalloc_oob_in_memset(struct kunit *test)
kfree(ptr);
}
-static void kmalloc_memmove_invalid_size(struct kunit *test)
+static void kmalloc_memmove_negative_size(struct kunit *test)
{
char *ptr;
size_t size = 64;
@@ -515,6 +515,21 @@ static void kmalloc_memmove_invalid_size(struct kunit
*test)
kfree(ptr);
}
+static void kmalloc_memmove_invalid_size(struct kunit *test)
+{
+ char *ptr;
+ size_t size = 64;
+ volatile size_t invalid_size = size;
+
+ ptr = kmalloc(size, GFP_KERNEL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);
+
+ memset((char *)ptr, 0, 64);
+ KUNIT_EXPECT_KASAN_FAIL(test,
+ memmove((char *)ptr, (char *)ptr + 4, invalid_size));
+ kfree(ptr);
+}
+
static void kmalloc_uaf(struct kunit *test)
{
char *ptr;
@@ -1129,6 +1144,7 @@ static struct kunit_case kasan_kunit_test_cases[] = {
KUNIT_CASE(kmalloc_oob_memset_4),
KUNIT_CASE(kmalloc_oob_memset_8),
KUNIT_CASE(kmalloc_oob_memset_16),
+ KUNIT_CASE(kmalloc_memmove_negative_size),
KUNIT_CASE(kmalloc_memmove_invalid_size),
KUNIT_CASE(kmalloc_uaf),
KUNIT_CASE(kmalloc_uaf_memset),
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11155):
https://lists.yoctoproject.org/g/linux-yocto/message/11155
Mute This Topic: https://lists.yoctoproject.org/mt/90342153/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 12/14] kasan: arm64: fix pcpu_page_first_chunk crash with KASAN_VMALLOC
From: Kefeng Wang
commit 3252b1d8309ea42bc6329d9341072ecf1c9505c0 upstream.
With KASAN_VMALLOC and NEED_PER_CPU_PAGE_FIRST_CHUNK the kernel crashes:
Unable to handle kernel paging request at virtual address 728f2000
...
swapper pgtable: 64k pages, 48-bit VAs, pgdp=4244
[728f2000] pgd=00063e7c0003, p4d=00063e7c0003,
pud=00063e7c0003, pmd=00063e7b0003, pte=
Internal error: Oops: 9607 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.0-rc4-3-gc6e6e28f3f30-dirty
#62
Hardware name: linux,dummy-virt (DT)
pstate: 20c5 (nzCv daIF -PAN -UAO -TCO BTYPE=--)
pc : kasan_check_range+0x90/0x1a0
lr : memcpy+0x88/0xf4
sp : 80001378fe20
...
Call trace:
kasan_check_range+0x90/0x1a0
pcpu_page_first_chunk+0x3f0/0x568
setup_per_cpu_areas+0xb8/0x184
start_kernel+0x8c/0x328
The vm area used in vm_area_register_early() has no kasan shadow memory,
Let's add a new kasan_populate_early_vm_area_shadow() function to
populate the vm area shadow memory to fix the issue.
[wangkefeng.w...@huawei.com: fix redefinition of
'kasan_populate_early_vm_area_shadow']
Link:
https://lkml.kernel.org/r/20211011123211.3936196-1-wangkefeng.w...@huawei.com
Link:
https://lkml.kernel.org/r/20210910053354.26721-4-wangkefeng.w...@huawei.com
Signed-off-by: Kefeng Wang
Acked-by: Marco Elver [KASAN]
Acked-by: Andrey Konovalov[KASAN]
Acked-by: Catalin Marinas
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Cc: Greg Kroah-Hartman
Cc: Will Deacon
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Paul Gortmaker
---
arch/arm64/mm/kasan_init.c | 16
include/linux/kasan.h | 6 ++
mm/kasan/shadow.c | 5 +
mm/vmalloc.c | 1 +
4 files changed, 28 insertions(+)
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index 61b52a92b8b6..5b996ca4d996 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -287,6 +287,22 @@ static void __init kasan_init_depth(void)
init_task.kasan_depth = 0;
}
+#ifdef CONFIG_KASAN_VMALLOC
+void __init kasan_populate_early_vm_area_shadow(void *start, unsigned long
size)
+{
+ unsigned long shadow_start, shadow_end;
+
+ if (!is_vmalloc_or_module_addr(start))
+ return;
+
+ shadow_start = (unsigned long)kasan_mem_to_shadow(start);
+ shadow_start = ALIGN_DOWN(shadow_start, PAGE_SIZE);
+ shadow_end = (unsigned long)kasan_mem_to_shadow(start + size);
+ shadow_end = ALIGN(shadow_end, PAGE_SIZE);
+ kasan_map_populate(shadow_start, shadow_end, NUMA_NO_NODE);
+}
+#endif
+
void __init kasan_init(void)
{
kasan_init_shadow();
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index a63b2a5dd762..3040e80a15cc 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -436,6 +436,8 @@ void kasan_release_vmalloc(unsigned long start, unsigned
long end,
unsigned long free_region_start,
unsigned long free_region_end);
+void kasan_populate_early_vm_area_shadow(void *start, unsigned long size);
+
#else /* CONFIG_KASAN_VMALLOC */
static inline int kasan_populate_vmalloc(unsigned long start,
@@ -453,6 +455,10 @@ static inline void kasan_release_vmalloc(unsigned long
start,
unsigned long free_region_start,
unsigned long free_region_end) {}
+static inline void kasan_populate_early_vm_area_shadow(void *start,
+ unsigned long size)
+{ }
+
#endif /* CONFIG_KASAN_VMALLOC */
#if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \
diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
index dd79840e6096..94136f84b449 100644
--- a/mm/kasan/shadow.c
+++ b/mm/kasan/shadow.c
@@ -254,6 +254,11 @@ core_initcall(kasan_memhotplug_init);
#ifdef CONFIG_KASAN_VMALLOC
+void __init __weak kasan_populate_early_vm_area_shadow(void *start,
+ unsigned long size)
+{
+}
+
static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned long addr,
void *unused)
{
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 1421b8421834..f9b817eae173 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2287,6 +2287,7 @@ void __init vm_area_register_early(struct vm_struct *vm,
size_t align)
vm->addr = (void *)addr;
vm->next = *p;
*p = vm;
+ kasan_populate_early_vm_area_shadow(vm->addr, vm->size);
}
static void vmap_init_free_space(void)
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11156):
https://lists.yoctoproject.org/g/linux-yocto/message/11156
Mute This Topic: https://lists.yoctoproject.org/mt/903421
[linux-yocto] [PATCH 11/14] arm64: support page mapping percpu first chunk allocator
From: Kefeng Wang
commit 09cea6195073ee1d0f076d907d9249045757245d upstream.
Percpu embedded first chunk allocator is the firstly option, but it
could fails on ARM64, eg,
percpu: max_distance=0x5fcfdc64 too large for vmalloc space 0x781fefff
percpu: max_distance=0x6054 too large for vmalloc space 0x7dffb7ff
percpu: max_distance=0x5fff9adb too large for vmalloc space 0x5dffb7ff
then we could get
WARNING: CPU: 15 PID: 461 at vmalloc.c:3087 pcpu_get_vm_areas+0x488/0x838
and the system could not boot successfully.
Let's implement page mapping percpu first chunk allocator as a fallback
to the embedding allocator to increase the robustness of the system.
Link:
https://lkml.kernel.org/r/20210910053354.26721-3-wangkefeng.w...@huawei.com
Signed-off-by: Kefeng Wang
Reviewed-by: Catalin Marinas
Cc: Andrey Konovalov
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Cc: Greg Kroah-Hartman
Cc: Marco Elver
Cc: Will Deacon
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Paul Gortmaker
---
arch/arm64/Kconfig | 4 ++
drivers/base/arch_numa.c | 82 +++-
2 files changed, 76 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1a18c9045773..3cf204df9aed 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1042,6 +1042,10 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
def_bool y
depends on NUMA
+config NEED_PER_CPU_PAGE_FIRST_CHUNK
+ def_bool y
+ depends on NUMA
+
source "kernel/Kconfig.hz"
config ARCH_SPARSEMEM_ENABLE
diff --git a/drivers/base/arch_numa.c b/drivers/base/arch_numa.c
index 00fb4120a5b3..28222688ace7 100644
--- a/drivers/base/arch_numa.c
+++ b/drivers/base/arch_numa.c
@@ -14,6 +14,7 @@
#include
#include
+#include
struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
EXPORT_SYMBOL(node_data);
@@ -168,22 +169,83 @@ static void __init pcpu_fc_free(void *ptr, size_t size)
memblock_free_early(__pa(ptr), size);
}
+#ifdef CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK
+static void __init pcpu_populate_pte(unsigned long addr)
+{
+ pgd_t *pgd = pgd_offset_k(addr);
+ p4d_t *p4d;
+ pud_t *pud;
+ pmd_t *pmd;
+
+ p4d = p4d_offset(pgd, addr);
+ if (p4d_none(*p4d)) {
+ pud_t *new;
+
+ new = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+ if (!new)
+ goto err_alloc;
+ p4d_populate(_mm, p4d, new);
+ }
+
+ pud = pud_offset(p4d, addr);
+ if (pud_none(*pud)) {
+ pmd_t *new;
+
+ new = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+ if (!new)
+ goto err_alloc;
+ pud_populate(_mm, pud, new);
+ }
+
+ pmd = pmd_offset(pud, addr);
+ if (!pmd_present(*pmd)) {
+ pte_t *new;
+
+ new = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+ if (!new)
+ goto err_alloc;
+ pmd_populate_kernel(_mm, pmd, new);
+ }
+
+ return;
+
+err_alloc:
+ panic("%s: Failed to allocate %lu bytes align=%lx from=%lx\n",
+ __func__, PAGE_SIZE, PAGE_SIZE, PAGE_SIZE);
+}
+#endif
+
void __init setup_per_cpu_areas(void)
{
unsigned long delta;
unsigned int cpu;
- int rc;
+ int rc = -EINVAL;
+
+ if (pcpu_chosen_fc != PCPU_FC_PAGE) {
+ /*
+* Always reserve area for module percpu variables. That's
+* what the legacy allocator did.
+*/
+ rc = pcpu_embed_first_chunk(PERCPU_MODULE_RESERVE,
+ PERCPU_DYNAMIC_RESERVE, PAGE_SIZE,
+ pcpu_cpu_distance,
+ pcpu_fc_alloc, pcpu_fc_free);
+#ifdef CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK
+ if (rc < 0)
+ pr_warn("PERCPU: %s allocator failed (%d), falling back
to page size\n",
+ pcpu_fc_names[pcpu_chosen_fc], rc);
+#endif
+ }
- /*
-* Always reserve area for module percpu variables. That's
-* what the legacy allocator did.
-*/
- rc = pcpu_embed_first_chunk(PERCPU_MODULE_RESERVE,
- PERCPU_DYNAMIC_RESERVE, PAGE_SIZE,
- pcpu_cpu_distance,
- pcpu_fc_alloc, pcpu_fc_free);
+#ifdef CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK
+ if (rc < 0)
+ rc = pcpu_page_first_chunk(PERCPU_MODULE_RESERVE,
+ pcpu_fc_alloc,
+ pcpu_fc_free,
+ pcpu_populate_pte);
+#endif
if (rc < 0)
- panic("Failed to initialize pe
[linux-yocto] [PATCH 10/14] vmalloc: choose a better start address in vm_area_register_early()
From: Kefeng Wang
commit 0eb68437a7f9dfef9c218873310c66c714f2fa99 upstream.
Percpu embedded first chunk allocator is the firstly option, but it
could fail on ARM64, eg,
percpu: max_distance=0x5fcfdc64 too large for vmalloc space 0x781fefff
percpu: max_distance=0x6054 too large for vmalloc space 0x7dffb7ff
percpu: max_distance=0x5fff9adb too large for vmalloc space 0x5dffb7ff
then we could get to
WARNING: CPU: 15 PID: 461 at vmalloc.c:3087 pcpu_get_vm_areas+0x488/0x838
and the system cannot boot successfully.
Let's implement page mapping percpu first chunk allocator as a fallback
to the embedding allocator to increase the robustness of the system.
Also fix a crash when both NEED_PER_CPU_PAGE_FIRST_CHUNK and
KASAN_VMALLOC enabled.
Tested on ARM64 qemu with cmdline "percpu_alloc=page".
This patch (of 3):
There are some fixed locations in the vmalloc area be reserved in
ARM(see iotable_init()) and ARM64(see map_kernel()), but for
pcpu_page_first_chunk(), it calls vm_area_register_early() and choose
VMALLOC_START as the start address of vmap area which could be
conflicted with above address, then could trigger a BUG_ON in
vm_area_add_early().
Let's choose a suit start address by traversing the vmlist.
Link:
https://lkml.kernel.org/r/20210910053354.26721-1-wangkefeng.w...@huawei.com
Link:
https://lkml.kernel.org/r/20210910053354.26721-2-wangkefeng.w...@huawei.com
Signed-off-by: Kefeng Wang
Reviewed-by: Catalin Marinas
Cc: Will Deacon
Cc: Andrey Ryabinin
Cc: Andrey Konovalov
Cc: Dmitry Vyukov
Cc: Marco Elver
Cc: Greg Kroah-Hartman
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Paul Gortmaker
---
mm/vmalloc.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 8375eecc55de..1421b8421834 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2272,15 +2272,21 @@ void __init vm_area_add_early(struct vm_struct *vm)
*/
void __init vm_area_register_early(struct vm_struct *vm, size_t align)
{
- static size_t vm_init_off __initdata;
- unsigned long addr;
+ unsigned long addr = ALIGN(VMALLOC_START, align);
+ struct vm_struct *cur, **p;
- addr = ALIGN(VMALLOC_START + vm_init_off, align);
- vm_init_off = PFN_ALIGN(addr + vm->size) - VMALLOC_START;
+ BUG_ON(vmap_initialized);
- vm->addr = (void *)addr;
+ for (p = (cur = *p) != NULL; p = >next) {
+ if ((unsigned long)cur->addr - addr >= vm->size)
+ break;
+ addr = ALIGN((unsigned long)cur->addr + cur->size, align);
+ }
- vm_area_add_early(vm);
+ BUG_ON(addr > VMALLOC_END - vm->size);
+ vm->addr = (void *)addr;
+ vm->next = *p;
+ *p = vm;
}
static void vmap_init_free_space(void)
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11154):
https://lists.yoctoproject.org/g/linux-yocto/message/11154
Mute This Topic: https://lists.yoctoproject.org/mt/90342152/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 06/14] workqueue, kasan: avoid alloc_pages() when recording stack
From: Marco Elver commit f70da745be4d4c367568b8345f50db1ae04efcb2 upstream. Shuah Khan reported: | When CONFIG_PROVE_RAW_LOCK_NESTING=y and CONFIG_KASAN are enabled, | kasan_record_aux_stack() runs into "BUG: Invalid wait context" when | it tries to allocate memory attempting to acquire spinlock in page | allocation code while holding workqueue pool raw_spinlock. | | There are several instances of this problem when block layer tries | to __queue_work(). Call trace from one of these instances is below: | | kblockd_mod_delayed_work_on() | mod_delayed_work_on() | __queue_delayed_work() | __queue_work() (rcu_read_lock, raw_spin_lock pool->lock held) | insert_work() | kasan_record_aux_stack() | kasan_save_stack() | stack_depot_save() | alloc_pages() | __alloc_pages() | get_page_from_freelist() | rm_queue() | rm_queue_pcplist() | local_lock_irqsave(, flags); | [ BUG: Invalid wait context triggered ] The default kasan_record_aux_stack() calls stack_depot_save() with GFP_NOWAIT, which in turn can then call alloc_pages(GFP_NOWAIT, ...). In general, however, it is not even possible to use either GFP_ATOMIC nor GFP_NOWAIT in certain non-preemptive contexts, including raw_spin_locks (see gfp.h and commmit ab00db216c9c7). Fix it by instructing stackdepot to not expand stack storage via alloc_pages() in case it runs out by using kasan_record_aux_stack_noalloc(). While there is an increased risk of failing to insert the stack trace, this is typically unlikely, especially if the same insertion had already succeeded previously (stack depot hit). For frequent calls from the same location, it therefore becomes extremely unlikely that kasan_record_aux_stack_noalloc() fails. Link: https://lkml.kernel.org/r/20210902200134.25603-1-sk...@linuxfoundation.org Link: https://lkml.kernel.org/r/20210913112609.2651084-7-el...@google.com Signed-off-by: Marco Elver Reported-by: Shuah Khan Tested-by: Shuah Khan Acked-by: Sebastian Andrzej Siewior Acked-by: Tejun Heo Reviewed-by: Andrey Konovalov Cc: Alexander Potapenko Cc: Andrey Ryabinin Cc: Dmitry Vyukov Cc: "Gustavo A. R. Silva" Cc: Lai Jiangshan Cc: Taras Madan Cc: Thomas Gleixner Cc: Vijayanand Jitta Cc: Vinayak Menon Cc: Walter Wu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker --- kernel/workqueue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 3f4d27668576..7ab66cd5d07f 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -1359,7 +1359,7 @@ static void insert_work(struct pool_workqueue *pwq, struct work_struct *work, struct worker_pool *pool = pwq->pool; /* record the work call stack in order to print it in KASAN reports */ - kasan_record_aux_stack(work); + kasan_record_aux_stack_noalloc(work); /* we own @work, set data and link */ set_work_pwq(work, pwq, extra_flags); -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11151): https://lists.yoctoproject.org/g/linux-yocto/message/11151 Mute This Topic: https://lists.yoctoproject.org/mt/90342148/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 09/14] kasan: test: bypass __alloc_size checks
From: Kees Cook
commit d73dad4eb5ad8c31ac9cf358eb5a55825bafe706 upstream.
Intentional overflows, as performed by the KASAN tests, are detected at
compile time[1] (instead of only at run-time) with the addition of
__alloc_size. Fix this by forcing the compiler into not being able to
trust the size used following the kmalloc()s.
[1]
https://lore.kernel.org/lkml/20211005184717.65c6d8eb39350395e387b...@linux-foundation.org
Link: https://lkml.kernel.org/r/20211006181544.1670992-1-keesc...@chromium.org
Signed-off-by: Kees Cook
Cc: Andrey Ryabinin
Cc: Alexander Potapenko
Cc: Andrey Konovalov
Cc: Dmitry Vyukov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Paul Gortmaker
---
lib/test_kasan.c| 8 +++-
lib/test_kasan_module.c | 2 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index aa8e42250219..5475fe396ff7 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -440,6 +440,7 @@ static void kmalloc_oob_memset_2(struct kunit *test)
ptr = kmalloc(size, GFP_KERNEL);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);
+ OPTIMIZER_HIDE_VAR(size);
KUNIT_EXPECT_KASAN_FAIL(test, memset(ptr + size - 1, 0, 2));
kfree(ptr);
}
@@ -452,6 +453,7 @@ static void kmalloc_oob_memset_4(struct kunit *test)
ptr = kmalloc(size, GFP_KERNEL);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);
+ OPTIMIZER_HIDE_VAR(size);
KUNIT_EXPECT_KASAN_FAIL(test, memset(ptr + size - 3, 0, 4));
kfree(ptr);
}
@@ -464,6 +466,7 @@ static void kmalloc_oob_memset_8(struct kunit *test)
ptr = kmalloc(size, GFP_KERNEL);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);
+ OPTIMIZER_HIDE_VAR(size);
KUNIT_EXPECT_KASAN_FAIL(test, memset(ptr + size - 7, 0, 8));
kfree(ptr);
}
@@ -476,6 +479,7 @@ static void kmalloc_oob_memset_16(struct kunit *test)
ptr = kmalloc(size, GFP_KERNEL);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);
+ OPTIMIZER_HIDE_VAR(size);
KUNIT_EXPECT_KASAN_FAIL(test, memset(ptr + size - 15, 0, 16));
kfree(ptr);
}
@@ -488,6 +492,7 @@ static void kmalloc_oob_in_memset(struct kunit *test)
ptr = kmalloc(size, GFP_KERNEL);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);
+ OPTIMIZER_HIDE_VAR(size);
KUNIT_EXPECT_KASAN_FAIL(test,
memset(ptr, 0, size + KASAN_GRANULE_SIZE));
kfree(ptr);
@@ -497,7 +502,7 @@ static void kmalloc_memmove_negative_size(struct kunit
*test)
{
char *ptr;
size_t size = 64;
- volatile size_t invalid_size = -2;
+ size_t invalid_size = -2;
/*
* Hardware tag-based mode doesn't check memmove for negative size.
@@ -510,6 +515,7 @@ static void kmalloc_memmove_negative_size(struct kunit
*test)
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);
memset((char *)ptr, 0, 64);
+ OPTIMIZER_HIDE_VAR(invalid_size);
KUNIT_EXPECT_KASAN_FAIL(test,
memmove((char *)ptr, (char *)ptr + 4, invalid_size));
kfree(ptr);
diff --git a/lib/test_kasan_module.c b/lib/test_kasan_module.c
index 7ebf433edef3..b112cbc835e9 100644
--- a/lib/test_kasan_module.c
+++ b/lib/test_kasan_module.c
@@ -35,6 +35,8 @@ static noinline void __init copy_user_test(void)
return;
}
+ OPTIMIZER_HIDE_VAR(size);
+
pr_info("out-of-bounds in copy_from_user()\n");
unused = copy_from_user(kmem, usermem, size + 1);
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11153):
https://lists.yoctoproject.org/g/linux-yocto/message/11153
Mute This Topic: https://lists.yoctoproject.org/mt/90342151/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 04/14] kasan: common: provide can_alloc in kasan_save_stack()
From: Marco Elver
commit 7594b34774294ff23a32506b8b874d6425a1481a upstream.
Add another argument, can_alloc, to kasan_save_stack() which is passed
as-is to __stack_depot_save().
No functional change intended.
Link: https://lkml.kernel.org/r/20210913112609.2651084-5-el...@google.com
Signed-off-by: Marco Elver
Tested-by: Shuah Khan
Acked-by: Sebastian Andrzej Siewior
Reviewed-by: Andrey Konovalov
Cc: Alexander Potapenko
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Cc: "Gustavo A. R. Silva"
Cc: Lai Jiangshan
Cc: Taras Madan
Cc: Tejun Heo
Cc: Thomas Gleixner
Cc: Vijayanand Jitta
Cc: Vinayak Menon
Cc: Walter Wu
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Paul Gortmaker
---
mm/kasan/common.c | 6 +++---
mm/kasan/generic.c | 2 +-
mm/kasan/kasan.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 2baf121fb8c5..3e0999892c36 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -30,20 +30,20 @@
#include "kasan.h"
#include "../slab.h"
-depot_stack_handle_t kasan_save_stack(gfp_t flags)
+depot_stack_handle_t kasan_save_stack(gfp_t flags, bool can_alloc)
{
unsigned long entries[KASAN_STACK_DEPTH];
unsigned int nr_entries;
nr_entries = stack_trace_save(entries, ARRAY_SIZE(entries), 0);
nr_entries = filter_irq_stacks(entries, nr_entries);
- return stack_depot_save(entries, nr_entries, flags);
+ return __stack_depot_save(entries, nr_entries, flags, can_alloc);
}
void kasan_set_track(struct kasan_track *track, gfp_t flags)
{
track->pid = current->pid;
- track->stack = kasan_save_stack(flags);
+ track->stack = kasan_save_stack(flags, true);
}
#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
index c3f5ba7a294a..2a8e59e6326d 100644
--- a/mm/kasan/generic.c
+++ b/mm/kasan/generic.c
@@ -345,7 +345,7 @@ void kasan_record_aux_stack(void *addr)
return;
alloc_meta->aux_stack[1] = alloc_meta->aux_stack[0];
- alloc_meta->aux_stack[0] = kasan_save_stack(GFP_NOWAIT);
+ alloc_meta->aux_stack[0] = kasan_save_stack(GFP_NOWAIT, true);
}
void kasan_set_free_info(struct kmem_cache *cache,
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index 8bf568a80eb8..fa6b48d08513 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -251,7 +251,7 @@ void kasan_report_invalid_free(void *object, unsigned long
ip);
struct page *kasan_addr_to_page(const void *addr);
-depot_stack_handle_t kasan_save_stack(gfp_t flags);
+depot_stack_handle_t kasan_save_stack(gfp_t flags, bool can_alloc);
void kasan_set_track(struct kasan_track *track, gfp_t flags);
void kasan_set_free_info(struct kmem_cache *cache, void *object, u8 tag);
struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11149):
https://lists.yoctoproject.org/g/linux-yocto/message/11149
Mute This Topic: https://lists.yoctoproject.org/mt/90342145/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 05/14] kasan: generic: introduce kasan_record_aux_stack_noalloc()
From: Marco Elver
commit 7cb3007ce2da27ec02a1a3211941e7fe6875b642 upstream.
Introduce a variant of kasan_record_aux_stack() that does not do any
memory allocation through stackdepot. This will permit using it in
contexts that cannot allocate any memory.
Link: https://lkml.kernel.org/r/20210913112609.2651084-6-el...@google.com
Signed-off-by: Marco Elver
Tested-by: Shuah Khan
Acked-by: Sebastian Andrzej Siewior
Reviewed-by: Andrey Konovalov
Cc: Alexander Potapenko
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Cc: "Gustavo A. R. Silva"
Cc: Lai Jiangshan
Cc: Taras Madan
Cc: Tejun Heo
Cc: Thomas Gleixner
Cc: Vijayanand Jitta
Cc: Vinayak Menon
Cc: Walter Wu
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Paul Gortmaker
---
include/linux/kasan.h | 2 ++
mm/kasan/generic.c| 14 --
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index f407e937241a..a63b2a5dd762 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -370,12 +370,14 @@ static inline void kasan_unpoison_task_stack(struct
task_struct *task) {}
void kasan_cache_shrink(struct kmem_cache *cache);
void kasan_cache_shutdown(struct kmem_cache *cache);
void kasan_record_aux_stack(void *ptr);
+void kasan_record_aux_stack_noalloc(void *ptr);
#else /* CONFIG_KASAN_GENERIC */
static inline void kasan_cache_shrink(struct kmem_cache *cache) {}
static inline void kasan_cache_shutdown(struct kmem_cache *cache) {}
static inline void kasan_record_aux_stack(void *ptr) {}
+static inline void kasan_record_aux_stack_noalloc(void *ptr) {}
#endif /* CONFIG_KASAN_GENERIC */
diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
index 2a8e59e6326d..84a038b07c6f 100644
--- a/mm/kasan/generic.c
+++ b/mm/kasan/generic.c
@@ -328,7 +328,7 @@ DEFINE_ASAN_SET_SHADOW(f3);
DEFINE_ASAN_SET_SHADOW(f5);
DEFINE_ASAN_SET_SHADOW(f8);
-void kasan_record_aux_stack(void *addr)
+static void __kasan_record_aux_stack(void *addr, bool can_alloc)
{
struct page *page = kasan_addr_to_page(addr);
struct kmem_cache *cache;
@@ -345,7 +345,17 @@ void kasan_record_aux_stack(void *addr)
return;
alloc_meta->aux_stack[1] = alloc_meta->aux_stack[0];
- alloc_meta->aux_stack[0] = kasan_save_stack(GFP_NOWAIT, true);
+ alloc_meta->aux_stack[0] = kasan_save_stack(GFP_NOWAIT, can_alloc);
+}
+
+void kasan_record_aux_stack(void *addr)
+{
+ return __kasan_record_aux_stack(addr, true);
+}
+
+void kasan_record_aux_stack_noalloc(void *addr)
+{
+ return __kasan_record_aux_stack(addr, false);
}
void kasan_set_free_info(struct kmem_cache *cache,
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11150):
https://lists.yoctoproject.org/g/linux-yocto/message/11150
Mute This Topic: https://lists.yoctoproject.org/mt/90342146/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 07/14] kasan: fix tag for large allocations when using CONFIG_SLAB
From: "Matthew Wilcox (Oracle)"
commit 820a1e6e87ccaa6c0c77ac7d79d05beec3f8cb88 upstream.
If an object is allocated on a tail page of a multi-page slab, kasan
will get the wrong tag because page->s_mem is NULL for tail pages. I'm
not quite sure what the user-visible effect of this might be.
Link: https://lkml.kernel.org/r/20211001024105.3217339-1-wi...@infradead.org
Fixes: 7f94ffbc4c6a ("kasan: add hooks implementation for tag-based mode")
Signed-off-by: Matthew Wilcox (Oracle)
Acked-by: Marco Elver
Reviewed-by: Andrey Konovalov
Cc: Andrey Ryabinin
Cc: Alexander Potapenko
Cc: Dmitry Vyukov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Paul Gortmaker
---
mm/kasan/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 3e0999892c36..8428da2aaf17 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -298,7 +298,7 @@ static inline u8 assign_tag(struct kmem_cache *cache,
/* For caches that either have a constructor or SLAB_TYPESAFE_BY_RCU: */
#ifdef CONFIG_SLAB
/* For SLAB assign tags based on the object index in the freelist. */
- return (u8)obj_to_index(cache, virt_to_page(object), (void *)object);
+ return (u8)obj_to_index(cache, virt_to_head_page(object), (void
*)object);
#else
/*
* For SLUB assign a random tag during slab creation, otherwise reuse
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11152):
https://lists.yoctoproject.org/g/linux-yocto/message/11152
Mute This Topic: https://lists.yoctoproject.org/mt/90342150/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 02/14] lib/stackdepot: remove unused function argument
From: Marco Elver
commit 7f2b8818ea1361e3482d1e3a3c9a824789177d3a upstream.
alloc_flags in depot_alloc_stack() is no longer used; remove it.
Link: https://lkml.kernel.org/r/20210913112609.2651084-3-el...@google.com
Signed-off-by: Marco Elver
Tested-by: Shuah Khan
Acked-by: Sebastian Andrzej Siewior
Reviewed-by: Andrey Konovalov
Cc: Alexander Potapenko
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Cc: "Gustavo A. R. Silva"
Cc: Lai Jiangshan
Cc: Taras Madan
Cc: Tejun Heo
Cc: Thomas Gleixner
Cc: Vijayanand Jitta
Cc: Vinayak Menon
Cc: Walter Wu
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Paul Gortmaker
---
lib/stackdepot.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/lib/stackdepot.c b/lib/stackdepot.c
index 0a2e417f83cb..c80a9f734253 100644
--- a/lib/stackdepot.c
+++ b/lib/stackdepot.c
@@ -102,8 +102,8 @@ static bool init_stack_slab(void **prealloc)
}
/* Allocation of a new stack in raw storage */
-static struct stack_record *depot_alloc_stack(unsigned long *entries, int size,
- u32 hash, void **prealloc, gfp_t alloc_flags)
+static struct stack_record *
+depot_alloc_stack(unsigned long *entries, int size, u32 hash, void **prealloc)
{
struct stack_record *stack;
size_t required_size = struct_size(stack, entries, size);
@@ -309,9 +309,8 @@ depot_stack_handle_t stack_depot_save(unsigned long
*entries,
found = find_stack(*bucket, entries, nr_entries, hash);
if (!found) {
- struct stack_record *new =
- depot_alloc_stack(entries, nr_entries,
- hash, , alloc_flags);
+ struct stack_record *new = depot_alloc_stack(entries,
nr_entries, hash, );
+
if (new) {
new->next = *bucket;
/*
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11148):
https://lists.yoctoproject.org/g/linux-yocto/message/11148
Mute This Topic: https://lists.yoctoproject.org/mt/90342144/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 03/14] lib/stackdepot: introduce __stack_depot_save()
From: Marco Elver
commit 11ac25c62cd2f3bb8da9e1df2e71afdebe76f093 upstream.
Add __stack_depot_save(), which provides more fine-grained control over
stackdepot's memory allocation behaviour, in case stackdepot runs out of
"stack slabs".
Normally stackdepot uses alloc_pages() in case it runs out of space;
passing can_alloc==false to __stack_depot_save() prohibits this, at the
cost of more likely failure to record a stack trace.
Link: https://lkml.kernel.org/r/20210913112609.2651084-4-el...@google.com
Signed-off-by: Marco Elver
Tested-by: Shuah Khan
Acked-by: Sebastian Andrzej Siewior
Reviewed-by: Andrey Konovalov
Cc: Alexander Potapenko
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Cc: "Gustavo A. R. Silva"
Cc: Lai Jiangshan
Cc: Taras Madan
Cc: Tejun Heo
Cc: Thomas Gleixner
Cc: Vijayanand Jitta
Cc: Vinayak Menon
Cc: Walter Wu
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Paul Gortmaker
---
include/linux/stackdepot.h | 4
lib/stackdepot.c | 43 --
2 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/include/linux/stackdepot.h b/include/linux/stackdepot.h
index 97b36dc53301..b2f7e7c6ba54 100644
--- a/include/linux/stackdepot.h
+++ b/include/linux/stackdepot.h
@@ -15,6 +15,10 @@
typedef u32 depot_stack_handle_t;
+depot_stack_handle_t __stack_depot_save(unsigned long *entries,
+ unsigned int nr_entries,
+ gfp_t gfp_flags, bool can_alloc);
+
depot_stack_handle_t stack_depot_save(unsigned long *entries,
unsigned int nr_entries, gfp_t gfp_flags);
diff --git a/lib/stackdepot.c b/lib/stackdepot.c
index c80a9f734253..bda58597e375 100644
--- a/lib/stackdepot.c
+++ b/lib/stackdepot.c
@@ -248,17 +248,28 @@ unsigned int stack_depot_fetch(depot_stack_handle_t
handle,
EXPORT_SYMBOL_GPL(stack_depot_fetch);
/**
- * stack_depot_save - Save a stack trace from an array
+ * __stack_depot_save - Save a stack trace from an array
*
* @entries: Pointer to storage array
* @nr_entries:Size of the storage array
* @alloc_flags: Allocation gfp flags
+ * @can_alloc: Allocate stack slabs (increased chance of failure if
false)
+ *
+ * Saves a stack trace from @entries array of size @nr_entries. If @can_alloc
is
+ * %true, is allowed to replenish the stack slab pool in case no space is left
+ * (allocates using GFP flags of @alloc_flags). If @can_alloc is %false, avoids
+ * any allocations and will fail if no space is left to store the stack trace.
+ *
+ * Context: Any context, but setting @can_alloc to %false is required if
+ * alloc_pages() cannot be used from the current context. Currently
+ * this is the case from contexts where neither %GFP_ATOMIC nor
+ * %GFP_NOWAIT can be used (NMI, raw_spin_lock).
*
- * Return: The handle of the stack struct stored in depot
+ * Return: The handle of the stack struct stored in depot, 0 on failure.
*/
-depot_stack_handle_t stack_depot_save(unsigned long *entries,
- unsigned int nr_entries,
- gfp_t alloc_flags)
+depot_stack_handle_t __stack_depot_save(unsigned long *entries,
+ unsigned int nr_entries,
+ gfp_t alloc_flags, bool can_alloc)
{
struct stack_record *found = NULL, **bucket;
depot_stack_handle_t retval = 0;
@@ -291,7 +302,7 @@ depot_stack_handle_t stack_depot_save(unsigned long
*entries,
* The smp_load_acquire() here pairs with smp_store_release() to
* |next_slab_inited| in depot_alloc_stack() and init_stack_slab().
*/
- if (unlikely(!smp_load_acquire(_slab_inited))) {
+ if (unlikely(can_alloc && !smp_load_acquire(_slab_inited))) {
/*
* Zero out zone modifiers, as we don't have specific zone
* requirements. Keep the flags related to allocation in atomic
@@ -339,6 +350,26 @@ depot_stack_handle_t stack_depot_save(unsigned long
*entries,
fast_exit:
return retval;
}
+EXPORT_SYMBOL_GPL(__stack_depot_save);
+
+/**
+ * stack_depot_save - Save a stack trace from an array
+ *
+ * @entries: Pointer to storage array
+ * @nr_entries:Size of the storage array
+ * @alloc_flags: Allocation gfp flags
+ *
+ * Context: Contexts where allocations via alloc_pages() are allowed.
+ * See __stack_depot_save() for more details.
+ *
+ * Return: The handle of the stack struct stored in depot, 0 on failure.
+ */
+depot_stack_handle_t stack_depot_save(unsigned long *entries,
+ unsigned int nr_entries,
+ gfp_t alloc_flags)
+{
+ return __stack_depot_save(entries, nr_entries, alloc_flags, true);
+}
EXPORT
[linux-yocto] [PATCH v5.15 00/14] kasan: fix "BUG: sleeping function called from invalid context"
This "seen on -rt" issue was originally reported on v5.15-rc7, as per: https://lore.kernel.org/rcu/20211101103158.3725704-1-jun.m...@windriver.com/T/#u and to save you reading the whole long thread, it finally got mainline as commit 300c0c5e7218 in v5.17. At a glance, the fix looks pretty simple and applies to v5.15 so one wonders why it was only backported to v5.16-stable. Well, that becomes obvious as soon as one tries to compile it. The noalloc variant - i.e. kasan_record_aux_stack_noalloc() only appeared in v5.16, as part of a larger KASAN series fed in via the akpm patch-bomb in the merge window prior to v5.16-rc1. Fortunately once one realizes that and then re-divorces the kasan content from the monolithic akpm series, along with the associated dependencies and related "Fixes:" everything simply applies hands-free with no fuss on the older v5.15 and also builds. While the issue was seen on -rt, I don't see any evidence that it couldn't happen on non-rt either. And since these are all mainline commits, I'd suggest we put them on v5.15/standard/base and merge outwards. Tested KASAN=y + KASAN_VMALLOC=y as the latter is called out in one of the commits as being fixed. Booted on non-rt defconfig for x86_64 and -rt on our (Yocto's) qemu-arm64 base. Note that our default 256MB isn't enough for KASAN_VMALLOC on qemu ARM64, so I bumped it to 2G for my testing. Paul. --- Jun Miao (1): rcu: Avoid alloc_pages() when recording stack Kees Cook (2): kasan: test: bypass __alloc_size checks kasan: test: silence intentional read overflow warnings Kefeng Wang (3): vmalloc: choose a better start address in vm_area_register_early() arm64: support page mapping percpu first chunk allocator kasan: arm64: fix pcpu_page_first_chunk crash with KASAN_VMALLOC Marco Elver (6): lib/stackdepot: include gfp.h lib/stackdepot: remove unused function argument lib/stackdepot: introduce __stack_depot_save() kasan: common: provide can_alloc in kasan_save_stack() kasan: generic: introduce kasan_record_aux_stack_noalloc() workqueue, kasan: avoid alloc_pages() when recording stack Matthew Wilcox (Oracle) (1): kasan: fix tag for large allocations when using CONFIG_SLAB Peter Collingbourne (1): kasan: test: add memcpy test that avoids out-of-bounds write arch/arm64/Kconfig | 4 ++ arch/arm64/mm/kasan_init.c | 16 drivers/base/arch_numa.c | 82 +- include/linux/kasan.h | 8 include/linux/stackdepot.h | 6 +++ kernel/rcu/tree.c | 4 +- kernel/workqueue.c | 2 +- lib/stackdepot.c | 52 +++- lib/test_kasan.c | 28 - lib/test_kasan_module.c| 2 + mm/kasan/common.c | 8 ++-- mm/kasan/generic.c | 14 ++- mm/kasan/kasan.h | 2 +- mm/kasan/shadow.c | 5 +++ mm/vmalloc.c | 19 ++--- 15 files changed, 213 insertions(+), 39 deletions(-) -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11146): https://lists.yoctoproject.org/g/linux-yocto/message/11146 Mute This Topic: https://lists.yoctoproject.org/mt/90342141/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 01/14] lib/stackdepot: include gfp.h
From: Marco Elver commit 7857ccdf94e94f1dd56496b90084fdcaa5e655a4 upstream. Patch series "stackdepot, kasan, workqueue: Avoid expanding stackdepot slabs when holding raw_spin_lock", v2. Shuah Khan reported [1]: | When CONFIG_PROVE_RAW_LOCK_NESTING=y and CONFIG_KASAN are enabled, | kasan_record_aux_stack() runs into "BUG: Invalid wait context" when | it tries to allocate memory attempting to acquire spinlock in page | allocation code while holding workqueue pool raw_spinlock. | | There are several instances of this problem when block layer tries | to __queue_work(). Call trace from one of these instances is below: | | kblockd_mod_delayed_work_on() | mod_delayed_work_on() | __queue_delayed_work() | __queue_work() (rcu_read_lock, raw_spin_lock pool->lock held) | insert_work() | kasan_record_aux_stack() | kasan_save_stack() | stack_depot_save() | alloc_pages() | __alloc_pages() | get_page_from_freelist() | rm_queue() | rm_queue_pcplist() | local_lock_irqsave(, flags); | [ BUG: Invalid wait context triggered ] PROVE_RAW_LOCK_NESTING is pointing out that (on RT kernels) the locking rules are being violated. More generally, memory is being allocated from a non-preemptive context (raw_spin_lock'd c-s) where it is not allowed. To properly fix this, we must prevent stackdepot from replenishing its "stack slab" pool if memory allocations cannot be done in the current context: it's a bug to use either GFP_ATOMIC nor GFP_NOWAIT in certain non-preemptive contexts, including raw_spin_locks (see gfp.h and commit ab00db216c9c7). The only downside is that saving a stack trace may fail if: stackdepot runs out of space AND the same stack trace has not been recorded before. I expect this to be unlikely, and a simple experiment (boot the kernel) didn't result in any failure to record stack trace from insert_work(). The series includes a few minor fixes to stackdepot that I noticed in preparing the series. It then introduces __stack_depot_save(), which exposes the option to force stackdepot to not allocate any memory. Finally, KASAN is changed to use the new stackdepot interface and provide kasan_record_aux_stack_noalloc(), which is then used by workqueue code. [1] https://lkml.kernel.org/r/20210902200134.25603-1-sk...@linuxfoundation.org This patch (of 6): refers to gfp_t, but doesn't include gfp.h. Fix it by including . Link: https://lkml.kernel.org/r/20210913112609.2651084-1-el...@google.com Link: https://lkml.kernel.org/r/20210913112609.2651084-2-el...@google.com Signed-off-by: Marco Elver Tested-by: Shuah Khan Acked-by: Sebastian Andrzej Siewior Reviewed-by: Andrey Konovalov Cc: Tejun Heo Cc: Lai Jiangshan Cc: Walter Wu Cc: Thomas Gleixner Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: Vijayanand Jitta Cc: Vinayak Menon Cc: "Gustavo A. R. Silva" Cc: Taras Madan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker --- include/linux/stackdepot.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/stackdepot.h b/include/linux/stackdepot.h index 6bb4bc1a5f54..97b36dc53301 100644 --- a/include/linux/stackdepot.h +++ b/include/linux/stackdepot.h @@ -11,6 +11,8 @@ #ifndef _LINUX_STACKDEPOT_H #define _LINUX_STACKDEPOT_H +#include + typedef u32 depot_stack_handle_t; depot_stack_handle_t stack_depot_save(unsigned long *entries, -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11145): https://lists.yoctoproject.org/g/linux-yocto/message/11145 Mute This Topic: https://lists.yoctoproject.org/mt/90342140/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][PATCH] ipv6: Fix stats accounting in ip6_pkt_drop
[Re: [linux-yocto][v5.10/standard/base][PATCH] ipv6: Fix stats accounting in
ip6_pkt_drop] On 06/04/2022 (Wed 21:25) He Zhe wrote:
>
>
> On 4/6/22 20:07, Paul Gortmaker wrote:
> > [[linux-yocto][v5.10/standard/base][PATCH] ipv6: Fix stats accounting in
> > ip6_pkt_drop] On 06/04/2022 (Wed 15:54) He Zhe wrote:
> >
> >> VRF devices are the loopbacks for VRFs, and a loopback can not be
> >> assigned to a VRF. Accordingly, the condition in ip6_pkt_drop should
> >> be '||' not '&&'.
> >>
> >> Fixes: 1d3fd8a10bed ("vrf: Use orig netdev to count Ip6InNoRoutes and a
> >> fresh route lookup when sending dest unreach")
> >> Reported-by: Pudak, Filip
> >> Reported-by: Xiao, Jiguang
> >> Signed-off-by: David Ahern
> >> Link: https://lore.kernel.org/r/20220404150908.2937-1-dsah...@kernel.org
> >> Signed-off-by: Paolo Abeni
> >>
> >> Link:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=1158f79f82d4
> > As this is in "net" (and not "net-next") it will go to mainline in a
> > few days[1], and the LF stable team will grab it via the Fixes tag and
> > backport it automatically (since it is a trivial change).
> >
> > What I'm getting at here, is that expiditing this (and any other fix that
> > matches this same criteria) is a make-work project for yourself and for
> > Bruce. Unless it is has a priority (like a 0-day CVE) then there is no
> > point trying to accelerate it vs. just waiting the few extra days for
> > the normal "hands-free" process feed to take place on its own.
> >
> > And then it will have [comit abcd upstream] on it as well, indicating
> > clearly that it was a mainline commit and not something that maybe
> > died on a mailing list thread and went no further.
>
> We have customer experiencing network statistics error due to this bug and it
> may also be the case for other Yocto users. Fixing this earlier may be more
> important for them vs developers waiting and feeling hands-free. Anyway, this
> patch is here up to maintainer's choice and convenience.
Sure - there is nothing wrong with that - all I'd suggest is that in the
future you pass that context along - either in a 0/1 preamble, or
alternatively you can add text below the dashes and above the diff as is
the common convention for transient comments -- which git throws away at
the "git am" stage of processing by the maintainer.
Nothing fancy - just pretty much what you said above
"I suspect this will make it through stable path but we are
seeing errors with this now and I expect others will too, so
lets expidite this fix now."
Thanks,
Paul.
--
>
> Thanks,
> Zhe
>
> >
> > Thanks,
> > Paul.
> >
> > [1]
> > https://docs.kernel.org/process/maintainer-netdev.html#how-do-the-changes-posted-to-netdev-make-their-way-into-linux
> > --
> >
> >> Signed-off-by: He Zhe
> >> ---
> >> net/ipv6/route.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> >> index 352e645c546e..776b1b58c5dc 100644
> >> --- a/net/ipv6/route.c
> >> +++ b/net/ipv6/route.c
> >> @@ -4398,7 +4398,7 @@ static int ip6_pkt_drop(struct sk_buff *skb, u8
> >> code, int ipstats_mib_noroutes)
> >>struct inet6_dev *idev;
> >>int type;
> >>
> >> - if (netif_is_l3_master(skb->dev) &&
> >> + if (netif_is_l3_master(skb->dev) ||
> >>dst->dev == net->loopback_dev)
> >>idev = __in6_dev_get_safely(dev_get_by_index_rcu(net,
> >> IP6CB(skb)->iif));
> >>else
> >> --
> >> 2.17.1
> >>
> >>
> >>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11128):
https://lists.yoctoproject.org/g/linux-yocto/message/11128
Mute This Topic: https://lists.yoctoproject.org/mt/90285003/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/standard/ti-sdk-5.10/ti-j72xx][PATCH] net: update the AF_MAX value to the latest
[[linux-yocto][linux-yocto v5.15/standard/ti-sdk-5.10/ti-j72xx][PATCH] net:
update the AF_MAX value to the latest] On 06/04/2022 (Wed 12:52) Xulin Sun
wrote:
> commit c6f441a33dd (net/rpmsg: add support for new rpmsg sockets) adds
> a new socket address AF_RPMSG, the AF_MAX should be incremented accordingly.
>
> To avoid below call trace:
> net/core/sock.c:233:21: error: excess elements in array initializer [-Werror]
> | 233 | _sock_locks("sk_lock-")
This is not a call trace. A call trace is what comes from a runtime
BUG() or WARN() etc etc. This is a compile error.
Let us look at c6f441a33dd - which it would be helpful in the future if
you indicate when a commit ID is yocto specific; otherwise the
convention is to assume a "reference free" ID is a mainline ID/SHA.
-
commit c6f441a33dde0e4fad634be1aa4fc145e893880c
Author: Suman Anna
Date: Tue Apr 13 16:20:19 2021 -0500
net/rpmsg: add support for new rpmsg sockets
commit f4b978a978c38149f712ddd137f12ed5fb914161 from
git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git
-
This is a classic example of what should NOT EVER be in a BSP branch.
There is NOTHING hardware specific about this AT ALL. By having these
kinds of random feature and random non-hardware changes in an SDK you
then open the door for these kinds of annoying whack-a-mole compile
issues and other regressions.
Now, I realize you didn't put it there, and may not have even worked on
the SDK integration into v5.15 kernel, but someone has to push back on
on the originators of the SDK content and act as a 1st pass filter for
removing obvious unrelated pet projects that are tagging along before
they make to to Yocto.
If your BSP strays outside of arch/ and drivers/ then you REALLY need to
look hard at those changes. If a BSP touches fs/ or net/ or lib/ or any
other non-hardware dirs, it is probably inappropriate and the change(s)
should be dropped.
If you don't, you make things a future merge-hell for Bruce for the next
two years that we maintain v5.15 kernels because we have SDK BSPs that
contain a truck load of random unrelated things.
Alternatively, if in this case, this new rpmsg *feature* is super
important to the overall userspace use case you have in mind for this
hardware, then submit it as a proper kernel feature/addition,
independent of the BSP, and then have the BSP include it.
Bruce, given the above, I suggest we revert c6f441a33dd from the branch
v5.15/standard/ti-sdk-5.10/ti-j72xx and let the original BSP submitter
revisit the question of whether it was needed or just simply shoved
forward because "it was there already".
Thanks,
Paul.
--
`
>
> Signed-off-by: Xulin Sun
> ---
> include/linux/socket.h | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index 6ec661deb432..ef57dbba6c5f 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -223,12 +223,11 @@ struct ucred {
>* reuses AF_INET address family
>*/
> #define AF_XDP 44 /* XDP sockets */
> -#define AF_RPMSG 45 /* Remote-processor messaging */
> -#define AF_MAX 46 /* For now.. */
> -
> -#define AF_MCTP 47 /* Management component
> +#define AF_MCTP 45 /* Management component
>* transport protocol
>*/
> +#define AF_RPMSG 46 /* Remote-processor messaging */
> +#define AF_MAX 47 /* For now.. */
>
> /* Protocol families, same as address families. */
> #define PF_UNSPECAF_UNSPEC
> --
> 2.35.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11126):
https://lists.yoctoproject.org/g/linux-yocto/message/11126
Mute This Topic: https://lists.yoctoproject.org/mt/90283473/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][PATCH] ipv6: Fix stats accounting in ip6_pkt_drop
[[linux-yocto][v5.10/standard/base][PATCH] ipv6: Fix stats accounting in
ip6_pkt_drop] On 06/04/2022 (Wed 15:54) He Zhe wrote:
> VRF devices are the loopbacks for VRFs, and a loopback can not be
> assigned to a VRF. Accordingly, the condition in ip6_pkt_drop should
> be '||' not '&&'.
>
> Fixes: 1d3fd8a10bed ("vrf: Use orig netdev to count Ip6InNoRoutes and a fresh
> route lookup when sending dest unreach")
> Reported-by: Pudak, Filip
> Reported-by: Xiao, Jiguang
> Signed-off-by: David Ahern
> Link: https://lore.kernel.org/r/20220404150908.2937-1-dsah...@kernel.org
> Signed-off-by: Paolo Abeni
>
> Link:
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=1158f79f82d4
As this is in "net" (and not "net-next") it will go to mainline in a
few days[1], and the LF stable team will grab it via the Fixes tag and
backport it automatically (since it is a trivial change).
What I'm getting at here, is that expiditing this (and any other fix that
matches this same criteria) is a make-work project for yourself and for
Bruce. Unless it is has a priority (like a 0-day CVE) then there is no
point trying to accelerate it vs. just waiting the few extra days for
the normal "hands-free" process feed to take place on its own.
And then it will have [comit abcd upstream] on it as well, indicating
clearly that it was a mainline commit and not something that maybe
died on a mailing list thread and went no further.
Thanks,
Paul.
[1]
https://docs.kernel.org/process/maintainer-netdev.html#how-do-the-changes-posted-to-netdev-make-their-way-into-linux
--
> Signed-off-by: He Zhe
> ---
> net/ipv6/route.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 352e645c546e..776b1b58c5dc 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -4398,7 +4398,7 @@ static int ip6_pkt_drop(struct sk_buff *skb, u8 code,
> int ipstats_mib_noroutes)
> struct inet6_dev *idev;
> int type;
>
> - if (netif_is_l3_master(skb->dev) &&
> + if (netif_is_l3_master(skb->dev) ||
> dst->dev == net->loopback_dev)
> idev = __in6_dev_get_safely(dev_get_by_index_rcu(net,
> IP6CB(skb)->iif));
> else
> --
> 2.17.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11125):
https://lists.yoctoproject.org/g/linux-yocto/message/11125
Mute This Topic: https://lists.yoctoproject.org/mt/90285003/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH v5.15 0/1] aufs: remove overhead for typically disabled Yocto use case
After having looked at the AUFS stuff some for the Yocto uprev, what I wanted to look at a bit more was the raw patches, like the aufs5-mmap.patch which touches existing core kernel files like mmap.c and fork.c etc. It is worth noting that the Yocto use case is quite different from the typical RYO user who goes out and sources AUFS for themselves. In the Yocto use case, we have probably 99% of our users who implicitly have AUFS code present but disabled via Kconfig. In the RYO case the code is rarely ever disabled since it was intentionally put there to be used. For those of us who used preempt-rt patches from over a decade ago, we can remember instances where the present-and-enabled case got all the testing and use, and the present-but-disabled case might not even build. That means we should be paying extra attention to ensure the present but disabled case isn't leaving us open to regressions, or any size or performance burdens vs. the unpatched case with no AUFS code present. To that end, I noticed overhead in AUFS that would remain even when disabled that could be relatively easily avoided and I fix that here. Boot testing included AUFS disabled, =y and =m (plus insmod) cases, on the yocto v5.15.30 baseline with the previous AUFS update applied. The two changes made here for the non-MMU case are untested but hopefully "obviously" correct as parallels to the tested MMU instances. Paul. --- Paul Gortmaker (1): aufs: reduce overhead for "code present but disabled" use case. include/linux/mm.h | 15 +++ include/linux/mm_types.h | 4 mm/Makefile | 3 ++- mm/mmap.c| 12 +++- 4 files changed, 32 insertions(+), 2 deletions(-) -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11084): https://lists.yoctoproject.org/g/linux-yocto/message/11084 Mute This Topic: https://lists.yoctoproject.org/mt/90039129/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 1/1] aufs: reduce overhead for "code present but disabled" use case.
The AUFS code introduces a new mm/prfile.c which is used to hook in a shadow structure plus some __FUNC__ and __LINE__ tracing via hijacking some fs/file and mm/vma calls (see aufs5-standalone/aufs5-mmap.patch). As these tiny stubs live in a separate source module, we are always going to be bouncing through them, even with AUFS completely disabled. We also see AUFS adding some content to existing structs even with AUFS disabled. We can fix the 1st by getting rid of prfile.c in the disabled case; we replace it with macros that collapse to the original unpatched code. We can fix the latter by using IS_ENABLED(CONFIG_AUFS_FS) around the extra content AUFS adds/changes so they aren't present when disabled. This covers both the CONFIG_AUFS_FS=m and CONFIG_AUFS_FS=y cases. Finally, there is the deprecated remap_file_pages() syscall - and while it has been deprecated since 2014 - it does add unused code and possibly exposure to regressions/CVE etc. - and so I also used the very same IS_ENABLED() there so we have the original code in the disabled case. The size difference for the disabled case is easy to detect/display. Functions found in prfile.c show up as "-" below since it isn't built: linux-yocto$ size ../aufs*/vmlinux textdata bss dec hex filename 201760198124604 2019564 303201871cea63b ../aufs-debloat/vmlinux 201762598124604 2019564 303204271cea72b ../aufs-default/vmlinux linux-yocto$./scripts/bloat-o-meter ../aufs-default/vmlinux ../aufs-debloat/vmlinux add/remove: 0/4 grow/shrink: 0/14 up/down: 0/-871 (-871) Function old new delta filemap_page_mkwrite 252 247 -5 gate_vma 200 192 -8 mmap_region 15281517 -11 __vma_adjust23572345 -12 remove_vma 104 91 -13 dup_mm.isra 14031387 -16 map_files_get_link 429 408 -21 copy_vma 597 576 -21 __split_vma 420 394 -26 show_numa_map944 917 -27 vma_do_pr_or_file 29 - -29 vma_do_get_file 35 - -35 show_map_vma 350 310 -40 vma_do_fput 47 - -47 vma_do_file_update_time 47 - -47 __func__ 17583 17424-159 __ia32_sys_remap_file_pages 786 623-163 __x64_sys_remap_file_pages 817 626-191 Total: Before=17285664, After=17284793, chg -0.01% linux-yocto$ Performance should be restored to the original non-AUFS baseline given the above reduction in code and removal of out-of-line stubs. Signed-off-by: Paul Gortmaker --- include/linux/mm.h | 15 +++ include/linux/mm_types.h | 4 mm/Makefile | 3 ++- mm/mmap.c| 12 +++- 4 files changed, 32 insertions(+), 2 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 31afd5410740..04c46c1ff2bf 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1813,6 +1813,7 @@ static inline void unmap_shared_mapping_range(struct address_space *mapping, unmap_mapping_range(mapping, holebegin, holelen, 0); } +#if IS_ENABLED(CONFIG_AUFS_FS) extern void vma_do_file_update_time(struct vm_area_struct *, const char[], int); extern struct file *vma_do_pr_or_file(struct vm_area_struct *, const char[], int); @@ -1835,6 +1836,20 @@ extern void vmr_do_fput(struct vm_region *, const char[], int); #define vmr_fput(region) vmr_do_fput(region, __func__, __LINE__) #endif /* !CONFIG_MMU */ +#else /* !CONFIG_AUFS_FS */ + +#define vma_file_update_time(vma) file_update_time((vma)->vm_file) +#define vma_pr_or_file(vma)(vma)->vm_file +#define vma_get_file(vma) get_file((vma)->vm_file) +#define vma_fput(vma) fput((vma)->vm_file) + +#ifndef CONFIG_MMU +#define vmr_pr_or_file(region) (region)->vm_file +#define vmr_fput(region) fput((region)->vm_file) +#endif /* !CONFIG_MMU */ + +#endif /* !CONFIG_AUFS_FS */ + extern int access_process_vm(struct task_struct *tsk, unsigned long addr, void *buf, int len, unsigned int gup_flags); extern int access_remote_vm(struct mm_struct *mm, unsigned long addr, diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h index 3a9a798a4ae1..8fea872e08f7 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -294,7 +294,9 @@ struct
[linux-yocto] [PATCH v5.15-rt] aufs: update compile fix for v5.15+ preempt-rt kernels
The AUFS preempt-rt fix from v5.10 was forward ported to v5.15 in yocto
commit 3f9f162d9bb0 ("aufs: i_op: Add handling for au_pin_hdir_set_owner
with RT kernel") but that isn't quite correct, as we'll stll get:
fs/aufs/i_op.c: In function ‘au_pin_hdir_set_owner’:
fs/aufs/i_op.c:641:28: error: ‘struct rw_semaphore’ has no member named
‘rtmutex’
p->hdir->hi_inode->i_rwsem.rtmutex.owner = task;
^
This is because there has been some restructuring between v5.10 and v5.15
kernels; the is gone and there is a new level of indirection:
In linux 5.10-rt
-- include/linux/rwsem-rt.h --
struct rw_semaphore {
atomic_treaders;
struct rt_mutex rtmutex;
#ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map dep_map;
#endif
};
In linux 5.15-rt
-- include/linux/rwsem.h --
struct rw_semaphore {
struct rwbase_rtrwbase;
#ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map dep_map;
#endif
};
-- include/linux/rwbase_rt.h --
struct rwbase_rt {
atomic_treaders;
struct rt_mutex_basertmutex;
};
Hence we need to bounce through the rwbase to get to the rtmutex now.
Cc: He Zhe
Signed-off-by: Paul Gortmaker
diff --git a/fs/aufs/i_op.c b/fs/aufs/i_op.c
index 354fcb8ea1cb..ce36045f48cb 100644
--- a/fs/aufs/i_op.c
+++ b/fs/aufs/i_op.c
@@ -638,7 +638,7 @@ int au_pin_hdir_relock(struct au_pin *p)
static void au_pin_hdir_set_owner(struct au_pin *p, struct task_struct *task)
{
#ifdef CONFIG_PREEMPT_RT
- p->hdir->hi_inode->i_rwsem.rtmutex.owner = task;
+ p->hdir->hi_inode->i_rwsem.rwbase.rtmutex.owner = task;
#else
atomic_long_set(>hdir->hi_inode->i_rwsem.owner, (long)task);
#endif
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11083):
https://lists.yoctoproject.org/g/linux-yocto/message/11083
Mute This Topic: https://lists.yoctoproject.org/mt/90024952/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] [PATCH v5.15 00/21] aufs: update from 5.14-20210906 to 5.15.5-20220221+
[[linux-yocto] [PATCH v5.15 00/21] aufs: update from 5.14-20210906 to 5.15.5-20220221+] On 24/03/2022 (Thu 10:41) Paul Gortmaker wrote: > I can push to linux-yocto-contrib once the push hook is fixed if needed. The following changes since commit 70cf8dde55448a804da825139fa12daf5a855047: Merge tag 'v5.15.30' into v5.15/standard/base (2022-03-21 07:44:52 -0400) are available in the Git repository at: git://git.yoctoproject.org/linux-yocto-contrib aufs-5.15.5-20220221 for you to fetch changes up to b98d189df02cc340bfbd61d4c8ef278800a8730e: aufs: bugfix, umount passes NULL to ->parse_monolithic() (2022-03-23 21:36:04 -0400) J. R. Okajima (16): aufs: for v5.15-rc1, no mand-lock anymore aufs: for v5.15-rc1, new param 'rcu' for ->get_acl() aufs: for v5.15-rc1, sync_inode() is gone aufs: pre fs_context, convert the type of alloc_sbinfo() aufs: pre fs_context, support the incomplete sb and sbinfo case aufs: pre fs_context, convert a static flag to a macro aufs: fs_context 1/7, skelton of the new shceme aufs: fs_context 2/7, parse "br" mount option aufs: fs_context 3/7, parse the branch-management options aufs: fs_context 4/7, parse xino options aufs: fs_context 5/7, parse all other mount options aufs: fs_context 6/7, now mount aufs: fs_context 7/7, finally remount aufs: tiny, headers after fs_context aufs standalone: cosmetic, missing copyright sentence aufs: bugfix, umount passes NULL to ->parse_monolithic() Paul Gortmaker (5): Revert "aufs: adjust to v5.15 fs changes" aufs: 5.14-20210906 ---> 5.14-20211018 aufs: 5.14-20211018 ---> 5.15.5-20211129 aufs: 5.15.5-20211129 ---> 5.15.5-20220117 aufs: 5.15.5-20220117 ---> 5.15.5-20220221 Documentation/filesystems/aufs/README |2 +- fs/aufs/Makefile |2 +- fs/aufs/cpup.c|6 +- fs/aufs/debug.c |5 +- fs/aufs/dentry.c | 36 +- fs/aufs/dentry.h |2 +- fs/aufs/dirren.c |9 +- fs/aufs/export.c | 13 +- fs/aufs/fsctx.c | 1242 + fs/aufs/i_op.c|1 - fs/aufs/i_op_del.c| 13 +- fs/aufs/i_op_ren.c| 14 +- fs/aufs/opts.c| 998 ++ fs/aufs/opts.h| 46 +- fs/aufs/plink.c | 62 +- fs/aufs/posix_acl.c | 10 +- fs/aufs/sbinfo.c | 14 +- fs/aufs/super.c | 247 +-- fs/aufs/super.h |9 +- fs/aufs/vfsub.c | 34 +- fs/aufs/vfsub.h | 10 +- fs/aufs/whout.c | 82 +-- fs/aufs/whout.h |4 +- fs/aufs/xino.c| 13 +- include/uapi/linux/aufs_type.h|2 +- 25 files changed, 1581 insertions(+), 1295 deletions(-) create mode 100644 fs/aufs/fsctx.c -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11082): https://lists.yoctoproject.org/g/linux-yocto/message/11082 Mute This Topic: https://lists.yoctoproject.org/mt/9691/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 20/21] aufs standalone: cosmetic, missing copyright sentence
From: "J. R. Okajima" commit 325d277142a1fff5ac844886d2495cfee5c1e7d0 aufs5-standalone upstream. I just forgot merging the copyright sentences in the new source file fs/aufs/fsctx.c. Signed-off-by: J. R. Okajima Signed-off-by: Paul Gortmaker --- fs/aufs/fsctx.c | 13 + 1 file changed, 13 insertions(+) diff --git a/fs/aufs/fsctx.c b/fs/aufs/fsctx.c index aa9b38c2..eb305670c358 100644 --- a/fs/aufs/fsctx.c +++ b/fs/aufs/fsctx.c @@ -1,6 +1,19 @@ // SPDX-License-Identifier: GPL-2.0 /* * Copyright (C) 2022 Junjiro R. Okajima + * + * This program, aufs is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see <http://www.gnu.org/licenses/>. */ /* -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11081): https://lists.yoctoproject.org/g/linux-yocto/message/11081 Mute This Topic: https://lists.yoctoproject.org/mt/9719/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 19/21] aufs: 5.15.5-20220117 ---> 5.15.5-20220221
Corresponds to:
commit 6f292fea7136cec1752935170e44b78e0fa53ea7 (HEAD)
Author: J. R. Okajima
Date: Sun Feb 20 09:43:26 2022 +0900
5.15.5 20220221
in https://github.com/sfjro/aufs5-standalone.git
which via "git log --oneline --no-merges aufs5.15.5" encapsulates:
6f292fea7136 5.15.5 20220221
ac38cd415fb9 aufs: tiny, headers after fs_context
8aa55258925f aufs: fs_context 7/7, finally remount
3450ca9346c0 aufs: fs_context 6/7, now mount
e734244bd54a aufs: fs_context 5/7, parse all other mount options
3c9e9e3b9102 aufs: fs_context 4/7, parse xino options
5dc9a7c80362 aufs: fs_context 3/7, parse the branch-management options
4fdd4d389330 aufs: fs_context 2/7, parse "br" mount option
7f235dcdee2a aufs: fs_context 1/7, skelton of the new shceme
b8aa569c2ea5 aufs: pre fs_context, convert a static flag to a macro
4a19e0b7642f aufs: pre fs_context, support the incomplete sb and sbinfo case
3792c81561c7 aufs: pre fs_context, convert the type of alloc_sbinfo()
17dd5444ac51 5.15.5 20220117
Note that the series of 3+7+1 commits have been applied individually
prior to this version bump commit.
Signed-off-by: Paul Gortmaker
---
include/uapi/linux/aufs_type.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/aufs_type.h b/include/uapi/linux/aufs_type.h
index 4b51ea9f14b4..8ae8cc22a72c 100644
--- a/include/uapi/linux/aufs_type.h
+++ b/include/uapi/linux/aufs_type.h
@@ -40,7 +40,7 @@
#include
#endif /* __KERNEL__ */
-#define AUFS_VERSION "5.15.5-20220117"
+#define AUFS_VERSION "5.15.5-20220221"
/* todo? move this to linux-2.6.19/include/magic.h */
#define AUFS_SUPER_MAGIC ('a' << 24 | 'u' << 16 | 'f' << 8 | 's')
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11079):
https://lists.yoctoproject.org/g/linux-yocto/message/11079
Mute This Topic: https://lists.yoctoproject.org/mt/9714/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 21/21] aufs: bugfix, umount passes NULL to ->parse_monolithic()
From: "J. R. Okajima"
commit 25f5c5fdcb1b6c2a47f58b59c74547538b7b7c2a aufs5-standalone upstream.
The parameter "void *data" is NULL in unmounting.
Reported-by: PB on github
Signed-off-by: J. R. Okajima
See-also: https://github.com/sfjro/aufs5-standalone/issues/9
Signed-off-by: Paul Gortmaker
---
fs/aufs/fsctx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/aufs/fsctx.c b/fs/aufs/fsctx.c
index eb305670c358..e5622fc17d60 100644
--- a/fs/aufs/fsctx.c
+++ b/fs/aufs/fsctx.c
@@ -1104,7 +1104,7 @@ static int au_fsctx_parse_monolithic(struct fs_context
*fc, void *data)
str = data;
AuDbg("str %s\n", str);
- while (1) {
+ while (str) {
u = is_colonopt(str);
if (u)
str[u] = '=';
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11080):
https://lists.yoctoproject.org/g/linux-yocto/message/11080
Mute This Topic: https://lists.yoctoproject.org/mt/9715/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 18/21] aufs: tiny, headers after fs_context
From: "J. R. Okajima" commit ac38cd415fb9089b0c4ccb8f1d0588da9d6e14e5 aufs5-standalone upstream. Since new opts.h includes linux/namei.h, all other source files are not necessary to include it anymore. Signed-off-by: J. R. Okajima Signed-off-by: Paul Gortmaker --- fs/aufs/dentry.c | 1 - fs/aufs/export.c | 1 - fs/aufs/i_op.c | 1 - fs/aufs/vfsub.c | 1 - 4 files changed, 4 deletions(-) diff --git a/fs/aufs/dentry.c b/fs/aufs/dentry.c index 1bae481ab105..8f5976bc4419 100644 --- a/fs/aufs/dentry.c +++ b/fs/aufs/dentry.c @@ -21,7 +21,6 @@ */ #include -#include #include "aufs.h" /* diff --git a/fs/aufs/export.c b/fs/aufs/export.c index e28bceb7386a..2e409acd84f0 100644 --- a/fs/aufs/export.c +++ b/fs/aufs/export.c @@ -22,7 +22,6 @@ #include #include -#include #include #include #include diff --git a/fs/aufs/i_op.c b/fs/aufs/i_op.c index bfce27d451f1..dd59340637cf 100644 --- a/fs/aufs/i_op.c +++ b/fs/aufs/i_op.c @@ -23,7 +23,6 @@ #include #include #include -#include #include #include "aufs.h" diff --git a/fs/aufs/vfsub.c b/fs/aufs/vfsub.c index f6e27fbcf584..9c551a27cc98 100644 --- a/fs/aufs/vfsub.c +++ b/fs/aufs/vfsub.c @@ -21,7 +21,6 @@ */ #include -#include #include #include #include -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11078): https://lists.yoctoproject.org/g/linux-yocto/message/11078 Mute This Topic: https://lists.yoctoproject.org/mt/9713/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 13/21] aufs: fs_context 3/7, parse the branch-management options
From: "J. R. Okajima"
commit 5dc9a7c80362f1bbb4699aa2b9cb4d6439edfca3 aufs5-standalone upstream.
This "fs_context" series essentially moves some parts of opts.c to
fsctx.c, and adjusts it to fit fs_context scheme. No enhancements,
no bugfixes.
Since some parts of opts.c are moved out, this commit makes aufs
unusable but compilable.
add, ins, append, prepend, del, and mod options are added. idel and
imod options are still not implemented.
Signed-off-by: J. R. Okajima
Signed-off-by: Paul Gortmaker
---
fs/aufs/fsctx.c | 272 +++-
fs/aufs/opts.c | 216 --
2 files changed, 270 insertions(+), 218 deletions(-)
diff --git a/fs/aufs/fsctx.c b/fs/aufs/fsctx.c
index 92ead39cbbaa..6d281649fa3f 100644
--- a/fs/aufs/fsctx.c
+++ b/fs/aufs/fsctx.c
@@ -25,6 +25,8 @@ static void au_fsctx_dump(struct au_opts *opts)
/* reduce stack space */
union {
struct au_opt_add *add;
+ struct au_opt_del *del;
+ struct au_opt_mod *mod;
} u;
struct au_opt *opt;
@@ -37,9 +39,36 @@ static void au_fsctx_dump(struct au_opts *opts)
u.add->bindex, u.add->pathname, u.add->perm,
u.add->path.dentry);
break;
+ case Opt_del:
+ fallthrough;
+ case Opt_idel:
+ u.del = >del;
+ AuDbg("del {%s, %p}\n",
+ u.del->pathname, u.del->h_path.dentry);
+ break;
+ case Opt_mod:
+ fallthrough;
+ case Opt_imod:
+ u.mod = >mod;
+ AuDbg("mod {%s, 0x%x, %p}\n",
+ u.mod->path, u.mod->perm, u.mod->h_root);
+ break;
+ case Opt_append:
+ u.add = >add;
+ AuDbg("append {b%d, %s, 0x%x, %p}\n",
+ u.add->bindex, u.add->pathname, u.add->perm,
+ u.add->path.dentry);
+ break;
+ case Opt_prepend:
+ u.add = >add;
+ AuDbg("prepend {b%d, %s, 0x%x, %p}\n",
+ u.add->bindex, u.add->pathname, u.add->perm,
+ u.add->path.dentry);
+ break;
/* re-commit later */
default:
+ AuDbg("type %d\n", opt->type);
BUG();
}
opt++;
@@ -51,8 +80,19 @@ static void au_fsctx_dump(struct au_opts *opts)
const struct fs_parameter_spec aufs_fsctx_paramspec[] = {
fsparam_string("br", Opt_br),
- /* re-commit later */
+ /* "add=%d:%s" or "ins=%d:%s" */
+ fsparam_string("add", Opt_add),
+ fsparam_string("ins", Opt_add),
+ fsparam_path("append", Opt_append),
+ fsparam_path("prepend", Opt_prepend),
+
+ fsparam_path("del", Opt_del),
+ /* fsparam_s32("idel", Opt_idel), */
+ fsparam_path("mod", Opt_mod),
+ /* fsparam_string("imod", Opt_imod), */
+
+ /* re-commit later */
{}
};
@@ -115,6 +155,169 @@ static int au_fsctx_parse_br(struct fs_context *fc, char
*brspec)
return err;
}
+static int au_fsctx_parse_add(struct fs_context *fc, char *addspec)
+{
+ int err, n;
+ char *p;
+ struct au_fsctx_opts *a = fc->fs_private;
+ struct au_opt *opt = a->opt;
+
+ err = -EINVAL;
+ p = strchr(addspec, ':');
+ if (unlikely(!p)) {
+ errorfc(fc, "bad arg in %s", addspec);
+ goto out;
+ }
+ *p++ = '\0';
+ err = kstrtoint(addspec, 0, );
+ if (unlikely(err)) {
+ errorfc(fc, "bad integer in %s", addspec);
+ goto out;
+ }
+ AuDbg("n %d\n", n);
+ err = au_fsctx_parse_do_add(fc, opt, p, /*len*/0, n);
+
+out:
+ AuTraceErr(err);
+ return err;
+}
+
+static int au_fsctx_parse_del(struct fs_context *fc, struct au_opt_del *del,
+ struct fs_parameter *param)
+{
+ int err;
+
+ err = -ENOMEM;
+ /* will be freed by au_fsctx_free() */
+ del->pathname = kmemdup_nul(param->string, param->size, GFP_NOFS);
+ if (unlikely(!del->pathname))
+ goto out;
+ AuDbg("del %s\n", del->pathname);
+ err = vfsub_kern_path(del->pathname, AuOpt_LkupDirFlags, >h_path);
+ if (unlikely(err))
+
[linux-yocto] [PATCH 15/21] aufs: fs_context 5/7, parse all other mount options
From: "J. R. Okajima"
commit e734244bd54a154dae92d264e8a6e7659507347d aufs5-standalone upstream.
This "fs_context" series essentially moves some parts of opts.c to
fsctx.c, and adjusts it to fit fs_context scheme. No enhancements,
no bugfixes.
Since some parts of opts.c are moved out, this commit makes aufs
unusable but compilable.
Signed-off-by: J. R. Okajima
Signed-off-by: Paul Gortmaker
---
fs/aufs/fsctx.c | 310 ++-
fs/aufs/opts.c | 545 ++--
fs/aufs/opts.h | 25 +--
3 files changed, 381 insertions(+), 499 deletions(-)
diff --git a/fs/aufs/fsctx.c b/fs/aufs/fsctx.c
index 3319bf02b31b..b7896c4c1c07 100644
--- a/fs/aufs/fsctx.c
+++ b/fs/aufs/fsctx.c
@@ -29,6 +29,7 @@ static void au_fsctx_dump(struct au_opts *opts)
struct au_opt_mod *mod;
struct au_opt_xino *xino;
struct au_opt_xino_itrunc *xino_itrunc;
+ struct au_opt_wbr_create *create;
} u;
struct au_opt *opt;
@@ -68,6 +69,19 @@ static void au_fsctx_dump(struct au_opts *opts)
u.add->path.dentry);
break;
+ case Opt_dirwh:
+ AuDbg("dirwh %d\n", opt->dirwh);
+ break;
+ case Opt_rdcache:
+ AuDbg("rdcache %d\n", opt->rdcache);
+ break;
+ case Opt_rdblk:
+ AuDbg("rdblk %d\n", opt->rdblk);
+ break;
+ case Opt_rdhash:
+ AuDbg("rdhash %u\n", opt->rdhash);
+ break;
+
case Opt_xino:
u.xino = >xino;
AuDbg("xino {%s %pD}\n", u.xino->path, u.xino->file);
@@ -84,6 +98,15 @@ static void au_fsctx_dump(struct au_opts *opts)
/* simple true/false flag */
au_fsctx_TF(trunc_xino);
au_fsctx_TF(trunc_xib);
+ au_fsctx_TF(dirperm1);
+ au_fsctx_TF(plink);
+ au_fsctx_TF(shwh);
+ au_fsctx_TF(dio);
+ au_fsctx_TF(warn_perm);
+ au_fsctx_TF(verbose);
+ au_fsctx_TF(sum);
+ au_fsctx_TF(dirren);
+ au_fsctx_TF(acl);
#undef au_fsctx_TF
case Opt_trunc_xino_path:
@@ -95,7 +118,57 @@ static void au_fsctx_dump(struct au_opts *opts)
case Opt_noxino:
AuLabel(noxino);
break;
- /* re-commit later */
+
+ case Opt_list_plink:
+ AuLabel(list_plink);
+ break;
+ case Opt_udba:
+ AuDbg("udba %d, %s\n",
+ opt->udba, au_optstr_udba(opt->udba));
+ break;
+ case Opt_diropq_a:
+ AuLabel(diropq_a);
+ break;
+ case Opt_diropq_w:
+ AuLabel(diropq_w);
+ break;
+ case Opt_wsum:
+ AuLabel(wsum);
+ break;
+ case Opt_wbr_create:
+ u.create = >wbr_create;
+ AuDbg("create %d, %s\n", u.create->wbr_create,
+ au_optstr_wbr_create(u.create->wbr_create));
+ switch (u.create->wbr_create) {
+ case AuWbrCreate_MFSV:
+ fallthrough;
+ case AuWbrCreate_PMFSV:
+ AuDbg("%d sec\n", u.create->mfs_second);
+ break;
+ case AuWbrCreate_MFSRR:
+ fallthrough;
+ case AuWbrCreate_TDMFS:
+ AuDbg("%llu watermark\n",
+ u.create->mfsrr_watermark);
+ break;
+ case AuWbrCreate_MFSRRV:
+ fallthrough;
+ case AuWbrCreate_TDMFSV:
+ fallthrough;
+ case AuWbrCreate_PMFSRRV:
+ AuDbg("%llu watermark, %d sec\n",
+ u.create->mfsrr_watermark,
+ u.create->mfs_second);
+ break;
+ }
+ break;
+ case Opt_wbr_copyup:
+ AuDbg("copyup %d, %s\n", opt->wbr_copyup,
+ au_optstr_wbr_copyup(opt->wbr_copyup))
[linux-yocto] [PATCH 16/21] aufs: fs_context 6/7, now mount
From: "J. R. Okajima"
commit 3450ca9346c07e69e9f6686751ecbd656c61cc30 aufs5-standalone upstream.
This "fs_context" series essentially moves some parts of opts.c to
fsctx.c, and adjusts it to fit fs_context scheme. No enhancements,
no bugfixes.
This commit makes aufs usable back but "remount" option is still
unusable.
Signed-off-by: J. R. Okajima
Signed-off-by: Paul Gortmaker
---
fs/aufs/fsctx.c | 98 +++-
fs/aufs/super.c | 118 ++--
fs/aufs/super.h | 6 ++-
3 files changed, 106 insertions(+), 116 deletions(-)
diff --git a/fs/aufs/fsctx.c b/fs/aufs/fsctx.c
index b7896c4c1c07..eae790d2c4a2 100644
--- a/fs/aufs/fsctx.c
+++ b/fs/aufs/fsctx.c
@@ -19,6 +19,101 @@ struct au_fsctx_opts {
struct au_opts opts;
};
+/* stop extra interpretation of errno in mount(8), and strange error messages
*/
+static int cvt_err(int err)
+{
+ AuTraceErr(err);
+
+ switch (err) {
+ case -ENOENT:
+ case -ENOTDIR:
+ case -EEXIST:
+ case -EIO:
+ err = -EINVAL;
+ }
+ return err;
+}
+
+static int au_fsctx_fill_super(struct super_block *sb, struct fs_context *fc)
+{
+ int err;
+ struct au_fsctx_opts *a = fc->fs_private;
+ struct au_sbinfo *sbinfo = a->sbinfo;
+ struct dentry *root;
+ struct inode *inode;
+
+ sbinfo->si_sb = sb;
+ sb->s_fs_info = sbinfo;
+ kobject_get(>si_kobj);
+
+ __si_write_lock(sb);
+ si_pid_set(sb);
+ au_sbilist_add(sb);
+
+ /* all timestamps always follow the ones on the branch */
+ sb->s_flags |= SB_NOATIME | SB_NODIRATIME;
+ sb->s_flags |= SB_I_VERSION; /* do we really need this? */
+ sb->s_op = _sop;
+ sb->s_d_op = _dop;
+ sb->s_magic = AUFS_SUPER_MAGIC;
+ sb->s_maxbytes = 0;
+ sb->s_stack_depth = 1;
+ au_export_init(sb);
+ au_xattr_init(sb);
+
+ err = au_alloc_root(sb);
+ if (unlikely(err)) {
+ si_write_unlock(sb);
+ goto out;
+ }
+ root = sb->s_root;
+ inode = d_inode(root);
+ ii_write_lock_parent(inode);
+ aufs_write_unlock(root);
+
+ /* lock vfs_inode first, then aufs. */
+ inode_lock(inode);
+ aufs_write_lock(root);
+ err = au_opts_mount(sb, >opts);
+ AuTraceErr(err);
+ if (!err && au_ftest_si(sbinfo, NO_DREVAL)) {
+ sb->s_d_op = _dop_noreval;
+ /* infofc(fc, "%ps", sb->s_d_op); */
+ pr_info("%ps\n", sb->s_d_op);
+ au_refresh_dop(root, /*force_reval*/0);
+ sbinfo->si_iop_array = aufs_iop_nogetattr;
+ au_refresh_iop(inode, /*force_getattr*/0);
+ }
+ aufs_write_unlock(root);
+ inode_unlock(inode);
+ if (!err)
+ goto out; /* success */
+
+ dput(root);
+ sb->s_root = NULL;
+
+out:
+ if (unlikely(err))
+ kobject_put(>si_kobj);
+ AuTraceErr(err);
+ err = cvt_err(err);
+ AuTraceErr(err);
+ return err;
+}
+
+static int au_fsctx_get_tree(struct fs_context *fc)
+{
+ int err;
+
+ AuDbg("fc %p\n", fc);
+ err = get_tree_nodev(fc, au_fsctx_fill_super);
+
+ AuTraceErr(err);
+ return err;
+}
+
+/* -- */
+
static void au_fsctx_dump(struct au_opts *opts)
{
#ifdef CONFIG_AUFS_DEBUG
@@ -1017,7 +1112,8 @@ static void au_fsctx_free(struct fs_context *fc)
static const struct fs_context_operations au_fsctx_ops = {
.free = au_fsctx_free,
.parse_param= au_fsctx_parse_param,
- .parse_monolithic = au_fsctx_parse_monolithic
+ .parse_monolithic = au_fsctx_parse_monolithic,
+ .get_tree = au_fsctx_get_tree
/* re-commit later */
};
diff --git a/fs/aufs/super.c b/fs/aufs/super.c
index 713d2bb7f0ad..bdab4bc56811 100644
--- a/fs/aufs/super.c
+++ b/fs/aufs/super.c
@@ -847,7 +847,7 @@ static int aufs_remount_fs(struct super_block *sb, int
*flags, char *data)
return err;
}
-static const struct super_operations aufs_sop = {
+const struct super_operations aufs_sop = {
.alloc_inode= aufs_alloc_inode,
.destroy_inode = aufs_destroy_inode,
.free_inode = aufs_free_inode,
@@ -862,7 +862,7 @@ static const struct super_operations aufs_sop = {
/* -- */
-static int alloc_root(struct super_block *sb)
+int au_alloc_root(struct super_block *sb)
{
int err;
struct inode *inode;
@@ -898,119 +898,8 @@ static int alloc_root(struct super_block *sb)
return err;
}
-static int aufs_fill_super(struct super_block *sb, void *raw_data,
-
[linux-yocto] [PATCH 17/21] aufs: fs_context 7/7, finally remount
From: "J. R. Okajima"
commit 8aa55258925f264b9f5e99167dde63f5e66cd52d aufs5-standalone upstream.
This "fs_context" series essentially moves some parts of opts.c to
fsctx.c, and adjusts it to fit fs_context scheme. No enhancements,
no bugfixes.
This commit finishes the series and makes aufs fully usable back.
Signed-off-by: J. R. Okajima
Signed-off-by: Paul Gortmaker
---
fs/aufs/fsctx.c | 61 +++--
fs/aufs/opts.c | 12 ---
fs/aufs/opts.h | 2 --
fs/aufs/super.c | 90 ++---
fs/aufs/super.h | 1 +
5 files changed, 62 insertions(+), 104 deletions(-)
diff --git a/fs/aufs/fsctx.c b/fs/aufs/fsctx.c
index eae790d2c4a2..aa9b38c2 100644
--- a/fs/aufs/fsctx.c
+++ b/fs/aufs/fsctx.c
@@ -34,6 +34,59 @@ static int cvt_err(int err)
return err;
}
+static int au_fsctx_reconfigure(struct fs_context *fc)
+{
+ int err, do_dx;
+ unsigned int mntflags;
+ struct dentry *root;
+ struct super_block *sb;
+ struct inode *inode;
+ struct au_fsctx_opts *a = fc->fs_private;
+
+ AuDbg("fc %p\n", fc);
+
+ root = fc->root;
+ sb = root->d_sb;
+ err = si_write_lock(sb, AuLock_FLUSH | AuLock_NOPLM);
+ if (!err) {
+ di_write_lock_child(root);
+ err = au_opts_verify(sb, fc->sb_flags, /*pending*/0);
+ aufs_write_unlock(root);
+ }
+
+ inode = d_inode(root);
+ inode_lock(inode);
+ err = si_write_lock(sb, AuLock_FLUSH | AuLock_NOPLM);
+ if (unlikely(err))
+ goto out;
+ di_write_lock_child(root);
+
+ /* au_opts_remount() may return an error */
+ err = au_opts_remount(sb, >opts);
+
+ if (au_ftest_opts(a->opts.flags, REFRESH))
+ au_remount_refresh(sb, au_ftest_opts(a->opts.flags,
+REFRESH_IDOP));
+
+ if (au_ftest_opts(a->opts.flags, REFRESH_DYAOP)) {
+ mntflags = au_mntflags(sb);
+ do_dx = !!au_opt_test(mntflags, DIO);
+ au_dy_arefresh(do_dx);
+ }
+
+ au_fhsm_wrote_all(sb, /*force*/1); /* ?? */
+ aufs_write_unlock(root);
+
+out:
+ inode_unlock(inode);
+ err = cvt_err(err);
+ AuTraceErr(err);
+
+ return err;
+}
+
+/* -- */
+
static int au_fsctx_fill_super(struct super_block *sb, struct fs_context *fc)
{
int err;
@@ -1113,8 +1166,12 @@ static const struct fs_context_operations au_fsctx_ops =
{
.free = au_fsctx_free,
.parse_param= au_fsctx_parse_param,
.parse_monolithic = au_fsctx_parse_monolithic,
- .get_tree = au_fsctx_get_tree
- /* re-commit later */
+ .get_tree = au_fsctx_get_tree,
+ .reconfigure= au_fsctx_reconfigure
+ /*
+* nfs4 requires ->dup()? No.
+* I don't know what is this ->dup() for.
+*/
};
int aufs_fsctx_init(struct fs_context *fc)
diff --git a/fs/aufs/opts.c b/fs/aufs/opts.c
index c57f79dd7ec3..703ff034c467 100644
--- a/fs/aufs/opts.c
+++ b/fs/aufs/opts.c
@@ -391,11 +391,6 @@ const char *au_optstr_wbr_copyup(int wbr_copyup)
/* -- */
-void au_opts_free(struct au_opts *opts)
-{
- /* empty */
-}
-
int au_opt_add(struct au_opt *opt, char *opt_str, unsigned long sb_flags,
aufs_bindex_t bindex)
{
@@ -432,13 +427,6 @@ int au_opt_add(struct au_opt *opt, char *opt_str, unsigned
long sb_flags,
return err;
}
-/* called without aufs lock */
-int au_opts_parse(struct super_block *sb, char *str, struct au_opts *opts)
-{
- /* empty */
- return 0;
-}
-
static int au_opt_wbr_create(struct super_block *sb,
struct au_opt_wbr_create *create)
{
diff --git a/fs/aufs/opts.h b/fs/aufs/opts.h
index 265f751351c8..3aa8ed1ccc03 100644
--- a/fs/aufs/opts.h
+++ b/fs/aufs/opts.h
@@ -245,11 +245,9 @@ const char *au_optstr_wbr_create(int wbr_create);
int au_wbr_copyup_val(char *str);
const char *au_optstr_wbr_copyup(int wbr_copyup);
-void au_opts_free(struct au_opts *opts);
int au_opt_add(struct au_opt *opt, char *opt_str, unsigned long sb_flags,
aufs_bindex_t bindex);
struct super_block;
-int au_opts_parse(struct super_block *sb, char *str, struct au_opts *opts);
int au_opts_verify(struct super_block *sb, unsigned long sb_flags,
unsigned int pending);
int au_opts_mount(struct super_block *sb, struct au_opts *opts);
diff --git a/fs/aufs/super.c b/fs/aufs/super.c
index bdab4bc56811..24a5c99eea3b 100644
--- a/fs/aufs/super.c
+++ b/fs/aufs/super.c
@@ -701,7 +701,7 @@ static int au_refresh_i(struct super_block *sb, unsigned
int do_idop)
return err;
[linux-yocto] [PATCH 11/21] aufs: fs_context 1/7, skelton of the new shceme
From: "J. R. Okajima"
commit 7f235dcdee2a7706517d893c851cf14fabca6a7c aufs5-standalone upstream.
Introduces a new file fs/aufs/fsctx.c which defines
- file_system_type->init_fs_context()
- file_system_type->parameters
- fs_context_operations->free()
but they are not completed and not activated yet.
This series "fs_context" will add the support for fs_context step by
step, and these operations will be filled and set in the succeeding
commits.
The commit itself is rather meaningless and never affect the
behaviour.
Signed-off-by: J. R. Okajima
Signed-off-by: Paul Gortmaker
---
fs/aufs/Makefile | 2 +-
fs/aufs/fsctx.c | 89
2 files changed, 90 insertions(+), 1 deletion(-)
create mode 100644 fs/aufs/fsctx.c
diff --git a/fs/aufs/Makefile b/fs/aufs/Makefile
index 2c819a64935e..4af8ecde3e3f 100644
--- a/fs/aufs/Makefile
+++ b/fs/aufs/Makefile
@@ -17,7 +17,7 @@ ccflags-y += -include
${srctree}/include/uapi/linux/aufs_type.h
endif
obj-$(CONFIG_AUFS_FS) += aufs.o
-aufs-y := module.o sbinfo.o super.o branch.o xino.o sysaufs.o opts.o \
+aufs-y := module.o sbinfo.o super.o branch.o xino.o sysaufs.o opts.o fsctx.o \
wkq.o vfsub.o dcsub.o \
cpup.o whout.o wbr_policy.o \
dinfo.o dentry.o \
diff --git a/fs/aufs/fsctx.c b/fs/aufs/fsctx.c
new file mode 100644
index ..f02cc9005d95
--- /dev/null
+++ b/fs/aufs/fsctx.c
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Junjiro R. Okajima
+ */
+
+/*
+ * fs context, aka new mount api
+ */
+
+#include
+#include "aufs.h"
+
+struct au_fsctx_opts {
+ struct au_opt *opt, *opt_tail;
+ struct super_block *sb;
+ struct au_sbinfo *sbinfo;
+ struct au_opts opts;
+};
+
+static void au_fsctx_free(struct fs_context *fc)
+{
+ struct au_fsctx_opts *a = fc->fs_private;
+
+ /* fs_type=%p, root=%pD */
+ AuDbg("fc %p{sb_flags 0x%x, sb_flags_mask 0x%x, purpose %u\n",
+ fc, fc->sb_flags, fc->sb_flags_mask, fc->purpose);
+
+ kobject_put(>sbinfo->si_kobj);
+ free_page((unsigned long)a->opts.opt);
+ au_kfree_rcu(a);
+}
+
+static const struct fs_context_operations au_fsctx_ops = {
+ .free = au_fsctx_free
+ /* re-commit later */
+};
+
+int aufs_fsctx_init(struct fs_context *fc)
+{
+ int err;
+ struct au_fsctx_opts *a;
+
+ /* fs_type=%p, root=%pD */
+ AuDbg("fc %p{sb_flags 0x%x, sb_flags_mask 0x%x, purpose %u\n",
+ fc, fc->sb_flags, fc->sb_flags_mask, fc->purpose);
+
+ /* they will be freed by au_fsctx_free() */
+ err = -ENOMEM;
+ a = kzalloc(sizeof(*a), GFP_NOFS);
+ if (unlikely(!a))
+ goto out;
+ a->opts.opt = (void *)__get_free_page(GFP_NOFS);
+ if (unlikely(!a->opts.opt))
+ goto out_a;
+ a->opt = a->opts.opt;
+ a->opt->type = 0; /* re-commit later */
+ a->opts.max_opt = PAGE_SIZE / sizeof(*a->opts.opt);
+ a->opt_tail = a->opt + a->opts.max_opt - 1;
+ a->opts.sb_flags = fc->sb_flags;
+
+ a->sb = NULL;
+ if (fc->root) {
+ AuDebugOn(fc->purpose != FS_CONTEXT_FOR_RECONFIGURE);
+ a->opts.flags = AuOpts_REMOUNT;
+ a->sb = fc->root->d_sb;
+ a->sbinfo = au_sbi(a->sb);
+ kobject_get(>sbinfo->si_kobj);
+ } else {
+ a->sbinfo = au_si_alloc(a->sb);
+ AuDebugOn(!a->sbinfo);
+ err = PTR_ERR(a->sbinfo);
+ if (IS_ERR(a->sbinfo))
+ goto out_opt;
+ au_rw_write_unlock(>sbinfo->si_rwsem);
+ }
+
+ err = 0;
+ fc->fs_private = a;
+ fc->ops = _fsctx_ops;
+ goto out; /* success */
+
+out_opt:
+ free_page((unsigned long)a->opts.opt);
+out_a:
+ au_kfree_rcu(a);
+out:
+ AuTraceErr(err);
+ return err;
+}
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11072):
https://lists.yoctoproject.org/g/linux-yocto/message/11072
Mute This Topic: https://lists.yoctoproject.org/mt/9702/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 14/21] aufs: fs_context 4/7, parse xino options
From: "J. R. Okajima"
commit 3c9e9e3b9102387b69d6e468f654223a5491b912 aufs5-standalone upstream.
This "fs_context" series essentially moves some parts of opts.c to
fsctx.c, and adjusts it to fit fs_context scheme. No enhancements,
no bugfixes.
Since some parts of opts.c are moved out, this commit makes aufs
unusable but compilable.
xino/noxino, trunc_xino/notrunc_xino, itrunc_xino, and
trunc_xib/notrunc_xib options are added. trunx_xino_v and zxino
options are still not implemented.
Signed-off-by: J. R. Okajima
Signed-off-by: Paul Gortmaker
---
fs/aufs/fsctx.c | 200 +++-
fs/aufs/opts.c | 173 +++--
fs/aufs/opts.h | 5 +-
3 files changed, 213 insertions(+), 165 deletions(-)
diff --git a/fs/aufs/fsctx.c b/fs/aufs/fsctx.c
index 6d281649fa3f..3319bf02b31b 100644
--- a/fs/aufs/fsctx.c
+++ b/fs/aufs/fsctx.c
@@ -27,6 +27,8 @@ static void au_fsctx_dump(struct au_opts *opts)
struct au_opt_add *add;
struct au_opt_del *del;
struct au_opt_mod *mod;
+ struct au_opt_xino *xino;
+ struct au_opt_xino_itrunc *xino_itrunc;
} u;
struct au_opt *opt;
@@ -65,6 +67,34 @@ static void au_fsctx_dump(struct au_opts *opts)
u.add->bindex, u.add->pathname, u.add->perm,
u.add->path.dentry);
break;
+
+ case Opt_xino:
+ u.xino = >xino;
+ AuDbg("xino {%s %pD}\n", u.xino->path, u.xino->file);
+ break;
+
+#define au_fsctx_TF(name)\
+ case Opt_##name: \
+ if (opt->tf) \
+ AuLabel(name);\
+ else \
+ AuLabel(no##name);\
+ break;
+
+ /* simple true/false flag */
+ au_fsctx_TF(trunc_xino);
+ au_fsctx_TF(trunc_xib);
+#undef au_fsctx_TF
+
+ case Opt_trunc_xino_path:
+ fallthrough;
+ case Opt_itrunc_xino:
+ u.xino_itrunc = >xino_itrunc;
+ AuDbg("trunc_xino %d\n", u.xino_itrunc->bindex);
+ break;
+ case Opt_noxino:
+ AuLabel(noxino);
+ break;
/* re-commit later */
default:
@@ -78,6 +108,14 @@ static void au_fsctx_dump(struct au_opts *opts)
/* -- */
+/*
+ * For conditionally compiled mount options.
+ * Instead of fsparam_flag_no(), use this macro to distinguish ignore_silent.
+ */
+#define au_ignore_flag(name, action) \
+ fsparam_flag(name, action), \
+ fsparam_flag("no" name, Opt_ignore_silent)
+
const struct fs_parameter_spec aufs_fsctx_paramspec[] = {
fsparam_string("br", Opt_br),
@@ -92,6 +130,16 @@ const struct fs_parameter_spec aufs_fsctx_paramspec[] = {
fsparam_path("mod", Opt_mod),
/* fsparam_string("imod", Opt_imod), */
+ fsparam_path("xino", Opt_xino),
+ fsparam_flag("noxino", Opt_noxino),
+ fsparam_flag_no("trunc_xino", Opt_trunc_xino),
+ /* "trunc_xino_v=%d:%d" */
+ /* fsparam_string("trunc_xino_v", Opt_trunc_xino_v), */
+ fsparam_path("trunc_xino", Opt_trunc_xino_path),
+ fsparam_s32("itrunc_xino", Opt_itrunc_xino),
+ /* fsparam_path("zxino", Opt_zxino), */
+ fsparam_flag_no("trunc_xib", Opt_trunc_xib),
+
/* re-commit later */
{}
};
@@ -318,6 +366,108 @@ static int au_fsctx_parse_imod(struct fs_context *fc,
struct au_opt_mod *mod,
}
#endif
+static int au_fsctx_parse_xino(struct fs_context *fc,
+ struct au_opt_xino *xino,
+ struct fs_parameter *param)
+{
+ int err;
+ struct au_fsctx_opts *a = fc->fs_private;
+
+ err = -ENOMEM;
+ /* will be freed by au_opts_free() */
+ xino->path = kmemdup_nul(param->string, param->size, GFP_NOFS);
+ if (unlikely(!xino->path))
+ goto out;
+ AuDbg("path %s\n", xino->path);
+
+ xino->file = au_xino_create(a->sb, xino->path, /*silent*/0,
+ /*wbrtop*/0);
+ err = PTR_ERR(xino->file);
+ if (IS_ERR(xino->file)) {
+ xino->file = NULL;
+ goto out;
+ }
[linux-yocto] [PATCH 07/21] aufs: 5.15.5-20211129 ---> 5.15.5-20220117
Corresponds to:
commit 17dd5444ac51cc6f10ff4af464bf3392a8a52b79 (HEAD)
Author: J. R. Okajima
Date: Wed Jan 12 01:38:48 2022 +0900
5.15.5 20220117
in https://github.com/sfjro/aufs5-standalone.git
which via "git log --oneline --no-merges aufs5.15.5" encapsulates:
17dd5444ac51 5.15.5 20220117
b043ceba31e2 aufs: update the donators list
fcc56866b84d 5.15.5 20211129
Signed-off-by: Paul Gortmaker
---
Documentation/filesystems/aufs/README | 2 +-
include/uapi/linux/aufs_type.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/filesystems/aufs/README
b/Documentation/filesystems/aufs/README
index d08a56444e22..9c05340b9dda 100644
--- a/Documentation/filesystems/aufs/README
+++ b/Documentation/filesystems/aufs/README
@@ -369,7 +369,7 @@ lauri kasvandik made a donation (2013/5).
The Parted Magic Project made a donation (2013/9 and 11).
Pavel Barta made a donation (2013/10).
Nikolay Pertsev made a donation (2014/5).
-James B made a donation (2014/7 and 2015/7).
+James B made a donation (2014/7, 2015/7, and 2021/12).
Stefano Di Biase made a donation (2014/8).
Daniel Epellei made a donation (2015/1).
OmegaPhil made a donation (2016/1, 2018/4).
diff --git a/include/uapi/linux/aufs_type.h b/include/uapi/linux/aufs_type.h
index 5219a4d117b3..4b51ea9f14b4 100644
--- a/include/uapi/linux/aufs_type.h
+++ b/include/uapi/linux/aufs_type.h
@@ -40,7 +40,7 @@
#include
#endif /* __KERNEL__ */
-#define AUFS_VERSION "5.15.5-20211129"
+#define AUFS_VERSION "5.15.5-20220117"
/* todo? move this to linux-2.6.19/include/magic.h */
#define AUFS_SUPER_MAGIC ('a' << 24 | 'u' << 16 | 'f' << 8 | 's')
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11070):
https://lists.yoctoproject.org/g/linux-yocto/message/11070
Mute This Topic: https://lists.yoctoproject.org/mt/9700/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 10/21] aufs: pre fs_context, convert a static flag to a macro
From: "J. R. Okajima"
commit b8aa569c2ea55f158a9b0824c8dff1bd7fbb8e61 aufs5-standalone upstream.
This series "pre fs_context" prepares for the succeeding series
"fs_context" which makes aufs supports new fsopen/fsconfig/fsmount
systemcalls.
The commit itself is less meaningful and never affect the behaviour.
Signed-off-by: J. R. Okajima
Signed-off-by: Paul Gortmaker
---
fs/aufs/opts.c | 11 ---
fs/aufs/opts.h | 3 +++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/aufs/opts.c b/fs/aufs/opts.c
index 019a6c7aa8d2..b5dde6856069 100644
--- a/fs/aufs/opts.c
+++ b/fs/aufs/opts.c
@@ -20,7 +20,6 @@
* mount options/flags
*/
-#include
#include /* a distribution requires */
#include
#include "aufs.h"
@@ -552,8 +551,6 @@ const char *au_optstr_wbr_copyup(int wbr_copyup)
/* -- */
-static const int lkup_dirflags = LOOKUP_FOLLOW | LOOKUP_DIRECTORY;
-
static void dump_opts(struct au_opts *opts)
{
#ifdef CONFIG_AUFS_DEBUG
@@ -796,7 +793,7 @@ static int opt_add(struct au_opt *opt, char *opt_str,
unsigned long sb_flags,
add->perm = br_perm_val(p);
}
- err = vfsub_kern_path(add->pathname, lkup_dirflags, >path);
+ err = vfsub_kern_path(add->pathname, AuOpt_LkupDirFlags, >path);
if (!err) {
if (!p) {
add->perm = AuBrPerm_RO;
@@ -822,7 +819,7 @@ static int au_opts_parse_del(struct au_opt_del *del,
substring_t args[])
del->pathname = args[0].from;
AuDbg("del path %s\n", del->pathname);
- err = vfsub_kern_path(del->pathname, lkup_dirflags, >h_path);
+ err = vfsub_kern_path(del->pathname, AuOpt_LkupDirFlags, >h_path);
if (unlikely(err))
pr_err("lookup failed %s (%d)\n", del->pathname, err);
@@ -870,7 +867,7 @@ au_opts_parse_mod(struct au_opt_mod *mod, substring_t
args[])
}
*p++ = 0;
- err = vfsub_kern_path(mod->path, lkup_dirflags, );
+ err = vfsub_kern_path(mod->path, AuOpt_LkupDirFlags, );
if (unlikely(err)) {
pr_err("lookup failed %s (%d)\n", mod->path, err);
goto out;
@@ -948,7 +945,7 @@ au_opts_parse_xino_itrunc_path(struct super_block *sb,
struct path path;
struct dentry *root;
- err = vfsub_kern_path(args[0].from, lkup_dirflags, );
+ err = vfsub_kern_path(args[0].from, AuOpt_LkupDirFlags, );
if (unlikely(err)) {
pr_err("lookup failed %s (%d)\n", args[0].from, err);
goto out;
diff --git a/fs/aufs/opts.h b/fs/aufs/opts.h
index 960bce3ca2f2..98486c6b6579 100644
--- a/fs/aufs/opts.h
+++ b/fs/aufs/opts.h
@@ -25,6 +25,7 @@
#ifdef __KERNEL__
+#include
#include
struct file;
@@ -72,6 +73,8 @@ struct file;
| AuOpt_UDBA_REVAL \
| AuOpt_UDBA_HNOTIFY)
+#define AuOpt_LkupDirFlags (LOOKUP_FOLLOW | LOOKUP_DIRECTORY)
+
#define au_opt_test(flags, name) (flags & AuOpt_##name)
#define au_opt_set(flags, name) do { \
BUILD_BUG_ON(AuOpt_##name & AuOptMask_UDBA); \
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11071):
https://lists.yoctoproject.org/g/linux-yocto/message/11071
Mute This Topic: https://lists.yoctoproject.org/mt/9701/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 12/21] aufs: fs_context 2/7, parse "br" mount option
From: "J. R. Okajima"
commit 4fdd4d3893306b2a70f38a83c9b2e4d5b55a0796 aufs5-standalone upstream.
Adds parsing mount options as fs_context operations, which was started
by the preceding commit. This "fs_context" series essentially moves some
parts of opts.c to fsctx.c, and adjusts it to fit fs_context scheme.
No enhancements, no bugfixes.
Since some parts of opts.c are moved out, this commit makes aufs
unusable but compilable.
As a first step, we start it by "br" mount option. The other options
will follow by the succeeding commits.
Signed-off-by: J. R. Okajima
Signed-off-by: Paul Gortmaker
---
fs/aufs/fsctx.c | 223 +++-
fs/aufs/opts.c | 67 +++
fs/aufs/opts.h | 37 +++-
3 files changed, 268 insertions(+), 59 deletions(-)
diff --git a/fs/aufs/fsctx.c b/fs/aufs/fsctx.c
index f02cc9005d95..92ead39cbbaa 100644
--- a/fs/aufs/fsctx.c
+++ b/fs/aufs/fsctx.c
@@ -11,12 +11,227 @@
#include "aufs.h"
struct au_fsctx_opts {
+ aufs_bindex_t bindex;
+ unsigned char skipped;
struct au_opt *opt, *opt_tail;
struct super_block *sb;
struct au_sbinfo *sbinfo;
struct au_opts opts;
};
+static void au_fsctx_dump(struct au_opts *opts)
+{
+#ifdef CONFIG_AUFS_DEBUG
+ /* reduce stack space */
+ union {
+ struct au_opt_add *add;
+ } u;
+ struct au_opt *opt;
+
+ opt = opts->opt;
+ while (opt->type != Opt_tail) {
+ switch (opt->type) {
+ case Opt_add:
+ u.add = >add;
+ AuDbg("add {b%d, %s, 0x%x, %p}\n",
+ u.add->bindex, u.add->pathname, u.add->perm,
+ u.add->path.dentry);
+ break;
+ /* re-commit later */
+
+ default:
+ BUG();
+ }
+ opt++;
+ }
+#endif
+}
+
+/* -- */
+
+const struct fs_parameter_spec aufs_fsctx_paramspec[] = {
+ fsparam_string("br", Opt_br),
+ /* re-commit later */
+
+ {}
+};
+
+static int au_fsctx_parse_do_add(struct fs_context *fc, struct au_opt *opt,
+char *brspec, size_t speclen,
+aufs_bindex_t bindex)
+{
+ int err;
+ char *p;
+
+ AuDbg("brspec %s\n", brspec);
+
+ err = -ENOMEM;
+ if (!speclen)
+ speclen = strlen(brspec);
+ /* will be freed by au_fsctx_free() */
+ p = kmemdup_nul(brspec, speclen, GFP_NOFS);
+ if (unlikely(!p)) {
+ errorfc(fc, "failed in %s", brspec);
+ goto out;
+ }
+ err = au_opt_add(opt, p, fc->sb_flags, bindex);
+
+out:
+ AuTraceErr(err);
+ return err;
+}
+
+static int au_fsctx_parse_br(struct fs_context *fc, char *brspec)
+{
+ int err;
+ char *p;
+ struct au_fsctx_opts *a = fc->fs_private;
+ struct au_opt *opt = a->opt;
+ aufs_bindex_t bindex = a->bindex;
+
+ AuDbg("brspec %s\n", brspec);
+
+ err = -EINVAL;
+ while ((p = strsep(, ":")) && *p) {
+ err = au_fsctx_parse_do_add(fc, opt, p, /*len*/0, bindex);
+ AuTraceErr(err);
+ if (unlikely(err))
+ break;
+ bindex++;
+ opt++;
+ if (unlikely(opt > a->opt_tail)) {
+ err = -E2BIG;
+ bindex--;
+ opt--;
+ break;
+ }
+ opt->type = Opt_tail;
+ a->skipped = 1;
+ }
+ a->bindex = bindex;
+ a->opt = opt;
+
+ AuTraceErr(err);
+ return err;
+}
+
+static int au_fsctx_parse_param(struct fs_context *fc, struct fs_parameter
*param)
+{
+ int err, token;
+ struct fs_parse_result result;
+ struct au_fsctx_opts *a = fc->fs_private;
+ struct au_opt *opt = a->opt;
+
+ AuDbg("fc %p, param {key %s, string %s}\n",
+ fc, param->key, param->string);
+ err = fs_parse(fc, aufs_fsctx_paramspec, param, );
+ if (unlikely(err < 0))
+ goto out;
+ token = err;
+ AuDbg("token %d, res{negated %d, uint64 %llu}\n",
+ token, result.negated, result.uint_64);
+
+ err = -EINVAL;
+ a->skipped = 0;
+ switch (token) {
+ case Opt_br:
+ err = au_fsctx_parse_br(fc, param->string);
+ break;
+ /* re-commit later */
+
+ default:
+ a->skipped = 1;
+ err = -ENOPARAM;
+ break;
+ }
+ if (unlikely(err))
+
[linux-yocto] [PATCH 09/21] aufs: pre fs_context, support the incomplete sb and sbinfo case
From: "J. R. Okajima"
commit 4a19e0b7642f1bda78be13b532f0c2eb687e291b aufs5-standalone upstream.
This series "pre fs_context" prepares for the succeeding series
"fs_context" which makes aufs supports new fsopen/fsconfig/fsmount
systemcalls.
The commit itself is less meaningful and never affect the behaviour.
This commit supports the incomplete/unfinished superblock and sbinfo,
in order to suppot the error during parse or mount phase in
fs_context.
Signed-off-by: J. R. Okajima
Signed-off-by: Paul Gortmaker
---
fs/aufs/sbinfo.c | 6 +++--
fs/aufs/super.c | 57 +++-
fs/aufs/xino.c | 2 +-
3 files changed, 42 insertions(+), 23 deletions(-)
diff --git a/fs/aufs/sbinfo.c b/fs/aufs/sbinfo.c
index 2a2b804d1029..0169428a4298 100644
--- a/fs/aufs/sbinfo.c
+++ b/fs/aufs/sbinfo.c
@@ -124,8 +124,10 @@ struct au_sbinfo *au_si_alloc(struct super_block *sb)
/* leave other members for sysaufs and si_mnt. */
sbinfo->si_sb = sb;
- sb->s_fs_info = sbinfo;
- si_pid_set(sb);
+ if (sb) {
+ sb->s_fs_info = sbinfo;
+ si_pid_set(sb);
+ }
return sbinfo; /* success */
out_br:
diff --git a/fs/aufs/super.c b/fs/aufs/super.c
index 666e1837ffbb..713d2bb7f0ad 100644
--- a/fs/aufs/super.c
+++ b/fs/aufs/super.c
@@ -923,10 +923,11 @@ static int aufs_fill_super(struct super_block *sb, void
*raw_data,
opts.max_opt = PAGE_SIZE / sizeof(*opts.opt);
opts.sb_flags = sb->s_flags;
- err = au_si_alloc(sb);
- if (unlikely(err))
+ sbinfo = au_si_alloc(sb);
+ AuDebugOn(!sbinfo);
+ err = PTR_ERR(sbinfo);
+ if (unlikely(IS_ERR(sbinfo)))
goto out_opts;
- sbinfo = au_sbi(sb);
/* all timestamps always follow the ones on the branch */
sb->s_flags |= SB_NOATIME | SB_NODIRATIME;
@@ -1013,26 +1014,42 @@ static struct dentry *aufs_mount(struct
file_system_type *fs_type, int flags,
static void aufs_kill_sb(struct super_block *sb)
{
struct au_sbinfo *sbinfo;
+ struct dentry *root;
sbinfo = au_sbi(sb);
- if (sbinfo) {
- au_sbilist_del(sb);
- aufs_write_lock(sb->s_root);
- au_fhsm_fin(sb);
- if (sbinfo->si_wbr_create_ops->fin)
- sbinfo->si_wbr_create_ops->fin(sb);
- if (au_opt_test(sbinfo->si_mntflags, UDBA_HNOTIFY)) {
- au_opt_set_udba(sbinfo->si_mntflags, UDBA_NONE);
- au_remount_refresh(sb, /*do_idop*/0);
- }
- if (au_opt_test(sbinfo->si_mntflags, PLINK))
- au_plink_put(sb, /*verbose*/1);
- au_xino_clr(sb);
- au_dr_opt_flush(sb);
- sbinfo->si_sb = NULL;
- aufs_write_unlock(sb->s_root);
- au_nwt_flush(>si_nowait);
+ if (!sbinfo)
+ goto out;
+
+ au_sbilist_del(sb);
+
+ root = sb->s_root;
+ if (root)
+ aufs_write_lock(root);
+ else
+ __si_write_lock(sb);
+
+ au_fhsm_fin(sb);
+ if (sbinfo->si_wbr_create_ops->fin)
+ sbinfo->si_wbr_create_ops->fin(sb);
+ if (au_opt_test(sbinfo->si_mntflags, UDBA_HNOTIFY)) {
+ au_opt_set_udba(sbinfo->si_mntflags, UDBA_NONE);
+ au_remount_refresh(sb, /*do_idop*/0);
}
+ if (au_opt_test(sbinfo->si_mntflags, PLINK))
+ au_plink_put(sb, /*verbose*/1);
+ au_xino_clr(sb);
+ if (root)
+ au_dr_opt_flush(sb);
+
+ if (root)
+ aufs_write_unlock(root);
+ else
+ __si_write_unlock(sb);
+
+ sbinfo->si_sb = NULL;
+ au_nwt_flush(>si_nowait);
+
+out:
kill_anon_super(sb);
}
diff --git a/fs/aufs/xino.c b/fs/aufs/xino.c
index e6683663885b..4e7e39c98edf 100644
--- a/fs/aufs/xino.c
+++ b/fs/aufs/xino.c
@@ -209,7 +209,7 @@ struct file *au_xino_create(struct super_block *sb, char
*fpath, int silent,
}
err = -EINVAL;
- if (unlikely(sb == d->d_sb)) {
+ if (unlikely(sb && sb == d->d_sb)) {
if (!silent)
pr_err("%s must be outside\n", fpath);
goto out;
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11068):
https://lists.yoctoproject.org/g/linux-yocto/message/11068
Mute This Topic: https://lists.yoctoproject.org/mt/9698/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
