5.9.11-rc1 review
Greg Kroah-Hartman
maintainerPATCH 175/252 bpf, sockmap: Use truesize with sk_rmem_schedule()
In reply to Greg Kroah-HartmanFrom: John Fastabend <[email protected]>
[ Upstream commit 70796fb751f1d34cc650e640572a174faf009cd4 ]
We use skb->size with sk_rmem_scheduled() which is not correct. Instead use truesize to align with socket and tcp stack usage of sk_rmem_schedule.
--- net/core/skmsg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/core/skmsg.c +1 -1
@@ -411,7 +411,7 @@ static int sk_psock_skb_ingress(struct sk_psock *psock, struct sk_buff *skb) msg =kzalloc (sizeof (*msg), __GFP_NOWARN |GFP_ATOMIC );if (unlikely (!msg))return -EAGAIN ; -if (!sk_rmem_schedule (sk, skb, skb->len)) { +if (!sk_rmem_schedule (sk, skb, skb->truesize)) {kfree (msg);return -EAGAIN ; }
Signature · 1 line
2.27.0
Greg Kroah-Hartman
maintainerPATCH 176/252 bpf, sockmap: Avoid returning unneeded EAGAIN when redirecting to self
In reply to Greg Kroah-HartmanFrom: John Fastabend <[email protected]>
[ Upstream commit 6fa9201a898983da731fca068bb4b5c941537588 ]
If a socket redirects to itself and it is under memory pressure it is possible to get a socket stuck so that recv() returns EAGAIN and the socket can not advance for some time. This happens because when redirecting a skb to the same socket we received the skb on we first check if it is OK to enqueue the skb on the receiving socket by checking memory limits. But, if the skb is itself the object holding the memory needed to enqueue the skb we will keep retrying from kernel side and always fail with EAGAIN. Then userspace will get a recv() EAGAIN error if there are no skbs in the psock ingress queue. This will continue until either some skbs get kfree'd causing the memory pressure to reduce far enough that we can enqueue the pending packet or the socket is destroyed. In some cases its possible to get a socket stuck for a noticeable amount of time if the socket is only receiving skbs from sk_skb verdict programs. To reproduce I make the socket memory limits ridiculously low so sockets are always under memory pressure. More often though if under memory pressure it looks like a spurious EAGAIN error on user space side causing userspace to retry and typically enough has moved on the memory side that it works.
To fix skip memory checks and skb_orphan if receiving on the same sock as already assigned.
For SK_PASS cases this is easy, its always the same socket so we can just omit the orphan/set_owner pair.
For backlog cases we need to check skb->sk and decide if the orphan and set_owner pair are needed.
--- net/core/skmsg.c | 72 +++++++++++++++++++++++++++++++++++------------- 1 file changed, 53 insertions(+), 19 deletions(-)
net/core/skmsg.c +53 -19
@@ -399,38 +399,38 @@ out: }EXPORT_SYMBOL_GPL (sk_msg_memcopy_from_iter); -static int sk_psock_skb_ingress (struct sk_psock *psock,struct sk_buff *skb) +static struct sk_msg *sk_psock_create_ingress_msg (struct sock *sk, +struct sk_buff *skb) { -struct sock *sk = psock->sk; -int copied =0 , num_sge;struct sk_msg *msg;if (atomic_read (&sk->sk_rmem_alloc) > sk->sk_rcvbuf) -return -EAGAIN ; +return NULL ; + +if (!sk_rmem_schedule (sk, skb, skb->truesize)) +return NULL ; msg =kzalloc (sizeof (*msg), __GFP_NOWARN |GFP_ATOMIC );if (unlikely (!msg)) -return -EAGAIN ; -if (!sk_rmem_schedule (sk, skb, skb->truesize)) { -kfree (msg); -return -EAGAIN ; - } +return NULL ;sk_msg_init (msg); - num_sge =skb_to_sgvec (skb, msg->sg.data,0 , skb->len); +return msg; +} + +static int sk_psock_skb_ingress_enqueue (struct sk_buff *skb, +struct sk_psock *psock, +struct sock *sk, +struct sk_msg *msg) +{ +int num_sge =skb_to_sgvec (skb, msg->sg.data,0 , skb->len); +int copied; +if (unlikely (num_sge <0 )) {kfree (msg);return num_sge; } -/* This will transition ownership of the data from the socket where -* the BPF program was run initiating the redirect to the socket -* we will eventually receive this data on. The data will be released -* from skb_consume found in __tcp_bpf_recvmsg() after its been copied -* into user buffers. -*/ -skb_set_owner_r (skb, sk); - copied = skb->len; msg->sg.start =0 ; msg->sg.size = copied;
@@ -442,6 +442,40 @@ static int sk_psock_skb_ingress(struct sk_psock *psock, struct sk_buff *skb)return copied; } +static int sk_psock_skb_ingress (struct sk_psock *psock,struct sk_buff *skb) +{ +struct sock *sk = psock->sk; +struct sk_msg *msg; + + msg =sk_psock_create_ingress_msg (sk, skb); +if (!msg) +return -EAGAIN ; + +/* This will transition ownership of the data from the socket where +* the BPF program was run initiating the redirect to the socket +* we will eventually receive this data on. The data will be released +* from skb_consume found in __tcp_bpf_recvmsg() after its been copied +* into user buffers. +*/ +skb_set_owner_r (skb, sk); +return sk_psock_skb_ingress_enqueue (skb, psock, sk, msg); +} + +/* Puts an skb on the ingress queue of the socket already assigned to the +* skb. In this case we do not need to check memory limits or skb_set_owner_r +* because the skb is already accounted for here. +*/ +static int sk_psock_skb_ingress_self (struct sk_psock *psock,struct sk_buff *skb) +{ +struct sk_msg *msg =kzalloc (sizeof (*msg), __GFP_NOWARN |GFP_ATOMIC ); +struct sock *sk = psock->sk; + +if (unlikely (!msg)) +return -EAGAIN ; +sk_msg_init (msg); +return sk_psock_skb_ingress_enqueue (skb, psock, sk, msg); +} +static int sk_psock_handle_skb (struct sk_psock *psock,struct sk_buff *skb,u32 off,u32 len,bool ingress) {
@@ -784,7 +818,7 @@ static void sk_psock_verdict_apply(struct sk_psock *psock,* retrying later from workqueue. */ if (skb_queue_empty (&psock->ingress_skb)) { - err =sk_psock_skb_ingress (psock, skb); + err =sk_psock_skb_ingress_self (psock, skb); }if (err <0 ) {skb_queue_tail (&psock->ingress_skb, skb);
Signature · 1 line
2.27.0
Greg Kroah-Hartman
maintainerPATCH 177/252 efi/arm: set HSCTLR Thumb2 bit correctly for HVC calls from HYP
In reply to Greg Kroah-HartmanFrom: Ard Biesheuvel <[email protected]>
[ Upstream commit fbc81ec5b85d43a4b22e49ec0e643fa7dec2ea40 ]
Commit
db227c19e68db353 ("ARM: 8985/1: efi/decompressor: deal with HYP mode boot gracefully")
updated the EFI entry code to permit firmware to invoke the EFI stub loader in HYP mode, with the MMU either enabled or disabled, neither of which is permitted by the EFI spec, but which does happen in the field.
In the MMU on case, we remain in HYP mode as configured by the firmware, and rely on the fact that any HVC instruction issued in this mode will be dispatched via the SVC slot in the HYP vector table. However, this slot will point to a Thumb2 symbol if the kernel is built in Thumb2 mode, and so we have to configure HSCTLR to ensure that the exception handlers are invoked in Thumb2 mode as well.
--- arch/arm/boot/compressed/head.S | 3 +++ 1 file changed, 3 insertions(+)
arch/arm/boot/compressed/head.S +3 -0
@@ -1476,6 +1476,9 @@ ENTRY(efi_enter_kernel) @ issued from HYP mode take us to the correct handler code. We @ will disable the MMU before jumping to the kernel proper. @ + ARM( bic r1, r1, #(1 << 30) ) @ clear HSCTLR.TE + THUMB( orr r1, r1, #(1 << 30) ) @ set HSCTLR.TE + mcr p15, 4, r1, c1, c0, 0 adr r0, __hyp_reentry_vectors mcr p15, 4, r0, c12, c0, 0 @ set HYP vector base (HVBAR) isb
Signature · 1 line
2.27.0
Greg Kroah-Hartman
maintainerPATCH 178/252 counter/ti-eqep: Fix regmap max_register
In reply to Greg Kroah-HartmanFrom: David Lechner <[email protected]>
[ Upstream commit 271b339236e1c0e6448bc1cafeaedcb529324bf0 ]
The values given were the offset of the register after the last register instead of the actual last register in each range. Fix by using the correct last register of each range.
--- drivers/counter/ti-eqep.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/counter/ti-eqep.c +2 -2
@@ -368,7 +368,7 @@ static const struct regmap_config ti_eqep_regmap32_config = { .reg_bits = 32, .val_bits = 32, .reg_stride = 4, - .max_register = 0x24, + .max_register = QUPRD, };static const struct regmap_config ti_eqep_regmap16_config = {
@@ -376,7 +376,7 @@ static const struct regmap_config ti_eqep_regmap16_config = { .reg_bits = 16, .val_bits = 16, .reg_stride = 2, - .max_register = 0x1e, + .max_register = QCPRDLAT, };static int ti_eqep_probe (struct platform_device *pdev)
Signature · 1 line
2.27.0
Greg Kroah-Hartman
maintainerPATCH 179/252 efi/x86: Free efi_pgd with free_pages()
In reply to Greg Kroah-HartmanFrom: Arvind Sankar <[email protected]>
[ Upstream commit c2fe61d8be491ff8188edaf22e838f819999146b ]
Commit
d9e9a6418065 ("x86/mm/pti: Allocate a separate user PGD")
changed the PGD allocation to allocate PGD_ALLOCATION_ORDER pages, so in the error path it should be freed using free_pages() rather than free_page().
Commit
06ace26f4e6f ("x86/efi: Free efi_pgd with free_pages()")fixed one instance of this, but missed another.
Move the freeing out-of-line to avoid code duplication and fix this bug.
--- arch/x86/platform/efi/efi_64.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-)
arch/x86/platform/efi/efi_64.c +13 -11
@@ -77,28 +77,30 @@ int __init efi_alloc_page_tables(void) gfp_mask =GFP_KERNEL | __GFP_ZERO; efi_pgd = (pgd_t *)__get_free_pages (gfp_mask,PGD_ALLOCATION_ORDER );if (!efi_pgd) -return -ENOMEM ; + goto fail; pgd = efi_pgd +pgd_index (EFI_VA_END ); p4d =p4d_alloc (&init_mm, pgd,EFI_VA_END ); -if (!p4d) { -free_page ((unsigned long )efi_pgd); -return -ENOMEM ; - } +if (!p4d) + goto free_pgd; pud =pud_alloc (&init_mm, p4d,EFI_VA_END ); -if (!pud) { -if (pgtable_l5_enabled ()) -free_page ((unsigned long )pgd_page_vaddr (*pgd)); -free_pages ((unsigned long )efi_pgd,PGD_ALLOCATION_ORDER ); -return -ENOMEM ; - } +if (!pud) + goto free_p4d; efi_mm.pgd = efi_pgd;mm_init_cpumask (&efi_mm);init_new_context (NULL , &efi_mm);return 0 ; + +free_p4d: +if (pgtable_l5_enabled ()) +free_page ((unsigned long )pgd_page_vaddr (*pgd)); +free_pgd: +free_pages ((unsigned long )efi_pgd,PGD_ALLOCATION_ORDER ); +fail: +return -ENOMEM ; }/*
Signature · 1 line
2.27.0
Greg Kroah-Hartman
maintainerPATCH 180/252 sched/fair: Fix overutilized update in enqueue_task_fair()
In reply to Greg Kroah-HartmanFrom: Quentin Perret <[email protected]>
[ Upstream commit 8e1ac4299a6e8726de42310d9c1379f188140c71 ]
enqueue_task_fair() attempts to skip the overutilized update for new tasks as their util_avg is not accurate yet. However, the flag we check to do so is overwritten earlier on in the function, which makes the condition pretty much a nop.
Fix this by saving the flag early on.
--- kernel/sched/fair.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
kernel/sched/fair.c +2 -1
@@ -5473,6 +5473,7 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)struct cfs_rq *cfs_rq;struct sched_entity *se = &p->se;int idle_h_nr_running =task_has_idle_policy (p); +int task_new = !(flags &ENQUEUE_WAKEUP );/* * The code below (indirectly) updates schedutil which looks at
@@ -5545,7 +5546,7 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)* into account, but that is not straightforward to implement, * and the following generally works well enough in practice. */ -if (flags &ENQUEUE_WAKEUP ) +if (!task_new)update_overutilized_status (rq); enqueue_throttle:
Signature · 1 line
2.27.0
Greg Kroah-Hartman
maintainerPATCH 181/252 sched: Fix data-race in wakeup
In reply to Greg Kroah-HartmanFrom: Peter Zijlstra <[email protected]>
[ Upstream commit f97bb5272d9e95d400d6c8643ebb146b3e3e7842 ]
Mel reported that on some ARM64 platforms loadavg goes bananas and Will tracked it down to the following race:
CPU0 CPU1
schedule()
prev->sched_contributes_to_load = X;
deactivate_task(prev); try_to_wake_up()
if (p->on_rq &&) // false
if (smp_load_acquire(&p->on_cpu) && // true
ttwu_queue_wakelist())
p->sched_remote_wakeup = Y;
smp_store_release(prev->on_cpu, 0);where both p->sched_contributes_to_load and p->sched_remote_wakeup are in the same word, and thus the stores X and Y race (and can clobber one another's data).
Whereas prior to commit c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") the p->on_cpu handoff serialized access to p->sched_remote_wakeup (just as it still does with p->sched_contributes_to_load) that commit broke that by calling ttwu_queue_wakelist() with p->on_cpu != 0.
However, due to
p->XXX = X ttwu()
schedule() if (p->on_rq && ...) // false
smp_mb__after_spinlock() if (smp_load_acquire(&p->on_cpu) &&
deactivate_task() ttwu_queue_wakelist())
p->on_rq = 0; p->sched_remote_wakeup = Y;We can be sure any 'current' store is complete and 'current' is guaranteed asleep. Therefore we can move p->sched_remote_wakeup into the current flags word.
Note: while the observed failure was loadavg accounting gone wrong due to ttwu() cobbering p->sched_contributes_to_load, the reverse problem is also possible where schedule() clobbers p->sched_remote_wakeup, this could result in enqueue_entity() wrecking ->vruntime and causing scheduling artifacts.
--- include/linux/sched.h | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)
include/linux/sched.h +15 -1
@@ -770,7 +770,6 @@ struct task_struct { unsigned sched_reset_on_fork:1; unsigned sched_contributes_to_load:1; unsigned sched_migrated:1; - unsigned sched_remote_wakeup:1;#ifdef CONFIG_PSI unsigned sched_psi_wake_requeue:1;#endif
@@ -780,6 +779,21 @@ struct task_struct {/* Unserialized, strictly 'current' */ +/* +* This field must not be in the scheduler word above due to wakelist +* queueing no longer being serialized by p->on_cpu. However: +* +* p->XXX = X; ttwu() +* schedule() if (p->on_rq && ..) // false +* smp_mb__after_spinlock(); if (smp_load_acquire(&p->on_cpu) && //true +* deactivate_task() ttwu_queue_wakelist()) +* p->on_rq = 0; p->sched_remote_wakeup = Y; +* +* guarantees all stores of 'current' are visible before +* ->sched_remote_wakeup gets used, so it can be in this word. +*/ + unsigned sched_remote_wakeup:1; +/* Bit to tell LSMs we're in execve(): */ unsigned in_execve:1; unsigned in_iowait:1;
Signature · 1 line
2.27.0
Greg Kroah-Hartman
maintainerPATCH 182/252 sched: Fix rq->nr_iowait ordering
In reply to Greg Kroah-HartmanFrom: Peter Zijlstra <[email protected]>
[ Upstream commit ec618b84f6e15281cc3660664d34cd0dd2f2579e ]
schedule() ttwu()
deactivate_task(); if (p->on_rq && ...) // false
atomic_dec(&task_rq(p)->nr_iowait);
if (prev->in_iowait)
atomic_inc(&rq->nr_iowait);Allows nr_iowait to be decremented before it gets incremented, resulting in more dodgy IO-wait numbers than usual.
Note that because we can now do ttwu_queue_wakelist() before p->on_cpu==0, we lose the natural ordering and have to further delay the decrement.
--- kernel/sched/core.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)
kernel/sched/core.c +10 -5
@@ -2505,7 +2505,12 @@ ttwu_do_activate(struct rq *rq, struct task_struct *p, int wake_flags,#ifdef CONFIG_SMP if (wake_flags &WF_MIGRATED ) en_flags |=ENQUEUE_MIGRATED ; + else#endif +if (p->in_iowait) { +delayacct_blkio_end (p); +atomic_dec (&task_rq (p)->nr_iowait); + }activate_task (rq, p, en_flags);ttwu_do_wakeup (rq, p, wake_flags, rf);
@@ -2892,11 +2897,6 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)if (READ_ONCE (p->on_rq) &&ttwu_runnable (p, wake_flags)) goto unlock; -if (p->in_iowait) { -delayacct_blkio_end (p); -atomic_dec (&task_rq (p)->nr_iowait); - } -#ifdef CONFIG_SMP /* * Ensure we load p->on_cpu _after_ p->on_rq, otherwise it would be
@@ -2967,6 +2967,11 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags) cpu =select_task_rq (p, p->wake_cpu,SD_BALANCE_WAKE , wake_flags);if (task_cpu (p) != cpu) { +if (p->in_iowait) { +delayacct_blkio_end (p); +atomic_dec (&task_rq (p)->nr_iowait); + } + wake_flags |=WF_MIGRATED ;psi_ttwu_dequeue (p);set_task_cpu (p, cpu);
Signature · 1 line
2.27.0
Greg Kroah-Hartman
maintainerPATCH 183/252 libfs: fix error cast of negative value in simple_attr_write()
In reply to Greg Kroah-HartmanFrom: Yicong Yang <[email protected]>
[ Upstream commit 488dac0c9237647e9b8f788b6a342595bfa40bda ]
The attr->set() receive a value of u64, but simple_strtoll() is used for doing the conversion. It will lead to the error cast if user inputs a negative value.
Use kstrtoull() instead of simple_strtoll() to convert a string got from the user to an unsigned value. The former will return '-EINVAL' if it gets a negetive value, but the latter can't handle the situation correctly. Make 'val' unsigned long long as what kstrtoull() takes, this will eliminate the compile warning on no 64-bit architectures.
--- fs/libfs.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
fs/libfs.c +4 -2
@@ -957,7 +957,7 @@ ssize_t simple_attr_write(struct file *file, const char __user *buf, size_t len, loff_t *ppos) { struct simple_attr *attr; -u64 val; +unsigned long long val;size_t size;ssize_t ret;
@@ -975,7 +975,9 @@ ssize_t simple_attr_write(struct file *file, const char __user *buf, goto out; attr->set_buf[size] ='\0' ; - val =simple_strtoll (attr->set_buf,NULL ,0 ); + ret =kstrtoull (attr->set_buf,0 , &val); +if (ret) + goto out; ret = attr->set (attr->data, val);if (ret ==0 ) ret = len;/* on success, claim we got the whole input */
Signature · 1 line
2.27.0
Greg Kroah-Hartman
maintainerPATCH 184/252 afs: Fix speculative status fetch going out of order wrt to modifications
In reply to Greg Kroah-HartmanFrom: David Howells <[email protected]>
[ Upstream commit a9e5c87ca7443d09fb530fffa4d96ce1c76dbe4d ]
When doing a lookup in a directory, the afs filesystem uses a bulk status fetch to speculatively retrieve the statuses of up to 48 other vnodes found in the same directory and it will then either update extant inodes or create new ones - effectively doing 'lookup ahead'.
To avoid the possibility of deadlocking itself, however, the filesystem doesn't lock all of those inodes; rather just the directory inode is locked (by the VFS).
When the operation completes, afs_inode_init_from_status() or afs_apply_status() is called, depending on whether the inode already exists, to commit the new status.
A case exists, however, where the speculative status fetch operation may straddle a modification operation on one of those vnodes. What can then happen is that the speculative bulk status RPC retrieves the old status, and whilst that is happening, the modification happens - which returns an updated status, then the modification status is committed, then we attempt to commit the speculative status.
This results in something like the following being seen in dmesg:
kAFS: vnode modified {100058:861} 8->9 YFS.InlineBulkStatusshowing that for vnode 861 on volume 100058, we saw YFS.InlineBulkStatus say that the vnode had data version 8 when we'd already recorded version 9 due to a local modification. This was causing the cache to be invalidated for that vnode when it shouldn't have been. If it happens on a data file, this might lead to local changes being lost.
Fix this by ignoring speculative status updates if the data version doesn't match the expected value.
Note that it is possible to get a DV regression if a volume gets restored from a backup - but we should get a callback break in such a case that should trigger a recheck anyway. It might be worth checking the volume creation time in the volsync info and, if a change is observed in that (as would happen on a restore), invalidate all caches associated with the volume.
--- fs/afs/dir.c | 1 + fs/afs/inode.c | 8 ++++++++ fs/afs/internal.h | 1 + 3 files changed, 10 insertions(+)
fs/afs/dir.c +1 -0
@@ -823,6 +823,7 @@ static struct inode *afs_do_lookup(struct inode *dir, struct dentry *dentry, vp->cb_break_before =afs_calc_vnode_cb_break (vnode); vp->vnode = vnode; vp->put_vnode = true; + vp->speculative = true;/* vnode not locked */ } } }
fs/afs/inode.c +8 -0
@@ -294,6 +294,13 @@ void afs_vnode_commit_status(struct afs_operation *op, struct afs_vnode_param *v op->flags &= ~AFS_OPERATION_DIR_CONFLICT ; } }else if (vp->scb.have_status) { +if (vp->dv_before + vp->dv_delta != vp->scb.status.data_version && + vp->speculative) +/* Ignore the result of a speculative bulk status fetch +* if it splits around a modification op, thereby +* appearing to regress the data version. +*/ + goto out;afs_apply_status (op, vp);if (vp->scb.have_cb)afs_apply_callback (op, vp);
@@ -305,6 +312,7 @@ void afs_vnode_commit_status(struct afs_operation *op, struct afs_vnode_param *v } } +out:write_sequnlock (&vnode->cb_lock);if (vp->scb.have_status)
fs/afs/internal.h +1 -0
@@ -754,6 +754,7 @@ struct afs_vnode_param { bool update_ctime:1; /* Need to update the ctime */ bool set_size:1; /* Must update i_size */ bool op_unlinked:1; /* True if file was unlinked by op */ + bool speculative:1; /* T if speculative status fetch (no vnode lock) */ };/*
Signature · 1 line
2.27.0
Greg Kroah-Hartman
maintainerPATCH 185/252 HID: logitech-hidpp: Add PID for MX Anywhere 2
In reply to Greg Kroah-HartmanFrom: Harry Cutts <[email protected]>
[ Upstream commit b59f38dbfd5d19eb7e03d8b639f0c0d385ba8cc5 ]
It seems that the PID 0x4072 was missing from the list Logitech gave me for this mouse, as I found one with it in the wild (with which I tested this patch).
--- drivers/hid/hid-logitech-hidpp.c | 1 + 1 file changed, 1 insertion(+)
drivers/hid/hid-logitech-hidpp.c +1 -0
@@ -3947,6 +3947,7 @@ static const struct hid_device_id hidpp_devices[] = { LDJ_DEVICE(0x405e), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 }, {/* Mouse Logitech MX Anywhere 2 */ LDJ_DEVICE(0x404a), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 }, + { LDJ_DEVICE(0x4072), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 }, { LDJ_DEVICE(0xb013), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 }, { LDJ_DEVICE(0xb018), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 }, { LDJ_DEVICE(0xb01f), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
Signature · 1 line
2.27.0
Greg Kroah-Hartman
maintainerPATCH 186/252 HID: mcp2221: Fix GPIO output handling
In reply to Greg Kroah-HartmanFrom: Lars Povlsen <[email protected]>
[ Upstream commit 567b8e9fed8add9e20885be38ecd73bb0e07406b ]
The mcp2221 driver GPIO output handling has has several issues.
* A wrong value is used for the GPIO direction.
* Wrong offsets are calculated for some GPIO set value/set direction operations, when offset is larger than 0.
This has been fixed by introducing proper manifest constants for the direction encoding, and using 'offsetof' when calculating GPIO register offsets.
The updated driver has been tested with the Sparx5 pcb134/pcb135 board, which has the mcp2221 device with several (output) GPIO's.
--- drivers/hid/hid-mcp2221.c | 48 +++++++++++++++++++++++++++++++-------- 1 file changed, 39 insertions(+), 9 deletions(-)
drivers/hid/hid-mcp2221.c +39 -9
@@ -49,6 +49,36 @@ enum { MCP2221_ALT_F_NOT_GPIOD = 0xEF, }; +/* MCP GPIO direction encoding */ +enum { +MCP2221_DIR_OUT =0x00 , +MCP2221_DIR_IN =0x01 , +}; + +#define MCP_NGPIO 4 + +/* MCP GPIO set command layout */ +struct mcp_set_gpio { +u8 cmd; +u8 dummy; +struct { +u8 change_value; +u8 value; +u8 change_direction; +u8 direction; + } gpio[MCP_NGPIO ]; +} __packed; + +/* MCP GPIO get command layout */ +struct mcp_get_gpio { +u8 cmd; +u8 dummy; +struct { +u8 direction; +u8 value; + } gpio[MCP_NGPIO ]; +} __packed; +/* * There is no way to distinguish responses. Therefore next command * is sent only after response to previous has been received. Mutex
@@ -542,7 +572,7 @@ static int mcp_gpio_get(struct gpio_chip *gc, mcp->txbuf[0 ] =MCP2221_GPIO_GET ; - mcp->gp_idx = (offset +1 ) *2 ; + mcp->gp_idx = offsetof(struct mcp_get_gpio, gpio[offset].value);mutex_lock (&mcp->lock); ret =mcp_send_data_req_status (mcp, mcp->txbuf,1 );
@@ -559,7 +589,7 @@ static void mcp_gpio_set(struct gpio_chip *gc,memset (mcp->txbuf,0 ,18 ); mcp->txbuf[0 ] =MCP2221_GPIO_SET ; - mcp->gp_idx = ((offset +1 ) *4 ) -1 ; + mcp->gp_idx = offsetof(struct mcp_set_gpio, gpio[offset].value); mcp->txbuf[mcp->gp_idx -1 ] =1 ; mcp->txbuf[mcp->gp_idx] = !!value;
@@ -575,7 +605,7 @@ static int mcp_gpio_dir_set(struct mcp2221 *mcp,memset (mcp->txbuf,0 ,18 ); mcp->txbuf[0 ] =MCP2221_GPIO_SET ; - mcp->gp_idx = (offset +1 ) *5 ; + mcp->gp_idx = offsetof(struct mcp_set_gpio, gpio[offset].direction); mcp->txbuf[mcp->gp_idx -1 ] =1 ; mcp->txbuf[mcp->gp_idx] = val;
@@ -590,7 +620,7 @@ static int mcp_gpio_direction_input(struct gpio_chip *gc,struct mcp2221 *mcp =gpiochip_get_data (gc);mutex_lock (&mcp->lock); - ret =mcp_gpio_dir_set (mcp, offset,0 ); + ret =mcp_gpio_dir_set (mcp, offset,MCP2221_DIR_IN );mutex_unlock (&mcp->lock);return ret;
@@ -603,7 +633,7 @@ static int mcp_gpio_direction_output(struct gpio_chip *gc,struct mcp2221 *mcp =gpiochip_get_data (gc);mutex_lock (&mcp->lock); - ret =mcp_gpio_dir_set (mcp, offset,1 ); + ret =mcp_gpio_dir_set (mcp, offset,MCP2221_DIR_OUT );mutex_unlock (&mcp->lock);/* Can't configure as output, bailout early */
@@ -623,7 +653,7 @@ static int mcp_gpio_get_direction(struct gpio_chip *gc, mcp->txbuf[0 ] =MCP2221_GPIO_GET ; - mcp->gp_idx = (offset +1 ) *2 ; + mcp->gp_idx = offsetof(struct mcp_get_gpio, gpio[offset].direction);mutex_lock (&mcp->lock); ret =mcp_send_data_req_status (mcp, mcp->txbuf,1 );
@@ -632,7 +662,7 @@ static int mcp_gpio_get_direction(struct gpio_chip *gc,if (ret)return ret; -if (mcp->gpio_dir) +if (mcp->gpio_dir ==MCP2221_DIR_IN )return GPIO_LINE_DIRECTION_IN ;return GPIO_LINE_DIRECTION_OUT ;
@@ -758,7 +788,7 @@ static int mcp2221_raw_event(struct hid_device *hdev, mcp->status = -ENOENT ; }else { mcp->status = !!data[mcp->gp_idx]; - mcp->gpio_dir = !!data[mcp->gp_idx +1 ]; + mcp->gpio_dir = data[mcp->gp_idx +1 ]; }break ;default :
@@ -860,7 +890,7 @@ static int mcp2221_probe(struct hid_device *hdev, mcp->gc->get_direction = mcp_gpio_get_direction; mcp->gc->set = mcp_gpio_set; mcp->gc->get = mcp_gpio_get; - mcp->gc->ngpio =4 ; + mcp->gc->ngpio =MCP_NGPIO ; mcp->gc->base =-1 ; mcp->gc->can_sleep =1 ; mcp->gc->parent = &hdev->dev;
Signature · 1 line
2.27.0
Greg Kroah-Hartman
maintainerPATCH 187/252 HID: logitech-dj: Handle quad/bluetooth keyboards with a builtin trackpad
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
[ Upstream commit ee5e58418a854755201eb4952b1230d873a457d5 ]
Some quad/bluetooth keyboards, such as the Dinovo Edge (Y-RAY81) have a builtin touchpad. In this case when asking the receiver for paired devices, we get only 1 paired device with a device_type of REPORT_TYPE_KEYBOARD.
This means that we do not instantiate a second dj_hiddev for the mouse (as we normally would) and thus there is no place for us to forward the mouse input reports to, causing the touchpad part of the keyboard to not work.
There is no way for us to detect these keyboards, so this commit adds an array with device-ids for such keyboards and when a keyboard is on this list it adds STD_MOUSE to the reports_supported bitmap for the dj_hiddev created for the keyboard fixing the touchpad not working.
Using a list of device-ids for this is not ideal, but there are only very few such keyboards so this should be fine. Besides the Dinovo Edge, other known wireless Logitech keyboards with a builtin touchpad are:
* Dinovo Mini (TODO add its device-id to the list)
* K400 (uses a unifying receiver so is not affected)
* K600 (uses a unifying receiver so is not affected)
--- drivers/hid/hid-logitech-dj.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
drivers/hid/hid-logitech-dj.c +19 -0
@@ -866,11 +866,23 @@ static void logi_dj_recv_queue_notification(struct dj_receiver_dev *djrcv_dev,schedule_work (&djrcv_dev->work); } +/* +* Some quad/bluetooth keyboards have a builtin touchpad in this case we see +* only 1 paired device with a device_type of REPORT_TYPE_KEYBOARD. For the +* touchpad to work we must also forward mouse input reports to the dj_hiddev +* created for the keyboard (instead of forwarding them to a second paired +* device with a device_type of REPORT_TYPE_MOUSE as we normally would). +*/ +static const u16 kbd_builtin_touchpad_ids[] = { +0xb309 ,/* Dinovo Edge */ +}; +static void logi_hidpp_dev_conn_notif_equad (struct hid_device *hdev,struct hidpp_event *hidpp_report,struct dj_workitem *workitem) {struct dj_receiver_dev *djrcv_dev =hid_get_drvdata (hdev); +int i, id; workitem->type =WORKITEM_TYPE_PAIRED ; workitem->device_type = hidpp_report->params[HIDPP_PARAM_DEVICE_INFO] &
@@ -882,6 +894,13 @@ static void logi_hidpp_dev_conn_notif_equad(struct hid_device *hdev, workitem->reports_supported |=STD_KEYBOARD |MULTIMEDIA |POWER_KEYS |MEDIA_CENTER |HIDPP ; + id = (workitem->quad_id_msb <<8 ) | workitem->quad_id_lsb; +for (i =0 ; i <ARRAY_SIZE (kbd_builtin_touchpad_ids); i++) { +if (id == kbd_builtin_touchpad_ids[i]) { + workitem->reports_supported |=STD_MOUSE ; +break ; + } + }break ;case REPORT_TYPE_MOUSE : workitem->reports_supported |=STD_MOUSE |HIDPP ;
Signature · 1 line
2.27.0
Greg Kroah-Hartman
maintainerPATCH 188/252 HID: logitech-dj: Fix Dinovo Mini when paired with a MX5x00 receiver
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
[ Upstream commit b4c00e7976636f33a4f67eab436a11666c8afd60 ]
Some users are pairing the Dinovo keyboards with the MX5000 or MX5500 receivers, instead of with the Dinovo receivers. The receivers are mostly the same (and the air protocol obviously is compatible) but currently the Dinovo receivers are handled by hid-lg.c while the MX5x00 receivers are handled by logitech-dj.c.
When using a Dinovo keyboard, with its builtin touchpad, through logitech-dj.c then the touchpad stops working because when asking the receiver for paired devices, we get only 1 paired device with a device_type of REPORT_TYPE_KEYBOARD. And since we don't see a paired mouse, we have nowhere to send mouse-events to, so we drop them.
Extend the existing fix for the Dinovo Edge for this to also cover the Dinovo Mini keyboard and also add a mapping to logitech-hidpp for the Media key on the Dinovo Mini, so that that keeps working too.
--- drivers/hid/hid-logitech-dj.c | 1 + drivers/hid/hid-logitech-hidpp.c | 25 +++++++++++++++++++++++++ 2 files changed, 26 insertions(+)
drivers/hid/hid-logitech-dj.c +1 -0
@@ -875,6 +875,7 @@ static void logi_dj_recv_queue_notification(struct dj_receiver_dev *djrcv_dev,*/ static const u16 kbd_builtin_touchpad_ids[] = {0xb309 ,/* Dinovo Edge */ +0xb30c ,/* Dinovo Mini */ }; static void logi_hidpp_dev_conn_notif_equad(struct hid_device *hdev,
drivers/hid/hid-logitech-hidpp.c +25 -0
@@ -93,6 +93,8 @@ MODULE_PARM_DESC(disable_tap_to_click,#define HIDPP_CAPABILITY_BATTERY_LEVEL_STATUS BIT(3)#define HIDPP_CAPABILITY_BATTERY_VOLTAGE BIT(4) +#define lg_map_key_clear (c) hid_map_usage_clear(hi, usage, bit, max, EV_KEY, (c)) +/* * There are two hidpp protocols in use, the first version hidpp10 is known * as register access protocol or RAP, the second version hidpp20 is known as
@@ -2950,6 +2952,26 @@ static int g920_get_config(struct hidpp_device *hidpp,return g920_ff_set_autocenter (hidpp, data); } +/* -------------------------------------------------------------------------- */ +/* Logitech Dinovo Mini keyboard with builtin touchpad */ +/* -------------------------------------------------------------------------- */ +#define DINOVO_MINI_PRODUCT_ID 0xb30c + +static int lg_dinovo_input_mapping (struct hid_device *hdev,struct hid_input *hi, +struct hid_field *field,struct hid_usage *usage, +unsigned long **bit,int *max) +{ +if ((usage->hid &HID_USAGE_PAGE ) !=HID_UP_LOGIVENDOR ) +return 0 ; + +switch (usage->hid &HID_USAGE ) { +case 0x00d :lg_map_key_clear (KEY_MEDIA );break ; +default : +return 0 ; + } +return 1 ; +} +/* -------------------------------------------------------------------------- */ /* HID++1.0 devices which use HID++ reports for their wheels */ /* -------------------------------------------------------------------------- */
@@ -3185,6 +3207,9 @@ static int hidpp_input_mapping(struct hid_device *hdev, struct hid_input *hi, field->application != HID_GD_MOUSE)return m560_input_mapping (hdev, hi, field, usage, bit, max); +if (hdev->product ==DINOVO_MINI_PRODUCT_ID ) +return lg_dinovo_input_mapping (hdev, hi, field, usage, bit, max); +return 0 ; }
Signature · 1 line
2.27.0
Greg Kroah-Hartman
maintainerPATCH 189/252 speakup: Do not let the line discipline be used several times
In reply to Greg Kroah-HartmanFrom: Samuel Thibault <[email protected]>
commit d4122754442799187d5d537a9c039a49a67e57f1 upstream.
Speakup has only one speakup_tty variable to store the tty it is managing. This makes sense since its codebase currently assumes that there is only one user who controls the screen reading.
That however means that we have to forbid using the line discipline several times, otherwise the second closure would try to free a NULL ldisc_data, leading to
general protection fault: 0000 [#1] SMP KASAN PTI RIP: 0010:spk_ttyio_ldisc_close+0x2c/0x60 Call Trace: tty_ldisc_release+0xa2/0x340 tty_release_struct+0x17/0xd0 tty_release+0x9d9/0xcc0 __fput+0x231/0x740 task_work_run+0x12c/0x1a0 do_exit+0x9b5/0x2230 ? release_task+0x1240/0x1240 ? __do_page_fault+0x562/0xa30 do_group_exit+0xd5/0x2a0 __x64_sys_exit_group+0x35/0x40 do_syscall_64+0x89/0x2b0 ? page_fault+0x8/0x30 entry_SYSCALL_64_after_hwframe+0x44/0xa9
--- drivers/accessibility/speakup/spk_ttyio.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
drivers/accessibility/speakup/spk_ttyio.c +11 -1
@@ -49,15 +49,25 @@ static int spk_ttyio_ldisc_open(struct tif (!tty->ops->write)return -EOPNOTSUPP ; + +mutex_lock (&speakup_tty_mutex); +if (speakup_tty) { +mutex_unlock (&speakup_tty_mutex); +return -EBUSY ; + } speakup_tty = tty; ldisc_data =kmalloc (sizeof (*ldisc_data),GFP_KERNEL ); -if (!ldisc_data) +if (!ldisc_data) { + speakup_tty =NULL ; +mutex_unlock (&speakup_tty_mutex);return -ENOMEM ; + }init_completion (&ldisc_data->completion); ldisc_data->buf_free = true; speakup_tty->disc_data = ldisc_data; +mutex_unlock (&speakup_tty_mutex);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 190/252 ALSA: firewire: Clean up a locking issue in copy_resp_to_buf()
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
commit 02a9c6ee4183af2e438454c55098b828a96085fb upstream.
The spin_lock/unlock_irq() functions cannot be nested. The problem is that presumably we would want the IRQs to be re-enabled on the second call the spin_unlock_irq() but instead it will be enabled at the first call so IRQs will be enabled earlier than expected.
In this situation the copy_resp_to_buf() function is only called from one function and it is called with IRQs disabled. We can just use the regular spin_lock/unlock() functions.
--- sound/firewire/fireworks/fireworks_transaction.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
sound/firewire/fireworks/fireworks_transaction.c +2 -2
@@ -123,7 +123,7 @@ copy_resp_to_buf(struct snd_efw *efw, vo t = (struct snd_efw_transaction *)data; length =min_t (size_t,be32_to_cpu (t->length) *sizeof (u32), length); -spin_lock_irq (&efw->lock); +spin_lock (&efw->lock);if (efw->push_ptr < efw->pull_ptr) capacity = (unsigned int )(efw->pull_ptr - efw->push_ptr);
@@ -190,7 +190,7 @@ handle_resp_for_user(struct fw_card *carcopy_resp_to_buf (efw, data, length, rcode); end: -spin_unlock_irq (&instances_lock); +spin_unlock (&instances_lock); } static void
Greg Kroah-Hartman
maintainerPATCH 191/252 ALSA: usb-audio: Add delay quirk for all Logitech USB devices
In reply to Greg Kroah-HartmanFrom: Joakim Tjernlund <[email protected]>
commit 54a2a3898f469a915510038fe84ef4f083131d3e upstream.
Found one more Logitech device, BCC950 ConferenceCam, which needs the same delay here. This makes 3 out of 3 devices I have tried.
Therefore, add a delay for all Logitech devices as it does not hurt.
--- sound/usb/quirks.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
sound/usb/quirks.c +5 -5
@@ -1678,13 +1678,13 @@ void snd_usb_ctl_msg_quirk(struct usb_de && (requesttype & USB_TYPE_MASK) == USB_TYPE_CLASS)msleep (20 ); -/* Zoom R16/24, Logitech H650e/H570e, Jabra 550a, Kingston HyperX -* needs a tiny delay here, otherwise requests like get/set -* frequency return as failed despite actually succeeding. +/* Zoom R16/24, many Logitech(at least H650e/H570e/BCC950), +* Jabra 550a, Kingston HyperX needs a tiny delay here, +* otherwise requests like get/set frequency return +* as failed despite actually succeeding. */ if ((chip->usb_id ==USB_ID (0x1686 ,0x00dd ) || - chip->usb_id ==USB_ID (0x046d ,0x0a46 ) || - chip->usb_id ==USB_ID (0x046d ,0x0a56 ) || +USB_ID_VENDOR (chip->usb_id) ==0x046d ||/* Logitech */ chip->usb_id ==USB_ID (0x0b0e ,0x0349 ) || chip->usb_id ==USB_ID (0x0951 ,0x16ad )) && (requesttype &USB_TYPE_MASK ) ==USB_TYPE_CLASS )
Greg Kroah-Hartman
maintainerPATCH 192/252 ALSA: ctl: fix error path at adding user-defined element set
In reply to Greg Kroah-HartmanFrom: Takashi Sakamoto <[email protected]>
commit 95a793c3bc75cf888e0e641d656e7d080f487d8b upstream.
When processing request to add/replace user-defined element set, check of given element identifier and decision of numeric identifier is done in "__snd_ctl_add_replace()" helper function. When the result of check is wrong, the helper function returns error code. The error code shall be returned to userspace application.
Current implementation includes bug to return zero to userspace application regardless of the result. This commit fixes the bug.
--- sound/core/control.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/core/control.c +1 -1
@@ -1527,7 +1527,7 @@ static int snd_ctl_elem_add(struct snd_c unlock:up_write (&card->controls_rwsem); -return 0 ; +return err; } static int snd_ctl_elem_add_user(struct snd_ctl_file *file,
Greg Kroah-Hartman
maintainerPATCH 193/252 ALSA: mixart: Fix mutex deadlock
In reply to Greg Kroah-HartmanFrom: Takashi Iwai <[email protected]>
commit d21b96c8ed2aea7e6b7bf4735e1d2503cfbf4072 upstream.
The code change for switching to non-atomic mode brought the unexpected mutex deadlock in get_msg(). It converted the spinlock with the existing mutex, but there were calls with the already holding the mutex. Since the only place that needs the extra lock is the code path from snd_mixart_send_msg(), remove the mutex lock in get_msg() and apply in the caller side for fixing the mutex deadlock.
--- sound/pci/mixart/mixart_core.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
sound/pci/mixart/mixart_core.c +2 -3
@@ -70,7 +70,6 @@ static int get_msg(struct mixart_mgr *mgunsigned int i;#endif -mutex_lock (&mgr->msg_lock); err =0 ;/* copy message descriptor from miXart to driver */
@@ -119,8 +118,6 @@ static int get_msg(struct mixart_mgr *mgwritel_be (headptr,MIXART_MEM (mgr,MSG_OUTBOUND_FREE_HEAD )); _clean_exit: -mutex_unlock (&mgr->msg_lock); -return err; }
@@ -258,7 +255,9 @@ int snd_mixart_send_msg(struct mixart_mg resp.data = resp_data; resp.size = max_resp_size; +mutex_lock (&mgr->msg_lock); err =get_msg (mgr, &resp, msg_frame); +mutex_unlock (&mgr->msg_lock);if ( request->message_id != resp.message_id )dev_err (&mgr->pci->dev,"RESPONSE ERROR!\n" );
Greg Kroah-Hartman
maintainerPATCH 194/252 ALSA: hda/realtek - Add supported for Lenovo ThinkPad Headset Button
In reply to Greg Kroah-HartmanFrom: Kailang Yang <[email protected]>
commit 446b8185f0c39ac3faadbcd8ac156c50f2fd4ffe upstream.
Add supported for Lenovo ThinkPad Headset Button. Thinkpad P1 Gen 3 (0x22c1)
Thinkpad X1 Extreme Gen 3 (0x22c2)
--- sound/pci/hda/patch_realtek.c | 9 +++++++++ 1 file changed, 9 insertions(+)
sound/pci/hda/patch_realtek.c +9 -0
@@ -6301,6 +6301,7 @@ enum {ALC274_FIXUP_HP_MIC ,ALC274_FIXUP_HP_HEADSET_MIC ,ALC256_FIXUP_ASUS_HPE , + ALC285_FIXUP_THINKPAD_NO_BASS_SPK_HEADSET_JACK, }; static const struct hda_fixup alc269_fixups[] = {
@@ -7705,6 +7706,12 @@ static const struct hda_fixup alc269_fix .chained = true, .chain_id =ALC294_FIXUP_ASUS_HEADSET_MIC }, + [ALC285_FIXUP_THINKPAD_NO_BASS_SPK_HEADSET_JACK] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc_fixup_headset_jack, + .chained = true, + .chain_id =ALC269_FIXUP_THINKPAD_ACPI + }, };static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7966,6 +7973,8 @@ static const struct snd_pci_quirk alc269SND_PCI_QUIRK (0x17aa ,0x225d ,"Thinkpad T480" ,ALC269_FIXUP_LIMIT_INT_MIC_BOOST ),SND_PCI_QUIRK (0x17aa ,0x2292 ,"Thinkpad X1 Carbon 7th" ,ALC285_FIXUP_THINKPAD_HEADSET_JACK ),SND_PCI_QUIRK (0x17aa ,0x22be ,"Thinkpad X1 Carbon 8th" ,ALC285_FIXUP_THINKPAD_HEADSET_JACK ), +SND_PCI_QUIRK (0x17aa ,0x22c1 ,"Thinkpad P1 Gen 3" ,ALC285_FIXUP_THINKPAD_NO_BASS_SPK_HEADSET_JACK ), +SND_PCI_QUIRK (0x17aa ,0x22c2 ,"Thinkpad X1 Extreme Gen 3" ,ALC285_FIXUP_THINKPAD_NO_BASS_SPK_HEADSET_JACK ),SND_PCI_QUIRK (0x17aa ,0x30bb ,"ThinkCentre AIO" ,ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY ),SND_PCI_QUIRK (0x17aa ,0x30e2 ,"ThinkCentre AIO" ,ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY ), SND_PCI_QUIRK(0x17aa, 0x310c, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION),
Greg Kroah-Hartman
maintainerPATCH 195/252 ALSA: hda/realtek - Add supported mute Led for HP
In reply to Greg Kroah-HartmanFrom: Kailang Yang <[email protected]>
commit a0ccbc5319d57b9efdc55c943a3fde30a0776502 upstream.
HP Pavilion x360 Convertible machine, it supported mute led. GPIO4 high will turn on led.
The patch will enable control led via GPIO4 pin.
--- sound/pci/hda/patch_realtek.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
sound/pci/hda/patch_realtek.c +13 -0
@@ -4216,6 +4216,12 @@ static void alc286_fixup_hp_gpio_led(stralc_fixup_hp_gpio_led (codec, action,0x02 ,0x20 ); } +static void alc287_fixup_hp_gpio_led (struct hda_codec *codec, +const struct hda_fixup *fix,int action) +{ +alc_fixup_hp_gpio_led (codec, action,0x10 ,0 ); +} +/* turn on/off mic-mute LED per capture hook via VREF change */ static int vref_micmute_led_set (struct led_classdev *led_cdev,enum led_brightness brightness)
@@ -6302,6 +6308,7 @@ enum {ALC274_FIXUP_HP_HEADSET_MIC ,ALC256_FIXUP_ASUS_HPE ,ALC285_FIXUP_THINKPAD_NO_BASS_SPK_HEADSET_JACK , + ALC287_FIXUP_HP_GPIO_LED, }; static const struct hda_fixup alc269_fixups[] = {
@@ -7712,6 +7719,10 @@ static const struct hda_fixup alc269_fix .chained = true, .chain_id =ALC269_FIXUP_THINKPAD_ACPI }, + [ALC287_FIXUP_HP_GPIO_LED] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc287_fixup_hp_gpio_led, + }, };static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7866,6 +7877,8 @@ static const struct snd_pci_quirk alc269SND_PCI_QUIRK (0x103c ,0x8760 ,"HP" ,ALC285_FIXUP_HP_MUTE_LED ),SND_PCI_QUIRK (0x103c ,0x877a ,"HP" ,ALC285_FIXUP_HP_MUTE_LED ),SND_PCI_QUIRK (0x103c ,0x877d ,"HP" ,ALC236_FIXUP_HP_MUTE_LED ), +SND_PCI_QUIRK (0x103c ,0x87f4 ,"HP" ,ALC287_FIXUP_HP_GPIO_LED ), +SND_PCI_QUIRK (0x103c ,0x87f5 ,"HP" ,ALC287_FIXUP_HP_GPIO_LED ),SND_PCI_QUIRK (0x1043 ,0x103e ,"ASUS X540SA" ,ALC256_FIXUP_ASUS_MIC ),SND_PCI_QUIRK (0x1043 ,0x103f ,"ASUS TX300" ,ALC282_FIXUP_ASUS_TX300 ), SND_PCI_QUIRK(0x1043, 0x106d, "Asus K53BE", ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
Greg Kroah-Hartman
maintainerPATCH 196/252 ALSA: hda/realtek: Add some Clove SSID in the ALC293(ALC1220)
In reply to Greg Kroah-HartmanFrom: PeiSen Hou <[email protected]>
commit b5acfe152abaa2721c9ca8aa67f941d7de55d24e upstream.
Fix "use as headset mic, without its own jack detect" problem.
[ Minor coding style fixes by tiwai ]
--- sound/pci/hda/patch_realtek.c | 50 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 49 insertions(+), 1 deletion(-)
sound/pci/hda/patch_realtek.c +49 -1
@@ -2522,13 +2522,23 @@ static const struct snd_pci_quirk alc882SND_PCI_QUIRK_VENDOR (0x1462 ,"MSI" ,ALC882_FIXUP_GPIO3 ),SND_PCI_QUIRK (0x147b ,0x107a ,"Abit AW9D-MAX" ,ALC882_FIXUP_ABIT_AW9D_MAX ),SND_PCI_QUIRK (0x1558 ,0x9501 ,"Clevo P950HR" ,ALC1220_FIXUP_CLEVO_P950 ), +SND_PCI_QUIRK (0x1558 ,0x9506 ,"Clevo P955HQ" ,ALC1220_FIXUP_CLEVO_P950 ), +SND_PCI_QUIRK (0x1558 ,0x950A ,"Clevo P955H[PR]" ,ALC1220_FIXUP_CLEVO_P950 ),SND_PCI_QUIRK (0x1558 ,0x95e1 ,"Clevo P95xER" ,ALC1220_FIXUP_CLEVO_P950 ),SND_PCI_QUIRK (0x1558 ,0x95e2 ,"Clevo P950ER" ,ALC1220_FIXUP_CLEVO_P950 ), +SND_PCI_QUIRK (0x1558 ,0x95e3 ,"Clevo P955[ER]T" ,ALC1220_FIXUP_CLEVO_P950 ), +SND_PCI_QUIRK (0x1558 ,0x95e4 ,"Clevo P955ER" ,ALC1220_FIXUP_CLEVO_P950 ), +SND_PCI_QUIRK (0x1558 ,0x95e5 ,"Clevo P955EE6" ,ALC1220_FIXUP_CLEVO_P950 ), +SND_PCI_QUIRK (0x1558 ,0x95e6 ,"Clevo P950R[CDF]" ,ALC1220_FIXUP_CLEVO_P950 ),SND_PCI_QUIRK (0x1558 ,0x96e1 ,"Clevo P960[ER][CDFN]-K" ,ALC1220_FIXUP_CLEVO_P950 ),SND_PCI_QUIRK (0x1558 ,0x97e1 ,"Clevo P970[ER][CDFN]" ,ALC1220_FIXUP_CLEVO_P950 ), +SND_PCI_QUIRK (0x1558 ,0x97e2 ,"Clevo P970RC-M" ,ALC1220_FIXUP_CLEVO_P950 ), +SND_PCI_QUIRK (0x1558 ,0x50d3 ,"Clevo PC50[ER][CDF]" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ),SND_PCI_QUIRK (0x1558 ,0x65d1 ,"Clevo PB51[ER][CDF]" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ), +SND_PCI_QUIRK (0x1558 ,0x65d2 ,"Clevo PB51R[CDF]" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ), +SND_PCI_QUIRK (0x1558 ,0x65e1 ,"Clevo PB51[ED][DF]" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ),SND_PCI_QUIRK (0x1558 ,0x67d1 ,"Clevo PB71[ER][CDF]" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ), -SND_PCI_QUIRK (0x1558 ,0x50d3 ,"Clevo PC50[ER][CDF]" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ), +SND_PCI_QUIRK (0x1558 ,0x67e1 ,"Clevo PB71[DE][CDF]" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ),SND_PCI_QUIRK (0x1558 ,0x70d1 ,"Clevo PC70[ER][CDF]" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ),SND_PCI_QUIRK (0x1558 ,0x7714 ,"Clevo X170" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ), SND_PCI_QUIRK_VENDOR(0x1558, "Clevo laptop", ALC882_FIXUP_EAPD),
@@ -7944,11 +7954,49 @@ static const struct snd_pci_quirk alc269SND_PCI_QUIRK (0x1458 ,0xfa53 ,"Gigabyte BXBT-2807" ,ALC283_FIXUP_HEADSET_MIC ),SND_PCI_QUIRK (0x1462 ,0xb120 ,"MSI Cubi MS-B120" ,ALC283_FIXUP_HEADSET_MIC ),SND_PCI_QUIRK (0x1462 ,0xb171 ,"Cubi N 8GL (MS-B171)" ,ALC283_FIXUP_HEADSET_MIC ), +SND_PCI_QUIRK (0x1558 ,0x1323 ,"Clevo N130ZU" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ),SND_PCI_QUIRK (0x1558 ,0x1325 ,"System76 Darter Pro (darp5)" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x1401 ,"Clevo L140[CZ]U" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x1403 ,"Clevo N140CU" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x1404 ,"Clevo N150CU" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x14a1 ,"Clevo L141MU" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x4018 ,"Clevo NV40M[BE]" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x4019 ,"Clevo NV40MZ" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x4020 ,"Clevo NV40MB" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x40a1 ,"Clevo NL40GU" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x40c1 ,"Clevo NL40[CZ]U" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x40d1 ,"Clevo NL41DU" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x50a3 ,"Clevo NJ51GU" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x50b3 ,"Clevo NK50S[BEZ]" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x50b6 ,"Clevo NK50S5" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x50b8 ,"Clevo NK50SZ" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x50d5 ,"Clevo NP50D5" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x50f0 ,"Clevo NH50A[CDF]" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x50f3 ,"Clevo NH58DPQ" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x5101 ,"Clevo S510WU" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x5157 ,"Clevo W517GU1" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x51a1 ,"Clevo NS50MU" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x70a1 ,"Clevo NB70T[HJK]" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x70b3 ,"Clevo NK70SB" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x8228 ,"Clevo NR40BU" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x8520 ,"Clevo NH50D[CD]" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x8521 ,"Clevo NH77D[CD]" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x8535 ,"Clevo NH50D[BE]" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x8536 ,"Clevo NH79D[BE]" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ),SND_PCI_QUIRK (0x1558 ,0x8550 ,"System76 Gazelle (gaze14)" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ),SND_PCI_QUIRK (0x1558 ,0x8551 ,"System76 Gazelle (gaze14)" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ),SND_PCI_QUIRK (0x1558 ,0x8560 ,"System76 Gazelle (gaze14)" ,ALC269_FIXUP_HEADSET_MIC ),SND_PCI_QUIRK (0x1558 ,0x8561 ,"System76 Gazelle (gaze14)" ,ALC269_FIXUP_HEADSET_MIC ), +SND_PCI_QUIRK (0x1558 ,0x8668 ,"Clevo NP50B[BE]" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x8680 ,"Clevo NJ50LU" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x8686 ,"Clevo NH50[CZ]U" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x8a20 ,"Clevo NH55DCQ-Y" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x8a51 ,"Clevo NH70RCQ-Y" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x8d50 ,"Clevo NH55RCQ-M" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x951d ,"Clevo N950T[CDF]" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x961d ,"Clevo N960S[CDF]" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0x971d ,"Clevo N970T[CDF]" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1558 ,0xa500 ,"Clevo NL53RU" ,ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE ),SND_PCI_QUIRK (0x17aa ,0x1036 ,"Lenovo P520" ,ALC233_FIXUP_LENOVO_MULTI_CODECS ),SND_PCI_QUIRK (0x17aa ,0x1048 ,"ThinkCentre Station" ,ALC283_FIXUP_HEADSET_MIC ), SND_PCI_QUIRK(0x17aa, 0x20f2, "Thinkpad SL410/510", ALC269_FIXUP_SKU_IGNORE),
Greg Kroah-Hartman
maintainerPATCH 197/252 ALSA: hda/realtek - HP Headset Mic cant detect after boot
In reply to Greg Kroah-HartmanFrom: Kailang Yang <[email protected]>
commit 9e885770277d2ed8d85f9cbd4992515ec324242f upstream.
System boot or warm boot with plugged headset. If it turn on power save mode, Headset Mic will lose. This patch will solve this issue.
--- sound/pci/hda/patch_realtek.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
sound/pci/hda/patch_realtek.c +13 -0
@@ -6319,6 +6319,7 @@ enum {ALC256_FIXUP_ASUS_HPE ,ALC285_FIXUP_THINKPAD_NO_BASS_SPK_HEADSET_JACK ,ALC287_FIXUP_HP_GPIO_LED , + ALC256_FIXUP_HP_HEADSET_MIC, }; static const struct hda_fixup alc269_fixups[] = {
@@ -7733,6 +7734,10 @@ static const struct hda_fixup alc269_fix .type = HDA_FIXUP_FUNC, .v.func = alc287_fixup_hp_gpio_led, }, + [ALC256_FIXUP_HP_HEADSET_MIC] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc274_fixup_hp_headset_mic, + }, }; static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -8348,6 +8353,10 @@ static const struct snd_hda_pin_quirk al {0x19, 0x02a11020}, {0x1a, 0x02a11030}, {0x21, 0x0221101f}), +SND_HDA_PIN_QUIRK (0x10ec0236 ,0x103c ,"HP" ,ALC256_FIXUP_HP_HEADSET_MIC , + {0x14, 0x90170110}, + {0x19, 0x02a11020}, + {0x21, 0x02211030}),SND_HDA_PIN_QUIRK (0x10ec0255 ,0x1028 ,"Dell" ,ALC255_FIXUP_DELL2_MIC_NO_PRESENCE , {0x14, 0x90170110}, {0x21, 0x02211020}),
@@ -8450,6 +8459,10 @@ static const struct snd_hda_pin_quirk al {0x1a, 0x90a70130}, {0x1b, 0x90170110}, {0x21, 0x03211020}), + SND_HDA_PIN_QUIRK(0x10ec0256, 0x103c, "HP", ALC256_FIXUP_HP_HEADSET_MIC, + {0x14, 0x90170110}, + {0x19, 0x02a11020}, + {0x21, 0x0221101f}), SND_HDA_PIN_QUIRK(0x10ec0274, 0x103c, "HP", ALC274_FIXUP_HP_HEADSET_MIC, {0x17, 0x90170110}, {0x19, 0x03a11030},
Greg Kroah-Hartman
maintainerPATCH 198/252 tty: serial: imx: fix potential deadlock
In reply to Greg Kroah-HartmanFrom: Sam Nobs <[email protected]>
commit 33f16855dcb973f745c51882d0e286601ff3be2b upstream.
Enabling the lock dependency validator has revealed that the way spinlocks are used in the IMX serial port could result in a deadlock.
Specifically, imx_uart_int() acquires a spinlock without disabling the interrupts, meaning that another interrupt could come along and try to acquire the same spinlock, potentially causing the two to wait for each other indefinitely.
Use spin_lock_irqsave() instead to disable interrupts upon acquisition of the spinlock.
--- drivers/tty/serial/imx.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/tty/serial/imx.c +8 -2
@@ -942,8 +942,14 @@ static irqreturn_t imx_uart_int(int irq,struct imx_port *sport = dev_id;unsigned int usr1, usr2, ucr1, ucr2, ucr3, ucr4;irqreturn_t ret =IRQ_NONE ; +unsigned long flags =0 ; -spin_lock (&sport->port.lock); +/* +* IRQs might not be disabled upon entering this interrupt handler, +* e.g. when interrupt handlers are forced to be threaded. To support +* this scenario as well, disable IRQs when acquiring the spinlock. +*/ +spin_lock_irqsave (&sport->port.lock, flags); usr1 =imx_uart_readl (sport,USR1 ); usr2 =imx_uart_readl (sport,USR2 );
@@ -1013,7 +1019,7 @@ static irqreturn_t imx_uart_int(int irq, ret =IRQ_HANDLED ; } -spin_unlock (&sport->port.lock); +spin_unlock_irqrestore (&sport->port.lock, flags);return ret; }
Greg Kroah-Hartman
maintainerPATCH 199/252 tty: serial: imx: keep console clocks always on
In reply to Greg Kroah-HartmanFrom: Fugang Duan <[email protected]>
commit e67c139c488e84e7eae6c333231e791f0e89b3fb upstream.
For below code, there has chance to cause deadlock in SMP system:
Thread 1:clk_enable_lock();pr_info("debug message");clk_enable_unlock();
Thread 2:imx_uart_console_write()
clk_enable() clk_enable_lock();
Thread 1:
Acuired clk enable_lock -> printk -> console_trylock_spinning
Thread 2:console_unlock() -> imx_uart_console_write -> clk_disable -> Acquite clk enable_lock
So the patch is to keep console port clocks always on like other console drivers.
--- drivers/tty/serial/imx.c | 20 +++----------------- 1 file changed, 3 insertions(+), 17 deletions(-)
drivers/tty/serial/imx.c +3 -17
@@ -2007,16 +2007,6 @@ imx_uart_console_write(struct console *cunsigned int ucr1;unsigned long flags =0 ;int locked =1 ; -int retval; - - retval =clk_enable (sport->clk_per); -if (retval) -return ; - retval =clk_enable (sport->clk_ipg); -if (retval) { -clk_disable (sport->clk_per); -return ; - }if (sport->port.sysrq) locked =0 ;
@@ -2052,9 +2042,6 @@ imx_uart_console_write(struct console *cif (locked)spin_unlock_irqrestore (&sport->port.lock, flags); - -clk_disable (sport->clk_ipg); -clk_disable (sport->clk_per); }/*
@@ -2155,15 +2142,14 @@ imx_uart_console_setup(struct console *c retval =uart_set_options (&sport->port, co, baud, parity, bits, flow); -clk_disable (sport->clk_ipg);if (retval) { -clk_unprepare (sport->clk_ipg); +clk_disable_unprepare (sport->clk_ipg); goto error_console; } - retval =clk_prepare (sport->clk_per); + retval =clk_prepare_enable (sport->clk_per);if (retval) -clk_unprepare (sport->clk_ipg); +clk_disable_unprepare (sport->clk_ipg); error_console:return retval;
Greg Kroah-Hartman
maintainerPATCH 200/252 HID: logitech-dj: Fix an error in mse_bluetooth_descriptor
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
commit eec231e060fb79923c349f6e89f022b286f32c1e upstream.
Fix an error in the mouse / INPUT(2) descriptor used for quad/bt2.0 combo receivers. Replace INPUT with INPUT (Data,Var,Abs) for the field for the 4 extra buttons which share their report-byte with the low-res hwheel.
This is likely a copy and paste error. I've verified that the new 0x81, 0x02 value matches both the mouse descriptor for the currently supported MX5000 / MX5500 receivers, as well as the INPUT(2) mouse descriptors for the Dinovo receivers for which support is being worked on.
--- drivers/hid/hid-logitech-dj.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hid/hid-logitech-dj.c +1 -1
@@ -328,7 +328,7 @@ static const char mse_bluetooth_descript0x25 ,0x01 ,/* LOGICAL_MAX (1) */ 0x75 ,0x01 ,/* REPORT_SIZE (1) */ 0x95 ,0x04 ,/* REPORT_COUNT (4) */ -0x81 ,0x06 ,/* INPUT */ +0x81 ,0x02 ,/* INPUT (Data,Var,Abs) */ 0xC0 ,/* END_COLLECTION */ 0xC0, /* END_COLLECTION */ };
Greg Kroah-Hartman
maintainerPATCH 201/252 efivarfs: fix memory leak in efivarfs_create()
In reply to Greg Kroah-HartmanFrom: Vamshi K Sthambamkadi <[email protected]>
commit fe5186cf12e30facfe261e9be6c7904a170bd822 upstream.
kmemleak report:
unreferenced object 0xffff9b8915fcb000 (size 4096):
comm "efivarfs.sh", pid 2360, jiffies 4294920096 (age 48.264s) hex dump (first 32 bytes):
2d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -...............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000cc4d897c>] kmem_cache_alloc_trace+0x155/0x4b0
[<000000007d1dfa72>] efivarfs_create+0x6e/0x1a0
[<00000000e6ee18fc>] path_openat+0xe4b/0x1120
[<000000000ad0414f>] do_filp_open+0x91/0x100
[<00000000ce93a198>] do_sys_openat2+0x20c/0x2d0
[<000000002a91be6d>] do_sys_open+0x46/0x80
[<000000000a854999>] __x64_sys_openat+0x20/0x30
[<00000000c50d89c9>] do_syscall_64+0x38/0x90
[<00000000cecd6b5f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9In efivarfs_create(), inode->i_private is setup with efivar_entry object which is never freed.
--- fs/efivarfs/super.c | 1 + 1 file changed, 1 insertion(+)
fs/efivarfs/super.c +1 -0
@@ -21,6 +21,7 @@ LIST_HEAD(efivarfs_list);static void efivarfs_evict_inode (struct inode *inode) {clear_inode (inode); +kfree (inode->i_private); }static const struct super_operations efivarfs_ops = {
Greg Kroah-Hartman
maintainerPATCH 202/252 staging: rtl8723bs: Add 024c:0627 to the list of SDIO device-ids
In reply to Greg Kroah-HartmanFrom: Brian O'Keefe <[email protected]>
commit aee9dccc5b64e878cf1b18207436e73f66d74157 upstream.
Add 024c:0627 to the list of SDIO device-ids, based on hardware found in the wild. This hardware exists on at least some Acer SW1-011 tablets.
--- drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 1 + 1 file changed, 1 insertion(+)
drivers/staging/rtl8723bs/os_dep/sdio_intf.c +1 -0
@@ -21,6 +21,7 @@ static const struct sdio_device_id sdio_ { SDIO_DEVICE(0x024c, 0x0525), }, { SDIO_DEVICE(0x024c, 0x0623), }, { SDIO_DEVICE(0x024c, 0x0626), }, + { SDIO_DEVICE(0x024c, 0x0627), }, { SDIO_DEVICE(0x024c, 0xb723), }, { /* end: all zeroes */ }, };
Greg Kroah-Hartman
maintainerPATCH 203/252 staging: mt7621-pci: avoid to request pci bus resources
In reply to Greg Kroah-HartmanFrom: Sergio Paracuellos <[email protected]>
commit e2b2e4386cb7a5e935dff388cf8961317daf39ce upstream.
After upgrading kernel to version 5.9.x the driver was not working anymore showing the following kernel trace:
...
mt7621-pci 1e140000.pcie: resource collision:
[mem 0x60000000-0x6fffffff] conflicts with pcie@1e140000 [mem 0x60000000-0x6fffffff]
------------[ cut here ]------------
WARNING: CPU: 2 PID: 73 at kernel/resource.c:1400
devm_request_resource+0xfc/0x10c
Modules linked in:
CPU: 2 PID: 73 Comm: kworker/2:1 Not tainted 5.9.2 #0
Workqueue: events deferred_probe_work_func
Stack : 00000000 81590000 807d0a1c 808a0000 8fd49080
807d0000 00000009 808ac820
00000001 808338d0 7fff0001 800839dc 00000049
00000001 8fe51b00 367204ab
00000000 00000000 807d0a1c 807c0000 00000001
80082358 8fe50000 00559000
00000000 8fe519f1 ffffffff 00000005 00000000
00000001 00000000 807d0000
00000009 808ac820 00000001 808338d0 00000001
803bf1b0 00000008 81390008Call Trace: [<8000d018>] show_stack+0x30/0x100 [<8032e66c>] dump_stack+0xa4/0xd4 [<8002db1c>] __warn+0xc0/0x134 [<8002dbec>] warn_slowpath_fmt+0x5c/0xac [<80033b34>] devm_request_resource+0xfc/0x10c [<80365ff8>] devm_request_pci_bus_resources+0x58/0xdc [<8048e13c>] mt7621_pci_probe+0x8dc/0xe48 [<803d2140>] platform_drv_probe+0x40/0x94 [<803cfd94>] really_probe+0x108/0x4ec [<803cd958>] bus_for_each_drv+0x70/0xb0 [<803d0388>] __device_attach+0xec/0x164 [<803cec8c>] bus_probe_device+0xa4/0xc0 [<803cf1c4>] deferred_probe_work_func+0x80/0xc4 [<80048444>] process_one_work+0x260/0x510 [<80048a4c>] worker_thread+0x358/0x5cc [<8004f7d0>] kthread+0x134/0x13c [<80007478>] ret_from_kernel_thread+0x14/0x1c ---[ end trace a9dd2e37537510d3 ]---
mt7621-pci 1e140000.pcie: Error requesting resources
mt7621-pci: probe of 1e140000.pcie failed with error -16
...
With commit 669cbc708122 ("PCI: Move DT resource setup into devm_pci_alloc_host_bridge()"), the DT 'ranges' is parsed and populated into resources when the host bridge is allocated. The resources are requested as well, but that happens a 2nd time for this driver in mt7621_pcie_request_resources(). Hence we should avoid this second request.
Also, the bus ranges was also populated by default, so we can remove it from mt7621_pcie_request_resources() to avoid the following trace if we don't avoid it:
pci_bus 0000:00: busn_res: can not insert [bus 00-ff] under domain [bus 00-ff] (conflicts with (null) [bus 00-ff])
Function 'mt7621_pcie_request_resources' has been renamed into 'mt7621_pcie_add_resources' which now is a more accurate name for this function.
--- drivers/staging/mt7621-pci/pci-mt7621.c | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-)
drivers/staging/mt7621-pci/pci-mt7621.c +3 -12
@@ -653,16 +653,11 @@ static int mt7621_pcie_init_virtual_bridreturn 0 ; } -static int mt7621_pcie_request_resources (struct mt7621_pcie *pcie, -struct list_head *res) +static void mt7621_pcie_add_resources (struct mt7621_pcie *pcie, +struct list_head *res) { -struct device *dev = pcie->dev; -pci_add_resource_offset (res, &pcie->io, pcie->offset.io);pci_add_resource_offset (res, &pcie->mem, pcie->offset.mem); -pci_add_resource (res, &pcie->busn); - -return devm_request_pci_bus_resources (dev, res); } static int mt7621_pcie_register_host(struct pci_host_bridge *host,
@@ -738,11 +733,7 @@ static int mt7621_pci_probe(struct platfsetup_cm_memory_region (pcie); - err =mt7621_pcie_request_resources (pcie, &res); -if (err) { -dev_err (dev,"Error requesting resources\n" ); -return err; - } +mt7621_pcie_add_resources (pcie, &res); err =mt7621_pcie_register_host (bridge, &res);if (err) {
Greg Kroah-Hartman
maintainerPATCH 204/252 iio: light: fix kconfig dependency bug for VCNL4035
In reply to Greg Kroah-HartmanFrom: Necip Fazil Yildiran <[email protected]>
commit 44a146a44f656fc03d368c1b9248d29a128cd053 upstream.
When VCNL4035 is enabled and IIO_BUFFER is disabled, it results in the following Kbuild warning:
WARNING: unmet direct dependencies detected for IIO_TRIGGERED_BUFFER
Depends on [n]: IIO [=y] && IIO_BUFFER [=n]
Selected by [y]:
- VCNL4035 [=y] && IIO [=y] && I2C [=y]
The reason is that VCNL4035 selects IIO_TRIGGERED_BUFFER without depending on or selecting IIO_BUFFER while IIO_TRIGGERED_BUFFER depends on IIO_BUFFER. This can also fail building the kernel.
Honor the kconfig dependency to remove unmet direct dependency warnings and avoid any potential build failures.
--- drivers/iio/light/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/iio/light/Kconfig +1 -0
@@ -529,6 +529,7 @@ config VCNL4000 config VCNL4035 tristate "VCNL4035 combined ALS and proximity sensor" + select IIO_BUFFER select IIO_TRIGGERED_BUFFER select REGMAP_I2C depends on I2C
Greg Kroah-Hartman
maintainerPATCH 205/252 ext4: fix bogus warning in ext4_update_dx_flag()
In reply to Greg Kroah-HartmanFrom: Jan Kara <[email protected]>
commit f902b216501094495ff75834035656e8119c537f upstream.
The idea of the warning in ext4_update_dx_flag() is that we should warn when we are clearing EXT4_INODE_INDEX on a filesystem with metadata checksums enabled since after clearing the flag, checksums for internal htree nodes will become invalid. So there's no need to warn (or actually do anything) when EXT4_INODE_INDEX is not set.
--- fs/ext4/ext4.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/ext4/ext4.h +2 -1
@@ -2622,7 +2622,8 @@ void ext4_insert_dentry(struct inode *in struct ext4_filename *fname);static inline void ext4_update_dx_flag (struct inode *inode) { -if (!ext4_has_feature_dir_index (inode->i_sb)) { +if (!ext4_has_feature_dir_index (inode->i_sb) && +ext4_test_inode_flag (inode,EXT4_INODE_INDEX )) {/* ext4_iget() should have caught this... */ WARN_ON_ONCE (ext4_has_feature_metadata_csum (inode->i_sb));ext4_clear_inode_flag (inode,EXT4_INODE_INDEX );
Greg Kroah-Hartman
maintainerPATCH 206/252 xfs: fix forkoff miscalculation related to XFS_LITINO(mp)
In reply to Greg Kroah-HartmanFrom: Gao Xiang <[email protected]>
commit ada49d64fb3538144192181db05de17e2ffc3551 upstream.
Currently, commit e9e2eae89ddb dropped a (int) decoration from XFS_LITINO(mp), and since sizeof() expression is also involved, the result of XFS_LITINO(mp) is simply as the size_t type (commonly unsigned long).
Considering the expression in xfs_attr_shortform_bytesfit():
offset = (XFS_LITINO(mp) - bytes) >> 3;
let "bytes" be (int)340, and
"XFS_LITINO(mp)" be (unsigned long)336.
on 64-bit platform, the expression is
offset = ((unsigned long)336 - (int)340) >> 3 =
(int)(0xfffffffffffffffcUL >> 3) = -1
but on 32-bit platform, the expression is
offset = ((unsigned long)336 - (int)340) >> 3 =
(int)(0xfffffffcUL >> 3) = 0x1fffffff
instead.
so offset becomes a large positive number on 32-bit platform, and cause xfs_attr_shortform_bytesfit() returns maxforkoff rather than 0.
Therefore, one result is
"ASSERT(new_size <= XFS_IFORK_SIZE(ip, whichfork));"
assertion failure in xfs_idata_realloc(), which was also the root cause of the original bugreport from Dennis, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1894177
And it can also be manually triggered with the following commands:
$ touch a; $ setfattr -n user.0 -v "`seq 0 80`" a; $ setfattr -n user.1 -v "`seq 0 80`" a
on 32-bit platform.
Fix the case in xfs_attr_shortform_bytesfit() by bailing out "XFS_LITINO(mp) < bytes" in advance suggested by Eric and a misleading comment together with this bugfix suggested by Darrick. It seems the other users of XFS_LITINO(mp) are not impacted.
--- fs/xfs/libxfs/xfs_attr_leaf.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
fs/xfs/libxfs/xfs_attr_leaf.c +7 -1
@@ -515,7 +515,7 @@ xfs_attr_copy_value(*========================================================================*/ /* -* Query whether the requested number of additional bytes of extended +* Query whether the total requested number of attr fork bytes of extended * attribute space will be able to fit inline. * * Returns zero if not, else the di_forkoff fork offset to be used in the
@@ -535,6 +535,12 @@ xfs_attr_shortform_bytesfit(int maxforkoff;int offset; +/* +* Check if the new size could fit at all first: +*/ +if (bytes >XFS_LITINO (mp)) +return 0 ; +/* rounded down */ offset = (XFS_LITINO (mp) - bytes) >>3 ;
Greg Kroah-Hartman
maintainerPATCH 207/252 ACPI: fan: Initialize performance state sysfs attribute
In reply to Greg Kroah-HartmanFrom: Guenter Roeck <[email protected]>
commit 7dc7a8b04f3da8aa3c3be514e155e2fa094e976f upstream.
The following warning is reported if lock debugging is enabled.
DEBUG_LOCKS_WARN_ON(1)
WARNING: CPU: 1 PID: 1 at kernel/locking/lockdep.c:4617 lockdep_init_map_waits+0x141/0x222 ... Call Trace: __kernfs_create_file+0x7a/0xd8 sysfs_add_file_mode_ns+0x135/0x189 sysfs_create_file_ns+0x70/0xa0 acpi_fan_probe+0x547/0x621 platform_drv_probe+0x67/0x8b ...
Dynamically allocated sysfs attributes need to be initialized to avoid the warning.
--- drivers/acpi/fan.c | 1 + 1 file changed, 1 insertion(+)
drivers/acpi/fan.c +1 -0
@@ -351,6 +351,7 @@ static int acpi_fan_get_fps(struct acpi_struct acpi_fan_fps *fps = &fan->fps[i];snprintf (fps->name,ACPI_FPS_NAME_LEN ,"state%d" , i); +sysfs_attr_init (&fps->dev_attr.attr); fps->dev_attr.show = show_state; fps->dev_attr.store =NULL ; fps->dev_attr.attr.name = fps->name;
Greg Kroah-Hartman
maintainerPATCH 208/252 iio: accel: kxcjk1013: Replace is_smo8500_device with an acpi_type enum
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
commit 11e94f28c3de35d5ad1ac6a242a5b30f4378991a upstream.
Replace the boolean is_smo8500_device variable with an acpi_type enum.
For now this can be either ACPI_GENERIC or ACPI_SMO8500, this is a preparation patch for adding special handling for the KIOX010A ACPI HID, which will add a ACPI_KIOX010A acpi_type to the introduced enum.
For stable as needed as precursor for next patch.
--- drivers/iio/accel/kxcjk-1013.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)
drivers/iio/accel/kxcjk-1013.c +10 -5
@@ -126,6 +126,11 @@ enum kx_chipset {KX_MAX_CHIPS /* this must be last */ }; +enum kx_acpi_type { +ACPI_GENERIC , +ACPI_SMO8500 , +}; +struct kxcjk1013_data {struct i2c_client *client;struct iio_trigger *dready_trig;
@@ -143,7 +148,7 @@ struct kxcjk1013_data {bool motion_trigger_on;int64_t timestamp;enum kx_chipset chipset; -bool is_smo8500_device; +enum kx_acpi_type acpi_type; };enum kxcjk1013_axis {
@@ -1247,7 +1252,7 @@ static irqreturn_t kxcjk1013_data_rdy_trstatic const char *kxcjk1013_match_acpi_device (struct device *dev,enum kx_chipset *chipset, -bool *is_smo8500_device) +enum kx_acpi_type *acpi_type) {const struct acpi_device_id *id;
@@ -1256,7 +1261,7 @@ static const char *kxcjk1013_match_acpi_return NULL ;if (strcmp (id->id,"SMO8500" ) ==0 ) - *is_smo8500_device = true; + *acpi_type =ACPI_SMO8500 ; *chipset = (enum kx_chipset )id->driver_data;
@@ -1299,7 +1304,7 @@ static int kxcjk1013_probe(struct i2c_cl }else if (ACPI_HANDLE (&client->dev)) { name =kxcjk1013_match_acpi_device (&client->dev, &data->chipset, - &data->is_smo8500_device); + &data->acpi_type); }else return -ENODEV ;
@@ -1316,7 +1321,7 @@ static int kxcjk1013_probe(struct i2c_cl indio_dev->modes =INDIO_DIRECT_MODE ; indio_dev->info = &kxcjk1013_info; -if (client->irq >0 && !data->is_smo8500_device) { +if (client->irq >0 && data->acpi_type !=ACPI_SMO8500 ) { ret = devm_request_threaded_irq(&client->dev, client->irq, kxcjk1013_data_rdy_trig_poll, kxcjk1013_event_handler,
Greg Kroah-Hartman
maintainerPATCH 209/252 iio: accel: kxcjk1013: Add support for KIOX010A ACPI DSM for setting tablet-mode
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
commit e5b1032a656e9aa4c7a4df77cb9156a2a651a5f9 upstream.
Some 360 degree hinges (yoga) style 2-in-1 devices use 2 KXCJ91008-s to allow the OS to determine the angle between the display and the base of the device, so that the OS can determine if the 2-in-1 is in laptop or in tablet-mode.
On Windows both accelerometers are read by a special HingeAngleService process; and this process calls a DSM (Device Specific Method) on the ACPI KIOX010A device node for the sensor in the display, to let the embedded-controller (EC) know about the mode so that it can disable the kbd and touchpad to avoid spurious input while folded into tablet-mode.
This notifying of the EC is problematic because sometimes the EC comes up thinking that device is in tablet-mode and the kbd and touchpad do not work. This happens for example on Irbis NB111 devices after a suspend / resume cycle (after a complete battery drain / hard reset without having booted Windows at least once). Other 2-in-1s which are likely affected too are e.g. the Teclast F5 and F6 series.
The kxcjk-1013 driver may seem like a strange place to deal with this, but since it is *the* driver for the ACPI KIOX010A device, it is also the driver which has access to the ACPI handle needed by the DSM.
Add support for calling the DSM and on probe unconditionally tell the EC that the device is laptop mode, fixing the kbd and touchpad sometimes not working.
--- drivers/iio/accel/kxcjk-1013.c | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+)
drivers/iio/accel/kxcjk-1013.c +36 -0
@@ -129,6 +129,7 @@ enum kx_chipset {enum kx_acpi_type {ACPI_GENERIC ,ACPI_SMO8500 , +ACPI_KIOX010A , };struct kxcjk1013_data {
@@ -275,6 +276,32 @@ static const struct { {19163, 1, 0}, {38326, 0, 1} }; +#ifdef CONFIG_ACPI +enum kiox010a_fn_index { +KIOX010A_SET_LAPTOP_MODE =1 , +KIOX010A_SET_TABLET_MODE =2 , +}; + +static int kiox010a_dsm (struct device *dev,int fn_index) +{ +acpi_handle handle =ACPI_HANDLE (dev); +guid_t kiox010a_dsm_guid; +union acpi_object *obj; + +if (!handle) +return -ENODEV ; + +guid_parse ("1f339696-d475-4e26-8cad-2e9f8e6d7a91" , &kiox010a_dsm_guid); + + obj =acpi_evaluate_dsm (handle, &kiox010a_dsm_guid,1 , fn_index,NULL ); +if (!obj) +return -EIO ; + +ACPI_FREE (obj); +return 0 ; +} +#endif +static int kxcjk1013_set_mode (struct kxcjk1013_data *data,enum kxcjk1013_mode mode) {
@@ -352,6 +379,13 @@ static int kxcjk1013_chip_init(struct kx {int ret; +#ifdef CONFIG_ACPI +if (data->acpi_type ==ACPI_KIOX010A ) { +/* Make sure the kbd and touchpad on 2-in-1s using 2 KXCJ91008-s work */ +kiox010a_dsm (&data->client->dev,KIOX010A_SET_LAPTOP_MODE ); + } +#endif + ret =i2c_smbus_read_byte_data (data->client,KXCJK1013_REG_WHO_AM_I );if (ret <0 ) {dev_err (&data->client->dev,"Error reading who_am_i\n" );
@@ -1262,6 +1296,8 @@ static const char *kxcjk1013_match_acpi_if (strcmp (id->id,"SMO8500" ) ==0 ) *acpi_type =ACPI_SMO8500 ; +else if (strcmp (id->id,"KIOX010A" ) ==0 ) + *acpi_type =ACPI_KIOX010A ; *chipset = (enum kx_chipset )id->driver_data;
Greg Kroah-Hartman
maintainerPATCH 210/252 iio: adc: mediatek: fix unset field
In reply to Greg Kroah-HartmanFrom: Fabien Parent <[email protected]>
commit 15207a92e019803d62687455d8aa2ff9eb3dc82c upstream.
dev_comp field is used in a couple of places but it is never set. This results in kernel oops when dereferencing a NULL pointer. Set the dev_comp field correctly in the probe function.
--- drivers/iio/adc/mt6577_auxadc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/iio/adc/mt6577_auxadc.c +4 -2
@@ -9,9 +9,9 @@#include <linux/err.h> #include <linux/kernel.h> #include <linux/module.h> -#include <linux/of.h> -#include <linux/of_device.h> +#include <linux/mod_devicetable.h> #include <linux/platform_device.h> +#include <linux/property.h> #include <linux/iopoll.h> #include <linux/io.h> #include <linux/iio/iio.h>
@@ -276,6 +276,8 @@ static int mt6577_auxadc_probe(struct pl goto err_disable_clk; } + adc_dev->dev_comp =device_get_match_data (&pdev->dev); +mutex_init (&adc_dev->lock); mt6577_auxadc_mod_reg(adc_dev->reg_base + MT6577_AUXADC_MISC,
Greg Kroah-Hartman
maintainerPATCH 211/252 iio: cros_ec: Use default frequencies when EC returns invalid information
In reply to Greg Kroah-HartmanFrom: Gwendal Grignou <[email protected]>
commit 56e4f2dda23c6d39d327944faa89efaa4eb290d1 upstream.
Minimal and maximal frequencies supported by a sensor is queried. On some older machines, these frequencies are not returned properly and the EC returns 0 instead.
When returned maximal frequency is 0, ignore the information and use default frequencies instead.
--- drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c | 16 +++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-)
drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c +11 -5
@@ -255,7 +255,7 @@ int cros_ec_sensors_core_init(struct plastruct cros_ec_sensorhub *sensor_hub =dev_get_drvdata (dev->parent);struct cros_ec_dev *ec = sensor_hub->ec;struct cros_ec_sensor_platform *sensor_platform =dev_get_platdata (dev); -u32 ver_mask; +u32 ver_mask, temp;int frequencies[ARRAY_SIZE (state->frequencies) /2 ] = {0 };int ret, i;
@@ -310,10 +310,16 @@ int cros_ec_sensors_core_init(struct pla &frequencies[2 ], &state->fifo_max_event_count); }else { - frequencies[1 ] = state->resp->info_3.min_frequency; - frequencies[2 ] = state->resp->info_3.max_frequency; - state->fifo_max_event_count = - state->resp->info_3.fifo_max_event_count; +if (state->resp->info_3.max_frequency ==0 ) { +get_default_min_max_freq (state->resp->info.type, + &frequencies[1 ], + &frequencies[2 ], + &temp); + }else { + frequencies[1 ] = state->resp->info_3.min_frequency; + frequencies[2 ] = state->resp->info_3.max_frequency; + } + state->fifo_max_event_count = state->resp->info_3.fifo_max_event_count; }for (i =0 ; i <ARRAY_SIZE (frequencies); i++) { state->frequencies[2 * i] = frequencies[i] /1000 ;
Greg Kroah-Hartman
maintainerPATCH 212/252 iio: imu: st_lsm6dsx: set 10ms as min shub slave timeout
In reply to Greg Kroah-HartmanFrom: Lorenzo Bianconi <[email protected]>
commit fe0b980ffd1dd8b10c09f82385514819ba2a661d upstream.
Set 10ms as minimum i2c slave configuration timeout since st_lsm6dsx relies on accel ODR for i2c master clock and at high sample rates (e.g. 833Hz or 416Hz) the slave sensor occasionally may need more cycles than i2c master timeout (2s/833Hz + 1 ~ 3ms) to apply the configuration resulting in an uncomplete slave configuration and a constant reading from the i2c slave connected to st_lsm6dsx i2c master.
--- drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c +4 -2
@@ -156,11 +156,13 @@ static const struct st_lsm6dsx_ext_dev_sstatic void st_lsm6dsx_shub_wait_complete (struct st_lsm6dsx_hw *hw) {struct st_lsm6dsx_sensor *sensor; -u32 odr; +u32 odr, timeout; sensor =iio_priv (hw->iio_devs[ST_LSM6DSX_ID_ACC ]); odr = (hw->enable_mask &BIT (ST_LSM6DSX_ID_ACC )) ? sensor->odr :12500 ; -msleep ((2000000U / odr) +1 ); +/* set 10ms as minimum timeout for i2c slave configuration */ + timeout =max_t (u32,2000000U / odr +1 ,10 ); +msleep (timeout); }/*
Greg Kroah-Hartman
maintainerPATCH 213/252 iio/adc: ingenic: Fix AUX/VBAT readings when touchscreen is used
In reply to Greg Kroah-HartmanFrom: Paul Cercueil <[email protected]>
commit 6d6aa2907d59ddd3c0ebb2b93e1ddc84e474485b upstream.
When the command feature of the ADC is used, it is possible to program the ADC, and specify at each step what input should be processed, and in comparison to what reference.
This broke the AUX and battery readings when the touchscreen was enabled, most likely because the CMD feature would change the VREF all the time.
Now, when AUX or battery are read, we temporarily disable the CMD feature, which means that we won't get touchscreen readings in that time frame. But it now gives correct values for AUX / battery, and the touchscreen isn't disabled for long enough to be an actual issue.
--- drivers/iio/adc/ingenic-adc.c | 32 ++++++++++++++++++++++++++------ 1 file changed, 26 insertions(+), 6 deletions(-)
drivers/iio/adc/ingenic-adc.c +26 -6
@@ -177,13 +177,12 @@ static void ingenic_adc_set_config(strucmutex_unlock (&adc->lock); } -static void ingenic_adc_enable (struct ingenic_adc *adc, -int engine, -bool enabled) +static void ingenic_adc_enable_unlocked (struct ingenic_adc *adc, +int engine, +bool enabled) {u8 val; -mutex_lock (&adc->lock); val =readb (adc->base +JZ_ADC_REG_ENABLE );if (enabled)
@@ -192,20 +191,41 @@ static void ingenic_adc_enable(struct in val &= ~BIT (engine);writeb (val, adc->base +JZ_ADC_REG_ENABLE ); +} + +static void ingenic_adc_enable (struct ingenic_adc *adc, +int engine, +bool enabled) +{ +mutex_lock (&adc->lock); +ingenic_adc_enable_unlocked (adc, engine, enabled);mutex_unlock (&adc->lock); }static int ingenic_adc_capture (struct ingenic_adc *adc,int engine) { +u32 cfg;u8 val;int ret; -ingenic_adc_enable (adc, engine, true); +/* +* Disable CMD_SEL temporarily, because it causes wrong VBAT readings, +* probably due to the switch of VREF. We must keep the lock here to +* avoid races with the buffer enable/disable functions. +*/ +mutex_lock (&adc->lock); + cfg =readl (adc->base +JZ_ADC_REG_CFG ); +writel (cfg & ~JZ_ADC_REG_CFG_CMD_SEL , adc->base +JZ_ADC_REG_CFG ); + +ingenic_adc_enable_unlocked (adc, engine, true); ret =readb_poll_timeout (adc->base +JZ_ADC_REG_ENABLE , val, !(val &BIT (engine)),250 ,1000 );if (ret) -ingenic_adc_enable (adc, engine, false); +ingenic_adc_enable_unlocked (adc, engine, false); + +writel (cfg, adc->base +JZ_ADC_REG_CFG ); +mutex_unlock (&adc->lock);return ret; }
Greg Kroah-Hartman
maintainerPATCH 214/252 iio/adc: ingenic: Fix battery VREF for JZ4770 SoC
In reply to Greg Kroah-HartmanFrom: Paul Cercueil <[email protected]>
commit c91ebcc578e09783cfa4d85c1b437790f140f29a upstream.
The reference voltage for the battery is clearly marked as 1.2V in the programming manual. With this fixed, the battery channel now returns correct values.
--- drivers/iio/adc/ingenic-adc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/adc/ingenic-adc.c +1 -1
@@ -71,7 +71,7 @@#define JZ4725B_ADC_BATTERY_HIGH_VREF_BITS 10#define JZ4740_ADC_BATTERY_HIGH_VREF (7500 * 0.986)#define JZ4740_ADC_BATTERY_HIGH_VREF_BITS 12 -#define JZ4770_ADC_BATTERY_VREF 6600 +#define JZ4770_ADC_BATTERY_VREF 1200#define JZ4770_ADC_BATTERY_VREF_BITS 12#define JZ_ADC_IRQ_AUX BIT(0)
Greg Kroah-Hartman
maintainerPATCH 215/252 iio: adc: stm32-adc: fix a regression when using dma and irq
In reply to Greg Kroah-HartmanFrom: Olivier Moysan <[email protected]>
commit 695e2f5c289bb7f8b85351dcfa35fa236e0200a4 upstream.
Since overrun interrupt support has been added, there's a regression when two ADCs are used at the same time, with:
- an ADC configured to use IRQs. EOCIE bit is set. The handler is normally called in this case.
- an ADC configured to use DMA. EOCIE bit isn't set. EOC triggers the DMA request. It's then automatically cleared by DMA read. But the handler gets called due to status bit is temporarily set (IRQ triggered by the other ADC).
This is a regression as similar issue had been fixed earlier by commit dcb10920179a ("iio: adc: stm32-adc:
fix a race when using several adcs with dma and irq"). Issue is that stm32_adc_eoc_enabled() returns non-zero value (always) since OVR bit has been added and enabled for both DMA and IRQ case.
Remove OVR mask in IER register, and rely only on CSR status for overrun. To avoid subsequent calls to interrupt routine on overrun, CSR OVR bit has to be cleared. CSR OVR bit cannot be cleared directly by software. To do this ADC must be stopped first, and OVR bit in ADC ISR has to be cleared.
Also add a check in ADC IRQ handler to report spurious IRQs.
--- drivers/iio/adc/stm32-adc-core.c | 41 +++++++++++++------------------ drivers/iio/adc/stm32-adc.c | 50 +++++++++++++++++++++++++++++++++++++-- 2 files changed, 65 insertions(+), 26 deletions(-)
drivers/iio/adc/stm32-adc-core.c +17 -24
@@ -41,18 +41,16 @@* struct stm32_adc_common_regs - stm32 common registers * @csr: common status register offset * @ccr: common control register offset -* @eoc1_msk: adc1 end of conversion flag in @csr -* @eoc2_msk: adc2 end of conversion flag in @csr -* @eoc3_msk: adc3 end of conversion flag in @csr +* @eoc_msk: array of eoc (end of conversion flag) masks in csr for adc1..n +* @ovr_msk: array of ovr (overrun flag) masks in csr for adc1..n * @ier: interrupt enable register offset for each adc * @eocie_msk: end of conversion interrupt enable mask in @ier */ struct stm32_adc_common_regs {u32 csr;u32 ccr; -u32 eoc1_msk; -u32 eoc2_msk; -u32 eoc3_msk; +u32 eoc_msk[STM32_ADC_MAX_ADCS ]; +u32 ovr_msk[STM32_ADC_MAX_ADCS ];u32 ier;u32 eocie_msk; };
@@ -282,21 +280,20 @@ out:static const struct stm32_adc_common_regs stm32f4_adc_common_regs = { .csr =STM32F4_ADC_CSR , .ccr =STM32F4_ADC_CCR , - .eoc1_msk =STM32F4_EOC1 |STM32F4_OVR1 , - .eoc2_msk =STM32F4_EOC2 |STM32F4_OVR2 , - .eoc3_msk =STM32F4_EOC3 |STM32F4_OVR3 , + .eoc_msk = {STM32F4_EOC1 ,STM32F4_EOC2 ,STM32F4_EOC3 }, + .ovr_msk = {STM32F4_OVR1 ,STM32F4_OVR2 ,STM32F4_OVR3 }, .ier =STM32F4_ADC_CR1 , - .eocie_msk =STM32F4_EOCIE |STM32F4_OVRIE , + .eocie_msk =STM32F4_EOCIE , };/* STM32H7 common registers definitions */ static const struct stm32_adc_common_regs stm32h7_adc_common_regs = { .csr =STM32H7_ADC_CSR , .ccr =STM32H7_ADC_CCR , - .eoc1_msk =STM32H7_EOC_MST |STM32H7_OVR_MST , - .eoc2_msk =STM32H7_EOC_SLV |STM32H7_OVR_SLV , + .eoc_msk = {STM32H7_EOC_MST ,STM32H7_EOC_SLV }, + .ovr_msk = {STM32H7_OVR_MST ,STM32H7_OVR_SLV }, .ier =STM32H7_ADC_IER , - .eocie_msk =STM32H7_EOCIE |STM32H7_OVRIE , + .eocie_msk =STM32H7_EOCIE , };static const unsigned int stm32_adc_offset[STM32_ADC_MAX_ADCS ] = {
@@ -318,6 +315,7 @@ static void stm32_adc_irq_handler(struct {struct stm32_adc_priv *priv =irq_desc_get_handler_data (desc);struct irq_chip *chip =irq_desc_get_chip (desc); +int i;u32 status;chained_irq_enter (chip, desc);
@@ -335,17 +333,12 @@ static void stm32_adc_irq_handler(struct* before invoking the interrupt handler (e.g. call ISR only for * IRQ-enabled ADCs). */ -if (status & priv->cfg->regs->eoc1_msk && -stm32_adc_eoc_enabled (priv,0 )) -generic_handle_irq (irq_find_mapping (priv->domain,0 )); - -if (status & priv->cfg->regs->eoc2_msk && -stm32_adc_eoc_enabled (priv,1 )) -generic_handle_irq (irq_find_mapping (priv->domain,1 )); - -if (status & priv->cfg->regs->eoc3_msk && -stm32_adc_eoc_enabled (priv,2 )) -generic_handle_irq (irq_find_mapping (priv->domain,2 )); +for (i =0 ; i < priv->cfg->num_irqs; i++) { +if ((status & priv->cfg->regs->eoc_msk[i] && +stm32_adc_eoc_enabled (priv, i)) || + (status & priv->cfg->regs->ovr_msk[i])) +generic_handle_irq (irq_find_mapping (priv->domain, i)); + }chained_irq_exit (chip, desc); };
drivers/iio/adc/stm32-adc.c +48 -2
113 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 216/252 serial: ar933x_uart: disable clk on error handling path in probe
In reply to Greg Kroah-HartmanFrom: Zheng Zengkai <[email protected]>
commit 425af483523b76bc78e14674a430579d38b2a593 upstream.
ar933x_uart_probe() does not invoke clk_disable_unprepare() on one error handling path. This patch fixes that.
--- drivers/tty/serial/ar933x_uart.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/tty/serial/ar933x_uart.c +4 -2
@@ -789,8 +789,10 @@ static int ar933x_uart_probe(struct plat goto err_disable_clk; up->gpios =mctrl_gpio_init (port,0 ); -if (IS_ERR (up->gpios) &&PTR_ERR (up->gpios) != -ENOSYS ) -return PTR_ERR (up->gpios); +if (IS_ERR (up->gpios) &&PTR_ERR (up->gpios) != -ENOSYS ) { + ret =PTR_ERR (up->gpios); + goto err_disable_clk; + } up->rts_gpiod =mctrl_gpio_to_gpiod (up->gpios,UART_GPIO_RTS );
Greg Kroah-Hartman
maintainerPATCH 217/252 arm64: dts: agilex/stratix10: Fix qspi node compatible
In reply to Greg Kroah-HartmanFrom: Dinh Nguyen <[email protected]>
commit f126b6702e7354d6247a36f20b9172457af5c15a upstream.
The QSPI flash node needs to have the required "jedec,spi-nor" in the compatible string.
--- arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts | 2 +- arch/arm64/boot/dts/altera/socfpga_stratix10_socdk_nand.dts | 2 +- arch/arm64/boot/dts/intel/socfpga_agilex_socdk.dts | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts +1 -1
@@ -159,7 +159,7 @@ flash@0 { #address-cells = <1>; #size-cells = <1>; - compatible = "n25q00a"; + compatible = "micron,mt25qu02g", "jedec,spi-nor"; reg = <0>; spi-max-frequency = <100000000>;
arch/arm64/boot/dts/altera/socfpga_stratix10_socdk_nand.dts +1 -1
@@ -192,7 +192,7 @@ flash@0 { #address-cells = <1>; #size-cells = <1>; - compatible = "n25q00a"; + compatible = "micron,mt25qu02g", "jedec,spi-nor"; reg = <0>; spi-max-frequency = <100000000>;
arch/arm64/boot/dts/intel/socfpga_agilex_socdk.dts +1 -1
@@ -110,7 +110,7 @@ flash@0 { #address-cells = <1>; #size-cells = <1>; - compatible = "mt25qu02g"; + compatible = "micron,mt25qu02g", "jedec,spi-nor"; reg = <0>; spi-max-frequency = <100000000>;
Greg Kroah-Hartman
maintainerPATCH 218/252 spi: lpspi: Fix use-after-free on unbind
In reply to Greg Kroah-HartmanFrom: Lukas Wunner <[email protected]>
commit 4def49da620c84a682d9361d6bef0a97eed46fe0 upstream.
Normally the last reference on an spi_controller is released by spi_unregister_controller(). In the case of the i.MX lpspi driver, the spi_controller is registered with devm_spi_register_controller(), so spi_unregister_controller() is invoked automatically after the driver has unbound.
However the driver already releases the last reference in fsl_lpspi_remove() through a gratuitous call to spi_master_put(), causing a use-after-free when spi_unregister_controller() is subsequently invoked by the devres framework.
Fix by dropping the superfluous spi_master_put().
--- drivers/spi/spi-fsl-lpspi.c | 3 --- 1 file changed, 3 deletions(-)
drivers/spi/spi-fsl-lpspi.c +0 -3
@@ -938,9 +938,6 @@ static int fsl_lpspi_remove(struct platfspi_controller_get_devdata (controller);pm_runtime_disable (fsl_lpspi->dev); - -spi_master_put (controller); -return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 219/252 spi: Introduce device-managed SPI controller allocation
In reply to Greg Kroah-HartmanFrom: Lukas Wunner <[email protected]>
commit 5e844cc37a5cbaa460e68f9a989d321d63088a89 upstream.
SPI driver probing currently comprises two steps, whereas removal comprises only one step:
spi_alloc_master()
spi_register_controller()
spi_unregister_controller()
That's because spi_unregister_controller() calls device_unregister() instead of device_del(), thereby releasing the reference on the spi_controller which was obtained by spi_alloc_master().
An SPI driver's private data is contained in the same memory allocation as the spi_controller struct. Thus, once spi_unregister_controller() has been called, the private data is inaccessible. But some drivers need to access it after spi_unregister_controller() to perform further teardown steps.
Introduce devm_spi_alloc_master() and devm_spi_alloc_slave(), which release a reference on the spi_controller struct only after the driver has unbound, thereby keeping the memory allocation accessible. Change spi_unregister_controller() to not release a reference if the spi_controller was allocated by one of these new devm functions.
The present commit is small enough to be backportable to stable. It allows fixing drivers which use the private data in their ->remove() hook after it's been freed. It also allows fixing drivers which neglect to release a reference on the spi_controller in the probe error path.
Long-term, most SPI drivers shall be moved over to the devm functions introduced herein. The few that can't shall be changed in a treewide commit to explicitly release the last reference on the controller. That commit shall amend spi_unregister_controller() to no longer release a reference, thereby completing the migration.
As a result, the behaviour will be less surprising and more consistent with subsystems such as IIO, which also includes the private data in the allocation of the generic iio_dev struct, but calls device_del() in iio_device_unregister().
--- drivers/spi/spi.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++- include/linux/spi/spi.h | 19 +++++++++++++++ 2 files changed, 76 insertions(+), 1 deletion(-)
drivers/spi/spi.c +57 -1
@@ -2442,6 +2442,49 @@ struct spi_controller *__spi_alloc_contr }EXPORT_SYMBOL_GPL (__spi_alloc_controller); +static void devm_spi_release_controller (struct device *dev,void *ctlr) +{ +spi_controller_put (*(struct spi_controller **)ctlr); +} + +/** +* __devm_spi_alloc_controller - resource-managed __spi_alloc_controller() +* @dev: physical device of SPI controller +* @size: how much zeroed driver-private data to allocate +* @slave: whether to allocate an SPI master (false) or SPI slave (true) +* Context: can sleep +* +* Allocate an SPI controller and automatically release a reference on it +* when @dev is unbound from its driver. Drivers are thus relieved from +* having to call spi_controller_put(). +* +* The arguments to this function are identical to __spi_alloc_controller(). +* +* Return: the SPI controller structure on success, else NULL. +*/ +struct spi_controller *__devm_spi_alloc_controller (struct device *dev, +unsigned int size, +bool slave) +{ +struct spi_controller **ptr, *ctlr; + + ptr =devres_alloc (devm_spi_release_controller,sizeof (*ptr), +GFP_KERNEL ); +if (!ptr) +return NULL ; + + ctlr =__spi_alloc_controller (dev, size, slave); +if (ctlr) { + *ptr = ctlr; +devres_add (dev, ptr); + }else { +devres_free (ptr); + } + +return ctlr; +} +EXPORT_SYMBOL_GPL (__devm_spi_alloc_controller); +#ifdef CONFIG_OF static int of_spi_get_gpio_numbers (struct spi_controller *ctlr) {
@@ -2778,6 +2821,11 @@ int devm_spi_register_controller(struct }EXPORT_SYMBOL_GPL (devm_spi_register_controller); +static int devm_spi_match_controller (struct device *dev,void *res,void *ctlr) +{ +return *(struct spi_controller **)res == ctlr; +} +static int __unregister (struct device *dev,void *null) {spi_unregister_device (to_spi_device (dev));
@@ -2819,7 +2867,15 @@ void spi_unregister_controller(struct splist_del (&ctlr->list);mutex_unlock (&board_lock); -device_unregister (&ctlr->dev); +device_del (&ctlr->dev); + +/* Release the last reference on the controller if its driver +* has not yet been converted to devm_spi_alloc_master/slave(). +*/ +if (!devres_find (ctlr->dev.parent, devm_spi_release_controller, + devm_spi_match_controller, ctlr)) +put_device (&ctlr->dev); +/* free bus id */ mutex_lock (&board_lock);if (found == ctlr)
include/linux/spi/spi.h +19 -0
@@ -734,6 +734,25 @@ static inline struct spi_controller *spireturn __spi_alloc_controller (host, size, true); } +struct spi_controller *__devm_spi_alloc_controller (struct device *dev, +unsigned int size, +bool slave); + +static inline struct spi_controller *devm_spi_alloc_master (struct device *dev, +unsigned int size) +{ +return __devm_spi_alloc_controller (dev, size, false); +} + +static inline struct spi_controller *devm_spi_alloc_slave (struct device *dev, +unsigned int size) +{ +if (!IS_ENABLED (CONFIG_SPI_SLAVE )) +return NULL ; + +return __devm_spi_alloc_controller (dev, size, true); +} +extern int spi_register_controller (struct spi_controller *ctlr);extern int devm_spi_register_controller (struct device *dev,struct spi_controller *ctlr);
Greg Kroah-Hartman
maintainerPATCH 220/252 spi: npcm-fiu: Dont leak SPI master in probe error path
In reply to Greg Kroah-HartmanFrom: Lukas Wunner <[email protected]>
commit 04a9cd51d3f3308a98cbc6adc07acb12fbade011 upstream.
If the calls to of_match_device(), of_alias_get_id(), devm_ioremap_resource(), devm_regmap_init_mmio() or devm_clk_get() fail on probe of the NPCM FIU SPI driver, the spi_controller struct is erroneously not freed.
Fix by switching over to the new devm_spi_alloc_master() helper.
--- drivers/spi/spi-npcm-fiu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/spi/spi-npcm-fiu.c +1 -1
@@ -680,7 +680,7 @@ static int npcm_fiu_probe(struct platforint ret;int id; - ctrl =spi_alloc_master (dev,sizeof (*fiu)); + ctrl =devm_spi_alloc_master (dev,sizeof (*fiu));if (!ctrl)return -ENOMEM ;
Greg Kroah-Hartman
maintainerPATCH 221/252 spi: bcm2835aux: Fix use-after-free on unbind
In reply to Greg Kroah-HartmanFrom: Lukas Wunner <[email protected]>
commit e13ee6cc4781edaf8c7321bee19217e3702ed481 upstream.
bcm2835aux_spi_remove() accesses the driver's private data after calling spi_unregister_master() even though that function releases the last reference on the spi_master and thereby frees the private data.
Fix by switching over to the new devm_spi_alloc_master() helper which keeps the private data accessible until the driver has unbound.
--- drivers/spi/spi-bcm2835aux.c | 21 +++++++-------------- 1 file changed, 7 insertions(+), 14 deletions(-)
drivers/spi/spi-bcm2835aux.c +7 -14
@@ -494,7 +494,7 @@ static int bcm2835aux_spi_probe(struct punsigned long clk_hz;int err; - master =spi_alloc_master (&pdev->dev,sizeof (*bs)); + master =devm_spi_alloc_master (&pdev->dev,sizeof (*bs));if (!master)return -ENOMEM ;
@@ -524,29 +524,24 @@ static int bcm2835aux_spi_probe(struct p/* the main area */ bs->regs =devm_platform_ioremap_resource (pdev,0 ); -if (IS_ERR (bs->regs)) { - err =PTR_ERR (bs->regs); - goto out_master_put; - } +if (IS_ERR (bs->regs)) +return PTR_ERR (bs->regs); bs->clk =devm_clk_get (&pdev->dev,NULL );if (IS_ERR (bs->clk)) { - err =PTR_ERR (bs->clk);dev_err (&pdev->dev,"could not get clk: %d\n" , err); - goto out_master_put; +return PTR_ERR (bs->clk); } bs->irq =platform_get_irq (pdev,0 ); -if (bs->irq <=0 ) { - err = bs->irq ? bs->irq : -ENODEV ; - goto out_master_put; - } +if (bs->irq <=0 ) +return bs->irq ? bs->irq : -ENODEV ;/* this also enables the HW block */ err =clk_prepare_enable (bs->clk);if (err) {dev_err (&pdev->dev,"could not prepare clock: %d\n" , err); - goto out_master_put; +return err; }/* just checking if the clock returns a sane value */
@@ -581,8 +576,6 @@ static int bcm2835aux_spi_probe(struct p out_clk_disable:clk_disable_unprepare (bs->clk); -out_master_put: -spi_master_put (master);return err; }
Greg Kroah-Hartman
maintainerPATCH 222/252 regulator: pfuze100: limit pfuze-support-disable-sw to pfuze{100,200}
In reply to Greg Kroah-HartmanFrom: Sean Nyekjaer <[email protected]>
commit 365ec8b61689bd64d6a61e129e0319bf71336407 upstream.
Limit the fsl,pfuze-support-disable-sw to the pfuze100 and pfuze200 variants.
When enabling fsl,pfuze-support-disable-sw and using a pfuze3000 or pfuze3001, the driver would choose pfuze100_sw_disable_regulator_ops instead of the newly introduced and correct pfuze3000_sw_regulator_ops.
--- drivers/regulator/pfuze100-regulator.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
drivers/regulator/pfuze100-regulator.c +8 -5
@@ -836,11 +836,14 @@ static int pfuze100_regulator_probe(stru* the switched regulator till yet. */ if (pfuze_chip->flags &PFUZE_FLAG_DISABLE_SW ) { -if (pfuze_chip->regulator_descs[i].sw_reg) { - desc->ops = &pfuze100_sw_disable_regulator_ops; - desc->enable_val =0x8 ; - desc->disable_val =0x0 ; - desc->enable_time =500 ; +if (pfuze_chip->chip_id ==PFUZE100 || + pfuze_chip->chip_id ==PFUZE200 ) { +if (pfuze_chip->regulator_descs[i].sw_reg) { + desc->ops = &pfuze100_sw_disable_regulator_ops; + desc->enable_val =0x8 ; + desc->disable_val =0x0 ; + desc->enable_time =500 ; + } } }
Greg Kroah-Hartman
maintainerPATCH 223/252 regulator: fix memory leak with repeated set_machine_constraints()
In reply to Greg Kroah-HartmanFrom: Michał Mirosław <[email protected]>
commit 57a6ad482af256b2a13de14194fb8f67c1a65f10 upstream.
Fixed commit introduced a possible second call to set_machine_constraints() and that allocates memory for rdev->constraints. Move the allocation to the caller so it's easier to manage and done once.
--- drivers/regulator/core.c | 29 +++++++++++++---------------- 1 file changed, 13 insertions(+), 16 deletions(-)
drivers/regulator/core.c +13 -16
@@ -1280,7 +1280,6 @@ static int _regulator_do_enable(struct r/** * set_machine_constraints - sets regulator constraints * @rdev: regulator source -* @constraints: constraints to apply * * Allows platform initialisation code to define and constrain * regulator circuits e.g. valid voltage/current ranges, etc. NOTE:
@@ -1288,21 +1287,11 @@ static int _regulator_do_enable(struct r* regulator operations to proceed i.e. set_voltage, set_current_limit, * set_mode. */ -static int set_machine_constraints (struct regulator_dev *rdev, -const struct regulation_constraints *constraints) +static int set_machine_constraints (struct regulator_dev *rdev) {int ret =0 ;const struct regulator_ops *ops = rdev->desc->ops; -if (constraints) - rdev->constraints =kmemdup (constraints,sizeof (*constraints), -GFP_KERNEL ); -else - rdev->constraints =kzalloc (sizeof (*constraints), -GFP_KERNEL ); -if (!rdev->constraints) -return -ENOMEM ; - ret =machine_constraints_voltage (rdev, rdev->constraints);if (ret !=0 )return ret;
@@ -5112,7 +5101,6 @@ struct regulator_dev * regulator_register(const struct regulator_desc *regulator_desc, const struct regulator_config *cfg) { - const struct regulation_constraints *constraints = NULL; const struct regulator_init_data *init_data;struct regulator_config *config =NULL ;static atomic_t regulator_no =ATOMIC_INIT (-1 );
@@ -5251,14 +5239,23 @@ regulator_register(const struct regulato/* set regulator constraints */ if (init_data) - constraints = &init_data->constraints; + rdev->constraints =kmemdup (&init_data->constraints, +sizeof (*rdev->constraints), +GFP_KERNEL ); +else + rdev->constraints =kzalloc (sizeof (*rdev->constraints), +GFP_KERNEL ); +if (!rdev->constraints) { + ret = -ENOMEM ; + goto wash; + }if (init_data && init_data->supply_regulator) rdev->supply_name = init_data->supply_regulator;else if (regulator_desc->supply_name) rdev->supply_name = regulator_desc->supply_name; - ret =set_machine_constraints (rdev, constraints); + ret =set_machine_constraints (rdev);if (ret == -EPROBE_DEFER ) {/* Regulator might be in bypass mode and so needs its supply * to set the constraints */
@@ -5267,7 +5264,7 @@ regulator_register(const struct regulato* that is just being created */ ret =regulator_resolve_supply (rdev);if (!ret) - ret =set_machine_constraints (rdev, constraints); + ret =set_machine_constraints (rdev);else rdev_dbg (rdev,"unable to resolve supply early: %pe\n" ,ERR_PTR (ret));
Greg Kroah-Hartman
maintainerPATCH 224/252 regulator: avoid resolve_supply() infinite recursion
In reply to Greg Kroah-HartmanFrom: Michał Mirosław <[email protected]>
commit 4b639e254d3d4f15ee4ff2b890a447204cfbeea9 upstream.
When a regulator's name equals its supply's name the regulator_resolve_supply() recurses indefinitely. Add a check so that debugging the problem is easier. The "fixed" commit just exposed the problem.
--- drivers/regulator/core.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/regulator/core.c +6 -0
@@ -1805,6 +1805,12 @@ static int regulator_resolve_supply(stru } } +if (r == rdev) { +dev_err (dev,"Supply for %s (%s) resolved to itself\n" , + rdev->desc->name, rdev->supply_name); +return -EINVAL ; + } +/* * If the supply's parent device is not the same as the * regulator's parent device, then ensure the parent device
Greg Kroah-Hartman
maintainerPATCH 225/252 regulator: workaround self-referent regulators
In reply to Greg Kroah-HartmanFrom: Michał Mirosław <[email protected]>
commit f5c042b23f7429e5c2ac987b01a31c69059a978b upstream.
Workaround regulators whose supply name happens to be the same as its own name. This fixes boards that used to work before the early supply resolving was removed. The error message is left in place so that offending drivers can be detected.
--- drivers/regulator/core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/regulator/core.c +4 -1
@@ -1808,7 +1808,10 @@ static int regulator_resolve_supply(struif (r == rdev) {dev_err (dev,"Supply for %s (%s) resolved to itself\n" , rdev->desc->name, rdev->supply_name); -return -EINVAL ; +if (!have_full_constraints ()) +return -EINVAL ; + r = dummy_regulator_rdev; +get_device (&r->dev); }/*
Greg Kroah-Hartman
maintainerPATCH 226/252 gfs2: Fix regression in freeze_go_sync
In reply to Greg Kroah-HartmanFrom: Bob Peterson <[email protected]>
commit 20b329129009caf1c646152abe09b697227e1c37 upstream.
Patch 541656d3a513 ("gfs2: freeze should work on read-only mounts") changed the check for glock state in function freeze_go_sync() from "gl->gl_state == LM_ST_SHARED" to "gl->gl_req == LM_ST_EXCLUSIVE". That's wrong and it regressed gfs2's freeze/thaw mechanism because it caused only the freezing node (which requests the glock in EX) to queue freeze work.
All nodes go through this go_sync code path during the freeze to drop their SHared hold on the freeze glock, allowing the freezing node to acquire it in EXclusive mode. But all the nodes must freeze access to the file system locally, so they ALL must queue freeze work. The freeze_work calls freeze_func, which makes a request to reacquire the freeze glock in SH, effectively blocking until the thaw from the EX holder. Once thawed, the freezing node drops its EX hold on the freeze glock, then the (blocked) freeze_func reacquires the freeze glock in SH again (on all nodes, including the freezer) so all nodes go back to a thawed state.
This patch changes the check back to gl_state == LM_ST_SHARED like it was prior to 541656d3a513.
--- fs/gfs2/glops.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
fs/gfs2/glops.c +12 -1
@@ -540,7 +540,18 @@ static int freeze_go_sync(struct gfs2_glint error =0 ;struct gfs2_sbd *sdp = gl->gl_name.ln_sbd; -if (gl->gl_req ==LM_ST_EXCLUSIVE && !gfs2_withdrawn (sdp)) { +/* +* We need to check gl_state == LM_ST_SHARED here and not gl_req == +* LM_ST_EXCLUSIVE. That's because when any node does a freeze, +* all the nodes should have the freeze glock in SH mode and they all +* call do_xmote: One for EX and the others for UN. They ALL must +* freeze locally, and they ALL must queue freeze work. The freeze_work +* calls freeze_func, which tries to reacquire the freeze glock in SH, +* effectively waiting for the thaw on the node who holds it in EX. +* Once thawed, the work func acquires the freeze glock in +* SH and everybody goes back to thawed. +*/ +if (gl->gl_state ==LM_ST_SHARED && !gfs2_withdrawn (sdp)) {atomic_set (&sdp->sd_freeze_state,SFS_STARTING_FREEZE ); error =freeze_super (sdp->sd_vfs);if (error) {
Greg Kroah-Hartman
maintainerPATCH 227/252 xtensa: fix TLBTEMP area placement
In reply to Greg Kroah-HartmanFrom: Max Filippov <[email protected]>
commit 481535c5b41d191b22775a6873de5ec0e1cdced1 upstream.
fast_second_level_miss handler for the TLBTEMP area has an assumption that page table directory entry for the TLBTEMP address range is 0. For it to be true the TLBTEMP area must be aligned to 4MB boundary and not share its 4MB region with anything that may use a page table. This is not true currently: TLBTEMP shares space with vmalloc space which results in the following kinds of runtime errors when fast_second_level_miss loads page table directory entry for the vmalloc space instead of fixing up the TLBTEMP area:
Unable to handle kernel paging request at virtual address c7ff0e00 pc = d0009275, ra = 90009478 Oops: sig: 9 [#1] PREEMPT CPU: 1 PID: 61 Comm: kworker/u9:2 Not tainted 5.10.0-rc3-next-20201110-00007-g1fe4962fa983-dirty #58 Workqueue: xprtiod xs_stream_data_receive_workfn a00: 90009478 d11e1dc0 c7ff0e00 00000020 c7ff0000 00000001 7f8b8107 00000000 a08: 900c5992 d11e1d90 d0cc88b8 5506e97c 00000000 5506e97c d06c8074 d11e1d90 pc: d0009275, ps: 00060310, depc: 00000014, excvaddr: c7ff0e00 lbeg: d0009275, lend: d0009287 lcount: 00000003, sar: 00000010 Call Trace: xs_stream_data_receive_workfn+0x43c/0x770 process_one_work+0x1a1/0x324 worker_thread+0x1cc/0x3c0 kthread+0x10d/0x124 ret_from_kernel_thread+0xc/0x18
--- Documentation/xtensa/mmu.rst | 9 ++++++--- arch/xtensa/include/asm/pgtable.h | 2 +- 2 files changed, 7 insertions(+), 4 deletions(-)
Documentation/xtensa/mmu.rst +6 -3
@@ -82,7 +82,8 @@ Default MMUv2-compatible layout:: +------------------+ | VMALLOC area | VMALLOC_START 0xc0000000 128MB - 64KB +------------------+ VMALLOC_END - | Cache aliasing | TLBTEMP_BASE_1 0xc7ff0000 DCACHE_WAY_SIZE + +------------------+ + | Cache aliasing | TLBTEMP_BASE_1 0xc8000000 DCACHE_WAY_SIZE | remap area 1 | +------------------+ | Cache aliasing | TLBTEMP_BASE_2 DCACHE_WAY_SIZE
@@ -124,7 +125,8 @@ Default MMUv2-compatible layout:: +------------------+ | VMALLOC area | VMALLOC_START 0xa0000000 128MB - 64KB +------------------+ VMALLOC_END - | Cache aliasing | TLBTEMP_BASE_1 0xa7ff0000 DCACHE_WAY_SIZE + +------------------+ + | Cache aliasing | TLBTEMP_BASE_1 0xa8000000 DCACHE_WAY_SIZE | remap area 1 | +------------------+ | Cache aliasing | TLBTEMP_BASE_2 DCACHE_WAY_SIZE
@@ -167,7 +169,8 @@ Default MMUv2-compatible layout:: +------------------+ | VMALLOC area | VMALLOC_START 0x90000000 128MB - 64KB +------------------+ VMALLOC_END - | Cache aliasing | TLBTEMP_BASE_1 0x97ff0000 DCACHE_WAY_SIZE + +------------------+ + | Cache aliasing | TLBTEMP_BASE_1 0x98000000 DCACHE_WAY_SIZE | remap area 1 | +------------------+ | Cache aliasing | TLBTEMP_BASE_2 DCACHE_WAY_SIZE
arch/xtensa/include/asm/pgtable.h +1 -1
@@ -69,7 +69,7 @@*/ #define VMALLOC_START (XCHAL_KSEG_CACHED_VADDR - 0x10000000)#define VMALLOC_END (VMALLOC_START + 0x07FEFFFF) -#define TLBTEMP_BASE_1 (VMALLOC_END + 1) +#define TLBTEMP_BASE_1 (VMALLOC_START + 0x08000000)#define TLBTEMP_BASE_2 (TLBTEMP_BASE_1 + DCACHE_WAY_SIZE)#if 2 *DCACHE_WAY_SIZE >ICACHE_WAY_SIZE #define TLBTEMP_SIZE (2 * DCACHE_WAY_SIZE)
Greg Kroah-Hartman
maintainerPATCH 228/252 xtensa: disable preemption around cache alias management calls
In reply to Greg Kroah-HartmanFrom: Max Filippov <[email protected]>
commit 3a860d165eb5f4d7cf0bf81ef6a5b5c5e1754422 upstream.
Although cache alias management calls set up and tear down TLB entries and fast_second_level_miss is able to restore TLB entry should it be evicted they absolutely cannot preempt each other because they use the same TLBTEMP area for different purposes.
Disable preemption around all cache alias management calls to enforce that.
--- arch/xtensa/mm/cache.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
arch/xtensa/mm/cache.c +14 -0
@@ -70,8 +70,10 @@ static inline void kmap_invalidate_coher kvaddr =TLBTEMP_BASE_1 + (page_to_phys (page) &DCACHE_ALIAS_MASK ); +preempt_disable ();__invalidate_dcache_page_alias (kvaddr,page_to_phys (page)); +preempt_enable (); } } }
@@ -156,6 +158,7 @@ void flush_dcache_page(struct page *pageif (!alias && !mapping)return ; +preempt_disable (); virt =TLBTEMP_BASE_1 + (phys &DCACHE_ALIAS_MASK );__flush_invalidate_dcache_page_alias (virt, phys);
@@ -166,6 +169,7 @@ void flush_dcache_page(struct page *pageif (mapping)__invalidate_icache_page_alias (virt, phys); +preempt_enable (); }/* There shouldn't be an entry in the cache for this page anymore. */
@@ -199,8 +203,10 @@ void local_flush_cache_page(struct vm_arunsigned long phys =page_to_phys (pfn_to_page (pfn));unsigned long virt =TLBTEMP_BASE_1 + (address &DCACHE_ALIAS_MASK ); +preempt_disable ();__flush_invalidate_dcache_page_alias (virt, phys);__invalidate_icache_page_alias (virt, phys); +preempt_enable (); }EXPORT_SYMBOL (local_flush_cache_page);
@@ -227,11 +233,13 @@ update_mmu_cache(struct vm_area_struct *unsigned long phys =page_to_phys (page);unsigned long tmp; +preempt_disable (); tmp =TLBTEMP_BASE_1 + (phys &DCACHE_ALIAS_MASK );__flush_invalidate_dcache_page_alias (tmp, phys); tmp =TLBTEMP_BASE_1 + (addr &DCACHE_ALIAS_MASK );__flush_invalidate_dcache_page_alias (tmp, phys);__invalidate_icache_page_alias (tmp, phys); +preempt_enable ();clear_bit (PG_arch_1, &page->flags); }
@@ -265,7 +273,9 @@ void copy_to_user_page(struct vm_area_stif (alias) {unsigned long t =TLBTEMP_BASE_1 + (vaddr &DCACHE_ALIAS_MASK ); +preempt_disable ();__flush_invalidate_dcache_page_alias (t, phys); +preempt_enable (); }/* Copy data */
@@ -280,9 +290,11 @@ void copy_to_user_page(struct vm_area_stif (alias) {unsigned long t =TLBTEMP_BASE_1 + (vaddr &DCACHE_ALIAS_MASK ); +preempt_disable ();__flush_invalidate_dcache_range ((unsigned long ) dst, len);if ((vma->vm_flags &VM_EXEC ) !=0 )__invalidate_icache_page_alias (t, phys); +preempt_enable (); }else if ((vma->vm_flags &VM_EXEC ) !=0 ) {__flush_dcache_range ((unsigned long )dst,len);
@@ -304,7 +316,9 @@ extern void copy_from_user_page(struct vif (alias) {unsigned long t =TLBTEMP_BASE_1 + (vaddr &DCACHE_ALIAS_MASK ); +preempt_disable ();__flush_invalidate_dcache_page_alias (t, phys); +preempt_enable (); }memcpy (dst, src, len);
Greg Kroah-Hartman
maintainerPATCH 229/252 mac80211: minstrel: remove deferred sampling code
In reply to Greg Kroah-HartmanFrom: Felix Fietkau <[email protected]>
commit 4fe40b8e1566dad04c87fbf299049a1d0d4bd58d upstream.
Deferring sampling attempts to the second stage has some bad interactions with drivers that process the rate table in hardware and use the probe flag to indicate probing packets (e.g. most mt76 drivers). On affected drivers it can lead to probing not working at all.
If the link conditions turn worse, it might not be such a good idea to do a lot of sampling for lower rates in this case.
Fix this by simply skipping the sample attempt instead of deferring it, but keep the checks that would allow it to be sampled if it was skipped too often, but only if it has less than 95% success probability.
Also ensure that IEEE80211_TX_CTL_RATE_CTRL_PROBE is set for all probing packets.
--- net/mac80211/rc80211_minstrel.c | 25 ++++--------------------- net/mac80211/rc80211_minstrel.h | 1 - 2 files changed, 4 insertions(+), 22 deletions(-)
net/mac80211/rc80211_minstrel.c +4 -21
@@ -287,12 +287,6 @@ minstrel_tx_status(void *priv, struct ie mi->r[ndx].stats.success += success; } -if ((info->flags &IEEE80211_TX_CTL_RATE_CTRL_PROBE ) && (i >=0 )) - mi->sample_packets++; - -if (mi->sample_deferred >0 ) - mi->sample_deferred--; -if (time_after (jiffies, mi->last_stats_update + mp->update_interval / (mp->new_avg ?2 :1 )))minstrel_update_stats (mp, mi);
@@ -367,7 +361,7 @@ minstrel_get_rate(void *priv, struct ieereturn ; delta = (mi->total_packets * sampling_ratio /100 ) - - (mi->sample_packets + mi->sample_deferred /2 ); + mi->sample_packets;/* delta < 0: no sampling required */ prev_sample = mi->prev_sample;
@@ -376,7 +370,6 @@ minstrel_get_rate(void *priv, struct ieereturn ;if (mi->total_packets >=10000 ) { - mi->sample_deferred =0 ; mi->sample_packets =0 ; mi->total_packets =0 ; }else if (delta > mi->n_rates *2 ) {
@@ -401,19 +394,8 @@ minstrel_get_rate(void *priv, struct iee* rate sampling method should be used. * Respect such rates that are not sampled for 20 interations. */ -if (mrr_capable && - msr->perfect_tx_time > mr->perfect_tx_time && - msr->stats.sample_skipped <20 ) { -/* Only use IEEE80211_TX_CTL_RATE_CTRL_PROBE to mark -* packets that have the sampling rate deferred to the -* second MRR stage. Increase the sample counter only -* if the deferred sample rate was actually used. -* Use the sample_deferred counter to make sure that -* the sampling is not done in large bursts */ - info->flags |=IEEE80211_TX_CTL_RATE_CTRL_PROBE ; - rate++; - mi->sample_deferred++; - }else { +if (msr->perfect_tx_time < mr->perfect_tx_time || + msr->stats.sample_skipped >=20 ) {if (!msr->sample_limit)return ;
@@ -433,6 +415,7 @@ minstrel_get_rate(void *priv, struct iee rate->idx = mi->r[ndx].rix; rate->count =minstrel_get_retry_count (&mi->r[ndx], info); + info->flags |=IEEE80211_TX_CTL_RATE_CTRL_PROBE ; }
net/mac80211/rc80211_minstrel.h +0 -1
@@ -126,7 +126,6 @@ struct minstrel_sta_info {u8 max_prob_rate;unsigned int total_packets;unsigned int sample_packets; -int sample_deferred;unsigned int sample_row;unsigned int sample_column;
Greg Kroah-Hartman
maintainerPATCH 230/252 mac80211: minstrel: fix tx status processing corner case
In reply to Greg Kroah-HartmanFrom: Felix Fietkau <[email protected]>
commit b2911a84396f72149dce310a3b64d8948212c1b3 upstream.
Some drivers fill the status rate list without setting the rate index after the final rate to -1. minstrel_ht already deals with this, but minstrel doesn't, which causes it to get stuck at the lowest rate on these drivers.
Fix this by checking the count as well.
--- net/mac80211/rc80211_minstrel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/mac80211/rc80211_minstrel.c +1 -1
@@ -274,7 +274,7 @@ minstrel_tx_status(void *priv, struct ie success = !!(info->flags &IEEE80211_TX_STAT_ACK );for (i =0 ; i <IEEE80211_TX_MAX_RATES ; i++) { -if (ar[i].idx <0 ) +if (ar[i].idx <0 || !ar[i].count)break ; ndx =rix_to_ndx (mi, ar[i].idx);
Greg Kroah-Hartman
maintainerPATCH 231/252 mac80211: free sta in sta_info_insert_finish() on errors
In reply to Greg Kroah-HartmanFrom: Johannes Berg <[email protected]>
commit 7bc40aedf24d31d8bea80e1161e996ef4299fb10 upstream.
If sta_info_insert_finish() fails, we currently keep the station around and free it only in the caller, but there's only one such caller and it always frees it immediately.
As syzbot found, another consequence of this split is that we can put things that sleep only into __cleanup_single_sta() and not in sta_info_free(), but this is the only place that requires such of sta_info_free() now.
Change this to free the station in sta_info_insert_finish(), in which case we can still sleep. This will also let us unify the cleanup code later.
--- net/mac80211/sta_info.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-)
net/mac80211/sta_info.c +4 -10
@@ -705,7 +705,7 @@ static int sta_info_insert_finish(struct out_drop_sta: local->num_sta--;synchronize_net (); -__cleanup_single_sta (sta); +cleanup_single_sta (sta); out_err:mutex_unlock (&local->sta_mtx);kfree (sinfo);
@@ -724,19 +724,13 @@ int sta_info_insert_rcu(struct sta_info err =sta_info_insert_check (sta);if (err) { +sta_info_free (local, sta);mutex_unlock (&local->sta_mtx);rcu_read_lock (); - goto out_free; +return err; } - err =sta_info_insert_finish (sta); -if (err) - goto out_free; - -return 0 ; - out_free: -sta_info_free (local, sta); -return err; +return sta_info_insert_finish (sta); }int sta_info_insert (struct sta_info *sta)
Greg Kroah-Hartman
maintainerPATCH 232/252 s390: fix system call exit path
In reply to Greg Kroah-HartmanFrom: Heiko Carstens <[email protected]>
commit ce9dfafe29bed86fe3cda330ac6072ce84e1ff81 upstream.
The system call exit path is running with interrupts enabled while checking for TIF/PIF/CIF bits which require special handling. If all bits have been checked interrupts are disabled and the kernel exits to user space.
The problem is that after checking all bits and before interrupts are disabled bits can be set already again, due to interrupt handling.
This means that the kernel can exit to user space with some TIF/PIF/CIF bits set, which should never happen. E.g. TIF_NEED_RESCHED might be set, which might lead to additional latencies, since that bit will only be recognized with next exit to user space.
Fix this by checking the corresponding bits only when interrupts are disabled.
--- arch/s390/kernel/entry.S | 2 ++ 1 file changed, 2 insertions(+)
arch/s390/kernel/entry.S +2 -0
@@ -422,6 +422,7 @@ ENTRY(system_call) #endif LOCKDEP_SYS_EXIT .Lsysc_tif: + DISABLE_INTS TSTMSK __PT_FLAGS(%r11),_PIF_WORK jnz .Lsysc_work TSTMSK __TI_flags(%r12),_TIF_WORK
@@ -446,6 +447,7 @@ ENTRY(system_call) # One of the work bits is on. Find out which one. # .Lsysc_work: + ENABLE_INTS TSTMSK __TI_flags(%r12),_TIF_NEED_RESCHED jo .Lsysc_reschedule TSTMSK __PT_FLAGS(%r11),_PIF_SYSCALL_RESTART
Greg Kroah-Hartman
maintainerPATCH 233/252 s390/cpum_sf.c: fix file permission for cpum_sfb_size
In reply to Greg Kroah-HartmanFrom: Thomas Richter <[email protected]>
commit 78d732e1f326f74f240d416af9484928303d9951 upstream.
This file is installed by the s390 CPU Measurement sampling facility device driver to export supported minimum and maximum sample buffer sizes.
This file is read by lscpumf tool to display the details of the device driver capabilities. The lscpumf tool might be invoked by a non-root user. In this case it does not print anything because the file contents can not be read.
Fix this by allowing read access for all users. Reading the file contents is ok, changing the file contents is left to the root user only.
For further reference and details see:
[1] https://github.com/ibm-s390-tools/s390-tools/issues/97
--- arch/s390/kernel/perf_cpum_sf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/s390/kernel/perf_cpum_sf.c +1 -1
@@ -2228,4 +2228,4 @@ out: }arch_initcall (init_cpum_sampling_pmu); -core_param (cpum_sfb_size,CPUM_SF_MAX_SDB , sfb_size,0640 ); +core_param (cpum_sfb_size,CPUM_SF_MAX_SDB , sfb_size,0644 );
Greg Kroah-Hartman
maintainerPATCH 234/252 s390/dasd: fix null pointer dereference for ERP requests
In reply to Greg Kroah-HartmanFrom: Stefan Haberland <[email protected]>
commit 6f117cb854a44a79898d844e6ae3fd23bd94e786 upstream.
When requeueing all requests on the device request queue to the blocklayer we might get to an ERP (error recovery) request that is a copy of an original CQR.
Those requests do not have blocklayer request information or a pointer to the dasd_queue set. When trying to access those data it will lead to a null pointer dereference in dasd_requeue_all_requests().
Fix by checking if the request is an ERP request that can simply be ignored. The blocklayer request will be requeued by the original CQR that is on the device queue right behind the ERP request.
--- drivers/s390/block/dasd.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/s390/block/dasd.c +6 -0
@@ -2980,6 +2980,12 @@ static int _dasd_requeue_request(structif (!block)return -EINVAL ; +/* +* If the request is an ERP request there is nothing to requeue. +* This will be done with the remaining original request. +*/ +if (cqr->refers) +return 0 ;spin_lock_irq (&cqr->dq->lock); req = (struct request *) cqr->callback_data;blk_mq_requeue_request (req, false);
Greg Kroah-Hartman
maintainerPATCH 235/252 Drivers: hv: vmbus: Allow cleanup of VMBUS_CONNECT_CPU if disconnected
In reply to Greg Kroah-HartmanFrom: Chris Co <[email protected]>
commit 92e4dc8b05663d6539b1b8375f3b1cf7b204cfe9 upstream.
When invoking kexec() on a Linux guest running on a Hyper-V host, the kernel panics.
RIP: 0010:cpuhp_issue_call+0x137/0x140
Call Trace:
__cpuhp_remove_state_cpuslocked+0x99/0x100
__cpuhp_remove_state+0x1c/0x30
hv_kexec_handler+0x23/0x30 [hv_vmbus]
hv_machine_shutdown+0x1e/0x30
machine_shutdown+0x10/0x20
kernel_kexec+0x6d/0x96
__do_sys_reboot+0x1ef/0x230
__x64_sys_reboot+0x1d/0x20
do_syscall_64+0x6b/0x3d8
entry_SYSCALL_64_after_hwframe+0x44/0xa9This was due to hv_synic_cleanup() callback returning -EBUSY to cpuhp_issue_call() when tearing down the VMBUS_CONNECT_CPU, even if the vmbus_connection.conn_state = DISCONNECTED. hv_synic_cleanup() should succeed in the case where vmbus_connection.conn_state is DISCONNECTED.
Fix is to add an extra condition to test for vmbus_connection.conn_state == CONNECTED on the VMBUS_CONNECT_CPU and only return early if true. This way the kexec() path can still shut everything down while preserving the initial behavior of preventing CPU offlining on the VMBUS_CONNECT_CPU while the VM is running.
--- drivers/hv/hv.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/hv/hv.c +6 -2
@@ -244,9 +244,13 @@ int hv_synic_cleanup(unsigned int cpu)/* * Hyper-V does not provide a way to change the connect CPU once -* it is set; we must prevent the connect CPU from going offline. +* it is set; we must prevent the connect CPU from going offline +* while the VM is running normally. But in the panic or kexec() +* path where the vmbus is already disconnected, the CPU must be +* allowed to shut down. */ -if (cpu ==VMBUS_CONNECT_CPU ) +if (cpu ==VMBUS_CONNECT_CPU && + vmbus_connection.conn_state ==CONNECTED )return -EBUSY ;/*
Greg Kroah-Hartman
maintainerPATCH 236/252 drm/amd/display: Add missing pflip irq for dcn2.0
In reply to Greg Kroah-HartmanFrom: Alex Deucher <[email protected]>
commit 728321e53045d2668bf2b8627a8d61bc2c480d3b upstream.
If we have more than 4 displays we will run
into dummy irq calls or flip timout issues.
--- drivers/gpu/drm/amd/display/dc/irq/dcn20/irq_service_dcn20.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/display/dc/irq/dcn20/irq_service_dcn20.c +2 -2
@@ -299,8 +299,8 @@ irq_source_info_dcn20[DAL_IRQ_SOURCES_NUpflip_int_entry (1 ),pflip_int_entry (2 ),pflip_int_entry (3 ), - [DC_IRQ_SOURCE_PFLIP5] = dummy_irq_entry(), - [DC_IRQ_SOURCE_PFLIP6] = dummy_irq_entry(), +pflip_int_entry (4 ), + pflip_int_entry(5), [DC_IRQ_SOURCE_PFLIP_UNDERLAY0 ] =dummy_irq_entry (),gpio_pad_int_entry (0 ), gpio_pad_int_entry(1),
Greg Kroah-Hartman
maintainerPATCH 237/252 drm/i915: Handle max_bpc==16
In reply to Greg Kroah-HartmanFrom: Ville Syrjälä <[email protected]>
commit d2e3fce9ddafe689c6f7cb355f23560637e30b9d upstream.
EDID can declare the maximum supported bpc up to 16, and apparently there are displays that do so. Currently we assume 12 bpc is tha max. Fix the assumption and toss in a MISSING_CASE() for any other value we don't expect to see.
This fixes modesets with a display with EDID max bpc > 12. Previously any modeset would just silently fail on platforms that didn't otherwise limit this via the max_bpc property. In particular we don't add the max_bpc property to HDMI ports on gmch platforms, and thus we would see the raw max_bpc coming from the EDID.
I suppose we could already adjust this to also allow 16bpc, but seeing as no current platform supports that there is little point.
--- drivers/gpu/drm/i915/display/intel_display.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/i915/display/intel_display.c +2 -1
@@ -12819,10 +12819,11 @@ compute_sink_pipe_bpp(const struct drm_c case 10 ... 11: bpp =10 *3 ;break ; -case 12 : + case 12 ... 16: bpp =12 *3 ;break ;default : +MISSING_CASE (conn_state->max_bpc);return -EINVAL ; }
Greg Kroah-Hartman
maintainerPATCH 238/252 drm/i915/tgl: Fix Media power gate sequence.
In reply to Greg Kroah-HartmanFrom: Rodrigo Vivi <[email protected]>
commit 85a12d7eb8fe449cf38f1aa9ead5ca744729a98f upstream.
Some media power gates are disabled by default. commit 5d86923060fc ("drm/i915/tgl: Enable VD HCP/MFX sub-pipe power gating") tried to enable it, but it duplicated an existent register. So, the main PG setup sequences ended up overwriting it.
So, let's now merge this to the main PG setup sequence.
v2: (Chris): s/BIT/REG_BIT, remove useless comment,
remove useless =0, use the right gt, remove rc6 sequence doubt from commit message.
--- drivers/gpu/drm/i915/gt/intel_rc6.c | 22 +++++++++++++++++----- drivers/gpu/drm/i915/i915_reg.h | 12 +++++------- drivers/gpu/drm/i915/intel_pm.c | 13 ------------- 3 files changed, 22 insertions(+), 25 deletions(-)
drivers/gpu/drm/i915/gt/intel_rc6.c +17 -5
@@ -56,9 +56,12 @@ static inline void set(struct intel_uncostatic void gen11_rc6_enable (struct intel_rc6 *rc6) { -struct intel_uncore *uncore =rc6_to_uncore (rc6); +struct intel_gt *gt =rc6_to_gt (rc6); +struct intel_uncore *uncore = gt->uncore;struct intel_engine_cs *engine;enum intel_engine_id id; +u32 pg_enable; +int i;/* 2b: Program RC6 thresholds.*/ set (uncore,GEN6_RC6_WAKE_RATE_LIMIT ,54 <<16 |85 );
@@ -102,10 +105,19 @@ static void gen11_rc6_enable(struct inteGEN6_RC_CTL_RC6_ENABLE |GEN6_RC_CTL_EI_MODE (1 ); -set (uncore,GEN9_PG_ENABLE , -GEN9_RENDER_PG_ENABLE | -GEN9_MEDIA_PG_ENABLE | -GEN11_MEDIA_SAMPLER_PG_ENABLE ); + pg_enable = +GEN9_RENDER_PG_ENABLE | +GEN9_MEDIA_PG_ENABLE | +GEN11_MEDIA_SAMPLER_PG_ENABLE ; + +if (INTEL_GEN (gt->i915) >=12 ) { +for (i =0 ; i <I915_MAX_VCS ; i++) +if (HAS_ENGINE (gt,_VCS (i))) + pg_enable |= (VDN_HCP_POWERGATE_ENABLE (i) | +VDN_MFX_POWERGATE_ENABLE (i)); + } + +set (uncore,GEN9_PG_ENABLE , pg_enable); }static void gen9_rc6_enable (struct intel_rc6 *rc6)
drivers/gpu/drm/i915/i915_reg.h +5 -7
@@ -8974,10 +8974,6 @@ enum {#define GEN9_PWRGT_MEDIA_STATUS_MASK (1 << 0)#define GEN9_PWRGT_RENDER_STATUS_MASK (1 << 1) -#define POWERGATE_ENABLE _MMIO(0xa210) -#define VDN_HCP_POWERGATE_ENABLE (n) BIT(((n) * 2) + 3) -#define VDN_MFX_POWERGATE_ENABLE (n) BIT(((n) * 2) + 4) -#define GTFIFODBG _MMIO(0x120000)#define GT_FIFO_SBDEDICATE_FREE_ENTRY_CHV (0x1f << 20)#define GT_FIFO_FREE_ENTRIES_CHV (0x7f << 13)
@@ -9117,9 +9113,11 @@ enum {#define GEN9_MEDIA_PG_IDLE_HYSTERESIS _MMIO(0xA0C4)#define GEN9_RENDER_PG_IDLE_HYSTERESIS _MMIO(0xA0C8)#define GEN9_PG_ENABLE _MMIO(0xA210) -#define GEN9_RENDER_PG_ENABLE REG_BIT(0) -#define GEN9_MEDIA_PG_ENABLE REG_BIT(1) -#define GEN11_MEDIA_SAMPLER_PG_ENABLE REG_BIT(2) +#define GEN9_RENDER_PG_ENABLE REG_BIT(0) +#define GEN9_MEDIA_PG_ENABLE REG_BIT(1) +#define GEN11_MEDIA_SAMPLER_PG_ENABLE REG_BIT(2) +#define VDN_HCP_POWERGATE_ENABLE (n) REG_BIT(3 + 2 * (n)) +#define VDN_MFX_POWERGATE_ENABLE (n) REG_BIT(4 + 2 * (n))#define GEN8_PUSHBUS_CONTROL _MMIO(0xA248)#define GEN8_PUSHBUS_ENABLE _MMIO(0xA250)#define GEN8_PUSHBUS_SHIFT _MMIO(0xA25C)
drivers/gpu/drm/i915/intel_pm.c +0 -13
@@ -7124,23 +7124,10 @@ static void icl_init_clock_gating(structstatic void tgl_init_clock_gating (struct drm_i915_private *dev_priv) { -u32 vd_pg_enable =0 ; -unsigned int i; -/* Wa_1409120013:tgl */ I915_WRITE (ILK_DPFC_CHICKEN ,ILK_DPFC_CHICKEN_COMP_DUMMY_PIXEL ); -/* This is not a WA. Enable VD HCP & MFX_ENC powergate */ -for (i =0 ; i <I915_MAX_VCS ; i++) { -if (HAS_ENGINE (&dev_priv->gt,_VCS (i))) - vd_pg_enable |=VDN_HCP_POWERGATE_ENABLE (i) | -VDN_MFX_POWERGATE_ENABLE (i); - } - -I915_WRITE (POWERGATE_ENABLE , -I915_READ (POWERGATE_ENABLE ) | vd_pg_enable); -/* Wa_1409825376:tgl (pre-prod)*/ if (IS_TGL_REVID (dev_priv,TGL_REVID_A0 ,TGL_REVID_A0 )) I915_WRITE(GEN9_CLKGATE_DIS_3, I915_READ(GEN9_CLKGATE_DIS_3) |
Greg Kroah-Hartman
maintainerPATCH 239/252 io_uring: dont double complete failed reissue request
In reply to Greg Kroah-HartmanFrom: Jens Axboe <[email protected]>
commit c993df5a688975bf9ce899706ca13d2bc8d6be25 upstream.
Zorro reports that an xfstest test case is failing, and it turns out that for the reissue path we can potentially issue a double completion on the request for the failure path. There's an issue around the retry as well, but for now, at least just make sure that we handle the error path correctly.
--- fs/io_uring.c | 1 - 1 file changed, 1 deletion(-)
fs/io_uring.c +0 -1
@@ -2359,7 +2359,6 @@ static bool io_resubmit_prep(struct io_k } end_req:req_set_fail_links (req); -io_req_complete (req, ret);return false; }#endif
Greg Kroah-Hartman
maintainerPATCH 240/252 mmc: sdhci-pci: Prefer SDR25 timing for High Speed mode for BYT-based Intel controllers
In reply to Greg Kroah-HartmanFrom: Adrian Hunter <[email protected]>
commit 60d53566100abde4acc5504b524bc97f89015690 upstream.
A UHS setting of SDR25 can give better results for High Speed mode. This is because there is no setting corresponding to high speed. Currently SDHCI sets no value, which means zero which is also the setting for SDR12. There was an attempt to change this in sdhci.c but it caused problems for some drivers, so it was reverted and the change was made to sdhci-brcmstb in commit 2fefc7c5f7d16e ("mmc: sdhci-brcmstb: Fix incorrect switch to HS mode"). Several other drivers also do this.
--- drivers/mmc/host/sdhci-pci-core.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
drivers/mmc/host/sdhci-pci-core.c +11 -2
@@ -665,6 +665,15 @@ static void sdhci_intel_set_power(struct } } +static void sdhci_intel_set_uhs_signaling (struct sdhci_host *host, +unsigned int timing) +{ +/* Set UHS timing to SDR25 for High Speed mode */ +if (timing ==MMC_TIMING_MMC_HS || timing ==MMC_TIMING_SD_HS ) + timing =MMC_TIMING_UHS_SDR25 ; +sdhci_set_uhs_signaling (host, timing); +} +#define INTEL_HS400_ES_REG 0x78#define INTEL_HS400_ES_BIT BIT(0)
@@ -721,7 +730,7 @@ static const struct sdhci_ops sdhci_inte .enable_dma = sdhci_pci_enable_dma, .set_bus_width = sdhci_set_bus_width, .reset = sdhci_reset, - .set_uhs_signaling = sdhci_set_uhs_signaling, + .set_uhs_signaling = sdhci_intel_set_uhs_signaling, .hw_reset = sdhci_pci_hw_reset, };
@@ -731,7 +740,7 @@ static const struct sdhci_ops sdhci_inte .enable_dma = sdhci_pci_enable_dma, .set_bus_width = sdhci_set_bus_width, .reset = sdhci_cqhci_reset, - .set_uhs_signaling = sdhci_set_uhs_signaling, + .set_uhs_signaling = sdhci_intel_set_uhs_signaling, .hw_reset = sdhci_pci_hw_reset, .irq = sdhci_cqhci_irq, };
Greg Kroah-Hartman
maintainerPATCH 241/252 mmc: sdhci-of-arasan: Allow configuring zero tap values
In reply to Greg Kroah-HartmanFrom: Manish Narani <[email protected]>
commit 9e9534329306fcd7ea1b84f14860a3c04ebe7f1a upstream.
Allow configuring the Output and Input tap values with zero to avoid failures in some cases (one of them is SD boot mode) where the output and input tap values may be already set to non-zero.
--- drivers/mmc/host/sdhci-of-arasan.c | 40 +++++++------------------------------ 1 file changed, 8 insertions(+), 32 deletions(-)
drivers/mmc/host/sdhci-of-arasan.c +8 -32
@@ -600,14 +600,8 @@ static int sdhci_zynqmp_sdcardclk_set_phu8 tap_delay, tap_max =0 ;int ret; -/* -* This is applicable for SDHCI_SPEC_300 and above -* ZynqMP does not set phase for <=25MHz clock. -* If degrees is zero, no need to do anything. -*/ -if (host->version <SDHCI_SPEC_300 || - host->timing ==MMC_TIMING_LEGACY || - host->timing ==MMC_TIMING_UHS_SDR12 || !degrees) +/* This is applicable for SDHCI_SPEC_300 and above */ +if (host->version <SDHCI_SPEC_300 )return 0 ;switch (host->timing) {
@@ -668,14 +662,8 @@ static int sdhci_zynqmp_sampleclk_set_phu8 tap_delay, tap_max =0 ;int ret; -/* -* This is applicable for SDHCI_SPEC_300 and above -* ZynqMP does not set phase for <=25MHz clock. -* If degrees is zero, no need to do anything. -*/ -if (host->version <SDHCI_SPEC_300 || - host->timing ==MMC_TIMING_LEGACY || - host->timing ==MMC_TIMING_UHS_SDR12 || !degrees) +/* This is applicable for SDHCI_SPEC_300 and above */ +if (host->version <SDHCI_SPEC_300 )return 0 ;switch (host->timing) {
@@ -733,14 +721,8 @@ static int sdhci_versal_sdcardclk_set_phstruct sdhci_host *host = sdhci_arasan->host;u8 tap_delay, tap_max =0 ; -/* -* This is applicable for SDHCI_SPEC_300 and above -* Versal does not set phase for <=25MHz clock. -* If degrees is zero, no need to do anything. -*/ -if (host->version <SDHCI_SPEC_300 || - host->timing ==MMC_TIMING_LEGACY || - host->timing ==MMC_TIMING_UHS_SDR12 || !degrees) +/* This is applicable for SDHCI_SPEC_300 and above */ +if (host->version <SDHCI_SPEC_300 )return 0 ;switch (host->timing) {
@@ -804,14 +786,8 @@ static int sdhci_versal_sampleclk_set_phstruct sdhci_host *host = sdhci_arasan->host;u8 tap_delay, tap_max =0 ; -/* -* This is applicable for SDHCI_SPEC_300 and above -* Versal does not set phase for <=25MHz clock. -* If degrees is zero, no need to do anything. -*/ -if (host->version <SDHCI_SPEC_300 || - host->timing ==MMC_TIMING_LEGACY || - host->timing ==MMC_TIMING_UHS_SDR12 || !degrees) +/* This is applicable for SDHCI_SPEC_300 and above */ +if (host->version <SDHCI_SPEC_300 )return 0 ;switch (host->timing) {
Greg Kroah-Hartman
maintainerPATCH 242/252 mmc: sdhci-of-arasan: Use Mask writes for Tap delays
In reply to Greg Kroah-HartmanFrom: Manish Narani <[email protected]>
commit d338c6d01dc614cad253d6c042501fa0eb242d5c upstream.
Mask the ITAP and OTAP delay bits before updating with the new tap value for Versal platform.
--- drivers/mmc/host/sdhci-of-arasan.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/mmc/host/sdhci-of-arasan.c +5 -0
@@ -30,7 +30,10 @@#define SDHCI_ARASAN_VENDOR_REGISTER 0x78#define SDHCI_ARASAN_ITAPDLY_REGISTER 0xF0F8 +#define SDHCI_ARASAN_ITAPDLY_SEL_MASK 0xFF +#define SDHCI_ARASAN_OTAPDLY_REGISTER 0xF0FC +#define SDHCI_ARASAN_OTAPDLY_SEL_MASK 0x3F#define SDHCI_ARASAN_CQE_BASE_ADDR 0x200#define VENDOR_ENHANCED_STROBE BIT(0)
@@ -755,6 +758,7 @@ static int sdhci_versal_sdcardclk_set_ph regval =sdhci_readl (host,SDHCI_ARASAN_OTAPDLY_REGISTER ); regval |=SDHCI_OTAPDLY_ENABLE ;sdhci_writel (host, regval,SDHCI_ARASAN_OTAPDLY_REGISTER ); + regval &= ~SDHCI_ARASAN_OTAPDLY_SEL_MASK ; regval |= tap_delay;sdhci_writel (host, regval,SDHCI_ARASAN_OTAPDLY_REGISTER ); }
@@ -822,6 +826,7 @@ static int sdhci_versal_sampleclk_set_phsdhci_writel (host, regval,SDHCI_ARASAN_ITAPDLY_REGISTER ); regval |=SDHCI_ITAPDLY_ENABLE ;sdhci_writel (host, regval,SDHCI_ARASAN_ITAPDLY_REGISTER ); + regval &= ~SDHCI_ARASAN_ITAPDLY_SEL_MASK ; regval |= tap_delay;sdhci_writel (host, regval,SDHCI_ARASAN_ITAPDLY_REGISTER ); regval &= ~SDHCI_ITAPDLY_CHGWIN ;
Greg Kroah-Hartman
maintainerPATCH 243/252 mmc: sdhci-of-arasan: Issue DLL reset explicitly
In reply to Greg Kroah-HartmanFrom: Manish Narani <[email protected]>
commit d06d60d52ec0b0eef702dd3e7b4699f0b589ad0f upstream.
In the current implementation DLL reset will be issued for each ITAP and OTAP setting inside ATF, this is creating issues in some scenarios and this sequence is not inline with the TRM. To fix the issue, DLL reset should be removed from the ATF and host driver will request it explicitly.
This patch update host driver to explicitly request for DLL reset before ITAP (assert DLL) and after OTAP (release DLL) settings.
--- drivers/mmc/host/sdhci-of-arasan.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/mmc/host/sdhci-of-arasan.c +6 -0
@@ -635,6 +635,9 @@ static int sdhci_zynqmp_sdcardclk_set_phif (ret)pr_err ("Error setting Output Tap Delay\n" ); +/* Release DLL Reset */ +zynqmp_pm_sd_dll_reset (node_id,PM_DLL_RESET_RELEASE ); +return ret; }
@@ -669,6 +672,9 @@ static int sdhci_zynqmp_sampleclk_set_phif (host->version <SDHCI_SPEC_300 )return 0 ; +/* Assert DLL Reset */ +zynqmp_pm_sd_dll_reset (node_id,PM_DLL_RESET_ASSERT ); +switch (host->timing) {case MMC_TIMING_MMC_HS :case MMC_TIMING_SD_HS :
Greg Kroah-Hartman
maintainerPATCH 244/252 blk-cgroup: fix a hd_struct leak in blkcg_fill_root_iostats
In reply to Greg Kroah-HartmanFrom: Christoph Hellwig <[email protected]>
commit b7131ee0bac5e5df73e4098e77bbddb3a31d06ff upstream.
disk_get_part needs to be paired with a disk_put_part.
--- block/blk-cgroup.c | 1 + 1 file changed, 1 insertion(+)
block/blk-cgroup.c +1 -0
@@ -840,6 +840,7 @@ static void blkcg_fill_root_iostats(voidblkg_iostat_set (&blkg->iostat.cur, &tmp);u64_stats_update_end (&blkg->iostat.sync); } +disk_put_part (part); } }
Greg Kroah-Hartman
maintainerPATCH 245/252 ptrace: Set PF_SUPERPRIV when checking capability
In reply to Greg Kroah-HartmanFrom: Mickaël Salaün <[email protected]>
commit cf23705244c947151179f929774fabf71e239eee upstream.
Commit 69f594a38967 ("ptrace: do not audit capability check when outputing /proc/pid/stat") replaced the use of ns_capable() with has_ns_capability{,_noaudit}() which doesn't set PF_SUPERPRIV.
Commit 6b3ad6649a4c ("ptrace: reintroduce usage of subjective credentials in ptrace_has_cap()") replaced has_ns_capability{,_noaudit}() with security_capable(), which doesn't set PF_SUPERPRIV neither.
Since commit 98f368e9e263 ("kernel: Add noaudit variant of ns_capable()"), a new ns_capable_noaudit() helper is available. Let's use it!
As a result, the signature of ptrace_has_cap() is restored to its original one.
--- kernel/ptrace.c | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-)
kernel/ptrace.c +5 -11
@@ -264,17 +264,11 @@ static int ptrace_check_attach(struct tareturn ret; } -static bool ptrace_has_cap (const struct cred *cred,struct user_namespace *ns, -unsigned int mode) +static bool ptrace_has_cap (struct user_namespace *ns,unsigned int mode) { -int ret; -if (mode &PTRACE_MODE_NOAUDIT ) - ret =security_capable (cred, ns,CAP_SYS_PTRACE ,CAP_OPT_NOAUDIT ); -else - ret =security_capable (cred, ns,CAP_SYS_PTRACE ,CAP_OPT_NONE ); - -return ret ==0 ; +return ns_capable_noaudit (ns,CAP_SYS_PTRACE ); +return ns_capable (ns,CAP_SYS_PTRACE ); }/* Returns 0 on success, -errno on denial. */
@@ -326,7 +320,7 @@ static int __ptrace_may_access(struct ta gid_eq(caller_gid, tcred->sgid) && gid_eq(caller_gid, tcred->gid)) goto ok; -if (ptrace_has_cap (cred, tcred->user_ns, mode)) +if (ptrace_has_cap (tcred->user_ns, mode)) goto ok;rcu_read_unlock ();return -EPERM ;
@@ -345,7 +339,7 @@ ok: mm = task->mm;if (mm && ((get_dumpable (mm) !=SUID_DUMP_USER ) && - !ptrace_has_cap (cred, mm->user_ns, mode))) + !ptrace_has_cap (mm->user_ns, mode)))return -EPERM ;return security_ptrace_access_check (task, mode);
Greg Kroah-Hartman
maintainerPATCH 246/252 seccomp: Set PF_SUPERPRIV when checking capability
In reply to Greg Kroah-HartmanFrom: Mickaël Salaün <[email protected]>
commit fb14528e443646dd3fd02df4437fcf5265b66baa upstream.
Replace the use of security_capable(current_cred(), ...) with ns_capable_noaudit() which set PF_SUPERPRIV.
Since commit 98f368e9e263 ("kernel: Add noaudit variant of ns_capable()"), a new ns_capable_noaudit() helper is available. Let's use it!
--- kernel/seccomp.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
kernel/seccomp.c +2 -3
@@ -38,7 +38,7 @@#include <linux/filter.h> #include <linux/pid.h> #include <linux/ptrace.h> -#include <linux/security.h> +#include <linux/capability.h> #include <linux/tracehook.h> #include <linux/uaccess.h> #include <linux/anon_inodes.h>
@@ -554,8 +554,7 @@ static struct seccomp_filter *seccomp_pr* behavior of privileged children. */ if (!task_no_new_privs (current) && -security_capable (current_cred (),current_user_ns (), -CAP_SYS_ADMIN ,CAP_OPT_NOAUDIT ) !=0 ) + !ns_capable_noaudit (current_user_ns (),CAP_SYS_ADMIN ))return ERR_PTR (-EACCES );/* Allocate a new seccomp_filter */
Greg Kroah-Hartman
maintainerPATCH 247/252 fanotify: fix logic of reporting name info with watched parent
In reply to Greg Kroah-HartmanFrom: Amir Goldstein <[email protected]>
commit 7372e79c9eb9d7034e498721eb2861ae4fdbc618 upstream.
The victim inode's parent and name info is required when an event needs to be delivered to a group interested in filename info OR when the inode's parent is interested in an event on its children.
Let us call the first condition 'parent_needed' and the second condition 'parent_interested'.
In fsnotify_parent(), the condition where the inode's parent is interested in some events on its children, but not necessarily interested the specific event is called 'parent_watched'.
fsnotify_parent() tests the condition (!parent_watched && !parent_needed) for sending the event without parent and name info, which is correct.
It then wrongly assumes that parent_watched implies !parent_needed and tests the condition (parent_watched && !parent_interested) for sending the event without parent and name info, which is wrong, because parent may still be needed by some group.
For example, after initializing a group with FAN_REPORT_DFID_NAME and adding a FAN_MARK_MOUNT with FAN_OPEN mask, open events on non-directory children of "testdir" are delivered with file name info.
After adding another mark to the same group on the parent "testdir" with FAN_CLOSE|FAN_EVENT_ON_CHILD mask, open events on non-directory children of "testdir" are no longer delivered with file name info.
Fix the logic and use auxiliary variables to clarify the conditions.
--- fs/notify/fsnotify.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
fs/notify/fsnotify.c +7 -5
@@ -178,6 +178,7 @@ int __fsnotify_parent(struct dentry *denstruct inode *inode =d_inode (dentry);struct dentry *parent;bool parent_watched = dentry->d_flags &DCACHE_FSNOTIFY_PARENT_WATCHED ; +bool parent_needed, parent_interested;__u32 p_mask;struct inode *p_inode =NULL ;struct name_snapshot name;
@@ -193,7 +194,8 @@ int __fsnotify_parent(struct dentry *denreturn 0 ; parent =NULL ; -if (!parent_watched && !fsnotify_event_needs_parent (inode, mnt, mask)) + parent_needed =fsnotify_event_needs_parent (inode, mnt, mask); +if (!parent_watched && !parent_needed) goto notify;/* Does parent inode care about events on children? */
@@ -205,17 +207,17 @@ int __fsnotify_parent(struct dentry *den/* * Include parent/name in notification either if some notification -* groups require parent info (!parent_watched case) or the parent is -* interested in this event. +* groups require parent info or the parent is interested in this event. */ -if (!parent_watched || (mask & p_mask &ALL_FSNOTIFY_EVENTS )) { + parent_interested = mask & p_mask &ALL_FSNOTIFY_EVENTS ; +if (parent_needed || parent_interested) {/* When notifying parent, child should be passed as data */ WARN_ON_ONCE (inode !=fsnotify_data_inode (data, data_type));/* Notify both parent and child with child name info */ take_dentry_name_snapshot (&name, dentry); file_name = &name.name; -if (parent_watched) +if (parent_interested) mask |=FS_EVENT_ON_CHILD ; }
Greg Kroah-Hartman
maintainerPATCH 248/252 x86/microcode/intel: Check patch signature before saving microcode for early loading
In reply to Greg Kroah-HartmanFrom: Chen Yu <[email protected]>
commit 1a371e67dc77125736cc56d3a0893f06b75855b6 upstream.
Currently, scan_microcode() leverages microcode_matches() to check if the microcode matches the CPU by comparing the family and model. However, the processor stepping and flags of the microcode signature should also be considered when saving a microcode patch for early update.
Use find_matching_signature() in scan_microcode() and get rid of the now-unused microcode_matches() which is a good cleanup in itself.
Complete the verification of the patch being saved for early loading in save_microcode_patch() directly. This needs to be done there too because save_mc_for_early() will call save_microcode_patch() too.
The second reason why this needs to be done is because the loader still tries to support, at least hypothetically, mixed-steppings systems and thus adds all patches to the cache that belong to the same CPU model albeit with different steppings.
For example:
microcode: CPU: sig=0x906ec, pf=0x2, rev=0xd6
microcode: mc_saved[0]: sig=0x906e9, pf=0x2a, rev=0xd6, total size=0x19400, date = 2020-04-23
microcode: mc_saved[1]: sig=0x906ea, pf=0x22, rev=0xd6, total size=0x19000, date = 2020-04-27
microcode: mc_saved[2]: sig=0x906eb, pf=0x2, rev=0xd6, total size=0x19400, date = 2020-04-23
microcode: mc_saved[3]: sig=0x906ec, pf=0x22, rev=0xd6, total size=0x19000, date = 2020-04-27
microcode: mc_saved[4]: sig=0x906ed, pf=0x22, rev=0xd6, total size=0x19400, date = 2020-04-23
The patch which is being saved for early loading, however, can only be the one which fits the CPU this runs on so do the signature verification before saving.
[ bp: Do signature verification in save_microcode_patch()
and rewrite commit message. ]
--- arch/x86/kernel/cpu/microcode/intel.c | 63 +++++----------------------------- 1 file changed, 10 insertions(+), 53 deletions(-)
arch/x86/kernel/cpu/microcode/intel.c +10 -53
@@ -100,53 +100,6 @@ static int has_newer_microcode(void *mc,return find_matching_signature (mc, csig, cpf); } -/* -* Given CPU signature and a microcode patch, this function finds if the -* microcode patch has matching family and model with the CPU. -* -* %true - if there's a match -* %false - otherwise -*/ -static bool microcode_matches (struct microcode_header_intel *mc_header, -unsigned long sig) -{ -unsigned long total_size =get_totalsize (mc_header); -unsigned long data_size =get_datasize (mc_header); -struct extended_sigtable *ext_header; -unsigned int fam_ucode, model_ucode; -struct extended_signature *ext_sig; -unsigned int fam, model; -int ext_sigcount, i; - - fam =x86_family (sig); - model =x86_model (sig); - - fam_ucode =x86_family (mc_header->sig); - model_ucode =x86_model (mc_header->sig); - -if (fam == fam_ucode && model == model_ucode) -return true; - -/* Look for ext. headers: */ -if (total_size <= data_size +MC_HEADER_SIZE ) -return false; - - ext_header = (void *) mc_header + data_size +MC_HEADER_SIZE ; - ext_sig = (void *)ext_header +EXT_HEADER_SIZE ; - ext_sigcount = ext_header->count; - -for (i =0 ; i < ext_sigcount; i++) { - fam_ucode =x86_family (ext_sig->sig); - model_ucode =x86_model (ext_sig->sig); - -if (fam == fam_ucode && model == model_ucode) -return true; - - ext_sig++; - } -return false; -} -static struct ucode_patch *memdup_patch (void *data,unsigned int size) {struct ucode_patch *p;
@@ -164,7 +117,7 @@ static struct ucode_patch *memdup_patch(return p; } -static void save_microcode_patch (void *data,unsigned int size) +static void save_microcode_patch (struct ucode_cpu_info *uci,void *data,unsigned int size) {struct microcode_header_intel *mc_hdr, *mc_saved_hdr;struct ucode_patch *iter, *tmp, *p =NULL ;
@@ -210,6 +163,9 @@ static void save_microcode_patch(void *dif (!p)return ; +if (!find_matching_signature (p->data, uci->cpu_sig.sig, uci->cpu_sig.pf)) +return ; +/* * Save for early loading. On 32-bit, that needs to be a physical * address as the APs are running from physical addresses, before
@@ -344,13 +300,14 @@ scan_microcode(void *data, size_t size, size -= mc_size; -if (!microcode_matches (mc_header, uci->cpu_sig.sig)) { +if (!find_matching_signature (data, uci->cpu_sig.sig, + uci->cpu_sig.pf)) { data += mc_size;continue ; }if (save) { -save_microcode_patch (data, mc_size); +save_microcode_patch (uci, data, mc_size); goto next; }
@@ -483,14 +440,14 @@ static void show_saved_mc(void)* Save this microcode patch. It will be loaded early when a CPU is * hot-added or resumes. */ -static void save_mc_for_early (u8 *mc,unsigned int size) +static void save_mc_for_early (struct ucode_cpu_info *uci,u8 *mc,unsigned int size) {/* Synchronization during CPU hotplug. */ static DEFINE_MUTEX (x86_cpu_microcode_mutex);mutex_lock (&x86_cpu_microcode_mutex); -save_microcode_patch (mc, size); +save_microcode_patch (uci, mc, size);show_saved_mc ();mutex_unlock (&x86_cpu_microcode_mutex);
@@ -935,7 +892,7 @@ static enum ucode_state generic_load_mic* permanent memory. So it will be loaded early when a CPU is hot added * or resumes. */ -save_mc_for_early (new_mc, new_mc_size); +save_mc_for_early (uci, new_mc, new_mc_size);pr_debug ("CPU%d found a matching microcode update with version 0x%x (current=0x%x)\n" , cpu, new_rev, uci->cpu_sig.rev);
Greg Kroah-Hartman
maintainerPATCH 249/252 mm: never attempt async page lock if weve transferred data already
In reply to Greg Kroah-HartmanFrom: Jens Axboe <[email protected]>
commit 0abed7c69b956d135cb6d320c350b2adb213e7d8 upstream.
We catch the case where we enter generic_file_buffered_read() with data already transferred, but we also need to be careful not to allow an async page lock if we're looping transferring data. If not, we could be returning -EIOCBQUEUED instead of the transferred amount, and it could result in double waitqueue additions as well.
--- mm/filemap.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-)
mm/filemap.c +14 -4
@@ -2327,10 +2327,15 @@ page_ok: page_not_up_to_date:/* Get exclusive access to the page ... */ -if (iocb->ki_flags &IOCB_WAITQ ) +if (iocb->ki_flags &IOCB_WAITQ ) { +if (written) { +put_page (page); + goto out; + } error =lock_page_async (page, iocb->ki_waitq); -else + }else { error =lock_page_killable (page); + }if (unlikely (error)) goto readpage_error;
@@ -2373,10 +2378,15 @@ readpage: }if (!PageUptodate (page)) { -if (iocb->ki_flags &IOCB_WAITQ ) +if (iocb->ki_flags &IOCB_WAITQ ) { +if (written) { +put_page (page); + goto out; + } error =lock_page_async (page, iocb->ki_waitq); -else + }else { error =lock_page_killable (page); + }if (unlikely (error)) goto readpage_error;
Greg Kroah-Hartman
maintainerPATCH 250/252 mm: fix readahead_page_batch for retry entries
In reply to Greg Kroah-HartmanFrom: Matthew Wilcox (Oracle) <[email protected]>
commit 4349a83a3190c1d4414371161b0f4a4c3ccd3f9d upstream.
Both btrfs and fuse have reported faults caused by seeing a retry entry instead of the page they were looking for. This was caused by a missing check in the iterator.
As can be seen in the below panic log, the accessing 0x402 causes a panic. In the xarray.h, 0x402 means RETRY_ENTRY.
BUG: kernel NULL pointer dereference, address: 0000000000000402
CPU: 14 PID: 306003 Comm: as Not tainted 5.9.0-1-amd64 #1 Debian 5.9.1-1
Hardware name: Lenovo ThinkSystem SR665/7D2VCTO1WW, BIOS D8E106Q-1.01 05/30/2020
RIP: 0010:fuse_readahead+0x152/0x470 [fuse]
Code: 41 8b 57 18 4c 8d 54 10 ff 4c 89 d6 48 8d 7c 24 10 e8 d2 e3 28 f9 48 85 c0 0f 84 fe 00 00 00 44 89 f2 49 89 04 d4 44 8d 72 01 <48> 8b 10 41 8b 4f 1c 48 c1 ea 10 83 e2 01 80 fa 01 19 d2 81 e2 01
RSP: 0018:ffffad99ceaebc50 EFLAGS: 00010246
RAX: 0000000000000402 RBX: 0000000000000001 RCX: 0000000000000002
RDX: 0000000000000000 RSI: ffff94c5af90bd98 RDI: ffffad99ceaebc60
RBP: ffff94ddc1749a00 R08: 0000000000000402 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000100 R12: ffff94de6c429ce0
R13: ffff94de6c4d3700 R14: 0000000000000001 R15: ffffad99ceaebd68
FS: 00007f228c5c7040(0000) GS:ffff94de8ed80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000402 CR3: 0000001dbd9b4000 CR4: 0000000000350ee0
Call Trace:
read_pages+0x83/0x270
page_cache_readahead_unbounded+0x197/0x230
generic_file_buffered_read+0x57a/0xa20
new_sync_read+0x112/0x1a0
vfs_read+0xf8/0x180
ksys_read+0x5f/0xe0
do_syscall_64+0x33/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xa9--- include/linux/pagemap.h | 2 ++ 1 file changed, 2 insertions(+)
include/linux/pagemap.h +2 -0
@@ -794,6 +794,8 @@ static inline unsigned int __readahead_bxas_set (&xas, rac->_index);rcu_read_lock ();xas_for_each (&xas, page, rac->_index + rac->_nr_pages -1 ) { +if (xas_retry (&xas, page)) +continue ;VM_BUG_ON_PAGE (!PageLocked (page), page);VM_BUG_ON_PAGE (PageTail (page), page); array[i++] = page;
Greg Kroah-Hartman
maintainerPATCH 251/252 mm: memcg/slab: fix root memcg vmstats
In reply to Greg Kroah-HartmanFrom: Muchun Song <[email protected]>
commit 8faeb1ffd79593c9cd8a2a80ecdda371e3b826cb upstream.
If we reparent the slab objects to the root memcg, when we free the slab object, we need to update the per-memcg vmstats to keep it correct for the root memcg. Now this at least affects the vmstat of NR_KERNEL_STACK_KB for !CONFIG_VMAP_STACK when the thread stack size is smaller than the PAGE_SIZE.
David said:
"I assume that without this fix that the root memcg's vmstat would
always be inflated if we reparented"
--- mm/memcontrol.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
mm/memcontrol.c +7 -2
@@ -872,8 +872,13 @@ void __mod_lruvec_slab_state(void *p, enrcu_read_lock (); memcg =mem_cgroup_from_obj (p); -/* Untracked pages have no memcg, no lruvec. Update only the node */ -if (!memcg || memcg == root_mem_cgroup) { +/* +* Untracked pages have no memcg, no lruvec. Update only the +* node. If we reparent the slab objects to the root memcg, +* when we free the slab object, we need to update the per-memcg +* vmstats to keep it correct for the root memcg. +*/ +if (!memcg) {__mod_node_page_state (pgdat, idx, val); }else { lruvec =mem_cgroup_lruvec (memcg, pgdat);
Greg Kroah-Hartman
maintainerPATCH 252/252 mm/userfaultfd: do not access vma->vm_mm after calling handle_userfault()
In reply to Greg Kroah-HartmanFrom: Gerald Schaefer <[email protected]>
commit bfe8cc1db02ab243c62780f17fc57f65bde0afe1 upstream.
Alexander reported a syzkaller / KASAN finding on s390, see below for complete output.
In do_huge_pmd_anonymous_page(), the pre-allocated pagetable will be freed in some cases. In the case of userfaultfd_missing(), this will happen after calling handle_userfault(), which might have released the mmap_lock. Therefore, the following pte_free(vma->vm_mm, pgtable) will access an unstable vma->vm_mm, which could have been freed or re-used already.
For all architectures other than s390 this will go w/o any negative impact, because pte_free() simply frees the page and ignores the passed-in mm. The implementation for SPARC32 would also access mm->page_table_lock for pte_free(), but there is no THP support in SPARC32, so the buggy code path will not be used there.
For s390, the mm->context.pgtable_list is being used to maintain the 2K pagetable fragments, and operating on an already freed or even re-used mm could result in various more or less subtle bugs due to list / pagetable corruption.
Fix this by calling pte_free() before handle_userfault(), similar to how it is already done in __do_huge_pmd_anonymous_page() for the WRITE / non-huge_zero_page case.
Commit 6b251fc96cf2c ("userfaultfd: call handle_userfault() for userfaultfd_missing() faults") actually introduced both, the do_huge_pmd_anonymous_page() and also __do_huge_pmd_anonymous_page() changes wrt to calling handle_userfault(), but only in the latter case it put the pte_free() before calling handle_userfault().
BUG: KASAN: use-after-free in do_huge_pmd_anonymous_page+0xcda/0xd90 mm/huge_memory.c:744
Read of size 8 at addr 00000000962d6988 by task syz-executor.0/9334
CPU: 1 PID: 9334 Comm: syz-executor.0 Not tainted 5.10.0-rc1-syzkaller-07083-g4c9720875573 #0
Hardware name: IBM 3906 M04 701 (KVM/Linux)
Call Trace:
do_huge_pmd_anonymous_page+0xcda/0xd90 mm/huge_memory.c:744
create_huge_pmd mm/memory.c:4256 [inline]
__handle_mm_fault+0xe6e/0x1068 mm/memory.c:4480
handle_mm_fault+0x288/0x748 mm/memory.c:4607
do_exception+0x394/0xae0 arch/s390/mm/fault.c:479
do_dat_exception+0x34/0x80 arch/s390/mm/fault.c:567
pgm_check_handler+0x1da/0x22c arch/s390/kernel/entry.S:706
copy_from_user_mvcos arch/s390/lib/uaccess.c:111 [inline]
raw_copy_from_user+0x3a/0x88 arch/s390/lib/uaccess.c:174
_copy_from_user+0x48/0xa8 lib/usercopy.c:16
copy_from_user include/linux/uaccess.h:192 [inline]
__do_sys_sigaltstack kernel/signal.c:4064 [inline]
__s390x_sys_sigaltstack+0xc8/0x240 kernel/signal.c:4060
system_call+0xe0/0x28c arch/s390/kernel/entry.S:415
Allocated by task 9334:
slab_alloc_node mm/slub.c:2891 [inline]
slab_alloc mm/slub.c:2899 [inline]
kmem_cache_alloc+0x118/0x348 mm/slub.c:2904
vm_area_dup+0x9c/0x2b8 kernel/fork.c:356
__split_vma+0xba/0x560 mm/mmap.c:2742
split_vma+0xca/0x108 mm/mmap.c:2800
mlock_fixup+0x4ae/0x600 mm/mlock.c:550
apply_vma_lock_flags+0x2c6/0x398 mm/mlock.c:619
do_mlock+0x1aa/0x718 mm/mlock.c:711
__do_sys_mlock2 mm/mlock.c:738 [inline]
__s390x_sys_mlock2+0x86/0xa8 mm/mlock.c:728
system_call+0xe0/0x28c arch/s390/kernel/entry.S:415
Freed by task 9333:
slab_free mm/slub.c:3142 [inline]
kmem_cache_free+0x7c/0x4b8 mm/slub.c:3158
__vma_adjust+0x7b2/0x2508 mm/mmap.c:960
vma_merge+0x87e/0xce0 mm/mmap.c:1209
userfaultfd_release+0x412/0x6b8 fs/userfaultfd.c:868
__fput+0x22c/0x7a8 fs/file_table.c:281
task_work_run+0x200/0x320 kernel/task_work.c:151
tracehook_notify_resume include/linux/tracehook.h:188 [inline]
do_notify_resume+0x100/0x148 arch/s390/kernel/signal.c:538
system_call+0xe6/0x28c arch/s390/kernel/entry.S:416
The buggy address belongs to the object at 00000000962d6948 which belongs to the cache vm_area_struct of size 200
The buggy address is located 64 bytes inside of 200-byte region [00000000962d6948, 00000000962d6a10)
The buggy address belongs to the page: page:00000000313a09fe refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x962d6 flags: 0x3ffff00000000200(slab)
raw: 3ffff00000000200 000040000257e080 0000000c0000000c 000000008020ba00
raw: 0000000000000000 000f001e00000000 ffffffff00000001 0000000096959501
page dumped because: kasan: bad access detected
page->mem_cgroup:0000000096959501
Memory state around the buggy address:
00000000962d6880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000000962d6900: 00 fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb
>00000000962d6980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
00000000962d6a00: fb fb fc fc fc fc fc fc fc fc 00 00 00 00 00 00
00000000962d6a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================--- mm/huge_memory.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
mm/huge_memory.c +4 -5
@@ -710,7 +710,6 @@ vm_fault_t do_huge_pmd_anonymous_page(st transparent_hugepage_use_zero_page()) {pgtable_t pgtable;struct page *zero_page; -bool set;vm_fault_t ret; pgtable =pte_alloc_one (vma->vm_mm);if (unlikely (!pgtable))
@@ -723,25 +722,25 @@ vm_fault_t do_huge_pmd_anonymous_page(st } vmf->ptl =pmd_lock (vma->vm_mm, vmf->pmd); ret =0 ; - set = false;if (pmd_none (*vmf->pmd)) { ret =check_stable_address_space (vma->vm_mm);if (ret) {spin_unlock (vmf->ptl); +pte_free (vma->vm_mm, pgtable); }else if (userfaultfd_missing (vma)) {spin_unlock (vmf->ptl); +pte_free (vma->vm_mm, pgtable); ret =handle_userfault (vmf,VM_UFFD_MISSING );VM_BUG_ON (ret &VM_FAULT_FALLBACK ); }else {set_huge_zero_page (pgtable, vma->vm_mm, vma, haddr, vmf->pmd, zero_page);spin_unlock (vmf->ptl); - set = true; } - }else + }else {spin_unlock (vmf->ptl); -if (!set)pte_free (vma->vm_mm, pgtable); + }return ret; } gfp =alloc_hugepage_direct_gfpmask (vma);
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.9.11 release. There are 252 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 25 Nov 2020 12:17:50 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.9.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.9:
15 builds: 15 pass, 0 fail
26 boots: 26 pass, 0 fail
64 tests: 64 pass, 0 failLinux version: 5.9.11-rc1-g7939279fca79
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Greg Kroah-Hartman
maintainerQuoted 26 lines · Jon Hunter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.9.11 release. There are 252 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 25 Nov 2020 12:17:50 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.9.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.9:
15 builds: 15 pass, 0 fail 26 boots: 26 pass, 0 fail 64 tests: 64 pass, 0 fail
Quoted 7 lines
Linux version: 5.9.11-rc1-g7939279fca79
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,tegra194-p2972-0000, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-0000, tegra30-cardhu-a04Tested-by Jon Hunter <[email protected]>
Thanks for testing these and letting me know.
gre gk-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.9.11 release. There are 252 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 25 Nov 2020 12:17:50 +0000. Anything received after that time might be too late.
Build results:
total: 154 pass: 154 fail: 0 Qemu test results: total: 426 pass: 426 fail: 0
Guenter
Greg Kroah-Hartman
maintainerQuoted 10 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.9.11 release. There are 252 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 25 Nov 2020 12:17:50 +0000. Anything received after that time might be too late.
Quoted 6 lines
Build results:
total: 154 pass: 154 fail: 0 Qemu test results: total: 426 pass: 426 fail: 0Tested-by Guenter Roeck <[email protected]>
Thanks for testing them all and letting me know.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.9.11 release. There are 252 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 25 Nov 2020 12:17:50 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.9.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Greg Kroah-Hartman
maintainerQuoted 15 lines · Shuah Khan
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.9.11 release. There are 252 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 25 Nov 2020 12:17:50 +0000. 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/v5.x/stable-review/patch-5.9.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.9.y
and the diffstat can be found below.
Quoted 8 lines
Quoted 4 lines
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Tested-by Shuah Khan <[email protected]>
Thanks for testing them all and letting me know.
greg k-h
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.9.11 release. There are 252 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 25 Nov 2020 12:17:50 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.9.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 5.9.11-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.9.y
git commit: 7939279fca79f52c48861829cef3fe5d15529c42
git describe: v5.9.10-253-g7939279fca79
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.9.y/build/v5.9.10-253-g7939279fca79
No regressions (compared to build v5.9.10)
No fixes (compared to build v5.9.10)
Ran 47415 total tests in the following environments and test suites.
Environments
--------------
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- nxp-ls2088
- powerpc
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-i386-clang
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-tracing-tests
* perf
* v4l2-compliance
* ltp-controllers-tests
* ltp-syscalls-tests
* network-basic-tests
* ltp-cve-tests
* ltp-fs-tests
* ltp-hugetlb-tests
* ltp-mm-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kunit
* kselftest
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 17 lines · Naresh Kamboju
Quoted 15 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.9.11 release. There are 252 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 25 Nov 2020 12:17:50 +0000. 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/v5.x/stable-review/patch-5.9.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.9.y
and the diffstat can be found below.
Quoted 8 lines
Quoted 3 lines
thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm,x86_64, and i386.
Thanks for testing and letting me know.
greg k-h