* Re: [PATCH 3/3] arm64: allwinner: dts: h6: add Wi-Fi support for Pine H64 model A/B
From: Chen-Yu Tsai @ 2018-07-24 2:21 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Maxime Ripard, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <20180724011551.49603-4-icenowy-h8G6r0blFSE@public.gmane.org>
On Tue, Jul 24, 2018 at 9:15 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> The Pine H64 model A has a Wi-Fi module connector and the model B has an
> on-board RTL8723BS Wi-Fi module.
>
> Add support for them. For model A, as it's not defaultly present, keep
> it disabled now.
Nope. Pine64 actually has two WiFi/BT modules. And they require different
device tree snippets for both the WiFi and BT side. This is better resolved
with device tree overlays.
I have both, though I've yet found time to work on them.
ChenYu
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> .../allwinner/sun50i-h6-pine-h64-model-b.dts | 8 +++++
> .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 29 +++++++++++++++++++
> 2 files changed, 37 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> index d0fcc25efb00..d0f775613c9b 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> @@ -18,3 +18,11 @@
> };
> };
> };
> +
> +&mmc1 {
> + status = "okay";
> +};
> +
> +&wifi_pwrseq {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> index a85867f8b684..75db6d4139bf 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> @@ -40,6 +40,12 @@
> gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
> };
> };
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PL2 */
> + status = "disabled";
> + };
> };
>
> &mmc0 {
> @@ -50,6 +56,17 @@
> status = "okay";
> };
>
> +&mmc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
> + vmmc-supply = <®_cldo2>;
> + vqmmc-supply = <®_bldo2>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "disabled";
> +};
> +
> &mmc2 {
> pinctrl-names = "default";
> pinctrl-0 = <&mmc2_pins>;
> @@ -128,12 +145,24 @@
> };
>
> reg_cldo2: cldo2 {
> + /*
> + * This regulator is connected with CLDO3.
> + * Before the kernel can support synchronized
> + * enable of coupled regulators, keep them
> + * both always on as a ugly hack.
> + */
> + regulator-always-on;
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
> regulator-name = "vcc-wifi-1";
> };
>
> reg_cldo3: cldo3 {
> + /*
> + * This regulator is connected with CLDO2.
> + * See the comments for CLDO2.
> + */
> + regulator-always-on;
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
> regulator-name = "vcc-wifi-2";
> --
> 2.18.0
>
^ permalink raw reply
* [PATCH 3/3] arm64: allwinner: dts: h6: add Wi-Fi support for Pine H64 model A/B
From: Chen-Yu Tsai @ 2018-07-24 2:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180724011551.49603-4-icenowy@aosc.io>
On Tue, Jul 24, 2018 at 9:15 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> The Pine H64 model A has a Wi-Fi module connector and the model B has an
> on-board RTL8723BS Wi-Fi module.
>
> Add support for them. For model A, as it's not defaultly present, keep
> it disabled now.
Nope. Pine64 actually has two WiFi/BT modules. And they require different
device tree snippets for both the WiFi and BT side. This is better resolved
with device tree overlays.
I have both, though I've yet found time to work on them.
ChenYu
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> .../allwinner/sun50i-h6-pine-h64-model-b.dts | 8 +++++
> .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 29 +++++++++++++++++++
> 2 files changed, 37 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> index d0fcc25efb00..d0f775613c9b 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> @@ -18,3 +18,11 @@
> };
> };
> };
> +
> +&mmc1 {
> + status = "okay";
> +};
> +
> +&wifi_pwrseq {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> index a85867f8b684..75db6d4139bf 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> @@ -40,6 +40,12 @@
> gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
> };
> };
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PL2 */
> + status = "disabled";
> + };
> };
>
> &mmc0 {
> @@ -50,6 +56,17 @@
> status = "okay";
> };
>
> +&mmc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
> + vmmc-supply = <®_cldo2>;
> + vqmmc-supply = <®_bldo2>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "disabled";
> +};
> +
> &mmc2 {
> pinctrl-names = "default";
> pinctrl-0 = <&mmc2_pins>;
> @@ -128,12 +145,24 @@
> };
>
> reg_cldo2: cldo2 {
> + /*
> + * This regulator is connected with CLDO3.
> + * Before the kernel can support synchronized
> + * enable of coupled regulators, keep them
> + * both always on as a ugly hack.
> + */
> + regulator-always-on;
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
> regulator-name = "vcc-wifi-1";
> };
>
> reg_cldo3: cldo3 {
> + /*
> + * This regulator is connected with CLDO2.
> + * See the comments for CLDO2.
> + */
> + regulator-always-on;
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
> regulator-name = "vcc-wifi-2";
> --
> 2.18.0
>
^ permalink raw reply
* Re: [PATCH] nios2: use generic dma_noncoherent_ops
From: Ley Foon Tan @ 2018-07-24 2:21 UTC (permalink / raw)
To: Christoph Hellwig
Cc: nios2-dev-g9ZBwUv/Ih/yUk5EbOjzuce+I+R0W71w,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
In-Reply-To: <20180723082717.GA19548-jcswGhMUV9g@public.gmane.org>
On Mon, 2018-07-23 at 10:27 +0200, Christoph Hellwig wrote:
> On Mon, Jul 23, 2018 at 04:20:42PM +0800, Ley Foon Tan wrote:
> >
> > On Thu, 2018-07-19 at 14:22 +0200, Christoph Hellwig wrote:
> > >
> > > On Thu, Jul 19, 2018 at 01:48:55PM +0800, Ley Foon Tan wrote:
> > > >
> > > >
> > > > Do you have git repo for this series of patches?
> > > This patch should apply without the need for any other patch
> > > to Linus' latest tree, but I have a tree with all the conversions
> > > here:
> > >
> > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/hea
> > > ds/g
> > > eneric-dma-noncoherent.3
> > Hi
> >
> > Compilation, system bootup and Ethernet are working fine with this
> > patch.
> Do you want to merge it through the nios tree or should I pick it up?
Hi
Please pick it up with your git tree.
Thanks.
Regards
Ley Foon
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* Re: [PATCH v2 2/2] PCI: NVMe device specific reset quirk
From: Sinan Kaya @ 2018-07-24 2:20 UTC (permalink / raw)
To: Alex Williamson; +Cc: linux-pci, linux-kernel, linux-nvme
In-Reply-To: <20180723195711.0a3c9301@t450s.home>
On 7/23/18, Alex Williamson <alex.williamson@redhat.com> wrote:
> On Mon, 23 Jul 2018 17:40:02 -0700
> Sinan Kaya <okaya@kernel.org> wrote:
>
>> On 7/23/2018 5:13 PM, Alex Williamson wrote:
>> > + * The NVMe specification requires that controllers support PCIe FLR,
>> > but
>> > + * but some Samsung SM961/PM961 controllers fail to recover after FLR
>> > (-1
>> > + * config space) unless the device is quiesced prior to FLR.
>>
>> Does disabling the memory bit in PCI config space as part of the FLR
>> reset function help? (like the very first thing)
>
> No, it does not. I modified this to only clear PCI_COMMAND_MEMORY and
> call pcie_flr(), the Samsung controller dies just as it did previously.
>
>> Can we do that in the pcie_flr() function to cover other endpoint types
>> that might be pushing traffic while code is trying to do a reset?
>
> Do you mean PCI_COMMAND_MASTER rather than PCI_COMMAND_MEMORY?
Yes
> I tried
> that too, it doesn't work either. I'm not really sure the theory
> behind clearing memory, clearing busmaster to stop DMA seems like a
> sane thing to do, but doesn't help here.
Let me explain what I guessed. You might be able to fill in the blanks
where I am completely off.
We do vfio initiated flr reset immediately following guest machine
shutdown. The card could be fully enabled and pushing traffic to the
system at this moment.
I don't know if vfio does any device disable or not.
FLR is supposed to reset the endpoint but endpoint doesn't recover per
your report.
Having vendor specific reset routines for PCIE endpoints defeats the
purpose of FLR.
Since the adapter is fully functional, i suggested turning off bus
master and memory enable bits to stop endpoint from sending packets.
But, this is not helping either.
Those sleep statements looked very fragile to be honest.
I was curious if there is something else that we could do for other endpoints.
No objections otherwise.
>
> Alex
>
^ permalink raw reply
* Re: [PATCH v2 2/2] PCI: NVMe device specific reset quirk
From: Sinan Kaya @ 2018-07-24 2:20 UTC (permalink / raw)
To: Alex Williamson; +Cc: linux-pci, linux-kernel, linux-nvme
In-Reply-To: <20180723195711.0a3c9301@t450s.home>
On 7/23/18, Alex Williamson <alex.williamson@redhat.com> wrote:
> On Mon, 23 Jul 2018 17:40:02 -0700
> Sinan Kaya <okaya@kernel.org> wrote:
>
>> On 7/23/2018 5:13 PM, Alex Williamson wrote:
>> > + * The NVMe specification requires that controllers support PCIe FLR,
>> > but
>> > + * but some Samsung SM961/PM961 controllers fail to recover after FLR
>> > (-1
>> > + * config space) unless the device is quiesced prior to FLR.
>>
>> Does disabling the memory bit in PCI config space as part of the FLR
>> reset function help? (like the very first thing)
>
> No, it does not. I modified this to only clear PCI_COMMAND_MEMORY and
> call pcie_flr(), the Samsung controller dies just as it did previously.
>
>> Can we do that in the pcie_flr() function to cover other endpoint types
>> that might be pushing traffic while code is trying to do a reset?
>
> Do you mean PCI_COMMAND_MASTER rather than PCI_COMMAND_MEMORY?
Yes
> I tried
> that too, it doesn't work either. I'm not really sure the theory
> behind clearing memory, clearing busmaster to stop DMA seems like a
> sane thing to do, but doesn't help here.
Let me explain what I guessed. You might be able to fill in the blanks
where I am completely off.
We do vfio initiated flr reset immediately following guest machine
shutdown. The card could be fully enabled and pushing traffic to the
system at this moment.
I don't know if vfio does any device disable or not.
FLR is supposed to reset the endpoint but endpoint doesn't recover per
your report.
Having vendor specific reset routines for PCIE endpoints defeats the
purpose of FLR.
Since the adapter is fully functional, i suggested turning off bus
master and memory enable bits to stop endpoint from sending packets.
But, this is not helping either.
Those sleep statements looked very fragile to be honest.
I was curious if there is something else that we could do for other endpoints.
No objections otherwise.
>
> Alex
>
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* [PATCH v2 2/2] PCI: NVMe device specific reset quirk
From: Sinan Kaya @ 2018-07-24 2:20 UTC (permalink / raw)
In-Reply-To: <20180723195711.0a3c9301@t450s.home>
On 7/23/18, Alex Williamson <alex.williamson@redhat.com> wrote:
> On Mon, 23 Jul 2018 17:40:02 -0700
> Sinan Kaya <okaya@kernel.org> wrote:
>
>> On 7/23/2018 5:13 PM, Alex Williamson wrote:
>> > + * The NVMe specification requires that controllers support PCIe FLR,
>> > but
>> > + * but some Samsung SM961/PM961 controllers fail to recover after FLR
>> > (-1
>> > + * config space) unless the device is quiesced prior to FLR.
>>
>> Does disabling the memory bit in PCI config space as part of the FLR
>> reset function help? (like the very first thing)
>
> No, it does not. I modified this to only clear PCI_COMMAND_MEMORY and
> call pcie_flr(), the Samsung controller dies just as it did previously.
>
>> Can we do that in the pcie_flr() function to cover other endpoint types
>> that might be pushing traffic while code is trying to do a reset?
>
> Do you mean PCI_COMMAND_MASTER rather than PCI_COMMAND_MEMORY?
Yes
> I tried
> that too, it doesn't work either. I'm not really sure the theory
> behind clearing memory, clearing busmaster to stop DMA seems like a
> sane thing to do, but doesn't help here.
Let me explain what I guessed. You might be able to fill in the blanks
where I am completely off.
We do vfio initiated flr reset immediately following guest machine
shutdown. The card could be fully enabled and pushing traffic to the
system at this moment.
I don't know if vfio does any device disable or not.
FLR is supposed to reset the endpoint but endpoint doesn't recover per
your report.
Having vendor specific reset routines for PCIE endpoints defeats the
purpose of FLR.
Since the adapter is fully functional, i suggested turning off bus
master and memory enable bits to stop endpoint from sending packets.
But, this is not helping either.
Those sleep statements looked very fragile to be honest.
I was curious if there is something else that we could do for other endpoints.
No objections otherwise.
>
> Alex
>
^ permalink raw reply
* [RELEASE] LTTng-Tools 2.10.5 - KeKriek
From: Jérémie Galarneau @ 2018-07-24 2:18 UTC (permalink / raw)
To: lttng-dev
Hi all,
The fifth bug-fix release of LTTng-Tools 2.10 - KeKriek has just been
released. This release addresses a number of issues listed below.
2018-07-23 lttng-tools 2.10.5 (National Vanilla Ice Cream Day)
* Fix: missing context enum values in session xml schema
* Tests: add session auto-loading test cases
* Bash completion: ignore namespace for xmllint parsing
* Typo in ust consumer log message (channek -> channel)
* Fix: use signed variable for refcounting of consumer_relayd_sock_pair
* Fix: warning due to hash_key_str() being not const-correct
* Print consumerd32/64/kernel configuration
* Fix: calling ht_{hash, match}_enum with wrong argument
* Fix: probes should be compared strictly by events metadata
* Fix: test_ust-dl is generated at configure-time
* Fix: cmd line options overwrite env variable config options
* Fix: perform the initialization memory barrier out of loop body
* Port: fix format warnings on Cygwin
* Add missing include for ssize_t on Cygwin
* Fix: sessions with agent channels fail to load
* Fix: don't wait for the load thread before serving client commands
* Fix: sessiond fails to launch on --without-ust configuration
* Fix: agent thread poll set creation failure results in deadlock
* Fix: test uses sizeof() on the wrong operand of strncpy
* Fix: ret may be used uninitialized in sample_channel_positions()
As always, please report any issue you may encounter to bugs.lttng.org
or on this mailing list.
Project website: https://lttng.org
Download link:
https://lttng.org/files/lttng-tools/lttng-tools-2.10.5.tar.bz2
GPG sig:
https://lttng.org/files/lttng-tools/lttng-tools-2.10.5.tar.bz2.asc
--
Jérémie Galarneau
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
^ permalink raw reply
* [RELEASE] LTTng-Tools 2.9.10 - Joannès
From: Jérémie Galarneau @ 2018-07-24 2:18 UTC (permalink / raw)
To: lttng-dev
Hi all,
The tenth bug-fix release of LTTng-Tools 2.9 - Joannès has just been
released. This release addresses a number of issues listed below.
2018-07-23 lttng-tools 2.9.10 (National Vanilla Ice Cream Day)
* Fix: missing context enum values in session xml schema
* Tests: add session auto-loading test cases
* Bash completion: ignore namespace for xmllint parsing
* Typo in ust consumer log message (channek -> channel)
* Fix: use signed variable for refcounting of consumer_relayd_sock_pair
* Fix: warning due to hash_key_str() being not const-correct
* Fix: calling ht_{hash, match}_enum with wrong argument
* Fix: probes should be compared strictly by events metadata
* Fix: test_ust-dl is generated at configure-time
* Fix: perform the initialization memory barrier out of loop body
* Port: fix format warnings on Cygwin
* Fix: don't wait for the load thread before serving client commands
* Fix: sessiond fails to launch on --without-ust configuration
* Fix: agent thread poll set creation failure results in deadlock
* Fix: test uses sizeof() on the wrong operand of strncpy
As always, please report any issue you may encounter to bugs.lttng.org
or on this mailing list.
Project website: https://lttng.org
Download link:
https://lttng.org/files/lttng-tools/lttng-tools-2.9.10.tar.bz2
GPG sig:
https://lttng.org/files/lttng-tools/lttng-tools-2.9.10.tar.bz2.asc
--
Jérémie Galarneau
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
^ permalink raw reply
* RE: [PATCH v6 0/5] add mailbox support for i.MX7D
From: A.s. Dong @ 2018-07-24 2:18 UTC (permalink / raw)
To: Jassi Brar, Oleksij Rempel
Cc: Mark Rutland, devicetree@vger.kernel.org, Vladimir Zapolskiy,
Rob Herring, dl-linux-imx, kernel@pengutronix.de, Fabio Estevam,
Shawn Guo, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CABb+yY1r=Sg64t3j45XXSJu-_HYx2Uya0WLDHP82stiQ4vnM5A@mail.gmail.com>
> -----Original Message-----
> From: Jassi Brar [mailto:jassisinghbrar@gmail.com]
> Sent: Monday, July 23, 2018 11:33 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: Oleksij Rempel <o.rempel@pengutronix.de>; kernel@pengutronix.de;
> linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; dl-linux-
> imx <linux-imx@nxp.com>; Shawn Guo <shawnguo@kernel.org>; Fabio
> Estevam <fabio.estevam@nxp.com>; Rob Herring <robh+dt@kernel.org>;
> Mark Rutland <mark.rutland@arm.com>; Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com>
> Subject: Re: [PATCH v6 0/5] add mailbox support for i.MX7D
>
> On Sun, Jul 22, 2018 at 4:14 PM, A.s. Dong <aisheng.dong@nxp.com> wrote:
> > Hi Oleksij,
> >
> > Thanks for the work.
> >
> > Hi Jassi,
> > Do you think if we can have your tag and let those patches go through
> > Shawn's tree as the later QXP support patches depends on them?
> >
> Hmm... I don't find the 5 patches in my mailbox. Are you sure I was CC'ed?
I guess you are missed to be CC'ed.
Oleksij,
As there're some new review comments and may need a small change,
please do not miss to CC Jassi (Mailbox Maintainer) in the next version
of your patch series.
Regards
Dong Aisheng
>
> Dong Aisheng (2):
> dt-bindings: mailbox: allow mbox-cells to be equal to 0
> dt-bindings: arm: fsl: add mu binding doc
>
> Oleksij Rempel (3):
> dt-bindings: mailbox: imx-mu: add generic MU channel support
> ARM: dts: imx7s: add i.MX7 messaging unit support
> mailbox: Add support for i.MX7D messaging unit
^ permalink raw reply
* [PATCH v6 0/5] add mailbox support for i.MX7D
From: A.s. Dong @ 2018-07-24 2:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABb+yY1r=Sg64t3j45XXSJu-_HYx2Uya0WLDHP82stiQ4vnM5A@mail.gmail.com>
> -----Original Message-----
> From: Jassi Brar [mailto:jassisinghbrar at gmail.com]
> Sent: Monday, July 23, 2018 11:33 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: Oleksij Rempel <o.rempel@pengutronix.de>; kernel at pengutronix.de;
> linux-arm-kernel at lists.infradead.org; devicetree at vger.kernel.org; dl-linux-
> imx <linux-imx@nxp.com>; Shawn Guo <shawnguo@kernel.org>; Fabio
> Estevam <fabio.estevam@nxp.com>; Rob Herring <robh+dt@kernel.org>;
> Mark Rutland <mark.rutland@arm.com>; Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com>
> Subject: Re: [PATCH v6 0/5] add mailbox support for i.MX7D
>
> On Sun, Jul 22, 2018 at 4:14 PM, A.s. Dong <aisheng.dong@nxp.com> wrote:
> > Hi Oleksij,
> >
> > Thanks for the work.
> >
> > Hi Jassi,
> > Do you think if we can have your tag and let those patches go through
> > Shawn's tree as the later QXP support patches depends on them?
> >
> Hmm... I don't find the 5 patches in my mailbox. Are you sure I was CC'ed?
I guess you are missed to be CC'ed.
Oleksij,
As there're some new review comments and may need a small change,
please do not miss to CC Jassi (Mailbox Maintainer) in the next version
of your patch series.
Regards
Dong Aisheng
>
> Dong Aisheng (2):
> dt-bindings: mailbox: allow mbox-cells to be equal to 0
> dt-bindings: arm: fsl: add mu binding doc
>
> Oleksij Rempel (3):
> dt-bindings: mailbox: imx-mu: add generic MU channel support
> ARM: dts: imx7s: add i.MX7 messaging unit support
> mailbox: Add support for i.MX7D messaging unit
^ permalink raw reply
* RE: [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
From: A.s. Dong @ 2018-07-24 2:13 UTC (permalink / raw)
To: Vladimir Zapolskiy, Oleksij Rempel, Shawn Guo, Fabio Estevam,
Rob Herring, Mark Rutland, Vladimir Zapolskiy
Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
kernel@pengutronix.de, dl-linux-imx
In-Reply-To: <846bb908-f75e-1988-8f30-e49a537c7969@mleia.com>
> -----Original Message-----
> From: Vladimir Zapolskiy [mailto:vz@mleia.com]
> Sent: Tuesday, July 24, 2018 7:31 AM
> To: Oleksij Rempel <o.rempel@pengutronix.de>; Shawn Guo
> <shawnguo@kernel.org>; Fabio Estevam <fabio.estevam@nxp.com>; Rob
> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; A.s.
> Dong <aisheng.dong@nxp.com>; Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com>
> Cc: kernel@pengutronix.de; linux-arm-kernel@lists.infradead.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
>
> Hi Oleksij,
>
> On 07/22/2018 09:39 AM, Oleksij Rempel wrote:
> > The Mailbox controller is able to send messages (up to 4 32 bit words)
> > between the endpoints.
> >
> > This driver was tested using the mailbox-test driver sending messages
> > between the Cortex-A7 and the Cortex-M4.
> >
> > Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>
> [snip]
>
> > +static int imx_mu_startup(struct mbox_chan *chan) {
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + int ret;
> > +
> > + cp->irq_desc = devm_kasprintf(priv->dev, GFP_KERNEL,
> "imx_mu_chan[%i]",
> > + cp->idx);
> > + if (!cp->irq_desc)
> > + return -ENOMEM;
> > +
>
> Again I would suggest to move this allocation to the loop in .probe function.
>
> [snip]
>
+1
Good point.
> > +
> > + for (i = 0; i < IMX_MU_CHANS; i++) {
> > + struct imx_mu_con_priv *cp = &priv->con_priv[i];
> > +
> > + cp->idx = i;
> > + cp->irq = irq;
>
> ^^^^ right over here.
>
> > + priv->mbox_chans[i].con_priv = cp;
> > + }
> > +
>
> please feel free to add my technical side review tag to the next version:
>
> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
>
> FWIW I find that review comments from Lucas are pretty valid, I would
> recommend to incorporate them.
+1
Regards
Dong Aisheng
>
> --
> Best wishes,
> Vladimir
^ permalink raw reply
* [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
From: A.s. Dong @ 2018-07-24 2:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <846bb908-f75e-1988-8f30-e49a537c7969@mleia.com>
> -----Original Message-----
> From: Vladimir Zapolskiy [mailto:vz at mleia.com]
> Sent: Tuesday, July 24, 2018 7:31 AM
> To: Oleksij Rempel <o.rempel@pengutronix.de>; Shawn Guo
> <shawnguo@kernel.org>; Fabio Estevam <fabio.estevam@nxp.com>; Rob
> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; A.s.
> Dong <aisheng.dong@nxp.com>; Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com>
> Cc: kernel at pengutronix.de; linux-arm-kernel at lists.infradead.org;
> devicetree at vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
>
> Hi Oleksij,
>
> On 07/22/2018 09:39 AM, Oleksij Rempel wrote:
> > The Mailbox controller is able to send messages (up to 4 32 bit words)
> > between the endpoints.
> >
> > This driver was tested using the mailbox-test driver sending messages
> > between the Cortex-A7 and the Cortex-M4.
> >
> > Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>
> [snip]
>
> > +static int imx_mu_startup(struct mbox_chan *chan) {
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + int ret;
> > +
> > + cp->irq_desc = devm_kasprintf(priv->dev, GFP_KERNEL,
> "imx_mu_chan[%i]",
> > + cp->idx);
> > + if (!cp->irq_desc)
> > + return -ENOMEM;
> > +
>
> Again I would suggest to move this allocation to the loop in .probe function.
>
> [snip]
>
+1
Good point.
> > +
> > + for (i = 0; i < IMX_MU_CHANS; i++) {
> > + struct imx_mu_con_priv *cp = &priv->con_priv[i];
> > +
> > + cp->idx = i;
> > + cp->irq = irq;
>
> ^^^^ right over here.
>
> > + priv->mbox_chans[i].con_priv = cp;
> > + }
> > +
>
> please feel free to add my technical side review tag to the next version:
>
> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
>
> FWIW I find that review comments from Lucas are pretty valid, I would
> recommend to incorporate them.
+1
Regards
Dong Aisheng
>
> --
> Best wishes,
> Vladimir
^ permalink raw reply
* [PATCH] init/Kconfig: fix its typos
From: Randy Dunlap @ 2018-07-24 2:11 UTC (permalink / raw)
To: LKML, Andrew Morton, Masahiro Yamada, Thomas Gleixner,
Ingo Molnar
From: Randy Dunlap <rdunlap@infradead.org>
Correct typos of "it's" to "its.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
init/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20180723.orig/init/Kconfig
+++ linux-next-20180723/init/Kconfig
@@ -428,7 +428,7 @@ config BSD_PROCESS_ACCT_V3
help
If you say Y here, the process accounting information is written
in a new file format that also logs the process IDs of each
- process and it's parent. Note that this file format is incompatible
+ process and its parent. Note that this file format is incompatible
with previous v0/v1/v2 file formats, so you will need updated tools
for processing it. A preliminary version of these tools is available
at <http://www.gnu.org/software/acct/>.
@@ -1684,7 +1684,7 @@ config MMAP_ALLOW_UNINITIALIZED
default n
help
Normally, and according to the Linux spec, anonymous memory obtained
- from mmap() has it's contents cleared before it is passed to
+ from mmap() has its contents cleared before it is passed to
userspace. Enabling this config option allows you to request that
mmap() skip that if it is given an MAP_UNINITIALIZED flag, thus
providing a huge performance boost. If this option is not enabled,
^ permalink raw reply
* Re: [PATCH] fsck.f2fs: rebuild qf_ino if quota node is corrupted
From: Sheng Yong @ 2018-07-24 2:11 UTC (permalink / raw)
To: Jaegeuk Kim; +Cc: hyojun, linux-f2fs-devel, miaoxie
In-Reply-To: <20180723124921.GC19644@jaegeuk-macbookpro.roam.corp.google.com>
Hi, Jaegeuk
On 2018/7/23 20:49, Jaegeuk Kim wrote:
> On 07/23, Sheng Yong wrote:
>> If a quota node is corrupted, it may be removed. But its qf_ino in
>> super blocks is not cleared. To keep quota feature available, let's
>> try to rebuild a new quota node.
>
> Hi Sheng,
>
> IIRC, we need to rebuild whole quota structures, no?
>
I'm afraid not. Fsck records all dquot entries to a dict during checking all files.
If a quota file is removed or quota content is corrupted, quota_write_inode (in
fsck_chk_quota_files) will rebuild quota structures for us according to data recorded
in the dict. We only have to make sure the inode of a quota file is correct.
In the scenario where a quota file is removed, I think, rebuilding the inode of the
unreachable quota file is enough. Am I missing something?
thanks,
Sheng
> Thanks,
>
>>
>> Signed-off-by: Sheng Yong <shengyong1@huawei.com>
>> ---
>> fsck/fsck.c | 82 +++++++++++++++++++++++++++++++++++++++++++++++++---
>> fsck/fsck.h | 1 +
>> fsck/mount.c | 7 +++--
>> 3 files changed, 84 insertions(+), 6 deletions(-)
>>
>> diff --git a/fsck/fsck.c b/fsck/fsck.c
>> index e95dedf..dd10182 100644
>> --- a/fsck/fsck.c
>> +++ b/fsck/fsck.c
>> @@ -10,6 +10,7 @@
>> */
>> #include "fsck.h"
>> #include "quotaio.h"
>> +#include "quotaio_v2.h"
>> #include <time.h>
>>
>> char *tree_mark;
>> @@ -1697,13 +1698,80 @@ int fsck_chk_quota_node(struct f2fs_sb_info *sbi)
>> }
>> ret = fsck_chk_node_blk(sbi, NULL, ino,
>> F2FS_FT_REG_FILE, TYPE_INODE, &blk_cnt, NULL);
>> - if (ret)
>> - ASSERT_MSG("wrong quota inode, qtype [%d] ino [0x%x]",
>> - qtype, ino);
>> + if (ret) {
>> + /* sanity_check_nid failed, node should be removed */
>> + ASSERT_MSG("[0x%x] wrong quota inode", ino);
>> + if (c.fix_on)
>> + F2FS_FSCK(sbi)->corrupt_quotas = 1 << qtype;
>> + }
>> }
>> return ret;
>> }
>>
>> +static nid_t prepare_rebuild_qf_inode(struct f2fs_sb_info *sbi, int qtype)
>> +{
>> + struct f2fs_checkpoint *cp = F2FS_CKPT(sbi);
>> + struct f2fs_summary sum;
>> + struct f2fs_node *qf_node;
>> + nid_t nid = QUOTA_INO(F2FS_RAW_SUPER(sbi), qtype);
>> + block_t node_blkaddr;
>> + int ret;
>> +
>> + DBG(1, "Rebuild Quota file (qtype [%3d] ino [0x%x])\n", qtype, nid);
>> +
>> + qf_node = calloc(F2FS_BLKSIZE, 1);
>> + if (!qf_node) {
>> + MSG(0, "\tError: calloc failed for qf_inode!!!\n");
>> + return 0;
>> + }
>> +
>> + /* prepare qf_node */
>> + qf_node->footer.nid = cpu_to_le32(nid);
>> + qf_node->footer.ino = cpu_to_le32(nid);
>> + qf_node->footer.cp_ver = cpu_to_le64(get_cp(checkpoint_ver));
>> +
>> + qf_node->i.i_mode = cpu_to_le16(0x8180);
>> + qf_node->i.i_links = cpu_to_le32(1);
>> + qf_node->i.i_uid = cpu_to_le32(getuid());
>> + qf_node->i.i_gid = cpu_to_le32(getgid());
>> + qf_node->i.i_size = 0;
>> + qf_node->i.i_blocks = 1;
>> + qf_node->i.i_atime = cpu_to_le32(time(NULL));
>> + qf_node->i.i_atime_nsec = 0;
>> + qf_node->i.i_ctime = cpu_to_le32(time(NULL));
>> + qf_node->i.i_ctime_nsec = 0;
>> + qf_node->i.i_mtime = cpu_to_le32(time(NULL));
>> + qf_node->i.i_mtime_nsec = 0;
>> + qf_node->i.i_generation = 0;
>> + qf_node->i.i_xattr_nid = 0;
>> + qf_node->i.i_flags = FS_IMMUTABLE_FL;
>> + qf_node->i.i_current_depth = cpu_to_le32(1);
>> + qf_node->i.i_dir_level = DEF_DIR_LEVEL;
>> + if (c.feature & cpu_to_le32(F2FS_FEATURE_EXTRA_ATTR)) {
>> + qf_node->i.i_inline = F2FS_EXTRA_ATTR;
>> + qf_node->i.i_extra_isize =
>> + cpu_to_le16(F2FS_TOTAL_EXTRA_ATTR_SIZE);
>> + }
>> + if (c.feature & cpu_to_le32(F2FS_FEATURE_INODE_CRTIME)) {
>> + qf_node->i.i_crtime = cpu_to_le32(time(NULL));
>> + qf_node->i.i_crtime_nsec = 0;
>> + }
>> +
>> + /* write back qf inode */
>> + node_blkaddr = 0;
>> + set_summary(&sum, nid, 0, 0);
>> + reserve_new_block(sbi, &node_blkaddr, &sum, CURSEG_HOT_NODE);
>> + update_nat_blkaddr(sbi, nid, nid, node_blkaddr);
>> + DBG(1, "Write new qf_node to blk %#x\n", node_blkaddr);
>> +
>> + ret = dev_write_block(qf_node, node_blkaddr);
Ah.. It should be write_inode instead of dev_write_block.
>> + ASSERT(ret >= 0);
>> + f2fs_clear_bit(nid, F2FS_FSCK(sbi)->nat_area_bitmap);
>> +
>> + free(qf_node);
>> + return nid;
>> +}
>> +
>> int fsck_chk_quota_files(struct f2fs_sb_info *sbi)
>> {
>> struct f2fs_fsck *fsck = F2FS_FSCK(sbi);
>> @@ -1722,6 +1790,12 @@ int fsck_chk_quota_files(struct f2fs_sb_info *sbi)
>> if (!ino)
>> continue;
>>
>> + if (fsck->corrupt_quotas & (1 << qtype) && c.fix_on) {
>> + ino = prepare_rebuild_qf_inode(sbi, qtype);
>> + if (!ino)
>> + continue;
>> + }
>> +
>> DBG(1, "Checking Quota file ([%3d] ino [0x%x])\n", qtype, ino);
>> needs_writeout = 0;
>> ret = quota_compare_and_update(sbi, qtype, &needs_writeout,
>> @@ -1733,7 +1807,7 @@ int fsck_chk_quota_files(struct f2fs_sb_info *sbi)
>>
>> /* Something is wrong */
>> if (c.fix_on) {
>> - DBG(0, "Fixing Quota file ([%3d] ino [0x%x])\n",
>> + FIX_MSG("Fixing Quota file ([%3d] ino [0x%x])\n",
>> qtype, ino);
>> f2fs_filesize_update(sbi, ino, 0);
>> ret = quota_write_inode(sbi, qtype);
>> diff --git a/fsck/fsck.h b/fsck/fsck.h
>> index 580e851..393c995 100644
>> --- a/fsck/fsck.h
>> +++ b/fsck/fsck.h
>> @@ -91,6 +91,7 @@ struct f2fs_fsck {
>> u32 nat_valid_inode_cnt;
>>
>> struct quota_ctx *qctx;
>> + unsigned short corrupt_quotas;
>> };
>>
>> #define BLOCK_SZ 4096
>> diff --git a/fsck/mount.c b/fsck/mount.c
>> index 3c9607f..121b26a 100644
>> --- a/fsck/mount.c
>> +++ b/fsck/mount.c
>> @@ -2022,8 +2022,11 @@ int find_next_free_block(struct f2fs_sb_info *sbi, u64 *to, int left, int type)
>> if (se2->valid_blocks)
>> break;
>> }
>> - if (i == sbi->segs_per_sec)
>> + if (i == sbi->segs_per_sec) {
>> + /* find a free seg, init its type */
>> + se->orig_type = type;
>> return 0;
>> + }
>> }
>>
>> if (se->type == type &&
>> @@ -2244,7 +2247,7 @@ void write_superblock(struct f2fs_super_block *new_sb)
>> ASSERT(ret >= 0);
>> }
>> free(buf);
>> - DBG(0, "Info: Done to rebuild superblock\n");
>> + MSG(0, "Info: Done to rebuild superblock\n");
>> }
>>
>> void build_nat_area_bitmap(struct f2fs_sb_info *sbi)
>> --
>> 2.17.1
>
> .
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply
* Re: [PATCH 6/7] x86/vdso: Add vDSO functions for user wait instructions
From: Andy Lutomirski @ 2018-07-24 2:11 UTC (permalink / raw)
To: Fenghua Yu, Thomas Gleixner, Ingo Molnar, H Peter Anvin
Cc: Ashok Raj, Alan Cox, Ravi V Shankar, linux-kernel, x86
In-Reply-To: <1532350557-98388-7-git-send-email-fenghua.yu@intel.com>
On 07/23/2018 05:55 AM, Fenghua Yu wrote:
> User wants to query if user wait instructions (umonitor, umwait, and
> tpause) are supported and use the instructions. The vDSO functions
> provides fast interface for user to check the support and use the
> instructions.
>
> waitpkg_supported and its alias __vdso_waitpkg_supported check if
> user wait instructions (a.k.a. wait package feature) are supported
>
> umonitor and its alias __vdso_umonitor provide user APIs for calling
> umonitor instruction.
>
> umwait and its alias __vdso_umwait provide user APIs for calling
> umwait instruction.
>
> tpause and its alias __vdso_tpause provide user APIs for calling
> tpause instruction.
>
> nsec_to_tsc and its alias __vdso_nsec_to_tsc converts nanoseconds
> to TSC counter if TSC frequency is known. It will fail if TSC frequency
> is unknown.
>
> The instructions can be implemented in intrinsic functions in future
> GCC. But the vDSO interfaces are available to user without the
> intrinsic functions support in GCC and the API waitpkg_supported and
> nsec_to_tsc cannot be implemented as GCC functions.
>
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> ---
> arch/x86/entry/vdso/Makefile | 2 +-
> arch/x86/entry/vdso/vdso.lds.S | 10 ++
> arch/x86/entry/vdso/vma.c | 9 ++
> arch/x86/entry/vdso/vuserwait.c | 233 +++++++++++++++++++++++++++++++++
> arch/x86/include/asm/vdso_funcs_data.h | 3 +
> 5 files changed, 256 insertions(+), 1 deletion(-)
> create mode 100644 arch/x86/entry/vdso/vuserwait.c
>
> diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
> index af4fcae5de83..fb0062b09b3c 100644
> --- a/arch/x86/entry/vdso/Makefile
> +++ b/arch/x86/entry/vdso/Makefile
> @@ -17,7 +17,7 @@ VDSO32-$(CONFIG_X86_32) := y
> VDSO32-$(CONFIG_IA32_EMULATION) := y
>
> # files to link into the vdso
> -vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o vdirectstore.o
> +vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o vdirectstore.o vuserwait.o
>
> # files to link into kernel
> obj-y += vma.o
> diff --git a/arch/x86/entry/vdso/vdso.lds.S b/arch/x86/entry/vdso/vdso.lds.S
> index 097cdcda43a5..0942710608bf 100644
> --- a/arch/x86/entry/vdso/vdso.lds.S
> +++ b/arch/x86/entry/vdso/vdso.lds.S
> @@ -35,6 +35,16 @@ VERSION {
> __vdso_movdir64b_supported;
> movdir64b;
> __vdso_movdir64b;
> + waitpkg_supported;
> + __vdso_waitpkg_supported;
> + umonitor;
> + __vdso_umonitor;
> + umwait;
> + __vdso_umwait;
> + tpause;
> + __vdso_tpause;
> + nsec_to_tsc;
> + __vdso_nsec_to_tsc;
> local: *;
> };
> }
> diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
> index edbe5e63e5c2..006dfb5e5003 100644
> --- a/arch/x86/entry/vdso/vma.c
> +++ b/arch/x86/entry/vdso/vma.c
> @@ -372,10 +372,19 @@ static int vgetcpu_online(unsigned int cpu)
>
> static void __init init_vdso_funcs_data(void)
> {
> + struct system_counterval_t sys_counterval;
> +
> if (static_cpu_has(X86_FEATURE_MOVDIRI))
> vdso_funcs_data.movdiri_supported = true;
> if (static_cpu_has(X86_FEATURE_MOVDIR64B))
> vdso_funcs_data.movdir64b_supported = true;
> + if (static_cpu_has(X86_FEATURE_WAITPKG))
> + vdso_funcs_data.waitpkg_supported = true;
> + if (static_cpu_has(X86_FEATURE_TSC_KNOWN_FREQ)) {
> + vdso_funcs_data.tsc_known_freq = true;
> + sys_counterval = convert_art_ns_to_tsc(1);
> + vdso_funcs_data.tsc_per_nsec = sys_counterval.cycles;
> + }
You're losing a ton of precision here. You might even be losing *all*
of the precision and malfunctioning rather badly.
The correct way to do this is:
tsc_counts = ns * mul >> shift;
and the vclock code illustrates it. convert_art_ns_to_tsc() is a bad
example because it uses an expensive division operation for no good
reason except that no one bothered to optimize it.
> +notrace int __vdso_nsec_to_tsc(unsigned long nsec, unsigned long *tsc)
> +{
> + if (!_vdso_funcs_data->tsc_known_freq)
> + return -ENODEV;
> +
> + *tsc = _vdso_funcs_data->tsc_per_nsec * nsec;
> +
> + return 0;
> +}
Please don't expose this one at all. It would be nice for programs that
use waitpkg to be migratable using CRIU-like tools, and this export
actively harms any such effort. If you omit this function, then the
kernel could learn to abort an in-progress __vdso_umwait if preempted
(rseq-style) and CRIU would just work. It would be a bit of a hack, but
it solves a real problem.
> +notrace int __vdso_umwait(int state, unsigned long nsec)
__vdso_umwait_relative(), please. Because some day (possibly soon)
someone will want __vdso_umwait_absolute() and its friend
__vdso_read_art_ns() so they can do:
u64 start = __vdso_read_art_ns();
__vdso_umonitor(...);
... do something potentially slow or that might fault ...
__vdso_umwait_absolute(start + timeout);
Also, this patch appears to have a subtle but show-stopping race. Consider:
1. Task A does UMONITOR on CPU 1
2. Task A is preempted.
3. Task B does UMONITOR on CPU 1 at a different address
4. Task A resumes
5. Task A does UMWAIT
Now task A hangs, at least until the next external wakeup happens.
It's not entirely clear to me how you're supposed to fix this without
some abomination that's so bad that it torpedoes the entire feature.
Except that there is no chicken bit to turn this thing off. Sigh.
^ permalink raw reply
* Re: [PATCH 1/3] [BUGFIX] tracing: Fix double free of event_trigger_data
From: Steven Rostedt @ 2018-07-24 2:10 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Ingo Molnar, Shuah Khan, Tom Zanussi, Hiraku Toyooka,
linux-kernel, stable
In-Reply-To: <153149926702.11274.12489440326560729788.stgit@devbox>
On Sat, 14 Jul 2018 01:27:47 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:
> Fix a double free bug of event_trigger_data caused by
> calling unregister_trigger() from register_snapshot_trigger().
> This kicks a kernel BUG if double free checker is enabled
> as below;
>
> kernel BUG at /home/mhiramat/ksrc/linux/mm/slub.c:296!
> invalid opcode: 0000 [#1] SMP PTI
> CPU: 2 PID: 4312 Comm: ftracetest Not tainted 4.18.0-rc1+ #44
> Hardware name: ASUS All Series/B85M-G, BIOS 2108 08/11/2014
> RIP: 0010:set_freepointer.part.37+0x0/0x10
> Code: 41 b8 01 00 00 00 29 c8 4d 8d 0c 0c b9 10 00 00 00 50 e8 e3 28 23 00 8b 53 08 5e 5f 89 d1 81 e1 00 04 00 00 e9 e9 fe ff ff 90 <0f> 0b 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 48 c7 c6 90 7f 0d
> RSP: 0018:ffffa799caa3bd90 EFLAGS: 00010246
> RAX: ffff9b825f8c8e80 RBX: ffff9b825f8c8e80 RCX: ffff9b825f8c8e80
> RDX: 0000000000021562 RSI: ffff9b830e9e70e0 RDI: 0000000000000202
> RBP: 0000000000000246 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff9b830e0072c0
> R13: ffffeb8e0d7e3200 R14: ffffffff961db7af R15: 00000000fffffffe
> FS: 00007f135ba9f700(0000) GS:ffff9b830e800000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000563736b5f3a2 CR3: 0000000295916005 CR4: 00000000001606e0
> Call Trace:
> kfree+0x35d/0x380
> event_trigger_callback+0x13f/0x1c0
> event_trigger_write+0xf2/0x1a0
> ? lock_acquire+0x9f/0x200
> __vfs_write+0x26/0x170
> ? rcu_read_lock_sched_held+0x6b/0x80
> ? rcu_sync_lockdep_assert+0x2e/0x60
> ? __sb_start_write+0x13e/0x1a0
> ? vfs_write+0x18a/0x1b0
> vfs_write+0xc1/0x1b0
> ksys_write+0x45/0xa0
> do_syscall_64+0x60/0x200
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> unregister_trigger() will free given event_trigger_data
> at last. But that event_trigger_data will be freed again
> in event_trigger_callback() if register_snapshot_trigger()
> is failed, and causes a double free bug.
>
> Registering the data should be the final operation in the
> register function on normal path, because the trigger
> must be ready for taking action right after it is
> registered.
Nice catch. I can reproduce this. But this patch is fixing the symptom
and not the disease.
>
> Fixes: commit 93e31ffbf417 ("tracing: Add 'snapshot' event trigger command")
> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
> Cc: stable@vger.kernel.org
> ---
> kernel/trace/trace.c | 5 +++++
> kernel/trace/trace.h | 2 ++
> kernel/trace/trace_events_trigger.c | 10 ++++++----
> 3 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index f054bd6a1c66..2556d8c097d2 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -980,6 +980,11 @@ static void free_snapshot(struct trace_array *tr)
> tr->allocated_snapshot = false;
> }
>
> +void tracing_free_snapshot_instance(struct trace_array *tr)
> +{
> + free_snapshot(tr);
> +}
> +
> /**
> * tracing_alloc_snapshot - allocate snapshot buffer.
> *
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index f8f86231ad90..03468bb8a79a 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -1823,12 +1823,14 @@ static inline void trace_event_eval_update(struct trace_eval_map **map, int len)
> #ifdef CONFIG_TRACER_SNAPSHOT
> void tracing_snapshot_instance(struct trace_array *tr);
> int tracing_alloc_snapshot_instance(struct trace_array *tr);
> +void tracing_free_snapshot_instance(struct trace_array *tr);
> #else
> static inline void tracing_snapshot_instance(struct trace_array *tr) { }
> static inline int tracing_alloc_snapshot_instance(struct trace_array *tr)
> {
> return 0;
> }
> +static inline void tracing_free_snapshot_instance(struct trace_array *tr) { }
> #endif
>
> extern struct trace_iterator *tracepoint_print_iter;
> diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
> index d18249683682..40e2f4406b2c 100644
> --- a/kernel/trace/trace_events_trigger.c
> +++ b/kernel/trace/trace_events_trigger.c
> @@ -1079,11 +1079,13 @@ register_snapshot_trigger(char *glob, struct event_trigger_ops *ops,
> struct event_trigger_data *data,
> struct trace_event_file *file)
> {
> - int ret = register_trigger(glob, ops, data, file);
> + int free_if_fail = !file->tr->allocated_snapshot;
> + int ret = 0;
>
> - if (ret > 0 && tracing_alloc_snapshot_instance(file->tr) != 0) {
> - unregister_trigger(glob, ops, data, file);
> - ret = 0;
> + if (!tracing_alloc_snapshot_instance(file->tr)) {
> + ret = register_trigger(glob, ops, data, file);
> + if (ret == 0 && free_if_fail)
> + tracing_free_snapshot_instance(file->tr);
> }
>
> return ret;
Really, when we register_trigger() we should be able to freely call
unresgister_trigger() with no side effects like the above happens.
Instead of doing the above, I believe this is a better approach:
Thoughts?
P.S. This brings up another minor bug. The failure should return ENOMEM
not ENOENT.
-- Steve
diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
index d18249683682..d15a746bcdfb 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -679,6 +679,7 @@ event_trigger_callback(struct event_command *cmd_ops,
goto out_free;
out_reg:
+ event_trigger_init(trigger_ops, trigger_data);
ret = cmd_ops->reg(glob, trigger_ops, trigger_data, file);
/*
* The above returns on success the # of functions enabled,
@@ -687,9 +688,9 @@ event_trigger_callback(struct event_command *cmd_ops,
*/
if (!ret) {
ret = -ENOENT;
- goto out_free;
+ goto out_free_trigger;
} else if (ret < 0)
- goto out_free;
+ goto out_free_trigger;
ret = 0;
out:
return ret;
@@ -699,6 +700,10 @@ event_trigger_callback(struct event_command *cmd_ops,
cmd_ops->set_filter(NULL, trigger_data, NULL);
kfree(trigger_data);
goto out;
+
+ out_free_trigger:
+ event_trigger_free(trigger_ops, trigger_data);
+ goto out;
}
/**
^ permalink raw reply related
* Re: [RFC PATCH 02/10] iommu/vt-d: Alloc domain for a mediated device
From: Lu Baolu @ 2018-07-24 2:09 UTC (permalink / raw)
To: Liu, Yi L, Joerg Roedel, David Woodhouse, Alex Williamson,
Kirti Wankhede
Cc: Raj, Ashok, Kumar, Sanjay K, Pan, Jacob jun, Tian, Kevin,
Sun, Yi Y, peterx@redhat.com, iommu@lists.linux-foundation.org,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jacob Pan
In-Reply-To: <A2975661238FB949B60364EF0F2C257439CA1432@SHSMSX104.ccr.corp.intel.com>
Hi,
On 07/23/2018 12:44 PM, Liu, Yi L wrote:
>> From: Lu Baolu [mailto:baolu.lu@linux.intel.com]
>> Sent: Sunday, July 22, 2018 2:09 PM
>>
>> The PASID-granular 2nd level address translation makes it possible to isolate and
>> protect a mediated device exposed by a real device which support PCI PASID
> "support" -> "supports"
Sure.
>
>> features. This patch adds support to allocate a domain for a mediated device. A
>> default pasid value will be allocated as well for the mediated device. This will be used
> This is not accurate, it is "a default pasid value will be allocated for the domain, and the
> mdev will be configed to use this pasid when it is added to this domain"
Looks better. Thank you.
Best regards,
Lu Baolu
>
> Regards,
> Yi Liu
>
>> by the mediated device attached to this domain for non-SVM DMA transactions.
>>
>> Cc: Ashok Raj <ashok.raj@intel.com>
>> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
>> Cc: Kevin Tian <kevin.tian@intel.com>
>> Cc: Liu Yi L <yi.l.liu@intel.com>
>> Signed-off-by: Sanjay Kumar <sanjay.k.kumar@intel.com>
>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> ---
>> drivers/iommu/intel-iommu.c | 17 ++++++++++++++++- include/linux/intel-iommu.h
>> | 5 +++++
>> 2 files changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index
>> fc3ac1c..3ede34a 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -1926,6 +1926,9 @@ static void domain_exit(struct dmar_domain *domain)
>> domain_remove_dev_info(domain);
>> rcu_read_unlock();
>>
>> + if (domain->default_pasid > 0)
>> + intel_pasid_free_id(domain->default_pasid);
>> +
>> /* destroy iovas */
>> put_iova_domain(&domain->iovad);
>>
>> @@ -2519,11 +2522,23 @@ static struct dmar_domain
>> *dmar_insert_one_dev_info(struct intel_iommu *iommu,
>> }
>> }
>>
>> + if (dev && dev_is_mdev(dev) && domain->default_pasid <= 0) {
>> + int max = intel_pasid_get_dev_max_id(dev_mdev_parent(dev));
>> +
>> + domain->default_pasid = intel_pasid_alloc_id(domain, PASID_MIN,
>> + max, GFP_KERNEL);
>> + if (domain->default_pasid < 0) {
>> + free_devinfo_mem(info);
>> + return NULL;
>> + }
>> + }
>> +
>> spin_lock_irqsave(&device_domain_lock, flags);
>> if (dev)
>> found = find_domain(dev);
>>
>> - if (!found) {
>> + /* A mediated device never has an DMA alias. Ignore searching. */
>> + if (!found && !dev_is_mdev(dev)) {
>> struct device_domain_info *info2;
>> info2 = dmar_search_domain_by_dev_info(iommu->segment, bus,
>> devfn);
>> if (info2) {
>> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h index
>> 7efc632..9f5dcf6 100644
>> --- a/include/linux/intel-iommu.h
>> +++ b/include/linux/intel-iommu.h
>> @@ -423,6 +423,11 @@ struct dmar_domain {
>> 2 == 1GiB, 3 == 512GiB, 4 == 1TiB */
>> u64 max_addr; /* maximum mapped address */
>>
>> + int default_pasid; /*
>> + * The default pasid used for non-SVM
>> + * traffic on mediated devices.
>> + */
>> +
>> struct iommu_domain domain; /* generic domain data structure for
>> iommu core */
>> };
>> --
>> 2.7.4
>
^ permalink raw reply
* Re: [RFC PATCH 02/10] iommu/vt-d: Alloc domain for a mediated device
From: Lu Baolu @ 2018-07-24 2:09 UTC (permalink / raw)
To: Liu, Yi L, Joerg Roedel, David Woodhouse, Alex Williamson,
Kirti Wankhede
Cc: Raj, Ashok, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Kumar, Sanjay K,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sun, Yi Y,
Pan, Jacob jun
In-Reply-To: <A2975661238FB949B60364EF0F2C257439CA1432-0J0gbvR4kTg/UvCtAeCM4rfspsVTdybXVpNB7YpNyf8@public.gmane.org>
Hi,
On 07/23/2018 12:44 PM, Liu, Yi L wrote:
>> From: Lu Baolu [mailto:baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org]
>> Sent: Sunday, July 22, 2018 2:09 PM
>>
>> The PASID-granular 2nd level address translation makes it possible to isolate and
>> protect a mediated device exposed by a real device which support PCI PASID
> "support" -> "supports"
Sure.
>
>> features. This patch adds support to allocate a domain for a mediated device. A
>> default pasid value will be allocated as well for the mediated device. This will be used
> This is not accurate, it is "a default pasid value will be allocated for the domain, and the
> mdev will be configed to use this pasid when it is added to this domain"
Looks better. Thank you.
Best regards,
Lu Baolu
>
> Regards,
> Yi Liu
>
>> by the mediated device attached to this domain for non-SVM DMA transactions.
>>
>> Cc: Ashok Raj <ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Cc: Jacob Pan <jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> Cc: Kevin Tian <kevin.tian-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Cc: Liu Yi L <yi.l.liu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Sanjay Kumar <sanjay.k.kumar-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Lu Baolu <baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> ---
>> drivers/iommu/intel-iommu.c | 17 ++++++++++++++++- include/linux/intel-iommu.h
>> | 5 +++++
>> 2 files changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index
>> fc3ac1c..3ede34a 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -1926,6 +1926,9 @@ static void domain_exit(struct dmar_domain *domain)
>> domain_remove_dev_info(domain);
>> rcu_read_unlock();
>>
>> + if (domain->default_pasid > 0)
>> + intel_pasid_free_id(domain->default_pasid);
>> +
>> /* destroy iovas */
>> put_iova_domain(&domain->iovad);
>>
>> @@ -2519,11 +2522,23 @@ static struct dmar_domain
>> *dmar_insert_one_dev_info(struct intel_iommu *iommu,
>> }
>> }
>>
>> + if (dev && dev_is_mdev(dev) && domain->default_pasid <= 0) {
>> + int max = intel_pasid_get_dev_max_id(dev_mdev_parent(dev));
>> +
>> + domain->default_pasid = intel_pasid_alloc_id(domain, PASID_MIN,
>> + max, GFP_KERNEL);
>> + if (domain->default_pasid < 0) {
>> + free_devinfo_mem(info);
>> + return NULL;
>> + }
>> + }
>> +
>> spin_lock_irqsave(&device_domain_lock, flags);
>> if (dev)
>> found = find_domain(dev);
>>
>> - if (!found) {
>> + /* A mediated device never has an DMA alias. Ignore searching. */
>> + if (!found && !dev_is_mdev(dev)) {
>> struct device_domain_info *info2;
>> info2 = dmar_search_domain_by_dev_info(iommu->segment, bus,
>> devfn);
>> if (info2) {
>> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h index
>> 7efc632..9f5dcf6 100644
>> --- a/include/linux/intel-iommu.h
>> +++ b/include/linux/intel-iommu.h
>> @@ -423,6 +423,11 @@ struct dmar_domain {
>> 2 == 1GiB, 3 == 512GiB, 4 == 1TiB */
>> u64 max_addr; /* maximum mapped address */
>>
>> + int default_pasid; /*
>> + * The default pasid used for non-SVM
>> + * traffic on mediated devices.
>> + */
>> +
>> struct iommu_domain domain; /* generic domain data structure for
>> iommu core */
>> };
>> --
>> 2.7.4
>
^ permalink raw reply
* RE: [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
From: A.s. Dong @ 2018-07-24 2:09 UTC (permalink / raw)
To: Lucas Stach, Oleksij Rempel, Shawn Guo, Fabio Estevam,
Rob Herring, Mark Rutland, Vladimir Zapolskiy
Cc: kernel@pengutronix.de, devicetree@vger.kernel.org, dl-linux-imx,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1532366380.3163.109.camel@pengutronix.de>
> -----Original Message-----
> From: Lucas Stach [mailto:l.stach@pengutronix.de]
> Sent: Tuesday, July 24, 2018 1:20 AM
> To: Oleksij Rempel <o.rempel@pengutronix.de>; Shawn Guo
> <shawnguo@kernel.org>; Fabio Estevam <fabio.estevam@nxp.com>; Rob
> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; A.s.
> Dong <aisheng.dong@nxp.com>; Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com>
> Cc: dl-linux-imx <linux-imx@nxp.com>; linux-arm-kernel@lists.infradead.org;
> kernel@pengutronix.de; devicetree@vger.kernel.org
> Subject: Re: [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
>
[...]
> > +}
> > +
> > +static int imx_mu_send_data(struct mbox_chan *chan, void *data) {
> > > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > > + struct imx_mu_con_priv *cp = chan->con_priv;
> > > + u32 *arg = data;
> > +
> > > + if (!imx_mu_last_tx_done(chan))
> > > + return -EBUSY;
> > +
> > > + imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
> > + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xSR_TEn(cp->idx), 0);
>
> In multi-channel mode this RMW cycle needs some kind of locking. As this
> register is also changed from the irq handler, this probably needs to be a
> irqsave spinlock.
>
Good catch!
They do need to be protected.
Regards
Dong Aisheng
^ permalink raw reply
* [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
From: A.s. Dong @ 2018-07-24 2:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1532366380.3163.109.camel@pengutronix.de>
> -----Original Message-----
> From: Lucas Stach [mailto:l.stach at pengutronix.de]
> Sent: Tuesday, July 24, 2018 1:20 AM
> To: Oleksij Rempel <o.rempel@pengutronix.de>; Shawn Guo
> <shawnguo@kernel.org>; Fabio Estevam <fabio.estevam@nxp.com>; Rob
> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; A.s.
> Dong <aisheng.dong@nxp.com>; Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com>
> Cc: dl-linux-imx <linux-imx@nxp.com>; linux-arm-kernel at lists.infradead.org;
> kernel at pengutronix.de; devicetree at vger.kernel.org
> Subject: Re: [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
>
[...]
> > +}
> > +
> > +static int imx_mu_send_data(struct mbox_chan *chan, void *data) {
> > > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > > + struct imx_mu_con_priv *cp = chan->con_priv;
> > > + u32 *arg = data;
> > +
> > > + if (!imx_mu_last_tx_done(chan))
> > > + return -EBUSY;
> > +
> > > + imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
> > + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xSR_TEn(cp->idx), 0);
>
> In multi-channel mode this RMW cycle needs some kind of locking. As this
> register is also changed from the irq handler, this probably needs to be a
> irqsave spinlock.
>
Good catch!
They do need to be protected.
Regards
Dong Aisheng
^ permalink raw reply
* [U-Boot] [PATCH 14/17] cmd: fat: add fatmkdir command
From: AKASHI Takahiro @ 2018-07-24 2:07 UTC (permalink / raw)
To: u-boot
In-Reply-To: <fc8bb142-bc61-f814-c5ee-e0967b06dc47@gmx.de>
On Fri, Jul 20, 2018 at 07:09:17PM +0200, Heinrich Schuchardt wrote:
> On 07/20/2018 04:57 AM, AKASHI Takahiro wrote:
> > In this patch, a new command, fatmkdir, is added.
> >
> > Please note that, as there is no notion of "current directory" on u-boot,
> > a directory name specified must contains an absolute directory path as
> > a parent directory. Otherwise, "/" (root directory) is assumed.
> >
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > ---
>
> Please, provide a Python test with an additional patch.
Please see my reply to Simon's/Tom's comments.
> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Thanks a lot for your review.
-Takahiro AKASHI
^ permalink raw reply
* Re: To remove packages from busybox
From: Andre McCurdy @ 2018-07-24 2:06 UTC (permalink / raw)
To: Simon Chamlian; +Cc: Yocto discussion list
In-Reply-To: <CANmTPBZ7neRETjpdKtC+2MpPuhtKegeQQEPY_1=SSDJzmUbWBA@mail.gmail.com>
On Mon, Jul 23, 2018 at 1:29 PM, Simon Chamlian <simon.chamlian@mpbc.ca> wrote:
> Hi,
>
> In order to remove package from busybox, I used:
>
> $ bitbake -c menuconfig busybox
>
> Under 'System Logging Itilities -->' I unchecked syslogd
>
> Then ran
> $ bitbake busybox
>
> and I get the following error:
>
> WARNING: busybox-1.24.1-r0 do_package: busybox: alternative target
> (/etc/syslog.conf or /etc/syslog.conf.busybox) does not exist, skipping...
> WARNING: busybox-1.24.1-r0 do_package: busybox: NOT adding alternative
> provide /etc/syslog.conf: /etc/syslog.conf.busybox does not exist
>
> ERROR: busybox-1.24.1-r0 do_package: SYSTEMD_SERVICE_busybox-syslog value
> busybox-syslog.service does not exist
>
>
> ERROR: busybox-1.24.1-r0 do_package: Function failed:
> systemd_populate_packages
>
>
> ERROR: Logfile of failure stored in:
> /opt/PHYTEC_BSPs/yocto_imx7/build/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/busybox/1.24.1-r0/temp/log.do_package.30881
>
> ERROR: Task
> (/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/meta/recipes-core/busybox/busybox_1.24.1.bb:do_package)
> failed with exit code '1'
>
> NOTE: Tasks Summary: Attempted 711 tasks of which 705 didn't need to be
> rerun and 1 failed.
>
> What am I doing wrong?
The "correct" way to disable syslog support in busybox would probably
be to create a .bbappend which contains:
SRC_URI_remove = "file://syslog.conf"
ie you would remove the config fragment which enables syslog from SRC_URI.
However, customising busybox like that gets almost no testing, so
there could certainly still be bugs.
^ permalink raw reply
* Re: [RFC PATCH 01/10] iommu/vt-d: Get iommu device for a mediated device
From: Lu Baolu @ 2018-07-24 2:06 UTC (permalink / raw)
To: Liu, Yi L, Joerg Roedel, David Woodhouse, Alex Williamson,
Kirti Wankhede
Cc: Raj, Ashok, Kumar, Sanjay K, Pan, Jacob jun, Tian, Kevin,
Sun, Yi Y, peterx@redhat.com, iommu@lists.linux-foundation.org,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jacob Pan
In-Reply-To: <A2975661238FB949B60364EF0F2C257439CA141D@SHSMSX104.ccr.corp.intel.com>
Hi Yi,
Thank you for reviewing my patch.
On 07/23/2018 12:44 PM, Liu, Yi L wrote:
> Hi Baolu,
>
> Per my understanding, the subject is not accurate. I think this patch is
> to get parent device structure for a mediate device instead of iommu
> device. This may be misleading for reviewers.
Please check below.
>
> Thanks,
> Yi Liu
>
>> From: Lu Baolu [mailto:baolu.lu@linux.intel.com]
>> Sent: Sunday, July 22, 2018 2:09 PM
>>
>> This patch adds the support to get the iommu device for a mediated device. The
>> assumption is that each mediated device is a minimal assignable set of a physical PCI
>> device. Hence, we should use the iommu device of the parent PCI device to manage
>> the translation.
>>
>> Cc: Ashok Raj <ashok.raj@intel.com>
>> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
>> Cc: Kevin Tian <kevin.tian@intel.com>
>> Cc: Liu Yi L <yi.l.liu@intel.com>
>> Signed-off-by: Sanjay Kumar <sanjay.k.kumar@intel.com>
>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> ---
>> drivers/iommu/intel-iommu.c | 6 ++++++ drivers/iommu/intel-pasid.h | 16
>> ++++++++++++++++
>> 2 files changed, 22 insertions(+)
>>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index
>> 7d198ea..fc3ac1c 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -767,6 +767,12 @@ static struct intel_iommu *device_to_iommu(struct device
>> *dev, u8 *bus, u8 *devf
>> if (iommu_dummy(dev))
>> return NULL;
>>
>> + if (dev_is_mdev(dev)) {
>> + dev = dev_mdev_parent(dev);
>> + if (WARN_ON(!dev_is_pci(dev)))
>> + return NULL;
>> + }
>> +
This gets the parent of a mediated device. And an iommu device will be
found which services the parent device. A mediated device should in the
same iommu scope as its parent.
Best regards,
Lu Baolu
>> if (dev_is_pci(dev)) {
>> struct pci_dev *pf_pdev;
>>
>> diff --git a/drivers/iommu/intel-pasid.h b/drivers/iommu/intel-pasid.h index
>> 518df72..46cde66 100644
>> --- a/drivers/iommu/intel-pasid.h
>> +++ b/drivers/iommu/intel-pasid.h
>> @@ -35,6 +35,22 @@ struct pasid_table {
>> struct list_head dev; /* device list */
>> };
>>
>> +static inline bool dev_is_mdev(struct device *dev) {
>> + if (!dev)
>> + return false;
>> +
>> + return !strcmp(dev->bus->name, "mdev"); }
>> +
>> +static inline struct device *dev_mdev_parent(struct device *dev) {
>> + if (WARN_ON(!dev_is_mdev(dev)))
>> + return NULL;
>> +
>> + return dev->parent;
>> +}
>> +
>> extern u32 intel_pasid_max_id;
>> int intel_pasid_alloc_id(void *ptr, int start, int end, gfp_t gfp); void
>> intel_pasid_free_id(int pasid);
>> --
>> 2.7.4
>
^ permalink raw reply
* Re: [RFC PATCH 01/10] iommu/vt-d: Get iommu device for a mediated device
From: Lu Baolu @ 2018-07-24 2:06 UTC (permalink / raw)
To: Liu, Yi L, Joerg Roedel, David Woodhouse, Alex Williamson,
Kirti Wankhede
Cc: Raj, Ashok, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Kumar, Sanjay K,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sun, Yi Y,
Pan, Jacob jun
In-Reply-To: <A2975661238FB949B60364EF0F2C257439CA141D-0J0gbvR4kTg/UvCtAeCM4rfspsVTdybXVpNB7YpNyf8@public.gmane.org>
Hi Yi,
Thank you for reviewing my patch.
On 07/23/2018 12:44 PM, Liu, Yi L wrote:
> Hi Baolu,
>
> Per my understanding, the subject is not accurate. I think this patch is
> to get parent device structure for a mediate device instead of iommu
> device. This may be misleading for reviewers.
Please check below.
>
> Thanks,
> Yi Liu
>
>> From: Lu Baolu [mailto:baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org]
>> Sent: Sunday, July 22, 2018 2:09 PM
>>
>> This patch adds the support to get the iommu device for a mediated device. The
>> assumption is that each mediated device is a minimal assignable set of a physical PCI
>> device. Hence, we should use the iommu device of the parent PCI device to manage
>> the translation.
>>
>> Cc: Ashok Raj <ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Cc: Jacob Pan <jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> Cc: Kevin Tian <kevin.tian-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Cc: Liu Yi L <yi.l.liu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Sanjay Kumar <sanjay.k.kumar-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Lu Baolu <baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> ---
>> drivers/iommu/intel-iommu.c | 6 ++++++ drivers/iommu/intel-pasid.h | 16
>> ++++++++++++++++
>> 2 files changed, 22 insertions(+)
>>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index
>> 7d198ea..fc3ac1c 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -767,6 +767,12 @@ static struct intel_iommu *device_to_iommu(struct device
>> *dev, u8 *bus, u8 *devf
>> if (iommu_dummy(dev))
>> return NULL;
>>
>> + if (dev_is_mdev(dev)) {
>> + dev = dev_mdev_parent(dev);
>> + if (WARN_ON(!dev_is_pci(dev)))
>> + return NULL;
>> + }
>> +
This gets the parent of a mediated device. And an iommu device will be
found which services the parent device. A mediated device should in the
same iommu scope as its parent.
Best regards,
Lu Baolu
>> if (dev_is_pci(dev)) {
>> struct pci_dev *pf_pdev;
>>
>> diff --git a/drivers/iommu/intel-pasid.h b/drivers/iommu/intel-pasid.h index
>> 518df72..46cde66 100644
>> --- a/drivers/iommu/intel-pasid.h
>> +++ b/drivers/iommu/intel-pasid.h
>> @@ -35,6 +35,22 @@ struct pasid_table {
>> struct list_head dev; /* device list */
>> };
>>
>> +static inline bool dev_is_mdev(struct device *dev) {
>> + if (!dev)
>> + return false;
>> +
>> + return !strcmp(dev->bus->name, "mdev"); }
>> +
>> +static inline struct device *dev_mdev_parent(struct device *dev) {
>> + if (WARN_ON(!dev_is_mdev(dev)))
>> + return NULL;
>> +
>> + return dev->parent;
>> +}
>> +
>> extern u32 intel_pasid_max_id;
>> int intel_pasid_alloc_id(void *ptr, int start, int end, gfp_t gfp); void
>> intel_pasid_free_id(int pasid);
>> --
>> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v3 bpf-next 5/8] veth: Add ndo_xdp_xmit
From: Jakub Kicinski @ 2018-07-24 1:02 UTC (permalink / raw)
To: Toshiaki Makita
Cc: netdev, Alexei Starovoitov, Daniel Borkmann, Toshiaki Makita,
Jesper Dangaard Brouer
In-Reply-To: <20180722151308.5480-6-toshiaki.makita1@gmail.com>
On Mon, 23 Jul 2018 00:13:05 +0900, Toshiaki Makita wrote:
> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
> This allows NIC's XDP to redirect packets to veth. The destination veth
> device enqueues redirected packets to the napi ring of its peer, then
> they are processed by XDP on its peer veth device.
> This can be thought as calling another XDP program by XDP program using
> REDIRECT, when the peer enables driver XDP.
>
> Note that when the peer veth device does not set driver xdp, redirected
> packets will be dropped because the peer is not ready for NAPI.
Often we can't redirect to devices which don't have am xdp program
installed. In your case we can't redirect unless the peer of the
target doesn't have a program installed? :(
Perhaps it is time to reconsider what Saeed once asked for, a flag or
attribute to enable being the destination of a XDP_REDIRECT.
> v2:
> - Drop the part converting xdp_frame into skb when XDP is not enabled.
> - Implement bulk interface of ndo_xdp_xmit.
> - Implement XDP_XMIT_FLUSH bit and drop ndo_xdp_flush.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> ---
> drivers/net/veth.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
>
> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index 4be75c58bc6a..57187e955fea 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -17,6 +17,7 @@
> #include <net/rtnetlink.h>
> #include <net/dst.h>
> #include <net/xfrm.h>
> +#include <net/xdp.h>
> #include <linux/veth.h>
> #include <linux/module.h>
> #include <linux/bpf.h>
> @@ -125,6 +126,11 @@ static void *veth_ptr_to_xdp(void *ptr)
> return (void *)((unsigned long)ptr & ~VETH_XDP_FLAG);
> }
>
> +static void *veth_xdp_to_ptr(void *ptr)
> +{
> + return (void *)((unsigned long)ptr | VETH_XDP_FLAG);
> +}
> +
> static void veth_ptr_free(void *ptr)
> {
> if (veth_is_xdp_frame(ptr))
> @@ -267,6 +273,44 @@ static struct sk_buff *veth_build_skb(void *head, int headroom, int len,
> return skb;
> }
>
> +static int veth_xdp_xmit(struct net_device *dev, int n,
> + struct xdp_frame **frames, u32 flags)
> +{
> + struct veth_priv *rcv_priv, *priv = netdev_priv(dev);
> + struct net_device *rcv;
> + int i, drops = 0;
> +
> + if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
> + return -EINVAL;
> +
> + rcv = rcu_dereference(priv->peer);
> + if (unlikely(!rcv))
> + return -ENXIO;
> +
> + rcv_priv = netdev_priv(rcv);
> + /* xdp_ring is initialized on receive side? */
> + if (!rcu_access_pointer(rcv_priv->xdp_prog))
> + return -ENXIO;
> +
> + spin_lock(&rcv_priv->xdp_ring.producer_lock);
> + for (i = 0; i < n; i++) {
> + struct xdp_frame *frame = frames[i];
> + void *ptr = veth_xdp_to_ptr(frame);
> +
> + if (unlikely(xdp_ok_fwd_dev(rcv, frame->len) ||
> + __ptr_ring_produce(&rcv_priv->xdp_ring, ptr))) {
Would you mind sparing a few more words how this is safe vs the
.ndo_close() on the peer? Personally I'm a bit uncomfortable with the
IFF_UP check in xdp_ok_fwd_dev(), I'm not sure what's supposed to
guarantee the device doesn't go down right after that check, or is
already down, but netdev->flags are not atomic...
> + xdp_return_frame_rx_napi(frame);
> + drops++;
> + }
> + }
> + spin_unlock(&rcv_priv->xdp_ring.producer_lock);
> +
> + if (flags & XDP_XMIT_FLUSH)
> + __veth_xdp_flush(rcv_priv);
> +
> + return n - drops;
> +}
> +
> static struct sk_buff *veth_xdp_rcv_one(struct veth_priv *priv,
> struct xdp_frame *frame)
> {
> @@ -760,6 +804,7 @@ static const struct net_device_ops veth_netdev_ops = {
> .ndo_features_check = passthru_features_check,
> .ndo_set_rx_headroom = veth_set_rx_headroom,
> .ndo_bpf = veth_xdp,
> + .ndo_xdp_xmit = veth_xdp_xmit,
> };
>
> #define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HW_CSUM | \
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.