From: Dan Carpenter <redacted>
commit b41c15f4e1c1f1657da15c482fa837c1b7384452 upstream.
The "count" variable needs to be capped on every path so that we don't
copy too much information to the user.
Fixes: 618eabeae711 ("ALSA: bebob: Add hwdep interface")
Signed-off-by: Dan Carpenter <redacted>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <redacted>
Link: https://lore.kernel.org/r/20201007074928.GA2529578@mwanda
Signed-off-by: Takashi Iwai <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/firewire/bebob/bebob_hwdep.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
From: Xie He <redacted>
[ Upstream commit 5fce1e43e2d5bf2f7e3224d7b99b1c65ab2c26e2 ]
This driver calls ether_setup to set up the network device.
The ether_setup function would add the IFF_TX_SKB_SHARING flag to the
device. This flag indicates that it is safe to transmit shared skbs to
the device.
However, this is not true. This driver may pad the frame (in eth_tx)
before transmission, so the skb may be modified.
Fixes: 550fd08c2ceb ("net: Audit drivers to identify those needing IFF_TX_SKB_SHARING cleared")
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: Xie He <redacted>
Link: https://lore.kernel.org/r/20201020063420.187497-1-xie.he.0141@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wan/hdlc_raw_eth.c | 1 +
1 file changed, 1 insertion(+)
From: Defang Bo <redacted>
[ Upstream commit 280e3ebdafb863b3cb50d5842f056267e15bf40c ]
Check that the NFC_ATTR_FIRMWARE_NAME attributes are provided by
the netlink client prior to accessing them.This prevents potential
unhandled NULL pointer dereference exceptions which can be triggered
by malicious user-mode programs, if they omit one or both of these
attributes.
Similar to commit a0323b979f81 ("nfc: Ensure presence of required attributes in the activate_target handler").
Fixes: 9674da8759df ("NFC: Add firmware upload netlink command")
Signed-off-by: Defang Bo <redacted>
Link: https://lore.kernel.org/r/1603107538-4744-1-git-send-email-bodefang@126.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/nfc/netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/nfc/netlink.c+++ b/net/nfc/netlink.c
@@ -1224,7 +1224,7 @@ static int nfc_genl_fw_download(struct su32idx;charfirmware_name[NFC_FIRMWARE_NAME_MAXSIZE+1];-if(!info->attrs[NFC_ATTR_DEVICE_INDEX])+if(!info->attrs[NFC_ATTR_DEVICE_INDEX]||!info->attrs[NFC_ATTR_FIRMWARE_NAME])return-EINVAL;idx=nla_get_u32(info->attrs[NFC_ATTR_DEVICE_INDEX]);
From: Neal Cardwell <ncardwell@google.com>
[ Upstream commit 18ded910b589839e38a51623a179837ab4cc3789 ]
In the header prediction fast path for a bulk data receiver, if no
data is newly acknowledged then we do not call tcp_ack() and do not
call tcp_ack_update_window(). This means that a bulk receiver that
receives large amounts of data can have the incoming sequence numbers
wrap, so that the check in tcp_may_update_window fails:
after(ack_seq, tp->snd_wl1)
If the incoming receive windows are zero in this state, and then the
connection that was a bulk data receiver later wants to send data,
that connection can find itself persistently rejecting the window
updates in incoming ACKs. This means the connection can persistently
fail to discover that the receive window has opened, which in turn
means that the connection is unable to send anything, and the
connection's sending process can get permanently "stuck".
The fix is to update snd_wl1 in the header prediction fast path for a
bulk data receiver, so that it keeps up and does not see wrapping
problems.
This fix is based on a very nice and thorough analysis and diagnosis
by Apollon Oikonomopoulos (see link below).
This is a stable candidate but there is no Fixes tag here since the
bug predates current git history. Just for fun: looks like the bug
dates back to when header prediction was added in Linux v2.1.8 in Nov
1996. In that version tcp_rcv_established() was added, and the code
only updates snd_wl1 in tcp_ack(), and in the new "Bulk data transfer:
receiver" code path it does not call tcp_ack(). This fix seems to
apply cleanly at least as far back as v3.2.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Reported-by: Apollon Oikonomopoulos <redacted>
Tested-by: Apollon Oikonomopoulos <redacted>
Link: https://www.spinics.net/lists/netdev/msg692430.html
Acked-by: Soheil Hassas Yeganeh <redacted>
Acked-by: Yuchung Cheng <redacted>
Signed-off-by: Eric Dumazet <redacted>
Link: https://lore.kernel.org/r/20201022143331.1887495-1-ncardwell.kernel@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/tcp_input.c | 2 ++
1 file changed, 2 insertions(+)
From: Eric Dumazet <redacted>
[ Upstream commit b38e7819cae946e2edf869e604af1e65a5d241c5 ]
Keyu Man reported that the ICMP rate limiter could be used
by attackers to get useful signal. Details will be provided
in an upcoming academic publication.
Our solution is to add some noise, so that the attackers
no longer can get help from the predictable token bucket limiter.
Fixes: 4cdf507d5452 ("icmp: add a global rate limitation")
Signed-off-by: Eric Dumazet <redacted>
Reported-by: Keyu Man <redacted>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/networking/ip-sysctl.txt | 4 +++-
net/ipv4/icmp.c | 7 +++++--
2 files changed, 8 insertions(+), 3 deletions(-)
@@ -905,12 +905,14 @@ icmp_ratelimit - INTEGER icmp_msgs_per_sec - INTEGER Limit maximal number of ICMP packets sent per second from this host. Only messages whose type matches icmp_ratemask (see below) are- controlled by this limit.+ controlled by this limit. For security reasons, the precise count+ of messages per second is randomized. Default: 1000 icmp_msgs_burst - INTEGER icmp_msgs_per_sec controls number of ICMP packets sent per second, while icmp_msgs_burst controls the burst size of these packets.+ For security reasons, the precise burst size is randomized. Default: 50 icmp_ratemask - INTEGER--- a/net/ipv4/icmp.c+++ b/net/ipv4/icmp.c
@@ -244,7 +244,7 @@ static struct { /** * icmp_global_allow - Are we allowed to send one more ICMP message ? *- * Uses a token bucket to limit our ICMP messages to sysctl_icmp_msgs_per_sec.+ * Uses a token bucket to limit our ICMP messages to ~sysctl_icmp_msgs_per_sec. * Returns false if we reached the limit and can not send another packet. * Note: called with BH disabled */
@@ -272,7 +272,10 @@ bool icmp_global_allow(void) } credit = min_t(u32, icmp_global.credit + incr, sysctl_icmp_msgs_burst); if (credit) {- credit--;+ /* We want to use a credit of one in average, but need to randomize+ * it for security reasons.+ */+ credit = max_t(int, credit - prandom_u32_max(3), 0); rc = true; } WRITE_ONCE(icmp_global.credit, credit);
From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
commit f6426ab9c957e97418ac5b0466538792767b1738 upstream.
The function amd_ir_set_vcpu_affinity makes use of the parameter struct
amd_iommu_pi_data.prev_ga_tag to determine if it should delete struct
amd_iommu_pi_data from a list when not running in AVIC mode.
However, prev_ga_tag is initialized only when AVIC is enabled. The non-zero
uninitialized value can cause unintended code path, which ends up making
use of the struct vcpu_svm.ir_list and ir_list_lock without being
initialized (since they are intended only for the AVIC case).
This triggers NULL pointer dereference bug in the function vm_ir_list_del
with the following call trace:
svm_update_pi_irte+0x3c2/0x550 [kvm_amd]
? proc_create_single_data+0x41/0x50
kvm_arch_irq_bypass_add_producer+0x40/0x60 [kvm]
__connect+0x5f/0xb0 [irqbypass]
irq_bypass_register_producer+0xf8/0x120 [irqbypass]
vfio_msi_set_vector_signal+0x1de/0x2d0 [vfio_pci]
vfio_msi_set_block+0x77/0xe0 [vfio_pci]
vfio_pci_set_msi_trigger+0x25c/0x2f0 [vfio_pci]
vfio_pci_set_irqs_ioctl+0x88/0xb0 [vfio_pci]
vfio_pci_ioctl+0x2ea/0xed0 [vfio_pci]
? alloc_file_pseudo+0xa5/0x100
vfio_device_fops_unl_ioctl+0x26/0x30 [vfio]
? vfio_device_fops_unl_ioctl+0x26/0x30 [vfio]
__x64_sys_ioctl+0x96/0xd0
do_syscall_64+0x37/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Therefore, initialize prev_ga_tag to zero before use. This should be safe
because ga_tag value 0 is invalid (see function avic_vm_init).
Fixes: dfa20099e26e ("KVM: SVM: Refactor AVIC vcpu initialization into avic_init_vcpu()")
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Message-Id: [off-list ref]
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/svm.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/kvm/svm.c+++ b/arch/x86/kvm/svm.c
@@ -4862,6 +4862,7 @@ static int svm_update_pi_irte(struct kvm*-TellIOMMUtouselegacymodeforthisinterrupt.*-Retrievega_tagofpriorinterruptremappingdata.*/+pi.prev_ga_tag=0;pi.is_guest_mode=false;ret=irq_set_vcpu_affinity(host_irq,&pi);
From: Sean Christopherson <redacted>
commit e89505698c9f70125651060547da4ff5046124fc upstream.
Call kvm_mmu_commit_zap_page() after exiting the "prepare zap" loop in
kvm_recover_nx_lpages() to finish zapping pages in the unlikely event
that the loop exited due to lpage_disallowed_mmu_pages being empty.
Because the recovery thread drops mmu_lock() when rescheduling, it's
possible that lpage_disallowed_mmu_pages could be emptied by a different
thread without to_zap reaching zero despite to_zap being derived from
the number of disallowed lpages.
Fixes: 1aa9b9572b105 ("kvm: x86: mmu: Recovery of shattered NX large pages")
Cc: Junaid Shahid <redacted>
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <redacted>
Message-Id: [off-list ref]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/mmu.c | 1 +
1 file changed, 1 insertion(+)
From: David Wilder <redacted>
[ Upstream commit 413f142cc05cb03f2d1ea83388e40c1ddc0d74e9 ]
Ingress large send packets are identified by either:
The IBMVETH_RXQ_LRG_PKT flag in the receive buffer
or with a -1 placed in the ip header checksum.
The method used depends on firmware version. Frame
geometry and sufficient header validation is performed by the
hypervisor eliminating the need for further header checks here.
Fixes: 7b5967389f5a ("ibmveth: set correct gso_size and gso_type")
Signed-off-by: David Wilder <redacted>
Reviewed-by: Thomas Falcon <redacted>
Reviewed-by: Cristobal Forno <redacted>
Reviewed-by: Pradeep Satyanarayana <redacted>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/ibm/ibmveth.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
@@ -1330,6 +1330,7 @@ static int ibmveth_poll(struct napi_struintoffset=ibmveth_rxq_frame_offset(adapter);intcsum_good=ibmveth_rxq_csum_good(adapter);intlrg_pkt=ibmveth_rxq_large_packet(adapter);+__sum16iph_check=0;skb=ibmveth_rxq_get_buffer(adapter);
@@ -1366,7 +1367,17 @@ static int ibmveth_poll(struct napi_struskb_put(skb,length);skb->protocol=eth_type_trans(skb,netdev);-if(length>netdev->mtu+ETH_HLEN){+/* PHYP without PLSO support places a -1 in the ip+*checksumforlargesendframes.+*/+if(skb->protocol==cpu_to_be16(ETH_P_IP)){+structiphdr*iph=(structiphdr*)skb->data;++iph_check=iph->check;+}++if((length>netdev->mtu+ETH_HLEN)||+lrg_pkt||iph_check==0xffff){ibmveth_rx_mss_helper(skb,mss,lrg_pkt);adapter->rx_large_packets++;}
From: Roberto Sassu <roberto.sassu@huawei.com>
commit 60386b854008adc951c470067f90a2d85b5d520f upstream.
Errors returned by crypto_shash_update() are not checked in
ima_calc_boot_aggregate_tfm() and thus can be overwritten at the next
iteration of the loop. This patch adds a check after calling
crypto_shash_update() and returns immediately if the result is not zero.
Cc: stable@vger.kernel.org
Fixes: 3323eec921efd ("integrity: IMA as an integrity service provider")
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
security/integrity/ima/ima_crypto.c | 2 ++
1 file changed, 2 insertions(+)
@@ -699,6 +699,8 @@ static int __init ima_calc_boot_aggregatima_pcrread(i,pcr_i);/* now accumulate with current aggregate */rc=crypto_shash_update(shash,pcr_i,TPM_DIGEST_SIZE);+if(rc!=0)+returnrc;}if(!rc)crypto_shash_final(shash,digest);
From: Herbert Xu <herbert@gondor.apana.org.au>
commit cbdad1f246dd98e6c9c32a6e5212337f542aa7e0 upstream.
The async path cannot use MAY_BACKLOG because it is not meant to
block, which is what MAY_BACKLOG does. On the other hand, both
the sync and async paths can make use of MAY_SLEEP.
Fixes: 83094e5e9e49 ("crypto: af_alg - add async support to...")
Cc: <redacted>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
crypto/algif_aead.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
From: Dinghao Liu <redacted>
[ Upstream commit 857a3139bd8be4f702c030c8ca06f3fd69c1741a ]
When pci_get_device_func() fails, the driver doesn't need to execute
pci_dev_put(). mci should still be freed, though, to prevent a memory
leak. When pci_enable_device() fails, the error injection PCI device
"einj" doesn't need to be disabled either.
[ bp: Massage commit message, rename label to "bail_mc_free". ]
Fixes: 52608ba205461 ("i5100_edac: probe for device 19 function 0")
Signed-off-by: Dinghao Liu <redacted>
Signed-off-by: Borislav Petkov <redacted>
Link: https://lkml.kernel.org/r/20200826121437.31606-1-dinghao.liu@zju.edu.cn
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/edac/i5100_edac.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
From: Tom Rix <trix@redhat.com>
[ Upstream commit 505bfc2a142f12ce7bc7a878b44abc3496f2e747 ]
clang static analysis reports this problem
tuner-simple.c:714:13: warning: Assigned value is
garbage or undefined
buffer[1] = buffer[3];
^ ~~~~~~~~~
In simple_set_radio_freq buffer[3] used to be done
in-function with a switch of tuner type, now done
by a call to simple_radio_bandswitch which has this case
case TUNER_TENA_9533_DI:
case TUNER_YMEC_TVF_5533MF:
tuner_dbg("This tuner doesn't ...
return 0;
which does not set buffer[3]. In the old logic, this case
would have returned 0 from simple_set_radio_freq.
Recover this old behavior by returning an error for this
codition. Since the old simple_set_radio_freq behavior
returned a 0, do the same.
Fixes: c7a9f3aa1e1b ("V4L/DVB (7129): tuner-simple: move device-specific code into three separate functions")
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Hans Verkuil <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/tuners/tuner-simple.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
@@ -499,7 +499,7 @@ static int simple_radio_bandswitch(struct dvb_frontend *fe, u8 *buffer)caseTUNER_TENA_9533_DI:caseTUNER_YMEC_TVF_5533MF:tuner_dbg("This tuner doesn't have FM. Most cards have a TEA5767 for FM\n");-return0;+return-EINVAL;caseTUNER_PHILIPS_FM1216ME_MK3:caseTUNER_PHILIPS_FM1236_MK3:caseTUNER_PHILIPS_FMD1216ME_MK3:
@@ -700,7 +700,8 @@ static int simple_set_radio_freq(struct dvb_frontend *fe,TUNER_RATIO_SELECT_50;/* 50 kHz step *//* Bandswitch byte */-simple_radio_bandswitch(fe,&buffer[0]);+if(simple_radio_bandswitch(fe,&buffer[0]))+return0;/* Convert from 1/16 kHz V4L steps to 1/20 MHz (=50 kHz) PLL stepsfreq*(1Mhz/16000V4Lsteps)*(20PLLsteps/1MHz)=
From: Sylwester Nawrocki <s.nawrocki@samsung.com>
[ Upstream commit 00d21f325d58567d81d9172096692d0a9ea7f725 ]
The "idle" pinctrl state is optional as documented in the DT binding.
The change introduced by the commit being reverted makes that pinctrl state
mandatory and breaks initialization of the whole media driver, since the
"idle" state is not specified in any mainline dts.
This reverts commit 18ffec750578 ("media: exynos4-is: Add missed check for pinctrl_lookup_state()")
to fix the regression.
Fixes: 18ffec750578 ("media: exynos4-is: Add missed check for pinctrl_lookup_state()")
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Hans Verkuil <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/exynos4-is/media-dev.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
From: Tom Rix <trix@redhat.com>
[ Upstream commit 52438c4463ac904d14bf3496765e67750766f3a6 ]
clang static analysis reports this error
m5mols_core.c:767:4: warning: Called function pointer
is null (null dereference) [core.CallAndMessage]
info->set_power(&client->dev, 0);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In other places, the set_power ptr is checked.
So add a check.
Fixes: bc125106f8af ("[media] Add support for M-5MOLS 8 Mega Pixel camera ISP")
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/i2c/m5mols/m5mols_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
[ Upstream commit d6834b4b58d110814aaf3469e7fd87d34ae5ae81 ]
The media controller core prints a warning when an entity is registered
without a function being set. This affects the uvcvideo driver, as the
warning was added without first addressing the issue in existing
drivers. The problem is harmless, but unnecessarily worries users. Fix
it by mapping UVC entity types to MC entity functions as accurately as
possible using the existing functions.
Fixes: b50bde4e476d ("[media] v4l2-subdev: use MEDIA_ENT_T_UNKNOWN for new subdevs")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/usb/uvc/uvc_entity.c | 35 ++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
@@ -78,10 +78,45 @@ static int uvc_mc_init_entity(struct uvc_video_chain *chain,intret;if(UVC_ENTITY_TYPE(entity)!=UVC_TT_STREAMING){+u32function;+v4l2_subdev_init(&entity->subdev,&uvc_subdev_ops);strlcpy(entity->subdev.name,entity->name,sizeof(entity->subdev.name));+switch(UVC_ENTITY_TYPE(entity)){+caseUVC_VC_SELECTOR_UNIT:+function=MEDIA_ENT_F_VID_MUX;+break;+caseUVC_VC_PROCESSING_UNIT:+caseUVC_VC_EXTENSION_UNIT:+/* For lack of a better option. */+function=MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER;+break;+caseUVC_COMPOSITE_CONNECTOR:+caseUVC_COMPONENT_CONNECTOR:+function=MEDIA_ENT_F_CONN_COMPOSITE;+break;+caseUVC_SVIDEO_CONNECTOR:+function=MEDIA_ENT_F_CONN_SVIDEO;+break;+caseUVC_ITT_CAMERA:+function=MEDIA_ENT_F_CAM_SENSOR;+break;+caseUVC_TT_VENDOR_SPECIFIC:+caseUVC_ITT_VENDOR_SPECIFIC:+caseUVC_ITT_MEDIA_TRANSPORT_INPUT:+caseUVC_OTT_VENDOR_SPECIFIC:+caseUVC_OTT_DISPLAY:+caseUVC_OTT_MEDIA_TRANSPORT_OUTPUT:+caseUVC_EXTERNAL_VENDOR_SPECIFIC:+default:+function=MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN;+break;+}++entity->subdev.entity.function=function;+ret=media_entity_pads_init(&entity->subdev.entity,entity->num_pads,entity->pads);
From: Cong Wang <redacted>
[ Upstream commit ed42989eab57d619667d7e87dfbd8fe207db54fe ]
skb_unshare() drops a reference count on the old skb unconditionally,
so in the failure case, we end up freeing the skb twice here.
And because the skb is allocated in fclone and cloned by caller
tipc_msg_reassemble(), the consequence is actually freeing the
original skb too, thus triggered the UAF by syzbot.
Fix this by replacing this skb_unshare() with skb_cloned()+skb_copy().
Fixes: ff48b6222e65 ("tipc: use skb_unshare() instead in tipc_buf_append()")
Reported-and-tested-by: syzbot+e96a7ba46281824cc46a@syzkaller.appspotmail.com
Cc: Jon Maloy <jmaloy@redhat.com>
Cc: Ying Xue <redacted>
Signed-off-by: Cong Wang <redacted>
Reviewed-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/tipc/msg.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/tipc/msg.c+++ b/net/tipc/msg.c
@@ -140,7 +140,8 @@ int tipc_buf_append(struct sk_buff **heaif(fragid==FIRST_FRAGMENT){if(unlikely(head))gotoerr;-frag=skb_unshare(frag,GFP_ATOMIC);+if(skb_cloned(frag))+frag=skb_copy(frag,GFP_ATOMIC);if(unlikely(!frag))gotoerr;head=*headbuf=frag;
From: Herbert Xu <herbert@gondor.apana.org.au>
[ Upstream commit 2a05b029c1ee045b886ebf9efef9985ca23450de ]
I removed the MAY_BACKLOG flag on the aio path a while ago but
the error check still incorrectly interpreted EBUSY as success.
This may cause the submitter to wait for a request that will never
complete.
Fixes: dad419970637 ("crypto: algif_skcipher - Do not set...")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
crypto/algif_skcipher.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Arvind Sankar <redacted>
[ Upstream commit 0a4bb5e5507a585532cc413125b921c8546fc39f ]
Commit
0c2a3913d6f5 ("x86/fpu: Parse clearcpuid= as early XSAVE argument")
changed clearcpuid parsing from __setup() to cmdline_find_option().
While the __setup() function would have been called for each clearcpuid=
parameter on the command line, cmdline_find_option() will only return
the last one, so the change effectively made it impossible to disable
more than one bit.
Allow a comma-separated list of bit numbers as the argument for
clearcpuid to allow multiple bits to be disabled again. Log the bits
being disabled for informational purposes.
Also fix the check on the return value of cmdline_find_option(). It
returns -1 when the option is not found, so testing as a boolean is
incorrect.
Fixes: 0c2a3913d6f5 ("x86/fpu: Parse clearcpuid= as early XSAVE argument")
Signed-off-by: Arvind Sankar <redacted>
Signed-off-by: Borislav Petkov <redacted>
Link: https://lkml.kernel.org/r/20200907213919.2423441-1-nivedita@alum.mit.edu
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../admin-guide/kernel-parameters.txt | 2 +-
arch/x86/kernel/fpu/init.c | 30 ++++++++++++++-----
2 files changed, 23 insertions(+), 9 deletions(-)
@@ -552,7 +552,7 @@ loops can be debugged more effectively on production systems.- clearcpuid=BITNUM [X86]+ clearcpuid=BITNUM[,BITNUM...] [X86] Disable CPUID feature X for the kernel. See arch/x86/include/asm/cpufeatures.h for the valid bit numbers. Note the Linux specific bits are not necessarily
@@ -271,12 +271,26 @@ static void __init fpu__init_parse_early_param(void)if(cmdline_find_option_bool(boot_command_line,"noxsaves"))setup_clear_cpu_cap(X86_FEATURE_XSAVES);-if(cmdline_find_option(boot_command_line,"clearcpuid",arg,-sizeof(arg))&&-get_option(&argptr,&bit)&&-bit>=0&&-bit<NCAPINTS*32)-setup_clear_cpu_cap(bit);+arglen=cmdline_find_option(boot_command_line,"clearcpuid",arg,sizeof(arg));+if(arglen<=0)+return;++pr_info("Clearing CPUID bits:");+do{+res=get_option(&argptr,&bit);+if(res==0||res==3)+break;++/* If the argument was too long, the last bit may be cut off */+if(res==1&&arglen>=sizeof(arg))+break;++if(bit>=0&&bit<NCAPINTS*32){+pr_cont(" "X86_CAP_FMT,x86_cap_flag(bit));+setup_clear_cpu_cap(bit);+}+}while(res==2);+pr_cont("\n");}/*
From: David Wilder <redacted>
[ Upstream commit 5ce9ad815a296374ca21f43f3b1ab5083d202ee1 ]
ibmveth_rx_csum_helper() must be called after ibmveth_rx_mss_helper()
as ibmveth_rx_csum_helper() may alter ip and tcp checksum values.
Fixes: 66aa0678efc2 ("ibmveth: Support to enable LSO/CSO for Trunk VEA.")
Signed-off-by: David Wilder <redacted>
Reviewed-by: Thomas Falcon <redacted>
Reviewed-by: Cristobal Forno <redacted>
Reviewed-by: Pradeep Satyanarayana <redacted>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/ibm/ibmveth.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
@@ -1366,16 +1366,16 @@ static int ibmveth_poll(struct napi_struskb_put(skb,length);skb->protocol=eth_type_trans(skb,netdev);-if(csum_good){-skb->ip_summed=CHECKSUM_UNNECESSARY;-ibmveth_rx_csum_helper(skb,adapter);-}-if(length>netdev->mtu+ETH_HLEN){ibmveth_rx_mss_helper(skb,mss,lrg_pkt);adapter->rx_large_packets++;}+if(csum_good){+skb->ip_summed=CHECKSUM_UNNECESSARY;+ibmveth_rx_csum_helper(skb,adapter);+}+napi_gro_receive(napi,skb);/* send it up */netdev->stats.rx_packets++;
From: Dinghao Liu <redacted>
[ Upstream commit d8fc21c17099635e8ebd986d042be65a6c6b5bd0 ]
When devm_ioremap_resource() fails, isp should be
freed just like other error paths in isp_probe.
Fixes: 8644cdf972dd6 ("[media] omap3isp: Replace many MMIO regions by two")
Signed-off-by: Dinghao Liu <redacted>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/omap3isp/isp.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
From: David Ahern <dsahern@kernel.org>
[ Upstream commit 874fb9e2ca949b443cc419a4f2227cafd4381d39 ]
Tobias reported regressions in IPsec tests following the patch
referenced by the Fixes tag below. The root cause is dropping the
reset of the flowi4_oif after the fib_lookup. Apparently it is
needed for xfrm cases, so restore the oif update to ip_route_output_flow
right before the call to xfrm_lookup_route.
Fixes: 2fbc6e89b2f1 ("ipv4: Update exception handling for multipath routes via same device")
Reported-by: Tobias Brunner <redacted>
Signed-off-by: David Ahern <dsahern@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/route.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: Heiner Kallweit <hkallweit1@gmail.com>
[ Upstream commit ef9da46ddef071e1bbb943afbbe9b38771855554 ]
Petr reported that after resume from suspend RTL8402 partially
truncates incoming packets, and re-initializing register RxConfig
before the actual chip re-initialization sequence is needed to avoid
the issue.
Reported-by: Petr Tesarik <redacted>
Proposed-by: Petr Tesarik [off-list ref]
Tested-by: Petr Tesarik <redacted>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/realtek/r8169.c | 108 ++++++++++++++++++-----------------
1 file changed, 56 insertions(+), 52 deletions(-)
@@ -4519,6 +4571,10 @@ static int rtl_set_mac_address(struct nepm_runtime_put_noidle(d);+/* Reportedly at least Asus X453MA truncates packets otherwise */+if(tp->mac_version==RTL_GIGA_MAC_VER_37)+rtl_init_rxcfg(tp);+return0;}
From: Shyam Prasad N <sprasad@microsoft.com>
commit 0bd294b55a5de442370c29fa53bab17aef3ff318 upstream.
In crypt_message, when smb2_get_enc_key returns error, we need to
return the error back to the caller. If not, we end up processing
the message further, causing a kernel oops due to unwarranted access
of memory.
Call Trace:
smb3_receive_transform+0x120/0x870 [cifs]
cifs_demultiplex_thread+0xb53/0xc20 [cifs]
? cifs_handle_standard+0x190/0x190 [cifs]
kthread+0x116/0x130
? kthread_park+0x80/0x80
ret_from_fork+0x1f/0x30
Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
Reviewed-by: Pavel Shilovsky <redacted>
Reviewed-by: Ronnie Sahlberg <redacted>
CC: Stable <redacted>
Signed-off-by: Steve French <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/cifs/smb2ops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/cifs/smb2ops.c+++ b/fs/cifs/smb2ops.c
@@ -2305,7 +2305,7 @@ crypt_message(struct TCP_Server_Info *seif(rc){cifs_dbg(VFS,"%s: Could not get %scryption key\n",__func__,enc?"en":"de");-return0;+returnrc;}rc=smb3_crypto_aead_allocate(server);
From: Xiaoliang Pang <redacted>
[ Upstream commit 228d284aac61283cde508a925d666f854b57af63 ]
In the init loop, if an error occurs in function 'dma_alloc_coherent',
then goto the err_cleanup section, after run i--,
in the array ring, the struct mtk_ring with index i will not be released,
causing memory leaks
Fixes: 785e5c616c849 ("crypto: mediatek - Add crypto driver support for some MediaTek chips")
Cc: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Xiaoliang Pang <redacted>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/crypto/mediatek/mtk-platform.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Dan Carpenter <redacted>
[ Upstream commit 54f9ab7b870934b70e5a21786d951fbcf663970f ]
The value for "aid" comes from skb->data so Smatch marks it as
untrusted. If it's invalid then it can result in an out of bounds array
access in ath6kl_add_new_sta().
Fixes: 572e27c00c9d ("ath6kl: Fix AP mode connect event parsing and TIM updates")
Signed-off-by: Dan Carpenter <redacted>
Signed-off-by: Kalle Valo <redacted>
Link: https://lore.kernel.org/r/20200813141315.GB457408@mwanda
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath6kl/main.c | 3 +++
1 file changed, 3 insertions(+)
From: Rohit kumar <redacted>
[ Upstream commit 753a6e17942f6f425ca622e1610625998312ad89 ]
i2sctl register value is set to 0 during hw_free(). This
impacts any ongoing concurrent session on the same i2s
port. As trigger() stop already resets enable bit to 0,
there is no need of explicit hw_free. Removing it to
fix the issue.
Fixes: 80beab8e1d86 ("ASoC: qcom: Add LPASS CPU DAI driver")
Signed-off-by: Rohit kumar <redacted>
Reviewed-by: Srinivas Kandagatla <redacted>
Link: https://lore.kernel.org/r/1597402388-14112-7-git-send-email-rohitkr@codeaurora.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/qcom/lpass-cpu.c | 16 ----------------
1 file changed, 16 deletions(-)
From: Tom Rix <trix@redhat.com>
[ Upstream commit 9c9f015bc9f8839831c7ba0a6d731a3853c464e2 ]
Clang static analysis reports this error
brcmfmac/core.c:490:4: warning: Dereference of null pointer
(*ifp)->ndev->stats.rx_errors++;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In this block of code
if (ret || !(*ifp) || !(*ifp)->ndev) {
if (ret != -ENODATA && *ifp)
(*ifp)->ndev->stats.rx_errors++;
brcmu_pkt_buf_free_skb(skb);
return -ENODATA;
}
(*ifp)->ndev being NULL is caught as an error
But then it is used to report the error.
So add a check before using it.
Fixes: 91b632803ee4 ("brcmfmac: Use net_device_stats from struct net_device")
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Kalle Valo <redacted>
Link: https://lore.kernel.org/r/20200802161804.6126-1-trix@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Tom Rix <trix@redhat.com>
[ Upstream commit cdd296cdae1af2d27dae3fcfbdf12c5252ab78cf ]
Reviewing this block of code in cdv_intel_dp_init()
ret = cdv_intel_dp_aux_native_read(gma_encoder, DP_DPCD_REV, ...
cdv_intel_edp_panel_vdd_off(gma_encoder);
if (ret == 0) {
/* if this fails, presume the device is a ghost */
DRM_INFO("failed to retrieve link info, disabling eDP\n");
drm_encoder_cleanup(encoder);
cdv_intel_dp_destroy(connector);
goto err_priv;
} else {
The (ret == 0) is not strict enough.
cdv_intel_dp_aux_native_read() returns > 0 on success
otherwise it is failure.
So change to <=
Fixes: d112a8163f83 ("gma500/cdv: Add eDP support")
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200805205911.20927-1-trix@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/gma500/cdv_intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -2121,7 +2121,7 @@ cdv_intel_dp_init(struct drm_device *dev, struct psb_intel_mode_device *mode_devintel_dp->dpcd,sizeof(intel_dp->dpcd));cdv_intel_edp_panel_vdd_off(gma_encoder);-if(ret==0){+if(ret<=0){/* if this fails, presume the device is a ghost */DRM_INFO("failed to retrieve link info, disabling eDP\n");cdv_intel_dp_encoder_destroy(encoder);
From: Tong Zhang <redacted>
[ Upstream commit 0fb9342d06b0f667b915ba58bfefc030e534a218 ]
parse_options() in drivers/tty/serial/earlycon.c calls uart_parse_earlycon
in drivers/tty/serial/serial_core.c therefore selecting SERIAL_EARLYCON
should automatically select SERIAL_CORE, otherwise will result in symbol
not found error during linking if SERIAL_CORE is not configured as builtin
Fixes: 9aac5887595b ("tty/serial: add generic serial earlycon")
Signed-off-by: Tong Zhang <redacted>
Link: https://lore.kernel.org/r/20200828123949.2642-1-ztong0001@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/serial/Kconfig | 1 +
1 file changed, 1 insertion(+)
From: Tyrel Datwyler <tyreld@linux.ibm.com>
[ Upstream commit 63ffcbdad738e3d1c857027789a2273df3337624 ]
The code currently NULLs tty->driver_data in hvcs_close() with the
intent of informing the next call to hvcs_open() that device needs to be
reconfigured. However, when hvcs_cleanup() is called we copy hvcsd from
tty->driver_data which was previoulsy NULLed by hvcs_close() and our
call to tty_port_put(&hvcsd->port) doesn't actually do anything since
&hvcsd->port ends up translating to NULL by chance. This has the side
effect that when hvcs_remove() is called we have one too many port
references preventing hvcs_destuct_port() from ever being called. This
also prevents us from reusing the /dev/hvcsX node in a future
hvcs_probe() and we can eventually run out of /dev/hvcsX devices.
Fix this by waiting to NULL tty->driver_data in hvcs_cleanup().
Fixes: 27bf7c43a19c ("TTY: hvcs, add tty install")
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://lore.kernel.org/r/20200820234643.70412-1-tyreld@linux.ibm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/hvc/hvcs.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
@@ -120,10 +120,10 @@ static int pty_write(struct tty_struct *tty, const unsigned char *buf, int c)spin_lock_irqsave(&to->port->lock,flags);/* Stuff the data into the input queue of the other end */c=tty_insert_flip_string(to->port,buf,c);+spin_unlock_irqrestore(&to->port->lock,flags);/* And shovel */if(c)tty_flip_buffer_push(to->port);-spin_unlock_irqrestore(&to->port->lock,flags);}returnc;}
From: Souptick Joarder <redacted>
[ Upstream commit 7f360bec37857bfd5a48cef21d86f58a09a3df63 ]
First, when memory allocation for sg_list_unaligned failed, there
is a bug of calling put_pages() as we haven't pinned any pages.
Second, if get_user_pages_fast() failed we should unpin num_pinned
pages.
This will address both.
As part of these changes, minor update in documentation.
Fixes: 6db7199407ca ("drivers/virt: introduce Freescale hypervisor management driver")
Signed-off-by: Souptick Joarder <redacted>
Reviewed-by: Dan Carpenter <redacted>
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
Link: https://lore.kernel.org/r/1598995271-6755-1-git-send-email-jrdr.linux@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/virt/fsl_hypervisor.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
@@ -157,7 +157,7 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user *p)unsignedinti;longret=0;-intnum_pinned;/* return value from get_user_pages() */+intnum_pinned=0;/* return value from get_user_pages_fast() */phys_addr_tremote_paddr;/* The next address in the remote buffer */uint32_tcount;/* The number of bytes left to copy */
@@ -174,7 +174,7 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user *p)return-EINVAL;/*-*Thearrayofpagesreturnedbyget_user_pages()coversonly+*Thearrayofpagesreturnedbyget_user_pages_fast()coversonly*page-alignedmemory.Sincetheuserbufferisprobablynot*page-aligned,weneedtohandlethediscrepancy.*
@@ -224,7 +224,7 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user *p)/**'pages'isanarrayofstructpagepointersthat'sinitializedby-*get_user_pages().+*get_user_pages_fast().*/pages=kzalloc(num_pages*sizeof(structpage*),GFP_KERNEL);if(!pages){
@@ -241,7 +241,7 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user *p)if(!sg_list_unaligned){pr_debug("fsl-hv: could not allocate S/G list\n");ret=-ENOMEM;-gotoexit;+gotofree_pages;}sg_list=PTR_ALIGN(sg_list_unaligned,sizeof(structfh_sg_list));
@@ -250,7 +250,6 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user *p)num_pages,pages,(param.source==-1)?0:FOLL_WRITE);if(num_pinned!=num_pages){-/* get_user_pages() failed */pr_debug("fsl-hv: could not lock source buffer\n");ret=(num_pinned<0)?num_pinned:-EFAULT;gotoexit;
@@ -292,13 +291,13 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user *p)virt_to_phys(sg_list),num_pages);exit:-if(pages){-for(i=0;i<num_pages;i++)-if(pages[i])-put_page(pages[i]);+if(pages&&(num_pinned>0)){+for(i=0;i<num_pinned;i++)+put_page(pages[i]);}kfree(sg_list_unaligned);+free_pages:kfree(pages);if(!ret)
From: Hans de Goede <redacted>
[ Upstream commit ef9f60daab309558c8bb3e086a9a11ee40bd6061 ]
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency. Adding 0
to the counter is a no-op. The data-sheet even explicitly states that
writing 0 to the base_unit bits will result in the PWM outputting a
continuous 0 signal.
When the user requestes a low enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value
which is bigger then base_unit_range - 1. Currently the codes for this
deals with this by applying a mask:
base_unit &= (base_unit_range - 1);
But this means that we let the value overflow the range, we throw away the
higher bits and store whatever value is left in the lower bits into the
register leading to a random output frequency, rather then clamping the
output frequency to the highest frequency which the hardware can do.
This commit fixes both issues by clamping the base_unit value to be
between 1 and (base_unit_range - 1).
Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Thierry Reding <redacted>
Signed-off-by: Hans de Goede <redacted>
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-5-hdegoede@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/pwm/pwm-lpss.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
@@ -109,6 +109,8 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, struct pwm_device *pwm,freq*=base_unit_range;base_unit=DIV_ROUND_CLOSEST_ULL(freq,c);+/* base_unit must not be 0 and we also want to avoid overflowing it */+base_unit=clamp_val(base_unit,1,base_unit_range-1);on_time_div=255ULL*duty_ns;do_div(on_time_div,period_ns);
From: Dan Carpenter <redacted>
[ Upstream commit d4f98dbfe717490e771b6e701904bfcf4b4557f0 ]
This code doesn't check if "settings->startup_profile" is within bounds
and that could result in an out of bounds array access. What the code
does do is it checks if the settings can be written to the firmware, so
it's possible that the firmware has a bounds check? It's safer and
easier to verify when the bounds checking is done in the kernel.
Fixes: 14bf62cde794 ("HID: add driver for Roccat Kone gaming mouse")
Signed-off-by: Dan Carpenter <redacted>
Signed-off-by: Jiri Kosina <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-roccat-kone.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
@@ -297,31 +297,40 @@ static ssize_t kone_sysfs_write_settings(struct file *fp, struct kobject *kobj,structkone_device*kone=hid_get_drvdata(dev_get_drvdata(dev));structusb_device*usb_dev=interface_to_usbdev(to_usb_interface(dev));intretval=0,difference,old_profile;+structkone_settings*settings=(structkone_settings*)buf;/* I need to get my data in one piece */if(off!=0||count!=sizeof(structkone_settings))return-EINVAL;mutex_lock(&kone->kone_lock);-difference=memcmp(buf,&kone->settings,sizeof(structkone_settings));+difference=memcmp(settings,&kone->settings,+sizeof(structkone_settings));if(difference){-retval=kone_set_settings(usb_dev,-(structkone_settingsconst*)buf);-if(retval){-mutex_unlock(&kone->kone_lock);-returnretval;+if(settings->startup_profile<1||+settings->startup_profile>5){+retval=-EINVAL;+gotounlock;}+retval=kone_set_settings(usb_dev,settings);+if(retval)+gotounlock;+old_profile=kone->settings.startup_profile;-memcpy(&kone->settings,buf,sizeof(structkone_settings));+memcpy(&kone->settings,settings,sizeof(structkone_settings));kone_profile_activated(kone,kone->settings.startup_profile);if(kone->settings.startup_profile!=old_profile)kone_profile_report(kone,kone->settings.startup_profile);}+unlock:mutex_unlock(&kone->kone_lock);+if(retval)+returnretval;+returnsizeof(structkone_settings);}staticBIN_ATTR(settings,0660,kone_sysfs_read_settings,
From: Thomas Preston <redacted>
[ Upstream commit b445f6237744df5e8d4f56f8733b2108c611220a ]
The mcp23x17_regmap is initialised with structs named "mcp23x16".
However, the mcp23s08 driver doesn't support the MCP23016 device yet, so
this appears to be a typo.
Fixes: 8f38910ba4f6 ("pinctrl: mcp23s08: switch to regmap caching")
Signed-off-by: Thomas Preston <redacted>
Reviewed-by: Andy Shevchenko <redacted>
Link: https://lore.kernel.org/r/20200828213226.1734264-2-thomas.preston@codethink.co.uk
Signed-off-by: Linus Walleij <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/pinctrl/pinctrl-mcp23s08.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
From: Qiushi Wu <redacted>
[ Upstream commit 7dae2aaaf432767ca7aa11fa84643a7c2600dbdd ]
pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code, causing incorrect ref count if
pm_runtime_put_noidle() is not called in error handling paths.
And also, when the call of function vpe_runtime_get() failed,
we won't call vpe_runtime_put().
Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails
inside vpe_runtime_get().
Fixes: 4571912743ac ("[media] v4l: ti-vpe: Add VPE mem to mem driver")
Signed-off-by: Qiushi Wu <redacted>
Signed-off-by: Hans Verkuil <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/ti-vpe/vpe.c | 2 ++
1 file changed, 2 insertions(+)
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
[ Upstream commit aea6cb99703e17019e025aa71643b4d3e0a24413 ]
When creating a new regulator its supply cannot create the sysfs link
because the device is not yet published. Remove early supply resolving
since it will be done later anyway. This makes the following error
disappear and the symlinks get created instead.
DCDC_REG1: supplied by VSYS
VSYS: could not add device link regulator.3 err -2
Note: It doesn't fix the problem for bypassed regulators, though.
Fixes: 45389c47526d ("regulator: core: Add early supply resolution for regulators")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/ba09e0a8617ffeeb25cb4affffe6f3149319cef8.1601155770.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/regulator/core.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
@@ -4090,15 +4090,20 @@ regulator_register(const struct regulator_desc *regulator_desc,elseif(regulator_desc->supply_name)rdev->supply_name=regulator_desc->supply_name;-/*-*Attempttoresolvetheregulatorsupply,ifspecified,-*butdon'treturnanerrorifwefailbecausewewilltry-*toresolveitagainlaterasmoreregulatorsareadded.-*/-if(regulator_resolve_supply(rdev))-rdev_dbg(rdev,"unable to resolve supply\n");-ret=set_machine_constraints(rdev,constraints);+if(ret==-EPROBE_DEFER){+/* Regulator might be in bypass mode and so needs its supply+*tosettheconstraints*/+/* FIXME: this currently triggers a chicken-and-egg problem+*whencreating-SUPPLYsymlinkinsysfstoaregulator+*thatisjustbeingcreated*/+ret=regulator_resolve_supply(rdev);+if(!ret)+ret=set_machine_constraints(rdev,constraints);+else+rdev_dbg(rdev,"unable to resolve supply early: %pe\n",+ERR_PTR(ret));+}if(ret<0)gotowash;
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit 3e1b6469f8324bee5927b063e2aca30d3e56b907 ]
Building lpddr2_nvm with clang can result in a giant stack usage
in one function:
drivers/mtd/lpddr/lpddr2_nvm.c:399:12: error: stack frame size of 1144 bytes in function 'lpddr2_nvm_probe' [-Werror,-Wframe-larger-than=]
The problem is that clang decides to build a copy of the mtd_info
structure on the stack and then do a memcpy() into the actual version. It
shouldn't really do it that way, but it's not strictly a bug either.
As a workaround, use a static const version of the structure to assign
most of the members upfront and then only set the few members that
require runtime knowledge at probe time.
Fixes: 96ba9dd65788 ("mtd: lpddr: add driver for LPDDR2-NVM PCM memories")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <redacted>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200505140136.263461-1-arnd@arndb.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/mtd/lpddr/lpddr2_nvm.c | 35 ++++++++++++++++++----------------
1 file changed, 19 insertions(+), 16 deletions(-)
@@ -448,6 +459,7 @@ static int lpddr2_nvm_probe(struct platform_device *pdev).pfow_base=OW_BASE_ADDRESS,.fldrv_priv=pcm_data,};+if(IS_ERR(map->virt))returnPTR_ERR(map->virt);
@@ -459,22 +471,13 @@ static int lpddr2_nvm_probe(struct platform_device *pdev)returnPTR_ERR(pcm_data->ctl_regs);/* Populate mtd_info data structure */-*mtd=(structmtd_info){-.dev={.parent=&pdev->dev},-.name=pdev->dev.init_name,-.type=MTD_RAM,-.priv=map,-.size=resource_size(add_range),-.erasesize=ERASE_BLOCKSIZE*pcm_data->bus_width,-.writesize=1,-.writebufsize=WRITE_BUFFSIZE*pcm_data->bus_width,-.flags=(MTD_CAP_NVRAM|MTD_POWERUP_LOCK),-._read=lpddr2_nvm_read,-._write=lpddr2_nvm_write,-._erase=lpddr2_nvm_erase,-._unlock=lpddr2_nvm_unlock,-._lock=lpddr2_nvm_lock,-};+*mtd=lpddr2_nvm_mtd_info;+mtd->dev.parent=&pdev->dev;+mtd->name=pdev->dev.init_name;+mtd->priv=map;+mtd->size=resource_size(add_range);+mtd->erasesize=ERASE_BLOCKSIZE*pcm_data->bus_width;+mtd->writebufsize=WRITE_BUFFSIZE*pcm_data->bus_width;/* Verify the presence of the device looking for PFOW string */if(!lpddr2_nvm_pfow_present(map)){
From: Finn Thain <redacted>
[ Upstream commit 66943005cc41f48e4d05614e8f76c0ca1812f0fd ]
According to the MPC750 Users Manual, the SITV value in Thermal
Management Register 3 is 13 bits long. The present code calculates the
SITV value as 60 * 500 cycles. This would overflow to give 10 us on
a 500 MHz CPU rather than the intended 60 us. (But according to the
Microprocessor Datasheet, there is also a factor of 266 that has to be
applied to this value on certain parts i.e. speed sort above 266 MHz.)
Always use the maximum cycle count, as recommended by the Datasheet.
Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2")
Signed-off-by: Finn Thain <redacted>
Tested-by: Stan Johnson <redacted>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/896f542e5f0f1d6cf8218524c2b67d79f3d69b3c.1599260540.git.fthain@telegraphics.com.au
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/reg.h | 2 +-
arch/powerpc/kernel/tau_6xx.c | 12 ++++--------
2 files changed, 5 insertions(+), 9 deletions(-)
@@ -175,15 +175,11 @@ static void tau_timeout(void * info)*complexsleepcodeneedstobeadded.Onemtspreverytime*tau_timeoutiscalledisprobablynotabigdeal.*-*Enablethermalsensorandsetupsampleintervaltimer-*need20ustodothecompare..untilanice'cpu_speed'function-*callisimplemented,justassumea500mhzclock.Itdoesn'treally-*matterifwetaketoolongforacomparesinceit'sallinterrupt-*drivenanyway.-*-*useaextralongtime..(60us@500mhz)+*The"PowerPC 740 and PowerPC 750 Microprocessor Datasheet"+*recommendsthat"the maximum value be set in THRM3 under all+*conditions."*/-mtspr(SPRN_THRM3,THRM3_SITV(500*60)|THRM3_E);+mtspr(SPRN_THRM3,THRM3_SITV(0x1fff)|THRM3_E);local_irq_restore(flags);}
From: Finn Thain <redacted>
[ Upstream commit 420ab2bc7544d978a5d0762ee736412fe9c796ab ]
The commentary at the call site seems to disagree with the code. The
conditional prevents calling set_thresholds() via the exception handler,
which appears to crash. Perhaps that's because it immediately triggers
another TAU exception. Anyway, calling set_thresholds() from TAUupdate()
is redundant because tau_timeout() does so.
Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2")
Signed-off-by: Finn Thain <redacted>
Tested-by: Stan Johnson <redacted>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/d7c7ee33232cf72a6a6bbb6ef05838b2e2b113c0.1599260540.git.fthain@telegraphics.com.au
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kernel/tau_6xx.c | 5 -----
1 file changed, 5 deletions(-)
@@ -108,11 +108,6 @@ void TAUupdate(int cpu)#ifdef DEBUGprintk("grew = %d\n",tau[cpu].grew);#endif--#ifndef CONFIG_TAU_INT /* tau_timeout will do this if not using interrupts */-set_thresholds(cpu);-#endif-}#ifdef CONFIG_TAU_INT
@@ -38,8 +38,6 @@ static struct tau_tempstructtimer_listtau_timer;-#undef DEBUG-/* TODO: put these in a /proc interface, with some sanity checks, and maybe*dynamicadjustmenttominimize#ofinterrupts*//* configurable values for step size and how much to expand the window when
@@ -72,42 +70,33 @@ void set_thresholds(unsigned long cpu)voidTAUupdate(intcpu){-unsignedthrm;--#ifdef DEBUG-printk("TAUupdate ");-#endif+u32thrm;+u32bits=THRM1_TIV|THRM1_TIN|THRM1_V;/* if both thresholds are crossed, the step_sizes cancel out*andthewindowwindsupgettingexpandedtwice.*/-if((thrm=mfspr(SPRN_THRM1))&THRM1_TIV){/* is valid? */-if(thrm&THRM1_TIN){/* crossed low threshold */-if(tau[cpu].low>=step_size){-tau[cpu].low-=step_size;-tau[cpu].high-=(step_size-window_expand);-}-tau[cpu].grew=1;-#ifdef DEBUG-printk("low threshold crossed ");-#endif+thrm=mfspr(SPRN_THRM1);+if((thrm&bits)==bits){+mtspr(SPRN_THRM1,0);++if(tau[cpu].low>=step_size){+tau[cpu].low-=step_size;+tau[cpu].high-=(step_size-window_expand);}+tau[cpu].grew=1;+pr_debug("%s: low threshold crossed\n",__func__);}-if((thrm=mfspr(SPRN_THRM2))&THRM1_TIV){/* is valid? */-if(thrm&THRM1_TIN){/* crossed high threshold */-if(tau[cpu].high<=127-step_size){-tau[cpu].low+=(step_size-window_expand);-tau[cpu].high+=step_size;-}-tau[cpu].grew=1;-#ifdef DEBUG-printk("high threshold crossed ");-#endif+thrm=mfspr(SPRN_THRM2);+if((thrm&bits)==bits){+mtspr(SPRN_THRM2,0);++if(tau[cpu].high<=127-step_size){+tau[cpu].low+=(step_size-window_expand);+tau[cpu].high+=step_size;}+tau[cpu].grew=1;+pr_debug("%s: high threshold crossed\n",__func__);}--#ifdef DEBUG-printk("grew = %d\n",tau[cpu].grew);-#endif}#ifdef CONFIG_TAU_INT
@@ -132,18 +121,18 @@ void TAUException(struct pt_regs * regs)staticvoidtau_timeout(void*info){intcpu;-unsignedlongflags;intsize;intshrink;-/* disabling interrupts *should* be okay */-local_irq_save(flags);cpu=smp_processor_id();#ifndef CONFIG_TAU_INTTAUupdate(cpu);#endif+/* Stop thermal sensor comparisons and interrupts */+mtspr(SPRN_THRM3,0);+size=tau[cpu].high-tau[cpu].low;if(size>min_window&&!tau[cpu].grew){/* do an exponential shrink of half the amount currently over size */
@@ -165,18 +154,12 @@ static void tau_timeout(void * info)set_thresholds(cpu);-/*-*Dotheenableeverytime,sinceotherwiseabunchof(relatively)-*complexsleepcodeneedstobeadded.Onemtspreverytime-*tau_timeoutiscalledisprobablynotabigdeal.-*+/* Restart thermal sensor comparisons and interrupts.*The"PowerPC 740 and PowerPC 750 Microprocessor Datasheet"*recommendsthat"the maximum value be set in THRM3 under all*conditions."*/mtspr(SPRN_THRM3,THRM3_SITV(0x1fff)|THRM3_E);--local_irq_restore(flags);}staticvoidtau_timeout_smp(unsignedlongunused)
@@ -243,7 +243,7 @@ config TAUtempisactuallywhat/proc/cpuinfosaysitis.configTAU_INT-bool"Interrupt driven TAU driver (DANGEROUS)"+bool"Interrupt driven TAU driver (EXPERIMENTAL)"depends onTAU---help---TheTAUsupportsaninterruptdrivenmodewhichcausesaninterrupt
@@ -251,12 +251,7 @@ config TAU_INTtogetnotifiedthetemphasexceededarange.Withthisoptionoff,atimerisusedtore-checkthetemperatureperiodically.-However,onsomecpusitappearsthattheTAUinterrupthardware-isbuggyandcancauseasituationwhichwouldleadunexplainedhard-lockups.--UnlessyouareextendingtheTAUdriver,orenjoykernel/hardware-debugging,leavethisoptionoff.+Ifindoubt,sayNhere.configTAU_AVERAGEbool"Average high and low temp"
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
[ Upstream commit 505f394fa239cecb76d916aa858f87ed7ea7fde4 ]
With commit 4f3882177240 hid-input started clearing of "ignored" usages
to avoid using garbage that might have been left in them. However
"battery strength" usages should not be ignored, as we do want to
use them.
Fixes: 4f3882177240 ("HID: hid-input: clear unmapped usages")
Reported-by: Kenneth Albanowski <redacted>
Tested-by: Kenneth Albanowski <redacted>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-input.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Thomas Gleixner <redacted>
[ Upstream commit a53b59ece86c86d16d12ccdaa1ad0c78250a9d96 ]
enic_dev_wait() has a BUG_ON(in_interrupt()).
Chasing the callers of enic_dev_wait() revealed the gems of enic_reset()
and enic_tx_hang_reset() which are both invoked through work queues in
order to be able to call rtnl_lock(). So far so good.
After locking rtnl both functions acquire enic::enic_api_lock which
serializes against the (ab)use from infiniband. This is where the
trainwreck starts.
enic::enic_api_lock is a spin_lock() which implicitly disables preemption,
but both functions invoke a ton of functions under that lock which can
sleep. The BUG_ON(in_interrupt()) does not trigger in that case because it
can't detect the preempt disabled condition.
This clearly has never been tested with any of the mandatory debug options
for 7+ years, which would have caught that for sure.
Cure it by adding a enic_api_busy member to struct enic, which is modified
and evaluated with enic::enic_api_lock held.
If enic_api_devcmd_proxy_by_index() observes enic::enic_api_busy as true,
it drops enic::enic_api_lock and busy waits for enic::enic_api_busy to
become false.
It would be smarter to wait for a completion of that busy period, but
enic_api_devcmd_proxy_by_index() is called with other spin locks held which
obviously can't sleep.
Remove the BUG_ON(in_interrupt()) check as well because it's incomplete and
with proper debugging enabled the problem would have been caught from the
debug checks in schedule_timeout().
Fixes: 0b038566c0ea ("drivers/net: enic: Add an interface for USNIC to interact with firmware")
Signed-off-by: Thomas Gleixner <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/cisco/enic/enic.h | 1 +
drivers/net/ethernet/cisco/enic/enic_api.c | 6 +++++
drivers/net/ethernet/cisco/enic/enic_main.c | 27 ++++++++++++++++-----
3 files changed, 28 insertions(+), 6 deletions(-)
@@ -34,6 +34,12 @@ int enic_api_devcmd_proxy_by_index(struct net_device *netdev, int vf,structvnic_dev*vdev=enic->vdev;spin_lock(&enic->enic_api_lock);+while(enic->enic_api_busy){+spin_unlock(&enic->enic_api_lock);+cpu_relax();+spin_lock(&enic->enic_api_lock);+}+spin_lock_bh(&enic->devcmd_lock);vnic_dev_cmd_proxy_by_index_start(vdev,vf);
@@ -2101,8 +2101,6 @@ static int enic_dev_wait(struct vnic_dev *vdev,intdone;interr;-BUG_ON(in_interrupt());-err=start(vdev,arg);if(err)returnerr;
@@ -2279,6 +2277,13 @@ static int enic_set_rss_nic_cfg(struct enic *enic)rss_hash_bits,rss_base_cpu,rss_enable);}+staticvoidenic_set_api_busy(structenic*enic,boolbusy)+{+spin_lock(&enic->enic_api_lock);+enic->enic_api_busy=busy;+spin_unlock(&enic->enic_api_lock);+}+staticvoidenic_reset(structwork_struct*work){structenic*enic=container_of(work,structenic,reset);
@@ -2288,7 +2293,9 @@ static void enic_reset(struct work_struct *work)rtnl_lock();-spin_lock(&enic->enic_api_lock);+/* Stop any activity from infiniband */+enic_set_api_busy(enic,true);+enic_stop(enic->netdev);enic_dev_soft_reset(enic);enic_reset_addr_lists(enic);
@@ -2296,7 +2303,10 @@ static void enic_reset(struct work_struct *work)enic_set_rss_nic_cfg(enic);enic_dev_set_ig_vlan_rewrite_mode(enic);enic_open(enic->netdev);-spin_unlock(&enic->enic_api_lock);++/* Allow infiniband to fiddle with the device again */+enic_set_api_busy(enic,false);+call_netdevice_notifiers(NETDEV_REBOOT,enic->netdev);rtnl_unlock();
@@ -2308,7 +2318,9 @@ static void enic_tx_hang_reset(struct work_struct *work)rtnl_lock();-spin_lock(&enic->enic_api_lock);+/* Stop any activity from infiniband */+enic_set_api_busy(enic,true);+enic_dev_hang_notify(enic);enic_stop(enic->netdev);enic_dev_hang_reset(enic);
@@ -2317,7 +2329,10 @@ static void enic_tx_hang_reset(struct work_struct *work)enic_set_rss_nic_cfg(enic);enic_dev_set_ig_vlan_rewrite_mode(enic);enic_open(enic->netdev);-spin_unlock(&enic->enic_api_lock);++/* Allow infiniband to fiddle with the device again */+enic_set_api_busy(enic,false);+call_netdevice_notifiers(NETDEV_REBOOT,enic->netdev);rtnl_unlock();
From: Athira Rajeev <redacted>
[ Upstream commit 3b6c3adbb2fa42749c3d38cfc4d4d0b7e096bb7b ]
PMU counter support functions enforces event constraints for group of
events to check if all events in a group can be monitored. Incase of
event codes using PMC5 and PMC6 ( 500fa and 600f4 respectively ), not
all constraints are applicable, say the threshold or sample bits. But
current code includes pmc5 and pmc6 in some group constraints (like
IC_DC Qualifier bits) which is actually not applicable and hence
results in those events not getting counted when scheduled along with
group of other events. Patch fixes this by excluding PMC5/6 from
constraints which are not relevant for it.
Fixes: 7ffd948 ("powerpc/perf: factor out power8 pmu functions")
Signed-off-by: Athira Rajeev <redacted>
Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1600672204-1610-1-git-send-email-atrajeev@linux.vnet.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/perf/isa207-common.c | 10 ++++++++++
1 file changed, 10 insertions(+)
@@ -275,6 +275,15 @@ int isa207_get_constraint(u64 event, unsigned long *maskp, unsigned long *valp)mask|=CNST_PMC_MASK(pmc);value|=CNST_PMC_VAL(pmc);++/*+*PMC5andPMC6areusedtocountcyclesandinstructionsand+*theydonotsupportmostoftheconstraintbits.Addacheck+*toexcludePMC5/6frommostoftheconstraintsexceptfor+*EBB/BHRB.+*/+if(pmc>=5)+gotoebb_bhrb;}if(pmc<=4){
@@ -333,6 +342,7 @@ int isa207_get_constraint(u64 event, unsigned long *maskp, unsigned long *valp)}}+ebb_bhrb:if(!pmc&&ebb)/* EBB events must specify the PMC */return-1;
From: Jassi Brar <redacted>
[ Upstream commit c7dacf5b0f32957b24ef29df1207dc2cd8307743 ]
If the txdone is done by polling, it is possible for msg_submit() to start
the timer while txdone_hrtimer() callback is running. If the timer needs
recheduling, it could already be enqueued by the time hrtimer_forward_now()
is called, leading hrtimer to loudly complain.
WARNING: CPU: 3 PID: 74 at kernel/time/hrtimer.c:932 hrtimer_forward+0xc4/0x110
CPU: 3 PID: 74 Comm: kworker/u8:1 Not tainted 5.9.0-rc2-00236-gd3520067d01c-dirty #5
Hardware name: Libre Computer AML-S805X-AC (DT)
Workqueue: events_freezable_power_ thermal_zone_device_check
pstate: 20000085 (nzCv daIf -PAN -UAO BTYPE=--)
pc : hrtimer_forward+0xc4/0x110
lr : txdone_hrtimer+0xf8/0x118
[...]
This can be fixed by not starting the timer from the callback path. Which
requires the timer reloading as long as any message is queued on the
channel, and not just when current tx is not done yet.
Fixes: 0cc67945ea59 ("mailbox: switch to hrtimer for tx_complete polling")
Reported-by: Da Xue <redacted>
Reviewed-by: Sudeep Holla <redacted>
Tested-by: Sudeep Holla <redacted>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Tested-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Jassi Brar <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/mailbox/mailbox.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
@@ -85,9 +85,12 @@ static void msg_submit(struct mbox_chan *chan)exit:spin_unlock_irqrestore(&chan->lock,flags);-if(!err&&(chan->txdone_method&TXDONE_BY_POLL))-/* kick start the timer immediately to avoid delays */-hrtimer_start(&chan->mbox->poll_hrt,0,HRTIMER_MODE_REL);+/* kick start the timer immediately to avoid delays */+if(!err&&(chan->txdone_method&TXDONE_BY_POLL)){+/* but only if not already active */+if(!hrtimer_active(&chan->mbox->poll_hrt))+hrtimer_start(&chan->mbox->poll_hrt,0,HRTIMER_MODE_REL);+}}staticvoidtx_tick(structmbox_chan*chan,intr)
From: Mark Tomlinson <redacted>
[ Upstream commit eb7eacaa5b9e4f665bd08d416c8f88e63d2f123c ]
The core interrupt code expects the irq_set_affinity call to update the
effective affinity for the interrupt. This was not being done, so update
iproc_msi_irq_set_affinity() to do so.
Link: https://lore.kernel.org/r/20200803035241.7737-1-mark.tomlinson@alliedtelesis.co.nz
Fixes: 3bc2b2348835 ("PCI: iproc: Add iProc PCIe MSI support")
Signed-off-by: Mark Tomlinson <redacted>
Signed-off-by: Lorenzo Pieralisi <redacted>
Reviewed-by: Ray Jui <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/pci/host/pcie-iproc-msi.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
@@ -217,15 +217,20 @@ static int iproc_msi_irq_set_affinity(struct irq_data *data,structiproc_msi*msi=irq_data_get_irq_chip_data(data);inttarget_cpu=cpumask_first(mask);intcurr_cpu;+intret;curr_cpu=hwirq_to_cpu(msi,data->hwirq);if(curr_cpu==target_cpu)-returnIRQ_SET_MASK_OK_DONE;+ret=IRQ_SET_MASK_OK_DONE;+else{+/* steer MSI to the target CPU */+data->hwirq=hwirq_to_canonical_hwirq(msi,data->hwirq)+target_cpu;+ret=IRQ_SET_MASK_OK;+}-/* steer MSI to the target CPU */-data->hwirq=hwirq_to_canonical_hwirq(msi,data->hwirq)+target_cpu;+irq_data_update_effective_affinity(data,cpumask_of(target_cpu));-returnIRQ_SET_MASK_OK;+returnret;}staticvoidiproc_msi_irq_compose_msi_msg(structirq_data*data,
From: Alex Williamson <redacted>
[ Upstream commit 852b1beecb6ff9326f7ca4bc0fe69ae860ebdb9e ]
The eventfd context is used as our irqbypass token, therefore if an
eventfd is re-used, our token is the same. The irqbypass code will
return an -EBUSY in this case, but we'll still attempt to unregister
the producer, where if that duplicate token still exists, results in
removing the wrong object. Clear the token of failed producers so
that they harmlessly fall out when unregistered.
Fixes: 6d7425f109d2 ("vfio: Register/unregister irq_bypass_producer")
Reported-by: guomin chen <redacted>
Tested-by: guomin chen <redacted>
Signed-off-by: Alex Williamson <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/vfio/pci/vfio_pci_intrs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: Vasant Hegde <redacted>
[ Upstream commit 0a43ae3e2beb77e3481d812834d33abe270768ab ]
Every dump reported by OPAL is exported to userspace through a sysfs
interface and notified using kobject_uevent(). The userspace daemon
(opal_errd) then reads the dump and acknowledges that the dump is
saved safely to disk. Once acknowledged the kernel removes the
respective sysfs file entry causing respective resources to be
released including kobject.
However it's possible the userspace daemon may already be scanning
dump entries when a new sysfs dump entry is created by the kernel.
User daemon may read this new entry and ack it even before kernel can
notify userspace about it through kobject_uevent() call. If that
happens then we have a potential race between
dump_ack_store->kobject_put() and kobject_uevent which can lead to
use-after-free of a kernfs object resulting in a kernel crash.
This patch fixes this race by protecting the sysfs file
creation/notification by holding a reference count on kobject until we
safely send kobject_uevent().
The function create_dump_obj() returns the dump object which if used
by caller function will end up in use-after-free problem again.
However, the return value of create_dump_obj() function isn't being
used today and there is no need as well. Hence change it to return
void to make this fix complete.
Fixes: c7e64b9ce04a ("powerpc/powernv Platform dump interface")
Signed-off-by: Vasant Hegde <redacted>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201017164210.264619-1-hegdevasant@linux.vnet.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/platforms/powernv/opal-dump.c | 41 +++++++++++++++-------
1 file changed, 29 insertions(+), 12 deletions(-)
@@ -347,21 +346,39 @@ static struct dump_obj *create_dump_obj(uint32_t id, size_t size,rc=kobject_add(&dump->kobj,NULL,"0x%x-0x%x",type,id);if(rc){kobject_put(&dump->kobj);-returnNULL;+return;}+/*+*Assoonasthesysfsfileforthisdumpiscreated/activatedthereis+*achancetheopal_errddaemon(oranyuserspace)mightreadand+*acknowledgethedumpbeforekobject_uevent()iscalled.Ifthat+*happensthenthereisapotentialracebetween+*dump_ack_store->kobject_put()andkobject_uevent()whichleadstoa+*use-after-freeofakernfsobjectresultinginakernelcrash.+*+*Toavoidthat,weneedtotakeareferenceonbehalfofthebinfile,+*sothatourreferenceremainsvalidwhilewecallkobject_uevent().+*Wethendropourreferencebeforeexitingthefunction,leavingthe+*binfiletodropthelastreference(ifithasn'talready).+*/++/* Take a reference for the bin file */+kobject_get(&dump->kobj);rc=sysfs_create_bin_file(&dump->kobj,&dump->dump_attr);-if(rc){+if(rc==0){+kobject_uevent(&dump->kobj,KOBJ_ADD);++pr_info("%s: New platform dump. ID = 0x%x Size %u\n",+__func__,dump->id,dump->size);+}else{+/* Drop reference count taken for bin file */kobject_put(&dump->kobj);-returnNULL;}-pr_info("%s: New platform dump. ID = 0x%x Size %u\n",-__func__,dump->id,dump->size);--kobject_uevent(&dump->kobj,KOBJ_ADD);--returndump;+/* Drop our reference */+kobject_put(&dump->kobj);+return;}staticirqreturn_tprocess_dump(intirq,void*data)
From: zhenwei pi <redacted>
[ Upstream commit 85bd23f3dc09a2ae9e56885420e52c54bf983713 ]
When connecting a controller with a zero kato value using the following
command line
nvme connect -t tcp -n NQN -a ADDR -s PORT --keep-alive-tmo=0
the warning below can be reproduced:
WARNING: CPU: 1 PID: 241 at kernel/workqueue.c:1627 __queue_delayed_work+0x6d/0x90
with trace:
mod_delayed_work_on+0x59/0x90
nvmet_update_cc+0xee/0x100 [nvmet]
nvmet_execute_prop_set+0x72/0x80 [nvmet]
nvmet_tcp_try_recv_pdu+0x2f7/0x770 [nvmet_tcp]
nvmet_tcp_io_work+0x63f/0xb2d [nvmet_tcp]
...
This is caused by queuing up an uninitialized work. Althrough the
keep-alive timer is disabled during allocating the controller (fixed in
0d3b6a8d213a), ka_work still has a chance to run (called by
nvmet_start_ctrl).
Fixes: 0d3b6a8d213a ("nvmet: Disable keep-alive timer when kato is cleared to 0h")
Signed-off-by: zhenwei pi <redacted>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/nvme/target/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Kaige Li <redacted>
[ Upstream commit 44a0a3c17919db1498cebb02ecf3cf4abc1ade7b ]
The related system resources were not released when pci_set_dma_mask(),
pci_set_consistent_dma_mask(), or pci_iomap() return error in the
amd_ntb_init_pci() function. Add pci_release_regions() to fix it.
Fixes: a1b3695820aa ("NTB: Add support for AMD PCI-Express Non-Transparent Bridge")
Signed-off-by: Kaige Li <redacted>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/ntb/hw/amd/ntb_hw_amd.c | 1 +
1 file changed, 1 insertion(+)
From: Al Grant <redacted>
[ Upstream commit f3d301c1f2f5676465cdf3259737ea19cc82731f ]
perf_event.h has macros that define the field offsets in the
data_src bitmask in perf records. The SNOOPX and REMOTE offsets
were both 37. These are distinct fields, and the bitfield layout
in perf_mem_data_src confirms that SNOOPX should be at offset 38.
Fixes: 52839e653b5629bd ("perf tools: Add support for printing new mem_info encodings")
Signed-off-by: Al Grant <redacted>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Andi Kleen <redacted>
Link: https://lkml.kernel.org/r/4ac9f5cc-4388-b34a-9999-418a4099415d@foss.arm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/uapi/linux/perf_event.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Colin Ian King <redacted>
[ Upstream commit 8e71f694e0c819db39af2336f16eb9689f1ae53f ]
An incorrect sizeof is being used, struct rvt_ibport ** is not correct, it
should be struct rvt_ibport *. Note that since ** is the same size as
* this is not causing any issues. Improve this fix by using
sizeof(*rdi->ports) as this allows us to not even reference the type
of the pointer. Also remove line breaks as the entire statement can
fit on one line.
Link: https://lore.kernel.org/r/20201008095204.82683-1-colin.king@canonical.com
Addresses-Coverity: ("Sizeof not portable (SIZEOF_MISMATCH)")
Fixes: ff6acd69518e ("IB/rdmavt: Add device structure allocation")
Signed-off-by: Colin Ian King <redacted>
Reviewed-by: Ira Weiny <redacted>
Acked-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/sw/rdmavt/vt.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
From: Leon Romanovsky <leonro@nvidia.com>
[ Upstream commit a4947e84f23474803b62a2759b5808147e4e15f9 ]
The various array_size functions use SIZE_MAX define, but missed limits.h
causes to failure to compile code that needs overflow.h.
In file included from drivers/infiniband/core/uverbs_std_types_device.c:6:
./include/linux/overflow.h: In function 'array_size':
./include/linux/overflow.h:258:10: error: 'SIZE_MAX' undeclared (first use in this function)
258 | return SIZE_MAX;
| ^~~~~~~~
Fixes: 610b15c50e86 ("overflow.h: Add allocation size calculation helpers")
Link: https://lore.kernel.org/r/20200913102928.134985-1-leon@kernel.org
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/linux/overflow.h | 1 +
1 file changed, 1 insertion(+)
From: Dinghao Liu <redacted>
[ Upstream commit d912a1d9e9afe69c6066c1ceb6bfc09063074075 ]
pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu <redacted>
Signed-off-by: Hans Verkuil <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/sti/hva/hva-hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -393,7 +393,7 @@ int hva_hw_probe(struct platform_device *pdev, struct hva_dev *hva)ret=pm_runtime_get_sync(dev);if(ret<0){dev_err(dev,"%s failed to set PM\n",HVA_PREFIX);-gotoerr_clk;+gotoerr_pm;}/* check IP hardware version */
From: Adam Goode <redacted>
[ Upstream commit 8a652a17e3c005dcdae31b6c8fdf14382a29cbbe ]
bFrameIndex and bFormatIndex can be negotiated by the camera during
probing, resulting in the camera choosing a different format than
expected. v4l2 can already accommodate such changes, but the code was
not updating the proper fields.
Without such a change, v4l2 would potentially interpret the payload
incorrectly, causing corrupted output. This was happening on the
Elgato HD60 S+, which currently always renegotiates to format 1.
As an aside, the Elgato firmware is buggy and should not be renegotating,
but it is still a valid thing for the camera to do. Both macOS and Windows
will properly probe and read uncorrupted images from this camera.
With this change, both qv4l2 and chromium can now read uncorrupted video
from the Elgato HD60 S+.
[Add blank lines, remove periods at the of messages]
Signed-off-by: Adam Goode <redacted>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/usb/uvc/uvc_v4l2.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
@@ -252,11 +252,41 @@ static int uvc_v4l2_try_format(struct uvc_streaming *stream,if(ret<0)gotodone;+/* After the probe, update fmt with the values returned from+*negotiationwiththedevice.+*/+for(i=0;i<stream->nformats;++i){+if(probe->bFormatIndex==stream->format[i].index){+format=&stream->format[i];+break;+}+}++if(i==stream->nformats){+uvc_trace(UVC_TRACE_FORMAT,"Unknown bFormatIndex %u\n",+probe->bFormatIndex);+return-EINVAL;+}++for(i=0;i<format->nframes;++i){+if(probe->bFrameIndex==format->frame[i].bFrameIndex){+frame=&format->frame[i];+break;+}+}++if(i==format->nframes){+uvc_trace(UVC_TRACE_FORMAT,"Unknown bFrameIndex %u\n",+probe->bFrameIndex);+return-EINVAL;+}+fmt->fmt.pix.width=frame->wWidth;fmt->fmt.pix.height=frame->wHeight;fmt->fmt.pix.field=V4L2_FIELD_NONE;fmt->fmt.pix.bytesperline=uvc_v4l2_get_bytesperline(format,frame);fmt->fmt.pix.sizeimage=probe->dwMaxVideoFrameSize;+fmt->fmt.pix.pixelformat=format->fcc;fmt->fmt.pix.colorspace=format->colorspace;fmt->fmt.pix.priv=0;
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
[ Upstream commit 15a36aae1ec1c1f17149b6113b92631791830740 ]
As reported by smatch:
drivers/media/pci/saa7134//saa7134-tvaudio.c:686 saa_dsp_writel() warn: should 'reg << 2' be a 64 bit type?
On a 64-bits Kernel, the shift might be bigger than 32 bits.
In real, this should never happen, but let's shut up the warning.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/pci/saa7134/saa7134-tvaudio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Thomas Pedersen <redacted>
[ Upstream commit 8b783d104e7f40684333d2ec155fac39219beb2f ]
Even though a driver or mac80211 shouldn't produce a
legacy bitrate if sband->bitrates doesn't exist, don't
crash if that is the case either.
This fixes a kernel panic if station dump is run before
last_rate can be updated with a data frame when
sband->bitrates is missing (eg. in S1G bands).
Signed-off-by: Thomas Pedersen <redacted>
Link: https://lore.kernel.org/r/20201005164522.18069-1-thomas@adapt-ip.com
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/cfg.c | 3 ++-
net/mac80211/sta_info.c | 4 ++++
2 files changed, 6 insertions(+), 1 deletion(-)
From: Christoph Hellwig <hch@lst.de>
[ Upstream commit 428805c0c5e76ef643b1fbc893edfb636b3d8aef ]
get_gendisk grabs a reference on the disk and file operation, so this
code will leak both of them while having absolutely no use for the
gendisk itself.
This effectively reverts commit 2df83fa4bce421f ("PM / Hibernate: Use
get_gendisk to verify partition if resume_file is integer format")
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Rafael J. Wysocki <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/power/hibernate.c | 11 -----------
1 file changed, 11 deletions(-)
@@ -833,17 +833,6 @@ static int software_resume(void)/* Check if the device is there */swsusp_resume_device=name_to_dev_t(resume_file);--/*-*name_to_dev_tisineffectivetoverifyparitionifresume_fileisin-*integerformat.(e.g.major:minor)-*/-if(isdigit(resume_file[0])&&resume_wait){-intpartno;-while(!get_gendisk(swsusp_resume_device,&partno))-msleep(10);-}-if(!swsusp_resume_device){/**Somedevicediscoverymightstillbeinprogress;weneed