* Re: new seccomp mode aims to improve performance
From: Alexei Starovoitov @ 2020-05-29 17:31 UTC (permalink / raw)
To: Kees Cook
Cc: zhujianwei (C), bpf@vger.kernel.org,
linux-security-module@vger.kernel.org, Hehuazhen
In-Reply-To: <202005290903.11E67AB0FD@keescook>
On Fri, May 29, 2020 at 9:09 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 29, 2020 at 08:43:56AM -0700, Alexei Starovoitov wrote:
> > On Fri, May 29, 2020 at 5:50 AM zhujianwei (C) <zhujianwei7@huawei.com> wrote:
> > >
> > > Hi, all
> > >
> > > We're using seccomp to increase container security, but bpf rules filter causes performance to deteriorate. So, is there a good solution to improve performance, or can we add a simplified seccomp mode to improve performance?
>
> Yes, there are already plans for a simple syscall bitmap[1] seccomp feature.
>
> > I don't think your hunch at where cpu is spending cycles is correct.
> > Could you please do two experiments:
> > 1. try trivial seccomp bpf prog that simply returns 'allow'
> > 2. replace bpf_prog_run_pin_on_cpu() in seccomp.c with C code
> > that returns 'allow' and make sure it's noinline or in a different C file,
> > so that compiler doesn't optimize the whole seccomp_run_filters() into a nop.
> >
> > Then measure performance of both.
> > I bet you'll see exactly the same numbers.
>
> Android has already done this, it appeared to not be the same. Calling
> into a SECCOMP_RET_ALLOW filter had a surprisingly high cost. I'll see
> if I can get you the numbers. I was frankly quite surprised -- I
> understood the bulk of the seccomp overhead to be in taking the TIF_WORK
> path, copying arguments, etc, but something else is going on there.
Kees,
Please show the numbers that prove your point.
I've seen people making this mistake over and over again.
Intel folks also said that calling into bpf is slow only to be proved wrong.
It turned out to be the cost of retpoline and bpf_dispatcher logic resolved it.
^ permalink raw reply
* Re: [PATCH] wlcore: fix runtime pm imbalance in wl1271_tx_work
From: Kalle Valo @ 2020-05-29 17:31 UTC (permalink / raw)
To: Dinghao Liu
Cc: dinghao.liu, kjlu, David S. Miller, Jakub Kicinski,
Thomas Gleixner, Arnd Bergmann, Greg Kroah-Hartman,
Allison Randal, Alexios Zavras, Jason A. Donenfeld,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20200520124241.9931-1-dinghao.liu@zju.edu.cn>
Dinghao Liu <dinghao.liu@zju.edu.cn> wrote:
> There are two error handling paths in this functon. When
> wlcore_tx_work_locked() returns an error code, we should
> decrease the runtime PM usage counter the same way as the
> error handling path beginning from pm_runtime_get_sync().
>
> Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
> Acked-by: Tony Lindgren <tony@atomide.com>
Patch applied to wireless-drivers-next.git, thanks.
9604617e998b wlcore: fix runtime pm imbalance in wl1271_tx_work
--
https://patchwork.kernel.org/patch/11560387/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v4 05/11] thermal: remove get_mode() operation of drivers
From: Andrzej Pietrasiewicz @ 2020-05-29 17:22 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-pm, linux-acpi, netdev, linux-wireless, platform-driver-x86,
linux-arm-kernel, linux-renesas-soc, linux-rockchip,
Emmanuel Grumbach, Heiko Stuebner, Rafael J . Wysocki,
Vishal Kulkarni, Luca Coelho, Miquel Raynal, kernel,
Fabio Estevam, Amit Kucheria, Chunyan Zhang, Daniel Lezcano,
Allison Randal, NXP Linux Team, Darren Hart, Zhang Rui,
Gayatri Kammela, Len Brown, Johannes Berg, Intel Linux Wireless,
Sascha Hauer, Ido Schimmel, Baolin Wang, Jiri Pirko, Orson Zhai,
Thomas Gleixner, Kalle Valo, Support Opensource, Enrico Weigelt,
Peter Kaestle, Sebastian Reichel, Bartlomiej Zolnierkiewicz,
Pengutronix Kernel Team, Niklas Söderlund, Shawn Guo,
David S . Miller, Andy Shevchenko
In-Reply-To: <20200529154910.GA158174@roeck-us.net>
Hi Guenter,
W dniu 29.05.2020 o 17:49, Guenter Roeck pisze:
> On Thu, May 28, 2020 at 09:20:45PM +0200, Andrzej Pietrasiewicz wrote:
>> get_mode() is now redundant, as the state is stored in struct
>> thermal_zone_device.
>>
>> Consequently the "mode" attribute in sysfs can always be visible, because
>> it is always possible to get the mode from struct tzd.
>>
>> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
>
> There is a slight semantic change for the two drivers which still have
> a local copy of enum thermal_device_mode: Previously trying to read the
> mode for those would return -EPERM since they don't have a get_mode
> function. Now the global value for mode is returned, but I am not sure
> if it matches the local value.
Please see my replies to your comment about patch 4/11.
Regards,
Andrzej
^ permalink raw reply
* Re: [PATCH] efi: Replace zero-length array and use struct_size() helper
From: Gustavo A. R. Silva @ 2020-05-29 17:37 UTC (permalink / raw)
To: Kees Cook; +Cc: Ard Biesheuvel, linux-efi, linux-kernel, Gustavo A. R. Silva
In-Reply-To: <202005290131.4B104937C@keescook>
On Fri, May 29, 2020 at 01:31:54AM -0700, Kees Cook wrote:
> On Wed, May 27, 2020 at 12:14:25PM -0500, Gustavo A. R. Silva wrote:
> > The current codebase makes use of the zero-length array language
> > extension to the C90 standard, but the preferred mechanism to declare
> > variable-length types such as these ones is a flexible array member[1][2],
> > introduced in C99:
> >
> > struct foo {
> > int stuff;
> > struct boo array[];
> > };
> >
> > By making use of the mechanism above, we will get a compiler warning
> > in case the flexible array does not occur last in the structure, which
> > will help us prevent some kind of undefined behavior bugs from being
> > inadvertently introduced[3] to the codebase from now on.
> >
> > Also, notice that, dynamic memory allocations won't be affected by
> > this change:
> >
> > "Flexible array members have incomplete type, and so the sizeof operator
> > may not be applied. As a quirk of the original implementation of
> > zero-length arrays, sizeof evaluates to zero."[1]
> >
> > sizeof(flexible-array-member) triggers a warning because flexible array
> > members have incomplete type[1]. There are some instances of code in
> > which the sizeof operator is being incorrectly/erroneously applied to
> > zero-length arrays and the result is zero. Such instances may be hiding
> > some bugs. So, this work (flexible-array member conversions) will also
> > help to get completely rid of those sorts of issues.
> >
> > Lastly, make use of the sizeof_field() helper instead of an open-coded
> > version.
> >
> > This issue was found with the help of Coccinelle and audited _manually_.
> >
> > [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> > [2] https://github.com/KSPP/linux/issues/21
> > [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
> >
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
>
> Reviewed-by: Kees Cook <keescook@chromium.org>
>
Thanks :)
Please, see more comments below...
> > ---
> > drivers/firmware/efi/efi.c | 3 ++-
> > include/linux/efi.h | 7 ++-----
> > 2 files changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index 7f1657b6c30df..edc5d36caf54e 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -622,7 +622,8 @@ int __init efi_config_parse_tables(const efi_config_table_t *config_tables,
> > rsv = (void *)(p + prsv % PAGE_SIZE);
> >
> > /* reserve the entry itself */
> > - memblock_reserve(prsv, EFI_MEMRESERVE_SIZE(rsv->size));
> > + memblock_reserve(prsv,
> > + struct_size(rsv, entry, rsv->size));
> >
> > for (i = 0; i < atomic_read(&rsv->count); i++) {
> > memblock_reserve(rsv->entry[i].base,
> > diff --git a/include/linux/efi.h b/include/linux/efi.h
> > index c45ac969ea4eb..328cc52a5fd45 100644
> > --- a/include/linux/efi.h
> > +++ b/include/linux/efi.h
> > @@ -1234,14 +1234,11 @@ struct linux_efi_memreserve {
> > struct {
> > phys_addr_t base;
> > phys_addr_t size;
> > - } entry[0];
> > + } entry[];
> > };
> >
> > -#define EFI_MEMRESERVE_SIZE(count) (sizeof(struct linux_efi_memreserve) + \
> > - (count) * sizeof(((struct linux_efi_memreserve *)0)->entry[0]))
> > -
> > #define EFI_MEMRESERVE_COUNT(size) (((size) - sizeof(struct linux_efi_memreserve)) \
> > - / sizeof(((struct linux_efi_memreserve *)0)->entry[0]))
> > + / sizeof_field(struct linux_efi_memreserve, entry[0]))
>
> Whoa. This is kind of a "reverse struct_size()". I wonder if any other
> places in the kernel do a similar calculation?
>
So far this is the only intance of this I've run into.
What I've found is that there are many instances of the open-coded
version of sizeof_field() and offsetof(). I'm addressing them on the
way.
Thanks
--
Gustavo
^ permalink raw reply
* Re: general protection fault in inet_unhash
From: Eric Dumazet @ 2020-05-29 17:32 UTC (permalink / raw)
To: Andrii Nakryiko, Dmitry Vyukov
Cc: syzbot, Alexei Starovoitov, David Miller, guro, kuba,
Alexey Kuznetsov, LKML, netdev, syzkaller-bugs, Hideaki YOSHIFUJI,
Eric Dumazet
In-Reply-To: <da6dd6d1-8ed9-605c-887f-a956780fc48d@fb.com>
On 5/28/20 11:32 PM, Andrii Nakryiko wrote:
> On 5/28/20 11:23 PM, Dmitry Vyukov wrote:
>> On Thu, May 28, 2020 at 11:01 PM 'Andrii Nakryiko' via syzkaller-bugs
>> <syzkaller-bugs@googlegroups.com> wrote:
>>>
>>> On 5/28/20 9:44 AM, syzbot wrote:
>>>> Hello,
>>>>
>>>> syzbot found the following crash on:
>>>>
>>>> HEAD commit: dc0f3ed1 net: phy: at803x: add cable diagnostics support f..
>>>> git tree: net-next
>>>> console output: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_log.txt-3Fx-3D17289cd2100000&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=vxqvl81C2rT6GOGdPyz8iQ&m=sMAtpavBBjBzFzT0V8c6FcH8cu2M9da3ZozO5Lc8do0&s=t1v5ZakZM9Aw_9u_I6FbFZ28U0GFs0e9dMMUOyiDxO4&e=
>>>> kernel config: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_.config-3Fx-3D7e1bc97341edbea6&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=vxqvl81C2rT6GOGdPyz8iQ&m=sMAtpavBBjBzFzT0V8c6FcH8cu2M9da3ZozO5Lc8do0&s=yeXCTODuJF6ExmCJ-ppqMHsfvMCbCQ9zkmZi3W6NGHo&e=
>>>> dashboard link: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_bug-3Fextid-3D3610d489778b57cc8031&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=vxqvl81C2rT6GOGdPyz8iQ&m=sMAtpavBBjBzFzT0V8c6FcH8cu2M9da3ZozO5Lc8do0&s=8fAJHh81yojiinnGJzTw6hN4w4A6XRZST4463CWL9Y8&e=
>>>> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>>>> syz repro: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_repro.syz-3Fx-3D15f237aa100000&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=vxqvl81C2rT6GOGdPyz8iQ&m=sMAtpavBBjBzFzT0V8c6FcH8cu2M9da3ZozO5Lc8do0&s=cPv-hQsGYs0CVz3I26BmauS0hQ8_YTWHeH5p-U5ElWY&e=
>>>> C reproducer: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_repro.c-3Fx-3D1553834a100000&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=vxqvl81C2rT6GOGdPyz8iQ&m=sMAtpavBBjBzFzT0V8c6FcH8cu2M9da3ZozO5Lc8do0&s=r6sGJDOgosZDE9sRxqFnVibDNJFt_6IteSWeqEQLbNE&e=
>>>>
>>>> The bug was bisected to:
>>>>
>>>> commit af6eea57437a830293eab56246b6025cc7d46ee7
>>>> Author: Andrii Nakryiko <andriin@fb.com>
>>>> Date: Mon Mar 30 02:59:58 2020 +0000
>>>>
>>>> bpf: Implement bpf_link-based cgroup BPF program attachment
>>>>
>>>> bisection log: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_bisect.txt-3Fx-3D1173cd7e100000&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=vxqvl81C2rT6GOGdPyz8iQ&m=sMAtpavBBjBzFzT0V8c6FcH8cu2M9da3ZozO5Lc8do0&s=rJIpYFSAMRfea3349dd7PhmLD_hriVwq8ZtTHcSagBA&e=
>>>> final crash: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_report.txt-3Fx-3D1373cd7e100000&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=vxqvl81C2rT6GOGdPyz8iQ&m=sMAtpavBBjBzFzT0V8c6FcH8cu2M9da3ZozO5Lc8do0&s=TWpx5JNdxKiKPABUScn8WB7u3fXueCp7BXwQHg4Unz0&e=
>>>> console output: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_log.txt-3Fx-3D1573cd7e100000&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=vxqvl81C2rT6GOGdPyz8iQ&m=sMAtpavBBjBzFzT0V8c6FcH8cu2M9da3ZozO5Lc8do0&s=-SMhn-dVZI4W51EZQ8Im0sdThgwt9M6fxUt3_bcYvk8&e=
>>>>
>>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>>> Reported-by: syzbot+3610d489778b57cc8031@syzkaller.appspotmail.com
>>>> Fixes: af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment")
>>>>
>>>> general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN
>>>> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
>>>> CPU: 0 PID: 7063 Comm: syz-executor654 Not tainted 5.7.0-rc6-syzkaller #0
>>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>>>> RIP: 0010:inet_unhash+0x11f/0x770 net/ipv4/inet_hashtables.c:600
>>>
>>> No idea why it was bisected to bpf_link change. It seems completely
>>> struct sock-related. Seems like
>>
>> Hi Andrii,
>>
>> You can always find a detailed explanation of syzbot bisections under
>> the "bisection log" link.
>
> Right. Sorry, I didn't mean that bisect went wrong or anything like that. I just don't see how my change has anything to do with invalid socket state. As I just replied in another email, this particular repro is using bpf_link_create() for cgroup attachment, which was added in my patch. So running repro before my patch would always fail to attach BPF program, and thus won't be able to repro the issue (because the bug is somewhere in the interaction between BPF program attachment and socket itself). So it will always bisect to my patch :)
L2TP seems to use sk->sk_node to insert sockets into l2tp_ip_table, _and_ uses l2tp_ip_prot.unhash == inet_unhash
So if/when BPF_CGROUP_RUN_PROG_INET_SOCK(sk) returns an error and inet_create() calls sk_common_release()
bad things happen, because inet_unhash() expects a valid hashinfo pointer.
I guess the following patch should fix this.
Bug has been there forever, but only BPF_CGROUP_RUN_PROG_INET_SOCK(sk) could trigger it.
diff --git a/net/l2tp/l2tp_core.h b/net/l2tp/l2tp_core.h
index 10cf7c3dcbb3fb1b27657588f3d1ba806cba737f..097c80c0e323777df997a189eb456e3ae6d26888 100644
--- a/net/l2tp/l2tp_core.h
+++ b/net/l2tp/l2tp_core.h
@@ -231,6 +231,7 @@ int l2tp_nl_register_ops(enum l2tp_pwtype pw_type,
const struct l2tp_nl_cmd_ops *ops);
void l2tp_nl_unregister_ops(enum l2tp_pwtype pw_type);
int l2tp_ioctl(struct sock *sk, int cmd, unsigned long arg);
+void l2tp_unhash(struct sock *sk);
static inline void l2tp_tunnel_inc_refcount(struct l2tp_tunnel *tunnel)
{
diff --git a/net/l2tp/l2tp_ip.c b/net/l2tp/l2tp_ip.c
index 0d7c887a2b75db65afba7955a2bf9572a6a37786..461bffa534a039410070834ac6144c23239a27bb 100644
--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -221,6 +221,16 @@ static int l2tp_ip_open(struct sock *sk)
return 0;
}
+void l2tp_unhash(struct sock *sk)
+{
+ if (sk_unhashed(sk))
+ return;
+ write_lock_bh(&l2tp_ip_lock);
+ sk_del_node_init(sk);
+ write_unlock_bh(&l2tp_ip_lock);
+}
+EXPORT_SYMBOL(l2tp_unhash);
+
static void l2tp_ip_close(struct sock *sk, long timeout)
{
write_lock_bh(&l2tp_ip_lock);
@@ -595,7 +605,7 @@ static struct proto l2tp_ip_prot = {
.recvmsg = l2tp_ip_recvmsg,
.backlog_rcv = l2tp_ip_backlog_recv,
.hash = inet_hash,
- .unhash = inet_unhash,
+ .unhash = l2tp_unhash,
.obj_size = sizeof(struct l2tp_ip_sock),
#ifdef CONFIG_COMPAT
.compat_setsockopt = compat_ip_setsockopt,
diff --git a/net/l2tp/l2tp_ip6.c b/net/l2tp/l2tp_ip6.c
index d148766f40d117c50fc28092173d3686428d1dfc..1d9911937aad524c9ad5edcdf23297b81c2d0a21 100644
--- a/net/l2tp/l2tp_ip6.c
+++ b/net/l2tp/l2tp_ip6.c
@@ -729,7 +729,7 @@ static struct proto l2tp_ip6_prot = {
.recvmsg = l2tp_ip6_recvmsg,
.backlog_rcv = l2tp_ip6_backlog_recv,
.hash = inet6_hash,
- .unhash = inet_unhash,
+ .unhash = l2tp_unhash,
.obj_size = sizeof(struct l2tp_ip6_sock),
#ifdef CONFIG_COMPAT
.compat_setsockopt = compat_ipv6_setsockopt,
>
>>
>>> struct inet_hashinfo *hashinfo = sk->sk_prot->h.hashinfo;
>>>
>>> ends up being NULL.
>>>
>>> Can some more networking-savvy people help with investigating this, please?
>>>
>>>> Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e dd 04 00 00 48 8d 7d 08 44 8b 73 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 55 05 00 00 48 8d 7d 14 4c 8b 6d 08 48 b8 00 00
>>>> RSP: 0018:ffffc90001777d30 EFLAGS: 00010202
>>>> RAX: dffffc0000000000 RBX: ffff88809a6df940 RCX: ffffffff8697c242
>>>> RDX: 0000000000000001 RSI: ffffffff8697c251 RDI: 0000000000000008
>>>> RBP: 0000000000000000 R08: ffff88809f3ae1c0 R09: fffffbfff1514cc1
>>>> R10: ffffffff8a8a6607 R11: fffffbfff1514cc0 R12: ffff88809a6df9b0
>>>> R13: 0000000000000007 R14: 0000000000000000 R15: ffffffff873a4d00
>>>> FS: 0000000001d2b880(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>> CR2: 00000000006cd090 CR3: 000000009403a000 CR4: 00000000001406f0
>>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>>>> Call Trace:
>>>> sk_common_release+0xba/0x370 net/core/sock.c:3210
>>>> inet_create net/ipv4/af_inet.c:390 [inline]
>>>> inet_create+0x966/0xe00 net/ipv4/af_inet.c:248
>>>> __sock_create+0x3cb/0x730 net/socket.c:1428
>>>> sock_create net/socket.c:1479 [inline]
>>>> __sys_socket+0xef/0x200 net/socket.c:1521
>>>> __do_sys_socket net/socket.c:1530 [inline]
>>>> __se_sys_socket net/socket.c:1528 [inline]
>>>> __x64_sys_socket+0x6f/0xb0 net/socket.c:1528
>>>> do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
>>>> entry_SYSCALL_64_after_hwframe+0x49/0xb3
>>>> RIP: 0033:0x441e29
>>>> Code: e8 fc b3 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
>>>> RSP: 002b:00007ffdce184148 EFLAGS: 00000246 ORIG_RAX: 0000000000000029
>>>> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000441e29
>>>> RDX: 0000000000000073 RSI: 0000000000000002 RDI: 0000000000000002
>>>> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
>>>> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
>>>> R13: 0000000000402c30 R14: 0000000000000000 R15: 0000000000000000
>>>> Modules linked in:
>>>> ---[ end trace 23b6578228ce553e ]---
>>>> RIP: 0010:inet_unhash+0x11f/0x770 net/ipv4/inet_hashtables.c:600
>>>> Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e dd 04 00 00 48 8d 7d 08 44 8b 73 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 55 05 00 00 48 8d 7d 14 4c 8b 6d 08 48 b8 00 00
>>>> RSP: 0018:ffffc90001777d30 EFLAGS: 00010202
>>>> RAX: dffffc0000000000 RBX: ffff88809a6df940 RCX: ffffffff8697c242
>>>> RDX: 0000000000000001 RSI: ffffffff8697c251 RDI: 0000000000000008
>>>> RBP: 0000000000000000 R08: ffff88809f3ae1c0 R09: fffffbfff1514cc1
>>>> R10: ffffffff8a8a6607 R11: fffffbfff1514cc0 R12: ffff88809a6df9b0
>>>> R13: 0000000000000007 R14: 0000000000000000 R15: ffffffff873a4d00
>>>> FS: 0000000001d2b880(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>> CR2: 00000000006cd090 CR3: 000000009403a000 CR4: 00000000001406f0
>>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>>>>
>>>>
>>>> ---
>>>> This bug is generated by a bot. It may contain errors.
>>>> See https://urldefense.proofpoint.com/v2/url?u=https-3A__goo.gl_tpsmEJ&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=vxqvl81C2rT6GOGdPyz8iQ&m=sMAtpavBBjBzFzT0V8c6FcH8cu2M9da3ZozO5Lc8do0&s=NELwknC4AyuWSJIHbwt_O_c0jfPc_6D9RuKHh_adQ_Y&e= for more information about syzbot.
>>>> syzbot engineers can be reached at syzkaller@googlegroups.com.
>>>>
>>>> syzbot will keep track of this bug report. See:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__goo.gl_tpsmEJ-23status&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=vxqvl81C2rT6GOGdPyz8iQ&m=sMAtpavBBjBzFzT0V8c6FcH8cu2M9da3ZozO5Lc8do0&s=YfV-e6A04EIqHwezxYop7CpJyhXD8DVzwTPUT0xckaM&e= for how to communicate with syzbot.
>>>> For information about bisection process see: https://urldefense.proofpoint.com/v2/url?u=https-3A__goo.gl_tpsmEJ-23bisection&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=vxqvl81C2rT6GOGdPyz8iQ&m=sMAtpavBBjBzFzT0V8c6FcH8cu2M9da3ZozO5Lc8do0&s=xOFzqI48uvECf4XFjlhNl4LBOT02lz1HlCL6MT1uMrI&e=
>>>> syzbot can test patches for this bug, for details see:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__goo.gl_tpsmEJ-23testing-2Dpatches&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=vxqvl81C2rT6GOGdPyz8iQ&m=sMAtpavBBjBzFzT0V8c6FcH8cu2M9da3ZozO5Lc8do0&s=_cj6MOAz3yNlXgjMuyRu6ZOEjRvYWEvtTd7kE46wVfo&e=
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
>>> To view this discussion on the web visit https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_syzkaller-2Dbugs_d65c8424-2De78c-2D63f9-2D3711-2D532494619dc6-2540fb.com&d=DwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=vxqvl81C2rT6GOGdPyz8iQ&m=b2VQiGg0nrxk96tqrmflMQ24DJk-MOxx4uyOs7wSUJ0&s=TYFus0Dh0-ZHiL510kJIyPOWCyX34UzLWR4QvS3r_iY&e= .
>
^ permalink raw reply related
* Re: [PATCH 0/5] libceph: support for replica reads
From: Ilya Dryomov @ 2020-05-29 17:25 UTC (permalink / raw)
To: Jason Dillaman; +Cc: ceph-devel, Jeff Layton
In-Reply-To: <CAOi1vP83RsnP7JB2VGfCZv+hwLTDuuzC1vwJpvbX84NKSTZ6jQ@mail.gmail.com>
On Fri, May 29, 2020 at 7:21 PM Ilya Dryomov <idryomov@gmail.com> wrote:
>
> On Fri, May 29, 2020 at 6:57 PM Jason Dillaman <jdillama@redhat.com> wrote:
> >
> > lgtm -- couple questions:
> >
> > 1) the client adding the options will be responsible for determining if it's safe to enable read-from-replica/balanced reads (i.e. OSDs >= octopus)?
>
> Yes, we can't easily check require_osd_release or similar in the
> kernel. This is opt-in, and I'll add a warning together with the
> description of the new options to the man page.
>
> > 2) is there a way to determine if the kernel supports the new options (or will older kernels just ignore the options w/o complaining)? i.e. can ceph-csi safely add the argument regardless?
>
> No, older kernels will error out. I think ceph-csi would handle
> this the same way ceph quotas are handled (i.e. with the list of
> known "good" kernel versions) or alternatively just attempt to map
> with and then without crush_location and read_balance=localize
^^^
Typo, read_policy=localize.
Thanks,
Ilya
^ permalink raw reply
* Re: [PATCH] ASoC: mediatek: mt6358: support DMIC one-wire mode
From: Tzung-Bi Shih @ 2020-05-29 17:26 UTC (permalink / raw)
To: Mark Brown
Cc: Jiaxin Yu, Liam Girdwood, Takashi Iwai, Matthias Brugger,
Hariprasad Kelam, ALSA development, linux-arm-kernel,
linux-mediatek, Linux Kernel Mailing List, howie.huang
In-Reply-To: <20200529130539.GK4610@sirena.org.uk>
On Fri, May 29, 2020 at 9:05 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Fri, May 29, 2020 at 07:22:43PM +0800, Tzung-Bi Shih wrote:
> > On Fri, May 29, 2020 at 7:09 PM Mark Brown <broonie@kernel.org> wrote:
>
> > > What is DMIC one wire mode? This doesn't sound like something I'd
> > > expect to vary at runtime.
>
> > It means: 1 PDM data wire carries 2 channel data (rising edge for left
> > and falling edge for right).
>
> I thought that was normal for DMICs - is this selecting between left and
> right or something?
Not sure what is the common name but use the same context here.
MT6358 accepts up to 2 PDM wires for 2 DMICs.
If one wire mode is on, MT6358 only accepts 1 PDM wire.
If one wire mode is off, MT6358 merges L/R from 2 PDM wires into 1
I2S-like to SoC.
^ permalink raw reply
* Re: [sched/fair] 0b0695f2b3: phoronix-test-suite.compress-gzip.0.seconds 19.8% regression
From: Vincent Guittot @ 2020-05-29 17:26 UTC (permalink / raw)
To: Oliver Sang
Cc: Ingo Molnar, Ben Segall, Dietmar Eggemann, Juri Lelli,
Linus Torvalds, Mel Gorman, Mike Galbraith, Peter Zijlstra,
Steven Rostedt, Thomas Gleixner, LKML, lkp, OTC LSE PnP,
Huang, Ying
In-Reply-To: <CAKfTPtD+JW-mBt20vHAwOBxo7wbYG3seAc2+t2dWkqSzxf3dSQ@mail.gmail.com>
On Mon, 25 May 2020 at 10:02, Vincent Guittot
<vincent.guittot@linaro.org> wrote:
>
> On Thu, 21 May 2020 at 10:28, Oliver Sang <oliver.sang@intel.com> wrote:
> >
> > On Wed, May 20, 2020 at 03:04:48PM +0200, Vincent Guittot wrote:
> > > On Thu, 14 May 2020 at 19:09, Vincent Guittot
> > > <vincent.guittot@linaro.org> wrote:
> > > >
> > > > Hi Oliver,
> > > >
> > > > On Thu, 14 May 2020 at 16:05, kernel test robot <oliver.sang@intel.com> wrote:
> > > > >
> > > > > Hi Vincent Guittot,
> > > > >
> > > > > Below report FYI.
> > > > > Last year, we actually reported an improvement "[sched/fair] 0b0695f2b3:
> > > > > vm-scalability.median 3.1% improvement" on link [1].
> > > > > but now we found the regression on pts.compress-gzip.
> > > > > This seems align with what showed in "[v4,00/10] sched/fair: rework the CFS
> > > > > load balance" (link [2]), where showed the reworked load balance could have
> > > > > both positive and negative effect for different test suites.
> > > >
> > > > We have tried to run all possible use cases but it's impossible to
> > > > covers all so there were a possibility that one that is not covered,
> > > > would regressed.
> > > >
> > > > > And also from link [3], the patch set risks regressions.
> > > > >
> > > > > We also confirmed this regression on another platform
> > > > > (Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz with 8G memory),
> > > > > below is the data (lower is better).
> > > > > v5.4 4.1
> > > > > fcf0553db6f4c79387864f6e4ab4a891601f395e 4.01
> > > > > 0b0695f2b34a4afa3f6e9aa1ff0e5336d8dad912 4.89
> > > > > v5.5 5.18
> > > > > v5.6 4.62
> > > > > v5.7-rc2 4.53
> > > > > v5.7-rc3 4.59
> > > > >
> > > > > It seems there are some recovery on latest kernels, but not fully back.
> > > > > We were just wondering whether you could share some lights the further works
> > > > > on the load balance after patch set [2] which could cause the performance
> > > > > change?
> > > > > And whether you have plan to refine the load balance algorithm further?
> > > >
> > > > I'm going to have a look at your regression to understand what is
> > > > going wrong and how it can be fixed
> > >
> > > I have run the benchmark on my local setups to try to reproduce the
> > > regression and I don't see the regression. But my setups are different
> > > from your so it might be a problem specific to yours
> >
> > Hi Vincent, which OS are you using? We found the regression on Clear OS,
> > but it cannot reproduce on Debian.
> > On https://www.phoronix.com/scan.php?page=article&item=mac-win-linux2018&num=5
> > it was mentioned that -
> > Gzip compression is much faster out-of-the-box on Clear Linux due to it exploiting
> > multi-threading capabilities compared to the other operating systems Gzip support.
>
> I'm using Debian, I haven't noticed it was only on Clear OS.
> I'm going to look at it. Could you send me traces in the meantime ?
I run more tests to understand the problem. Even if Clear Linux uses
multithreading, the system is not overloaded and there is a
significant amount of idle time. This means that we use the has_spare
capacity path that spreads tasks on the system. At least that is what
I have seen in the KVM image. Beside this, I think that I have been
able to reproduce the problem on my platform with debian using pigz
instead of gzip for the compress-gzip-1.2.0 test. On my platform, I
can see a difference when I enable all CPU idle states whereas there
is no performance difference when only the shallowest idle state is
enabled.
The new load balance rework is more efficient at spreading tasks on
the system and one side effect could be that there is more idle time
between tasks wake up on each CPU. As a result, CPUs have to wake up
from a deeper idle state. This could explain the +54% increase of C6
usage that is reported. Is it possible to get All C-state statistics
?
Could you run the test after disabling deep idle states like C6 and
above and check what is the difference between v5.7-rc7 and v5.4 ?
comparing fcf0553db6 ("sched/fair: Remove meaningless imbalance
calculation") and
0b0695f2b3 ("sched/fair: Rework load_balance()") is not really
useful because they are part of the same rework and should be
considered a one single change.
>
> >
> > >
> > > After analysing the benchmark, it doesn't overload the system and is
> > > mainly based on 1 main gzip thread with few others waking up and
> > > sleeping around.
> > >
> > > I thought that scheduler could be too aggressive when trying to
> > > balance the threads on your system, which could generate more task
> > > migrations and impact the performance. But this doesn't seem to be the
> > > case because perf-stat.i.cpu-migrations is -8%. On the other side, the
> > > context switch is +16% and more interestingly idle state C1E and C6
> > > usages increase more than 50%. I don't know if we can rely or this
> > > value or not but I wonder if it could be that threads are now spread
> > > on different CPUs which generates idle time on the busy CPUs but the
> > > added time to enter/leave these states hurts the performance.
> > >
> > > Could you make some traces of both kernels ? Tracing sched events
> > > should be enough to understand the behavior
> > >
> > > Regards,
> > > Vincent
> > >
> > > >
> > > > Thanks
> > > > Vincent
> > > >
> > > > > thanks
> > > > >
> > > > > [1] https://lists.01.org/hyperkitty/list/lkp@lists.01.org/thread/SANC7QLYZKUNMM6O7UNR3OAQAKS5BESE/
> > > > > [2] https://lore.kernel.org/patchwork/cover/1141687/
> > > > > [3] https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.5-Scheduler
^ permalink raw reply
* [PATCH] x86/uaccess: Remove redundant likely/unlikely annotations
From: Josh Poimboeuf @ 2020-05-29 17:25 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Christoph Hellwig, Randy Dunlap, Andrew Morton, broonie,
linux-fsdevel, linux-kernel, linux-mm, linux-next, mhocko,
mm-commits, sfr, Linus Torvalds, viro, x86, Steven Rostedt
In-Reply-To: <20200529165419.GF706460@hirez.programming.kicks-ass.net>
On Fri, May 29, 2020 at 06:54:19PM +0200, Peter Zijlstra wrote:
> On Fri, May 29, 2020 at 11:50:11AM -0500, Josh Poimboeuf wrote:
> > The nested likelys seem like overkill anyway -- user_access_begin() is
> > __always_inline and it already has unlikely(), which should be
> > propagated.
> >
> > So just remove the outer likelys?
>
> That fixes it. Ack!
If there are no objections to the patch, I can add it to my objtool-core
branch unless anybody else wants to take it. It only affects
linux-next.
---8<---
From: Josh Poimboeuf <jpoimboe@redhat.com>
Subject: [PATCH] x86/uaccess: Remove redundant likely/unlikely annotations
Since user_access_begin() already has an unlikely() annotation for its
access_ok() check, "if (likely(user_access_begin))" results in nested
likely annotations. When combined with CONFIG_TRACE_BRANCH_PROFILING,
GCC converges the error/success paths of the nested ifs, using a
register value to distinguish between them.
While the code is technically uaccess safe, it complicates the
branch-profiling generated code. It also confuses objtool, because it
doesn't do register value tracking, resulting in the following warnings:
arch/x86/lib/csum-wrappers_64.o: warning: objtool: csum_and_copy_from_user()+0x2a4: call to memset() with UACCESS enabled
arch/x86/lib/csum-wrappers_64.o: warning: objtool: csum_and_copy_to_user()+0x243: return with UACCESS enabled
The outer likely annotations aren't actually needed anyway, since the
compiler propagates the error path coldness when it inlines
user_access_begin().
Fixes: 18372ef87665 ("x86_64: csum_..._copy_..._user(): switch to unsafe_..._user()")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
arch/x86/lib/csum-wrappers_64.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/lib/csum-wrappers_64.c b/arch/x86/lib/csum-wrappers_64.c
index a12b8629206d..ee63d7576fd2 100644
--- a/arch/x86/lib/csum-wrappers_64.c
+++ b/arch/x86/lib/csum-wrappers_64.c
@@ -27,7 +27,7 @@ csum_and_copy_from_user(const void __user *src, void *dst,
might_sleep();
*errp = 0;
- if (!likely(user_access_begin(src, len)))
+ if (!user_access_begin(src, len))
goto out_err;
/*
@@ -89,7 +89,7 @@ csum_and_copy_to_user(const void *src, void __user *dst,
might_sleep();
- if (unlikely(!user_access_begin(dst, len))) {
+ if (!user_access_begin(dst, len)) {
*errp = -EFAULT;
return 0;
}
--
2.21.3
^ permalink raw reply related
* Re: [PATCH v6 00/16] spi: dw: Add generic DW DMA controller support
From: Mark Brown @ 2020-05-29 17:33 UTC (permalink / raw)
To: Serge Semin
Cc: Serge Semin, Ekaterina Skachko, Feng Tang, devicetree,
Thomas Bogendoerfer, Georgy Vlasov, Pavel Parkhomenko,
Alexey Kolotnikov, linux-spi, linux-kernel, Vadim Vlasov,
Alexey Malahov, linux-mips, Andy Shevchenko, Rob Herring,
Ramil Zaripov, Arnd Bergmann, Maxim Kaurkin
In-Reply-To: <20200529172642.hcnvyzv2ocizsvpy@mobilestation>
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
On Fri, May 29, 2020 at 08:26:42PM +0300, Serge Semin wrote:
> You must have missed the patch 16:
> 0e8332aaf059 dt-bindings: spi: Convert DW SPI binding to DT schema
> As you can see it has been acked by Rob. So you can also merge it into your
> repo. Though It has to be rebased first due to the Dinh Nguyen patches
> recently merged in. Do you want me to do the rebasing?
Please rebase. TBH I'd not noticed Rob's review so I just left it
waiting for that, there's such a huge backlog there it didn't occur to
me that it might've been reviewed.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] dt-bindings: mmc: convert arasan sdhci bindings to yaml
From: Rob Herring @ 2020-05-29 17:25 UTC (permalink / raw)
To: Wan Ahmad Zainie
Cc: ulf.hansson, adrian.hunter, michal.simek, linux-mmc, devicetree
In-Reply-To: <20200526062758.17642-4-wan.ahmad.zainie.wan.mohamad@intel.com>
On Tue, May 26, 2020 at 02:27:58PM +0800, Wan Ahmad Zainie wrote:
> Convert arasan,sdhci.txt file to yaml. The new file arasan,sdhci.yaml
> will inherit properties from mmc-controller.yaml. 'sdhci' is no longer
> a valid name for node and should be changed to 'mmc'.
>
> Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com>
> ---
> .../devicetree/bindings/mmc/arasan,sdhci.txt | 192 ------------
> .../devicetree/bindings/mmc/arasan,sdhci.yaml | 293 ++++++++++++++++++
> 2 files changed, 293 insertions(+), 192 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> create mode 100644 Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml
> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml
> new file mode 100644
> index 000000000000..927e2f13958b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml
> @@ -0,0 +1,293 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/mmc/arasan,sdhci.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Device Tree Bindings for the Arasan SDHCI Controller
> +
> +allOf:
> + - $ref: "mmc-controller.yaml#"
> +
> +maintainers:
> + - Adrian Hunter <adrian.hunter@intel.com>
> +
> +properties:
> + compatible:
> + oneOf:
> + - const: arasan,sdhci-8.9a # generic Arasan SDHCI 8.9a PHY
> + - const: arasan,sdhci-4.9a # generic Arasan SDHCI 4.9a PHY
> + - const: arasan,sdhci-5.1 # generic Arasan SDHCI 5.1 PHY
> + - items:
> + - const: rockchip,rk3399-sdhci-5.1 # rk3399 eMMC PHY
> + - const: arasan,sdhci-5.1
> + description: |
Can drop '|' as formatting isn't important.
> + For this device it is strongly suggested to include
> + arasan,soc-ctl-syscon.
> + - items:
> + - const: xlnx,zynqmp-8.9a # ZynqMP SDHCI 8.9a PHY
> + - const: arasan,sdhci-8.9a
> + description: |
> + For this device it is strongly suggested to include
> + clock-output-names and '#clock-cells'.
Sounds like a constraint. It's either optional or required though. There
is no suggested.
> + - items:
> + - const: xlnx,versal-8.9a # Versal SDHCI 8.9a PHY
> + - const: arasan,sdhci-8.9a
> + description: |
> + For this device it is strongly suggested to include
> + clock-output-names and '#clock-cells'.
> + - items:
> + - const: intel,lgm-sdhci-5.1-emmc # Intel LGM eMMC PHY
> + - const: arasan,sdhci-5.1
> + description: |
> + For this device it is strongly suggested to include
> + arasan,soc-ctl-syscon.
> + - items:
> + - const: intel,lgm-sdhci-5.1-sdxc # Intel LGM SDXC PHY
> + - const: arasan,sdhci-5.1
> + description: |
> + For this device it is strongly suggested to include
> + arasan,soc-ctl-syscon.
> + - items:
> + - const: intel,keembay-sdhci-5.1-emmc # Intel Keem Bay eMMC PHY
> + - const: arasan,sdhci-5.1
> + description: |
> + For this device it is strongly suggested to include
> + arasan,soc-ctl-syscon.
> + - const: intel,keembay-sdhci-5.1-sd # Intel Keem Bay SD controller
> + description: |
> + For this device it is strongly suggested to include
> + arasan,soc-ctl-syscon.
> + - const: intel,keembay-sdhci-5.1-sdio # Intel Keem Bay SDIO controller
> + description: |
> + For this device it is strongly suggested to include
> + arasan,soc-ctl-syscon.
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + minItems: 2
> + maxItems: 3
> +
> + clock-names:
> + minItems: 2
> + items:
> + - const: clk_xin
> + - const: clk_ahb
> + - const: gate
> +
> + interrupts:
> + maxItems: 1
> +
> + phys:
> + maxItems: 1
> +
> + phy-names:
> + const: phy_arasan
> +
> + arasan,soc-ctl-syscon:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: |
> + A phandle to a syscon device (see ../mfd/syscon.txt) used to access
> + core corecfg registers. Offsets of registers in this syscon are
> + determined based on the main compatible string for the device.
> +
> + clock-output-names:
> + description: |
> + If specified, this will be the name of the card clock which will
> + be exposed by this device. Required if '#clock-cells' is specified.
The last sentence can be a 'dependencies' schema.
Are there defined names for this?
> +
> + '#clock-cells':
> + enum: [0, 1]
> + description: |
> + With this property in place we will export one or two clocks
> + representing the Card Clock. These clocks are expected to be
> + consumed by our PHY.
> +
> + xlnx,fails-without-test-cd:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: |
> + When present, the controller doesn't work when the CD line is not
> + connected properly, and the line is not connected properly.
> + Test mode can be used to force the controller to function.
> +
> + xlnx,int-clock-stable-broken:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: |
> + When present, the controller always reports that the internal clock
> + is stable even when it is not.
> +
> + xlnx,mio-bank:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: |
> + When specified, this will indicate the MIO bank number in which
> + the command and data lines are configured. If not specified, driver
> + will assume this as 0.
default: 0
Is there a range of valid values?
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> +
> +if:
> + properties:
> + compatible:
> + contains:
> + const: arasan,sdhci-5.1
> +then:
> + required:
> + - phys
> + - phy-names
Add: unevaluatedProperties: false
> +
> +examples:
> + - |
> + mmc@e0100000 {
> + compatible = "arasan,sdhci-8.9a";
> + reg = <0xe0100000 0x1000>;
> + clock-names = "clk_xin", "clk_ahb";
> + clocks = <&clkc 21>, <&clkc 32>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 24 4>;
> + };
> +
> + - |
> + mmc@e2800000 {
> + compatible = "arasan,sdhci-5.1";
> + reg = <0xe2800000 0x1000>;
> + clock-names = "clk_xin", "clk_ahb";
> + clocks = <&cru 8>, <&cru 18>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 24 4>;
> + phys = <&emmc_phy>;
> + phy-names = "phy_arasan";
> + };
> +
> + - |
> + #include <dt-bindings/clock/rk3399-cru.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> + mmc@fe330000 {
> + compatible = "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1";
> + reg = <0x0 0xfe330000 0x0 0x10000>;
Examples default to a single cell each for size and address.
> + interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cru SCLK_EMMC>, <&cru ACLK_EMMC>;
> + clock-names = "clk_xin", "clk_ahb";
> + arasan,soc-ctl-syscon = <&grf>;
> + assigned-clocks = <&cru SCLK_EMMC>;
> + assigned-clock-rates = <200000000>;
> + clock-output-names = "emmc_cardclock";
> + phys = <&emmc_phy>;
> + phy-names = "phy_arasan";
> + #clock-cells = <0>;
> + };
> +
> + - |
> + mmc@ff160000 {
> + compatible = "xlnx,zynqmp-8.9a", "arasan,sdhci-8.9a";
> + interrupt-parent = <&gic>;
> + interrupts = <0 48 4>;
> + reg = <0x0 0xff160000 0x0 0x1000>;
Same here.
> + clocks = <&clk200>, <&clk200>;
> + clock-names = "clk_xin", "clk_ahb";
> + clock-output-names = "clk_out_sd0", "clk_in_sd0";
> + #clock-cells = <1>;
> + clk-phase-sd-hs = <63 72>;
> + };
> +
> + - |
> + mmc@f1040000 {
> + compatible = "xlnx,versal-8.9a", "arasan,sdhci-8.9a";
> + interrupt-parent = <&gic>;
> + interrupts = <0 126 4>;
> + reg = <0x0 0xf1040000 0x0 0x10000>;
> + clocks = <&clk200>, <&clk200>;
> + clock-names = "clk_xin", "clk_ahb";
> + clock-output-names = "clk_out_sd0", "clk_in_sd0";
> + #clock-cells = <1>;
> + clk-phase-sd-hs = <132>, <60>;
> + };
> +
> + - |
> + #define LGM_CLK_EMMC5
> + #define LGM_CLK_NGI
> + #define LGM_GCLK_EMMC
> + mmc@ec700000 {
> + compatible = "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1";
> + reg = <0xec700000 0x300>;
> + interrupt-parent = <&ioapic1>;
> + interrupts = <44 1>;
> + clocks = <&cgu0 LGM_CLK_EMMC5>, <&cgu0 LGM_CLK_NGI>,
> + <&cgu0 LGM_GCLK_EMMC>;
> + clock-names = "clk_xin", "clk_ahb", "gate";
> + clock-output-names = "emmc_cardclock";
> + #clock-cells = <0>;
> + phys = <&emmc_phy>;
> + phy-names = "phy_arasan";
> + arasan,soc-ctl-syscon = <&sysconf>;
> + };
> +
> + - |
> + #define LGM_CLK_SDIO
> + #define LGM_GCLK_SDXC
> + mmc@ec600000 {
> + compatible = "intel,lgm-sdhci-5.1-sdxc", "arasan,sdhci-5.1";
> + reg = <0xec600000 0x300>;
> + interrupt-parent = <&ioapic1>;
> + interrupts = <43 1>;
> + clocks = <&cgu0 LGM_CLK_SDIO>, <&cgu0 LGM_CLK_NGI>,
> + <&cgu0 LGM_GCLK_SDXC>;
> + clock-names = "clk_xin", "clk_ahb", "gate";
> + clock-output-names = "sdxc_cardclock";
> + #clock-cells = <0>;
> + phys = <&sdxc_phy>;
> + phy-names = "phy_arasan";
> + arasan,soc-ctl-syscon = <&sysconf>;
> + };
> +
> + - |
> + #define KEEM_BAY_PSS_AUX_EMMC
> + #define KEEM_BAY_PSS_EMMC
> + mmc@33000000 {
> + compatible = "intel,keembay-sdhci-5.1-emmc", "arasan,sdhci-5.1";
> + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
> + reg = <0x0 0x33000000 0x0 0x300>;
> + clock-names = "clk_xin", "clk_ahb";
> + clocks = <&scmi_clk KEEM_BAY_PSS_AUX_EMMC>,
> + <&scmi_clk KEEM_BAY_PSS_EMMC>;
> + phys = <&emmc_phy>;
> + phy-names = "phy_arasan";
> + assigned-clocks = <&scmi_clk KEEM_BAY_PSS_AUX_EMMC>;
> + assigned-clock-rates = <200000000>;
> + clock-output-names = "emmc_cardclock";
> + #clock-cells = <0>;
> + arasan,soc-ctl-syscon = <&mmc_phy_syscon>;
> + };
> +
> + - |
> + #define KEEM_BAY_PSS_AUX_SD0
> + #define KEEM_BAY_PSS_SD0
> + mmc@31000000 {
> + compatible = "intel,keembay-sdhci-5.1-sd";
> + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
> + reg = <0x0 0x31000000 0x0 0x300>;
> + clock-names = "clk_xin", "clk_ahb";
> + clocks = <&scmi_clk KEEM_BAY_PSS_AUX_SD0>,
> + <&scmi_clk KEEM_BAY_PSS_SD0>;
> + arasan,soc-ctl-syscon = <&sd0_phy_syscon>;
> + };
> +
> + - |
> + #define KEEM_BAY_PSS_AUX_SD1
> + #define KEEM_BAY_PSS_SD1
> + mmc@32000000 {
> + compatible = "intel,keembay-sdhci-5.1-sdio";
> + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
> + reg = <0x0 0x32000000 0x0 0x300>;
> + clock-names = "clk_xin", "clk_ahb";
> + clocks = <&scmi_clk KEEM_BAY_PSS_AUX_SD1>,
> + <&scmi_clk KEEM_BAY_PSS_SD1>;
> + arasan,soc-ctl-syscon = <&sd1_phy_syscon>;
> + };
Really need 3 Keem Bay examples?
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH 0/2] Fix regulators coupling for Exynos5800
From: Krzysztof Kozlowski @ 2020-05-29 17:33 UTC (permalink / raw)
To: Mark Brown
Cc: linux-pm, Dmitry Osipenko, Marek Szyprowski, linux-kernel,
Stephen Boyd, Bartlomiej Zolnierkiewicz, Viresh Kumar,
Nishanth Menon, Chanwoo Choi, linux-samsung-soc, Liam Girdwood,
Lucas Stach, peron.clem, Rafael Wysocki, Vincent Guittot
In-Reply-To: <20200529165827.GP4610@sirena.org.uk>
On Fri, May 29, 2020 at 05:58:27PM +0100, Mark Brown wrote:
> On Fri, May 29, 2020 at 05:52:15PM +0100, Mark Brown wrote:
>
> > [1/1] regulator: extract voltage balancing code to the separate function
> > commit: 752db83a5dfd4fd3a0624b9ab440ed947fa003ca
>
> Let me know if you need a pull request for this - I figured it was too
> late to apply the second patch before the merge window with the cross
> tree stuff.
Thanks, I think it will not be needed. I'll apply the second patch after
the merge window.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ALSA: Fixing usage of plain int instead of NULL
From: Thomas Ebeling @ 2020-05-29 17:32 UTC (permalink / raw)
To: alsa-devel; +Cc: Takashi Iwai
As reported by kbuild test robot, mixer quirks for RME Babyface
Pro used plain integer instead of NULL.
Signed-off-by: Thomas Ebeling <penguins@bollie.de>
Reported-by: kbuild test robot <lkp@intel.com>
---
sound/usb/mixer_quirks.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/usb/mixer_quirks.c b/sound/usb/mixer_quirks.c
index aad2683ff793..b6bcf2f92383 100644
--- a/sound/usb/mixer_quirks.c
+++ b/sound/usb/mixer_quirks.c
@@ -2255,7 +2255,7 @@ static int snd_bbfpro_ctl_update(struct usb_mixer_interface *mixer, u8 reg,
err = snd_usb_ctl_msg(chip->dev,
usb_sndctrlpipe(chip->dev, 0), usb_req,
USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- usb_val, usb_idx, 0, 0);
+ usb_val, usb_idx, NULL, 0);
snd_usb_unlock_shutdown(chip);
return err;
@@ -2394,7 +2394,7 @@ static int snd_bbfpro_vol_update(struct usb_mixer_interface *mixer, u16 index,
SND_BBFPRO_USBREQ_MIXER,
USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- usb_val, usb_idx, 0, 0);
+ usb_val, usb_idx, NULL, 0);
snd_usb_unlock_shutdown(chip);
return err;
--
2.26.2
^ permalink raw reply related
* (no subject)
From: John Paul Adrian Glaubitz @ 2020-05-29 17:34 UTC (permalink / raw)
To: linux-sh
Cc: Rich Felker, Yoshinori Sato, Geert Uytterhoeven, Michael Karcher,
linux-kernel
Hi!
This is my attempt of implementing a 64-bit get_user() for SH to address the
build problem when CONFIG_INFINIBAND_USER_ACCESS is enabled.
I have carefully looked at the existing implementations of __get_user_asm(),
__put_user_asm() and the 64-bit __put_user_u64() to come up with the 64-bit
__get_user_u64().
I'm admittedly not an expert when it comes to writing GCC contraints, so the
code might be completely wrong. However, it builds fine without warnings
and fixes the aforementioned issue for me.
Hopefully someone from the more experienced group of kernel developers can
review my code and help me get it into proper shape for submission.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* [PATCH] sh: Implement __get_user_u64() required for 64-bit get_user()
From: John Paul Adrian Glaubitz @ 2020-05-29 17:34 UTC (permalink / raw)
To: linux-sh
Cc: Rich Felker, Yoshinori Sato, Geert Uytterhoeven, Michael Karcher,
linux-kernel, John Paul Adrian Glaubitz
In-Reply-To: <20200529173419.4185337-1-glaubitz@physik.fu-berlin.de>
Trying to build the kernel with CONFIG_INFINIBAND_USER_ACCESS enabled fails
ERROR: "__get_user_unknown" [drivers/infiniband/core/ib_uverbs.ko] undefined!
with on SH since the kernel misses a 64-bit implementation of get_user().
Implement the missing 64-bit get_user() as __get_user_u64(), matching the
already existing __put_user_u64() which implements the 64-bit put_user().
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
---
arch/sh/include/asm/uaccess_32.h | 49 ++++++++++++++++++++++++++++++++
1 file changed, 49 insertions(+)
diff --git a/arch/sh/include/asm/uaccess_32.h b/arch/sh/include/asm/uaccess_32.h
index 624cf55acc27..8bc1cb50f8bf 100644
--- a/arch/sh/include/asm/uaccess_32.h
+++ b/arch/sh/include/asm/uaccess_32.h
@@ -26,6 +26,9 @@ do { \
case 4: \
__get_user_asm(x, ptr, retval, "l"); \
break; \
+ case 8: \
+ __get_user_u64(x, ptr, retval); \
+ break; \
default: \
__get_user_unknown(); \
break; \
@@ -66,6 +69,52 @@ do { \
extern void __get_user_unknown(void);
+#if defined(CONFIG_CPU_LITTLE_ENDIAN)
+#define __get_user_u64(x, addr, err) \
+({ \
+__asm__ __volatile__( \
+ "1:\n\t" \
+ "mov.l %2,%R1\n\t" \
+ "mov.l %T2,%S1\n\t" \
+ "2:\n" \
+ ".section .fixup,\"ax\"\n" \
+ "3:\n\t" \
+ "mov #0, %1\n\t" \
+ "mov.l 4f, %0\n\t" \
+ "jmp @%0\n\t" \
+ " mov %3, %0\n\t" \
+ ".balign 4\n" \
+ "4: .long 2b\n\t" \
+ ".previous\n" \
+ ".section __ex_table,\"a\"\n\t" \
+ ".long 1b, 3b\n\t" \
+ ".previous" \
+ :"=&r" (err), "=&r" (x) \
+ :"m" (__m(addr)), "i" (-EFAULT), "0" (err)); })
+#else
+#define __get_user_u64(x, addr, err) \
+({ \
+__asm__ __volatile__( \
+ "1:\n\t" \
+ "mov.l %2,%S1\n\t" \
+ "mov.l %T2,%R1\n\t" \
+ "2:\n" \
+ ".section .fixup,\"ax\"\n" \
+ "3:\n\t" \
+ "mov #0, %1\n\t" \
+ "mov.l 4f, %0\n\t" \
+ "jmp @%0\n\t" \
+ " mov %3, %0\n\t" \
+ ".balign 4\n" \
+ "4: .long 2b\n\t" \
+ ".previous\n" \
+ ".section __ex_table,\"a\"\n\t" \
+ ".long 1b, 3b\n\t" \
+ ".previous" \
+ :"=&r" (err), "=&r" (x) \
+ :"m" (__m(addr)), "i" (-EFAULT), "0" (err)); })
+#endif
+
#define __put_user_size(x,ptr,size,retval) \
do { \
retval = 0; \
--
2.27.0.rc2
^ permalink raw reply related
* Re: [PATCH] wlcore: fix runtime pm imbalance in wlcore_regdomain_config
From: Kalle Valo @ 2020-05-29 17:34 UTC (permalink / raw)
To: Dinghao Liu
Cc: dinghao.liu, kjlu, David S. Miller, Jakub Kicinski,
Thomas Gleixner, Johannes Berg, Emmanuel Grumbach, Fuqian Huang,
Jason A. Donenfeld, Tony Lindgren, Maital Hahn, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20200520124649.10848-1-dinghao.liu@zju.edu.cn>
Dinghao Liu <dinghao.liu@zju.edu.cn> wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> the call returns an error code. Thus a pairing decrement is needed
> on the error handling path to keep the counter balanced.
>
> Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
> Acked-by: Tony Lindgren <tony@atomide.com>
Patch applied to wireless-drivers-next.git, thanks.
282a04bf1d80 wlcore: fix runtime pm imbalance in wlcore_regdomain_config
--
https://patchwork.kernel.org/patch/11560391/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] wlcore: fix runtime pm imbalance in wl1271_op_suspend
From: Kalle Valo @ 2020-05-29 17:34 UTC (permalink / raw)
To: Dinghao Liu
Cc: dinghao.liu, kjlu, David S. Miller, Jakub Kicinski,
Thomas Gleixner, Johannes Berg, Greg Kroah-Hartman, Maital Hahn,
Fuqian Huang, Emmanuel Grumbach, Jason A. Donenfeld,
Tony Lindgren, linux-wireless, netdev, linux-kernel
In-Reply-To: <20200520125724.12832-1-dinghao.liu@zju.edu.cn>
Dinghao Liu <dinghao.liu@zju.edu.cn> wrote:
> When wlcore_hw_interrupt_notify() returns an error code,
> a pairing runtime PM usage counter decrement is needed to
> keep the counter balanced.
>
> Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
> Acked-by: Tony Lindgren <tony@atomide.com>
Patch applied to wireless-drivers-next.git, thanks.
3e69ed2b52fd wlcore: fix runtime pm imbalance in wl1271_op_suspend
--
https://patchwork.kernel.org/patch/11560333/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 4/6] x86/entry: Optimize local_db_save() for virt
From: Sean Christopherson @ 2020-05-29 17:24 UTC (permalink / raw)
To: Peter Zijlstra
Cc: tglx, luto, linux-kernel, x86, Lai Jiangshan, andrew.cooper3,
daniel.thompson, Andy Lutomirski
In-Reply-To: <20200528202328.588432451@infradead.org>
On Thu, May 28, 2020 at 10:19:41PM +0200, Peter Zijlstra wrote:
> static int arch_bp_generic_len(int x86_len)
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -3027,6 +3027,8 @@ static int nested_vmx_check_vmentry_hw(s
>
> /*
> * VMExit clears RFLAGS.IF and DR7, even on a consistency check.
> + * XXX how is this not broken? access to cpu_dr7 ought to be with
> + * IRQs disabled.
Ah, it's simply broken. This code is conditional on a module param that's
off by default, i.e. it's not run widely, and odds are intersection with
debugging is rare.
Moving local_irq_enable() below the DR7 restoration is not an issue.
Maybe also add lockdep_assert_irqs_disabled() to hw_breakpoint_restore() or
hw_breakpoint_active()?
> */
> local_irq_enable();
> if (hw_breakpoint_active())
>
>
^ permalink raw reply
* Re: [PATCH net-next 00/11] New DSA driver for VSC9953 Seville switch
From: Mark Brown @ 2020-05-29 17:34 UTC (permalink / raw)
To: Vladimir Oltean
Cc: David S. Miller, Russell King - ARM Linux admin, Claudiu Manoil,
Vivien Didelot, Florian Fainelli, Andrew Lunn, Allan W. Nielsen,
Antoine Tenart, netdev, fido_max, Alexandre Belloni,
radu-andrei.bulie, Horatiu Vultur, Alexandru Marginean,
Microchip Linux Driver Support, Madalin Bucur (OSS)
In-Reply-To: <CA+h21hqV5Mm=oBQ49zZFiMbg6FcopudCxowQcTwF-_O_Onj81w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 618 bytes --]
On Fri, May 29, 2020 at 08:28:01PM +0300, Vladimir Oltean wrote:
> Thanks a lot for merging this. I plan to resend this series again (on
> the last mile!) during the weekend, with the feedback collected so
> far, so I'm not sure what is the best path to make sure Dave also has
> this patch in his tree so I don't break net-next.
That was what the pull request would be for, though if you need to
resend the chances are it'll be after the merge window before it gets
applied in which case he'll get the patch through Linus' tree which
makes things easier (that was part of the reason I just went ahead and
applied).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] libceph: crush_location infrastructure
From: Jeff Layton @ 2020-05-29 17:27 UTC (permalink / raw)
To: Ilya Dryomov, ceph-devel
In-Reply-To: <20200529151952.15184-4-idryomov@gmail.com>
On Fri, 2020-05-29 at 17:19 +0200, Ilya Dryomov wrote:
> Allow expressing client's location in terms of CRUSH hierarchy as
> a set of (bucket type name, bucket name) pairs. The userspace syntax
> "crush_location = key1=value1 key2=value2" is incompatible with mount
> options and needed adaptation:
>
> - ':' separator
> - one key:value pair per crush_location option
> - crush_location options are combined together
>
> So for:
>
> crush_location = host=foo rack=bar
>
> one would write:
>
> crush_location=host:foo,crush_location=rack:bar
>
> As in userspace, "multipath" locations are supported, so indicating
> locality for parallel hierarchies is possible:
>
> crush_location=rack:foo1,crush_location=rack:foo2,crush_location=datacenter:bar
>
Blech, that syntax is hideous. It's also problematic in that the options
are additive -- you can't override an option that was given earlier
(e.g. in fstab), or in a shell script.
Is it not possible to do something with a single crush_location= option?
Maybe:
crush_location=rack:foo1/rack:foo2/datacenter:bar
It's still ugly with the embedded '=' signs, but it would at least make
it so that the options aren't additive.
> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
> ---
> include/linux/ceph/libceph.h | 1 +
> include/linux/ceph/osdmap.h | 16 ++++-
> net/ceph/ceph_common.c | 25 ++++++++
> net/ceph/osdmap.c | 114 +++++++++++++++++++++++++++++++++++
> 4 files changed, 155 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/ceph/libceph.h b/include/linux/ceph/libceph.h
> index 4b5a47bcaba4..4733959f1ec7 100644
> --- a/include/linux/ceph/libceph.h
> +++ b/include/linux/ceph/libceph.h
> @@ -64,6 +64,7 @@ struct ceph_options {
> int num_mon;
> char *name;
> struct ceph_crypto_key *key;
> + struct rb_root crush_locs;
> };
>
> /*
> diff --git a/include/linux/ceph/osdmap.h b/include/linux/ceph/osdmap.h
> index 5e601975745f..ef8619ad1401 100644
> --- a/include/linux/ceph/osdmap.h
> +++ b/include/linux/ceph/osdmap.h
> @@ -302,9 +302,23 @@ bool ceph_pg_to_primary_shard(struct ceph_osdmap *osdmap,
> int ceph_pg_to_acting_primary(struct ceph_osdmap *osdmap,
> const struct ceph_pg *raw_pgid);
>
> +struct crush_loc {
> + char *cl_type_name;
> + char *cl_name;
> +};
> +
> +struct crush_loc_node {
> + struct rb_node cl_node;
> + struct crush_loc cl_loc; /* pointers into cl_data */
> + char cl_data[];
> +};
> +
> +int ceph_parse_crush_loc(const char *str, struct rb_root *locs);
> +int ceph_compare_crush_locs(struct rb_root *locs1, struct rb_root *locs2);
> +void ceph_clear_crush_locs(struct rb_root *locs);
> +
> extern struct ceph_pg_pool_info *ceph_pg_pool_by_id(struct ceph_osdmap *map,
> u64 id);
> -
> extern const char *ceph_pg_pool_name_by_id(struct ceph_osdmap *map, u64 id);
> extern int ceph_pg_poolid_by_name(struct ceph_osdmap *map, const char *name);
> u64 ceph_pg_pool_flags(struct ceph_osdmap *map, u64 id);
> diff --git a/net/ceph/ceph_common.c b/net/ceph/ceph_common.c
> index a0e97f6c1072..6d495685ee03 100644
> --- a/net/ceph/ceph_common.c
> +++ b/net/ceph/ceph_common.c
> @@ -176,6 +176,10 @@ int ceph_compare_options(struct ceph_options *new_opt,
> }
> }
>
> + ret = ceph_compare_crush_locs(&opt1->crush_locs, &opt2->crush_locs);
> + if (ret)
> + return ret;
> +
> /* any matching mon ip implies a match */
> for (i = 0; i < opt1->num_mon; i++) {
> if (ceph_monmap_contains(client->monc.monmap,
> @@ -260,6 +264,7 @@ enum {
> Opt_secret,
> Opt_key,
> Opt_ip,
> + Opt_crush_location,
> /* string args above */
> Opt_share,
> Opt_crc,
> @@ -274,6 +279,7 @@ static const struct fs_parameter_spec ceph_parameters[] = {
> fsparam_flag_no ("cephx_require_signatures", Opt_cephx_require_signatures),
> fsparam_flag_no ("cephx_sign_messages", Opt_cephx_sign_messages),
> fsparam_flag_no ("crc", Opt_crc),
> + fsparam_string ("crush_location", Opt_crush_location),
> fsparam_string ("fsid", Opt_fsid),
> fsparam_string ("ip", Opt_ip),
> fsparam_string ("key", Opt_key),
> @@ -298,6 +304,7 @@ struct ceph_options *ceph_alloc_options(void)
> if (!opt)
> return NULL;
>
> + opt->crush_locs = RB_ROOT;
> opt->mon_addr = kcalloc(CEPH_MAX_MON, sizeof(*opt->mon_addr),
> GFP_KERNEL);
> if (!opt->mon_addr) {
> @@ -320,6 +327,7 @@ void ceph_destroy_options(struct ceph_options *opt)
> if (!opt)
> return;
>
> + ceph_clear_crush_locs(&opt->crush_locs);
> kfree(opt->name);
> if (opt->key) {
> ceph_crypto_key_destroy(opt->key);
> @@ -454,6 +462,14 @@ int ceph_parse_param(struct fs_parameter *param, struct ceph_options *opt,
> if (!opt->key)
> return -ENOMEM;
> return get_secret(opt->key, param->string, &log);
> + case Opt_crush_location:
> + err = ceph_parse_crush_loc(param->string, &opt->crush_locs);
> + if (err) {
> + error_plog(&log, "Failed to parse crush location: %d",
> + err);
> + return err;
> + }
> + break;
>
> case Opt_osdtimeout:
> warn_plog(&log, "Ignoring osdtimeout");
> @@ -536,6 +552,7 @@ int ceph_print_client_options(struct seq_file *m, struct ceph_client *client,
> {
> struct ceph_options *opt = client->options;
> size_t pos = m->count;
> + struct rb_node *n;
>
> if (opt->name) {
> seq_puts(m, "name=");
> @@ -545,6 +562,14 @@ int ceph_print_client_options(struct seq_file *m, struct ceph_client *client,
> if (opt->key)
> seq_puts(m, "secret=<hidden>,");
>
> + for (n = rb_first(&opt->crush_locs); n; n = rb_next(n)) {
> + struct crush_loc_node *loc =
> + rb_entry(n, struct crush_loc_node, cl_node);
> +
> + seq_printf(m, "crush_location=%s:%s,",
> + loc->cl_loc.cl_type_name, loc->cl_loc.cl_name);
> + }
> +
> if (opt->flags & CEPH_OPT_FSID)
> seq_printf(m, "fsid=%pU,", &opt->fsid);
> if (opt->flags & CEPH_OPT_NOSHARE)
> diff --git a/net/ceph/osdmap.c b/net/ceph/osdmap.c
> index e74130876d3a..995cdb8b559e 100644
> --- a/net/ceph/osdmap.c
> +++ b/net/ceph/osdmap.c
> @@ -2715,3 +2715,117 @@ int ceph_pg_to_acting_primary(struct ceph_osdmap *osdmap,
> return acting.primary;
> }
> EXPORT_SYMBOL(ceph_pg_to_acting_primary);
> +
> +static struct crush_loc_node *alloc_crush_loc(size_t type_name_len,
> + size_t name_len)
> +{
> + struct crush_loc_node *loc;
> +
> + loc = kmalloc(sizeof(*loc) + type_name_len + name_len + 2, GFP_NOIO);
> + if (!loc)
> + return NULL;
> +
> + RB_CLEAR_NODE(&loc->cl_node);
> + return loc;
> +}
> +
> +static void free_crush_loc(struct crush_loc_node *loc)
> +{
> + WARN_ON(!RB_EMPTY_NODE(&loc->cl_node));
> +
> + kfree(loc);
> +}
> +
> +static int crush_loc_compare(const struct crush_loc *loc1,
> + const struct crush_loc *loc2)
> +{
> + return strcmp(loc1->cl_type_name, loc2->cl_type_name) ?:
> + strcmp(loc1->cl_name, loc2->cl_name);
> +}
> +
> +DEFINE_RB_FUNCS2(crush_loc, struct crush_loc_node, cl_loc, crush_loc_compare,
> + RB_BYPTR, const struct crush_loc *, cl_node)
> +
> +/*
> + * A <bucket type name>:<bucket name> pair, e.g. "zone:us-east".
> + */
> +int ceph_parse_crush_loc(const char *str, struct rb_root *locs)
> +{
> + struct crush_loc_node *loc;
> + const char *type_name, *name;
> + size_t type_name_len, name_len;
> +
> + type_name = str;
> + str = strchrnul(str, ':');
> + if (*str == '\0')
> + return -EINVAL; /* no ':' */
> +
> + type_name_len = str - type_name;
> + if (type_name_len == 0)
> + return -EINVAL;
> +
> + name = ++str;
> + str = strchrnul(str, ':');
> + if (*str != '\0')
> + return -EINVAL; /* another ':' */
> +
> + name_len = str - name;
> + if (name_len == 0)
> + return -EINVAL;
> +
> + loc = alloc_crush_loc(type_name_len, name_len);
> + if (!loc)
> + return -ENOMEM;
> +
> + loc->cl_loc.cl_type_name = loc->cl_data;
> + memcpy(loc->cl_loc.cl_type_name, type_name, type_name_len);
> + loc->cl_loc.cl_type_name[type_name_len] = '\0';
> +
> + loc->cl_loc.cl_name = loc->cl_data + type_name_len + 1;
> + memcpy(loc->cl_loc.cl_name, name, name_len);
> + loc->cl_loc.cl_name[name_len] = '\0';
> +
> + if (!__insert_crush_loc(locs, loc)) {
> + free_crush_loc(loc);
> + return -EEXIST;
> + }
> +
> + dout("%s type_name '%s' name '%s'\n", __func__,
> + loc->cl_loc.cl_type_name, loc->cl_loc.cl_name);
> + return 0;
> +}
> +
> +int ceph_compare_crush_locs(struct rb_root *locs1, struct rb_root *locs2)
> +{
> + struct rb_node *n1 = rb_first(locs1);
> + struct rb_node *n2 = rb_first(locs2);
> + int ret;
> +
> + for ( ; n1 && n2; n1 = rb_next(n1), n2 = rb_next(n2)) {
> + struct crush_loc_node *loc1 =
> + rb_entry(n1, struct crush_loc_node, cl_node);
> + struct crush_loc_node *loc2 =
> + rb_entry(n2, struct crush_loc_node, cl_node);
> +
> + ret = crush_loc_compare(&loc1->cl_loc, &loc2->cl_loc);
> + if (ret)
> + return ret;
> + }
> +
> + if (!n1 && n2)
> + return -1;
> + if (n1 && !n2)
> + return 1;
> + return 0;
> +}
> +
> +void ceph_clear_crush_locs(struct rb_root *locs)
> +{
> + while (!RB_EMPTY_ROOT(locs)) {
> + struct crush_loc_node *loc =
> + rb_entry(rb_first(locs), struct crush_loc_node, cl_node);
> +
> + erase_crush_loc(locs, loc);
> + free_crush_loc(loc);
> + }
> +}
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets
From: Rob Herring @ 2020-05-29 17:34 UTC (permalink / raw)
To: Jim Quinlan
Cc: open list:USB SUBSYSTEM,
open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Heikki Krogerus, Srinivas Kandagatla, Frank Rowand,
Christoph Hellwig, Saravana Kannan, Rafael J. Wysocki,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, Alan Stern,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Corey Minyard,
Suzuki K Poulose, Dan Williams, Andy Shevchenko,
Greg Kroah-Hartman, Oliver Neukum, open list, Wolfram Sang,
open list:DMA MAPPING HELPERS, Robin Murphy,
Nicolas Saenz Julienne
In-Reply-To: <CA+-6iNyOKvY-xNfXqDRa5_nJVJuqGKA-oe-ejNuJHUBt6ORu0A@mail.gmail.com>
On Wed, May 27, 2020 at 9:43 AM Jim Quinlan <james.quinlan@broadcom.com> wrote:
>
> Hi Nicolas,
>
> On Wed, May 27, 2020 at 11:00 AM Nicolas Saenz Julienne
> <nsaenzjulienne@suse.de> wrote:
> >
> > Hi Jim,
> > one thing comes to mind, there is a small test suite in drivers/of/unittest.c
> > (specifically of_unittest_pci_dma_ranges()) you could extend it to include your
> > use cases.
> Sure, will check out.
> >
> > On Tue, 2020-05-26 at 15:12 -0400, Jim Quinlan wrote:
> > > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > > the use of multiple pfn offsets between cpu addrs and dma addrs. It is
> > > similar to 'dma_pfn_offset' except that the offset chosen depends on the
> > > cpu or dma address involved.
> > >
> > > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> > > ---
> > > drivers/of/address.c | 65 +++++++++++++++++++++++++++++++++++--
> > > drivers/usb/core/message.c | 3 ++
> > > drivers/usb/core/usb.c | 3 ++
> > > include/linux/device.h | 10 +++++-
> > > include/linux/dma-direct.h | 10 ++++--
> > > include/linux/dma-mapping.h | 46 ++++++++++++++++++++++++++
> > > kernel/dma/Kconfig | 13 ++++++++
> > > 7 files changed, 144 insertions(+), 6 deletions(-)
> > >
> >
> > [...]
> >
> > > @@ -977,10 +1020,19 @@ int of_dma_get_range(struct device *dev, struct
> > > device_node *np, u64 *dma_addr,
> > > pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
> > > range.bus_addr, range.cpu_addr, range.size);
> > >
> > > + num_ranges++;
> > > if (dma_offset && range.cpu_addr - range.bus_addr != dma_offset)
> > > {
> > > - pr_warn("Can't handle multiple dma-ranges with different
> > > offsets on node(%pOF)\n", node);
> > > - /* Don't error out as we'd break some existing DTs */
> > > - continue;
> > > + if (!IS_ENABLED(CONFIG_DMA_PFN_OFFSET_MAP)) {
> > > + pr_warn("Can't handle multiple dma-ranges with
> > > different offsets on node(%pOF)\n", node);
> > > + pr_warn("Perhaps set DMA_PFN_OFFSET_MAP=y?\n");
> > > + /*
> > > + * Don't error out as we'd break some existing
> > > + * DTs that are using configs w/o
> > > + * CONFIG_DMA_PFN_OFFSET_MAP set.
> > > + */
> > > + continue;
> >
> > dev->bus_dma_limit is set in of_dma_configure(), this function's caller, based
> > on dma_start's value (set after this continue). So you'd be effectively setting
> > the dev->bus_dma_limit to whatever we get from the first dma-range.
> I'm not seeing that at all. On the evaluation of each dma-range,
> dma_start and dma_end are re-evaluated to be the lowest and highest
> bus values of the dma-ranges seen so far. After all dma-ranges are
> examined, dev->bus_dma_limit being set to the highest. In fact, the
> current code -- ie before my commits -- already does this for multiple
> dma-ranges as long as the cpu-bus offset is the same in the
> dma-ranges.
> >
> > This can be troublesome depending on how the dma-ranges are setup, for example
> > if the first dma-range doesn't include the CMA area, in arm64 generally set as
> > high as possible in ZONE_DMA32, that would render it useless for
> > dma/{direct/swiotlb}. Again depending on the bus_dma_limit value, if smaller
> > than ZONE_DMA you'd be unable to allocate any DMA memory.
> >
> > IMO, a solution to this calls for a revamp of dma-direct's dma_capable(): match
> > the target DMA memory area with each dma-range we have to see if it fits.
> >
> > > + }
> > > + dma_multi_pfn_offset = true;
> > > }
> > > dma_offset = range.cpu_addr - range.bus_addr;
> > >
> > > @@ -991,6 +1043,13 @@ int of_dma_get_range(struct device *dev, struct
> > > device_node *np, u64 *dma_addr,
> > > dma_end = range.bus_addr + range.size;
> > > }
> > >
> > > + if (dma_multi_pfn_offset) {
> > > + dma_offset = 0;
> > > + ret = attach_dma_pfn_offset_map(dev, node, num_ranges);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > +
> > > if (dma_start >= dma_end) {
> > > ret = -EINVAL;
> > > pr_debug("Invalid DMA ranges configuration on node(%pOF)\n",
> > > diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> > > index 6197938dcc2d..aaa3e58f5eb4 100644
> > > --- a/drivers/usb/core/message.c
> > > +++ b/drivers/usb/core/message.c
> > > @@ -1960,6 +1960,9 @@ int usb_set_configuration(struct usb_device *dev, int
> > > configuration)
> > > */
> > > intf->dev.dma_mask = dev->dev.dma_mask;
> > > intf->dev.dma_pfn_offset = dev->dev.dma_pfn_offset;
> > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > > + intf->dev.dma_pfn_offset_map = dev->dev.dma_pfn_offset_map;
> > > +#endif
> >
> > Thanks for looking at this, that said, I see more instances of drivers changing
> > dma_pfn_offset outside of the core code. Why not doing this there too?
> >
> > Also, are we 100% sure that dev->dev.dma_pfn_offset isn't going to be freed
> > before we're done using intf->dev? Maybe it's safer to copy the ranges?
> >
> > > INIT_WORK(&intf->reset_ws, __usb_queue_reset_device);
> > > intf->minor = -1;
> > > device_initialize(&intf->dev);
> > > diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> > > index f16c26dc079d..d2ed4d90e56e 100644
> > > --- a/drivers/usb/core/usb.c
> > > +++ b/drivers/usb/core/usb.c
> > > @@ -612,6 +612,9 @@ struct usb_device *usb_alloc_dev(struct usb_device
> > > *parent,
> > > */
> > > dev->dev.dma_mask = bus->sysdev->dma_mask;
> > > dev->dev.dma_pfn_offset = bus->sysdev->dma_pfn_offset;
> > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > > + dev->dev.dma_pfn_offset_map = bus->sysdev->dma_pfn_offset_map;
> > > +#endif
> > > set_dev_node(&dev->dev, dev_to_node(bus->sysdev));
> > > dev->state = USB_STATE_ATTACHED;
> > > dev->lpm_disable_count = 1;
> > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > index ac8e37cd716a..67a240ad4fc5 100644
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -493,6 +493,8 @@ struct dev_links_info {
> > > * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
> > > * DMA limit than the device itself supports.
> > > * @dma_pfn_offset: offset of DMA memory range relatively of RAM
> > > + * @dma_pfn_offset_map: Like dma_pfn_offset but used when there are
> > > multiple
> > > + * pfn offsets for multiple dma-ranges.
> > > * @dma_parms: A low level driver may set these to teach IOMMU code
> > > about
> > > * segment limitations.
> > > * @dma_pools: Dma pools (if dma'ble device).
> > > @@ -578,7 +580,13 @@ struct device {
> > > allocations such descriptors. */
> > > u64 bus_dma_limit; /* upstream dma constraint */
> > > unsigned long dma_pfn_offset;
> > > -
> > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > > + const struct dma_pfn_offset_region *dma_pfn_offset_map;
> > > + /* Like dma_pfn_offset, but for
> > > + * the unlikely case of multiple
> > > + * offsets. If non-null, dma_pfn_offset
> > > + * will be set to 0. */
> > > +#endif
> >
> > I'm still sad this doesn't fully replace dma_pfn_offset & bus_dma_limit. I feel
> > the extra logic involved in incorporating this as default isn't going to be
> > noticeable as far as performance is concerned to single dma-range users, and
> > it'd make for a nicer DMA code. Also you'd force everyone to test their changes
> > on the multi dma-ranges code path, as opposed to having this disabled 99.9% of
> > the time (hence broken every so often).
> Good point.
+1
> > Note that I sympathize with the amount of work involved on improving that, so
> > better wait to hear what more knowledgeable people have to say about this :)
> Yes, I agree. I want to avoid coding and testing one solution only to
> have a different reviewer NAK it.
It's a pretty safe bet that everyone will prefer one code path over 2.
Rob
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* Re: [PATCH net 1/3] mptcp: fix unblocking connect()
From: Mat Martineau @ 2020-05-29 17:35 UTC (permalink / raw)
To: Paolo Abeni; +Cc: netdev, David S. Miller, Jakub Kicinski
In-Reply-To: <ed95b3e88cd4dfc3efc495c0be646c095aefb975.1590766645.git.pabeni@redhat.com>
On Fri, 29 May 2020, Paolo Abeni wrote:
> Currently unblocking connect() on MPTCP sockets fails frequently.
> If mptcp_stream_connect() is invoked to complete a previously
> attempted unblocking connection, it will still try to create
> the first subflow via __mptcp_socket_create(). If the 3whs is
> completed and the 'can_ack' flag is already set, the latter
> will fail with -EINVAL.
>
> This change addresses the issue checking for pending connect and
> delegating the completion to the first subflow. Additionally
> do msk addresses and sk_state changes only when needed.
>
> Fixes: 2303f994b3e1 ("mptcp: Associate MPTCP context with TCP socket")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> net/mptcp/protocol.c | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
--
Mat Martineau
Intel
^ permalink raw reply
* Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets
From: Rob Herring @ 2020-05-29 17:34 UTC (permalink / raw)
To: Jim Quinlan
Cc: Nicolas Saenz Julienne,
open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
Frank Rowand, Greg Kroah-Hartman, Marek Szyprowski, Robin Murphy,
Alan Stern, Oliver Neukum, Rafael J. Wysocki, Andy Shevchenko,
Wolfram Sang, Corey Minyard, Srinivas Kandagatla,
Suzuki K Poulose, Saravana Kannan, Heikki Krogerus, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:USB SUBSYSTEM, open list:DMA MAPPING HELPERS
In-Reply-To: <CA+-6iNyOKvY-xNfXqDRa5_nJVJuqGKA-oe-ejNuJHUBt6ORu0A@mail.gmail.com>
On Wed, May 27, 2020 at 9:43 AM Jim Quinlan <james.quinlan@broadcom.com> wrote:
>
> Hi Nicolas,
>
> On Wed, May 27, 2020 at 11:00 AM Nicolas Saenz Julienne
> <nsaenzjulienne@suse.de> wrote:
> >
> > Hi Jim,
> > one thing comes to mind, there is a small test suite in drivers/of/unittest.c
> > (specifically of_unittest_pci_dma_ranges()) you could extend it to include your
> > use cases.
> Sure, will check out.
> >
> > On Tue, 2020-05-26 at 15:12 -0400, Jim Quinlan wrote:
> > > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > > the use of multiple pfn offsets between cpu addrs and dma addrs. It is
> > > similar to 'dma_pfn_offset' except that the offset chosen depends on the
> > > cpu or dma address involved.
> > >
> > > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> > > ---
> > > drivers/of/address.c | 65 +++++++++++++++++++++++++++++++++++--
> > > drivers/usb/core/message.c | 3 ++
> > > drivers/usb/core/usb.c | 3 ++
> > > include/linux/device.h | 10 +++++-
> > > include/linux/dma-direct.h | 10 ++++--
> > > include/linux/dma-mapping.h | 46 ++++++++++++++++++++++++++
> > > kernel/dma/Kconfig | 13 ++++++++
> > > 7 files changed, 144 insertions(+), 6 deletions(-)
> > >
> >
> > [...]
> >
> > > @@ -977,10 +1020,19 @@ int of_dma_get_range(struct device *dev, struct
> > > device_node *np, u64 *dma_addr,
> > > pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
> > > range.bus_addr, range.cpu_addr, range.size);
> > >
> > > + num_ranges++;
> > > if (dma_offset && range.cpu_addr - range.bus_addr != dma_offset)
> > > {
> > > - pr_warn("Can't handle multiple dma-ranges with different
> > > offsets on node(%pOF)\n", node);
> > > - /* Don't error out as we'd break some existing DTs */
> > > - continue;
> > > + if (!IS_ENABLED(CONFIG_DMA_PFN_OFFSET_MAP)) {
> > > + pr_warn("Can't handle multiple dma-ranges with
> > > different offsets on node(%pOF)\n", node);
> > > + pr_warn("Perhaps set DMA_PFN_OFFSET_MAP=y?\n");
> > > + /*
> > > + * Don't error out as we'd break some existing
> > > + * DTs that are using configs w/o
> > > + * CONFIG_DMA_PFN_OFFSET_MAP set.
> > > + */
> > > + continue;
> >
> > dev->bus_dma_limit is set in of_dma_configure(), this function's caller, based
> > on dma_start's value (set after this continue). So you'd be effectively setting
> > the dev->bus_dma_limit to whatever we get from the first dma-range.
> I'm not seeing that at all. On the evaluation of each dma-range,
> dma_start and dma_end are re-evaluated to be the lowest and highest
> bus values of the dma-ranges seen so far. After all dma-ranges are
> examined, dev->bus_dma_limit being set to the highest. In fact, the
> current code -- ie before my commits -- already does this for multiple
> dma-ranges as long as the cpu-bus offset is the same in the
> dma-ranges.
> >
> > This can be troublesome depending on how the dma-ranges are setup, for example
> > if the first dma-range doesn't include the CMA area, in arm64 generally set as
> > high as possible in ZONE_DMA32, that would render it useless for
> > dma/{direct/swiotlb}. Again depending on the bus_dma_limit value, if smaller
> > than ZONE_DMA you'd be unable to allocate any DMA memory.
> >
> > IMO, a solution to this calls for a revamp of dma-direct's dma_capable(): match
> > the target DMA memory area with each dma-range we have to see if it fits.
> >
> > > + }
> > > + dma_multi_pfn_offset = true;
> > > }
> > > dma_offset = range.cpu_addr - range.bus_addr;
> > >
> > > @@ -991,6 +1043,13 @@ int of_dma_get_range(struct device *dev, struct
> > > device_node *np, u64 *dma_addr,
> > > dma_end = range.bus_addr + range.size;
> > > }
> > >
> > > + if (dma_multi_pfn_offset) {
> > > + dma_offset = 0;
> > > + ret = attach_dma_pfn_offset_map(dev, node, num_ranges);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > +
> > > if (dma_start >= dma_end) {
> > > ret = -EINVAL;
> > > pr_debug("Invalid DMA ranges configuration on node(%pOF)\n",
> > > diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> > > index 6197938dcc2d..aaa3e58f5eb4 100644
> > > --- a/drivers/usb/core/message.c
> > > +++ b/drivers/usb/core/message.c
> > > @@ -1960,6 +1960,9 @@ int usb_set_configuration(struct usb_device *dev, int
> > > configuration)
> > > */
> > > intf->dev.dma_mask = dev->dev.dma_mask;
> > > intf->dev.dma_pfn_offset = dev->dev.dma_pfn_offset;
> > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > > + intf->dev.dma_pfn_offset_map = dev->dev.dma_pfn_offset_map;
> > > +#endif
> >
> > Thanks for looking at this, that said, I see more instances of drivers changing
> > dma_pfn_offset outside of the core code. Why not doing this there too?
> >
> > Also, are we 100% sure that dev->dev.dma_pfn_offset isn't going to be freed
> > before we're done using intf->dev? Maybe it's safer to copy the ranges?
> >
> > > INIT_WORK(&intf->reset_ws, __usb_queue_reset_device);
> > > intf->minor = -1;
> > > device_initialize(&intf->dev);
> > > diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> > > index f16c26dc079d..d2ed4d90e56e 100644
> > > --- a/drivers/usb/core/usb.c
> > > +++ b/drivers/usb/core/usb.c
> > > @@ -612,6 +612,9 @@ struct usb_device *usb_alloc_dev(struct usb_device
> > > *parent,
> > > */
> > > dev->dev.dma_mask = bus->sysdev->dma_mask;
> > > dev->dev.dma_pfn_offset = bus->sysdev->dma_pfn_offset;
> > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > > + dev->dev.dma_pfn_offset_map = bus->sysdev->dma_pfn_offset_map;
> > > +#endif
> > > set_dev_node(&dev->dev, dev_to_node(bus->sysdev));
> > > dev->state = USB_STATE_ATTACHED;
> > > dev->lpm_disable_count = 1;
> > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > index ac8e37cd716a..67a240ad4fc5 100644
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -493,6 +493,8 @@ struct dev_links_info {
> > > * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
> > > * DMA limit than the device itself supports.
> > > * @dma_pfn_offset: offset of DMA memory range relatively of RAM
> > > + * @dma_pfn_offset_map: Like dma_pfn_offset but used when there are
> > > multiple
> > > + * pfn offsets for multiple dma-ranges.
> > > * @dma_parms: A low level driver may set these to teach IOMMU code
> > > about
> > > * segment limitations.
> > > * @dma_pools: Dma pools (if dma'ble device).
> > > @@ -578,7 +580,13 @@ struct device {
> > > allocations such descriptors. */
> > > u64 bus_dma_limit; /* upstream dma constraint */
> > > unsigned long dma_pfn_offset;
> > > -
> > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > > + const struct dma_pfn_offset_region *dma_pfn_offset_map;
> > > + /* Like dma_pfn_offset, but for
> > > + * the unlikely case of multiple
> > > + * offsets. If non-null, dma_pfn_offset
> > > + * will be set to 0. */
> > > +#endif
> >
> > I'm still sad this doesn't fully replace dma_pfn_offset & bus_dma_limit. I feel
> > the extra logic involved in incorporating this as default isn't going to be
> > noticeable as far as performance is concerned to single dma-range users, and
> > it'd make for a nicer DMA code. Also you'd force everyone to test their changes
> > on the multi dma-ranges code path, as opposed to having this disabled 99.9% of
> > the time (hence broken every so often).
> Good point.
+1
> > Note that I sympathize with the amount of work involved on improving that, so
> > better wait to hear what more knowledgeable people have to say about this :)
> Yes, I agree. I want to avoid coding and testing one solution only to
> have a different reviewer NAK it.
It's a pretty safe bet that everyone will prefer one code path over 2.
Rob
^ permalink raw reply
* Re: [PATCH linux-rcu] docs/litmus-tests: add BPF ringbuf MPSC litmus tests
From: Joel Fernandes @ 2020-05-29 17:34 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, bpf, Networking, Paul E . McKenney, Alan Stern,
parri.andrea, will, Peter Ziljstra, Boqun Feng, npiggin, dhowells,
j.alglave, luc.maranget, Akira Yokosawa, dlustig, open list,
linux-arch, Kernel Team
In-Reply-To: <CAEf4BzZ_g2RwOgaRL1Qa9yo-8dH4kpgNaBOWZznNxqxhJUM1aA@mail.gmail.com>
Hi Andrii,
On Thu, May 28, 2020 at 10:50:30PM -0700, Andrii Nakryiko wrote:
> > [...]
> > > diff --git a/Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+bounded.litmus b/Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+bounded.litmus
> > > new file mode 100644
> > > index 000000000000..558f054fb0b4
> > > --- /dev/null
> > > +++ b/Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+bounded.litmus
> > > @@ -0,0 +1,91 @@
> > > +C bpf-rb+1p1c+bounded
> > > +
> > > +(*
> > > + * Result: Always
> > > + *
> > > + * This litmus test validates BPF ring buffer implementation under the
> > > + * following assumptions:
> > > + * - 1 producer;
> > > + * - 1 consumer;
> > > + * - ring buffer has capacity for only 1 record.
> > > + *
> > > + * Expectations:
> > > + * - 1 record pushed into ring buffer;
> > > + * - 0 or 1 element is consumed.
> > > + * - no failures.
> > > + *)
> > > +
> > > +{
> > > + atomic_t dropped;
> > > +}
> > > +
> > > +P0(int *lenFail, int *len1, int *cx, int *px)
> > > +{
> > > + int *rLenPtr;
> > > + int rLen;
> > > + int rPx;
> > > + int rCx;
> > > + int rFail;
> > > +
> > > + rFail = 0;
> > > +
> > > + rCx = smp_load_acquire(cx);
> > > + rPx = smp_load_acquire(px);
> >
> > Is it possible for you to put some more comments around which ACQUIRE is
> > paired with which RELEASE? And, in general more comments around the reason
> > for a certain memory barrier and what pairs with what. In the kernel sources,
> > the barriers needs a comment anyway.
This was the comment earlier that was missed.
> > > + if (rCx < rPx) {
> > > + if (rCx == 0) {
> > > + rLenPtr = len1;
> > > + } else {
> > > + rLenPtr = lenFail;
> > > + rFail = 1;
> > > + }
> > > +
> > > + rLen = smp_load_acquire(rLenPtr);
> > > + if (rLen == 0) {
> > > + rFail = 1;
> > > + } else if (rLen == 1) {
> > > + rCx = rCx + 1;
> > > + smp_store_release(cx, rCx);
> > > + }
> > > + }
> > > +}
> > > +
> > > +P1(int *lenFail, int *len1, spinlock_t *rb_lock, int *px, int *cx, atomic_t *dropped)
> > > +{
> > > + int rPx;
> > > + int rCx;
> > > + int rFail;
> > > + int *rLenPtr;
> > > +
> > > + rFail = 0;
> > > +
> > > + rCx = smp_load_acquire(cx);
> > > + spin_lock(rb_lock);
> > > +
> > > + rPx = *px;
> > > + if (rPx - rCx >= 1) {
> > > + atomic_inc(dropped);
> >
> > Why does 'dropped' need to be atomic if you are always incrementing under a
> > lock?
>
> It doesn't, strictly speaking, but making it atomic in litmus test was
> just more convenient, especially that I initially also had a lock-less
> variant of this algorithm.
Ok, that's fine.
> >
> > > + spin_unlock(rb_lock);
> > > + } else {
> > > + if (rPx == 0) {
> > > + rLenPtr = len1;
> > > + } else {
> > > + rLenPtr = lenFail;
> > > + rFail = 1;
> > > + }
> > > +
> > > + *rLenPtr = -1;
> >
> > Clarify please the need to set the length intermittently to -1. Thanks.
>
> This corresponds to setting a "busy bit" in kernel implementation.
> These litmus tests are supposed to be correlated with in-kernel
> implementation, I'm not sure I want to maintain extra 4 copies of
> comments here and in kernel code. Especially for 2-producer cases,
> there are 2 identical P1 and P2, which is unfortunate, but I haven't
> figured out how to have a re-usable pieces of code with litmus tests
> :)
I disagree that comments related to memory ordering are optional. IMHO, the
documentation should be clear from a memory ordering standpoint. After all,
good Documentation/ always clarifies something / some concept to the reader
right? :-) Please have mercy on me, I am just trying to learn *your*
Documentation ;-)
> > > diff --git a/Documentation/litmus-tests/bpf-rb/bpf-rb+2p1c+bounded.litmus b/Documentation/litmus-tests/bpf-rb/bpf-rb+2p1c+bounded.litmus
[...]
> > > +P1(int *lenFail, int *len1, spinlock_t *rb_lock, int *px, int *cx, atomic_t *dropped)
> > > +{
> > > + int rPx;
> > > + int rCx;
> > > + int rFail;
> > > + int *rLenPtr;
> > > +
> > > + rFail = 0;
> > > + rLenPtr = lenFail;
> > > +
> > > + rCx = smp_load_acquire(cx);
> > > + spin_lock(rb_lock);
> > > +
> > > + rPx = *px;
> > > + if (rPx - rCx >= 1) {
> > > + atomic_inc(dropped);
> > > + spin_unlock(rb_lock);
> > > + } else {
> > > + if (rPx == 0) {
> > > + rLenPtr = len1;
> > > + } else if (rPx == 1) {
> > > + rLenPtr = len1;
> > > + } else {
> > > + rLenPtr = lenFail;
> > > + rFail = 1;
> > > + }
> > > +
> > > + *rLenPtr = -1;
> > > + smp_store_release(px, rPx + 1);
> > > +
> > > + spin_unlock(rb_lock);
> > > +
> > > + smp_store_release(rLenPtr, 1);
> >
> > I ran a test replacing the last 2 statements above with the following and it
> > still works:
> >
> > spin_unlock(rb_lock);
> > WRITE_ONCE(*rLenPtr, 1);
> >
> > Wouldn't you expect the test to catch an issue? The spin_unlock is already a
> > RELEASE barrier.
>
> Well, apparently it's not an issue and WRITE_ONCE would work as well
> :) My original version actually used WRITE_ONCE here. See [0] and
> discussion in [1] after which I removed all the WRITE_ONCE/READ_ONCE
> in favor of store_release/load_acquire for consistency.
>
> [0] https://patchwork.ozlabs.org/project/netdev/patch/20200513192532.4058934-3-andriin@fb.com/
> [1] https://patchwork.ozlabs.org/project/netdev/patch/20200513192532.4058934-2-andriin@fb.com/
Huh. So you are replacing the test to use WRITE_ONCE instead? Why did you
favor the acquire/release memory barriers over the _ONCE annotations, if that
was not really needed then?
> > Suggestion: It is hard to review the patch because it is huge, it would be
> > good to split this up into 4 patches for each of the tests. But upto you :)
>
> Those 4 files are partial copies of each other, not sure splitting
> them actually would be easier. If anyone else thinks the same, though,
> I'll happily split.
I personally disagree. It would be much easier IMHO to review 4 different
files since some of them are also quite dissimilar. I frequently keep jumping
between diffs to find a different file and it makes the review that much
harder. But anything the LKMM experts decide in this regard is acceptable to me :)
thanks,
- Joel
^ permalink raw reply
* Re: Xenomai-3.1 make fails when configured -mx32 on 64bit kernel
From: Jan Kiszka @ 2020-05-29 17:35 UTC (permalink / raw)
To: Rosenow, Jim, xenomai@xenomai.org
In-Reply-To: <90c644a07db5444384a22e8d26c075e1@mts.com>
On 29.05.20 16:49, Rosenow, Jim via Xenomai wrote:
> Kernel version:
> Linux debian-10-64bit 4.4.218-xenomai-3.1 #1 SMP PREEMPT Fri May 29 04:49:06 CDT 2020 x86_64 GNU/Linux
>
> Ipipe version:
> ipipe-core-4.4.218-cip44-x86-23.patch
>
> 32bit configured -m32 builds and runs as does the default 64bit version:
> ../configure --enable-pshared --enable-smp CFLAGS="-m32" LDFLAGS="-m32"
>
> 32bit configured -mx32 does not build, see below.
> Thanks,
> Jim
>
> ../configure --enable-pshared --enable-smp CFLAGS="-mx32" LDFLAGS="-mx32"
>
> root@debian-10-64bit:~/Xenomai/xenomai-3.1/build# make
> Making all in doc
> make[1]: Entering directory '/root/Xenomai/xenomai-3.1/build/doc'
> Making all in gitdoc
> make[2]: Entering directory '/root/Xenomai/xenomai-3.1/build/doc/gitdoc'
> make[2]: Leaving directory '/root/Xenomai/xenomai-3.1/build/doc/gitdoc'
> Making all in doxygen
> make[2]: Entering directory '/root/Xenomai/xenomai-3.1/build/doc/doxygen'
> make[2]: Nothing to be done for 'all'.
> make[2]: Leaving directory '/root/Xenomai/xenomai-3.1/build/doc/doxygen'
> Making all in asciidoc
> make[2]: Entering directory '/root/Xenomai/xenomai-3.1/build/doc/asciidoc'
> make[2]: Nothing to be done for 'all'.
> make[2]: Leaving directory '/root/Xenomai/xenomai-3.1/build/doc/asciidoc'
> make[2]: Entering directory '/root/Xenomai/xenomai-3.1/build/doc'
> make[2]: Nothing to be done for 'all-am'.
> make[2]: Leaving directory '/root/Xenomai/xenomai-3.1/build/doc'
> make[1]: Leaving directory '/root/Xenomai/xenomai-3.1/build/doc'
> Making all in lib
> make[1]: Entering directory '/root/Xenomai/xenomai-3.1/build/lib'
> Making all in boilerplate
> make[2]: Entering directory '/root/Xenomai/xenomai-3.1/build/lib/boilerplate'
> make all-recursive
> make[3]: Entering directory '/root/Xenomai/xenomai-3.1/build/lib/boilerplate'
> Making all in init
> make[4]: Entering directory '/root/Xenomai/xenomai-3.1/build/lib/boilerplate/init'
> CC libbootstrap_a-bootstrap.o
> AR libbootstrap.a
> ar: `u' modifier ignored since `D' is the default (see `U')
> CC libbootstrap_pic_la-bootstrap.lo
> CCLD libbootstrap-pic.la
> ar: `u' modifier ignored since `D' is the default (see `U')
> make[4]: Leaving directory '/root/Xenomai/xenomai-3.1/build/lib/boilerplate/init'
> make[4]: Entering directory '/root/Xenomai/xenomai-3.1/build/lib/boilerplate'
> CC libavl_la-avl.lo
> CCLD libavl.la
> ar: `u' modifier ignored since `D' is the default (see `U')
> CC libversion_la-version.lo
> CCLD libversion.la
> ar: `u' modifier ignored since `D' is the default (see `U')
> CC iniparser/libiniparser_la-dictionary.lo
> CC iniparser/libiniparser_la-iniparser.lo
> CCLD libiniparser.la
> ar: `u' modifier ignored since `D' is the default (see `U')
> CC libboilerplate_la-ancillaries.lo
> CC libboilerplate_la-heapmem.lo
> CC libboilerplate_la-hash.lo
> CC libboilerplate_la-setup.lo
> CC libboilerplate_la-time.lo
> CC libshavl_la-avl.lo
> CCLD libshavl.la
> ar: `u' modifier ignored since `D' is the default (see `U')
> CC tlsf/libtlsf_la-tlsf.lo
> CCLD libtlsf.la
> ar: `u' modifier ignored since `D' is the default (see `U')
> CCLD libboilerplate.la
> ar: `u' modifier ignored since `D' is the default (see `U')
> CC version-version.o
> CCLD version
> make[4]: Leaving directory '/root/Xenomai/xenomai-3.1/build/lib/boilerplate'
> make[3]: Leaving directory '/root/Xenomai/xenomai-3.1/build/lib/boilerplate'
> make[2]: Leaving directory '/root/Xenomai/xenomai-3.1/build/lib/boilerplate'
> Making all in cobalt
> make[2]: Entering directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt'
> Making all in arch
> make[3]: Entering directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch'
> Making all in x86
> make[4]: Entering directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch/x86'
> Making all in include
> make[5]: Entering directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch/x86/include'
> Making all in asm
> make[6]: Entering directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch/x86/include/asm'
> Making all in xenomai
> make[7]: Entering directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch/x86/include/asm/xenomai'
> make[7]: Nothing to be done for 'all'.
> make[7]: Leaving directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch/x86/include/asm/xenomai'
> make[7]: Entering directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch/x86/include/asm'
> make[7]: Nothing to be done for 'all-am'.
> make[7]: Leaving directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch/x86/include/asm'
> make[6]: Leaving directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch/x86/include/asm'
> make[6]: Entering directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch/x86/include'
> make[6]: Nothing to be done for 'all-am'.
> make[6]: Leaving directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch/x86/include'
> make[5]: Leaving directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch/x86/include'
> make[5]: Entering directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch/x86'
> CC libarch_la-features.lo
> CCLD libarch.la
> ar: `u' modifier ignored since `D' is the default (see `U')
> make[5]: Leaving directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch/x86'
> make[4]: Leaving directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch/x86'
> make[4]: Entering directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch'
> make[4]: Nothing to be done for 'all-am'.
> make[4]: Leaving directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch'
> make[3]: Leaving directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt/arch'
> make[3]: Entering directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt'
> CC libcobalt_la-attr.lo
> CC libcobalt_la-clock.lo
> In file included from ../../../lib/cobalt/clock.c:32:
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/tsc.h: In function ‘cobalt_read_tsc’:
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/tsc.h:34:54: error: left shift count >= width of type [-Werror=shift-count-overflow]
> return ((unsigned long)__a) | (((unsigned long)__d) << 32);
> ^~
> In file included from ../../../lib/cobalt/clock.c:31:
> ../../../lib/cobalt/clock.c: In function ‘__cobalt_clock_getres’:
> /root/Xenomai/xenomai-3.1/kernel/cobalt/arch/x86/include/asm/xenomai/uapi/syscall.h:22:28: error: ‘__COBALT_X32_BASE’ undeclared (first use in this function)
> #define __xn_syscall_base __COBALT_X32_BASE
> ^~~~~~~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:196:10: note: in definition of macro ‘DO_SYSCALL’
> : "0" (name) ASM_ARGS_##nr \
> ^~~~
> /root/Xenomai/xenomai-3.1/kernel/cobalt/arch/x86/include/asm/xenomai/uapi/syscall.h:27:60: note: in expansion of macro ‘__xn_syscall_base’
> #define __xn_syscode(__nr) (__COBALT_SYSCALL_BIT | (__nr + __xn_syscall_base))
> ^~~~~~~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:202:13: note: in expansion of macro ‘__xn_syscode’
> DO_SYSCALL(__xn_syscode(op), nr, args)
> ^~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:211:37: note: in expansion of macro ‘XENOMAI_DO_SYSCALL’
> #define XENOMAI_SYSCALL2(op,a1,a2) XENOMAI_DO_SYSCALL(2,op,a1,a2)
> ^~~~~~~~~~~~~~~~~~
> ../../../lib/cobalt/clock.c:104:9: note: in expansion of macro ‘XENOMAI_SYSCALL2’
> ret = -XENOMAI_SYSCALL2(sc_cobalt_clock_getres, clock_id, tp);
> ^~~~~~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/kernel/cobalt/arch/x86/include/asm/xenomai/uapi/syscall.h:22:28: note: each undeclared identifier is reported only once for each function it appears in
> #define __xn_syscall_base __COBALT_X32_BASE
> ^~~~~~~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:196:10: note: in definition of macro ‘DO_SYSCALL’
> : "0" (name) ASM_ARGS_##nr \
> ^~~~
> /root/Xenomai/xenomai-3.1/kernel/cobalt/arch/x86/include/asm/xenomai/uapi/syscall.h:27:60: note: in expansion of macro ‘__xn_syscall_base’
> #define __xn_syscode(__nr) (__COBALT_SYSCALL_BIT | (__nr + __xn_syscall_base))
> ^~~~~~~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:202:13: note: in expansion of macro ‘__xn_syscode’
> DO_SYSCALL(__xn_syscode(op), nr, args)
> ^~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:211:37: note: in expansion of macro ‘XENOMAI_DO_SYSCALL’
> #define XENOMAI_SYSCALL2(op,a1,a2) XENOMAI_DO_SYSCALL(2,op,a1,a2)
> ^~~~~~~~~~~~~~~~~~
> ../../../lib/cobalt/clock.c:104:9: note: in expansion of macro ‘XENOMAI_SYSCALL2’
> ret = -XENOMAI_SYSCALL2(sc_cobalt_clock_getres, clock_id, tp);
> ^~~~~~~~~~~~~~~~
> ../../../lib/cobalt/clock.c: In function ‘__cobalt_clock_gettime’:
> /root/Xenomai/xenomai-3.1/kernel/cobalt/arch/x86/include/asm/xenomai/uapi/syscall.h:22:28: error: ‘__COBALT_X32_BASE’ undeclared (first use in this function)
> #define __xn_syscall_base __COBALT_X32_BASE
> ^~~~~~~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:196:10: note: in definition of macro ‘DO_SYSCALL’
> : "0" (name) ASM_ARGS_##nr \
> ^~~~
> /root/Xenomai/xenomai-3.1/kernel/cobalt/arch/x86/include/asm/xenomai/uapi/syscall.h:27:60: note: in expansion of macro ‘__xn_syscall_base’
> #define __xn_syscode(__nr) (__COBALT_SYSCALL_BIT | (__nr + __xn_syscall_base))
> ^~~~~~~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:202:13: note: in expansion of macro ‘__xn_syscode’
> DO_SYSCALL(__xn_syscode(op), nr, args)
> ^~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:211:37: note: in expansion of macro ‘XENOMAI_DO_SYSCALL’
> #define XENOMAI_SYSCALL2(op,a1,a2) XENOMAI_DO_SYSCALL(2,op,a1,a2)
> ^~~~~~~~~~~~~~~~~~
> ../../../lib/cobalt/clock.c:204:10: note: in expansion of macro ‘XENOMAI_SYSCALL2’
> ret = -XENOMAI_SYSCALL2(sc_cobalt_clock_gettime, clock_id, tp);
> ^~~~~~~~~~~~~~~~
> ../../../lib/cobalt/clock.c: In function ‘__cobalt_clock_settime’:
> /root/Xenomai/xenomai-3.1/kernel/cobalt/arch/x86/include/asm/xenomai/uapi/syscall.h:22:28: error: ‘__COBALT_X32_BASE’ undeclared (first use in this function)
> #define __xn_syscall_base __COBALT_X32_BASE
> ^~~~~~~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:196:10: note: in definition of macro ‘DO_SYSCALL’
> : "0" (name) ASM_ARGS_##nr \
> ^~~~
> /root/Xenomai/xenomai-3.1/kernel/cobalt/arch/x86/include/asm/xenomai/uapi/syscall.h:27:60: note: in expansion of macro ‘__xn_syscall_base’
> #define __xn_syscode(__nr) (__COBALT_SYSCALL_BIT | (__nr + __xn_syscall_base))
> ^~~~~~~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:202:13: note: in expansion of macro ‘__xn_syscode’
> DO_SYSCALL(__xn_syscode(op), nr, args)
> ^~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:211:37: note: in expansion of macro ‘XENOMAI_DO_SYSCALL’
> #define XENOMAI_SYSCALL2(op,a1,a2) XENOMAI_DO_SYSCALL(2,op,a1,a2)
> ^~~~~~~~~~~~~~~~~~
> ../../../lib/cobalt/clock.c:240:9: note: in expansion of macro ‘XENOMAI_SYSCALL2’
> ret = -XENOMAI_SYSCALL2(sc_cobalt_clock_settime, clock_id, tp);
> ^~~~~~~~~~~~~~~~
> ../../../lib/cobalt/clock.c: In function ‘__cobalt_clock_adjtime’:
> /root/Xenomai/xenomai-3.1/kernel/cobalt/arch/x86/include/asm/xenomai/uapi/syscall.h:22:28: error: ‘__COBALT_X32_BASE’ undeclared (first use in this function)
> #define __xn_syscall_base __COBALT_X32_BASE
> ^~~~~~~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:196:10: note: in definition of macro ‘DO_SYSCALL’
> : "0" (name) ASM_ARGS_##nr \
> ^~~~
> /root/Xenomai/xenomai-3.1/kernel/cobalt/arch/x86/include/asm/xenomai/uapi/syscall.h:27:60: note: in expansion of macro ‘__xn_syscall_base’
> #define __xn_syscode(__nr) (__COBALT_SYSCALL_BIT | (__nr + __xn_syscall_base))
> ^~~~~~~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:202:13: note: in expansion of macro ‘__xn_syscode’
> DO_SYSCALL(__xn_syscode(op), nr, args)
> ^~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:211:37: note: in expansion of macro ‘XENOMAI_DO_SYSCALL’
> #define XENOMAI_SYSCALL2(op,a1,a2) XENOMAI_DO_SYSCALL(2,op,a1,a2)
> ^~~~~~~~~~~~~~~~~~
> ../../../lib/cobalt/clock.c:255:9: note: in expansion of macro ‘XENOMAI_SYSCALL2’
> ret = -XENOMAI_SYSCALL2(sc_cobalt_clock_adjtime, clock_id, tx);
> ^~~~~~~~~~~~~~~~
> ../../../lib/cobalt/clock.c: In function ‘__cobalt_clock_nanosleep’:
> /root/Xenomai/xenomai-3.1/kernel/cobalt/arch/x86/include/asm/xenomai/uapi/syscall.h:22:28: error: ‘__COBALT_X32_BASE’ undeclared (first use in this function)
> #define __xn_syscall_base __COBALT_X32_BASE
> ^~~~~~~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:196:10: note: in definition of macro ‘DO_SYSCALL’
> : "0" (name) ASM_ARGS_##nr \
> ^~~~
> /root/Xenomai/xenomai-3.1/kernel/cobalt/arch/x86/include/asm/xenomai/uapi/syscall.h:27:60: note: in expansion of macro ‘__xn_syscall_base’
> #define __xn_syscode(__nr) (__COBALT_SYSCALL_BIT | (__nr + __xn_syscall_base))
> ^~~~~~~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:202:13: note: in expansion of macro ‘__xn_syscode’
> DO_SYSCALL(__xn_syscode(op), nr, args)
> ^~~~~~~~~~~~
> /root/Xenomai/xenomai-3.1/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h:213:42: note: in expansion of macro ‘XENOMAI_DO_SYSCALL’
> #define XENOMAI_SYSCALL4(op,a1,a2,a3,a4) XENOMAI_DO_SYSCALL(4,op,a1,a2,a3,a4)
> ^~~~~~~~~~~~~~~~~~
> ../../../lib/cobalt/clock.c:312:9: note: in expansion of macro ‘XENOMAI_SYSCALL4’
> ret = -XENOMAI_SYSCALL4(sc_cobalt_clock_nanosleep,
> ^~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
> make[3]: *** [Makefile:632: libcobalt_la-clock.lo] Error 1
> make[3]: Leaving directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt'
> make[2]: *** [Makefile:805: all-recursive] Error 1
> make[2]: Leaving directory '/root/Xenomai/xenomai-3.1/build/lib/cobalt'
> make[1]: *** [Makefile:426: all-recursive] Error 1
> make[1]: Leaving directory '/root/Xenomai/xenomai-3.1/build/lib'
> make: *** [Makefile:459: all-recursive] Error 1
>
Indeed, something regressed. No one tests this path.
Are you seriously considering x32? It's a dead end [1], and I would
rather consider removing it. Or someone needs to pick up the ball, fix
this and also ensure it's hooked up in CI and eventually testing - at
least as long as our test environment support it.
Jan
[1] https://lwn.net/Articles/774734/
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.