From: Sudeep Holla <redacted>
commit 865ed67ab955428b9aa771d8b4f1e4fb7fd08945 upstream.
Without the bound checks for scpi_pd->name, it could result in the buffer
overflow when copying the SCPI device name from the corresponding device
tree node as the name string is set at maximum size of 30.
Let us fix it by using devm_kasprintf so that the string buffer is
allocated dynamically.
Fixes: 8bec4337ad40 ("firmware: scpi: add device power domain support using genpd")
Reported-by: Pedro Batista <redacted>
Signed-off-by: Sudeep Holla <redacted>
Cc: stable@vger.kernel.org
Cc: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20211209120456.696879-1-sudeep.holla@arm.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firmware/scpi_pm_domain.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
From: Daniel Borkmann <daniel@iogearbox.net>
commit 7d3baf0afa3aa9102d6a521a8e4c41888bb79882 upstream.
The change in commit 37086bfdc737 ("bpf: Propagate stack bounds to registers
in atomics w/ BPF_FETCH") around check_mem_access() handling is buggy since
this would allow for unprivileged users to leak kernel pointers. For example,
an atomic fetch/and with -1 on a stack destination which holds a spilled
pointer will migrate the spilled register type into a scalar, which can then
be exported out of the program (since scalar != pointer) by dumping it into
a map value.
The original implementation of XADD was preventing this situation by using
a double call to check_mem_access() one with BPF_READ and a subsequent one
with BPF_WRITE, in both cases passing -1 as a placeholder value instead of
register as per XADD semantics since it didn't contain a value fetch. The
BPF_READ also included a check in check_stack_read_fixed_off() which rejects
the program if the stack slot is of __is_pointer_value() if dst_regno < 0.
The latter is to distinguish whether we're dealing with a regular stack spill/
fill or some arithmetical operation which is disallowed on non-scalars, see
also 6e7e63cbb023 ("bpf: Forbid XADD on spilled pointers for unprivileged
users") for more context on check_mem_access() and its handling of placeholder
value -1.
One minimally intrusive option to fix the leak is for the BPF_FETCH case to
initially check the BPF_READ case via check_mem_access() with -1 as register,
followed by the actual load case with non-negative load_reg to propagate
stack bounds to registers.
Fixes: 37086bfdc737 ("bpf: Propagate stack bounds to registers in atomics w/ BPF_FETCH")
Reported-by: <redacted>
Acked-by: Brendan Jackman <redacted>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/bpf/verifier.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
@@ -4417,13 +4417,19 @@ static int check_atomic(struct bpf_verifload_reg=-1;}-/* check whether we can read the memory */+/* Check whether we can read the memory, with second call for fetch+*casetosimulatetheregisterfill.+*/err=check_mem_access(env,insn_idx,insn->dst_reg,insn->off,-BPF_SIZE(insn->code),BPF_READ,load_reg,true);+BPF_SIZE(insn->code),BPF_READ,-1,true);+if(!err&&load_reg>=0)+err=check_mem_access(env,insn_idx,insn->dst_reg,insn->off,+BPF_SIZE(insn->code),BPF_READ,load_reg,+true);if(err)returnerr;-/* check whether we can write into the same memory */+/* Check whether we can write into the same memory. */err=check_mem_access(env,insn_idx,insn->dst_reg,insn->off,BPF_SIZE(insn->code),BPF_WRITE,-1,true);if(err)
From: Daniel Borkmann <daniel@iogearbox.net>
commit e572ff80f05c33cd0cb4860f864f5c9c044280b6 upstream.
Make the bounds propagation in __reg_assign_32_into_64() slightly more
robust and readable by aligning it similarly as we did back in the
__reg_combine_64_into_32() counterpart. Meaning, only propagate or
pessimize them as a smin/smax pair.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/bpf/verifier.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
@@ -1358,22 +1358,28 @@ static void __reg_bound_offset(struct bpreg->var_off=tnum_or(tnum_clear_subreg(var64_off),var32_off);}+staticbool__reg32_bound_s64(s32a)+{+returna>=0&&a<=S32_MAX;+}+staticvoid__reg_assign_32_into_64(structbpf_reg_state*reg){reg->umin_value=reg->u32_min_value;reg->umax_value=reg->u32_max_value;-/* Attempt to pull 32-bit signed bounds into 64-bit bounds-*butmustbepositiveotherwisesettoworsecasebounds-*andrefinelaterfromtnum.++/* Attempt to pull 32-bit signed bounds into 64-bit bounds but must+*bepositiveotherwisesettoworsecaseboundsandrefinelater+*fromtnum.*/-if(reg->s32_min_value>=0&®->s32_max_value>=0)-reg->smax_value=reg->s32_max_value;-else-reg->smax_value=U32_MAX;-if(reg->s32_min_value>=0)+if(__reg32_bound_s64(reg->s32_min_value)&&+__reg32_bound_s64(reg->s32_max_value)){reg->smin_value=reg->s32_min_value;-else+reg->smax_value=reg->s32_max_value;+}else{reg->smin_value=0;+reg->smax_value=U32_MAX;+}}staticvoid__reg_combine_32_into_64(structbpf_reg_state*reg)
From: Will Deacon <will@kernel.org>
commit 817fc978b5a29b039db0418a91072b31c9aab152 upstream.
virtio_max_dma_size() returns the maximum DMA mapping size of the virtio
device by querying dma_max_mapping_size() for the device when the DMA
API is in use for the vring. Unfortunately, the device passed is
initialised by register_virtio_device() and does not inherit the DMA
configuration from its parent, resulting in SWIOTLB errors when bouncing
is enabled and the default 256K mapping limit (IO_TLB_SEGSIZE) is not
respected:
| virtio-pci 0000:00:01.0: swiotlb buffer is full (sz: 294912 bytes), total 1024 (slots), used 725 (slots)
Follow the pattern used elsewhere in the virtio_ring code when calling
into the DMA layer and pass the parent device to dma_max_mapping_size()
instead.
Cc: Marc Zyngier <maz@kernel.org>
Cc: Quentin Perret <redacted>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <redacted>
Signed-off-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20211201112018.25276-1-will@kernel.org
Acked-by: Jason Wang <redacted>
Tested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Fixes: e6d6dd6c875e ("virtio: Introduce virtio_max_dma_size()")
Cc: Joerg Roedel <redacted>
Cc: Konrad Rzeszutek Wilk <redacted>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Steven Price <steven.price@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/virtio/virtio_ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Sven Schnelle <svens@linux.ibm.com>
commit c9b12b59e2ea4c3c7cedec7efb071b649652f3a9 upstream.
In the current code, when exiting from idle, rcu_irq_enter() is
called twice during irq entry:
irq_entry_enter()-> rcu_irq_enter()
irq_enter() -> rcu_irq_enter()
This may lead to wrong results from rcu_is_cpu_rrupt_from_idle()
because of a wrong dynticks nmi nesting count. Fix this by only
calling irq_enter_rcu().
Cc: <redacted> # 5.12+
Reported-by: Mark Rutland <mark.rutland@arm.com>
Fixes: 56e62a737028 ("s390: convert to generic entry")
Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/s390/kernel/irq.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
From: Christian Brauner <redacted>
commit fd84bfdddd169c219c3a637889a8b87f70a072c2 upstream.
Ceph always inherits the SGID bit if it is set on the parent inode,
while the generic inode_init_owner does not do this in a few cases where
it can create a possible security problem (cf. [1]).
Update ceph to strip the SGID bit just as inode_init_owner would.
This bug was detected by the mapped mount testsuite in [3]. The
testsuite tests all core VFS functionality and semantics with and
without mapped mounts. That is to say it functions as a generic VFS
testsuite in addition to a mapped mount testsuite. While working on
mapped mount support for ceph, SIGD inheritance was the only failing
test for ceph after the port.
The same bug was detected by the mapped mount testsuite in XFS in
January 2021 (cf. [2]).
[1]: commit 0fa3ecd87848 ("Fix up non-directory creation in SGID directories")
[2]: commit 01ea173e103e ("xfs: fix up non-directory creation in SGID directories")
[3]: https://git.kernel.org/fs/xfs/xfstests-dev.git
Cc: stable@vger.kernel.org
Signed-off-by: Christian Brauner <redacted>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ceph/file.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
--- a/fs/ceph/file.c+++ b/fs/ceph/file.c
@@ -603,13 +603,25 @@ static int ceph_finish_async_create(struin.cap.realm=cpu_to_le64(ci->i_snap_realm->ino);in.cap.flags=CEPH_CAP_FLAG_AUTH;in.ctime=in.mtime=in.atime=iinfo.btime;-in.mode=cpu_to_le32((u32)mode);in.truncate_seq=cpu_to_le32(1);in.truncate_size=cpu_to_le64(-1ULL);in.xattr_version=cpu_to_le64(1);in.uid=cpu_to_le32(from_kuid(&init_user_ns,current_fsuid()));-in.gid=cpu_to_le32(from_kgid(&init_user_ns,dir->i_mode&S_ISGID?-dir->i_gid:current_fsgid()));+if(dir->i_mode&S_ISGID){+in.gid=cpu_to_le32(from_kgid(&init_user_ns,dir->i_gid));++/* Directories always inherit the setgid bit. */+if(S_ISDIR(mode))+mode|=S_ISGID;+elseif((mode&(S_ISGID|S_IXGRP))==(S_ISGID|S_IXGRP)&&+!in_group_p(dir->i_gid)&&+!capable_wrt_inode_uidgid(&init_user_ns,dir,CAP_FSETID))+mode&=~S_ISGID;+}else{+in.gid=cpu_to_le32(from_kgid(&init_user_ns,current_fsgid()));+}+in.mode=cpu_to_le32((u32)mode);+in.nlink=cpu_to_le32(1);in.max_size=cpu_to_le64(lo->stripe_unit);
From: Paul Moore <paul@paul-moore.com>
commit f4b3ee3c85551d2d343a3ba159304066523f730f upstream.
If the audit daemon were ever to get stuck in a stopped state the
kernel's kauditd_thread() could get blocked attempting to send audit
records to the userspace audit daemon. With the kernel thread
blocked it is possible that the audit queue could grow unbounded as
certain audit record generating events must be exempt from the queue
limits else the system enter a deadlock state.
This patch resolves this problem by lowering the kernel thread's
socket sending timeout from MAX_SCHEDULE_TIMEOUT to HZ/10 and tweaks
the kauditd_send_queue() function to better manage the various audit
queues when connection problems occur between the kernel and the
audit daemon. With this patch, the backlog may temporarily grow
beyond the defined limits when the audit daemon is stopped and the
system is under heavy audit pressure, but kauditd_thread() will
continue to make progress and drain the queues as it would for other
connection problems. For example, with the audit daemon put into a
stopped state and the system configured to audit every syscall it
was still possible to shutdown the system without a kernel panic,
deadlock, etc.; granted, the system was slow to shutdown but that is
to be expected given the extreme pressure of recording every syscall.
The timeout value of HZ/10 was chosen primarily through
experimentation and this developer's "gut feeling". There is likely
no one perfect value, but as this scenario is limited in scope (root
privileges would be needed to send SIGSTOP to the audit daemon), it
is likely not worth exposing this as a tunable at present. This can
always be done at a later date if it proves necessary.
Cc: stable@vger.kernel.org
Fixes: 5b52330bbfe63 ("audit: fix auditd/kernel connection state tracking")
Reported-by: Gaosheng Cui <redacted>
Tested-by: Gaosheng Cui <redacted>
Reviewed-by: Richard Guy Briggs <redacted>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/audit.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
--- a/kernel/audit.c+++ b/kernel/audit.c
@@ -718,7 +718,7 @@ static int kauditd_send_queue(struct soc{intrc=0;structsk_buff*skb;-staticunsignedintfailed=0;+unsignedintfailed=0;/* NOTE: kauditd_thread takes care of all our locking, we just use*thenetlinkinfopassedtous(e.g.skandportid)*/
@@ -735,32 +735,30 @@ static int kauditd_send_queue(struct soccontinue;}+retry:/* grab an extra skb reference in case of error */skb_get(skb);rc=netlink_unicast(sk,skb,portid,0);if(rc<0){-/* fatal failure for our queue flush attempt? */+/* send failed - try a few times unless fatal error */if(++failed>=retry_limit||rc==-ECONNREFUSED||rc==-EPERM){-/* yes - error processing for the queue */sk=NULL;if(err_hook)(*err_hook)(skb);-if(!skb_hook)-gotoout;-/* keep processing with the skb_hook */+if(rc==-EAGAIN)+rc=0;+/* continue to drain the queue */continue;}else-/* no - requeue to preserve ordering */-skb_queue_head(queue,skb);+gotoretry;}else{-/* it worked - drop the extra reference and continue */+/* skb sent - drop the extra reference and continue */consume_skb(skb);failed=0;}}-out:return(rc>=0?0:rc);}
@@ -1609,7 +1607,8 @@ static int __net_init audit_net_init(straudit_panic("cannot initialize netlink socket in namespace");return-ENOMEM;}-aunet->sk->sk_sndtimeo=MAX_SCHEDULE_TIMEOUT;+/* limit the timeout in case auditd is blocked/stopped */+aunet->sk->sk_sndtimeo=HZ/10;return0;}
From: Vitaly Kuznetsov <vkuznets@redhat.com>
[ Upstream commit 908fa88e420f30dde6d80f092795a18ec72ca6d3 ]
With the elevated 'KVM_CAP_MAX_VCPUS' value kvm_create_max_vcpus test
may hit RLIMIT_NOFILE limits:
# ./kvm_create_max_vcpus
KVM_CAP_MAX_VCPU_ID: 4096
KVM_CAP_MAX_VCPUS: 1024
Testing creating 1024 vCPUs, with IDs 0...1023.
/dev/kvm not available (errno: 24), skipping test
Adjust RLIMIT_NOFILE limits to make sure KVM_CAP_MAX_VCPUS fds can be
opened. Note, raising hard limit ('rlim_max') requires CAP_SYS_RESOURCE
capability which is generally not needed to run kvm selftests (but without
raising the limit the test is doomed to fail anyway).
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: [off-list ref]
[Skip the test if the hard limit can be raised. - Paolo]
Reviewed-by: Sean Christopherson <seanjc@google.com>
Tested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../selftests/kvm/kvm_create_max_vcpus.c | 30 +++++++++++++++++++
1 file changed, 30 insertions(+)
From: Lai Jiangshan <redacted>
[ Upstream commit e45e9e3998f0001079b09555db5bb3b4257f6746 ]
The KVM doesn't know whether any TLB for a specific pcid is cached in
the CPU when tdp is enabled. So it is better to flush all the guest
TLB when invalidating any single PCID context.
The case is very rare or even impossible since KVM generally doesn't
intercept CR3 write or INVPCID instructions when tdp is enabled, so the
fix is mostly for the sake of overall robustness.
Signed-off-by: Lai Jiangshan <redacted>
Message-Id: [off-list ref]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/kvm/x86.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
From: Felix Fietkau <nbd@nbd.name>
commit 18688c80ad8a8dd50523dc9276e929932cac86d4 upstream.
Since retransmission clears info->control, rate control needs to be called
again, otherwise the driver might crash due to invalid rates.
Cc: stable@vger.kernel.org # 5.14+
Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Reported-by: Robert W <redacted>
Fixes: 03c3911d2d67 ("mac80211: call ieee80211_tx_h_rate_ctrl() when dequeue")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Link: https://lore.kernel.org/r/20211122204323.9787-1-nbd@nbd.name
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mac80211/tx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/net/mac80211/tx.c+++ b/net/mac80211/tx.c
@@ -1821,15 +1821,15 @@ static int invoke_tx_handlers_late(strucstructieee80211_tx_info*info=IEEE80211_SKB_CB(tx->skb);ieee80211_tx_resultres=TX_CONTINUE;+if(!ieee80211_hw_check(&tx->local->hw,HAS_RATE_CONTROL))+CALL_TXH(ieee80211_tx_h_rate_ctrl);+if(unlikely(info->flags&IEEE80211_TX_INTFL_RETRANSMISSION)){__skb_queue_tail(&tx->skbs,tx->skb);tx->skb=NULL;gototxh_done;}-if(!ieee80211_hw_check(&tx->local->hw,HAS_RATE_CONTROL))-CALL_TXH(ieee80211_tx_h_rate_ctrl);-CALL_TXH(ieee80211_tx_h_michael_mic_add);CALL_TXH(ieee80211_tx_h_sequence);CALL_TXH(ieee80211_tx_h_fragment);
From: Felix Fietkau <nbd@nbd.name>
commit 73111efacd3c6d9e644acca1d132566932be8af0 upstream.
Some drivers that do their own sequence number allocation (e.g. ath9k) rely
on being able to modify params->ssn on starting tx ampdu sessions.
This was broken by a change that modified it to use sta->tid_seq[tid] instead.
Cc: stable@vger.kernel.org
Fixes: 31d8bb4e07f8 ("mac80211: agg-tx: refactor sending addba")
Reported-by: Eneas U de Queiroz <redacted>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20211124094024.43222-1-nbd@nbd.name
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mac80211/agg-tx.c | 4 ++--
net/mac80211/sta_info.h | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
From: Johannes Berg <redacted>
commit db7205af049d230e7e0abf61c1e74c1aab40f390 upstream.
Mark TXQs as having seen transmit while they were stopped if
we bail out of drv_wake_tx_queue() due to reconfig, so that
the queue wake after this will make them catch up. This is
particularly necessary for when TXQs are used for management
packets since those TXQs won't see a lot of traffic that'd
make them catch up later.
Cc: stable@vger.kernel.org
Fixes: 4856bfd23098 ("mac80211: do not call driver wake_tx_queue op during reconfig")
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20211129152938.4573a221c0e1.I0d1d5daea3089be3fc0dccc92991b0f8c5677f0c@changeid
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mac80211/driver-ops.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
@@ -1219,8 +1219,11 @@ static inline void drv_wake_tx_queue(str{structieee80211_sub_if_data*sdata=vif_to_sdata(txq->txq.vif);-if(local->in_reconfig)+/* In reconfig don't transmit now, but mark for waking later */+if(local->in_reconfig){+set_bit(IEEE80211_TXQ_STOP_NETIF_TX,&txq->flags);return;+}if(!check_sdata_in_driver(sdata))return;
From: Anand Jain <redacted>
Commit 6605fd2f394bba0a0059df2b6cfc87b0b6d393a2 upstream.
The test case btrfs/238 reports the warning below:
WARNING: CPU: 3 PID: 481 at fs/btrfs/super.c:2509 btrfs_show_devname+0x104/0x1e8 [btrfs]
CPU: 2 PID: 1 Comm: systemd Tainted: G W O 5.14.0-rc1-custom #72
Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
Call trace:
btrfs_show_devname+0x108/0x1b4 [btrfs]
show_mountinfo+0x234/0x2c4
m_show+0x28/0x34
seq_read_iter+0x12c/0x3c4
vfs_read+0x29c/0x2c8
ksys_read+0x80/0xec
__arm64_sys_read+0x28/0x34
invoke_syscall+0x50/0xf8
do_el0_svc+0x88/0x138
el0_svc+0x2c/0x8c
el0t_64_sync_handler+0x84/0xe4
el0t_64_sync+0x198/0x19c
Reason:
While btrfs_prepare_sprout() moves the fs_devices::devices into
fs_devices::seed_list, the btrfs_show_devname() searches for the devices
and found none, leading to the warning as in above.
Fix:
latest_dev is updated according to the changes to the device list.
That means we could use the latest_dev->name to show the device name in
/proc/self/mounts, the pointer will be always valid as it's assigned
before the device is deleted from the list in remove or replace.
The RCU protection is sufficient as the device structure is freed after
synchronization.
Reported-by: Su Yue <redacted>
Tested-by: Su Yue <redacted>
Signed-off-by: Anand Jain <redacted>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Anand Jain <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/super.c | 24 +++++-------------------
1 file changed, 5 insertions(+), 19 deletions(-)
--- a/fs/btrfs/super.c+++ b/fs/btrfs/super.c
@@ -2463,30 +2463,16 @@ static int btrfs_unfreeze(struct super_bstaticintbtrfs_show_devname(structseq_file*m,structdentry*root){structbtrfs_fs_info*fs_info=btrfs_sb(root->d_sb);-structbtrfs_device*dev,*first_dev=NULL;/*-*Lightweightlockingofthedevices.Weshouldnotneed-*device_list_mutexhereasweonlyreadthedevicedataandthelist-*isprotectedbyRCU.Evenifadeviceisdeletedduringthelist-*traversals,we'llgetvaliddata,thefreeingcallbackwillwaitat-*leastuntilthercu_read_unlock.+*Thereshouldbealwaysavalidpointerinlatest_dev,itmaybestale+*forashortmomentincaseit'sbeingdeletedbutstillvaliduntil+*theendofRCUgraceperiod.*/rcu_read_lock();-list_for_each_entry_rcu(dev,&fs_info->fs_devices->devices,dev_list){-if(test_bit(BTRFS_DEV_STATE_MISSING,&dev->dev_state))-continue;-if(!dev->name)-continue;-if(!first_dev||dev->devid<first_dev->devid)-first_dev=dev;-}--if(first_dev)-seq_escape(m,rcu_str_deref(first_dev->name)," \t\n\\");-else-WARN_ON(1);+seq_escape(m,rcu_str_deref(fs_info->fs_devices->latest_dev->name)," \t\n\\");rcu_read_unlock();+return0;}
From: Alex Bee <redacted>
[ Upstream commit 8240e87f16d17a9592c9d67857a3dcdbcb98f10d ]
As stated in the schematics [1] and [2] P5 the APIO5 domain is supplied
by RK808-D Buck4, which in our case vcc1v8_codec - i.e. a 1.8 V regulator.
Currently only white noise comes from the ES8316's output, which - for
whatever reason - came up only after the the correct switch from i2s0_8ch_bus
to i2s0_2ch_bus for i2s0's pinctrl was done.
Fix this by setting the correct regulator for audio-supply.
[1] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/rockpi4_v13_sch_20181112.pdf
[2] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/rockpi_4c_v12_sch_20200620.pdf
Fixes: 1b5715c602fd ("arm64: dts: rockchip: add ROCK Pi 4 DTS support")
Signed-off-by: Alex Bee <redacted>
Link: https://lore.kernel.org/r/20211027143726.165809-1-knaerzche@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Johannes Berg <redacted>
[ Upstream commit d5e568c3a4ec2ddd23e7dc5ad5b0c64e4f22981a ]
For admission control, obviously all of that only works for
QoS data frames, otherwise we cannot even access the QoS
field in the header.
Syzbot reported (see below) an uninitialized value here due
to a status of a non-QoS nullfunc packet, which isn't even
long enough to contain the QoS header.
Fix this to only do anything for QoS data packets.
Reported-by: syzbot+614e82b88a1a4973e534@syzkaller.appspotmail.com
Fixes: 02219b3abca5 ("mac80211: add WMM admission control support")
Link: https://lore.kernel.org/r/20211122124737.dad29e65902a.Ieb04587afacb27c14e0de93ec1bfbefb238cc2a0@changeid
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/mlme.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
From: Randy Dunlap <redacted>
[ Upstream commit 1dc2f2b81a6a9895da59f3915760f6c0c3074492 ]
The hyperv utilities use PTP clock interfaces and should depend a
a kconfig symbol such that they will be built as a loadable module or
builtin so that linker errors do not happen.
Prevents these build errors:
ld: drivers/hv/hv_util.o: in function `hv_timesync_deinit':
hv_util.c:(.text+0x37d): undefined reference to `ptp_clock_unregister'
ld: drivers/hv/hv_util.o: in function `hv_timesync_init':
hv_util.c:(.text+0x738): undefined reference to `ptp_clock_register'
Fixes: 3716a49a81ba ("hv_utils: implement Hyper-V PTP source")
Signed-off-by: Randy Dunlap <redacted>
Reported-by: kernel test robot <redacted>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <redacted>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: linux-hyperv@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Michael Kelley <redacted>
Link: https://lore.kernel.org/r/20211126023316.25184-1-rdunlap@infradead.org
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hv/Kconfig | 1 +
1 file changed, 1 insertion(+)
From: Martin Kepplinger <redacted>
[ Upstream commit e5e6268f77badf18bd6ab435364cfe21c7396c31 ]
The mxsfb driver handling imx8mq lcdif doesn't yet request the
interconnect bandwidth that's needed at runtime when the description is
present in the DT node.
So remove that description and bring it back when it's supported.
Fixes: ad1abc8a03fd ("arm64: dts: imx8mq: Add interconnect for lcdif")
Signed-off-by: Martin Kepplinger <redacted>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 --
1 file changed, 2 deletions(-)
From: Mike Tipton <redacted>
[ Upstream commit 54baf56eaa40aa5cdcd02b3c20d593e4e1211220 ]
Before commit fc0c209c147f ("clk: Allow parents to be specified without
string names") child clks couldn't find their parent until the parent
clk was added to a list in __clk_core_init(). After that commit, child
clks can reference their parent clks directly via a clk_hw pointer, or
they can lookup that clk_hw pointer via DT if the parent clk is
registered with an OF clk provider.
The common clk framework treats hw->core being non-NULL as "the clk is
registered" per the logic within clk_core_fill_parent_index():
parent = entry->hw->core;
/*
* We have a direct reference but it isn't registered yet?
* Orphan it and let clk_reparent() update the orphan status
* when the parent is registered.
*/
if (!parent)
Therefore we need to be extra careful to not set hw->core until the clk
is fully registered with the clk framework. Otherwise we can get into a
situation where a child finds a parent clk and we move the child clk off
the orphan list when the parent isn't actually registered, wrecking our
enable accounting and breaking critical clks.
Consider the following scenario:
CPU0 CPU1
---- ----
struct clk_hw clkBad;
struct clk_hw clkA;
clkA.init.parent_hws = { &clkBad };
clk_hw_register(&clkA) clk_hw_register(&clkBad)
... __clk_register()
hw->core = core
...
__clk_register()
__clk_core_init()
clk_prepare_lock()
__clk_init_parent()
clk_core_get_parent_by_index()
clk_core_fill_parent_index()
if (entry->hw) {
parent = entry->hw->core;
At this point, 'parent' points to clkBad even though clkBad hasn't been
fully registered yet. Ouch! A similar problem can happen if a clk
controller registers orphan clks that are referenced in the DT node of
another clk controller.
Let's fix all this by only setting the hw->core pointer underneath the
clk prepare lock in __clk_core_init(). This way we know that
clk_core_fill_parent_index() can't see hw->core be non-NULL until the
clk is fully registered.
Fixes: fc0c209c147f ("clk: Allow parents to be specified without string names")
Signed-off-by: Mike Tipton <redacted>
Link: https://lore.kernel.org/r/20211109043438.4639-1-quic_mdtipton@quicinc.com
[sboyd@kernel.org: Reword commit text, update comment]
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/clk/clk.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
From: Stephan Gerhold <stephan@gerhold.net>
[ Upstream commit 4ebd29f91629e69da7d57390cdc953772eee03ab ]
At the moment, using the ARM32 multi_v7_defconfig always results in two
SoCs being exposed in sysfs. This is wrong, as far as I'm aware the
Qualcomm DragonBoard 410c does not actually make use of a i.MX SoC. :)
qcom-db410c:/sys/devices/soc0$ grep . *
family:Freescale i.MX
machine:Qualcomm Technologies, Inc. APQ 8016 SBC
revision:0.0
serial_number:0000000000000000
soc_id:Unknown
qcom-db410c:/sys/devices/soc1$ grep . *
family:Snapdragon
machine:APQ8016
...
This happens because imx_soc_device_init() registers the soc device
unconditionally, even when running on devices that do not make use of i.MX.
Arnd already reported this more than a year ago and even suggested a fix
similar to this commit, but for some reason it was never submitted.
Fix it by checking if the "__mxc_cpu_type" variable was actually
initialized by earlier platform code. On devices without i.MX it will
simply stay 0.
Cc: Peng Fan <peng.fan@nxp.com>
Fixes: d2199b34871b ("ARM: imx: use device_initcall for imx_soc_device_init")
Reported-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/CAK8P3a0hxO1TmK6oOMQ70AHSWJnP_CAq57YMOutrxkSYNjFeuw@mail.gmail.com/
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/soc/imx/soc-imx.c | 4 ++++
1 file changed, 4 insertions(+)
@@ -36,6 +36,10 @@ static int __init imx_soc_device_init(void)intret;inti;+/* Return early if this is running on devices with different SoCs */+if(!__mxc_cpu_type)+return0;+if(of_machine_is_compatible("fsl,ls1021a"))return0;
From: Johannes Berg <redacted>
[ Upstream commit d599f714b73e4177dfdfe64fce09175568288ee9 ]
If we get to the WARN_ONCE(..., "Got a HT rate (...)", ...)
here with a NULL sta, then we crash because mvmsta is bad
and we try to dereference it. Fix that by printing -1 as the
state if no station was given.
Signed-off-by: Johannes Berg <redacted>
Fixes: 6761a718263a ("iwlwifi: mvm: add explicit check for non-data frames in get Tx rate")
Signed-off-by: Luca Coelho <redacted>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20211203140410.1a1541d7dcb5.I606c746e11447fe168cf046376b70b04e278c3b4@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
@@ -268,17 +268,18 @@ static u32 iwl_mvm_get_tx_rate(struct iwl_mvm *mvm,intrate_idx=-1;u8rate_plcp;u32rate_flags=0;-structiwl_mvm_sta*mvmsta=iwl_mvm_sta_from_mac80211(sta);/* info->control is only relevant for non HW rate control */if(!ieee80211_hw_check(mvm->hw,HAS_RATE_CONTROL)){+structiwl_mvm_sta*mvmsta=iwl_mvm_sta_from_mac80211(sta);+/* HT rate doesn't make sense for a non data frame */WARN_ONCE(info->control.rates[0].flags&IEEE80211_TX_RC_MCS&&!ieee80211_is_data(fc),"Got a HT rate (flags:0x%x/mcs:%d/fc:0x%x/state:%d) for a non data frame\n",info->control.rates[0].flags,info->control.rates[0].idx,-le16_to_cpu(fc),mvmsta->sta_state);+le16_to_cpu(fc),sta?mvmsta->sta_state:-1);rate_idx=info->control.rates[0].idx;}
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit 27d9839f17940e8edc475df616bbd9cf7ede8d05 ]
When neither VIRTIO_PCI_LIB nor VIRTIO are enabled, but the alibaba
vdpa driver is, the kernel runs into a link error because the legacy
virtio module never gets built:
x86_64-linux-ld: drivers/vdpa/alibaba/eni_vdpa.o: in function `eni_vdpa_set_features':
eni_vdpa.c:(.text+0x23f): undefined reference to `vp_legacy_set_features'
x86_64-linux-ld: drivers/vdpa/alibaba/eni_vdpa.o: in function `eni_vdpa_set_vq_state':
eni_vdpa.c:(.text+0x2fe): undefined reference to `vp_legacy_get_queue_enable'
x86_64-linux-ld: drivers/vdpa/alibaba/eni_vdpa.o: in function `eni_vdpa_set_vq_address':
eni_vdpa.c:(.text+0x376): undefined reference to `vp_legacy_set_queue_address'
x86_64-linux-ld: drivers/vdpa/alibaba/eni_vdpa.o: in function `eni_vdpa_set_vq_ready':
eni_vdpa.c:(.text+0x3b4): undefined reference to `vp_legacy_set_queue_address'
x86_64-linux-ld: drivers/vdpa/alibaba/eni_vdpa.o: in function `eni_vdpa_free_irq':
eni_vdpa.c:(.text+0x460): undefined reference to `vp_legacy_queue_vector'
x86_64-linux-ld: eni_vdpa.c:(.text+0x4b7): undefined reference to `vp_legacy_config_vector'
x86_64-linux-ld: drivers/vdpa/alibaba/eni_vdpa.o: in function `eni_vdpa_reset':
When VIRTIO_PCI_LIB was added, it was correctly added to drivers/Makefile
as well, but for the legacy module, this is missing. Solve this by always
entering drivers/virtio during the build and letting its Makefile take
care of the individual options, rather than having a separate line for
each sub-option.
Fixes: 64b9f64f80a6 ("vdpa: introduce virtio pci driver")
Fixes: e85087beedca ("eni_vdpa: add vDPA driver for Alibaba ENI")
Fixes: d89c8169bd70 ("virtio-pci: introduce legacy device module")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20211206085034.2836099-1-arnd@kernel.org
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/Makefile | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
From: Parav Pandit <redacted>
[ Upstream commit bb47620be322c5e9e372536cb6b54e17b3a00258 ]
virtio device id value can be more than 31. Hence, use BIT_ULL in
assignment.
Fixes: 33b347503f01 ("vdpa: Define vdpa mgmt device, ops and a netlink interface")
Reported-by: kernel test robot <redacted>
Reported-by: Dan Carpenter <redacted>
Signed-off-by: Parav Pandit <redacted>
Acked-by: Jason Wang <redacted>
Link: https://lore.kernel.org/r/20211130042949.88958-1-parav@nvidia.com
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/vdpa/vdpa.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
@@ -2191,7 +2191,7 @@ ipv6_ping_vrf()log_startshow_hint"Fails since VRF device does not support linklocal or multicast"run_cmd${ping6}-c1-w1${a}-log_test_addr${a}$?2"ping out, VRF bind"+log_test_addr${a}$?1"ping out, VRF bind"doneforain${NSB_IP6}${NSB_LO_IP6}${NSB_LINKIP6}%${NSA_DEV}${MCAST}%${NSA_DEV}
From: Anand Jain <redacted>
Commit cdccc03a8a369b59cff5e7ea3292511cfa551120 upstream.
There were few lockdep warnings because btrfs_show_devname() was using
device_list_mutex as recorded in the commits:
0ccd05285e7f ("btrfs: fix a possible umount deadlock")
779bf3fefa83 ("btrfs: fix lock dep warning, move scratch dev out of device_list_mutex and uuid_mutex")
And finally, commit 88c14590cdd6 ("btrfs: use RCU in btrfs_show_devname
for device list traversal") removed the device_list_mutex from
btrfs_show_devname for performance reasons.
This patch removes a stale comment about the function
btrfs_show_devname and device_list_mutex.
Signed-off-by: Anand Jain <redacted>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Anand Jain <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/volumes.c | 7 -------
1 file changed, 7 deletions(-)
From: Filip Pokryvka <redacted>
[ Upstream commit ee60e626d536da4c710b3634afe68fe7c6d69b59 ]
Ethtool ring feature has _max_pending attributes read-only.
Set only read-write attributes in nsim_set_ringparam.
This patch is useful, if netdevsim device is set-up using NetworkManager,
because NetworkManager sends 0 as MAX values, as it is pointless to
retrieve them in extra call, because they should be read-only. Then,
the device is left in incosistent state (value > MAX).
Fixes: a7fc6db099b5 ("netdevsim: support ethtool ring and coalesce settings")
Signed-off-by: Filip Pokryvka <redacted>
Link: https://lore.kernel.org/r/20211210175032.411872-1-fpokryvk@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/netdevsim/ethtool.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
From: Mario Limonciello <mario.limonciello@amd.com>
commit 2d54067fcd23aae61e23508425ae5b29e973573d upstream.
On some Lenovo AMD Gen2 platforms the IRQ for the SCI and pinctrl drivers
are shared. Due to how the s2idle loop handling works, this case needs
an extra explicit check whether the interrupt was caused by SCI or by
the GPIO controller.
To fix this rework the existing IRQ handler function to function as a
checker and an IRQ handler depending on the calling arguments.
BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1738
Reported-by: Joerie de Gram <redacted>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Acked-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Link: https://lore.kernel.org/r/20211101014853.6177-2-mario.limonciello@amd.com
Signed-off-by: Linus Walleij <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pinctrl/pinctrl-amd.c | 29 ++++++++++++++++++++++++++---
1 file changed, 26 insertions(+), 3 deletions(-)
@@ -627,6 +627,14 @@ static irqreturn_t amd_gpio_irq_handler(/* Each status bit covers four pins */for(i=0;i<4;i++){regval=readl(regs+i);+/* caused wake on resume context for shared IRQ */+if(irq<0&&(regval&BIT(WAKE_STS_OFF))){+dev_dbg(&gpio_dev->pdev->dev,+"Waking due to GPIO %d: 0x%x",+irqnr+i,regval);+returntrue;+}+if(!(regval&PIN_IRQ_PENDING)||!(regval&BIT(INTERRUPT_MASK_OFF)))continue;
@@ -650,9 +658,12 @@ static irqreturn_t amd_gpio_irq_handler(}writel(regval,regs+i);raw_spin_unlock_irqrestore(&gpio_dev->lock,flags);-ret=IRQ_HANDLED;+ret=true;}}+/* did not cause wake on resume context for shared IRQ */+if(irq<0)+returnfalse;/* Signal EOI to the GPIO unit */raw_spin_lock_irqsave(&gpio_dev->lock,flags);
From: Ville Syrjälä <redacted>
commit cecbc0c7eba7983965cac94f88d2db00b913253b upstream.
Looks like our VBIOS/GOP generally fail to turn the DP dual mode adater
TMDS output buffers back on after a reboot. This leads to a black screen
after reboot if we turned the TMDS output buffers off prior to reboot.
And if i915 decides to do a fastboot the black screen will persist even
after i915 takes over.
Apparently this has been a problem ever since commit b2ccb822d376 ("drm/i915:
Enable/disable TMDS output buffers in DP++ adaptor as needed") if one
rebooted while the display was turned off. And things became worse with
commit fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot")
since now we always turn the display off before a reboot.
This was reported on a RKL, but I confirmed the same behaviour on my
SNB as well. So looks pretty universal.
Let's fix this by explicitly turning the TMDS output buffers back on
in the encoder->shutdown() hook. Note that this gets called after irqs
have been disabled, so the i2c communication with the DP dual mode
adapter has to be performed via polling (which the gmbus code is
perfectly happy to do for us).
We also need a bit of care in handling DDI encoders which may or may
not be set up for HDMI output. Specifically ddc_pin will not be
populated for a DP only DDI encoder, in which case we don't want to
call intel_gmbus_get_adapter(). We can handle that by simply doing
the dual mode adapter type check before calling
intel_gmbus_get_adapter().
Cc: <redacted> # v5.11+
Fixes: fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4371
Signed-off-by: Ville Syrjälä <redacted>
Link: https://patchwork.freedesktop.org/patch/msgid/20211029191802.18448-2-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <redacted>
(cherry picked from commit 49c55f7b035b87371a6d3c53d9af9f92ddc962db)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/display/g4x_hdmi.c | 1 +
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 16 ++++++++++++++--
drivers/gpu/drm/i915/display/intel_hdmi.h | 1 +
4 files changed, 17 insertions(+), 2 deletions(-)
From: Hangbin Liu <redacted>
[ Upstream commit 71da1aec215290e249d09c44c768df859f3a3bba ]
The recent GRE selftests defined NUM_NETIFS=10. If the users copy
forwarding.config.sample to forwarding.config directly, they will get
error "Command line is not complete" when run the GRE tests, because
create_netif_veth() failed with no interface name defined.
Fix it by extending the NETIFS with p9 and p10.
Fixes: 2800f2485417 ("selftests: forwarding: Test multipath hashing on inner IP pkts for GRE tunnel")
Signed-off-by: Hangbin Liu <redacted>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/net/forwarding/forwarding.config.sample | 2 ++
1 file changed, 2 insertions(+)
@@ -13,6 +13,8 @@ NETIFS[p5]=veth4 NETIFS[p6]=veth5 NETIFS[p7]=veth6 NETIFS[p8]=veth7+NETIFS[p9]=veth8+NETIFS[p10]=veth9 # Port that does not have a cable connected. NETIF_NO_CABLE=eth8
From: Marek Behún <kabel@kernel.org>
[ Upstream commit 9d591fc028b6bddb38c6585874f331267cbdadae ]
Commit 64d47d50be7a ("net: dsa: mv88e6xxx: configure interface settings
in mac_config") removed forcing of speed and duplex from
mv88e6xxx_mac_config(), where the link is forced down, and left it only
in mv88e6xxx_mac_link_up(), by which time link is unforced.
It seems that (at least on 88E6190) when changing cmode to 2500base-x,
if the link is not forced down, but the speed or duplex are still
forced, the forcing of new settings for speed & duplex doesn't take in
mv88e6xxx_mac_link_up().
Fix this by unforcing speed & duplex in mv88e6xxx_mac_link_down().
Fixes: 64d47d50be7a ("net: dsa: mv88e6xxx: configure interface settings in mac_config")
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Russell King (Oracle) <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/dsa/mv88e6xxx/chip.c | 4 ++++
1 file changed, 4 insertions(+)
From: Ilan Peer <redacted>
[ Upstream commit e08ebd6d7b90ae81f21425ca39136f5b2272580f ]
The function cfg80211_reg_can_beacon_relax() expects wiphy
mutex to be held when it is being called. However, when
reg_leave_invalid_chans() is called the mutex is not held.
Fix it by acquiring the lock before calling the function.
Fixes: a05829a7222e ("cfg80211: avoid holding the RTNL when calling the driver")
Signed-off-by: Ilan Peer <redacted>
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20211202152831.527686cda037.I40ad9372a47cbad53b4aae7b5a6ccc0dc3fddf8b@changeid
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/wireless/reg.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
From: Harshit Mogalapalli <redacted>
[ Upstream commit 53b3495273282aa844c4613d19c3b30558c70c84 ]
smatch warning:
drivers/gpu/drm/i915/display/intel_dmc.c:601 parse_dmc_fw() warn:
unsigned 'fw->size - offset' is never less than zero
Firmware size is size_t and offset is u32. So the subtraction is
unsigned which can never be less than zero.
Fixes: 3d5928a168a9 ("drm/i915/xelpd: Pipe A DMC plugging")
Signed-off-by: Harshit Mogalapalli <redacted>
Reviewed-by: Lucas De Marchi <redacted>
Signed-off-by: Lucas De Marchi <redacted>
Link: https://patchwork.freedesktop.org/patch/msgid/20211210044129.12422-1-harshit.m.mogalapalli@oracle.com
(cherry picked from commit 87bb2a410dcfb617b88e4695edf4beb6336dc314)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/i915/display/intel_dmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: David Ahern <dsahern@kernel.org>
[ Upstream commit 7e0147592b5c4f9e2eb8c54a7857a56d4863f74e ]
Commit referenced below added configuration in the default VRF that
duplicates a VRF to check MD5 passwords are properly used and fail
when expected. That config should not be added all the time as it
can cause tests to pass that should not (by matching on default VRF
setup when it should not). Move the duplicate setup to a function
that is only called for the MD5 tests and add a cleanup function
to remove it after the MD5 tests.
Fixes: 5cad8bce26e0 ("fcnal-test: Add TCP MD5 tests for VRF")
Signed-off-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/net/fcnal-test.sh | 26 +++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
@@ -455,6 +455,22 @@ cleanup()ipnetnsdel${NSC}>/dev/null2>&1}+cleanup_vrf_dup()+{+iplinkdel${NSA_DEV2}>/dev/null2>&1+ipnetnspids${NSC}|xargskill2>/dev/null+ipnetnsdel${NSC}>/dev/null2>&1+}++setup_vrf_dup()+{+# some VRF tests use ns-C which has the same config as+# ns-B but for a device NOT in the VRF+create_ns${NSC}"-""-"+connect_ns${NSA}${NSA_DEV2}${NSA_IP}/24${NSA_IP6}/64\+${NSC}${NSC_DEV}${NSB_IP}/24${NSB_IP6}/64+}+ setup(){localwith_vrf=${1}
@@ -484,12 +500,6 @@ setup()ip-netns${NSB}roadd${VRF_IP}/32via${NSA_IP}dev${NSB_DEV}ip-netns${NSB}-6roadd${VRF_IP6}/128via${NSA_IP6}dev${NSB_DEV}--# some VRF tests use ns-C which has the same config as-# ns-B but for a device NOT in the VRF-create_ns${NSC}"-""-"-connect_ns${NSA}${NSA_DEV2}${NSA_IP}/24${NSA_IP6}/64\-${NSC}${NSC_DEV}${NSB_IP}/24${NSB_IP6}/64elseip-netns${NSA}roadd${NSB_LO_IP}/32via${NSB_IP}dev${NSA_DEV}ip-netns${NSA}roadd${NSB_LO_IP6}/128via${NSB_IP6}dev${NSA_DEV}
@@ -1240,7 +1250,9 @@ ipv4_tcp_vrf()log_test_addr${a}$?1"Global server, local connection"# run MD5 tests+setup_vrf_dupipv4_tcp_md5+cleanup_vrf_dup## enable VRF global server
@@ -2719,7 +2731,9 @@ ipv6_tcp_vrf()log_test_addr${a}$?1"Global server, local connection"# run MD5 tests+setup_vrf_dupipv6_tcp_md5+cleanup_vrf_dup## enable VRF global server
From: Javier Martinez Canillas <javierm@redhat.com>
[ Upstream commit 842470c4e211f284a224842849b1fa81b130c154 ]
This reverts commit b3484d2b03e4c940a9598aa841a52d69729c582a.
That change attempted to improve the DRM drivers fbdev emulation device
names to avoid having confusing names like "simpledrmdrmfb" in /proc/fb.
But unfortunately, there are user-space programs such as pm-utils that
match against the fbdev names and so broke after the mentioned commit.
Since the names in /proc/fb are used by tools that consider it an uAPI,
let's restore the old names even when this lead to silly names like the
one mentioned above.
Fixes: b3484d2b03e4 ("drm/fb-helper: improve DRM fbdev emulation device names")
Reported-by: Johannes Stezenbach <redacted>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Ville Syrjälä <redacted>
Link: https://patchwork.freedesktop.org/patch/msgid/20211020165740.3011927-1-javierm@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/drm_fb_helper.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
@@ -246,7 +246,11 @@ struct btrfs_fs_devices {/* Highest generation number of seen devices */u64latest_generation;-structblock_device*latest_bdev;+/*+*Themountdeviceoradevicewithhighestgenerationafterremoval+*orreplace.+*/+structbtrfs_device*latest_dev;/* all of the devices in the FS, protected by a mutex*sowecansafelywalkittowriteoutthesuperswithout
From: Karol Kolacinski <redacted>
[ Upstream commit 37e738b6fdb14529534dca441e0222313688fde3 ]
The driver has to check if it does not accidentally put the timestamp in
the SKB before previous timestamp gets overwritten.
Timestamp values in the PHY are read only and do not get cleared except
at hardware reset or when a new timestamp value is captured.
The cached_tstamp field is used to detect the case where a new timestamp
has not yet been captured, ensuring that we avoid sending stale
timestamp data to the stack.
Fixes: ea9b847cda64 ("ice: enable transmit timestamps for E810 devices")
Signed-off-by: Karol Kolacinski <redacted>
Tested-by: Gurucharan G <redacted>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/ice/ice_ptp.c | 11 ++++-------
drivers/net/ethernet/intel/ice/ice_ptp.h | 6 ++++++
2 files changed, 10 insertions(+), 7 deletions(-)
@@ -1182,19 +1182,16 @@ static void ice_ptp_tx_tstamp_work(struct kthread_work *work)if(err)continue;-/* Check if the timestamp is valid */-if(!(raw_tstamp&ICE_PTP_TS_VALID))+/* Check if the timestamp is invalid or stale */+if(!(raw_tstamp&ICE_PTP_TS_VALID)||+raw_tstamp==tx->tstamps[idx].cached_tstamp)continue;-/* clear the timestamp register, so that it won't show valid-*againwhenre-used.-*/-ice_clear_phy_tstamp(hw,tx->quad,phy_idx);-/* The timestamp is valid, so we'll go ahead and clear this*indexandthensendthetimestampuptothestack.*/spin_lock(&tx->lock);+tx->tstamps[idx].cached_tstamp=raw_tstamp;clear_bit(idx,tx->in_use);skb=tx->tstamps[idx].skb;tx->tstamps[idx].skb=NULL;
From: Nathan Chancellor <nathan@kernel.org>
[ Upstream commit a7083763619f7485ccdade160deb81737cf2732f ]
A new warning in clang points out two instances where boolean
expressions are being used with a bitwise OR instead of logical OR:
drivers/soc/tegra/fuse/speedo-tegra20.c:72:9: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
reg = tegra_fuse_read_spare(i) |
^~~~~~~~~~~~~~~~~~~~~~~~~~
||
drivers/soc/tegra/fuse/speedo-tegra20.c:72:9: note: cast one or both operands to int to silence this warning
drivers/soc/tegra/fuse/speedo-tegra20.c:87:9: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
reg = tegra_fuse_read_spare(i) |
^~~~~~~~~~~~~~~~~~~~~~~~~~
||
drivers/soc/tegra/fuse/speedo-tegra20.c:87:9: note: cast one or both operands to int to silence this warning
2 warnings generated.
The motivation for the warning is that logical operations short circuit
while bitwise operations do not.
In this instance, tegra_fuse_read_spare() is not semantically returning
a boolean, it is returning a bit value. Use u32 for its return type so
that it can be used with either bitwise or boolean operators without any
warnings.
Fixes: 25cd5a391478 ("ARM: tegra: Add speedo-based process identification")
Link: https://github.com/ClangBuiltLinux/linux/issues/1488
Suggested-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Thierry Reding <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/soc/tegra/fuse/fuse-tegra.c | 2 +-
drivers/soc/tegra/fuse/fuse.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
@@ -1549,7 +1549,7 @@ void __mptcp_push_pending(struct sock *sk, unsigned int flags)intret=0;prev_ssk=ssk;-mptcp_flush_join_list(msk);+__mptcp_flush_join_list(msk);ssk=mptcp_subflow_get_send(msk);/* First check. If the ssk has changed since
From: Nicholas Kazlauskas <redacted>
[ Upstream commit 7e4d2f30df3fb48f75ce9e96867d42bdddab83ac ]
[Why]
SMU now respects the PHY refclk disable request from driver.
This causes a hang during hotplug when PHY refclk was disabled
because it's not being re-enabled and the transmitter control
starts on dc_link_detect.
[How]
We normally would re-enable the clk with exit_optimized_pwr_state
but this is only set on DCN21 and DCN301. Set it for dcn31 as well.
This fixes DMCUB timeouts in the PHY.
Fixes: 64b1d0e8d500 ("drm/amd/display: Add DCN3.1 HWSEQ")
Reviewed-by: Eric Yang <redacted>
Acked-by: Pavle Kotarac <redacted>
Tested-by: Daniel Wheeler <redacted>
Signed-off-by: Nicholas Kazlauskas <redacted>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c | 1 +
1 file changed, 1 insertion(+)
@@ -7641,6 +7641,20 @@ static int igb_set_vf_mac_filter(struct igb_adapter *adapter, const int vf,structvf_mac_filter*entry=NULL;intret=0;+if((vf_data->flags&IGB_VF_FLAG_PF_SET_MAC)&&+!vf_data->trusted){+dev_warn(&pdev->dev,+"VF %d requested MAC filter but is administratively denied\n",+vf);+return-EINVAL;+}+if(!is_valid_ether_addr(addr)){+dev_warn(&pdev->dev,+"VF %d attempted to set invalid MAC filter\n",+vf);+return-EINVAL;+}+switch(info){caseE1000_VF_MAC_FILTER_CLR:/* remove all unicast MAC filters related to the current VF */
@@ -7654,20 +7668,6 @@ static int igb_set_vf_mac_filter(struct igb_adapter *adapter, const int vf,}break;caseE1000_VF_MAC_FILTER_ADD:-if((vf_data->flags&IGB_VF_FLAG_PF_SET_MAC)&&-!vf_data->trusted){-dev_warn(&pdev->dev,-"VF %d requested MAC filter but is administratively denied\n",-vf);-return-EINVAL;-}-if(!is_valid_ether_addr(addr)){-dev_warn(&pdev->dev,-"VF %d attempted to set invalid MAC filter\n",-vf);-return-EINVAL;-}-/* try to find empty slot in the list */list_for_each(pos,&adapter->vf_macs.l){entry=list_entry(pos,structvf_mac_filter,l);
From: Letu Ren <redacted>
[ Upstream commit b6d335a60dc624c0d279333b22c737faa765b028 ]
In `igbvf_probe`, if register_netdev() fails, the program will go to
label err_hw_init, and then to label err_ioremap. In free_netdev() which
is just below label err_ioremap, there is `list_for_each_entry_safe` and
`netif_napi_del` which aims to delete all entries in `dev->napi_list`.
The program has added an entry `adapter->rx_ring->napi` which is added by
`netif_napi_add` in igbvf_alloc_queues(). However, adapter->rx_ring has
been freed below label err_hw_init. So this a UAF.
In terms of how to patch the problem, we can refer to igbvf_remove() and
delete the entry before `adapter->rx_ring`.
The KASAN logs are as follows:
[ 35.126075] BUG: KASAN: use-after-free in free_netdev+0x1fd/0x450
[ 35.127170] Read of size 8 at addr ffff88810126d990 by task modprobe/366
[ 35.128360]
[ 35.128643] CPU: 1 PID: 366 Comm: modprobe Not tainted 5.15.0-rc2+ #14
[ 35.129789] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[ 35.131749] Call Trace:
[ 35.132199] dump_stack_lvl+0x59/0x7b
[ 35.132865] print_address_description+0x7c/0x3b0
[ 35.133707] ? free_netdev+0x1fd/0x450
[ 35.134378] __kasan_report+0x160/0x1c0
[ 35.135063] ? free_netdev+0x1fd/0x450
[ 35.135738] kasan_report+0x4b/0x70
[ 35.136367] free_netdev+0x1fd/0x450
[ 35.137006] igbvf_probe+0x121d/0x1a10 [igbvf]
[ 35.137808] ? igbvf_vlan_rx_add_vid+0x100/0x100 [igbvf]
[ 35.138751] local_pci_probe+0x13c/0x1f0
[ 35.139461] pci_device_probe+0x37e/0x6c0
[ 35.165526]
[ 35.165806] Allocated by task 366:
[ 35.166414] ____kasan_kmalloc+0xc4/0xf0
[ 35.167117] foo_kmem_cache_alloc_trace+0x3c/0x50 [igbvf]
[ 35.168078] igbvf_probe+0x9c5/0x1a10 [igbvf]
[ 35.168866] local_pci_probe+0x13c/0x1f0
[ 35.169565] pci_device_probe+0x37e/0x6c0
[ 35.179713]
[ 35.179993] Freed by task 366:
[ 35.180539] kasan_set_track+0x4c/0x80
[ 35.181211] kasan_set_free_info+0x1f/0x40
[ 35.181942] ____kasan_slab_free+0x103/0x140
[ 35.182703] kfree+0xe3/0x250
[ 35.183239] igbvf_probe+0x1173/0x1a10 [igbvf]
[ 35.184040] local_pci_probe+0x13c/0x1f0
Fixes: d4e0fe01a38a0 (igbvf: add new driver to support 82576 virtual functions)
Reported-by: Zheyu Ma <redacted>
Signed-off-by: Letu Ren <redacted>
Tested-by: Konrad Jankowski <redacted>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/igbvf/netdev.c | 1 +
1 file changed, 1 insertion(+)
From: David Ahern <dsahern@kernel.org>
[ Upstream commit 0f108ae4452025fef529671998f6c7f1c4526790 ]
Commit referenced below added negative socket bind tests for VRF. The
socket binds should fail since the address to bind to is in a VRF yet
the socket is not bound to the VRF or a device within it. Update the
expected return code to check for 1 (bind failure) so the test passes
when the bind fails as expected. Add a 'show_hint' comment to explain
why the bind is expected to fail.
Fixes: 75b2b2b3db4c ("selftests: Add ipv4 address bind tests to fcnal-test")
Reported-by: Li Zhijian <redacted>
Signed-off-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/net/fcnal-test.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
@@ -1810,8 +1810,9 @@ ipv4_addr_bind_vrf()forain${NSA_IP}${VRF_IP}dolog_start+show_hint"Socket not bound to VRF, but address is in VRF"run_cmdnettest-s-R-Picmp-l${a}-b-log_test_addr${a}$?0"Raw socket bind to local address"+log_test_addr${a}$?1"Raw socket bind to local address"log_startrun_cmdnettest-s-R-Picmp-l${a}-I${NSA_DEV}-b
From: Sasha Neftin <redacted>
[ Upstream commit 0182d1f3fa640888a2ed7e3f6df2fdb10adee7c8 ]
The LTR maximum value was incorrectly written using the scale from
the LTR minimum value. This would cause incorrect values to be sent,
in cases where the initial calculation lead to different min/max scales.
Fixes: 707abf069548 ("igc: Add initial LTR support")
Suggested-by: Dima Ruinskiy <redacted>
Signed-off-by: Sasha Neftin <redacted>
Tested-by: Nechama Kraus <redacted>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/igc/igc_i225.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Haimin Zhang <redacted>
[ Upstream commit 481221775d53d6215a6e5e9ce1cce6d2b4ab9a46 ]
Zero-initialize memory for new map's value in function nsim_bpf_map_alloc
since it may cause a potential kernel information leak issue, as follows:
1. nsim_bpf_map_alloc calls nsim_map_alloc_elem to allocate elements for
a new map.
2. nsim_map_alloc_elem uses kmalloc to allocate map's value, but doesn't
zero it.
3. A user application can use IOCTL BPF_MAP_LOOKUP_ELEM to get specific
element's information in the map.
4. The kernel function map_lookup_elem will call bpf_map_copy_value to get
the information allocated at step-2, then use copy_to_user to copy to the
user buffer.
This can only leak information for an array map.
Fixes: 395cacb5f1a0 ("netdevsim: bpf: support fake map offload")
Suggested-by: Jakub Kicinski <kuba@kernel.org>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Haimin Zhang <redacted>
Link: https://lore.kernel.org/r/20211215111530.72103-1-tcs.kernel@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/netdevsim/bpf.c | 1 +
1 file changed, 1 insertion(+)
From: David Ahern <dsahern@kernel.org>
[ Upstream commit 28a2686c185e84b6aa6a4d9c9a972360eb7ca266 ]
IPv6 allows binding a socket to a device then binding to an address
not on the device (__inet6_bind -> ipv6_chk_addr with strict flag
not set). Update the bind tests to reflect legacy behavior.
Fixes: 34d0302ab861 ("selftests: Add ipv6 address bind tests to fcnal-test")
Reported-by: Li Zhijian <redacted>
Signed-off-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/net/fcnal-test.sh | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
@@ -3429,11 +3429,14 @@ ipv6_addr_bind_novrf()run_cmdnettest-6-s-l${a}-I${NSA_DEV}-t1-blog_test_addr${a}$?0"TCP socket bind to local address after device bind"+# Sadly, the kernel allows binding a socket to a device and then+# binding to an address not on the device. So this test passes+# when it really should nota=${NSA_LO_IP6}log_start-show_hint"Should fail with 'Cannot assign requested address'"+show_hint"Tecnically should fail since address is not on device but kernel allows"run_cmdnettest-6-s-l${a}-I${NSA_DEV}-t1-b-log_test_addr${a}$?1"TCP socket bind to out of scope local address"+log_test_addr${a}$?0"TCP socket bind to out of scope local address"} ipv6_addr_bind_vrf()
@@ -3474,10 +3477,15 @@ ipv6_addr_bind_vrf()run_cmdnettest-6-s-l${a}-I${NSA_DEV}-t1-blog_test_addr${a}$?0"TCP socket bind to local address with device bind"+# Sadly, the kernel allows binding a socket to a device and then+# binding to an address not on the device. The only restriction+# is that the address is valid in the L3 domain. So this test+# passes when it really should nota=${VRF_IP6}log_start+show_hint"Tecnically should fail since address is not on device but kernel allows"run_cmdnettest-6-s-l${a}-I${NSA_DEV}-t1-b-log_test_addr${a}$?1"TCP socket bind to VRF address with device bind"+log_test_addr${a}$?0"TCP socket bind to VRF address with device bind"a=${NSA_LO_IP6}log_start
@@ -220,7 +220,7 @@ static int smp_85xx_start_cpu(int cpu)local_irq_save(flags);hard_irq_disable();-if(qoriq_pm_ops)+if(qoriq_pm_ops&&qoriq_pm_ops->cpu_up_prepare)qoriq_pm_ops->cpu_up_prepare(cpu);/* if cpu is not spinning, reset it */
@@ -292,7 +292,7 @@ static int smp_85xx_kick_cpu(int nr)booting_thread_hwid=cpu_thread_in_core(nr);primary=cpu_first_thread_sibling(nr);-if(qoriq_pm_ops)+if(qoriq_pm_ops&&qoriq_pm_ops->cpu_up_prepare)qoriq_pm_ops->cpu_up_prepare(nr);/*
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit c4d936efa46d8ea183df16c0f3fa4423327da51d ]
This reverts commit 796eed4b2342c9d6b26c958e92af91253a2390e1.
This change causes boot lockups when using "arlyprintk=xdbc" because
ktime can not be used at this point in time in the boot process. Also,
it is not needed for very small delays like this.
Reported-by: Mathias Nyman <redacted>
Reported-by: Peter Zijlstra <peterz@infradead.org>
Cc: Jann Horn <jannh@google.com>
Cc: Chunfeng Yun <chunfeng.yun@mediatek.com>
Fixes: 796eed4b2342 ("usb: early: convert to readl_poll_timeout_atomic()")
Link: https://lore.kernel.org/r/c2b5c9bb-1b75-bf56-3754-b5b18812d65e@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/usb/early/xhci-dbc.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
@@ -136,9 +135,17 @@ static int handshake(void __iomem *ptr, u32 mask, u32 done, int wait, int delay){u32result;-returnreadl_poll_timeout_atomic(ptr,result,-((result&mask)==done),-delay,wait);+/* Can not use readl_poll_timeout_atomic() for early boot things */+do{+result=readl(ptr);+result&=mask;+if(result==done)+return0;+udelay(delay);+wait-=delay;+}while(wait>0);++return-ETIMEDOUT;}staticvoid__initxdbc_bios_handoff(void)
From: Vitaly Kuznetsov <vkuznets@redhat.com>
[ Upstream commit 1aa2abb33a419090c7c87d4ae842a6347078ee12 ]
The ability to write to MSR_IA32_PERF_CAPABILITIES from the host should
not depend on guest visible CPUID entries, even if just to allow
creating/restoring guest MSRs and CPUIDs in any sequence.
Fixes: 27461da31089 ("KVM: x86/pmu: Support full width counting")
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: [off-list ref]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/kvm/x86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
commit 1ee33b1ca2b8dabfcc17198ffd049a6b55674a86 upstream.
syzbot is reporting that an unprivileged user who logged in from tty
console can crash the system using a reproducer shown below [1], for
n_hdlc_tty_wakeup() is synchronously calling n_hdlc_send_frames().
----------
#include <sys/ioctl.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
const int disc = 0xd;
ioctl(1, TIOCSETD, &disc);
while (1) {
ioctl(1, TCXONC, 0);
write(1, "", 1);
ioctl(1, TCXONC, 1); /* Kernel panic - not syncing: scheduling while atomic */
}
}
----------
Linus suspected that "struct tty_ldisc"->ops->write_wakeup() must not
sleep, and Jiri confirmed it from include/linux/tty_ldisc.h. Thus, defer
n_hdlc_send_frames() from n_hdlc_tty_wakeup() to a WQ context like
net/nfc/nci/uart.c does.
Link: https://syzkaller.appspot.com/bug?extid=5f47a8cea6a12b77a876 [1]
Reported-by: syzbot <redacted>
Cc: stable <redacted>
Analyzed-by: Fabio M. De Francesco [off-list ref]
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Confirmed-by: Jiri Slaby [off-list ref]
Reviewed-by: Fabio M. De Francesco <redacted>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Link: https://lore.kernel.org/r/40de8b7e-a3be-4486-4e33-1b1d1da452f8@i-love.sakura.ne.jp
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/n_hdlc.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
@@ -241,6 +246,8 @@ static int n_hdlc_tty_open(struct tty_streturn-ENFILE;}+INIT_WORK(&n_hdlc->write_work,n_hdlc_tty_write_work);+n_hdlc->tty_for_write_work=tty;tty->disc_data=n_hdlc;tty->receive_room=65536;
@@ -335,6 +342,20 @@ check_again:}/* end of n_hdlc_send_frames() *//**+*n_hdlc_tty_write_work-Asynchronouscallbackfortransmitwakeup+*@work:pointertowork_struct+*+*Calledwhenlowleveldevicedrivercanacceptmoresenddata.+*/+staticvoidn_hdlc_tty_write_work(structwork_struct*work)+{+structn_hdlc*n_hdlc=container_of(work,structn_hdlc,write_work);+structtty_struct*tty=n_hdlc->tty_for_write_work;++n_hdlc_send_frames(n_hdlc,tty);+}/* end of n_hdlc_tty_write_work() */++/***n_hdlc_tty_wakeup-Callbackfortransmitwakeup*@tty:pointertoassociatedttyinstancedata*
@@ -344,7 +365,7 @@ static void n_hdlc_tty_wakeup(struct tty{structn_hdlc*n_hdlc=tty->disc_data;-n_hdlc_send_frames(n_hdlc,tty);+schedule_work(&n_hdlc->write_work);}/* end of n_hdlc_tty_wakeup() *//**
From: Jimmy Wang <redacted>
commit 0ad3bd562bb91853b9f42bda145b5db6255aee90 upstream.
This device doesn't work well with LPM, losing connectivity intermittently.
Disable LPM to resolve the issue.
Reviewed-by: <redacted>
Signed-off-by: Jimmy Wang <redacted>
Cc: stable <redacted>
Link: https://lore.kernel.org/r/20211214012652.4898-1-wangjm221@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
From: Jiasheng Jiang <redacted>
[ Upstream commit 407ecd1bd726f240123f704620d46e285ff30dd9 ]
The return value of kmalloc() needs to be checked.
To avoid use in efx_nic_update_stats() in case of the failure of alloc.
Fixes: b593b6f1b492 ("sfc_ef100: statistics gathering")
Signed-off-by: Jiasheng Jiang <redacted>
Reported-by: kernel test robot <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/sfc/ef100_nic.c | 3 +++
1 file changed, 3 insertions(+)
From: Thomas Gleixner <redacted>
commit 94185adbfad56815c2c8401e16d81bdb74a79201 upstream.
PCI_MSIX_FLAGS_MASKALL is set in the MSI-X control register at MSI-X
interrupt setup time. It's cleared on success, but the error handling path
only clears the PCI_MSIX_FLAGS_ENABLE bit.
That's incorrect as the reset state of the PCI_MSIX_FLAGS_MASKALL bit is
zero. That can be observed via lspci:
Capabilities: [b0] MSI-X: Enable- Count=67 Masked+
Clear the bit in the error path to restore the reset state.
Fixes: 438553958ba1 ("PCI/MSI: Enable and mask MSI-X early")
Reported-by: Stefan Roese <sr@denx.de>
Signed-off-by: Thomas Gleixner <redacted>
Tested-by: Stefan Roese <sr@denx.de>
Cc: linux-pci@vger.kernel.org
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Michal Simek <redacted>
Cc: Marek Vasut <marex@denx.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/87tufevoqx.ffs@tglx
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/msi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Stefan Roese <sr@denx.de>
commit 83dbf898a2d45289be875deb580e93050ba67529 upstream.
Masking all unused MSI-X entries is done to ensure that a crash kernel
starts from a clean slate, which correponds to the reset state of the
device as defined in the PCI-E specificion 3.0 and later:
Vector Control for MSI-X Table Entries
--------------------------------------
"00: Mask bit: When this bit is set, the function is prohibited from
sending a message using this MSI-X Table entry.
...
This bit’s state after reset is 1 (entry is masked)."
A Marvell NVME device fails to deliver MSI interrupts after trying to
enable MSI-X interrupts due to that masking. It seems to take the MSI-X
mask bits into account even when MSI-X is disabled.
While not specification compliant, this can be cured by moving the masking
into the success path, so that the MSI-X table entries stay in device reset
state when the MSI-X setup fails.
[ tglx: Move it into the success path, add comment and amend changelog ]
Fixes: aa8092c1d1f1 ("PCI/MSI: Mask all unused MSI-X entries")
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Thomas Gleixner <redacted>
Cc: linux-pci@vger.kernel.org
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Michal Simek <redacted>
Cc: Marek Vasut <marex@denx.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20211210161025.3287927-1-sr@denx.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/msi.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
--- a/drivers/pci/msi.c+++ b/drivers/pci/msi.c
@@ -721,9 +721,6 @@ static int msix_capability_init(struct pgotoout_disable;}-/* Ensure that all table entries are masked. */-msix_mask_all(base,tsize);-ret=msix_setup_entries(dev,base,entries,nvec,affd);if(ret)gotoout_disable;
@@ -750,6 +747,16 @@ static int msix_capability_init(struct p/* Set MSI-X enabled bits and unmask the function */pci_intx_for_msi(dev,0);dev->msix_enabled=1;++/*+*Ensurethatalltableentriesaremaskedtoprevent+*staleentriesfromfiringinacrashkernel.+*+*DonelatetodealwithabrokenMarvellNVMEdevice+*whichtakestheMSI-Xmaskbitsintoaccounteven+*whenMSI-Xisdisabled,whichpreventsMSIdelivery.+*/+msix_mask_all(base,tsize);pci_msix_clear_and_set_ctrl(dev,PCI_MSIX_FLAGS_MASKALL,0);pcibios_free_irq(dev);
From: Chunfeng Yun <chunfeng.yun@mediatek.com>
commit ccc14c6cfd346e85c3ecb970975afd5132763437 upstream.
There is warning of 'list_del corruption' when enable list debug
(CONFIG_DEBUG_LIST=y), fix it by using list_del_init()
Fixes: 4ce186665e7c ("usb: xhci-mtk: Do not use xhci's virt_dev in drop_endpoint")
Cc: stable <redacted>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/20211209025422.17108-1-chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-mtk-sch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Xu Yang <xu.yang_2@nxp.com>
commit ca4d8344a72b91fb9d4c8bfbc22204b4c09c5d8f upstream.
In current design, when the tcpm port is unregisterd, the kthread_worker
will be destroyed in the last step. Inside the kthread_destroy_worker(),
the worker will flush all the works and wait for them to end. However, if
one of the works calls hrtimer_start(), this hrtimer will be pending until
timeout even though tcpm port is removed. Once the hrtimer timeout, many
strange kernel dumps appear.
Thus, we can first complete kthread_destroy_worker(), then cancel all the
hrtimers. This will guarantee that no hrtimer is pending at the end.
Fixes: 3ed8e1c2ac99 ("usb: typec: tcpm: Migrate workqueue to RT priority for processing events")
cc: <redacted>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Link: https://lore.kernel.org/r/20211209101507.499096-1-xu.yang_2@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/typec/tcpm/tcpm.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
From: Jianglei Nie <redacted>
commit f35838a6930296fc1988764cfa54cb3f705c0665 upstream.
Line 1169 (#3) allocates a memory chunk for victim_name by kmalloc(),
but when the function returns in line 1184 (#4) victim_name allocated
by line 1169 (#3) is not freed, which will lead to a memory leak.
There is a similar snippet of code in this function as allocating a memory
chunk for victim_name in line 1104 (#1) as well as releasing the memory
in line 1116 (#2).
We should kfree() victim_name when the return value of backref_in_log()
is less than zero and before the function returns in line 1184 (#4).
1057 static inline int __add_inode_ref(struct btrfs_trans_handle *trans,
1058 struct btrfs_root *root,
1059 struct btrfs_path *path,
1060 struct btrfs_root *log_root,
1061 struct btrfs_inode *dir,
1062 struct btrfs_inode *inode,
1063 u64 inode_objectid, u64 parent_objectid,
1064 u64 ref_index, char *name, int namelen,
1065 int *search_done)
1066 {
1104 victim_name = kmalloc(victim_name_len, GFP_NOFS);
// #1: kmalloc (victim_name-1)
1105 if (!victim_name)
1106 return -ENOMEM;
1112 ret = backref_in_log(log_root, &search_key,
1113 parent_objectid, victim_name,
1114 victim_name_len);
1115 if (ret < 0) {
1116 kfree(victim_name); // #2: kfree (victim_name-1)
1117 return ret;
1118 } else if (!ret) {
1169 victim_name = kmalloc(victim_name_len, GFP_NOFS);
// #3: kmalloc (victim_name-2)
1170 if (!victim_name)
1171 return -ENOMEM;
1180 ret = backref_in_log(log_root, &search_key,
1181 parent_objectid, victim_name,
1182 victim_name_len);
1183 if (ret < 0) {
1184 return ret; // #4: missing kfree (victim_name-2)
1185 } else if (!ret) {
1241 return 0;
1242 }
Fixes: d3316c8233bb ("btrfs: Properly handle backref_in_log retval")
CC: stable@vger.kernel.org # 5.10+
Reviewed-by: Qu Wenruo <redacted>
Reviewed-by: Filipe Manana <redacted>
Signed-off-by: Jianglei Nie <redacted>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/tree-log.c | 1 +
1 file changed, 1 insertion(+)
From: Filipe Manana <redacted>
commit 33fab972497ae66822c0b6846d4f9382938575b6 upstream.
When creating a subvolume, at create_subvol(), we allocate an anonymous
device and later call btrfs_get_new_fs_root(), which in turn just calls
btrfs_get_root_ref(). There we call btrfs_init_fs_root() which assigns
the anonymous device to the root, but if after that call there's an error,
when we jump to 'fail' label, we call btrfs_put_root(), which frees the
anonymous device and then returns an error that is propagated back to
create_subvol(). Than create_subvol() frees the anonymous device again.
When this happens, if the anonymous device was not reallocated after
the first time it was freed with btrfs_put_root(), we get a kernel
message like the following:
(...)
[13950.282466] BTRFS: error (device dm-0) in create_subvol:663: errno=-5 IO failure
[13950.283027] ida_free called for id=65 which is not allocated.
[13950.285974] BTRFS info (device dm-0): forced readonly
(...)
If the anonymous device gets reallocated by another btrfs filesystem
or any other kernel subsystem, then bad things can happen.
So fix this by setting the root's anonymous device to 0 at
btrfs_get_root_ref(), before we call btrfs_put_root(), if an error
happened.
Fixes: 2dfb1e43f57dd3 ("btrfs: preallocate anon block device at first phase of snapshot creation")
CC: stable@vger.kernel.org # 5.10+
Reviewed-by: Qu Wenruo <redacted>
Signed-off-by: Filipe Manana <redacted>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/disk-io.c | 8 ++++++++
1 file changed, 8 insertions(+)
From: Josef Bacik <josef@toxicpanda.com>
commit 651740a502411793327e2f0741104749c4eedcd1 upstream.
Filipe reported a hang when we have errors on btrfs. This turned out to
be a side-effect of my fix c2e39305299f01 ("btrfs: clear extent buffer
uptodate when we fail to write it") which made it so we clear
EXTENT_BUFFER_UPTODATE on an eb when we fail to write it out.
Below is a paste of Filipe's analysis he got from using drgn to debug
the hang
"""
btree readahead code calls read_extent_buffer_pages(), sets ->io_pages to
a value while writeback of all pages has not yet completed:
--> writeback for the first 3 pages finishes, we clear
EXTENT_BUFFER_UPTODATE from eb on the first page when we get an
error.
--> at this point eb->io_pages is 1 and we cleared Uptodate bit from the
first 3 pages
--> read_extent_buffer_pages() does not see EXTENT_BUFFER_UPTODATE() so
it continues, it's able to lock the pages since we obviously don't
hold the pages locked during writeback
--> read_extent_buffer_pages() then computes 'num_reads' as 3, and sets
eb->io_pages to 3, since only the first page does not have Uptodate
bit set at this point
--> writeback for the remaining page completes, we ended decrementing
eb->io_pages by 1, resulting in eb->io_pages == 2, and therefore
never calling end_extent_buffer_writeback(), so
EXTENT_BUFFER_WRITEBACK remains in the eb's flags
--> of course, when the read bio completes, it doesn't and shouldn't
call end_extent_buffer_writeback()
--> we should clear EXTENT_BUFFER_UPTODATE only after all pages of
the eb finished writeback? or maybe make the read pages code
wait for writeback of all pages of the eb to complete before
checking which pages need to be read, touch ->io_pages, submit
read bio, etc
writeback bit never cleared means we can hang when aborting a
transaction, at:
btrfs_cleanup_one_transaction()
btrfs_destroy_marked_extents()
wait_on_extent_buffer_writeback()
"""
This is a problem because our writes are not synchronized with reads in
any way. We clear the UPTODATE flag and then we can easily come in and
try to read the EB while we're still waiting on other bio's to
complete.
We have two options here, we could lock all the pages, and then check to
see if eb->io_pages != 0 to know if we've already got an outstanding
write on the eb.
Or we can simply check to see if we have WRITE_ERR set on this extent
buffer. We set this bit _before_ we clear UPTODATE, so if the read gets
triggered because we aren't UPTODATE because of a write error we're
guaranteed to have WRITE_ERR set, and in this case we can simply return
-EIO. This will fix the reported hang.
Reported-by: Filipe Manana <redacted>
Fixes: c2e39305299f01 ("btrfs: clear extent buffer uptodate when we fail to write it")
CC: stable@vger.kernel.org # 5.4+
Reviewed-by: Filipe Manana <redacted>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/extent_io.c | 8 ++++++++
1 file changed, 8 insertions(+)