* [PATCH 1/2] KVM: arm/arm64: vgic: Use the appropriate TRACE_INCLUDE_PATH
From: Zenghui Yu @ 2019-09-11 2:33 UTC (permalink / raw)
To: maz, james.morse, julien.thierry.kdev, suzuki.poulose
Cc: linux-kernel, Masahiro Yamada, Zenghui Yu, wanghaibin.wang,
kvmarm, linux-arm-kernel
In-Reply-To: <1568169216-12632-1-git-send-email-yuzenghui@huawei.com>
Commit 49dfe94fe5ad ("KVM: arm/arm64: Fix TRACE_INCLUDE_PATH") fixes
TRACE_INCLUDE_PATH to the correct relative path to the define_trace.h
and explains why did the old one work.
The same fix should be applied to virt/kvm/arm/vgic/trace.h.
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
---
virt/kvm/arm/vgic/trace.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/arm/vgic/trace.h b/virt/kvm/arm/vgic/trace.h
index 55fed77a9f73..4fd4f6db181b 100644
--- a/virt/kvm/arm/vgic/trace.h
+++ b/virt/kvm/arm/vgic/trace.h
@@ -30,7 +30,7 @@ TRACE_EVENT(vgic_update_irq_pending,
#endif /* _TRACE_VGIC_H */
#undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH ../../../virt/kvm/arm/vgic
+#define TRACE_INCLUDE_PATH ../../virt/kvm/arm/vgic
#undef TRACE_INCLUDE_FILE
#define TRACE_INCLUDE_FILE trace
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] KVM: arm/arm64: Print the EC hex value with its exact width
From: Zenghui Yu @ 2019-09-11 2:33 UTC (permalink / raw)
To: maz, james.morse, julien.thierry.kdev, suzuki.poulose
Cc: Zenghui Yu, wanghaibin.wang, kvmarm, linux-arm-kernel,
linux-kernel
In-Reply-To: <1568169216-12632-1-git-send-email-yuzenghui@huawei.com>
EC is the bits [31:26] of ESR_ELx on arm64 (HSR on arm). Print the
hex value with its exact width (8).
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
---
virt/kvm/arm/trace.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/arm/trace.h b/virt/kvm/arm/trace.h
index 204d210d01c2..022b0a060034 100644
--- a/virt/kvm/arm/trace.h
+++ b/virt/kvm/arm/trace.h
@@ -42,7 +42,7 @@ TRACE_EVENT(kvm_exit,
__entry->vcpu_pc = vcpu_pc;
),
- TP_printk("%s: HSR_EC: 0x%04x (%s), PC: 0x%08lx",
+ TP_printk("%s: HSR_EC: 0x%02x (%s), PC: 0x%08lx",
__print_symbolic(__entry->ret, kvm_arm_exception_type),
__entry->esr_ec,
__print_symbolic(__entry->esr_ec, kvm_arm_exception_class),
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/2] KVM: arm/arm64: Two minor tracing changes
From: Zenghui Yu @ 2019-09-11 2:33 UTC (permalink / raw)
To: maz, james.morse, julien.thierry.kdev, suzuki.poulose
Cc: Zenghui Yu, wanghaibin.wang, kvmarm, linux-arm-kernel,
linux-kernel
This series includes two very minor tracing changes in KVM arm/arm64.
See patches for details. Thanks!
Zenghui Yu (2):
KVM: arm/arm64: vgic: Use the appropriate TRACE_INCLUDE_PATH
KVM: arm/arm64: Print the EC hex value with its exact width
virt/kvm/arm/trace.h | 2 +-
virt/kvm/arm/vgic/trace.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Peng Fan @ 2019-09-11 2:27 UTC (permalink / raw)
To: Andre Przywara, Jassi Brar
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190909143230.48b1143f@donnerap.cambridge.arm.com>
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
>
> On Fri, 30 Aug 2019 03:12:29 -0500
> Jassi Brar <jassisinghbrar@gmail.com> wrote:
>
> Hi,
>
> > On Fri, Aug 30, 2019 at 3:07 AM Peng Fan <peng.fan@nxp.com> wrote:
> > >
> > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc
> > > > for the ARM SMC/HVC mailbox
> > > >
> > > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan <peng.fan@nxp.com> wrote:
> > > > >
> > > > > Hi Jassi,
> > > > >
> > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding
> > > > > > doc for the ARM SMC/HVC mailbox
> > > > > >
> > > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan <peng.fan@nxp.com>
> wrote:
> > > > > >
> > > > > > > > > +examples:
> > > > > > > > > + - |
> > > > > > > > > + sram@910000 {
> > > > > > > > > + compatible = "mmio-sram";
> > > > > > > > > + reg = <0x0 0x93f000 0x0 0x1000>;
> > > > > > > > > + #address-cells = <1>;
> > > > > > > > > + #size-cells = <1>;
> > > > > > > > > + ranges = <0 0x0 0x93f000 0x1000>;
> > > > > > > > > +
> > > > > > > > > + cpu_scp_lpri: scp-shmem@0 {
> > > > > > > > > + compatible = "arm,scmi-shmem";
> > > > > > > > > + reg = <0x0 0x200>;
> > > > > > > > > + };
> > > > > > > > > +
> > > > > > > > > + cpu_scp_hpri: scp-shmem@200 {
> > > > > > > > > + compatible = "arm,scmi-shmem";
> > > > > > > > > + reg = <0x200 0x200>;
> > > > > > > > > + };
> > > > > > > > > + };
> > > > > > > > > +
> > > > > > > > > + firmware {
> > > > > > > > > + smc_mbox: mailbox {
> > > > > > > > > + #mbox-cells = <1>;
> > > > > > > > > + compatible = "arm,smc-mbox";
> > > > > > > > > + method = "smc";
> > > > > > > > > + arm,num-chans = <0x2>;
> > > > > > > > > + transports = "mem";
> > > > > > > > > + /* Optional */
> > > > > > > > > + arm,func-ids = <0xc20000fe>, <0xc20000ff>;
> > > > > > > > >
> > > > > > > > SMC/HVC is synchronously(block) running in "secure mode",
> > > > > > > > i.e, there can only be one instance running platform wide. Right?
> > > > > > >
> > > > > > > I think there could be channel for TEE, and channel for Linux.
> > > > > > > For virtualization case, there could be dedicated channel for each
> VM.
> > > > > > >
> > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above,
> > > > > > can't both be active at the same time, right?
> > > > >
> > > > > If I get your point correctly,
> > > > > On UP, both could not be active. On SMP, tx/rx could be both
> > > > > active, anyway this depends on secure firmware and Linux firmware
> design.
> > > > >
> > > > > Do you have any suggestions about arm,func-ids here?
> > > > >
> > > > I was thinking if this is just an instruction, why can't each
> > > > channel be represented as a controller, i.e, have exactly one func-id per
> controller node.
> > > > Define as many controllers as you need channels ?
> > >
> > > I am ok, this could make driver code simpler. Something as below?
> > >
> > > smc_tx_mbox: tx_mbox {
> > > #mbox-cells = <0>;
> > > compatible = "arm,smc-mbox";
> > > method = "smc";
> > > transports = "mem";
> > > arm,func-id = <0xc20000fe>;
> > > };
> > >
> > > smc_rx_mbox: rx_mbox {
> > > #mbox-cells = <0>;
> > > compatible = "arm,smc-mbox";
> > > method = "smc";
> > > transports = "mem";
> > > arm,func-id = <0xc20000ff>;
> > > };
> > >
> > > firmware {
> > > scmi {
> > > compatible = "arm,scmi";
> > > mboxes = <&smc_tx_mbox>, <&smc_rx_mbox 1>;
> > > mbox-names = "tx", "rx";
> > > shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>;
> > > };
> > > };
> > >
> > Yes, the channel part is good.
> > But I am not convinced by the need to have SCMI specific "transport" mode.
>
> Why would this be SCMI specific and what is the problem with having this
> property?
> By the very nature of the SMC/HVC call you would expect to also pass
> parameters in registers. However this limits the amount of data you can push,
> so the option of reverting to a memory based payload sounds very
> reasonable.
> On the other hand *just* using memory complicates things, in case you have a
> very simple protocol. You would need a memory region shared between
> firmware and OS, which is not always easily possible on every platform. Also
> this doesn't scale easily with multiple mailboxes and channels. Passing
> parameters via registers is also naturally consistent, as there would be no
> races and no need for synchronisation with other cores or other users of the
> mailbox.
>
> So I clearly see the benefit of specifying *both* ways of payload transport.
> Given that this driver should be protocol agnostic, it makes a lot of sense to
> introduce both methods *now*, so in the future users can just use the register
> method, without extending the binding in a incompatible way later (earlier
> kernels would have the driver, but wouldn't know how to deal with this
> parameter).
Andre, thanks for your explanation.
Jassi, are you ok that this property "transport" is kept in V6?
Thanks,
Peng.
>
> Cheers,
> Andre.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] arm64: dts: imx8mn: Use "fsl, imx8mm-ocotp" as ocotp's fallback compatible
From: Anson Huang @ 2019-09-11 14:24 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
leonard.crestez, daniel.lezcano, ping.bai, daniel.baluta, jun.li,
devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1568211887-19318-1-git-send-email-Anson.Huang@nxp.com>
Use "fsl,imx8mm-ocotp" as i.MX8MN ocotp's fallback compatible instead
of "fsl,imx7d-ocotp" to support SoC UID read, as i.MX8MN reuses
i.MX8MM's SoC ID driver.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index e4efe8d..6cb6c9c 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -337,7 +337,7 @@
};
ocotp: ocotp-ctrl@30350000 {
- compatible = "fsl,imx8mn-ocotp", "fsl,imx7d-ocotp", "syscon";
+ compatible = "fsl,imx8mn-ocotp", "fsl,imx8mm-ocotp", "syscon";
reg = <0x30350000 0x10000>;
clocks = <&clk IMX8MN_CLK_OCOTP_ROOT>;
#address-cells = <1>;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: imx8mm: Remove incorrect fallback compatible for ocotp
From: Anson Huang @ 2019-09-11 14:24 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
leonard.crestez, daniel.lezcano, ping.bai, daniel.baluta, jun.li,
devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
Compared to i.MX7D, i.MX8MM has different ocotp layout, so it should
NOT use "fsl,imx7d-ocotp" as ocotp's fallback compatible, remove it.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 5f9d0da..7c4dcce 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -426,7 +426,7 @@
};
ocotp: ocotp-ctrl@30350000 {
- compatible = "fsl,imx8mm-ocotp", "fsl,imx7d-ocotp", "syscon";
+ compatible = "fsl,imx8mm-ocotp", "syscon";
reg = <0x30350000 0x10000>;
clocks = <&clk IMX8MM_CLK_OCOTP_ROOT>;
/* For nvmem subnodes */
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 1/2] ARM: dts: opos6ul/opos6uldev: rework device tree to support i.MX6ULL
From: Shawn Guo @ 2019-09-11 2:11 UTC (permalink / raw)
To: Sébastien Szymanski
Cc: Mark Rutland, devicetree, Sascha Hauer, Rob Herring,
NXP Linux Team, Pengutronix Kernel Team, Fabio Estevam,
linux-arm-kernel
In-Reply-To: <194bd606-e4bf-d8fd-ece2-cbec1f5e025f@armadeus.com>
On Tue, Sep 03, 2019 at 09:38:11AM +0200, Sébastien Szymanski wrote:
> Hello,
>
> On 7/24/19 2:06 PM, Sébastien Szymanski wrote:
> > Rework the device trees of the OPOS6UL and OPOS6ULDev boards to support
> > the OPOS6UL SoM with an i.MX6ULL SoC. The device trees are now as
> > following:
> >
> > - imx6ul-imx6ull-opos6ul.dtsi
> > common for both i.MX6UL and i.MX6ULL OPOS6UL SoM.
> > - imx6ul-opos6ul.dtsi
> > for i.MX6UL OPOS6UL SoM. It includes imx6ul.dtsi and
> > imx6ul-imx6ull-opos6ul.dtsi.
> > - imx6ull-opos6ul.dtsi
> > for i.MX6ULL OPOS6UL SoM. It includes imx6ull.dtsi and
> > imx6ul-imx6ull-opos6ul.dtsi.
> >
> > - imx6ul-imx6ull-opos6uldev.dtsi
> > OPOS6ULDev base device tree.
> > - imx6ul-opos6uldev.dts
> > OPOS6ULDev board with an i.MX6UL OPOS6UL SoM. It includes
> > imx6ul-opos6ul.dtsi and imx6ul-imx6ull-opos6uldevdtsi.
> > - imx6ull-opos6uldev.dts
> > OPOS6ULDev board with an i.MX6ULL OPOS6UL SoM. It includes
> > imx6ull-opos6ul.dtsi and imx6ul-imx6ull-opos6uldevdtsi.
> >
> > Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
> > ---
> >
> > Changes for v2:
> > - explain the file hierarchy in the commit log
> > - use MIT license instead of X11
> > - Change compatible properties to "armadeus,imx6{ul,ull}-opos6ul" and
> > "armadeus,imx6{ul,ull}-opos6uldev" to follow the bindings of the
> > Armadeus boards already supported.
>
> gentle ping...
I missed the patches. Sorry about that. Just applied both.
Shawn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V2] arm: xen: mm: use __GPF_DMA32 for arm64
From: Peng Fan @ 2019-09-11 2:06 UTC (permalink / raw)
To: Stefano Stabellini, Christoph Hellwig
Cc: jgross@suse.com, Catalin Marinas, linux@armlinux.org.uk,
Julien Grall, dl-linux-imx, xen-devel@lists.xenproject.org,
boris.ostrovsky@oracle.com, nd, will@kernel.org,
linux-arm-kernel@lists.infradead.org, Robin Murphy
In-Reply-To: <alpine.DEB.2.21.1908301926500.21347@sstabellini-ThinkPad-T480s>
> Subject: Re: [PATCH V2] arm: xen: mm: use __GPF_DMA32 for arm64
>
> + Juergen, Boris
>
> On Fri, 30 Aug 2019, Christoph Hellwig wrote:
> > Can we take a step back and figure out what we want to do here?
> >
> > AFAICS this function allocates memory for the swiotlb-xen buffer, and
> > that means it must be <= 32-bit addressable to satisfy the DMA API
> > guarantees. That means we generally want to use GFP_DMA32
> everywhere
> > that exists, but on systems with odd zones we might want to dip into
> > GFP_DMA. This also means swiotlb-xen doesn't actually do the right
> > thing on x86 at the moment. So shouldn't we just have one common
> > routine in swiotlb-xen.c that checks if we have CONFIG_ZONE_DMA32 set,
> > then try GFP_DMA32, and if not check if CONFIG_ZONE_DMA is set and
> > then try that, else default to GFP_KERNEL?
>
> Yes, for ARM/ARM64 it makes a lot of sense given that dom0 is 1:1 mapped
> (pseudo-physical == physical). I'll let Juergen and Boris comment on the x86
> side of things, but on x86 PV Dom0 is not 1:1 mapped so
> GFP_DMA32 is probably not meaningful.
If we only take ARM/ARM64, so could the following patch be ok?
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index d33b77e9add3..e5a6a73b2e06 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -28,7 +28,11 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
for_each_memblock(memory, reg) {
if (reg->base < (phys_addr_t)0xffffffff) {
+#ifdef CONFIG_ZONE_DMA32
+ flags |= __GFP_DMA32;
+#else
flags |= __GFP_DMA;
+#endif
break;
}
}
Thanks,
Peng.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [GIT PULL 1/7] i.MX drivers update for 5.4
From: Shawn Guo @ 2019-09-11 1:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stefan Agner, Li Yang, SoC Team, arm-soc, NXP Linux Team,
Sascha Hauer, Fabio Estevam, Linux ARM
In-Reply-To: <CAK8P3a17J5aOyKN=q=CLQevUYeRFd0qpE_e5Cz8rSErbrMONyw@mail.gmail.com>
On Tue, Sep 03, 2019 at 10:58:51PM +0200, Arnd Bergmann wrote:
> On Sun, Aug 25, 2019 at 5:33 PM Shawn Guo <shawnguo@kernel.org> wrote:
> >
>
> > i.MX drivers update for 5.4:
> > - A series from Anson Huang to add UID support for i.MX8 SoC and SCU
> > drivers.
> > - A series from Daniel Baluta to add DSP IPC driver for communication
> > between host AP (Linux) and the firmware running on DSP embedded in
> > i.MX8 SoCs.
> > - A small fix for GPCv2 error code printing.
> > - Switch from module_platform_driver_probe() to module_platform_driver()
> > for imx-weim driver, as we need the driver to probe again when device
> > is present later.
> > - Add optional burst clock mode support for imx-weim driver.
>
> Pulled into arm/drivers.
>
> The module_platform_driver_probe() change looks like it should have been
> in a bugfix branch, and I think there were some other patches that would
> qualify in your other pull requests:
>
> a95fbda08ee2 ("ARM: dts: imx7-colibri: disable HS400")
> 9846a4524ac9 ("ARM: dts: imx7d: cl-som-imx7: make ethernet work again")
> 7cb220a75ff3 ("arm64: dts: lx2160a: Fix incorrect I2C clock divider")
> f64697bd0b9e ("arm64: dts: ls1028a: fix gpio nodes")
>
> There may have been good reasons to not include them in the fixes
> pull request, but my feeling is that you could be a little more aggressive
> in categorizing bugfixes for backports or adding Cc:stable tags.
Okay, noted. I was generally relying on author's opinion whether it's a
critical bug fix and should have stable tag.
Shawn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang
From: Sergey Senozhatsky @ 2019-09-11 1:10 UTC (permalink / raw)
To: Qian Cai
Cc: Petr Mladek, Theodore Ts'o, Sergey Senozhatsky, Arnd Bergmann,
Peter Zijlstra, Catalin Marinas, linux-kernel, Steven Rostedt,
linux-mm, Greg Kroah-Hartman, Waiman Long, Dan Williams,
Will Deacon, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <1568128954.5576.129.camel@lca.pw>
Cc-ing Ted, Arnd, Greg
On (09/10/19 11:22), Qian Cai wrote:
> [ 1078.283869][T43784] -> #3 (&(&port->lock)->rlock){-.-.}:
> [ 1078.291350][T43784] __lock_acquire+0x5c8/0xbb0
> [ 1078.296394][T43784] lock_acquire+0x154/0x428
> [ 1078.301266][T43784] _raw_spin_lock_irqsave+0x80/0xa0
> [ 1078.306831][T43784] tty_port_tty_get+0x28/0x68
> [ 1078.311873][T43784] tty_port_default_wakeup+0x20/0x40
> [ 1078.317523][T43784] tty_port_tty_wakeup+0x38/0x48
> [ 1078.322827][T43784] uart_write_wakeup+0x2c/0x50
> [ 1078.327956][T43784] pl011_tx_chars+0x240/0x260
> [ 1078.332999][T43784] pl011_start_tx+0x24/0xa8
> [ 1078.337868][T43784] __uart_start+0x90/0xa0
> [ 1078.342563][T43784] uart_write+0x15c/0x2c8
> [ 1078.347261][T43784] do_output_char+0x1c8/0x2b0
> [ 1078.352304][T43784] n_tty_write+0x300/0x668
> [ 1078.357087][T43784] tty_write+0x2e8/0x430
> [ 1078.361696][T43784] redirected_tty_write+0xcc/0xe8
> [ 1078.367086][T43784] do_iter_write+0x228/0x270
> [ 1078.372041][T43784] vfs_writev+0x10c/0x1c8
> [ 1078.376735][T43784] do_writev+0xdc/0x180
> [ 1078.381257][T43784] __arm64_sys_writev+0x50/0x60
> [ 1078.386476][T43784] el0_svc_handler+0x11c/0x1f0
> [ 1078.391606][T43784] el0_svc+0x8/0xc
> [ 1078.395691][T43784]
uart_port->lock -> tty_port->lock
This thing along is already a bit suspicious. We re-enter tty
here: tty -> uart -> serial -> tty
And we re-enter tty under uart_port->lock.
> [ 1078.395691][T43784] -> #2 (&port_lock_key){-.-.}:
> [ 1078.402561][T43784] __lock_acquire+0x5c8/0xbb0
> [ 1078.407604][T43784] lock_acquire+0x154/0x428
> [ 1078.412474][T43784] _raw_spin_lock+0x68/0x88
> [ 1078.417343][T43784] pl011_console_write+0x2ac/0x318
> [ 1078.422820][T43784] console_unlock+0x3c4/0x898
> [ 1078.427863][T43784] vprintk_emit+0x2d4/0x460
> [ 1078.432732][T43784] vprintk_default+0x48/0x58
> [ 1078.437688][T43784] vprintk_func+0x194/0x250
> [ 1078.442557][T43784] printk+0xbc/0xec
> [ 1078.446732][T43784] register_console+0x4a8/0x580
> [ 1078.451947][T43784] uart_add_one_port+0x748/0x878
> [ 1078.457250][T43784] pl011_register_port+0x98/0x128
> [ 1078.462639][T43784] sbsa_uart_probe+0x398/0x480
> [ 1078.467772][T43784] platform_drv_probe+0x70/0x108
> [ 1078.473075][T43784] really_probe+0x15c/0x5d8
> [ 1078.477944][T43784] driver_probe_device+0x94/0x1d0
> [ 1078.483335][T43784] __device_attach_driver+0x11c/0x1a8
> [ 1078.489072][T43784] bus_for_each_drv+0xf8/0x158
> [ 1078.494201][T43784] __device_attach+0x164/0x240
> [ 1078.499331][T43784] device_initial_probe+0x24/0x30
> [ 1078.504721][T43784] bus_probe_device+0xf0/0x100
> [ 1078.509850][T43784] device_add+0x63c/0x960
> [ 1078.514546][T43784] platform_device_add+0x1ac/0x3b8
> [ 1078.520023][T43784] platform_device_register_full+0x1fc/0x290
> [ 1078.526373][T43784] acpi_create_platform_device.part.0+0x264/0x3a8
> [ 1078.533152][T43784] acpi_create_platform_device+0x68/0x80
> [ 1078.539150][T43784] acpi_default_enumeration+0x34/0x78
> [ 1078.544887][T43784] acpi_bus_attach+0x340/0x3b8
> [ 1078.550015][T43784] acpi_bus_attach+0xf8/0x3b8
> [ 1078.555057][T43784] acpi_bus_attach+0xf8/0x3b8
> [ 1078.560099][T43784] acpi_bus_attach+0xf8/0x3b8
> [ 1078.565142][T43784] acpi_bus_scan+0x9c/0x100
> [ 1078.570015][T43784] acpi_scan_init+0x16c/0x320
> [ 1078.575058][T43784] acpi_init+0x330/0x3b8
> [ 1078.579666][T43784] do_one_initcall+0x158/0x7ec
> [ 1078.584797][T43784] kernel_init_freeable+0x9a8/0xa70
> [ 1078.590360][T43784] kernel_init+0x18/0x138
> [ 1078.595055][T43784] ret_from_fork+0x10/0x1c
>
> [ 1078.599835][T43784] -> #1 (console_owner){-...}:
> [ 1078.606618][T43784] __lock_acquire+0x5c8/0xbb0
> [ 1078.611661][T43784] lock_acquire+0x154/0x428
> [ 1078.616530][T43784] console_unlock+0x298/0x898
> [ 1078.621573][T43784] vprintk_emit+0x2d4/0x460
> [ 1078.626442][T43784] vprintk_default+0x48/0x58
> [ 1078.631398][T43784] vprintk_func+0x194/0x250
> [ 1078.636267][T43784] printk+0xbc/0xec
> [ 1078.640443][T43784] _warn_unseeded_randomness+0xb4/0xd0
> [ 1078.646267][T43784] get_random_u64+0x4c/0x100
> [ 1078.651224][T43784] add_to_free_area_random+0x168/0x1a0
> [ 1078.657047][T43784] free_one_page+0x3dc/0xd08
> [ 1078.662003][T43784] __free_pages_ok+0x490/0xd00
> [ 1078.667132][T43784] __free_pages+0xc4/0x118
> [ 1078.671914][T43784] __free_pages_core+0x2e8/0x428
> [ 1078.677219][T43784] memblock_free_pages+0xa4/0xec
> [ 1078.682522][T43784] memblock_free_all+0x264/0x330
> [ 1078.687825][T43784] mem_init+0x90/0x148
> [ 1078.692259][T43784] start_kernel+0x368/0x684
zone->lock --> uart_port->lock
Some debugging options/warnings/error print outs/etc introduce
deadlock patterns.
This adds zone->lock --> uart_port->lock, which then brings in
uart_port->lock --> tty_port->lock, which in turn brings
tty_port->lock --> zone->lock.
> [ 1078.697126][T43784] -> #0 (&(&zone->lock)->rlock){-.-.}:
> [ 1078.704604][T43784] check_prev_add+0x120/0x1138
> [ 1078.709733][T43784] validate_chain+0x888/0x1270
> [ 1078.714863][T43784] __lock_acquire+0x5c8/0xbb0
> [ 1078.719906][T43784] lock_acquire+0x154/0x428
> [ 1078.724776][T43784] _raw_spin_lock+0x68/0x88
> [ 1078.729645][T43784] rmqueue_bulk.constprop.21+0xb0/0x1218
> [ 1078.735643][T43784] get_page_from_freelist+0x898/0x24a0
> [ 1078.741467][T43784] __alloc_pages_nodemask+0x2a8/0x1d08
> [ 1078.747291][T43784] alloc_pages_current+0xb4/0x150
> [ 1078.752682][T43784] allocate_slab+0xab8/0x2350
> [ 1078.757725][T43784] new_slab+0x98/0xc0
> [ 1078.762073][T43784] ___slab_alloc+0x66c/0xa30
> [ 1078.767029][T43784] __slab_alloc+0x68/0xc8
> [ 1078.771725][T43784] __kmalloc+0x3d4/0x658
> [ 1078.776333][T43784] __tty_buffer_request_room+0xd4/0x220
> [ 1078.782244][T43784] tty_insert_flip_string_fixed_flag+0x6c/0x128
> [ 1078.788849][T43784] pty_write+0x98/0x100
> [ 1078.793370][T43784] n_tty_write+0x2a0/0x668
> [ 1078.798152][T43784] tty_write+0x2e8/0x430
> [ 1078.802760][T43784] __vfs_write+0x5c/0xb0
> [ 1078.807368][T43784] vfs_write+0xf0/0x230
> [ 1078.811890][T43784] ksys_write+0xd4/0x180
> [ 1078.816498][T43784] __arm64_sys_write+0x4c/0x60
> [ 1078.821627][T43784] el0_svc_handler+0x11c/0x1f0
> [ 1078.826756][T43784] el0_svc+0x8/0xc
tty_port->lock --> zone->lock
> [ 1078.830842][T43784] other info that might help us debug this:
> [ 1078.830842][T43784]
> [ 1078.840918][T43784] Chain exists of:
> [ 1078.840918][T43784] &(&zone->lock)->rlock --> &port_lock_key --> &(&port-> >lock)->rlock
> [ 1078.840918][T43784]
> [ 1078.854731][T43784] Possible unsafe locking scenario:
> [ 1078.854731][T43784]
> [ 1078.862029][T43784] CPU0 CPU1
> [ 1078.867243][T43784] ---- ----
> [ 1078.872457][T43784] lock(&(&port->lock)->rlock);
> [ 1078.877238][T43784] lock(&port_lock_key);
> [ 1078.883929][T43784] lock(&(&port->lock)->rlock);
> [ 1078.891228][T43784] lock(&(&zone->lock)->rlock);
> [ 1078.896010][T43784]
> [ 1078.896010][T43784] *** DEADLOCK ***
[..]
> [ 1078.980932][T43784] dump_backtrace+0x0/0x228
> [ 1078.985279][T43784] show_stack+0x24/0x30
> [ 1078.989282][T43784] dump_stack+0xe8/0x13c
> [ 1078.993370][T43784] print_circular_bug+0x334/0x3d8
> [ 1078.998240][T43784] check_noncircular+0x268/0x310
> [ 1079.003022][T43784] check_prev_add+0x120/0x1138
> [ 1079.007631][T43784] validate_chain+0x888/0x1270
> [ 1079.012241][T43784] __lock_acquire+0x5c8/0xbb0
> [ 1079.016763][T43784] lock_acquire+0x154/0x428
> [ 1079.021111][T43784] _raw_spin_lock+0x68/0x88
> [ 1079.025460][T43784] rmqueue_bulk.constprop.21+0xb0/0x1218
> [ 1079.030937][T43784] get_page_from_freelist+0x898/0x24a0
> [ 1079.036240][T43784] __alloc_pages_nodemask+0x2a8/0x1d08
> [ 1079.041542][T43784] alloc_pages_current+0xb4/0x150
> [ 1079.046412][T43784] allocate_slab+0xab8/0x2350
> [ 1079.050934][T43784] new_slab+0x98/0xc0
> [ 1079.054761][T43784] ___slab_alloc+0x66c/0xa30
> [ 1079.059196][T43784] __slab_alloc+0x68/0xc8
> [ 1079.063371][T43784] __kmalloc+0x3d4/0x658
> [ 1079.067458][T43784] __tty_buffer_request_room+0xd4/0x220
> [ 1079.072847][T43784] tty_insert_flip_string_fixed_flag+0x6c/0x128
> [ 1079.078932][T43784] pty_write+0x98/0x100
> [ 1079.082932][T43784] n_tty_write+0x2a0/0x668
> [ 1079.087193][T43784] tty_write+0x2e8/0x430
> [ 1079.091280][T43784] __vfs_write+0x5c/0xb0
> [ 1079.095367][T43784] vfs_write+0xf0/0x230
> [ 1079.099368][T43784] ksys_write+0xd4/0x180
> [ 1079.103455][T43784] __arm64_sys_write+0x4c/0x60
> [ 1079.108064][T43784] el0_svc_handler+0x11c/0x1f0
> [ 1079.112672][T43784] el0_svc+0x8/0xc
tty_port->lock --> zone->lock
For instance, I don't really like the re-entrant tty, at least not
under uart_port->lock. This, maybe, can be one of the solutions.
Another one, a quick and dirty one, (and so many people will blame
me for this) would be to break zone->{printk}->uart chain...
Something like this
---
drivers/char/random.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 9b54cdb301d3..975015857200 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1687,8 +1687,9 @@ static void _warn_unseeded_randomness(const char *func_name, void *caller,
print_once = true;
#endif
if (__ratelimit(&unseeded_warning))
- pr_notice("random: %s called from %pS with crng_init=%d\n",
- func_name, caller, crng_init);
+ printk_deferred(KERN_NOTICE "random: %s called from %pS "
+ "with crng_init=%d\n", func_name, caller,
+ crng_init);
}
/*
@@ -2462,4 +2463,4 @@ void add_bootloader_randomness(const void *buf, unsigned int size)
else
add_device_randomness(buf, size);
}
-EXPORT_SYMBOL_GPL(add_bootloader_randomness);
\ No newline at end of file
+EXPORT_SYMBOL_GPL(add_bootloader_randomness);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] pinctrl: at91-pio4: implement .get_multiple and .set_multiple
From: Linus Walleij @ 2019-09-11 0:27 UTC (permalink / raw)
To: Alexandre Belloni
Cc: open list:GPIO SUBSYSTEM, Ludovic Desroches, Linux ARM,
linux-kernel@vger.kernel.org
In-Reply-To: <20190905141304.22005-1-alexandre.belloni@bootlin.com>
On Thu, Sep 5, 2019 at 3:13 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> Implement .get_multiple and .set_multiple to allow reading or setting
> multiple pins simultaneously. Pins in the same bank will all be switched at
> the same time, improving synchronization and performances.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Good initiative!
> + for (bank = 0; bank < atmel_pioctrl->nbanks; bank++) {> + unsigned int word = bank;
> + unsigned int offset = 0;
> + unsigned int reg;
> +
> +#if ATMEL_PIO_NPINS_PER_BANK != BITS_PER_LONG
Should it not be > rather than != ?
> + word = BIT_WORD(bank * ATMEL_PIO_NPINS_PER_BANK);
> + offset = bank * ATMEL_PIO_NPINS_PER_BANK % BITS_PER_LONG;
> +#endif
This doesn't look good for multiplatform kernels.
We need to get rid of any compiletime constants like this.
Not your fault I suppose it is already there, but this really need
to be fixed. Any ideas?
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] crypto: arm64/gcm-ce - implement 4 way interleave
From: Ard Biesheuvel @ 2019-09-10 23:19 UTC (permalink / raw)
To: linux-crypto
Cc: marc.zyngier, Ard Biesheuvel, herbert, linux-arm-kernel, ebiggers
In-Reply-To: <20190910231900.25445-1-ard.biesheuvel@linaro.org>
To improve performance on cores with deep pipelines such as ThunderX2,
reimplement gcm(aes) using a 4-way interleave rather than the 2-way
interleave we use currently.
This comes down to a complete rewrite of the GCM part of the combined
GCM/GHASH driver, and instead of interleaving two invocations of AES
with the GHASH handling at the instruction level, the new version
uses a more coarse grained approach where each chunk of 64 bytes is
encrypted first and then ghashed (or ghashed and then decrypted in
the converse case).
The core NEON routine is now able to consume inputs of any size,
and tail blocks of less than 64 bytes are handled using overlapping
loads and stores, and processed by the same 4-way encryption and
hashing routines. This gets rid of most of the branches, and avoids
having to return to the C code to handle the tail block using a
stack buffer.
The table below compares the performance of the old driver and the new
one on various micro-architectures and running in various modes.
| AES-128 | AES-192 | AES-256 |
#bytes | 512 | 1500 | 4k | 512 | 1500 | 4k | 512 | 1500 | 4k |
-------+-----+------+-----+-----+------+-----+-----+------+-----+
TX2 | 35% | 23% | 11% | 34% | 20% | 9% | 38% | 25% | 16% |
EMAG | 11% | 6% | 3% | 12% | 4% | 2% | 11% | 4% | 2% |
A72 | 8% | 5% | -4% | 9% | 4% | -5% | 7% | 4% | -5% |
A53 | 11% | 6% | -1% | 10% | 8% | -1% | 10% | 8% | -2% |
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/ghash-ce-core.S | 501 ++++++++++++++------
arch/arm64/crypto/ghash-ce-glue.c | 293 +++++-------
2 files changed, 467 insertions(+), 327 deletions(-)
diff --git a/arch/arm64/crypto/ghash-ce-core.S b/arch/arm64/crypto/ghash-ce-core.S
index 410e8afcf5a7..a791c4adf8e6 100644
--- a/arch/arm64/crypto/ghash-ce-core.S
+++ b/arch/arm64/crypto/ghash-ce-core.S
@@ -13,8 +13,8 @@
T1 .req v2
T2 .req v3
MASK .req v4
- XL .req v5
- XM .req v6
+ XM .req v5
+ XL .req v6
XH .req v7
IN1 .req v7
@@ -358,20 +358,37 @@ ENTRY(pmull_ghash_update_p8)
__pmull_ghash p8
ENDPROC(pmull_ghash_update_p8)
- KS0 .req v12
- KS1 .req v13
- INP0 .req v14
- INP1 .req v15
-
- .macro load_round_keys, rounds, rk
- cmp \rounds, #12
- blo 2222f /* 128 bits */
- beq 1111f /* 192 bits */
- ld1 {v17.4s-v18.4s}, [\rk], #32
-1111: ld1 {v19.4s-v20.4s}, [\rk], #32
-2222: ld1 {v21.4s-v24.4s}, [\rk], #64
- ld1 {v25.4s-v28.4s}, [\rk], #64
- ld1 {v29.4s-v31.4s}, [\rk]
+ KS0 .req v8
+ KS1 .req v9
+ KS2 .req v10
+ KS3 .req v11
+
+ INP0 .req v21
+ INP1 .req v22
+ INP2 .req v23
+ INP3 .req v24
+
+ K0 .req v25
+ K1 .req v26
+ K2 .req v27
+ K3 .req v28
+ K4 .req v12
+ K5 .req v13
+ K6 .req v4
+ K7 .req v5
+ K8 .req v14
+ K9 .req v15
+ KK .req v29
+ KL .req v30
+ KM .req v31
+
+ .macro load_round_keys, rounds, rk, tmp
+ add \tmp, \rk, #64
+ ld1 {K0.4s-K3.4s}, [\rk]
+ ld1 {K4.4s-K5.4s}, [\tmp]
+ add \tmp, \rk, \rounds, lsl #4
+ sub \tmp, \tmp, #32
+ ld1 {KK.4s-KM.4s}, [\tmp]
.endm
.macro enc_round, state, key
@@ -379,197 +396,367 @@ ENDPROC(pmull_ghash_update_p8)
aesmc \state\().16b, \state\().16b
.endm
- .macro enc_block, state, rounds
- cmp \rounds, #12
- b.lo 2222f /* 128 bits */
- b.eq 1111f /* 192 bits */
- enc_round \state, v17
- enc_round \state, v18
-1111: enc_round \state, v19
- enc_round \state, v20
-2222: .irp key, v21, v22, v23, v24, v25, v26, v27, v28, v29
+ .macro enc_qround, s0, s1, s2, s3, key
+ enc_round \s0, \key
+ enc_round \s1, \key
+ enc_round \s2, \key
+ enc_round \s3, \key
+ .endm
+
+ .macro enc_block, state, rounds, rk, tmp
+ add \tmp, \rk, #96
+ ld1 {K6.4s-K7.4s}, [\tmp], #32
+ .irp key, K0, K1, K2, K3, K4 K5
enc_round \state, \key
.endr
- aese \state\().16b, v30.16b
- eor \state\().16b, \state\().16b, v31.16b
+
+ tbnz \rounds, #2, .Lnot128_\@
+.Lout256_\@:
+ enc_round \state, K6
+ enc_round \state, K7
+
+.Lout192_\@:
+ enc_round \state, KK
+ aese \state\().16b, KL.16b
+ eor \state\().16b, \state\().16b, KM.16b
+
+ .subsection 1
+.Lnot128_\@:
+ ld1 {K8.4s-K9.4s}, [\tmp], #32
+ enc_round \state, K6
+ enc_round \state, K7
+ ld1 {K6.4s-K7.4s}, [\tmp]
+ enc_round \state, K8
+ enc_round \state, K9
+ tbz \rounds, #1, .Lout192_\@
+ b .Lout256_\@
+ .previous
.endm
+ .align 6
.macro pmull_gcm_do_crypt, enc
- ld1 {SHASH.2d}, [x4], #16
- ld1 {HH.2d}, [x4]
- ld1 {XL.2d}, [x1]
- ldr x8, [x5, #8] // load lower counter
+ stp x29, x30, [sp, #-32]!
+ mov x29, sp
+ str x19, [sp, #24]
+
+ load_round_keys x7, x6, x8
+
+ ld1 {SHASH.2d}, [x3], #16
+ ld1 {HH.2d-HH4.2d}, [x3]
- movi MASK.16b, #0xe1
trn1 SHASH2.2d, SHASH.2d, HH.2d
trn2 T1.2d, SHASH.2d, HH.2d
-CPU_LE( rev x8, x8 )
- shl MASK.2d, MASK.2d, #57
eor SHASH2.16b, SHASH2.16b, T1.16b
- .if \enc == 1
- ldr x10, [sp]
- ld1 {KS0.16b-KS1.16b}, [x10]
- .endif
+ trn1 HH34.2d, HH3.2d, HH4.2d
+ trn2 T1.2d, HH3.2d, HH4.2d
+ eor HH34.16b, HH34.16b, T1.16b
- cbnz x6, 4f
+ ld1 {XL.2d}, [x4]
-0: ld1 {INP0.16b-INP1.16b}, [x3], #32
+ cbz x0, 3f // tag only?
- rev x9, x8
- add x11, x8, #1
- add x8, x8, #2
+ ldr w8, [x5, #12] // load lower counter
+CPU_LE( rev w8, w8 )
- .if \enc == 1
- eor INP0.16b, INP0.16b, KS0.16b // encrypt input
- eor INP1.16b, INP1.16b, KS1.16b
+0: mov w9, #4 // max blocks per round
+ add x10, x0, #0xf
+ lsr x10, x10, #4 // remaining blocks
+
+ subs x0, x0, #64
+ csel w9, w10, w9, mi
+ add w8, w8, w9
+
+ bmi 1f
+ ld1 {INP0.16b-INP3.16b}, [x2], #64
+ .subsection 1
+ /*
+ * Populate the four input registers right to left with up to 63 bytes
+ * of data, using overlapping loads to avoid branches.
+ *
+ * INP0 INP1 INP2 INP3
+ * 1 byte | | | |x |
+ * 16 bytes | | | |xxxxxxxx|
+ * 17 bytes | | |xxxxxxxx|x |
+ * 47 bytes | |xxxxxxxx|xxxxxxxx|xxxxxxx |
+ * etc etc
+ *
+ * Note that this code may read up to 15 bytes before the start of
+ * the input. It is up to the calling code to ensure this is safe if
+ * this happens in the first iteration of the loop (i.e., when the
+ * input size is < 16 bytes)
+ */
+1: mov x15, #16
+ ands x19, x0, #0xf
+ csel x19, x19, x15, ne
+ adr_l x17, .Lpermute_table + 16
+
+ sub x11, x15, x19
+ add x12, x17, x11
+ sub x17, x17, x11
+ ld1 {T1.16b}, [x12]
+ sub x10, x1, x11
+ sub x11, x2, x11
+
+ cmp x0, #-16
+ csel x14, x15, xzr, gt
+ cmp x0, #-32
+ csel x15, x15, xzr, gt
+ cmp x0, #-48
+ csel x16, x19, xzr, gt
+ csel x1, x1, x10, gt
+ csel x2, x2, x11, gt
+
+ ld1 {INP0.16b}, [x2], x14
+ ld1 {INP1.16b}, [x2], x15
+ ld1 {INP2.16b}, [x2], x16
+ ld1 {INP3.16b}, [x2]
+ tbl INP3.16b, {INP3.16b}, T1.16b
+ b 2f
+ .previous
+
+2: .if \enc == 0
+ bl pmull_gcm_ghash_4x
.endif
- ld1 {KS0.8b}, [x5] // load upper counter
- rev x11, x11
- sub w0, w0, #2
- mov KS1.8b, KS0.8b
- ins KS0.d[1], x9 // set lower counter
- ins KS1.d[1], x11
+ bl pmull_gcm_enc_4x
- rev64 T1.16b, INP1.16b
+ tbnz x0, #63, 6f
+ st1 {INP0.16b-INP3.16b}, [x1], #64
+ .if \enc == 1
+ bl pmull_gcm_ghash_4x
+ .endif
+ bne 0b
- cmp w7, #12
- b.ge 2f // AES-192/256?
+3: ldp x19, x10, [sp, #24]
+ cbz x10, 5f // output tag?
-1: enc_round KS0, v21
- ext IN1.16b, T1.16b, T1.16b, #8
+ ld1 {INP3.16b}, [x10] // load lengths[]
+ mov w9, #1
+ bl pmull_gcm_ghash_4x
- enc_round KS1, v21
- pmull2 XH2.1q, SHASH.2d, IN1.2d // a1 * b1
+ mov w11, #(0x1 << 24) // BE '1U'
+ ld1 {KS0.16b}, [x5]
+ mov KS0.s[3], w11
- enc_round KS0, v22
- eor T1.16b, T1.16b, IN1.16b
+ enc_block KS0, x7, x6, x12
- enc_round KS1, v22
- pmull XL2.1q, SHASH.1d, IN1.1d // a0 * b0
+ ext XL.16b, XL.16b, XL.16b, #8
+ rev64 XL.16b, XL.16b
+ eor XL.16b, XL.16b, KS0.16b
+ st1 {XL.16b}, [x10] // store tag
- enc_round KS0, v23
- pmull XM2.1q, SHASH2.1d, T1.1d // (a1 + a0)(b1 + b0)
+4: ldp x29, x30, [sp], #32
+ ret
- enc_round KS1, v23
- rev64 T1.16b, INP0.16b
- ext T2.16b, XL.16b, XL.16b, #8
+5:
+CPU_LE( rev w8, w8 )
+ str w8, [x5, #12] // store lower counter
+ st1 {XL.2d}, [x4]
+ b 4b
+
+6: ld1 {T1.16b-T2.16b}, [x17], #32 // permute vectors
+ sub x17, x17, x19, lsl #1
+
+ cmp w9, #1
+ beq 7f
+ .subsection 1
+7: ld1 {INP2.16b}, [x1]
+ tbx INP2.16b, {INP3.16b}, T1.16b
+ mov INP3.16b, INP2.16b
+ b 8f
+ .previous
+
+ st1 {INP0.16b}, [x1], x14
+ st1 {INP1.16b}, [x1], x15
+ st1 {INP2.16b}, [x1], x16
+ tbl INP3.16b, {INP3.16b}, T1.16b
+ tbx INP3.16b, {INP2.16b}, T2.16b
+8: st1 {INP3.16b}, [x1]
- enc_round KS0, v24
- ext IN1.16b, T1.16b, T1.16b, #8
- eor T1.16b, T1.16b, T2.16b
+ .if \enc == 1
+ ld1 {T1.16b}, [x17]
+ tbl INP3.16b, {INP3.16b}, T1.16b // clear non-data bits
+ bl pmull_gcm_ghash_4x
+ .endif
+ b 3b
+ .endm
- enc_round KS1, v24
- eor XL.16b, XL.16b, IN1.16b
+ /*
+ * void pmull_gcm_encrypt(int blocks, u8 dst[], const u8 src[],
+ * struct ghash_key const *k, u64 dg[], u8 ctr[],
+ * int rounds, u8 tag)
+ */
+ENTRY(pmull_gcm_encrypt)
+ pmull_gcm_do_crypt 1
+ENDPROC(pmull_gcm_encrypt)
- enc_round KS0, v25
- eor T1.16b, T1.16b, XL.16b
+ /*
+ * void pmull_gcm_decrypt(int blocks, u8 dst[], const u8 src[],
+ * struct ghash_key const *k, u64 dg[], u8 ctr[],
+ * int rounds, u8 tag)
+ */
+ENTRY(pmull_gcm_decrypt)
+ pmull_gcm_do_crypt 0
+ENDPROC(pmull_gcm_decrypt)
- enc_round KS1, v25
- pmull2 XH.1q, HH.2d, XL.2d // a1 * b1
+pmull_gcm_ghash_4x:
+ movi MASK.16b, #0xe1
+ shl MASK.2d, MASK.2d, #57
- enc_round KS0, v26
- pmull XL.1q, HH.1d, XL.1d // a0 * b0
+ rev64 T1.16b, INP0.16b
+ rev64 T2.16b, INP1.16b
+ rev64 TT3.16b, INP2.16b
+ rev64 TT4.16b, INP3.16b
- enc_round KS1, v26
- pmull2 XM.1q, SHASH2.2d, T1.2d // (a1 + a0)(b1 + b0)
+ ext XL.16b, XL.16b, XL.16b, #8
- enc_round KS0, v27
- eor XL.16b, XL.16b, XL2.16b
- eor XH.16b, XH.16b, XH2.16b
+ tbz w9, #2, 0f // <4 blocks?
+ .subsection 1
+0: movi XH2.16b, #0
+ movi XM2.16b, #0
+ movi XL2.16b, #0
- enc_round KS1, v27
- eor XM.16b, XM.16b, XM2.16b
- ext T1.16b, XL.16b, XH.16b, #8
+ tbz w9, #0, 1f // 2 blocks?
+ tbz w9, #1, 2f // 1 block?
- enc_round KS0, v28
- eor T2.16b, XL.16b, XH.16b
- eor XM.16b, XM.16b, T1.16b
+ eor T2.16b, T2.16b, XL.16b
+ ext T1.16b, T2.16b, T2.16b, #8
+ b .Lgh3
- enc_round KS1, v28
- eor XM.16b, XM.16b, T2.16b
+1: eor TT3.16b, TT3.16b, XL.16b
+ ext T2.16b, TT3.16b, TT3.16b, #8
+ b .Lgh2
- enc_round KS0, v29
- pmull T2.1q, XL.1d, MASK.1d
+2: eor TT4.16b, TT4.16b, XL.16b
+ ext IN1.16b, TT4.16b, TT4.16b, #8
+ b .Lgh1
+ .previous
- enc_round KS1, v29
- mov XH.d[0], XM.d[1]
- mov XM.d[1], XL.d[0]
+ eor T1.16b, T1.16b, XL.16b
+ ext IN1.16b, T1.16b, T1.16b, #8
- aese KS0.16b, v30.16b
- eor XL.16b, XM.16b, T2.16b
+ pmull2 XH2.1q, HH4.2d, IN1.2d // a1 * b1
+ eor T1.16b, T1.16b, IN1.16b
+ pmull XL2.1q, HH4.1d, IN1.1d // a0 * b0
+ pmull2 XM2.1q, HH34.2d, T1.2d // (a1 + a0)(b1 + b0)
- aese KS1.16b, v30.16b
- ext T2.16b, XL.16b, XL.16b, #8
+ ext T1.16b, T2.16b, T2.16b, #8
+.Lgh3: eor T2.16b, T2.16b, T1.16b
+ pmull2 XH.1q, HH3.2d, T1.2d // a1 * b1
+ pmull XL.1q, HH3.1d, T1.1d // a0 * b0
+ pmull XM.1q, HH34.1d, T2.1d // (a1 + a0)(b1 + b0)
- eor KS0.16b, KS0.16b, v31.16b
- pmull XL.1q, XL.1d, MASK.1d
- eor T2.16b, T2.16b, XH.16b
+ eor XH2.16b, XH2.16b, XH.16b
+ eor XL2.16b, XL2.16b, XL.16b
+ eor XM2.16b, XM2.16b, XM.16b
- eor KS1.16b, KS1.16b, v31.16b
- eor XL.16b, XL.16b, T2.16b
+ ext T2.16b, TT3.16b, TT3.16b, #8
+.Lgh2: eor TT3.16b, TT3.16b, T2.16b
+ pmull2 XH.1q, HH.2d, T2.2d // a1 * b1
+ pmull XL.1q, HH.1d, T2.1d // a0 * b0
+ pmull2 XM.1q, SHASH2.2d, TT3.2d // (a1 + a0)(b1 + b0)
- .if \enc == 0
- eor INP0.16b, INP0.16b, KS0.16b
- eor INP1.16b, INP1.16b, KS1.16b
- .endif
+ eor XH2.16b, XH2.16b, XH.16b
+ eor XL2.16b, XL2.16b, XL.16b
+ eor XM2.16b, XM2.16b, XM.16b
- st1 {INP0.16b-INP1.16b}, [x2], #32
+ ext IN1.16b, TT4.16b, TT4.16b, #8
+.Lgh1: eor TT4.16b, TT4.16b, IN1.16b
+ pmull XL.1q, SHASH.1d, IN1.1d // a0 * b0
+ pmull2 XH.1q, SHASH.2d, IN1.2d // a1 * b1
+ pmull XM.1q, SHASH2.1d, TT4.1d // (a1 + a0)(b1 + b0)
- cbnz w0, 0b
+ eor XH.16b, XH.16b, XH2.16b
+ eor XL.16b, XL.16b, XL2.16b
+ eor XM.16b, XM.16b, XM2.16b
-CPU_LE( rev x8, x8 )
- st1 {XL.2d}, [x1]
- str x8, [x5, #8] // store lower counter
+ eor T2.16b, XL.16b, XH.16b
+ ext T1.16b, XL.16b, XH.16b, #8
+ eor XM.16b, XM.16b, T2.16b
- .if \enc == 1
- st1 {KS0.16b-KS1.16b}, [x10]
- .endif
+ __pmull_reduce_p64
+
+ eor T2.16b, T2.16b, XH.16b
+ eor XL.16b, XL.16b, T2.16b
ret
+ENDPROC(pmull_gcm_ghash_4x)
+
+pmull_gcm_enc_4x:
+ ld1 {KS0.16b}, [x5] // load upper counter
+ sub w10, w8, #4
+ sub w11, w8, #3
+ sub w12, w8, #2
+ sub w13, w8, #1
+ rev w10, w10
+ rev w11, w11
+ rev w12, w12
+ rev w13, w13
+ mov KS1.16b, KS0.16b
+ mov KS2.16b, KS0.16b
+ mov KS3.16b, KS0.16b
+ ins KS0.s[3], w10 // set lower counter
+ ins KS1.s[3], w11
+ ins KS2.s[3], w12
+ ins KS3.s[3], w13
+
+ add x10, x6, #96 // round key pointer
+ ld1 {K6.4s-K7.4s}, [x10], #32
+ .irp key, K0, K1, K2, K3, K4, K5
+ enc_qround KS0, KS1, KS2, KS3, \key
+ .endr
-2: b.eq 3f // AES-192?
- enc_round KS0, v17
- enc_round KS1, v17
- enc_round KS0, v18
- enc_round KS1, v18
-3: enc_round KS0, v19
- enc_round KS1, v19
- enc_round KS0, v20
- enc_round KS1, v20
- b 1b
+ tbnz x7, #2, .Lnot128
+ .subsection 1
+.Lnot128:
+ ld1 {K8.4s-K9.4s}, [x10], #32
+ .irp key, K6, K7
+ enc_qround KS0, KS1, KS2, KS3, \key
+ .endr
+ ld1 {K6.4s-K7.4s}, [x10]
+ .irp key, K8, K9
+ enc_qround KS0, KS1, KS2, KS3, \key
+ .endr
+ tbz x7, #1, .Lout192
+ b .Lout256
+ .previous
-4: load_round_keys w7, x6
- b 0b
- .endm
+.Lout256:
+ .irp key, K6, K7
+ enc_qround KS0, KS1, KS2, KS3, \key
+ .endr
- /*
- * void pmull_gcm_encrypt(int blocks, u64 dg[], u8 dst[], const u8 src[],
- * struct ghash_key const *k, u8 ctr[],
- * int rounds, u8 ks[])
- */
-ENTRY(pmull_gcm_encrypt)
- pmull_gcm_do_crypt 1
-ENDPROC(pmull_gcm_encrypt)
+.Lout192:
+ enc_qround KS0, KS1, KS2, KS3, KK
- /*
- * void pmull_gcm_decrypt(int blocks, u64 dg[], u8 dst[], const u8 src[],
- * struct ghash_key const *k, u8 ctr[],
- * int rounds)
- */
-ENTRY(pmull_gcm_decrypt)
- pmull_gcm_do_crypt 0
-ENDPROC(pmull_gcm_decrypt)
+ aese KS0.16b, KL.16b
+ aese KS1.16b, KL.16b
+ aese KS2.16b, KL.16b
+ aese KS3.16b, KL.16b
+
+ eor KS0.16b, KS0.16b, KM.16b
+ eor KS1.16b, KS1.16b, KM.16b
+ eor KS2.16b, KS2.16b, KM.16b
+ eor KS3.16b, KS3.16b, KM.16b
+
+ eor INP0.16b, INP0.16b, KS0.16b
+ eor INP1.16b, INP1.16b, KS1.16b
+ eor INP2.16b, INP2.16b, KS2.16b
+ eor INP3.16b, INP3.16b, KS3.16b
- /*
- * void pmull_gcm_encrypt_block(u8 dst[], u8 src[], u8 rk[], int rounds)
- */
-ENTRY(pmull_gcm_encrypt_block)
- cbz x2, 0f
- load_round_keys w3, x2
-0: ld1 {v0.16b}, [x1]
- enc_block v0, w3
- st1 {v0.16b}, [x0]
ret
-ENDPROC(pmull_gcm_encrypt_block)
+ENDPROC(pmull_gcm_enc_4x)
+
+ .section ".rodata", "a"
+ .align 6
+.Lpermute_table:
+ .byte 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
+ .byte 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
+ .byte 0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7
+ .byte 0x8, 0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf
+ .byte 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
+ .byte 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
+ .byte 0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7
+ .byte 0x8, 0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf
+ .previous
diff --git a/arch/arm64/crypto/ghash-ce-glue.c b/arch/arm64/crypto/ghash-ce-glue.c
index 70b1469783f9..522cf004ce65 100644
--- a/arch/arm64/crypto/ghash-ce-glue.c
+++ b/arch/arm64/crypto/ghash-ce-glue.c
@@ -58,17 +58,15 @@ asmlinkage void pmull_ghash_update_p8(int blocks, u64 dg[], const char *src,
struct ghash_key const *k,
const char *head);
-asmlinkage void pmull_gcm_encrypt(int blocks, u64 dg[], u8 dst[],
- const u8 src[], struct ghash_key const *k,
+asmlinkage void pmull_gcm_encrypt(int bytes, u8 dst[], const u8 src[],
+ struct ghash_key const *k, u64 dg[],
u8 ctr[], u32 const rk[], int rounds,
- u8 ks[]);
+ u8 tag[]);
-asmlinkage void pmull_gcm_decrypt(int blocks, u64 dg[], u8 dst[],
- const u8 src[], struct ghash_key const *k,
- u8 ctr[], u32 const rk[], int rounds);
-
-asmlinkage void pmull_gcm_encrypt_block(u8 dst[], u8 const src[],
- u32 const rk[], int rounds);
+asmlinkage void pmull_gcm_decrypt(int bytes, u8 dst[], const u8 src[],
+ struct ghash_key const *k, u64 dg[],
+ u8 ctr[], u32 const rk[], int rounds,
+ u8 tag[]);
static int ghash_init(struct shash_desc *desc)
{
@@ -85,7 +83,7 @@ static void ghash_do_update(int blocks, u64 dg[], const char *src,
struct ghash_key const *k,
const char *head))
{
- if (likely(crypto_simd_usable())) {
+ if (likely(crypto_simd_usable() && simd_update)) {
kernel_neon_begin();
simd_update(blocks, dg, src, key, head);
kernel_neon_end();
@@ -398,136 +396,112 @@ static void gcm_calculate_auth_mac(struct aead_request *req, u64 dg[])
}
}
-static void gcm_final(struct aead_request *req, struct gcm_aes_ctx *ctx,
- u64 dg[], u8 tag[], int cryptlen)
-{
- u8 mac[AES_BLOCK_SIZE];
- u128 lengths;
-
- lengths.a = cpu_to_be64(req->assoclen * 8);
- lengths.b = cpu_to_be64(cryptlen * 8);
-
- ghash_do_update(1, dg, (void *)&lengths, &ctx->ghash_key, NULL,
- pmull_ghash_update_p64);
-
- put_unaligned_be64(dg[1], mac);
- put_unaligned_be64(dg[0], mac + 8);
-
- crypto_xor(tag, mac, AES_BLOCK_SIZE);
-}
-
static int gcm_encrypt(struct aead_request *req)
{
struct crypto_aead *aead = crypto_aead_reqtfm(req);
struct gcm_aes_ctx *ctx = crypto_aead_ctx(aead);
+ int nrounds = num_rounds(&ctx->aes_key);
struct skcipher_walk walk;
+ u8 buf[AES_BLOCK_SIZE];
u8 iv[AES_BLOCK_SIZE];
- u8 ks[2 * AES_BLOCK_SIZE];
- u8 tag[AES_BLOCK_SIZE];
u64 dg[2] = {};
- int nrounds = num_rounds(&ctx->aes_key);
+ u128 lengths;
+ u8 *tag;
int err;
+ lengths.a = cpu_to_be64(req->assoclen * 8);
+ lengths.b = cpu_to_be64(req->cryptlen * 8);
+
if (req->assoclen)
gcm_calculate_auth_mac(req, dg);
memcpy(iv, req->iv, GCM_IV_SIZE);
- put_unaligned_be32(1, iv + GCM_IV_SIZE);
+ put_unaligned_be32(2, iv + GCM_IV_SIZE);
err = skcipher_walk_aead_encrypt(&walk, req, false);
- if (likely(crypto_simd_usable() && walk.total >= 2 * AES_BLOCK_SIZE)) {
- u32 const *rk = NULL;
-
- kernel_neon_begin();
- pmull_gcm_encrypt_block(tag, iv, ctx->aes_key.key_enc, nrounds);
- put_unaligned_be32(2, iv + GCM_IV_SIZE);
- pmull_gcm_encrypt_block(ks, iv, NULL, nrounds);
- put_unaligned_be32(3, iv + GCM_IV_SIZE);
- pmull_gcm_encrypt_block(ks + AES_BLOCK_SIZE, iv, NULL, nrounds);
- put_unaligned_be32(4, iv + GCM_IV_SIZE);
-
+ if (likely(crypto_simd_usable())) {
do {
- int blocks = walk.nbytes / (2 * AES_BLOCK_SIZE) * 2;
+ const u8 *src = walk.src.virt.addr;
+ u8 *dst = walk.dst.virt.addr;
+ int nbytes = walk.nbytes;
+
+ tag = (u8 *)&lengths;
- if (rk)
- kernel_neon_begin();
+ if (unlikely(nbytes > 0 && nbytes < AES_BLOCK_SIZE)) {
+ src = dst = memcpy(buf + sizeof(buf) - nbytes,
+ src, nbytes);
+ } else if (nbytes < walk.total) {
+ nbytes &= ~(AES_BLOCK_SIZE - 1);
+ tag = NULL;
+ }
- pmull_gcm_encrypt(blocks, dg, walk.dst.virt.addr,
- walk.src.virt.addr, &ctx->ghash_key,
- iv, rk, nrounds, ks);
+ kernel_neon_begin();
+ pmull_gcm_encrypt(nbytes, dst, src, &ctx->ghash_key, dg,
+ iv, ctx->aes_key.key_enc, nrounds,
+ tag);
kernel_neon_end();
- err = skcipher_walk_done(&walk,
- walk.nbytes % (2 * AES_BLOCK_SIZE));
+ if (unlikely(!nbytes))
+ break;
- rk = ctx->aes_key.key_enc;
- } while (walk.nbytes >= 2 * AES_BLOCK_SIZE);
- } else {
- aes_encrypt(&ctx->aes_key, tag, iv);
- put_unaligned_be32(2, iv + GCM_IV_SIZE);
+ if (unlikely(nbytes > 0 && nbytes < AES_BLOCK_SIZE))
+ memcpy(walk.dst.virt.addr,
+ buf + sizeof(buf) - nbytes, nbytes);
- while (walk.nbytes >= (2 * AES_BLOCK_SIZE)) {
- const int blocks =
- walk.nbytes / (2 * AES_BLOCK_SIZE) * 2;
+ err = skcipher_walk_done(&walk, walk.nbytes - nbytes);
+ } while (walk.nbytes);
+ } else {
+ while (walk.nbytes >= AES_BLOCK_SIZE) {
+ int blocks = walk.nbytes / AES_BLOCK_SIZE;
+ const u8 *src = walk.src.virt.addr;
u8 *dst = walk.dst.virt.addr;
- u8 *src = walk.src.virt.addr;
int remaining = blocks;
do {
- aes_encrypt(&ctx->aes_key, ks, iv);
- crypto_xor_cpy(dst, src, ks, AES_BLOCK_SIZE);
+ aes_encrypt(&ctx->aes_key, buf, iv);
+ crypto_xor_cpy(dst, src, buf, AES_BLOCK_SIZE);
crypto_inc(iv, AES_BLOCK_SIZE);
dst += AES_BLOCK_SIZE;
src += AES_BLOCK_SIZE;
} while (--remaining > 0);
- ghash_do_update(blocks, dg,
- walk.dst.virt.addr, &ctx->ghash_key,
- NULL, pmull_ghash_update_p64);
+ ghash_do_update(blocks, dg, walk.dst.virt.addr,
+ &ctx->ghash_key, NULL, NULL);
err = skcipher_walk_done(&walk,
- walk.nbytes % (2 * AES_BLOCK_SIZE));
- }
- if (walk.nbytes) {
- aes_encrypt(&ctx->aes_key, ks, iv);
- if (walk.nbytes > AES_BLOCK_SIZE) {
- crypto_inc(iv, AES_BLOCK_SIZE);
- aes_encrypt(&ctx->aes_key, ks + AES_BLOCK_SIZE, iv);
- }
+ walk.nbytes % AES_BLOCK_SIZE);
}
- }
- /* handle the tail */
- if (walk.nbytes) {
- u8 buf[GHASH_BLOCK_SIZE];
- unsigned int nbytes = walk.nbytes;
- u8 *dst = walk.dst.virt.addr;
- u8 *head = NULL;
+ /* handle the tail */
+ if (walk.nbytes) {
+ aes_encrypt(&ctx->aes_key, buf, iv);
- crypto_xor_cpy(walk.dst.virt.addr, walk.src.virt.addr, ks,
- walk.nbytes);
+ crypto_xor_cpy(walk.dst.virt.addr, walk.src.virt.addr,
+ buf, walk.nbytes);
- if (walk.nbytes > GHASH_BLOCK_SIZE) {
- head = dst;
- dst += GHASH_BLOCK_SIZE;
- nbytes %= GHASH_BLOCK_SIZE;
+ memcpy(buf, walk.dst.virt.addr, walk.nbytes);
+ memset(buf + walk.nbytes, 0, sizeof(buf) - walk.nbytes);
}
- memcpy(buf, dst, nbytes);
- memset(buf + nbytes, 0, GHASH_BLOCK_SIZE - nbytes);
- ghash_do_update(!!nbytes, dg, buf, &ctx->ghash_key, head,
- pmull_ghash_update_p64);
+ tag = (u8 *)&lengths;
+ ghash_do_update(1, dg, tag, &ctx->ghash_key,
+ walk.nbytes ? buf : NULL, NULL);
- err = skcipher_walk_done(&walk, 0);
+ if (walk.nbytes)
+ err = skcipher_walk_done(&walk, 0);
+
+ put_unaligned_be64(dg[1], tag);
+ put_unaligned_be64(dg[0], tag + 8);
+ put_unaligned_be32(1, iv + GCM_IV_SIZE);
+ aes_encrypt(&ctx->aes_key, iv, iv);
+ crypto_xor(tag, iv, AES_BLOCK_SIZE);
}
if (err)
return err;
- gcm_final(req, ctx, dg, tag, req->cryptlen);
-
/* copy authtag to end of dst */
scatterwalk_map_and_copy(tag, req->dst, req->assoclen + req->cryptlen,
crypto_aead_authsize(aead), 1);
@@ -540,75 +514,65 @@ static int gcm_decrypt(struct aead_request *req)
struct crypto_aead *aead = crypto_aead_reqtfm(req);
struct gcm_aes_ctx *ctx = crypto_aead_ctx(aead);
unsigned int authsize = crypto_aead_authsize(aead);
+ int nrounds = num_rounds(&ctx->aes_key);
struct skcipher_walk walk;
- u8 iv[2 * AES_BLOCK_SIZE];
- u8 tag[AES_BLOCK_SIZE];
- u8 buf[2 * GHASH_BLOCK_SIZE];
+ u8 buf[AES_BLOCK_SIZE];
+ u8 iv[AES_BLOCK_SIZE];
u64 dg[2] = {};
- int nrounds = num_rounds(&ctx->aes_key);
+ u128 lengths;
+ u8 *tag;
int err;
+ lengths.a = cpu_to_be64(req->assoclen * 8);
+ lengths.b = cpu_to_be64((req->cryptlen - authsize) * 8);
+
if (req->assoclen)
gcm_calculate_auth_mac(req, dg);
memcpy(iv, req->iv, GCM_IV_SIZE);
- put_unaligned_be32(1, iv + GCM_IV_SIZE);
+ put_unaligned_be32(2, iv + GCM_IV_SIZE);
err = skcipher_walk_aead_decrypt(&walk, req, false);
- if (likely(crypto_simd_usable() && walk.total >= 2 * AES_BLOCK_SIZE)) {
- u32 const *rk = NULL;
-
- kernel_neon_begin();
- pmull_gcm_encrypt_block(tag, iv, ctx->aes_key.key_enc, nrounds);
- put_unaligned_be32(2, iv + GCM_IV_SIZE);
-
+ if (likely(crypto_simd_usable())) {
do {
- int blocks = walk.nbytes / (2 * AES_BLOCK_SIZE) * 2;
- int rem = walk.total - blocks * AES_BLOCK_SIZE;
-
- if (rk)
- kernel_neon_begin();
-
- pmull_gcm_decrypt(blocks, dg, walk.dst.virt.addr,
- walk.src.virt.addr, &ctx->ghash_key,
- iv, rk, nrounds);
-
- /* check if this is the final iteration of the loop */
- if (rem < (2 * AES_BLOCK_SIZE)) {
- u8 *iv2 = iv + AES_BLOCK_SIZE;
-
- if (rem > AES_BLOCK_SIZE) {
- memcpy(iv2, iv, AES_BLOCK_SIZE);
- crypto_inc(iv2, AES_BLOCK_SIZE);
- }
+ const u8 *src = walk.src.virt.addr;
+ u8 *dst = walk.dst.virt.addr;
+ int nbytes = walk.nbytes;
- pmull_gcm_encrypt_block(iv, iv, NULL, nrounds);
+ tag = (u8 *)&lengths;
- if (rem > AES_BLOCK_SIZE)
- pmull_gcm_encrypt_block(iv2, iv2, NULL,
- nrounds);
+ if (unlikely(nbytes > 0 && nbytes < AES_BLOCK_SIZE)) {
+ src = dst = memcpy(buf + sizeof(buf) - nbytes,
+ src, nbytes);
+ } else if (nbytes < walk.total) {
+ nbytes &= ~(AES_BLOCK_SIZE - 1);
+ tag = NULL;
}
+ kernel_neon_begin();
+ pmull_gcm_decrypt(nbytes, dst, src, &ctx->ghash_key, dg,
+ iv, ctx->aes_key.key_enc, nrounds,
+ tag);
kernel_neon_end();
- err = skcipher_walk_done(&walk,
- walk.nbytes % (2 * AES_BLOCK_SIZE));
+ if (unlikely(!nbytes))
+ break;
- rk = ctx->aes_key.key_enc;
- } while (walk.nbytes >= 2 * AES_BLOCK_SIZE);
- } else {
- aes_encrypt(&ctx->aes_key, tag, iv);
- put_unaligned_be32(2, iv + GCM_IV_SIZE);
+ if (unlikely(nbytes > 0 && nbytes < AES_BLOCK_SIZE))
+ memcpy(walk.dst.virt.addr,
+ buf + sizeof(buf) - nbytes, nbytes);
- while (walk.nbytes >= (2 * AES_BLOCK_SIZE)) {
- int blocks = walk.nbytes / (2 * AES_BLOCK_SIZE) * 2;
+ err = skcipher_walk_done(&walk, walk.nbytes - nbytes);
+ } while (walk.nbytes);
+ } else {
+ while (walk.nbytes >= AES_BLOCK_SIZE) {
+ int blocks = walk.nbytes / AES_BLOCK_SIZE;
+ const u8 *src = walk.src.virt.addr;
u8 *dst = walk.dst.virt.addr;
- u8 *src = walk.src.virt.addr;
ghash_do_update(blocks, dg, walk.src.virt.addr,
- &ctx->ghash_key, NULL,
- pmull_ghash_update_p64);
+ &ctx->ghash_key, NULL, NULL);
do {
aes_encrypt(&ctx->aes_key, buf, iv);
@@ -620,49 +584,38 @@ static int gcm_decrypt(struct aead_request *req)
} while (--blocks > 0);
err = skcipher_walk_done(&walk,
- walk.nbytes % (2 * AES_BLOCK_SIZE));
+ walk.nbytes % AES_BLOCK_SIZE);
}
- if (walk.nbytes) {
- if (walk.nbytes > AES_BLOCK_SIZE) {
- u8 *iv2 = iv + AES_BLOCK_SIZE;
-
- memcpy(iv2, iv, AES_BLOCK_SIZE);
- crypto_inc(iv2, AES_BLOCK_SIZE);
- aes_encrypt(&ctx->aes_key, iv2, iv2);
- }
- aes_encrypt(&ctx->aes_key, iv, iv);
+ /* handle the tail */
+ if (walk.nbytes) {
+ memcpy(buf, walk.src.virt.addr, walk.nbytes);
+ memset(buf + walk.nbytes, 0, sizeof(buf) - walk.nbytes);
}
- }
- /* handle the tail */
- if (walk.nbytes) {
- const u8 *src = walk.src.virt.addr;
- const u8 *head = NULL;
- unsigned int nbytes = walk.nbytes;
+ tag = (u8 *)&lengths;
+ ghash_do_update(1, dg, tag, &ctx->ghash_key,
+ walk.nbytes ? buf : NULL, NULL);
- if (walk.nbytes > GHASH_BLOCK_SIZE) {
- head = src;
- src += GHASH_BLOCK_SIZE;
- nbytes %= GHASH_BLOCK_SIZE;
- }
+ if (walk.nbytes) {
+ aes_encrypt(&ctx->aes_key, buf, iv);
- memcpy(buf, src, nbytes);
- memset(buf + nbytes, 0, GHASH_BLOCK_SIZE - nbytes);
- ghash_do_update(!!nbytes, dg, buf, &ctx->ghash_key, head,
- pmull_ghash_update_p64);
+ crypto_xor_cpy(walk.dst.virt.addr, walk.src.virt.addr,
+ buf, walk.nbytes);
- crypto_xor_cpy(walk.dst.virt.addr, walk.src.virt.addr, iv,
- walk.nbytes);
+ err = skcipher_walk_done(&walk, 0);
+ }
- err = skcipher_walk_done(&walk, 0);
+ put_unaligned_be64(dg[1], tag);
+ put_unaligned_be64(dg[0], tag + 8);
+ put_unaligned_be32(1, iv + GCM_IV_SIZE);
+ aes_encrypt(&ctx->aes_key, iv, iv);
+ crypto_xor(tag, iv, AES_BLOCK_SIZE);
}
if (err)
return err;
- gcm_final(req, ctx, dg, tag, req->cryptlen - authsize);
-
/* compare calculated auth tag with the stored one */
scatterwalk_map_and_copy(buf, req->src,
req->assoclen + req->cryptlen - authsize,
@@ -675,7 +628,7 @@ static int gcm_decrypt(struct aead_request *req)
static struct aead_alg gcm_aes_alg = {
.ivsize = GCM_IV_SIZE,
- .chunksize = 2 * AES_BLOCK_SIZE,
+ .chunksize = AES_BLOCK_SIZE,
.maxauthsize = AES_BLOCK_SIZE,
.setkey = gcm_setkey,
.setauthsize = gcm_setauthsize,
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] crypto: testmgr - add another gcm(aes) testcase
From: Ard Biesheuvel @ 2019-09-10 23:18 UTC (permalink / raw)
To: linux-crypto
Cc: marc.zyngier, Ard Biesheuvel, herbert, linux-arm-kernel, ebiggers
In-Reply-To: <20190910231900.25445-1-ard.biesheuvel@linaro.org>
Add an additional gcm(aes) test case that triggers the code path in
the new arm64 driver that deals with tail blocks whose size is not
a multiple of the block size, and where the size of the preceding
input is a multiple of 64 bytes.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
crypto/testmgr.h | 192 ++++++++++++++++++++
1 file changed, 192 insertions(+)
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index b3296441f9c7..690e68cb3e51 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -17411,6 +17411,198 @@ static const struct aead_testvec aes_gcm_tv_template[] = {
"\x25\x19\x49\x8e\x80\xf1\x47\x8f"
"\x37\xba\x55\xbd\x6d\x27\x61\x8c",
.clen = 76,
+ }, {
+ .key = "\x62\x35\xf8\x95\xfc\xa5\xeb\xf6"
+ "\x0e\x92\x12\x04\xd3\xa1\x3f\x2e"
+ "\x8b\x32\xcf\xe7\x44\xed\x13\x59"
+ "\x04\x38\x77\xb0\xb9\xad\xb4\x38",
+ .klen = 32,
+ .iv = "\x00\xff\xff\xff\xff\x00\x00\xff"
+ "\xff\xff\x00\xff",
+ .ptext = "\x42\xc1\xcc\x08\x48\x6f\x41\x3f"
+ "\x2f\x11\x66\x8b\x2a\x16\xf0\xe0"
+ "\x58\x83\xf0\xc3\x70\x14\xc0\x5b"
+ "\x3f\xec\x1d\x25\x3c\x51\xd2\x03"
+ "\xcf\x59\x74\x1f\xb2\x85\xb4\x07"
+ "\xc6\x6a\x63\x39\x8a\x5b\xde\xcb"
+ "\xaf\x08\x44\xbd\x6f\x91\x15\xe1"
+ "\xf5\x7a\x6e\x18\xbd\xdd\x61\x50"
+ "\x59\xa9\x97\xab\xbb\x0e\x74\x5c"
+ "\x00\xa4\x43\x54\x04\x54\x9b\x3b"
+ "\x77\xec\xfd\x5c\xa6\xe8\x7b\x08"
+ "\xae\xe6\x10\x3f\x32\x65\xd1\xfc"
+ "\xa4\x1d\x2c\x31\xfb\x33\x7a\xb3"
+ "\x35\x23\xf4\x20\x41\xd4\xad\x82"
+ "\x8b\xa4\xad\x96\x1c\x20\x53\xbe"
+ "\x0e\xa6\xf4\xdc\x78\x49\x3e\x72"
+ "\xb1\xa9\xb5\x83\xcb\x08\x54\xb7"
+ "\xad\x49\x3a\xae\x98\xce\xa6\x66"
+ "\x10\x30\x90\x8c\x55\x83\xd7\x7c"
+ "\x8b\xe6\x53\xde\xd2\x6e\x18\x21"
+ "\x01\x52\xd1\x9f\x9d\xbb\x9c\x73"
+ "\x57\xcc\x89\x09\x75\x9b\x78\x70"
+ "\xed\x26\x97\x4d\xb4\xe4\x0c\xa5"
+ "\xfa\x70\x04\x70\xc6\x96\x1c\x7d"
+ "\x54\x41\x77\xa8\xe3\xb0\x7e\x96"
+ "\x82\xd9\xec\xa2\x87\x68\x55\xf9"
+ "\x8f\x9e\x73\x43\x47\x6a\x08\x36"
+ "\x93\x67\xa8\x2d\xde\xac\x41\xa9"
+ "\x5c\x4d\x73\x97\x0f\x70\x68\xfa"
+ "\x56\x4d\x00\xc2\x3b\x1f\xc8\xb9"
+ "\x78\x1f\x51\x07\xe3\x9a\x13\x4e"
+ "\xed\x2b\x2e\xa3\xf7\x44\xb2\xe7"
+ "\xab\x19\x37\xd9\xba\x76\x5e\xd2"
+ "\xf2\x53\x15\x17\x4c\x6b\x16\x9f"
+ "\x02\x66\x49\xca\x7c\x91\x05\xf2"
+ "\x45\x36\x1e\xf5\x77\xad\x1f\x46"
+ "\xa8\x13\xfb\x63\xb6\x08\x99\x63"
+ "\x82\xa2\xed\xb3\xac\xdf\x43\x19"
+ "\x45\xea\x78\x73\xd9\xb7\x39\x11"
+ "\xa3\x13\x7c\xf8\x3f\xf7\xad\x81"
+ "\x48\x2f\xa9\x5c\x5f\xa0\xf0\x79"
+ "\xa4\x47\x7d\x80\x20\x26\xfd\x63"
+ "\x0a\xc7\x7e\x6d\x75\x47\xff\x76"
+ "\x66\x2e\x8a\x6c\x81\x35\xaf\x0b"
+ "\x2e\x6a\x49\x60\xc1\x10\xe1\xe1"
+ "\x54\x03\xa4\x09\x0c\x37\x7a\x15"
+ "\x23\x27\x5b\x8b\x4b\xa5\x64\x97"
+ "\xae\x4a\x50\x73\x1f\x66\x1c\x5c"
+ "\x03\x25\x3c\x8d\x48\x58\x71\x34"
+ "\x0e\xec\x4e\x55\x1a\x03\x6a\xe5"
+ "\xb6\x19\x2b\x84\x2a\x20\xd1\xea"
+ "\x80\x6f\x96\x0e\x05\x62\xc7\x78"
+ "\x87\x79\x60\x38\x46\xb4\x25\x57"
+ "\x6e\x16\x63\xf8\xad\x6e\xd7\x42"
+ "\x69\xe1\x88\xef\x6e\xd5\xb4\x9a"
+ "\x3c\x78\x6c\x3b\xe5\xa0\x1d\x22"
+ "\x86\x5c\x74\x3a\xeb\x24\x26\xc7"
+ "\x09\xfc\x91\x96\x47\x87\x4f\x1a"
+ "\xd6\x6b\x2c\x18\x47\xc0\xb8\x24"
+ "\xa8\x5a\x4a\x9e\xcb\x03\xe7\x2a"
+ "\x09\xe6\x4d\x9c\x6d\x86\x60\xf5"
+ "\x2f\x48\x69\x37\x9f\xf2\xd2\xcb"
+ "\x0e\x5a\xdd\x6e\x8a\xfb\x6a\xfe"
+ "\x0b\x63\xde\x87\x42\x79\x8a\x68"
+ "\x51\x28\x9b\x7a\xeb\xaf\xb8\x2f"
+ "\x9d\xd1\xc7\x45\x90\x08\xc9\x83"
+ "\xe9\x83\x84\xcb\x28\x69\x09\x69"
+ "\xce\x99\x46\x00\x54\xcb\xd8\x38"
+ "\xf9\x53\x4a\xbf\x31\xce\x57\x15"
+ "\x33\xfa\x96\x04\x33\x42\xe3\xc0"
+ "\xb7\x54\x4a\x65\x7a\x7c\x02\xe6"
+ "\x19\x95\xd0\x0e\x82\x07\x63\xf9"
+ "\xe1\x2b\x2a\xfc\x55\x92\x52\xc9"
+ "\xb5\x9f\x23\x28\x60\xe7\x20\x51"
+ "\x10\xd3\xed\x6d\x9b\xab\xb8\xe2"
+ "\x5d\x9a\x34\xb3\xbe\x9c\x64\xcb"
+ "\x78\xc6\x91\x22\x40\x91\x80\xbe"
+ "\xd7\x78\x5c\x0e\x0a\xdc\x08\xe9"
+ "\x67\x10\xa4\x83\x98\x79\x23\xe7"
+ "\x92\xda\xa9\x22\x16\xb1\xe7\x78"
+ "\xa3\x1c\x6c\x8f\x35\x7c\x4d\x37"
+ "\x2f\x6e\x0b\x50\x5c\x34\xb9\xf9"
+ "\xe6\x3d\x91\x0d\x32\x95\xaa\x3d"
+ "\x48\x11\x06\xbb\x2d\xf2\x63\x88"
+ "\x3f\x73\x09\xe2\x45\x56\x31\x51"
+ "\xfa\x5e\x4e\x62\xf7\x90\xf9\xa9"
+ "\x7d\x7b\x1b\xb1\xc8\x26\x6e\x66"
+ "\xf6\x90\x9a\x7f\xf2\x57\xcc\x23"
+ "\x59\xfa\xfa\xaa\x44\x04\x01\xa7"
+ "\xa4\x78\xdb\x74\x3d\x8b\xb5",
+ .plen = 719,
+ .ctext = "\x84\x0b\xdb\xd5\xb7\xa8\xfe\x20"
+ "\xbb\xb1\x12\x7f\x41\xea\xb3\xc0"
+ "\xa2\xb4\x37\x19\x11\x58\xb6\x0b"
+ "\x4c\x1d\x38\x05\x54\xd1\x16\x73"
+ "\x8e\x1c\x20\x90\xa2\x9a\xb7\x74"
+ "\x47\xe6\xd8\xfc\x18\x3a\xb4\xea"
+ "\xd5\x16\x5a\x2c\x53\x01\x46\xb3"
+ "\x18\x33\x74\x6c\x50\xf2\xe8\xc0"
+ "\x73\xda\x60\x22\xeb\xe3\xe5\x9b"
+ "\x20\x93\x6c\x4b\x37\x99\xb8\x23"
+ "\x3b\x4e\xac\xe8\x5b\xe8\x0f\xb7"
+ "\xc3\x8f\xfb\x4a\x37\xd9\x39\x95"
+ "\x34\xf1\xdb\x8f\x71\xd9\xc7\x0b"
+ "\x02\xf1\x63\xfc\x9b\xfc\xc5\xab"
+ "\xb9\x14\x13\x21\xdf\xce\xaa\x88"
+ "\x44\x30\x1e\xce\x26\x01\x92\xf8"
+ "\x9f\x00\x4b\x0c\x4b\xf7\x5f\xe0"
+ "\x89\xca\x94\x66\x11\x21\x97\xca"
+ "\x3e\x83\x74\x2d\xdb\x4d\x11\xeb"
+ "\x97\xc2\x14\xff\x9e\x1e\xa0\x6b"
+ "\x08\xb4\x31\x2b\x85\xc6\x85\x6c"
+ "\x90\xec\x39\xc0\xec\xb3\xb5\x4e"
+ "\xf3\x9c\xe7\x83\x3a\x77\x0a\xf4"
+ "\x56\xfe\xce\x18\x33\x6d\x0b\x2d"
+ "\x33\xda\xc8\x05\x5c\xb4\x09\x2a"
+ "\xde\x6b\x52\x98\x01\xef\x36\x3d"
+ "\xbd\xf9\x8f\xa8\x3e\xaa\xcd\xd1"
+ "\x01\x2d\x42\x49\xc3\xb6\x84\xbb"
+ "\x48\x96\xe0\x90\x93\x6c\x48\x64"
+ "\xd4\xfa\x7f\x93\x2c\xa6\x21\xc8"
+ "\x7a\x23\x7b\xaa\x20\x56\x12\xae"
+ "\x16\x9d\x94\x0f\x54\xa1\xec\xca"
+ "\x51\x4e\xf2\x39\xf4\xf8\x5f\x04"
+ "\x5a\x0d\xbf\xf5\x83\xa1\x15\xe1"
+ "\xf5\x3c\xd8\x62\xa3\xed\x47\x89"
+ "\x85\x4c\xe5\xdb\xac\x9e\x17\x1d"
+ "\x0c\x09\xe3\x3e\x39\x5b\x4d\x74"
+ "\x0e\xf5\x34\xee\x70\x11\x4c\xfd"
+ "\xdb\x34\xb1\xb5\x10\x3f\x73\xb7"
+ "\xf5\xfa\xed\xb0\x1f\xa5\xcd\x3c"
+ "\x8d\x35\x83\xd4\x11\x44\x6e\x6c"
+ "\x5b\xe0\x0e\x69\xa5\x39\xe5\xbb"
+ "\xa9\x57\x24\x37\xe6\x1f\xdd\xcf"
+ "\x16\x2a\x13\xf9\x6a\x2d\x90\xa0"
+ "\x03\x60\x7a\xed\x69\xd5\x00\x8b"
+ "\x7e\x4f\xcb\xb9\xfa\x91\xb9\x37"
+ "\xc1\x26\xce\x90\x97\x22\x64\x64"
+ "\xc1\x72\x43\x1b\xf6\xac\xc1\x54"
+ "\x8a\x10\x9c\xdd\x8d\xd5\x8e\xb2"
+ "\xe4\x85\xda\xe0\x20\x5f\xf4\xb4"
+ "\x15\xb5\xa0\x8d\x12\x74\x49\x23"
+ "\x3a\xdf\x4a\xd3\xf0\x3b\x89\xeb"
+ "\xf8\xcc\x62\x7b\xfb\x93\x07\x41"
+ "\x61\x26\x94\x58\x70\xa6\x3c\xe4"
+ "\xff\x58\xc4\x13\x3d\xcb\x36\x6b"
+ "\x32\xe5\xb2\x6d\x03\x74\x6f\x76"
+ "\x93\x77\xde\x48\xc4\xfa\x30\x4a"
+ "\xda\x49\x80\x77\x0f\x1c\xbe\x11"
+ "\xc8\x48\xb1\xe5\xbb\xf2\x8a\xe1"
+ "\x96\x2f\x9f\xd1\x8e\x8a\x5c\xe2"
+ "\xf7\xd7\xd8\x54\xf3\x3f\xc4\x91"
+ "\xb8\xfb\x86\xdc\x46\x24\x91\x60"
+ "\x6c\x2f\xc9\x41\x37\x51\x49\x54"
+ "\x09\x81\x21\xf3\x03\x9f\x2b\xe3"
+ "\x1f\x39\x63\xaf\xf4\xd7\x53\x60"
+ "\xa7\xc7\x54\xf9\xee\xb1\xb1\x7d"
+ "\x75\x54\x65\x93\xfe\xb1\x68\x6b"
+ "\x57\x02\xf9\xbb\x0e\xf9\xf8\xbf"
+ "\x01\x12\x27\xb4\xfe\xe4\x79\x7a"
+ "\x40\x5b\x51\x4b\xdf\x38\xec\xb1"
+ "\x6a\x56\xff\x35\x4d\x42\x33\xaa"
+ "\x6f\x1b\xe4\xdc\xe0\xdb\x85\x35"
+ "\x62\x10\xd4\xec\xeb\xc5\x7e\x45"
+ "\x1c\x6f\x17\xca\x3b\x8e\x2d\x66"
+ "\x4f\x4b\x36\x56\xcd\x1b\x59\xaa"
+ "\xd2\x9b\x17\xb9\x58\xdf\x7b\x64"
+ "\x8a\xff\x3b\x9c\xa6\xb5\x48\x9e"
+ "\xaa\xe2\x5d\x09\x71\x32\x5f\xb6"
+ "\x29\xbe\xe7\xc7\x52\x7e\x91\x82"
+ "\x6b\x6d\x33\xe1\x34\x06\x36\x21"
+ "\x5e\xbe\x1e\x2f\x3e\xc1\xfb\xea"
+ "\x49\x2c\xb5\xca\xf7\xb0\x37\xea"
+ "\x1f\xed\x10\x04\xd9\x48\x0d\x1a"
+ "\x1c\xfb\xe7\x84\x0e\x83\x53\x74"
+ "\xc7\x65\xe2\x5c\xe5\xba\x73\x4c"
+ "\x0e\xe1\xb5\x11\x45\x61\x43\x46"
+ "\xaa\x25\x8f\xbd\x85\x08\xfa\x4c"
+ "\x15\xc1\xc0\xd8\xf5\xdc\x16\xbb"
+ "\x7b\x1d\xe3\x87\x57\xa7\x2a\x1d"
+ "\x38\x58\x9e\x8a\x43\xdc\x57"
+ "\xd1\x81\x7d\x2b\xe9\xff\x99\x3a"
+ "\x4b\x24\x52\x58\x55\xe1\x49\x14",
+ .clen = 735,
}
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/2] crypto: faster GCM-AES for arm64
From: Ard Biesheuvel @ 2019-09-10 23:18 UTC (permalink / raw)
To: linux-crypto
Cc: marc.zyngier, Ard Biesheuvel, herbert, linux-arm-kernel, ebiggers
This series reimplements gcm(aes) for arm64 systems that support the
AES and 64x64->128 PMULL/PMULL2 instructions. Patch #1 adds a test
case and patch #2 updates the driver.
Ard Biesheuvel (2):
crypto: testmgr - add another gcm(aes) testcase
crypto: arm64/gcm-ce - implement 4 way interleave
arch/arm64/crypto/ghash-ce-core.S | 501 ++++++++++++++------
arch/arm64/crypto/ghash-ce-glue.c | 293 +++++-------
crypto/testmgr.h | 192 ++++++++
3 files changed, 659 insertions(+), 327 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: fix function types in COND_SYSCALL
From: Sami Tolvanen @ 2019-09-10 22:40 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland
Cc: Sami Tolvanen, Kees Cook, linux-arm-kernel, linux-kernel
Define a weak function in COND_SYSCALL instead of a weak alias to
sys_ni_syscall, which has an incompatible type. This fixes indirect
call mismatches with Control-Flow Integrity (CFI) checking.
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
arch/arm64/include/asm/syscall_wrapper.h | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/syscall_wrapper.h b/arch/arm64/include/asm/syscall_wrapper.h
index 507d0ee6bc69..06d880b3526c 100644
--- a/arch/arm64/include/asm/syscall_wrapper.h
+++ b/arch/arm64/include/asm/syscall_wrapper.h
@@ -8,6 +8,8 @@
#ifndef __ASM_SYSCALL_WRAPPER_H
#define __ASM_SYSCALL_WRAPPER_H
+struct pt_regs;
+
#define SC_ARM64_REGS_TO_ARGS(x, ...) \
__MAP(x,__SC_ARGS \
,,regs->regs[0],,regs->regs[1],,regs->regs[2] \
@@ -35,8 +37,11 @@
ALLOW_ERROR_INJECTION(__arm64_compat_sys_##sname, ERRNO); \
asmlinkage long __arm64_compat_sys_##sname(const struct pt_regs *__unused)
-#define COND_SYSCALL_COMPAT(name) \
- cond_syscall(__arm64_compat_sys_##name);
+#define COND_SYSCALL_COMPAT(name) \
+ asmlinkage long __weak __arm64_compat_sys_##name(const struct pt_regs *regs) \
+ { \
+ return sys_ni_syscall(); \
+ }
#define COMPAT_SYS_NI(name) \
SYSCALL_ALIAS(__arm64_compat_sys_##name, sys_ni_posix_timers);
@@ -70,7 +75,11 @@
#endif
#ifndef COND_SYSCALL
-#define COND_SYSCALL(name) cond_syscall(__arm64_sys_##name)
+#define COND_SYSCALL(name) \
+ asmlinkage long __weak __arm64_sys_##name(const struct pt_regs *regs) \
+ { \
+ return sys_ni_syscall(); \
+ }
#endif
#ifndef SYS_NI
--
2.23.0.162.g0b9fbb3734-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v9 1/8] mm: Add per-cpu logic to page shuffling
From: Alexander Duyck @ 2019-09-10 22:14 UTC (permalink / raw)
To: Michal Hocko
Cc: yang.zhang.wz, pagupta, kvm, mst, catalin.marinas,
Alexander Duyck, lcapitulino, linux-mm, will, aarcange,
virtio-dev, David Hildenbrand, willy, wei.w.wang, ying.huang,
riel, dan.j.williams, linux-arm-kernel, osalvador, nitesh,
konrad.wilk, dave.hansen, linux-kernel, pbonzini, akpm,
fengguang.wu, kirill.shutemov
In-Reply-To: <20190910121130.GU2063@dhcp22.suse.cz>
On Tue, 2019-09-10 at 14:11 +0200, Michal Hocko wrote:
> On Mon 09-09-19 08:11:36, Alexander Duyck wrote:
> > On Mon, 2019-09-09 at 10:14 +0200, David Hildenbrand wrote:
> > > On 07.09.19 19:25, Alexander Duyck wrote:
> > > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > >
> > > > Change the logic used to generate randomness in the suffle path so that we
> > > > can avoid cache line bouncing. The previous logic was sharing the offset
> > > > and entropy word between all CPUs. As such this can result in cache line
> > > > bouncing and will ultimately hurt performance when enabled.
> > >
> > > So, usually we perform such changes if there is real evidence. Do you
> > > have any such performance numbers to back your claims?
> >
> > I'll have to go rerun the test to get the exact numbers. The reason this
> > came up is that my original test was spanning NUMA nodes and that made
> > this more expensive as a result since the memory was both not local to the
> > CPU and was being updated by multiple sockets.
>
> What was the pattern of page freeing in your testing? I am wondering
> because order 0 pages should be prevailing and those usually go via pcp
> lists so they do not get shuffled unless the batch is full IIRC.
So I am pretty sure my previous data was faulty. One side effect of the
page reporting is that it was evicting pages out of the guest and when the
pages were faulted back in they were coming from local page pools. This
was throwing off my early numbers and making tests look better than they
should have for the reported case.
I had this patch previously merged with another one so I wasn't testing it
on its own, it was instead a part of a bigger set. Now that I have tried
testing it on its own I can see that it has no significant impact on
performance. With that being the case I will probably just drop it.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 1/8] mm: Add per-cpu logic to page shuffling
From: Alexander Duyck @ 2019-09-10 22:11 UTC (permalink / raw)
To: David Hildenbrand, Alexander Duyck, virtio-dev, kvm, mst,
catalin.marinas, dave.hansen, linux-kernel, willy, mhocko,
linux-mm, akpm, will, linux-arm-kernel, osalvador
Cc: yang.zhang.wz, pagupta, riel, konrad.wilk, ying.huang,
lcapitulino, wei.w.wang, aarcange, nitesh, pbonzini,
dan.j.williams, fengguang.wu, kirill.shutemov
In-Reply-To: <0df2e5d0-af92-04b4-aa7d-891387874039@redhat.com>
On Mon, 2019-09-09 at 10:14 +0200, David Hildenbrand wrote:
> On 07.09.19 19:25, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> >
> > Change the logic used to generate randomness in the suffle path so that we
> > can avoid cache line bouncing. The previous logic was sharing the offset
> > and entropy word between all CPUs. As such this can result in cache line
> > bouncing and will ultimately hurt performance when enabled.
>
> So, usually we perform such changes if there is real evidence. Do you
> have any such performance numbers to back your claims?
I don't have any numbers. From what I can tell the impact is small enough
that this doesn't really have much impact.
With that being the case I can probably just drop this patch. I will
instead just use "rand & 1" in the 2nd patch to generate the return value
which was what was previously done in add_to_free_area_random.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/4] gpio/aspeed: Fix incorrect number of banks
From: Vijay Khemka @ 2019-09-10 22:05 UTC (permalink / raw)
To: Rashmica Gupta, linus.walleij@linaro.org
Cc: linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-aspeed@lists.ozlabs.org,
Bartosz Golaszewski
In-Reply-To: <20190905011635.15902-1-rashmica.g@gmail.com>
On 9/4/19, 6:17 PM, "Linux-aspeed on behalf of Rashmica Gupta" <linux-aspeed-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of rashmica.g@gmail.com> wrote:
The current calculation for the number of GPIO banks is only correct if
the number of GPIOs is a multiple of 32 (if there were 31 GPIOs we would
currently say there are 0 banks, which is incorrect).
Fixes: 361b79119a4b7 ('gpio: Add Aspeed driver')
Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
Reviewed-by: Vijay Khemka <vijaykhemka@fb.com>
---
drivers/gpio/gpio-aspeed.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 9defe25d4721..b83e23aecd18 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -1165,7 +1165,7 @@ static int __init aspeed_gpio_probe(struct platform_device *pdev)
gpio->chip.base = -1;
/* Allocate a cache of the output registers */
- banks = gpio->config->nr_gpios >> 5;
+ banks = DIV_ROUND_UP(gpio->config->nr_gpios, 32);
Good catch
gpio->dcache = devm_kcalloc(&pdev->dev,
banks, sizeof(u32), GFP_KERNEL);
if (!gpio->dcache)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: Alexander Duyck @ 2019-09-10 21:23 UTC (permalink / raw)
To: Michal Hocko, Alexander Duyck
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, lcapitulino, linux-mm, will, Andrea Arcangeli,
virtio-dev, Michael S. Tsirkin, Matthew Wilcox, Wang, Wei W,
ying.huang, Rik van Riel, Konrad Rzeszutek Wilk, Dan Williams,
linux-arm-kernel, Oscar Salvador, Nitesh Narayan Lal, Dave Hansen,
LKML, Paolo Bonzini, Andrew Morton, Fengguang Wu,
Kirill A. Shutemov
In-Reply-To: <20190910175213.GD4023@dhcp22.suse.cz>
On Tue, 2019-09-10 at 19:52 +0200, Michal Hocko wrote:
> On Tue 10-09-19 09:05:43, Alexander Duyck wrote:
> > On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote:
> > > On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> > > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> wrote:
> > > > > I wanted to review "mm: Introduce Reported pages" just realize that I
> > > > > have no clue on what is going on so returned to the cover and it didn't
> > > > > really help much. I am completely unfamiliar with virtio so please bear
> > > > > with me.
> > > > >
> > > > > On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> > > > > [...]
> > > > > > This series provides an asynchronous means of reporting to a hypervisor
> > > > > > that a guest page is no longer in use and can have the data associated
> > > > > > with it dropped. To do this I have implemented functionality that allows
> > > > > > for what I am referring to as unused page reporting
> > > > > >
> > > > > > The functionality for this is fairly simple. When enabled it will allocate
> > > > > > statistics to track the number of reported pages in a given free area.
> > > > > > When the number of free pages exceeds this value plus a high water value,
> > > > > > currently 32, it will begin performing page reporting which consists of
> > > > > > pulling pages off of free list and placing them into a scatter list. The
> > > > > > scatterlist is then given to the page reporting device and it will perform
> > > > > > the required action to make the pages "reported", in the case of
> > > > > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > > > > and as such they are forced out of the guest. After this they are placed
> > > > > > back on the free list,
> > > > >
> > > > > And here I am reallly lost because "forced out of the guest" makes me
> > > > > feel that those pages are no longer usable by the guest. So how come you
> > > > > can add them back to the free list. I suspect understanding this part
> > > > > will allow me to understand why we have to mark those pages and prevent
> > > > > merging.
> > > >
> > > > Basically as the paragraph above mentions "forced out of the guest"
> > > > really is just the hypervisor calling MADV_DONTNEED on the page in
> > > > question. So the behavior is the same as any userspace application
> > > > that calls MADV_DONTNEED where the contents are no longer accessible
> > > > from userspace and attempting to access them will result in a fault
> > > > and the page being populated with a zero fill on-demand page, or a
> > > > copy of the file contents if the memory is file backed.
> > >
> > > As I've said I have no idea about virt so this doesn't really tell me
> > > much. Does that mean that if somebody allocates such a page and tries to
> > > access it then virt will handle a fault and bring it back?
> >
> > Actually I am probably describing too much as the MADV_DONTNEED is the
> > hypervisor behavior in response to the virtio-balloon notification. A
> > more thorough explanation of it can be found by just running "man
> > madvise", probably best just to leave it at that since I am probably
> > confusing things by describing hypervisor behavior in a kernel patch
> > set.
>
> This analogy is indeed confusing and doesn't help to build a picture.
All I am really doing is using a pointer per free_list, the page->index,
and a page flag to provide a way to iterate over the list in such a way
that I will not repeat the operation on a page I have already reported. It
is taking advantage of the fact that we add pages to either the head or
the tail of the list, and can pull the pages from anywhere in the list, so
we have to work around those edges to avoid processing the already
reported pages in between.
Admittedly this is pretty complex. I've been at this for several months,
and have gone through several iterations.
If it helps I can try to draw it out as a bit of ASCII art. Basically what
I am trying to do is find a way to skip over the blob of reported pages
that would exist after we have not been reporting for a little while. Most
of this logic is in the get_reported_pages/free_reported_pages that should
be in patch 6.
So on our first iteration through the pages it is pretty straightforward.
We basically just keep pushing the boundary pointer up, we fetch the pages
immediately in front of it, and then when we return the now-reported pages
we push the boundary pointer up to those pages.
While we are actively reporting a given zone we prevent any pages from
being inserted behind the boundary. They are always inserted before the
boundary pointer. This is achieved by replacing the free_list tail pointer
value with the boundary pointer value in the case of add_to_tail calls.
Legend:
U Unused Page
R Reported Page
< Boundary Reported Page
Head ....................................................... Tail
Start UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU <
.. UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU<RRRRRRRRRRRRRRRRRRRRRRR
End UU<RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
After we completed the boundary pointer is discarded and we don't have to
update it when the zone->flag indicating reporting is active is no longer
set. What we then have happening is that pages are pulled out of the
free_list at random locations or from the head. This causes the list of
reported pages to slowly shrink, however the block of pages should remain
contiguous since new pages are only added to the head or the tail.
Head ....................................................... Tail
Idle UUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRUUUU
Once we have a large enough difference between the nr_free and
reported_pages we will then restart the reporting by resetting the
boundary to the tail and proceeding to pull the non-reported pages that
are in front of the boundary(fig1). Once those are exhasusted we will
start pulling the pages from the head of the list, reporting those, and
then placing them back at the boundary(fig2). When we finally hit the
point where there are no more pages to pull from the head that are not
reported we will update the boundary to the first reported page in the
list, return the reported pages there, and we should be done reporting
pages from this free list.
Head ....................................................... Tail
Start UUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRUUUU <
fig1 UUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRU<RRRR
fig2 UUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR<RRRRRRRRRRRRRRRRRRRR
End UU<RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
The goal with all this is to allow the boundary pointer to move, but to
guarantee forward progress as we work our way through the free_list(s).
Essentially the only requirements we are posing on the page allocator is
that if it pulls the page at the boundary it has to push it back, and if
it wants to add to the tail it has to use the boundary page as the tail
instead.
> > For the most part all the page reporting really does is provide a way
> > to incrementally identify unused regions of memory in the buddy
> > allocator. That in turn is used by virtio-balloon in a polling thread
> > to report to the hypervisor what pages are not in use so that it can
> > make a decision on what to do with the pages now that it knows they
> > are unused.
>
> So essentially you want to store metadata into free pages and control
> what the allocator can do with them? Namely buddy merging if the type
> doesn't match?
We don't put any limitations on the allocator other then that it needs to
clean up the metadata on allocation, and that it cannot allocate a page
that is in the process of being reported since we pulled it from the
free_list. If the page is a "Reported" page then it decrements the
reported_pages count for the free_area and makes sure the page doesn't
exist in the "Boundary" array pointer value, if it does it moves the
"Boundary" since it is pulling the page.
> > All this is providing is just a report and it is optional if the
> > hypervisor will act on it or not. If the hypervisor takes some sort of
> > action on the page, then the expectation is that the hypervisor will
> > use some sort of mechanism such as a page fault to discover when the
> > page is used again.
>
> OK so the baloon driver is in charge of this metadata and the allocator
> has to live with that. Isn't that a layer violation?
Really the metadata belongs to the page reporting. The virtio balloon
driver doesn't get to see any of it. It basically registers as a Reporting
interface and then we start sending it scatterlists to report. It doesn't
do anything with the actual pages themselves other then DMA map the
physical addresses for them.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: Alexander Duyck @ 2019-09-10 20:37 UTC (permalink / raw)
To: Michal Hocko, Alexander Duyck
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, lcapitulino, linux-mm, will, Andrea Arcangeli,
virtio-dev, Michael S. Tsirkin, Matthew Wilcox, Wang, Wei W,
ying.huang, Rik van Riel, Konrad Rzeszutek Wilk, Dan Williams,
linux-arm-kernel, Oscar Salvador, Nitesh Narayan Lal, Dave Hansen,
LKML, Paolo Bonzini, Andrew Morton, Fengguang Wu,
Kirill A. Shutemov
In-Reply-To: <20190910180026.GE4023@dhcp22.suse.cz>
On Tue, 2019-09-10 at 20:00 +0200, Michal Hocko wrote:
> On Tue 10-09-19 19:52:13, Michal Hocko wrote:
> > On Tue 10-09-19 09:05:43, Alexander Duyck wrote:
> [...]
> > > All this is providing is just a report and it is optional if the
> > > hypervisor will act on it or not. If the hypervisor takes some sort of
> > > action on the page, then the expectation is that the hypervisor will
> > > use some sort of mechanism such as a page fault to discover when the
> > > page is used again.
> >
> > OK so the baloon driver is in charge of this metadata and the allocator
> > has to live with that. Isn't that a layer violation?
>
> Another thing that is not clear to me is how these marked pages are
> different from any other free pages. All of them are unused and you are
> losing your metadata as soon as the page gets allocated because the page
> changes its owner and the struct page belongs to it.
Really they aren't any different then other free pages other than they are
marked. Us losing the metadata as soon as the page is allocated is fine as
we will need to re-report it when it is returned so we no longer need the
metadata once it is allocated.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next 0/6] net: stmmac: Improvements for -next
From: Jesse Brandeburg @ 2019-09-10 20:36 UTC (permalink / raw)
To: Jose Abreu
Cc: Joao Pinto, Alexandre Torgue, netdev, linux-kernel, linux-stm32,
jesse.brandeburg, Maxime Coquelin, Giuseppe Cavallaro,
David S. Miller, linux-arm-kernel
In-Reply-To: <cover.1568126224.git.joabreu@synopsys.com>
On Tue, 10 Sep 2019 16:41:21 +0200 Jose wrote:
> Misc patches for -next. It includes:
> - Two fixes for features in -next only
> - New features support for GMAC cores (which includes GMAC4 and GMAC5)
>
> ---
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: Jose Abreu <joabreu@synopsys.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: netdev@vger.kernel.org
> Cc: linux-stm32@st-md-mailman.stormreply.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>
> Jose Abreu (6):
> net: stmmac: Prevent divide-by-zero
> net: stmmac: Add VLAN HASH filtering support in GMAC4+
> net: stmmac: xgmac: Reinitialize correctly a variable
> net: stmmac: Add support for SA Insertion/Replacement in GMAC4+
> net: stmmac: Add support for VLAN Insertion Offload in GMAC4+
> net: stmmac: ARP Offload for GMAC4+ Cores
For the series, looks good to me.
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang
From: Qian Cai @ 2019-09-10 20:35 UTC (permalink / raw)
To: Petr Mladek, Steven Rostedt, Catalin Marinas, Will Deacon
Cc: Sergey Senozhatsky, Peter Zijlstra, linux-kernel, linux-mm,
Waiman Long, Dan Williams, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <1568128954.5576.129.camel@lca.pw>
On Tue, 2019-09-10 at 11:22 -0400, Qian Cai wrote:
> On Thu, 2019-09-05 at 17:08 -0400, Qian Cai wrote:
> > Another data point is if change CONFIG_DEBUG_OBJECTS_TIMERS from =y to =n, it
> > will also fix it.
> >
> > On Thu, 2019-08-22 at 17:33 -0400, Qian Cai wrote:
> > > https://raw.githubusercontent.com/cailca/linux-mm/master/arm64.config
> > >
> > > Booting an arm64 ThunderX2 server with page_alloc.shuffle=1 [1] +
> > > CONFIG_PROVE_LOCKING=y results in hanging.
> > >
> > > [1] https://lore.kernel.org/linux-mm/154899811208.3165233.17623209031065121886.s
> > > tgit@dwillia2-desk3.amr.corp.intel.com/
> > >
> > > ...
> > > [ 125.142689][ T1] arm-smmu-v3 arm-smmu-v3.2.auto: option mask 0x2
> > > [ 125.149687][ T1] arm-smmu-v3 arm-smmu-v3.2.auto: ias 44-bit, oas 44-bit
> > > (features 0x0000170d)
> > > [ 125.165198][ T1] arm-smmu-v3 arm-smmu-v3.2.auto: allocated 524288 entries
> > > for cmdq
> > > [ 125.239425][ [ 125.251484][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: option
> > > mask 0x2
> > > [ 125.258233][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: ias 44-bit, oas 44-bit
> > > (features 0x0000170d)
> > > [ 125.282750][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: allocated 524288 entries
> > > for cmdq
> > > [ 125.320097][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: allocated 524288 entries
> > > for evtq
> > > [ 125.332667][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: option mask 0x2
> > > [ 125.339427][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: ias 44-bit, oas 44-bit
> > > (features 0x0000170d)
> > > [ 125.354846][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries
> > > for cmdq
> > > [ 125.375295][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries
> > > for evtq
> > > [ 125.387371][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: option mask 0x2
> > > [ 125.393955][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: ias 44-bit, oas 44-bit
> > > (features 0x0000170d)
> > > [ 125.522605][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries
> > > for cmdq
> > > [ 125.543338][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries
> > > for evtq
> > > [ 126.694742][ T1] EFI Variables Facility v0.08 2004-May-17
> > > [ 126.799291][ T1] NET: Registered protocol family 17
> > > [ 126.978632][ T1] zswap: loaded using pool lzo/zbud
> > > [ 126.989168][ T1] kmemleak: Kernel memory leak detector initialized
> > > [ 126.989191][ T1577] kmemleak: Automatic memory scanning thread started
> > > [ 127.044079][ T1335] pcieport 0000:0f:00.0: Adding to iommu group 0
> > > [ 127.388074][ T1] Freeing unused kernel memory: 22528K
> > > [ 133.527005][ T1] Checked W+X mappings: passed, no W+X pages found
> > > [ 133.533474][ T1] Run /init as init process
> > > [ 133.727196][ T1] systemd[1]: System time before build time, advancing
> > > clock.
> > > [ 134.576021][ T1587] modprobe (1587) used greatest stack depth: 27056 bytes
> > > left
> > > [ 134.764026][ T1] systemd[1]: systemd 239 running in system mode. (+PAM
> > > +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT
> > > +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-
> > > hierarchy=legacy)
> > > [ 134.799044][ T1] systemd[1]: Detected architecture arm64.
> > > [ 134.804818][ T1] systemd[1]: Running in initial RAM disk.
> > > <...hang...>
> > >
> > > Fix it by either set page_alloc.shuffle=0 or CONFIG_PROVE_LOCKING=n which allow
> > > it to continue successfully.
> > >
> > >
> > > [ 121.093846][ T1] systemd[1]: Set hostname to <hpe-apollo-cn99xx>.
> > > [ 123.157524][ T1] random: systemd: uninitialized urandom read (16 bytes
> > > read)
> > > [ 123.168562][ T1] systemd[1]: Listening on Journal Socket.
> > > [ OK ] Listening on Journal Socket.
> > > [ 123.203932][ T1] random: systemd: uninitialized urandom read (16 bytes
> > > read)
> > > [ 123.212813][ T1] systemd[1]: Listening on udev Kernel Socket.
> > > [ OK ] Listening on udev Kernel Socket.
> > > ...
>
> Not sure if the arm64 hang is just an effect of the potential console deadlock
> below. The lockdep splat can be reproduced by set,
>
> CONFIG_DEBUG_OBJECTS_TIMER=n (=y will lead to the hang above)
> CONFIG_PROVE_LOCKING=y
> CONFIG_SLAB_FREELIST_RANDOM=y (with page_alloc.shuffle=1)
>
> while compiling kernels,
This is more than likely, as this debug patch alone will fix the hang,
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 9b54cdb301d3..4d5c38035f03 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -2323,7 +2323,7 @@ u64 get_random_u64(void)
return ret;
#endif
- warn_unseeded_randomness(&previous);
+ //warn_unseeded_randomness(&previous);
batch = raw_cpu_ptr(&batched_entropy_u64);
spin_lock_irqsave(&batch->batch_lock, flags);
which mostly indicates that the additional printk() from this path due to
"page_alloc.shuffle=1" causes a real deadlock,
allocate_slab
shuffle_freelist
get_random_u64
warn_unseeded_randomness
printk
>
> [ 1078.214683][T43784] WARNING: possible circular locking dependency detected
> [ 1078.221550][T43784] 5.3.0-rc7-next-20190904 #14 Not tainted
> [ 1078.227112][T43784] ------------------------------------------------------
> [ 1078.233976][T43784] vi/43784 is trying to acquire lock:
> [ 1078.239192][T43784] ffff008b7cff9290 (&(&zone->lock)->rlock){-.-.}, at:
> rmqueue_bulk.constprop.21+0xb0/0x1218
> [ 1078.249111][T43784]
> [ 1078.249111][T43784] but task is already holding lock:
> [ 1078.256322][T43784] ffff00938db47d40 (&(&port->lock)->rlock){-.-.}, at:
> pty_write+0x78/0x100
> [ 1078.264760][T43784]
> [ 1078.264760][T43784] which lock already depends on the new lock.
> [ 1078.264760][T43784]
> [ 1078.275008][T43784]
> [ 1078.275008][T43784] the existing dependency chain (in reverse order) is:
> [ 1078.283869][T43784]
> [ 1078.283869][T43784] -> #3 (&(&port->lock)->rlock){-.-.}:
> [ 1078.291350][T43784] __lock_acquire+0x5c8/0xbb0
> [ 1078.296394][T43784] lock_acquire+0x154/0x428
> [ 1078.301266][T43784] _raw_spin_lock_irqsave+0x80/0xa0
> [ 1078.306831][T43784] tty_port_tty_get+0x28/0x68
> [ 1078.311873][T43784] tty_port_default_wakeup+0x20/0x40
> [ 1078.317523][T43784] tty_port_tty_wakeup+0x38/0x48
> [ 1078.322827][T43784] uart_write_wakeup+0x2c/0x50
> [ 1078.327956][T43784] pl011_tx_chars+0x240/0x260
> [ 1078.332999][T43784] pl011_start_tx+0x24/0xa8
> [ 1078.337868][T43784] __uart_start+0x90/0xa0
> [ 1078.342563][T43784] uart_write+0x15c/0x2c8
> [ 1078.347261][T43784] do_output_char+0x1c8/0x2b0
> [ 1078.352304][T43784] n_tty_write+0x300/0x668
> [ 1078.357087][T43784] tty_write+0x2e8/0x430
> [ 1078.361696][T43784] redirected_tty_write+0xcc/0xe8
> [ 1078.367086][T43784] do_iter_write+0x228/0x270
> [ 1078.372041][T43784] vfs_writev+0x10c/0x1c8
> [ 1078.376735][T43784] do_writev+0xdc/0x180
> [ 1078.381257][T43784] __arm64_sys_writev+0x50/0x60
> [ 1078.386476][T43784] el0_svc_handler+0x11c/0x1f0
> [ 1078.391606][T43784] el0_svc+0x8/0xc
> [ 1078.395691][T43784]
> [ 1078.395691][T43784] -> #2 (&port_lock_key){-.-.}:
> [ 1078.402561][T43784] __lock_acquire+0x5c8/0xbb0
> [ 1078.407604][T43784] lock_acquire+0x154/0x428
> [ 1078.412474][T43784] _raw_spin_lock+0x68/0x88
> [ 1078.417343][T43784] pl011_console_write+0x2ac/0x318
> [ 1078.422820][T43784] console_unlock+0x3c4/0x898
> [ 1078.427863][T43784] vprintk_emit+0x2d4/0x460
> [ 1078.432732][T43784] vprintk_default+0x48/0x58
> [ 1078.437688][T43784] vprintk_func+0x194/0x250
> [ 1078.442557][T43784] printk+0xbc/0xec
> [ 1078.446732][T43784] register_console+0x4a8/0x580
> [ 1078.451947][T43784] uart_add_one_port+0x748/0x878
> [ 1078.457250][T43784] pl011_register_port+0x98/0x128
> [ 1078.462639][T43784] sbsa_uart_probe+0x398/0x480
> [ 1078.467772][T43784] platform_drv_probe+0x70/0x108
> [ 1078.473075][T43784] really_probe+0x15c/0x5d8
> [ 1078.477944][T43784] driver_probe_device+0x94/0x1d0
> [ 1078.483335][T43784] __device_attach_driver+0x11c/0x1a8
> [ 1078.489072][T43784] bus_for_each_drv+0xf8/0x158
> [ 1078.494201][T43784] __device_attach+0x164/0x240
> [ 1078.499331][T43784] device_initial_probe+0x24/0x30
> [ 1078.504721][T43784] bus_probe_device+0xf0/0x100
> [ 1078.509850][T43784] device_add+0x63c/0x960
> [ 1078.514546][T43784] platform_device_add+0x1ac/0x3b8
> [ 1078.520023][T43784] platform_device_register_full+0x1fc/0x290
> [ 1078.526373][T43784] acpi_create_platform_device.part.0+0x264/0x3a8
> [ 1078.533152][T43784] acpi_create_platform_device+0x68/0x80
> [ 1078.539150][T43784] acpi_default_enumeration+0x34/0x78
> [ 1078.544887][T43784] acpi_bus_attach+0x340/0x3b8
> [ 1078.550015][T43784] acpi_bus_attach+0xf8/0x3b8
> [ 1078.555057][T43784] acpi_bus_attach+0xf8/0x3b8
> [ 1078.560099][T43784] acpi_bus_attach+0xf8/0x3b8
> [ 1078.565142][T43784] acpi_bus_scan+0x9c/0x100
> [ 1078.570015][T43784] acpi_scan_init+0x16c/0x320
> [ 1078.575058][T43784] acpi_init+0x330/0x3b8
> [ 1078.579666][T43784] do_one_initcall+0x158/0x7ec
> [ 1078.584797][T43784] kernel_init_freeable+0x9a8/0xa70
> [ 1078.590360][T43784] kernel_init+0x18/0x138
> [ 1078.595055][T43784] ret_from_fork+0x10/0x1c
> [ 1078.599835][T43784]
> [ 1078.599835][T43784] -> #1 (console_owner){-...}:
> [ 1078.606618][T43784] __lock_acquire+0x5c8/0xbb0
> [ 1078.611661][T43784] lock_acquire+0x154/0x428
> [ 1078.616530][T43784] console_unlock+0x298/0x898
> [ 1078.621573][T43784] vprintk_emit+0x2d4/0x460
> [ 1078.626442][T43784] vprintk_default+0x48/0x58
> [ 1078.631398][T43784] vprintk_func+0x194/0x250
> [ 1078.636267][T43784] printk+0xbc/0xec
> [ 1078.640443][T43784] _warn_unseeded_randomness+0xb4/0xd0
> [ 1078.646267][T43784] get_random_u64+0x4c/0x100
> [ 1078.651224][T43784] add_to_free_area_random+0x168/0x1a0
> [ 1078.657047][T43784] free_one_page+0x3dc/0xd08
> [ 1078.662003][T43784] __free_pages_ok+0x490/0xd00
> [ 1078.667132][T43784] __free_pages+0xc4/0x118
> [ 1078.671914][T43784] __free_pages_core+0x2e8/0x428
> [ 1078.677219][T43784] memblock_free_pages+0xa4/0xec
> [ 1078.682522][T43784] memblock_free_all+0x264/0x330
> [ 1078.687825][T43784] mem_init+0x90/0x148
> [ 1078.692259][T43784] start_kernel+0x368/0x684
> [ 1078.697126][T43784]
> [ 1078.697126][T43784] -> #0 (&(&zone->lock)->rlock){-.-.}:
> [ 1078.704604][T43784] check_prev_add+0x120/0x1138
> [ 1078.709733][T43784] validate_chain+0x888/0x1270
> [ 1078.714863][T43784] __lock_acquire+0x5c8/0xbb0
> [ 1078.719906][T43784] lock_acquire+0x154/0x428
> [ 1078.724776][T43784] _raw_spin_lock+0x68/0x88
> [ 1078.729645][T43784] rmqueue_bulk.constprop.21+0xb0/0x1218
> [ 1078.735643][T43784] get_page_from_freelist+0x898/0x24a0
> [ 1078.741467][T43784] __alloc_pages_nodemask+0x2a8/0x1d08
> [ 1078.747291][T43784] alloc_pages_current+0xb4/0x150
> [ 1078.752682][T43784] allocate_slab+0xab8/0x2350
> [ 1078.757725][T43784] new_slab+0x98/0xc0
> [ 1078.762073][T43784] ___slab_alloc+0x66c/0xa30
> [ 1078.767029][T43784] __slab_alloc+0x68/0xc8
> [ 1078.771725][T43784] __kmalloc+0x3d4/0x658
> [ 1078.776333][T43784] __tty_buffer_request_room+0xd4/0x220
> [ 1078.782244][T43784] tty_insert_flip_string_fixed_flag+0x6c/0x128
> [ 1078.788849][T43784] pty_write+0x98/0x100
> [ 1078.793370][T43784] n_tty_write+0x2a0/0x668
> [ 1078.798152][T43784] tty_write+0x2e8/0x430
> [ 1078.802760][T43784] __vfs_write+0x5c/0xb0
> [ 1078.807368][T43784] vfs_write+0xf0/0x230
> [ 1078.811890][T43784] ksys_write+0xd4/0x180
> [ 1078.816498][T43784] __arm64_sys_write+0x4c/0x60
> [ 1078.821627][T43784] el0_svc_handler+0x11c/0x1f0
> [ 1078.826756][T43784] el0_svc+0x8/0xc
> [ 1078.830842][T43784]
> [ 1078.830842][T43784] other info that might help us debug this:
> [ 1078.830842][T43784]
> [ 1078.840918][T43784] Chain exists of:
> [ 1078.840918][T43784] &(&zone->lock)->rlock --> &port_lock_key --> &(&port-
> > lock)->rlock
>
> [ 1078.840918][T43784]
> [ 1078.854731][T43784] Possible unsafe locking scenario:
> [ 1078.854731][T43784]
> [ 1078.862029][T43784] CPU0 CPU1
> [ 1078.867243][T43784] ---- ----
> [ 1078.872457][T43784] lock(&(&port->lock)->rlock);
> [ 1078.877238][T43784] lock(&port_lock_key);
> [ 1078.883929][T43784] lock(&(&port->lock)-
> > rlock);
>
> [ 1078.891228][T43784] lock(&(&zone->lock)->rlock);
> [ 1078.896010][T43784]
> [ 1078.896010][T43784] *** DEADLOCK ***
> [ 1078.896010][T43784]
> [ 1078.904004][T43784] 5 locks held by vi/43784:
> [ 1078.908351][T43784] #0: ffff000c36240890 (&tty->ldisc_sem){++++}, at:
> ldsem_down_read+0x44/0x50
> [ 1078.917133][T43784] #1: ffff000c36240918 (&tty->atomic_write_lock){+.+.},
> at: tty_write_lock+0x24/0x60
> [ 1078.926521][T43784] #2: ffff000c36240aa0 (&o_tty->termios_rwsem/1){++++},
> at: n_tty_write+0x108/0x668
> [ 1078.935823][T43784] #3: ffffa0001e0b2360 (&ldata->output_lock){+.+.}, at:
> n_tty_write+0x1d0/0x668
> [ 1078.944777][T43784] #4: ffff00938db47d40 (&(&port->lock)->rlock){-.-.}, at:
> pty_write+0x78/0x100
> [ 1078.953644][T43784]
> [ 1078.953644][T43784] stack backtrace:
> [ 1078.959382][T43784] CPU: 97 PID: 43784 Comm: vi Not tainted 5.3.0-rc7-next-
> 20190904 #14
> [ 1078.967376][T43784] Hardware name: HPE Apollo
> 70 /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019
> [ 1078.977799][T43784] Call trace:
> [ 1078.980932][T43784] dump_backtrace+0x0/0x228
> [ 1078.985279][T43784] show_stack+0x24/0x30
> [ 1078.989282][T43784] dump_stack+0xe8/0x13c
> [ 1078.993370][T43784] print_circular_bug+0x334/0x3d8
> [ 1078.998240][T43784] check_noncircular+0x268/0x310
> [ 1079.003022][T43784] check_prev_add+0x120/0x1138
> [ 1079.007631][T43784] validate_chain+0x888/0x1270
> [ 1079.012241][T43784] __lock_acquire+0x5c8/0xbb0
> [ 1079.016763][T43784] lock_acquire+0x154/0x428
> [ 1079.021111][T43784] _raw_spin_lock+0x68/0x88
> [ 1079.025460][T43784] rmqueue_bulk.constprop.21+0xb0/0x1218
> [ 1079.030937][T43784] get_page_from_freelist+0x898/0x24a0
> [ 1079.036240][T43784] __alloc_pages_nodemask+0x2a8/0x1d08
> [ 1079.041542][T43784] alloc_pages_current+0xb4/0x150
> [ 1079.046412][T43784] allocate_slab+0xab8/0x2350
> [ 1079.050934][T43784] new_slab+0x98/0xc0
> [ 1079.054761][T43784] ___slab_alloc+0x66c/0xa30
> [ 1079.059196][T43784] __slab_alloc+0x68/0xc8
> [ 1079.063371][T43784] __kmalloc+0x3d4/0x658
> [ 1079.067458][T43784] __tty_buffer_request_room+0xd4/0x220
> [ 1079.072847][T43784] tty_insert_flip_string_fixed_flag+0x6c/0x128
> [ 1079.078932][T43784] pty_write+0x98/0x100
> [ 1079.082932][T43784] n_tty_write+0x2a0/0x668
> [ 1079.087193][T43784] tty_write+0x2e8/0x430
> [ 1079.091280][T43784] __vfs_write+0x5c/0xb0
> [ 1079.095367][T43784] vfs_write+0xf0/0x230
> [ 1079.099368][T43784] ksys_write+0xd4/0x180
> [ 1079.103455][T43784] __arm64_sys_write+0x4c/0x60
> [ 1079.108064][T43784] el0_svc_handler+0x11c/0x1f0
> [ 1079.112672][T43784] el0_svc+0x8/0xc
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h
From: Alexander Duyck @ 2019-09-10 20:26 UTC (permalink / raw)
To: Michal Hocko, Alexander Duyck
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, lcapitulino, linux-mm, will, Andrea Arcangeli,
virtio-dev, Michael S. Tsirkin, Matthew Wilcox, Wang, Wei W,
ying.huang, Rik van Riel, Konrad Rzeszutek Wilk, Dan Williams,
linux-arm-kernel, Oscar Salvador, Nitesh Narayan Lal, Dave Hansen,
LKML, Paolo Bonzini, Andrew Morton, Fengguang Wu,
Kirill A. Shutemov
In-Reply-To: <20190910174553.GC4023@dhcp22.suse.cz>
On Tue, 2019-09-10 at 19:45 +0200, Michal Hocko wrote:
> On Tue 10-09-19 07:46:50, Alexander Duyck wrote:
> > On Tue, Sep 10, 2019 at 5:23 AM Michal Hocko <mhocko@kernel.org> wrote:
> > > On Sat 07-09-19 10:25:28, Alexander Duyck wrote:
> > > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > >
> > > > In order to support page reporting it will be necessary to store and
> > > > retrieve the migratetype of a page. To enable that I am moving the set and
> > > > get operations for pcppage_migratetype into the mm/internal.h header so
> > > > that they can be used outside of the page_alloc.c file.
> > >
> > > Please describe who is the user and why does it needs this interface.
> > > This is really important because migratetype is an MM internal thing and
> > > external users shouldn't really care about it at all. We really do not
> > > want a random code to call those, especially the set_pcppage_migratetype.
> >
> > I was using it to store the migratetype of the page so that I could
> > find the boundary list that contained the reported page as the array
> > is indexed based on page order and migratetype. However on further
> > discussion I am thinking I may just use page->index directly to index
> > into the boundary array. Doing that I should be able to get a very
> > slight improvement in lookup time since I am not having to pull order
> > and migratetype and then compute the index based on that. In addition
> > it becomes much more clear as to what is going on, and if needed I
> > could add debug checks to verify the page is "Reported" and that the
> > "Buddy" page type is set.
>
> Be careful though. A free page belongs to the page allocator and it is
> free to reuse any fields for its purpose so using any of them nilly
> willy is no go. If you need to stuff something like that then there
> better be an api the allocator is aware of. My main objection is the
> abuse migrate type. There might be other ways to express what you need.
> Please make sure you clearly define that though.
I will. Basically if the Reported is set then it will mean that the index
value is in use and provides the index into the boundary array. The
Reported flag will be cleared when the page is pulled from the buddy list
and in the case of the page being allocated it is already overwritten by
__rmqueue_smallest calling set_pcppage_migratetype which is what gave me
the idea to just use that in the first place.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang
From: Qian Cai @ 2019-09-10 19:49 UTC (permalink / raw)
To: Petr Mladek, Steven Rostedt, Catalin Marinas, Will Deacon,
Theodore Ts'o
Cc: Sergey Senozhatsky, Peter Zijlstra, linux-kernel, linux-mm,
Waiman Long, Dan Williams, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <1568128954.5576.129.camel@lca.pw>
On Tue, 2019-09-10 at 11:22 -0400, Qian Cai wrote:
> On Thu, 2019-09-05 at 17:08 -0400, Qian Cai wrote:
> > Another data point is if change CONFIG_DEBUG_OBJECTS_TIMERS from =y to =n, it
> > will also fix it.
> >
> > On Thu, 2019-08-22 at 17:33 -0400, Qian Cai wrote:
> > > https://raw.githubusercontent.com/cailca/linux-mm/master/arm64.config
> > >
> > > Booting an arm64 ThunderX2 server with page_alloc.shuffle=1 [1] +
> > > CONFIG_PROVE_LOCKING=y results in hanging.
> > >
> > > [1] https://lore.kernel.org/linux-mm/154899811208.3165233.17623209031065121886.s
> > > tgit@dwillia2-desk3.amr.corp.intel.com/
> > >
> > > ...
> > > [ 125.142689][ T1] arm-smmu-v3 arm-smmu-v3.2.auto: option mask 0x2
> > > [ 125.149687][ T1] arm-smmu-v3 arm-smmu-v3.2.auto: ias 44-bit, oas 44-bit
> > > (features 0x0000170d)
> > > [ 125.165198][ T1] arm-smmu-v3 arm-smmu-v3.2.auto: allocated 524288 entries
> > > for cmdq
> > > [ 125.239425][ [ 125.251484][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: option
> > > mask 0x2
> > > [ 125.258233][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: ias 44-bit, oas 44-bit
> > > (features 0x0000170d)
> > > [ 125.282750][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: allocated 524288 entries
> > > for cmdq
> > > [ 125.320097][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: allocated 524288 entries
> > > for evtq
> > > [ 125.332667][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: option mask 0x2
> > > [ 125.339427][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: ias 44-bit, oas 44-bit
> > > (features 0x0000170d)
> > > [ 125.354846][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries
> > > for cmdq
> > > [ 125.375295][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries
> > > for evtq
> > > [ 125.387371][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: option mask 0x2
> > > [ 125.393955][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: ias 44-bit, oas 44-bit
> > > (features 0x0000170d)
> > > [ 125.522605][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries
> > > for cmdq
> > > [ 125.543338][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries
> > > for evtq
> > > [ 126.694742][ T1] EFI Variables Facility v0.08 2004-May-17
> > > [ 126.799291][ T1] NET: Registered protocol family 17
> > > [ 126.978632][ T1] zswap: loaded using pool lzo/zbud
> > > [ 126.989168][ T1] kmemleak: Kernel memory leak detector initialized
> > > [ 126.989191][ T1577] kmemleak: Automatic memory scanning thread started
> > > [ 127.044079][ T1335] pcieport 0000:0f:00.0: Adding to iommu group 0
> > > [ 127.388074][ T1] Freeing unused kernel memory: 22528K
> > > [ 133.527005][ T1] Checked W+X mappings: passed, no W+X pages found
> > > [ 133.533474][ T1] Run /init as init process
> > > [ 133.727196][ T1] systemd[1]: System time before build time, advancing
> > > clock.
> > > [ 134.576021][ T1587] modprobe (1587) used greatest stack depth: 27056 bytes
> > > left
> > > [ 134.764026][ T1] systemd[1]: systemd 239 running in system mode. (+PAM
> > > +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT
> > > +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-
> > > hierarchy=legacy)
> > > [ 134.799044][ T1] systemd[1]: Detected architecture arm64.
> > > [ 134.804818][ T1] systemd[1]: Running in initial RAM disk.
> > > <...hang...>
> > >
> > > Fix it by either set page_alloc.shuffle=0 or CONFIG_PROVE_LOCKING=n which allow
> > > it to continue successfully.
> > >
> > >
> > > [ 121.093846][ T1] systemd[1]: Set hostname to <hpe-apollo-cn99xx>.
> > > [ 123.157524][ T1] random: systemd: uninitialized urandom read (16 bytes
> > > read)
> > > [ 123.168562][ T1] systemd[1]: Listening on Journal Socket.
> > > [ OK ] Listening on Journal Socket.
> > > [ 123.203932][ T1] random: systemd: uninitialized urandom read (16 bytes
> > > read)
> > > [ 123.212813][ T1] systemd[1]: Listening on udev Kernel Socket.
> > > [ OK ] Listening on udev Kernel Socket.
> > > ...
>
> Not sure if the arm64 hang is just an effect of the potential console deadlock
> below. The lockdep splat can be reproduced by set,
>
> CONFIG_DEBUG_OBJECTS_TIMER=n (=y will lead to the hang above)
> CONFIG_PROVE_LOCKING=y
> CONFIG_SLAB_FREELIST_RANDOM=y (with page_alloc.shuffle=1)
>
> while compiling kernels,
>
> [ 1078.214683][T43784] WARNING: possible circular locking dependency detected
> [ 1078.221550][T43784] 5.3.0-rc7-next-20190904 #14 Not tainted
> [ 1078.227112][T43784] ------------------------------------------------------
> [ 1078.233976][T43784] vi/43784 is trying to acquire lock:
> [ 1078.239192][T43784] ffff008b7cff9290 (&(&zone->lock)->rlock){-.-.}, at:
> rmqueue_bulk.constprop.21+0xb0/0x1218
> [ 1078.249111][T43784]
> [ 1078.249111][T43784] but task is already holding lock:
> [ 1078.256322][T43784] ffff00938db47d40 (&(&port->lock)->rlock){-.-.}, at:
> pty_write+0x78/0x100
> [ 1078.264760][T43784]
> [ 1078.264760][T43784] which lock already depends on the new lock.
> [ 1078.264760][T43784]
> [ 1078.275008][T43784]
> [ 1078.275008][T43784] the existing dependency chain (in reverse order) is:
> [ 1078.283869][T43784]
> [ 1078.283869][T43784] -> #3 (&(&port->lock)->rlock){-.-.}:
> [ 1078.291350][T43784] __lock_acquire+0x5c8/0xbb0
> [ 1078.296394][T43784] lock_acquire+0x154/0x428
> [ 1078.301266][T43784] _raw_spin_lock_irqsave+0x80/0xa0
> [ 1078.306831][T43784] tty_port_tty_get+0x28/0x68
> [ 1078.311873][T43784] tty_port_default_wakeup+0x20/0x40
> [ 1078.317523][T43784] tty_port_tty_wakeup+0x38/0x48
> [ 1078.322827][T43784] uart_write_wakeup+0x2c/0x50
> [ 1078.327956][T43784] pl011_tx_chars+0x240/0x260
> [ 1078.332999][T43784] pl011_start_tx+0x24/0xa8
> [ 1078.337868][T43784] __uart_start+0x90/0xa0
> [ 1078.342563][T43784] uart_write+0x15c/0x2c8
> [ 1078.347261][T43784] do_output_char+0x1c8/0x2b0
> [ 1078.352304][T43784] n_tty_write+0x300/0x668
> [ 1078.357087][T43784] tty_write+0x2e8/0x430
> [ 1078.361696][T43784] redirected_tty_write+0xcc/0xe8
> [ 1078.367086][T43784] do_iter_write+0x228/0x270
> [ 1078.372041][T43784] vfs_writev+0x10c/0x1c8
> [ 1078.376735][T43784] do_writev+0xdc/0x180
> [ 1078.381257][T43784] __arm64_sys_writev+0x50/0x60
> [ 1078.386476][T43784] el0_svc_handler+0x11c/0x1f0
> [ 1078.391606][T43784] el0_svc+0x8/0xc
> [ 1078.395691][T43784]
> [ 1078.395691][T43784] -> #2 (&port_lock_key){-.-.}:
> [ 1078.402561][T43784] __lock_acquire+0x5c8/0xbb0
> [ 1078.407604][T43784] lock_acquire+0x154/0x428
> [ 1078.412474][T43784] _raw_spin_lock+0x68/0x88
> [ 1078.417343][T43784] pl011_console_write+0x2ac/0x318
> [ 1078.422820][T43784] console_unlock+0x3c4/0x898
> [ 1078.427863][T43784] vprintk_emit+0x2d4/0x460
> [ 1078.432732][T43784] vprintk_default+0x48/0x58
> [ 1078.437688][T43784] vprintk_func+0x194/0x250
> [ 1078.442557][T43784] printk+0xbc/0xec
> [ 1078.446732][T43784] register_console+0x4a8/0x580
> [ 1078.451947][T43784] uart_add_one_port+0x748/0x878
> [ 1078.457250][T43784] pl011_register_port+0x98/0x128
> [ 1078.462639][T43784] sbsa_uart_probe+0x398/0x480
> [ 1078.467772][T43784] platform_drv_probe+0x70/0x108
> [ 1078.473075][T43784] really_probe+0x15c/0x5d8
> [ 1078.477944][T43784] driver_probe_device+0x94/0x1d0
> [ 1078.483335][T43784] __device_attach_driver+0x11c/0x1a8
> [ 1078.489072][T43784] bus_for_each_drv+0xf8/0x158
> [ 1078.494201][T43784] __device_attach+0x164/0x240
> [ 1078.499331][T43784] device_initial_probe+0x24/0x30
> [ 1078.504721][T43784] bus_probe_device+0xf0/0x100
> [ 1078.509850][T43784] device_add+0x63c/0x960
> [ 1078.514546][T43784] platform_device_add+0x1ac/0x3b8
> [ 1078.520023][T43784] platform_device_register_full+0x1fc/0x290
> [ 1078.526373][T43784] acpi_create_platform_device.part.0+0x264/0x3a8
> [ 1078.533152][T43784] acpi_create_platform_device+0x68/0x80
> [ 1078.539150][T43784] acpi_default_enumeration+0x34/0x78
> [ 1078.544887][T43784] acpi_bus_attach+0x340/0x3b8
> [ 1078.550015][T43784] acpi_bus_attach+0xf8/0x3b8
> [ 1078.555057][T43784] acpi_bus_attach+0xf8/0x3b8
> [ 1078.560099][T43784] acpi_bus_attach+0xf8/0x3b8
> [ 1078.565142][T43784] acpi_bus_scan+0x9c/0x100
> [ 1078.570015][T43784] acpi_scan_init+0x16c/0x320
> [ 1078.575058][T43784] acpi_init+0x330/0x3b8
> [ 1078.579666][T43784] do_one_initcall+0x158/0x7ec
> [ 1078.584797][T43784] kernel_init_freeable+0x9a8/0xa70
> [ 1078.590360][T43784] kernel_init+0x18/0x138
> [ 1078.595055][T43784] ret_from_fork+0x10/0x1c
> [ 1078.599835][T43784]
> [ 1078.599835][T43784] -> #1 (console_owner){-...}:
> [ 1078.606618][T43784] __lock_acquire+0x5c8/0xbb0
> [ 1078.611661][T43784] lock_acquire+0x154/0x428
> [ 1078.616530][T43784] console_unlock+0x298/0x898
> [ 1078.621573][T43784] vprintk_emit+0x2d4/0x460
> [ 1078.626442][T43784] vprintk_default+0x48/0x58
> [ 1078.631398][T43784] vprintk_func+0x194/0x250
> [ 1078.636267][T43784] printk+0xbc/0xec
> [ 1078.640443][T43784] _warn_unseeded_randomness+0xb4/0xd0
> [ 1078.646267][T43784] get_random_u64+0x4c/0x100
> [ 1078.651224][T43784] add_to_free_area_random+0x168/0x1a0
> [ 1078.657047][T43784] free_one_page+0x3dc/0xd08
> [ 1078.662003][T43784] __free_pages_ok+0x490/0xd00
> [ 1078.667132][T43784] __free_pages+0xc4/0x118
> [ 1078.671914][T43784] __free_pages_core+0x2e8/0x428
> [ 1078.677219][T43784] memblock_free_pages+0xa4/0xec
> [ 1078.682522][T43784] memblock_free_all+0x264/0x330
> [ 1078.687825][T43784] mem_init+0x90/0x148
> [ 1078.692259][T43784] start_kernel+0x368/0x684
> [ 1078.697126][T43784]
> [ 1078.697126][T43784] -> #0 (&(&zone->lock)->rlock){-.-.}:
> [ 1078.704604][T43784] check_prev_add+0x120/0x1138
> [ 1078.709733][T43784] validate_chain+0x888/0x1270
> [ 1078.714863][T43784] __lock_acquire+0x5c8/0xbb0
> [ 1078.719906][T43784] lock_acquire+0x154/0x428
> [ 1078.724776][T43784] _raw_spin_lock+0x68/0x88
> [ 1078.729645][T43784] rmqueue_bulk.constprop.21+0xb0/0x1218
> [ 1078.735643][T43784] get_page_from_freelist+0x898/0x24a0
> [ 1078.741467][T43784] __alloc_pages_nodemask+0x2a8/0x1d08
> [ 1078.747291][T43784] alloc_pages_current+0xb4/0x150
> [ 1078.752682][T43784] allocate_slab+0xab8/0x2350
> [ 1078.757725][T43784] new_slab+0x98/0xc0
> [ 1078.762073][T43784] ___slab_alloc+0x66c/0xa30
> [ 1078.767029][T43784] __slab_alloc+0x68/0xc8
> [ 1078.771725][T43784] __kmalloc+0x3d4/0x658
> [ 1078.776333][T43784] __tty_buffer_request_room+0xd4/0x220
> [ 1078.782244][T43784] tty_insert_flip_string_fixed_flag+0x6c/0x128
> [ 1078.788849][T43784] pty_write+0x98/0x100
> [ 1078.793370][T43784] n_tty_write+0x2a0/0x668
> [ 1078.798152][T43784] tty_write+0x2e8/0x430
> [ 1078.802760][T43784] __vfs_write+0x5c/0xb0
> [ 1078.807368][T43784] vfs_write+0xf0/0x230
> [ 1078.811890][T43784] ksys_write+0xd4/0x180
> [ 1078.816498][T43784] __arm64_sys_write+0x4c/0x60
> [ 1078.821627][T43784] el0_svc_handler+0x11c/0x1f0
> [ 1078.826756][T43784] el0_svc+0x8/0xc
> [ 1078.830842][T43784]
> [ 1078.830842][T43784] other info that might help us debug this:
> [ 1078.830842][T43784]
> [ 1078.840918][T43784] Chain exists of:
> [ 1078.840918][T43784] &(&zone->lock)->rlock --> &port_lock_key --> &(&port-
> > lock)->rlock
>
> [ 1078.840918][T43784]
> [ 1078.854731][T43784] Possible unsafe locking scenario:
> [ 1078.854731][T43784]
> [ 1078.862029][T43784] CPU0 CPU1
> [ 1078.867243][T43784] ---- ----
> [ 1078.872457][T43784] lock(&(&port->lock)->rlock);
> [ 1078.877238][T43784] lock(&port_lock_key);
> [ 1078.883929][T43784] lock(&(&port->lock)-
> > rlock);
>
> [ 1078.891228][T43784] lock(&(&zone->lock)->rlock);
> [ 1078.896010][T43784]
> [ 1078.896010][T43784] *** DEADLOCK ***
> [ 1078.896010][T43784]
> [ 1078.904004][T43784] 5 locks held by vi/43784:
> [ 1078.908351][T43784] #0: ffff000c36240890 (&tty->ldisc_sem){++++}, at:
> ldsem_down_read+0x44/0x50
> [ 1078.917133][T43784] #1: ffff000c36240918 (&tty->atomic_write_lock){+.+.},
> at: tty_write_lock+0x24/0x60
> [ 1078.926521][T43784] #2: ffff000c36240aa0 (&o_tty->termios_rwsem/1){++++},
> at: n_tty_write+0x108/0x668
> [ 1078.935823][T43784] #3: ffffa0001e0b2360 (&ldata->output_lock){+.+.}, at:
> n_tty_write+0x1d0/0x668
> [ 1078.944777][T43784] #4: ffff00938db47d40 (&(&port->lock)->rlock){-.-.}, at:
> pty_write+0x78/0x100
> [ 1078.953644][T43784]
> [ 1078.953644][T43784] stack backtrace:
> [ 1078.959382][T43784] CPU: 97 PID: 43784 Comm: vi Not tainted 5.3.0-rc7-next-
> 20190904 #14
> [ 1078.967376][T43784] Hardware name: HPE Apollo
> 70 /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019
> [ 1078.977799][T43784] Call trace:
> [ 1078.980932][T43784] dump_backtrace+0x0/0x228
> [ 1078.985279][T43784] show_stack+0x24/0x30
> [ 1078.989282][T43784] dump_stack+0xe8/0x13c
> [ 1078.993370][T43784] print_circular_bug+0x334/0x3d8
> [ 1078.998240][T43784] check_noncircular+0x268/0x310
> [ 1079.003022][T43784] check_prev_add+0x120/0x1138
> [ 1079.007631][T43784] validate_chain+0x888/0x1270
> [ 1079.012241][T43784] __lock_acquire+0x5c8/0xbb0
> [ 1079.016763][T43784] lock_acquire+0x154/0x428
> [ 1079.021111][T43784] _raw_spin_lock+0x68/0x88
> [ 1079.025460][T43784] rmqueue_bulk.constprop.21+0xb0/0x1218
> [ 1079.030937][T43784] get_page_from_freelist+0x898/0x24a0
> [ 1079.036240][T43784] __alloc_pages_nodemask+0x2a8/0x1d08
> [ 1079.041542][T43784] alloc_pages_current+0xb4/0x150
> [ 1079.046412][T43784] allocate_slab+0xab8/0x2350
> [ 1079.050934][T43784] new_slab+0x98/0xc0
> [ 1079.054761][T43784] ___slab_alloc+0x66c/0xa30
> [ 1079.059196][T43784] __slab_alloc+0x68/0xc8
> [ 1079.063371][T43784] __kmalloc+0x3d4/0x658
> [ 1079.067458][T43784] __tty_buffer_request_room+0xd4/0x220
> [ 1079.072847][T43784] tty_insert_flip_string_fixed_flag+0x6c/0x128
> [ 1079.078932][T43784] pty_write+0x98/0x100
> [ 1079.082932][T43784] n_tty_write+0x2a0/0x668
> [ 1079.087193][T43784] tty_write+0x2e8/0x430
> [ 1079.091280][T43784] __vfs_write+0x5c/0xb0
> [ 1079.095367][T43784] vfs_write+0xf0/0x230
> [ 1079.099368][T43784] ksys_write+0xd4/0x180
> [ 1079.103455][T43784] __arm64_sys_write+0x4c/0x60
> [ 1079.108064][T43784] el0_svc_handler+0x11c/0x1f0
> [ 1079.112672][T43784] el0_svc+0x8/0xc
Hmm, it feels like that CONFIG_SHUFFLE_PAGE_ALLOCATOR=y introduces some unique
locking patterns that the lockdep does not like via,
allocate_slab
shuffle_freelist
get_random_u32
Here is another splat with while compiling/installing a kernel,
[ 1254.443119][ C2] WARNING: possible circular locking dependency detected
[ 1254.450038][ C2] 5.3.0-rc5-next-20190822 #1 Not tainted
[ 1254.455559][ C2] ------------------------------------------------------
[ 1254.462988][ C2] swapper/2/0 is trying to acquire lock:
[ 1254.468509][ C2] ffffffffa2925218 (random_write_wait.lock){..-.}, at:
__wake_up_common_lock+0xc6/0x150
[ 1254.478154][ C2]
[ 1254.478154][ C2] but task is already holding lock:
[ 1254.485896][ C2] ffff88845373fda0 (batched_entropy_u32.lock){-.-.}, at:
get_random_u32+0x4c/0xe0
[ 1254.495007][ C2]
[ 1254.495007][ C2] which lock already depends on the new lock.
[ 1254.495007][ C2]
[ 1254.505331][ C2]
[ 1254.505331][ C2] the existing dependency chain (in reverse order) is:
[ 1254.514755][ C2]
[ 1254.514755][ C2] -> #3 (batched_entropy_u32.lock){-.-.}:
[ 1254.522553][ C2] __lock_acquire+0x5b3/0xb40
[ 1254.527638][ C2] lock_acquire+0x126/0x280
[ 1254.533016][ C2] _raw_spin_lock_irqsave+0x3a/0x50
[ 1254.538624][ C2] get_random_u32+0x4c/0xe0
[ 1254.543539][ C2] allocate_slab+0x6d6/0x19c0
[ 1254.548625][ C2] new_slab+0x46/0x70
[ 1254.553010][ C2] ___slab_alloc+0x58b/0x960
[ 1254.558533][ C2] __slab_alloc+0x43/0x70
[ 1254.563269][ C2] kmem_cache_alloc+0x354/0x460
[ 1254.568534][ C2] fill_pool+0x272/0x4b0
[ 1254.573182][ C2] __debug_object_init+0x86/0x7a0
[ 1254.578615][ C2] debug_object_init+0x16/0x20
[ 1254.584256][ C2] hrtimer_init+0x27/0x1e0
[ 1254.589079][ C2] init_dl_task_timer+0x20/0x40
[ 1254.594342][ C2] __sched_fork+0x10b/0x1f0
[ 1254.599253][ C2] init_idle+0xac/0x520
[ 1254.603816][ C2] fork_idle+0x18c/0x230
[ 1254.608933][ C2] idle_threads_init+0xf0/0x187
[ 1254.614193][ C2] smp_init+0x1d/0x12d
[ 1254.618671][ C2] kernel_init_freeable+0x37e/0x76e
[ 1254.624282][ C2] kernel_init+0x11/0x12f
[ 1254.629016][ C2] ret_from_fork+0x27/0x50
[ 1254.634344][ C2]
[ 1254.634344][ C2] -> #2 (&rq->lock){-.-.}:
[ 1254.640831][ C2] __lock_acquire+0x5b3/0xb40
[ 1254.645917][ C2] lock_acquire+0x126/0x280
[ 1254.650827][ C2] _raw_spin_lock+0x2f/0x40
[ 1254.655741][ C2] task_fork_fair+0x43/0x200
[ 1254.661213][ C2] sched_fork+0x29b/0x420
[ 1254.665949][ C2] copy_process+0xf12/0x3180
[ 1254.670947][ C2] _do_fork+0xef/0x950
[ 1254.675422][ C2] kernel_thread+0xa8/0xe0
[ 1254.680244][ C2] rest_init+0x28/0x311
[ 1254.685298][ C2] arch_call_rest_init+0xe/0x1b
[ 1254.690558][ C2] start_kernel+0x6eb/0x724
[ 1254.695469][ C2] x86_64_start_reservations+0x24/0x26
[ 1254.701339][ C2] x86_64_start_kernel+0xf4/0xfb
[ 1254.706689][ C2] secondary_startup_64+0xb6/0xc0
[ 1254.712601][ C2]
[ 1254.712601][ C2] -> #1 (&p->pi_lock){-.-.}:
[ 1254.719263][ C2] __lock_acquire+0x5b3/0xb40
[ 1254.724349][ C2] lock_acquire+0x126/0x280
[ 1254.729260][ C2] _raw_spin_lock_irqsave+0x3a/0x50
[ 1254.735317][ C2] try_to_wake_up+0xad/0x1050
[ 1254.740403][ C2] default_wake_function+0x2f/0x40
[ 1254.745929][ C2] pollwake+0x10d/0x160
[ 1254.750491][ C2] __wake_up_common+0xc4/0x2a0
[ 1254.755663][ C2] __wake_up_common_lock+0xea/0x150
[ 1254.761756][ C2] __wake_up+0x13/0x20
[ 1254.766230][ C2] account.constprop.9+0x217/0x340
[ 1254.771754][ C2] extract_entropy.constprop.7+0xcf/0x220
[ 1254.777886][ C2] _xfer_secondary_pool+0x19a/0x3d0
[ 1254.783981][ C2] push_to_pool+0x3e/0x230
[ 1254.788805][ C2] process_one_work+0x52a/0xb40
[ 1254.794064][ C2] worker_thread+0x63/0x5b0
[ 1254.798977][ C2] kthread+0x1df/0x200
[ 1254.803451][ C2] ret_from_fork+0x27/0x50
[ 1254.808787][ C2]
[ 1254.808787][ C2] -> #0 (random_write_wait.lock){..-.}:
[ 1254.816409][ C2] check_prev_add+0x107/0xea0
[ 1254.821494][ C2] validate_chain+0x8fc/0x1200
[ 1254.826667][ C2] __lock_acquire+0x5b3/0xb40
[ 1254.831751][ C2] lock_acquire+0x126/0x280
[ 1254.837189][ C2] _raw_spin_lock_irqsave+0x3a/0x50
[ 1254.842797][ C2] __wake_up_common_lock+0xc6/0x150
[ 1254.848408][ C2] __wake_up+0x13/0x20
[ 1254.852882][ C2] account.constprop.9+0x217/0x340
[ 1254.858988][ C2] extract_entropy.constprop.7+0xcf/0x220
[ 1254.865122][ C2] crng_reseed+0xa1/0x3f0
[ 1254.869859][ C2] _extract_crng+0xc3/0xd0
[ 1254.874682][ C2] crng_reseed+0x21b/0x3f0
[ 1254.879505][ C2] _extract_crng+0xc3/0xd0
[ 1254.884772][ C2] extract_crng+0x40/0x60
[ 1254.889507][ C2] get_random_u32+0xb4/0xe0
[ 1254.894417][ C2] allocate_slab+0x6d6/0x19c0
[ 1254.899501][ C2] new_slab+0x46/0x70
[ 1254.903886][ C2] ___slab_alloc+0x58b/0x960
[ 1254.909377][ C2] __slab_alloc+0x43/0x70
[ 1254.914112][ C2] kmem_cache_alloc+0x354/0x460
[ 1254.919375][ C2] __build_skb+0x23/0x60
[ 1254.924024][ C2] __netdev_alloc_skb+0x127/0x1e0
[ 1254.929470][ C2] tg3_poll_work+0x11b2/0x1f70 [tg3]
[ 1254.935654][ C2] tg3_poll_msix+0x67/0x330 [tg3]
[ 1254.941092][ C2] net_rx_action+0x24e/0x7e0
[ 1254.946089][ C2] __do_softirq+0x123/0x767
[ 1254.951000][ C2] irq_exit+0xd6/0xf0
[ 1254.955385][ C2] do_IRQ+0xe2/0x1a0
[ 1254.960155][ C2] ret_from_intr+0x0/0x2a
[ 1254.964896][ C2] cpuidle_enter_state+0x156/0x8e0
[ 1254.970418][ C2] cpuidle_enter+0x41/0x70
[ 1254.975242][ C2] call_cpuidle+0x5e/0x90
[ 1254.979975][ C2] do_idle+0x333/0x370
[ 1254.984972][ C2] cpu_startup_entry+0x1d/0x1f
[ 1254.990148][ C2] start_secondary+0x290/0x330
[ 1254.995319][ C2] secondary_startup_64+0xb6/0xc0
[ 1255.000750][ C2]
[ 1255.000750][ C2] other info that might help us debug this:
[ 1255.000750][ C2]
[ 1255.011424][ C2] Chain exists of:
[ 1255.011424][ C2] random_write_wait.lock --> &rq->lock -->
batched_entropy_u32.lock
[ 1255.011424][ C2]
[ 1255.025245][ C2] Possible unsafe locking scenario:
[ 1255.025245][ C2]
[ 1255.033012][ C2] CPU0 CPU1
[ 1255.038270][ C2] ---- ----
[ 1255.043526][ C2] lock(batched_entropy_u32.lock);
[ 1255.048610][ C2] lock(&rq->lock);
[
1255.054918][ C2] lock(batched_entropy_u32.loc
k);
[ 1255.063035][ C2] lock(random_write_wait.lock);
[ 1255.067945][ C2]
[ 1255.067945][ C2] *** DEADLOCK ***
[ 1255.067945][ C2]
[ 1255.076000][ C2] 1 lock held by swapper/2/0:
[ 1255.080558][ C2] #0: ffff88845373fda0 (batched_entropy_u32.lock){-.-.},
at: get_random_u32+0x4c/0xe0
[ 1255.090547][ C2]
[ 1255.090547][ C2] stack backtrace:
[ 1255.096333][ C2] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.3.0-rc5-next-
20190822 #1
[ 1255.104473][ C2] Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385
Gen10, BIOS A40 03/09/2018
[ 1255.114276][ C2] Call Trace:
[ 1255.117439][ C2] <IRQ>
[ 1255.120169][ C2] dump_stack+0x86/0xca
[ 1255.124205][ C2] print_circular_bug.cold.32+0x243/0x26e
[ 1255.129816][ C2] check_noncircular+0x29e/0x2e0
[ 1255.135221][ C2] ? __bfs+0x238/0x380
[ 1255.139172][ C2] ? print_circular_bug+0x120/0x120
[ 1255.144259][ C2] ? find_usage_forwards+0x7d/0xb0
[ 1255.149260][ C2] check_prev_add+0x107/0xea0
[ 1255.153823][ C2] validate_chain+0x8fc/0x1200
[ 1255.159007][ C2] ? check_prev_add+0xea0/0xea0
[ 1255.163743][ C2] ? check_usage_backwards+0x210/0x210
[ 1255.169091][ C2] __lock_acquire+0x5b3/0xb40
[ 1255.173655][ C2] lock_acquire+0x126/0x280
[ 1255.178041][ C2] ? __wake_up_common_lock+0xc6/0x150
[ 1255.183732][ C2] _raw_spin_lock_irqsave+0x3a/0x50
[ 1255.188817][ C2] ? __wake_up_common_lock+0xc6/0x150
[ 1255.194076][ C2] __wake_up_common_lock+0xc6/0x150
[ 1255.199163][ C2] ? __wake_up_common+0x2a0/0x2a0
[ 1255.204078][ C2] ? rcu_read_lock_any_held.part.5+0x20/0x20
[ 1255.210428][ C2] __wake_up+0x13/0x20
[ 1255.214379][ C2] account.constprop.9+0x217/0x340
[ 1255.219377][ C2] extract_entropy.constprop.7+0xcf/0x220
[ 1255.224987][ C2] ? crng_reseed+0xa1/0x3f0
[ 1255.229375][ C2] crng_reseed+0xa1/0x3f0
[ 1255.234122][ C2] ? rcu_read_lock_sched_held+0xac/0xe0
[ 1255.239556][ C2] ? check_flags.part.16+0x86/0x220
[ 1255.244641][ C2] ? extract_entropy.constprop.7+0x220/0x220
[ 1255.250511][ C2] ? __kasan_check_read+0x11/0x20
[ 1255.255422][ C2] ? validate_chain+0xab/0x1200
[ 1255.260742][ C2] ? rcu_read_lock_any_held.part.5+0x20/0x20
[ 1255.266616][ C2] _extract_crng+0xc3/0xd0
[ 1255.270915][ C2] crng_reseed+0x21b/0x3f0
[ 1255.275215][ C2] ? extract_entropy.constprop.7+0x220/0x220
[ 1255.281085][ C2] ? __kasan_check_write+0x14/0x20
[ 1255.286517][ C2] ? do_raw_spin_lock+0x118/0x1d0
[ 1255.291428][ C2] ? rwlock_bug.part.0+0x60/0x60
[ 1255.296251][ C2] _extract_crng+0xc3/0xd0
[ 1255.300550][ C2] extract_crng+0x40/0x60
[ 1255.304763][ C2] get_random_u32+0xb4/0xe0
[ 1255.309640][ C2] allocate_slab+0x6d6/0x19c0
[ 1255.314203][ C2] new_slab+0x46/0x70
[ 1255.318066][ C2] ___slab_alloc+0x58b/0x960
[ 1255.322539][ C2] ? __build_skb+0x23/0x60
[ 1255.326841][ C2] ? fault_create_debugfs_attr+0x140/0x140
[ 1255.333048][ C2] ? __build_skb+0x23/0x60
[ 1255.337348][ C2] __slab_alloc+0x43/0x70
[ 1255.341559][ C2] ? __slab_alloc+0x43/0x70
[ 1255.345944][ C2] ? __build_skb+0x23/0x60
[ 1255.350242][ C2] kmem_cache_alloc+0x354/0x460
[ 1255.354978][ C2] ? __netdev_alloc_skb+0x1c6/0x1e0
[ 1255.360626][ C2] ? trace_hardirqs_on+0x3a/0x160
[ 1255.365535][ C2] __build_skb+0x23/0x60
[ 1255.369660][ C2] __netdev_alloc_skb+0x127/0x1e0
[ 1255.374576][ C2] tg3_poll_work+0x11b2/0x1f70 [tg3]
[ 1255.379750][ C2] ? find_held_lock+0x11b/0x150
[ 1255.385027][ C2] ? tg3_tx_recover+0xa0/0xa0 [tg3]
[ 1255.390114][ C2] ? _raw_spin_unlock_irqrestore+0x38/0x50
[ 1255.395809][ C2] ? __kasan_check_read+0x11/0x20
[ 1255.400718][ C2] ? validate_chain+0xab/0x1200
[ 1255.405455][ C2] ? __wake_up_common+0x2a0/0x2a0
[ 1255.410761][ C2] ? mark_held_locks+0x34/0xb0
[ 1255.415415][ C2] tg3_poll_msix+0x67/0x330 [tg3]
[ 1255.420327][ C2] net_rx_action+0x24e/0x7e0
[ 1255.424800][ C2] ? find_held_lock+0x11b/0x150
[ 1255.429536][ C2] ? napi_busy_loop+0x600/0x600
[ 1255.434733][ C2] ? rcu_read_lock_sched_held+0xac/0xe0
[ 1255.440169][ C2] ? __do_softirq+0xed/0x767
[ 1255.444642][ C2] ? rcu_read_lock_any_held.part.5+0x20/0x20
[ 1255.450518][ C2] ? lockdep_hardirqs_on+0x1b0/0x2a0
[ 1255.455693][ C2] ? irq_exit+0xd6/0xf0
[ 1255.460280][ C2] __do_softirq+0x123/0x767
[ 1255.464668][ C2] irq_exit+0xd6/0xf0
[ 1255.468532][ C2] do_IRQ+0xe2/0x1a0
[ 1255.472308][ C2] common_interrupt+0xf/0xf
[ 1255.476694][ C2] </IRQ>
[ 1255.479509][ C2] RIP: 0010:cpuidle_enter_state+0x156/0x8e0
[ 1255.485750][ C2] Code: bf ff 8b 05 a4 27 2d 01 85 c0 0f 8f 1d 04 00 00 31
ff e8 4d ba 92 ff 80 7d d0 00 0f 85 0b 02 00 00 e8 ae c0 a7 ff fb 45 85 ed <0f>
88 2d 02 00 00 4d 63 fd 49 83 ff 09 0f 87 91 06 00 00 4b 8d 04
[ 1255.505335][ C2] RSP: 0018:ffff888206637cf8 EFLAGS: 00000202 ORIG_RAX:
ffffffffffffffc8
[ 1255.514154][ C2] RAX: 0000000000000000 RBX: ffff889f98b44008 RCX:
ffffffffa116e980
[ 1255.522033][ C2] RDX: 0000000000000007 RSI: dffffc0000000000 RDI:
ffff8882066287ec
[ 1255.529913][ C2] RBP: ffff888206637d48 R08: fffffbfff4557aee R09:
0000000000000000
[ 1255.538278][ C2] R10: 0000000000000000 R11: 0000000000000000 R12:
ffffffffa28e8ac0
[ 1255.546158][ C2] R13: 0000000000000002 R14: 0000012412160253 R15:
ffff889f98b4400c
[ 1255.554040][ C2] ? lockdep_hardirqs_on+0x1b0/0x2a0
[ 1255.559725][ C2] ? cpuidle_enter_state+0x152/0x8e0
[ 1255.564898][ C2] cpuidle_enter+0x41/0x70
[ 1255.569196][ C2] call_cpuidle+0x5e/0x90
[ 1255.573408][ C2] do_idle+0x333/0x370
[ 1255.577358][ C2] ? complete+0x51/0x60
[ 1255.581394][ C2] ? arch_cpu_idle_exit+0x40/0x40
[ 1255.586777][ C2] ? complete+0x51/0x60
[ 1255.590814][ C2] cpu_startup_entry+0x1d/0x1f
[ 1255.595461][ C2] start_secondary+0x290/0x330
[ 1255.600111][ C2] ? set_cpu_sibling_map+0x18f0/0x18f0
[ 1255.605460][ C2] secondary_startup_64+0xb6/0xc0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6dl: SolidRun: add phy node with 100Mb/s max-speed
From: Andrew Lunn @ 2019-09-10 18:50 UTC (permalink / raw)
To: tinywrkb
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Shawn Guo, Sascha Hauer, Russell King, open list, Rob Herring,
NXP Linux Team, Pengutronix Kernel Team, Fabio Estevam,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190910155507.491230-1-tinywrkb@gmail.com>
On Tue, Sep 10, 2019 at 06:55:07PM +0300, tinywrkb wrote:
> Cubox-i Solo/DualLite carrier board has 100Mb/s magnetics while the
> Atheros AR8035 PHY on the MicroSoM v1.3 CPU module is a 1GbE PHY device.
>
> Since commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in
> genphy_read_status") ethernet is broken on Cubox-i Solo/DualLite devices.
Hi Tinywrkb
You emailed lots of people, but missed the PHY maintainers :-(
Are you sure this is the patch which broken it? Did you do a git
bisect.
Thanks
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox