- Nov 20, 2023
-
-
Filipe Manana authored
[ Upstream commit dec96fc2 ] In the tree search v2 ioctl we use the type size_t, which is an unsigned long, to track the buffer size in the local variable 'buf_size'. An unsigned long is 32 bits wide on a 32 bits architecture. The buffer size defined in struct btrfs_ioctl_search_args_v2 is a u64, so when we later try to copy the local variable 'buf_size' to the argument struct, when the search returns -EOVERFLOW, we copy only 32 bits which will be a problem on big endian systems. Fix this by using a u64 type for the buffer sizes, not only at btrfs_ioctl_tree_search_v2(), but also everywhere down the call chain so that we can use the u64 at btrfs_ioctl_tree_search_v2(). Fixes: cc68a8a5 ("btrfs: new ioctl TREE_SEARCH_V2") Reported-by:
Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/linux-btrfs/ce6f4bd6-9453-4ffe-ba00-cee35495e10f@moroto.mountain/ Signed-off-by:
Filipe Manana <fdmanana@suse.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Dominique Martinet authored
commit 421b605e upstream. This reverts commit 84ee19bf. The commit above made quirks with an OEMID fail to be applied, as they were checking card->cid.oemid for the full 16 bits defined in MMC_FIXUP macros but the field would only contain the bottom 8 bits. eMMC v5.1A might have bogus values in OEMID's higher bits so another fix will be made, but it has been decided to revert this until that is ready. Fixes: 84ee19bf ("mmc: core: Capture correct oemid-bits for eMMC cards") Link: https://lkml.kernel.org/r/ZToJsSLHr8RnuTHz@codewreck.org Link: https://lkml.kernel.org/r/CAPDyKFqkKibcXnwjnhc3+W1iJBHLeqQ9BpcZrSwhW2u9K2oUtg@mail.gmail.com Signed-off-by:
Dominique Martinet <dominique.martinet@atmark-techno.com> Cc: stable@vger.kernel.org Cc: Alex Fetters <Alex.Fetters@garmin.com> Reviewed-by:
Avri Altman <avri.altman@wdc.com> Link: https://lore.kernel.org/r/20231103004220.1666641-1-asmadeus@codewreck.org Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Yazen Ghannam authored
commit 2a565258 upstream. Three PCI IDs for DF Function 4 were defined but not used. Add them to the "link" list. Fixes: f8faf349 ("x86/amd_nb: Add AMD PCI IDs for SMN communication") Fixes: 23a5b8bb ("x86/amd_nb: Add PCI ID for family 19h model 78h") Signed-off-by:
Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230803150430.3542854-1-yazen.ghannam@amd.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jens Axboe authored
commit f8f9ab2d upstream. io_uring does non-blocking connection attempts, which can yield some unexpected results if a connect request is re-attempted by an an application. This is equivalent to the following sync syscall sequence: sock = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, IPPROTO_TCP); connect(sock, &addr, sizeof(addr); ret == -1 and errno == EINPROGRESS expected here. Now poll for POLLOUT on sock, and when that returns, we expect the socket to be connected. But if we follow that procedure with: connect(sock, &addr, sizeof(addr)); you'd expect ret == -1 and errno == EISCONN here, but you actually get ret == 0. If we attempt the connection one more time, then we get EISCON as expected. io_uring used to do this, but turns out that bluetooth fails with EBADFD if you attempt to re-connect. Also looks like EISCONN _could_ occur with this sequence. Retain the ->in_progress logic, but work-around a potential EISCONN or EBADFD error and only in those cases look at the sock_error(). This should work in general and avoid the odd sequence of a repeated connect request returning success when the socket is already connected. This is all a side effect of the socket state being in a CONNECTING state when we get EINPROGRESS, and only a re-connect or other related operation will turn that into CONNECTED. Cc: stable@vger.kernel.org Fixes: 3fb1bd68 ("io_uring/net: handle -EINPROGRESS correct for IORING_OP_CONNECT") Link: https://github.com/axboe/liburing/issues/980 Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Yujie Liu authored
[ Upstream commit f032c53b ] The order of descriptions should be consistent with the argument list of the function, so "kretprobe" should be the second one. int __kprobe_event_gen_cmd_start(struct dynevent_cmd *cmd, bool kretprobe, const char *name, const char *loc, ...) Link: https://lore.kernel.org/all/20231031041305.3363712-1-yujie.liu@intel.com/ Fixes: 2a588dd1 ("tracing: Add kprobe event command generation functions") Suggested-by:
Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by:
Yujie Liu <yujie.liu@intel.com> Reviewed-by:
Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by:
Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Arnd Bergmann authored
[ Upstream commit a5035c81 ] wr_reg_wa() is not an appropriate name for a global function, and doesn't need to be global anyway, so mark it static and avoid the warning: drivers/video/fbdev/fsl-diu-fb.c:493:6: error: no previous prototype for 'wr_reg_wa' [-Werror=missing-prototypes] Fixes: 0d9dab39 ("powerpc/5121: fsl-diu-fb: fix issue with re-enabling DIU area descriptor") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Dan Carpenter authored
[ Upstream commit aba6ab57 ] I've re-written the error handling but the bug is that if init_imstt() fails we need to call iounmap(par->cmap_regs). Fixes: c75f5a55 ("fbdev: imsttfb: Fix use after free bug in imsttfb_probe") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Helge Deller authored
[ Upstream commit 518ecb6a ] Release ressources when init_imstt() returns failure. Signed-off-by:
Helge Deller <deller@gmx.de> Stable-dep-of: aba6ab57 ("fbdev: imsttfb: fix a resource leak in probe") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Amit Kumar Mahapatra authored
[ Upstream commit c2ded280 ] Zynq QSPI driver has been converted to use spi-mem framework so add spi-mem to driver kconfig dependencies. Fixes: 67dca5e5 ("spi: spi-mem: Add support for Zynq QSPI controller") Signed-off-by:
Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com> Signed-off-by:
Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Link: https://lore.kernel.org/r/1699037031-702858-1-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jerome Brunet authored
[ Upstream commit 4bdcbc31 ] The name currently used to get the clock includes the dapm prefix. It should use the name as provided to the widget, without the prefix. Fixes: 3caac759 ("ASoC: soc-dapm.c: fixup snd_soc_dapm_new_control_unlocked() error handling") Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20231106103712.703962-1-jbrunet@baylibre.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jerome Brunet authored
[ Upstream commit 15be353d ] The HDMI hotplug callback to the hdmi-codec is currently registered when jack is set. The hotplug not only serves to report the ASoC jack state but also to get the ELD. It should be registered when the component probes instead, so it does not depend on the card driver registering a jack for the HDMI to properly report the ELD. Fixes: 25ce4f2b ("ASoC: hdmi-codec: Get ELD in before reporting plugged event") Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20231106104013.704356-1-jbrunet@baylibre.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Eugen Hristev authored
[ Upstream commit 004fc58e ] Property 'playback-codecs' is referenced as 'speaker-codec' in the error message, and this can lead to confusion. Correct the error message such that the correct property name is referenced. Fixes: 0da16e37 ("ASoC: mediatek: mt8186: add machine driver with mt6366, rt1019 and rt5682s") Signed-off-by:
Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231031103139.77395-1-eugen.hristev@collabora.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Erik Kurzinger authored
[ Upstream commit 101c9f63 ] If DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT is invoked with the DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE flag set but no fence has yet been submitted for the given timeline point the call will fail immediately with EINVAL. This does not match the intended behavior where the call should wait until the fence has been submitted (or the timeout expires). The following small example program illustrates the issue. It should wait for 5 seconds and then print ETIME, but instead it terminates right away after printing EINVAL. #include <stdio.h> #include <fcntl.h> #include <time.h> #include <errno.h> #include <xf86drm.h> int main(void) { int fd = open("/dev/dri/card0", O_RDWR); uint32_t syncobj; drmSyncobjCreate(fd, 0, &syncobj); struct timespec ts; clock_gettime(CLOCK_MONOTONIC, &ts); uint64_t point = 1; if (drmSyncobjTimelineWait(fd, &syncobj, &point, 1, ts.tv_sec * 1000000000 + ts.tv_nsec + 5000000000, // 5s DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE, NULL)) { printf("drmSyncobjTimelineWait failed %d\n", errno); } } Fixes: 01d6c357 ("drm/syncobj: add support for timeline point wait v8") Signed-off-by:
Erik Kurzinger <ekurzinger@nvidia.com> Reviewed by: Simon Ser <contact@emersion.fd> Signed-off-by:
Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/1fac96f1-2f3f-f9f9-4eb0-340f27a8f6c0@nvidia.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Anup Patel authored
[ Upstream commit c4676f8d ] The riscv_of_processor_hartid() used by riscv_of_parent_hartid() fails for HARTs disabled in the DT. This results in the following warning thrown by the RISC-V INTC driver for the E-core on SiFive boards: [ 0.000000] riscv-intc: unable to find hart id for /cpus/cpu@0/interrupt-controller The riscv_of_parent_hartid() is only expected to read the hartid from the DT so we directly call of_get_cpu_hwid() instead of calling riscv_of_processor_hartid(). Fixes: ad635e72 ("riscv: cpu: Add 64bit hartid support on RV64") Signed-off-by:
Anup Patel <apatel@ventanamicro.com> Reviewed-by:
Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20231027154254.355853-2-apatel@ventanamicro.com Signed-off-by:
Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Florian Westphal authored
[ Upstream commit 80abbe8a ] The ipv6 redirect target was derived from the ipv4 one, i.e. its identical to a 'dnat' with the first (primary) address assigned to the network interface. The code has been moved around to make it usable from nf_tables too, but its still the same as it was back when this was added in 2012. IPv6, however, has different types of addresses, if the 'wrong' address comes first the redirection does not work. In Daniels case, the addresses are: inet6 ::ffff:192 ... inet6 2a01: ... ... so the function attempts to redirect to the mapped address. Add more checks before the address is deemed correct: 1. If the packets' daddr is scoped, search for a scoped address too 2. skip tentative addresses 3. skip mapped addresses Use the first address that appears to match our needs. Reported-by:
Daniel Huhardeaux <tech@tootai.net> Closes: https://lore.kernel.org/netfilter/71be06b8-6aa0-4cf9-9e0b-e2839b01b22f@tootai.net/ Fixes: 115e23ac ("netfilter: ip6tables: add REDIRECT target") Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jeremy Sowden authored
[ Upstream commit 6f56ad1b ] `nf_nat_redirect_ipv4` takes a `struct nf_nat_ipv4_multi_range_compat`, but converts it internally to a `struct nf_nat_range2`. Change the function to take the latter, factor out the code now shared with `nf_nat_redirect_ipv6`, move the conversion to the xt_REDIRECT module, and update the ipv4 range initialization in the nft_redir module. Replace a bare hex constant for 127.0.0.1 with a macro. Remove `WARN_ON`. `nf_nat_setup_info` calls `nf_ct_is_confirmed`: /* Can't setup nat info for confirmed ct. */ if (nf_ct_is_confirmed(ct)) return NF_ACCEPT; This means that `ct` cannot be null or the kernel will crash, and implies that `ctinfo` is `IP_CT_NEW` or `IP_CT_RELATED`. nft_redir has separate ipv4 and ipv6 call-backs which share much of their code, and an inet one switch containing a switch that calls one of the others based on the family of the packet. Merge the ipv4 and ipv6 ones into the inet one in order to get rid of the duplicate code. Const-qualify the `priv` pointer since we don't need to write through it. Assign `priv->flags` to the range instead of OR-ing it in. Set the `NF_NAT_RANGE_PROTO_SPECIFIED` flag once during init, rather than on every eval. Signed-off-by:
Jeremy Sowden <jeremy@azazel.net> Signed-off-by:
Florian Westphal <fw@strlen.de> Stable-dep-of: 80abbe8a ("netfilter: nat: fix ipv6 nat redirect with mapped and scoped addresses") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Maciej Żenczykowski authored
[ Upstream commit 7b308feb ] in6_pton() supports 'low-32-bit dot-decimal representation' (this is useful with DNS64/NAT64 networks for example): # echo +aaaa:bbbb:cccc:dddd:eeee:ffff:1.2.3.4 > /proc/self/net/xt_recent/DEFAULT # cat /proc/self/net/xt_recent/DEFAULT src=aaaa:bbbb:cccc:dddd:eeee:ffff:0102:0304 ttl: 0 last_seen: 9733848829 oldest_pkt: 1 9733848829 but the provided buffer is too short: # echo +aaaa:bbbb:cccc:dddd:eeee:ffff:255.255.255.255 > /proc/self/net/xt_recent/DEFAULT -bash: echo: write error: Invalid argument Fixes: 079aa88f ("netfilter: xt_recent: IPv6 support") Signed-off-by:
Maciej Żenczykowski <zenczykowski@gmail.com> Reviewed-by:
Simon Horman <horms@kernel.org> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Roman Bacik authored
[ Upstream commit ba15a143 ] Add the code to handle an invalid state when both bits S_RX_EVENT (indicating a transaction) and S_START_BUSY (indicating the end of transaction - transition of START_BUSY from 1 to 0) are set in the interrupt status register during a slave read. Signed-off-by:
Roman Bacik <roman.bacik@broadcom.com> Fixes: 1ca1b451 ("i2c: iproc: handle Master aborted error") Acked-by:
Ray Jui <ray.jui@broadcom.com> Signed-off-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Heiner Kallweit authored
[ Upstream commit 8999ce4c ] So far we ignore the setting of IFF_MULTICAST. Fix this and clear bit AcceptMulticast if IFF_MULTICAST isn't set. Note: Based on the implementations I've seen it doesn't seem to be 100% clear what a driver is supposed to do if IFF_ALLMULTI is set but IFF_MULTICAST is not. This patch is based on the understanding that IFF_MULTICAST has precedence. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/4a57ba02-d52d-4369-9f14-3565e6c1f7dc@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Filippo Storniolo authored
[ Upstream commit 3a5cc90a ] If the same remote peer, using the same port, tries to connect to a server on a listening port more than once, the server will reject the connection, causing a "connection reset by peer" error on the remote peer. This is due to the presence of a dangling socket from a previous connection in both the connected and bound socket lists. The inconsistency of the above lists only occurs when the remote peer disconnects and the server remains active. This bug does not occur when the server socket is closed: virtio_transport_release() will eventually schedule a call to virtio_transport_do_close() and the latter will remove the socket from the bound and connected socket lists and clear the sk_buff. However, virtio_transport_do_close() will only perform the above actions if it has been scheduled, and this will not happen if the server is processing the shutdown message from a remote peer. To fix this, introduce a call to vsock_remove_sock() when the server is handling a client disconnect. This is to remove the socket from the bound and connected socket lists without clearing the sk_buff. Fixes: 06a8fc78 ("VSOCK: Introduce virtio_vsock_common.ko") Reported-by:
Daan De Meyer <daan.j.demeyer@gmail.com> Tested-by:
Daan De Meyer <daan.j.demeyer@gmail.com> Co-developed-by:
Luigi Leonardi <luigi.leonardi@outlook.com> Signed-off-by:
Luigi Leonardi <luigi.leonardi@outlook.com> Signed-off-by:
Filippo Storniolo <f.storniolo95@gmail.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Bobby Eshleman authored
[ Upstream commit 71dc9ec9 ] This commit changes virtio/vsock to use sk_buff instead of virtio_vsock_pkt. Beyond better conforming to other net code, using sk_buff allows vsock to use sk_buff-dependent features in the future (such as sockmap) and improves throughput. This patch introduces the following performance changes: Tool: Uperf Env: Phys Host + L1 Guest Payload: 64k Threads: 16 Test Runs: 10 Type: SOCK_STREAM Before: commit b7bfaa76 ("Linux 6.2-rc3") Before ------ g2h: 16.77Gb/s h2g: 10.56Gb/s After ----- g2h: 21.04Gb/s h2g: 10.76Gb/s Signed-off-by:
Bobby Eshleman <bobby.eshleman@bytedance.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Stable-dep-of: 3a5cc90a ("vsock/virtio: remove socket from connected/bound list on shutdown") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Yu Kuai authored
[ Upstream commit 1b0a151c ] If one of the underlying disks of raid or dm is set to read-only, then each io will generate new log, which will cause message storm. This environment is indeed problematic, however we can't make sure our naive custormer won't do this, hence use pr_warn_ratelimited() to prevent message storm in this case. Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Fixes: 57e95e46 ("block: fix and cleanup bio_check_ro") Signed-off-by:
Ye Bin <yebin10@huawei.com> Link: https://lore.kernel.org/r/20231107111247.2157820-1-yukuai1@huaweicloud.com Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Li Lingfeng authored
[ Upstream commit 32746272 ] Commit 4af5f2e0 ("nbd: use blk_mq_alloc_disk and blk_cleanup_disk") cleans up disk by blk_cleanup_disk() and it won't set disk->private_data as NULL as before. UAF may be triggered in nbd_open() if someone tries to open nbd device right after nbd_put() since nbd has been free in nbd_dev_remove(). Fix this by implementing ->free_disk and free private data in it. Fixes: 4af5f2e0 ("nbd: use blk_mq_alloc_disk and blk_cleanup_disk") Signed-off-by:
Li Lingfeng <lilingfeng3@huawei.com> Reviewed-by:
Josef Bacik <josef@toxicpanda.com> Link: https://lore.kernel.org/r/20231107103435.2074904-1-lilingfeng@huaweicloud.com Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
George Shuklin authored
[ Upstream commit 9fc3bc76 ] Dell R650xs servers hangs on reboot if tg3 driver calls tg3_power_down. This happens only if network adapters (BCM5720 for R650xs) were initialized using SNP (e.g. by booting ipxe.efi). The actual problem is on Dell side, but this fix allows servers to come back alive after reboot. Signed-off-by:
George Shuklin <george.shuklin@gmail.com> Fixes: 2ca1c94c ("tg3: Disable tg3 device on system reboot to avoid triggering AER") Reviewed-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by:
Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231103115029.83273-1-george.shuklin@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Anuj Gupta authored
[ Upstream commit 1147dd05 ] Driver may return an error before submitting the command to the device. Ensure that such error is propagated up. Fixes: 456cba38 ("nvme: wire-up uring-cmd support for io-passthru on char-device.") Signed-off-by:
Anuj Gupta <anuj20.g@samsung.com> Signed-off-by:
Kanchan Joshi <joshi.k@samsung.com> Reviewed-by:
Niklas Cassel <niklas.cassel@wdc.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Keith Busch <kbusch@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
D. Wythe authored
[ Upstream commit aa96fbd6 ] Note that we always hold a reference to sock when attempting to submit close_work. Therefore, if we have successfully canceled close_work from pending, we MUST release that reference to avoid potential leaks. Fixes: 42bfba9e ("net/smc: immediate termination for SMCD link groups") Signed-off-by:
D. Wythe <alibuda@linux.alibaba.com> Reviewed-by:
Dust Li <dust.li@linux.alibaba.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
D. Wythe authored
[ Upstream commit c5bf605b ] This patch re-fix the issues mentioned by commit 22a825c5 ("net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler()"). Blocking sending message do solve the issues though, but it also prevents the peer to receive the final message. Besides, in logic, whether the sndbuf_desc is NULL or not have no impact on the processing of cdc message sending. Hence that, this patch allows the cdc message sending but to check the sndbuf_desc with care in smc_cdc_tx_handler(). Fixes: 22a825c5 ("net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler()") Signed-off-by:
D. Wythe <alibuda@linux.alibaba.com> Reviewed-by:
Dust Li <dust.li@linux.alibaba.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
D. Wythe authored
[ Upstream commit 5211c972 ] Considering scenario: smc_cdc_rx_handler __smc_release sock_set_flag smc_close_active() sock_set_flag __set_bit(DEAD) __set_bit(DONE) Dues to __set_bit is not atomic, the DEAD or DONE might be lost. if the DEAD flag lost, the state SMC_CLOSED will be never be reached in smc_close_passive_work: if (sock_flag(sk, SOCK_DEAD) && smc_close_sent_any_close(conn)) { sk->sk_state = SMC_CLOSED; } else { /* just shutdown, but not yet closed locally */ sk->sk_state = SMC_APPFINCLOSEWAIT; } Replace sock_set_flags or __set_bit to set_bit will fix this problem. Since set_bit is atomic. Fixes: b38d7324 ("smc: socket closing and linkgroup cleanup") Signed-off-by:
D. Wythe <alibuda@linux.alibaba.com> Reviewed-by:
Dust Li <dust.li@linux.alibaba.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Geetha sowjanya authored
[ Upstream commit 3423ca23 ] On interface down, the pending SQEs in the NIX get dropped or drained out during SMQ flush. But skb's pointed by these SQEs never get free or updated to the stack as respective CQE never get added. This patch fixes the issue by freeing all valid skb's in SQ SG list. Fixes: b1bc8457 ("octeontx2-pf: Cleanup all receive buffers in SG descriptor") Signed-off-by:
Geetha sowjanya <gakula@marvell.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Subbaraya Sundeep authored
[ Upstream commit ab6dddd2 ] Current implementation is such that the number of Send queues (SQs) are decided on the device probe which is equal to the number of online cpus. These SQs are allocated and deallocated in interface open and c lose calls respectively. This patch defines new APIs for initializing and deinitializing Send queues dynamically and allocates more number of transmit queues for QOS feature. Signed-off-by:
Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by:
Hariprasad Kelam <hkelam@marvell.com> Signed-off-by:
Sunil Kovvuri Goutham <sgoutham@marvell.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Reviewed-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Stable-dep-of: 3423ca23 ("octeontx2-pf: Free pending and dropped SQEs") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Hariprasad Kelam authored
[ Upstream commit 508c58f7 ] current implementation is such that tot_tx_queues contains both xdp queues and normal tx queues. which will be allocated in interface open calls and deallocated on interface down calls respectively. With addition of QOS, where send quees are allocated/deallacated upon user request Qos send queues won't be part of tot_tx_queues. So this patch renames tot_tx_queues to non_qos_queues. Signed-off-by:
Hariprasad Kelam <hkelam@marvell.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Reviewed-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Stable-dep-of: 3423ca23 ("octeontx2-pf: Free pending and dropped SQEs") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Hangbin Liu authored
[ Upstream commit 63e20191 ] In the PMTU test, when all previous tests are skipped and the new test passes, the exit code is set to 0. However, the current check mistakenly treats this as an assignment, causing the check to pass every time. Consequently, regardless of how many tests have failed, if the latest test passes, the PMTU test will report a pass. Fixes: 2a9d3716 ("selftests: pmtu.sh: improve the test result processing") Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Acked-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Furong Xu authored
[ Upstream commit db456d90 ] From XGMAC Core 3.20 and later, each Flexible PPS has individual PPSEN bit to select Fixed mode or Flexible mode. The PPSEN must be set, or it stays in Fixed PPS mode by default. XGMAC Core prior 3.20, only PPSEN0(bit 4) is writable. PPSEN{1,2,3} are read-only reserved, and they are already in Flexible mode by default, our new code always set PPSEN{1,2,3} do not make things worse ;-) Fixes: 95eaf3cd ("net: stmmac: dwxgmac: Add Flexible PPS support") Reviewed-by:
Serge Semin <fancer.lancer@gmail.com> Reviewed-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
Furong Xu <0x1207@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
NeilBrown authored
[ Upstream commit e8ae8ad4 ] The comment for idr_for_each_entry_ul() states after normal termination @entry is left with the value NULL This is not correct in the case where UINT_MAX has an entry in the idr. In that case @entry will be non-NULL after termination. No current code depends on the documentation being correct, but to save future code we should fix it. Also fix idr_for_each_entry_continue_ul(). While this is not documented as leaving @entry as NULL, the mellanox driver appears to depend on it doing so. So make that explicit in the documentation as well as in the code. Fixes: e33d2b74 ("idr: fix overflow case for idr_for_each_entry_ul()") Cc: Matthew Wilcox <willy@infradead.org> Cc: Chris Mi <chrism@mellanox.com> Cc: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Patrick Thompson authored
[ Upstream commit efa5f131 ] RTL8168H and RTL8107E ethernet adapters erroneously filter unicast eapol packets unless allmulti is enabled. These devices correspond to RTL_GIGA_MAC_VER_46 and VER_48. Add an exception for VER_46 and VER_48 in the same way that VER_35 has an exception. Fixes: 6e1d0b89 ("r8169:add support for RTL8168H and RTL8107E") Signed-off-by:
Patrick Thompson <ptf@google.com> Reviewed-by:
Jacob Keller <jacob.e.keller@intel.com> Reviewed-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/20231030205031.177855-1-ptf@google.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Kuniyuki Iwashima authored
[ Upstream commit 23be1e0e ] Initially, commit 4237c75c ("[MLSXFRM]: Auto-labeling of child sockets") introduced security_inet_conn_request() in some functions where reqsk is allocated. The hook is added just after the allocation, so reqsk's IPv6 remote address was not initialised then. However, SELinux/Smack started to read it in netlbl_req_setattr() after commit e1adea92 ("calipso: Allow request sockets to be relabelled by the lsm."). Commit 284904aa ("lsm: Relocate the IPv4 security_inet_conn_request() hooks") fixed that kind of issue only in TCPv4 because IPv6 labeling was not supported at that time. Finally, the same issue was introduced again in IPv6. Let's apply the same fix on DCCPv6 and TCPv6. Fixes: e1adea92 ("calipso: Allow request sockets to be relabelled by the lsm.") Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Acked-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Kuniyuki Iwashima authored
[ Upstream commit fa2df45a ] Initially, commit 4237c75c ("[MLSXFRM]: Auto-labeling of child sockets") introduced security_inet_conn_request() in some functions where reqsk is allocated. The hook is added just after the allocation, so reqsk's IPv4 remote address was not initialised then. However, SELinux/Smack started to read it in netlbl_req_setattr() after the cited commits. This bug was partially fixed by commit 284904aa ("lsm: Relocate the IPv4 security_inet_conn_request() hooks"). This patch fixes the last bug in DCCPv4. Fixes: 389fb800 ("netlabel: Label incoming TCP connections correctly in SELinux") Fixes: 07feee8f ("netlabel: Cleanup the Smack/NetLabel code to fix incoming TCP connections") Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Acked-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jian Shen authored
[ Upstream commit 8ffbd166 ] When ptr_ring_init() returns failure in page_pool_init(), free_percpu() is not called to free pool->recycle_stats, which may cause memory leak. Fixes: ad6fa1e1 ("page_pool: Add recycle stats") Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
Jijie Shao <shaojijie@huawei.com> Reviewed-by:
Yunsheng Lin <linyunsheng@huawei.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Link: https://lore.kernel.org/r/20231030091256.2915394-1-shaojijie@huawei.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Ratheesh Kannoth authored
[ Upstream commit 7aeeb2cb ] Error code strings are not getting printed properly due to holes. Print error code as well. Fixes: 51afe902 ("octeontx2-pf: NIX TX overwrites SQ_CTX_HW_S[SQ_INT]") Signed-off-by:
Ratheesh Kannoth <rkannoth@marvell.com> Reviewed-by:
Wojciech Drewek <wojciech.drewek@intel.com> Link: https://lore.kernel.org/r/20231027021953.1819959-2-rkannoth@marvell.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Ratheesh Kannoth authored
[ Upstream commit 96b9a68d ] Some of error codes were wrong. Fix the same. Fixes: 51afe902 ("octeontx2-pf: NIX TX overwrites SQ_CTX_HW_S[SQ_INT]") Signed-off-by:
Ratheesh Kannoth <rkannoth@marvell.com> Reviewed-by:
Wojciech Drewek <wojciech.drewek@intel.com> Link: https://lore.kernel.org/r/20231027021953.1819959-1-rkannoth@marvell.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-