Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
Quoting Guenter Roeck (2024-10-08 16:27:37) > On 10/8/24 16:12, Stephen Boyd wrote: > > > > The best I can come up with then is to test for a NULL of_root when > > CONFIG_ARM64 and CONFIG_ACPI are enabled, because the tests > > intentionally don't work when both those configs are enabled and the > > 'of_root' isn't populated. In all other cases the 'of_root' missing is a > > bug. I'll probably make this into some sort of kunit helper function in > > of_private.h and send it to DT maintainers. > > Sounds good. Thanks a lot for tracking this down. > > That makes me wonder though why only arm64 has that restriction. Both > riscv and loongarch have ACPI enabled in their defconfig files but call > unflatten_device_tree() unconditionally. > > Oh well ... Some of the reason is described in the thread I linked earlier. In particular, this email from Mark[1]. There's also more comments from Mark on an earlier patchset[2]. Maybe arm64 will allow it later, and then we'll be able to revert this skip patch. [1] https://lore.kernel.org/all/zd4dqpho7em1j...@fvff77s0q05n.cambridge.arm.com/ [2] https://lore.kernel.org/all/ZaZtbU9hre3YhZam@FVFF77S0Q05N/
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
Quoting Guenter Roeck (2024-10-03 21:52:09)
> On 10/3/24 17:42, Stephen Boyd wrote:
> >
> > Can you please describe how you run the kunit test? And provide the qemu
> > command you run to boot arm64 with acpi?
> >
>
> Example command line:
>
> qemu-system-aarch64 -M virt -m 512 \
> -kernel arch/arm64/boot/Image -no-reboot -nographic \
> -snapshot \
> -bios /opt/buildbot/rootfs/arm64/../firmware/QEMU_EFI-aarch64.fd \
> -device virtio-blk-device,drive=d0 \
> -drive file=rootfs.ext2,if=none,id=d0,format=raw \
> -cpu cortex-a57 -serial stdio -monitor none -no-reboot \
> --append "kunit.stats_enabled=2 kunit.filter=speed>slow root=/dev/vda
> rootwait earlycon=pl011,0x900 console=ttyAMA0"
>
> That works fine for me. Configuration is arm64 defconfig plus various
> debug and kunit options. I built the efi image myself from sources.
> The root file system is from buildroot with modified init script.
> kunit tests are all built into the kernel and run during boot.
Thanks. I figured out that I was missing enabling CONFIG_ACPI. Here's my
commandline
./tools/testing/kunit/kunit.py run --arch=arm64 \
--kunitconfig=drivers/of \
--qemu_args="-bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd -smp 2" \
--kconfig_add="CONFIG_ACPI=y" \
--kernel_args="earlycon=pl011,0x900"
Now I can boot and reproduce the failure, but there's another problem.
ACPI disables itself when it fails to find tables.
ACPI: Unable to load the System Description Tables
This calls disable_acpi() which sets acpi_disabled to 1. This happens
before the unit test runs, meaning we can't reliably use 'acpi_disabled'
as a method to skip.
The best I can come up with then is to test for a NULL of_root when
CONFIG_ARM64 and CONFIG_ACPI are enabled, because the tests
intentionally don't work when both those configs are enabled and the
'of_root' isn't populated. In all other cases the 'of_root' missing is a
bug. I'll probably make this into some sort of kunit helper function in
of_private.h and send it to DT maintainers.
---8<
diff --git a/drivers/of/of_kunit_helpers.c b/drivers/of/of_kunit_helpers.c
index 287d6c91bb37..a1330e183230 100644
--- a/drivers/of/of_kunit_helpers.c
+++ b/drivers/of/of_kunit_helpers.c
@@ -36,6 +36,9 @@ int of_overlay_fdt_apply_kunit(struct kunit *test, void
*overlay_fdt,
int ret;
int *copy_id;
+ if (IS_ENABLED(CONFIG_ARM64) && IS_ENABLED(CONFIG_ACPI) && !of_root)
+ kunit_skip(test, "arm64+acpi rejects overlays");
+
copy_id = kunit_kmalloc(test, sizeof(*copy_id), GFP_KERNEL);
if (!copy_id)
return -ENOMEM;
diff --git a/drivers/of/of_test.c b/drivers/of/of_test.c
index c85a258bc6ae..6cca43bf8029 100644
--- a/drivers/of/of_test.c
+++ b/drivers/of/of_test.c
@@ -38,6 +38,8 @@ static int of_dtb_test_init(struct kunit *test)
{
if (!IS_ENABLED(CONFIG_OF_EARLY_FLATTREE))
kunit_skip(test, "requires CONFIG_OF_EARLY_FLATTREE");
+ if (IS_ENABLED(CONFIG_ARM64) && IS_ENABLED(CONFIG_ACPI) && !of_root)
+ kunit_skip(test, "arm64+acpi doesn't populate a root node on
ACPI systems");
return 0;
}
diff --git a/drivers/of/overlay_test.c b/drivers/of/overlay_test.c
index 19a292cdeee3..3e7ac97a6796 100644
--- a/drivers/of/overlay_test.c
+++ b/drivers/of/overlay_test.c
@@ -64,6 +64,8 @@ static void of_overlay_apply_kunit_cleanup(struct kunit *test)
if (!IS_ENABLED(CONFIG_OF_EARLY_FLATTREE))
kunit_skip(test, "requires CONFIG_OF_EARLY_FLATTREE for root
node");
+ if (IS_ENABLED(CONFIG_ARM64) && IS_ENABLED(CONFIG_ACPI) && !of_root)
+ kunit_skip(test, "arm64+acpi rejects overlays");
kunit_init_test(&fake, "fake test", NULL);
KUNIT_ASSERT_EQ(test, fake.status, KUNIT_SUCCESS);
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
Quoting Guenter Roeck (2024-10-03 17:25:37) > On 10/3/24 16:46, Stephen Boyd wrote: > [ ... ] > > That DT test has been there for a few releases. Is this the first time > > those tests have been run on arm64+acpi? I didn't try after sending the > > patches and forgot that the patch was dropped. > > > > Previously I had the affected tests disabled and never tracked down the > problem. > Since the problem is now spreading to additional tests, I finally tracked it > down, > that is all. Ok great. Good to know this isn't a new problem. Thanks for tracking it down. > > > How are you running kunit tests? I installed the qemu-efi-aarch64 debian > > package to get QEMU_EFI.fd but passing that to the kunit.py run command > > with --qemu_args="-bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd" didn't > > get me beyond the point that the EFI stub boots linux. I think the > > serial console must not be working and thus the kunit wrapper waits for > > something to show up but nothing ever does. I haven't dug any further > > though, so maybe you have a working command. > > > > I run all tests during boot, not from the command line. I also use the -bios > command but don't recall any issues with the console. I specify the > console on the qemu command line; depending on the qemu machine it is either > ttyS0 or ttyAMA0. The init script then finds and selects the active console. Can you please describe how you run the kunit test? And provide the qemu command you run to boot arm64 with acpi? > > > Here's my command that isn't working: > > > > ./tools/testing/kunit/kunit.py run --arch=arm64 --kunitconfig=drivers/of > > --qemu_args="-bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd" > > > > I can't really see what that command is actually doing ;-). It eventually runs this qemu command qemu-system-aarch64 -nodefaults -m 1024 -kernel .kunit/arch/arm64/boot/Image.gz -append 'kunit.enable=1 console=ttyAMA0 kunit_shutdown=reboot' -no-reboot -nographic -serial stdio -machine virt -cpu max,pauth-impdef=on -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd I see that it fails because the architected timer isn't there after I add an earlycon=pl011,0x900 to the kernel commandline. I suspect passing a bios like this is incorrect, but I rarely run qemu manually so I don't know what I'm doing wrong. NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 rcu: srcu_init: Setting srcu_struct sizes based on contention. timer_probe: no matching timers found Kernel panic - not syncing: Unable to initialise architected timer. CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc1-00261-g497f7c30f184 #203 Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x38/0x90 dump_stack+0x18/0x24 panic+0x36c/0x380 early_brk64+0x0/0xa8 start_kernel+0x27c/0x558 __primary_switched+0x80/0x88 ---[ end Kernel panic - not syncing: Unable to initialise architected timer. ]--- > > I'll just keep the affected tests disabled on arm64 for the time being. We should skip the tests on arm64+acpi, which is similar to disabling but not exactly the same. There will likely be more DT overlay usage in kunit and so that will lead to more test disabling. Skipping properly is the better solution.
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
Quoting Guenter Roeck (2024-09-28 14:32:35) > On 9/28/24 12:27, Shuah Khan wrote: > > On 9/28/24 11:54, Shuah Khan wrote: > >> On 9/28/24 11:31, Guenter Roeck wrote: > >>> On 9/27/24 17:08, Guenter Roeck wrote: > >>>> On 9/27/24 13:45, Shuah Khan wrote: > >>>>> On 9/27/24 10:19, Guenter Roeck wrote: > >>>>>> Copying devicetree maintainers. > >>>>>> > >>>>>> On Thu, Sep 26, 2024 at 09:39:38PM -0700, Guenter Roeck wrote: > >>>>>>> On Thu, Sep 26, 2024 at 09:14:11PM -0700, Guenter Roeck wrote: > >>>>>>>> Hi Stephen, > >>>>>>>> > >>>>>>>> On Thu, Jul 18, 2024 at 02:05:07PM -0700, Stephen Boyd wrote: > >>>>>>>>> Test that clks registered with 'struct clk_parent_data' work as > >>>>>>>>> intended and can find their parents. > >>>>>>>>> > >>>>>>>> > >>>>>>>> When testing this on arm64, I see the error below. The error is only > >>>>>>>> seen if I boot through efi, i.e., with "-bios QEMU_EFI-aarch64.fd" > >>>>>>>> qemu parameter. > >>>>>>>> > >>>>>>>> Any idea what might cause the problem ? > >>>>>>>> > >>>>>>> I noticed that the new overlay tests fail as well, also with "path > >>>>>>> '/' not > >>>>>>> found". > >>>>>>> > >>>>>>> [Maybe] answering my own question: I think the problem may be that > >>>>>>> there > >>>>>>> is no devicetree file and thus no devicetree root when booting through > >>>>>>> efi (in other words, of_root is NULL). Would it make sense to skip the > >>>>>>> tests in that case ? > >>>>>>> > >>>>>> > >>>>>> The problem is that of_root is not initialized in arm64 boots if ACPI > >>>>>> is enabled. > >>>>>> > >>>>>> From arch/arm64/kernel/setup.c:setup_arch(): > >>>>>> > >>>>>> if (acpi_disabled) > >>>>>> unflatten_device_tree(); // initializes of_root Oof I forgot that Rob didn't apply the patch that let an empty root live on ARM64 ACPI systems. See this thread[1] for all the details. > >>>>>> > >>>>>> ACPI is enabled if the system boots from EFI. This also affects > >>>>>> CONFIG_OF_KUNIT_TEST, which explicitly checks if of_root exists and > >>>>>> fails the test if it doesn't. > >>>>>> > >>>>>> I think those tests need to add a check for this condition, or affected > >>>>>> machines won't be able to run those unit tests. The obvious solution > >>>>>> would > >>>>>> be to check if of_root is set, but then the associated test case in > >>>>>> CONFIG_OF_KUNIT_TEST would not make sense. > >>>>>> > >>>>>> Any suggestions ? > >>>>>> I think that's the best we can do for now. Basically add a check like if (IS_ENABLED(CONFIG_ARM64) && acpi_disabled) kunit_skip(test, "ARM64 + ACPI rejects DT overlays"); to the overlay application function and the DT test. > >>>>> > >>>>> Would it work if these tests check if acpi_disabled and skip if it isn't > >>>>> disabled? It might be low overhead condition to check from these tests. > >>>>> > >>>>> acpi_disabled is exported: > >>>>> > >>>>> arch/arm64/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); > >>>>> arch/loongarch/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); > >>>>> arch/riscv/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); > >>>>> arch/x86/kernel/acpi/boot.c:EXPORT_SYMBOL(acpi_disabled); > >>>>> > >>>> > >>>> I don't think that would work. Looking through the use of acpi_init, > >>>> I don't think that of_root is always NULL when acpi_init is false; that > >>>> just happens to be the case on arm64 when booting through efi. > >>>> However, even arm64 has the following code. > &
Re: [PATCH v2 2/5] dt-bindings: soc: qcom: smd-rpm: add generic compatibles
Quoting Dmitry Baryshkov (2024-07-29 12:52:15) > Add two generic compatibles to all smd-rpm devices, they follow the same > RPMSG protocol and are either accessed through the smd-edge or through > the glink-edge. > > Signed-off-by: Dmitry Baryshkov > --- Acked-by: Stephen Boyd
Re: [PATCH v9 5/9] clk: mmp: Add Marvell PXA1908 clock driver
Quoting Duje Mihanović (2024-04-20 06:32:56) > On 4/20/24 00:24, Stephen Boyd wrote: > > Quoting Duje Mihanović (2024-04-19 07:31:14) > >> On Friday, April 12, 2024 4:57:09 AM GMT+2 Stephen Boyd wrote: > >>> Quoting Duje Mihanović (2024-04-11 03:15:34) > >>> > >>>> On 4/11/2024 10:00 AM, Stephen Boyd wrote: > >>>>> Is there a reason this file can't be a platform driver? > >>>> > >>>> Not that I know of, I did it like this only because the other in-tree > >>>> MMP clk drivers do so. I guess the initialization should look like any > >>>> of the qcom GCC drivers then? > >>> > >>> Yes. > >> > >> With the entire clock driver code in one file this is quite messy as I also > >> needed to add module_init and module_exit functions to (un)register each > >> platform driver, presumably because the module_platform_driver macro > >> doesn't > >> work with multiple platform drivers in one module. If I split up the driver > >> code for each clock controller block into its own file (such as clk-of- > >> pxa1908-apbc.c) as I believe is the best option, should the commits be > >> split > >> up accordingly as well? > > > > Sure. Why is 'of' in the name? Maybe that is unnecessary? > > That seems to be a historical leftover from when Marvell was just adding > DT support to the ARM32 MMP SoCs which Rob followed along with in the > PXA1928 clk driver and so have I. Should I drop it then as Marvell has > in the PXA1908 vendor kernel? > Sounds good to me.
Re: [PATCH v9 5/9] clk: mmp: Add Marvell PXA1908 clock driver
Quoting Duje Mihanović (2024-04-19 07:31:14) > On Friday, April 12, 2024 4:57:09 AM GMT+2 Stephen Boyd wrote: > > Quoting Duje Mihanović (2024-04-11 03:15:34) > > > > > On 4/11/2024 10:00 AM, Stephen Boyd wrote: > > > > Is there a reason this file can't be a platform driver? > > > > > > Not that I know of, I did it like this only because the other in-tree > > > MMP clk drivers do so. I guess the initialization should look like any > > > of the qcom GCC drivers then? > > > > Yes. > > With the entire clock driver code in one file this is quite messy as I also > needed to add module_init and module_exit functions to (un)register each > platform driver, presumably because the module_platform_driver macro doesn't > work with multiple platform drivers in one module. If I split up the driver > code for each clock controller block into its own file (such as clk-of- > pxa1908-apbc.c) as I believe is the best option, should the commits be split > up accordingly as well? Sure. Why is 'of' in the name? Maybe that is unnecessary? > > > > While at it, do you think the other MMP clk drivers could use a > conversion? > > > > I'm a little wary if the conversion cannot be tested though. > > I'd rather leave it to someone with the hardware then, especially since the > only reason I found out about the above is that the board I'm working on > failed to boot completely without the module_init function. > Ok, sounds fine.
Re: [PATCH v9 5/9] clk: mmp: Add Marvell PXA1908 clock driver
Quoting Duje Mihanović (2024-04-11 03:15:34) > On 4/11/2024 10:00 AM, Stephen Boyd wrote: > > > > Is there a reason this file can't be a platform driver? > > Not that I know of, I did it like this only because the other in-tree > MMP clk drivers do so. I guess the initialization should look like any > of the qcom GCC drivers then? Yes. > > While at it, do you think the other MMP clk drivers could use a conversion? > Sure, go for it. I'm a little wary if the conversion cannot be tested though. It doesn't hurt that other drivers haven't been converted.
Re: [PATCH v9 5/9] clk: mmp: Add Marvell PXA1908 clock driver
Quoting Duje Mihanović (2024-04-02 13:55:41)
> diff --git a/drivers/clk/mmp/clk-of-pxa1908.c
> b/drivers/clk/mmp/clk-of-pxa1908.c
> new file mode 100644
> index ..6f1f6e25a718
> --- /dev/null
> +++ b/drivers/clk/mmp/clk-of-pxa1908.c
> @@ -0,0 +1,328 @@
> +// SPDX-License-Identifier: GPL-2.0-only
[...]
> +static void __init pxa1908_apbc_clk_init(struct device_node *np)
> +{
> + struct pxa1908_clk_unit *pxa_unit;
> +
> + pxa_unit = kzalloc(sizeof(*pxa_unit), GFP_KERNEL);
> + if (!pxa_unit)
> + return;
> +
> + pxa_unit->apbc_base = of_iomap(np, 0);
> + if (!pxa_unit->apbc_base) {
> + pr_err("failed to map apbc registers\n");
> + kfree(pxa_unit);
> + return;
> + }
> +
> + mmp_clk_init(np, &pxa_unit->unit, APBC_NR_CLKS);
> +
> + pxa1908_apb_periph_clk_init(pxa_unit);
> +}
> +CLK_OF_DECLARE(pxa1908_apbc, "marvell,pxa1908-apbc", pxa1908_apbc_clk_init);
Is there a reason this file can't be a platform driver?
Re: [PATCH v9 4/9] dt-bindings: clock: Add Marvell PXA1908 clock bindings
Quoting Duje Mihanović (2024-04-02 13:55:40) > Add dt bindings and documentation for the Marvell PXA1908 clock > controller. > > Reviewed-by: Conor Dooley > Signed-off-by: Duje Mihanović > --- Reviewed-by: Stephen Boyd
Re: [PATCH v9 1/9] clk: mmp: Switch to use struct u32_fract instead of custom one
Quoting Duje Mihanović (2024-04-02 13:55:37) > From: Andy Shevchenko > > The struct mmp_clk_factor_tbl repeats the generic struct u32_fract. > Kill the custom one and use the generic one instead. > > Signed-off-by: Andy Shevchenko > Tested-by: Duje Mihanović > Reviewed-by: Linus Walleij > Signed-off-by: Duje Mihanović > --- Reviewed-by: Stephen Boyd > > diff --git a/drivers/clk/mmp/clk.h b/drivers/clk/mmp/clk.h > index 55ac05379781..c83cec169ddc 100644 > --- a/drivers/clk/mmp/clk.h > +++ b/drivers/clk/mmp/clk.h > @@ -3,6 +3,7 @@ > #define __MACH_MMP_CLK_H > > #include > +#include > #include > #include > This clkdev include should be dropped in another patch.
Re: [PATCH 1/3] dt-bindings: clock: keystone: remove unstable remark
Quoting Krzysztof Kozlowski (2024-02-24 01:12:34)
> Keystone clock controller bindings were marked as work-in-progress /
> unstable in 2013 in commit b9e0d40c0d83 ("clk: keystone: add Keystone
> PLL clock driver") and commit 7affe5685c96 ("clk: keystone: Add gate
> control clock driver") Almost eleven years is enough, so drop the
> "unstable" remark and expect usual ABI rules.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
Acked-by: Stephen Boyd
Re: [PATCH 2/3] dt-bindings: clock: ti: remove unstable remark
+Tony
Quoting Krzysztof Kozlowski (2024-02-24 01:12:35)
> Several TI SoC clock bindings were marked as work-in-progress / unstable
> between 2013-2016, for example in commit f60b1ea5ea7a ("CLK: TI: add
> support for gate clock"). It was enough of time to consider them stable
> and expect usual ABI rules.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
Acked-by: Stephen Boyd
> Documentation/devicetree/bindings/clock/ti/adpll.txt| 2 --
> Documentation/devicetree/bindings/clock/ti/apll.txt | 2 --
> Documentation/devicetree/bindings/clock/ti/autoidle.txt | 2 --
> Documentation/devicetree/bindings/clock/ti/clockdomain.txt | 2 --
> Documentation/devicetree/bindings/clock/ti/composite.txt| 2 --
> Documentation/devicetree/bindings/clock/ti/divider.txt | 2 --
> Documentation/devicetree/bindings/clock/ti/dpll.txt | 2 --
> Documentation/devicetree/bindings/clock/ti/fapll.txt| 2 --
> .../devicetree/bindings/clock/ti/fixed-factor-clock.txt | 2 --
> Documentation/devicetree/bindings/clock/ti/gate.txt | 2 --
> Documentation/devicetree/bindings/clock/ti/interface.txt| 2 --
> Documentation/devicetree/bindings/clock/ti/mux.txt | 2 --
> 12 files changed, 24 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/ti/adpll.txt
> b/Documentation/devicetree/bindings/clock/ti/adpll.txt
> index 4c8a2ce2cd70..3122360adcf3 100644
> --- a/Documentation/devicetree/bindings/clock/ti/adpll.txt
> +++ b/Documentation/devicetree/bindings/clock/ti/adpll.txt
> @@ -1,7 +1,5 @@
> Binding for Texas Instruments ADPLL clock.
>
> -Binding status: Unstable - ABI compatibility may be broken in the future
> -
> This binding uses the common clock binding[1]. It assumes a
> register-mapped ADPLL with two to three selectable input clocks
> and three to four children.
> diff --git a/Documentation/devicetree/bindings/clock/ti/apll.txt
> b/Documentation/devicetree/bindings/clock/ti/apll.txt
> index ade4dd4c30f0..bbd505c1199d 100644
> --- a/Documentation/devicetree/bindings/clock/ti/apll.txt
> +++ b/Documentation/devicetree/bindings/clock/ti/apll.txt
> @@ -1,7 +1,5 @@
> Binding for Texas Instruments APLL clock.
>
> -Binding status: Unstable - ABI compatibility may be broken in the future
> -
> This binding uses the common clock binding[1]. It assumes a
> register-mapped APLL with usually two selectable input clocks
> (reference clock and bypass clock), with analog phase locked
> diff --git a/Documentation/devicetree/bindings/clock/ti/autoidle.txt
> b/Documentation/devicetree/bindings/clock/ti/autoidle.txt
> index 7c735dde9fe9..05645a10a9e3 100644
> --- a/Documentation/devicetree/bindings/clock/ti/autoidle.txt
> +++ b/Documentation/devicetree/bindings/clock/ti/autoidle.txt
> @@ -1,7 +1,5 @@
> Binding for Texas Instruments autoidle clock.
>
> -Binding status: Unstable - ABI compatibility may be broken in the future
> -
> This binding uses the common clock binding[1]. It assumes a register mapped
> clock which can be put to idle automatically by hardware based on the usage
> and a configuration bit setting. Autoidle clock is never an individual
> diff --git a/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
> b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
> index 9c6199249ce5..edf0b5d42768 100644
> --- a/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
> +++ b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
> @@ -1,7 +1,5 @@
> Binding for Texas Instruments clockdomain.
>
> -Binding status: Unstable - ABI compatibility may be broken in the future
> -
> This binding uses the common clock binding[1] in consumer role.
> Every clock on TI SoC belongs to one clockdomain, but software
> only needs this information for specific clocks which require
> diff --git a/Documentation/devicetree/bindings/clock/ti/composite.txt
> b/Documentation/devicetree/bindings/clock/ti/composite.txt
> index 33ac7c9ad053..6f7e1331b546 100644
> --- a/Documentation/devicetree/bindings/clock/ti/composite.txt
> +++ b/Documentation/devicetree/bindings/clock/ti/composite.txt
> @@ -1,7 +1,5 @@
> Binding for TI composite clock.
>
> -Binding status: Unstable - ABI compatibility may be broken in the future
> -
> This binding uses the common clock binding[1]. It assumes a
> register-mapped composite clock with multiple different sub-types;
>
> diff --git a/Documentation/devicetree/bindings/clock/ti/divider.txt
> b/Documentation/devicetree/bindings/clock/ti/divider.txt
> index 9b13b32974f9..4d7c76f0b356 100644
> --- a/Documentation/devicetree/bindings/clock/ti/divider.txt
> +++ b/Documentat
Re: [PATCH v5 4/4] vduse: Add LSM hook to check Virtio device type
On Mon, Dec 18, 2023 at 12:21 PM Stephen Smalley wrote: > > On Tue, Dec 12, 2023 at 8:17 AM Maxime Coquelin > wrote: > > > > This patch introduces a LSM hook for devices creation, > > destruction (ioctl()) and opening (open()) operations, > > checking the application is allowed to perform these > > operations for the Virtio device type. > > Can you explain why the existing LSM hooks and SELinux implementation > are not sufficient? We already control the ability to open device > nodes via selinux_inode_permission() and selinux_file_open(), and can > support fine-grained per-cmd ioctl checking via selinux_file_ioctl(). > And it should already be possible to label these nodes distinctly > through existing mechanisms (file_contexts if udev-created/labeled, > genfs_contexts if kernel-created). What exactly can't you do today > that this hook enables? (added Ondrej to the distribution; IMHO we should swap him into MAINTAINERS in place of Eric Paris since Eric has long-since moved on from SELinux and Ondrej serves in that capacity these days) Other items to consider: - If vduse devices are created using anonymous inodes, then SELinux grew a general facility for labeling and controlling the creation of those via selinux_inode_init_security_anon(). - You can encode information about the device into its SELinux type that then allows you to distinguish things like net vs block based on the device's SELinux security context rather than encoding that in the permission bits. - If you truly need new LSM hooks (which you need to prove first), then you should pass some usable information about the object in question to allow SELinux to find a security context for it. Like an inode associated with the device, for example.
Re: [PATCH v5 4/4] vduse: Add LSM hook to check Virtio device type
On Tue, Dec 12, 2023 at 8:17 AM Maxime Coquelin wrote: > > This patch introduces a LSM hook for devices creation, > destruction (ioctl()) and opening (open()) operations, > checking the application is allowed to perform these > operations for the Virtio device type. Can you explain why the existing LSM hooks and SELinux implementation are not sufficient? We already control the ability to open device nodes via selinux_inode_permission() and selinux_file_open(), and can support fine-grained per-cmd ioctl checking via selinux_file_ioctl(). And it should already be possible to label these nodes distinctly through existing mechanisms (file_contexts if udev-created/labeled, genfs_contexts if kernel-created). What exactly can't you do today that this hook enables?
Re: [PATCH] dt-bindings: correct white-spaces in examples
Quoting Krzysztof Kozlowski (2023-11-24 01:21:21) > Use only one and exactly one space around '=' in DTS example. > > Signed-off-by: Krzysztof Kozlowski > > --- Acked-by: Stephen Boyd
Re: [PATCH 01/10] appletalk: remove localtalk and ppp support
On Mon, 9 Oct 2023 18:49:43 +0200 Rodolfo Zitellini wrote: > Hi! > I’ve been working on a new LocalTalk interface driver for the last couple > months, do you think it would be possible to at least postpone the removal of > LT a bit? > > It is a driver for an open source device called TashTalk > (https://github.com/lampmerchant/tashtalk), which runs on a PIC micro that > does all the LT interfacing, and communicates back via serial to the host > system. My driver is relatively simple and works very well with netatalk 2.2 > (which is still maintained and still has support for AppleTalk). The driver > is basically complete and trsted and I was preparing to submit a patch. > > Still having LocalTalk in my view has many advantages for us enthusiasts that > still want to bridge old machines to the current world without modifications, > for example for printing on modern printers, netbooting, sharing files and > even tcp/ip. All this basically works out of the box via the driver, Linux > and available userspace tools (netatalk, macipgw). > > The old ISA cards supported by COPS were basically unobtanium even 20 years > ago, but the solution of using a PIC and a serial port is very robust and > much more furure-proof. We also already have a device that can interface a > modern machine directly via USB to LocalTalk. > > The development of the TashTalk has been also extensively discussed on thr > 68KMLA forum > (https://68kmla.org/bb/index.php?threads/modtashtalk-lt0-driver-for-linux.45031/) > > I hope the decision to remove LocalTalk can be reconsidered at least for the > time being so there is a chance to submit a new, modern device making use of > this stack. > > Many Thanks, > Rodolfo Zitellini Does it really need it to be a kernel protocol stack? What about doing it in userspace or with BPF?
Re: [PATCH v5 0/6] Fix some bugs related to ramp and dax
Hi Andrew, On Thu, 31 Mar 2022 15:36:04 -0700 Andrew Morton wrote: > > Thanks. I'll drop > > mm-rmap-fix-cache-flush-on-thp-pages.patch > dax-fix-cache-flush-on-pmd-mapped-pages.patch > mm-rmap-introduce-pfn_mkclean_range-to-cleans-ptes.patch > mm-rmap-introduce-pfn_mkclean_range-to-cleans-ptes-fix.patch > mm-pvmw-add-support-for-walking-devmap-pages.patch > dax-fix-missing-writeprotect-the-pte-entry.patch > dax-fix-missing-writeprotect-the-pte-entry-v6.patch > mm-simplify-follow_invalidate_pte.patch I have removed those and the 4 patches that I had to revert yesterday. -- Cheers, Stephen Rothwell pgp0GZT9jLG1O.pgp Description: OpenPGP digital signature
Re: [PATCH v3 3/3] drm/msm/dp: check main link status before start aux read
Quoting Kuogee Hsieh (2021-04-16 10:38:51)
> Maybe when the cable is disconnected the DP phy should be shutdown and
> some bit in the phy could effectively "cut off" the aux channel and then
> NAKs would start coming through here in the DP controller I/O register
> space. This patch have DP aux channel read/write to return NAK immediately
> if DP controller connection status is in unplugged state.
>
> Changes in V3:
> -- check core_initialized before handle irq_hpd
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/gpu/drm/msm/dp/dp_aux.c | 5 +
> drivers/gpu/drm/msm/dp/dp_display.c | 14 ++
> drivers/gpu/drm/msm/dp/dp_link.c| 20 +++-
> 3 files changed, 30 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
> index 7c22bfe..fae3806 100644
> --- a/drivers/gpu/drm/msm/dp/dp_aux.c
> +++ b/drivers/gpu/drm/msm/dp/dp_aux.c
> @@ -343,6 +343,11 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
>
> mutex_lock(&aux->mutex);
>
> + if (!dp_catalog_link_is_connected(aux->catalog)) {
> + ret = -ETIMEDOUT;
> + goto unlock_exit;
> + }
> +
This still makes me concerned. Any possibility to not do this and have
the phy cut the connection off and have this transfer timeout
immediately?
> aux->native = msg->request & (DP_AUX_NATIVE_WRITE &
> DP_AUX_NATIVE_READ);
>
> /* Ignore address only message */
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 1784e11..db3f45e 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -571,7 +571,7 @@ static int dp_hpd_plug_handle(struct dp_display_private
> *dp, u32 data)
> dp->hpd_state = ST_DISCONNECTED;
>
> if (ret == -ECONNRESET) { /* cable unplugged */
> - dp->core_initialized = false;
> + DRM_ERROR("dongle unplugged = %d\n", ret);
Is this a debug message?
> }
>
> } else {
> @@ -711,9 +711,15 @@ static int dp_irq_hpd_handle(struct dp_display_private
> *dp, u32 data)
> return 0;
> }
>
> - ret = dp_display_usbpd_attention_cb(&dp->pdev->dev);
> - if (ret == -ECONNRESET) { /* cable unplugged */
> - dp->core_initialized = false;
> + /*
> +* dp core (ahb/aux clks) must be initialized before
> +* irq_hpd be handled
> +*/
> + if (dp->core_initialized) {
> + ret = dp_display_usbpd_attention_cb(&dp->pdev->dev);
> + if (ret == -ECONNRESET) { /* cable unplugged */
> + DRM_ERROR("dongle unplugged = %d\n", ret);
Another debug message?
> + }
> }
>
> mutex_unlock(&dp->event_mutex);
> diff --git a/drivers/gpu/drm/msm/dp/dp_link.c
> b/drivers/gpu/drm/msm/dp/dp_link.c
> index be986da..53ecae6 100644
> --- a/drivers/gpu/drm/msm/dp/dp_link.c
> +++ b/drivers/gpu/drm/msm/dp/dp_link.c
> @@ -737,18 +737,25 @@ static int dp_link_parse_sink_count(struct dp_link
> *dp_link)
> return 0;
> }
>
> -static void dp_link_parse_sink_status_field(struct dp_link_private *link)
> +static int dp_link_parse_sink_status_field(struct dp_link_private *link)
> {
> int len = 0;
>
> link->prev_sink_count = link->dp_link.sink_count;
> - dp_link_parse_sink_count(&link->dp_link);
> + len = dp_link_parse_sink_count(&link->dp_link);
> + if (len < 0) {
> + DRM_ERROR("DP parse sink count failed\n");
> + return len;
> + }
>
> len = drm_dp_dpcd_read_link_status(link->aux,
> link->link_status);
> - if (len < DP_LINK_STATUS_SIZE)
> + if (len < DP_LINK_STATUS_SIZE) {
> DRM_ERROR("DP link status read failed\n");
> - dp_link_parse_request(link);
> + return len;
> + }
> +
> + return dp_link_parse_request(link);
> }
>
> /**
> @@ -1032,7 +1039,10 @@ int dp_link_process_request(struct dp_link *dp_link)
>
> dp_link_reset_data(link);
>
> - dp_link_parse_sink_status_field(link);
> + ret = dp_link_parse_sink_status_field(link);
> + if (ret) {
> + return ret;
> + }
>
> if (link->request.test_requested == DP_TEST_LINK_EDID_READ) {
> dp_link->sink_request |= DP_TEST_LINK_EDID_READ;
> --
Can you split this part off into another patch? It seems to stand on its
own as it makes the code more robust to transfer errors in the sink
parsing code.
Re: [PATCH 1/2] drm/msm/dp: service only one irq_hpd if there are multiple irq_hpd pending
Quoting Kuogee Hsieh (2021-04-16 13:27:57)
> Some dongle may generate more than one irq_hpd events in a short period of
> time. This patch will treat those irq_hpd events as single one and service
> only one irq_hpd event.
Why is it bad to get multiple irq_hpd events in a short period of time?
Please tell us here in the commit text.
>
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/gpu/drm/msm/dp/dp_display.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 5a39da6..0a7d383 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -707,6 +707,9 @@ static int dp_irq_hpd_handle(struct dp_display_private
> *dp, u32 data)
> return 0;
> }
>
> + /* only handle first irq_hpd in case of multiple irs_hpd pending */
> + dp_del_event(dp, EV_IRQ_HPD_INT);
> +
> ret = dp_display_usbpd_attention_cb(&dp->pdev->dev);
> if (ret == -ECONNRESET) { /* cable unplugged */
> dp->core_initialized = false;
> @@ -1300,6 +1303,9 @@ static int dp_pm_suspend(struct device *dev)
> /* host_init will be called at pm_resume */
> dp->core_initialized = false;
>
> + /* system suspended, delete pending irq_hdps */
> + dp_del_event(dp, EV_IRQ_HPD_INT);
What happens if I suspend my device and when this function is running I
toggle my monitor to use the HDMI input that is connected instead of some
other input, maybe the second HDMI input? Wouldn't that generate an HPD
interrupt to grab the attention of this device?
> +
> mutex_unlock(&dp->event_mutex);
>
> return 0;
> @@ -1496,6 +1502,9 @@ int msm_dp_display_disable(struct msm_dp *dp, struct
> drm_encoder *encoder)
> /* stop sentinel checking */
> dp_del_event(dp_display, EV_DISCONNECT_PENDING_TIMEOUT);
>
> + /* link is down, delete pending irq_hdps */
> + dp_del_event(dp_display, EV_IRQ_HPD_INT);
> +
I'm becoming convinced that the whole kthread design and event queue is
broken. These sorts of patches are working around the larger problem
that the kthread is running independently of the driver and irqs can
come in at any time but the event queue is not checked from the irq
handler to debounce the irq event. Is the event queue necessary at all?
I wonder if it would be simpler to just use an irq thread and process
the hpd signal from there. Then we're guaranteed to not get an irq again
until the irq thread is done processing the event. This would naturally
debounce the irq hpd event that way.
> dp_display_disable(dp_display, 0);
>
> rc = dp_display_unprepare(dp);
[PATCH v5 13/13] kdump: Use vmlinux_build_id to simplify
We can use the vmlinux_build_id array here now instead of open coding
it. This mostly consolidates code.
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Cc: Dave Young
Cc: Baoquan He
Cc: Vivek Goyal
Cc:
Signed-off-by: Stephen Boyd
---
include/linux/crash_core.h | 12 -
kernel/crash_core.c| 50 ++
2 files changed, 8 insertions(+), 54 deletions(-)
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index 206bde8308b2..de62a722431e 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -38,8 +38,12 @@ phys_addr_t paddr_vmcoreinfo_note(void);
#define VMCOREINFO_OSRELEASE(value) \
vmcoreinfo_append_str("OSRELEASE=%s\n", value)
-#define VMCOREINFO_BUILD_ID(value) \
- vmcoreinfo_append_str("BUILD-ID=%s\n", value)
+#define VMCOREINFO_BUILD_ID() \
+ ({ \
+ static_assert(sizeof(vmlinux_build_id) == 20); \
+ vmcoreinfo_append_str("BUILD-ID=%20phN\n", vmlinux_build_id); \
+ })
+
#define VMCOREINFO_PAGESIZE(value) \
vmcoreinfo_append_str("PAGESIZE=%ld\n", value)
#define VMCOREINFO_SYMBOL(name) \
@@ -69,10 +73,6 @@ extern unsigned char *vmcoreinfo_data;
extern size_t vmcoreinfo_size;
extern u32 *vmcoreinfo_note;
-/* raw contents of kernel .notes section */
-extern const void __start_notes __weak;
-extern const void __stop_notes __weak;
-
Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
void *data, size_t data_len);
void final_note(Elf_Word *buf);
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 825284baaf46..29cc15398ee4 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -4,6 +4,7 @@
* Copyright (C) 2002-2004 Eric Biederman
*/
+#include
#include
#include
#include
@@ -378,53 +379,6 @@ phys_addr_t __weak paddr_vmcoreinfo_note(void)
}
EXPORT_SYMBOL(paddr_vmcoreinfo_note);
-#define NOTES_SIZE (&__stop_notes - &__start_notes)
-#define BUILD_ID_MAX SHA1_DIGEST_SIZE
-#define NT_GNU_BUILD_ID 3
-
-struct elf_note_section {
- struct elf_note n_hdr;
- u8 n_data[];
-};
-
-/*
- * Add build ID from .notes section as generated by the GNU ld(1)
- * or LLVM lld(1) --build-id option.
- */
-static void add_build_id_vmcoreinfo(void)
-{
- char build_id[BUILD_ID_MAX * 2 + 1];
- int n_remain = NOTES_SIZE;
-
- while (n_remain >= sizeof(struct elf_note)) {
- const struct elf_note_section *note_sec =
- &__start_notes + NOTES_SIZE - n_remain;
- const u32 n_namesz = note_sec->n_hdr.n_namesz;
-
- if (note_sec->n_hdr.n_type == NT_GNU_BUILD_ID &&
- n_namesz != 0 &&
- !strcmp((char *)¬e_sec->n_data[0], "GNU")) {
- if (note_sec->n_hdr.n_descsz <= BUILD_ID_MAX) {
- const u32 n_descsz = note_sec->n_hdr.n_descsz;
- const u8 *s = ¬e_sec->n_data[n_namesz];
-
- s = PTR_ALIGN(s, 4);
- bin2hex(build_id, s, n_descsz);
- build_id[2 * n_descsz] = '\0';
- VMCOREINFO_BUILD_ID(build_id);
- return;
- }
- pr_warn("Build ID is too large to include in
vmcoreinfo: %u > %u\n",
- note_sec->n_hdr.n_descsz,
- BUILD_ID_MAX);
- return;
- }
- n_remain -= sizeof(struct elf_note) +
- ALIGN(note_sec->n_hdr.n_namesz, 4) +
- ALIGN(note_sec->n_hdr.n_descsz, 4);
- }
-}
-
static int __init crash_save_vmcoreinfo_init(void)
{
vmcoreinfo_data = (unsigned char *)get_zeroed_page(GFP_KERNEL);
@@ -443,7 +397,7 @@ static int __init crash_save_vmcoreinfo_init(void)
}
VMCOREINFO_OSRELEASE(init_uts_ns.name.release);
- add_build_id_vmcoreinfo();
+ VMCOREINFO_BUILD_ID();
VMCOREINFO_PAGESIZE(PAGE_SIZE);
VMCOREINFO_SYMBOL(init_uts_ns);
--
https://chromeos.dev
[PATCH v5 09/13] scripts/decode_stacktrace.sh: Silence stderr messages from addr2line/nm
Sometimes if you're using tools that have linked things improperly or
have new features/sections that older tools don't expect you'll see
warnings printed to stderr. We don't really care about these warnings,
so let's just silence these messages to cleanup output of this script.
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Cc: Konstantin Khlebnikov
Cc: Sasha Levin
Signed-off-by: Stephen Boyd
---
scripts/decode_stacktrace.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/decode_stacktrace.sh b/scripts/decode_stacktrace.sh
index ca21f8bdf5f2..20b5af1ebe5e 100755
--- a/scripts/decode_stacktrace.sh
+++ b/scripts/decode_stacktrace.sh
@@ -74,7 +74,7 @@ find_module() {
find_module && return
if [[ $release == "" ]] ; then
- release=$(gdb -ex 'print init_uts_ns.name.release' -ex 'quit'
-quiet -batch "$vmlinux" | sed -n 's/\$1 = "\(.*\)".*/\1/p')
+ release=$(gdb -ex 'print init_uts_ns.name.release' -ex 'quit'
-quiet -batch "$vmlinux" 2>/dev/null | sed -n 's/\$1 = "\(.*\)".*/\1/p')
fi
for dn in {/usr/lib/debug,}/lib/modules/$release ; do
@@ -128,7 +128,7 @@ parse_symbol() {
if [[ "${cache[$module,$name]+isset}" == "isset" ]]; then
local base_addr=${cache[$module,$name]}
else
- local base_addr=$(nm "$objfile" | awk '$3 == "'$name'" && ($2
== "t" || $2 == "T") {print $1; exit}')
+ local base_addr=$(nm "$objfile" 2>/dev/null | awk '$3 ==
"'$name'" && ($2 == "t" || $2 == "T") {print $1; exit}')
if [[ $base_addr == "" ]] ; then
# address not found
return
@@ -152,7 +152,7 @@ parse_symbol() {
if [[ "${cache[$module,$address]+isset}" == "isset" ]]; then
local code=${cache[$module,$address]}
else
- local code=$(${CROSS_COMPILE}addr2line -i -e "$objfile"
"$address")
+ local code=$(${CROSS_COMPILE}addr2line -i -e "$objfile"
"$address" 2>/dev/null)
cache[$module,$address]=$code
fi
--
https://chromeos.dev
[PATCH v5 12/13] buildid: Fix kernel-doc notation
Kernel doc should use "Return:" instead of "Returns" to properly reflect the return values. Cc: Jiri Olsa Cc: Alexei Starovoitov Cc: Jessica Yu Cc: Evan Green Cc: Hsin-Yi Wang Signed-off-by: Stephen Boyd --- lib/buildid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/buildid.c b/lib/buildid.c index a7edab4914e6..dfc62625cae4 100644 --- a/lib/buildid.c +++ b/lib/buildid.c @@ -121,7 +121,7 @@ static int get_build_id_64(const void *page_addr, unsigned char *build_id, * @build_id: buffer to store build id, at least BUILD_ID_SIZE long * @size: returns actual build id size in case of success * - * Returns 0 on success, otherwise error (< 0). + * Return: 0 on success, -EINVAL otherwise */ int build_id_parse(struct vm_area_struct *vma, unsigned char *build_id, __u32 *size) -- https://chromeos.dev
[PATCH v5 10/13] scripts/decode_stacktrace.sh: Indicate 'auto' can be used for base path
Add "auto" to the usage message so that it's a little clearer that you
can pass "auto" as the second argument. When passing "auto" the script
tries to find the base path automatically instead of requiring it be
passed on the commandline. Also use [] to indicate the
variable argument and that it is optional so that we can differentiate
from the literal "auto" that should be passed.
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Cc: Konstantin Khlebnikov
Cc: Sasha Levin
Signed-off-by: Stephen Boyd
---
scripts/decode_stacktrace.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/decode_stacktrace.sh b/scripts/decode_stacktrace.sh
index 20b5af1ebe5e..5fbad61fe490 100755
--- a/scripts/decode_stacktrace.sh
+++ b/scripts/decode_stacktrace.sh
@@ -5,7 +5,7 @@
usage() {
echo "Usage:"
- echo " $0 -r | [base path] [modules path]"
+ echo " $0 -r | [|auto] []"
}
if [[ $1 == "-r" ]] ; then
--
https://chromeos.dev
[PATCH v5 08/13] scripts/decode_stacktrace.sh: Support debuginfod
Now that stacktraces contain the build ID information we can update this
script to use debuginfod-find to locate the debuginfo for the vmlinux
and modules automatically. This can replace the existing code that
requires specifying a path to vmlinux or tries to find the vmlinux and
modules automatically by using the release number. Work it into the
script as a fallback option if the vmlinux isn't specified on the
commandline.
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Cc: Konstantin Khlebnikov
Cc: Sasha Levin
Cc: Petr Mladek
Cc: Steven Rostedt
Cc: Andy Shevchenko
Cc: Matthew Wilcox
Signed-off-by: Stephen Boyd
---
scripts/decode_stacktrace.sh | 81 +++-
1 file changed, 70 insertions(+), 11 deletions(-)
diff --git a/scripts/decode_stacktrace.sh b/scripts/decode_stacktrace.sh
index 90398347e366..ca21f8bdf5f2 100755
--- a/scripts/decode_stacktrace.sh
+++ b/scripts/decode_stacktrace.sh
@@ -3,11 +3,10 @@
# (c) 2014, Sasha Levin
#set -x
-if [[ $# < 1 ]]; then
+usage() {
echo "Usage:"
echo " $0 -r | [base path] [modules path]"
- exit 1
-fi
+}
if [[ $1 == "-r" ]] ; then
vmlinux=""
@@ -24,6 +23,7 @@ if [[ $1 == "-r" ]] ; then
if [[ $vmlinux == "" ]] ; then
echo "ERROR! vmlinux image for release $release is not found"
>&2
+ usage
exit 2
fi
else
@@ -31,12 +31,35 @@ else
basepath=${2-auto}
modpath=$3
release=""
+ debuginfod=
+
+ # Can we use debuginfod-find?
+ if type debuginfod-find >/dev/null 2>&1 ; then
+ debuginfod=${1-only}
+ fi
+
+ if [[ $vmlinux == "" && -z $debuginfod ]] ; then
+ echo "ERROR! vmlinux image must be specified" >&2
+ usage
+ exit 1
+ fi
fi
declare -A cache
declare -A modcache
find_module() {
+ if [[ -n $debuginfod ]] ; then
+ if [[ -n $modbuildid ]] ; then
+ debuginfod-find debuginfo $modbuildid && return
+ fi
+
+ # Only using debuginfod so don't try to find vmlinux module path
+ if [[ $debuginfod == "only" ]] ; then
+ return
+ fi
+ fi
+
if [[ "$modpath" != "" ]] ; then
for fn in $(find "$modpath" -name "${module//_/[-_]}.ko*") ; do
if readelf -WS "$fn" | grep -qwF .debug_line ; then
@@ -150,6 +173,27 @@ parse_symbol() {
symbol="$segment$name ($code)"
}
+debuginfod_get_vmlinux() {
+ local vmlinux_buildid=${1##* }
+
+ if [[ $vmlinux != "" ]]; then
+ return
+ fi
+
+ if [[ $vmlinux_buildid =~ ^[0-9a-f]+ ]]; then
+ vmlinux=$(debuginfod-find debuginfo $vmlinux_buildid)
+ if [[ $? -ne 0 ]] ; then
+ echo "ERROR! vmlinux image not found via
debuginfod-find" >&2
+ usage
+ exit 2
+ fi
+ return
+ fi
+ echo "ERROR! Build ID for vmlinux not found. Try passing -r or
specifying vmlinux" >&2
+ usage
+ exit 2
+}
+
decode_code() {
local scripts=`dirname "${BASH_SOURCE[0]}"`
@@ -157,6 +201,14 @@ decode_code() {
}
handle_line() {
+ if [[ $basepath == "auto" && $vmlinux != "" ]] ; then
+ module=""
+ symbol="kernel_init+0x0/0x0"
+ parse_symbol
+ basepath=${symbol#kernel_init (}
+ basepath=${basepath%/init/main.c:*)}
+ fi
+
local words
# Tokenize
@@ -182,16 +234,28 @@ handle_line() {
fi
done
+ if [[ ${words[$last]} =~ ^[0-9a-f]+\] ]]; then
+ words[$last-1]="${words[$last-1]} ${words[$last]}"
+ unset words[$last]
+ last=$(( $last - 1 ))
+ fi
+
if [[ ${words[$last]} =~ \[([^]]+)\] ]]; then
module=${words[$last]}
module=${module#\[}
module=${module%\]}
+ modbuildid=${module#* }
+ module=${module% *}
+ if [[ $modbuildid == $module ]]; then
+ modbuildid=
+ fi
symbol=${words[$last-1]}
unset words[$last-1]
else
# The symbol is the last element, process it
symbol=${words[$last]}
module=
+ modbuildid=
fi
unset words[$last]
@@ -201,14 +265,6 @@ handle_line() {
echo &
[PATCH v5 11/13] buildid: Mark some arguments const
These arguments are never modified so they can be marked const to
indicate as such.
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Signed-off-by: Stephen Boyd
---
lib/buildid.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/buildid.c b/lib/buildid.c
index 530dbd1f6bbe..a7edab4914e6 100644
--- a/lib/buildid.c
+++ b/lib/buildid.c
@@ -48,10 +48,10 @@ static int parse_build_id_buf(unsigned char *build_id,
return -EINVAL;
}
-static inline int parse_build_id(void *page_addr,
+static inline int parse_build_id(const void *page_addr,
unsigned char *build_id,
__u32 *size,
-void *note_start,
+const void *note_start,
Elf32_Word note_size)
{
/* check for overflow */
@@ -66,7 +66,7 @@ static inline int parse_build_id(void *page_addr,
}
/* Parse build ID from 32-bit ELF */
-static int get_build_id_32(void *page_addr, unsigned char *build_id,
+static int get_build_id_32(const void *page_addr, unsigned char *build_id,
__u32 *size)
{
Elf32_Ehdr *ehdr = (Elf32_Ehdr *)page_addr;
@@ -91,7 +91,7 @@ static int get_build_id_32(void *page_addr, unsigned char
*build_id,
}
/* Parse build ID from 64-bit ELF */
-static int get_build_id_64(void *page_addr, unsigned char *build_id,
+static int get_build_id_64(const void *page_addr, unsigned char *build_id,
__u32 *size)
{
Elf64_Ehdr *ehdr = (Elf64_Ehdr *)page_addr;
--
https://chromeos.dev
[PATCH v5 07/13] x86/dumpstack: Use %pSb/%pBb for backtrace printing
Let's use the new printk formats to print the stacktrace entries when
printing a backtrace to the kernel logs. This will include any module's
build ID[1] in it so that offline/crash debugging can easily locate the
debuginfo for a module via something like debuginfod[2].
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc:
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Cc: Petr Mladek
Cc: Steven Rostedt
Cc: Andy Shevchenko
Cc: Matthew Wilcox
Link: https://fedoraproject.org/wiki/Releases/FeatureBuildId [1]
Link: https://sourceware.org/elfutils/Debuginfod.html [2]
Signed-off-by: Stephen Boyd
---
arch/x86/kernel/dumpstack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 299c20f0a38b..ea4fe192189d 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -69,7 +69,7 @@ static void printk_stack_address(unsigned long address, int
reliable,
const char *log_lvl)
{
touch_nmi_watchdog();
- printk("%s %s%pB\n", log_lvl, reliable ? "" : "? ", (void *)address);
+ printk("%s %s%pBb\n", log_lvl, reliable ? "" : "? ", (void *)address);
}
static int copy_code(struct pt_regs *regs, u8 *buf, unsigned long src,
--
https://chromeos.dev
[PATCH v5 05/13] module: Add printk formats to add module build ID to stacktraces
Let's make kernel stacktraces easier to identify by including the build ID[1] of a module if the stacktrace is printing a symbol from a module. This makes it simpler for developers to locate a kernel module's full debuginfo for a particular stacktrace. Combined with scripts/decode_stracktrace.sh, a developer can download the matching debuginfo from a debuginfod[2] server and find the exact file and line number for the functions plus offsets in a stacktrace that match the module. This is especially useful for pstore crash debugging where the kernel crashes are recorded in something like console-ramoops and the recovery kernel/modules are different or the debuginfo doesn't exist on the device due to space concerns (the debuginfo can be too large for space limited devices). Originally, I put this on the %pS format, but that was quickly rejected given that %pS is used in other places such as ftrace where build IDs aren't meaningful. There was some discussions on the list to put every module build ID into the "Modules linked in:" section of the stacktrace message but that quickly becomes very hard to read once you have more than three or four modules linked in. It also provides too much information when we don't expect each module to be traversed in a stacktrace. Having the build ID for modules that aren't important just makes things messy. Splitting it to multiple lines for each module quickly explodes the number of lines printed in an oops too, possibly wrapping the warning off the console. And finally, trying to stash away each module used in a callstack to provide the ID of each symbol printed is cumbersome and would require changes to each architecture to stash away modules and return their build IDs once unwinding has completed. Instead, we opt for the simpler approach of introducing new printk formats '%pS[R]b' for "pointer symbolic backtrace with module build ID" and '%pBb' for "pointer backtrace with module build ID" and then updating the few places in the architecture layer where the stacktrace is printed to use this new format. Example: WARNING: CPU: 3 PID: 3373 at drivers/misc/lkdtm/bugs.c:83 lkdtm_WARNING+0x28/0x30 [lkdtm] Modules linked in: lkdtm rfcomm algif_hash algif_skcipher af_alg xt_cgroup uinput xt_MASQUERADE hci_uart CPU: 3 PID: 3373 Comm: bash Not tainted 5.11 #12 a8c0d47f7051f3e6670ceaea724af66a39c6cec8 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) pstate: 0049 (nzcv daif +PAN -UAO -TCO BTYPE=--) pc : lkdtm_WARNING+0x28/0x30 [lkdtm] lr : lkdtm_do_action+0x24/0x40 [lkdtm] sp : ffc013febca0 x29: ffc013febca0 x28: ff88d9438040 x27: x26: x25: x24: ffdd0e9772c0 x23: 0020 x22: ffdd0e975366 x21: ffdd0e9772e0 x20: ffc013febde0 x19: 0008 x18: x17: x16: 0037 x15: ffdd102ab174 x14: 0003 x13: 0004 x12: x11: x10: x9 : 0001 x8 : ffdd0e979000 x7 : x6 : ffdd10ff6b54 x5 : x4 : x3 : ffc013feb938 x2 : ff89fef05a70 x1 : ff89feef5788 x0 : ffdd0e9772e0 Call trace: lkdtm_WARNING+0x28/0x30 [lkdtm 6c2215028606bda50de823490723dc4bc5bf46f9] direct_entry+0x16c/0x1b4 [lkdtm 6c2215028606bda50de823490723dc4bc5bf46f9] full_proxy_write+0x74/0xa4 vfs_write+0xec/0x2e8 ksys_write+0x84/0xf0 __arm64_sys_write+0x24/0x30 el0_svc_common+0xf4/0x1c0 do_el0_svc_compat+0x28/0x3c el0_svc_compat+0x10/0x1c el0_sync_compat_handler+0xa8/0xcc el0_sync_compat+0x178/0x180 ---[ end trace f89bc7f5417cbcc6 ]--- Cc: Jiri Olsa Cc: Alexei Starovoitov Cc: Jessica Yu Cc: Evan Green Cc: Hsin-Yi Wang Cc: Petr Mladek Cc: Steven Rostedt Cc: Sergey Senozhatsky Cc: Andy Shevchenko Cc: Rasmus Villemoes Cc: Cc: Matthew Wilcox Link: https://fedoraproject.org/wiki/Releases/FeatureBuildId [1] Link: https://sourceware.org/elfutils/Debuginfod.html [2] Signed-off-by: Stephen Boyd --- Documentation/core-api/printk-formats.rst | 11 +++ include/linux/kallsyms.h | 20 - include/linux/module.h| 8 +- kernel/kallsyms.c | 101 +- kernel/module.c | 31 ++- lib/vsprintf.c| 8 +- 6 files changed, 154 insertions(+), 25 deletions(-) diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index 160e710d992f..5f60533f2a56 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -114,6 +114,17 @@ used when printing stack backtraces. The specifier takes into consideration the effect of compiler optimisations which may occur when tail-calls are used and m
[PATCH v5 06/13] arm64: stacktrace: Use %pSb for backtrace printing
Let's use the new printk format to print the stacktrace entry when
printing a backtrace to the kernel logs. This will include any module's
build ID[1] in it so that offline/crash debugging can easily locate the
debuginfo for a module via something like debuginfod[2].
Cc: Catalin Marinas
Cc: Will Deacon
Cc:
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Cc: Petr Mladek
Cc: Steven Rostedt
Cc: Andy Shevchenko
Cc: Matthew Wilcox
Link: https://fedoraproject.org/wiki/Releases/FeatureBuildId [1]
Link: https://sourceware.org/elfutils/Debuginfod.html [2]
Signed-off-by: Stephen Boyd
---
arch/arm64/kernel/stacktrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index ad20981dfda4..9d38da01ff98 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -129,7 +129,7 @@ NOKPROBE_SYMBOL(walk_stackframe);
static void dump_backtrace_entry(unsigned long where, const char *loglvl)
{
- printk("%s %pS\n", loglvl, (void *)where);
+ printk("%s %pSb\n", loglvl, (void *)where);
}
void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
--
https://chromeos.dev
[PATCH v5 04/13] dump_stack: Add vmlinux build ID to stack traces
Add the running kernel's build ID[1] to the stacktrace information
header. This makes it simpler for developers to locate the vmlinux with
full debuginfo for a particular kernel stacktrace. Combined with
scripts/decode_stracktrace.sh, a developer can download the correct
vmlinux from a debuginfod[2] server and find the exact file and line
number for the functions plus offsets in a stacktrace.
This is especially useful for pstore crash debugging where the kernel
crashes are recorded in the pstore logs and the recovery kernel is
different or the debuginfo doesn't exist on the device due to space
concerns (the data can be large and a security concern). The stacktrace
can be analyzed after the crash by using the build ID to find the
matching vmlinux and understand where in the function something went
wrong.
Example stacktrace from lkdtm:
WARNING: CPU: 4 PID: 3255 at drivers/misc/lkdtm/bugs.c:83
lkdtm_WARNING+0x28/0x30 [lkdtm]
Modules linked in: lkdtm rfcomm algif_hash algif_skcipher af_alg xt_cgroup
uinput xt_MASQUERADE
CPU: 4 PID: 3255 Comm: bash Not tainted 5.11 #3
aa23f7a1231c229de205662d5a9e0d4c580f19a1
Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
pstate: 0049 (nzcv daif +PAN -UAO -TCO BTYPE=--)
pc : lkdtm_WARNING+0x28/0x30 [lkdtm]
The hex string aa23f7a1231c229de205662d5a9e0d4c580f19a1 is the build ID,
following the kernel version number. Put it all behind a config option,
STACKTRACE_BUILD_ID, so that kernel developers can remove this
information if they decide it is too much.
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Cc: Petr Mladek
Cc: Steven Rostedt
Cc: Andy Shevchenko
Cc: Matthew Wilcox
Link: https://fedoraproject.org/wiki/Releases/FeatureBuildId [1]
Link: https://sourceware.org/elfutils/Debuginfod.html [2]
Signed-off-by: Stephen Boyd
---
include/linux/buildid.h | 4
lib/Kconfig.debug | 11 +++
lib/buildid.c | 2 ++
lib/dump_stack.c| 13 +++--
4 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/include/linux/buildid.h b/include/linux/buildid.h
index f375900cf9ed..3b7a0ff4642f 100644
--- a/include/linux/buildid.h
+++ b/include/linux/buildid.h
@@ -10,7 +10,11 @@ int build_id_parse(struct vm_area_struct *vma, unsigned char
*build_id,
__u32 *size);
int build_id_parse_buf(const void *buf, unsigned char *build_id, u32 buf_size);
+#if IS_ENABLED(CONFIG_STACKTRACE_BUILD_ID) || IS_ENABLED(CONFIG_CRASH_CORE)
extern unsigned char vmlinux_build_id[BUILD_ID_SIZE_MAX];
void init_vmlinux_build_id(void);
+#else
+static inline void init_vmlinux_build_id(void) { }
+#endif
#endif
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 2779c29d9981..5f883e50f406 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -35,6 +35,17 @@ config PRINTK_CALLER
no option to enable/disable at the kernel command line parameter or
sysfs interface.
+config STACKTRACE_BUILD_ID
+ bool "Show build ID information in stacktraces"
+ depends on PRINTK
+ help
+ Selecting this option adds build ID information for symbols in
+ stacktraces printed with the printk format '%p[SR]b'.
+
+ This option is intended for distros where debuginfo is not easily
+ accessible but can be downloaded given the build ID of the vmlinux or
+ kernel module where the function is located.
+
config CONSOLE_LOGLEVEL_DEFAULT
int "Default console loglevel (1-15)"
range 1 15
diff --git a/lib/buildid.c b/lib/buildid.c
index 1103ed46214f..530dbd1f6bbe 100644
--- a/lib/buildid.c
+++ b/lib/buildid.c
@@ -174,6 +174,7 @@ int build_id_parse_buf(const void *buf, unsigned char
*build_id, u32 buf_size)
return parse_build_id_buf(build_id, NULL, buf, buf_size);
}
+#if IS_ENABLED(CONFIG_STACKTRACE_BUILD_ID) || IS_ENABLED(CONFIG_CRASH_CORE)
unsigned char vmlinux_build_id[BUILD_ID_SIZE_MAX] __ro_after_init;
/**
@@ -187,3 +188,4 @@ void __init init_vmlinux_build_id(void)
build_id_parse_buf(&__start_notes, vmlinux_build_id, size);
}
+#endif
diff --git a/lib/dump_stack.c b/lib/dump_stack.c
index f5a33b6f773f..d685331b065f 100644
--- a/lib/dump_stack.c
+++ b/lib/dump_stack.c
@@ -5,6 +5,7 @@
*/
#include
+#include
#include
#include
#include
@@ -36,6 +37,14 @@ void __init dump_stack_set_arch_desc(const char *fmt, ...)
va_end(args);
}
+#if IS_ENABLED(CONFIG_STACKTRACE_BUILD_ID)
+#define BUILD_ID_FMT " %20phN"
+#define BUILD_ID_VAL vmlinux_build_id
+#else
+#define BUILD_ID_FMT "%s"
+#define BUILD_ID_VAL ""
+#endif
+
/**
* dump_stack_print_info - print generic debug info for dump_stack()
* @log_lvl: log level
@@ -45,13 +54,13 @@ void __init dump_stack_set_arch_desc(const char *fmt, ...)
*/
void dump_stack_print_info(const char *log_lvl)
{
- printk("%sCPU: %d PID: %d Comm: %.
[PATCH v5 02/13] buildid: Add API to parse build ID out of buffer
Add an API that can parse the build ID out of a buffer, instead of a
vma, to support printing a kernel module's build ID for stack traces.
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Signed-off-by: Stephen Boyd
---
include/linux/buildid.h | 1 +
lib/buildid.c | 50 ++---
2 files changed, 38 insertions(+), 13 deletions(-)
diff --git a/include/linux/buildid.h b/include/linux/buildid.h
index 40232f90db6e..ebce93f26d06 100644
--- a/include/linux/buildid.h
+++ b/include/linux/buildid.h
@@ -8,5 +8,6 @@
int build_id_parse(struct vm_area_struct *vma, unsigned char *build_id,
__u32 *size);
+int build_id_parse_buf(const void *buf, unsigned char *build_id, u32 buf_size);
#endif
diff --git a/lib/buildid.c b/lib/buildid.c
index e014636ec3eb..6aea1c4e5e85 100644
--- a/lib/buildid.c
+++ b/lib/buildid.c
@@ -2,30 +2,23 @@
#include
#include
+#include
#include
#define BUILD_ID 3
+
/*
* Parse build id from the note segment. This logic can be shared between
* 32-bit and 64-bit system, because Elf32_Nhdr and Elf64_Nhdr are
* identical.
*/
-static inline int parse_build_id(void *page_addr,
-unsigned char *build_id,
-__u32 *size,
-void *note_start,
-Elf32_Word note_size)
+static int parse_build_id_buf(unsigned char *build_id,
+ __u32 *size,
+ const void *note_start,
+ Elf32_Word note_size)
{
Elf32_Word note_offs = 0, new_offs;
- /* check for overflow */
- if (note_start < page_addr || note_start + note_size < note_start)
- return -EINVAL;
-
- /* only supports note that fits in the first page */
- if (note_start + note_size > page_addr + PAGE_SIZE)
- return -EINVAL;
-
while (note_offs + sizeof(Elf32_Nhdr) < note_size) {
Elf32_Nhdr *nhdr = (Elf32_Nhdr *)(note_start + note_offs);
@@ -50,9 +43,27 @@ static inline int parse_build_id(void *page_addr,
break;
note_offs = new_offs;
}
+
return -EINVAL;
}
+static inline int parse_build_id(void *page_addr,
+unsigned char *build_id,
+__u32 *size,
+void *note_start,
+Elf32_Word note_size)
+{
+ /* check for overflow */
+ if (note_start < page_addr || note_start + note_size < note_start)
+ return -EINVAL;
+
+ /* only supports note that fits in the first page */
+ if (note_start + note_size > page_addr + PAGE_SIZE)
+ return -EINVAL;
+
+ return parse_build_id_buf(build_id, size, note_start, note_size);
+}
+
/* Parse build ID from 32-bit ELF */
static int get_build_id_32(void *page_addr, unsigned char *build_id,
__u32 *size)
@@ -148,3 +159,16 @@ int build_id_parse(struct vm_area_struct *vma, unsigned
char *build_id,
put_page(page);
return ret;
}
+
+/**
+ * build_id_parse_buf - Get build ID from a buffer
+ * @buf: Elf note section(s) to parse
+ * @buf_size: Size of @buf in bytes
+ * @build_id: Build ID parsed from @buf, at least BUILD_ID_SIZE_MAX long
+ *
+ * Return: 0 on success, -EINVAL otherwise
+ */
+int build_id_parse_buf(const void *buf, unsigned char *build_id, u32 buf_size)
+{
+ return parse_build_id_buf(build_id, NULL, buf, buf_size);
+}
--
https://chromeos.dev
[PATCH v5 03/13] buildid: Stash away kernels build ID on init
Parse the kernel's build ID at initialization so that other code can
print a hex format string representation of the running kernel's build
ID. This will be used in the kdump and dump_stack code so that
developers can easily locate the vmlinux debug symbols for a
crash/stacktrace.
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Cc: Dave Young
Cc: Baoquan He
Cc: Vivek Goyal
Cc:
Signed-off-by: Stephen Boyd
---
include/linux/buildid.h | 3 +++
init/main.c | 1 +
lib/buildid.c | 15 +++
3 files changed, 19 insertions(+)
diff --git a/include/linux/buildid.h b/include/linux/buildid.h
index ebce93f26d06..f375900cf9ed 100644
--- a/include/linux/buildid.h
+++ b/include/linux/buildid.h
@@ -10,4 +10,7 @@ int build_id_parse(struct vm_area_struct *vma, unsigned char
*build_id,
__u32 *size);
int build_id_parse_buf(const void *buf, unsigned char *build_id, u32 buf_size);
+extern unsigned char vmlinux_build_id[BUILD_ID_SIZE_MAX];
+void init_vmlinux_build_id(void);
+
#endif
diff --git a/init/main.c b/init/main.c
index 53b278845b88..eaede2f41327 100644
--- a/init/main.c
+++ b/init/main.c
@@ -857,6 +857,7 @@ asmlinkage __visible void __init __no_sanitize_address
start_kernel(void)
set_task_stack_end_magic(&init_task);
smp_setup_processor_id();
debug_objects_early_init();
+ init_vmlinux_build_id();
cgroup_init_early();
diff --git a/lib/buildid.c b/lib/buildid.c
index 6aea1c4e5e85..1103ed46214f 100644
--- a/lib/buildid.c
+++ b/lib/buildid.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
#include
+#include
#include
#include
#include
@@ -172,3 +173,17 @@ int build_id_parse_buf(const void *buf, unsigned char
*build_id, u32 buf_size)
{
return parse_build_id_buf(build_id, NULL, buf, buf_size);
}
+
+unsigned char vmlinux_build_id[BUILD_ID_SIZE_MAX] __ro_after_init;
+
+/**
+ * init_vmlinux_build_id - Compute and stash the running kernel's build ID
+ */
+void __init init_vmlinux_build_id(void)
+{
+ extern const void __start_notes __weak;
+ extern const void __stop_notes __weak;
+ unsigned int size = &__stop_notes - &__start_notes;
+
+ build_id_parse_buf(&__start_notes, vmlinux_build_id, size);
+}
--
https://chromeos.dev
[PATCH v5 01/13] buildid: Only consider GNU notes for build ID parsing
Some kernel elf files have various notes that also happen to have an elf
note type of '3', which matches NT_GNU_BUILD_ID but the note name isn't
"GNU". For example, this note trips up the existing logic:
Owner Data size Description
Xen0x0008 Unknown note type: (0x0003) description data: 00 00 00
ff80
Let's make sure that it is a GNU note when parsing the build ID so that
we can use this function to parse a vmlinux's build ID too.
Reported-by: Petr Mladek
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Fixes: bd7525dacd7e ("bpf: Move stack_map_get_build_id into lib")
Tested-by: Petr Mladek
Signed-off-by: Stephen Boyd
---
lib/buildid.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/buildid.c b/lib/buildid.c
index 6156997c3895..e014636ec3eb 100644
--- a/lib/buildid.c
+++ b/lib/buildid.c
@@ -31,6 +31,7 @@ static inline int parse_build_id(void *page_addr,
if (nhdr->n_type == BUILD_ID &&
nhdr->n_namesz == sizeof("GNU") &&
+ !strcmp((char *)(nhdr + 1), "GNU") &&
nhdr->n_descsz > 0 &&
nhdr->n_descsz <= BUILD_ID_SIZE_MAX) {
memcpy(build_id,
--
https://chromeos.dev
[PATCH v5 00/13] Add build ID to stacktraces
This series adds the kernel's build ID[1] to the stacktrace header printed in oops messages, warnings, etc. and the build ID for any module that appears in the stacktrace after the module name. The goal is to make the stacktrace more self-contained and descriptive by including the relevant build IDs in the kernel logs when something goes wrong. This can be used by post processing tools like script/decode_stacktrace.sh and kernel developers to easily locate the debug info associated with a kernel crash and line up what line and file things started falling apart at. To show how this can be used I've included a patch to decode_stacktrace.sh that downloads the debuginfo from a debuginfod server. This also includes some patches to make the buildid.c file use more const arguments and consolidate logic into buildid.c from kdump. These are left to the end as they were mostly cleanup patches. I don't know who exactly maintains this so I guess Andrew is the best option to merge all this code. Here's an example lkdtm stacktrace on arm64. WARNING: CPU: 4 PID: 3255 at drivers/misc/lkdtm/bugs.c:83 lkdtm_WARNING+0x28/0x30 [lkdtm] Modules linked in: lkdtm rfcomm algif_hash algif_skcipher af_alg xt_cgroup uinput xt_MASQUERADE CPU: 4 PID: 3255 Comm: bash Not tainted 5.11 #3 aa23f7a1231c229de205662d5a9e0d4c580f19a1 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) pstate: 0049 (nzcv daif +PAN -UAO -TCO BTYPE=--) pc : lkdtm_WARNING+0x28/0x30 [lkdtm] lr : lkdtm_do_action+0x24/0x40 [lkdtm] sp : ffc0134fbca0 x29: ffc0134fbca0 x28: ff92d53ba240 x27: x26: x25: x24: ffe3622352c0 x23: 0020 x22: ffe362233366 x21: ffe3622352e0 x20: ffc0134fbde0 x19: 0008 x18: x17: ff929b6536fc x16: x15: x14: 0012 x13: ffe380ed892c x12: ffe381d05068 x11: x10: x9 : 0001 x8 : ffe362237000 x7 : x6 : x5 : x4 : 0001 x3 : 0008 x2 : ff93fef25a70 x1 : ff93fef15788 x0 : ffe3622352e0 Call trace: lkdtm_WARNING+0x28/0x30 [lkdtm ed5019fdf5e53be37cb1ba7899292d7e143b259e] direct_entry+0x16c/0x1b4 [lkdtm ed5019fdf5e53be37cb1ba7899292d7e143b259e] full_proxy_write+0x74/0xa4 vfs_write+0xec/0x2e8 ksys_write+0x84/0xf0 __arm64_sys_write+0x24/0x30 el0_svc_common+0xf4/0x1c0 do_el0_svc_compat+0x28/0x3c el0_svc_compat+0x10/0x1c el0_sync_compat_handler+0xa8/0xcc el0_sync_compat+0x178/0x180 ---[ end trace 3d95032303e59e68 ]--- Changes from v4 (https://lore.kernel.org/r/20210410015300.3764485-1-swb...@chromium.org): * Stubbed out more code when CONFIG_STACKTRACE_BUILD_ID=n * Use static_assert instead of BUILD_BUG_ON() * Dropped bad printk change to IP on x86 Changes from v3 (https://lore.kernel.org/r/20210331030520.3816265-1-swb...@chromium.org): * Fixed compilation warnings due to config changes * Fixed kernel-doc on init_vmlinx_build_id() * Totally removed add_build_id_vmcoreinfo() * Added another printk format %pBb to help x86 print backtraces * Some BUILD_BUG_ON() checks to make sure the buildid doesn't get bigger or smaller Changes from v2 (https://lore.kernel.org/r/20210324020443.1815557-1-swb...@chromium.org): * Renamed symbol printing function to indicate build IDness * Put build ID information behind Kconfig knob * Build ID for vmlinux is calculated in early init instead of on demand * printk format is %pS[R]b Changes from v1 (https://lore.kernel.org/r/20210301174749.1269154-1-swb...@chromium.org): * New printk format %pSb and %pSr * Return binary format instead of hex format string from build ID APIs * Some new patches to cleanup buildid/decode_stacktrace.sh * A new patch to decode_stacktrace.sh to parse output [1] https://fedoraproject.org/wiki/Releases/FeatureBuildId Cc: Alexei Starovoitov Cc: Andy Shevchenko Cc: Baoquan He Cc: Borislav Petkov Cc: Catalin Marinas Cc: Dave Young Cc: Evan Green Cc: Hsin-Yi Wang Cc: Ingo Molnar Cc: Jessica Yu Cc: Jiri Olsa Cc: Cc: Konstantin Khlebnikov Cc: Cc: Cc: Cc: Matthew Wilcox Cc: Petr Mladek Cc: Rasmus Villemoes Cc: Sasha Levin Cc: Sergey Senozhatsky Cc: Steven Rostedt Cc: Thomas Gleixner Cc: Vivek Goyal Cc: Will Deacon Cc: Cc: Christoph Hellwig Cc: peter enderborg https://chromeos.dev
Re: [PATCH v3] arm64: vdso32: drop -no-integrated-as flag
Quoting Nick Desaulniers (2021-04-20 10:44:25) > Clang can assemble these files just fine; this is a relic from the top > level Makefile conditionally adding this. We no longer need --prefix, > --gcc-toolchain, or -Qunused-arguments flags either with this change, so > remove those too. > > To test building: > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \ > CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make LLVM=1 LLVM_IAS=1 \ > defconfig arch/arm64/kernel/vdso32/ > > Suggested-by: Nathan Chancellor > Signed-off-by: Nick Desaulniers > Reviewed-by: Nathan Chancellor > Reviewed-by: Vincenzo Frascino > --- It boots for me and compat vDSO seems to work properly per tools/testing/selftests/vDSO/, userspace programs aren't crashing right and left, must be good: Tested-by: Stephen Boyd
linux-next: Tree for Apr 20
Hi all,
Changes since 20210419:
The powerpc tree lost its build failure.
The ftrace tree gained a conflict against the bpf-next tree.
Non-merge commits (relative to Linus' tree): 12917
11294 files changed, 619161 insertions(+), 276245 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 340 trees (counting Linus' and 89 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (7af08140979a Revert "gcov: clang: fix clang-11+ build")
Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2)
Merging kbuild-current/fixes (bcbcf50f5218 kbuild: fix ld-version.sh to not be
affected by locale)
Merging arc-current/for-curr (163630b2d95b arc: Fix typos/spellos)
Merging arm-current/fixes (d2f7eca60b29 ARM: 9071/1: uprobes: Don't hook on
thumb instructions)
Merging arm64-fixes/for-next/fixes (22315a2296f4 arm64: alternatives: Move
length validation in alternative_{insn, endif})
Merging arm-soc-fixes/arm/fixes (b9a9786a13ea Merge tag
'omap-for-v5.12/fixes-rc6-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes)
Merging drivers-memory-fixes/fixes (a38fd8748464 Linux 5.12-rc2)
Merging m68k-current/for-linus (a65a802aadba m68k: Fix virt_addr_valid() W=1
compiler warnings)
Merging powerpc-fixes/fixes (791f9e36599d powerpc/vdso: Make sure
vdso_wrapper.o is rebuilt everytime vdso.so is rebuilt)
Merging s390-fixes/fixes (a994eddb947e s390/entry: save the caller of psw_idle)
Merging sparc/master (05a59d79793d Merge
git://git.kernel.org:/pub/scm/linux/kernel/git/netdev/net)
Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption
not used on new files)
Merging net/master (8d892d60941b net: ethernet: ixp4xx: Set the DMA masks
explicitly)
Merging bpf/master (b02265429681 Merge
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf)
Merging ipsec/master (88a5af943985 Merge tag 'net-5.12-rc8' of
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net)
Merging netfilter/master (88a5af943985 Merge tag 'net-5.12-rc8' of
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net)
Merging ipvs/master (ccb39c628558 Merge
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging wireless-drivers/master (e7020bb068d8 iwlwifi: Fix softirq/hardirq
disabling in iwl_pcie_gen2_enqueue_hcmd())
Merging mac80211/master (88a5af943985 Merge tag 'net-5.12-rc8' of
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net)
Merging rdma-fixes/for-rc (d434405aaab7 Linux 5.12-rc7)
Merging sound-current/for-linus (c8426b2700b5 ALSA: hda/realtek: Fix speaker
amp setup on Acer Aspire E1)
Merging sound-asoc-fixes/for-linus (d28addbcaf3f Merge remote-tracking branch
'asoc/for-5.12' into asoc-linus)
Merging regmap-fixes/for-linus (78d889705732 Merge remote-tracking branch
'regmap/for-5.12' into regmap-linus)
Merging regulator-fixes/for-linus (6068cc31dedd Merge remote-tracking branch
'regulator/for-5.12' into regulator-linus)
Merging spi-fixes/for-linus (088a84700d27 Merge remote-tracking branch
'spi/for-5.12' into spi-linus)
Merging pci-current/for-linus (cf673bd0cc97 PCI: switchtec: Fix Spectre v1
vulnerability)
Merging driver-core.current/driver-
linux-next: manual merge of the ftrace tree with the bpf-next tree
Hi all,
Today's linux-next merge of the ftrace tree got a conflict in:
kernel/trace/bpf_trace.c
between commit:
d9c9e4db186a ("bpf: Factorize bpf_trace_printk and bpf_seq_printf")
from the bpf-next tree and commit:
f2cc020d7876 ("tracing: Fix various typos in comments")
from the ftrace tree.
I fixed it up (the former removed the comment updated by the latter) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpZSIISeFaSc.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the spi tree
Hi all,
After merging the spi tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
In file included from include/linux/printk.h:409,
from include/linux/kernel.h:16,
from include/linux/clk.h:13,
from drivers/spi/spi-stm32-qspi.c:7:
drivers/spi/spi-stm32-qspi.c: In function 'stm32_qspi_dirmap_read':
drivers/spi/spi-stm32-qspi.c:481:21: warning: format '%x' expects argument of
type 'unsigned int', but argument 5 has type 'size_t' {aka 'long unsigned int'}
[-Wformat=]
481 | dev_dbg(qspi->dev, "%s len = 0x%x offs = 0x%llx buf = 0x%p\n",
__func__, len, offs, buf);
| ^~
include/linux/dynamic_debug.h:129:15: note: in definition of macro
'__dynamic_func_call'
129 | func(&id, ##__VA_ARGS__); \
| ^~~
include/linux/dynamic_debug.h:161:2: note: in expansion of macro
'_dynamic_func_call'
161 | _dynamic_func_call(fmt,__dynamic_dev_dbg, \
| ^~
include/linux/dev_printk.h:123:2: note: in expansion of macro 'dynamic_dev_dbg'
123 | dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~
include/linux/dev_printk.h:123:23: note: in expansion of macro 'dev_fmt'
123 | dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~
drivers/spi/spi-stm32-qspi.c:481:2: note: in expansion of macro 'dev_dbg'
481 | dev_dbg(qspi->dev, "%s len = 0x%x offs = 0x%llx buf = 0x%p\n",
__func__, len, offs, buf);
| ^~~
drivers/spi/spi-stm32-qspi.c:481:34: note: format string is defined here
481 | dev_dbg(qspi->dev, "%s len = 0x%x offs = 0x%llx buf = 0x%p\n",
__func__, len, offs, buf);
| ~^
| |
| unsigned int
| %lx
Introduced by commit
18674dee3cd6 ("spi: stm32-qspi: Add dirmap support")
--
Cheers,
Stephen Rothwell
pgpnXiPdMIUXz.pgp
Description: OpenPGP digital signature
Re: [PATCH v8 net-next 2/2] net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)
On Fri, 16 Apr 2021 13:11:59 -0700 Dexuan Cui wrote: > Add a VF driver for Microsoft Azure Network Adapter (MANA) that will be > available in the future. > > Co-developed-by: Haiyang Zhang > Signed-off-by: Haiyang Zhang > Co-developed-by: Shachar Raindel > Signed-off-by: Shachar Raindel > Signed-off-by: Dexuan Cui Reviewed-by: Stephen Hemminger
Re: [PATCH v8 net-next 1/2] hv_netvsc: Make netvsc/VF binding check both MAC and serial number
On Fri, 16 Apr 2021 13:11:58 -0700 Dexuan Cui wrote: > Currently the netvsc/VF binding logic only checks the PCI serial number. > > The upcoming Microsoft Azure Network Adapter (MANA) supports multiple > net_device interfaces (each such interface is called a "vPort", and has > its unique MAC address) which are backed by the same VF PCI device, so > the binding logic should check both the MAC address and the PCI serial > number. > > The change should not break any other existing VF drivers, because > Hyper-V NIC SR-IOV implementation requires the netvsc network > interface and the VF network interface have the same MAC address. > > Co-developed-by: Haiyang Zhang > Signed-off-by: Haiyang Zhang > Co-developed-by: Shachar Raindel > Signed-off-by: Shachar Raindel > Signed-off-by: Dexuan Cui Acked-by: Stephen Hemminger
linux-next: Tree for Apr 19
Hi all,
Changes since 20210416:
The powerpc tree gained a build failure for which I applied a patch.
The vfs tree gained conflicts against the f2fs and xfs trees.
Non-merge commits (relative to Linus' tree): 12643
11170 files changed, 606490 insertions(+), 274006 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 340 trees (counting Linus' and 89 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (bf05bf16c76b Linux 5.12-rc8)
Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2)
Merging kbuild-current/fixes (bcbcf50f5218 kbuild: fix ld-version.sh to not be
affected by locale)
Merging arc-current/for-curr (163630b2d95b arc: Fix typos/spellos)
Merging arm-current/fixes (d2f7eca60b29 ARM: 9071/1: uprobes: Don't hook on
thumb instructions)
Merging arm64-fixes/for-next/fixes (22315a2296f4 arm64: alternatives: Move
length validation in alternative_{insn, endif})
Merging arm-soc-fixes/arm/fixes (b9a9786a13ea Merge tag
'omap-for-v5.12/fixes-rc6-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes)
Merging drivers-memory-fixes/fixes (a38fd8748464 Linux 5.12-rc2)
Merging m68k-current/for-linus (a65a802aadba m68k: Fix virt_addr_valid() W=1
compiler warnings)
Merging powerpc-fixes/fixes (791f9e36599d powerpc/vdso: Make sure
vdso_wrapper.o is rebuilt everytime vdso.so is rebuilt)
Merging s390-fixes/fixes (a994eddb947e s390/entry: save the caller of psw_idle)
Merging sparc/master (05a59d79793d Merge
git://git.kernel.org:/pub/scm/linux/kernel/git/netdev/net)
Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption
not used on new files)
Merging net/master (88a5af943985 Merge tag 'net-5.12-rc8' of
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net)
Merging bpf/master (b02265429681 Merge
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf)
Merging ipsec/master (6628ddfec758 net: geneve: check skb is large enough for
IPv4/IPv6 header)
Merging netfilter/master (ccb39c628558 Merge
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (ccb39c628558 Merge
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging wireless-drivers/master (65db391dd874 iwlwifi: mvm: fix beacon
protection checks)
Merging mac80211/master (0e0704bb9ea0 Merge branch 'ch_tlss-fixes')
Merging rdma-fixes/for-rc (d434405aaab7 Linux 5.12-rc7)
Merging sound-current/for-linus (c8426b2700b5 ALSA: hda/realtek: Fix speaker
amp setup on Acer Aspire E1)
Merging sound-asoc-fixes/for-linus (465a19220d82 Merge remote-tracking branch
'asoc/for-5.12' into asoc-linus)
Merging regmap-fixes/for-linus (78d889705732 Merge remote-tracking branch
'regmap/for-5.12' into regmap-linus)
Merging regulator-fixes/for-linus (6068cc31dedd Merge remote-tracking branch
'regulator/for-5.12' into regulator-linus)
Merging spi-fixes/for-linus (9fa8376485bf Merge remote-tracking branch
'spi/for-5.12' into spi-linus)
Merging pci-current/for-linus (cf673bd0cc97 PCI: switchtec: Fix Spectre v1
vulnerability)
Merging driver-core.current/driver-core-linus (d434405aaab7 Linux 5.12-rc7)
Merging tty.current/tty-linus (e49d033bddf5 Linux 5.12-rc6)
Merging usb.current/us
linux-next: build failure after merge of the powerpc tree
Hi all,
After merging the powerpc tree, today's linux-next build (powerpc
allyesconfig) failed like this:
arch/powerpc/kernel/fadump.c: In function 'crash_fadump':
arch/powerpc/kernel/fadump.c:731:28: error: 'INTERRUPT_SYSTEM_RESET' undeclared
(first use in this function)
731 | if (TRAP(&(fdh->regs)) == INTERRUPT_SYSTEM_RESET) {
|^~
arch/powerpc/kernel/fadump.c:731:28: note: each undeclared identifier is
reported only once for each function it appears in
Caused by commit
7153d4bf0b37 ("powerpc/traps: Enhance readability for trap types")
I have applied the following patch for today.
From: Stephen Rothwell
Date: Mon, 19 Apr 2021 19:05:05 +1000
Subject: [PATCH] fix up for "powerpc/traps: Enhance readability for trap types"
Signed-off-by: Stephen Rothwell
---
arch/powerpc/kernel/fadump.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index b55b4c23f3b6..000e3b7f3fca 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
/*
* The CPU who acquired the lock to trigger the fadump crash should
--
2.30.2
--
Cheers,
Stephen Rothwell
pgpkGCP_0Ab4P.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the sound-asoc tree
Hi all,
After merging the sound-asoc tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
sound/soc/generic/simple-card.c: In function 'simple_parse_of':
sound/soc/generic/simple-card.c:478:1: warning: the frame size of 1552 bytes is
larger than 1024 bytes [-Wframe-larger-than=]
478 | }
| ^
sound/soc/generic/simple-card.c: In function 'asoc_simple_probe':
sound/soc/generic/simple-card.c:706:1: warning: the frame size of 1552 bytes is
larger than 1024 bytes [-Wframe-larger-than=]
706 | }
| ^
sound/soc/generic/audio-graph-card.c: In function 'audio_graph_parse_of':
sound/soc/generic/audio-graph-card.c:612:1: warning: the frame size of 1552
bytes is larger than 1024 bytes [-Wframe-larger-than=]
612 | }
| ^
Presumably introduced by commit
343e55e71877 ("ASoC: simple-card-utils: Increase maximum number of links to
128")
--
Cheers,
Stephen Rothwell
pgpSxmQ9sIt8x.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the vfs tree with the f2fs tree
Hi all,
Today's linux-next merge of the vfs tree got a conflict in:
fs/f2fs/namei.c
between commit:
5f029c045c94 ("f2fs: clean up build warnings")
from the f2fs tree and commit:
80e5d1ff5d5f ("useful constants: struct qstr for ".."")
from the vfs tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/f2fs/namei.c
index 405d85dbf9f1,377c6b161b23..
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@@ -416,10 -416,8 +416,9 @@@ out
struct dentry *f2fs_get_parent(struct dentry *child)
{
- struct qstr dotdot = QSTR_INIT("..", 2);
struct page *page;
- unsigned long ino = f2fs_inode_by_name(d_inode(child), &dotdot, &page);
+ unsigned long ino = f2fs_inode_by_name(d_inode(child), &dotdot_name,
&page);
+
if (!ino) {
if (IS_ERR(page))
return ERR_CAST(page);
pgpXEbsccnEan.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the vfs tree with the xfs tree
Hi all,
Today's linux-next merge of the vfs tree got a conflict in:
fs/xfs/xfs_ioctl.c
between commit:
b2197a36c0ef ("xfs: remove XFS_IFEXTENTS")
from the xfs tree and commit:
9fefd5db08ce ("xfs: convert to fileattr")
from the vfs tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/xfs/xfs_ioctl.c
index bf490bfae6cb,bbda105a2ce5..
--- a/fs/xfs/xfs_ioctl.c
+++ b/fs/xfs/xfs_ioctl.c
@@@ -1056,77 -1057,17 +1057,19 @@@ xfs_ioc_ag_geometry
static void
xfs_fill_fsxattr(
struct xfs_inode*ip,
- boolattr,
- struct fsxattr *fa)
+ int whichfork,
+ struct fileattr *fa)
{
+ struct xfs_mount*mp = ip->i_mount;
- struct xfs_ifork*ifp = attr ? ip->i_afp : &ip->i_df;
+ struct xfs_ifork*ifp = XFS_IFORK_PTR(ip, whichfork);
- simple_fill_fsxattr(fa, xfs_ip2xflags(ip));
+ fileattr_fill_xflags(fa, xfs_ip2xflags(ip));
- fa->fsx_extsize = ip->i_d.di_extsize << ip->i_mount->m_sb.sb_blocklog;
- fa->fsx_cowextsize = ip->i_d.di_cowextsize <<
- ip->i_mount->m_sb.sb_blocklog;
- fa->fsx_projid = ip->i_d.di_projid;
- if (ifp && (ifp->if_flags & XFS_IFEXTENTS))
+
+ fa->fsx_extsize = XFS_FSB_TO_B(mp, ip->i_extsize);
+ if (ip->i_diflags2 & XFS_DIFLAG2_COWEXTSIZE)
+ fa->fsx_cowextsize = XFS_FSB_TO_B(mp, ip->i_cowextsize);
+ fa->fsx_projid = ip->i_projid;
+ if (ifp && !xfs_need_iread_extents(ifp))
fa->fsx_nextents = xfs_iext_count(ifp);
else
fa->fsx_nextents = xfs_ifork_nextents(ifp);
@@@ -1212,10 -1167,10 +1169,10 @@@ static in
xfs_ioctl_setattr_xflags(
struct xfs_trans*tp,
struct xfs_inode*ip,
- struct fsxattr *fa)
+ struct fileattr *fa)
{
struct xfs_mount*mp = ip->i_mount;
- uint64_tdi_flags2;
+ uint64_ti_flags2;
/* Can't change realtime flag if any extents are allocated. */
if ((ip->i_df.if_nextents || ip->i_delayed_blks) &&
@@@ -1348,8 -1289,11 +1291,11 @@@ xfs_ioctl_setattr_check_extsize
xfs_extlen_tsize;
xfs_fsblock_t extsize_fsb;
+ if (!fa->fsx_valid)
+ return 0;
+
if (S_ISREG(VFS_I(ip)->i_mode) && ip->i_df.if_nextents &&
- ((ip->i_d.di_extsize << mp->m_sb.sb_blocklog) != fa->fsx_extsize))
+ ((ip->i_extsize << mp->m_sb.sb_blocklog) != fa->fsx_extsize))
return -EINVAL;
if (fa->fsx_extsize == 0)
@@@ -1520,18 -1476,18 +1478,19 @@@ xfs_fileattr_set
* extent size hint should be set on the inode. If no extent size flags
* are set on the inode then unconditionally clear the extent size hint.
*/
- if (ip->i_d.di_flags & (XFS_DIFLAG_EXTSIZE | XFS_DIFLAG_EXTSZINHERIT))
- ip->i_d.di_extsize = fa->fsx_extsize >> mp->m_sb.sb_blocklog;
- else
- ip->i_d.di_extsize = 0;
- if (xfs_sb_version_has_v3inode(&mp->m_sb) &&
- (ip->i_d.di_flags2 & XFS_DIFLAG2_COWEXTSIZE))
- ip->i_d.di_cowextsize = fa->fsx_cowextsize >>
- mp->m_sb.sb_blocklog;
+ if (ip->i_diflags & (XFS_DIFLAG_EXTSIZE | XFS_DIFLAG_EXTSZINHERIT))
+ ip->i_extsize = XFS_B_TO_FSB(mp, fa->fsx_extsize);
else
- ip->i_d.di_cowextsize = 0;
+ ip->i_extsize = 0;
+
+ if (xfs_sb_version_has_v3inode(&mp->m_sb)) {
+ if (ip->i_diflags2 & XFS_DIFLAG2_COWEXTSIZE)
+ ip->i_cowextsize = XFS_B_TO_FSB(mp, fa->fsx_cowextsize);
+ else
+ ip->i_cowextsize = 0;
+ }
+ skip_xattr:
error = xfs_trans_commit(tp);
/*
pgpP4E4dzcZ3M.pgp
Description: OpenPGP digital signature
linux-next: Fixes tag needs some work in the net-next tree
Hi all,
In commit
0e672f306a28 ("veth: check for NAPI instead of xdp_prog before xmit of XDP
frame")
Fixes tag
Fixes: 6788fa154546 ("veth: allow enabling NAPI even without XDP")
has these problem(s):
- Target SHA1 does not exist
Maybe you meant
Fixes: d3256efd8e8b ("veth: allow enabling NAPI even without XDP")
--
Cheers,
Stephen Rothwell
pgpEC523gR0tU.pgp
Description: OpenPGP digital signature
Re: [PATCH 12/12] dt-bindings: soc: qcom: aoss: Delete unused power-domain definitions
Quoting Sibi Sankar (2021-04-16 05:03:58) > Delete unused power-domain definitions exposed by AOSS QMP. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 10/12] arm64: dts: qcom: sm8250: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:56) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SM8250 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 11/12] arm64: dts: qcom: sm8350: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:57) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SM8350 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 09/12] arm64: dts: qcom: sm8150: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:55) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SM8150 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 08/12] arm64: dts: qcom: sdm845: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:54) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SDM845 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 07/12] arm64: dts: qcom: sc7280: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:53) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SC7280 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 06/12] arm64: dts: qcom: sc7180: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:52) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SC7180 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 02/12] soc: qcom: aoss: Drop power domain support
Quoting Sibi Sankar (2021-04-16 05:03:48) > The load state resources are expected to follow the life cycle of the > remote processor it tracks. However, modeling load state resources as > power-domains result in them getting turned off during system suspend > and thereby falling out of sync with the remote processors that are still > on. Fix this by replacing load state resource control through the generic > qmp message send interface instead. > > Signed-off-by: Sibi Sankar > --- Is it possible to keep this code around for a cycle so that there isn't the chance that someone is using the deprecated DT bindings with a new kernel? I worry that ripping the code out will cause them angst. Certainly we have to keep the code in place until DT is updated, so this patch should come last?
Re: [PATCH 03/12] dt-bindings: remoteproc: qcom: pas: Add QMP bindings
Quoting Sibi Sankar (2021-04-16 05:03:49) > Add Qualcomm Mailbox Protocol (QMP) binding to replace the power domains > exposed by the AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 04/12] dt-bindings: remoteproc: qcom: Add QMP bindings
Quoting Sibi Sankar (2021-04-16 05:03:50) > Add Qualcomm Mailbox Protocol (QMP) binding to replace the power domains > exposed by the AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 01/12] dt-bindings: soc: qcom: aoss: Drop power-domain bindings
Quoting Sibi Sankar (2021-04-16 05:03:47) > Drop power-domain bindings exposed by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH v4 05/13] module: Add printk formats to add module build ID to stacktraces
Quoting Jessica Yu (2021-04-15 06:04:35)
> +++ Stephen Boyd [09/04/21 18:52 -0700]:
> >diff --git a/include/linux/module.h b/include/linux/module.h
> >index 59f094fa6f74..4bf869f6c944 100644
> >--- a/include/linux/module.h
> >+++ b/include/linux/module.h
> >@@ -11,6 +11,7 @@
> >
> > #include
> > #include
> >+#include
> > #include
> > #include
> > #include
> >@@ -367,6 +368,9 @@ struct module {
> > /* Unique handle for this module */
> > char name[MODULE_NAME_LEN];
> >
> >+ /* Module build ID */
> >+ unsigned char build_id[BUILD_ID_SIZE_MAX];
>
> Hi Stephen,
>
> Since this field is not used when !CONFIG_STACKTRACE_BUILD_ID, I
> would prefer to wrap this in an ifdef, similar to the other
> CONFIG-dependent fields in struct module. This makes it explicit under
> what conditions (i.e. config) the field is meant to be used.
Ok will do.
> >diff --git a/kernel/module.c b/kernel/module.c
> >index 30479355ab85..6f5bc1b046a5 100644
> >--- a/kernel/module.c
> >+++ b/kernel/module.c
> >@@ -2770,6 +2771,20 @@ static void add_kallsyms(struct module *mod, const
> >struct load_info *info)
> > }
> > mod->core_kallsyms.num_symtab = ndst;
> > }
> >+
> >+static void init_build_id(struct module *mod, const struct load_info *info)
> >+{
> >+ const Elf_Shdr *sechdr;
> >+ unsigned int i;
> >+
> >+ for (i = 0; i < info->hdr->e_shnum; i++) {
> >+ sechdr = &info->sechdrs[i];
> >+ if (!sect_empty(sechdr) && sechdr->sh_type == SHT_NOTE &&
> >+ !build_id_parse_buf((void *)sechdr->sh_addr,
> >mod->build_id,
> >+ sechdr->sh_size))
> >+ break;
> >+ }
>
> If mod->build_id is not used when !CONFIG_STACKTRACE_BUILD_ID, then we
> don't need to look for it. I would be fine with wrapping the function
> body in an ifdef (similar to what we currently do in
> del_usage_links() and do_mod_ctors()).
Ok, done.
>
> >+}
> > #else
> > static inline void layout_symtab(struct module *mod, struct load_info *info)
> > {
> >@@ -2778,6 +2793,10 @@ static inline void layout_symtab(struct module *mod,
> >struct load_info *info)
> > static void add_kallsyms(struct module *mod, const struct load_info *info)
> > {
> > }
> >+
> >+static void init_build_id(struct module *mod, const struct load_info *info)
> >+{
> >+}
> > #endif /* CONFIG_KALLSYMS */
> >
> > static void dynamic_debug_setup(struct module *mod, struct _ddebug *debug,
> > unsigned int num)
> >@@ -4004,6 +4023,7 @@ static int load_module(struct load_info *info, const
> >char __user *uargs,
> > goto free_arch_cleanup;
> > }
> >
> >+ init_build_id(mod, info);
> > dynamic_debug_setup(mod, info->debug, info->num_debug);
> >
> > /* Ftrace init must be called in the MODULE_STATE_UNFORMED state */
> >@@ -4235,7 +4255,7 @@ void * __weak
> >dereference_module_function_descriptor(struct module *mod,
> > const char *module_address_lookup(unsigned long addr,
> > unsigned long *size,
> > unsigned long *offset,
> >- char **modname,
> >+ char **modname, const unsigned char **modbuildid,
> > char *namebuf)
> > {
> > const char *ret = NULL;
> >@@ -4246,6 +4266,8 @@ const char *module_address_lookup(unsigned long addr,
> > if (mod) {
> > if (modname)
> > *modname = mod->name;
> >+ if (modbuildid)
> >+ *modbuildid = mod->build_id;
>
> Then maybe we can set *modbuildid = NULL in the case of
> !CONFIG_STACKTRACE_BUILD_ID, similar to the kernel case in
> kallsyms_lookup_buildid().
>
Sounds good. It means that some more ifdefs are probably required vs.
making the array size be 0 when the config is disabled but that isn't a
big problem for me. I'm reworking the code now and will test and then
send v5 shortly. Thanks!
Re: [PATCH v2 1/7] dt-bindings: clock: Add MT8192 APU clock bindings
Quoting Flora Fu (2021-04-14 22:52:34) > Add clock bindings for APU on MT8192. > > Signed-off-by: Flora Fu > Acked-by: Rob Herring > --- Acked-by: Stephen Boyd
Re: [PATCH v2 2/7] clk: mediatek: mt8192: Add APU clocks support
Quoting Flora Fu (2021-04-14 22:52:35) > Add APU clocks support on MT8192. > > Signed-off-by: Flora Fu > --- Acked-by: Stephen Boyd
Re: [PATCH 2/4] dt-bindings: clock: Convert ti,sci-clk to json schema
Quoting Nishanth Menon (2021-04-15 23:37:19)
> diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> new file mode 100644
> index ..72633651f0c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI-SCI clock controller node bindings
> +
> +maintainers:
> + - Nishanth Menon
> +
> +allOf:
> + - $ref: /schemas/clock/clock.yaml#
Is this needed?
> +
> +description: |
> + Some TI SoCs contain a system controller (like the Power Management Micro
> + Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for
> controlling
> + the state of the various hardware modules present on the SoC. Communication
> + between the host processor running an OS and the system controller happens
> + through a protocol called TI System Control Interface (TI-SCI protocol).
> +
> + This clock controller node uses the TI SCI protocol to perform various
> clock
> + management of various hardware modules (devices) present on the SoC. This
> + node must be a child node of the associated TI-SCI system controller node.
> +
> +properties:
> + $nodename:
> +pattern: "^clock-controller$"
Is this nodename pattern check required?
> +
> + compatible:
> +const: ti,k2g-sci-clk
I thought most things keyed off the compatible string.
> +
> + "#clock-cells":
> +const: 2
> +description:
> + The two cells represent values that the TI-SCI controller defines.
> +
> + The first cell should contain the device ID.
> +
> + The second cell should contain the clock ID.
> +
> + Please see http://processors.wiki.ti.com/index.php/TISCI for
> + protocol documentation for the values to be used for different devices.
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +k3_clks: clock-controller {
> +compatible = "ti,k2g-sci-clk";
> +#clock-cells = <2>;
> +};
Re: [PATCH v7 net-next] net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)
On Fri, 16 Apr 2021 17:58:45 + Dexuan Cui wrote: > > > > > > This probably should be a separate patch. > > > I think it is trying to address the case of VF discovery in Hyper-V/Azure > > > where > > > the reported > > > VF from Hypervisor is bogus or confused. > > > > This is for the Multi vPorts feature of MANA driver, which allows one VF to > > create multiple vPorts (NICs). They have the same PCI device and same VF > > serial number, but different MACs. > > > > So we put the change in one patch to avoid distro vendors missing this > > change when backporting the MANA driver. > > > > Thanks, > > - Haiyang > > The netvsc change should come together in the same patch with this VF > driver, otherwise the multi-vPorts functionality doesn't work properly. > > The netvsc change should not break any other existing VF drivers, because > Hyper-V NIC SR-IOV implementation requires the the NetVSC network > interface and the VF network interface should have the same MAC address, > otherwise things won't work. > > Thanks, > Dexuan Distro vendors should be able to handle a patch series. Don't see why this could not be two patch series.
Re: [PATCH] mmc: core: Don't allocate IDA for OF aliases
Quoting Ulf Hansson (2021-04-16 00:17:10) > On Thu, 15 Apr 2021 at 21:29, Stephen Boyd wrote: > > > > > > Don't think so. The device (with the kobject inside) is removed, and > > thus the mmc1 device will be removed, but the kobject's release function > > is delayed due to the config. This means that > > mmc_host_classdev_release() is called at a later time. The only thing > > inside that function is the IDA removal and the kfree of the container > > object. Given that nothing else is in that release function I believe it > > is safe to skip IDA allocation as it won't be blocking anything in the > > reserved alias case. > > > > Furthermore, when the device is deleted in mmc_remove_host() there could > > be other users of the device that haven't called put_device() yet. > > Either way, those other users are keeping the device memory alive, but > > otherwise device_del() has unlinked it from the various driver core > > lists and sysfs has removed it too so it's in a state where code may be > > referencing it but it's on the way out so users of the device will not > > be able to do much with it during this time. > > Right, but see more below. > > > > > This sort of problem (if it exists which I don't think it does) would > > have been there all along and can't be fixed at this level. When a > > device that has an alias calls the mmc_alloc_host() function twice it > > gets two different device structures created so there are two distinct > > kobjects that will need to be released at some point. The index is > > usually different for those two kobjects, but with aliases it turns out > > it is the same. When it comes to registering that device with the same > > name the second one will fail because a device with that name already > > exists on the bus. This would be really hard to do given that it would > > need to be the same aliased device in DT calling the mmc_add_host() > > function without calling mmc_remove_host() for the first one it added in > > between. > > In fact, we have a few rare corner cases that can trigger KASAN splats > when mmc_remove_host() gets executed. Similar splats can be triggered > by just doing a sudden card removal. It's especially related to the > cases, where a thread holds a reference to the card/host object when > it's being removed. I am working on patches to fix these cases, but > haven't yet decided on the best solution. Ok. Can you share the KASAN reports? The memory allocated for this class object and associated index from the IDA will be unique for each call the mmc_alloc_host() so I don't see how KASAN could be noticing something unless a reference to the host is leaking out without the proper get_device() call being made to keep the underlying memory from being freed. > > That's the reason why I was thinking that maybe returning > -EPROBE_DEFER could be an option, but certainly I need to think more > about this. I was hoping that you wouldn't need to think more about returning -EPROBE_DEFER after my email. :( Returning EPROBE_DEFER looks like it's a bandaid for bigger problems with reference counting the pointer allocated in mmc_alloc_host(). I hope I convinced you that there isn't any danger in reusing the IDA in the case of an alias because the only way that is a problem is if the same device calls mmc_alloc_host() twice without calling mmc_remove_host() in between. That should be a pretty obvious problem in driver code? The check to see if that same device has tried to alloc a host twice would still effectively happen after this patch because when mmc_add_host() tries to add that second device to the driver core it will complain about duplicate device names and fail. Will you apply this patch?
Re: [PATCH v7 net-next] net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)
On Thu, 15 Apr 2021 23:07:05 -0700
Dexuan Cui wrote:
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index 7349a70af083..f682a5572d84 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -2297,6 +2297,7 @@ static struct net_device *get_netvsc_byslot(const
> struct net_device *vf_netdev)
> {
> struct device *parent = vf_netdev->dev.parent;
> struct net_device_context *ndev_ctx;
> + struct net_device *ndev;
> struct pci_dev *pdev;
> u32 serial;
>
> @@ -2319,8 +2320,17 @@ static struct net_device *get_netvsc_byslot(const
> struct net_device *vf_netdev)
> if (!ndev_ctx->vf_alloc)
> continue;
>
> - if (ndev_ctx->vf_serial == serial)
> - return hv_get_drvdata(ndev_ctx->device_ctx);
> + if (ndev_ctx->vf_serial != serial)
> + continue;
> +
> + ndev = hv_get_drvdata(ndev_ctx->device_ctx);
> + if (ndev->addr_len != vf_netdev->addr_len ||
> + memcmp(ndev->perm_addr, vf_netdev->perm_addr,
> +ndev->addr_len) != 0)
> + continue;
> +
> + return ndev;
> +
> }
>
> netdev_notice(vf_netdev,
This probably should be a separate patch.
I think it is trying to address the case of VF discovery in Hyper-V/Azure where
the reported
VF from Hypervisor is bogus or confused.
Re: linux-next: Fixes tag needs some work in the kvm tree
Hi all,
On Fri, 16 Apr 2021 16:02:01 +0200 Paolo Bonzini wrote:
>
> On 16/04/21 14:38, Christian Borntraeger wrote:
> > On 16.04.21 14:27, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> In commit
> >>
> >> c3171e94cc1c ("KVM: s390: VSIE: fix MVPG handling for prefixing and >>
> >> MSO")
> >>
> >> Fixes tag
> >>
> >> Fixes: bdf7509bbefa ("s390/kvm: VSIE: correctly handle MVPG when in >>
> >> VSIE")
> >>
> >> has these problem(s):
> >>
> >> - Subject does not match target commit subject
> >> Just use
> >> git log -1 --format='Fixes: %h ("%s")'
> >
> > Hmm, this has been sitting in kvms390/next for some time now. Is this a >
> > new check?
> >
>
> Maybe you just missed it when it was reported for kvms390?
>
> https://www.spinics.net/lists/linux-next/msg59652.html
It was a different commit SHA then and was reported because the Fixes
SHA did not exist. It was fixed the next day, so I guess either I
missed reporting this different problem, or I thought at least it had
been fixed to use the correct SHA. I am not completely consistent,
sometimes :-)
--
Cheers,
Stephen Rothwell
pgpqysU3Glgh7.pgp
Description: OpenPGP digital signature
linux-next: Fixes tag needs some work in the kvm tree
Hi all,
In commit
c3171e94cc1c ("KVM: s390: VSIE: fix MVPG handling for prefixing and MSO")
Fixes tag
Fixes: bdf7509bbefa ("s390/kvm: VSIE: correctly handle MVPG when in VSIE")
has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h ("%s")'
--
Cheers,
Stephen Rothwell
pgp8D6dFguKch.pgp
Description: OpenPGP digital signature
linux-next: Tree for Apr 16
Hi all,
Changes since 20210415:
New trees: cxl-fixes, cxl
The rust tree gained conflicts against the printk and char-misc trees.
Non-merge commits (relative to Linus' tree): 12231
10888 files changed, 590734 insertions(+), 269274 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 340 trees (counting Linus' and 87 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (7e25f40eab52 Merge tag 'acpi-5.12-rc8' of
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm)
Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2)
Merging kbuild-current/fixes (bcbcf50f5218 kbuild: fix ld-version.sh to not be
affected by locale)
Merging arc-current/for-curr (163630b2d95b arc: Fix typos/spellos)
Merging arm-current/fixes (30e3b4f256b4 ARM: footbridge: fix PCI interrupt
mapping)
Merging arm64-fixes/for-next/fixes (22315a2296f4 arm64: alternatives: Move
length validation in alternative_{insn, endif})
Merging arm-soc-fixes/arm/fixes (b9a9786a13ea Merge tag
'omap-for-v5.12/fixes-rc6-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes)
Merging drivers-memory-fixes/fixes (a38fd8748464 Linux 5.12-rc2)
Merging m68k-current/for-linus (a65a802aadba m68k: Fix virt_addr_valid() W=1
compiler warnings)
Merging powerpc-fixes/fixes (791f9e36599d powerpc/vdso: Make sure
vdso_wrapper.o is rebuilt everytime vdso.so is rebuilt)
Merging s390-fixes/fixes (a994eddb947e s390/entry: save the caller of psw_idle)
Merging sparc/master (05a59d79793d Merge
git://git.kernel.org:/pub/scm/linux/kernel/git/netdev/net)
Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption
not used on new files)
Merging net/master (4e39a072a6a0 i40e: fix the panic when running bpf in xdpdrv
mode)
Merging bpf/master (afd0be729953 libbpf: Fix potential NULL pointer dereference)
Merging ipsec/master (6628ddfec758 net: geneve: check skb is large enough for
IPv4/IPv6 header)
Merging netfilter/master (ccb39c628558 Merge
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (fbea31808ca1 netfilter: conntrack: do not print icmpv6 as
unknown via /proc)
Merging wireless-drivers/master (65db391dd874 iwlwifi: mvm: fix beacon
protection checks)
Merging mac80211/master (864db232dc70 net: ipv6: check for validity before
dereferencing cfg->fc_nlinfo.nlh)
Merging rdma-fixes/for-rc (d434405aaab7 Linux 5.12-rc7)
Merging sound-current/for-linus (c8426b2700b5 ALSA: hda/realtek: Fix speaker
amp setup on Acer Aspire E1)
Merging sound-asoc-fixes/for-linus (f655ede26d66 Merge remote-tracking branch
'asoc/for-5.12' into asoc-linus)
Merging regmap-fixes/for-linus (78d889705732 Merge remote-tracking branch
'regmap/for-5.12' into regmap-linus)
Merging regulator-fixes/for-linus (6068cc31dedd Merge remote-tracking branch
'regulator/for-5.12' into regulator-linus)
Merging spi-fixes/for-linus (49dff37f84d5 Merge remote-tracking branch
'spi/for-5.12' into spi-linus)
Merging pci-current/for-linus (cf673bd0cc97 PCI: switchtec: Fix Spectre v1
vulnerability)
Merging driver-core.current/driver-core-linus (d434405aaab7 Linux 5.12-rc7)
Merging tty.current/tty-linus (e49d033bddf5 Linux 5.
Re: linux-next: manual merge of the rust tree with the char-misc tree
Hi all,
On Fri, 16 Apr 2021 17:58:06 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the rust tree got a conflict in:
>
> include/uapi/linux/android/binder.h
>
> between commits:
>
> 432ff1e91694 ("binder: BINDER_FREEZE ioctl")
> ae28c1be1e54 ("binder: BINDER_GET_FROZEN_INFO ioctl")
> a7dc1e6f99df ("binder: tell userspace to dump current backtrace when
> detected oneway spamming")
>
> from the char-misc tree and commit:
>
> 1fed5dee5fbb ("Android: Binder IPC in Rust (WIP)")
>
> from the rust tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc include/uapi/linux/android/binder.h
> index 20e435fe657a,7b13c9e9aa2f..
> --- a/include/uapi/linux/android/binder.h
> +++ b/include/uapi/linux/android/binder.h
> @@@ -217,31 -217,18 +217,33 @@@ struct binder_node_info_for_ref
> __u32reserved3;
> };
>
> +struct binder_freeze_info {
> +__u32pid;
> +__u32enable;
> +__u32timeout_ms;
> +};
> +
> +struct binder_frozen_status_info {
> +__u32pid;
> +__u32sync_recv;
> +__u32async_recv;
> +};
> +
> - #define BINDER_WRITE_READ _IOWR('b', 1, struct binder_write_read)
> - #define BINDER_SET_IDLE_TIMEOUT _IOW('b', 3, __s64)
> - #define BINDER_SET_MAX_THREADS _IOW('b', 5, __u32)
> - #define BINDER_SET_IDLE_PRIORITY_IOW('b', 6, __s32)
> - #define BINDER_SET_CONTEXT_MGR _IOW('b', 7, __s32)
> - #define BINDER_THREAD_EXIT _IOW('b', 8, __s32)
> - #define BINDER_VERSION _IOWR('b', 9, struct
> binder_version)
> - #define BINDER_GET_NODE_DEBUG_INFO _IOWR('b', 11, struct
> binder_node_debug_info)
> - #define BINDER_GET_NODE_INFO_FOR_REF_IOWR('b', 12, struct
> binder_node_info_for_ref)
> - #define BINDER_SET_CONTEXT_MGR_EXT _IOW('b', 13, struct flat_binder_object)
> - #define BINDER_FREEZE _IOW('b', 14, struct
> binder_freeze_info)
> - #define BINDER_GET_FROZEN_INFO _IOWR('b', 15, struct
> binder_frozen_status_info)
> - #define BINDER_ENABLE_ONEWAY_SPAM_DETECTION _IOW('b', 16, __u32)
> + enum {
> + BINDER_WRITE_READ = _IOWR('b', 1, struct
> binder_write_read),
> + BINDER_SET_IDLE_TIMEOUT = _IOW('b', 3, __s64),
> + BINDER_SET_MAX_THREADS = _IOW('b', 5, __u32),
> + BINDER_SET_IDLE_PRIORITY= _IOW('b', 6, __s32),
> + BINDER_SET_CONTEXT_MGR = _IOW('b', 7, __s32),
> + BINDER_THREAD_EXIT = _IOW('b', 8, __s32),
> + BINDER_VERSION = _IOWR('b', 9, struct binder_version),
> + BINDER_GET_NODE_DEBUG_INFO = _IOWR('b', 11, struct
> binder_node_debug_info),
> + BINDER_GET_NODE_INFO_FOR_REF= _IOWR('b', 12, struct
> binder_node_info_for_ref),
> + BINDER_SET_CONTEXT_MGR_EXT = _IOW('b', 13, struct
> flat_binder_object),
> ++BINDER_FREEZE = _IOW('b', 14, struct
> binder_freeze_info)
> ++BINDER_GET_FROZEN_INFO = _IOWR('b', 15, struct
> binder_frozen_status_info)
> ++BINDER_ENABLE_ONEWAY_SPAM_DETECTION = _IOW('b', 16, __u32)
> + };
>
> /*
>* NOTE: Two special error codes you should check for when calling
I also needed this patch (which I will add to my merge resolution):
diff --git a/include/uapi/linux/android/binder.h
b/include/uapi/linux/android/binder.h
index 49611d7309e0..9fca291e0132 100644
--- a/include/uapi/linux/android/binder.h
+++ b/include/uapi/linux/android/binder.h
@@ -240,9 +240,9 @@ enum {
BINDER_GET_NODE_DEBUG_INFO = _IOWR('b', 11, struct
binder_node_debug_info),
BINDER_GET_NODE_INFO_FOR_REF= _IOWR('b', 12, struct
binder_node_info_for_ref),
BINDER_SET_CONTEXT_MGR_EXT = _IOW('b', 13, struct
flat_binder_object),
- BINDER_FREEZE = _IOW('b', 14, struct
binder_freeze_info)
- BINDER_GET_FROZEN_INFO = _IOWR('b', 15, struct
binder_frozen_status_info)
- BINDER_ENABLE_ONEWAY_SPAM_DETECTION = _IOW('b', 16, __u32)
+ BINDER_FREEZE = _IOW('b', 14, struct
binder_freeze_info),
+ BINDER_GET_FROZEN_INFO = _IOWR('b', 15, struct
binder_frozen_status_info),
+ BINDER_ENABLE_ONEWAY_SPAM_DETECTION = _IOW('b', 16, __u32),
};
/*
--
Cheers,
Stephen Rothwell
pgpjWc7lWPj1R.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the rust tree with the printk tree
Hi all,
Today's linux-next merge of the rust tree got a conflict in:
kernel/printk/printk.c
between commit:
cf5b0208fda4 ("printk: introduce CONSOLE_LOG_MAX")
from the printk tree and commit:
fd1e637b9b4b ("Rust: Kernel crate")
from the rust tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc kernel/printk/printk.c
index 421c35571797,d13be89530c4..
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@@ -394,11 -411,8 +394,12 @@@ static struct latched_seq clear_seq =
#define PREFIX_MAX32
#endif
+/* the maximum size of a formatted record (i.e. with prefix added per line) */
+#define CONSOLE_LOG_MAX 1024
+
+/* the maximum size allowed to be reserved for a record */
+ /* Keep in sync with rust/kernel/print.rs */
-#define LOG_LINE_MAX (1024 - PREFIX_MAX)
+#define LOG_LINE_MAX (CONSOLE_LOG_MAX - PREFIX_MAX)
#define LOG_LEVEL(v) ((v) & 0x07)
#define LOG_FACILITY(v) ((v) >> 3 & 0xff)
pgpi28yOEgIhE.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the rust tree with the char-misc tree
Hi all,
Today's linux-next merge of the rust tree got a conflict in:
include/uapi/linux/android/binder.h
between commits:
432ff1e91694 ("binder: BINDER_FREEZE ioctl")
ae28c1be1e54 ("binder: BINDER_GET_FROZEN_INFO ioctl")
a7dc1e6f99df ("binder: tell userspace to dump current backtrace when detected
oneway spamming")
from the char-misc tree and commit:
1fed5dee5fbb ("Android: Binder IPC in Rust (WIP)")
from the rust tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/uapi/linux/android/binder.h
index 20e435fe657a,7b13c9e9aa2f..
--- a/include/uapi/linux/android/binder.h
+++ b/include/uapi/linux/android/binder.h
@@@ -217,31 -217,18 +217,33 @@@ struct binder_node_info_for_ref
__u32reserved3;
};
+struct binder_freeze_info {
+ __u32pid;
+ __u32enable;
+ __u32timeout_ms;
+};
+
+struct binder_frozen_status_info {
+ __u32pid;
+ __u32sync_recv;
+ __u32async_recv;
+};
+
- #define BINDER_WRITE_READ _IOWR('b', 1, struct binder_write_read)
- #define BINDER_SET_IDLE_TIMEOUT _IOW('b', 3, __s64)
- #define BINDER_SET_MAX_THREADS_IOW('b', 5, __u32)
- #define BINDER_SET_IDLE_PRIORITY _IOW('b', 6, __s32)
- #define BINDER_SET_CONTEXT_MGR_IOW('b', 7, __s32)
- #define BINDER_THREAD_EXIT_IOW('b', 8, __s32)
- #define BINDER_VERSION_IOWR('b', 9, struct
binder_version)
- #define BINDER_GET_NODE_DEBUG_INFO_IOWR('b', 11, struct
binder_node_debug_info)
- #define BINDER_GET_NODE_INFO_FOR_REF _IOWR('b', 12, struct
binder_node_info_for_ref)
- #define BINDER_SET_CONTEXT_MGR_EXT_IOW('b', 13, struct flat_binder_object)
- #define BINDER_FREEZE _IOW('b', 14, struct binder_freeze_info)
- #define BINDER_GET_FROZEN_INFO_IOWR('b', 15, struct
binder_frozen_status_info)
- #define BINDER_ENABLE_ONEWAY_SPAM_DETECTION _IOW('b', 16, __u32)
+ enum {
+ BINDER_WRITE_READ = _IOWR('b', 1, struct
binder_write_read),
+ BINDER_SET_IDLE_TIMEOUT = _IOW('b', 3, __s64),
+ BINDER_SET_MAX_THREADS = _IOW('b', 5, __u32),
+ BINDER_SET_IDLE_PRIORITY= _IOW('b', 6, __s32),
+ BINDER_SET_CONTEXT_MGR = _IOW('b', 7, __s32),
+ BINDER_THREAD_EXIT = _IOW('b', 8, __s32),
+ BINDER_VERSION = _IOWR('b', 9, struct binder_version),
+ BINDER_GET_NODE_DEBUG_INFO = _IOWR('b', 11, struct
binder_node_debug_info),
+ BINDER_GET_NODE_INFO_FOR_REF= _IOWR('b', 12, struct
binder_node_info_for_ref),
+ BINDER_SET_CONTEXT_MGR_EXT = _IOW('b', 13, struct
flat_binder_object),
++ BINDER_FREEZE = _IOW('b', 14, struct
binder_freeze_info)
++ BINDER_GET_FROZEN_INFO = _IOWR('b', 15, struct
binder_frozen_status_info)
++ BINDER_ENABLE_ONEWAY_SPAM_DETECTION = _IOW('b', 16, __u32)
+ };
/*
* NOTE: Two special error codes you should check for when calling
pgpHe4_ap9qjq.pgp
Description: OpenPGP digital signature
Re: linux-next: build warning after merge of the amdgpu tree
Hi, On Fri, 16 Apr 2021 03:12:12 + "Liang, Prike" wrote: > > Hi, Rothwell (Stephen, actually :-)) > This fix solution hasn't locked down and still being discussed and > roll-updated in the NVMe mail group. > Will update the patch once it refined done. In which case, this patch should not be in linux-next (or any branch that is included by linux-next). -- Cheers, Stephen Rothwell pgpe8OeiFcmwZ.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the mmc tree
Hi all,
This is actually just a warning.
On Fri, 16 Apr 2021 13:48:27 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the mmc tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from drivers/memstick/host/r592.h:13,
> from drivers/memstick/host/r592.c:21:
> drivers/memstick/host/r592.c: In function 'r592_flush_fifo_write':
> include/linux/kfifo.h:588:1: warning: ignoring return value of
> '__kfifo_uint_must_check_helper' declared with attribute 'warn_unused_result'
> [-Wunused-result]
> 588 | __kfifo_uint_must_check_helper( \
> | ^
> 589 | ({ \
> |
> 590 | typeof((fifo) + 1) __tmp = (fifo); \
> |
> 591 | typeof(__tmp->ptr) __buf = (buf); \
> | ~~~
> 592 | unsigned long __n = (n); \
> | ~~
> 593 | const size_t __recsize = sizeof(*__tmp->rectype); \
> | ~~~
> 594 | struct __kfifo *__kfifo = &__tmp->kfifo; \
> | ~~
> 595 | (__recsize) ?\
> | ~~
> 596 | __kfifo_out_r(__kfifo, __buf, __n, __recsize) : \
> | ~
> 597 | __kfifo_out(__kfifo, __buf, __n); \
> | ~~~
> 598 | }) \
> |
> 599 | )
> | ~
> drivers/memstick/host/r592.c:367:2: note: in expansion of macro 'kfifo_out'
> 367 | kfifo_out(&dev->pio_fifo, buffer, 4);
> | ^
>
> Caused by commit
>
> 4b00ed3c5072 ("memstick: r592: remove unused variable")
--
Cheers,
Stephen Rothwell
pgpuShvUS9tYz.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the mmc tree
Hi all,
After merging the mmc tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
In file included from drivers/memstick/host/r592.h:13,
from drivers/memstick/host/r592.c:21:
drivers/memstick/host/r592.c: In function 'r592_flush_fifo_write':
include/linux/kfifo.h:588:1: warning: ignoring return value of
'__kfifo_uint_must_check_helper' declared with attribute 'warn_unused_result'
[-Wunused-result]
588 | __kfifo_uint_must_check_helper( \
| ^
589 | ({ \
|
590 | typeof((fifo) + 1) __tmp = (fifo); \
|
591 | typeof(__tmp->ptr) __buf = (buf); \
| ~~~
592 | unsigned long __n = (n); \
| ~~
593 | const size_t __recsize = sizeof(*__tmp->rectype); \
| ~~~
594 | struct __kfifo *__kfifo = &__tmp->kfifo; \
| ~~
595 | (__recsize) ?\
| ~~
596 | __kfifo_out_r(__kfifo, __buf, __n, __recsize) : \
| ~
597 | __kfifo_out(__kfifo, __buf, __n); \
| ~~~
598 | }) \
|
599 | )
| ~
drivers/memstick/host/r592.c:367:2: note: in expansion of macro 'kfifo_out'
367 | kfifo_out(&dev->pio_fifo, buffer, 4);
| ^
Caused by commit
4b00ed3c5072 ("memstick: r592: remove unused variable")
Please check the fixes for "simple, robot reported" warnings :-(
--
Cheers,
Stephen Rothwell
pgp9fZLWkh9zV.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the amdgpu tree
Hi all,
After merging the amdgpu tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
drivers/pci/quirks.c: In function 'quirk_amd_nvme_fixup':
drivers/pci/quirks.c:312:18: warning: unused variable 'rdev' [-Wunused-variable]
312 | struct pci_dev *rdev;
| ^~~~
Introduced by commit
9597624ef606 ("nvme: put some AMD PCIE downstream NVME device to simple
suspend/resume path")
--
Cheers,
Stephen Rothwell
pgpI2syQttFk6.pgp
Description: OpenPGP digital signature
[PATCH RESEND v5] proc: Allow pid_revalidate() during LOOKUP_RCU
The pid_revalidate() function drops from RCU into REF lookup mode. When
many threads are resolving paths within /proc in parallel, this can
result in heavy spinlock contention on d_lockref as each thread tries to
grab a reference to the /proc dentry (and drop it shortly thereafter).
Investigation indicates that it is not necessary to drop RCU in
pid_revalidate(), as no RCU data is modified and the function never
sleeps. So, remove the LOOKUP_RCU check.
Signed-off-by: Stephen Brennan
---
Resending this in the hopes of Al picking this up, or else more feedback about
how to test for RCU-unsafe code in procfs.
When running running ~128 parallel instances of "TZ=/etc/localtime ps -fe
>/dev/null" on a 128CPU machine, the %sys utilization reaches 97%, and perf
shows the following code path as being responsible for heavy contention on
the d_lockref spinlock:
walk_component()
lookup_fast()
d_revalidate()
pid_revalidate() // returns -ECHILD
unlazy_child()
lockref_get_not_dead(&nd->path.dentry->d_lockref) <-- contention
By applying this patch, %sys utilization falls to around 85% under the same
workload, and the number of ps processes executed per unit time increases by
3x-4x. Although this particular workload is a bit contrived, we have seen some
monitoring scripts which produced similarly high %sys time due to this
contention.
As a result this patch, several procfs methods which were only called in
ref-walk mode could now be called from RCU mode. To ensure that this patch
is safe, I audited all the inode get_link and permission() implementations,
as well as dentry d_revalidate() implementations, in fs/proc. These methods
are called in the following ways:
* get_link() receives a NULL dentry pointer when called in RCU mode.
* permission() receives MAY_NOT_BLOCK in the mode parameter when called
from RCU.
* d_revalidate() receives LOOKUP_RCU in flags.
There were generally three groups I found. Group (1) are functions which
contain a check at the top of the function and return -ECHILD, and so
appear to be trivially RCU safe (although this is by dropping out of RCU
completely). Group (2) are functions which have no explicit check, but
on my audit, I was confident that there were no sleeping function calls,
and thus were RCU safe as is. However, I would appreciate any additional
review if possible. Group (3) are functions which call security hooks, but
which ought to be safe (especially after Al's commits: 23d8f5b684fc ("make
dump_common_audit_data() safe to be called from RCU pathwalk") and 2
previous).
Group (1):
proc_ns_get_link()
proc_pid_get_link()
map_files_d_revalidate()
proc_misc_d_revalidate()
tid_fd_revalidate()
Group (2):
proc_get_link()
proc_self_get_link()
proc_thread_self_get_link()
proc_fd_permission()
Group (3):
pid_revalidate()-- addressed by my patch,
calls security_task_to_inode()
proc_pid_permission() -- calls security_ptrace_access_check()
proc_map_files_get_link() -- calls security_capable()
I've tested this patch by enabling CONFIG_PROVE_RCU to warn on sleeping during
RCU, and running heavy procfs-related workloads (like the PS one described
above). I would love more input on selinux/audit rules to explore to attempt to
catch any other potential issues.
Changes in v5:
- Al's commits are now in linux-next, resolving proc_pid_permission() issue.
- Add NULL check after d_inode_rcu(dentry), because inode may become NULL if
we do not hold a reference.
Changes in v4:
- Simplify by unconditionally calling pid_update_inode() from pid_revalidate,
and removing the LOOKUP_RCU check.
Changes in v3:
- Rather than call pid_update_inode() with flags, create
proc_inode_needs_update() to determine whether the call can be skipped.
- Restore the call to the security hook
Changes in v2:
- Remove get_pid_task_rcu_user() and get_proc_task_rcu(), since they were
unnecessary.
- Remove the call to security_task_to_inode().
fs/proc/base.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index ebea9501afb8..3e105bd05801 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1830,19 +1830,21 @@ static int pid_revalidate(struct dentry *dentry,
unsigned int flags)
{
struct inode *inode;
struct task_struct *task;
+ int ret = 0;
- if (flags & LOOKUP_RCU)
- return -ECHILD;
-
- inode = d_inode(dentry);
- task = get_proc_task(inode);
+ rcu_read_lock();
+ inode = d_inode_rcu(dentry);
+ if (!inode)
+ goto out;
+ task = pid_task(proc_pid(inode), PIDTYPE_PID);
if (task) {
pid_update_inode(task, inode);
- put_task_struct(task);
- return 1;
+ ret = 1;
}
- return 0;
+out:
+ rcu_read
Re: [PATCH v13 14/14] powerpc/64s/radix: Enable huge vmalloc mappings
Hi all, On Thu, 15 Apr 2021 11:55:29 -0700 Andrew Morton wrote: > > On Thu, 15 Apr 2021 12:23:55 +0200 Christophe Leroy > wrote: > > > + * is done. STRICT_MODULE_RWX may require extra work to support this > > > + * too. > > > + */ > > > > > > - return __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END, > > > GFP_KERNEL, > > > - PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS, > > > NUMA_NO_NODE, > > > > > > I think you should add the following in > > > > #ifndef MODULES_VADDR > > #define MODULES_VADDR VMALLOC_START > > #define MODULES_END VMALLOC_END > > #endif > > > > And leave module_alloc() as is (just removing the enclosing #ifdef > > MODULES_VADDR and adding the > > VM_NO_HUGE_VMAP flag) > > > > This would minimise the conflits with the changes I did in powerpc/next > > reported by Stephen R. > > > > I'll drop powerpc-64s-radix-enable-huge-vmalloc-mappings.patch for now, > make life simpler. I have dropped that patch from linux-next. -- Cheers, Stephen Rothwell pgpxAl10ZqUKJ.pgp Description: OpenPGP digital signature
linux-next: error trying to fetch the scmi tree
Hi all, Fetching the scmi tree produces this error: fatal: couldn't find remote ref refs/heads/for-linux-next I will use the scmi tree from next-20210415 for today. -- Cheers, Stephen Rothwell pgp0J0njab4ca.pgp Description: OpenPGP digital signature
Re: [PATCH v2 3/3] drm/msm/dp: check main link status before start aux read
Quoting khs...@codeaurora.org (2021-04-15 15:02:40) > On 2021-04-15 13:06, Stephen Boyd wrote: > > > > Is it really necessary to have this patch at all? I think there are > > bigger problems with suspend/resume of the DP driver in relation to the > > kthread stopping. I hope that the aux channel would start NAKing > > transfers once the cable is disconnected too, so that we don't need to > > do an extra check for each aux transfer. > > I am working on duplicate this problem, but it is not happen on me yet > so far. > From kernel dump, i can see it crash at dp_irq_hdp_handle() after > suspended. > dp_irq_hpd_handle and dp_pm_suspend() are serialized by event_mutex. > > After suspend, ahb clock is disabled. > Hence next dp_catalog_link_is_connected() crash at acess dp ctrl > registers. > > > aux channel does not do NAKing immediately if unplugged. Therefore > aux_transfer will wait until timeout (HZ/4). > worst, drm_dp_dpcd_access() will retry 32 times before return dpcd > read/write failed. > This patch try to eliminate the time spinning on waiting for timeout 32 > times. > Would be useful to have that level of detail in the commit text. Maybe when the cable is disconnected the DP phy should be shutdown and some bit in the phy could effectively "cut off" the aux channel and then NAKs would start coming through here in the DP controller I/O register space?
Re: linux-next: manual merge of the net-next tree with the net tree
Hi all,
On Thu, 15 Apr 2021 14:00:16 + "Ong, Boon Leong"
wrote:
>
> I check linux-next merge fix above and spotted an additional fix needed.
> Please see below.
>
> >+ /**
> >+ * dma_recycle_rx_skbufs - recycle RX dma buffers
> >+ * @priv: private structure
> >+ * @queue: RX queue index
> >+ */
> >+ static void dma_recycle_rx_skbufs(struct stmmac_priv *priv, u32 queue)
> >+ {
> >+struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
> >+int i;
> >+
> >+for (i = 0; i < priv->dma_rx_size; i++) {
> >+struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
> >+
> >+if (buf->page) {
> >+page_pool_recycle_direct(rx_q->page_pool, buf-
> >>page);
> >+buf->page = NULL;
> >+}
> >+
> >+if (priv->sph && buf->sec_page) {
> >+page_pool_recycle_direct(rx_q->page_pool, buf-
> >>sec_page);
> >+buf->sec_page = NULL;
> >+}
> >+}
> >+ }
>
> With https://git.kernel.org/netdev/net/c/00423969d806 that reverts
> stmmac_reinit_rx_buffers(), then the above dma_recycle_rx_skbufs()
> is no longer needed when net-next is sent for merge.
Thanks. I have added removal of that (now unused) function to my merge
resolution.
--
Cheers,
Stephen Rothwell
pgp7tmTAfcDCC.pgp
Description: OpenPGP digital signature
linux-next: Fixes tag needs some work in the iommu tree
Hi all,
In commit
af5247b169a0 ("iommu/mediatek: Always enable the clk on resume")
Fixes tag
Fixes: commit c0b57581b73b ("iommu/mediatek: Add power-domain operation")
has these problem(s):
- leading word 'commit' unexpected
--
Cheers,
Stephen Rothwell
pgpG5YnhRgXwK.pgp
Description: OpenPGP digital signature
Re: [PATCH v6 net-next] net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)
On Wed, 14 Apr 2021 22:45:19 -0700
Dexuan Cui wrote:
> +static int mana_probe_port(struct mana_context *ac, int port_idx,
> +struct net_device **ndev_storage)
> +{
> + struct gdma_context *gc = ac->gdma_dev->gdma_context;
> + struct mana_port_context *apc;
> + struct net_device *ndev;
> + int err;
> +
> + ndev = alloc_etherdev_mq(sizeof(struct mana_port_context),
> + gc->max_num_queues);
> + if (!ndev)
> + return -ENOMEM;
> +
> + *ndev_storage = ndev;
> +
> + apc = netdev_priv(ndev);
> + apc->ac = ac;
> + apc->ndev = ndev;
> + apc->max_queues = gc->max_num_queues;
> + apc->num_queues = min_t(uint, gc->max_num_queues, MANA_MAX_NUM_QUEUES);
> + apc->port_handle = INVALID_MANA_HANDLE;
> + apc->port_idx = port_idx;
> +
> + ndev->netdev_ops = &mana_devops;
> + ndev->ethtool_ops = &mana_ethtool_ops;
> + ndev->mtu = ETH_DATA_LEN;
> + ndev->max_mtu = ndev->mtu;
> + ndev->min_mtu = ndev->mtu;
> + ndev->needed_headroom = MANA_HEADROOM;
> + SET_NETDEV_DEV(ndev, gc->dev);
> +
> + netif_carrier_off(ndev);
> +
> + get_random_bytes(apc->hashkey, MANA_HASH_KEY_SIZE);
Current practice for network drivers is to use netdev_rss_key_fill() for this.
Re: [PATCH v6 net-next] net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)
On Wed, 14 Apr 2021 22:45:19 -0700
Dexuan Cui wrote:
> +static int mana_query_vport_cfg(struct mana_port_context *apc, u32
> vport_index,
> + u32 *max_sq, u32 *max_rq, u32 *num_indir_entry)
> +{
> + struct mana_query_vport_cfg_resp resp = {};
> + struct mana_query_vport_cfg_req req = {};
> + int err;
> +
> + mana_gd_init_req_hdr(&req.hdr, MANA_QUERY_VPORT_CONFIG,
> + sizeof(req), sizeof(resp));
> +
> + req.vport_index = vport_index;
> +
> + err = mana_send_request(apc->ac, &req, sizeof(req), &resp,
> + sizeof(resp));
> + if (err)
> + return err;
> +
> + err = mana_verify_resp_hdr(&resp.hdr, MANA_QUERY_VPORT_CONFIG,
> +sizeof(resp));
> + if (err)
> + return err;
> +
> + if (resp.hdr.status)
> + return -EPROTO;
> +
> + *max_sq = resp.max_num_sq;
> + *max_rq = resp.max_num_rq;
> + *num_indir_entry = resp.num_indirection_ent;
> +
> + apc->port_handle = resp.vport;
> + memcpy(apc->mac_addr, resp.mac_addr, ETH_ALEN);
You could use ether_addr_copy here.
> +int mana_do_attach(struct net_device *ndev, enum mana_attach_caller caller)
> +{
> + struct mana_port_context *apc = netdev_priv(ndev);
> + struct gdma_dev *gd = apc->ac->gdma_dev;
> + u32 max_txq, max_rxq, max_queues;
> + int port_idx = apc->port_idx;
> + u32 num_indirect_entries;
> + int err;
> +
> + if (caller == MANA_OPEN)
> + goto start_open;
> +
> + err = mana_init_port_context(apc);
> + if (err)
> + return err;
> +
> + err = mana_query_vport_cfg(apc, port_idx, &max_txq, &max_rxq,
> +&num_indirect_entries);
> + if (err) {
> + netdev_err(ndev, "Failed to query info for vPort 0\n");
> + goto reset_apc;
> + }
> +
> + max_queues = min_t(u32, max_txq, max_rxq);
> + if (apc->max_queues > max_queues)
> + apc->max_queues = max_queues;
> +
> + if (apc->num_queues > apc->max_queues)
> + apc->num_queues = apc->max_queues;
> +
> + memcpy(ndev->dev_addr, apc->mac_addr, ETH_ALEN);
And here use ether_addr_copy().
Re: [PATCH v2 3/3] drm/msm/dp: check main link status before start aux read
Quoting khs...@codeaurora.org (2021-04-15 10:37:29)
> On 2021-04-14 14:09, Stephen Boyd wrote:
> > Quoting Kuogee Hsieh (2021-04-13 16:11:44)
> >> Make sure main link is in connection state before start aux
> >> read/write operation to avoid unnecessary long delay due to
> >> main link had been unplugged.
> >>
> >> Signed-off-by: Kuogee Hsieh
> >> ---
> >> drivers/gpu/drm/msm/dp/dp_aux.c | 5 +
> >> drivers/gpu/drm/msm/dp/dp_link.c | 20 +++-
> >> 2 files changed, 20 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c
> >> b/drivers/gpu/drm/msm/dp/dp_aux.c
> >> index 7c22bfe..fae3806 100644
> >> --- a/drivers/gpu/drm/msm/dp/dp_aux.c
> >> +++ b/drivers/gpu/drm/msm/dp/dp_aux.c
> >> @@ -343,6 +343,11 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux
> >> *dp_aux,
> >>
> >> mutex_lock(&aux->mutex);
> >>
> >> + if (!dp_catalog_link_is_connected(aux->catalog)) {
> >> + ret = -ETIMEDOUT;
> >> + goto unlock_exit;
> >> + }
> >
> > I get a crash here sometimes when plugging and unplugging an apple HDMI
> > dongle during suspend/resume. I guess device power management
> > (dp_pm_suspend()) is happening in parallel with aux transfers from the
> > kthread. Why doesn't the aux communication start reporting NAKs once
> > the
> > cable is disconnected?
> >
> > [ 366.210058] hdmi-audio-codec hdmi-audio-codec.15.auto: calling
> > platform_pm_suspend+0x0/0x60 @ 7175, parent:
> > ae9.displayport-controller
> > [ 366.222825] hdmi-audio-codec hdmi-audio-codec.15.auto:
> > platform_pm_suspend+0x0/0x60 returned 0 after 1 usecs
> > [ 366.232939] msm-dp-display ae9.displayport-controller: calling
> > dp_pm_suspend+0x0/0x80 @ 7175, parent: ae0.mdss
> > [ 366.244006] msm-dp-display ae9.displayport-controller:
> > dp_pm_suspend+0x0/0x80 returned 0 after 79 usecs
> > [ 366.254025] msm_dsi ae94000.dsi: calling
> > pm_runtime_force_suspend+0x0/0xb4 @ 7175, parent: ae0.mdss
> > [ 366.263669] msm_dsi ae94000.dsi: pm_runtime_force_suspend+0x0/0xb4
> > returned 0 after 0 usecs
> > [ 366.272290] panel-simple panel: calling
> > platform_pm_suspend+0x0/0x60 @ 7175, parent: platform
> > [ 366.272501] ti_sn65dsi86 2-002d: calling
> > pm_runtime_force_suspend+0x0/0xb4 @ 176, parent: i2c-2
> > [ 366.281055] panel-simple panel: platform_pm_suspend+0x0/0x60
> > returned 0 after 0 usecs
> > [ 366.281081] leds mmc1::: calling led_suspend+0x0/0x4c @ 7175,
> > parent: 7c4000.sdhci
> > [ 366.290065] ti_sn65dsi86 2-002d: pm_runtime_force_suspend+0x0/0xb4
> > returned 0 after 0 usecs
> > [ 366.298046] leds mmc1::: led_suspend+0x0/0x4c returned 0 after 1
> > usecs
> > [ 366.302994] Internal error: synchronous external abort: 9610
> > [#1] PREEMPT SMP
> > [ 366.303006] Modules linked in: vhost_vsock
> > vmw_vsock_virtio_transport_common vsock vhost rfcomm algif_hash
> > algif_skcipher af_alg xt_cgroup uinput xt_MASQUERADE venus_enc
> > hci_uart venus_dec btqca cros_ec_typec typec bluetooth qcom_spmi_adc5
> > snd_soc_sc7180 qcom_spmi_temp_alarm ecdh_generic qcom_spmi_adc_tm5
> > qcom_vadc_common snd_soc_qcom_common ecc snd_soc_rt5682_i2c
> > snd_soc_rt5682 snd_soc_rl6231 venus_core v4l2_mem2mem
> > snd_soc_lpass_sc7180 snd_soc_lpass_hdmi snd_soc_lpass_cpu
> > snd_soc_lpass_platform snd_soc_max98357a fuse iio_trig_sysfs
> > cros_ec_sensors cros_ec_sensors_ring cros_ec_lid_angle
> > cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf
> > cros_ec_sensorhub lzo_rle lzo_compress zram ath10k_snoc ath10k_core
> > ath mac80211 cfg80211 cdc_ether usbnet r8152 mii uvcvideo
> > videobuf2_vmalloc joydev
> > [ 366.303211] CPU: 0 PID: 224 Comm: dp_hpd_handler Not tainted 5.4.109
> > #27
> > [ 366.303216] Hardware name: Google Lazor (rev3+) with KB Backlight
> > (DT)
> > [ 366.303225] pstate: 60c9 (nZCv daif +PAN +UAO)
> > [ 366.303234] pc : dp_catalog_link_is_connected+0x20/0x34
> > [ 366.303244] lr : dp_aux_transfer+0x44/0x284
> > [ 366.303250] sp : ffc011bfbbe0
> > [ 366.303254] x29: ffc011bfbbe0 x28:
> > [ 366.303262] x27: 000c x26: ff896f8212bc
> > [ 366.303269] x25: 0001 x24: 0001
> > [ 366.303275] x23: 0020 x22: ff896ff82118
> > [ 366.303282] x21: ffc011bfbc50 x20: ff896ff82090
> > [ 366.
Re: [PATCH] mmc: core: Don't allocate IDA for OF aliases
Quoting Ulf Hansson (2021-04-15 01:56:12)
> On Tue, 13 Apr 2021 at 02:36, Stephen Boyd wrote:
> >
> > - err = ida_simple_get(&mmc_host_ida, min_idx, max_idx, GFP_KERNEL);
> > - if (err < 0) {
> > - kfree(host);
> > - return NULL;
> > + index = ida_simple_get(&mmc_host_ida, min_idx, max_idx,
> > GFP_KERNEL);
> > + if (index < 0) {
> > + kfree(host);
> > + return NULL;
> > + }
>
> This means that a DTB that is screwed up in a way that it has two mmc
> aliases with the same index, would be allowed to use the same index.
>
> What will happen when we continue the probe sequence in such a case?
Yeah I thought about this after sending the patch. So the problem would
be like this right?
aliases {
mmc1 = &sdhci0;
mmc1 = &sdhci1;
};
I have good news! DT won't compile it because it saw the same alias
assigned to twice. I tried it on my sc7180 board.
arch/arm64/boot/dts/qcom/sc7180.dtsi:35.3-18:
ERROR (duplicate_property_names): /aliases:mmc1: Duplicate property name
ERROR: Input tree has errors, aborting (use -f to force output)
arch/arm64/boot/dts/qcom/sc7180-idp.dtb] Error 2
I suppose if someone forced the compilation it may be bad, but do we
really care?
TL;DR: this seems like it isn't a problem.
>
> > }
> >
> > - host->index = err;
> > + host->index = index;
> >
> > dev_set_name(&host->class_dev, "mmc%d", host->index);
> > host->ws = wakeup_source_register(NULL, dev_name(&host->class_dev));
>
> Another concern that could potentially be a problem, is that the
> "thread" that holds the reference that prevents ida from being
> removed, how would that react to a new mmc device to become
> re-registered with the same index?
>
> I wonder if we perhaps should return -EPROBE_DEFER instead, when
> ida_simple_get() fails?
>
Don't think so. The device (with the kobject inside) is removed, and
thus the mmc1 device will be removed, but the kobject's release function
is delayed due to the config. This means that
mmc_host_classdev_release() is called at a later time. The only thing
inside that function is the IDA removal and the kfree of the container
object. Given that nothing else is in that release function I believe it
is safe to skip IDA allocation as it won't be blocking anything in the
reserved alias case.
Furthermore, when the device is deleted in mmc_remove_host() there could
be other users of the device that haven't called put_device() yet.
Either way, those other users are keeping the device memory alive, but
otherwise device_del() has unlinked it from the various driver core
lists and sysfs has removed it too so it's in a state where code may be
referencing it but it's on the way out so users of the device will not
be able to do much with it during this time.
This sort of problem (if it exists which I don't think it does) would
have been there all along and can't be fixed at this level. When a
device that has an alias calls the mmc_alloc_host() function twice it
gets two different device structures created so there are two distinct
kobjects that will need to be released at some point. The index is
usually different for those two kobjects, but with aliases it turns out
it is the same. When it comes to registering that device with the same
name the second one will fail because a device with that name already
exists on the bus. This would be really hard to do given that it would
need to be the same aliased device in DT calling the mmc_add_host()
function without calling mmc_remove_host() for the first one it added in
between.
(Sorry if that is long. I'm sort of stream of conciousness writing it to
you here and not rewriting it to be more concise)
linux-next: Tree for Apr 15
Hi all, Changes since 20210414: The rdma tree gained a conflict against Linus' tree. The net-next tree gained a conflict against the net tree. The vfio tree gained a conflict against the drm tree. The akpm-current tree gained a conflict against the powerpc tree. Non-merge commits (relative to Linus' tree): 11858 10560 files changed, 579015 insertions(+), 265574 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig and htmldocs. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 338 trees (counting Linus' and 87 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (7f75285ca572 Merge tag 'for-5.12/dm-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm) Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2) Merging kbuild-current/fixes (bcbcf50f5218 kbuild: fix ld-version.sh to not be affected by locale) Merging arc-current/for-curr (163630b2d95b arc: Fix typos/spellos) Merging arm-current/fixes (30e3b4f256b4 ARM: footbridge: fix PCI interrupt mapping) Merging arm64-fixes/for-next/fixes (738fa58ee132 arm64: kprobes: Restore local irqflag if kprobes is cancelled) Merging arm-soc-fixes/arm/fixes (b9a9786a13ea Merge tag 'omap-for-v5.12/fixes-rc6-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes) Merging drivers-memory-fixes/fixes (a38fd8748464 Linux 5.12-rc2) Merging m68k-current/for-linus (a65a802aadba m68k: Fix virt_addr_valid() W=1 compiler warnings) Merging powerpc-fixes/fixes (791f9e36599d powerpc/vdso: Make sure vdso_wrapper.o is rebuilt everytime vdso.so is rebuilt) Merging s390-fixes/fixes (a994eddb947e s390/entry: save the caller of psw_idle) Merging sparc/master (05a59d79793d Merge git://git.kernel.org:/pub/scm/linux/kernel/git/netdev/net) Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption not used on new files) Merging net/master (00423969d806 Revert "net: stmmac: re-init rx buffers when mac resume back") Merging bpf/master (afd0be729953 libbpf: Fix potential NULL pointer dereference) Merging ipsec/master (6628ddfec758 net: geneve: check skb is large enough for IPv4/IPv6 header) Merging netfilter/master (ccb39c628558 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging ipvs/master (fbea31808ca1 netfilter: conntrack: do not print icmpv6 as unknown via /proc) Merging wireless-drivers/master (65db391dd874 iwlwifi: mvm: fix beacon protection checks) Merging mac80211/master (864db232dc70 net: ipv6: check for validity before dereferencing cfg->fc_nlinfo.nlh) Merging rdma-fixes/for-rc (d434405aaab7 Linux 5.12-rc7) Merging sound-current/for-linus (c8426b2700b5 ALSA: hda/realtek: Fix speaker amp setup on Acer Aspire E1) Merging sound-asoc-fixes/for-linus (2077f5503437 Merge remote-tracking branch 'asoc/for-5.12' into asoc-linus) Merging regmap-fixes/for-linus (78d889705732 Merge remote-tracking branch 'regmap/for-5.12' into regmap-linus) Merging regulator-fixes/for-linus (6068cc31dedd Merge remote-tracking branch 'regulator/for-5.12' into regulator-linus) Merging spi-fixes/for-linus (c730b40940f9 Merge remote-tracking branch 'spi/for-5.12' into spi-linus) Merging pci-current/for-linus (cf673bd0cc97 PCI: switchtec: F
Re: linux-next: manual merge of the akpm-current tree with the powerpc tree
Hi all,
On Thu, 15 Apr 2021 19:44:17 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> arch/powerpc/kernel/module.c
>
> between commit:
>
> 2ec13df16704 ("powerpc/modules: Load modules closer to kernel text")
>
> from the powerpc tree and commit:
>
> 4930ba789f8d ("powerpc/64s/radix: enable huge vmalloc mappings")
>
> from the akpm-current tree.
>
> I fixed it up (I think - see below) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/powerpc/kernel/module.c
> index fab84024650c,cdb2d88c54e7..
> --- a/arch/powerpc/kernel/module.c
> +++ b/arch/powerpc/kernel/module.c
> @@@ -88,29 -88,26 +89,42 @@@ int module_finalize(const Elf_Ehdr *hdr
> return 0;
> }
>
> - #ifdef MODULES_VADDR
> -void *module_alloc(unsigned long size)
> +static __always_inline void *
> +__module_alloc(unsigned long size, unsigned long start, unsigned long end)
> {
> -unsigned long start = VMALLOC_START;
> -unsigned long end = VMALLOC_END;
> -
> -#ifdef MODULES_VADDR
> -BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
> -start = MODULES_VADDR;
> -end = MODULES_END;
> -#endif
> -
> + /*
> + * Don't do huge page allocations for modules yet until more testing
> + * is done. STRICT_MODULE_RWX may require extra work to support this
> + * too.
> + */
> +
> return __vmalloc_node_range(size, 1, start, end, GFP_KERNEL,
> - PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS,
> NUMA_NO_NODE,
> + PAGE_KERNEL_EXEC,
> + VM_NO_HUGE_VMAP | VM_FLUSH_RESET_PERMS,
> + NUMA_NO_NODE,
> __builtin_return_address(0));
> }
> +
> ++
> +void *module_alloc(unsigned long size)
> +{
> ++unsigned long start = VMALLOC_START;
> ++unsigned long end = VMALLOC_END;
> +unsigned long limit = (unsigned long)_etext - SZ_32M;
> +void *ptr = NULL;
> +
> ++#ifdef MODULES_VADDR
> +BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
> ++start = MODULES_VADDR;
> ++end = MODULES_END;
> +
> +/* First try within 32M limit from _etext to avoid branch trampolines */
> +if (MODULES_VADDR < PAGE_OFFSET && MODULES_END > limit)
> - ptr = __module_alloc(size, limit, MODULES_END);
> ++ ptr = __module_alloc(size, limit, end);
> +
> +if (!ptr)
> - ptr = __module_alloc(size, MODULES_VADDR, MODULES_END);
> ++#endif
> ++ptr = __module_alloc(size, start, end);
> +
> +return ptr;
> +}
> - #endif
Unfortunately, it also needs this:
From: Stephen Rothwell
Date: Thu, 15 Apr 2021 19:53:58 +1000
Subject: [PATCH] merge fix up for powerpc merge fix
Signed-off-by: Stephen Rothwell
---
arch/powerpc/kernel/module.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
index d8ab1ad2eb05..c060f99afd4d 100644
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@ -110,7 +110,9 @@ void *module_alloc(unsigned long size)
{
unsigned long start = VMALLOC_START;
unsigned long end = VMALLOC_END;
+#ifdef MODULES_VADDR
unsigned long limit = (unsigned long)_etext - SZ_32M;
+#endif
void *ptr = NULL;
#ifdef MODULES_VADDR
--
2.30.2
--
Cheers,
Stephen Rothwell
pgpwiUNsqMujV.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with the powerpc tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/powerpc/kernel/module.c
between commit:
2ec13df16704 ("powerpc/modules: Load modules closer to kernel text")
from the powerpc tree and commit:
4930ba789f8d ("powerpc/64s/radix: enable huge vmalloc mappings")
from the akpm-current tree.
I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/powerpc/kernel/module.c
index fab84024650c,cdb2d88c54e7..
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@@ -88,29 -88,26 +89,42 @@@ int module_finalize(const Elf_Ehdr *hdr
return 0;
}
- #ifdef MODULES_VADDR
-void *module_alloc(unsigned long size)
+static __always_inline void *
+__module_alloc(unsigned long size, unsigned long start, unsigned long end)
{
- unsigned long start = VMALLOC_START;
- unsigned long end = VMALLOC_END;
-
-#ifdef MODULES_VADDR
- BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
- start = MODULES_VADDR;
- end = MODULES_END;
-#endif
-
+ /*
+* Don't do huge page allocations for modules yet until more testing
+* is done. STRICT_MODULE_RWX may require extra work to support this
+* too.
+*/
+
return __vmalloc_node_range(size, 1, start, end, GFP_KERNEL,
- PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS,
NUMA_NO_NODE,
+ PAGE_KERNEL_EXEC,
+ VM_NO_HUGE_VMAP | VM_FLUSH_RESET_PERMS,
+ NUMA_NO_NODE,
__builtin_return_address(0));
}
+
++
+void *module_alloc(unsigned long size)
+{
++ unsigned long start = VMALLOC_START;
++ unsigned long end = VMALLOC_END;
+ unsigned long limit = (unsigned long)_etext - SZ_32M;
+ void *ptr = NULL;
+
++#ifdef MODULES_VADDR
+ BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
++ start = MODULES_VADDR;
++ end = MODULES_END;
+
+ /* First try within 32M limit from _etext to avoid branch trampolines */
+ if (MODULES_VADDR < PAGE_OFFSET && MODULES_END > limit)
- ptr = __module_alloc(size, limit, MODULES_END);
++ ptr = __module_alloc(size, limit, end);
+
+ if (!ptr)
- ptr = __module_alloc(size, MODULES_VADDR, MODULES_END);
++#endif
++ ptr = __module_alloc(size, start, end);
+
+ return ptr;
+}
- #endif
pgpNvkByg9NJG.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the powerpc tree
Hi all,
After merging the powerpc tree, today's linux-next build (powerpc
allyesconfig) produced this warning:
In file included from include/linux/device.h:15,
from arch/powerpc/include/asm/io.h:27,
from include/linux/io.h:13,
from include/linux/irq.h:20,
from arch/powerpc/include/asm/hardirq.h:6,
from include/linux/hardirq.h:11,
from include/linux/highmem.h:10,
from include/linux/bio.h:8,
from include/linux/libnvdimm.h:14,
from arch/powerpc/platforms/pseries/papr_scm.c:12:
arch/powerpc/platforms/pseries/papr_scm.c: In function 'papr_scm_pmem_flush':
arch/powerpc/platforms/pseries/papr_scm.c:144:26: warning: format '%lld'
expects argument of type 'long long int', but argument 3 has type 'long int'
[-Wformat=]
144 | dev_err(&p->pdev->dev, "flush error: %lld", rc);
| ^~~
include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
19 | #define dev_fmt(fmt) fmt
| ^~~
arch/powerpc/platforms/pseries/papr_scm.c:144:3: note: in expansion of macro
'dev_err'
144 | dev_err(&p->pdev->dev, "flush error: %lld", rc);
| ^~~
arch/powerpc/platforms/pseries/papr_scm.c:144:43: note: format string is
defined here
144 | dev_err(&p->pdev->dev, "flush error: %lld", rc);
|~~~^
| |
| long long int
| %ld
Introduced by commit
75b7c05ebf90 ("powerpc/papr_scm: Implement support for H_SCM_FLUSH hcall")
--
Cheers,
Stephen Rothwell
pgpNgHPm4xr1X.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the vfio tree with the drm tree
Hi all,
Today's linux-next merge of the vfio tree got a conflict in:
drivers/gpu/drm/i915/gvt/gvt.c
between commit:
9ff06c385300 ("drm/i915/gvt: Remove references to struct drm_device.pdev")
from the drm tree and commit:
383987fd15ba ("vfio/gvt: Use mdev_get_type_group_id()")
from the vfio tree.
I fixed it up (I used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpau0KrImBu4.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
between commit:
00423969d806 ("Revert "net: stmmac: re-init rx buffers when mac resume back"")
from the net tree and commits:
bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy")
de0b90e52a11 ("net: stmmac: rearrange RX and TX desc init into per-queue
basis")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4749bd0af160,3a5ca5833ce1..
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@@ -1380,8 -1519,182 +1519,131 @@@ static void stmmac_free_tx_buffer(struc
}
/**
- * init_dma_rx_desc_rings - init the RX descriptor rings
- * @dev: net device structure
+ * dma_free_rx_skbufs - free RX dma buffers
+ * @priv: private structure
+ * @queue: RX queue index
+ */
+ static void dma_free_rx_skbufs(struct stmmac_priv *priv, u32 queue)
+ {
+ int i;
+
+ for (i = 0; i < priv->dma_rx_size; i++)
+ stmmac_free_rx_buffer(priv, queue, i);
+ }
+
+ static int stmmac_alloc_rx_buffers(struct stmmac_priv *priv, u32 queue,
+ gfp_t flags)
+ {
+ struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+ int i;
+
+ for (i = 0; i < priv->dma_rx_size; i++) {
+ struct dma_desc *p;
+ int ret;
+
+ if (priv->extend_desc)
+ p = &((rx_q->dma_erx + i)->basic);
+ else
+ p = rx_q->dma_rx + i;
+
+ ret = stmmac_init_rx_buffers(priv, p, i, flags,
+queue);
+ if (ret)
+ return ret;
+
+ rx_q->buf_alloc_num++;
+ }
+
+ return 0;
+ }
+
+ /**
+ * dma_recycle_rx_skbufs - recycle RX dma buffers
+ * @priv: private structure
+ * @queue: RX queue index
+ */
+ static void dma_recycle_rx_skbufs(struct stmmac_priv *priv, u32 queue)
+ {
+ struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+ int i;
+
+ for (i = 0; i < priv->dma_rx_size; i++) {
+ struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
+
+ if (buf->page) {
+ page_pool_recycle_direct(rx_q->page_pool, buf->page);
+ buf->page = NULL;
+ }
+
+ if (priv->sph && buf->sec_page) {
+ page_pool_recycle_direct(rx_q->page_pool,
buf->sec_page);
+ buf->sec_page = NULL;
+ }
+ }
+ }
+
+ /**
+ * dma_free_rx_xskbufs - free RX dma buffers from XSK pool
+ * @priv: private structure
+ * @queue: RX queue index
+ */
+ static void dma_free_rx_xskbufs(struct stmmac_priv *priv, u32 queue)
+ {
+ struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+ int i;
+
+ for (i = 0; i < priv->dma_rx_size; i++) {
+ struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
+
+ if (!buf->xdp)
+ continue;
+
+ xsk_buff_free(buf->xdp);
+ buf->xdp = NULL;
+ }
+ }
+
+ static int stmmac_alloc_rx_buffers_zc(struct stmmac_priv *priv, u32 queue)
+ {
+ struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+ int i;
+
+ for (i = 0; i < priv->dma_rx_size; i++) {
+ struct stmmac_rx_buffer *buf;
+ dma_addr_t dma_addr;
+ struct dma_desc *p;
+
+ if (priv->extend_desc)
+ p = (struct dma_desc *)(rx_q->dma_erx + i);
+ else
+ p = rx_q->dma_rx + i;
+
+ buf = &rx_q->buf_pool[i];
+
+ buf->xdp = xsk_buff_alloc(rx_q->xsk_pool);
+ if (!buf->xdp)
+ return -ENOMEM;
+
+ dma_addr = xsk_buff_xdp_get_dma(buf->xdp);
+ stmmac_set_desc_addr(priv, p, dma_addr);
+ rx_q->buf_alloc_num++;
+ }
+
+ return 0;
+ }
+
-/**
- * stmmac_reinit_rx_buffers - reinit the RX descriptor buffer.
- * @priv: driver private structure
- * Description: this function is called to re-allocate a receive buffer,
perform
- * the DMA mapping and init the descriptor.
- */
-static
linux-next: manual merge of the rdma tree with Linus' tree
Hi all,
Today's linux-next merge of the rdma tree got a conflict in:
drivers/infiniband/hw/hfi1/hfi.h
between commit:
5de61a47eb90 ("IB/hfi1: Fix probe time panic when AIP is enabled with a buggy
BIOS")
from Linus' tree and commit:
780278c2c8bb ("IB/hfi1: Rework AIP and VNIC dummy netdev usage")
from the rdma tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/infiniband/hw/hfi1/hfi.h
index 2a9a040569eb,2183d02ccfa2..
--- a/drivers/infiniband/hw/hfi1/hfi.h
+++ b/drivers/infiniband/hw/hfi1/hfi.h
@@@ -1408,8 -1402,7 +1402,8 @@@ struct hfi1_devdata
/* Lock to protect IRQ SRC register access */
spinlock_t irq_src_lock;
int vnic_num_vports;
- struct net_device *dummy_netdev;
+ struct hfi1_netdev_rx *netdev_rx;
+ struct hfi1_affinity_node *affinity_entry;
/* Keeps track of IPoIB RSM rule users */
atomic_t ipoib_rsm_usr_num;
pgpeGS0gS2kE3.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the powerpc tree
Hi all,
After merging the powerpc tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
drivers/macintosh/via-pmu.c:190:12: warning: '__fake_sleep' defined but not
used [-Wunused-variable]
190 | static int __fake_sleep;
|^~~~
Introduced by commit
95d143923379 ("macintosh/via-pmu: Make some symbols static")
--
Cheers,
Stephen Rothwell
pgpzhoRtj0jYy.pgp
Description: OpenPGP digital signature
linux-next: Fixes tag needs some work in the sound-asoc tree
Hi all,
In commit
a4856e15e58b ("ASoC: rsnd: check all BUSIF status when error")
Fixes tag
Fixes: commit 66c705d07d784 ("SoC: rsnd: add interrupt support for SSI BUSIF
buffer")
has these problem(s):
- leading word 'commit' unexpected
--
Cheers,
Stephen Rothwell
pgphHFEJb4NiG.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 2/3] drm/msm/dp: initialize audio_comp when audio starts
Quoting Kuogee Hsieh (2021-04-14 14:02:50)
> Initialize audio_comp when audio starts and wait for audio_comp at
> dp_display_disable(). This will take care of both dongle unplugged
> and display off (suspend) cases.
>
> Changes in v2:
> -- add dp_display_start_audio()
>
> Signed-off-by: Kuogee Hsieh
Looking better. Thanks!
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 0ba71c7..8a69bcd 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -177,6 +177,14 @@ static int dp_del_event(struct dp_display_private
> *dp_priv, u32 event)
>
> return 0;
> }
> +void dp_display_start_audio(struct msm_dp *dp_display)
Please unstick this from previous function by adding a newline above.
> +{
> + struct dp_display_private *dp;
> +
> + dp = container_of(dp_display, struct dp_display_private, dp_display);
> +
> + reinit_completion(&dp->audio_comp);
> +}
>
> void dp_display_signal_audio_complete(struct msm_dp *dp_display)
> {
> @@ -648,10 +656,6 @@ static int dp_hpd_unplug_handle(struct
> dp_display_private *dp, u32 data)
> /* start sentinel checking in case of missing uevent */
> dp_add_event(dp, EV_DISCONNECT_PENDING_TIMEOUT, 0,
> DP_TIMEOUT_5_SECOND);
>
> - /* signal the disconnect event early to ensure proper teardown */
This doesn't need to be done early anymore? Please mention why in the
commit text.
> - reinit_completion(&dp->audio_comp);
> - dp_display_handle_plugged_change(g_dp_display, false);
> -
> dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK |
> DP_DP_IRQ_HPD_INT_MASK, true);
>
> @@ -894,7 +898,6 @@ static int dp_display_disable(struct dp_display_private
> *dp, u32 data)
> /* wait only if audio was enabled */
> if (dp_display->audio_enabled) {
> /* signal the disconnect event */
> - reinit_completion(&dp->audio_comp);
> dp_display_handle_plugged_change(dp_display, false);
> if (!wait_for_completion_timeout(&dp->audio_comp,
> HZ * 5))
Re: [PATCH v2 1/3] drm/msm/dp: check sink_count before update is_connected status
Quoting Kuogee Hsieh (2021-04-14 14:02:34)
> Link status is different from display connected status in the case
> of something like an Apple dongle where the type-c plug can be
> connected, and therefore the link is connected, but no sink is
> connected until an HDMI cable is plugged into the dongle.
> The sink_count of DPCD of dongle will increase to 1 once an HDMI
> cable is plugged into the dongle so that display connected status
> will become true. This checking also apply at pm_resume.
>
> Fixes: 94e58e2d06e3 ("drm/msm/dp: reset dp controller only at boot up and
> pm_resume")
> Reported-by: Stephen Boyd
> Reviewed-by: Stephen Boyd
> Tested-by: Stephen Boyd
> Signed-off-by: Kuogee Hsieh
> ---
Can you please thread your emailed patches? I see them all as toplevel
messages in my inbox :(
> drivers/gpu/drm/msm/dp/dp_display.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 5a39da6..0ba71c7 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -586,10 +586,8 @@ static int dp_connect_pending_timeout(struct
> dp_display_private *dp, u32 data)
> mutex_lock(&dp->event_mutex);
>
> state = dp->hpd_state;
> - if (state == ST_CONNECT_PENDING) {
> - dp_display_enable(dp, 0);
> + if (state == ST_CONNECT_PENDING)
> dp->hpd_state = ST_CONNECTED;
> - }
>
> mutex_unlock(&dp->event_mutex);
>
> @@ -669,10 +667,8 @@ static int dp_disconnect_pending_timeout(struct
> dp_display_private *dp, u32 data
> mutex_lock(&dp->event_mutex);
>
> state = dp->hpd_state;
> - if (state == ST_DISCONNECT_PENDING) {
> - dp_display_disable(dp, 0);
> + if (state == ST_DISCONNECT_PENDING)
> dp->hpd_state = ST_DISCONNECTED;
> - }
>
> mutex_unlock(&dp->event_mutex);
>
> @@ -1272,7 +1268,12 @@ static int dp_pm_resume(struct device *dev)
>
> status = dp_catalog_link_is_connected(dp->catalog);
>
> - if (status)
> + /*
> +* can not declared display is connected unless
> +* HDMI cable is plugged in and sink_count of
> +* dongle become 1
> +*/
> + if (status && dp->link->sink_count)
> dp->dp_display.is_connected = true;
> else
> dp->dp_display.is_connected = false;
With this patch applied things still go wrong for me sometimes. I can
connect the apple dongle and then disconnect the apple dongle, instead
of connect and disconnect the HDMI cable, and sometimes the external
display doesn't come on. I'm still investigating but just wanted to let
you know.
Re: [PATCH v2 3/3] drm/msm/dp: check main link status before start aux read
Quoting Kuogee Hsieh (2021-04-13 16:11:44)
> Make sure main link is in connection state before start aux
> read/write operation to avoid unnecessary long delay due to
> main link had been unplugged.
>
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/gpu/drm/msm/dp/dp_aux.c | 5 +
> drivers/gpu/drm/msm/dp/dp_link.c | 20 +++-
> 2 files changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
> index 7c22bfe..fae3806 100644
> --- a/drivers/gpu/drm/msm/dp/dp_aux.c
> +++ b/drivers/gpu/drm/msm/dp/dp_aux.c
> @@ -343,6 +343,11 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
>
> mutex_lock(&aux->mutex);
>
> + if (!dp_catalog_link_is_connected(aux->catalog)) {
> + ret = -ETIMEDOUT;
> + goto unlock_exit;
> + }
I get a crash here sometimes when plugging and unplugging an apple HDMI
dongle during suspend/resume. I guess device power management
(dp_pm_suspend()) is happening in parallel with aux transfers from the
kthread. Why doesn't the aux communication start reporting NAKs once the
cable is disconnected?
[ 366.210058] hdmi-audio-codec hdmi-audio-codec.15.auto: calling
platform_pm_suspend+0x0/0x60 @ 7175, parent: ae9.displayport-controller
[ 366.222825] hdmi-audio-codec hdmi-audio-codec.15.auto:
platform_pm_suspend+0x0/0x60 returned 0 after 1 usecs
[ 366.232939] msm-dp-display ae9.displayport-controller: calling
dp_pm_suspend+0x0/0x80 @ 7175, parent: ae0.mdss
[ 366.244006] msm-dp-display ae9.displayport-controller:
dp_pm_suspend+0x0/0x80 returned 0 after 79 usecs
[ 366.254025] msm_dsi ae94000.dsi: calling pm_runtime_force_suspend+0x0/0xb4 @
7175, parent: ae0.mdss
[ 366.263669] msm_dsi ae94000.dsi: pm_runtime_force_suspend+0x0/0xb4 returned
0 after 0 usecs
[ 366.272290] panel-simple panel: calling platform_pm_suspend+0x0/0x60 @ 7175,
parent: platform
[ 366.272501] ti_sn65dsi86 2-002d: calling pm_runtime_force_suspend+0x0/0xb4 @
176, parent: i2c-2
[ 366.281055] panel-simple panel: platform_pm_suspend+0x0/0x60 returned 0
after 0 usecs
[ 366.281081] leds mmc1::: calling led_suspend+0x0/0x4c @ 7175, parent:
7c4000.sdhci
[ 366.290065] ti_sn65dsi86 2-002d: pm_runtime_force_suspend+0x0/0xb4 returned
0 after 0 usecs
[ 366.298046] leds mmc1::: led_suspend+0x0/0x4c returned 0 after 1 usecs
[ 366.302994] Internal error: synchronous external abort: 9610 [#1]
PREEMPT SMP
[ 366.303006] Modules linked in: vhost_vsock vmw_vsock_virtio_transport_common
vsock vhost rfcomm algif_hash algif_skcipher af_alg xt_cgroup uinput
xt_MASQUERADE venus_enc hci_uart venus_dec btqca cros_ec_typec typec bluetooth
qcom_spmi_adc5 snd_soc_sc7180 qcom_spmi_temp_alarm ecdh_generic
qcom_spmi_adc_tm5 qcom_vadc_common snd_soc_qcom_common ecc snd_soc_rt5682_i2c
snd_soc_rt5682 snd_soc_rl6231 venus_core v4l2_mem2mem snd_soc_lpass_sc7180
snd_soc_lpass_hdmi snd_soc_lpass_cpu snd_soc_lpass_platform snd_soc_max98357a
fuse iio_trig_sysfs cros_ec_sensors cros_ec_sensors_ring cros_ec_lid_angle
cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf cros_ec_sensorhub
lzo_rle lzo_compress zram ath10k_snoc ath10k_core ath mac80211 cfg80211
cdc_ether usbnet r8152 mii uvcvideo videobuf2_vmalloc joydev
[ 366.303211] CPU: 0 PID: 224 Comm: dp_hpd_handler Not tainted 5.4.109 #27
[ 366.303216] Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
[ 366.303225] pstate: 60c9 (nZCv daif +PAN +UAO)
[ 366.303234] pc : dp_catalog_link_is_connected+0x20/0x34
[ 366.303244] lr : dp_aux_transfer+0x44/0x284
[ 366.303250] sp : ffc011bfbbe0
[ 366.303254] x29: ffc011bfbbe0 x28:
[ 366.303262] x27: 000c x26: ff896f8212bc
[ 366.303269] x25: 0001 x24: 0001
[ 366.303275] x23: 0020 x22: ff896ff82118
[ 366.303282] x21: ffc011bfbc50 x20: ff896ff82090
[ 366.303289] x19: ff896ffc3598 x18:
[ 366.303295] x17: x16: 0001
[ 366.303303] x15: x14: 02ef
[ 366.303311] x13: 0400 x12: ffeb896ea060
[ 366.303317] x11: x10:
[ 366.303324] x9 : ff896f061100 x8 : ffc010582204
[ 366.303331] x7 : 00b2b5593519 x6 : 003033ff
[ 366.303338] x5 : x4 : 0001
[ 366.303345] x3 : ff896ff432a1 x2 :
[ 366.303352] x1 : 0119 x0 : ff896ffc3598
[ 366.303360] Call trace:
[ 366.303367] dp_catalog_link_is_connected+0x20/0x34
[ 366.303374] dp_aux_transfer+0x44/0x284
[ 366.303387] drm_dp_dpcd_access+0x8c/0x11c
[ 366.303393] drm_dp_dpcd_read+0x64/0x10c
[ 366.303399] dp_link_process_request+0x94/0xaf8
[ 366.303405] dp_display_usbpd_attention_cb+0x38/0x140
[ 366.303411] hpd_event_thread+0x3f0/0x48c
[ 366.303426] kthread+0x140/0x17c
[ 366.303439] ret_from_fork+0x1
Re: [Resend RFC PATCH V2 08/12] UIO/Hyper-V: Not load UIO HV driver in the isolation VM.
On Wed, 14 Apr 2021 17:45:51 +0200 Greg KH wrote: > On Wed, Apr 14, 2021 at 10:49:41AM -0400, Tianyu Lan wrote: > > From: Tianyu Lan > > > > UIO HV driver should not load in the isolation VM for security reason. > > Return ENOTSUPP in the hv_uio_probe() in the isolation VM. > > > > Signed-off-by: Tianyu Lan This is debatable, in isolation VM's shouldn't userspace take responsibility to validate host communication. If that is an issue please participate with the DPDK community (main user of this) to make sure netvsc userspace driver has the required checks.
Re: [PATCH v2] usb: dwc3: core: Add shutdown callback for dwc3
Quoting Sandeep Maheswaram (2021-04-13 23:03:29) > This patch adds a shutdown callback to USB DWC core driver to ensure that > it is properly shutdown in reboot/shutdown path. This is required > where SMMU address translation is enabled like on SC7180 > SoC and few others. If the hardware is still accessing memory after > SMMU translation is disabled as part of SMMU shutdown callback in > system reboot or shutdown path, then IOVAs(I/O virtual address) > which it was using will go on the bus as the physical addresses which > might result in unknown crashes (NoC/interconnect errors). > > Signed-off-by: Sandeep Maheswaram > --- Reviewed-by: Stephen Boyd
linux-next: Signed-off-by missing for commit in the drivers-x86 tree
Hi all,
Commit
ff57cfaa3d68 ("platform/x86: pmc_atom: Match all Beckhoff Automation baytrail
boards with critclk_systems DMI table")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpK7vO1nXM1y.pgp
Description: OpenPGP digital signature
linux-next: Tree for Apr 14
Hi all, Changes since 20210413: Non-merge commits (relative to Linus' tree): 11611 10392 files changed, 569164 insertions(+), 261078 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig and htmldocs. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 338 trees (counting Linus' and 87 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (eebe426d32e1 Merge tag 'fixes-for-5.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux) Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2) Merging kbuild-current/fixes (bcbcf50f5218 kbuild: fix ld-version.sh to not be affected by locale) Merging arc-current/for-curr (163630b2d95b arc: Fix typos/spellos) Merging arm-current/fixes (30e3b4f256b4 ARM: footbridge: fix PCI interrupt mapping) Merging arm64-fixes/for-next/fixes (738fa58ee132 arm64: kprobes: Restore local irqflag if kprobes is cancelled) Merging arm-soc-fixes/arm/fixes (b9a9786a13ea Merge tag 'omap-for-v5.12/fixes-rc6-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes) Merging drivers-memory-fixes/fixes (a38fd8748464 Linux 5.12-rc2) Merging m68k-current/for-linus (a65a802aadba m68k: Fix virt_addr_valid() W=1 compiler warnings) Merging powerpc-fixes/fixes (791f9e36599d powerpc/vdso: Make sure vdso_wrapper.o is rebuilt everytime vdso.so is rebuilt) Merging s390-fixes/fixes (a994eddb947e s390/entry: save the caller of psw_idle) Merging sparc/master (05a59d79793d Merge git://git.kernel.org:/pub/scm/linux/kernel/git/netdev/net) Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption not used on new files) Merging net/master (2afeec08ab5c xen-netback: Check for hotplug-status existence before watching) Merging bpf/master (afd0be729953 libbpf: Fix potential NULL pointer dereference) Merging ipsec/master (6628ddfec758 net: geneve: check skb is large enough for IPv4/IPv6 header) Merging netfilter/master (ccb39c628558 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging ipvs/master (fbea31808ca1 netfilter: conntrack: do not print icmpv6 as unknown via /proc) Merging wireless-drivers/master (65db391dd874 iwlwifi: mvm: fix beacon protection checks) Merging mac80211/master (864db232dc70 net: ipv6: check for validity before dereferencing cfg->fc_nlinfo.nlh) Merging rdma-fixes/for-rc (d434405aaab7 Linux 5.12-rc7) Merging sound-current/for-linus (c8426b2700b5 ALSA: hda/realtek: Fix speaker amp setup on Acer Aspire E1) Merging sound-asoc-fixes/for-linus (357505e41fb0 Merge remote-tracking branch 'asoc/for-5.12' into asoc-linus) Merging regmap-fixes/for-linus (78d889705732 Merge remote-tracking branch 'regmap/for-5.12' into regmap-linus) Merging regulator-fixes/for-linus (6068cc31dedd Merge remote-tracking branch 'regulator/for-5.12' into regulator-linus) Merging spi-fixes/for-linus (c730b40940f9 Merge remote-tracking branch 'spi/for-5.12' into spi-linus) Merging pci-current/for-linus (cf673bd0cc97 PCI: switchtec: Fix Spectre v1 vulnerability) Merging driver-core.current/driver-core-linus (d434405aaab7 Linux 5.12-rc7) Merging tty.current/tty-linus (e49d033bddf5 Linux 5.12-rc6) Merging usb.current/usb-linus (d434405aaab7 Linux 5.12-rc7) Merging usb-gadget-fixes/fixes (e49d033
