May 2020 - Linux-stable-mirror

stable-rc/linux-5.4.y boot: 148 boots: 1 failed, 137 passed with 7 offline, 3 untried/unknown (v5.4.42)

by kernelci.org bot

****************************************** * WARNING: Boot tests are now deprecated * ****************************************** As kernelci.org is expanding its functional testing capabilities, the concept of boot testing is now deprecated. Boot results are scheduled to be dropped on *5th June 2020*. The full schedule for boot tests deprecation is available on this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238 The new equivalent is the *baseline* test suite which also runs sanity checks using dmesg and bootrr: https://github.com/kernelci/bootrr See the *baseline results for this kernel revision* on this page: https://kernelci.org/test/job/stable-rc/branch/linux-5.4.y/kernel/v5.4.42/p… ------------------------------------------------------------------------------- stable-rc/linux-5.4.y boot: 148 boots: 1 failed, 137 passed with 7 offline, 3 untried/unknown (v5.4.42) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.4.y/kernel/v5.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.4.y/kernel/v5.4.42/ Tree: stable-rc Branch: linux-5.4.y Git Describe: v5.4.42 Git Commit: 1cdaf895c99d319c0007d0b62818cf85fc4b087f Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 95 unique boards, 27 SoC families, 21 builds out of 200 Boot Regressions Detected: arc: hsdk_defconfig: gcc-8: hsdk: lab-baylibre: failing since 6 days (last pass: v5.4.41-2-ged1728340b22 - first fail: v5.4.41-148-gcac6eb2794c8) arm: davinci_all_defconfig: gcc-8: da850-evm: lab-baylibre-seattle: new failure (last pass: v5.4.41-148-gcac6eb2794c8) dm365evm,legacy: lab-baylibre-seattle: new failure (last pass: v5.4.41-148-gcac6eb2794c8) qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 106 days (last pass: v5.4.17-99-gbd0c6624a110 - first fail: v5.4.17-238-gbffcaa93483d) sama5_defconfig: gcc-8: at91-sama5d4_xplained: lab-baylibre: failing since 47 days (last pass: v5.4.30-37-g40da5db79b55 - first fail: v5.4.30-39-g23c04177b89f) versatile_defconfig: gcc-8: versatile-pb: lab-collabora: new failure (last pass: v5.4.41-148-gcac6eb2794c8) Boot Failure Detected: arm: sama5_defconfig: gcc-8: at91-sama5d4_xplained: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab stih410-b2120: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab davinci_all_defconfig: gcc-8 da850-evm: 1 offline lab dm365evm,legacy: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab --- For more info write to <info(a)kernelci.org>

4 years, 7 months

1
0
0 0

stable-rc/linux-4.19.y boot: 129 boots: 1 failed, 117 passed with 7 offline, 4 untried/unknown (v4.19.124)

by kernelci.org bot

****************************************** * WARNING: Boot tests are now deprecated * ****************************************** As kernelci.org is expanding its functional testing capabilities, the concept of boot testing is now deprecated. Boot results are scheduled to be dropped on *5th June 2020*. The full schedule for boot tests deprecation is available on this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238 The new equivalent is the *baseline* test suite which also runs sanity checks using dmesg and bootrr: https://github.com/kernelci/bootrr See the *baseline results for this kernel revision* on this page: https://kernelci.org/test/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.12… ------------------------------------------------------------------------------- stable-rc/linux-4.19.y boot: 129 boots: 1 failed, 117 passed with 7 offline, 4 untried/unknown (v4.19.124) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.124/ Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.124 Git Commit: 1bab61d3e8cd96f2badf515dcb06e4e1029bc017 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 79 unique boards, 23 SoC families, 20 builds out of 206 Boot Regressions Detected: arm: davinci_all_defconfig: gcc-8: da850-evm: lab-baylibre-seattle: new failure (last pass: v4.19.123-81-gff1170bc0ae9) dm365evm,legacy: lab-baylibre-seattle: new failure (last pass: v4.19.123-81-gff1170bc0ae9) qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 12 days (last pass: v4.19.122 - first fail: v4.19.122-48-g92ba0b6b33ad) sama5_defconfig: gcc-8: at91-sama5d4_xplained: lab-baylibre: failing since 73 days (last pass: v4.19.108-87-g624c124960e8 - first fail: v4.19.109) sunxi_defconfig: gcc-8: sun8i-h2-plus-orangepi-r1: lab-baylibre: new failure (last pass: v4.19.123-81-gff1170bc0ae9) versatile_defconfig: gcc-8: versatile-pb: lab-collabora: new failure (last pass: v4.19.123-81-gff1170bc0ae9) arm64: defconfig: gcc-8: sun50i-a64-pine64-plus: lab-baylibre: new failure (last pass: v4.19.123-81-gff1170bc0ae9) Boot Failure Detected: arm: sama5_defconfig: gcc-8: at91-sama5d4_xplained: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab stih410-b2120: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab davinci_all_defconfig: gcc-8 da850-evm: 1 offline lab dm365evm,legacy: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab --- For more info write to <info(a)kernelci.org>

4 years, 7 months

1
0
0 0

stable-rc/linux-3.16.y boot: 59 boots: 53 failed, 0 passed with 3 offline, 3 untried/unknown (v3.16.84)

by kernelci.org bot

****************************************** * WARNING: Boot tests are now deprecated * ****************************************** As kernelci.org is expanding its functional testing capabilities, the concept of boot testing is now deprecated. Boot results are scheduled to be dropped on *5th June 2020*. The full schedule for boot tests deprecation is available on this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238 The new equivalent is the *baseline* test suite which also runs sanity checks using dmesg and bootrr: https://github.com/kernelci/bootrr See the *baseline results for this kernel revision* on this page: https://kernelci.org/test/job/stable-rc/branch/linux-3.16.y/kernel/v3.16.84… ------------------------------------------------------------------------------- stable-rc/linux-3.16.y boot: 59 boots: 53 failed, 0 passed with 3 offline, 3 untried/unknown (v3.16.84) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.16.y/kernel/v3.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.16.y/kernel/v3.16.84/ Tree: stable-rc Branch: linux-3.16.y Git Describe: v3.16.84 Git Commit: babf7e4a11200d94219dcebd64f50e6304bbde2e Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 31 unique boards, 11 SoC families, 15 builds out of 187 Boot Regressions Detected: arm: multi_v7_defconfig: gcc-8: armada-xp-openblocks-ax3-4: lab-baylibre-seattle: failing since 25 days (last pass: v3.16.82 - first fail: v3.16.83) exynos5800-peach-pi: lab-baylibre-seattle: failing since 25 days (last pass: v3.16.82 - first fail: v3.16.83) imx6dl-wandboard_dual: lab-baylibre-seattle: failing since 25 days (last pass: v3.16.82 - first fail: v3.16.83) imx6dl-wandboard_solo: lab-baylibre-seattle: failing since 25 days (last pass: v3.16.82 - first fail: v3.16.83) imx6q-wandboard: lab-baylibre-seattle: failing since 25 days (last pass: v3.16.82 - first fail: v3.16.83) omap3-beagle: lab-baylibre-seattle: failing since 25 days (last pass: v3.16.82 - first fail: v3.16.83) omap4-panda: lab-baylibre-seattle: failing since 25 days (last pass: v3.16.82 - first fail: v3.16.83) sun4i-a10-cubieboard: lab-baylibre-seattle: failing since 25 days (last pass: v3.16.82 - first fail: v3.16.83) tegra20-iris-512: lab-baylibre-seattle: failing since 25 days (last pass: v3.16.82 - first fail: v3.16.83) tegra30-beaver: lab-baylibre-seattle: failing since 25 days (last pass: v3.16.82 - first fail: v3.16.83) zynq-zc702: lab-baylibre-seattle: failing since 25 days (last pass: v3.16.82 - first fail: v3.16.83) Boot Failures Detected: i386: i386_defconfig: gcc-8: qemu_i386: 1 failed lab x86_64: x86_64_defconfig: gcc-8: minnowboard-turbot-E3826: 1 failed lab qemu_x86_64: 1 failed lab arm: imx_v4_v5_defconfig: gcc-8: imx27-phytec-phycard-s-rdk: 1 failed lab tegra_defconfig: gcc-8: tegra124-jetson-tk1: 2 failed labs tegra20-iris-512: 1 failed lab tegra30-beaver: 1 failed lab mvebu_v7_defconfig: gcc-8: armada-xp-openblocks-ax3-4: 1 failed lab bcm2835_defconfig: gcc-8: bcm2835-rpi-b: 1 failed lab davinci_all_defconfig: gcc-8: da850-evm: 1 failed lab dm365evm,legacy: 1 failed lab sunxi_defconfig: gcc-8: sun4i-a10-cubieboard: 1 failed lab sun4i-a10-olinuxino-lime: 1 failed lab sun5i-a13-olinuxino-micro: 1 failed lab sun7i-a20-cubieboard2: 2 failed labs omap2plus_defconfig: gcc-8: omap3-beagle: 1 failed lab omap4-panda: 3 failed labs multi_v7_defconfig: gcc-8: armada-xp-openblocks-ax3-4: 1 failed lab imx27-phytec-phycard-s-rdk: 1 failed lab imx53-qsrb: 1 failed lab imx6dl-riotboard: 1 failed lab imx6dl-wandboard_dual: 1 failed lab imx6dl-wandboard_solo: 1 failed lab imx6q-sabrelite: 2 failed labs imx6q-wandboard: 1 failed lab omap3-beagle: 1 failed lab omap4-panda: 3 failed labs qemu_arm-virt-gicv2: 1 failed lab qemu_arm-virt-gicv3: 1 failed lab sun4i-a10-cubieboard: 1 failed lab sun4i-a10-olinuxino-lime: 1 failed lab sun5i-a13-olinuxino-micro: 1 failed lab sun7i-a20-cubieboard2: 2 failed labs tegra124-jetson-tk1: 1 failed lab tegra20-iris-512: 1 failed lab tegra30-beaver: 1 failed lab zynq-zc702: 1 failed lab imx_v6_v7_defconfig: gcc-8: imx27-phytec-phycard-s-rdk: 1 failed lab imx53-qsrb: 1 failed lab imx6dl-riotboard: 1 failed lab imx6dl-wandboard_dual: 1 failed lab imx6dl-wandboard_solo: 1 failed lab multi_v5_defconfig: gcc-8: imx27-phytec-phycard-s-rdk: 1 failed lab arm64: defconfig: gcc-8: qemu_arm64-virt-gicv2: 1 failed lab qemu_arm64-virt-gicv3: 1 failed lab Offline Platforms: arm: imx_v6_v7_defconfig: gcc-8 imx6q-wandboard: 1 offline lab multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab --- For more info write to <info(a)kernelci.org>

4 years, 7 months

1
0
0 0

FAILED: patch "[PATCH] s390/kexec_file: fix initrd location for kdump kernel" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 70b690547d5ea1a3d135a4cc39cd1e08246d0c3a Mon Sep 17 00:00:00 2001 From: Philipp Rudo <prudo(a)linux.ibm.com> Date: Tue, 12 May 2020 19:39:56 +0200 Subject: [PATCH] s390/kexec_file: fix initrd location for kdump kernel initrd_start must not point at the location the initrd is loaded into the crashkernel memory but at the location it will be after the crashkernel memory is swapped with the memory at 0. Fixes: ee337f5469fd ("s390/kexec_file: Add crash support to image loader") Reported-by: Lianbo Jiang <lijiang(a)redhat.com> Signed-off-by: Philipp Rudo <prudo(a)linux.ibm.com> Tested-by: Lianbo Jiang <lijiang(a)redhat.com> Link: https://lore.kernel.org/r/20200512193956.15ae3f23@laptop2-ibm.local Signed-off-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Signed-off-by: Vasily Gorbik <gor(a)linux.ibm.com> diff --git a/arch/s390/kernel/machine_kexec_file.c b/arch/s390/kernel/machine_kexec_file.c index 8415ae7d2a23..f9e4baa64b67 100644 --- a/arch/s390/kernel/machine_kexec_file.c +++ b/arch/s390/kernel/machine_kexec_file.c @@ -151,7 +151,7 @@ static int kexec_file_add_initrd(struct kimage *image, buf.mem += crashk_res.start; buf.memsz = buf.bufsz; - data->parm->initrd_start = buf.mem; + data->parm->initrd_start = data->memsz; data->parm->initrd_size = buf.memsz; data->memsz += buf.memsz;

4 years, 7 months

1
0
0 0

FAILED: patch "[PATCH] tpm: check event log version before reading final events" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From b4f1874c62168159fdb419ced4afc77c1b51c475 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Yhuel?= <loic.yhuel(a)gmail.com> Date: Tue, 12 May 2020 06:01:13 +0200 Subject: [PATCH] tpm: check event log version before reading final events MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This fixes the boot issues since 5.3 on several Dell models when the TPM is enabled. Depending on the exact grub binary, booting the kernel would freeze early, or just report an error parsing the final events log. We get an event log in the SHA-1 format, which doesn't have a tcg_efi_specid_event_head in the first event, and there is a final events table which doesn't match the crypto agile format. __calc_tpm2_event_size reads bad "count" and "efispecid->num_algs", and either fails, or loops long enough for the machine to be appear frozen. So we now only parse the final events table, which is per the spec always supposed to be in the crypto agile format, when we got a event log in this format. Fixes: c46f3405692de ("tpm: Reserve the TPM final events table") Fixes: 166a2809d65b2 ("tpm: Don't duplicate events from the final event log in the TCG2 log") Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1779611 Signed-off-by: Loïc Yhuel <loic.yhuel(a)gmail.com> Link: https://lore.kernel.org/r/20200512040113.277768-1-loic.yhuel@gmail.com Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com> Reviewed-by: Jerry Snitselaar <jsnitsel(a)redhat.com> Reviewed-by: Matthew Garrett <mjg59(a)google.com> [ardb: warn when final events table is missing or in the wrong format] Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> diff --git a/drivers/firmware/efi/libstub/tpm.c b/drivers/firmware/efi/libstub/tpm.c index 1d59e103a2e3..e9a684637b70 100644 --- a/drivers/firmware/efi/libstub/tpm.c +++ b/drivers/firmware/efi/libstub/tpm.c @@ -54,7 +54,7 @@ void efi_retrieve_tpm2_eventlog(void) efi_status_t status; efi_physical_addr_t log_location = 0, log_last_entry = 0; struct linux_efi_tpm_eventlog *log_tbl = NULL; - struct efi_tcg2_final_events_table *final_events_table; + struct efi_tcg2_final_events_table *final_events_table = NULL; unsigned long first_entry_addr, last_entry_addr; size_t log_size, last_entry_size; efi_bool_t truncated; @@ -127,7 +127,8 @@ void efi_retrieve_tpm2_eventlog(void) * Figure out whether any events have already been logged to the * final events structure, and if so how much space they take up */ - final_events_table = get_efi_config_table(LINUX_EFI_TPM_FINAL_LOG_GUID); + if (version == EFI_TCG2_EVENT_LOG_FORMAT_TCG_2) + final_events_table = get_efi_config_table(LINUX_EFI_TPM_FINAL_LOG_GUID); if (final_events_table && final_events_table->nr_events) { struct tcg_pcr_event2_head *header; int offset; diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c index 31f9f0e369b9..0543fbf60222 100644 --- a/drivers/firmware/efi/tpm.c +++ b/drivers/firmware/efi/tpm.c @@ -62,8 +62,11 @@ int __init efi_tpm_eventlog_init(void) tbl_size = sizeof(*log_tbl) + log_tbl->size; memblock_reserve(efi.tpm_log, tbl_size); - if (efi.tpm_final_log == EFI_INVALID_TABLE_ADDR) + if (efi.tpm_final_log == EFI_INVALID_TABLE_ADDR || + log_tbl->version != EFI_TCG2_EVENT_LOG_FORMAT_TCG_2) { + pr_warn(FW_BUG "TPM Final Events table missing or invalid\n"); goto out; + } final_tbl = early_memremap(efi.tpm_final_log, sizeof(*final_tbl));

4 years, 7 months

1
0
0 0

FAILED: patch "[PATCH] rxrpc: Fix ack discard" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 441fdee1eaf050ef0040bde0d7af075c1c6a6d8b Mon Sep 17 00:00:00 2001 From: David Howells <dhowells(a)redhat.com> Date: Wed, 29 Apr 2020 23:48:43 +0100 Subject: [PATCH] rxrpc: Fix ack discard The Rx protocol has a "previousPacket" field in it that is not handled in the same way by all protocol implementations. Sometimes it contains the serial number of the last DATA packet received, sometimes the sequence number of the last DATA packet received and sometimes the highest sequence number so far received. AF_RXRPC is using this to weed out ACKs that are out of date (it's possible for ACK packets to get reordered on the wire), but this does not work with OpenAFS which will just stick the sequence number of the last packet seen into previousPacket. The issue being seen is that big AFS FS.StoreData RPC (eg. of ~256MiB) are timing out when partly sent. A trace was captured, with an additional tracepoint to show ACKs being discarded in rxrpc_input_ack(). Here's an excerpt showing the problem. 52873.203230: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 0002449c q=00024499 fl=09 A DATA packet with sequence number 00024499 has been transmitted (the "q=" field). ... 52873.243296: rxrpc_rx_ack: c=000004ae 00012a2b DLY r=00024499 f=00024497 p=00024496 n=0 52873.243376: rxrpc_rx_ack: c=000004ae 00012a2c IDL r=0002449b f=00024499 p=00024498 n=0 52873.243383: rxrpc_rx_ack: c=000004ae 00012a2d OOS r=0002449d f=00024499 p=0002449a n=2 The Out-Of-Sequence ACK indicates that the server didn't see DATA sequence number 00024499, but did see seq 0002449a (previousPacket, shown as "p=", skipped the number, but firstPacket, "f=", which shows the bottom of the window is set at that point). 52873.252663: rxrpc_retransmit: c=000004ae q=24499 a=02 xp=14581537 52873.252664: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244bc q=00024499 fl=0b *RETRANS* The packet has been retransmitted. Retransmission recurs until the peer says it got the packet. 52873.271013: rxrpc_rx_ack: c=000004ae 00012a31 OOS r=000244a1 f=00024499 p=0002449e n=6 More OOS ACKs indicate that the other packets that are already in the transmission pipeline are being received. The specific-ACK list is up to 6 ACKs and NAKs. ... 52873.284792: rxrpc_rx_ack: c=000004ae 00012a49 OOS r=000244b9 f=00024499 p=000244b6 n=30 52873.284802: rxrpc_retransmit: c=000004ae q=24499 a=0a xp=63505500 52873.284804: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244c2 q=00024499 fl=0b *RETRANS* 52873.287468: rxrpc_rx_ack: c=000004ae 00012a4a OOS r=000244ba f=00024499 p=000244b7 n=31 52873.287478: rxrpc_rx_ack: c=000004ae 00012a4b OOS r=000244bb f=00024499 p=000244b8 n=32 At this point, the server's receive window is full (n=32) with presumably 1 NAK'd packet and 31 ACK'd packets. We can't transmit any more packets. 52873.287488: rxrpc_retransmit: c=000004ae q=24499 a=0a xp=61327980 52873.287489: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244c3 q=00024499 fl=0b *RETRANS* 52873.293850: rxrpc_rx_ack: c=000004ae 00012a4c DLY r=000244bc f=000244a0 p=00024499 n=25 And now we've received an ACK indicating that a DATA retransmission was received. 7 packets have been processed (the occupied part of the window moved, as indicated by f= and n=). 52873.293853: rxrpc_rx_discard_ack: c=000004ae r=00012a4c 000244a0<00024499 00024499<000244b8 However, the DLY ACK gets discarded because its previousPacket has gone backwards (from p=000244b8, in the ACK at 52873.287478 to p=00024499 in the ACK at 52873.293850). We then end up in a continuous cycle of retransmit/discard. kafs fails to update its window because it's discarding the ACKs and can't transmit an extra packet that would clear the issue because the window is full. OpenAFS doesn't change the previousPacket value in the ACKs because no new DATA packets are received with a different previousPacket number. Fix this by altering the discard check to only discard an ACK based on previousPacket if there was no advance in the firstPacket. This allows us to transmit a new packet which will cause previousPacket to advance in the next ACK. The check, however, needs to allow for the possibility that previousPacket may actually have had the serial number placed in it instead - in which case it will go outside the window and we should ignore it. Fixes: 1a2391c30c0b ("rxrpc: Fix detection of out of order acks") Reported-by: Dave Botsch <botsch(a)cnf.cornell.edu> Signed-off-by: David Howells <dhowells(a)redhat.com> diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c index 2f22f082a66c..3be4177baf70 100644 --- a/net/rxrpc/input.c +++ b/net/rxrpc/input.c @@ -802,6 +802,30 @@ static void rxrpc_input_soft_acks(struct rxrpc_call *call, u8 *acks, } } +/* + * Return true if the ACK is valid - ie. it doesn't appear to have regressed + * with respect to the ack state conveyed by preceding ACKs. + */ +static bool rxrpc_is_ack_valid(struct rxrpc_call *call, + rxrpc_seq_t first_pkt, rxrpc_seq_t prev_pkt) +{ + rxrpc_seq_t base = READ_ONCE(call->ackr_first_seq); + + if (after(first_pkt, base)) + return true; /* The window advanced */ + + if (before(first_pkt, base)) + return false; /* firstPacket regressed */ + + if (after_eq(prev_pkt, call->ackr_prev_seq)) + return true; /* previousPacket hasn't regressed. */ + + /* Some rx implementations put a serial number in previousPacket. */ + if (after_eq(prev_pkt, base + call->tx_winsize)) + return false; + return true; +} + /* * Process an ACK packet. * @@ -865,8 +889,7 @@ static void rxrpc_input_ack(struct rxrpc_call *call, struct sk_buff *skb) } /* Discard any out-of-order or duplicate ACKs (outside lock). */ - if (before(first_soft_ack, call->ackr_first_seq) || - before(prev_pkt, call->ackr_prev_seq)) { + if (!rxrpc_is_ack_valid(call, first_soft_ack, prev_pkt)) { trace_rxrpc_rx_discard_ack(call->debug_id, sp->hdr.serial, first_soft_ack, call->ackr_first_seq, prev_pkt, call->ackr_prev_seq); @@ -882,8 +905,7 @@ static void rxrpc_input_ack(struct rxrpc_call *call, struct sk_buff *skb) spin_lock(&call->input_lock); /* Discard any out-of-order or duplicate ACKs (inside lock). */ - if (before(first_soft_ack, call->ackr_first_seq) || - before(prev_pkt, call->ackr_prev_seq)) { + if (!rxrpc_is_ack_valid(call, first_soft_ack, prev_pkt)) { trace_rxrpc_rx_discard_ack(call->debug_id, sp->hdr.serial, first_soft_ack, call->ackr_first_seq, prev_pkt, call->ackr_prev_seq);

4 years, 7 months

1
0
0 0

FAILED: patch "[PATCH] rxrpc: Fix ack discard" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 441fdee1eaf050ef0040bde0d7af075c1c6a6d8b Mon Sep 17 00:00:00 2001 From: David Howells <dhowells(a)redhat.com> Date: Wed, 29 Apr 2020 23:48:43 +0100 Subject: [PATCH] rxrpc: Fix ack discard The Rx protocol has a "previousPacket" field in it that is not handled in the same way by all protocol implementations. Sometimes it contains the serial number of the last DATA packet received, sometimes the sequence number of the last DATA packet received and sometimes the highest sequence number so far received. AF_RXRPC is using this to weed out ACKs that are out of date (it's possible for ACK packets to get reordered on the wire), but this does not work with OpenAFS which will just stick the sequence number of the last packet seen into previousPacket. The issue being seen is that big AFS FS.StoreData RPC (eg. of ~256MiB) are timing out when partly sent. A trace was captured, with an additional tracepoint to show ACKs being discarded in rxrpc_input_ack(). Here's an excerpt showing the problem. 52873.203230: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 0002449c q=00024499 fl=09 A DATA packet with sequence number 00024499 has been transmitted (the "q=" field). ... 52873.243296: rxrpc_rx_ack: c=000004ae 00012a2b DLY r=00024499 f=00024497 p=00024496 n=0 52873.243376: rxrpc_rx_ack: c=000004ae 00012a2c IDL r=0002449b f=00024499 p=00024498 n=0 52873.243383: rxrpc_rx_ack: c=000004ae 00012a2d OOS r=0002449d f=00024499 p=0002449a n=2 The Out-Of-Sequence ACK indicates that the server didn't see DATA sequence number 00024499, but did see seq 0002449a (previousPacket, shown as "p=", skipped the number, but firstPacket, "f=", which shows the bottom of the window is set at that point). 52873.252663: rxrpc_retransmit: c=000004ae q=24499 a=02 xp=14581537 52873.252664: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244bc q=00024499 fl=0b *RETRANS* The packet has been retransmitted. Retransmission recurs until the peer says it got the packet. 52873.271013: rxrpc_rx_ack: c=000004ae 00012a31 OOS r=000244a1 f=00024499 p=0002449e n=6 More OOS ACKs indicate that the other packets that are already in the transmission pipeline are being received. The specific-ACK list is up to 6 ACKs and NAKs. ... 52873.284792: rxrpc_rx_ack: c=000004ae 00012a49 OOS r=000244b9 f=00024499 p=000244b6 n=30 52873.284802: rxrpc_retransmit: c=000004ae q=24499 a=0a xp=63505500 52873.284804: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244c2 q=00024499 fl=0b *RETRANS* 52873.287468: rxrpc_rx_ack: c=000004ae 00012a4a OOS r=000244ba f=00024499 p=000244b7 n=31 52873.287478: rxrpc_rx_ack: c=000004ae 00012a4b OOS r=000244bb f=00024499 p=000244b8 n=32 At this point, the server's receive window is full (n=32) with presumably 1 NAK'd packet and 31 ACK'd packets. We can't transmit any more packets. 52873.287488: rxrpc_retransmit: c=000004ae q=24499 a=0a xp=61327980 52873.287489: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244c3 q=00024499 fl=0b *RETRANS* 52873.293850: rxrpc_rx_ack: c=000004ae 00012a4c DLY r=000244bc f=000244a0 p=00024499 n=25 And now we've received an ACK indicating that a DATA retransmission was received. 7 packets have been processed (the occupied part of the window moved, as indicated by f= and n=). 52873.293853: rxrpc_rx_discard_ack: c=000004ae r=00012a4c 000244a0<00024499 00024499<000244b8 However, the DLY ACK gets discarded because its previousPacket has gone backwards (from p=000244b8, in the ACK at 52873.287478 to p=00024499 in the ACK at 52873.293850). We then end up in a continuous cycle of retransmit/discard. kafs fails to update its window because it's discarding the ACKs and can't transmit an extra packet that would clear the issue because the window is full. OpenAFS doesn't change the previousPacket value in the ACKs because no new DATA packets are received with a different previousPacket number. Fix this by altering the discard check to only discard an ACK based on previousPacket if there was no advance in the firstPacket. This allows us to transmit a new packet which will cause previousPacket to advance in the next ACK. The check, however, needs to allow for the possibility that previousPacket may actually have had the serial number placed in it instead - in which case it will go outside the window and we should ignore it. Fixes: 1a2391c30c0b ("rxrpc: Fix detection of out of order acks") Reported-by: Dave Botsch <botsch(a)cnf.cornell.edu> Signed-off-by: David Howells <dhowells(a)redhat.com> diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c index 2f22f082a66c..3be4177baf70 100644 --- a/net/rxrpc/input.c +++ b/net/rxrpc/input.c @@ -802,6 +802,30 @@ static void rxrpc_input_soft_acks(struct rxrpc_call *call, u8 *acks, } } +/* + * Return true if the ACK is valid - ie. it doesn't appear to have regressed + * with respect to the ack state conveyed by preceding ACKs. + */ +static bool rxrpc_is_ack_valid(struct rxrpc_call *call, + rxrpc_seq_t first_pkt, rxrpc_seq_t prev_pkt) +{ + rxrpc_seq_t base = READ_ONCE(call->ackr_first_seq); + + if (after(first_pkt, base)) + return true; /* The window advanced */ + + if (before(first_pkt, base)) + return false; /* firstPacket regressed */ + + if (after_eq(prev_pkt, call->ackr_prev_seq)) + return true; /* previousPacket hasn't regressed. */ + + /* Some rx implementations put a serial number in previousPacket. */ + if (after_eq(prev_pkt, base + call->tx_winsize)) + return false; + return true; +} + /* * Process an ACK packet. * @@ -865,8 +889,7 @@ static void rxrpc_input_ack(struct rxrpc_call *call, struct sk_buff *skb) } /* Discard any out-of-order or duplicate ACKs (outside lock). */ - if (before(first_soft_ack, call->ackr_first_seq) || - before(prev_pkt, call->ackr_prev_seq)) { + if (!rxrpc_is_ack_valid(call, first_soft_ack, prev_pkt)) { trace_rxrpc_rx_discard_ack(call->debug_id, sp->hdr.serial, first_soft_ack, call->ackr_first_seq, prev_pkt, call->ackr_prev_seq); @@ -882,8 +905,7 @@ static void rxrpc_input_ack(struct rxrpc_call *call, struct sk_buff *skb) spin_lock(&call->input_lock); /* Discard any out-of-order or duplicate ACKs (inside lock). */ - if (before(first_soft_ack, call->ackr_first_seq) || - before(prev_pkt, call->ackr_prev_seq)) { + if (!rxrpc_is_ack_valid(call, first_soft_ack, prev_pkt)) { trace_rxrpc_rx_discard_ack(call->debug_id, sp->hdr.serial, first_soft_ack, call->ackr_first_seq, prev_pkt, call->ackr_prev_seq);

4 years, 7 months

1
0
0 0

stable-rc/linux-4.4.y boot: 82 boots: 3 failed, 73 passed with 4 offline, 2 untried/unknown (v4.4.224)

by kernelci.org bot

****************************************** * WARNING: Boot tests are now deprecated * ****************************************** As kernelci.org is expanding its functional testing capabilities, the concept of boot testing is now deprecated. Boot results are scheduled to be dropped on *5th June 2020*. The full schedule for boot tests deprecation is available on this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238 The new equivalent is the *baseline* test suite which also runs sanity checks using dmesg and bootrr: https://github.com/kernelci/bootrr See the *baseline results for this kernel revision* on this page: https://kernelci.org/test/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.224/… ------------------------------------------------------------------------------- stable-rc/linux-4.4.y boot: 82 boots: 3 failed, 73 passed with 4 offline, 2 untried/unknown (v4.4.224) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.224/ Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.224 Git Commit: d72237c1e00f85e5df1c040280d50561c8a28329 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 47 unique boards, 18 SoC families, 17 builds out of 190 Boot Regressions Detected: arm: qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 11 days (last pass: v4.4.223 - first fail: v4.4.223-36-g32f5ec9b096d) sama5_defconfig: gcc-8: at91-sama5d4_xplained: lab-baylibre: failing since 60 days (last pass: v4.4.216-127-g955137020949 - first fail: v4.4.217) Boot Failures Detected: arm: sama5_defconfig: gcc-8: at91-sama5d4_xplained: 1 failed lab imx_v4_v5_defconfig: gcc-8: imx27-phytec-phycard-s-rdk: 1 failed lab multi_v5_defconfig: gcc-8: imx27-phytec-phycard-s-rdk: 1 failed lab Offline Platforms: arm: qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab --- For more info write to <info(a)kernelci.org>

4 years, 7 months

1
0
0 0

FAILED: patch "[PATCH] iwlwifi: pcie: handle QuZ configs with killer NICs as well" failed to apply to 5.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From f92f26f2ed2c9f92c9270c705bca96310c3cdf5a Mon Sep 17 00:00:00 2001 From: Luca Coelho <luciano.coelho(a)intel.com> Date: Fri, 24 Apr 2020 12:20:08 +0300 Subject: [PATCH] iwlwifi: pcie: handle QuZ configs with killer NICs as well The killer devices were left out of the checks that convert Qu-B0 to QuZ configurations. Add them. Cc: stable(a)vger.kernel.org # v5.3+ Fixes: 5a8c31aa6357 ("iwlwifi: pcie: fix recognition of QuZ devices") Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> Tested-by: You-Sheng Yang <vicamo(a)gmail.com> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20200424121518.b715acfbe211.I273a098064a2… diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c index 6744c0281ffb..29971c25dba4 100644 --- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c @@ -1092,6 +1092,10 @@ static int iwl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) iwl_trans->cfg = &iwl_ax101_cfg_quz_hr; else if (iwl_trans->cfg == &iwl_ax201_cfg_qu_hr) iwl_trans->cfg = &iwl_ax201_cfg_quz_hr; + else if (iwl_trans->cfg == &killer1650s_2ax_cfg_qu_b0_hr_b0) + iwl_trans->cfg = &iwl_ax1650s_cfg_quz_hr; + else if (iwl_trans->cfg == &killer1650i_2ax_cfg_qu_b0_hr_b0) + iwl_trans->cfg = &iwl_ax1650i_cfg_quz_hr; } #endif

4 years, 7 months

1
0
0 0

FAILED: patch "[PATCH] iwlwifi: pcie: handle QuZ configs with killer NICs as well" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From f92f26f2ed2c9f92c9270c705bca96310c3cdf5a Mon Sep 17 00:00:00 2001 From: Luca Coelho <luciano.coelho(a)intel.com> Date: Fri, 24 Apr 2020 12:20:08 +0300 Subject: [PATCH] iwlwifi: pcie: handle QuZ configs with killer NICs as well The killer devices were left out of the checks that convert Qu-B0 to QuZ configurations. Add them. Cc: stable(a)vger.kernel.org # v5.3+ Fixes: 5a8c31aa6357 ("iwlwifi: pcie: fix recognition of QuZ devices") Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> Tested-by: You-Sheng Yang <vicamo(a)gmail.com> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20200424121518.b715acfbe211.I273a098064a2… diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c index 6744c0281ffb..29971c25dba4 100644 --- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c @@ -1092,6 +1092,10 @@ static int iwl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) iwl_trans->cfg = &iwl_ax101_cfg_quz_hr; else if (iwl_trans->cfg == &iwl_ax201_cfg_qu_hr) iwl_trans->cfg = &iwl_ax201_cfg_quz_hr; + else if (iwl_trans->cfg == &killer1650s_2ax_cfg_qu_b0_hr_b0) + iwl_trans->cfg = &iwl_ax1650s_cfg_quz_hr; + else if (iwl_trans->cfg == &killer1650i_2ax_cfg_qu_b0_hr_b0) + iwl_trans->cfg = &iwl_ax1650i_cfg_quz_hr; } #endif

4 years, 7 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2020