[PATCH 4.4 37/38] perf map: Tighten snprintf() string precision to pass gcc check on some 32-bit arches
From: Arnaldo Carvalho de Melo
commit 77d02bd00cea9f1a87afe58113fa75b983d6c23a upstream.
Noticed on a debian:experimental mips and mipsel cross build build
environment:
perfbuilder@ec265a086e9b:~$ mips-linux-gnu-gcc --version | head -1
mips-linux-gnu-gcc (Debian 10.2.1-3) 10.2.1 20201224
perfbuilder@ec265a086e9b:~$
CC /tmp/build/perf/util/map.o
util/map.c: In function 'map__new':
util/map.c:109:5: error: '%s' directive output may be truncated writing
between 1 and 2147483645 bytes into a region of size 4096
[-Werror=format-truncation=]
109 |"%s/platforms/%s/arch-%s/usr/lib/%s",
| ^~
In file included from /usr/mips-linux-gnu/include/stdio.h:867,
from util/symbol.h:11,
from util/map.c:2:
/usr/mips-linux-gnu/include/bits/stdio2.h:67:10: note:
'__builtin___snprintf_chk' output 32 or more bytes (assuming 4294967321) into a
destination of size 4096
67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ^~~~
68 |__bos (__s), __fmt, __va_arg_pack ());
|~
cc1: all warnings being treated as errors
Since we have the lenghts for what lands in that place, use it to give
the compiler more info and make it happy.
Signed-off-by: Arnaldo Carvalho de Melo
Cc: Anders Roxell
Signed-off-by: Greg Kroah-Hartman
---
tools/perf/util/map.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -88,8 +88,7 @@ static inline bool replace_android_lib(c
if (!strncmp(filename, "/system/lib/", 12)) {
char *ndk, *app;
const char *arch;
- size_t ndk_length;
- size_t app_length;
+ int ndk_length, app_length;
ndk = getenv("NDK_ROOT");
app = getenv("APP_PLATFORM");
@@ -117,8 +116,8 @@ static inline bool replace_android_lib(c
if (new_length > PATH_MAX)
return false;
snprintf(newfilename, new_length,
- "%s/platforms/%s/arch-%s/usr/lib/%s",
- ndk, app, arch, libname);
+ "%.*s/platforms/%.*s/arch-%s/usr/lib/%s",
+ ndk_length, ndk, app_length, app, arch, libname);
return true;
}
[PATCH 4.4 28/38] net: ieee802154: fix nl802154 del llsec key
From: Alexander Aring commit 37feaaf5ceb2245e474369312bb7b922ce7bce69 upstream. This patch fixes a nullpointer dereference if NL802154_ATTR_SEC_KEY is not set by the user. If this is the case nl802154 will return -EINVAL. Reported-by: syzbot+ac5c11d2959a8b3c4...@syzkaller.appspotmail.com Signed-off-by: Alexander Aring Link: https://lore.kernel.org/r/20210221174321.14210-1-aahri...@redhat.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman --- net/ieee802154/nl802154.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/net/ieee802154/nl802154.c +++ b/net/ieee802154/nl802154.c @@ -1577,7 +1577,8 @@ static int nl802154_del_llsec_key(struct struct nlattr *attrs[NL802154_KEY_ATTR_MAX + 1]; struct ieee802154_llsec_key_id id; - if (nla_parse_nested(attrs, NL802154_KEY_ATTR_MAX, + if (!info->attrs[NL802154_ATTR_SEC_KEY] || + nla_parse_nested(attrs, NL802154_KEY_ATTR_MAX, info->attrs[NL802154_ATTR_SEC_KEY], nl802154_key_policy)) return -EINVAL;
[PATCH 4.4 00/38] 4.4.267-rc1 review
This is the start of the stable review cycle for the 4.4.267 release. There are 38 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat, 17 Apr 2021 14:44:01 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.267-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 4.4.267-rc1 Juergen Gross xen/events: fix setting irq affinity Arnaldo Carvalho de Melo perf map: Tighten snprintf() string precision to pass gcc check on some 32-bit arches Florian Westphal netfilter: x_tables: fix compat match/target pad out-of-bound write Arnd Bergmann drm/imx: imx-ldb: fix out of bounds array access warning Alexander Aring net: ieee802154: stop dump llsec params for monitors Alexander Aring net: ieee802154: forbid monitor for del llsec seclevel Alexander Aring net: ieee802154: forbid monitor for set llsec params Alexander Aring net: ieee802154: fix nl802154 del llsec devkey Alexander Aring net: ieee802154: fix nl802154 add llsec key Alexander Aring net: ieee802154: fix nl802154 del llsec dev Alexander Aring net: ieee802154: fix nl802154 del llsec key Alexander Aring net: ieee802154: nl-mac: fix check on panid Pavel Skripkin net: mac802154: Fix general protection fault Pavel Skripkin drivers: net: fix memory leak in peak_usb_create_dev Pavel Skripkin drivers: net: fix memory leak in atusb_probe Phillip Potter net: tun: set tun->dev->addr_len during TUNSETLINK processing Du Cheng cfg80211: remove WARN_ON() in cfg80211_sme_connect Krzysztof Kozlowski clk: socfpga: fix iomem pointer cast on 64-bit Potnuri Bharat Teja RDMA/cxgb4: check for ipv6 address properly while destroying listener Alexander Gordeev s390/cpcmd: fix inline assembly register clobbering Zqiang workqueue: Move the position of debug_work_activate() in __queue_work() Lukasz Bartosik clk: fix invalid usage of list cursor in unregister Lv Yunlong net:tipc: Fix a double free in tipc_sk_mcast_rcv Claudiu Manoil gianfar: Handle error code at MAC address change Eric Dumazet sch_red: fix off-by-one checks in red_check_params() Pavel Tikhomirov net: sched: sch_teql: fix null-pointer dereference Tetsuo Handa batman-adv: initialize "struct batadv_tvlv_tt_vlan_data"->reserved field Helge Deller parisc: parisc-agp requires SBA IOMMU driver Jack Qiu fs: direct-io: fix missing sdio->boundary Sergei Trofimovich ia64: fix user_stack_pointer() for ptrace() Muhammad Usama Anjum net: ipv6: check for validity before dereferencing cfg->fc_nlinfo.nlh Luca Fancellu xen/evtchn: Change irq_info lock to raw_spinlock_t Xiaoming Ni nfc: Avoid endless loops caused by repeated llcp_sock_connect() Xiaoming Ni nfc: fix memory leak in llcp_sock_connect() Xiaoming Ni nfc: fix refcount leak in llcp_sock_connect() Xiaoming Ni nfc: fix refcount leak in llcp_sock_bind() Jonas Holmberg ALSA: aloop: Fix initialization of controls Ye Xiang iio: hid-sensor-prox: Fix scale not correct issue - Diffstat: Makefile | 4 +-- arch/ia64/include/asm/ptrace.h | 8 + arch/s390/kernel/cpcmd.c | 6 ++-- drivers/char/agp/Kconfig | 2 +- drivers/clk/clk.c| 30 - drivers/clk/socfpga/clk-gate.c | 2 +- drivers/gpu/drm/imx/imx-ldb.c| 10 ++ drivers/iio/light/hid-sensor-prox.c | 14 ++-- drivers/infiniband/hw/cxgb4/cm.c | 3 +- drivers/net/can/usb/peak_usb/pcan_usb_core.c | 6 +++- drivers/net/ethernet/freescale/gianfar.c | 6 +++- drivers/net/ieee802154/atusb.c | 1 + drivers/net/tun.c| 48 drivers/xen/events/events_base.c | 14 drivers/xen/events/events_internal.h | 2 +- fs/direct-io.c | 5 +-- include/net/red.h| 4 +-- kernel/workqueue.c | 2 +- net/batman-adv/translation-table.c | 1 + net/ieee802154/nl-mac.c | 7 ++-- net/ieee802154/nl802154.c| 23 ++--- net/ipv4/netfilter/arp_tables.c | 2 ++ net/ipv4/netfilter/ip_tables.c | 2 ++ net/ipv6/netfilter/ip6_tables.c | 2 ++ net/ipv6/route.c |
[PATCH 4.4 09/38] ia64: fix user_stack_pointer() for ptrace()
From: Sergei Trofimovich
commit 7ad1e366167837daeb93d0bacb57dee820b0b898 upstream.
ia64 has two stacks:
- memory stack (or stack), pointed at by by r12
- register backing store (register stack), pointed at by
ar.bsp/ar.bspstore with complications around dirty
register frame on CPU.
In [1] Dmitry noticed that PTRACE_GET_SYSCALL_INFO returns the register
stack instead memory stack.
The bug comes from the fact that user_stack_pointer() and
current_user_stack_pointer() don't return the same register:
ulong user_stack_pointer(struct pt_regs *regs) { return regs->ar_bspstore; }
#define current_user_stack_pointer() (current_pt_regs()->r12)
The change gets both back in sync.
I think ptrace(PTRACE_GET_SYSCALL_INFO) is the only affected user by
this bug on ia64.
The change fixes 'rt_sigreturn.gen.test' strace test where it was
observed initially.
Link: https://bugs.gentoo.org/769614 [1]
Link: https://lkml.kernel.org/r/20210331084447.2561532-1-sly...@gentoo.org
Signed-off-by: Sergei Trofimovich
Reported-by: Dmitry V. Levin
Cc: Oleg Nesterov
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
arch/ia64/include/asm/ptrace.h |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
--- a/arch/ia64/include/asm/ptrace.h
+++ b/arch/ia64/include/asm/ptrace.h
@@ -53,8 +53,7 @@
static inline unsigned long user_stack_pointer(struct pt_regs *regs)
{
- /* FIXME: should this be bspstore + nr_dirty regs? */
- return regs->ar_bspstore;
+ return regs->r12;
}
static inline int is_syscall_success(struct pt_regs *regs)
@@ -78,11 +77,6 @@ static inline long regs_return_value(str
unsigned long __ip = instruction_pointer(regs); \
(__ip & ~3UL) + ((__ip & 3UL) << 2);\
})
-/*
- * Why not default? Because user_stack_pointer() on ia64 gives register
- * stack backing store instead...
- */
-#define current_user_stack_pointer() (current_pt_regs()->r12)
/* given a pointer to a task_struct, return the user's pt_regs */
# define task_pt_regs(t) (((struct pt_regs *) ((char *) (t) +
IA64_STK_OFFSET)) - 1)
Re: [PATCH v4 1/6] perf arm-spe: Remove unused enum value ARM_SPE_PER_CPU_MMAPS
On 15/04/2021 17:41, Leo Yan wrote: > Hi James, > > On Thu, Apr 15, 2021 at 05:13:36PM +0300, James Clark wrote: >> On 12/04/2021 12:10, Leo Yan wrote: >>> The enum value 'ARM_SPE_PER_CPU_MMAPS' is never used so remove it. >> >> Hi Leo, >> >> I think this causes an error when attempting to open a newly recorded file >> with an old version of perf. The value ARM_SPE_AUXTRACE_PRIV_MAX is used >> here: >> >> size_t min_sz = sizeof(u64) * ARM_SPE_AUXTRACE_PRIV_MAX; >> struct perf_record_time_conv *tc = >time_conv; >> struct arm_spe *spe; >> int err; >> >> if (auxtrace_info->header.size < sizeof(struct >> perf_record_auxtrace_info) + >> min_sz) >> return -EINVAL; >> >> And removing ARM_SPE_PER_CPU_MMAPS changes the value of >> ARM_SPE_AUXTRACE_PRIV_MAX. >> >> At least I think that's what's causing the problem. I get this error: >> >> ./perf report -i per-thread-spe-time.data >> 0x1c0 [0x18]: failed to process type: 70 [Invalid argument] >> Error: >> failed to process sample >> # To display the perf.data header info, please use >> --header/--header-only options. >> # > > Yes, when working on this patch I had concern as well. > > I carefully thought that the perf tool should be backwards-compatible, > but there have no requirement for forwards-compatibility. This is the > main reason why I kept this patch. > > If you or anyone could confirm the forwards-compatibility is required, > it's quite fine for me to drop this patch. > Personally, I can easily imagine sending a file to someone to open with an older version and it causing friction where it could be easily avoided. And it even made testing a bit more difficult because I wanted to compare opening the same file with the patched and un-patched version. But if there is no hard requirement I can't really put too much pressure to not remove it. > Thanks a lot for the reviewing and testing! > Leo >
[PATCH 4.4 08/38] net: ipv6: check for validity before dereferencing cfg->fc_nlinfo.nlh
From: Muhammad Usama Anjum
commit 864db232dc7036aa2de19749c3d5be0143b24f8f upstream.
nlh is being checked for validtity two times when it is dereferenced in
this function. Check for validity again when updating the flags through
nlh pointer to make the dereferencing safe.
CC:
Addresses-Coverity: ("NULL pointer dereference")
Signed-off-by: Muhammad Usama Anjum
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/ipv6/route.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2980,9 +2980,11 @@ static int ip6_route_multipath_add(struc
* nexthops have been replaced by first new, the rest should
* be added to it.
*/
- cfg->fc_nlinfo.nlh->nlmsg_flags &= ~(NLM_F_EXCL |
-NLM_F_REPLACE);
- cfg->fc_nlinfo.nlh->nlmsg_flags |= NLM_F_CREATE;
+ if (cfg->fc_nlinfo.nlh) {
+ cfg->fc_nlinfo.nlh->nlmsg_flags &= ~(NLM_F_EXCL |
+NLM_F_REPLACE);
+ cfg->fc_nlinfo.nlh->nlmsg_flags |= NLM_F_CREATE;
+ }
nhn++;
}
[PATCH 4.4 07/38] xen/evtchn: Change irq_info lock to raw_spinlock_t
From: Luca Fancellu
commit d120198bd5ff1d41808b6914e1eb89aff937415c upstream.
Unmask operation must be called with interrupt disabled,
on preempt_rt spin_lock_irqsave/spin_unlock_irqrestore
don't disable/enable interrupts, so use raw_* implementation
and change lock variable in struct irq_info from spinlock_t
to raw_spinlock_t
Cc: sta...@vger.kernel.org
Fixes: 25da4618af24 ("xen/events: don't unmask an event channel when an eoi is
pending")
Signed-off-by: Luca Fancellu
Reviewed-by: Julien Grall
Reviewed-by: Wei Liu
Link: https://lore.kernel.org/r/20210406105105.10141-1-luca.fance...@arm.com
Signed-off-by: Boris Ostrovsky
Signed-off-by: Greg Kroah-Hartman
---
drivers/xen/events/events_base.c | 10 +-
drivers/xen/events/events_internal.h |2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -222,7 +222,7 @@ static int xen_irq_info_common_setup(str
info->evtchn = evtchn;
info->cpu = cpu;
info->mask_reason = EVT_MASK_REASON_EXPLICIT;
- spin_lock_init(>lock);
+ raw_spin_lock_init(>lock);
ret = set_evtchn_to_irq(evtchn, irq);
if (ret < 0)
@@ -374,28 +374,28 @@ static void do_mask(struct irq_info *inf
{
unsigned long flags;
- spin_lock_irqsave(>lock, flags);
+ raw_spin_lock_irqsave(>lock, flags);
if (!info->mask_reason)
mask_evtchn(info->evtchn);
info->mask_reason |= reason;
- spin_unlock_irqrestore(>lock, flags);
+ raw_spin_unlock_irqrestore(>lock, flags);
}
static void do_unmask(struct irq_info *info, u8 reason)
{
unsigned long flags;
- spin_lock_irqsave(>lock, flags);
+ raw_spin_lock_irqsave(>lock, flags);
info->mask_reason &= ~reason;
if (!info->mask_reason)
unmask_evtchn(info->evtchn);
- spin_unlock_irqrestore(>lock, flags);
+ raw_spin_unlock_irqrestore(>lock, flags);
}
#ifdef CONFIG_X86
--- a/drivers/xen/events/events_internal.h
+++ b/drivers/xen/events/events_internal.h
@@ -47,7 +47,7 @@ struct irq_info {
unsigned short eoi_cpu; /* EOI must happen on this cpu */
unsigned int irq_epoch; /* If eoi_cpu valid: irq_epoch of event */
u64 eoi_time; /* Time in jiffies when to EOI. */
- spinlock_t lock;
+ raw_spinlock_t lock;
union {
unsigned short virq;
[PATCH 4.4 06/38] nfc: Avoid endless loops caused by repeated llcp_sock_connect()
From: Xiaoming Ni
commit 4b5db93e7f2afbdfe3b78e37879a85290187e6f1 upstream.
When sock_wait_state() returns -EINPROGRESS, "sk->sk_state" is
LLCP_CONNECTING. In this case, llcp_sock_connect() is repeatedly invoked,
nfc_llcp_sock_link() will add sk to local->connecting_sockets twice.
sk->sk_node->next will point to itself, that will make an endless loop
and hang-up the system.
To fix it, check whether sk->sk_state is LLCP_CONNECTING in
llcp_sock_connect() to avoid repeated invoking.
Fixes: b4011239a08e ("NFC: llcp: Fix non blocking sockets connections")
Reported-by: "kiyin(尹亮)"
Link: https://www.openwall.com/lists/oss-security/2020/11/01/1
Cc: #v3.11
Signed-off-by: Xiaoming Ni
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/nfc/llcp_sock.c |4
1 file changed, 4 insertions(+)
--- a/net/nfc/llcp_sock.c
+++ b/net/nfc/llcp_sock.c
@@ -679,6 +679,10 @@ static int llcp_sock_connect(struct sock
ret = -EISCONN;
goto error;
}
+ if (sk->sk_state == LLCP_CONNECTING) {
+ ret = -EINPROGRESS;
+ goto error;
+ }
dev = nfc_get_device(addr->dev_idx);
if (dev == NULL) {
[PATCH 4.4 05/38] nfc: fix memory leak in llcp_sock_connect()
From: Xiaoming Ni
commit 7574fcdbdcb335763b6b322f6928dc0fd5730451 upstream.
In llcp_sock_connect(), use kmemdup to allocate memory for
"llcp_sock->service_name". The memory is not released in the sock_unlink
label of the subsequent failure branch.
As a result, memory leakage occurs.
fix CVE-2020-25672
Fixes: d646960f7986 ("NFC: Initial LLCP support")
Reported-by: "kiyin(尹亮)"
Link: https://www.openwall.com/lists/oss-security/2020/11/01/1
Cc: #v3.3
Signed-off-by: Xiaoming Ni
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/nfc/llcp_sock.c |2 ++
1 file changed, 2 insertions(+)
--- a/net/nfc/llcp_sock.c
+++ b/net/nfc/llcp_sock.c
@@ -751,6 +751,8 @@ sock_unlink:
nfc_llcp_local_put(llcp_sock->local);
nfc_llcp_sock_unlink(>connecting_sockets, sk);
+ kfree(llcp_sock->service_name);
+ llcp_sock->service_name = NULL;
put_dev:
nfc_put_device(dev);
[PATCH 4.4 04/38] nfc: fix refcount leak in llcp_sock_connect()
From: Xiaoming Ni
commit 8a4cd82d62b5ec7e5482333a72b58a4eea4979f0 upstream.
nfc_llcp_local_get() is invoked in llcp_sock_connect(),
but nfc_llcp_local_put() is not invoked in subsequent failure branches.
As a result, refcount leakage occurs.
To fix it, add calling nfc_llcp_local_put().
fix CVE-2020-25671
Fixes: c7aa12252f51 ("NFC: Take a reference on the LLCP local pointer when
creating a socket")
Reported-by: "kiyin(尹亮)"
Link: https://www.openwall.com/lists/oss-security/2020/11/01/1
Cc: #v3.6
Signed-off-by: Xiaoming Ni
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/nfc/llcp_sock.c |2 ++
1 file changed, 2 insertions(+)
--- a/net/nfc/llcp_sock.c
+++ b/net/nfc/llcp_sock.c
@@ -710,6 +710,7 @@ static int llcp_sock_connect(struct sock
llcp_sock->local = nfc_llcp_local_get(local);
llcp_sock->ssap = nfc_llcp_get_local_ssap(local);
if (llcp_sock->ssap == LLCP_SAP_MAX) {
+ nfc_llcp_local_put(llcp_sock->local);
ret = -ENOMEM;
goto put_dev;
}
@@ -747,6 +748,7 @@ static int llcp_sock_connect(struct sock
sock_unlink:
nfc_llcp_put_ssap(local, llcp_sock->ssap);
+ nfc_llcp_local_put(llcp_sock->local);
nfc_llcp_sock_unlink(>connecting_sockets, sk);
[PATCH 4.4 26/38] net: mac802154: Fix general protection fault
From: Pavel Skripkin commit 1165affd484889d4986cf3b724318935a0b120d8 upstream. syzbot found general protection fault in crypto_destroy_tfm()[1]. It was caused by wrong clean up loop in llsec_key_alloc(). If one of the tfm array members is in IS_ERR() range it will cause general protection fault in clean up function [1]. Call Trace: crypto_free_aead include/crypto/aead.h:191 [inline] [1] llsec_key_alloc net/mac802154/llsec.c:156 [inline] mac802154_llsec_key_add+0x9e0/0xcc0 net/mac802154/llsec.c:249 ieee802154_add_llsec_key+0x56/0x80 net/mac802154/cfg.c:338 rdev_add_llsec_key net/ieee802154/rdev-ops.h:260 [inline] nl802154_add_llsec_key+0x3d3/0x560 net/ieee802154/nl802154.c:1584 genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:800 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by: Pavel Skripkin Reported-by: syzbot+9ec037722d2603a9f...@syzkaller.appspotmail.com Acked-by: Alexander Aring Link: https://lore.kernel.org/r/20210304152125.1052825-1-paskrip...@gmail.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman --- net/mac802154/llsec.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/mac802154/llsec.c +++ b/net/mac802154/llsec.c @@ -158,7 +158,7 @@ err_tfm0: crypto_free_blkcipher(key->tfm0); err_tfm: for (i = 0; i < ARRAY_SIZE(key->tfm); i++) - if (key->tfm[i]) + if (!IS_ERR_OR_NULL(key->tfm[i])) crypto_free_aead(key->tfm[i]); kzfree(key);
[PATCH 4.4 03/38] nfc: fix refcount leak in llcp_sock_bind()
From: Xiaoming Ni
commit c33b1cc62ac05c1dbb1cdafe2eb66da01c76ca8d upstream.
nfc_llcp_local_get() is invoked in llcp_sock_bind(),
but nfc_llcp_local_put() is not invoked in subsequent failure branches.
As a result, refcount leakage occurs.
To fix it, add calling nfc_llcp_local_put().
fix CVE-2020-25670
Fixes: c7aa12252f51 ("NFC: Take a reference on the LLCP local pointer when
creating a socket")
Reported-by: "kiyin(尹亮)"
Link: https://www.openwall.com/lists/oss-security/2020/11/01/1
Cc: #v3.6
Signed-off-by: Xiaoming Ni
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/nfc/llcp_sock.c |2 ++
1 file changed, 2 insertions(+)
--- a/net/nfc/llcp_sock.c
+++ b/net/nfc/llcp_sock.c
@@ -119,11 +119,13 @@ static int llcp_sock_bind(struct socket
llcp_sock->service_name_len,
GFP_KERNEL);
if (!llcp_sock->service_name) {
+ nfc_llcp_local_put(llcp_sock->local);
ret = -ENOMEM;
goto put_dev;
}
llcp_sock->ssap = nfc_llcp_get_sdp_ssap(local, llcp_sock);
if (llcp_sock->ssap == LLCP_SAP_MAX) {
+ nfc_llcp_local_put(llcp_sock->local);
kfree(llcp_sock->service_name);
llcp_sock->service_name = NULL;
ret = -EADDRINUSE;
[PATCH 4.4 25/38] drivers: net: fix memory leak in peak_usb_create_dev
From: Pavel Skripkin commit a0b96b4a62745397aee662670cfc2157bac03f55 upstream. syzbot reported memory leak in peak_usb. The problem was in case of failure after calling ->dev_init()[2] in peak_usb_create_dev()[1]. The data allocated int dev_init() wasn't freed, so simple ->dev_free() call fix this problem. backtrace: [<79d6542a>] kmalloc include/linux/slab.h:552 [inline] [<79d6542a>] kzalloc include/linux/slab.h:682 [inline] [<79d6542a>] pcan_usb_fd_init+0x156/0x210 drivers/net/can/usb/peak_usb/pcan_usb_fd.c:868 [2] [] peak_usb_create_dev drivers/net/can/usb/peak_usb/pcan_usb_core.c:851 [inline] [1] [ ] peak_usb_probe+0x389/0x490 drivers/net/can/usb/peak_usb/pcan_usb_core.c:949 Reported-by: syzbot+91adee8d9ebb9193d...@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- drivers/net/can/usb/peak_usb/pcan_usb_core.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c +++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c @@ -882,7 +882,7 @@ static int peak_usb_create_dev(const str if (dev->adapter->dev_set_bus) { err = dev->adapter->dev_set_bus(dev, 0); if (err) - goto lbl_unregister_candev; + goto adap_dev_free; } /* get device number early */ @@ -894,6 +894,10 @@ static int peak_usb_create_dev(const str return 0; +adap_dev_free: + if (dev->adapter->dev_free) + dev->adapter->dev_free(dev); + lbl_unregister_candev: unregister_candev(netdev);
[PATCH 4.4 24/38] drivers: net: fix memory leak in atusb_probe
From: Pavel Skripkin commit 6b9fbe16955152626557ec6f439f3407b7769941 upstream. syzbot reported memory leak in atusb_probe()[1]. The problem was in atusb_alloc_urbs(). Since urb is anchored, we need to release the reference to correctly free the urb backtrace: [] kmalloc include/linux/slab.h:559 [inline] [] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74 [] atusb_alloc_urbs drivers/net/ieee802154/atusb.c:362 [inline][2] [] atusb_probe+0x158/0x820 drivers/net/ieee802154/atusb.c:1038 [1] Reported-by: syzbot+28a246747e0a46512...@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- drivers/net/ieee802154/atusb.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/net/ieee802154/atusb.c +++ b/drivers/net/ieee802154/atusb.c @@ -340,6 +340,7 @@ static int atusb_alloc_urbs(struct atusb return -ENOMEM; } usb_anchor_urb(urb, >idle_urbs); + usb_free_urb(urb); n--; } return 0;
[PATCH 4.4 22/38] cfg80211: remove WARN_ON() in cfg80211_sme_connect
From: Du Cheng commit 1b5ab825d9acc0f27d2f25c6252f3526832a9626 upstream. A WARN_ON(wdev->conn) would trigger in cfg80211_sme_connect(), if multiple send_msg(NL80211_CMD_CONNECT) system calls are made from the userland, which should be anticipated and handled by the wireless driver. Remove this WARN_ON() to prevent kernel panic if kernel is configured to "panic_on_warn". Bug reported by syzbot. Reported-by: syzbot+5f9392825de654244...@syzkaller.appspotmail.com Signed-off-by: Du Cheng Link: https://lore.kernel.org/r/20210407162756.6101-1-duche...@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman --- net/wireless/sme.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/wireless/sme.c +++ b/net/wireless/sme.c @@ -507,7 +507,7 @@ static int cfg80211_sme_connect(struct w if (wdev->current_bss) return -EALREADY; - if (WARN_ON(wdev->conn)) + if (wdev->conn) return -EINPROGRESS; wdev->conn = kzalloc(sizeof(*wdev->conn), GFP_KERNEL);
[PATCH 4.4 23/38] net: tun: set tun->dev->addr_len during TUNSETLINK processing
From: Phillip Potter
commit cca8ea3b05c972ffb5295367e6c544369b45fbdd upstream.
When changing type with TUNSETLINK ioctl command, set tun->dev->addr_len
to match the appropriate type, using new tun_get_addr_len utility function
which returns appropriate address length for given type. Fixes a
KMSAN-found uninit-value bug reported by syzbot at:
https://syzkaller.appspot.com/bug?id=0766d38c656abeace60621896d705743aeefed51
Reported-by: syzbot+001516d86dbe88862...@syzkaller.appspotmail.com
Diagnosed-by: Eric Dumazet
Signed-off-by: Phillip Potter
Reviewed-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/tun.c | 48
1 file changed, 48 insertions(+)
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -71,6 +71,14 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
#include
@@ -1888,6 +1896,45 @@ unlock:
return ret;
}
+/* Return correct value for tun->dev->addr_len based on tun->dev->type. */
+static unsigned char tun_get_addr_len(unsigned short type)
+{
+ switch (type) {
+ case ARPHRD_IP6GRE:
+ case ARPHRD_TUNNEL6:
+ return sizeof(struct in6_addr);
+ case ARPHRD_IPGRE:
+ case ARPHRD_TUNNEL:
+ case ARPHRD_SIT:
+ return 4;
+ case ARPHRD_ETHER:
+ return ETH_ALEN;
+ case ARPHRD_IEEE802154:
+ case ARPHRD_IEEE802154_MONITOR:
+ return IEEE802154_EXTENDED_ADDR_LEN;
+ case ARPHRD_PHONET_PIPE:
+ case ARPHRD_PPP:
+ case ARPHRD_NONE:
+ return 0;
+ case ARPHRD_6LOWPAN:
+ return EUI64_ADDR_LEN;
+ case ARPHRD_FDDI:
+ return FDDI_K_ALEN;
+ case ARPHRD_HIPPI:
+ return HIPPI_ALEN;
+ case ARPHRD_IEEE802:
+ return FC_ALEN;
+ case ARPHRD_ROSE:
+ return ROSE_ADDR_LEN;
+ case ARPHRD_NETROM:
+ return AX25_ADDR_LEN;
+ case ARPHRD_LOCALTLK:
+ return LTALK_ALEN;
+ default:
+ return 0;
+ }
+}
+
static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
unsigned long arg, int ifreq_len)
{
@@ -2026,6 +2073,7 @@ static long __tun_chr_ioctl(struct file
ret = -EBUSY;
} else {
tun->dev->type = (int) arg;
+ tun->dev->addr_len = tun_get_addr_len(tun->dev->type);
tun_debug(KERN_INFO, tun, "linktype set to %d\n",
tun->dev->type);
ret = 0;
[PATCH 4.4 21/38] clk: socfpga: fix iomem pointer cast on 64-bit
From: Krzysztof Kozlowski
commit 2867b9746cef78745c594894aece6f8ef826e0b4 upstream.
Pointers should be cast with uintptr_t instead of integer. This fixes
warning when compile testing on ARM64:
drivers/clk/socfpga/clk-gate.c: In function ‘socfpga_clk_recalc_rate’:
drivers/clk/socfpga/clk-gate.c:102:7: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
Fixes: b7cec13f082f ("clk: socfpga: Look for the GPIO_DB_CLK by its offset")
Signed-off-by: Krzysztof Kozlowski
Acked-by: Dinh Nguyen
Link:
https://lore.kernel.org/r/20210314110709.32599-1-krzysztof.kozlow...@canonical.com
Signed-off-by: Stephen Boyd
Signed-off-by: Greg Kroah-Hartman
---
drivers/clk/socfpga/clk-gate.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/clk/socfpga/clk-gate.c
+++ b/drivers/clk/socfpga/clk-gate.c
@@ -107,7 +107,7 @@ static unsigned long socfpga_clk_recalc_
val = readl(socfpgaclk->div_reg) >> socfpgaclk->shift;
val &= GENMASK(socfpgaclk->width - 1, 0);
/* Check for GPIO_DB_CLK by its offset */
- if ((int) socfpgaclk->div_reg & SOCFPGA_GPIO_DB_CLK_OFFSET)
+ if ((uintptr_t) socfpgaclk->div_reg &
SOCFPGA_GPIO_DB_CLK_OFFSET)
div = val + 1;
else
div = (1 << val);
[PATCH 4.4 20/38] RDMA/cxgb4: check for ipv6 address properly while destroying listener
From: Potnuri Bharat Teja
[ Upstream commit 603c4690b01aaffe3a6c3605a429f6dac39852ae ]
ipv6 bit is wrongly set by the below which causes fatal adapter lookup
engine errors for ipv4 connections while destroying a listener. Fix it to
properly check the local address for ipv6.
Fixes: 3408be145a5d ("RDMA/cxgb4: Fix adapter LE hash errors while destroying
ipv6 listening server")
Link: https://lore.kernel.org/r/20210331135715.30072-1-bha...@chelsio.com
Signed-off-by: Potnuri Bharat Teja
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/hw/cxgb4/cm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/cxgb4/cm.c b/drivers/infiniband/hw/cxgb4/cm.c
index 8d75161854ee..f422a8a2528b 100644
--- a/drivers/infiniband/hw/cxgb4/cm.c
+++ b/drivers/infiniband/hw/cxgb4/cm.c
@@ -3447,7 +3447,8 @@ int c4iw_destroy_listen(struct iw_cm_id *cm_id)
c4iw_init_wr_wait(>com.wr_wait);
err = cxgb4_remove_server(
ep->com.dev->rdev.lldi.ports[0], ep->stid,
- ep->com.dev->rdev.lldi.rxq_ids[0], true);
+ ep->com.dev->rdev.lldi.rxq_ids[0],
+ ep->com.local_addr.ss_family == AF_INET6);
if (err)
goto done;
err = c4iw_wait_for_reply(>com.dev->rdev, >com.wr_wait,
--
2.30.2
[PATCH 4.4 02/38] ALSA: aloop: Fix initialization of controls
From: Jonas Holmberg
commit 168632a495f49f33a18c2d502fc249d7610375e9 upstream.
Add a control to the card before copying the id so that the numid field
is initialized in the copy. Otherwise the numid field of active_id,
format_id, rate_id and channels_id will be the same (0) and
snd_ctl_notify() will not queue the events properly.
Signed-off-by: Jonas Holmberg
Reviewed-by: Jaroslav Kysela
Cc:
Link: https://lore.kernel.org/r/20210407075428.2666787-1-jona...@axis.com
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/drivers/aloop.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -1062,6 +1062,14 @@ static int loopback_mixer_new(struct loo
return -ENOMEM;
kctl->id.device = dev;
kctl->id.subdevice = substr;
+
+ /* Add the control before copying the id so that
+* the numid field of the id is set in the copy.
+*/
+ err = snd_ctl_add(card, kctl);
+ if (err < 0)
+ return err;
+
switch (idx) {
case ACTIVE_IDX:
setup->active_id = kctl->id;
@@ -1078,9 +1086,6 @@ static int loopback_mixer_new(struct loo
default:
break;
}
- err = snd_ctl_add(card, kctl);
- if (err < 0)
- return err;
}
}
}
[PATCH 4.4 19/38] s390/cpcmd: fix inline assembly register clobbering
From: Alexander Gordeev
[ Upstream commit 7a2f91441b2c1d81b77c1cd816a4659f4abc9cbe ]
Register variables initialized using arithmetic. That leads to
kasan instrumentaton code corrupting the registers contents.
Follow GCC guidlines and use temporary variables for assigning
init values to register variables.
Fixes: 94c12cc7d196 ("[S390] Inline assembly cleanup.")
Signed-off-by: Alexander Gordeev
Acked-by: Ilya Leoshkevich
Link:
https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Local-Register-Variables.html
Signed-off-by: Heiko Carstens
Signed-off-by: Sasha Levin
---
arch/s390/kernel/cpcmd.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/s390/kernel/cpcmd.c b/arch/s390/kernel/cpcmd.c
index 7f768914fb4f..c15546c6fb66 100644
--- a/arch/s390/kernel/cpcmd.c
+++ b/arch/s390/kernel/cpcmd.c
@@ -37,10 +37,12 @@ static int diag8_noresponse(int cmdlen)
static int diag8_response(int cmdlen, char *response, int *rlen)
{
+ unsigned long _cmdlen = cmdlen | 0x4000L;
+ unsigned long _rlen = *rlen;
register unsigned long reg2 asm ("2") = (addr_t) cpcmd_buf;
register unsigned long reg3 asm ("3") = (addr_t) response;
- register unsigned long reg4 asm ("4") = cmdlen | 0x4000L;
- register unsigned long reg5 asm ("5") = *rlen;
+ register unsigned long reg4 asm ("4") = _cmdlen;
+ register unsigned long reg5 asm ("5") = _rlen;
asm volatile(
" sam31\n"
--
2.30.2
[PATCH 4.4 18/38] workqueue: Move the position of debug_work_activate() in __queue_work()
From: Zqiang
[ Upstream commit 0687c66b5f666b5ad433f4e94251590d9bc9d10e ]
The debug_work_activate() is called on the premise that
the work can be inserted, because if wq be in WQ_DRAINING
status, insert work may be failed.
Fixes: e41e704bc4f4 ("workqueue: improve destroy_workqueue() debuggability")
Signed-off-by: Zqiang
Reviewed-by: Lai Jiangshan
Signed-off-by: Tejun Heo
Signed-off-by: Sasha Levin
---
kernel/workqueue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 6b293804cd73..a2de597604e6 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1351,7 +1351,6 @@ static void __queue_work(int cpu, struct workqueue_struct
*wq,
*/
WARN_ON_ONCE(!irqs_disabled());
- debug_work_activate(work);
/* if draining, only works from the same workqueue are allowed */
if (unlikely(wq->flags & __WQ_DRAINING) &&
@@ -1430,6 +1429,7 @@ retry:
worklist = >delayed_works;
}
+ debug_work_activate(work);
insert_work(pwq, work, worklist, work_flags);
spin_unlock(>pool->lock);
--
2.30.2
[PATCH 4.4 16/38] net:tipc: Fix a double free in tipc_sk_mcast_rcv
From: Lv Yunlong
[ Upstream commit 6bf24dc0cc0cc43b29ba344b66d78590e687e046 ]
In the if(skb_peek(arrvq) == skb) branch, it calls __skb_dequeue(arrvq) to get
the skb by skb = skb_peek(arrvq). Then __skb_dequeue() unlinks the skb from
arrvq
and returns the skb which equals to skb_peek(arrvq). After __skb_dequeue(arrvq)
finished, the skb is freed by kfree_skb(__skb_dequeue(arrvq)) in the first time.
Unfortunately, the same skb is freed in the second time by kfree_skb(skb) after
the branch completed.
My patch removes kfree_skb() in the if(skb_peek(arrvq) == skb) branch, because
this skb will be freed by kfree_skb(skb) finally.
Fixes: cb1b728096f54 ("tipc: eliminate race condition at multicast reception")
Signed-off-by: Lv Yunlong
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
net/tipc/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 65171f8e8c45..0e5bb03c6425 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -763,7 +763,7 @@ void tipc_sk_mcast_rcv(struct net *net, struct sk_buff_head
*arrvq,
spin_lock_bh(>lock);
if (skb_peek(arrvq) == skb) {
skb_queue_splice_tail_init(, inputq);
- kfree_skb(__skb_dequeue(arrvq));
+ __skb_dequeue(arrvq);
}
spin_unlock_bh(>lock);
__skb_queue_purge();
--
2.30.2
[PATCH 4.4 17/38] clk: fix invalid usage of list cursor in unregister
From: Lukasz Bartosik
[ Upstream commit 7045465500e465b09f09d6e5bdc260a9f1aab97b ]
Fix invalid usage of a list_for_each_entry cursor in
clk_notifier_unregister(). When list is empty or if the list
is completely traversed (without breaking from the loop on one
of the entries) then the list cursor does not point to a valid
entry and therefore should not be used. The patch fixes a logical
bug that hasn't been seen in pratice however it is analogus
to the bug fixed in clk_notifier_register().
The issue was dicovered when running 5.12-rc1 kernel on x86_64
with KASAN enabled:
BUG: KASAN: global-out-of-bounds in clk_notifier_register+0xab/0x230
Read of size 8 at addr a0d10588 by task swapper/0/1
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc1 #1
Hardware name: Google Caroline/Caroline,
BIOS Google_Caroline.7820.430.0 07/20/2018
Call Trace:
dump_stack+0xee/0x15c
print_address_description+0x1e/0x2dc
kasan_report+0x188/0x1ce
? clk_notifier_register+0xab/0x230
? clk_prepare_lock+0x15/0x7b
? clk_notifier_register+0xab/0x230
clk_notifier_register+0xab/0x230
dw8250_probe+0xc01/0x10d4
...
Memory state around the buggy address:
a0d10480: 00 00 00 00 00 03 f9 f9 f9 f9 f9 f9 00 00 00 00
a0d10500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9
>a0d10580: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
^
a0d10600: 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 00 00 00 00
a0d10680: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 00 00 00 00
==
Fixes: b2476490ef11 ("clk: introduce the common clock framework")
Reported-by: Lukasz Majczak
Signed-off-by: Lukasz Bartosik
Link: https://lore.kernel.org/r/20210401225149.18826-2...@semihalf.com
Signed-off-by: Stephen Boyd
Signed-off-by: Sasha Levin
---
drivers/clk/clk.c | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 53c068f90b37..c46fff3a32fe 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2870,32 +2870,28 @@ EXPORT_SYMBOL_GPL(clk_notifier_register);
*/
int clk_notifier_unregister(struct clk *clk, struct notifier_block *nb)
{
- struct clk_notifier *cn = NULL;
- int ret = -EINVAL;
+ struct clk_notifier *cn;
+ int ret = -ENOENT;
if (!clk || !nb)
return -EINVAL;
clk_prepare_lock();
- list_for_each_entry(cn, _notifier_list, node)
- if (cn->clk == clk)
- break;
-
- if (cn->clk == clk) {
- ret = srcu_notifier_chain_unregister(>notifier_head, nb);
+ list_for_each_entry(cn, _notifier_list, node) {
+ if (cn->clk == clk) {
+ ret =
srcu_notifier_chain_unregister(>notifier_head, nb);
- clk->core->notifier_count--;
+ clk->core->notifier_count--;
- /* XXX the notifier code should handle this better */
- if (!cn->notifier_head.head) {
- srcu_cleanup_notifier_head(>notifier_head);
- list_del(>node);
- kfree(cn);
+ /* XXX the notifier code should handle this better */
+ if (!cn->notifier_head.head) {
+ srcu_cleanup_notifier_head(>notifier_head);
+ list_del(>node);
+ kfree(cn);
+ }
+ break;
}
-
- } else {
- ret = -ENOENT;
}
clk_prepare_unlock();
--
2.30.2
[PATCH 4.4 15/38] gianfar: Handle error code at MAC address change
From: Claudiu Manoil
[ Upstream commit bff5b62585123823842833ab20b1c0a7fa437f8c ]
Handle return error code of eth_mac_addr();
Fixes: 3d23a05c75c7 ("gianfar: Enable changing mac addr when if up")
Signed-off-by: Claudiu Manoil
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/freescale/gianfar.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c
b/drivers/net/ethernet/freescale/gianfar.c
index bc00fa5e864f..fb135797688a 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -485,7 +485,11 @@ static struct net_device_stats *gfar_get_stats(struct
net_device *dev)
static int gfar_set_mac_addr(struct net_device *dev, void *p)
{
- eth_mac_addr(dev, p);
+ int ret;
+
+ ret = eth_mac_addr(dev, p);
+ if (ret)
+ return ret;
gfar_set_mac_for_addr(dev, 0, dev->dev_addr);
--
2.30.2
[PATCH 4.4 14/38] sch_red: fix off-by-one checks in red_check_params()
From: Eric Dumazet
[ Upstream commit 3a87571f0ffc51ba3bf3ecdb6032861d0154b164 ]
This fixes following syzbot report:
UBSAN: shift-out-of-bounds in ./include/net/red.h:237:23
shift exponent 32 is too large for 32-bit type 'unsigned int'
CPU: 1 PID: 8418 Comm: syz-executor170 Not tainted
5.12.0-rc4-next-20210324-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x141/0x1d7 lib/dump_stack.c:120
ubsan_epilogue+0xb/0x5a lib/ubsan.c:148
__ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327
red_set_parms include/net/red.h:237 [inline]
choke_change.cold+0x3c/0xc8 net/sched/sch_choke.c:414
qdisc_create+0x475/0x12f0 net/sched/sch_api.c:1247
tc_modify_qdisc+0x4c8/0x1a50 net/sched/sch_api.c:1663
rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553
netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502
netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338
netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927
sock_sendmsg_nosec net/socket.c:654 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:674
sys_sendmsg+0x6e8/0x810 net/socket.c:2350
___sys_sendmsg+0xf3/0x170 net/socket.c:2404
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x43f039
Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 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 73 01
c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:7ffdfa725168 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 00400488 RCX: 0043f039
RDX: RSI: 2040 RDI: 0004
RBP: 00403020 R08: 00400488 R09: 00400488
R10: 00400488 R11: 0246 R12: 004030b0
R13: R14: 004ac018 R15: 00400488
Fixes: 8afa10cbe281 ("net_sched: red: Avoid illegal values")
Signed-off-by: Eric Dumazet
Reported-by: syzbot
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
include/net/red.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/net/red.h b/include/net/red.h
index b3ab5c6bfa83..117a3654d319 100644
--- a/include/net/red.h
+++ b/include/net/red.h
@@ -170,9 +170,9 @@ static inline void red_set_vars(struct red_vars *v)
static inline bool red_check_params(u32 qth_min, u32 qth_max, u8 Wlog,
u8 Scell_log, u8 *stab)
{
- if (fls(qth_min) + Wlog > 32)
+ if (fls(qth_min) + Wlog >= 32)
return false;
- if (fls(qth_max) + Wlog > 32)
+ if (fls(qth_max) + Wlog >= 32)
return false;
if (Scell_log >= 32)
return false;
--
2.30.2
[PATCH 4.4 13/38] net: sched: sch_teql: fix null-pointer dereference
From: Pavel Tikhomirov
commit 1ffbc7ea91606e4abd10eb60de5367f1c86daf5e upstream.
Reproduce:
modprobe sch_teql
tc qdisc add dev teql0 root teql0
This leads to (for instance in Centos 7 VM) OOPS:
[ 532.366633] BUG: unable to handle kernel NULL pointer dereference at
00a8
[ 532.366733] IP: [] teql_destroy+0x18/0x100 [sch_teql]
[ 532.366825] PGD 8001376d5067 PUD 137e37067 PMD 0
[ 532.366906] Oops: [#1] SMP
[ 532.366987] Modules linked in: sch_teql ...
[ 532.367945] CPU: 1 PID: 3026 Comm: tc Kdump: loaded Tainted: G
T 3.10.0-1062.7.1.el7.x86_64 #1
[ 532.368041] Hardware name: Virtuozzo KVM, BIOS 1.11.0-2.vz7.2 04/01/2014
[ 532.368125] task: 8b7d37d31070 ti: 8b7c9fdbc000 task.ti:
8b7c9fdbc000
[ 532.368224] RIP: 0010:[] []
teql_destroy+0x18/0x100 [sch_teql]
[ 532.368320] RSP: 0018:8b7c9fdbf8e0 EFLAGS: 00010286
[ 532.368394] RAX: c0612490 RBX: 8b7cb1565e00 RCX: 8b7d35ba2000
[ 532.368476] RDX: 8b7d35ba2000 RSI: RDI: 8b7cb1565e00
[ 532.368557] RBP: 8b7c9fdbf8f8 R08: 8b7d3fd1f140 R09: 8b7d3b001600
[ 532.368638] R10: 8b7d3b001600 R11: 84c7d65b R12: ffd8
[ 532.368719] R13: 8000 R14: 8b7d35ba2000 R15: 8b7c9fdbf9a8
[ 532.368800] FS: 7f6a4e872740() GS:8b7d3fd0()
knlGS:
[ 532.368885] CS: 0010 DS: ES: CR0: 80050033
[ 532.368961] CR2: 00a8 CR3: 0001396ee000 CR4: 000206e0
[ 532.369046] Call Trace:
[ 532.369159] [] qdisc_create+0x36e/0x450
[ 532.369268] [] ? ns_capable+0x29/0x50
[ 532.369366] [] ? nla_parse+0x32/0x120
[ 532.369442] [] tc_modify_qdisc+0x13c/0x610
[ 532.371508] [] rtnetlink_rcv_msg+0xa7/0x260
[ 532.372668] [] ? sock_has_perm+0x75/0x90
[ 532.373790] [] ? rtnl_newlink+0x890/0x890
[ 532.374914] [] netlink_rcv_skb+0xab/0xc0
[ 532.376055] [] rtnetlink_rcv+0x28/0x30
[ 532.377204] [] netlink_unicast+0x170/0x210
[ 532.378333] [] netlink_sendmsg+0x308/0x420
[ 532.379465] [] sock_sendmsg+0xb6/0xf0
[ 532.380710] [] ? __xfs_filemap_fault+0x8e/0x1d0 [xfs]
[ 532.381868] [] ? xfs_filemap_fault+0x2c/0x30 [xfs]
[ 532.383037] [] ? __do_fault.isra.61+0x8a/0x100
[ 532.384144] [] ___sys_sendmsg+0x3e9/0x400
[ 532.385268] [] ? handle_mm_fault+0x39d/0x9b0
[ 532.386387] [] ? __do_page_fault+0x238/0x500
[ 532.387472] [] __sys_sendmsg+0x51/0x90
[ 532.388560] [] SyS_sendmsg+0x12/0x20
[ 532.389636] [] system_call_fastpath+0x25/0x2a
[ 532.390704] [] ? system_call_after_swapgs+0xae/0x146
[ 532.391753] Code: 00 00 00 00 00 00 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00
66 66 66 66 90 55 48 89 e5 41 55 41 54 53 48 8b b7 48 01 00 00 48 89 fb <48> 8b
8e a8 00 00 00 48 85 c9 74 43 48 89 ca eb 0f 0f 1f 80 00
[ 532.394036] RIP [] teql_destroy+0x18/0x100 [sch_teql]
[ 532.395127] RSP
[ 532.396179] CR2: 00a8
Null pointer dereference happens on master->slaves dereference in
teql_destroy() as master is null-pointer.
When qdisc_create() calls teql_qdisc_init() it imediately fails after
check "if (m->dev == dev)" because both devices are teql0, and it does
not set qdisc_priv(sch)->m leaving it zero on error path, then
qdisc_create() imediately calls teql_destroy() which does not expect
zero master pointer and we get OOPS.
Fixes: 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation")
Signed-off-by: Pavel Tikhomirov
Reviewed-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/sched/sch_teql.c |3 +++
1 file changed, 3 insertions(+)
--- a/net/sched/sch_teql.c
+++ b/net/sched/sch_teql.c
@@ -138,6 +138,9 @@ teql_destroy(struct Qdisc *sch)
struct teql_sched_data *dat = qdisc_priv(sch);
struct teql_master *master = dat->m;
+ if (!master)
+ return;
+
prev = master->slaves;
if (prev) {
do {
Re: [PATCH v3 01/12] drm/bridge: Fix the stop condition of drm_bridge_chain_pre_enable()
Hi,
On Wed, Apr 14, 2021 at 6:56 PM Laurent Pinchart
wrote:
>
> Hi Doug,
>
> On Wed, Apr 14, 2021 at 06:19:13PM -0700, Doug Anderson wrote:
> > On Sun, Apr 4, 2021 at 5:50 PM Laurent Pinchart wrote:
> > > On Fri, Apr 02, 2021 at 03:28:35PM -0700, Douglas Anderson wrote:
> > > > The drm_bridge_chain_pre_enable() is not the proper opposite of
> > > > drm_bridge_chain_post_disable(). It continues along the chain to
> > > > _before_ the starting bridge. Let's fix that.
> > > >
> > > > Fixes: 05193dc38197 ("drm/bridge: Make the bridge chain a double-linked
> > > > list")
> > > > Signed-off-by: Douglas Anderson
> > > > Reviewed-by: Andrzej Hajda
> > > > ---
> > > >
> > > > (no changes since v1)
> > > >
> > > > drivers/gpu/drm/drm_bridge.c | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > > > index 64f0effb52ac..044acd07c153 100644
> > > > --- a/drivers/gpu/drm/drm_bridge.c
> > > > +++ b/drivers/gpu/drm/drm_bridge.c
> > > > @@ -522,6 +522,9 @@ void drm_bridge_chain_pre_enable(struct drm_bridge
> > > > *bridge)
> > > > list_for_each_entry_reverse(iter, >bridge_chain,
> > > > chain_node) {
> > > > if (iter->funcs->pre_enable)
> > > > iter->funcs->pre_enable(iter);
> > > > +
> > > > + if (iter == bridge)
> > > > + break;
> > >
> > > This looks good as it matches drm_atomic_bridge_chain_disable().
> > >
> > > Reviewed-by: Laurent Pinchart
> >
> > Thanks for your review here and several of the other patches. Can you
> > suggest any plan for getting them landed? It would at least be nice to
> > get the non-controversial ones landed.
>
> Do you have commit access to drm-misc ? If not, given your
> contributions, I think you qualify for it.
No, I don't have access. I searched for how to get it and read through
the qualifications and, you're right, I think I do. I've hopefully
followed the right flow and created an issue to give me ssh access:
https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/348
Is that something you (or someone else on this CC list) approves?
> > > I'm curious though, given that the bridge passed to the function should
> > > be the one closest to the encoder, does this make a difference ?
> >
> > Yes, that's how I discovered it originally. Let's see. So if I don't
> > have this patch but have the rest of the series then I get a splat at
> > bootup. This shows that dsi_mgr_bridge_pre_enable() must be "earlier"
> > in the chain than my bridge chip. Here's the splat:
>
> Right, I think it's caused by a later patch in the series calling this
> function with a different bridge than the one closest to the encoder.
Yup! I still wanted this patch to be first in the series, though,
since it's a bugfix that we'd want to land even if the later patches
changed in some way.
-Doug
[PATCH 4.4 11/38] parisc: parisc-agp requires SBA IOMMU driver
From: Helge Deller commit 9054284e8846b0105aad43a4e7174ca29fffbc44 upstream. Add a dependency to the SBA IOMMU driver to avoid: ERROR: modpost: "sba_list" [drivers/char/agp/parisc-agp.ko] undefined! Reported-by: kernel test robot Cc: sta...@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman --- drivers/char/agp/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/char/agp/Kconfig +++ b/drivers/char/agp/Kconfig @@ -124,7 +124,7 @@ config AGP_HP_ZX1 config AGP_PARISC tristate "HP Quicksilver AGP support" - depends on AGP && PARISC && 64BIT + depends on AGP && PARISC && 64BIT && IOMMU_SBA help This option gives you AGP GART support for the HP Quicksilver AGP bus adapter on HP PA-RISC machines (Ok, just on the C8000
[PATCH 4.4 12/38] batman-adv: initialize "struct batadv_tvlv_tt_vlan_data"->reserved field
From: Tetsuo Handa
commit 08c27f3322fec11950b8f1384aa0f3b11d028528 upstream.
KMSAN found uninitialized value at batadv_tt_prepare_tvlv_local_data()
[1], for commit ced72933a5e8ab52 ("batman-adv: use CRC32C instead of CRC16
in TT code") inserted 'reserved' field into "struct batadv_tvlv_tt_data"
and commit 7ea7b4a142758dea ("batman-adv: make the TT CRC logic VLAN
specific") moved that field to "struct batadv_tvlv_tt_vlan_data" but left
that field uninitialized.
[1]
https://syzkaller.appspot.com/bug?id=07f3e6dba96f0eb3cabab986adcd8a58b9bdbe9d
Reported-by: syzbot
Tested-by: syzbot
Signed-off-by: Tetsuo Handa
Fixes: ced72933a5e8ab52 ("batman-adv: use CRC32C instead of CRC16 in TT code")
Fixes: 7ea7b4a142758dea ("batman-adv: make the TT CRC logic VLAN specific")
Acked-by: Sven Eckelmann
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/batman-adv/translation-table.c |1 +
1 file changed, 1 insertion(+)
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -871,6 +871,7 @@ batadv_tt_prepare_tvlv_local_data(struct
tt_vlan->vid = htons(vlan->vid);
tt_vlan->crc = htonl(vlan->tt.crc);
+ tt_vlan->reserved = 0;
tt_vlan++;
}
[PATCH 4.4 10/38] fs: direct-io: fix missing sdio->boundary
From: Jack Qiu
commit df41872b68601059dd4a84858952dcae58acd331 upstream.
I encountered a hung task issue, but not a performance one. I run DIO
on a device (need lba continuous, for example open channel ssd), maybe
hungtask in below case:
DIO: Checkpoint:
get addr A(at boundary), merge into BIO,
no submit because boundary missing
flush dirty data(get addr A+1),
wait IO(A+1)
writeback timeout, because
DIO(A) didn't submit
get addr A+2 fail, because checkpoint is doing
dio_send_cur_page() may clear sdio->boundary, so prevent it from missing
a boundary.
Link: https://lkml.kernel.org/r/20210322042253.38312-1-jack@huawei.com
Fixes: b1058b981272 ("direct-io: submit bio after boundary buffer is added to
it")
Signed-off-by: Jack Qiu
Reviewed-by: Jan Kara
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
fs/direct-io.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -780,6 +780,7 @@ submit_page_section(struct dio *dio, str
struct buffer_head *map_bh)
{
int ret = 0;
+ int boundary = sdio->boundary; /* dio_send_cur_page may clear it */
if (dio->rw & WRITE) {
/*
@@ -818,10 +819,10 @@ submit_page_section(struct dio *dio, str
sdio->cur_page_fs_offset = sdio->block_in_file << sdio->blkbits;
out:
/*
-* If sdio->boundary then we want to schedule the IO now to
+* If boundary then we want to schedule the IO now to
* avoid metadata seeks.
*/
- if (sdio->boundary) {
+ if (boundary) {
ret = dio_send_cur_page(dio, sdio, map_bh);
if (sdio->bio)
dio_bio_submit(dio, sdio);
[PATCH 4.4 01/38] iio: hid-sensor-prox: Fix scale not correct issue
From: Ye Xiang
commit d68c592e02f6f49a88e705f13dfc1883432cf300 upstream
Currently, the proxy sensor scale is zero because it just return the
exponent directly. To fix this issue, this patch use
hid_sensor_format_scale to process the scale first then return the
output.
Fixes: 39a3a0138f61 ("iio: hid-sensors: Added Proximity Sensor Driver")
Signed-off-by: Ye Xiang
Link: https://lore.kernel.org/r/20210130102530.31064-1-xiang...@intel.com
Cc:
Signed-off-by: Jonathan Cameron
[sudip: adjust context]
Signed-off-by: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman
---
drivers/iio/light/hid-sensor-prox.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
--- a/drivers/iio/light/hid-sensor-prox.c
+++ b/drivers/iio/light/hid-sensor-prox.c
@@ -37,6 +37,9 @@ struct prox_state {
struct hid_sensor_common common_attributes;
struct hid_sensor_hub_attribute_info prox_attr;
u32 human_presence;
+ int scale_pre_decml;
+ int scale_post_decml;
+ int scale_precision;
};
/* Channel definitions */
@@ -105,8 +108,9 @@ static int prox_read_raw(struct iio_dev
ret_type = IIO_VAL_INT;
break;
case IIO_CHAN_INFO_SCALE:
- *val = prox_state->prox_attr.units;
- ret_type = IIO_VAL_INT;
+ *val = prox_state->scale_pre_decml;
+ *val2 = prox_state->scale_post_decml;
+ ret_type = prox_state->scale_precision;
break;
case IIO_CHAN_INFO_OFFSET:
*val = hid_sensor_convert_exponent(
@@ -240,6 +244,12 @@ static int prox_parse_report(struct plat
st->common_attributes.sensitivity.index,
st->common_attributes.sensitivity.report_id);
}
+
+ st->scale_precision = hid_sensor_format_scale(
+ hsdev->usage,
+ >prox_attr,
+ >scale_pre_decml, >scale_post_decml);
+
return ret;
}
Re: [PATCH v4 4/7] arm64: dts: renesas: r8a77970: Add csi40 port@0
Hi Jacopo,
Thank you for the patch.
On Thu, Apr 15, 2021 at 02:25:59PM +0200, Jacopo Mondi wrote:
> Declare port@0 in the csi40 device node and leave it un-connected.
> Each board .dts file will connect the port as it requires.
>
> Signed-off-by: Jacopo Mondi
The port exists at the hardware level, so including it here sounds good.
The DT binding even makes the port mandatory :-)
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a77970.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> index 5a5d5649332a..e8f6352c3665 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> @@ -1106,6 +1106,10 @@ ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> + port@0 {
> + reg = <0>;
> + };
> +
> port@1 {
> #address-cells = <1>;
> #size-cells = <0>;
--
Regards,
Laurent Pinchart
Re: [PATCH 1/2] x86/events/amd/iommu: Fix sysfs type mismatch
On Thu, Apr 15, 2021 at 08:53:35AM +0100, Christoph Hellwig wrote: > On Wed, Apr 14, 2021 at 05:11:11PM -0700, Nathan Chancellor wrote: > > dev_attr_show() calls _iommu_event_show() via an indirect call but > > _iommu_event_show()'s type does not currently match the type of the > > show() member in 'struct device_attribute', resulting in a Control Flow > > Integrity violation. > > While the fix looks fine I think we need to solve this kind of problem > by better type checking. The fact that we can use the wong type here > without a compiler warning is the real issue. I agree. Unfortunately, it seems that is going to be a much longer tail project because of how pervasive this is (using container_of() + attributes to get callbacks). https://lore.kernel.org/r/202006112217.2E6CE093@keescook/ https://lore.kernel.org/r/202104021823.64FA6119@keescook/ Cheers, Nathan
Re: [PATCH v4 4/6] perf arm-spe: Assign kernel time to synthesized event
On 12/04/2021 12:10, Leo Yan wrote: > In current code, it assigns the arch timer counter to the synthesized > samples Arm SPE trace, thus the samples don't contain the kernel time > but only contain the raw counter value. > > To fix the issue, this patch converts the timer counter to kernel time > and assigns it to sample timestamp. > > Signed-off-by: Leo Yan > --- > tools/perf/util/arm-spe.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c > index 23714cf0380e..c13a89f06ab8 100644 > --- a/tools/perf/util/arm-spe.c > +++ b/tools/perf/util/arm-spe.c > @@ -234,7 +234,7 @@ static void arm_spe_prep_sample(struct arm_spe *spe, > struct arm_spe_record *record = >decoder->record; > > if (!spe->timeless_decoding) > - sample->time = speq->timestamp; > + sample->time = tsc_to_perf_time(record->timestamp, >tc); I noticed that in arm_spe_recording_options() the TIME sample bit is set regardless of any options. I don't know of a way to remove this, and if there isn't, does that mean that all the code in this file that looks at spe->timeless_decoding is untested and has never been hit? Unless there is a way to get a perf file with only the AUXTRACE event and no others? I think that one might have no timestamp set. Otherwise other events will always have timestamps so spe->timeless_decoding is always false. > > sample->ip = record->from_ip; > sample->cpumode = arm_spe_cpumode(spe, sample->ip); >
[PATCH] iommu/fsl-pamu: Fix uninitialized variable warning
From: Joerg Roedel
The variable 'i' in the function update_liodn_stash() is not
initialized and only used in a debug printk(). So it has no
meaning at all, remove it.
Reported-by: kernel test robot
Signed-off-by: Joerg Roedel
---
drivers/iommu/fsl_pamu_domain.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index 32944d67baa4..0ac781186dbd 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -57,14 +57,13 @@ static int __init iommu_init_mempool(void)
static int update_liodn_stash(int liodn, struct fsl_dma_domain *dma_domain,
u32 val)
{
- int ret = 0, i;
+ int ret = 0;
unsigned long flags;
spin_lock_irqsave(_lock, flags);
ret = pamu_update_paace_stash(liodn, val);
if (ret) {
- pr_debug("Failed to update SPAACE %d field for liodn %d\n ",
-i, liodn);
+ pr_debug("Failed to update SPAACE for liodn %d\n ", liodn);
spin_unlock_irqrestore(_lock, flags);
return ret;
}
--
2.30.2
Re: [v2 1/2] dt-bindings: Add bindings for aspeed pwm-tach and pwm.
On Wed, Apr 14, 2021 at 10:44 PM Billy Tsai wrote:
>
> Hi Rob,
>
> On 2021/4/15, 6:16 AM,Rob Herringwrote:
>
> On Wed, Apr 14, 2021 at 06:49:38PM +0800, Billy Tsai wrote:
> >> This patch adds device bindings for aspeed pwm-tach device which is a
> >> multi-function device include pwn and tach function and pwm device
> which
> >> should be the sub-node of pwm-tach device.
> >>
> >> Signed-off-by: Billy Tsai
> >> Change-Id: I18d9dea14c3a04e1b7e38ffecd49d45917b9b545
> >
> >Drop
> >
> >> ---
> >> .../bindings/mfd/aspeed,ast2600-pwm-tach.yaml | 60 +++
> >> .../bindings/pwm/aspeed,ast2600-pwm.yaml | 44 ++
> >> 2 files changed, 104 insertions(+)
> >> create mode 100644
> Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
> >> create mode 100644
> Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
> >>
> >> diff --git
> a/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
> b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
> >> new file mode 100644
> >> index ..eaf8bdf8d44e
> >> --- /dev/null
> >> +++
> b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
> >> @@ -0,0 +1,60 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +# Copyright (C) 2021 ASPEED, Inc.
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/mfd/aspeed,ast2600-pwm-tach.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: PWM Tach controller Device Tree Bindings
> >> +
> >> +description: |
> >> + The PWM Tach controller is represented as a multi-function device
> which
> >> + includes:
> >> +PWM
> >> +Tach
>
> > But is it really? A PWM and tach sounds like a fan controller. Look at
>
> Our PWM is not only for fans but also used for the motor, led, buzzer, and so
> on.
> So I want to split the function into two devices with a multi-function device.
> One for PWM output and one for tach monitor.
>
> > other existing PWM+tach bindings we have for fans.
>
> I didn't see the PWM+tach bindings can you give some example for me, thanks.
Let me grep 'tach' for you:
Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt
Hey, look at that, there's already one for ASpeed. So the question is
how is the newer h/w different?
>
> >> +
> >> +maintainers:
> >> + - Billy Tsai
> >> +
> >> +properties:
> >> + compatible:
> >> +items:
> >> + - enum:
> >> + - aspeed,ast2600-pwm-tach
> >> + - const: syscon
> >> + - const: simple-mfd
> >> + reg:
> >> +maxItems: 1
> >> + "#address-cells":
> >> +const: 1
> >> + "#size-cells":
> >> +const: 1
> >> +
> >> +required:
> >> + - compatible
> >> + - reg
> >> + - "#address-cells"
> >> + - "#size-cells"
> >> +
> >> +additionalProperties:
> >> + type: object
>
> > As you know the 2 node names, they should be documented. However, see
> > below.
>
> >> +
> >> +examples:
> >> + - |
> >> +pwm_tach: pwm_tach@1e61 {
> >> + compatible = "aspeed,ast2600-pwm-tach", "syscon", "simple-mfd";
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + reg = <0x1e61 0x100>;
> >> +
> >> + pwm: pwm@0 {
> >> +compatible = "aspeed,ast2600-pwm";
> >> +#pwm-cells = <3>;
> >> +reg = <0x0 0x100>;
> >> + };
> >> +
> >> + tach: tach@1 {
> >> +compatible = "aspeed,ast2600-tach";
> >> +reg = <0x0 0x100>;
>
> > You have 2 nodes at the same address. Not valid.
>
> Our pwm and tach is used the same base address and the offset is like below:
>
> PWM0 used 0x0 0x4, Tach0 used 0x8 0xc
> PWM1 used 0x10 0x14, Tach1 used 0x18 0x1c
> ...
>
> I will remove the reg property from pwm and tach node and remove the
> "#address-cells" and
> "#size-cells" from the parent node.
That's not really the solution...
>
> >> + };
>
> > There's no real need for 2 child nodes. The parent node can be a PWM
> > provider.
>
> However, In our usage, the parent node is a mfd, not a simple PWM device
> only. I don't want to
> combine the different functions with the one device node.
Looks like a single h/w block to me. If you want to divide that up
into multiple drivers, then that's an OS problem. A single node can be
multiple providers. For example, on the existing aspeed binding, just
add '#pwm-cells' to the node if you want to also expose it as a PWM
provider.
Rob
Re: [RFC PATCH] USB:XHCI:skip hub registration
On Thu, Apr 15, 2021 at 08:22:38PM +0800, Longfang Liu wrote:
> When the number of ports on the USB hub is 0, skip the registration
> operation of the USB hub.
>
> The current Kunpeng930's XHCI hardware controller is defective. The number
> of ports on its USB3.0 bus controller is 0, and the number of ports on
> the USB2.0 bus controller is 1.
>
> In order to solve this problem that the USB3.0 controller does not have
> a port which causes the registration of the hub to fail, this patch passes
> the defect information by adding flags in the quirks of xhci and usb_hcd,
> and finally skips the registration process of the hub directly according
> to the results of these flags when the hub is initialized.
>
> Signed-off-by: Longfang Liu
The objections that Greg raised are all good ones.
But even aside from them, this patch doesn't actually do what the
description says. The patch doesn't remove the call to usb_add_hcd
for the USB-3 bus. If you simply skipped that call (and the
corresponding call to usb_remove_hcd) when there are no
ports on the root hub, none of the stuff in this patch would be needed.
Alan Stern
> ---
> drivers/usb/core/hub.c | 6 ++
> drivers/usb/host/xhci-pci.c | 4
> drivers/usb/host/xhci.c | 5 +
> drivers/usb/host/xhci.h | 1 +
> include/linux/usb/hcd.h | 1 +
> 5 files changed, 17 insertions(+)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index b1e14be..2d6869d 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1769,9 +1769,15 @@ static int hub_probe(struct usb_interface *intf, const
> struct usb_device_id *id)
> struct usb_host_interface *desc;
> struct usb_device *hdev;
> struct usb_hub *hub;
> + struct usb_hcd *hcd;
>
> desc = intf->cur_altsetting;
> hdev = interface_to_usbdev(intf);
> + hcd = bus_to_hcd(hdev->bus);
> + if (hcd->usb3_no_port) {
> + dev_warn(>dev, "USB hub has no port\n");
> + return -ENODEV;
> + }
>
> /*
>* Set default autosuspend delay as 0 to speedup bus suspend,
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index ef513c2..63b89a4 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -281,6 +281,10 @@ static void xhci_pci_quirks(struct device *dev, struct
> xhci_hcd *xhci)
> if (xhci->quirks & XHCI_RESET_ON_RESUME)
> xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
> "QUIRK: Resetting on resume");
> +
> + if (pdev->vendor == PCI_VENDOR_ID_HUAWEI &&
> + pdev->device == 0xa23c)
> + xhci->quirks |= XHCI_USB3_NOPORT;
> }
>
> #ifdef CONFIG_ACPI
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index bee5dec..e3e3573 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -5184,6 +5184,11 @@ int xhci_gen_setup(struct usb_hcd *hcd,
> xhci_get_quirks_t get_quirks)
> /* xHCI private pointer was set in xhci_pci_probe for the second
>* registered roothub.
>*/
> + if (xhci->quirks & XHCI_USB3_NOPORT) {
> + xhci_info(xhci, "xHCI host has no port\n");
> + hcd->usb3_no_port = 1;
> + }
> +
> return 0;
> }
>
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index 2c6c4f8..d3c658f 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1874,6 +1874,7 @@ struct xhci_hcd {
> #define XHCI_RESET_PLL_ON_DISCONNECT BIT_ULL(34)
> #define XHCI_SNPS_BROKEN_SUSPENDBIT_ULL(35)
> #define XHCI_RENESAS_FW_QUIRKBIT_ULL(36)
> +#define XHCI_USB3_NOPORT BIT_ULL(37)
>
> unsigned intnum_active_eps;
> unsigned intlimit_active_eps;
> diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
> index 3dbb42c..7df23a0f 100644
> --- a/include/linux/usb/hcd.h
> +++ b/include/linux/usb/hcd.h
> @@ -172,6 +172,7 @@ struct usb_hcd {
> unsignedtpl_support:1; /* OTG & EH TPL support */
> unsignedcant_recv_wakeups:1;
> /* wakeup requests from downstream aren't received */
> + unsignedusb3_no_port:1; /* xHCI main_hcd has no port */
>
> unsigned intirq;/* irq allocated */
> void __iomem*regs; /* device memory/io */
> --
> 2.8.1
>
Re: [PATCH v4 0/6] perf arm-spe: Enable timestamp
Hi Leo,
I was looking at testing this on N1SDP and I thought I would try the round trip
with perf inject and
then perf report but saw that perf inject with SPE always results in an error
(unrelated to your change)
-> ./perf report -i per-thread-spe-time.inject.data
0x1328 [0x8]: failed to process type: 9 [Bad address]
Error:
failed to process sample
Do you have any test suggestions other than looking at the raw data?
Thanks
James
On 12/04/2021 12:10, Leo Yan wrote:
> This patch set is to enable timestamp for Arm SPE trace. It reads out
> TSC parameters from the TIME_CONV event, the parameters are used for
> conversion between timer counter and kernel time and which is applied
> for Arm SPE samples.
>
> This version dropped the change for adding hardware clock parameters
> into auxtrace info, alternatively, it utilizes the TIME_CONV event to
> extract the clock parameters which is used for timestamp calculation.
>
> This patch set can be clearly applied on perf/core branch with:
>
> commit 2c0cb9f56020 ("perf test: Add a shell test for 'perf stat
> --bpf-counters' new option")
>
> Ths patch series has been tested on Hisilicon D06 platform.
>
> Changes from v3:
> * Let to be backwards-compatible for TIME_CONV event (Adrian).
>
> Changes from v2:
> * Changed to use TIME_CONV event for extracting clock parameters (Al).
>
> Changes from v1:
> * Rebased patch series on the latest perf/core branch;
> * Fixed the patch for dumping TSC parameters to support both the
> older and new auxtrace info format.
>
>
> Leo Yan (6):
> perf arm-spe: Remove unused enum value ARM_SPE_PER_CPU_MMAPS
> perf arm-spe: Save clock parameters from TIME_CONV event
> perf arm-spe: Convert event kernel time to counter value
> perf arm-spe: Assign kernel time to synthesized event
> perf arm-spe: Bail out if the trace is later than perf event
> perf arm-spe: Don't wait for PERF_RECORD_EXIT event
>
> tools/perf/util/arm-spe.c | 74 +--
> tools/perf/util/arm-spe.h | 1 -
> 2 files changed, 64 insertions(+), 11 deletions(-)
>
Re: [PATCH] sched,psi: fix the 'int' underflow for psi
On Thu, Apr 15, 2021 at 07:59:41PM +0530, Charan Teja Reddy wrote:
> psi_group_cpu->tasks, represented by the unsigned int, stores the number
> of tasks that could be stalled on a psi resource(io/mem/cpu).
> Decrementing these counters at zero leads to wrapping which further
> leads to the psi_group_cpu->state_mask is being set with the respective
> pressure state. This could result into the unnecessary time sampling for
> the pressure state thus cause the spurious psi events. This can further
> lead to wrong actions being taken at the user land based on these psi
> events.
> Though psi_bug is set under these conditions but that just for debug
> purpose. Fix it by decrementing the ->tasks count only when it is
> non-zero.
Makes sense, it's more graceful in the event of a bug.
But what motivates this change? Is it something you hit recently with
an upstream kernel and we should investigate?
> Signed-off-by: Charan Teja Reddy
> ---
> kernel/sched/psi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
> index 967732c..f925468 100644
> --- a/kernel/sched/psi.c
> +++ b/kernel/sched/psi.c
> @@ -718,7 +718,8 @@ static void psi_group_change(struct psi_group *group, int
> cpu,
> groupc->tasks[3], clear, set);
> psi_bug = 1;
> }
> - groupc->tasks[t]--;
> + if (groupc->tasks[t])
> + groupc->tasks[t]--;
There is already a branch on the tasks to signal the bug. How about:
if (groupc->tasksk[t]) {
groupc->tasks[t]--;
} else if (!psi_bug) {
printk_deferred(...
psi_bug = 1;
}
Re: [PATCH v4 1/7] dt-bindings: media: max9286: Re-indent example
Hi Jacopo,
Thank you for the patch.
On Thu, Apr 15, 2021 at 02:25:56PM +0200, Jacopo Mondi wrote:
> The dt-bindings examples are usually indented with 4 spaces.
>
> The maxim,max9286 schema has the example indented with only
> 2 spaces, re-indent it.
>
> Cosmetic change only.
>
> Signed-off-by: Jacopo Mondi
Tested by applying and verifying that `git show -b` shows an empty diff.
Reviewed-by: Laurent Pinchart
> ---
> .../bindings/media/i2c/maxim,max9286.yaml | 214 +-
> 1 file changed, 107 insertions(+), 107 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> index ee16102fdfe7..0e7162998b77 100644
> --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> @@ -191,140 +191,140 @@ examples:
> #include
>
> i2c@e66d8000 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> +#address-cells = <1>;
> +#size-cells = <0>;
>
> - reg = <0 0xe66d8000>;
> +reg = <0 0xe66d8000>;
>
> - gmsl-deserializer@2c {
> -compatible = "maxim,max9286";
> -reg = <0x2c>;
> -poc-supply = <_poc_12v>;
> -enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
> +gmsl-deserializer@2c {
> +compatible = "maxim,max9286";
> +reg = <0x2c>;
> +poc-supply = <_poc_12v>;
> +enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
>
> -gpio-controller;
> -#gpio-cells = <2>;
> +gpio-controller;
> +#gpio-cells = <2>;
>
> -maxim,reverse-channel-microvolt = <17>;
> +maxim,reverse-channel-microvolt = <17>;
>
> -ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
>
> - port@0 {
> -reg = <0>;
> +port@0 {
> +reg = <0>;
>
> -max9286_in0: endpoint {
> - remote-endpoint = <_out0>;
> -};
> - };
> -
> - port@1 {
> -reg = <1>;
> -
> -max9286_in1: endpoint {
> - remote-endpoint = <_out1>;
> -};
> - };
> -
> - port@2 {
> -reg = <2>;
> -
> -max9286_in2: endpoint {
> - remote-endpoint = <_out2>;
> -};
> - };
> +max9286_in0: endpoint {
> +remote-endpoint = <_out0>;
> +};
> +};
>
> - port@3 {
> -reg = <3>;
> +port@1 {
> +reg = <1>;
>
> -max9286_in3: endpoint {
> - remote-endpoint = <_out3>;
> -};
> - };
> +max9286_in1: endpoint {
> +remote-endpoint = <_out1>;
> +};
> +};
>
> - port@4 {
> -reg = <4>;
> +port@2 {
> +reg = <2>;
>
> -max9286_out: endpoint {
> - data-lanes = <1 2 3 4>;
> - remote-endpoint = <_in>;
> -};
> - };
> -};
> +max9286_in2: endpoint {
> +remote-endpoint = <_out2>;
> +};
> +};
>
> -i2c-mux {
> - #address-cells = <1>;
> - #size-cells = <0>;
> +port@3 {
> +reg = <3>;
>
> - i2c@0 {
> -#address-cells = <1>;
> -#size-cells = <0>;
> -reg = <0>;
> +max9286_in3: endpoint {
> +remote-endpoint = <_out3>;
> +};
> +};
>
> -camera@51 {
> - compatible = "imi,rdacm20";
> - reg = <0x51>, <0x61>;
> +port@4 {
> +reg = <4>;
>
> - port {
> -rdacm20_out0: endpoint {
> - remote-endpoint = <_in0>;
> +max9286_out: endpoint {
> +data-lanes = <1 2 3 4>;
> +remote-endpoint = <_in>;
> +};
> };
> - };
> -
> };
> - };
> -
> - i2c@1 {
> -#address-cells = <1>;
> -#size-cells = <0>;
> -reg = <1>;
>
> -camera@52 {
> - compatible = "imi,rdacm20";
> - reg = <0x52>, <0x62>;
> +i2c-mux {
> +#address-cells = <1>;
> +#size-cells = <0>;
>
> - port {
> -rdacm20_out1: endpoint {
> - remote-endpoint = <_in1>;
> -};
>
Re: [PATCH v4 1/6] perf arm-spe: Remove unused enum value ARM_SPE_PER_CPU_MMAPS
Hi James, On Thu, Apr 15, 2021 at 05:13:36PM +0300, James Clark wrote: > On 12/04/2021 12:10, Leo Yan wrote: > > The enum value 'ARM_SPE_PER_CPU_MMAPS' is never used so remove it. > > Hi Leo, > > I think this causes an error when attempting to open a newly recorded file > with an old version of perf. The value ARM_SPE_AUXTRACE_PRIV_MAX is used here: > > size_t min_sz = sizeof(u64) * ARM_SPE_AUXTRACE_PRIV_MAX; > struct perf_record_time_conv *tc = >time_conv; > struct arm_spe *spe; > int err; > > if (auxtrace_info->header.size < sizeof(struct > perf_record_auxtrace_info) + > min_sz) > return -EINVAL; > > And removing ARM_SPE_PER_CPU_MMAPS changes the value of > ARM_SPE_AUXTRACE_PRIV_MAX. > > At least I think that's what's causing the problem. I get this error: > > ./perf report -i per-thread-spe-time.data > 0x1c0 [0x18]: failed to process type: 70 [Invalid argument] > Error: > failed to process sample > # To display the perf.data header info, please use > --header/--header-only options. > # Yes, when working on this patch I had concern as well. I carefully thought that the perf tool should be backwards-compatible, but there have no requirement for forwards-compatibility. This is the main reason why I kept this patch. If you or anyone could confirm the forwards-compatibility is required, it's quite fine for me to drop this patch. Thanks a lot for the reviewing and testing! Leo
Re: [PATCH 2/2] iommu/amd: Remove performance counter pre-initialization test
I think you've put your finger on it, Suravee! On 15/04/2021 10:28, Suthikulpanit, Suravee wrote: David, On 4/14/2021 10:33 PM, David Coe wrote: Hi Suravee! I've re-run your revert+update patch on Ubuntu's latest kernel 5.11.0-14 partly to check my mailer's 'mangling' hadn't also reached the code! There are 3 sets of results in the attachment, all for the Ryzen 2400G. The as-distributed kernel already incorporates your IOMMU RFCv3 patch. A. As-distributed kernel (cold boot) >5 retries, so no IOMMU read/write capability, no amd_iommu events. B. As-distributed kernel (warm boot) <5 retries, amd_iommu running stats show large numbers as before. C. Revert+Update kernel amd_iommu events listed and also show large hit/miss numbers. In due course, I'll load the new (revert+update) kernel on the 4700G but won't overload your mail-box unless something unusual turns up. Best regards, For the Ryzen 2400G, could you please try with: - 1 event at a time - Not more than 8 events (On your system, it has 2 banks x 4 counters/bank. I am trying to see if this issue might be related to the counters multiplexing). Thanks, Attached are the results you requested for the 2400G along with a tiny shell-script. One event at a time and various batches of less than 8 events produce unexceptionable data. One final batch of 10 events and (hoopla) up go the counter stats. Will you be doing something in mitigation or does this just go with the patch? Is there anything further you need from me? I'll run the script on the 4700U but I don't expect surprises :-). All most appreciated, -- David iommu_list.sh Description: application/shellscript $ sudo ./iommu_list.sh Performance counter stats for 'system wide': 12 amd_iommu_0/cmd_processed/ 10.001266851 seconds time elapsed Performance counter stats for 'system wide': 11 amd_iommu_0/cmd_processed_inv/ 10.001259049 seconds time elapsed Performance counter stats for 'system wide': 0 amd_iommu_0/ign_rd_wr_mmio_1ff8h/ 10.000791810 seconds time elapsed Performance counter stats for 'system wide': 350 amd_iommu_0/int_dte_hit/ 10.000848437 seconds time elapsed Performance counter stats for 'system wide': 16 amd_iommu_0/int_dte_mis/ 10.001271989 seconds time elapsed Performance counter stats for 'system wide': 348 amd_iommu_0/mem_dte_hit/ 10.000808074 seconds time elapsed Performance counter stats for 'system wide': 211,925 amd_iommu_0/mem_dte_mis/ 10.000915362 seconds time elapsed Performance counter stats for 'system wide': 30 amd_iommu_0/mem_iommu_tlb_pde_hit/ 10.001520597 seconds time elapsed Performance counter stats for 'system wide': 450 amd_iommu_0/mem_iommu_tlb_pde_mis/ 10.000877493 seconds time elapsed Performance counter stats for 'system wide': 10,953 amd_iommu_0/mem_iommu_tlb_pte_hit/ 10.000831802 seconds time elapsed Performance counter stats for 'system wide': 13,235 amd_iommu_0/mem_iommu_tlb_pte_mis/ 10.001292003 seconds time elapsed Performance counter stats for 'system wide': 0 amd_iommu_0/mem_pass_excl/ 10.000836000 seconds time elapsed Performance counter stats for 'system wide': 0 amd_iommu_0/mem_pass_pretrans/ 10.000799887 seconds time elapsed Performance counter stats for 'system wide': 12,283 amd_iommu_0/mem_pass_untrans/ 10.000815339 seconds time elapsed Performance counter stats for 'system wide': 0 amd_iommu_0/mem_target_abort/ 10.001205168 seconds time elapsed Performance counter stats for 'system wide': 1,333 amd_iommu_0/mem_trans_total/ 10.000915359 seconds time elapsed Performance counter stats for 'system wide': 0 amd_iommu_0/page_tbl_read_gst/ 10.001248235 seconds time elapsed Performance counter stats for 'system wide': 65 amd_iommu_0/page_tbl_read_nst/ 10.001266411 seconds time elapsed Performance counter stats for 'system wide': 78 amd_iommu_0/page_tbl_read_tot/ 10.001272406 seconds time elapsed Performance counter stats for 'system wide': 0 amd_iommu_0/smi_blk/ 10.001282912 seconds time elapsed Performance counter stats for 'system wide': 0 amd_iommu_0/smi_recv/ 10.001223193 seconds time elapsed Performance counter stats for 'system wide': 0 amd_iommu_0/tlb_inv/ 10.001234853 seconds time elapsed Performance counter stats for 'system wide': 0 amd_iommu_0/vapic_int_guest/
[PATCH] ACPI: APEI: remove redundant assignment to variable rc
From: Colin Ian King
The variable rc is being assigned a value that is never read,
the assignment is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/acpi/apei/einj.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c
index 133156759551..328e8aeece6c 100644
--- a/drivers/acpi/apei/einj.c
+++ b/drivers/acpi/apei/einj.c
@@ -725,7 +725,6 @@ static int __init einj_init(void)
goto err_release;
}
- rc = -ENOMEM;
einj_param = einj_get_parameter_address();
if ((param_extension || acpi5) && einj_param) {
debugfs_create_x32("flags", S_IRUSR | S_IWUSR, einj_debug_dir,
--
2.30.2
Re: [PATCH bpf-next 1/2] bpf: Remove bpf_jit_enable=2 debugging mode
On 4/15/21 11:32 AM, Jianlin Lv wrote:
For debugging JITs, dumping the JITed image to kernel log is discouraged,
"bpftool prog dump jited" is much better way to examine JITed dumps.
This patch get rid of the code related to bpf_jit_enable=2 mode and
update the proc handler of bpf_jit_enable, also added auxiliary
information to explain how to use bpf_jit_disasm tool after this change.
Signed-off-by: Jianlin Lv
[...]
diff --git a/arch/x86/net/bpf_jit_comp32.c b/arch/x86/net/bpf_jit_comp32.c
index 0a7a2870f111..8d36b4658076 100644
--- a/arch/x86/net/bpf_jit_comp32.c
+++ b/arch/x86/net/bpf_jit_comp32.c
@@ -2566,9 +2566,6 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog
*prog)
cond_resched();
}
- if (bpf_jit_enable > 1)
- bpf_jit_dump(prog->len, proglen, pass + 1, image);
-
if (image) {
bpf_jit_binary_lock_ro(header);
prog->bpf_func = (void *)image;
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index c8496c1142c9..990b1720c7a4 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -273,16 +273,8 @@ static int proc_dointvec_minmax_bpf_enable(struct
ctl_table *table, int write,
tmp.data = _enable;
ret = proc_dointvec_minmax(, write, buffer, lenp, ppos);
- if (write && !ret) {
- if (jit_enable < 2 ||
- (jit_enable == 2 && bpf_dump_raw_ok(current_cred( {
- *(int *)table->data = jit_enable;
- if (jit_enable == 2)
- pr_warn("bpf_jit_enable = 2 was set! NEVER use this
in production, only for JIT debugging!\n");
- } else {
- ret = -EPERM;
- }
- }
+ if (write && !ret)
+ *(int *)table->data = jit_enable;
return ret;
}
@@ -389,7 +381,7 @@ static struct ctl_table net_core_table[] = {
.extra2 = SYSCTL_ONE,
# else
.extra1 = SYSCTL_ZERO,
- .extra2 = ,
+ .extra2 = SYSCTL_ONE,
# endif
},
# ifdef CONFIG_HAVE_EBPF_JIT
diff --git a/tools/bpf/bpf_jit_disasm.c b/tools/bpf/bpf_jit_disasm.c
index c8ae95804728..efa4b17ae016 100644
--- a/tools/bpf/bpf_jit_disasm.c
+++ b/tools/bpf/bpf_jit_disasm.c
@@ -7,7 +7,7 @@
*
* To get the disassembly of the JIT code, do the following:
*
- * 1) `echo 2 > /proc/sys/net/core/bpf_jit_enable`
+ * 1) Insert bpf_jit_dump() and recompile the kernel to output JITed image
into log
Hmm, if we remove bpf_jit_dump(), the next drive-by cleanup patch will be thrown
at bpf@vger stating that bpf_jit_dump() has no in-tree users and should be
removed.
Maybe we should be removing bpf_jit_disasm.c along with it as well as
bpf_jit_dump()
itself ... I guess if it's ever needed in those rare occasions for JIT
debugging we
can resurrect it from old kernels just locally. But yeah, bpftool's jit dump
should
suffice for vast majority of use cases.
There was a recent set for ppc32 jit which was merged into ppc tree which will
create
a merge conflict with this one [0]. So we would need a rebase and take it maybe
during
merge win once the ppc32 landed..
[0]
https://lore.kernel.org/bpf/cover.1616430991.git.christophe.le...@csgroup.eu/
* 2) Load a BPF filter (e.g. `tcpdump -p -n -s 0 -i eth1 host
192.168.20.0/24`)
* 3) Run e.g. `bpf_jit_disasm -o` to read out the last JIT code
*
diff --git a/tools/bpf/bpftool/feature.c b/tools/bpf/bpftool/feature.c
index 40a88df275f9..98c7eec2923f 100644
--- a/tools/bpf/bpftool/feature.c
+++ b/tools/bpf/bpftool/feature.c
@@ -203,9 +203,6 @@ static void probe_jit_enable(void)
case 1:
printf("JIT compiler is enabled\n");
break;
- case 2:
- printf("JIT compiler is enabled with debugging traces in
kernel logs\n");
- break;
This would still need to be there for older kernels ...
case -1:
printf("Unable to retrieve JIT-compiler status\n");
break;
Re: UBSAN: array-index-out-of-bounds in ehci_hub_control
On Thu, Apr 15, 2021 at 04:10:45PM +0200, Dmitry Vyukov wrote:
> Hi,
>
> I've got this report while booting v5.10.13 kernel, but upstream code
> seems to be the same.
> The access to port_status, the code is:
>
> struct ehci_regs {
> u32 port_status[0]; /* up to N_PORTS */
> u32 reserved3[9];
> https://elixir.bootlin.com/linux/v5.12-rc7/source/include/linux/usb/ehci_def.h#L130
>
> Question: should it be an empty array "[]" to prevent the undefined behavior?
> Or should it be declared as "[9]" to be more explicit?
Arnd has already looked at this:
https://marc.info/?t=15882824021=1=2
I thought we had arrived at an acceptable (though not great) solution,
but he never posted any finished patches. :-(
Alan Stern
> UBSAN: array-index-out-of-bounds in drivers/usb/host/ehci-hub.c:893:16
> index 1 is out of range for type 'u32 [0]'
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.10.13+ #1
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
> rel-1.13.0-44-g88ab0c15525c-prebuilt.qemu.org 04/01/2014
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x183/0x225 lib/dump_stack.c:118
> ubsan_epilogue lib/ubsan.c:148 [inline]
> __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:356
> ehci_hub_control+0x1d27/0x2370 drivers/usb/host/ehci-hub.c:893
> rh_call_control+0x938/0x11a0 drivers/usb/core/hcd.c:683
> rh_urb_enqueue drivers/usb/core/hcd.c:842 [inline]
> usb_hcd_submit_urb+0x2f2/0x5f0 drivers/usb/core/hcd.c:1543
> usb_start_wait_urb+0x11a/0x550 drivers/usb/core/message.c:58
> usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
> usb_control_msg+0x281/0x470 drivers/usb/core/message.c:153
> hub_power_on+0x1a8/0x3c0 arch/x86/include/asm/bitops.h:219
> hub_activate+0x330/0x1ba0 drivers/usb/core/hub.c:1076
> hub_configure+0x19e0/0x2690 drivers/usb/core/hub.c:1680
> hub_probe+0x82f/0x9b0 drivers/usb/core/hub.c:1882
> usb_probe_interface+0x67b/0xb70 drivers/usb/core/driver.c:396
> really_probe+0x58b/0x1580 drivers/base/dd.c:558
> driver_probe_device+0x15a/0x310 drivers/base/dd.c:740
> bus_for_each_drv+0x16a/0x1f0 drivers/base/bus.c:431
> __device_attach+0x2b2/0x4b0 drivers/base/dd.c:914
> bus_probe_device+0xb8/0x200 drivers/base/bus.c:491
> device_add+0x8e7/0xcb0 drivers/base/core.c:2954
> usb_set_configuration+0x1b98/0x2230 drivers/usb/core/message.c:2159
> usb_generic_driver_probe+0x83/0x140 drivers/usb/core/generic.c:238
> usb_probe_device+0x13a/0x260 drivers/usb/core/driver.c:293
> really_probe+0x58b/0x1580 drivers/base/dd.c:558
> driver_probe_device+0x15a/0x310 drivers/base/dd.c:740
> bus_for_each_drv+0x16a/0x1f0 drivers/base/bus.c:431
> __device_attach+0x2b2/0x4b0 drivers/base/dd.c:914
> bus_probe_device+0xb8/0x200 drivers/base/bus.c:491
> device_add+0x8e7/0xcb0 drivers/base/core.c:2954
> usb_new_device+0xa43/0x1120 drivers/usb/core/hub.c:2554
> register_root_hub+0x214/0x560 drivers/usb/core/hcd.c:1009
> usb_add_hcd+0x8ee/0x1080 drivers/usb/core/hcd.c:2793
> usb_hcd_pci_probe+0xa61/0x1280 drivers/usb/core/hcd-pci.c:264
> local_pci_probe drivers/pci/pci-driver.c:308 [inline]
> pci_call_probe drivers/pci/pci-driver.c:365 [inline]
> __pci_device_probe drivers/pci/pci-driver.c:390 [inline]
> pci_device_probe+0x3ef/0x630 drivers/pci/pci-driver.c:433
> really_probe+0x544/0x1580 drivers/base/dd.c:554
> driver_probe_device+0x15a/0x310 drivers/base/dd.c:740
> device_driver_attach+0x176/0x280 drivers/base/dd.c:1015
> __driver_attach+0xa7/0x490 drivers/base/dd.c:1092
> bus_for_each_dev+0x168/0x1d0 drivers/base/bus.c:305
> bus_add_driver+0x324/0x5e0 drivers/base/bus.c:622
> driver_register+0x2e9/0x3e0 drivers/base/driver.c:171
> do_one_initcall+0x1a3/0x410 init/main.c:1217
> do_initcall_level+0x168/0x218 init/main.c:1290
> do_initcalls+0x50/0x91 init/main.c:1306
> kernel_init_freeable+0x33b/0x47f init/main.c:1527
> kernel_init+0xd/0x290 init/main.c:1415
[PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
Strictly speaking the comparison between guid_t and raw buffer
is not correct. Return to plain memcmp() since the data structures
haven't changed to use uuid_t / guid_t the current state of affairs
is inconsistent. Either it should be changed altogether or left
as is.
Signed-off-by: Andy Shevchenko
---
drivers/nvdimm/btt_devs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
index 05feb97e11ce..82bcd2e86a18 100644
--- a/drivers/nvdimm/btt_devs.c
+++ b/drivers/nvdimm/btt_devs.c
@@ -244,13 +244,14 @@ struct device *nd_btt_create(struct nd_region *nd_region)
*/
bool nd_btt_arena_is_valid(struct nd_btt *nd_btt, struct btt_sb *super)
{
+ static const u8 null_uuid[16];
const u8 *parent_uuid = nd_dev_to_uuid(_btt->ndns->dev);
u64 checksum;
if (memcmp(super->signature, BTT_SIG, BTT_SIG_LEN) != 0)
return false;
- if (!guid_is_null((guid_t *)>parent_uuid))
+ if (memcmp(super->parent_uuid, null_uuid, 16) != 0)
if (memcmp(super->parent_uuid, parent_uuid, 16) != 0)
return false;
--
2.30.2
Re: [PATCH 11/13] ARM: dts: stm32: fix LTDC port node on STM32 MCU ad MPU
On 4/15/21 4:30 PM, Marek Vasut wrote:
On 4/15/21 3:34 PM, Alexandre TORGUE wrote:
Hi Marek
Hello Alexandre,
diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts
b/arch/arm/boot/dts/stm32mp157c-dk2.dts
index 2bc92ef3aeb9..19ef475a48fc 100644
--- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
+++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
@@ -82,9 +82,15 @@
};
{
- status = "okay";
-
port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ltdc_ep0_out: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_in>;
+ };
+
ltdc_ep1_out: endpoint@1 {
reg = <1>;
remote-endpoint = <_in>;
[...]
diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
index 64dca5b7f748..e7f10975cacf 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
@@ -277,11 +277,7 @@
status = "okay";
port {
- #address-cells = <1>;
- #size-cells = <0>;
-
- ltdc_ep0_out: endpoint@0 {
- reg = <0>;
+ ltdc_ep0_out: endpoint {
remote-endpoint = <_in>;
};
};
I think this is wrong, the AV96 can have two displays connected to
two ports of the LTDC, just like DK2 for example.
As for dk2 address/size cells are added only if there are 2 endpoints.
It is for this reason I moved endpoint0 definition from
stm32mp15xx-dkx to stm32mp151a-dk1.dts (dk1 has only one endpoint).
Here it's the same, if you have second endpoint then adress/size will
have to be added.
That's a bit problematic. Consider either the use case of DTO which adds
the other display, or even a custom board DTS. Without your patch, this
works:
arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
{
...
ports {
ltdc_ep0_out: endpoint@0 {
remote-endpoint = <_in>;
};
};
};
board-with-display.dts or board-overlay.dts
{
ports {
endpoint@1 { // just add another endpoint@1, no problem
remote-endpoint = <>;
};
};
};
With your patch, the DTS would have to modify the "endpoint" node to be
"endpoint@0" probably with a whole lot of /detele-node/ etc. magic (DTO
cannot do that, so that's a problem, and I do use DTOs on AV96
extensively for the various expansion cards) and then add the
endpoint@1. That becomes real complicated in custom board DT, and
impossible with DTO.
Yes I agree that it'll be problematic. So maybe so solution would be to
not detect a warning for the initial case (only one endpoint with a reg)
Re: [PATCH] PM / EM: Inefficient OPPs detection
On Thu, Apr 15, 2021 at 01:16:35PM +, Quentin Perret wrote: > On Thursday 08 Apr 2021 at 18:10:29 (+0100), Vincent Donnefort wrote: > > --- a/kernel/sched/cpufreq_schedutil.c > > +++ b/kernel/sched/cpufreq_schedutil.c > > @@ -10,6 +10,7 @@ > > > > #include "sched.h" > > > > +#include > > #include > > #include > > > > @@ -164,6 +165,9 @@ static unsigned int get_next_freq(struct sugov_policy > > *sg_policy, > > > > freq = map_util_freq(util, freq, max); > > > > + /* Avoid inefficient performance states */ > > + freq = em_pd_get_efficient_freq(em_cpu_get(policy->cpu), freq); > > I remember this was discussed when Douglas sent his patches some time > ago, but I still find it sad we index the EM table here but still > re-index the cpufreq frequency table later :/ > > Yes in your case this lookup is very inexpensive, but still. EAS relies > on the EM's table matching cpufreq's accurately, so this second lookup > still feels rather unnecessary ... To get only a single lookup, we would need to bring the inefficiency knowledge directly to the cpufreq framework. But it has its own limitations: The cpufreq driver can have its own resolve_freq() callback, which means that not all the drivers would benefit from that feature. The cpufreq_table can be ordered and accessed in several ways which brings many combinations that would need to be supported, ending-up with something much more intrusive. (We can though decide to limit the feature to the low to high access that schedutil needs). As the EM needs schedutil to exist anyway, it seemed to be the right place for this code. It allows any cpufreq driver to benefit from the feature, simplify a potential extension for a usage by devfreq devices and as a bonus it speeds-up energy computing, allowing a more complex Energy Model. > > > if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update) > > return sg_policy->next_freq; > > > > -- > > 2.7.4 > >
Re: [PATCH][next] net: stmmac: replace redundant comparison with true
On Thu, Apr 15, 2021 at 09:37:57AM +0100, Colin King wrote:
> From: Colin Ian King
>
> The comparison of the u32 variable queue with <= zero is always true
> since an unsigned can never be negative. Replace the conditional
> check with the boolean true to simplify the code. The while loop
> will terminate because of the zero check on queue before queue is
> decremented.
>
> Addresses-Coverity: ("Unsigned compared against 0")
> Signed-off-by: Colin Ian King
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index e3e22200a4fd..6e5b4c4b375c 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1673,7 +1673,7 @@ static void stmmac_reinit_rx_buffers(struct stmmac_priv
> *priv)
> return;
>
> err_reinit_rx_buffers:
> - while (queue >= 0) {
This is an off by one from what the original developer was intending
because we're freeing the most recent queue that wasn't allocated.
In other words, we're freeing everything that we need to plus *one
more thing that we don't need to*. But it's harmless in this case:
The better fix would be to make queue an int type and do:
while (--queue >= 0)
dma_free_rx_skbufs(priv, queue);
Re: [PATCH 2/2] drm/ttm: optimize the pool shrinker a bit v2
On Thu, Apr 15, 2021 at 07:56:24PM +0800, Christian König wrote:
> Switch back to using a spinlock again by moving the IOMMU unmap outside
> of the locked region.
>
> v2: Add a comment explaining why we need sync_shrinkers().
>
> Signed-off-by: Christian König
Series look good for me as well.
Acked-by: Huang Rui
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 44 +-
> 1 file changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> index cb38b1a17b09..955836d569cc 100644
> --- a/drivers/gpu/drm/ttm/ttm_pool.c
> +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> @@ -70,7 +70,7 @@ static struct ttm_pool_type global_uncached[MAX_ORDER];
> static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
> static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
>
> -static struct mutex shrinker_lock;
> +static spinlock_t shrinker_lock;
> static struct list_head shrinker_list;
> static struct shrinker mm_shrinker;
>
> @@ -263,9 +263,9 @@ static void ttm_pool_type_init(struct ttm_pool_type *pt,
> struct ttm_pool *pool,
> spin_lock_init(>lock);
> INIT_LIST_HEAD(>pages);
>
> - mutex_lock(_lock);
> + spin_lock(_lock);
> list_add_tail(>shrinker_list, _list);
> - mutex_unlock(_lock);
> + spin_unlock(_lock);
> }
>
> /* Remove a pool_type from the global shrinker list and free all pages */
> @@ -273,9 +273,9 @@ static void ttm_pool_type_fini(struct ttm_pool_type *pt)
> {
> struct page *p;
>
> - mutex_lock(_lock);
> + spin_lock(_lock);
> list_del(>shrinker_list);
> - mutex_unlock(_lock);
> + spin_unlock(_lock);
>
> while ((p = ttm_pool_type_take(pt)))
> ttm_pool_free_page(pt->pool, pt->caching, pt->order, p);
> @@ -313,24 +313,19 @@ static struct ttm_pool_type
> *ttm_pool_select_type(struct ttm_pool *pool,
> static unsigned int ttm_pool_shrink(void)
> {
> struct ttm_pool_type *pt;
> - unsigned int num_freed;
> struct page *p;
>
> - mutex_lock(_lock);
> + spin_lock(_lock);
> pt = list_first_entry(_list, typeof(*pt), shrinker_list);
> + list_move_tail(>shrinker_list, _list);
> + spin_unlock(_lock);
>
> p = ttm_pool_type_take(pt);
> - if (p) {
> - ttm_pool_free_page(pt->pool, pt->caching, pt->order, p);
> - num_freed = 1 << pt->order;
> - } else {
> - num_freed = 0;
> - }
> -
> - list_move_tail(>shrinker_list, _list);
> - mutex_unlock(_lock);
> + if (!p)
> + return 0;
>
> - return num_freed;
> + ttm_pool_free_page(pt->pool, pt->caching, pt->order, p);
> + return 1 << pt->order;
> }
>
> /* Return the allocation order based for a page */
> @@ -530,6 +525,11 @@ void ttm_pool_fini(struct ttm_pool *pool)
> for (j = 0; j < MAX_ORDER; ++j)
> ttm_pool_type_fini(>caching[i].orders[j]);
> }
> +
> + /* We removed the pool types from the LRU, but we need to also make sure
> + * that no shrinker is concurrently freeing pages from the pool.
> + */
> + sync_shrinkers();
> }
>
> /* As long as pages are available make sure to release at least one */
> @@ -604,7 +604,7 @@ static int ttm_pool_debugfs_globals_show(struct seq_file
> *m, void *data)
> {
> ttm_pool_debugfs_header(m);
>
> - mutex_lock(_lock);
> + spin_lock(_lock);
> seq_puts(m, "wc\t:");
> ttm_pool_debugfs_orders(global_write_combined, m);
> seq_puts(m, "uc\t:");
> @@ -613,7 +613,7 @@ static int ttm_pool_debugfs_globals_show(struct seq_file
> *m, void *data)
> ttm_pool_debugfs_orders(global_dma32_write_combined, m);
> seq_puts(m, "uc 32\t:");
> ttm_pool_debugfs_orders(global_dma32_uncached, m);
> - mutex_unlock(_lock);
> + spin_unlock(_lock);
>
> ttm_pool_debugfs_footer(m);
>
> @@ -640,7 +640,7 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct
> seq_file *m)
>
> ttm_pool_debugfs_header(m);
>
> - mutex_lock(_lock);
> + spin_lock(_lock);
> for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i) {
> seq_puts(m, "DMA ");
> switch (i) {
> @@ -656,7 +656,7 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct
> seq_file *m)
> }
> ttm_pool_debugfs_orders(pool->caching[i].orders, m);
> }
> - mutex_unlock(_lock);
> + spin_unlock(_lock);
>
> ttm_pool_debugfs_footer(m);
> return 0;
> @@ -693,7 +693,7 @@ int ttm_pool_mgr_init(unsigned long num_pages)
> if (!page_pool_size)
> page_pool_size = num_pages;
>
> - mutex_init(_lock);
> + spin_lock_init(_lock);
> INIT_LIST_HEAD(_list);
>
> for (i = 0; i < MAX_ORDER; ++i) {
> --
> 2.25.1
>
Re: [tip: core/rcu] softirq: Don't try waking ksoftirqd before it has been spawned
>
> Another approach is to move the spawning of ksoftirqd earlier. This
> still leaves a window of vulnerability, but the window is smaller, and
> thus the probablity of something needing to happen there is smaller.
> Uladzislau sent out a patch that did this some weeks back.
>
See below the patch that is in question, just in case:
commit f4cd768e341486655c8c196e1f2b48a4463541f3
Author: Paul E. McKenney
Date: Fri Feb 12 16:41:05 2021 -0800
softirq: Don't try waking ksoftirqd before it has been spawned
If there is heavy softirq activity, the softirq system will attempt
to awaken ksoftirqd and will stop the traditional back-of-interrupt
softirq processing. This is all well and good, but only if the
ksoftirqd kthreads already exist, which is not the case during early
boot, in which case the system hangs.
One reproducer is as follows:
tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 2
--configs "TREE03" --kconfig "CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_PROVE_LOCKING=y"
--bootargs "threadirqs=1" --trust-make
This commit therefore moves the spawning of the ksoftirqd kthreads
earlier in boot. With this change, the above test passes.
Reported-by: Sebastian Andrzej Siewior
Reported-by: Uladzislau Rezki
Inspired-by: Uladzislau Rezki
Signed-off-by: Paul E. McKenney
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index bb8ff90..283a02d 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -592,6 +592,8 @@ static inline struct task_struct *this_cpu_ksoftirqd(void)
return this_cpu_read(ksoftirqd);
}
+int spawn_ksoftirqd(void);
+
/* Tasklets --- multithreaded analogue of BHs.
This API is deprecated. Please consider using threaded IRQs instead:
diff --git a/init/main.c b/init/main.c
index c68d784..99835bb 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1512,6 +1512,7 @@ static noinline void __init kernel_init_freeable(void)
init_mm_internals();
+ spawn_ksoftirqd();
rcu_init_tasks_generic();
do_pre_smp_initcalls();
lockup_detector_init();
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 9d71046..45d50d4 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -724,7 +724,7 @@ static struct smp_hotplug_thread softirq_threads = {
.thread_comm= "ksoftirqd/%u",
};
-static __init int spawn_ksoftirqd(void)
+__init int spawn_ksoftirqd(void)
{
cpuhp_setup_state_nocalls(CPUHP_SOFTIRQ_DEAD, "softirq:dead", NULL,
takeover_tasklets);
@@ -732,7 +732,6 @@ static __init int spawn_ksoftirqd(void)
return 0;
}
-early_initcall(spawn_ksoftirqd);
/*
* [ These __weak aliases are kept in a separate compilation unit, so that
Thanks.
--
Vlad Rezki
Re: [RFC PATCH 1/5] tracing/hwlat: Add a cpus file specific for hwlat_detector
On 4/15/21 3:49 PM, Steven Rostedt wrote: > OK, for osnoise, I can see how it is useful. But as you said above, for > hwlat tracer, it's not as useful. I agree, it is not as useful. -- Daniel
Re: [PATCH 2/2] perf cs-etm: Set time on synthesised samples to preserve ordering
Hi James, On Thu, Apr 15, 2021 at 03:51:46PM +0300, James Clark wrote: [...] > > For the orignal perf data file with "--per-thread" option, the decoder > > runs into the condition for "etm->timeless_decoding"; and it doesn't > > contain ETM timestamp. > > > > Afterwards, the injected perf data file also misses ETM timestamp and > > hit the condition "etm->timeless_decoding". > > > > So I am confusing why the original perf data can be processed properly > > but fails to handle the injected perf data file. > > Hi Leo, > > My patch only deals with per-cpu mode. With per-thread mode everything is > already working > because _none_ of the events have timestamps because they are not enabled by > default: > > /* In per-cpu case, always need the time of mmap events etc */ > if (!perf_cpu_map__empty(cpus)) > evsel__set_sample_bit(tracking_evsel, TIME); > > When none of the events have timestamps, I think perf doesn't use the > ordering code in > ordered-events.c. So when the inject file is opened, the events are read in > file order. The explination makes sense to me. One thinking: if the original file doesn't use the ordered event, is it possible for the injected file to not use the ordered event as well? Could you confirm Intel-pt can work well for per-cpu mode for inject file? > So it's not really about --per-thread vs per-cpu mode, it's actually about > whether > PERF_SAMPLE_TIME is set, which is set as a by-product of per-cpu mode. > > I hope I understood your question properly. Thanks for info, sorry if I miss any info you have elaborated. Leo
Re: [PATCH 3/3] sched: Use cpu_dying() to fix balance_push vs hotplug-rollback
On 15/04/21 10:59, Peter Zijlstra wrote:
> Can't make sense of what I did.. I've removed that hunk. Patch now looks
> like this.
>
Small nit below, but regardless feel free to apply to the whole lot:
Reviewed-by: Valentin Schneider
@VincentD, ISTR you had tested the initial version of this with your fancy
shmancy hotplug rollback stresser. Feel like doing this
> So instead, make sure balance_push is enabled between
> sched_cpu_deactivate() and sched_cpu_activate() (eg. when
> !cpu_active()), and gate it's utility with cpu_dying().
I'd word that "is enabled below sched_cpu_activate()", since
sched_cpu_deactivate() is now out of the picture.
[...]
> @@ -7639,6 +7639,9 @@ static DEFINE_PER_CPU(struct cpu_stop_wo
>
> /*
> * Ensure we only run per-cpu kthreads once the CPU goes !active.
> + *
> + * This is active/set between sched_cpu_deactivate() / sched_cpu_activate().
Ditto
> + * But only effective when the hotplug motion is down.
> */
> static void balance_push(struct rq *rq)
> {
Re: [PATCH 1/5] mm/swapfile: add percpu_ref support for swap
On Thu, Apr 15, 2021 at 01:24:31PM +0800, Huang, Ying wrote:
> Dennis Zhou writes:
>
> > On Wed, Apr 14, 2021 at 01:44:58PM +0800, Huang, Ying wrote:
> >> Dennis Zhou writes:
> >>
> >> > On Wed, Apr 14, 2021 at 11:59:03AM +0800, Huang, Ying wrote:
> >> >> Dennis Zhou writes:
> >> >>
> >> >> > Hello,
> >> >> >
> >> >> > On Wed, Apr 14, 2021 at 10:06:48AM +0800, Huang, Ying wrote:
> >> >> >> Miaohe Lin writes:
> >> >> >>
> >> >> >> > On 2021/4/14 9:17, Huang, Ying wrote:
> >> >> >> >> Miaohe Lin writes:
> >> >> >> >>
> >> >> >> >>> On 2021/4/12 15:24, Huang, Ying wrote:
> >> >> >> "Huang, Ying" writes:
> >> >> >>
> >> >> >> > Miaohe Lin writes:
> >> >> >> >
> >> >> >> >> We will use percpu-refcount to serialize against concurrent
> >> >> >> >> swapoff. This
> >> >> >> >> patch adds the percpu_ref support for later fixup.
> >> >> >> >>
> >> >> >> >> Signed-off-by: Miaohe Lin
> >> >> >> >> ---
> >> >> >> >> include/linux/swap.h | 2 ++
> >> >> >> >> mm/swapfile.c| 25 ++---
> >> >> >> >> 2 files changed, 24 insertions(+), 3 deletions(-)
> >> >> >> >>
> >> >> >> >> diff --git a/include/linux/swap.h b/include/linux/swap.h
> >> >> >> >> index 144727041e78..849ba5265c11 100644
> >> >> >> >> --- a/include/linux/swap.h
> >> >> >> >> +++ b/include/linux/swap.h
> >> >> >> >> @@ -240,6 +240,7 @@ struct swap_cluster_list {
> >> >> >> >> * The in-memory structure used to track swap areas.
> >> >> >> >> */
> >> >> >> >> struct swap_info_struct {
> >> >> >> >> + struct percpu_ref users;/* serialization
> >> >> >> >> against concurrent swapoff */
> >> >> >> >> unsigned long flags; /* SWP_USED etc: see
> >> >> >> >> above */
> >> >> >> >> signed shortprio; /* swap priority of
> >> >> >> >> this type */
> >> >> >> >> struct plist_node list; /* entry in
> >> >> >> >> swap_active_head */
> >> >> >> >> @@ -260,6 +261,7 @@ struct swap_info_struct {
> >> >> >> >> struct block_device *bdev; /* swap device or bdev
> >> >> >> >> of swap file */
> >> >> >> >> struct file *swap_file; /* seldom referenced */
> >> >> >> >> unsigned int old_block_size;/* seldom referenced */
> >> >> >> >> + struct completion comp; /* seldom referenced */
> >> >> >> >> #ifdef CONFIG_FRONTSWAP
> >> >> >> >> unsigned long *frontswap_map; /* frontswap in-use,
> >> >> >> >> one bit per page */
> >> >> >> >> atomic_t frontswap_pages; /* frontswap pages
> >> >> >> >> in-use counter */
> >> >> >> >> diff --git a/mm/swapfile.c b/mm/swapfile.c
> >> >> >> >> index 149e77454e3c..724173cd7d0c 100644
> >> >> >> >> --- a/mm/swapfile.c
> >> >> >> >> +++ b/mm/swapfile.c
> >> >> >> >> @@ -39,6 +39,7 @@
> >> >> >> >> #include
> >> >> >> >> #include
> >> >> >> >> #include
> >> >> >> >> +#include
> >> >> >> >>
> >> >> >> >> #include
> >> >> >> >> #include
> >> >> >> >> @@ -511,6 +512,15 @@ static void swap_discard_work(struct
> >> >> >> >> work_struct *work)
> >> >> >> >> spin_unlock(>lock);
> >> >> >> >> }
> >> >> >> >>
> >> >> >> >> +static void swap_users_ref_free(struct percpu_ref *ref)
> >> >> >> >> +{
> >> >> >> >> + struct swap_info_struct *si;
> >> >> >> >> +
> >> >> >> >> + si = container_of(ref, struct swap_info_struct, users);
> >> >> >> >> + complete(>comp);
> >> >> >> >> + percpu_ref_exit(>users);
> >> >> >> >
> >> >> >> > Because percpu_ref_exit() is used, we cannot use
> >> >> >> > percpu_ref_tryget() in
> >> >> >> > get_swap_device(), better to add comments there.
> >> >> >>
> >> >> >> I just noticed that the comments of percpu_ref_tryget_live()
> >> >> >> says,
> >> >> >>
> >> >> >> * This function is safe to call as long as @ref is between
> >> >> >> init and exit.
> >> >> >>
> >> >> >> While we need to call get_swap_device() almost at any time, so
> >> >> >> it's
> >> >> >> better to avoid to call percpu_ref_exit() at all. This will
> >> >> >> waste some
> >> >> >> memory, but we need to follow the API definition to avoid
> >> >> >> potential
> >> >> >> issues in the long term.
> >> >> >> >>>
> >> >> >> >>> I have to admit that I'am not really familiar with percpu_ref.
> >> >> >> >>> So I read the
> >> >> >> >>> implementation code of the percpu_ref and found
> >> >> >> >>> percpu_ref_tryget_live() could
> >> >> >> >>> be called after exit now. But you're right we need to follow the
> >> >> >> >>> API definition
> >> >> >> >>> to avoid potential issues in the long term.
> >> >> >> >>>
> >> >> >>
> >> >> >> And we need to call percpu_ref_init() before insert the
> >> >> >>
Re: [PATCH 11/13] ARM: dts: stm32: fix LTDC port node on STM32 MCU ad MPU
On 4/15/21 3:34 PM, Alexandre TORGUE wrote:
Hi Marek
Hello Alexandre,
diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts
b/arch/arm/boot/dts/stm32mp157c-dk2.dts
index 2bc92ef3aeb9..19ef475a48fc 100644
--- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
+++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
@@ -82,9 +82,15 @@
};
{
- status = "okay";
-
port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ltdc_ep0_out: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_in>;
+ };
+
ltdc_ep1_out: endpoint@1 {
reg = <1>;
remote-endpoint = <_in>;
[...]
diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
index 64dca5b7f748..e7f10975cacf 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
@@ -277,11 +277,7 @@
status = "okay";
port {
- #address-cells = <1>;
- #size-cells = <0>;
-
- ltdc_ep0_out: endpoint@0 {
- reg = <0>;
+ ltdc_ep0_out: endpoint {
remote-endpoint = <_in>;
};
};
I think this is wrong, the AV96 can have two displays connected to two
ports of the LTDC, just like DK2 for example.
As for dk2 address/size cells are added only if there are 2 endpoints.
It is for this reason I moved endpoint0 definition from stm32mp15xx-dkx
to stm32mp151a-dk1.dts (dk1 has only one endpoint).
Here it's the same, if you have second endpoint then adress/size will
have to be added.
That's a bit problematic. Consider either the use case of DTO which adds
the other display, or even a custom board DTS. Without your patch, this
works:
arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
{
...
ports {
ltdc_ep0_out: endpoint@0 {
remote-endpoint = <_in>;
};
};
};
board-with-display.dts or board-overlay.dts
{
ports {
endpoint@1 { // just add another endpoint@1, no problem
remote-endpoint = <>;
};
};
};
With your patch, the DTS would have to modify the "endpoint" node to be
"endpoint@0" probably with a whole lot of /detele-node/ etc. magic (DTO
cannot do that, so that's a problem, and I do use DTOs on AV96
extensively for the various expansion cards) and then add the
endpoint@1. That becomes real complicated in custom board DT, and
impossible with DTO.
[PATCH] sched,psi: fix the 'int' underflow for psi
psi_group_cpu->tasks, represented by the unsigned int, stores the number of tasks that could be stalled on a psi resource(io/mem/cpu). Decrementing these counters at zero leads to wrapping which further leads to the psi_group_cpu->state_mask is being set with the respective pressure state. This could result into the unnecessary time sampling for the pressure state thus cause the spurious psi events. This can further lead to wrong actions being taken at the user land based on these psi events. Though psi_bug is set under these conditions but that just for debug purpose. Fix it by decrementing the ->tasks count only when it is non-zero. Signed-off-by: Charan Teja Reddy --- kernel/sched/psi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c index 967732c..f925468 100644 --- a/kernel/sched/psi.c +++ b/kernel/sched/psi.c @@ -718,7 +718,8 @@ static void psi_group_change(struct psi_group *group, int cpu, groupc->tasks[3], clear, set); psi_bug = 1; } - groupc->tasks[t]--; + if (groupc->tasks[t]) + groupc->tasks[t]--; } for (t = 0; set; set &= ~(1 << t), t++) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH] locking/qrwlock: Fix ordering in queued_write_lock_slowpath
While this code is executed with the wait_lock held, a reader can
acquire the lock without holding wait_lock. The writer side loops
checking the value with the atomic_cond_read_acquire(), but only truly
acquires the lock when the compare-and-exchange is completed
successfully which isn’t ordered. The other atomic operations from this
point are release-ordered and thus reads after the lock acquisition can
be completed before the lock is truly acquired which violates the
guarantees the lock should be making.
Fixes: b519b56e378ee ("locking/qrwlock: Use atomic_cond_read_acquire() when
spinning in qrwloc")
Signed-off-by: Ali Saidi
Cc: sta...@vger.kernel.org
---
kernel/locking/qrwlock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/locking/qrwlock.c b/kernel/locking/qrwlock.c
index 4786dd271b45..10770f6ac4d9 100644
--- a/kernel/locking/qrwlock.c
+++ b/kernel/locking/qrwlock.c
@@ -73,8 +73,8 @@ void queued_write_lock_slowpath(struct qrwlock *lock)
/* When no more readers or writers, set the locked flag */
do {
- atomic_cond_read_acquire(>cnts, VAL == _QW_WAITING);
- } while (atomic_cmpxchg_relaxed(>cnts, _QW_WAITING,
+ atomic_cond_read_relaxed(>cnts, VAL == _QW_WAITING);
+ } while (atomic_cmpxchg_acquire(>cnts, _QW_WAITING,
_QW_LOCKED) != _QW_WAITING);
unlock:
arch_spin_unlock(>wait_lock);
--
2.24.4.AMZN
Re: [PATCH v1] ASoC: Intel: kbl_da7219_max98927: Fix kabylake_ssp_fixup function
On 4/15/21 7:43 AM, Lukasz Majczak wrote:
kabylake_ssp_fixup function uses snd_soc_dpcm to identify the
codecs DAIs. The HW parameters are changed based on the codec DAI of the
stream. The earlier approach to get snd_soc_dpcm was using container_of()
macro on snd_pcm_hw_params.
The structures have been modified over time and snd_soc_dpcm does not have
snd_pcm_hw_params as a reference but as a copy. This causes the current
driver to crash when used.
This patch changes the way snd_soc_dpcm is extracted. snd_soc_pcm_runtime
holds 2 dpcm instances (one for playback and one for capture). 2 codecs
on the SSP are dmic (capture) and speakers (playback). Based on the
stream direction, snd_soc_dpcm is extracted from snd_soc_pcm_runtime.
Tested for all use cases of the driver.
Based on similar fix in kbl_rt5663_rt5514_max98927.c
from Harsha Priya and
Vamshi Krishna Gopal
Cc: # 5.4+
Signed-off-by: Lukasz Majczak
---
Hi,
This is basically a cherry-pick of this change:
https://patchwork.kernel.org/project/alsa-devel/patch/1595432147-11166-1-git-send-email-harshapriy...@intel.com/
just applied to the kbl_da7219_max98927.
Best regards,
Lukasz
Acked-by: Pierre-Louis Bossart
sound/soc/intel/boards/kbl_da7219_max98927.c | 38 +++-
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/sound/soc/intel/boards/kbl_da7219_max98927.c
b/sound/soc/intel/boards/kbl_da7219_max98927.c
index 9dfe5bd9180d..4b7b4a044f81 100644
--- a/sound/soc/intel/boards/kbl_da7219_max98927.c
+++ b/sound/soc/intel/boards/kbl_da7219_max98927.c
@@ -284,11 +284,33 @@ static int kabylake_ssp_fixup(struct snd_soc_pcm_runtime
*rtd,
struct snd_interval *chan = hw_param_interval(params,
SNDRV_PCM_HW_PARAM_CHANNELS);
struct snd_mask *fmt = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
- struct snd_soc_dpcm *dpcm = container_of(
- params, struct snd_soc_dpcm, hw_params);
- struct snd_soc_dai_link *fe_dai_link = dpcm->fe->dai_link;
- struct snd_soc_dai_link *be_dai_link = dpcm->be->dai_link;
+ struct snd_soc_dpcm *dpcm, *rtd_dpcm = NULL;
+ /*
+* The following loop will be called only for playback stream
+* In this platform, there is only one playback device on every SSP
+*/
+ for_each_dpcm_fe(rtd, SNDRV_PCM_STREAM_PLAYBACK, dpcm) {
+ rtd_dpcm = dpcm;
+ break;
+ }
+
+ /*
+* This following loop will be called only for capture stream
+* In this platform, there is only one capture device on every SSP
+*/
+ for_each_dpcm_fe(rtd, SNDRV_PCM_STREAM_CAPTURE, dpcm) {
+ rtd_dpcm = dpcm;
+ break;
+ }
+
+ if (!rtd_dpcm)
+ return -EINVAL;
+
+ /*
+* The above 2 loops are mutually exclusive based on the stream
direction,
+* thus rtd_dpcm variable will never be overwritten
+*/
/*
* Topology for kblda7219m98373 & kblmax98373 supports only S24_LE,
* where as kblda7219m98927 & kblmax98927 supports S16_LE by default.
@@ -311,9 +333,9 @@ static int kabylake_ssp_fixup(struct snd_soc_pcm_runtime
*rtd,
/*
* The ADSP will convert the FE rate to 48k, stereo, 24 bit
*/
- if (!strcmp(fe_dai_link->name, "Kbl Audio Port") ||
- !strcmp(fe_dai_link->name, "Kbl Audio Headset Playback") ||
- !strcmp(fe_dai_link->name, "Kbl Audio Capture Port")) {
+ if (!strcmp(rtd_dpcm->fe->dai_link->name, "Kbl Audio Port") ||
+ !strcmp(rtd_dpcm->fe->dai_link->name, "Kbl Audio Headset Playback")
||
+ !strcmp(rtd_dpcm->fe->dai_link->name, "Kbl Audio Capture Port")) {
rate->min = rate->max = 48000;
chan->min = chan->max = 2;
snd_mask_none(fmt);
@@ -324,7 +346,7 @@ static int kabylake_ssp_fixup(struct snd_soc_pcm_runtime
*rtd,
* The speaker on the SSP0 supports S16_LE and not S24_LE.
* thus changing the mask here
*/
- if (!strcmp(be_dai_link->name, "SSP0-Codec"))
+ if (!strcmp(rtd_dpcm->be->dai_link->name, "SSP0-Codec"))
snd_mask_set_format(fmt, SNDRV_PCM_FORMAT_S16_LE);
return 0;
[PATCH 1/1] char: hpet: Remove unused local variable 'm' in hpet_interrupt()
Commit 273ef9509b79 ("drivers/char/hpet.c: fix periodic-emulation for
delayed interrupt") removed the reference to local variable 'm', but
forgot to remove the definition and assignment of it. Due to
read_counter() indirectly calls "read barrier", the performance is
slightly degraded.
Since the following comments give some description based on 'm', so move
the assignment of 'm' into it.
Fixes: 273ef9509b79 ("drivers/char/hpet.c: fix periodic-emulation for delayed
interrupt")
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
---
drivers/char/hpet.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index ed3b7dab678dbd1..46950a0cda181a1 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -156,14 +156,16 @@ static irqreturn_t hpet_interrupt(int irq, void *data)
* This has the effect of treating non-periodic like periodic.
*/
if ((devp->hd_flags & (HPET_IE | HPET_PERIODIC)) == HPET_IE) {
- unsigned long m, t, mc, base, k;
+ unsigned long t, mc, base, k;
struct hpet __iomem *hpet = devp->hd_hpet;
struct hpets *hpetp = devp->hd_hpets;
t = devp->hd_ireqfreq;
- m = read_counter(>hd_timer->hpet_compare);
mc = read_counter(>hpet_mc);
- /* The time for the next interrupt would logically be t + m,
+ /*
+* m = read_counter(>hd_timer->hpet_compare);
+*
+* The time for the next interrupt would logically be t + m,
* however, if we are very unlucky and the interrupt is delayed
* for longer than t then we will completely miss the next
* interrupt if we set t + m and an application will hang.
--
2.26.0.106.g9fadedd
[PATCH v1 1/1] lightnvm: pblk: Import GUID before use
Strictly speaking the comparison between guid_t and raw buffer
is not correct. Import GUID to variable of guid_t type and then
compare.
Signed-off-by: Andy Shevchenko
---
drivers/lightnvm/pblk-recovery.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/lightnvm/pblk-recovery.c b/drivers/lightnvm/pblk-recovery.c
index 0e6f0c76e930..81b1b751d8c4 100644
--- a/drivers/lightnvm/pblk-recovery.c
+++ b/drivers/lightnvm/pblk-recovery.c
@@ -661,6 +661,7 @@ struct pblk_line *pblk_recov_l2p(struct pblk *pblk)
int meta_line;
int i, valid_uuid = 0;
LIST_HEAD(recov_list);
+ guid_t guid;
/* TODO: Implement FTL snapshot */
@@ -704,14 +705,15 @@ struct pblk_line *pblk_recov_l2p(struct pblk *pblk)
return ERR_PTR(-EINVAL);
}
+ import_guid(, smeta_buf->header.uuid);
+
/* The first valid instance uuid is used for initialization */
if (!valid_uuid) {
- import_guid(>instance_uuid,
smeta_buf->header.uuid);
+ guid_copy(>instance_uuid, );
valid_uuid = 1;
}
- if (!guid_equal(>instance_uuid,
- (guid_t *)_buf->header.uuid)) {
+ if (!guid_equal(>instance_uuid, )) {
pblk_debug(pblk, "ignore line %u due to uuid
mismatch\n",
i);
continue;
--
2.30.2
Re: [PATCH 1/1] perf map: Fix error return code in maps__clone()
On 2021/4/15 20:42, Arnaldo Carvalho de Melo wrote:
> Em Thu, Apr 15, 2021 at 05:27:44PM +0800, Zhen Lei escreveu:
>> Although 'err' has been initialized to -ENOMEM, but it will be reassigned
>> by the "err = unwind__prepare_access(...)" statement in the for loop. So
>> that, the value of 'err' is unknown when map__clone() failed.
>
> You forgot to research and add this:
>
> Fixes: 6c502584438bda63 ("perf unwind: Call unwind__prepare_access for forked
> thread")
>
> So that the sta...@kernel.org guys can pick this up automagically and
> apply this fix to the stable kernels.
>
> I've added it.
OK, thank you very much.
>
> Thanks, applied.
>
> - Arnaldo
>
>> Reported-by: Hulk Robot
>> Signed-off-by: Zhen Lei
>> ---
>> tools/perf/util/map.c | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
>> index fbc40a2c17d4dca..8af693d9678cefe 100644
>> --- a/tools/perf/util/map.c
>> +++ b/tools/perf/util/map.c
>> @@ -840,15 +840,18 @@ int maps__fixup_overlappings(struct maps *maps, struct
>> map *map, FILE *fp)
>> int maps__clone(struct thread *thread, struct maps *parent)
>> {
>> struct maps *maps = thread->maps;
>> -int err = -ENOMEM;
>> +int err;
>> struct map *map;
>>
>> down_read(>lock);
>>
>> maps__for_each_entry(parent, map) {
>> struct map *new = map__clone(map);
>> -if (new == NULL)
>> +
>> +if (new == NULL) {
>> +err = -ENOMEM;
>> goto out_unlock;
>> +}
>>
>> err = unwind__prepare_access(maps, new, NULL);
>> if (err)
>> --
>> 2.26.0.106.g9fadedd
>>
>>
>
[PATCH V2] dt-bindings: mailbox: ti,message-manager: Convert to json schema
Convert the ti,message-manager to yaml for better checks and documentation.
Differences being mostly in the examples:
- I've dropped the example usage of mailbox client, it is better done in
tisci node definition
- included header in example for buildable example
NOTE: The following checkpatch warning is generated since we do include
the header in the example, but this is a false positive warning.
WARNING: DT binding docs and includes should be a separate patch. See:
Documentation/devicetree/bindings/submitting-patches.rst
Signed-off-by: Nishanth Menon
---
Changes since v1:
- Fixed title in yaml (not driver)
- Commit message update to fix up a copy paste error (not secure-proxy).
- Subject line rewording to indicate json schema rather than yaml -
more inline with patches elsewhere.
V1: https://lore.kernel.org/linux-arm-kernel/20210414002721.23638-1...@ti.com/
.../bindings/mailbox/ti,message-manager.txt | 50 -
.../bindings/mailbox/ti,message-manager.yaml | 75 +++
2 files changed, 75 insertions(+), 50 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
create mode 100644
Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
deleted file mode 100644
index ebf0e3710cee..
--- a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Texas Instruments' Message Manager Driver
-
-
-The Texas Instruments' Message Manager is a mailbox controller that has
-configurable queues selectable at SoC(System on Chip) integration. The Message
-manager is broken up into queues in different address regions that are called
-"proxies" - each instance is unidirectional and is instantiated at SoC
-integration level to indicate receive or transmit path.
-
-Message Manager Device Node:
-===
-Required properties:
-
-- compatible: Shall be: "ti,k2g-message-manager"
-- reg-namesqueue_proxy_region - Map the queue proxy region.
- queue_state_debug_region - Map the queue state debug
- region.
-- reg: Contains the register map per reg-names.
-- #mbox-cells Shall be 2. Contains the queue ID and proxy ID in that
- order referring to the transfer path.
-- interrupt-names: Contains interrupt names matching the rx transfer path
- for a given SoC. Receive interrupts shall be of the
- format: "rx_".
- For ti,k2g-message-manager, this shall contain:
- "rx_005", "rx_057"
-- interrupts: Contains the interrupt information corresponding to
- interrupt-names property.
-
-Example(K2G):
-
-
- msgmgr: msgmgr@2a0 {
- compatible = "ti,k2g-message-manager";
- #mbox-cells = <2>;
- reg-names = "queue_proxy_region", "queue_state_debug_region";
- reg = <0x02a0 0x40>, <0x028c3400 0x400>;
- interrupt-names = "rx_005", "rx_057";
- interrupts = ,
-;
- };
-
- pmmc: pmmc {
- [...]
- mbox-names = "rx", "tx";
- # RX queue ID is 5, proxy ID is 2
- # TX queue ID is 0, proxy ID is 0
- mboxes= < 5 2>,
- < 0 0>;
- [...]
- };
diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
new file mode 100644
index ..1cbf9a75522e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/ti,message-manager.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments' message manager node bindings
+
+maintainers:
+ - Nishanth Menon
+
+description: |
+ The Texas Instruments' Message Manager is a mailbox controller that has
+ configurable queues selectable at SoC(System on Chip) integration. The
Message
+ manager is broken up into queues in different address regions that are called
+ "proxies" - each instance is unidirectional and is instantiated at SoC
+ integration level to indicate receive or transmit path.
+
+properties:
+ $nodename:
+pattern: "^mailbox@[0-9a-f]+$"
+
+ compatible:
+const: ti,k2g-message-manager
+
+ "#mbox-cells":
+const: 2
+description:
+ Contains the queue ID and proxy ID in that order referring to the
+ transfer path.
+
+ reg-names:
+items:
+
Re: [PATCH 2/3] habanalabs: support legacy and new pll indexes
On Sun, Mar 21, 2021 at 10:11:29PM +0200, Oded Gabbay wrote:
> From: Ohad Sharabi
>
> In order to use minimum of hard coded values common to LKD and F/W
> a dynamic method to work with PLLs is introduced in this patch.
> Formerly asic specific PLL numbering is now common for all asics.
> To be backward compatible a bit in dev status is defined, if the bit is
> not set LKD will keep working with old PLL numbering.
>
> Signed-off-by: Ohad Sharabi
> Reviewed-by: Oded Gabbay
> Signed-off-by: Oded Gabbay
> ---
> drivers/misc/habanalabs/common/firmware_if.c | 49 ++-
> drivers/misc/habanalabs/common/habanalabs.h | 14 --
> drivers/misc/habanalabs/common/sysfs.c| 24 ++---
> drivers/misc/habanalabs/gaudi/gaudi.c | 33 +
> drivers/misc/habanalabs/goya/goya.c | 26 ++
> .../misc/habanalabs/include/common/cpucp_if.h | 41
> .../habanalabs/include/common/hl_boot_if.h| 6 +++
> .../habanalabs/include/gaudi/gaudi_fw_if.h| 14 --
> .../misc/habanalabs/include/goya/goya_fw_if.h | 11 -
> 9 files changed, 182 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/misc/habanalabs/common/firmware_if.c
> b/drivers/misc/habanalabs/common/firmware_if.c
> index 2a58edaf984a..092691a8917d 100644
> --- a/drivers/misc/habanalabs/common/firmware_if.c
> +++ b/drivers/misc/habanalabs/common/firmware_if.c
> @@ -539,18 +539,63 @@ int hl_fw_cpucp_total_energy_get(struct hl_device
> *hdev, u64 *total_energy)
> return rc;
> }
>
> -int hl_fw_cpucp_pll_info_get(struct hl_device *hdev, u16 pll_index,
> +int get_used_pll_index(struct hl_device *hdev, enum pll_index
> input_pll_index,
> + enum pll_index *pll_index)
> +{
> + struct asic_fixed_properties *prop = >asic_prop;
> + u8 pll_byte, pll_bit_off;
> + bool dynamic_pll;
> +
> + if (input_pll_index >= PLL_MAX) {
> + dev_err(hdev->dev, "PLL index %d is out of range\n",
> + input_pll_index);
> + return -EINVAL;
> + }
> +
> + dynamic_pll = prop->fw_security_status_valid &&
> + (prop->fw_app_security_map & CPU_BOOT_DEV_STS0_DYN_PLL_EN);
> +
> + if (!dynamic_pll) {
> + /*
> + * in case we are working with legacy FW (each asic has unique
> + * PLL numbering) extract the legacy numbering
> + */
> + *pll_index = hdev->legacy_pll_map[input_pll_index];
> + return 0;
> + }
> +
> + /* PLL map is a u8 array */
> + pll_byte = prop->cpucp_info.pll_map[input_pll_index >> 3];
> + pll_bit_off = input_pll_index & 0x7;
> +
> + if (!(pll_byte & BIT(pll_bit_off))) {
> + dev_err(hdev->dev, "PLL index %d is not supported\n",
> + input_pll_index);
> + return -EINVAL;
> + }
> +
> + *pll_index = input_pll_index;
> +
> + return 0;
> +}
> +
> +int hl_fw_cpucp_pll_info_get(struct hl_device *hdev, enum pll_index
> pll_index,
> u16 *pll_freq_arr)
> {
> struct cpucp_packet pkt;
> + enum pll_index used_pll_idx;
> u64 result;
> int rc;
>
> + rc = get_used_pll_index(hdev, pll_index, _pll_idx);
> + if (rc)
> + return rc;
> +
> memset(, 0, sizeof(pkt));
>
> pkt.ctl = cpu_to_le32(CPUCP_PACKET_PLL_INFO_GET <<
> CPUCP_PKT_CTL_OPCODE_SHIFT);
> - pkt.pll_type = __cpu_to_le16(pll_index);
> + pkt.pll_type = __cpu_to_le16((u16)used_pll_idx);
>
> rc = hdev->asic_funcs->send_cpu_message(hdev, (u32 *) , sizeof(pkt),
> HL_CPUCP_INFO_TIMEOUT_USEC, );
> diff --git a/drivers/misc/habanalabs/common/habanalabs.h
> b/drivers/misc/habanalabs/common/habanalabs.h
> index 65f34918faed..dc8126b270d1 100644
> --- a/drivers/misc/habanalabs/common/habanalabs.h
> +++ b/drivers/misc/habanalabs/common/habanalabs.h
> @@ -1946,6 +1946,8 @@ struct hl_mmu_funcs {
> * @aggregated_cs_counters: aggregated cs counters among all contexts
> * @mmu_priv: device-specific MMU data.
> * @mmu_func: device-related MMU functions.
> + * @legacy_pll_map: map holding map between dynamic (common) PLL indexes and
> + * static (asic specific) PLL indexes.
> * @dram_used_mem: current DRAM memory consumption.
> * @timeout_jiffies: device CS timeout value.
> * @max_power: the max power of the device, as configured by the sysadmin.
> This
> @@ -2070,6 +2072,8 @@ struct hl_device {
> struct hl_mmu_priv mmu_priv;
> struct hl_mmu_funcs mmu_func[MMU_NUM_PGT_LOCATIONS];
>
> + enum pll_index *legacy_pll_map;
> +
> atomic64_t dram_used_mem;
> u64 timeout_jiffies;
> u64 max_power;
> @@ -2383,7 +2387,9 @@
Re: [PATCH 00/13] tty.h cleanups
On Thu, Apr 15, 2021 at 10:21:54AM +0200, Greg Kroah-Hartman wrote: > On Fri, Apr 09, 2021 at 09:32:45AM +0200, Johan Hovold wrote: > > On Thu, Apr 08, 2021 at 08:01:08PM +0200, Greg Kroah-Hartman wrote: > > > On Thu, Apr 08, 2021 at 04:25:22PM +0200, Johan Hovold wrote: > > > > On Thu, Apr 08, 2021 at 02:51:21PM +0200, Greg Kroah-Hartman wrote: > > > > > Turns out there is a lot of tty-internal stuff in include/linux/tty.h > > > > > that do not belong there. Create a internal-to-the-tty-layer .h file > > > > > for these types of things and move function prototypes to it instead > > > > > of > > > > > being in the system-wide header file. > > > > > > > > > > Along the way clean up the use of some old tty-only debugging macros > > > > > and > > > > > use the in-kernel dev_*() calls instead. > > > > > > > > I'm afraid that's not a good idea since not all ttys have a > > > > corresponding class device. Notable exception include pseudo terminals > > > > and serdev. > > > > > > > > While dev_printk() can handle a NULL device argument without crashing, > > > > we'll actually lose log information by removing the tty printk helpers. > > > > > > I think the same info will be printed here as before, just some NULL > > > information at the beginning, right? And the benifits overall (for real > > > tty devices), should outweigh the few devices that do not have this > > > information. > > > > No, you'll only be losing information (tty driver and tty name). Here's > > a pty example, where the first line in each pair use dev_info() and the > > second tty_info(): > > > > [ 10.235331] (NULL device *): tty_get_device > > [ 10.235441] ptm ptm0: tty_get_device > > > > [ 10.235586] (NULL device *): tty_get_device > > [ 10.235674] pts pts0: tty_get_device > > > > and similar for serdev, which is becoming more and more common. > > Ok, good point, I'll go apply only the first 2 patches in this series > (moving the macros out of tty.h and removing the unused one) and then > will redo this set of patches again. Perhaps no harm in leaving the tty_info() on in there for consistency. We have users of the _ratelimited() flavour of it (even if there's no dependency). > I think a better tty_msg() macro is warrented so that we can provide > dev_*() output if we have a device, otherwise fall back to the old > style to preserve functionality. Possibly, but the dev_printk() for the tty class devices wouldn't provide any more info than what's already there (i.e. driver name + tty name). (And associating ttys with other devices and drivers (e.g. a serdev client and its driver) might not be what we want since you lose the connection to the underlying tty driver.) Johan
Re: [PATCH RFC 01/22] asm-generic/hyperv: add HV_STATUS_ACCESS_DENIED definition
On Tue, Apr 13, 2021 at 02:26:09PM +0200, Vitaly Kuznetsov wrote:
> From TLFSv6.0b, this status means: "The caller did not possess sufficient
> access rights to perform the requested operation."
>
> Signed-off-by: Vitaly Kuznetsov
This can be applied to hyperv-next right away. Let me know what you
think.
Wei.
> ---
> include/asm-generic/hyperv-tlfs.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/asm-generic/hyperv-tlfs.h
> b/include/asm-generic/hyperv-tlfs.h
> index 83448e837ded..e01a3bade13a 100644
> --- a/include/asm-generic/hyperv-tlfs.h
> +++ b/include/asm-generic/hyperv-tlfs.h
> @@ -187,6 +187,7 @@ enum HV_GENERIC_SET_FORMAT {
> #define HV_STATUS_INVALID_HYPERCALL_INPUT3
> #define HV_STATUS_INVALID_ALIGNMENT 4
> #define HV_STATUS_INVALID_PARAMETER 5
> +#define HV_STATUS_ACCESS_DENIED 6
> #define HV_STATUS_OPERATION_DENIED 8
> #define HV_STATUS_INSUFFICIENT_MEMORY11
> #define HV_STATUS_INVALID_PORT_ID17
> --
> 2.30.2
>
Re: [PATCH v4 1/6] perf arm-spe: Remove unused enum value ARM_SPE_PER_CPU_MMAPS
On 12/04/2021 12:10, Leo Yan wrote:
> The enum value 'ARM_SPE_PER_CPU_MMAPS' is never used so remove it.
Hi Leo,
I think this causes an error when attempting to open a newly recorded file
with an old version of perf. The value ARM_SPE_AUXTRACE_PRIV_MAX is used here:
size_t min_sz = sizeof(u64) * ARM_SPE_AUXTRACE_PRIV_MAX;
struct perf_record_time_conv *tc = >time_conv;
struct arm_spe *spe;
int err;
if (auxtrace_info->header.size < sizeof(struct
perf_record_auxtrace_info) +
min_sz)
return -EINVAL;
And removing ARM_SPE_PER_CPU_MMAPS changes the value of
ARM_SPE_AUXTRACE_PRIV_MAX.
At least I think that's what's causing the problem. I get this error:
./perf report -i per-thread-spe-time.data
0x1c0 [0x18]: failed to process type: 70 [Invalid argument]
Error:
failed to process sample
# To display the perf.data header info, please use
--header/--header-only options.
#
James
>
> Signed-off-by: Leo Yan
> ---
> tools/perf/util/arm-spe.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/tools/perf/util/arm-spe.h b/tools/perf/util/arm-spe.h
> index 98d3235781c3..105ce0ea0a01 100644
> --- a/tools/perf/util/arm-spe.h
> +++ b/tools/perf/util/arm-spe.h
> @@ -11,7 +11,6 @@
>
> enum {
> ARM_SPE_PMU_TYPE,
> - ARM_SPE_PER_CPU_MMAPS,
> ARM_SPE_AUXTRACE_PRIV_MAX,
> };
>
>
Re: [PATCH] dt-bindings: mailbox: ti,message-manager: Convert to yaml
On 19:32-20210415, Lokesh Vutla wrote: > [..snip..] > > > diff --git > > a/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml > > b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml > > new file mode 100644 > > index ..4987e803ac37 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml > > @@ -0,0 +1,75 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/mailbox/ti,message-manager.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Texas Instruments' Message Manager Driver > > Driver is not the right word here. Can you change it to node? Indeed, thanks. v2 incoming. I also noticed a commit message typo while at it. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2] iommu/vt-d: Force to flush iotlb before creating superpage
On Thu, Apr 15, 2021 at 08:46:28AM +0800, Longpeng(Mike) wrote:
> Fixes: 6491d4d02893 ("intel-iommu: Free old page tables before creating
> superpage")
> Cc: # v3.0+
> Link:
> https://lore.kernel.org/linux-iommu/670baaf8-4ff8-4e84-4be3-030b95ab5...@huawei.com/
> Suggested-by: Lu Baolu
> Signed-off-by: Longpeng(Mike)
> ---
> v1 -> v2:
> - add Joerg
> - reconstruct the solution base on the Baolu's suggestion
> ---
> drivers/iommu/intel/iommu.c | 52
> +
> 1 file changed, 38 insertions(+), 14 deletions(-)
Applied, thanks.
Re: [PATCH] nfsd: remove unused function
> On Apr 15, 2021, at 4:38 AM, Jiapeng Chong
> wrote:
>
> Fix the following clang warning:
>
> fs/nfsd/nfs4state.c:6276:1: warning: unused function 'end_offset'
> [-Wunused-function].
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
Thanks for your patch. It's been added to the for-next topic branch in
git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
> ---
> fs/nfsd/nfs4state.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index 97447a6..32b11ff 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -6272,15 +6272,6 @@ static void nfsd4_close_open_stateid(struct
> nfs4_ol_stateid *s)
> return status;
> }
>
> -static inline u64
> -end_offset(u64 start, u64 len)
> -{
> - u64 end;
> -
> - end = start + len;
> - return end >= start ? end: NFS4_MAX_UINT64;
> -}
> -
> /* last octet in a range */
> static inline u64
> last_byte_offset(u64 start, u64 len)
> --
> 1.8.3.1
>
--
Chuck Lever
Re: [PATCH] PM / EM: Inefficient OPPs detection
On Thu, Apr 15, 2021 at 01:12:05PM +, Quentin Perret wrote: > Hi Vincent, > > On Thursday 08 Apr 2021 at 18:10:29 (+0100), Vincent Donnefort wrote: > > Some SoCs, such as the sd855 have OPPs within the same performance domain, > > whose cost is higher than others with a higher frequency. Even though > > those OPPs are interesting from a cooling perspective, it makes no sense > > to use them when the device can run at full capacity. Those OPPs handicap > > the performance domain, when choosing the most energy-efficient CPU and > > are wasting energy. They are inefficient. > > > > Hence, add support for such OPPs to the Energy Model, which creates for > > each OPP a performance state. The Energy Model can now be read using the > > regular table, which contains all performance states available, or using > > an efficient table, where inefficient performance states (and by > > extension, inefficient OPPs) have been removed. > > > > Currently, the efficient table is used in two paths. Schedutil, and > > find_energy_efficient_cpu(). We have to modify both paths in the same > > patch so they stay synchronized. The thermal framework still relies on > > the original table and hence, DevFreq devices won't create the efficient > > table. > > > > As used in the hot-path, the efficient table is a lookup table, generated > > dynamically when the perf domain is created. The complexity of searching > > a performance state is hence changed from O(n) to O(1). This also > > speeds-up em_cpu_energy() even if no inefficient OPPs have been found. > > Interesting. Do you have measurements showing the benefits on wake-up > duration? I remember doing so by hacking the wake-up path to force tasks > into feec()/compute_energy() even when overutilized, and then running > hackbench. Maybe something like that would work for you? I'll give a try and see if I get improved numbers. > > Just want to make sure we actually need all that complexity -- while > it's good to reduce the asymptotic complexity, we're looking at a rather > small problem (max 30 OPPs or so I expect?), so other effects may be > dominating. Simply skipping inefficient OPPs could be implemented in a > much simpler way I think. I could indeed just skip the perf state if marked as ineffective. But the idea was to avoid bringing another for loop in this hot-path. Also, not covered by this patch but probably we could get rid of the EM complexity limit as the table resolution is way faster with this change. > > Thanks, > Quentin
Re: [PATCH] staging: media: atomisp: pci: Change line break to avoid an open parenthesis at the end of the line
On 14/04/2021 22:56, Aline Santana Cordeiro wrote: > Change line break to avoid an open parenthesis at the end of the line. > It consequently removed spaces at the start of the subsequent line. > Both issues detected by checkpatch.pl. > > Signed-off-by: Aline Santana Cordeiro > --- > drivers/staging/media/atomisp/pci/atomisp_cmd.h | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.h > b/drivers/staging/media/atomisp/pci/atomisp_cmd.h > index 1c0d464..8c4fc2b 100644 > --- a/drivers/staging/media/atomisp/pci/atomisp_cmd.h > +++ b/drivers/staging/media/atomisp/pci/atomisp_cmd.h > @@ -75,8 +75,8 @@ void atomisp_wdt(struct timer_list *t); > void atomisp_setup_flash(struct atomisp_sub_device *asd); > irqreturn_t atomisp_isr(int irq, void *dev); > irqreturn_t atomisp_isr_thread(int irq, void *isp_ptr); > -const struct atomisp_format_bridge *get_atomisp_format_bridge_from_mbus( > -u32 mbus_code); > +const struct atomisp_format_bridge > +*get_atomisp_format_bridge_from_mbus(u32 mbus_code); You keep the * on the previous line since it is part of the return type. Regards, Hans > bool atomisp_is_mbuscode_raw(uint32_t code); > int atomisp_get_frame_pgnr(struct atomisp_device *isp, > const struct ia_css_frame *frame, u32 *p_pgnr); > @@ -381,9 +381,9 @@ enum mipi_port_id __get_mipi_port(struct atomisp_device > *isp, > > bool atomisp_is_vf_pipe(struct atomisp_video_pipe *pipe); > > -void atomisp_apply_css_parameters( > -struct atomisp_sub_device *asd, > -struct atomisp_css_params *css_param); > +void atomisp_apply_css_parameters(struct atomisp_sub_device *asd, > + struct atomisp_css_params *css_param); > + > void atomisp_free_css_parameters(struct atomisp_css_params *css_param); > > void atomisp_handle_parameter_and_buffer(struct atomisp_video_pipe *pipe); >
Re: [PATCH v3 12/27] perf parse-events: Support no alias assigned event inside hybrid PMU
On Thu, Apr 15, 2021 at 09:36:16PM +0800, Jin, Yao wrote:
SNIP
> > > + int n = 0;
> > > +
> > > + list_for_each(pos, list)
> > > + n++;
> > > +
> > > + return n;
> > > +}
> > > +
> > > +static int parse_events__with_hybrid_pmu(struct parse_events_state
> > > *parse_state,
> > > + const char *str, char *pmu_name,
> > > + bool *found, struct list_head *list)
> > > +{
> > > + struct parse_events_state ps = {
> > > + .list = LIST_HEAD_INIT(ps.list),
> > > + .stoken = PE_START_EVENTS,
> > > + .pmu_name = pmu_name,
> > > + .idx= parse_state->idx,
> > > + };
> >
> > could we add this pmu_name directly to __parse_events?
> >
>
> Do you suggest we directly call __parse_events()?
>
> int __parse_events(struct evlist *evlist, const char *str,
> struct parse_events_error *err, struct perf_pmu *fake_pmu)
>
> struct parse_events_state parse_state = {
> .list = LIST_HEAD_INIT(parse_state.list),
> .idx = evlist->core.nr_entries,
> .error= err,
> .evlist = evlist,
> .stoken = PE_START_EVENTS,
> .fake_pmu = fake_pmu,
> };
>
> But for parse_events__with_hybrid_pmu, we don't have valid evlist. So if we
> switch to __parse_events, evlist processing may be a problem.
you should use parse_state->evlist no? but we can chec/make this
change in next itaration.. it's already lot of changes
jirka
Re: [PATCH 09/11] mm/page_alloc: Avoid conflating IRQs disabled with zone->lock
On Thu, Apr 15, 2021 at 02:25:36PM +0200, Vlastimil Babka wrote:
> > @@ -3294,6 +3295,7 @@ void free_unref_page_list(struct list_head *list)
> > struct page *page, *next;
> > unsigned long flags, pfn;
> > int batch_count = 0;
> > + int migratetype;
> >
> > /* Prepare pages for freeing */
> > list_for_each_entry_safe(page, next, list, lru) {
> > @@ -3301,15 +3303,28 @@ void free_unref_page_list(struct list_head *list)
> > if (!free_unref_page_prepare(page, pfn))
> > list_del(>lru);
> > set_page_private(page, pfn);
>
> Should probably move this below so we don't set private for pages that then go
> through free_one_page()? Doesn't seem to be a bug, just unneccessary.
>
Sure.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 1d87ca364680..a9c1282d9c7b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3293,7 +3293,6 @@ void free_unref_page_list(struct list_head *list)
pfn = page_to_pfn(page);
if (!free_unref_page_prepare(page, pfn))
list_del(>lru);
- set_page_private(page, pfn);
/*
* Free isolated pages directly to the allocator, see
@@ -3307,6 +3306,8 @@ void free_unref_page_list(struct list_head *list)
list_del(>lru);
}
}
+
+ set_page_private(page, pfn);
}
local_lock_irqsave(, flags);
--
Mel Gorman
SUSE Labs
UBSAN: array-index-out-of-bounds in ehci_hub_control
Hi,
I've got this report while booting v5.10.13 kernel, but upstream code
seems to be the same.
The access to port_status, the code is:
struct ehci_regs {
u32 port_status[0]; /* up to N_PORTS */
u32 reserved3[9];
https://elixir.bootlin.com/linux/v5.12-rc7/source/include/linux/usb/ehci_def.h#L130
Question: should it be an empty array "[]" to prevent the undefined behavior?
Or should it be declared as "[9]" to be more explicit?
UBSAN: array-index-out-of-bounds in drivers/usb/host/ehci-hub.c:893:16
index 1 is out of range for type 'u32 [0]'
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.10.13+ #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.13.0-44-g88ab0c15525c-prebuilt.qemu.org 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x183/0x225 lib/dump_stack.c:118
ubsan_epilogue lib/ubsan.c:148 [inline]
__ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:356
ehci_hub_control+0x1d27/0x2370 drivers/usb/host/ehci-hub.c:893
rh_call_control+0x938/0x11a0 drivers/usb/core/hcd.c:683
rh_urb_enqueue drivers/usb/core/hcd.c:842 [inline]
usb_hcd_submit_urb+0x2f2/0x5f0 drivers/usb/core/hcd.c:1543
usb_start_wait_urb+0x11a/0x550 drivers/usb/core/message.c:58
usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
usb_control_msg+0x281/0x470 drivers/usb/core/message.c:153
hub_power_on+0x1a8/0x3c0 arch/x86/include/asm/bitops.h:219
hub_activate+0x330/0x1ba0 drivers/usb/core/hub.c:1076
hub_configure+0x19e0/0x2690 drivers/usb/core/hub.c:1680
hub_probe+0x82f/0x9b0 drivers/usb/core/hub.c:1882
usb_probe_interface+0x67b/0xb70 drivers/usb/core/driver.c:396
really_probe+0x58b/0x1580 drivers/base/dd.c:558
driver_probe_device+0x15a/0x310 drivers/base/dd.c:740
bus_for_each_drv+0x16a/0x1f0 drivers/base/bus.c:431
__device_attach+0x2b2/0x4b0 drivers/base/dd.c:914
bus_probe_device+0xb8/0x200 drivers/base/bus.c:491
device_add+0x8e7/0xcb0 drivers/base/core.c:2954
usb_set_configuration+0x1b98/0x2230 drivers/usb/core/message.c:2159
usb_generic_driver_probe+0x83/0x140 drivers/usb/core/generic.c:238
usb_probe_device+0x13a/0x260 drivers/usb/core/driver.c:293
really_probe+0x58b/0x1580 drivers/base/dd.c:558
driver_probe_device+0x15a/0x310 drivers/base/dd.c:740
bus_for_each_drv+0x16a/0x1f0 drivers/base/bus.c:431
__device_attach+0x2b2/0x4b0 drivers/base/dd.c:914
bus_probe_device+0xb8/0x200 drivers/base/bus.c:491
device_add+0x8e7/0xcb0 drivers/base/core.c:2954
usb_new_device+0xa43/0x1120 drivers/usb/core/hub.c:2554
register_root_hub+0x214/0x560 drivers/usb/core/hcd.c:1009
usb_add_hcd+0x8ee/0x1080 drivers/usb/core/hcd.c:2793
usb_hcd_pci_probe+0xa61/0x1280 drivers/usb/core/hcd-pci.c:264
local_pci_probe drivers/pci/pci-driver.c:308 [inline]
pci_call_probe drivers/pci/pci-driver.c:365 [inline]
__pci_device_probe drivers/pci/pci-driver.c:390 [inline]
pci_device_probe+0x3ef/0x630 drivers/pci/pci-driver.c:433
really_probe+0x544/0x1580 drivers/base/dd.c:554
driver_probe_device+0x15a/0x310 drivers/base/dd.c:740
device_driver_attach+0x176/0x280 drivers/base/dd.c:1015
__driver_attach+0xa7/0x490 drivers/base/dd.c:1092
bus_for_each_dev+0x168/0x1d0 drivers/base/bus.c:305
bus_add_driver+0x324/0x5e0 drivers/base/bus.c:622
driver_register+0x2e9/0x3e0 drivers/base/driver.c:171
do_one_initcall+0x1a3/0x410 init/main.c:1217
do_initcall_level+0x168/0x218 init/main.c:1290
do_initcalls+0x50/0x91 init/main.c:1306
kernel_init_freeable+0x33b/0x47f init/main.c:1527
kernel_init+0xd/0x290 init/main.c:1415
Re: [PATCH v3] firmware_loader: fix use-after-free in firmware_fallback_sysfs
On 4/14/21 9:26 AM, Shuah Khan wrote:
On 4/14/21 6:55 AM, Luis Chamberlain wrote:
Shuah, a question for you toward the end here.
On Wed, Apr 14, 2021 at 02:24:05PM +0530, Anirudh Rayabharam wrote:
This use-after-free happens when a fw_priv object has been freed but
hasn't been removed from the pending list (pending_fw_head). The next
time fw_load_sysfs_fallback tries to insert into the list, it ends up
accessing the pending_list member of the previoiusly freed fw_priv.
The root cause here is that all code paths that abort the fw load
don't delete it from the pending list. For example:
_request_firmware()
-> fw_abort_batch_reqs()
-> fw_state_aborted()
To fix this, delete the fw_priv from the list in __fw_set_state() if
the new state is DONE or ABORTED. This way, all aborts will remove
the fw_priv from the list. Accordingly, remove calls to list_del_init
that were being made before calling fw_state_(aborted|done).
Also, in fw_load_sysfs_fallback, don't add the fw_priv to the pending
list if it is already aborted. Instead, just jump out and return early.
Fixes: bcfbd3523f3c ("firmware: fix a double abort case with
fw_load_sysfs_fallback")
Reported-by: syzbot+de271708674e20930...@syzkaller.appspotmail.com
Tested-by: syzbot+de271708674e20930...@syzkaller.appspotmail.com
Signed-off-by: Anirudh Rayabharam
---
Changes in v3:
Modified the patch to incorporate suggestions by Luis Chamberlain in
order to fix the root cause instead of applying a "band-aid" kind of
fix.
https://lore.kernel.org/lkml/20210403013143.gv4...@42.do-not-panic.com/
Changes in v2:
1. Fixed 1 error and 1 warning (in the commit message) reported by
checkpatch.pl. The error was regarding the format for referring to
another commit "commit ("oneline")". The warning was for line
longer than 75 chars.
---
drivers/base/firmware_loader/fallback.c | 8 ++--
drivers/base/firmware_loader/firmware.h | 6 +-
drivers/base/firmware_loader/main.c | 2 ++
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/base/firmware_loader/fallback.c
b/drivers/base/firmware_loader/fallback.c
index 91899d185e31..73581b6998b4 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -94,7 +94,6 @@ static void __fw_load_abort(struct fw_priv *fw_priv)
if (fw_sysfs_done(fw_priv))
return;
- list_del_init(_priv->pending_list);
fw_state_aborted(fw_priv);
}
@@ -280,7 +279,6 @@ static ssize_t firmware_loading_store(struct
device *dev,
* Same logic as fw_load_abort, only the DONE bit
* is ignored and we set ABORT only on failure.
*/
- list_del_init(_priv->pending_list);
if (rc) {
fw_state_aborted(fw_priv);
written = rc;
@@ -513,6 +511,11 @@ static int fw_load_sysfs_fallback(struct
fw_sysfs *fw_sysfs, long timeout)
}
mutex_lock(_lock);
+ if (fw_state_is_aborted(fw_priv)) {
+ mutex_unlock(_lock);
+ retval = -EAGAIN;
+ goto out;
+ }
Thanks for the quick follow up!
This would regress commit 76098b36b5db1 ("firmware: send -EINTR on
signal abort on fallback mechanism") which I had mentioned in my follow
up email you posted a link to. It would regress it since the condition
is just being met earlier and you nullify the effort. So essentially
on Android you would make not being able to detect signal handlers
like the SIGCHLD signal sent to init, if init was the same process
dealing with the sysfs fallback firmware upload.
The way I dealt with this in my patch was I decided to return -EINTR
in the earlier case in the hunk you added, instead of -EAGAIN. In
addition to this, later on fw_load_sysfs_fallback() when
fw_sysfs_wait_timeout() is used that would also deal with checking
for error codes on wait, and only then check if it was a signal
that cancelled things (the check for -ERESTARTSYS). We therefore
only send to userspace -EAGAIN when the wait really did hit the
timeout.
But also note that my change added a check for
fw_state_is_aborted(fw_priv) inside fw_sysfs_wait_timeout(),
as that was a recently intended goal.
In either case I documented well *why* we do these error checks
before sending a code to userspace on fw_sysfs_wait_timeout() since
otherwise it would be easy to regress that code, so please also
document that as I did.
I'll re-iterate again also:
Shuah's commit 0542ad88fbdd81bb ("firmware loader: Fix
_request_firmware_load() return val for fw load abort") also
wanted to
distinguish the timeout vs -ENOMEM, but for some reason in the
timeout
case -EAGAIN was being sent back to userspace. I am no longer sure if
that is a good idea, but since we started doing that at some point I
guess we want to keep that behaviour.
Shuah, can you think of any reason to retain -EAGAIN other than you
introduced it here? If there's no real good reason I think it can
simplify
Re: [PATCH] dmaengine: idxd: Fix potential null dereference on pointer status
On 4/15/2021 4:06 AM, Colin King wrote:
From: Colin Ian King
There are calls to idxd_cmd_exec that pass a null status pointer however
a recent commit has added an assignment to *status that can end up
with a null pointer dereference. The function expects a null status
pointer sometimes as there is a later assignment to *status where
status is first null checked. Fix the issue by null checking status
before making the assignment.
Addresses-Coverity: ("Explicit null dereferenced")
Fixes: 89e3becd8f82 ("dmaengine: idxd: check device state before issue command")
Signed-off-by: Colin Ian King
Acked-by: Dave Jiang
Thanks!
---
drivers/dma/idxd/device.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/idxd/device.c b/drivers/dma/idxd/device.c
index 31c819544a22..78d2dc5e9bd8 100644
--- a/drivers/dma/idxd/device.c
+++ b/drivers/dma/idxd/device.c
@@ -451,7 +451,8 @@ static void idxd_cmd_exec(struct idxd_device *idxd, int
cmd_code, u32 operand,
if (idxd_device_is_halted(idxd)) {
dev_warn(>pdev->dev, "Device is HALTED!\n");
- *status = IDXD_CMDSTS_HW_ERR;
+ if (status)
+ *status = IDXD_CMDSTS_HW_ERR;
return;
}
Re: [PATCH v4 2/2] kvm/arm64: Try stage2 block mapping for host device MMIO
Hi Marc,
On 2021/4/15 22:03, Keqian Zhu wrote:
> The MMIO region of a device maybe huge (GB level), try to use
> block mapping in stage2 to speedup both map and unmap.
>
> Compared to normal memory mapping, we should consider two more
> points when try block mapping for MMIO region:
>
> 1. For normal memory mapping, the PA(host physical address) and
> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
> the HVA to request hugepage, so we don't need to consider PA
> alignment when verifing block mapping. But for device memory
> mapping, the PA and HVA may have different alignment.
>
> 2. For normal memory mapping, we are sure hugepage size properly
> fit into vma, so we don't check whether the mapping size exceeds
> the boundary of vma. But for device memory mapping, we should pay
> attention to this.
>
> This adds get_vma_page_shift() to get page shift for both normal
> memory and device MMIO region, and check these two points when
> selecting block mapping size for MMIO region.
>
> Signed-off-by: Keqian Zhu
> ---
> arch/arm64/kvm/mmu.c | 61
> 1 file changed, 51 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index c59af5ca01b0..5a1cc7751e6d 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -738,6 +738,35 @@ transparent_hugepage_adjust(struct kvm_memory_slot
> *memslot,
> return PAGE_SIZE;
> }
>
> +static int get_vma_page_shift(struct vm_area_struct *vma, unsigned long hva)
> +{
> + unsigned long pa;
> +
> + if (is_vm_hugetlb_page(vma) && !(vma->vm_flags & VM_PFNMAP))
> + return huge_page_shift(hstate_vma(vma));
> +
> + if (!(vma->vm_flags & VM_PFNMAP))
> + return PAGE_SHIFT;
> +
> + VM_BUG_ON(is_vm_hugetlb_page(vma));
> +
> + pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
> +
> +#ifndef __PAGETABLE_PMD_FOLDED
> + if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
> + ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
> + ALIGN(hva, PUD_SIZE) <= vma->vm_end)
> + return PUD_SHIFT;
> +#endif
> +
> + if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
> + ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
> + ALIGN(hva, PMD_SIZE) <= vma->vm_end)
> + return PMD_SHIFT;
> +
> + return PAGE_SHIFT;
> +}
> +
> static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> struct kvm_memory_slot *memslot, unsigned long hva,
> unsigned long fault_status)
> @@ -769,7 +798,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
> phys_addr_t fault_ipa,
> return -EFAULT;
> }
>
> - /* Let's check if we will get back a huge page backed by hugetlbfs */
> + /*
> + * Let's check if we will get back a huge page backed by hugetlbfs, or
> + * get block mapping for device MMIO region.
> + */
> mmap_read_lock(current->mm);
> vma = find_vma_intersection(current->mm, hva, hva + 1);
> if (unlikely(!vma)) {
> @@ -778,15 +810,15 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
> phys_addr_t fault_ipa,
> return -EFAULT;
> }
>
> - if (is_vm_hugetlb_page(vma))
> - vma_shift = huge_page_shift(hstate_vma(vma));
> - else
> - vma_shift = PAGE_SHIFT;
> -
> - if (logging_active ||
> - (vma->vm_flags & VM_PFNMAP)) {
> + /*
> + * logging_active is guaranteed to never be true for VM_PFNMAP
> + * memslots.
> + */
> + if (logging_active) {
> force_pte = true;
> vma_shift = PAGE_SHIFT;
> + } else {
> + vma_shift = get_vma_page_shift(vma, hva);
> }
I use a if/else manner in v4, please check that. Thanks very much!
BRs,
Keqian
>
> switch (vma_shift) {
> @@ -854,8 +886,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
> phys_addr_t fault_ipa,
> return -EFAULT;
>
> if (kvm_is_device_pfn(pfn)) {
> + /*
> + * If the page was identified as device early by looking at
> + * the VMA flags, vma_pagesize is already representing the
> + * largest quantity we can map. If instead it was mapped
> + * via gfn_to_pfn_prot(), vma_pagesize is set to PAGE_SIZE
> + * and must not be upgraded.
> + *
> + * In both cases, we don't let transparent_hugepage_adjust()
> + * change things at the last minute.
> + */
> device = true;
> - force_pte = true;
> } else if (logging_active && !write_fault) {
> /*
>* Only actually map the page as writable if this was a write
> @@ -876,7 +917,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
> phys_addr_t fault_ipa,
>* If we are not forced to use page mapping, check if we are
>
[PATCH RFC v3] media: em28xx: Fix race condition between open and init function
Fixes a race condition - for lack of a more precise term - between
em28xx_v4l2_open and em28xx_v4l2_init, by detaching the v4l2_dev,
media_pad and vdev structs from the em28xx_v4l2, and managing the
lifetime of those objects more dynamicaly.
The race happens when a thread[1] - containing the em28xx_v4l2_init()
code - calls the v4l2_mc_create_media_graph(), and it return a error,
if a thread[2] - running v4l2_open() - pass the verification point
and reaches the em28xx_v4l2_open() before the thread[1] finishes
the deregistration of v4l2 subsystem, the thread[1] will free all
resources before the em28xx_v4l2_open() can process their things,
because the em28xx_v4l2_init() has the dev->lock. And all this lead
the thread[2] to cause a user-after-free.
Reported-by: kernel test robot
Reported-and-tested-by: syzbot+b2391895514ed9ef4...@syzkaller.appspotmail.com
Signed-off-by: Igor Matheus Andrade Torrente
---
V2: Add v4l2_i2c_new_subdev null check
Deal with v4l2 subdevs dependencies
V3: Fix link error when compiled as a module
---
drivers/media/usb/em28xx/em28xx-camera.c | 4 +-
drivers/media/usb/em28xx/em28xx-video.c | 300 +++
drivers/media/usb/em28xx/em28xx.h| 6 +-
3 files changed, 209 insertions(+), 101 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-camera.c
b/drivers/media/usb/em28xx/em28xx-camera.c
index d1e66b503f4d..436c5a8cbbb6 100644
--- a/drivers/media/usb/em28xx/em28xx-camera.c
+++ b/drivers/media/usb/em28xx/em28xx-camera.c
@@ -340,7 +340,7 @@ int em28xx_init_camera(struct em28xx *dev)
v4l2->sensor_xtal = 430;
pdata.xtal = v4l2->sensor_xtal;
if (NULL ==
- v4l2_i2c_new_subdev_board(>v4l2_dev, adap,
+ v4l2_i2c_new_subdev_board(v4l2->v4l2_dev, adap,
_info, NULL))
return -ENODEV;
v4l2->vinmode = EM28XX_VINMODE_RGB8_GRBG;
@@ -394,7 +394,7 @@ int em28xx_init_camera(struct em28xx *dev)
v4l2->sensor_yres = 480;
subdev =
-v4l2_i2c_new_subdev_board(>v4l2_dev, adap,
+v4l2_i2c_new_subdev_board(v4l2->v4l2_dev, adap,
_info, NULL);
if (!subdev)
return -ENODEV;
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index 6b84c3413e83..85dfd80fddfb 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -184,7 +184,7 @@ static int em28xx_vbi_supported(struct em28xx *dev)
*/
static void em28xx_wake_i2c(struct em28xx *dev)
{
- struct v4l2_device *v4l2_dev = >v4l2->v4l2_dev;
+ struct v4l2_device *v4l2_dev = dev->v4l2->v4l2_dev;
v4l2_device_call_all(v4l2_dev, 0, core, reset, 0);
v4l2_device_call_all(v4l2_dev, 0, video, s_routing,
@@ -974,9 +974,17 @@ static void em28xx_v4l2_create_entities(struct em28xx *dev)
struct em28xx_v4l2 *v4l2 = dev->v4l2;
int ret, i;
+ v4l2->video_pad = kzalloc(sizeof(*v4l2->video_pad), GFP_KERNEL);
+ if (!v4l2->video_pad) {
+ dev_err(>intf->dev,
+ "failed to allocate video pad memory!\n");
+ v4l2->vdev->entity.num_pads = 0;
+ return;
+ }
+
/* Initialize Video, VBI and Radio pads */
- v4l2->video_pad.flags = MEDIA_PAD_FL_SINK;
- ret = media_entity_pads_init(>vdev.entity, 1, >video_pad);
+ v4l2->video_pad->flags = MEDIA_PAD_FL_SINK;
+ ret = media_entity_pads_init(>vdev->entity, 1, v4l2->video_pad);
if (ret < 0)
dev_err(>intf->dev,
"failed to initialize video media entity!\n");
@@ -1132,11 +1140,11 @@ int em28xx_start_analog_streaming(struct vb2_queue *vq,
unsigned int count)
f.type = V4L2_TUNER_RADIO;
else
f.type = V4L2_TUNER_ANALOG_TV;
- v4l2_device_call_all(>v4l2_dev,
+ v4l2_device_call_all(v4l2->v4l2_dev,
0, tuner, s_frequency, );
/* Enable video stream at TV decoder */
- v4l2_device_call_all(>v4l2_dev, 0, video, s_stream, 1);
+ v4l2_device_call_all(v4l2->v4l2_dev, 0, video, s_stream, 1);
}
v4l2->streaming_users++;
@@ -1157,7 +1165,7 @@ static void em28xx_stop_streaming(struct vb2_queue *vq)
if (v4l2->streaming_users-- == 1) {
/* Disable video stream at TV decoder */
- v4l2_device_call_all(>v4l2_dev, 0, video, s_stream, 0);
+ v4l2_device_call_all(v4l2->v4l2_dev, 0, video, s_stream, 0);
/* Last active user, so shutdown all the URBS */
em28xx_uninit_usb_xfer(dev, EM28XX_ANALOG_MODE);
@@ -1192,7 +1200,7 @@ void
[PATCH] arm: dts: aspeed: tiogapass: add hotplug controller
The ADM1278 IC is accessible on I2C bus and on both Wiwynn and Quanta
Tioga Pass implementations a pair of parallel 0.5 mOhm resistors is used
for current measurement.
Signed-off-by: Paul Fertser
---
arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
index 3cc2004fa2f2..500661956dea 100644
--- a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
@@ -591,6 +591,11 @@
{
status = "okay";
//HSC, AirMax Conn A
+ adm1278@0x45 {
+ compatible = "adm1275";
+ reg = <0x45>;
+ shunt-resistor-micro-ohms = <250>;
+ };
};
{
--
2.17.1
Re: [PATCH] staging: media: tegra-video: Align line break to match with the open parenthesis in file vi.c
On 14/04/2021 15:09, Aline Santana Cordeiro wrote:
> Align line break to match with the open parenthesis.
> Issue detected by checkpatch.pl.
>
> Signed-off-by: Aline Santana Cordeiro
> ---
> drivers/staging/media/tegra-video/vi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/tegra-video/vi.c
> b/drivers/staging/media/tegra-video/vi.c
> index 7a09061c..9878d1e 100644
> --- a/drivers/staging/media/tegra-video/vi.c
> +++ b/drivers/staging/media/tegra-video/vi.c
> @@ -1813,7 +1813,8 @@ static int tegra_vi_graph_parse_one(struct
> tegra_vi_channel *chan,
> }
>
> tvge = v4l2_async_notifier_add_fwnode_subdev(>notifier,
> - remote, struct tegra_vi_graph_entity);
> + remote,
Add this line to the previous line. That looks a bit better and is one line
shorter.
Regards,
Hans
> + struct
> tegra_vi_graph_entity);
> if (IS_ERR(tvge)) {
> ret = PTR_ERR(tvge);
> dev_err(vi->dev,
>
[PATCH v4 1/2] kvm/arm64: Remove the creation time's mapping of MMIO regions
The MMIO regions may be unmapped for many reasons and can be remapped
by stage2 fault path. Map MMIO regions at creation time becomes a
minor optimization and makes these two mapping path hard to sync.
Remove the mapping code while keep the useful sanity check.
Signed-off-by: Keqian Zhu
---
arch/arm64/kvm/mmu.c | 38 +++---
1 file changed, 3 insertions(+), 35 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 8711894db8c2..c59af5ca01b0 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1301,7 +1301,6 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
{
hva_t hva = mem->userspace_addr;
hva_t reg_end = hva + mem->memory_size;
- bool writable = !(mem->flags & KVM_MEM_READONLY);
int ret = 0;
if (change != KVM_MR_CREATE && change != KVM_MR_MOVE &&
@@ -1318,8 +1317,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
mmap_read_lock(current->mm);
/*
* A memory region could potentially cover multiple VMAs, and any holes
-* between them, so iterate over all of them to find out if we can map
-* any of them right now.
+* between them, so iterate over all of them.
*
* ++
* +---++ ++
@@ -1330,50 +1328,20 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
*/
do {
struct vm_area_struct *vma = find_vma(current->mm, hva);
- hva_t vm_start, vm_end;
if (!vma || vma->vm_start >= reg_end)
break;
- /*
-* Take the intersection of this VMA with the memory region
-*/
- vm_start = max(hva, vma->vm_start);
- vm_end = min(reg_end, vma->vm_end);
-
if (vma->vm_flags & VM_PFNMAP) {
- gpa_t gpa = mem->guest_phys_addr +
- (vm_start - mem->userspace_addr);
- phys_addr_t pa;
-
- pa = (phys_addr_t)vma->vm_pgoff << PAGE_SHIFT;
- pa += vm_start - vma->vm_start;
-
/* IO region dirty page logging not allowed */
if (memslot->flags & KVM_MEM_LOG_DIRTY_PAGES) {
ret = -EINVAL;
- goto out;
- }
-
- ret = kvm_phys_addr_ioremap(kvm, gpa, pa,
- vm_end - vm_start,
- writable);
- if (ret)
break;
+ }
}
- hva = vm_end;
+ hva = min(reg_end, vma->vm_end);
} while (hva < reg_end);
- if (change == KVM_MR_FLAGS_ONLY)
- goto out;
-
- spin_lock(>mmu_lock);
- if (ret)
- unmap_stage2_range(>arch.mmu, mem->guest_phys_addr,
mem->memory_size);
- else if (!cpus_have_final_cap(ARM64_HAS_STAGE2_FWB))
- stage2_flush_memslot(kvm, memslot);
- spin_unlock(>mmu_lock);
-out:
mmap_read_unlock(current->mm);
return ret;
}
--
2.19.1
[PATCH v4 2/2] kvm/arm64: Try stage2 block mapping for host device MMIO
The MMIO region of a device maybe huge (GB level), try to use
block mapping in stage2 to speedup both map and unmap.
Compared to normal memory mapping, we should consider two more
points when try block mapping for MMIO region:
1. For normal memory mapping, the PA(host physical address) and
HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
the HVA to request hugepage, so we don't need to consider PA
alignment when verifing block mapping. But for device memory
mapping, the PA and HVA may have different alignment.
2. For normal memory mapping, we are sure hugepage size properly
fit into vma, so we don't check whether the mapping size exceeds
the boundary of vma. But for device memory mapping, we should pay
attention to this.
This adds get_vma_page_shift() to get page shift for both normal
memory and device MMIO region, and check these two points when
selecting block mapping size for MMIO region.
Signed-off-by: Keqian Zhu
---
arch/arm64/kvm/mmu.c | 61
1 file changed, 51 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index c59af5ca01b0..5a1cc7751e6d 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -738,6 +738,35 @@ transparent_hugepage_adjust(struct kvm_memory_slot
*memslot,
return PAGE_SIZE;
}
+static int get_vma_page_shift(struct vm_area_struct *vma, unsigned long hva)
+{
+ unsigned long pa;
+
+ if (is_vm_hugetlb_page(vma) && !(vma->vm_flags & VM_PFNMAP))
+ return huge_page_shift(hstate_vma(vma));
+
+ if (!(vma->vm_flags & VM_PFNMAP))
+ return PAGE_SHIFT;
+
+ VM_BUG_ON(is_vm_hugetlb_page(vma));
+
+ pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
+
+#ifndef __PAGETABLE_PMD_FOLDED
+ if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
+ ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
+ ALIGN(hva, PUD_SIZE) <= vma->vm_end)
+ return PUD_SHIFT;
+#endif
+
+ if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
+ ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
+ ALIGN(hva, PMD_SIZE) <= vma->vm_end)
+ return PMD_SHIFT;
+
+ return PAGE_SHIFT;
+}
+
static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
struct kvm_memory_slot *memslot, unsigned long hva,
unsigned long fault_status)
@@ -769,7 +798,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
return -EFAULT;
}
- /* Let's check if we will get back a huge page backed by hugetlbfs */
+ /*
+* Let's check if we will get back a huge page backed by hugetlbfs, or
+* get block mapping for device MMIO region.
+*/
mmap_read_lock(current->mm);
vma = find_vma_intersection(current->mm, hva, hva + 1);
if (unlikely(!vma)) {
@@ -778,15 +810,15 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
return -EFAULT;
}
- if (is_vm_hugetlb_page(vma))
- vma_shift = huge_page_shift(hstate_vma(vma));
- else
- vma_shift = PAGE_SHIFT;
-
- if (logging_active ||
- (vma->vm_flags & VM_PFNMAP)) {
+ /*
+* logging_active is guaranteed to never be true for VM_PFNMAP
+* memslots.
+*/
+ if (logging_active) {
force_pte = true;
vma_shift = PAGE_SHIFT;
+ } else {
+ vma_shift = get_vma_page_shift(vma, hva);
}
switch (vma_shift) {
@@ -854,8 +886,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
return -EFAULT;
if (kvm_is_device_pfn(pfn)) {
+ /*
+* If the page was identified as device early by looking at
+* the VMA flags, vma_pagesize is already representing the
+* largest quantity we can map. If instead it was mapped
+* via gfn_to_pfn_prot(), vma_pagesize is set to PAGE_SIZE
+* and must not be upgraded.
+*
+* In both cases, we don't let transparent_hugepage_adjust()
+* change things at the last minute.
+*/
device = true;
- force_pte = true;
} else if (logging_active && !write_fault) {
/*
* Only actually map the page as writable if this was a write
@@ -876,7 +917,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
* If we are not forced to use page mapping, check if we are
* backed by a THP and thus use block mapping if possible.
*/
- if (vma_pagesize == PAGE_SIZE && !force_pte)
+ if (vma_pagesize == PAGE_SIZE && !(force_pte || device))
vma_pagesize =
[PATCH v4 0/2] kvm/arm64: Try stage2 block mapping for host device MMIO
Hi, We have two pathes to build stage2 mapping for MMIO regions. Create time's path and stage2 fault path. Patch#1 removes the creation time's mapping of MMIO regions Patch#2 tries stage2 block mapping for host device MMIO at fault path Changelog: v4: - use get_vma_page_shift() handle all cases. (Marc) - get rid of force_pte for device mapping. (Marc) v3: - Do not need to check memslot boundary in device_rough_page_shift(). (Marc) Thanks, Keqian Keqian Zhu (2): kvm/arm64: Remove the creation time's mapping of MMIO regions kvm/arm64: Try stage2 block mapping for host device MMIO arch/arm64/kvm/mmu.c | 99 1 file changed, 54 insertions(+), 45 deletions(-) -- 2.19.1
Re: [PATCH v3 1/2] binfmt_flat: allow not offsetting data start
Hi Damien,
On 15/4/21 4:15 pm, Damien Le Moal wrote:
Commit 2217b9826246 ("binfmt_flat: revert "binfmt_flat: don't offset
the data start"") restored offsetting the start of the data section by
a number of words defined by MAX_SHARED_LIBS. As a result, since
MAX_SHARED_LIBS is never 0, a gap between the text and data sections
always exists. For architectures which cannot support a such gap
between the text and data sections (e.g. riscv nommu), flat binary
programs cannot be executed.
To allow an architecture to request contiguous text and data sections,
introduce the config option CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP.
Using this new option, the macro DATA_GAP_WORDS is conditionally
defined in binfmt_flat.c to MAX_SHARED_LIBS for architectures
tolerating the text-to-data gap (CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP
disabled case) and to 0 when CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP is
enabled. DATA_GAP_WORDS is used in load_flat_file() to calculate the
data section length and start position.
An architecture enabling CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP also
prevents the use of the separate text/data load case (when the flat file
header flags FLAT_FLAG_RAM and FLAT_FLAG_GZIP are not set with NOMMU
kernels) and forces the use of a single RAM region for loading
(equivalent to FLAT_FLAG_RAM being set).
So is it the case that a flat format file on RISC-V will never have
relocations?
Signed-off-by: Damien Le Moal
Acked-by: Palmer Dabbelt
---
fs/Kconfig.binfmt | 3 +++
fs/binfmt_flat.c | 21 +++--
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
index c6f1c8c1934e..c6df931d5d45 100644
--- a/fs/Kconfig.binfmt
+++ b/fs/Kconfig.binfmt
@@ -112,6 +112,9 @@ config BINFMT_FLAT_ARGVP_ENVP_ON_STACK
config BINFMT_FLAT_OLD_ALWAYS_RAM
bool
+config BINFMT_FLAT_NO_TEXT_DATA_GAP
+ bool
+
config BINFMT_FLAT_OLD
bool "Enable support for very old legacy flat binaries"
depends on BINFMT_FLAT
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index b9c658e0548e..2be29bb964b8 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -74,6 +74,12 @@
#define MAX_SHARED_LIBS (1)
#endif
+#ifdef CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP
+#define DATA_GAP_WORDS (0)
+#else
+#define DATA_GAP_WORDS (MAX_SHARED_LIBS)
+#endif
+> struct lib_info {
struct {
unsigned long start_code; /* Start of text
segment */
@@ -559,7 +565,10 @@ static int load_flat_file(struct linux_binprm *bprm,
* case, and then the fully copied to RAM case which lumps
* it all together.
*/
- if (!IS_ENABLED(CONFIG_MMU) && !(flags &
(FLAT_FLAG_RAM|FLAT_FLAG_GZIP))) {
+ if (!IS_ENABLED(CONFIG_MMU) &&
+ !IS_ENABLED(CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP) &&
If RISC-V flat format files must always be loaded to RAM then why don't
they set the FLAT_FLAG_RAM when compiled/generated?
Regards
Greg
+ !(flags & (FLAT_FLAG_RAM|FLAT_FLAG_GZIP))) {
+
/*
* this should give us a ROM ptr, but if it doesn't we don't
* really care
@@ -576,7 +585,7 @@ static int load_flat_file(struct linux_binprm *bprm,
goto err;
}
- len = data_len + extra + MAX_SHARED_LIBS * sizeof(unsigned long);
+ len = data_len + extra + DATA_GAP_WORDS * sizeof(unsigned long);
len = PAGE_ALIGN(len);
realdatastart = vm_mmap(NULL, 0, len,
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 0);
@@ -591,7 +600,7 @@ static int load_flat_file(struct linux_binprm *bprm,
goto err;
}
datapos = ALIGN(realdatastart +
- MAX_SHARED_LIBS * sizeof(unsigned long),
+ DATA_GAP_WORDS * sizeof(unsigned long),
FLAT_DATA_ALIGN);
pr_debug("Allocated data+bss+stack (%u bytes): %lx\n",
@@ -622,7 +631,7 @@ static int load_flat_file(struct linux_binprm *bprm,
memp_size = len;
} else {
- len = text_len + data_len + extra + MAX_SHARED_LIBS * sizeof(u32);
+ len = text_len + data_len + extra + DATA_GAP_WORDS *
sizeof(u32);
len = PAGE_ALIGN(len);
textpos = vm_mmap(NULL, 0, len,
PROT_READ | PROT_EXEC | PROT_WRITE, MAP_PRIVATE, 0);
@@ -638,7 +647,7 @@ static int load_flat_file(struct linux_binprm *bprm,
realdatastart = textpos + ntohl(hdr->data_start);
datapos = ALIGN(realdatastart +
- MAX_SHARED_LIBS * sizeof(u32),
+ DATA_GAP_WORDS * sizeof(u32),
FLAT_DATA_ALIGN);
reloc = (__be32 __user *)
@@ -714,7 +723,7 @@ static int load_flat_file(struct linux_binprm *bprm,
Re: [PATCH v2 4/5] staging: rtl8192e: rectified spelling mistake and replace memcmp with ether_oui_equal
On Wed, Apr 14, 2021 at 10:55:25AM +0300, Dan Carpenter wrote:
> On Wed, Apr 14, 2021 at 12:26:01PM +0530, Mitali Borkar wrote:
> > Added a generic function of static inline bool in
> > include/linux/etherdevice.h to replace memcmp with
> > ether_oui_equal throughout the execution.
> > Corrected the misspelled words in this file.
> >
> > Signed-off-by: Mitali Borkar
> > ---
> >
> > Changes from v1:- Rectified spelling mistake and replaced memcmp with
> > ether_oui_equal.
> >
> > drivers/staging/rtl8192e/rtl819x_HTProc.c | 48 +++
> > include/linux/etherdevice.h | 5 +++
>^^^
> This is networking code and not staging code, but the netdev mailing
> list isn't CC'd.
>
I didn't knew mail id then, I will look into this,
> > 2 files changed, 29 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8192e/rtl819x_HTProc.c
> > b/drivers/staging/rtl8192e/rtl819x_HTProc.c
> > index ec6b46166e84..ce58feb2af9a 100644
> > --- a/drivers/staging/rtl8192e/rtl819x_HTProc.c
> > +++ b/drivers/staging/rtl8192e/rtl819x_HTProc.c
> > @@ -43,7 +43,7 @@ u16 MCS_DATA_RATE[2][2][77] = {
> > 810, 720, 810, 900, 900, 990} }
> > };
> >
> > -static u8 UNKNOWN_BORADCOM[3] = {0x00, 0x14, 0xbf};
> > +static u8 UNKNOWN_BROADCOM[3] = {0x00, 0x14, 0xbf};
>
> Please pull this spelling fix into its own patch.
>
Okay Sir.
> [ snip ]
>
> > diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
> > index 2e5debc0373c..6a1a63168319 100644
> > --- a/include/linux/etherdevice.h
> > +++ b/include/linux/etherdevice.h
> > @@ -87,6 +87,11 @@ static inline bool is_link_local_ether_addr(const u8
> > *addr)
> > #endif
> > }
> >
> > +static inline bool ether_oui_equal(const u8 *addr, const u8 *oui)
> > +{
> > +return addr[0] == oui[0] && addr[1] == oui[1] && addr[2] == oui[2];
> > +}
>
> The indenting is messed up on this.
>
OKay Sir, I am looking into this.
> regards,
> dan carpenter
>
Re: [PATCH] dt-bindings: mailbox: ti,message-manager: Convert to yaml
[..snip..] > diff --git > a/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml > b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml > new file mode 100644 > index ..4987e803ac37 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml > @@ -0,0 +1,75 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mailbox/ti,message-manager.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Texas Instruments' Message Manager Driver Driver is not the right word here. Can you change it to node? Thanks and regards, Lokesh
Re: [PATCH v2 4/5] staging: rtl8192e: rectified spelling mistake and replace memcmp with ether_oui_equal
On Thu, Apr 15, 2021 at 07:12:47PM +0530, Mitali Borkar wrote:
> On Wed, Apr 14, 2021 at 10:16:59AM +0200, Greg KH wrote:
> > On Wed, Apr 14, 2021 at 12:26:01PM +0530, Mitali Borkar wrote:
> > > Added a generic function of static inline bool in
> > > include/linux/etherdevice.h to replace memcmp with
> > > ether_oui_equal throughout the execution.
> > > Corrected the misspelled words in this file.
> > >
> > > Signed-off-by: Mitali Borkar
> > > ---
> > >
> > > Changes from v1:- Rectified spelling mistake and replaced memcmp with
> > > ether_oui_equal.
> > >
> > > drivers/staging/rtl8192e/rtl819x_HTProc.c | 48 +++
> > > include/linux/etherdevice.h | 5 +++
> > > 2 files changed, 29 insertions(+), 24 deletions(-)
> > >
> > > diff --git a/drivers/staging/rtl8192e/rtl819x_HTProc.c
> > > b/drivers/staging/rtl8192e/rtl819x_HTProc.c
> > > index ec6b46166e84..ce58feb2af9a 100644
> > > --- a/drivers/staging/rtl8192e/rtl819x_HTProc.c
> > > +++ b/drivers/staging/rtl8192e/rtl819x_HTProc.c
> > > @@ -43,7 +43,7 @@ u16 MCS_DATA_RATE[2][2][77] = {
> > >810, 720, 810, 900, 900, 990} }
> > > };
> > >
> > > -static u8 UNKNOWN_BORADCOM[3] = {0x00, 0x14, 0xbf};
> > > +static u8 UNKNOWN_BROADCOM[3] = {0x00, 0x14, 0xbf};
> > >
> > > static u8 LINKSYSWRT330_LINKSYSWRT300_BROADCOM[3] = {0x00, 0x1a, 0x70};
> > >
> > > @@ -146,16 +146,16 @@ bool IsHTHalfNmodeAPs(struct rtllib_device *ieee)
> > > boolretValue = false;
> > > struct rtllib_network *net = >current_network;
> > >
> > > - if ((memcmp(net->bssid, BELKINF5D8233V1_RALINK, 3) == 0) ||
> > > - (memcmp(net->bssid, BELKINF5D82334V3_RALINK, 3) == 0) ||
> > > - (memcmp(net->bssid, PCI_RALINK, 3) == 0) ||
> > > - (memcmp(net->bssid, EDIMAX_RALINK, 3) == 0) ||
> > > - (memcmp(net->bssid, AIRLINK_RALINK, 3) == 0) ||
> > > + if ((ether_oui_equal(net->bssid, BELKINF5D8233V1_RALINK) == 0) ||
> > > + (ether_oui_equal(net->bssid, BELKINF5D82334V3_RALINK) == 0) ||
> > > + (ether_oui_equal(net->bssid, PCI_RALINK) == 0) ||
> > > + (ether_oui_equal(net->bssid, EDIMAX_RALINK) == 0) ||
> > > + (ether_oui_equal(net->bssid, AIRLINK_RALINK) == 0) ||
> > > (net->ralink_cap_exist))
> > > retValue = true;
> > > - else if (!memcmp(net->bssid, UNKNOWN_BORADCOM, 3) ||
> > > - !memcmp(net->bssid, LINKSYSWRT330_LINKSYSWRT300_BROADCOM, 3) ||
> > > - !memcmp(net->bssid, LINKSYSWRT350_LINKSYSWRT150_BROADCOM, 3) ||
> > > + else if (ether_oui_equal(net->bssid, UNKNOWN_BROADCOM) ||
> > > + ether_oui_equal(net->bssid,
> > > LINKSYSWRT330_LINKSYSWRT300_BROADCOM) ||
> > > + ether_oui_equal(net->bssid,
> > > LINKSYSWRT350_LINKSYSWRT150_BROADCOM) ||
> > >(net->broadcom_cap_exist))
> > > retValue = true;
> > > else if (net->bssht.bd_rt2rt_aggregation)
> > > @@ -179,26 +179,26 @@ static void HTIOTPeerDetermine(struct rtllib_device
> > > *ieee)
> > > pHTInfo->IOTPeer = HT_IOT_PEER_92U_SOFTAP;
> > > } else if (net->broadcom_cap_exist) {
> > > pHTInfo->IOTPeer = HT_IOT_PEER_BROADCOM;
> > > - } else if (!memcmp(net->bssid, UNKNOWN_BORADCOM, 3) ||
> > > - !memcmp(net->bssid, LINKSYSWRT330_LINKSYSWRT300_BROADCOM, 3) ||
> > > - !memcmp(net->bssid, LINKSYSWRT350_LINKSYSWRT150_BROADCOM, 3)) {
> > > + } else if (ether_oui_equal(net->bssid, UNKNOWN_BROADCOM) ||
> > > +ether_oui_equal(net->bssid,
> > > LINKSYSWRT330_LINKSYSWRT300_BROADCOM) ||
> > > +ether_oui_equal(net->bssid,
> > > LINKSYSWRT350_LINKSYSWRT150_BROADCOM)) {
> > > pHTInfo->IOTPeer = HT_IOT_PEER_BROADCOM;
> > > - } else if ((memcmp(net->bssid, BELKINF5D8233V1_RALINK, 3) == 0) ||
> > > - (memcmp(net->bssid, BELKINF5D82334V3_RALINK, 3) == 0) ||
> > > - (memcmp(net->bssid, PCI_RALINK, 3) == 0) ||
> > > - (memcmp(net->bssid, EDIMAX_RALINK, 3) == 0) ||
> > > - (memcmp(net->bssid, AIRLINK_RALINK, 3) == 0) ||
> > > - net->ralink_cap_exist) {
> > > + } else if ((ether_oui_equal(net->bssid, BELKINF5D8233V1_RALINK) == 0) ||
> > > +(ether_oui_equal(net->bssid, BELKINF5D82334V3_RALINK) == 0)
> > > ||
> > > +(ether_oui_equal(net->bssid, PCI_RALINK) == 0) ||
> > > +(ether_oui_equal(net->bssid, EDIMAX_RALINK) == 0) ||
> > > +(ether_oui_equal(net->bssid, AIRLINK_RALINK) == 0) ||
> > > +net->ralink_cap_exist) {
> > > pHTInfo->IOTPeer = HT_IOT_PEER_RALINK;
> > > } else if ((net->atheros_cap_exist) ||
> > > - (memcmp(net->bssid, DLINK_ATHEROS_1, 3) == 0) ||
> > > - (memcmp(net->bssid, DLINK_ATHEROS_2, 3) == 0)) {
> > > +(ether_oui_equal(net->bssid, DLINK_ATHEROS_1) == 0) ||
> > > +(ether_oui_equal(net->bssid, DLINK_ATHEROS_2) == 0)) {
> > > pHTInfo->IOTPeer = HT_IOT_PEER_ATHEROS;
> > > - } else if ((memcmp(net->bssid, CISCO_BROADCOM, 3) == 0) ||
>
Re: [PATCH] arm64: alternatives: Move length validation in alternative_{insn,endif}
On Thu, Apr 15, 2021 at 06:25:57AM -0700, Nathan Chancellor wrote:
> On Thu, Apr 15, 2021 at 10:17:43AM +0100, Catalin Marinas wrote:
> > On Tue, Apr 13, 2021 at 05:08:04PM -0700, Nathan Chancellor wrote:
> > > After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
> > > set atomically"), LLVM's integrated assembler fails to build entry.S:
> > >
> > > :5:7: error: expected assembly-time absolute expression
> > > .org . - (664b-663b) + (662b-661b)
> > > ^
> > > :6:7: error: expected assembly-time absolute expression
> > > .org . - (662b-661b) + (664b-663b)
> > > ^
> >
> > I tried the latest Linus' tree and linux-next (defconfig) with this
> > commit in and I can't get your build error. I used both clang-10 from
> > Debian stable and clang-11 from Debian sid. So, which clang version did
> > you use or which kernel config options?
>
> Interesting, this reproduces for me with LLVM 12 or newer with just
> defconfig.
It fails for me as well with clang-12. Do you happen to know why it
works fine with previous clang versions?
--
Catalin
RE: linux-next: manual merge of the net-next tree with the net tree
>Hi all,
>
>Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>
>between commit:
>
> 00423969d806 ("Revert "net: stmmac: re-init rx buffers when mac resume
>back"")
>
>from the net tree and commits:
>
> bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy")
> de0b90e52a11 ("net: stmmac: rearrange RX and TX desc init into per-queue
>basis")
>
>from the net-next tree.
>
>I fixed it up (see below) and can carry the fix as necessary. This
>is now fixed as far as linux-next is concerned, but any non trivial
>conflicts should be mentioned to your upstream maintainer when your tree
>is submitted for merging. You may also want to consider cooperating
>with the maintainer of the conflicting tree to minimise any particularly
>complex conflicts.
I check linux-next merge fix above and spotted an additional fix needed.
Please see below.
>+ /**
>+ * dma_recycle_rx_skbufs - recycle RX dma buffers
>+ * @priv: private structure
>+ * @queue: RX queue index
>+ */
>+ static void dma_recycle_rx_skbufs(struct stmmac_priv *priv, u32 queue)
>+ {
>+ struct stmmac_rx_queue *rx_q = >rx_queue[queue];
>+ int i;
>+
>+ for (i = 0; i < priv->dma_rx_size; i++) {
>+ struct stmmac_rx_buffer *buf = _q->buf_pool[i];
>+
>+ if (buf->page) {
>+ page_pool_recycle_direct(rx_q->page_pool, buf-
>>page);
>+ buf->page = NULL;
>+ }
>+
>+ if (priv->sph && buf->sec_page) {
>+ page_pool_recycle_direct(rx_q->page_pool, buf-
>>sec_page);
>+ buf->sec_page = NULL;
>+ }
>+ }
>+ }
With https://git.kernel.org/netdev/net/c/00423969d806 that reverts
stmmac_reinit_rx_buffers(), then the above dma_recycle_rx_skbufs()
is no longer needed when net-next is sent for merge.
> -/**
> - * stmmac_reinit_rx_buffers - reinit the RX descriptor buffer.
> - * @priv: driver private structure
> - * Description: this function is called to re-allocate a receive buffer,
> perform
> - * the DMA mapping and init the descriptor.
> - */
> -static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
> -{
> - u32 rx_count = priv->plat->rx_queues_to_use;
> - u32 queue;
> -
> - for (queue = 0; queue < rx_count; queue++) {
> - struct stmmac_rx_queue *rx_q = >rx_queue[queue];
> -
> - if (rx_q->xsk_pool)
> - dma_free_rx_xskbufs(priv, queue);
dma_recycle_rx_skbufs() is only called here.
[GIT PULL] gpio: fixes for v5.12-rc8
Linus, I waited until late with this non-urgent one hoping we'd get more fixes for this release cycle to go with it but nothing's coming up so please pull this single fix for an older problem with the sysfs interface. Bartosz The following changes since commit 6cb59afe9e5b45a035bd6b97da6593743feefc72: gpiolib: Assign fwnode to parent's if no primary one provided (2021-03-16 10:18:08 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/gpio-fixes-for-v5.12-rc8 for you to fetch changes up to 23cf00ddd2e1aacf1873e43f5e0c519c120daf7a: gpio: sysfs: Obey valid_mask (2021-03-31 20:32:38 +0200) gpio fixes for v5.12-rc8 - do not allow exporting GPIO lines which were marked invalid by the driver Matti Vaittinen (1): gpio: sysfs: Obey valid_mask drivers/gpio/gpiolib-sysfs.c | 8 1 file changed, 8 insertions(+)
[PATCH v1 1/1] ACPI: NFIT: Import GUID before use
Strictly speaking the comparison between guid_t and raw buffer
is not correct. Import GUID to variable of guid_t type and then
compare.
Signed-off-by: Andy Shevchenko
---
drivers/acpi/nfit/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 958aaac869e8..6d8a1a93636a 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -678,10 +678,12 @@ static const char *spa_type_name(u16 type)
int nfit_spa_type(struct acpi_nfit_system_address *spa)
{
+ guid_t guid;
int i;
+ import_guid(, spa->range_guid);
for (i = 0; i < NFIT_UUID_MAX; i++)
- if (guid_equal(to_nfit_uuid(i), (guid_t *)>range_guid))
+ if (guid_equal(to_nfit_uuid(i), ))
return i;
return -1;
}
--
2.30.2
Re: backport patches to linux-5.4.y
On Tue, Apr 13, 2021 at 02:11:54PM +0200, Anders Roxell wrote:
> Hi,
>
> Can these patches be backported to linux-5.4.y, I've tried to build
> perf on arm and it failed without these patches.
> fc8c0a992233 ("perf tools: Use %define api.pure full instead of %pure-parser")
> 20befbb10803 ("perf tools: Use %zd for size_t printf formats on 32-bit")
> 77d02bd00cea ("perf map: Tighten snprintf() string precision to pass
> gcc check on some 32-bit arches")
>
>
>
> Commit fc8c0a992233 ("perf tools: Use %define api.pure full instead of
> %pure-parser") fixes:
>
> util/parse-events.y:1.1-12: warning: deprecated directive:
> '%pure-parser', use '%define api.pure' [-Wdeprecated]
> 1 | %pure-parser
> | ^~~~
> | %define api.pure
>
> Commit 20befbb10803 ("perf tools: Use %zd for size_t printf formats on
> 32-bit") fixes:
>
> In file included from util/session.c:17:
> util/session.c: In function 'perf_session__process_compressed_event':
> util/session.c:91:11: error: format '%ld' expects argument of type
> 'long int', but argument 4 has type 'size_t' {aka 'unsigned int'}
> [-Werror=format=]
>91 | pr_debug("decomp (B): %ld to %ld\n", src_size, decomp_size);
> | ^~
> util/debug.h:16:21: note: in definition of macro 'pr_fmt'
>16 | #define pr_fmt(fmt) fmt
> | ^~~
> util/session.c:91:2: note: in expansion of macro 'pr_debug'
>91 | pr_debug("decomp (B): %ld to %ld\n", src_size, decomp_size);
> | ^~~~
>
> Commit 77d02bd00cea ("perf map: Tighten snprintf() string precision to
> pass gcc check on some 32-bit arches") fixes:
>
> util/map.c: In function 'map__new':
> util/map.c:125:5: error: '%s' directive output may be truncated
> writing between 1 and 2147483645 bytes into a region of size 4096
> [-Werror=format-truncation=]
> 125 |"%s/platforms/%s/arch-%s/usr/lib/%s",
> | ^~
> In file included from /usr/arm-linux-gnueabihf/include/stdio.h:867,
> from util/symbol.h:11,
> from util/map.c:2:
> /usr/arm-linux-gnueabihf/include/bits/stdio2.h:67:10: note:
> '__builtin___snprintf_chk' output 32 or more bytes (assuming
> 4294967321) into a destination of size 4096
>67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
> | ^~~~
>68 |__bos (__s), __fmt, __va_arg_pack ());
> |~
Now queued up, thanks.
greg k-h
YES PLS
Did you received the mail i send to you?
Re: [PATCH] driver core: Fix locking bug in deferred_probe_timeout_work_func()
On Mon, Apr 12, 2021 at 11:09:06AM -0700, Saravana Kannan wrote:
> commit eed6e41813deb9ee622cd9242341f21430d7789f upstream.
>
> list_for_each_entry_safe() is only useful if we are deleting nodes in a
> linked list within the loop. It doesn't protect against other threads
> adding/deleting nodes to the list in parallel. We need to grab
> deferred_probe_mutex when traversing the deferred_probe_pending_list.
>
> Cc: sta...@vger.kernel.org
> Fixes: 25b4e70dcce9 ("driver core: allow stopping deferred probe after init")
> Signed-off-by: Saravana Kannan
> Link: https://lore.kernel.org/r/20210402040342.2944858-2-sarava...@google.com
> Signed-off-by: Greg Kroah-Hartman
> ---
> Hi Greg,
>
> This should apply cleanly to 4.19 and 5.4 if you think this should be
> picked up.
thanks, now queued up.
greg k-h
[GIT PULL] HID fixes
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-linus to receive HID fixes. I wanted to send them earlier than for the last -rc, but then unfortunately many things interfered. The changes are all device/driver specific fixes. = - EV_KEY and EV_ABS regression fix for Wacom from Ping Cheng - BIOS-specific quirk to fix some of the AMD_SFH-based systems, from Hans de Goede - other small error handling fixes and device ID additions = Thanks. Douglas Gilbert (1): HID cp2112: fix support for multiple gpiochips Hans de Goede (3): AMD_SFH: Removed unused activecontrolstatus member from the amd_mp2_dev struct AMD_SFH: Add sensor_mask module parameter AMD_SFH: Add DMI quirk table for BIOS-es which don't set the activestatus bits Jia-Ju Bai (1): HID: alps: fix error return code in alps_input_configured() Jiapeng Zhong (1): HID: wacom: Assign boolean values to a bool variable Luke D Jones (1): HID: asus: Add support for 2021 ASUS N-Key keyboard Ping Cheng (1): HID: wacom: set EV_KEY and EV_ABS only for non-HID_GENERIC type of devices Shou-Chieh Hsu (1): HID: google: add don USB id drivers/hid/amd-sfh-hid/amd_sfh_pcie.c | 40 +++--- drivers/hid/amd-sfh-hid/amd_sfh_pcie.h | 1 - drivers/hid/hid-alps.c | 1 + drivers/hid/hid-asus.c | 3 +++ drivers/hid/hid-cp2112.c | 22 +-- drivers/hid/hid-google-hammer.c| 2 ++ drivers/hid/hid-ids.h | 2 ++ drivers/hid/wacom_wac.c| 8 +++ 8 files changed, 59 insertions(+), 20 deletions(-) -- Jiri Kosina SUSE Labs
Re: [RFC PATCH 2/5] tracing/hwlat: Implement the mode config option
On Thu, 15 Apr 2021 15:16:04 +0200 Daniel Bristot de Oliveira wrote: > That was my initial intention with the NONE mode, but I feared breaking > something by removing the "migrate_disable" logic. If you do not think it is > a problem, I will remove the migrate disable and just change the mode. Yes, just change it. Thanks, -- Steve
Re: [RFC PATCH 1/5] tracing/hwlat: Add a cpus file specific for hwlat_detector
On Thu, 15 Apr 2021 15:09:50 +0200 Daniel Bristot de Oliveira wrote: > But for the osnoise tracer the cpus file is really useful. For instance, on a > system with the CPU 7 isolated: > > - %< - > # echo 7 > osnoise/cpus > # echo target_cpu == 7 > events/sched/sched_wakeup/filter > # echo stacktrace if target_cpu == 7 > events/sched/sched_wakeup/trigger > # echo 1 > events/sched/sched_wakeup/enable > # echo osnoise:thread_noise > set_event > # echo osnoise > current_tracer > # cat trace > [find...] > kworker/0:1-7 [000] d..5 1820.717780: > => trace_event_raw_event_sched_wakeup_template > => __traceiter_sched_wakeup > => ttwu_do_wakeup > => try_to_wake_up > => __queue_work > => queue_delayed_work_on > => vmstat_shepherd > => process_one_work > => worker_thread > => kthread > => ret_from_fork > kworker/7:1-410 [007] d..3 1820.717790: thread_noise: > kworker/7:1:410 start 1820.717786519 duration 3626 ns >osnoise/7-1000[007] 1821.582340: 100 90 > 99.99100 15 1 0 12 6 1 > - >% - > > It was possible to easily find that the '1' thread noise was a kworker, > dispatched from CPU 0, and that it was dispatched by "vmstat_shepherd". > > Also, the osnoise dir is not added to a new instance... so, it only > costs "one" file... Every file counts. ;-) What you did not articulate well, is that you want the other trace points to be traced on all CPUs (maybe) when the osnoise threads are on a few (or vice versa). OK, for osnoise, I can see how it is useful. But as you said above, for hwlat tracer, it's not as useful. -- Steve
Re: [PATCH V2 3/3] vDPA/ifcvf: get_config_size should return dev specific config size
On Thu, Apr 15, 2021 at 05:53:36PM +0800, Zhu Lingshan wrote:
get_config_size() should return the size based on the decected
device type.
Signed-off-by: Zhu Lingshan
---
drivers/vdpa/ifcvf/ifcvf_main.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
index cea1313b1a3f..6844c49fe1de 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -347,7 +347,23 @@ static u32 ifcvf_vdpa_get_vq_align(struct vdpa_device
*vdpa_dev)
static size_t ifcvf_vdpa_get_config_size(struct vdpa_device *vdpa_dev)
{
- return sizeof(struct virtio_net_config);
+ struct ifcvf_adapter *adapter = vdpa_to_adapter(vdpa_dev);
+ struct ifcvf_hw *vf = vdpa_to_vf(vdpa_dev);
+ struct pci_dev *pdev = adapter->pdev;
+ size_t size;
+
+ if (vf->dev_type == VIRTIO_ID_NET)
+ size = sizeof(struct virtio_net_config);
+
+ else if (vf->dev_type == VIRTIO_ID_BLOCK)
+ size = sizeof(struct virtio_blk_config);
+
+ else {
+ size = 0;
+ IFCVF_ERR(pdev, "VIRTIO ID %u not supported\n", vf->dev_type);
+ }
I slightly prefer the switch, but I don't have a strong opinion.
However, if we want to use if/else, we should follow
`Documentation/process/coding-style.rst` line 166:
Note that the closing brace is empty on a line of its own, **except** in
the cases where it is followed by a continuation of the same statement,
ie a ``while`` in a do-statement or an ``else`` in an if-statement, like
also `scripts/checkpatch.pl --strict` complains:
CHECK: braces {} should be used on all arms of this statement
#209: FILE: drivers/vdpa/ifcvf/ifcvf_main.c:355:
+ if (vf->dev_type == VIRTIO_ID_NET)
[...]
+ else if (vf->dev_type == VIRTIO_ID_BLOCK)
[...]
+ else {
[...]
CHECK: Unbalanced braces around else statement
#215: FILE: drivers/vdpa/ifcvf/ifcvf_main.c:361:
+ else {
Thanks,
Stefano
Re: [PATCH 1/2] iommu/mediatek-v1: Avoid build fail when build as module
On Mon, Apr 12, 2021 at 02:48:42PM +0800, Yong Wu wrote:
> When this driver build as module, It build fail like:
>
> ERROR: modpost: "of_phandle_iterator_args"
> [drivers/iommu/mtk_iommu_v1.ko] undefined!
>
> This patch remove this interface to avoid this build fail.
>
> Reported-by: Valdis Kletnieks
> Signed-off-by: Yong Wu
> ---
> Currently below patch is only in linux-next-20210409. This fixes tag may be
> not needed. we can add this if it is need.
> Fixes: 8de000cf0265 ("iommu/mediatek-v1: Allow building as module")
> ---
> drivers/iommu/mtk_iommu_v1.c | 62
> 1 file changed, 28 insertions(+), 34 deletions(-)
Applied both, thanks.
