* [PATCH v4 05/11] net: ethernet: mediatek: remove unnecessary spaces from Makefile
From: Bartosz Golaszewski @ 2020-05-20 11:25 UTC (permalink / raw)
To: Rob Herring, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, Stephane Le Provost, netdev, linux-kernel,
Bartosz Golaszewski, linux-mediatek, Andrew Perepech, Pedro Tsai,
linux-arm-kernel
In-Reply-To: <20200520112523.30995-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The Makefile formatting in the kernel tree usually doesn't use tabs,
so remove them before we add a second driver.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/net/ethernet/mediatek/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mediatek/Makefile b/drivers/net/ethernet/mediatek/Makefile
index 2d8362f9341b..3362fb7ef859 100644
--- a/drivers/net/ethernet/mediatek/Makefile
+++ b/drivers/net/ethernet/mediatek/Makefile
@@ -3,5 +3,5 @@
# Makefile for the Mediatek SoCs built-in ethernet macs
#
-obj-$(CONFIG_NET_MEDIATEK_SOC) += mtk_eth.o
+obj-$(CONFIG_NET_MEDIATEK_SOC) += mtk_eth.o
mtk_eth-y := mtk_eth_soc.o mtk_sgmii.o mtk_eth_path.o
--
2.25.0
_______________________________________________
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 v4 03/11] dt-bindings: net: add a binding document for MediaTek Ethernet MAC
From: Bartosz Golaszewski @ 2020-05-20 11:25 UTC (permalink / raw)
To: Rob Herring, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, Stephane Le Provost, netdev, linux-kernel,
Bartosz Golaszewski, linux-mediatek, Andrew Perepech, Pedro Tsai,
linux-arm-kernel
In-Reply-To: <20200520112523.30995-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This adds yaml DT bindings for the MediaTek Ethernet MAC present on the
mt8* family of SoCs.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
.../bindings/net/mediatek,eth-mac.yaml | 89 +++++++++++++++++++
1 file changed, 89 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/mediatek,eth-mac.yaml
diff --git a/Documentation/devicetree/bindings/net/mediatek,eth-mac.yaml b/Documentation/devicetree/bindings/net/mediatek,eth-mac.yaml
new file mode 100644
index 000000000000..8ffd0b762c0f
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mediatek,eth-mac.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/mediatek,eth-mac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Ethernet MAC Controller
+
+maintainers:
+ - Bartosz Golaszewski <bgolaszewski@baylibre.com>
+
+description:
+ This Ethernet MAC is used on the MT8* family of SoCs from MediaTek.
+ It's compliant with 802.3 standards and supports half- and full-duplex
+ modes with flow-control as well as CRC offloading and VLAN tags.
+
+allOf:
+ - $ref: "ethernet-controller.yaml#"
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt8516-eth
+ - mediatek,mt8518-eth
+ - mediatek,mt8175-eth
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 3
+ maxItems: 3
+
+ clock-names:
+ additionalItems: false
+ items:
+ - const: core
+ - const: reg
+ - const: trans
+
+ mediatek,pericfg:
+ $ref: /schemas/types.yaml#definitions/phandle
+ description:
+ Phandle to the device containing the PERICFG register range. This is used
+ to control the MII mode.
+
+ mdio:
+ type: object
+ description:
+ Creates and registers an MDIO bus.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - mediatek,pericfg
+ - phy-handle
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/mt8516-clk.h>
+
+ ethernet: ethernet@11180000 {
+ compatible = "mediatek,mt8516-eth";
+ reg = <0x11180000 0x1000>;
+ mediatek,pericfg = <&pericfg>;
+ interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&topckgen CLK_TOP_RG_ETH>,
+ <&topckgen CLK_TOP_66M_ETH>,
+ <&topckgen CLK_TOP_133M_ETH>;
+ clock-names = "core", "reg", "trans";
+ phy-handle = <ð_phy>;
+ phy-mode = "rmii";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eth_phy: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+ };
--
2.25.0
_______________________________________________
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 v4 04/11] net: ethernet: mediatek: rename Kconfig prompt
From: Bartosz Golaszewski @ 2020-05-20 11:25 UTC (permalink / raw)
To: Rob Herring, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, Stephane Le Provost, netdev, linux-kernel,
Bartosz Golaszewski, linux-mediatek, Andrew Perepech, Pedro Tsai,
linux-arm-kernel
In-Reply-To: <20200520112523.30995-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
We'll soon by adding a second MediaTek Ethernet driver so modify the
Kconfig prompt.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/net/ethernet/mediatek/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mediatek/Kconfig b/drivers/net/ethernet/mediatek/Kconfig
index 4968352ba188..5079b8090f16 100644
--- a/drivers/net/ethernet/mediatek/Kconfig
+++ b/drivers/net/ethernet/mediatek/Kconfig
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
config NET_VENDOR_MEDIATEK
- bool "MediaTek ethernet driver"
+ bool "MediaTek devices"
depends on ARCH_MEDIATEK || SOC_MT7621 || SOC_MT7620
---help---
If you have a Mediatek SoC with ethernet, say Y.
--
2.25.0
_______________________________________________
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 v4 02/11] dt-bindings: add new compatible to mediatek,pericfg
From: Bartosz Golaszewski @ 2020-05-20 11:25 UTC (permalink / raw)
To: Rob Herring, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, Stephane Le Provost, netdev, linux-kernel,
Bartosz Golaszewski, linux-mediatek, Andrew Perepech, Pedro Tsai,
linux-arm-kernel
In-Reply-To: <20200520112523.30995-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The PERICFG controller is present on the MT8516 SoC. Add an appropriate
compatible variant.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
.../devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
index 1340c6288024..55209a2baedc 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
@@ -25,6 +25,7 @@ properties:
- mediatek,mt8135-pericfg
- mediatek,mt8173-pericfg
- mediatek,mt8183-pericfg
+ - mediatek,mt8516-pericfg
- const: syscon
- items:
# Special case for mt7623 for backward compatibility
--
2.25.0
_______________________________________________
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 v4 01/11] dt-bindings: convert the binding document for mediatek PERICFG to yaml
From: Bartosz Golaszewski @ 2020-05-20 11:25 UTC (permalink / raw)
To: Rob Herring, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, Stephane Le Provost, netdev, linux-kernel,
Bartosz Golaszewski, linux-mediatek, Andrew Perepech, Pedro Tsai,
linux-arm-kernel
In-Reply-To: <20200520112523.30995-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Convert the DT binding .txt file for MediaTek's peripheral configuration
controller to YAML. There's one special case where the compatible has
three positions. Otherwise, it's a pretty normal syscon.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
.../arm/mediatek/mediatek,pericfg.txt | 36 -----------
.../arm/mediatek/mediatek,pericfg.yaml | 63 +++++++++++++++++++
2 files changed, 63 insertions(+), 36 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
deleted file mode 100644
index ecf027a9003a..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Mediatek pericfg controller
-===========================
-
-The Mediatek pericfg controller provides various clocks and reset
-outputs to the system.
-
-Required Properties:
-
-- compatible: Should be one of:
- - "mediatek,mt2701-pericfg", "syscon"
- - "mediatek,mt2712-pericfg", "syscon"
- - "mediatek,mt7622-pericfg", "syscon"
- - "mediatek,mt7623-pericfg", "mediatek,mt2701-pericfg", "syscon"
- - "mediatek,mt7629-pericfg", "syscon"
- - "mediatek,mt8135-pericfg", "syscon"
- - "mediatek,mt8173-pericfg", "syscon"
- - "mediatek,mt8183-pericfg", "syscon"
-- #clock-cells: Must be 1
-- #reset-cells: Must be 1
-
-The pericfg controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-Also it uses the common reset controller binding from
-Documentation/devicetree/bindings/reset/reset.txt.
-The available reset outputs are defined in
-dt-bindings/reset/mt*-resets.h
-
-Example:
-
-pericfg: power-controller@10003000 {
- compatible = "mediatek,mt8173-pericfg", "syscon";
- reg = <0 0x10003000 0 0x1000>;
- #clock-cells = <1>;
- #reset-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
new file mode 100644
index 000000000000..1340c6288024
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,pericfg.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: MediaTek Peripheral Configuration Controller
+
+maintainers:
+ - Bartosz Golaszewski <bgolaszewski@baylibre.com>
+
+description:
+ The Mediatek pericfg controller provides various clocks and reset outputs
+ to the system.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - mediatek,mt2701-pericfg
+ - mediatek,mt2712-pericfg
+ - mediatek,mt7622-pericfg
+ - mediatek,mt7629-pericfg
+ - mediatek,mt8135-pericfg
+ - mediatek,mt8173-pericfg
+ - mediatek,mt8183-pericfg
+ - const: syscon
+ - items:
+ # Special case for mt7623 for backward compatibility
+ - const: mediatek,mt7623-pericfg
+ - const: mediatek,mt2701-pericfg
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ pericfg@10003000 {
+ compatible = "mediatek,mt8173-pericfg", "syscon";
+ reg = <0x10003000 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ - |
+ pericfg@10003000 {
+ compatible = "mediatek,mt7623-pericfg", "mediatek,mt2701-pericfg", "syscon";
+ reg = <0x10003000 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
--
2.25.0
_______________________________________________
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 v4 00/11] mediatek: add support for MediaTek Ethernet MAC
From: Bartosz Golaszewski @ 2020-05-20 11:25 UTC (permalink / raw)
To: Rob Herring, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, Stephane Le Provost, netdev, linux-kernel,
Bartosz Golaszewski, linux-mediatek, Andrew Perepech, Pedro Tsai,
linux-arm-kernel
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This adds support for the Ethernet Controller present on MediaTeK SoCs from
the MT8* family.
First we convert the existing DT bindings for the PERICFG controller to YAML
and add a new compatible string for mt8516 variant of it. Then we add the DT
bindings for the MAC.
Next we do some cleanup of the mediatek ethernet drivers directory.
The largest patch in the series adds the actual new driver.
The rest of the patches add DT fixups for the boards already supported
upstream.
v1 -> v2:
- add a generic helper for retrieving the net_device associated with given
private data
- fix several typos in commit messages
- remove MTK_MAC_VERSION and don't set the driver version
- use NET_IP_ALIGN instead of a magic number (2) but redefine it as it defaults
to 0 on arm64
- don't manually turn the carrier off in mtk_mac_enable()
- process TX cleanup in napi poll callback
- configure pause in the adjust_link callback
- use regmap_read_poll_timeout() instead of handcoding the polling
- use devres_find() to verify that struct net_device is managed by devres in
devm_register_netdev()
- add a patch moving all networking devres helpers into net/devres.c
- tweak the dma barriers: remove where unnecessary and add comments to the
remaining barriers
- don't reset internal counters when enabling the NIC
- set the net_device's mtu size instead of checking the framesize in
ndo_start_xmit() callback
- fix a race condition in waking up the netif queue
- don't emit log messages on OOM errors
- use dma_set_mask_and_coherent()
- use eth_hw_addr_random()
- rework the receive callback so that we reuse the previous skb if unmapping
fails, like we already do if skb allocation fails
- rework hash table operations: add proper timeout handling and clear bits when
appropriate
v2 -> v3:
- drop the patch adding priv_to_netdev() and store the netdev pointer in the
driver private data
- add an additional dma_wmb() after reseting the descriptor in
mtk_mac_ring_pop_tail()
- check the return value of dma_set_mask_and_coherent()
- improve the DT bindings for mtk-eth-mac: make the reg property in the example
use single-cell address and size, extend the description of the PERICFG
phandle and document the mdio sub-node
- add a patch converting the old .txt bindings for PERICFG to yaml
- limit reading the DMA memory by storing the mapped addresses in the driver
private structure
- add a patch documenting the existing networking devres helpers
v3 -> v4:
- drop the devres patches: they will be sent separately
- call netdev_sent_queue() & netdev_completed_queue() where appropriate
- don't redefine NET_IP_ALIGN: define a private constant in the driver
- fix a couple typos
- only disabe/enable the MAC in suspend/resume if netif is running
- drop the count field from the ring structure and instead calculate the number
of used descriptors from the tail and head indicies
- rework the locking used to protect the ring structures from concurrent
access: use cheaper spin_lock_bh() and completely disable the internal
spinlock used by regmap
- rework the interrupt handling to make it more fine-grained: onle re-enable
TX and RX interrupts while they're needed, process the stats updates in a
workqueue, not in napi context
- shrink the code responsible for unmapping and freeing skb memory
- rework the barriers as advised by Arnd
Bartosz Golaszewski (11):
dt-bindings: convert the binding document for mediatek PERICFG to yaml
dt-bindings: add new compatible to mediatek,pericfg
dt-bindings: net: add a binding document for MediaTek Ethernet MAC
net: ethernet: mediatek: rename Kconfig prompt
net: ethernet: mediatek: remove unnecessary spaces from Makefile
net: ethernet: mtk-eth-mac: new driver
ARM64: dts: mediatek: add pericfg syscon to mt8516.dtsi
ARM64: dts: mediatek: add the ethernet node to mt8516.dtsi
ARM64: dts: mediatek: add an alias for ethernet0 for pumpkin boards
ARM64: dts: mediatek: add ethernet pins for pumpkin boards
ARM64: dts: mediatek: enable ethernet on pumpkin boards
.../arm/mediatek/mediatek,pericfg.txt | 36 -
.../arm/mediatek/mediatek,pericfg.yaml | 64 +
.../bindings/net/mediatek,eth-mac.yaml | 89 +
arch/arm64/boot/dts/mediatek/mt8516.dtsi | 17 +
.../boot/dts/mediatek/pumpkin-common.dtsi | 34 +
drivers/net/ethernet/mediatek/Kconfig | 8 +-
drivers/net/ethernet/mediatek/Makefile | 3 +-
drivers/net/ethernet/mediatek/mtk_eth_mac.c | 1668 +++++++++++++++++
8 files changed, 1881 insertions(+), 38 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
create mode 100644 Documentation/devicetree/bindings/net/mediatek,eth-mac.yaml
create mode 100644 drivers/net/ethernet/mediatek/mtk_eth_mac.c
--
2.25.0
_______________________________________________
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] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
From: Shengjiu Wang @ 2020-05-20 11:22 UTC (permalink / raw)
To: Lucas Stach
Cc: sumit.semwal, linaro-mm-sig, Linux-ALSA, linuxppc-dev,
linux-kernel, Timur Tabi, Xiubo Li, shawnguo, Shengjiu Wang,
Takashi Iwai, Liam Girdwood, dri-devel, perex, Nicolin Chen,
Mark Brown, linux-imx, kernel, Fabio Estevam, s.hauer,
linux-arm-kernel, linux-media
In-Reply-To: <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de>
Hi
On Wed, May 20, 2020 at 5:42 PM Lucas Stach <l.stach@pengutronix.de> wrote:
>
> Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu Wang:
> > Hi
> >
> > On Tue, May 19, 2020 at 6:04 PM Lucas Stach <l.stach@pengutronix.de> wrote:
> > > Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu Wang:
> > > > There are two requirements that we need to move the request
> > > > of dma channel from probe to open.
> > >
> > > How do you handle -EPROBE_DEFER return code from the channel request if
> > > you don't do it in probe?
> >
> > I use the dma_request_slave_channel or dma_request_channel instead
> > of dmaengine_pcm_request_chan_of. so there should be not -EPROBE_DEFER
> > return code.
>
> This is a pretty weak argument. The dmaengine device might probe after
> you try to get the channel. Using a function to request the channel
> that doesn't allow you to handle probe deferral is IMHO a bug and
> should be fixed, instead of building even more assumptions on top of
> it.
>
I see some driver also request dma channel in open() or hw_params().
how can they avoid the defer probe issue?
for example：
sound/arm/pxa2xx-pcm-lib.c
sound/soc/sprd/sprd-pcm-dma.c
> > > > - When dma device binds with power-domains, the power will
> > > > be enabled when we request dma channel. If the request of dma
> > > > channel happen on probe, then the power-domains will be always
> > > > enabled after kernel boot up, which is not good for power
> > > > saving, so we need to move the request of dma channel to .open();
> > >
> > > This is certainly something which could be fixed in the dmaengine
> > > driver.
> >
> > Dma driver always call the pm_runtime_get_sync in
> > device_alloc_chan_resources, the device_alloc_chan_resources is
> > called when channel is requested. so power is enabled on channel
> > request.
>
> So why can't you fix the dmaengine driver to do that RPM call at a
> later time when the channel is actually going to be used? This will
> allow further power savings with other slave devices than the audio
> PCM.
>
> Regards,
> Lucas
>
It seems the best place for calling pm_runtime_get_sync is the
device_alloc_chan_resources, and calling pm_runtime_put_sync
in the .device_free_chan_resources
For the slave_sg mode, the .device_prep_slave_sg and
.device_issue_pending will be called many times after
.device_alloc_chan_resources. so it is not good to call
pm_runtime_get_sync in .device_prep_slave_sg or
.device_issue_pending
best regards
wang shengjiu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [EXT] Re: [PATCH net-next 3/5] net: mvpp2: cls: Use RSS contexts to handle RSS tables
From: Russell King - ARM Linux admin @ 2020-05-20 11:18 UTC (permalink / raw)
To: Matteo Croce
Cc: Antoine Tenart, netdev, gregory.clement@bootlin.com, LKML,
Maxime Chevallier, Nadav Haklai, Thomas Petazzoni,
miquel.raynal@bootlin.com, Stefan Chulski, Marcin Wojtas,
David S . Miller, Linux ARM
In-Reply-To: <CAGnkfhx2qHVSBNTRQf+RQiRWBHxF5hPE=5m+YVKBv6C97P=BOw@mail.gmail.com>
On Wed, May 20, 2020 at 01:16:25PM +0200, Matteo Croce wrote:
> On Wed, May 20, 2020 at 1:11 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Tue, May 19, 2020 at 07:05:34PM +0200, Matteo Croce wrote:
> > > On Tue, 19 May 2020 12:05:20 +0200
> > > Matteo Croce <mcroce@redhat.com> wrote:
> > >
> > > Hi,
> > >
> > > The patch seems to work. I'm generating traffic with random MAC and IP
> > > addresses, to have many flows:
> > >
> > > # tcpdump -tenni eth2
> > > 9a:a9:b1:3a:b1:6b > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.4.0 > 192.168.0.4.0: UDP, length 12
> > > 9e:92:fd:f8:7f:0a > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.4.0 > 192.168.0.4.0: UDP, length 12
> > > 66:b7:11:8a:c2:1f > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.1.0 > 192.168.0.1.0: UDP, length 12
> > > 7a:ba:58:bd:9a:62 > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.1.0 > 192.168.0.1.0: UDP, length 12
> > > 7e:78:a9:97:70:3a > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.2.0 > 192.168.0.2.0: UDP, length 12
> > > b2:81:91:34:ce:42 > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.2.0 > 192.168.0.2.0: UDP, length 12
> > > 2a:05:52:d0:d9:3f > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.3.0 > 192.168.0.3.0: UDP, length 12
> > > ee:ee:47:35:fa:81 > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.3.0 > 192.168.0.3.0: UDP, length 12
> > >
> > > This is the default rate, with rxhash off:
> > >
> > > # utraf eth2
> > > tx: 0 bps 0 pps rx: 397.4 Mbps 827.9 Kpps
> > > tx: 0 bps 0 pps rx: 396.3 Mbps 825.7 Kpps
> > > tx: 0 bps 0 pps rx: 396.6 Mbps 826.3 Kpps
> > > tx: 0 bps 0 pps rx: 396.5 Mbps 826.1 Kpps
> > >
> > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > > 9 root 20 0 0 0 0 R 99.7 0.0 7:02.58 ksoftirqd/0
> > > 15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1
> > > 20 root 20 0 0 0 0 S 0.0 0.0 2:01.48 ksoftirqd/2
> > > 25 root 20 0 0 0 0 S 0.0 0.0 0:32.86 ksoftirqd/3
> > >
> > > and this with rx hashing enabled:
> > >
> > > # ethtool -K eth2 rxhash on
> > > # utraf eth2
> > > tx: 0 bps 0 pps rx: 456.4 Mbps 950.8 Kpps
> > > tx: 0 bps 0 pps rx: 458.4 Mbps 955.0 Kpps
> > > tx: 0 bps 0 pps rx: 457.6 Mbps 953.3 Kpps
> > > tx: 0 bps 0 pps rx: 462.2 Mbps 962.9 Kpps
> > >
> > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > > 20 root 20 0 0 0 0 R 0.7 0.0 2:02.34 ksoftirqd/2
> > > 25 root 20 0 0 0 0 S 0.3 0.0 0:33.25 ksoftirqd/3
> > > 9 root 20 0 0 0 0 S 0.0 0.0 7:52.57 ksoftirqd/0
> > > 15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1
> > >
> > >
> > > The throughput doesn't increase so much, maybe we hit an HW limit of
> > > the gigabit port. The interesting thing is how the global CPU usage
> > > drops from 25% to 1%.
> > > I can't explain this, it could be due to the reduced contention?
> >
> > Hi Matteo,
> >
> > Can I take that as a Tested-by ?
> >
> > Thanks.
> >
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
> >
>
> Tested-by: Matteo Croce <mcroce@redhat.com>
>
> probably also:
>
> Reported-by: Matteo Croce <mcroce@redhat.com>
Thanks!
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [EXT] Re: [PATCH net-next 3/5] net: mvpp2: cls: Use RSS contexts to handle RSS tables
From: Matteo Croce @ 2020-05-20 11:16 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Antoine Tenart, netdev, gregory.clement@bootlin.com, LKML,
Maxime Chevallier, Nadav Haklai, Thomas Petazzoni,
miquel.raynal@bootlin.com, Stefan Chulski, Marcin Wojtas,
David S . Miller, Linux ARM
In-Reply-To: <20200520111043.GK1551@shell.armlinux.org.uk>
On Wed, May 20, 2020 at 1:11 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Tue, May 19, 2020 at 07:05:34PM +0200, Matteo Croce wrote:
> > On Tue, 19 May 2020 12:05:20 +0200
> > Matteo Croce <mcroce@redhat.com> wrote:
> >
> > Hi,
> >
> > The patch seems to work. I'm generating traffic with random MAC and IP
> > addresses, to have many flows:
> >
> > # tcpdump -tenni eth2
> > 9a:a9:b1:3a:b1:6b > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.4.0 > 192.168.0.4.0: UDP, length 12
> > 9e:92:fd:f8:7f:0a > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.4.0 > 192.168.0.4.0: UDP, length 12
> > 66:b7:11:8a:c2:1f > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.1.0 > 192.168.0.1.0: UDP, length 12
> > 7a:ba:58:bd:9a:62 > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.1.0 > 192.168.0.1.0: UDP, length 12
> > 7e:78:a9:97:70:3a > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.2.0 > 192.168.0.2.0: UDP, length 12
> > b2:81:91:34:ce:42 > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.2.0 > 192.168.0.2.0: UDP, length 12
> > 2a:05:52:d0:d9:3f > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.3.0 > 192.168.0.3.0: UDP, length 12
> > ee:ee:47:35:fa:81 > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.3.0 > 192.168.0.3.0: UDP, length 12
> >
> > This is the default rate, with rxhash off:
> >
> > # utraf eth2
> > tx: 0 bps 0 pps rx: 397.4 Mbps 827.9 Kpps
> > tx: 0 bps 0 pps rx: 396.3 Mbps 825.7 Kpps
> > tx: 0 bps 0 pps rx: 396.6 Mbps 826.3 Kpps
> > tx: 0 bps 0 pps rx: 396.5 Mbps 826.1 Kpps
> >
> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > 9 root 20 0 0 0 0 R 99.7 0.0 7:02.58 ksoftirqd/0
> > 15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1
> > 20 root 20 0 0 0 0 S 0.0 0.0 2:01.48 ksoftirqd/2
> > 25 root 20 0 0 0 0 S 0.0 0.0 0:32.86 ksoftirqd/3
> >
> > and this with rx hashing enabled:
> >
> > # ethtool -K eth2 rxhash on
> > # utraf eth2
> > tx: 0 bps 0 pps rx: 456.4 Mbps 950.8 Kpps
> > tx: 0 bps 0 pps rx: 458.4 Mbps 955.0 Kpps
> > tx: 0 bps 0 pps rx: 457.6 Mbps 953.3 Kpps
> > tx: 0 bps 0 pps rx: 462.2 Mbps 962.9 Kpps
> >
> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > 20 root 20 0 0 0 0 R 0.7 0.0 2:02.34 ksoftirqd/2
> > 25 root 20 0 0 0 0 S 0.3 0.0 0:33.25 ksoftirqd/3
> > 9 root 20 0 0 0 0 S 0.0 0.0 7:52.57 ksoftirqd/0
> > 15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1
> >
> >
> > The throughput doesn't increase so much, maybe we hit an HW limit of
> > the gigabit port. The interesting thing is how the global CPU usage
> > drops from 25% to 1%.
> > I can't explain this, it could be due to the reduced contention?
>
> Hi Matteo,
>
> Can I take that as a Tested-by ?
>
> Thanks.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
>
Tested-by: Matteo Croce <mcroce@redhat.com>
probably also:
Reported-by: Matteo Croce <mcroce@redhat.com>
Thanks,
--
Matteo Croce
per aspera ad upstream
_______________________________________________
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 v4 2/4] kasan: record and print the free track
From: Dmitry Vyukov @ 2020-05-20 11:15 UTC (permalink / raw)
To: Walter Wu
Cc: wsd_upstream, linux-mediatek, LKML, kasan-dev, Linux-MM,
Alexander Potapenko, Andrey Ryabinin, Linux ARM
In-Reply-To: <1589969715.2612.2.camel@mtksdccf07>
On Wed, May 20, 2020 at 12:15 PM Walter Wu <walter-zh.wu@mediatek.com> wrote:
>
> On Wed, 2020-05-20 at 11:44 +0200, 'Dmitry Vyukov' via kasan-dev wrote:
> > On Wed, May 20, 2020 at 11:17 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > > > > On Wed, 2020-05-20 at 13:14 +0800, Walter Wu wrote:
> > > > > > > On Wed, May 20, 2020 at 6:03 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > > > > > > >
> > > > > > > > > On Tue, May 19, 2020 at 4:25 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Move free track from slub alloc meta-data to slub free meta-data in
> > > > > > > > > > order to make struct kasan_free_meta size is 16 bytes. It is a good
> > > > > > > > > > size because it is the minimal redzone size and a good number of
> > > > > > > > > > alignment.
> > > > > > > > > >
> > > > > > > > > > For free track in generic KASAN, we do the modification in struct
> > > > > > > > > > kasan_alloc_meta and kasan_free_meta:
> > > > > > > > > > - remove free track from kasan_alloc_meta.
> > > > > > > > > > - add free track into kasan_free_meta.
> > > > > > > > > >
> > > > > > > > > > [1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > > > > > > > > > Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> > > > > > > > > > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > > > > > > > > > Cc: Dmitry Vyukov <dvyukov@google.com>
> > > > > > > > > > Cc: Alexander Potapenko <glider@google.com>
> > > > > > > > > > ---
> > > > > > > > > > mm/kasan/common.c | 22 ++--------------------
> > > > > > > > > > mm/kasan/generic.c | 18 ++++++++++++++++++
> > > > > > > > > > mm/kasan/kasan.h | 7 +++++++
> > > > > > > > > > mm/kasan/report.c | 20 --------------------
> > > > > > > > > > mm/kasan/tags.c | 37 +++++++++++++++++++++++++++++++++++++
> > > > > > > > > > 5 files changed, 64 insertions(+), 40 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > > > > > > > > > index 8bc618289bb1..47b53912f322 100644
> > > > > > > > > > --- a/mm/kasan/common.c
> > > > > > > > > > +++ b/mm/kasan/common.c
> > > > > > > > > > @@ -51,7 +51,7 @@ depot_stack_handle_t kasan_save_stack(gfp_t flags)
> > > > > > > > > > return stack_depot_save(entries, nr_entries, flags);
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > -static inline void set_track(struct kasan_track *track, gfp_t flags)
> > > > > > > > > > +void kasan_set_track(struct kasan_track *track, gfp_t flags)
> > > > > > > > > > {
> > > > > > > > > > track->pid = current->pid;
> > > > > > > > > > track->stack = kasan_save_stack(flags);
> > > > > > > > > > @@ -299,24 +299,6 @@ struct kasan_free_meta *get_free_info(struct kmem_cache *cache,
> > > > > > > > > > return (void *)object + cache->kasan_info.free_meta_offset;
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > -
> > > > > > > > > > -static void kasan_set_free_info(struct kmem_cache *cache,
> > > > > > > > > > - void *object, u8 tag)
> > > > > > > > > > -{
> > > > > > > > > > - struct kasan_alloc_meta *alloc_meta;
> > > > > > > > > > - u8 idx = 0;
> > > > > > > > > > -
> > > > > > > > > > - alloc_meta = get_alloc_info(cache, object);
> > > > > > > > > > -
> > > > > > > > > > -#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > > > > > > > > - idx = alloc_meta->free_track_idx;
> > > > > > > > > > - alloc_meta->free_pointer_tag[idx] = tag;
> > > > > > > > > > - alloc_meta->free_track_idx = (idx + 1) % KASAN_NR_FREE_STACKS;
> > > > > > > > > > -#endif
> > > > > > > > > > -
> > > > > > > > > > - set_track(&alloc_meta->free_track[idx], GFP_NOWAIT);
> > > > > > > > > > -}
> > > > > > > > > > -
> > > > > > > > > > void kasan_poison_slab(struct page *page)
> > > > > > > > > > {
> > > > > > > > > > unsigned long i;
> > > > > > > > > > @@ -492,7 +474,7 @@ static void *__kasan_kmalloc(struct kmem_cache *cache, const void *object,
> > > > > > > > > > KASAN_KMALLOC_REDZONE);
> > > > > > > > > >
> > > > > > > > > > if (cache->flags & SLAB_KASAN)
> > > > > > > > > > - set_track(&get_alloc_info(cache, object)->alloc_track, flags);
> > > > > > > > > > + kasan_set_track(&get_alloc_info(cache, object)->alloc_track, flags);
> > > > > > > > > >
> > > > > > > > > > return set_tag(object, tag);
> > > > > > > > > > }
> > > > > > > > > > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> > > > > > > > > > index 3372bdcaf92a..763d8a13e0ac 100644
> > > > > > > > > > --- a/mm/kasan/generic.c
> > > > > > > > > > +++ b/mm/kasan/generic.c
> > > > > > > > > > @@ -344,3 +344,21 @@ void kasan_record_aux_stack(void *addr)
> > > > > > > > > > alloc_info->aux_stack[1] = alloc_info->aux_stack[0];
> > > > > > > > > > alloc_info->aux_stack[0] = kasan_save_stack(GFP_NOWAIT);
> > > > > > > > > > }
> > > > > > > > > > +
> > > > > > > > > > +void kasan_set_free_info(struct kmem_cache *cache,
> > > > > > > > > > + void *object, u8 tag)
> > > > > > > > > > +{
> > > > > > > > > > + struct kasan_free_meta *free_meta;
> > > > > > > > > > +
> > > > > > > > > > + free_meta = get_free_info(cache, object);
> > > > > > > > > > + kasan_set_track(&free_meta->free_track, GFP_NOWAIT);
> > > > > > > > > > +}
> > > > > > > > > > +
> > > > > > > > > > +struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > > > > > > > > + void *object, u8 tag)
> > > > > > > > > > +{
> > > > > > > > > > + struct kasan_free_meta *free_meta;
> > > > > > > > > > +
> > > > > > > > > > + free_meta = get_free_info(cache, object);
> > > > > > > > > > + return &free_meta->free_track;
> > > > > > > > > > +}
> > > > > > > > > > diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> > > > > > > > > > index a7391bc83070..ad897ec36545 100644
> > > > > > > > > > --- a/mm/kasan/kasan.h
> > > > > > > > > > +++ b/mm/kasan/kasan.h
> > > > > > > > > > @@ -127,6 +127,9 @@ struct kasan_free_meta {
> > > > > > > > > > * Otherwise it might be used for the allocator freelist.
> > > > > > > > > > */
> > > > > > > > > > struct qlist_node quarantine_link;
> > > > > > > > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > > > > > > > + struct kasan_track free_track;
> > > > > > > > > > +#endif
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > struct kasan_alloc_meta *get_alloc_info(struct kmem_cache *cache,
> > > > > > > > > > @@ -168,6 +171,10 @@ void kasan_report_invalid_free(void *object, unsigned long ip);
> > > > > > > > > > struct page *kasan_addr_to_page(const void *addr);
> > > > > > > > > >
> > > > > > > > > > depot_stack_handle_t kasan_save_stack(gfp_t flags);
> > > > > > > > > > +void kasan_set_track(struct kasan_track *track, gfp_t flags);
> > > > > > > > > > +void kasan_set_free_info(struct kmem_cache *cache, void *object, u8 tag);
> > > > > > > > > > +struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > > > > > > > > + void *object, u8 tag);
> > > > > > > > > >
> > > > > > > > > > #if defined(CONFIG_KASAN_GENERIC) && \
> > > > > > > > > > (defined(CONFIG_SLAB) || defined(CONFIG_SLUB))
> > > > > > > > > > diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> > > > > > > > > > index 6f8f2bf8f53b..96d2657fe70f 100644
> > > > > > > > > > --- a/mm/kasan/report.c
> > > > > > > > > > +++ b/mm/kasan/report.c
> > > > > > > > > > @@ -159,26 +159,6 @@ static void describe_object_addr(struct kmem_cache *cache, void *object,
> > > > > > > > > > (void *)(object_addr + cache->object_size));
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > -static struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > > > > > > > > - void *object, u8 tag)
> > > > > > > > > > -{
> > > > > > > > > > - struct kasan_alloc_meta *alloc_meta;
> > > > > > > > > > - int i = 0;
> > > > > > > > > > -
> > > > > > > > > > - alloc_meta = get_alloc_info(cache, object);
> > > > > > > > > > -
> > > > > > > > > > -#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > > > > > > > > - for (i = 0; i < KASAN_NR_FREE_STACKS; i++) {
> > > > > > > > > > - if (alloc_meta->free_pointer_tag[i] == tag)
> > > > > > > > > > - break;
> > > > > > > > > > - }
> > > > > > > > > > - if (i == KASAN_NR_FREE_STACKS)
> > > > > > > > > > - i = alloc_meta->free_track_idx;
> > > > > > > > > > -#endif
> > > > > > > > > > -
> > > > > > > > > > - return &alloc_meta->free_track[i];
> > > > > > > > > > -}
> > > > > > > > > > -
> > > > > > > > > > #ifdef CONFIG_KASAN_GENERIC
> > > > > > > > > > static void print_stack(depot_stack_handle_t stack)
> > > > > > > > > > {
> > > > > > > > > > diff --git a/mm/kasan/tags.c b/mm/kasan/tags.c
> > > > > > > > > > index 25b7734e7013..201dee5d6ae0 100644
> > > > > > > > > > --- a/mm/kasan/tags.c
> > > > > > > > > > +++ b/mm/kasan/tags.c
> > > > > > > > > > @@ -162,3 +162,40 @@ void __hwasan_tag_memory(unsigned long addr, u8 tag, unsigned long size)
> > > > > > > > > > kasan_poison_shadow((void *)addr, size, tag);
> > > > > > > > > > }
> > > > > > > > > > EXPORT_SYMBOL(__hwasan_tag_memory);
> > > > > > > > > > +
> > > > > > > > > > +void kasan_set_free_info(struct kmem_cache *cache,
> > > > > > > > > > + void *object, u8 tag)
> > > > > > > > > > +{
> > > > > > > > > > + struct kasan_alloc_meta *alloc_meta;
> > > > > > > > > > + u8 idx = 0;
> > > > > > > > > > +
> > > > > > > > > > + alloc_meta = get_alloc_info(cache, object);
> > > > > > > > > > +
> > > > > > > > > > +#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > > > > > > > > + idx = alloc_meta->free_track_idx;
> > > > > > > > > > + alloc_meta->free_pointer_tag[idx] = tag;
> > > > > > > > > > + alloc_meta->free_track_idx = (idx + 1) % KASAN_NR_FREE_STACKS;
> > > > > > > > > > +#endif
> > > > > > > > > > +
> > > > > > > > > > + kasan_set_track(&alloc_meta->free_track[idx], GFP_NOWAIT);
> > > > > > > > > > +}
> > > > > > > > > > +
> > > > > > > > > > +struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > > > > > > > > + void *object, u8 tag)
> > > > > > > > > > +{
> > > > > > > > > > + struct kasan_alloc_meta *alloc_meta;
> > > > > > > > > > + int i = 0;
> > > > > > > > > > +
> > > > > > > > > > + alloc_meta = get_alloc_info(cache, object);
> > > > > > > > > > +
> > > > > > > > > > +#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > > > > > > > > + for (i = 0; i < KASAN_NR_FREE_STACKS; i++) {
> > > > > > > > > > + if (alloc_meta->free_pointer_tag[i] == tag)
> > > > > > > > > > + break;
> > > > > > > > > > + }
> > > > > > > > > > + if (i == KASAN_NR_FREE_STACKS)
> > > > > > > > > > + i = alloc_meta->free_track_idx;
> > > > > > > > > > +#endif
> > > > > > > > > > +
> > > > > > > > > > + return &alloc_meta->free_track[i];
> > > > > > > > > > +}
> > > > > > > > >
> > > > > > > > > Hi Walter,
> > > > > > > > >
> > > > > > > > > FTR I've uploaded this for review purposes here:
> > > > > > > > > https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/2458
> > > > > > > > >
> > > > > > > > > Diff from the previous version is available as:
> > > > > > > > > https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/2458/1..2
> > > > > > > > >
> > > > > > > > > I've tested this locally and with syzkaller. This is :
> > > > > > > > >
> > > > > > > > > [ 80.583021][ C3] Freed by task 0:
> > > > > > > > > [ 80.583480][ C3] kasan_save_stack+0x1b/0x40 mm/kasan/common.c:49
> > > > > > > > > [ 80.584056][ C3] kasan_set_track+0x1c/0x30 mm/kasan/common.c:57
> > > > > > > > > [ 80.584617][ C3] kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:354
> > > > > > > > > [ 80.585221][ C3] __kasan_slab_free+0xd8/0x120 mm/kasan/common.c:438
> > > > > > > > > [ 80.585814][ C3] __cache_free mm/slab.c:3426 [inline]
> > > > > > > > > [ 80.585814][ C3] kfree+0x10b/0x2b0 mm/slab.c:3757
> > > > > > > > > [ 80.586291][ C3] kasan_rcu_reclaim+0x16/0x43 [test_kasan]
> > > > > > > > > [ 80.587009][ C3] rcu_do_batch kernel/rcu/tree.c:2207 [inline]
> > > > > > > > > [ 80.587009][ C3] rcu_core+0x59f/0x1370 kernel/rcu/tree.c:2434
> > > > > > > > > [ 80.587537][ C3] __do_softirq+0x26c/0x9fa kernel/softirq.c:292
> > > > > > > > > [ 80.588085][ C3]
> > > > > > > > > [ 80.588367][ C3] Last one call_rcu() call stack:
> > > > > > > > > [ 80.589052][ C3] kasan_save_stack+0x1b/0x40 mm/kasan/common.c:49
> > > > > > > > > [ 80.589622][ C3] kasan_record_aux_stack+0x82/0xb0 mm/kasan/generic.c:345
> > > > > > > > > [ 80.590254][ C3] __call_rcu kernel/rcu/tree.c:2672 [inline]
> > > > > > > > > [ 80.590254][ C3] call_rcu+0x14f/0x7f0 kernel/rcu/tree.c:2746
> > > > > > > > > [ 80.590782][ C3] kasan_rcu_uaf+0xe4/0xeb [test_kasan]
> > > > > > > > > [ 80.591697][ C3] kmalloc_tests_init+0xbc/0x1097 [test_kasan]
> > > > > > > > > [ 80.592900][ C3] do_one_initcall+0x10a/0x7d0 init/main.c:1196
> > > > > > > > > [ 80.593494][ C3] do_init_module+0x1e6/0x6d0 kernel/module.c:3539
> > > > > > > > > [ 80.594066][ C3] load_module+0x7464/0x9450 kernel/module.c:3890
> > > > > > > > > [ 80.594626][ C3] __do_sys_init_module+0x1e3/0x220 kernel/module.c:3953
> > > > > > > > > [ 80.595265][ C3] do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
> > > > > > > > > [ 80.595822][ C3] entry_SYSCALL_64_after_hwframe+0x49/0xb3
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Overall this looks very good to me.
> > > > > > > > > But there is one aspect that bothers me. In the previous patch you had
> > > > > > > > > code that returned NULL from kasan_get_free_track() if the object is
> > > > > > > > > live (which means free meta is not available, it's occupied by object
> > > > > > > > > data). Now you dropped that code, but I think we still need it.
> > > > > > > > > Otherwise we cast user object data to free meta and print the free
> > > > > > > > > stack/pid from whatever garbage is there. This may lead to very
> > > > > > > > > confusing output and potentially to crashes in stackdepot.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Yes, I totally agree with you. In the previous email I thought that
> > > > > > > > there is a problem with free track, but I did not point it out. Thank
> > > > > > > > you for pointing this problem. As you mentioned, we should fix it.
> > > > > > > >
> > > > > > > > > What do you think about this patch on top of your patches?
> > > > > > > > > https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/2478
> > > > > > > > > This way we very precisely mark the period of time when the object has
> > > > > > > > > free track live and set.
> > > > > > > > > If it looks good to you, feel free to incorporate it into your series.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Thank you for providing good idea solution.
> > > > > > > >
> > > > > > > > I saw this patch, that is a great patch. I think it can fix the issue
> > > > > > > > which has garbage stack. it should work as described below.
> > > > > > > >
> > > > > > > > 1). When object is live, then don't print free stack.
> > > > > > > > 2). When object is NOT alive, after free object:
> > > > > > > > 2a). when object is in quarantine, then it can print free stack
> > > > > > > > 2b). when object is NOT in quarantine, then it can NOT print free stack.
> > > > > > > >
> > > > > > > > I have a question about 2), why we don't directly use
> > > > > > > > KASAN_KMALLOC_FREE? if we directly use it, then 2b) can print free
> > > > > > > > stack? 2b) may has use-after-free? so that it may need free stack.
> > > > > > >
> > > > >
> > > > > About 2b), I see another question. When do qlink_free(), it will be
> > > > > written KASAN_KMALLOC_FREE from KASAN_KMALLOC_FREETRACK? if we don't
> > > > > write shadow memory, it is still KASAN_KMALLOC_FREETRACK, then 2b) will
> > > > > have free stack? Because I see you add KASAN_KMALLOC_FREETRACK to get
> > > > > use-after-free in get_shadow_bug_type(). so should it not write
> > > > > KASAN_KMALLOC_FREE?
> > > >
> > > > It may or may not work.
> > > > The potential problem is that when qlink_free calls ___cache_free,
> > > > slab/slub may start using object memory for its own purposes, e.g.
> > > > store the next link. This next link may overwrite part of free meta.
> > > > It actually may work because the slab/slib next link is likely to
> > > > overlap with kasan_free_meta.quarantine_link only. And we may have
> > > > kasan_free_meta.free_track intact while KASAN_KMALLOC_FREE is set. But
> > > > this needs careful checking for both slab and slub and if they may use
> > > > more than 1 word in some configurations.
> > > >
> > >
> > > This problem looks like existing, even without this change? currently
> > > KASAN may get wrong free stack?
> >
> > No, we should not have this problem now. Currently free track is
> > stored in alloc meta. Alloc meta does not overlap with the object.
> > It's only free meta that overlaps with the object and slab metadata at
> > different periods of the block lifetime. Schematically what we have
> > is:
> >
> > struct block_t {
> > alloc_meta kasan_alloc_meta;
> > union {
> > user_data char[N];
> > slab_meta slab_meta;
> > free_meta kasan_free_meta;
> > };
> > }
> >
> > free_meta shared storage space with 2 other things.
> >
>
> Ah...I forget it is stored in alloc mata, Yes, it should not have this
> problem.
>
> Thanks for your detailed explanation
>
> > > Regardless of whether the shadow memory content is
> > > KASAN_KMALLOC_FREETRACK or KASAN_KMALLOC_FREE, it may have this problem?
> >
> > KASAN_KMALLOC_FREETRACK is set only when nobody else uses the storage.
> >
>
> Ok, I will use KASAN_KMALLOC_FREE. If you have any concerns, please tell me.
> Thanks.
You mean KASAN_KMALLOC_FREETRACK?
Or, you checked that using KASAN_KMALLOC_FREE is safe and will not
cause any bad overlap?
> > > But because of kasan_get_free_track() have conditions to get free track,
> > > so that if shadow memory content is KASAN_KMALLOC_FREE, then it will
> > > avoid this problem and always print right free stack.
> >
> >
> >
> > > > > > > We can't use KASAN_KMALLOC_FREE because of this part:
> > > > > > >
> > > > > > > static bool __kasan_slab_free(struct kmem_cache *cache, void *object,
> > > > > > > unsigned long ip, bool quarantine)
> > > > > > > {
> > > > > > > ...
> > > > > > > kasan_poison_shadow(object, rounded_up_size, KASAN_KMALLOC_FREE);
> > > > > > >
> > > > > > > if ((IS_ENABLED(CONFIG_KASAN_GENERIC) && !quarantine) ||
> > > > > > > unlikely(!(cache->flags & SLAB_KASAN)))
> > > > > > > return false;
> > > > > > >
> > > > > > > kasan_set_free_info(cache, object, tag);
> > > > > > > ...
> > > > > > >
> > > > > >
> > > > > > Ok, I see. When return false, then the shadow memory content has
> > > > > > KASAN_KMALLOC_FREE, but it doesn't set free stack, so that we need to
> > > > > > avoid this situation. Thank for you reminder.
> > > > > >
> > > > > > >
> > > > > > > We may set KASAN_KMALLOC_FREE, but not set the track (or even have
> > > > > > > memory for the track!).
> > > > > > > The object may not have free meta allocated at all, e.g. very large
> > > > > > > object with ctor (no place to store meta), or it may be in a mempool:
> > > > > > > https://elixir.bootlin.com/linux/v5.7-rc6/source/mm/mempool.c#L109
> > > > > > > and mempool may be using the object memory itself (for its own next
> > > > > > > link or something).
> > > > > > >
> > > > > > > KASAN_KMALLOC_FREETRACK very explicitly tracks the exact condition we
> > > > > > > want: we have meta info live now and we have free track set.
_______________________________________________
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 2/3] sdhci: sparx5: Add Sparx5 SoC eMMC driver
From: Lars Povlsen @ 2020-05-20 11:14 UTC (permalink / raw)
To: Adrian Hunter
Cc: devicetree, Ulf Hansson, Alexandre Belloni, linux-mmc,
linux-kernel, Microchip Linux Driver Support, SoC Team,
Lars Povlsen, linux-arm-kernel
In-Reply-To: <87v9ktoc0h.fsf@soft-dev15.microsemi.net>
Lars Povlsen writes:
> Adrian Hunter writes:
>
>> On 13/05/20 4:31 pm, Lars Povlsen wrote:
>>> This adds the eMMC driver for the Sparx5 SoC. It is based upon the
>>> designware IP, but requires some extra initialization and quirks.
>>>
>>> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>>> ---
{Snip]
>>> +};
>>> +
>>> +static const struct sdhci_pltfm_data sdhci_sparx5_pdata = {
>>> + .quirks = 0,
>>> + .quirks2 = SDHCI_QUIRK2_HOST_NO_CMD23 | /* Card quirk */
>>
>> If this is a card quirk then it should be in drivers/mmc/core/quirks.h not here.
>
Adrian, I had a go at changing the controller quirk to a card quirk.
Unfortunately, SDHCI_QUIRK2_HOST_NO_CMD23 does not directly translate to
MMC_QUIRK_BLK_NO_CMD23, as for 'do_rel_wr' in mmc_blk_rw_rq_prep(), it
will *still* use MMC_SET_BLOCK_COUNT (cmd23), causing the issue.
We are using a ISSI "IS004G" device, and so I have gone through the
motions of adding it to quirks.h. The comment before the list of devices
using MMC_QUIRK_BLK_NO_CMD23 suggest working around a performance issue,
which is not exactly the issue I'm seeing. I'm seeing combinations of
CMD_TOUT_ERR, DATA_CRC_ERR and DATA_END_BIT_ERR whenever a cmd23 is
issued.
I have not been able to test the controller with another eMMC device
yet, but I expect its not the controller at fault.
So, I'm a little bit in doubt of how to proceed - either keep the quirk
as a controller quirk - or make a *new* card quirk (with
SDHCI_QUIRK2_HOST_NO_CMD23 semantics)?
Anybody else have had experience with ISSI eMMC devices?
I have also tried to use DT sdhci-caps-mask, but MMC_CAP_CMD23 is not
read from the controller just (unconditionally) set in sdhci.c - so that
doesn't fly either.
Any suggestions?
> Yes, its supposedly a card quirk. I'll see to use the card quirks
> methods in place.
>
--
Lars Povlsen,
Microchip
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 4/4] arm64: kgdb: Round up cpus using IPI_CALL_NMI_FUNC
From: Sumit Garg @ 2020-05-20 11:11 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sumit Garg, daniel.thompson, jason, catalin.marinas, jason.wessel,
dianders, linux-kernel, maz, kgdb-bugreport, tglx, will,
julien.thierry.kdev
In-Reply-To: <1589973115-14757-1-git-send-email-sumit.garg@linaro.org>
arm64 platforms with GICv3 or later supports pseudo NMIs which can be
leveraged to round up CPUs which are stuck in hard lockup state with
interrupts disabled that wouldn't be possible with a normal IPI.
So instead switch to round up CPUs using IPI_CALL_NMI_FUNC. And in
case a particular arm64 platform doesn't supports pseudo NMIs,
IPI_CALL_NMI_FUNC will act as a normal IPI which maintains existing
kgdb functionality.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
arch/arm64/include/asm/kgdb.h | 8 ++++++++
arch/arm64/kernel/kgdb.c | 21 +++++++++++++++++++++
arch/arm64/kernel/smp.c | 3 ++-
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kgdb.h b/arch/arm64/include/asm/kgdb.h
index 21fc85e..6f3d3af 100644
--- a/arch/arm64/include/asm/kgdb.h
+++ b/arch/arm64/include/asm/kgdb.h
@@ -24,6 +24,14 @@ static inline void arch_kgdb_breakpoint(void)
extern void kgdb_handle_bus_error(void);
extern int kgdb_fault_expected;
+#ifdef CONFIG_KGDB
+extern void ipi_kgdb_nmicallback(int cpu, void *regs);
+#else
+static inline void ipi_kgdb_nmicallback(int cpu, void *regs)
+{
+}
+#endif
+
#endif /* !__ASSEMBLY__ */
/*
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index 4311992..ee932ba 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -14,6 +14,7 @@
#include <linux/kgdb.h>
#include <linux/kprobes.h>
#include <linux/sched/task_stack.h>
+#include <linux/smp.h>
#include <asm/debug-monitors.h>
#include <asm/insn.h>
@@ -353,3 +354,23 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
return aarch64_insn_write((void *)bpt->bpt_addr,
*(u32 *)bpt->saved_instr);
}
+
+void ipi_kgdb_nmicallback(int cpu, void *regs)
+{
+ if (atomic_read(&kgdb_active) != -1)
+ kgdb_nmicallback(cpu, regs);
+}
+
+#ifdef CONFIG_SMP
+void kgdb_roundup_cpus(void)
+{
+ struct cpumask mask;
+
+ cpumask_copy(&mask, cpu_online_mask);
+ cpumask_clear_cpu(raw_smp_processor_id(), &mask);
+ if (cpumask_empty(&mask))
+ return;
+
+ arch_send_call_nmi_func_ipi_mask(&mask);
+}
+#endif
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index c5e42a1..3baace7 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -31,6 +31,7 @@
#include <linux/of.h>
#include <linux/irq_work.h>
#include <linux/kexec.h>
+#include <linux/kgdb.h>
#include <linux/kvm_host.h>
#include <asm/alternative.h>
@@ -958,7 +959,7 @@ static void do_handle_IPI(int ipinr)
#endif
case IPI_CALL_NMI_FUNC:
- /* nop, IPI handlers for special features can be added here. */
+ ipi_kgdb_nmicallback(cpu, get_irq_regs());
break;
default:
--
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 v2 3/4] arm64: smp: Setup IPI_CALL_NMI_FUNC as a pseudo NMI
From: Sumit Garg @ 2020-05-20 11:11 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sumit Garg, daniel.thompson, jason, catalin.marinas, jason.wessel,
dianders, linux-kernel, maz, kgdb-bugreport, tglx, will,
julien.thierry.kdev
In-Reply-To: <1589973115-14757-1-git-send-email-sumit.garg@linaro.org>
Setup IPI_CALL_NMI_FUNC as a pseudo NMI using generic interrupt framework
APIs. In case a plarform doesn't provide support for pseudo NMIs, switch
back to IPI_CALL_NMI_FUNC being a normal interrupt.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
arch/arm64/kernel/smp.c | 35 ++++++++++++++++++++++++++---------
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 236784e..c5e42a1 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -68,6 +68,7 @@ struct secondary_data secondary_data;
int cpus_stuck_in_kernel;
static int ipi_irq_base;
+static int ipi_nmi = -1;
static int nr_ipi = NR_IPI;
static struct irq_desc *ipi_desc[NR_IPI];
@@ -986,8 +987,14 @@ static void ipi_setup(int cpu)
if (ipi_irq_base) {
int i;
- for (i = 0; i < nr_ipi; i++)
- enable_percpu_irq(ipi_irq_base + i, 0);
+ for (i = 0; i < nr_ipi; i++) {
+ if (ipi_nmi == ipi_irq_base + i) {
+ if (!prepare_percpu_nmi(ipi_nmi))
+ enable_percpu_nmi(ipi_nmi, 0);
+ } else {
+ enable_percpu_irq(ipi_irq_base + i, 0);
+ }
+ }
}
}
@@ -997,23 +1004,33 @@ static void ipi_teardown(int cpu)
int i;
for (i = 0; i < nr_ipi; i++)
- disable_percpu_irq(ipi_irq_base + i);
+ if (ipi_nmi == ipi_irq_base + i) {
+ disable_percpu_nmi(ipi_nmi);
+ teardown_percpu_nmi(ipi_nmi);
+ } else {
+ disable_percpu_irq(ipi_irq_base + i);
+ }
}
}
void __init set_smp_ipi_range(int ipi_base, int n)
{
- int i;
+ int i, err;
WARN_ON(n < NR_IPI);
nr_ipi = min(n, NR_IPI);
- for (i = 0; i < nr_ipi; i++) {
- int err;
+ err = request_percpu_nmi(ipi_base + IPI_CALL_NMI_FUNC,
+ ipi_handler, "IPI", &irq_stat);
+ if (!err)
+ ipi_nmi = ipi_base + IPI_CALL_NMI_FUNC;
- err = request_percpu_irq(ipi_base + i, ipi_handler,
- "IPI", &irq_stat);
- WARN_ON(err);
+ for (i = 0; i < nr_ipi; i++) {
+ if (ipi_base + i != ipi_nmi) {
+ err = request_percpu_irq(ipi_base + i, ipi_handler,
+ "IPI", &irq_stat);
+ WARN_ON(err);
+ }
ipi_desc[i] = irq_to_desc(ipi_base + i);
irq_set_status_flags(ipi_base + i, IRQ_NO_ACCOUNTING);
--
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 v2 2/4] irqchip/gic-v3: Enable support for SGIs to act as NMIs
From: Sumit Garg @ 2020-05-20 11:11 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sumit Garg, daniel.thompson, jason, catalin.marinas, jason.wessel,
dianders, linux-kernel, maz, kgdb-bugreport, tglx, will,
julien.thierry.kdev
In-Reply-To: <1589973115-14757-1-git-send-email-sumit.garg@linaro.org>
Add support to handle SGIs as regular NMIs. As SGIs or IPIs defaults to a
special flow handler: handle_percpu_devid_fasteoi_ipi(), so skip NMI
handler update in case of SGIs.
Also, enable NMI support prior to gic_smp_init() as allocation of SGIs
as IRQs/NMIs happen as part of this routine.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
drivers/irqchip/irq-gic-v3.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 82095b8..ceef63b 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -477,6 +477,11 @@ static int gic_irq_nmi_setup(struct irq_data *d)
if (WARN_ON(gic_irq(d) >= 8192))
return -EINVAL;
+ if (get_intid_range(d) == SGI_RANGE) {
+ gic_irq_set_prio(d, GICD_INT_NMI_PRI);
+ return 0;
+ }
+
/* desc lock should already be held */
if (gic_irq_in_rdist(d)) {
u32 idx = gic_get_ppi_index(d);
@@ -514,6 +519,11 @@ static void gic_irq_nmi_teardown(struct irq_data *d)
if (WARN_ON(gic_irq(d) >= 8192))
return;
+ if (get_intid_range(d) == SGI_RANGE) {
+ gic_irq_set_prio(d, GICD_INT_DEF_PRI);
+ return;
+ }
+
/* desc lock should already be held */
if (gic_irq_in_rdist(d)) {
u32 idx = gic_get_ppi_index(d);
@@ -1675,6 +1685,7 @@ static int __init gic_init_bases(void __iomem *dist_base,
gic_dist_init();
gic_cpu_init();
+ gic_enable_nmi_support();
gic_smp_init();
gic_cpu_pm_init();
@@ -1686,8 +1697,6 @@ static int __init gic_init_bases(void __iomem *dist_base,
gicv2m_init(handle, gic_data.domain);
}
- gic_enable_nmi_support();
-
return 0;
out_free:
--
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 v2 1/4] arm64: smp: Introduce a new IPI as IPI_CALL_NMI_FUNC
From: Sumit Garg @ 2020-05-20 11:11 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sumit Garg, daniel.thompson, jason, catalin.marinas, jason.wessel,
dianders, linux-kernel, maz, kgdb-bugreport, tglx, will,
julien.thierry.kdev
In-Reply-To: <1589973115-14757-1-git-send-email-sumit.garg@linaro.org>
Introduce a new inter processor interrupt as IPI_CALL_NMI_FUNC that
can be invoked to run special handlers in NMI context. One such handler
example is kgdb_nmicallback() which is invoked in order to round up CPUs
to enter kgdb context.
As currently pseudo NMIs are supported on specific arm64 platforms which
incorporates GICv3 or later version of interrupt controller. In case a
particular platform doesn't support pseudo NMIs, IPI_CALL_NMI_FUNC will
act as a normal IPI which can still be used to invoke special handlers.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
arch/arm64/include/asm/hardirq.h | 2 +-
arch/arm64/include/asm/smp.h | 1 +
arch/arm64/kernel/smp.c | 13 ++++++++++++-
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/hardirq.h b/arch/arm64/include/asm/hardirq.h
index 87ad961..abaa23a 100644
--- a/arch/arm64/include/asm/hardirq.h
+++ b/arch/arm64/include/asm/hardirq.h
@@ -13,7 +13,7 @@
#include <asm/kvm_arm.h>
#include <asm/sysreg.h>
-#define NR_IPI 7
+#define NR_IPI 8
typedef struct {
unsigned int __softirq_pending;
diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index bec6ef0..b4602de 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -106,6 +106,7 @@ extern void secondary_entry(void);
extern void arch_send_call_function_single_ipi(int cpu);
extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
+extern void arch_send_call_nmi_func_ipi_mask(const struct cpumask *mask);
#ifdef CONFIG_ARM64_ACPI_PARKING_PROTOCOL
extern void arch_send_wakeup_ipi_mask(const struct cpumask *mask);
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index d29823a..236784e 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -81,7 +81,8 @@ enum ipi_msg_type {
IPI_CPU_CRASH_STOP,
IPI_TIMER,
IPI_IRQ_WORK,
- IPI_WAKEUP
+ IPI_WAKEUP,
+ IPI_CALL_NMI_FUNC
};
#ifdef CONFIG_HOTPLUG_CPU
@@ -802,6 +803,7 @@ static const char *ipi_types[NR_IPI] __tracepoint_string = {
S(IPI_TIMER, "Timer broadcast interrupts"),
S(IPI_IRQ_WORK, "IRQ work interrupts"),
S(IPI_WAKEUP, "CPU wake-up interrupts"),
+ S(IPI_CALL_NMI_FUNC, "NMI function call interrupts"),
};
static void smp_cross_call(const struct cpumask *target, unsigned int ipinr);
@@ -855,6 +857,11 @@ void arch_irq_work_raise(void)
}
#endif
+void arch_send_call_nmi_func_ipi_mask(const struct cpumask *mask)
+{
+ smp_cross_call(mask, IPI_CALL_NMI_FUNC);
+}
+
static void local_cpu_stop(void)
{
set_cpu_online(smp_processor_id(), false);
@@ -949,6 +956,10 @@ static void do_handle_IPI(int ipinr)
break;
#endif
+ case IPI_CALL_NMI_FUNC:
+ /* nop, IPI handlers for special features can be added here. */
+ break;
+
default:
pr_crit("CPU%u: Unknown IPI message 0x%x\n", cpu, ipinr);
break;
--
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 v2 0/4] arm64: Introduce new IPI as IPI_CALL_NMI_FUNC
From: Sumit Garg @ 2020-05-20 11:11 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sumit Garg, daniel.thompson, jason, catalin.marinas, jason.wessel,
dianders, linux-kernel, maz, kgdb-bugreport, tglx, will,
julien.thierry.kdev
With pseudo NMIs support available its possible to configure SGIs to be
triggered as pseudo NMIs running in NMI context. And kernel features
such as kgdb relies on NMI support to round up CPUs which are stuck in
hard lockup state with interrupts disabled.
This patch-set adds support for IPI_CALL_NMI_FUNC which can be triggered
as a pseudo NMI which in turn is leveraged via kgdb to round up CPUs.
After this patch-set we should be able to get a backtrace for a CPU
stuck in HARDLOCKUP. Have a look at an example below from a testcase run
on Developerbox:
$ echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT
# Enter kdb via Magic SysRq
[11]kdb> btc
btc: cpu status: Currently on cpu 10
Available cpus: 0-7(I), 8, 9(I), 10, 11-23(I)
<snip>
Stack traceback for pid 619
0xffff000871bc9c00 619 618 1 8 R 0xffff000871bca5c0 bash
CPU: 8 PID: 619 Comm: bash Not tainted 5.7.0-rc6-00762-g3804420 #77
Hardware name: Socionext SynQuacer E-series DeveloperBox, BIOS build #73 Apr 6 2020
Call trace:
dump_backtrace+0x0/0x198
show_stack+0x18/0x28
dump_stack+0xb8/0x100
kgdb_cpu_enter+0x5c0/0x5f8
kgdb_nmicallback+0xa0/0xa8
ipi_kgdb_nmicallback+0x24/0x30
ipi_handler+0x160/0x1b8
handle_percpu_devid_fasteoi_ipi+0x44/0x58
generic_handle_irq+0x30/0x48
handle_domain_nmi+0x44/0x80
gic_handle_irq+0x140/0x2a0
el1_irq+0xcc/0x180
lkdtm_HARDLOCKUP+0x10/0x18
direct_entry+0x124/0x1c0
full_proxy_write+0x60/0xb0
__vfs_write+0x1c/0x48
vfs_write+0xe4/0x1d0
ksys_write+0x6c/0xf8
__arm64_sys_write+0x1c/0x28
el0_svc_common.constprop.0+0x74/0x1f0
do_el0_svc+0x24/0x90
el0_sync_handler+0x178/0x2b8
el0_sync+0x158/0x180
<snip>
Changes since RFC version [1]:
- Switch to use generic interrupt framework to turn an IPI as NMI.
- Dependent on Marc's patch-set [2] which turns IPIs into normal
interrupts.
- Addressed misc. comments from Doug on patch #4.
- Posted kgdb NMI printk() fixup separately which has evolved since
to be solved using different approach via changing kgdb interception
of printk() in common printk() code (see patch [3]).
[1] https://lkml.org/lkml/2020/4/24/328
[2] https://lkml.org/lkml/2020/5/19/710
[3] https://lkml.org/lkml/2020/5/20/418
Sumit Garg (4):
arm64: smp: Introduce a new IPI as IPI_CALL_NMI_FUNC
irqchip/gic-v3: Enable support for SGIs to act as NMIs
arm64: smp: Setup IPI_CALL_NMI_FUNC as a pseudo NMI
arm64: kgdb: Round up cpus using IPI_CALL_NMI_FUNC
arch/arm64/include/asm/hardirq.h | 2 +-
arch/arm64/include/asm/kgdb.h | 8 +++++++
arch/arm64/include/asm/smp.h | 1 +
arch/arm64/kernel/kgdb.c | 21 +++++++++++++++++
arch/arm64/kernel/smp.c | 49 ++++++++++++++++++++++++++++++++--------
drivers/irqchip/irq-gic-v3.c | 13 +++++++++--
6 files changed, 81 insertions(+), 13 deletions(-)
--
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
* Re: [EXT] Re: [PATCH net-next 3/5] net: mvpp2: cls: Use RSS contexts to handle RSS tables
From: Russell King - ARM Linux admin @ 2020-05-20 11:10 UTC (permalink / raw)
To: Matteo Croce
Cc: Antoine Tenart, netdev, gregory.clement@bootlin.com, LKML,
Maxime Chevallier, Nadav Haklai, Thomas Petazzoni,
miquel.raynal@bootlin.com, Stefan Chulski, Marcin Wojtas,
David S . Miller, Linux ARM
In-Reply-To: <20200519190534.78bb8389@turbo.teknoraver.net>
On Tue, May 19, 2020 at 07:05:34PM +0200, Matteo Croce wrote:
> On Tue, 19 May 2020 12:05:20 +0200
> Matteo Croce <mcroce@redhat.com> wrote:
>
> Hi,
>
> The patch seems to work. I'm generating traffic with random MAC and IP
> addresses, to have many flows:
>
> # tcpdump -tenni eth2
> 9a:a9:b1:3a:b1:6b > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.4.0 > 192.168.0.4.0: UDP, length 12
> 9e:92:fd:f8:7f:0a > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.4.0 > 192.168.0.4.0: UDP, length 12
> 66:b7:11:8a:c2:1f > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.1.0 > 192.168.0.1.0: UDP, length 12
> 7a:ba:58:bd:9a:62 > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.1.0 > 192.168.0.1.0: UDP, length 12
> 7e:78:a9:97:70:3a > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.2.0 > 192.168.0.2.0: UDP, length 12
> b2:81:91:34:ce:42 > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.2.0 > 192.168.0.2.0: UDP, length 12
> 2a:05:52:d0:d9:3f > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.3.0 > 192.168.0.3.0: UDP, length 12
> ee:ee:47:35:fa:81 > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: 10.0.0.3.0 > 192.168.0.3.0: UDP, length 12
>
> This is the default rate, with rxhash off:
>
> # utraf eth2
> tx: 0 bps 0 pps rx: 397.4 Mbps 827.9 Kpps
> tx: 0 bps 0 pps rx: 396.3 Mbps 825.7 Kpps
> tx: 0 bps 0 pps rx: 396.6 Mbps 826.3 Kpps
> tx: 0 bps 0 pps rx: 396.5 Mbps 826.1 Kpps
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 9 root 20 0 0 0 0 R 99.7 0.0 7:02.58 ksoftirqd/0
> 15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1
> 20 root 20 0 0 0 0 S 0.0 0.0 2:01.48 ksoftirqd/2
> 25 root 20 0 0 0 0 S 0.0 0.0 0:32.86 ksoftirqd/3
>
> and this with rx hashing enabled:
>
> # ethtool -K eth2 rxhash on
> # utraf eth2
> tx: 0 bps 0 pps rx: 456.4 Mbps 950.8 Kpps
> tx: 0 bps 0 pps rx: 458.4 Mbps 955.0 Kpps
> tx: 0 bps 0 pps rx: 457.6 Mbps 953.3 Kpps
> tx: 0 bps 0 pps rx: 462.2 Mbps 962.9 Kpps
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 20 root 20 0 0 0 0 R 0.7 0.0 2:02.34 ksoftirqd/2
> 25 root 20 0 0 0 0 S 0.3 0.0 0:33.25 ksoftirqd/3
> 9 root 20 0 0 0 0 S 0.0 0.0 7:52.57 ksoftirqd/0
> 15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1
>
>
> The throughput doesn't increase so much, maybe we hit an HW limit of
> the gigabit port. The interesting thing is how the global CPU usage
> drops from 25% to 1%.
> I can't explain this, it could be due to the reduced contention?
Hi Matteo,
Can I take that as a Tested-by ?
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
_______________________________________________
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 1/3] arm64: vdso: Don't prefix sigreturn trampoline with a BTI C instruction
From: Dave Martin @ 2020-05-20 11:08 UTC (permalink / raw)
To: Mark Brown
Cc: Tamas Zsoldos, Will Deacon, kernel-team, linux-arm-kernel,
Daniel Kiss
In-Reply-To: <20200520104653.GA4823@sirena.org.uk>
On Wed, May 20, 2020 at 11:46:53AM +0100, Mark Brown wrote:
> On Wed, May 20, 2020 at 10:48:45AM +0100, Dave Martin wrote:
> > On Tue, May 19, 2020 at 04:42:47PM +0100, Mark Brown wrote:
> > > On Tue, May 19, 2020 at 03:55:15PM +0100, Dave Martin wrote:
>
> > > > > > If BTI {nothing} allows this while disallowing all BR/BLR then we could
> > > > > > use that (I can't remember what BTI {nothing} is useful for, if anything).
>
> > > > > > Otherwise, it's less clear what we should have here.
>
> > > > > I can't remember anything that distinguishes it from an explicit NOP.
>
> > > > I think it rejects everything other then fallthrough execution
> > > > (BTYPE==0, which includes RET). I might have misunderstood something
>
> > > Right, but since BTI only generates an exception when BTYPE != 0 I'm
> > > having trouble differentiating this from a NOP in practical terms.
>
> > The idea would be that if an attacker could fudge some function pointer
> > to point at __kernel_rt_sigreturn, attempting to do a call via that
> > pointer would still trigger a BTI trap.
>
> We'll get a BTI exception no matter what instruction is here so long as
> it's not an appropriate BTI landing pad so unless we want to prevent one
> being generated there's no need to change the instruction sequence. Or
> perhaps I'm not quite getting the scenario you're thinking of?
Duh, yes. I guess we're good, then.
Cheers
---Dave
_______________________________________________
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 2/2] arm64: vdso: Fix CFI directives in sigreturn trampoline
From: Dave Martin @ 2020-05-20 11:06 UTC (permalink / raw)
To: Will Deacon
Cc: Tamas Zsoldos, Mark Brown, kernel-team, linux-arm-kernel,
Daniel Kiss
In-Reply-To: <20200520104803.GA25694@willie-the-truck>
On Wed, May 20, 2020 at 11:48:03AM +0100, Will Deacon wrote:
> On Tue, May 19, 2020 at 05:28:21PM +0100, Will Deacon wrote:
> > Daniel reports that the .cfi_startproc is misplaced for the sigreturn
> > trampoline, which causes LLVM's unwinder to misbehave:
> >
> > | I run into this with LLVM’s unwinder.
> > | This combination was always broken.
> >
> > This prompted Dave to question our use of CFI directives more generally,
> > and I ended up going down a rabbit hole trying to figure out how this
> > very poorly documented stuff gets used.
> >
> > Move the CFI directives so that the "mysterious NOP" is included in
> > the .cfi_{start,end}proc block and add a bunch of comments so that I
> > can save myself another headache in future.
> >
> > Cc: Tamas Zsoldos <tamas.zsoldos@arm.com>
> > Reported-by: Dave Martin <dave.martin@arm.com>
> > Reported-by: Daniel Kiss <daniel.kiss@arm.com>
> > Signed-off-by: Will Deacon <will@kernel.org>
> > ---
> > arch/arm64/kernel/vdso/sigreturn.S | 40 ++++++++++++++++++++++++------
> > 1 file changed, 33 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/vdso/sigreturn.S b/arch/arm64/kernel/vdso/sigreturn.S
> > index 0c921130002a..cb47dfb3bd5a 100644
> > --- a/arch/arm64/kernel/vdso/sigreturn.S
> > +++ b/arch/arm64/kernel/vdso/sigreturn.S
> > @@ -1,7 +1,11 @@
> > /* SPDX-License-Identifier: GPL-2.0-only */
> > /*
> > * Sigreturn trampoline for returning from a signal when the SA_RESTORER
> > - * flag is not set.
> > + * flag is not set. It serves primarily as a hall of shame for crappy
> > + * unwinders and features an exciting but mysterious NOP instruction.
> > + *
> > + * It's also fragile as hell, so please think twice before changing anything
> > + * in here.
> > *
> > * Copyright (C) 2012 ARM Limited
> > *
> > @@ -14,7 +18,34 @@
> >
> > .text
> >
> > - nop
> > +/* Ensure that the mysterious NOP can be associated with a function. */
> > + .cfi_startproc
> > +
> > +/*
> > + * .cfi_signal_frame causes the corresponding Frame Description Entry in the
> > + * .eh_frame section to be annotated as a signal frame. This allows DWARF
> > + * unwinders (e.g. libstdc++) to implement _Unwind_GetIPInfo(), which permits
> > + * unwinding out of the signal trampoline without the need for the mysterious
> > + * NOP.
> > + */
> > + .cfi_signal_frame
> > +
> > +/*
> > + * Tell the unwinder where to locate the frame record linking back to the
> > + * interrupted context.
> > + */
> > + .cfi_def_cfa x29, 0
> > + .cfi_offset x29, 0 * 8
> > + .cfi_offset x29, 1 * 8
>
> Oops, just spotted this bug: second entry should be x30.
Dang, didn't spot that. Yes.
Must have been momory corruption in your editor...
Cheers
---Dave
_______________________________________________
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 2/2] arm64: vdso: Fix CFI directives in sigreturn trampoline
From: Dave Martin @ 2020-05-20 11:03 UTC (permalink / raw)
To: Will Deacon
Cc: Tamas Zsoldos, Mark Brown, kernel-team, linux-arm-kernel,
Daniel Kiss
In-Reply-To: <20200520103640.GA25539@willie-the-truck>
On Wed, May 20, 2020 at 11:36:40AM +0100, Will Deacon wrote:
> On Wed, May 20, 2020 at 11:27:47AM +0100, Dave Martin wrote:
> > On Wed, May 20, 2020 at 10:50:28AM +0100, Will Deacon wrote:
> > > On Wed, May 20, 2020 at 10:42:13AM +0100, Dave Martin wrote:
> > > > On Tue, May 19, 2020 at 05:28:21PM +0100, Will Deacon wrote:
> > > > > @@ -14,7 +18,34 @@
> > > > >
> > > > > .text
> > > > >
> > > > > - nop
> > > > > +/* Ensure that the mysterious NOP can be associated with a function. */
> > > > > + .cfi_startproc
> > > > > +
> > > > > +/*
> > > > > + * .cfi_signal_frame causes the corresponding Frame Description Entry in the
> > > > > + * .eh_frame section to be annotated as a signal frame. This allows DWARF
> > > > > + * unwinders (e.g. libstdc++) to implement _Unwind_GetIPInfo(), which permits
> > > > > + * unwinding out of the signal trampoline without the need for the mysterious
> > > > > + * NOP.
> > > > > + */
> > > > > + .cfi_signal_frame
> > > > > +
> > > > > +/*
> > > > > + * Tell the unwinder where to locate the frame record linking back to the
> > > > > + * interrupted context.
> > > > > + */
> > > > > + .cfi_def_cfa x29, 0
> > > > > + .cfi_offset x29, 0 * 8
> > > > > + .cfi_offset x29, 1 * 8
> > > >
> > > > We should also give rationale for why we don't describe how to recover
> > > > other regs here. At a signal, every reg is potentially live with data
> > > > essential to the backtrace, so custom unwind entries further up the
> > > > stack may unwind badly after trying to unwind out of the signal handler.
> > >
> > > Hmm, I'm not sure I get what you're asking for. We can't recover the other
> > > registers even if we tried, can we? I think the only way to get a reliable
> > > backtrace here is not to clobber the framepointer.
> >
> > A caller somewhere up the stack could have stashed stuff in nonstandard
> > places, with a custom unwind entry that doesn't use x29 in the usual way.
> >
> > If x29 and x30 were stashed in x8 and x9, say, then the unwinder needs
> > to restore x8 and x9 correctly before that frame is reached. Dwarf
> > unwind tables are expressive enough to describe how to unwind such a
> > frames: the directives work on all the registers, not just x29, lr.
>
> Understood, I just can't figure out how we could support that even if we
> wanted to. The only evidence we have of those registers is in the
> sigcontext, but that may have been modified by the time we end up in the
> return trampoline. Would we need to push the registers twice (i.e. expand
> the frame record to include the GPRs)? Not saying we should do this, just
> wondering what it would take.
No, it's inevitably best effort.
If the signal handler doesn't intend to return, than the backtrace may
be nonsense anyway. The signal might result from the regs being garbage
anyway, or the signal might be deliberate suicide by the "caller".
If the signal handler does intend to return normally, then it is
responsible for manipulating the sigcontext in a way that doesn't break
the interrupted code -- which implies that the backtrace will be valid,
and also means that invasive non-atomic changes to the sigcontext are
unlikely. Because we can't know the intent of the handler, no amount
of pushing duplicates etc. can work 100% of the time.
The overwhelmingly common case of is that the signal handler doesn't
mess with sigcontext at all, though. So we could probably restore the
integer regs correctly for the common case.
Nonetheless, there are limitations. Dwarf unwind can't describe how to
unwind the FPSIMD/SVE regs etc. We're really into debugger territory
if we start to care about that stuff.
> > For this kind of unwinding scenario to wokr, the userspace environment
> > would need to provide correct unwind info for _everything_ rather than
> > relying on the frame chain on the stack alone, so this scenario isn't
> > applicable to C.
> >
> > I'm not saying we should try to support this, but a comment to indicate
> > what we are and are not trying to do might be a good idea.
> >
> > How about something along these lines:
> >
> > /*
> > * Don't try to provide unwind into for the other regs of the
> > * interrupted context here. C/C++ based runtimes don't rely on
> > * this for unwinding in practice. Debuggers need more, but they
> > * already have baked-in knowledge about how to unwind out of
> > * signals.
> > */
>
> I'll fold that in, thanks.
Thanks. This just avoids having to ask the question again or go back
over all the messy rationale above.
If someone _needs_ this to be extended in future, we can revisit it.
But I hope not!
Cheers
---Dave
_______________________________________________
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 0/3] firmare: arm_sdei: Extras for v5.8
From: Will Deacon @ 2020-05-20 11:00 UTC (permalink / raw)
To: James Morse, linux-arm-kernel
Cc: catalin.marinas, Will Deacon, Christoph Hellwig, Hanjun Guo
In-Reply-To: <20200519182108.13693-1-james.morse@arm.com>
On Tue, 19 May 2020 19:21:05 +0100, James Morse wrote:
> Some extra patches for SDEI if you're still willing to add to your tree.
>
> Hanjun's patch to cleanup some ACPI table handling conflicts with
> Sudeep's patch that you already have queued.
>
> Based on arm64's for-next/sdei branch: v5.7-rc3-1-gcaf2cd610dbb
>
> [...]
Applied to arm64 (for-next/sdei), thanks!
[1/3] firmware: arm_sdei: Put the SDEI table after using it
https://git.kernel.org/arm64/c/70e6352aefb1
[2/3] firmware: arm_sdei: remove unused interfaces
https://git.kernel.org/arm64/c/82b2077afccd
[3/3] firmware: arm_sdei: Document the motivation behind these set_fs() calls
https://git.kernel.org/arm64/c/472de63b0b83
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
_______________________________________________
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 v4 2/4] kasan: record and print the free track
From: Dmitry Vyukov @ 2020-05-20 9:44 UTC (permalink / raw)
To: Walter Wu
Cc: wsd_upstream, linux-mediatek, LKML, kasan-dev, Linux-MM,
Alexander Potapenko, Andrey Ryabinin, Linux ARM
In-Reply-To: <1589966220.14692.24.camel@mtksdccf07>
On Wed, May 20, 2020 at 11:17 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > > On Wed, 2020-05-20 at 13:14 +0800, Walter Wu wrote:
> > > > > On Wed, May 20, 2020 at 6:03 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > > > > >
> > > > > > > On Tue, May 19, 2020 at 4:25 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > > > > > > >
> > > > > > > > Move free track from slub alloc meta-data to slub free meta-data in
> > > > > > > > order to make struct kasan_free_meta size is 16 bytes. It is a good
> > > > > > > > size because it is the minimal redzone size and a good number of
> > > > > > > > alignment.
> > > > > > > >
> > > > > > > > For free track in generic KASAN, we do the modification in struct
> > > > > > > > kasan_alloc_meta and kasan_free_meta:
> > > > > > > > - remove free track from kasan_alloc_meta.
> > > > > > > > - add free track into kasan_free_meta.
> > > > > > > >
> > > > > > > > [1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
> > > > > > > >
> > > > > > > > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > > > > > > > Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> > > > > > > > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > > > > > > > Cc: Dmitry Vyukov <dvyukov@google.com>
> > > > > > > > Cc: Alexander Potapenko <glider@google.com>
> > > > > > > > ---
> > > > > > > > mm/kasan/common.c | 22 ++--------------------
> > > > > > > > mm/kasan/generic.c | 18 ++++++++++++++++++
> > > > > > > > mm/kasan/kasan.h | 7 +++++++
> > > > > > > > mm/kasan/report.c | 20 --------------------
> > > > > > > > mm/kasan/tags.c | 37 +++++++++++++++++++++++++++++++++++++
> > > > > > > > 5 files changed, 64 insertions(+), 40 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > > > > > > > index 8bc618289bb1..47b53912f322 100644
> > > > > > > > --- a/mm/kasan/common.c
> > > > > > > > +++ b/mm/kasan/common.c
> > > > > > > > @@ -51,7 +51,7 @@ depot_stack_handle_t kasan_save_stack(gfp_t flags)
> > > > > > > > return stack_depot_save(entries, nr_entries, flags);
> > > > > > > > }
> > > > > > > >
> > > > > > > > -static inline void set_track(struct kasan_track *track, gfp_t flags)
> > > > > > > > +void kasan_set_track(struct kasan_track *track, gfp_t flags)
> > > > > > > > {
> > > > > > > > track->pid = current->pid;
> > > > > > > > track->stack = kasan_save_stack(flags);
> > > > > > > > @@ -299,24 +299,6 @@ struct kasan_free_meta *get_free_info(struct kmem_cache *cache,
> > > > > > > > return (void *)object + cache->kasan_info.free_meta_offset;
> > > > > > > > }
> > > > > > > >
> > > > > > > > -
> > > > > > > > -static void kasan_set_free_info(struct kmem_cache *cache,
> > > > > > > > - void *object, u8 tag)
> > > > > > > > -{
> > > > > > > > - struct kasan_alloc_meta *alloc_meta;
> > > > > > > > - u8 idx = 0;
> > > > > > > > -
> > > > > > > > - alloc_meta = get_alloc_info(cache, object);
> > > > > > > > -
> > > > > > > > -#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > > > > > > - idx = alloc_meta->free_track_idx;
> > > > > > > > - alloc_meta->free_pointer_tag[idx] = tag;
> > > > > > > > - alloc_meta->free_track_idx = (idx + 1) % KASAN_NR_FREE_STACKS;
> > > > > > > > -#endif
> > > > > > > > -
> > > > > > > > - set_track(&alloc_meta->free_track[idx], GFP_NOWAIT);
> > > > > > > > -}
> > > > > > > > -
> > > > > > > > void kasan_poison_slab(struct page *page)
> > > > > > > > {
> > > > > > > > unsigned long i;
> > > > > > > > @@ -492,7 +474,7 @@ static void *__kasan_kmalloc(struct kmem_cache *cache, const void *object,
> > > > > > > > KASAN_KMALLOC_REDZONE);
> > > > > > > >
> > > > > > > > if (cache->flags & SLAB_KASAN)
> > > > > > > > - set_track(&get_alloc_info(cache, object)->alloc_track, flags);
> > > > > > > > + kasan_set_track(&get_alloc_info(cache, object)->alloc_track, flags);
> > > > > > > >
> > > > > > > > return set_tag(object, tag);
> > > > > > > > }
> > > > > > > > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> > > > > > > > index 3372bdcaf92a..763d8a13e0ac 100644
> > > > > > > > --- a/mm/kasan/generic.c
> > > > > > > > +++ b/mm/kasan/generic.c
> > > > > > > > @@ -344,3 +344,21 @@ void kasan_record_aux_stack(void *addr)
> > > > > > > > alloc_info->aux_stack[1] = alloc_info->aux_stack[0];
> > > > > > > > alloc_info->aux_stack[0] = kasan_save_stack(GFP_NOWAIT);
> > > > > > > > }
> > > > > > > > +
> > > > > > > > +void kasan_set_free_info(struct kmem_cache *cache,
> > > > > > > > + void *object, u8 tag)
> > > > > > > > +{
> > > > > > > > + struct kasan_free_meta *free_meta;
> > > > > > > > +
> > > > > > > > + free_meta = get_free_info(cache, object);
> > > > > > > > + kasan_set_track(&free_meta->free_track, GFP_NOWAIT);
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > > > > > > + void *object, u8 tag)
> > > > > > > > +{
> > > > > > > > + struct kasan_free_meta *free_meta;
> > > > > > > > +
> > > > > > > > + free_meta = get_free_info(cache, object);
> > > > > > > > + return &free_meta->free_track;
> > > > > > > > +}
> > > > > > > > diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> > > > > > > > index a7391bc83070..ad897ec36545 100644
> > > > > > > > --- a/mm/kasan/kasan.h
> > > > > > > > +++ b/mm/kasan/kasan.h
> > > > > > > > @@ -127,6 +127,9 @@ struct kasan_free_meta {
> > > > > > > > * Otherwise it might be used for the allocator freelist.
> > > > > > > > */
> > > > > > > > struct qlist_node quarantine_link;
> > > > > > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > > > > > + struct kasan_track free_track;
> > > > > > > > +#endif
> > > > > > > > };
> > > > > > > >
> > > > > > > > struct kasan_alloc_meta *get_alloc_info(struct kmem_cache *cache,
> > > > > > > > @@ -168,6 +171,10 @@ void kasan_report_invalid_free(void *object, unsigned long ip);
> > > > > > > > struct page *kasan_addr_to_page(const void *addr);
> > > > > > > >
> > > > > > > > depot_stack_handle_t kasan_save_stack(gfp_t flags);
> > > > > > > > +void kasan_set_track(struct kasan_track *track, gfp_t flags);
> > > > > > > > +void kasan_set_free_info(struct kmem_cache *cache, void *object, u8 tag);
> > > > > > > > +struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > > > > > > + void *object, u8 tag);
> > > > > > > >
> > > > > > > > #if defined(CONFIG_KASAN_GENERIC) && \
> > > > > > > > (defined(CONFIG_SLAB) || defined(CONFIG_SLUB))
> > > > > > > > diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> > > > > > > > index 6f8f2bf8f53b..96d2657fe70f 100644
> > > > > > > > --- a/mm/kasan/report.c
> > > > > > > > +++ b/mm/kasan/report.c
> > > > > > > > @@ -159,26 +159,6 @@ static void describe_object_addr(struct kmem_cache *cache, void *object,
> > > > > > > > (void *)(object_addr + cache->object_size));
> > > > > > > > }
> > > > > > > >
> > > > > > > > -static struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > > > > > > - void *object, u8 tag)
> > > > > > > > -{
> > > > > > > > - struct kasan_alloc_meta *alloc_meta;
> > > > > > > > - int i = 0;
> > > > > > > > -
> > > > > > > > - alloc_meta = get_alloc_info(cache, object);
> > > > > > > > -
> > > > > > > > -#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > > > > > > - for (i = 0; i < KASAN_NR_FREE_STACKS; i++) {
> > > > > > > > - if (alloc_meta->free_pointer_tag[i] == tag)
> > > > > > > > - break;
> > > > > > > > - }
> > > > > > > > - if (i == KASAN_NR_FREE_STACKS)
> > > > > > > > - i = alloc_meta->free_track_idx;
> > > > > > > > -#endif
> > > > > > > > -
> > > > > > > > - return &alloc_meta->free_track[i];
> > > > > > > > -}
> > > > > > > > -
> > > > > > > > #ifdef CONFIG_KASAN_GENERIC
> > > > > > > > static void print_stack(depot_stack_handle_t stack)
> > > > > > > > {
> > > > > > > > diff --git a/mm/kasan/tags.c b/mm/kasan/tags.c
> > > > > > > > index 25b7734e7013..201dee5d6ae0 100644
> > > > > > > > --- a/mm/kasan/tags.c
> > > > > > > > +++ b/mm/kasan/tags.c
> > > > > > > > @@ -162,3 +162,40 @@ void __hwasan_tag_memory(unsigned long addr, u8 tag, unsigned long size)
> > > > > > > > kasan_poison_shadow((void *)addr, size, tag);
> > > > > > > > }
> > > > > > > > EXPORT_SYMBOL(__hwasan_tag_memory);
> > > > > > > > +
> > > > > > > > +void kasan_set_free_info(struct kmem_cache *cache,
> > > > > > > > + void *object, u8 tag)
> > > > > > > > +{
> > > > > > > > + struct kasan_alloc_meta *alloc_meta;
> > > > > > > > + u8 idx = 0;
> > > > > > > > +
> > > > > > > > + alloc_meta = get_alloc_info(cache, object);
> > > > > > > > +
> > > > > > > > +#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > > > > > > + idx = alloc_meta->free_track_idx;
> > > > > > > > + alloc_meta->free_pointer_tag[idx] = tag;
> > > > > > > > + alloc_meta->free_track_idx = (idx + 1) % KASAN_NR_FREE_STACKS;
> > > > > > > > +#endif
> > > > > > > > +
> > > > > > > > + kasan_set_track(&alloc_meta->free_track[idx], GFP_NOWAIT);
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > > > > > > + void *object, u8 tag)
> > > > > > > > +{
> > > > > > > > + struct kasan_alloc_meta *alloc_meta;
> > > > > > > > + int i = 0;
> > > > > > > > +
> > > > > > > > + alloc_meta = get_alloc_info(cache, object);
> > > > > > > > +
> > > > > > > > +#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > > > > > > + for (i = 0; i < KASAN_NR_FREE_STACKS; i++) {
> > > > > > > > + if (alloc_meta->free_pointer_tag[i] == tag)
> > > > > > > > + break;
> > > > > > > > + }
> > > > > > > > + if (i == KASAN_NR_FREE_STACKS)
> > > > > > > > + i = alloc_meta->free_track_idx;
> > > > > > > > +#endif
> > > > > > > > +
> > > > > > > > + return &alloc_meta->free_track[i];
> > > > > > > > +}
> > > > > > >
> > > > > > > Hi Walter,
> > > > > > >
> > > > > > > FTR I've uploaded this for review purposes here:
> > > > > > > https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/2458
> > > > > > >
> > > > > > > Diff from the previous version is available as:
> > > > > > > https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/2458/1..2
> > > > > > >
> > > > > > > I've tested this locally and with syzkaller. This is :
> > > > > > >
> > > > > > > [ 80.583021][ C3] Freed by task 0:
> > > > > > > [ 80.583480][ C3] kasan_save_stack+0x1b/0x40 mm/kasan/common.c:49
> > > > > > > [ 80.584056][ C3] kasan_set_track+0x1c/0x30 mm/kasan/common.c:57
> > > > > > > [ 80.584617][ C3] kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:354
> > > > > > > [ 80.585221][ C3] __kasan_slab_free+0xd8/0x120 mm/kasan/common.c:438
> > > > > > > [ 80.585814][ C3] __cache_free mm/slab.c:3426 [inline]
> > > > > > > [ 80.585814][ C3] kfree+0x10b/0x2b0 mm/slab.c:3757
> > > > > > > [ 80.586291][ C3] kasan_rcu_reclaim+0x16/0x43 [test_kasan]
> > > > > > > [ 80.587009][ C3] rcu_do_batch kernel/rcu/tree.c:2207 [inline]
> > > > > > > [ 80.587009][ C3] rcu_core+0x59f/0x1370 kernel/rcu/tree.c:2434
> > > > > > > [ 80.587537][ C3] __do_softirq+0x26c/0x9fa kernel/softirq.c:292
> > > > > > > [ 80.588085][ C3]
> > > > > > > [ 80.588367][ C3] Last one call_rcu() call stack:
> > > > > > > [ 80.589052][ C3] kasan_save_stack+0x1b/0x40 mm/kasan/common.c:49
> > > > > > > [ 80.589622][ C3] kasan_record_aux_stack+0x82/0xb0 mm/kasan/generic.c:345
> > > > > > > [ 80.590254][ C3] __call_rcu kernel/rcu/tree.c:2672 [inline]
> > > > > > > [ 80.590254][ C3] call_rcu+0x14f/0x7f0 kernel/rcu/tree.c:2746
> > > > > > > [ 80.590782][ C3] kasan_rcu_uaf+0xe4/0xeb [test_kasan]
> > > > > > > [ 80.591697][ C3] kmalloc_tests_init+0xbc/0x1097 [test_kasan]
> > > > > > > [ 80.592900][ C3] do_one_initcall+0x10a/0x7d0 init/main.c:1196
> > > > > > > [ 80.593494][ C3] do_init_module+0x1e6/0x6d0 kernel/module.c:3539
> > > > > > > [ 80.594066][ C3] load_module+0x7464/0x9450 kernel/module.c:3890
> > > > > > > [ 80.594626][ C3] __do_sys_init_module+0x1e3/0x220 kernel/module.c:3953
> > > > > > > [ 80.595265][ C3] do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
> > > > > > > [ 80.595822][ C3] entry_SYSCALL_64_after_hwframe+0x49/0xb3
> > > > > > >
> > > > > > >
> > > > > > > Overall this looks very good to me.
> > > > > > > But there is one aspect that bothers me. In the previous patch you had
> > > > > > > code that returned NULL from kasan_get_free_track() if the object is
> > > > > > > live (which means free meta is not available, it's occupied by object
> > > > > > > data). Now you dropped that code, but I think we still need it.
> > > > > > > Otherwise we cast user object data to free meta and print the free
> > > > > > > stack/pid from whatever garbage is there. This may lead to very
> > > > > > > confusing output and potentially to crashes in stackdepot.
> > > > > > >
> > > > > >
> > > > > > Yes, I totally agree with you. In the previous email I thought that
> > > > > > there is a problem with free track, but I did not point it out. Thank
> > > > > > you for pointing this problem. As you mentioned, we should fix it.
> > > > > >
> > > > > > > What do you think about this patch on top of your patches?
> > > > > > > https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/2478
> > > > > > > This way we very precisely mark the period of time when the object has
> > > > > > > free track live and set.
> > > > > > > If it looks good to you, feel free to incorporate it into your series.
> > > > > > >
> > > > > >
> > > > > > Thank you for providing good idea solution.
> > > > > >
> > > > > > I saw this patch, that is a great patch. I think it can fix the issue
> > > > > > which has garbage stack. it should work as described below.
> > > > > >
> > > > > > 1). When object is live, then don't print free stack.
> > > > > > 2). When object is NOT alive, after free object:
> > > > > > 2a). when object is in quarantine, then it can print free stack
> > > > > > 2b). when object is NOT in quarantine, then it can NOT print free stack.
> > > > > >
> > > > > > I have a question about 2), why we don't directly use
> > > > > > KASAN_KMALLOC_FREE? if we directly use it, then 2b) can print free
> > > > > > stack? 2b) may has use-after-free? so that it may need free stack.
> > > > >
> > >
> > > About 2b), I see another question. When do qlink_free(), it will be
> > > written KASAN_KMALLOC_FREE from KASAN_KMALLOC_FREETRACK? if we don't
> > > write shadow memory, it is still KASAN_KMALLOC_FREETRACK, then 2b) will
> > > have free stack? Because I see you add KASAN_KMALLOC_FREETRACK to get
> > > use-after-free in get_shadow_bug_type(). so should it not write
> > > KASAN_KMALLOC_FREE?
> >
> > It may or may not work.
> > The potential problem is that when qlink_free calls ___cache_free,
> > slab/slub may start using object memory for its own purposes, e.g.
> > store the next link. This next link may overwrite part of free meta.
> > It actually may work because the slab/slib next link is likely to
> > overlap with kasan_free_meta.quarantine_link only. And we may have
> > kasan_free_meta.free_track intact while KASAN_KMALLOC_FREE is set. But
> > this needs careful checking for both slab and slub and if they may use
> > more than 1 word in some configurations.
> >
>
> This problem looks like existing, even without this change? currently
> KASAN may get wrong free stack?
No, we should not have this problem now. Currently free track is
stored in alloc meta. Alloc meta does not overlap with the object.
It's only free meta that overlaps with the object and slab metadata at
different periods of the block lifetime. Schematically what we have
is:
struct block_t {
alloc_meta kasan_alloc_meta;
union {
user_data char[N];
slab_meta slab_meta;
free_meta kasan_free_meta;
};
}
free_meta shared storage space with 2 other things.
> Regardless of whether the shadow memory content is
> KASAN_KMALLOC_FREETRACK or KASAN_KMALLOC_FREE, it may have this problem?
KASAN_KMALLOC_FREETRACK is set only when nobody else uses the storage.
> But because of kasan_get_free_track() have conditions to get free track,
> so that if shadow memory content is KASAN_KMALLOC_FREE, then it will
> avoid this problem and always print right free stack.
> > > > > We can't use KASAN_KMALLOC_FREE because of this part:
> > > > >
> > > > > static bool __kasan_slab_free(struct kmem_cache *cache, void *object,
> > > > > unsigned long ip, bool quarantine)
> > > > > {
> > > > > ...
> > > > > kasan_poison_shadow(object, rounded_up_size, KASAN_KMALLOC_FREE);
> > > > >
> > > > > if ((IS_ENABLED(CONFIG_KASAN_GENERIC) && !quarantine) ||
> > > > > unlikely(!(cache->flags & SLAB_KASAN)))
> > > > > return false;
> > > > >
> > > > > kasan_set_free_info(cache, object, tag);
> > > > > ...
> > > > >
> > > >
> > > > Ok, I see. When return false, then the shadow memory content has
> > > > KASAN_KMALLOC_FREE, but it doesn't set free stack, so that we need to
> > > > avoid this situation. Thank for you reminder.
> > > >
> > > > >
> > > > > We may set KASAN_KMALLOC_FREE, but not set the track (or even have
> > > > > memory for the track!).
> > > > > The object may not have free meta allocated at all, e.g. very large
> > > > > object with ctor (no place to store meta), or it may be in a mempool:
> > > > > https://elixir.bootlin.com/linux/v5.7-rc6/source/mm/mempool.c#L109
> > > > > and mempool may be using the object memory itself (for its own next
> > > > > link or something).
> > > > >
> > > > > KASAN_KMALLOC_FREETRACK very explicitly tracks the exact condition we
> > > > > want: we have meta info live now and we have free track set.
_______________________________________________
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 4/4] arm64: dts: mt6797: Fix mmsys node name
From: Matthias Brugger @ 2020-05-20 10:54 UTC (permalink / raw)
To: Chun-Kuang Hu, matthias.bgg
Cc: Kate Stewart, devicetree, Stephen Boyd, Greg Kroah-Hartman,
Michael Turquette, linux-kernel, Rob Herring,
moderated list:ARM/Mediatek SoC support, Allison Randal, mtk01761,
Thomas Gleixner, linux-clk, Linux ARM
In-Reply-To: <CAAOTY_-Lh=4N2L9ZOrVw+wK1tSrCA=UuOH+7xs0U=12B3Qi7Ug@mail.gmail.com>
On 19/05/2020 17:06, Chun-Kuang Hu wrote:
> Hi, Matthias:
>
> <matthias.bgg@kernel.org> 於 2020年5月18日 週一 下午7:33寫道：
>>
>> From: Matthias Brugger <matthias.bgg@gmail.com>
>>
>> Node names are supposed to match the class of the device. The
>> mmsys node is a syscon as it provides more then just a clock controller.
>> Update the name.
>
> Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
>
Now queued for v5.7-next/dts64
>>
>> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
>>
>> ---
>>
>> arch/arm64/boot/dts/mediatek/mt6797.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt6797.dtsi b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
>> index 136ef9527a0d..3efd032481ce 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt6797.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
>> @@ -233,7 +233,7 @@ uart3: serial@11005000 {
>> status = "disabled";
>> };
>>
>> - mmsys: mmsys_config@14000000 {
>> + mmsys: syscon@14000000 {
>> compatible = "mediatek,mt6797-mmsys", "syscon";
>> reg = <0 0x14000000 0 0x1000>;
>> #clock-cells = <1>;
>> --
>> 2.26.2
>>
>>
>> _______________________________________________
>> Linux-mediatek mailing list
>> Linux-mediatek@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
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 3/4] clk/soc: mediatek: mt6779: Bind clock driver from platform device
From: Matthias Brugger @ 2020-05-20 10:54 UTC (permalink / raw)
To: Stephen Boyd, Michael Turquette, Rob Herring, matthias.bgg
Cc: Kate Stewart, devicetree, Greg Kroah-Hartman, linux-kernel,
linux-mediatek, linux-arm-kernel, mtk01761, Thomas Gleixner,
linux-clk, Allison Randal
In-Reply-To: <158996971719.215346.12802870863066637932@swboyd.mtv.corp.google.com>
On 20/05/2020 12:15, Stephen Boyd wrote:
> Quoting matthias.bgg@kernel.org (2020-05-18 04:31:55)
>> From: Matthias Brugger <matthias.bgg@gmail.com>
>>
>> The mmsys driver is now the top level entry point for the multimedia
>> system (mmsys), we bind the clock driver by creating a platform device.
>> We also bind the MediaTek DRM driver which is not yet implement and
>> therefor will errror out for now.
>>
>> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
>> ---
>
> Acked-by: Stephen Boyd <sboyd@kernel.org>
>
Now queued for v5.7-next/soc
_______________________________________________
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 1/4] clk/soc: mediatek: mt8183: Bind clock driver from platform device
From: Matthias Brugger @ 2020-05-20 10:53 UTC (permalink / raw)
To: Stephen Boyd, Michael Turquette, Rob Herring, matthias.bgg
Cc: Kate Stewart, devicetree, Greg Kroah-Hartman, linux-kernel,
linux-mediatek, linux-arm-kernel, mtk01761, Thomas Gleixner,
linux-clk, Allison Randal
In-Reply-To: <158996969738.215346.5933135216459465754@swboyd.mtv.corp.google.com>
On 20/05/2020 12:14, Stephen Boyd wrote:
> Quoting matthias.bgg@kernel.org (2020-05-18 04:31:53)
>> From: Matthias Brugger <matthias.bgg@gmail.com>
>>
>> The mmsys driver is now the top level entry point for the multimedia
>> system (mmsys), we bind the clock driver by creating a platform device.
>> We also bind the MediaTek DRM driver which is not yet implement and
>> therefor will errror out for now.
>>
>> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
>> ---
>
> Acked-by: Stephen Boyd <sboyd@kernel.org>
>
Now queued for v5.7-next/soc
_______________________________________________
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