This is the start of the stable review cycle for the 4.19.235 release.
There are 30 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed, 16 Mar 2022 11:27:22 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.235-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.19.235-rc1
Valentin Schneider <[email protected]>
ia64: ensure proper NUMA distance and possible map initialization
Dietmar Eggemann <[email protected]>
sched/topology: Fix sched_domain_topology_level alloc in sched_init_numa()
Valentin Schneider <[email protected]>
sched/topology: Make sched_init_numa() use a set for the deduplicating sort
Qu Wenruo <[email protected]>
btrfs: unlock newly allocated extent buffer after error
Josh Triplett <[email protected]>
ext4: add check to prevent attempting to resize an fs with sparse_super2
Russell King (Oracle) <[email protected]>
ARM: fix Thumb2 regression with Spectre BHB
Michael S. Tsirkin <[email protected]>
virtio: acknowledge all features before access
Michael S. Tsirkin <[email protected]>
virtio: unexport virtio_finalize_features
James Morse <[email protected]>
KVM: arm64: Reset PMC_EL0 to avoid a panic() on systems with no PMU
Emil Renner Berthing <[email protected]>
riscv: Fix auipc+jalr relocation range checks
Robert Hancock <[email protected]>
net: macb: Fix lost RX packet wakeup race in NAPI receive
Dan Carpenter <[email protected]>
staging: gdm724x: fix use after free in gdm_lte_rx()
Randy Dunlap <[email protected]>
ARM: Spectre-BHB: provide empty stub for non-config
Mike Kravetz <[email protected]>
selftests/memfd: clean up mapping in mfd_fail_write
Sven Schnelle <[email protected]>
tracing: Ensure trace buffer is at least 4096 bytes large
Marek Marczykowski-Górecki <[email protected]>
Revert "xen-netback: Check for hotplug-status existence before watching"
Marek Marczykowski-Górecki <[email protected]>
Revert "xen-netback: remove 'hotplug-status' once it has served its purpose"
suresh kumar <[email protected]>
net-sysfs: add check for netdevice being present to speed_show
Eric Dumazet <[email protected]>
sctp: fix kernel-infoleak for SCTP sockets
Clément Léger <[email protected]>
net: phy: DP83822: clear MISR2 register to disable interrupts
Miaoqian Lin <[email protected]>
gianfar: ethtool: Fix refcount leak in gfar_get_ts_info
Mark Featherston <[email protected]>
gpio: ts4900: Do not set DAT and OE together
Pavel Skripkin <[email protected]>
NFC: port100: fix use-after-free in port100_send_complete
Mohammad Kabat <[email protected]>
net/mlx5: Fix size field in bufferx_reg struct
Duoming Zhou <[email protected]>
ax25: Fix NULL pointer dereference in ax25_kill_by_device
Jiasheng Jiang <[email protected]>
net: ethernet: lpc_eth: Handle error for clk_enable
Jiasheng Jiang <[email protected]>
net: ethernet: ti: cpts: Handle error for clk_enable
Miaoqian Lin <[email protected]>
ethernet: Fix error handling in xemaclite_of_probe
Tom Rix <[email protected]>
qed: return status of qed_iov_get_link
Jia-Ju Bai <[email protected]>
net: qlogic: check the return value of dma_alloc_coherent() in qed_vf_hw_prepare()
-------------
Diffstat:
Makefile | 4 +-
arch/arm/include/asm/spectre.h | 6 ++
arch/arm/kernel/entry-armv.S | 4 +-
arch/arm64/kvm/sys_regs.c | 4 +-
arch/ia64/kernel/acpi.c | 7 +-
arch/riscv/kernel/module.c | 21 +++--
drivers/gpio/gpio-ts4900.c | 24 ++++--
drivers/net/ethernet/cadence/macb_main.c | 25 +++++-
drivers/net/ethernet/freescale/gianfar_ethtool.c | 1 +
drivers/net/ethernet/nxp/lpc_eth.c | 5 +-
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 18 +++--
drivers/net/ethernet/qlogic/qed/qed_vf.c | 7 ++
drivers/net/ethernet/ti/cpts.c | 4 +-
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 4 +-
drivers/net/phy/dp83822.c | 2 +-
drivers/net/xen-netback/xenbus.c | 13 ++--
drivers/nfc/port100.c | 2 +
drivers/staging/gdm724x/gdm_lte.c | 5 +-
drivers/virtio/virtio.c | 40 +++++-----
fs/btrfs/extent-tree.c | 1 +
fs/ext4/resize.c | 5 ++
include/linux/mlx5/mlx5_ifc.h | 4 +-
include/linux/topology.h | 1 +
include/linux/virtio.h | 1 -
include/linux/virtio_config.h | 3 +-
kernel/sched/topology.c | 99 ++++++++++++------------
kernel/trace/trace.c | 10 ++-
net/ax25/af_ax25.c | 7 ++
net/core/net-sysfs.c | 2 +-
net/sctp/diag.c | 9 +--
tools/testing/selftests/memfd/memfd_test.c | 1 +
31 files changed, 215 insertions(+), 124 deletions(-)
From: Jiasheng Jiang <[email protected]>
[ Upstream commit 2169b79258c8be803d2595d6456b1e77129fe154 ]
As the potential failure of the clk_enable(),
it should be better to check it and return error
if fails.
Fixes: b7370112f519 ("lpc32xx: Added ethernet driver")
Signed-off-by: Jiasheng Jiang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/nxp/lpc_eth.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
index 415ac33341c5..27c22f0e9d25 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -1512,6 +1512,7 @@ static int lpc_eth_drv_resume(struct platform_device *pdev)
{
struct net_device *ndev = platform_get_drvdata(pdev);
struct netdata_local *pldat;
+ int ret;
if (device_may_wakeup(&pdev->dev))
disable_irq_wake(ndev->irq);
@@ -1521,7 +1522,9 @@ static int lpc_eth_drv_resume(struct platform_device *pdev)
pldat = netdev_priv(ndev);
/* Enable interface clock */
- clk_enable(pldat->clk);
+ ret = clk_enable(pldat->clk);
+ if (ret)
+ return ret;
/* Reset and initialize */
__lpc_eth_reset(pldat);
--
2.34.1
From: Randy Dunlap <[email protected]>
commit 68453767131a5deec1e8f9ac92a9042f929e585d upstream.
When CONFIG_GENERIC_CPU_VULNERABILITIES is not set, references
to spectre_v2_update_state() cause a build error, so provide an
empty stub for that function when the Kconfig option is not set.
Fixes this build error:
arm-linux-gnueabi-ld: arch/arm/mm/proc-v7-bugs.o: in function `cpu_v7_bugs_init':
proc-v7-bugs.c:(.text+0x52): undefined reference to `spectre_v2_update_state'
arm-linux-gnueabi-ld: proc-v7-bugs.c:(.text+0x82): undefined reference to `spectre_v2_update_state'
Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround")
Signed-off-by: Randy Dunlap <[email protected]>
Reported-by: kernel test robot <[email protected]>
Cc: Russell King <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: [email protected]
Cc: [email protected]
Acked-by: Russell King (Oracle) <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/include/asm/spectre.h | 6 ++++++
1 file changed, 6 insertions(+)
--- a/arch/arm/include/asm/spectre.h
+++ b/arch/arm/include/asm/spectre.h
@@ -25,7 +25,13 @@ enum {
SPECTRE_V2_METHOD_LOOP8 = BIT(__SPECTRE_V2_METHOD_LOOP8),
};
+#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
void spectre_v2_update_state(unsigned int state, unsigned int methods);
+#else
+static inline void spectre_v2_update_state(unsigned int state,
+ unsigned int methods)
+{}
+#endif
int spectre_bhb_update_vectors(unsigned int method);
From: Mike Kravetz <[email protected]>
[ Upstream commit fda153c89af344d21df281009a9d046cf587ea0f ]
Running the memfd script ./run_hugetlbfs_test.sh will often end in error
as follows:
memfd-hugetlb: CREATE
memfd-hugetlb: BASIC
memfd-hugetlb: SEAL-WRITE
memfd-hugetlb: SEAL-FUTURE-WRITE
memfd-hugetlb: SEAL-SHRINK
fallocate(ALLOC) failed: No space left on device
./run_hugetlbfs_test.sh: line 60: 166855 Aborted (core dumped) ./memfd_test hugetlbfs
opening: ./mnt/memfd
fuse: DONE
If no hugetlb pages have been preallocated, run_hugetlbfs_test.sh will
allocate 'just enough' pages to run the test. In the SEAL-FUTURE-WRITE
test the mfd_fail_write routine maps the file, but does not unmap. As a
result, two hugetlb pages remain reserved for the mapping. When the
fallocate call in the SEAL-SHRINK test attempts allocate all hugetlb
pages, it is short by the two reserved pages.
Fix by making sure to unmap in mfd_fail_write.
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Mike Kravetz <[email protected]>
Cc: Joel Fernandes <[email protected]>
Cc: Shuah Khan <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
tools/testing/selftests/memfd/memfd_test.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/memfd/memfd_test.c b/tools/testing/selftests/memfd/memfd_test.c
index 10baa1652fc2..a4e520b94e43 100644
--- a/tools/testing/selftests/memfd/memfd_test.c
+++ b/tools/testing/selftests/memfd/memfd_test.c
@@ -386,6 +386,7 @@ static void mfd_fail_write(int fd)
printf("mmap()+mprotect() didn't fail as expected\n");
abort();
}
+ munmap(p, mfd_def_size);
}
/* verify PUNCH_HOLE fails */
--
2.34.1
On Mon, Mar 14, 2022 at 08:02:21PM +0530, Naresh Kamboju wrote:
> > > > or in the git tree and branch at:
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> > > > and the diffstat can be found below.
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > > >
> > > > -------------
> > > > Pseudo-Shortlog of commits:
> > >
> > > ...
> > >
> > > > James Morse <[email protected]>
> > > > KVM: arm64: Reset PMC_EL0 to avoid a panic() on systems with no PMU
> > >
> > >
> > > The above is causing the following build error for ARM64 ...
> > >
> > > arch/arm64/kvm/sys_regs.c: In function ‘reset_pmcr’:
> > > arch/arm64/kvm/sys_regs.c:624:3: error: implicit declaration of function ‘vcpu_sys_reg’ [-Werror=implicit-function-declaration]
> > > vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
> > > ^~~~~~~~~~~~
> > > arch/arm64/kvm/sys_regs.c:624:32: error: lvalue required as left operand of assignment
> > > vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
> > >
> >
> > Is this also broken in Linus's tree?
>
> nope.
> It is also only on 4.19.
Thanks. I've pushed out -rc2 releases with this commit dropped.
greg k-h
From: Tom Rix <[email protected]>
[ Upstream commit d9dc0c84ad2d4cc911ba252c973d1bf18d5eb9cf ]
Clang static analysis reports this issue
qed_sriov.c:4727:19: warning: Assigned value is
garbage or undefined
ivi->max_tx_rate = tx_rate ? tx_rate : link.speed;
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
link is only sometimes set by the call to qed_iov_get_link()
qed_iov_get_link fails without setting link or returning
status. So change the decl to return status.
Fixes: 73390ac9d82b ("qed*: support ndo_get_vf_config")
Signed-off-by: Tom Rix <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index 886c7aae662f..285231bc318b 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -3800,11 +3800,11 @@ bool qed_iov_mark_vf_flr(struct qed_hwfn *p_hwfn, u32 *p_disabled_vfs)
return found;
}
-static void qed_iov_get_link(struct qed_hwfn *p_hwfn,
- u16 vfid,
- struct qed_mcp_link_params *p_params,
- struct qed_mcp_link_state *p_link,
- struct qed_mcp_link_capabilities *p_caps)
+static int qed_iov_get_link(struct qed_hwfn *p_hwfn,
+ u16 vfid,
+ struct qed_mcp_link_params *p_params,
+ struct qed_mcp_link_state *p_link,
+ struct qed_mcp_link_capabilities *p_caps)
{
struct qed_vf_info *p_vf = qed_iov_get_vf_info(p_hwfn,
vfid,
@@ -3812,7 +3812,7 @@ static void qed_iov_get_link(struct qed_hwfn *p_hwfn,
struct qed_bulletin_content *p_bulletin;
if (!p_vf)
- return;
+ return -EINVAL;
p_bulletin = p_vf->bulletin.p_virt;
@@ -3822,6 +3822,7 @@ static void qed_iov_get_link(struct qed_hwfn *p_hwfn,
__qed_vf_get_link_state(p_hwfn, p_link, p_bulletin);
if (p_caps)
__qed_vf_get_link_caps(p_hwfn, p_caps, p_bulletin);
+ return 0;
}
static int
@@ -4676,6 +4677,7 @@ static int qed_get_vf_config(struct qed_dev *cdev,
struct qed_public_vf_info *vf_info;
struct qed_mcp_link_state link;
u32 tx_rate;
+ int ret;
/* Sanitize request */
if (IS_VF(cdev))
@@ -4689,7 +4691,9 @@ static int qed_get_vf_config(struct qed_dev *cdev,
vf_info = qed_iov_get_public_vf_info(hwfn, vf_id, true);
- qed_iov_get_link(hwfn, vf_id, NULL, &link, NULL);
+ ret = qed_iov_get_link(hwfn, vf_id, NULL, &link, NULL);
+ if (ret)
+ return ret;
/* Fill information about VF */
ivi->vf = vf_id;
--
2.34.1
From: Miaoqian Lin <[email protected]>
[ Upstream commit 2ac5b58e645c66932438bb021cb5b52097ce70b0 ]
The of_find_compatible_node() function returns a node pointer with
refcount incremented, We should use of_node_put() on it when done
Add the missing of_node_put() to release the refcount.
Fixes: 7349a74ea75c ("net: ethernet: gianfar_ethtool: get phc index through drvdata")
Signed-off-by: Miaoqian Lin <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Reviewed-by: Claudiu Manoil <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/freescale/gianfar_ethtool.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c
index 395a5266ea30..0cddaaaf48aa 100644
--- a/drivers/net/ethernet/freescale/gianfar_ethtool.c
+++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c
@@ -1528,6 +1528,7 @@ static int gfar_get_ts_info(struct net_device *dev,
ptp_node = of_find_compatible_node(NULL, NULL, "fsl,etsec-ptp");
if (ptp_node) {
ptp_dev = of_find_device_by_node(ptp_node);
+ of_node_put(ptp_node);
if (ptp_dev)
ptp = platform_get_drvdata(ptp_dev);
}
--
2.34.1
On Mon, Mar 14, 2022 at 02:14:41PM +0000, Jon Hunter wrote:
>
> On 14/03/2022 14:05, Greg Kroah-Hartman wrote:
> > On Mon, Mar 14, 2022 at 01:58:12PM +0000, Jon Hunter wrote:
> > > Hi Greg,
> > >
> > > On 14/03/2022 11:34, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 4.19.235 release.
> > > > There are 30 patches in this series, all will be posted as a response
> > > > to this one. If anyone has any issues with these being applied, please
> > > > let me know.
> > > >
> > > > Responses should be made by Wed, 16 Mar 2022 11:27:22 +0000.
> > > > Anything received after that time might be too late.
> > > >
> > > > The whole patch series can be found in one patch at:
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kernel.org%2Fpub%2Flinux%2Fkernel%2Fv4.x%2Fstable-review%2Fpatch-4.19.235-rc1.gz&data=04%7C01%7Cjonathanh%40nvidia.com%7C31eb601c0fb5484081d008da05c3aaad%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637828635201758957%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qkVZnVBxsP8BHFANdvt6NDk8btMPekZoMolKI%2FHK1Zw%3D&reserved=0
> > > > or in the git tree and branch at:
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> > > > and the diffstat can be found below.
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > > >
> > > > -------------
> > > > Pseudo-Shortlog of commits:
> > >
> > > ...
> > >
> > > > James Morse <[email protected]>
> > > > KVM: arm64: Reset PMC_EL0 to avoid a panic() on systems with no PMU
> > >
> > >
> > > The above is causing the following build error for ARM64 ...
> > >
> > > arch/arm64/kvm/sys_regs.c: In function ‘reset_pmcr’:
> > > arch/arm64/kvm/sys_regs.c:624:3: error: implicit declaration of function ‘vcpu_sys_reg’ [-Werror=implicit-function-declaration]
> > > vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
> > > ^~~~~~~~~~~~
> > > arch/arm64/kvm/sys_regs.c:624:32: error: lvalue required as left operand of assignment
> > > vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
> > >
> >
> > Is this also broken in Linus's tree?
>
>
> No, Linus' tree is not broken. However, I don't see this change in Linus'
> tree (v5.17-rc8).
Ah, this is a "fix something broken in stable-only" type patch :(
James, I'm dropping this from the 4.19, 4.9, and 4.14 trees right now as
it looks broken :(
thanks,
greg k-h
From: Eric Dumazet <[email protected]>
[ Upstream commit 633593a808980f82d251d0ca89730d8bb8b0220c ]
syzbot reported a kernel infoleak [1] of 4 bytes.
After analysis, it turned out r->idiag_expires is not initialized
if inet_sctp_diag_fill() calls inet_diag_msg_common_fill()
Make sure to clear idiag_timer/idiag_retrans/idiag_expires
and let inet_diag_msg_sctpasoc_fill() fill them again if needed.
[1]
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]
BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668
instrument_copy_to_user include/linux/instrumented.h:121 [inline]
copyout lib/iov_iter.c:154 [inline]
_copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668
copy_to_iter include/linux/uio.h:162 [inline]
simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519
__skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425
skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533
skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline]
netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977
sock_recvmsg_nosec net/socket.c:948 [inline]
sock_recvmsg net/socket.c:966 [inline]
__sys_recvfrom+0x795/0xa10 net/socket.c:2097
__do_sys_recvfrom net/socket.c:2115 [inline]
__se_sys_recvfrom net/socket.c:2111 [inline]
__x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x44/0xae
Uninit was created at:
slab_post_alloc_hook mm/slab.h:737 [inline]
slab_alloc_node mm/slub.c:3247 [inline]
__kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975
kmalloc_reserve net/core/skbuff.c:354 [inline]
__alloc_skb+0x545/0xf90 net/core/skbuff.c:426
alloc_skb include/linux/skbuff.h:1158 [inline]
netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248
__netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373
netlink_dump_start include/linux/netlink.h:254 [inline]
inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341
sock_diag_rcv_msg+0x24a/0x620
netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494
sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343
netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919
sock_sendmsg_nosec net/socket.c:705 [inline]
sock_sendmsg net/socket.c:725 [inline]
sock_write_iter+0x594/0x690 net/socket.c:1061
do_iter_readv_writev+0xa7f/0xc70
do_iter_write+0x52c/0x1500 fs/read_write.c:851
vfs_writev fs/read_write.c:924 [inline]
do_writev+0x645/0xe00 fs/read_write.c:967
__do_sys_writev fs/read_write.c:1040 [inline]
__se_sys_writev fs/read_write.c:1037 [inline]
__x64_sys_writev+0xe5/0x120 fs/read_write.c:1037
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x44/0xae
Bytes 68-71 of 2508 are uninitialized
Memory access of size 2508 starts at ffff888114f9b000
Data copied to user address 00007f7fe09ff2e0
CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file")
Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: syzbot <[email protected]>
Cc: Vlad Yasevich <[email protected]>
Cc: Neil Horman <[email protected]>
Cc: Marcelo Ricardo Leitner <[email protected]>
Reviewed-by: Xin Long <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/sctp/diag.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/net/sctp/diag.c b/net/sctp/diag.c
index 0a9db0a7f423..5f10984bf0f5 100644
--- a/net/sctp/diag.c
+++ b/net/sctp/diag.c
@@ -76,10 +76,6 @@ static void inet_diag_msg_sctpasoc_fill(struct inet_diag_msg *r,
r->idiag_timer = SCTP_EVENT_TIMEOUT_T3_RTX;
r->idiag_retrans = asoc->rtx_data_chunks;
r->idiag_expires = jiffies_to_msecs(t3_rtx->expires - jiffies);
- } else {
- r->idiag_timer = 0;
- r->idiag_retrans = 0;
- r->idiag_expires = 0;
}
}
@@ -159,13 +155,14 @@ static int inet_sctp_diag_fill(struct sock *sk, struct sctp_association *asoc,
r = nlmsg_data(nlh);
BUG_ON(!sk_fullsock(sk));
+ r->idiag_timer = 0;
+ r->idiag_retrans = 0;
+ r->idiag_expires = 0;
if (asoc) {
inet_diag_msg_sctpasoc_fill(r, sk, asoc);
} else {
inet_diag_msg_common_fill(r, sk);
r->idiag_state = sk->sk_state;
- r->idiag_timer = 0;
- r->idiag_retrans = 0;
}
if (inet_diag_msg_attrs_fill(sk, skb, r, ext, user_ns, net_admin))
--
2.34.1
From: Michael S. Tsirkin <[email protected]>
commit 838d6d3461db0fdbf33fc5f8a69c27b50b4a46da upstream.
virtio_finalize_features is only used internally within virtio.
No reason to export it.
Signed-off-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Cornelia Huck <[email protected]>
Acked-by: Jason Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/virtio/virtio.c | 3 +--
include/linux/virtio.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -165,7 +165,7 @@ void virtio_add_status(struct virtio_dev
}
EXPORT_SYMBOL_GPL(virtio_add_status);
-int virtio_finalize_features(struct virtio_device *dev)
+static int virtio_finalize_features(struct virtio_device *dev)
{
int ret = dev->config->finalize_features(dev);
unsigned status;
@@ -185,7 +185,6 @@ int virtio_finalize_features(struct virt
}
return 0;
}
-EXPORT_SYMBOL_GPL(virtio_finalize_features);
static int virtio_dev_probe(struct device *_d)
{
--- a/include/linux/virtio.h
+++ b/include/linux/virtio.h
@@ -151,7 +151,6 @@ void virtio_break_device(struct virtio_d
void virtio_config_changed(struct virtio_device *dev);
void virtio_config_disable(struct virtio_device *dev);
void virtio_config_enable(struct virtio_device *dev);
-int virtio_finalize_features(struct virtio_device *dev);
#ifdef CONFIG_PM_SLEEP
int virtio_device_freeze(struct virtio_device *dev);
int virtio_device_restore(struct virtio_device *dev);
From: Valentin Schneider <[email protected]>
commit b22a8f7b4bde4e4ab73b64908ffd5d90ecdcdbfd upstream.
John Paul reported a warning about bogus NUMA distance values spurred by
commit:
620a6dc40754 ("sched/topology: Make sched_init_numa() use a set for the deduplicating sort")
In this case, the afflicted machine comes up with a reported 256 possible
nodes, all of which are 0 distance away from one another. This was
previously silently ignored, but is now caught by the aforementioned
commit.
The culprit is ia64's node_possible_map which remains unchanged from its
initialization value of NODE_MASK_ALL. In John's case, the machine
doesn't have any SRAT nor SLIT table, but AIUI the possible map remains
untouched regardless of what ACPI tables end up being parsed. Thus,
!online && possible nodes remain with a bogus distance of 0 (distances \in
[0, 9] are "reserved and have no meaning" as per the ACPI spec).
Follow x86 / drivers/base/arch_numa's example and set the possible map to
the parsed map, which in this case seems to be the online map.
Link: http://lore.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 620a6dc40754 ("sched/topology: Make sched_init_numa() use a set for the deduplicating sort")
Signed-off-by: Valentin Schneider <[email protected]>
Reported-by: John Paul Adrian Glaubitz <[email protected]>
Tested-by: John Paul Adrian Glaubitz <[email protected]>
Tested-by: Sergei Trofimovich <[email protected]>
Cc: "Peter Zijlstra (Intel)" <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Vincent Guittot <[email protected]>
Cc: Dietmar Eggemann <[email protected]>
Cc: Anatoly Pugachev <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
[ dannf: minor context adjustment in arch/ia64/kernel/acpi.c ]
Signed-off-by: dann frazier <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/ia64/kernel/acpi.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -537,7 +537,8 @@ void __init acpi_numa_fixup(void)
if (srat_num_cpus == 0) {
node_set_online(0);
node_cpuid[0].phys_id = hard_smp_processor_id();
- return;
+ slit_distance(0, 0) = LOCAL_DISTANCE;
+ goto out;
}
/*
@@ -580,7 +581,7 @@ void __init acpi_numa_fixup(void)
for (j = 0; j < MAX_NUMNODES; j++)
node_distance(i, j) = i == j ? LOCAL_DISTANCE :
REMOTE_DISTANCE;
- return;
+ goto out;
}
memset(numa_slit, -1, sizeof(numa_slit));
@@ -605,6 +606,8 @@ void __init acpi_numa_fixup(void)
printk("\n");
}
#endif
+out:
+ node_possible_map = node_online_map;
}
#endif /* CONFIG_ACPI_NUMA */
On Mon, Mar 14, 2022 at 01:58:12PM +0000, Jon Hunter wrote:
> Hi Greg,
>
> On 14/03/2022 11:34, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.19.235 release.
> > There are 30 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 16 Mar 2022 11:27:22 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kernel.org%2Fpub%2Flinux%2Fkernel%2Fv4.x%2Fstable-review%2Fpatch-4.19.235-rc1.gz&data=04%7C01%7Cjonathanh%40nvidia.com%7C4c0c664e42044e5bd8a208da05af4c30%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637828547981871505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xF4hLHeQMZiCVtbZX2jXwWYGz30QY84EzlbqHLPUZSs%3D&reserved=0
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
> > -------------
> > Pseudo-Shortlog of commits:
>
> ...
>
> > James Morse <[email protected]>
> > KVM: arm64: Reset PMC_EL0 to avoid a panic() on systems with no PMU
>
>
> The above is causing the following build error for ARM64 ...
>
> arch/arm64/kvm/sys_regs.c: In function ‘reset_pmcr’:
> arch/arm64/kvm/sys_regs.c:624:3: error: implicit declaration of function ‘vcpu_sys_reg’ [-Werror=implicit-function-declaration]
> vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
> ^~~~~~~~~~~~
> arch/arm64/kvm/sys_regs.c:624:32: error: lvalue required as left operand of assignment
> vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
>
Is this also broken in Linus's tree?
thanks,
greg k-h
From: Marek Marczykowski-Górecki <[email protected]>
[ Upstream commit 0f4558ae91870692ce7f509c31c9d6ee721d8cdc ]
This reverts commit 1f2565780e9b7218cf92c7630130e82dcc0fe9c2.
The 'hotplug-status' node should not be removed as long as the vif
device remains configured. Otherwise the xen-netback would wait for
re-running the network script even if it was already called (in case of
the frontent re-connecting). But also, it _should_ be removed when the
vif device is destroyed (for example when unbinding the driver) -
otherwise hotplug script would not configure the device whenever it
re-appear.
Moving removal of the 'hotplug-status' node was a workaround for nothing
calling network script after xen-netback module is reloaded. But when
vif interface is re-created (on xen-netback unbind/bind for example),
the script should be called, regardless of who does that - currently
this case is not handled by the toolstack, and requires manual
script call. Keeping hotplug-status=connected to skip the call is wrong
and leads to not configured interface.
More discussion at
https://lore.kernel.org/xen-devel/[email protected]/T/#u
Signed-off-by: Marek Marczykowski-Górecki <[email protected]>
Reviewed-by: Paul Durrant <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/xen-netback/xenbus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 78c56149559c..6b678ab0a31f 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -499,6 +499,7 @@ static void backend_disconnect(struct backend_info *be)
unsigned int queue_index;
xen_unregister_watchers(vif);
+ xenbus_rm(XBT_NIL, be->dev->nodename, "hotplug-status");
#ifdef CONFIG_DEBUG_FS
xenvif_debugfs_delif(vif);
#endif /* CONFIG_DEBUG_FS */
--
2.34.1
From: Miaoqian Lin <[email protected]>
[ Upstream commit b19ab4b38b06aae12442b2de95ccf58b5dc53584 ]
This node pointer is returned by of_parse_phandle() with refcount
incremented in this function. Calling of_node_put() to avoid the
refcount leak. As the remove function do.
Fixes: 5cdaaa12866e ("net: emaclite: adding MDIO and phy lib support")
Signed-off-by: Miaoqian Lin <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index edb2215f9993..23a4f9061072 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -1173,7 +1173,7 @@ static int xemaclite_of_probe(struct platform_device *ofdev)
if (rc) {
dev_err(dev,
"Cannot register network device, aborting\n");
- goto error;
+ goto put_node;
}
dev_info(dev,
@@ -1181,6 +1181,8 @@ static int xemaclite_of_probe(struct platform_device *ofdev)
(unsigned int __force)ndev->mem_start, lp->base_addr, ndev->irq);
return 0;
+put_node:
+ of_node_put(lp->phy_node);
error:
free_netdev(ndev);
return rc;
--
2.34.1
From: Dietmar Eggemann <[email protected]>
commit 71e5f6644fb2f3304fcb310145ded234a37e7cc1 upstream.
Commit "sched/topology: Make sched_init_numa() use a set for the
deduplicating sort" allocates 'i + nr_levels (level)' instead of
'i + nr_levels + 1' sched_domain_topology_level.
This led to an Oops (on Arm64 juno with CONFIG_SCHED_DEBUG):
sched_init_domains
build_sched_domains()
__free_domain_allocs()
__sdt_free() {
...
for_each_sd_topology(tl)
...
sd = *per_cpu_ptr(sdd->sd, j); <--
...
}
Signed-off-by: Dietmar Eggemann <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Tested-by: Vincent Guittot <[email protected]>
Tested-by: Barry Song <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: dann frazier <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/sched/topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -1428,7 +1428,7 @@ void sched_init_numa(void)
/* Compute default topology size */
for (i = 0; sched_domain_topology[i].mask; i++);
- tl = kzalloc((i + nr_levels) *
+ tl = kzalloc((i + nr_levels + 1) *
sizeof(struct sched_domain_topology_level), GFP_KERNEL);
if (!tl)
return;
From: Mohammad Kabat <[email protected]>
[ Upstream commit ac77998b7ac3044f0509b097da9637184598980d ]
According to HW spec the field "size" should be 16 bits
in bufferx register.
Fixes: e281682bf294 ("net/mlx5_core: HW data structs/types definitions cleanup")
Signed-off-by: Mohammad Kabat <[email protected]>
Reviewed-by: Moshe Shemesh <[email protected]>
Signed-off-by: Saeed Mahameed <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
include/linux/mlx5/mlx5_ifc.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index 5f711b2983db..af040fcd2c5a 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -8287,8 +8287,8 @@ struct mlx5_ifc_bufferx_reg_bits {
u8 reserved_at_0[0x6];
u8 lossy[0x1];
u8 epsb[0x1];
- u8 reserved_at_8[0xc];
- u8 size[0xc];
+ u8 reserved_at_8[0x8];
+ u8 size[0x10];
u8 xoff_threshold[0x10];
u8 xon_threshold[0x10];
--
2.34.1
From: Josh Triplett <[email protected]>
commit b1489186cc8391e0c1e342f9fbc3eedf6b944c61 upstream.
The in-kernel ext4 resize code doesn't support filesystem with the
sparse_super2 feature. It fails with errors like this and doesn't finish
the resize:
EXT4-fs (loop0): resizing filesystem from 16640 to 7864320 blocks
EXT4-fs warning (device loop0): verify_reserved_gdb:760: reserved GDT 2 missing grp 1 (32770)
EXT4-fs warning (device loop0): ext4_resize_fs:2111: error (-22) occurred during file system resize
EXT4-fs (loop0): resized filesystem to 2097152
To reproduce:
mkfs.ext4 -b 4096 -I 256 -J size=32 -E resize=$((256*1024*1024)) -O sparse_super2 ext4.img 65M
truncate -s 30G ext4.img
mount ext4.img /mnt
python3 -c 'import fcntl, os, struct ; fd = os.open("/mnt", os.O_RDONLY | os.O_DIRECTORY) ; fcntl.ioctl(fd, 0x40086610, struct.pack("Q", 30 * 1024 * 1024 * 1024 // 4096), False) ; os.close(fd)'
dmesg | tail
e2fsck ext4.img
The userspace resize2fs tool has a check for this case: it checks if the
filesystem has sparse_super2 set and if the kernel provides
/sys/fs/ext4/features/sparse_super2. However, the former check requires
manually reading and parsing the filesystem superblock.
Detect this case in ext4_resize_begin and error out early with a clear
error message.
Signed-off-by: Josh Triplett <[email protected]>
Link: https://lore.kernel.org/r/74b8ae78405270211943cd7393e65586c5faeed1.1623093259.git.josh@joshtriplett.org
Signed-off-by: Theodore Ts'o <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ext4/resize.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/fs/ext4/resize.c
+++ b/fs/ext4/resize.c
@@ -74,6 +74,11 @@ int ext4_resize_begin(struct super_block
return -EPERM;
}
+ if (ext4_has_feature_sparse_super2(sb)) {
+ ext4_msg(sb, KERN_ERR, "Online resizing not supported with sparse_super2");
+ return -EOPNOTSUPP;
+ }
+
if (test_and_set_bit_lock(EXT4_FLAGS_RESIZING,
&EXT4_SB(sb)->s_ext4_flags))
ret = -EBUSY;
From: James Morse <[email protected]>
The logic in commit 2a5f1b67ec57 "KVM: arm64: Don't access PMCR_EL0 when no
PMU is available" relies on an empty reset handler being benign. This was
not the case in earlier kernel versions, so the stable backport of this
patch is causing problems.
KVMs behaviour in this area changed over time. In particular, prior to commit
03fdfb269009 ("KVM: arm64: Don't write junk to sysregs on reset"), an empty
reset handler will trigger a warning, as the guest registers have been
poisoned.
Prior to commit 20589c8cc47d ("arm/arm64: KVM: Don't panic on failure to
properly reset system registers"), this warning was a panic().
Instead of reverting the backport, make it write 0 to the sys_reg[] array.
This keeps the reset logic happy, and the dodgy value can't be seen by
the guest as it can't request the emulation.
The original bug was accessing the PMCR_EL0 register on CPUs that don't
implement that feature. There is no known silicon that does this, but
v4.9's ACPI support is unable to find the PMU, so triggers this code:
| Kernel panic - not syncing: Didn't reset vcpu_sys_reg(24)
| CPU: 1 PID: 3055 Comm: lkvm Not tainted 4.9.302-00032-g64e078a56789 #13476
| Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Jul 30 2018
| Call trace:
| [<ffff00000808b4b0>] dump_backtrace+0x0/0x1a0
| [<ffff00000808b664>] show_stack+0x14/0x20
| [<ffff0000088f0e18>] dump_stack+0x98/0xb8
| [<ffff0000088eef08>] panic+0x118/0x274
| [<ffff0000080b50e0>] access_actlr+0x0/0x20
| [<ffff0000080b2620>] kvm_reset_vcpu+0x5c/0xac
| [<ffff0000080ac688>] kvm_arch_vcpu_ioctl+0x3e4/0x490
| [<ffff0000080a382c>] kvm_vcpu_ioctl+0x5b8/0x720
| [<ffff000008201e44>] do_vfs_ioctl+0x2f4/0x884
| [<ffff00000820244c>] SyS_ioctl+0x78/0x9c
| [<ffff000008083a9c>] __sys_trace_return+0x0/0x4
Cc: <[email protected]> # < v5.3 with 2a5f1b67ec57 backported
Signed-off-by: James Morse <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/kvm/sys_regs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -620,8 +620,10 @@ static void reset_pmcr(struct kvm_vcpu *
u64 pmcr, val;
/* No PMU available, PMCR_EL0 may UNDEF... */
- if (!kvm_arm_support_pmu_v3())
+ if (!kvm_arm_support_pmu_v3()) {
+ vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
return;
+ }
pmcr = read_sysreg(pmcr_el0);
/*
From: Jia-Ju Bai <[email protected]>
[ Upstream commit e0058f0fa80f6e09c4d363779c241c45a3c56b94 ]
The function dma_alloc_coherent() in qed_vf_hw_prepare() can fail, so
its return value should be checked.
Fixes: 1408cc1fa48c ("qed: Introduce VFs")
Reported-by: TOTE Robot <[email protected]>
Signed-off-by: Jia-Ju Bai <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/qlogic/qed/qed_vf.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_vf.c b/drivers/net/ethernet/qlogic/qed/qed_vf.c
index 93a0fbf6a132..e12338abaf0a 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_vf.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_vf.c
@@ -539,6 +539,9 @@ int qed_vf_hw_prepare(struct qed_hwfn *p_hwfn)
p_iov->bulletin.size,
&p_iov->bulletin.phys,
GFP_KERNEL);
+ if (!p_iov->bulletin.p_virt)
+ goto free_pf2vf_reply;
+
DP_VERBOSE(p_hwfn, QED_MSG_IOV,
"VF's bulletin Board [%p virt 0x%llx phys 0x%08x bytes]\n",
p_iov->bulletin.p_virt,
@@ -578,6 +581,10 @@ int qed_vf_hw_prepare(struct qed_hwfn *p_hwfn)
return rc;
+free_pf2vf_reply:
+ dma_free_coherent(&p_hwfn->cdev->pdev->dev,
+ sizeof(union pfvf_tlvs),
+ p_iov->pf2vf_reply, p_iov->pf2vf_reply_phys);
free_vf2pf_request:
dma_free_coherent(&p_hwfn->cdev->pdev->dev,
sizeof(union vfpf_tlvs),
--
2.34.1
From: Marek Marczykowski-Górecki <[email protected]>
[ Upstream commit e8240addd0a3919e0fd7436416afe9aa6429c484 ]
This reverts commit 2afeec08ab5c86ae21952151f726bfe184f6b23d.
The reasoning in the commit was wrong - the code expected to setup the
watch even if 'hotplug-status' didn't exist. In fact, it relied on the
watch being fired the first time - to check if maybe 'hotplug-status' is
already set to 'connected'. Not registering a watch for non-existing
path (which is the case if hotplug script hasn't been executed yet),
made the backend not waiting for the hotplug script to execute. This in
turns, made the netfront think the interface is fully operational, while
in fact it was not (the vif interface on xen-netback side might not be
configured yet).
This was a workaround for 'hotplug-status' erroneously being removed.
But since that is reverted now, the workaround is not necessary either.
More discussion at
https://lore.kernel.org/xen-devel/[email protected]/T/#u
Signed-off-by: Marek Marczykowski-Górecki <[email protected]>
Reviewed-by: Paul Durrant <[email protected]>
Reviewed-by: Michael Brown <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/xen-netback/xenbus.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 6b678ab0a31f..6d7fb0a95645 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -1044,15 +1044,11 @@ static void connect(struct backend_info *be)
xenvif_carrier_on(be->vif);
unregister_hotplug_status_watch(be);
- if (xenbus_exists(XBT_NIL, dev->nodename, "hotplug-status")) {
- err = xenbus_watch_pathfmt(dev, &be->hotplug_status_watch,
- NULL, hotplug_status_changed,
- "%s/%s", dev->nodename,
- "hotplug-status");
- if (err)
- goto err;
+ err = xenbus_watch_pathfmt(dev, &be->hotplug_status_watch, NULL,
+ hotplug_status_changed,
+ "%s/%s", dev->nodename, "hotplug-status");
+ if (!err)
be->have_hotplug_status_watch = 1;
- }
netif_tx_wake_all_queues(be->vif->dev);
--
2.34.1
From: Sven Schnelle <[email protected]>
[ Upstream commit 7acf3a127bb7c65ff39099afd78960e77b2ca5de ]
Booting the kernel with 'trace_buf_size=1' give a warning at
boot during the ftrace selftests:
[ 0.892809] Running postponed tracer tests:
[ 0.892893] Testing tracer function:
[ 0.901899] Callback from call_rcu_tasks_trace() invoked.
[ 0.983829] Callback from call_rcu_tasks_rude() invoked.
[ 1.072003] .. bad ring buffer .. corrupted trace buffer ..
[ 1.091944] Callback from call_rcu_tasks() invoked.
[ 1.097695] PASSED
[ 1.097701] Testing dynamic ftrace: .. filter failed count=0 ..FAILED!
[ 1.353474] ------------[ cut here ]------------
[ 1.353478] WARNING: CPU: 0 PID: 1 at kernel/trace/trace.c:1951 run_tracer_selftest+0x13c/0x1b0
Therefore enforce a minimum of 4096 bytes to make the selftest pass.
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Sven Schnelle <[email protected]>
Signed-off-by: Steven Rostedt (Google) <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/trace/trace.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 19a6b088f1e7..063b434c89d2 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1118,10 +1118,12 @@ static int __init set_buf_size(char *str)
if (!str)
return 0;
buf_size = memparse(str, &str);
- /* nr_entries can not be zero */
- if (buf_size == 0)
- return 0;
- trace_buf_size = buf_size;
+ /*
+ * nr_entries can not be zero and the startup
+ * tests require some buffer space. Therefore
+ * ensure we have at least 4096 bytes of buffer.
+ */
+ trace_buf_size = max(4096UL, buf_size);
return 1;
}
__setup("trace_buf_size=", set_buf_size);
--
2.34.1
> > > or in the git tree and branch at:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> > >
> > > -------------
> > > Pseudo-Shortlog of commits:
> >
> > ...
> >
> > > James Morse <[email protected]>
> > > KVM: arm64: Reset PMC_EL0 to avoid a panic() on systems with no PMU
> >
> >
> > The above is causing the following build error for ARM64 ...
> >
> > arch/arm64/kvm/sys_regs.c: In function ‘reset_pmcr’:
> > arch/arm64/kvm/sys_regs.c:624:3: error: implicit declaration of function ‘vcpu_sys_reg’ [-Werror=implicit-function-declaration]
> > vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
> > ^~~~~~~~~~~~
> > arch/arm64/kvm/sys_regs.c:624:32: error: lvalue required as left operand of assignment
> > vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
> >
>
> Is this also broken in Linus's tree?
nope.
It is also only on 4.19.
--
Linaro LKFT
https://lkft.linaro.org
On Tue, Mar 15, 2022 at 12:14:08PM +0000, James Morse wrote:
> Hi Greg,
>
> On 3/14/22 2:57 PM, Greg Kroah-Hartman wrote:
> > On Mon, Mar 14, 2022 at 02:14:41PM +0000, Jon Hunter wrote:
> > > On 14/03/2022 14:05, Greg Kroah-Hartman wrote:
> > > > On Mon, Mar 14, 2022 at 01:58:12PM +0000, Jon Hunter wrote:
> > > > > On 14/03/2022 11:34, Greg Kroah-Hartman wrote:
> > > > > > This is the start of the stable review cycle for the 4.19.235 release.
> > > > > > There are 30 patches in this series, all will be posted as a response
> > > > > > to this one. If anyone has any issues with these being applied, please
> > > > > > let me know.
> > > > > >
> > > > > > Responses should be made by Wed, 16 Mar 2022 11:27:22 +0000.
> > > > > > Anything received after that time might be too late.
>
>
> > > > > > James Morse <[email protected]>
> > > > > > KVM: arm64: Reset PMC_EL0 to avoid a panic() on systems with no PMU
> > > > >
> > > > >
> > > > > The above is causing the following build error for ARM64 ...
> > > > >
> > > > > arch/arm64/kvm/sys_regs.c: In function ‘reset_pmcr’:
> > > > > arch/arm64/kvm/sys_regs.c:624:3: error: implicit declaration of function ‘vcpu_sys_reg’ [-Werror=implicit-function-declaration]
> > > > > vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
> > > > > ^~~~~~~~~~~~
> > > > > arch/arm64/kvm/sys_regs.c:624:32: error: lvalue required as left operand of assignment
> > > > > vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
> > > > >
> > > >
> > > > Is this also broken in Linus's tree?
> > >
> > >
> > > No, Linus' tree is not broken. However, I don't see this change in Linus'
> > > tree (v5.17-rc8).
> >
> > Ah, this is a "fix something broken in stable-only" type patch :(
>
> > James, I'm dropping this from the 4.19, 4.9, and 4.14 trees right now as
> > it looks broken :(
>
> What would you prefer I do here:
> 1 post a revert for the original problematic backport.
> 2 post versions of this to fix each of the above 3 stable kernels. (instead of putting conditions in the stable tag).
I don't see what I did wrong with the "conditions" in the existing
commit you sent. How did I get it wrong?
Best case, send a patch series for each kernel tree. That way I "know"
I got the right thing here.
thanks,
greg k-h
Hi Greg,
On 3/14/22 2:57 PM, Greg Kroah-Hartman wrote:
> On Mon, Mar 14, 2022 at 02:14:41PM +0000, Jon Hunter wrote:
>> On 14/03/2022 14:05, Greg Kroah-Hartman wrote:
>>> On Mon, Mar 14, 2022 at 01:58:12PM +0000, Jon Hunter wrote:
>>>> On 14/03/2022 11:34, Greg Kroah-Hartman wrote:
>>>>> This is the start of the stable review cycle for the 4.19.235 release.
>>>>> There are 30 patches in this series, all will be posted as a response
>>>>> to this one. If anyone has any issues with these being applied, please
>>>>> let me know.
>>>>>
>>>>> Responses should be made by Wed, 16 Mar 2022 11:27:22 +0000.
>>>>> Anything received after that time might be too late.
>>>>> James Morse <[email protected]>
>>>>> KVM: arm64: Reset PMC_EL0 to avoid a panic() on systems with no PMU
>>>>
>>>>
>>>> The above is causing the following build error for ARM64 ...
>>>>
>>>> arch/arm64/kvm/sys_regs.c: In function ‘reset_pmcr’:
>>>> arch/arm64/kvm/sys_regs.c:624:3: error: implicit declaration of function ‘vcpu_sys_reg’ [-Werror=implicit-function-declaration]
>>>> vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
>>>> ^~~~~~~~~~~~
>>>> arch/arm64/kvm/sys_regs.c:624:32: error: lvalue required as left operand of assignment
>>>> vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
>>>>
>>>
>>> Is this also broken in Linus's tree?
>>
>>
>> No, Linus' tree is not broken. However, I don't see this change in Linus'
>> tree (v5.17-rc8).
>
> Ah, this is a "fix something broken in stable-only" type patch :(
> James, I'm dropping this from the 4.19, 4.9, and 4.14 trees right now as
> it looks broken :(
What would you prefer I do here:
1 post a revert for the original problematic backport.
2 post versions of this to fix each of the above 3 stable kernels. (instead of putting conditions in the stable tag).
Thanks,
James
From: Pavel Skripkin <[email protected]>
[ Upstream commit f80cfe2f26581f188429c12bd937eb905ad3ac7b ]
Syzbot reported UAF in port100_send_complete(). The root case is in
missing usb_kill_urb() calls on error handling path of ->probe function.
port100_send_complete() accesses devm allocated memory which will be
freed on probe failure. We should kill this urbs before returning an
error from probe function to prevent reported use-after-free
Fail log:
BUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
Read of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26
...
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255
__kasan_report mm/kasan/report.c:442 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
__usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670
...
Allocated by task 1255:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:45 [inline]
set_alloc_info mm/kasan/common.c:436 [inline]
____kasan_kmalloc mm/kasan/common.c:515 [inline]
____kasan_kmalloc mm/kasan/common.c:474 [inline]
__kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524
alloc_dr drivers/base/devres.c:116 [inline]
devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823
devm_kzalloc include/linux/device.h:209 [inline]
port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502
Freed by task 1255:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track+0x21/0x30 mm/kasan/common.c:45
kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
____kasan_slab_free mm/kasan/common.c:366 [inline]
____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328
kasan_slab_free include/linux/kasan.h:236 [inline]
__cache_free mm/slab.c:3437 [inline]
kfree+0xf8/0x2b0 mm/slab.c:3794
release_nodes+0x112/0x1a0 drivers/base/devres.c:501
devres_release_all+0x114/0x190 drivers/base/devres.c:530
really_probe+0x626/0xcc0 drivers/base/dd.c:670
Reported-and-tested-by: [email protected]
Fixes: 0347a6ab300a ("NFC: port100: Commands mechanism implementation")
Signed-off-by: Pavel Skripkin <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/nfc/port100.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/nfc/port100.c b/drivers/nfc/port100.c
index 0f37acec98ab..bc680b8be133 100644
--- a/drivers/nfc/port100.c
+++ b/drivers/nfc/port100.c
@@ -1618,7 +1618,9 @@ static int port100_probe(struct usb_interface *interface,
nfc_digital_free_device(dev->nfc_digital_dev);
error:
+ usb_kill_urb(dev->in_urb);
usb_free_urb(dev->in_urb);
+ usb_kill_urb(dev->out_urb);
usb_free_urb(dev->out_urb);
usb_put_dev(dev->udev);
--
2.34.1
From: Jiasheng Jiang <[email protected]>
[ Upstream commit 6babfc6e6fab068018c36e8f6605184b8c0b349d ]
As the potential failure of the clk_enable(),
it should be better to check it and return error
if fails.
Fixes: 8a2c9a5ab4b9 ("net: ethernet: ti: cpts: rework initialization/deinitialization")
Signed-off-by: Jiasheng Jiang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/ti/cpts.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
index 10b301e79086..01cc92f6a1f8 100644
--- a/drivers/net/ethernet/ti/cpts.c
+++ b/drivers/net/ethernet/ti/cpts.c
@@ -445,7 +445,9 @@ int cpts_register(struct cpts *cpts)
for (i = 0; i < CPTS_MAX_EVENTS; i++)
list_add(&cpts->pool_data[i].list, &cpts->pool);
- clk_enable(cpts->refclk);
+ err = clk_enable(cpts->refclk);
+ if (err)
+ return err;
cpts_write32(cpts, CPTS_EN, control);
cpts_write32(cpts, TS_PEND_EN, int_enable);
--
2.34.1
Hi Greg,
On 14/03/2022 11:34, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.235 release.
> There are 30 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 16 Mar 2022 11:27:22 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kernel.org%2Fpub%2Flinux%2Fkernel%2Fv4.x%2Fstable-review%2Fpatch-4.19.235-rc1.gz&data=04%7C01%7Cjonathanh%40nvidia.com%7C4c0c664e42044e5bd8a208da05af4c30%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637828547981871505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xF4hLHeQMZiCVtbZX2jXwWYGz30QY84EzlbqHLPUZSs%3D&reserved=0
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
> Pseudo-Shortlog of commits:
...
> James Morse <[email protected]>
> KVM: arm64: Reset PMC_EL0 to avoid a panic() on systems with no PMU
The above is causing the following build error for ARM64 ...
arch/arm64/kvm/sys_regs.c: In function ‘reset_pmcr’:
arch/arm64/kvm/sys_regs.c:624:3: error: implicit declaration of function ‘vcpu_sys_reg’ [-Werror=implicit-function-declaration]
vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
^~~~~~~~~~~~
arch/arm64/kvm/sys_regs.c:624:32: error: lvalue required as left operand of assignment
vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
Cheers
Jon
--
nvpublic
On 14/03/2022 14:05, Greg Kroah-Hartman wrote:
> On Mon, Mar 14, 2022 at 01:58:12PM +0000, Jon Hunter wrote:
>> Hi Greg,
>>
>> On 14/03/2022 11:34, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 4.19.235 release.
>>> There are 30 patches in this series, all will be posted as a response
>>> to this one. If anyone has any issues with these being applied, please
>>> let me know.
>>>
>>> Responses should be made by Wed, 16 Mar 2022 11:27:22 +0000.
>>> Anything received after that time might be too late.
>>>
>>> The whole patch series can be found in one patch at:
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kernel.org%2Fpub%2Flinux%2Fkernel%2Fv4.x%2Fstable-review%2Fpatch-4.19.235-rc1.gz&data=04%7C01%7Cjonathanh%40nvidia.com%7C31eb601c0fb5484081d008da05c3aaad%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637828635201758957%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qkVZnVBxsP8BHFANdvt6NDk8btMPekZoMolKI%2FHK1Zw%3D&reserved=0
>>> or in the git tree and branch at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
>>> and the diffstat can be found below.
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>>> -------------
>>> Pseudo-Shortlog of commits:
>>
>> ...
>>
>>> James Morse <[email protected]>
>>> KVM: arm64: Reset PMC_EL0 to avoid a panic() on systems with no PMU
>>
>>
>> The above is causing the following build error for ARM64 ...
>>
>> arch/arm64/kvm/sys_regs.c: In function ‘reset_pmcr’:
>> arch/arm64/kvm/sys_regs.c:624:3: error: implicit declaration of function ‘vcpu_sys_reg’ [-Werror=implicit-function-declaration]
>> vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
>> ^~~~~~~~~~~~
>> arch/arm64/kvm/sys_regs.c:624:32: error: lvalue required as left operand of assignment
>> vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
>>
>
> Is this also broken in Linus's tree?
No, Linus' tree is not broken. However, I don't see this change in
Linus' tree (v5.17-rc8).
Jon
--
nvpublic
From: Clément Léger <[email protected]>
[ Upstream commit 37c9d66c95564c85a001d8a035354f0220a1e1c3 ]
MISR1 was cleared twice but the original author intention was probably
to clear MISR1 & MISR2 to completely disable interrupts. Fix it to
clear MISR2.
Fixes: 87461f7a58ab ("net: phy: DP83822 initial driver submission")
Signed-off-by: Clément Léger <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/phy/dp83822.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/dp83822.c b/drivers/net/phy/dp83822.c
index 6e8a2a4f3a6e..9e2ed98f7df2 100644
--- a/drivers/net/phy/dp83822.c
+++ b/drivers/net/phy/dp83822.c
@@ -244,7 +244,7 @@ static int dp83822_config_intr(struct phy_device *phydev)
if (err < 0)
return err;
- err = phy_write(phydev, MII_DP83822_MISR1, 0);
+ err = phy_write(phydev, MII_DP83822_MISR2, 0);
if (err < 0)
return err;
--
2.34.1