* Re: [PATCH net-next 1/2] net: linkwatch: add check for netdevice being present to linkwatch_do_dev
From: Geert Uytterhoeven @ 2018-09-19 8:48 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Florian Fainelli, Andrew Lunn, David S. Miller, netdev,
Geert Uytterhoeven
In-Reply-To: <11beeaa9-57d5-e641-9486-f2ba202d0998@gmail.com>
On Tue, Sep 18, 2018 at 9:56 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> When bringing down the netdevice (incl. detaching it) and calling
> netif_carrier_off directly or indirectly the latter triggers an
> asynchronous linkwatch event.
> This linkwatch event eventually may fail to access chip registers in
> the ndo_get_stats/ndo_get_stats64 callback because the device isn't
> accessible any longer, see call trace in [0].
>
> To prevent this scenario don't check for IFF_UP only, but also make
> sure that the netdevice is present.
>
> [0] https://lists.openwall.net/netdev/2018/03/15/62
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Survived 100 suspend/resume cycles on sh73a0/kzm9g and r8a73a4/ape6evm.
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] net: ibm: remove a redundant local variable 'k'
From: zhong jiang @ 2018-09-19 14:23 UTC (permalink / raw)
To: davem; +Cc: dougmill, netdev, linux-kernel
The local variable 'k' is never used after being assigned.
hence it should be redundant adn can be removed.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/ethernet/ibm/ehea/ehea_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_main.c b/drivers/net/ethernet/ibm/ehea/ehea_main.c
index ba580bf..7f6a401 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_main.c
+++ b/drivers/net/ethernet/ibm/ehea/ehea_main.c
@@ -778,12 +778,11 @@ static void check_sqs(struct ehea_port *port)
{
struct ehea_swqe *swqe;
int swqe_index;
- int i, k;
+ int i;
for (i = 0; i < port->num_def_qps; i++) {
struct ehea_port_res *pr = &port->port_res[i];
int ret;
- k = 0;
swqe = ehea_get_swqe(pr->qp, &swqe_index);
memset(swqe, 0, SWQE_HEADER_SIZE);
atomic_dec(&pr->swqe_avail);
--
1.7.12.4
^ permalink raw reply related
* Re: [PATCH 00/21] SMMU enablement for NXP LS1043A and LS1046A
From: Laurentiu Tudor @ 2018-09-19 14:18 UTC (permalink / raw)
To: Robin Murphy, devicetree@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Roy Pledge, Leo Li, shawnguo@kernel.org, davem@davemloft.net,
Madalin-cristian Bucur
In-Reply-To: <7d7646dc-9d0b-013d-75d7-a6cb4453f41f@arm.com>
Hi Robin,
On 19.09.2018 16:25, Robin Murphy wrote:
> Hi Laurentiu,
>
> On 19/09/18 13:35, laurentiu.tudor@nxp.com wrote:
>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>
>> This patch series adds SMMU support for NXP LS1043A and LS1046A chips
>> and consists mostly in important driver fixes and the required device
>> tree updates. It touches several subsystems and consists of three main
>> parts:
>> - changes in soc/drivers/fsl/qbman drivers adding iommu mapping of
>> reserved memory areas, fixes and defered probe support
>> - changes in drivers/net/ethernet/freescale/dpaa_eth drivers
>> consisting in misc dma mapping related fixes and probe ordering
>> - addition of the actual arm smmu device tree node together with
>> various adjustments to the device trees
>>
>> Performance impact
>>
>> Running iperf benchmarks in a back-to-back setup (both sides
>> having smmu enabled) on a 10GBps port show an important
>> networking performance degradation of around %40 (9.48Gbps
>> linerate vs 5.45Gbps). If you need performance but without
>> SMMU support you can use "iommu.passthrough=1" to disable
>> SMMU.
>>
>> USB issue and workaround
>>
>> There's a problem with the usb controllers in these chips
>> generating smaller, 40-bit wide dma addresses instead of the 48-bit
>> supported at the smmu input. So you end up in a situation where the
>> smmu is mapped with 48-bit address translations, but the device
>> generates transactions with clipped 40-bit addresses, thus smmu
>> context faults are triggered. I encountered a similar situation for
>> mmc that I managed to fix in software [1] however for USB I did not
>> find a proper place in the code to add a similar fix. The only
>> workaround I found was to add this kernel parameter which limits the
>> usb dma to 32-bit size: "xhci-hcd.quirks=0x800000".
>> This workaround if far from ideal, so any suggestions for a code
>> based workaround in this area would be greatly appreciated.
>
> If you have a nominally-64-bit device with a
> narrower-than-the-main-interconnect link in front of it, that should
> already be fixed in 4.19-rc by bus_dma_mask picking up DT dma-ranges,
> provided the interconnect hierarchy can be described appropriately (or
> at least massaged sufficiently to satisfy the binding), e.g.:
>
> / {
> ...
>
> soc {
> ranges;
> dma-ranges = <0 0 10000 0>;
>
> dev_48bit { ... };
>
> periph_bus {
> ranges;
> dma-ranges = <0 0 100 0>;
>
> dev_40bit { ... };
> };
> };
> };
>
> and if that fails to work as expected (except for PCI hosts where
> handling dma-ranges properly still needs sorting out), please do let us
> know ;)
>
Just to confirm, Is this [1] the change I was supposed to test?
Because if so, I'm still seeing context faults [2] with what looks like
clipped to 40-bits addresses. :-(
IIRC, the usb subsystem explicitly set 64-bit dma masks which in turn
will be limited to the SMMU input size of 48-bit. Won't that overwrite
the default dma mask derived from dma-ranges?
---
Best Regards, Laurentiu
[1] -----------------------------------------------------------------
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 3bdea0470f69..a214c3df37fd 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -612,6 +612,7 @@
compatible = "snps,dwc3";
reg = <0x0 0x2f00000 0x0 0x10000>;
interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ dma-ranges = <0x0 0x0 0x0 0x0 0x100 0x00000000>;
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
@@ -621,6 +622,7 @@
compatible = "snps,dwc3";
reg = <0x0 0x3000000 0x0 0x10000>;
interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+ dma-ranges = <0x0 0x0 0x0 0x0 0x100 0x00000000>;
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
@@ -630,6 +632,7 @@
compatible = "snps,dwc3";
reg = <0x0 0x3100000 0x0 0x10000>;
interrupts = <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>;
+ dma-ranges = <0x0 0x0 0x0 0x0 0x100 0x00000000>;
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
[2] -----------------------------------------------------------------
[ 2.090577] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[ 2.096064] xhci-hcd xhci-hcd.0.auto: new USB bus registered,
assigned bus number 2
[ 2.103720] xhci-hcd xhci-hcd.0.auto: Host supports USB 3.0 SuperSpeed
[ 2.110346] arm-smmu 9000000.iommu: Unhandled context fault:
fsr=0x402, iova=0xffffffb000, fsynr=0x1b0000, cb=3
[ 2.120449] usb usb2: We don't know the algorithms for LPM for this
host, disabling LPM.
[ 2.128717] hub 2-0:1.0: USB hub found
[ 2.132473] hub 2-0:1.0: 1 port detected
[ 2.136527] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller
[ 2.142014] xhci-hcd xhci-hcd.1.auto: new USB bus registered,
assigned bus number 3
[ 2.149747] xhci-hcd xhci-hcd.1.auto: hcc params 0x0220f66d hci
version 0x100 quirks 0x0000000002010010
[ 2.159149] xhci-hcd xhci-hcd.1.auto: irq 50, io mem 0x03000000
[ 2.165284] hub 3-0:1.0: USB hub found
[ 2.169039] hub 3-0:1.0: 1 port detected
[ 2.173051] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller
[ 2.178536] xhci-hcd xhci-hcd.1.auto: new USB bus registered,
assigned bus number 4
[ 2.186193] xhci-hcd xhci-hcd.1.auto: Host supports USB 3.0 SuperSpeed
[ 2.192809] arm-smmu 9000000.iommu: Unhandled context fault:
fsr=0x402, iova=0xffffffb000, fsynr=0x1f0000, cb=4
[ 2.192822] usb usb4: We don't know the algorithms for LPM for this
host, disabling LPM.
[ 2.211141] hub 4-0:1.0: USB hub found
[ 2.214896] hub 4-0:1.0: 1 port detected
[ 2.218935] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[ 2.224425] xhci-hcd xhci-hcd.2.auto: new USB bus registered,
assigned bus number 5
[ 2.232153] xhci-hcd xhci-hcd.2.auto: hcc params 0x0220f66d hci
version 0x100 quirks 0x0000000002010010
[ 2.241562] xhci-hcd xhci-hcd.2.auto: irq 51, io mem 0x03100000
[ 2.247694] hub 5-0:1.0: USB hub found
[ 2.251449] hub 5-0:1.0: 1 port detected
[ 2.255458] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[ 2.260945] xhci-hcd xhci-hcd.2.auto: new USB bus registered,
assigned bus number 6
[ 2.268601] xhci-hcd xhci-hcd.2.auto: Host supports USB 3.0 SuperSpeed
[ 2.275218] arm-smmu 9000000.iommu: Unhandled context fault:
fsr=0x402, iova=0xffffffb000, fsynr=0x110000, cb=5
[ 2.275230] usb usb6: We don't know the algorithms for LPM for this
host, disabling LPM.
>> The patch set is based on net-next so, if generally agreed, I'd suggest
>> to get the patches through the netdev tree after getting all the Acks.
>>
>> [1]
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fpatch%2F10506627%2F&data=02%7C01%7Claurentiu.tudor%40nxp.com%7C63c4e1dfc126488eb4ba08d61e336607%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636729603447603039&sdata=XhjOX9aLgoe%2BSTBgZztv6zCz0vMebSXW%2Fnb2QcD5shY%3D&reserved=0
>>
>>
>> Laurentiu Tudor (21):
>> soc/fsl/qman: fixup liodns only on ppc targets
>> soc/fsl/bman: map FBPR area in the iommu
>> soc/fsl/qman: map FQD and PFDR areas in the iommu
>> soc/fsl/qman-portal: map CENA area in the iommu
>> soc/fsl/qbman: add APIs to retrieve the probing status
>> soc/fsl/qman_portals: defer probe after qman's probe
>> soc/fsl/bman_portals: defer probe after bman's probe
>> soc/fsl/qbman_portals: add APIs to retrieve the probing status
>> fsl/fman: backup and restore ICID registers
>> fsl/fman: add API to get the device behind a fman port
>> dpaa_eth: defer probing after qbman
>> dpaa_eth: base dma mappings on the fman rx port
>> dpaa_eth: fix iova handling for contiguous frames
>> dpaa_eth: fix iova handling for sg frames
>> dpaa_eth: fix SG frame cleanup
>> arm64: dts: ls1046a: add smmu node
>> arm64: dts: ls1043a: add smmu node
>> arm64: dts: ls104xa: set mask to drop TBU ID from StreamID
>> arm64: dts: ls104x: add missing dma ranges property
>> arm64: dts: ls104x: add iommu-map to pci controllers
>> arm64: dts: ls104x: make dma-coherent global to the SoC
>>
>> .../arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 52 ++++++-
>> .../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 48 +++++++
>> .../net/ethernet/freescale/dpaa/dpaa_eth.c | 136 ++++++++++++------
>> drivers/net/ethernet/freescale/fman/fman.c | 35 ++++-
>> drivers/net/ethernet/freescale/fman/fman.h | 4 +
>> .../net/ethernet/freescale/fman/fman_port.c | 14 ++
>> .../net/ethernet/freescale/fman/fman_port.h | 2 +
>> drivers/soc/fsl/qbman/bman_ccsr.c | 23 +++
>> drivers/soc/fsl/qbman/bman_portal.c | 20 ++-
>> drivers/soc/fsl/qbman/qman_ccsr.c | 30 ++++
>> drivers/soc/fsl/qbman/qman_portal.c | 35 +++++
>> include/soc/fsl/bman.h | 16 +++
>> include/soc/fsl/qman.h | 17 +++
>> 13 files changed, 379 insertions(+), 53 deletions(-)
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 18/21] arm64: dts: ls104xa: set mask to drop TBU ID from StreamID
From: Laurentiu Tudor @ 2018-09-19 14:06 UTC (permalink / raw)
To: Robin Murphy, devicetree@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Madalin-cristian Bucur, Roy Pledge, Leo Li, shawnguo@kernel.org,
davem@davemloft.net
In-Reply-To: <fe2af486-3d7d-a38f-ef62-6754f809298f@arm.com>
Hi Robin,
On 19.09.2018 16:41, Robin Murphy wrote:
> On 19/09/18 13:36, laurentiu.tudor@nxp.com wrote:
>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>
>> The StreamID entering the SMMU is actually a concatenation of the
>> SMMU TBU ID and the ICID configured in software.
>> Since the TBU ID is internal to the SoC and since we want that the
>> actual the ICID configured in software to enter the SMMU witout any
>> additional set bits, mask out the TBU ID bits and leave only the
>> relevant ICID bits to enter SMMU.
>>
>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>> ---
>> arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 1 +
>> arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
>> b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
>> index 8b3eba167508..90296b9fb171 100644
>> --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
>> @@ -226,6 +226,7 @@
>> compatible = "arm,mmu-500";
>> reg = <0 0x9000000 0 0x400000>;
>> dma-coherent;
>> + stream-match-mask = <0x7f00>;
>
> The TBU ID only forms the top 5 bits, so also ignoring bits 9:8 raises
> an eyebrow - if the LS104x SMMU really is configured for 8-bit SID input
> then it's harmless,
On these lower-end platforms the SID input is configured and documented
as 8-bit.
> but if it's actually a 9 or 10-bit configuration
> then you probably want to avoid masking them (or at least document why)
> - IIRC there *was* stuff wired there on LS2085 at least.
Yes, on LS2s there are 2 extra-bits in there carrying some signaling.
However, on LS1s they are not present.
---
Thanks & Best Regards, Laurentiu
>
>> #global-interrupts = <2>;
>> #iommu-cells = <1>;
>> interrupts = <0 142 4>, /* global secure fault */
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
>> b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
>> index 06863d3e4a7d..15094dd8400e 100644
>> --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
>> @@ -232,6 +232,7 @@
>> compatible = "arm,mmu-500";
>> reg = <0 0x9000000 0 0x400000>;
>> dma-coherent;
>> + stream-match-mask = <0x7f00>;
>> #global-interrupts = <2>;
>> #iommu-cells = <1>;
>> interrupts = <0 142 4>, /* global secure fault */
>>
^ permalink raw reply
* Re: [Patch net-next] ipv4: initialize ra_mutex in inet_init_net()
From: Kirill Tkhai @ 2018-09-19 8:25 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers
In-Reply-To: <CAM_iQpUqVx91g6aWTERXGnNo7BoD20Ac1wGsqMK-_Ejk-2c+DQ@mail.gmail.com>
On 18.09.2018 23:17, Cong Wang wrote:
> On Mon, Sep 17, 2018 at 12:25 AM Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>> In inet_init() the order of registration is:
>>
>> ip_mr_init();
>> init_inet_pernet_ops();
>>
>> This means, ipmr_net_ops pernet operations are before af_inet_ops
>> in pernet_list. So, there is a theoretical probability, sometimes
>> in the future, we will have a problem during a fail of net initialization.
>>
>> Say,
>>
>> setup_net():
>> ipmr_net_ops->init() returns 0
>> xxx->init() returns error
>> and then we do:
>> ipmr_net_ops->exit(),
>>
>> which could touch ra_mutex (theoretically).
>
> How could ra_mutex be touched in this scenario?
>
> ra_mutex is only used in ip_ra_control() which is called
> only by {get,set}sockopt(). I don't see anything related
> to netns exit() path here.
Currently, it is not touched. But it's an ordinary practice,
someone closes sockets in pernet ->exit methods. For example,
we close percpu icmp sockets in icmp_sk_exit(), which are
also of RAW type, and there is also called ip_ra_control()
for them. Yes, they differ by their protocol; icmp sockets
are of IPPROTO_ICMP protocol, while ip_ra_control() acts
on IPPROTO_RAW sockets, but it's not good anyway. This does
not look reliable for the future. In case of someone changes
something here, we may do not notice this for the long time,
while some users will meet bugs on their places.
Problems on error paths is not easy to detect on testing,
while user may meet them. We had issue of same type with
uninitialized xfrm_policy_lock. It was introduced in 2013,
while the problem was found only in 2017:
introduced by 283bc9f35bbb
fixed by c282222a45cb
(Last week I met it on RH7 kernel, which still has no a fix.
But this talk is not about distribution kernels, just about
the way).
I just want to say if someone makes some creativity on top
of this code, it will be to more friendly from us to him/her
to not force this person to think about such not obvious details,
but just to implement nice architecture right now.
Thanks,
Kirill
^ permalink raw reply
* Re: [PATCH 16/21] arm64: dts: ls1046a: add smmu node
From: Laurentiu Tudor @ 2018-09-19 13:51 UTC (permalink / raw)
To: Robin Murphy, devicetree@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Roy Pledge, Leo Li, shawnguo@kernel.org, davem@davemloft.net,
Madalin-cristian Bucur
In-Reply-To: <a4d32163-71b1-35df-3a4c-eb27b605fc46@arm.com>
Hi Robin,
On 19.09.2018 16:30, Robin Murphy wrote:
> On 19/09/18 13:36, laurentiu.tudor@nxp.com wrote:
>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>
>> This allows for the SMMU device to be probed by the SMMU kernel driver.
>>
>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>> ---
>> .../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 42 +++++++++++++++++++
>> 1 file changed, 42 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
>> b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
>> index ef83786b8b90..06863d3e4a7d 100644
>> --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
>> @@ -228,6 +228,48 @@
>> bus-width = <4>;
>> };
>> + mmu: iommu@9000000 {
>> + compatible = "arm,mmu-500";
>> + reg = <0 0x9000000 0 0x400000>;
>> + dma-coherent;
>> + #global-interrupts = <2>;
>> + #iommu-cells = <1>;
>> + interrupts = <0 142 4>, /* global secure fault */
>
> Either that's not really the secure global interrupt, or those context
> interrupts are wrong.
Now that you pointing out, I realize that the comments don't make much
sense. Actually, 142 is the non-secure interrupt (all ints are ORed on
this IRQ) while 143 is the secure version. I'll update the comments in
the next re-spin.
---
Thanks & Best Regards, Laurentiu
>
>> + <0 143 4>, /* combined secure interrupt */
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>,
>> + <0 142 4>;
>> + };
>> +
>> scfg: scfg@1570000 {
>> compatible = "fsl,ls1046a-scfg", "syscon";
>> reg = <0x0 0x1570000 0x0 0x10000>;
>>
_______________________________________________
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 net-next] ravb: remove tx buffer addr 4byte alilgnment restriction for R-Car Gen3
From: Simon Horman @ 2018-09-19 8:06 UTC (permalink / raw)
To: David Miller, Sergei Shtylyov
Cc: Magnus Damm, netdev, linux-renesas-soc, Kazuya Mizuguchi,
Simon Horman
From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
This patch sets from two descriptor to one descriptor because R-Car Gen3
does not have the 4 bytes alignment restriction of the transmission buffer.
Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v2 [Simon Horman]
* As per review by Sergi Shtylyov
- Use reverse xmas tree for variable declarations
- Use > rather than >= for conditions
- Dropped unnecessary parentheses
- Don't allocate memory for tx_align when it will not be used
- But, kept NUM_TX_DESC_GEN[23] as I see some value in
the self-documentation provided by these #defines
v1 [Kazuya Mizuguchi]
---
drivers/net/ethernet/renesas/ravb.h | 6 +-
drivers/net/ethernet/renesas/ravb_main.c | 143 +++++++++++++++++++------------
2 files changed, 92 insertions(+), 57 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
index 1470fc12282b..b2b18036380e 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -954,7 +954,10 @@ enum RAVB_QUEUE {
#define RX_QUEUE_OFFSET 4
#define NUM_RX_QUEUE 2
#define NUM_TX_QUEUE 2
-#define NUM_TX_DESC 2 /* TX descriptors per packet */
+
+/* TX descriptors per packet */
+#define NUM_TX_DESC_GEN2 2
+#define NUM_TX_DESC_GEN3 1
struct ravb_tstamp_skb {
struct list_head list;
@@ -1033,6 +1036,7 @@ struct ravb_private {
unsigned no_avb_link:1;
unsigned avb_link_active_low:1;
unsigned wol_enabled:1;
+ int num_tx_desc; /* TX descriptors per packet */
};
static inline u32 ravb_read(struct net_device *ndev, enum ravb_reg reg)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index fb2a1125780d..f7c92d48d0dd 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -182,6 +182,7 @@ static int ravb_tx_free(struct net_device *ndev, int q, bool free_txed_only)
{
struct ravb_private *priv = netdev_priv(ndev);
struct net_device_stats *stats = &priv->stats[q];
+ int num_tx_desc = priv->num_tx_desc;
struct ravb_tx_desc *desc;
int free_num = 0;
int entry;
@@ -191,7 +192,7 @@ static int ravb_tx_free(struct net_device *ndev, int q, bool free_txed_only)
bool txed;
entry = priv->dirty_tx[q] % (priv->num_tx_ring[q] *
- NUM_TX_DESC);
+ num_tx_desc);
desc = &priv->tx_ring[q][entry];
txed = desc->die_dt == DT_FEMPTY;
if (free_txed_only && !txed)
@@ -200,12 +201,12 @@ static int ravb_tx_free(struct net_device *ndev, int q, bool free_txed_only)
dma_rmb();
size = le16_to_cpu(desc->ds_tagl) & TX_DS;
/* Free the original skb. */
- if (priv->tx_skb[q][entry / NUM_TX_DESC]) {
+ if (priv->tx_skb[q][entry / num_tx_desc]) {
dma_unmap_single(ndev->dev.parent, le32_to_cpu(desc->dptr),
size, DMA_TO_DEVICE);
/* Last packet descriptor? */
- if (entry % NUM_TX_DESC == NUM_TX_DESC - 1) {
- entry /= NUM_TX_DESC;
+ if (entry % num_tx_desc == num_tx_desc - 1) {
+ entry /= num_tx_desc;
dev_kfree_skb_any(priv->tx_skb[q][entry]);
priv->tx_skb[q][entry] = NULL;
if (txed)
@@ -224,6 +225,7 @@ static int ravb_tx_free(struct net_device *ndev, int q, bool free_txed_only)
static void ravb_ring_free(struct net_device *ndev, int q)
{
struct ravb_private *priv = netdev_priv(ndev);
+ int num_tx_desc = priv->num_tx_desc;
int ring_size;
int i;
@@ -249,7 +251,7 @@ static void ravb_ring_free(struct net_device *ndev, int q)
ravb_tx_free(ndev, q, false);
ring_size = sizeof(struct ravb_tx_desc) *
- (priv->num_tx_ring[q] * NUM_TX_DESC + 1);
+ (priv->num_tx_ring[q] * num_tx_desc + 1);
dma_free_coherent(ndev->dev.parent, ring_size, priv->tx_ring[q],
priv->tx_desc_dma[q]);
priv->tx_ring[q] = NULL;
@@ -278,12 +280,13 @@ static void ravb_ring_free(struct net_device *ndev, int q)
static void ravb_ring_format(struct net_device *ndev, int q)
{
struct ravb_private *priv = netdev_priv(ndev);
+ int num_tx_desc = priv->num_tx_desc;
struct ravb_ex_rx_desc *rx_desc;
struct ravb_tx_desc *tx_desc;
struct ravb_desc *desc;
int rx_ring_size = sizeof(*rx_desc) * priv->num_rx_ring[q];
int tx_ring_size = sizeof(*tx_desc) * priv->num_tx_ring[q] *
- NUM_TX_DESC;
+ num_tx_desc;
dma_addr_t dma_addr;
int i;
@@ -318,8 +321,10 @@ static void ravb_ring_format(struct net_device *ndev, int q)
for (i = 0, tx_desc = priv->tx_ring[q]; i < priv->num_tx_ring[q];
i++, tx_desc++) {
tx_desc->die_dt = DT_EEMPTY;
- tx_desc++;
- tx_desc->die_dt = DT_EEMPTY;
+ if (num_tx_desc > 1) {
+ tx_desc++;
+ tx_desc->die_dt = DT_EEMPTY;
+ }
}
tx_desc->dptr = cpu_to_le32((u32)priv->tx_desc_dma[q]);
tx_desc->die_dt = DT_LINKFIX; /* type */
@@ -339,6 +344,7 @@ static void ravb_ring_format(struct net_device *ndev, int q)
static int ravb_ring_init(struct net_device *ndev, int q)
{
struct ravb_private *priv = netdev_priv(ndev);
+ int num_tx_desc = priv->num_tx_desc;
struct sk_buff *skb;
int ring_size;
int i;
@@ -362,11 +368,13 @@ static int ravb_ring_init(struct net_device *ndev, int q)
priv->rx_skb[q][i] = skb;
}
- /* Allocate rings for the aligned buffers */
- priv->tx_align[q] = kmalloc(DPTR_ALIGN * priv->num_tx_ring[q] +
- DPTR_ALIGN - 1, GFP_KERNEL);
- if (!priv->tx_align[q])
- goto error;
+ if (num_tx_desc > 1) {
+ /* Allocate rings for the aligned buffers */
+ priv->tx_align[q] = kmalloc(DPTR_ALIGN * priv->num_tx_ring[q] +
+ DPTR_ALIGN - 1, GFP_KERNEL);
+ if (!priv->tx_align[q])
+ goto error;
+ }
/* Allocate all RX descriptors. */
ring_size = sizeof(struct ravb_ex_rx_desc) * (priv->num_rx_ring[q] + 1);
@@ -380,7 +388,7 @@ static int ravb_ring_init(struct net_device *ndev, int q)
/* Allocate all TX descriptors. */
ring_size = sizeof(struct ravb_tx_desc) *
- (priv->num_tx_ring[q] * NUM_TX_DESC + 1);
+ (priv->num_tx_ring[q] * num_tx_desc + 1);
priv->tx_ring[q] = dma_alloc_coherent(ndev->dev.parent, ring_size,
&priv->tx_desc_dma[q],
GFP_KERNEL);
@@ -1485,6 +1493,7 @@ static void ravb_tx_timeout_work(struct work_struct *work)
static netdev_tx_t ravb_start_xmit(struct sk_buff *skb, struct net_device *ndev)
{
struct ravb_private *priv = netdev_priv(ndev);
+ int num_tx_desc = priv->num_tx_desc;
u16 q = skb_get_queue_mapping(skb);
struct ravb_tstamp_skb *ts_skb;
struct ravb_tx_desc *desc;
@@ -1496,7 +1505,7 @@ static netdev_tx_t ravb_start_xmit(struct sk_buff *skb, struct net_device *ndev)
spin_lock_irqsave(&priv->lock, flags);
if (priv->cur_tx[q] - priv->dirty_tx[q] > (priv->num_tx_ring[q] - 1) *
- NUM_TX_DESC) {
+ num_tx_desc) {
netif_err(priv, tx_queued, ndev,
"still transmitting with the full ring!\n");
netif_stop_subqueue(ndev, q);
@@ -1507,41 +1516,55 @@ static netdev_tx_t ravb_start_xmit(struct sk_buff *skb, struct net_device *ndev)
if (skb_put_padto(skb, ETH_ZLEN))
goto exit;
- entry = priv->cur_tx[q] % (priv->num_tx_ring[q] * NUM_TX_DESC);
- priv->tx_skb[q][entry / NUM_TX_DESC] = skb;
-
- buffer = PTR_ALIGN(priv->tx_align[q], DPTR_ALIGN) +
- entry / NUM_TX_DESC * DPTR_ALIGN;
- len = PTR_ALIGN(skb->data, DPTR_ALIGN) - skb->data;
- /* Zero length DMA descriptors are problematic as they seem to
- * terminate DMA transfers. Avoid them by simply using a length of
- * DPTR_ALIGN (4) when skb data is aligned to DPTR_ALIGN.
- *
- * As skb is guaranteed to have at least ETH_ZLEN (60) bytes of
- * data by the call to skb_put_padto() above this is safe with
- * respect to both the length of the first DMA descriptor (len)
- * overflowing the available data and the length of the second DMA
- * descriptor (skb->len - len) being negative.
- */
- if (len == 0)
- len = DPTR_ALIGN;
+ entry = priv->cur_tx[q] % (priv->num_tx_ring[q] * num_tx_desc);
+ priv->tx_skb[q][entry / num_tx_desc] = skb;
+
+ if (num_tx_desc > 1) {
+ buffer = PTR_ALIGN(priv->tx_align[q], DPTR_ALIGN) +
+ entry / num_tx_desc * DPTR_ALIGN;
+ len = PTR_ALIGN(skb->data, DPTR_ALIGN) - skb->data;
+
+ /* Zero length DMA descriptors are problematic as they seem
+ * to terminate DMA transfers. Avoid them by simply using a
+ * length of DPTR_ALIGN (4) when skb data is aligned to
+ * DPTR_ALIGN.
+ *
+ * As skb is guaranteed to have at least ETH_ZLEN (60)
+ * bytes of data by the call to skb_put_padto() above this
+ * is safe with respect to both the length of the first DMA
+ * descriptor (len) overflowing the available data and the
+ * length of the second DMA descriptor (skb->len - len)
+ * being negative.
+ */
+ if (len == 0)
+ len = DPTR_ALIGN;
- memcpy(buffer, skb->data, len);
- dma_addr = dma_map_single(ndev->dev.parent, buffer, len, DMA_TO_DEVICE);
- if (dma_mapping_error(ndev->dev.parent, dma_addr))
- goto drop;
+ memcpy(buffer, skb->data, len);
+ dma_addr = dma_map_single(ndev->dev.parent, buffer, len,
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(ndev->dev.parent, dma_addr))
+ goto drop;
- desc = &priv->tx_ring[q][entry];
- desc->ds_tagl = cpu_to_le16(len);
- desc->dptr = cpu_to_le32(dma_addr);
+ desc = &priv->tx_ring[q][entry];
+ desc->ds_tagl = cpu_to_le16(len);
+ desc->dptr = cpu_to_le32(dma_addr);
- buffer = skb->data + len;
- len = skb->len - len;
- dma_addr = dma_map_single(ndev->dev.parent, buffer, len, DMA_TO_DEVICE);
- if (dma_mapping_error(ndev->dev.parent, dma_addr))
- goto unmap;
+ buffer = skb->data + len;
+ len = skb->len - len;
+ dma_addr = dma_map_single(ndev->dev.parent, buffer, len,
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(ndev->dev.parent, dma_addr))
+ goto unmap;
- desc++;
+ desc++;
+ } else {
+ desc = &priv->tx_ring[q][entry];
+ len = skb->len;
+ dma_addr = dma_map_single(ndev->dev.parent, skb->data, skb->len,
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(ndev->dev.parent, dma_addr))
+ goto drop;
+ }
desc->ds_tagl = cpu_to_le16(len);
desc->dptr = cpu_to_le32(dma_addr);
@@ -1549,9 +1572,11 @@ static netdev_tx_t ravb_start_xmit(struct sk_buff *skb, struct net_device *ndev)
if (q == RAVB_NC) {
ts_skb = kmalloc(sizeof(*ts_skb), GFP_ATOMIC);
if (!ts_skb) {
- desc--;
- dma_unmap_single(ndev->dev.parent, dma_addr, len,
- DMA_TO_DEVICE);
+ if (num_tx_desc > 1) {
+ desc--;
+ dma_unmap_single(ndev->dev.parent, dma_addr,
+ len, DMA_TO_DEVICE);
+ }
goto unmap;
}
ts_skb->skb = skb;
@@ -1568,15 +1593,18 @@ static netdev_tx_t ravb_start_xmit(struct sk_buff *skb, struct net_device *ndev)
skb_tx_timestamp(skb);
/* Descriptor type must be set after all the above writes */
dma_wmb();
- desc->die_dt = DT_FEND;
- desc--;
- desc->die_dt = DT_FSTART;
-
+ if (num_tx_desc > 1) {
+ desc->die_dt = DT_FEND;
+ desc--;
+ desc->die_dt = DT_FSTART;
+ } else {
+ desc->die_dt = DT_FSINGLE;
+ }
ravb_modify(ndev, TCCR, TCCR_TSRQ0 << q, TCCR_TSRQ0 << q);
- priv->cur_tx[q] += NUM_TX_DESC;
+ priv->cur_tx[q] += num_tx_desc;
if (priv->cur_tx[q] - priv->dirty_tx[q] >
- (priv->num_tx_ring[q] - 1) * NUM_TX_DESC &&
+ (priv->num_tx_ring[q] - 1) * num_tx_desc &&
!ravb_tx_free(ndev, q, true))
netif_stop_subqueue(ndev, q);
@@ -1590,7 +1618,7 @@ static netdev_tx_t ravb_start_xmit(struct sk_buff *skb, struct net_device *ndev)
le16_to_cpu(desc->ds_tagl), DMA_TO_DEVICE);
drop:
dev_kfree_skb_any(skb);
- priv->tx_skb[q][entry / NUM_TX_DESC] = NULL;
+ priv->tx_skb[q][entry / num_tx_desc] = NULL;
goto exit;
}
@@ -2076,6 +2104,9 @@ static int ravb_probe(struct platform_device *pdev)
ndev->max_mtu = 2048 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
ndev->min_mtu = ETH_MIN_MTU;
+ priv->num_tx_desc = chip_id == RCAR_GEN2 ?
+ NUM_TX_DESC_GEN2 : NUM_TX_DESC_GEN3;
+
/* Set function */
ndev->netdev_ops = &ravb_netdev_ops;
ndev->ethtool_ops = &ravb_ethtool_ops;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 18/21] arm64: dts: ls104xa: set mask to drop TBU ID from StreamID
From: Robin Murphy @ 2018-09-19 13:41 UTC (permalink / raw)
To: laurentiu.tudor, devicetree, netdev, linux-kernel,
linux-arm-kernel
Cc: madalin.bucur, roy.pledge, leoyang.li, shawnguo, davem
In-Reply-To: <20180919123613.15092-19-laurentiu.tudor@nxp.com>
On 19/09/18 13:36, laurentiu.tudor@nxp.com wrote:
> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>
> The StreamID entering the SMMU is actually a concatenation of the
> SMMU TBU ID and the ICID configured in software.
> Since the TBU ID is internal to the SoC and since we want that the
> actual the ICID configured in software to enter the SMMU witout any
> additional set bits, mask out the TBU ID bits and leave only the
> relevant ICID bits to enter SMMU.
>
> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 1 +
> arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> index 8b3eba167508..90296b9fb171 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> @@ -226,6 +226,7 @@
> compatible = "arm,mmu-500";
> reg = <0 0x9000000 0 0x400000>;
> dma-coherent;
> + stream-match-mask = <0x7f00>;
The TBU ID only forms the top 5 bits, so also ignoring bits 9:8 raises
an eyebrow - if the LS104x SMMU really is configured for 8-bit SID input
then it's harmless, but if it's actually a 9 or 10-bit configuration
then you probably want to avoid masking them (or at least document why)
- IIRC there *was* stuff wired there on LS2085 at least.
Robin.
> #global-interrupts = <2>;
> #iommu-cells = <1>;
> interrupts = <0 142 4>, /* global secure fault */
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> index 06863d3e4a7d..15094dd8400e 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> @@ -232,6 +232,7 @@
> compatible = "arm,mmu-500";
> reg = <0 0x9000000 0 0x400000>;
> dma-coherent;
> + stream-match-mask = <0x7f00>;
> #global-interrupts = <2>;
> #iommu-cells = <1>;
> interrupts = <0 142 4>, /* global secure fault */
>
^ permalink raw reply
* Re: [PATCH iproute2-next] iplink: add ipvtap support
From: Phil Sutter @ 2018-09-19 7:58 UTC (permalink / raw)
To: Hangbin Liu
Cc: netdev, Stephen Hemminger, David Ahern, Sainath Grandhi,
Davide Caratti
In-Reply-To: <1537326209-30837-1-git-send-email-liuhangbin@gmail.com>
On Wed, Sep 19, 2018 at 11:03:29AM +0800, Hangbin Liu wrote:
> IPVLAN and IPVTAP are using the same functions and parameters. So we can
> just add a new link_util with id ipvtap. Others are the same.
>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Acked-by: Phil Sutter <phil@nwl.cc>
^ permalink raw reply
* [RFC bpf-next 1/4] bpf: error handling when map_lookup_elem isn't supported
From: Prashant Bhole @ 2018-09-19 7:51 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: Prashant Bhole, Jakub Kicinski, Quentin Monnet, David S . Miller,
netdev
In-Reply-To: <20180919075143.9308-1-bhole_prashant_q7@lab.ntt.co.jp>
The error value returned by map_lookup_elem doesn't differentiate
whether lookup was failed because of invalid key or lookup is not
supported.
Lets add handling for -EOPNOTSUPP return value of map_lookup_elem()
method of map, with expectation from map's implementation that it
should return -EOPNOTSUPP if lookup is not supported.
The errno for bpf syscall for BPF_MAP_LOOKUP_ELEM command will be set
to EOPNOTSUPP if map lookup is not supported.
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
---
kernel/bpf/syscall.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index b3c2d09bcf7a..ecb06352b5a0 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -716,10 +716,15 @@ static int map_lookup_elem(union bpf_attr *attr)
} else {
rcu_read_lock();
ptr = map->ops->map_lookup_elem(map, key);
- if (ptr)
+ if (IS_ERR(ptr)) {
+ err = PTR_ERR(ptr);
+ } else if (!ptr) {
+ err = -ENOENT;
+ } else {
+ err = 0;
memcpy(value, ptr, value_size);
+ }
rcu_read_unlock();
- err = ptr ? 0 : -ENOENT;
}
if (err)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 16/21] arm64: dts: ls1046a: add smmu node
From: Robin Murphy @ 2018-09-19 13:30 UTC (permalink / raw)
To: laurentiu.tudor, devicetree, netdev, linux-kernel,
linux-arm-kernel
Cc: madalin.bucur, roy.pledge, leoyang.li, shawnguo, davem
In-Reply-To: <20180919123613.15092-17-laurentiu.tudor@nxp.com>
On 19/09/18 13:36, laurentiu.tudor@nxp.com wrote:
> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>
> This allows for the SMMU device to be probed by the SMMU kernel driver.
>
> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> ---
> .../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 42 +++++++++++++++++++
> 1 file changed, 42 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> index ef83786b8b90..06863d3e4a7d 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> @@ -228,6 +228,48 @@
> bus-width = <4>;
> };
>
> + mmu: iommu@9000000 {
> + compatible = "arm,mmu-500";
> + reg = <0 0x9000000 0 0x400000>;
> + dma-coherent;
> + #global-interrupts = <2>;
> + #iommu-cells = <1>;
> + interrupts = <0 142 4>, /* global secure fault */
Either that's not really the secure global interrupt, or those context
interrupts are wrong.
Robin.
> + <0 143 4>, /* combined secure interrupt */
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>,
> + <0 142 4>;
> + };
> +
> scfg: scfg@1570000 {
> compatible = "fsl,ls1046a-scfg", "syscon";
> reg = <0x0 0x1570000 0x0 0x10000>;
>
^ permalink raw reply
* [RFC bpf-next 3/4] tools/bpf: bpftool, split the function do_dump()
From: Prashant Bhole @ 2018-09-19 7:51 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: Prashant Bhole, Jakub Kicinski, Quentin Monnet, David S . Miller,
netdev
In-Reply-To: <20180919075143.9308-1-bhole_prashant_q7@lab.ntt.co.jp>
do_dump() function in bpftool/map.c has deep indentations. In order
to reduce deep indent, let's move element printing code out of
do_dump() into dump_map_elem() function.
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
---
tools/bpf/bpftool/map.c | 83 ++++++++++++++++++++++++-----------------
1 file changed, 49 insertions(+), 34 deletions(-)
diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
index af8ad32fa6e9..284e12a289c0 100644
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@ -655,6 +655,54 @@ static int do_show(int argc, char **argv)
return errno == ENOENT ? 0 : -1;
}
+static int dump_map_elem(int fd, void *key, void *value,
+ struct bpf_map_info *map_info, struct btf *btf,
+ json_writer_t *btf_wtr)
+{
+ int num_elems = 0;
+
+ if (!bpf_map_lookup_elem(fd, key, value)) {
+ if (json_output) {
+ print_entry_json(map_info, key, value, btf);
+ } else {
+ if (btf) {
+ struct btf_dumper d = {
+ .btf = btf,
+ .jw = btf_wtr,
+ .is_plain_text = true,
+ };
+
+ do_dump_btf(&d, map_info, key, value);
+ } else {
+ print_entry_plain(map_info, key, value);
+ }
+ num_elems++;
+ }
+ goto out;
+ }
+
+ /* lookup error handling */
+ if (map_is_map_of_maps(map_info->type) ||
+ map_is_map_of_progs(map_info->type))
+ goto out;
+
+ if (json_output) {
+ jsonw_name(json_wtr, "key");
+ print_hex_data_json(key, map_info->key_size);
+ jsonw_name(json_wtr, "value");
+ jsonw_start_object(json_wtr);
+ jsonw_string_field(json_wtr, "error",
+ "can't lookup element");
+ jsonw_end_object(json_wtr);
+ } else {
+ p_info("can't lookup element with key: ");
+ fprint_hex(stderr, key, map_info->key_size, " ");
+ fprintf(stderr, "\n");
+ }
+out:
+ return num_elems;
+}
+
static int do_dump(int argc, char **argv)
{
struct bpf_map_info info = {};
@@ -710,40 +758,7 @@ static int do_dump(int argc, char **argv)
err = 0;
break;
}
-
- if (!bpf_map_lookup_elem(fd, key, value)) {
- if (json_output)
- print_entry_json(&info, key, value, btf);
- else
- if (btf) {
- struct btf_dumper d = {
- .btf = btf,
- .jw = btf_wtr,
- .is_plain_text = true,
- };
-
- do_dump_btf(&d, &info, key, value);
- } else {
- print_entry_plain(&info, key, value);
- }
- num_elems++;
- } else if (!map_is_map_of_maps(info.type) &&
- !map_is_map_of_progs(info.type)) {
- if (json_output) {
- jsonw_name(json_wtr, "key");
- print_hex_data_json(key, info.key_size);
- jsonw_name(json_wtr, "value");
- jsonw_start_object(json_wtr);
- jsonw_string_field(json_wtr, "error",
- "can't lookup element");
- jsonw_end_object(json_wtr);
- } else {
- p_info("can't lookup element with key: ");
- fprint_hex(stderr, key, info.key_size, " ");
- fprintf(stderr, "\n");
- }
- }
-
+ num_elems += dump_map_elem(fd, key, value, &info, btf, btf_wtr);
prev_key = key;
}
--
2.17.1
^ permalink raw reply related
* [RFC bpf-next 4/4] tools/bpf: handle EOPNOTSUPP when map lookup is failed
From: Prashant Bhole @ 2018-09-19 7:51 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: Prashant Bhole, Jakub Kicinski, Quentin Monnet, David S . Miller,
netdev
In-Reply-To: <20180919075143.9308-1-bhole_prashant_q7@lab.ntt.co.jp>
Let's add a check for EOPNOTSUPP error when map lookup is failed.
Also in case map doesn't support lookup, the output of map dump is
changed from "can't lookup element" to "lookup not supported for
this map".
Patch adds function print_entry_error() function to print the error
value.
Following example dumps a map which does not support lookup.
Output before:
root# bpftool map -jp dump id 40
[
"key": ["0x0a","0x00","0x00","0x00"
],
"value": {
"error": "can\'t lookup element"
},
"key": ["0x0b","0x00","0x00","0x00"
],
"value": {
"error": "can\'t lookup element"
}
]
root# bpftool map dump id 40
can't lookup element with key:
0a 00 00 00
can't lookup element with key:
0b 00 00 00
Found 0 elements
Output after changes:
root# bpftool map dump -jp id 45
[
"key": ["0x0a","0x00","0x00","0x00"
],
"value": {
"error": "lookup not supported for this map"
},
"key": ["0x0b","0x00","0x00","0x00"
],
"value": {
"error": "lookup not supported for this map"
}
]
root# bpftool map dump id 45
key:
0a 00 00 00
value:
lookup not supported for this map
key:
0b 00 00 00
value:
lookup not supported for this map
Found 0 elements
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
---
tools/bpf/bpftool/main.h | 5 +++++
tools/bpf/bpftool/map.c | 35 ++++++++++++++++++++++++++++++-----
2 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/tools/bpf/bpftool/main.h b/tools/bpf/bpftool/main.h
index 40492cdc4e53..1a8c683f949b 100644
--- a/tools/bpf/bpftool/main.h
+++ b/tools/bpf/bpftool/main.h
@@ -46,6 +46,11 @@
#include "json_writer.h"
+#define ERR_CANNOT_LOOKUP \
+ "can't lookup element"
+#define ERR_LOOKUP_NOT_SUPPORTED \
+ "lookup not supported for this map"
+
#define ptr_to_u64(ptr) ((__u64)(unsigned long)(ptr))
#define NEXT_ARG() ({ argc--; argv++; if (argc < 0) usage(); })
diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
index 284e12a289c0..2faccd2098c9 100644
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@ -333,6 +333,25 @@ static void print_entry_json(struct bpf_map_info *info, unsigned char *key,
jsonw_end_object(json_wtr);
}
+static void print_entry_error(struct bpf_map_info *info, unsigned char *key,
+ char *value)
+{
+ bool single_line, break_names;
+ int value_size = strlen(value);
+
+ break_names = info->key_size > 16 || value_size > 16;
+ single_line = info->key_size + value_size <= 24 && !break_names;
+
+ printf("key:%c", break_names ? '\n' : ' ');
+ fprint_hex(stdout, key, info->key_size, " ");
+
+ printf(single_line ? " " : "\n");
+
+ printf("value:%c%s", break_names ? '\n' : ' ', value);
+
+ printf("\n");
+}
+
static void print_entry_plain(struct bpf_map_info *info, unsigned char *key,
unsigned char *value)
{
@@ -660,6 +679,8 @@ static int dump_map_elem(int fd, void *key, void *value,
json_writer_t *btf_wtr)
{
int num_elems = 0;
+ int lookup_errno;
+ char *errstr;
if (!bpf_map_lookup_elem(fd, key, value)) {
if (json_output) {
@@ -682,22 +703,26 @@ static int dump_map_elem(int fd, void *key, void *value,
}
/* lookup error handling */
+ lookup_errno = errno;
+
if (map_is_map_of_maps(map_info->type) ||
map_is_map_of_progs(map_info->type))
goto out;
+ if (lookup_errno == EOPNOTSUPP)
+ errstr = ERR_LOOKUP_NOT_SUPPORTED;
+ else
+ errstr = ERR_CANNOT_LOOKUP;
+
if (json_output) {
jsonw_name(json_wtr, "key");
print_hex_data_json(key, map_info->key_size);
jsonw_name(json_wtr, "value");
jsonw_start_object(json_wtr);
- jsonw_string_field(json_wtr, "error",
- "can't lookup element");
+ jsonw_string_field(json_wtr, "error", errstr);
jsonw_end_object(json_wtr);
} else {
- p_info("can't lookup element with key: ");
- fprint_hex(stderr, key, map_info->key_size, " ");
- fprintf(stderr, "\n");
+ print_entry_error(map_info, key, errstr);
}
out:
return num_elems;
--
2.17.1
^ permalink raw reply related
* [RFC bpf-next 2/4] bpf: return EOPNOTSUPP when map lookup isn't supported
From: Prashant Bhole @ 2018-09-19 7:51 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: Prashant Bhole, Jakub Kicinski, Quentin Monnet, David S . Miller,
netdev
In-Reply-To: <20180919075143.9308-1-bhole_prashant_q7@lab.ntt.co.jp>
Return ERR_PTR(-EOPNOTSUPP) from map_lookup_elem() methods of below
map types:
- BPF_MAP_TYPE_PROG_ARRAY
- BPF_MAP_TYPE_STACK_TRACE
- BPF_MAP_TYPE_XSKMAP
- BPF_MAP_TYPE_SOCKMAP/BPF_MAP_TYPE_SOCKHASH
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
---
kernel/bpf/arraymap.c | 2 +-
kernel/bpf/sockmap.c | 2 +-
kernel/bpf/stackmap.c | 2 +-
kernel/bpf/xskmap.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index dded84cbe814..24583da9ffd1 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -449,7 +449,7 @@ static void fd_array_map_free(struct bpf_map *map)
static void *fd_array_map_lookup_elem(struct bpf_map *map, void *key)
{
- return NULL;
+ return ERR_PTR(-EOPNOTSUPP);
}
/* only called from syscall */
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index 488ef9663c01..e50922a802f7 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -2076,7 +2076,7 @@ int sockmap_get_from_fd(const union bpf_attr *attr, int type,
static void *sock_map_lookup(struct bpf_map *map, void *key)
{
- return NULL;
+ return ERR_PTR(-EOPNOTSUPP);
}
static int sock_map_update_elem(struct bpf_map *map,
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 8061a439ef18..b2ade10f7ec3 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -505,7 +505,7 @@ const struct bpf_func_proto bpf_get_stack_proto = {
/* Called from eBPF program */
static void *stack_map_lookup_elem(struct bpf_map *map, void *key)
{
- return NULL;
+ return ERR_PTR(-EOPNOTSUPP);
}
/* Called from syscall */
diff --git a/kernel/bpf/xskmap.c b/kernel/bpf/xskmap.c
index 9f8463afda9c..ef0b7b6ef8a5 100644
--- a/kernel/bpf/xskmap.c
+++ b/kernel/bpf/xskmap.c
@@ -154,7 +154,7 @@ void __xsk_map_flush(struct bpf_map *map)
static void *xsk_map_lookup_elem(struct bpf_map *map, void *key)
{
- return NULL;
+ return ERR_PTR(-EOPNOTSUPP);
}
static int xsk_map_update_elem(struct bpf_map *map, void *key, void *value,
--
2.17.1
^ permalink raw reply related
* [RFC bpf-next 0/4] Error handling when map lookup isn't supported
From: Prashant Bhole @ 2018-09-19 7:51 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: Prashant Bhole, Jakub Kicinski, Quentin Monnet, David S . Miller,
netdev
Currently when map a lookup is failed, user space API can not make any
distinction whether given key was not found or lookup is not supported
by particular map.
In this series we modify return value of maps which do not support
lookup. Lookup on such map implementation will return -EOPNOTSUPP.
bpf() syscall with BPF_MAP_LOOKUP_ELEM command will set EOPNOTSUPP
errno. We also handle this error in bpftool to print appropriate
message.
Patch 1: adds handling of BPF_MAP_LOOKUP ELEM command of bpf syscall
such that errno will set to EOPNOTSUPP when map doesn't support lookup
Patch 2: Modifies the return value of map_lookup_elem() to EOPNOTSUPP
for maps which do not support lookup
Patch 3: Splits do_dump() in bpftool/map.c. Element printing code is
moved out into new function dump_map_elem(). This was done in order to
reduce deep indentation and accomodate further changes.
Patch 4: Changes to bpftool to do additional checking for errno when
map lookup is failed. In case of EOPNOTSUPP errno, it prints message
"lookup not supported for this map"
Prashant Bhole (4):
bpf: error handling when map_lookup_elem isn't supported
bpf: return EOPNOTSUPP when map lookup isn't supported
tools/bpf: bpftool, split the function do_dump()
tools/bpf: handle EOPNOTSUPP when map lookup is failed
kernel/bpf/arraymap.c | 2 +-
kernel/bpf/sockmap.c | 2 +-
kernel/bpf/stackmap.c | 2 +-
kernel/bpf/syscall.c | 9 +++-
kernel/bpf/xskmap.c | 2 +-
tools/bpf/bpftool/main.h | 5 ++
tools/bpf/bpftool/map.c | 108 +++++++++++++++++++++++++++------------
7 files changed, 90 insertions(+), 40 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net] net: mvneta: fix the Rx desc buffer DMA unmapping
From: Antoine Tenart @ 2018-09-19 13:29 UTC (permalink / raw)
To: davem, yelena
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, ymarkman, mw
With CONFIG_DMA_API_DEBUG enabled we now get a warning when using the
mvneta driver:
mvneta d0030000.ethernet: DMA-API: device driver frees DMA memory with
wrong function [device address=0x000000001165b000] [size=4096 bytes]
[mapped as page] [unmapped as single]
This is because when using the s/w buffer management, the Rx descriptor
buffer is mapped with dma_map_page but unmapped with dma_unmap_single.
This patch fixes this by using the right unmapping function.
Fixes: 562e2f467e71 ("net: mvneta: Improve the buffer allocation method for SWBM")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
drivers/net/ethernet/marvell/mvneta.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index bc80a678abc3..2db9708f2e24 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2008,8 +2008,8 @@ static int mvneta_rx_swbm(struct napi_struct *napi,
skb_add_rx_frag(rxq->skb, frag_num, page,
frag_offset, frag_size,
PAGE_SIZE);
- dma_unmap_single(dev->dev.parent, phys_addr,
- PAGE_SIZE, DMA_FROM_DEVICE);
+ dma_unmap_page(dev->dev.parent, phys_addr,
+ PAGE_SIZE, DMA_FROM_DEVICE);
rxq->left_size -= frag_size;
}
} else {
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 00/21] SMMU enablement for NXP LS1043A and LS1046A
From: Robin Murphy @ 2018-09-19 13:25 UTC (permalink / raw)
To: laurentiu.tudor, devicetree, netdev, linux-kernel,
linux-arm-kernel
Cc: madalin.bucur, roy.pledge, leoyang.li, shawnguo, davem
In-Reply-To: <20180919123613.15092-1-laurentiu.tudor@nxp.com>
Hi Laurentiu,
On 19/09/18 13:35, laurentiu.tudor@nxp.com wrote:
> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>
> This patch series adds SMMU support for NXP LS1043A and LS1046A chips
> and consists mostly in important driver fixes and the required device
> tree updates. It touches several subsystems and consists of three main
> parts:
> - changes in soc/drivers/fsl/qbman drivers adding iommu mapping of
> reserved memory areas, fixes and defered probe support
> - changes in drivers/net/ethernet/freescale/dpaa_eth drivers
> consisting in misc dma mapping related fixes and probe ordering
> - addition of the actual arm smmu device tree node together with
> various adjustments to the device trees
>
> Performance impact
>
> Running iperf benchmarks in a back-to-back setup (both sides
> having smmu enabled) on a 10GBps port show an important
> networking performance degradation of around %40 (9.48Gbps
> linerate vs 5.45Gbps). If you need performance but without
> SMMU support you can use "iommu.passthrough=1" to disable
> SMMU.
>
> USB issue and workaround
>
> There's a problem with the usb controllers in these chips
> generating smaller, 40-bit wide dma addresses instead of the 48-bit
> supported at the smmu input. So you end up in a situation where the
> smmu is mapped with 48-bit address translations, but the device
> generates transactions with clipped 40-bit addresses, thus smmu
> context faults are triggered. I encountered a similar situation for
> mmc that I managed to fix in software [1] however for USB I did not
> find a proper place in the code to add a similar fix. The only
> workaround I found was to add this kernel parameter which limits the
> usb dma to 32-bit size: "xhci-hcd.quirks=0x800000".
> This workaround if far from ideal, so any suggestions for a code
> based workaround in this area would be greatly appreciated.
If you have a nominally-64-bit device with a
narrower-than-the-main-interconnect link in front of it, that should
already be fixed in 4.19-rc by bus_dma_mask picking up DT dma-ranges,
provided the interconnect hierarchy can be described appropriately (or
at least massaged sufficiently to satisfy the binding), e.g.:
/ {
...
soc {
ranges;
dma-ranges = <0 0 10000 0>;
dev_48bit { ... };
periph_bus {
ranges;
dma-ranges = <0 0 100 0>;
dev_40bit { ... };
};
};
};
and if that fails to work as expected (except for PCI hosts where
handling dma-ranges properly still needs sorting out), please do let us
know ;)
Robin.
> The patch set is based on net-next so, if generally agreed, I'd suggest
> to get the patches through the netdev tree after getting all the Acks.
>
> [1] https://patchwork.kernel.org/patch/10506627/
>
> Laurentiu Tudor (21):
> soc/fsl/qman: fixup liodns only on ppc targets
> soc/fsl/bman: map FBPR area in the iommu
> soc/fsl/qman: map FQD and PFDR areas in the iommu
> soc/fsl/qman-portal: map CENA area in the iommu
> soc/fsl/qbman: add APIs to retrieve the probing status
> soc/fsl/qman_portals: defer probe after qman's probe
> soc/fsl/bman_portals: defer probe after bman's probe
> soc/fsl/qbman_portals: add APIs to retrieve the probing status
> fsl/fman: backup and restore ICID registers
> fsl/fman: add API to get the device behind a fman port
> dpaa_eth: defer probing after qbman
> dpaa_eth: base dma mappings on the fman rx port
> dpaa_eth: fix iova handling for contiguous frames
> dpaa_eth: fix iova handling for sg frames
> dpaa_eth: fix SG frame cleanup
> arm64: dts: ls1046a: add smmu node
> arm64: dts: ls1043a: add smmu node
> arm64: dts: ls104xa: set mask to drop TBU ID from StreamID
> arm64: dts: ls104x: add missing dma ranges property
> arm64: dts: ls104x: add iommu-map to pci controllers
> arm64: dts: ls104x: make dma-coherent global to the SoC
>
> .../arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 52 ++++++-
> .../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 48 +++++++
> .../net/ethernet/freescale/dpaa/dpaa_eth.c | 136 ++++++++++++------
> drivers/net/ethernet/freescale/fman/fman.c | 35 ++++-
> drivers/net/ethernet/freescale/fman/fman.h | 4 +
> .../net/ethernet/freescale/fman/fman_port.c | 14 ++
> .../net/ethernet/freescale/fman/fman_port.h | 2 +
> drivers/soc/fsl/qbman/bman_ccsr.c | 23 +++
> drivers/soc/fsl/qbman/bman_portal.c | 20 ++-
> drivers/soc/fsl/qbman/qman_ccsr.c | 30 ++++
> drivers/soc/fsl/qbman/qman_portal.c | 35 +++++
> include/soc/fsl/bman.h | 16 +++
> include/soc/fsl/qman.h | 17 +++
> 13 files changed, 379 insertions(+), 53 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v3 net-next 07/12] net: ethernet: Add helper to remove a supported link mode
From: Simon Horman @ 2018-09-19 7:45 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Miller, netdev, Florian Fainelli, Sergei Shtylyov,
linux-renesas-soc
In-Reply-To: <20180918130236.GB29092@lunn.ch>
[CC Sergei, linux-renesas-soc]
On Tue, Sep 18, 2018 at 03:02:36PM +0200, Andrew Lunn wrote:
> > Hi Andrew,
>
> Hi Simon
>
> Thanks for the dumps
>
> > 1. net-next: cf7d97e1e54d ("net: mdio: remove duplicated include from mdio_bus.c")
> >
> > basic status: no link
> > capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > advertising: 100baseTx-FD 100baseTx-HD flow-control
> > link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> >
> > 2. net-next with this patch reverted
> >
> > basic status: autonegotiation complete, link ok
> > capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > advertising: 100baseTx-FD 100baseTx-HD
> > link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>
> So flow-control is not present here.
>
> > basic status: autonegotiation complete, link ok
> > capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > advertising: 100baseTx-FD 100baseTx-HD
> > link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>
> And here also.
Thanks for raising this, I noticed it too.
> Looking at the code, i see:
>
> /* E-MAC init function */
> static void ravb_emac_init(struct net_device *ndev)
> {
> struct ravb_private *priv = netdev_priv(ndev);
>
> /* Receive frame limit set register */
> ravb_write(ndev, ndev->mtu + ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN, RFLR);
>
> /* EMAC Mode: PAUSE prohibition; Duplex; RX Checksum; TX; RX */
> ravb_write(ndev, ECMR_ZPF | (priv->duplex ? ECMR_DM : 0) |
> (ndev->features & NETIF_F_RXCSUM ? ECMR_RCSC : 0) |
> ECMR_TE | ECMR_RE, ECMR);
>
> Does this mean Pause is not supported in the hardware?
According to my reading of the documentation Pause is supported by the
hardware and the above code seems to conflict with the comment (possibly
both the code and comment predate the current documentation). My reading of
the documentation is that the above unconditionally _enables_ receiving and
sending Pause frames with time parameter value 0.
^ permalink raw reply
* Re: [PATCH v3 net-next] ravb: do not write 1 to reserved bits
From: Simon Horman @ 2018-09-19 7:39 UTC (permalink / raw)
To: David Miller; +Cc: sergei.shtylyov, magnus.damm, netdev, linux-renesas-soc
In-Reply-To: <20180918.201026.764474223291614125.davem@redhat.com>
On Tue, Sep 18, 2018 at 08:10:26PM -0700, David Miller wrote:
> From: Simon Horman <horms+renesas@verge.net.au>
> Date: Tue, 18 Sep 2018 12:22:26 +0200
>
> > From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> >
> > EtherAVB hardware requires 0 to be written to status register bits in
> > order to clear them, however, care must be taken not to:
> >
> > 1. Clear other bits, by writing zero to them
> > 2. Write one to reserved bits
> >
> > This patch corrects the ravb driver with respect to the second point above.
> > This is done by defining reserved bit masks for the affected registers and,
> > after auditing the code, ensure all sites that may write a one to a
> > reserved bit use are suitably masked.
> >
> > Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> I've decided to apply this to 'net', let me know if this is a problem.
Thanks Dave, 'net' is fine by me.
^ permalink raw reply
* Re: [PATCH bpf-next 2/2] xsk: fix bug when trying to use both copy and zero-copy on one queue id
From: Magnus Karlsson @ 2018-09-19 7:18 UTC (permalink / raw)
To: jakub.kicinski
Cc: ys114321, Karlsson, Magnus, Björn Töpel, ast,
Daniel Borkmann, Network Development
In-Reply-To: <20180918185557.4da5a463@cakuba.netronome.com>
On Wed, Sep 19, 2018 at 3:58 AM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> On Tue, 18 Sep 2018 10:22:11 -0700, Y Song wrote:
> > > +/* The umem is stored both in the _rx struct and the _tx struct as we do
> > > + * not know if the device has more tx queues than rx, or the opposite.
> > > + * This might also change during run time.
> > > + */
> > > +static void xdp_reg_umem_at_qid(struct net_device *dev, struct xdp_umem *umem,
> > > + u16 queue_id)
> > > +{
> > > + if (queue_id < dev->real_num_rx_queues)
> > > + dev->_rx[queue_id].umem = umem;
> > > + if (queue_id < dev->real_num_tx_queues)
> > > + dev->_tx[queue_id].umem = umem;
> > > +}
> > > +
> > > +static struct xdp_umem *xdp_get_umem_from_qid(struct net_device *dev,
> > > + u16 queue_id)
> > > +{
> > > + if (queue_id < dev->real_num_rx_queues)
> > > + return dev->_rx[queue_id].umem;
> > > + if (queue_id < dev->real_num_tx_queues)
> > > + return dev->_tx[queue_id].umem;
> > > +
> > > + return NULL;
> > > +}
> > > +
> > > +static void xdp_clear_umem_at_qid(struct net_device *dev, u16 queue_id)
> > > +{
> > > + /* Zero out the entry independent on how many queues are configured
> > > + * at this point in time, as it might be used in the future.
> > > + */
> > > + if (queue_id < dev->num_rx_queues)
> > > + dev->_rx[queue_id].umem = NULL;
> > > + if (queue_id < dev->num_tx_queues)
> > > + dev->_tx[queue_id].umem = NULL;
> > > +}
> > > +
> >
> > I am sure whether the following scenario can happen or not.
> > Could you clarify?
> > 1. suppose initially we have num_rx_queues = num_tx_queues = 10
> > xdp_reg_umem_at_qid() set umem1 to queue_id = 8
> > 2. num_tx_queues is changed to 5
> > 3. xdp_clear_umem_at_qid() is called for queue_id = 8,
> > and dev->_rx[8].umum = 0.
> > 4. xdp_reg_umem_at_qid() is called gain to set for queue_id = 8
> > dev->_rx[8].umem = umem2
> > 5. num_tx_queues is changed to 10
> > Now dev->_rx[8].umem != dev->_tx[8].umem, is this possible and is it
> > a problem?
>
> Plus IIRC the check of qid vs real_num_[rt]x_queues in xsk_bind() is
> not under rtnl_lock so it doesn't count for much. Why not do all the
> checks against num_[rt]x_queues here, instead of real_..?
You are correct, two separate rtnl_lock regions is broken. Will spin a
v2 tomorrow when I am back in the office.
Thanks Jakub for catching this. I really appreciate you reviewing my code.
/Magnus
^ permalink raw reply
* Re: [PATCH bpf-next 2/2] xsk: fix bug when trying to use both copy and zero-copy on one queue id
From: Magnus Karlsson @ 2018-09-19 7:14 UTC (permalink / raw)
To: ys114321
Cc: Karlsson, Magnus, Björn Töpel, ast, Daniel Borkmann,
Network Development
In-Reply-To: <CAH3MdRU8jKBdpNK6Uq3NRyeb2ih6tgWJOAKW_pQFm0QQ0kuvpw@mail.gmail.com>
On Tue, Sep 18, 2018 at 7:23 PM Y Song <ys114321@gmail.com> wrote:
>
> On Tue, Sep 18, 2018 at 3:13 AM Magnus Karlsson
> <magnus.karlsson@intel.com> wrote:
> >
> > Previously, the xsk code did not record which umem was bound to a
> > specific queue id. This was not required if all drivers were zero-copy
> > enabled as this had to be recorded in the driver anyway. So if a user
> > tried to bind two umems to the same queue, the driver would say
> > no. But if copy-mode was first enabled and then zero-copy mode (or the
> > reverse order), we mistakenly enabled both of them on the same umem
> > leading to buggy behavior. The main culprit for this is that we did
> > not store the association of umem to queue id in the copy case and
> > only relied on the driver reporting this. As this relation was not
> > stored in the driver for copy mode (it does not rely on the AF_XDP
> > NDOs), this obviously could not work.
> >
> > This patch fixes the problem by always recording the umem to queue id
> > relationship in the netdev_queue and netdev_rx_queue structs. This way
> > we always know what kind of umem has been bound to a queue id and can
> > act appropriately at bind time.
> >
> > Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
> > ---
> > net/xdp/xdp_umem.c | 87 +++++++++++++++++++++++++++++++++++++++++++-----------
> > net/xdp/xdp_umem.h | 2 +-
> > 2 files changed, 71 insertions(+), 18 deletions(-)
> >
> > diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
> > index b3b632c..12300b5 100644
> > --- a/net/xdp/xdp_umem.c
> > +++ b/net/xdp/xdp_umem.c
> > @@ -42,6 +42,41 @@ void xdp_del_sk_umem(struct xdp_umem *umem, struct xdp_sock *xs)
> > }
> > }
> >
> > +/* The umem is stored both in the _rx struct and the _tx struct as we do
> > + * not know if the device has more tx queues than rx, or the opposite.
> > + * This might also change during run time.
> > + */
> > +static void xdp_reg_umem_at_qid(struct net_device *dev, struct xdp_umem *umem,
> > + u16 queue_id)
> > +{
> > + if (queue_id < dev->real_num_rx_queues)
> > + dev->_rx[queue_id].umem = umem;
> > + if (queue_id < dev->real_num_tx_queues)
> > + dev->_tx[queue_id].umem = umem;
> > +}
> > +
> > +static struct xdp_umem *xdp_get_umem_from_qid(struct net_device *dev,
> > + u16 queue_id)
> > +{
> > + if (queue_id < dev->real_num_rx_queues)
> > + return dev->_rx[queue_id].umem;
> > + if (queue_id < dev->real_num_tx_queues)
> > + return dev->_tx[queue_id].umem;
> > +
> > + return NULL;
> > +}
> > +
> > +static void xdp_clear_umem_at_qid(struct net_device *dev, u16 queue_id)
> > +{
> > + /* Zero out the entry independent on how many queues are configured
> > + * at this point in time, as it might be used in the future.
> > + */
> > + if (queue_id < dev->num_rx_queues)
> > + dev->_rx[queue_id].umem = NULL;
> > + if (queue_id < dev->num_tx_queues)
> > + dev->_tx[queue_id].umem = NULL;
> > +}
> > +
>
> I am sure whether the following scenario can happen or not.
> Could you clarify?
> 1. suppose initially we have num_rx_queues = num_tx_queues = 10
> xdp_reg_umem_at_qid() set umem1 to queue_id = 8
> 2. num_tx_queues is changed to 5
You probably mean real_num_tx_queues here. This is the current number
of queues configured via e.g. ethtool. num_tx_queues will not change
unless you change device (or device driver).
> 3. xdp_clear_umem_at_qid() is called for queue_id = 8,
> and dev->_rx[8].umum = 0.
At this point both _rx[8].umem and _tx[8].umem are set to NULL as the
test is against num_[rx|tx]_queues which is the max allowed for the
device, not the current allocated one which is real_num_tx_queues.
With this in mind, the scenario below will not happen. Do you agree?
> 4. xdp_reg_umem_at_qid() is called gain to set for queue_id = 8
> dev->_rx[8].umem = umem2
> 5. num_tx_queues is changed to 10
> Now dev->_rx[8].umem != dev->_tx[8].umem, is this possible and is it
> a problem?
>
> > int xdp_umem_query(struct net_device *dev, u16 queue_id)
> > {
> > struct netdev_bpf bpf;
> > @@ -58,11 +93,11 @@ int xdp_umem_query(struct net_device *dev, u16 queue_id)
> > }
> >
> > int xdp_umem_assign_dev(struct xdp_umem *umem, struct net_device *dev,
> > - u32 queue_id, u16 flags)
> > + u16 queue_id, u16 flags)
> > {
> > bool force_zc, force_copy;
> > struct netdev_bpf bpf;
> > - int err;
> > + int err = 0;
> >
> > force_zc = flags & XDP_ZEROCOPY;
> > force_copy = flags & XDP_COPY;
> > @@ -70,18 +105,28 @@ int xdp_umem_assign_dev(struct xdp_umem *umem, struct net_device *dev,
> > if (force_zc && force_copy)
> > return -EINVAL;
> >
> > + rtnl_lock();
> > + if (xdp_get_umem_from_qid(dev, queue_id)) {
> > + err = -EBUSY;
> > + goto rtnl_unlock;
> > + }
> > +
> > + xdp_reg_umem_at_qid(dev, umem, queue_id);
> > + umem->dev = dev;
> > + umem->queue_id = queue_id;
> > if (force_copy)
> > - return 0;
> > + /* For copy-mode, we are done. */
> > + goto rtnl_unlock;
> >
> > - if (!dev->netdev_ops->ndo_bpf || !dev->netdev_ops->ndo_xsk_async_xmit)
> > - return force_zc ? -EOPNOTSUPP : 0; /* fail or fallback */
> > + if (!dev->netdev_ops->ndo_bpf ||
> > + !dev->netdev_ops->ndo_xsk_async_xmit) {
> > + err = -EOPNOTSUPP;
> > + goto err_unreg_umem;
> > + }
> >
> > - rtnl_lock();
> > err = xdp_umem_query(dev, queue_id);
> > - if (err) {
> > - err = err < 0 ? -EOPNOTSUPP : -EBUSY;
> > - goto err_rtnl_unlock;
> > - }
> > + if (err)
> > + goto err_unreg_umem;
> >
> > bpf.command = XDP_SETUP_XSK_UMEM;
> > bpf.xsk.umem = umem;
> > @@ -89,18 +134,20 @@ int xdp_umem_assign_dev(struct xdp_umem *umem, struct net_device *dev,
> >
> > err = dev->netdev_ops->ndo_bpf(dev, &bpf);
> > if (err)
> > - goto err_rtnl_unlock;
> > + goto err_unreg_umem;
> > rtnl_unlock();
> >
> > dev_hold(dev);
> > - umem->dev = dev;
> > - umem->queue_id = queue_id;
> > umem->zc = true;
> > return 0;
> >
> > -err_rtnl_unlock:
> > +err_unreg_umem:
> > + xdp_clear_umem_at_qid(dev, queue_id);
>
> You did not clear umem->dev and umem->queue_id,is a problem here?
> For example in xdp_umem_clear_dev(), umem->dev is checked.
As the umem might be shared, I cannot clear these variables as they
are used by another socket when it is shared.
The umem->dev check in xdp_umem_clear_dev() is for sockets that are
killed when only half-ways set up. In that case, umem->dev might still
be NULL.
> > + if (!force_zc)
> > + err = 0; /* fallback to copy mode */
> > +rtnl_unlock:
> > rtnl_unlock();
> > - return force_zc ? err : 0; /* fail or fallback */
> > + return err;
> > }
> >
> > static void xdp_umem_clear_dev(struct xdp_umem *umem)
> > @@ -108,7 +155,7 @@ static void xdp_umem_clear_dev(struct xdp_umem *umem)
> > struct netdev_bpf bpf;
> > int err;
> >
> > - if (umem->dev) {
> > + if (umem->zc) {
> > bpf.command = XDP_SETUP_XSK_UMEM;
> > bpf.xsk.umem = NULL;
> > bpf.xsk.queue_id = umem->queue_id;
> > @@ -121,7 +168,13 @@ static void xdp_umem_clear_dev(struct xdp_umem *umem)
> > WARN(1, "failed to disable umem!\n");
> >
> > dev_put(umem->dev);
> > - umem->dev = NULL;
> > + umem->zc = false;
> > + }
> > +
> > + if (umem->dev) {
> > + rtnl_lock();
> > + xdp_clear_umem_at_qid(umem->dev, umem->queue_id);
> > + rtnl_unlock();
>
> Previously, umem->dev is reset to NULL. Now, it is left as is. I
> assume it is not possible
> that this function xdp_umem_clear_dev() is called again for this umem, right?
This function will only be called once for each umem / queue_id pair.
We only allow one such binding with this patch. This is what was
broken with the original code.
Thanks Song for your review. I appreciate that you take a look at my code.
/Magnus
> > }
> > }
> >
> > diff --git a/net/xdp/xdp_umem.h b/net/xdp/xdp_umem.h
> > index c8be1ad..2760322 100644
> > --- a/net/xdp/xdp_umem.h
> > +++ b/net/xdp/xdp_umem.h
> > @@ -9,7 +9,7 @@
> > #include <net/xdp_sock.h>
> >
> > int xdp_umem_assign_dev(struct xdp_umem *umem, struct net_device *dev,
> > - u32 queue_id, u16 flags);
> > + u16 queue_id, u16 flags);
> > bool xdp_umem_validate_queues(struct xdp_umem *umem);
> > void xdp_get_umem(struct xdp_umem *umem);
> > void xdp_put_umem(struct xdp_umem *umem);
> > --
> > 2.7.4
> >
^ permalink raw reply
* Re: [PATCH] netfilter: conntrack: get rid of double sizeof
From: Florian Westphal @ 2018-09-19 12:40 UTC (permalink / raw)
To: zhong jiang
Cc: davem, kadlec, pablo, fw, netfilter-devel, netdev, linux-kernel
In-Reply-To: <1537359671-53720-1-git-send-email-zhongjiang@huawei.com>
zhong jiang <zhongjiang@huawei.com> wrote:
> sizeof(sizeof()) is quite strange and does not seem to be what
> is wanted here.
Fixes: 39215846740a9f ("netfilter: conntrack: remove nlattr_size pointer from l4proto trackers")
Acked-by: Florian Westphal <fw@strlen.de>
^ permalink raw reply
* Re: [PATCH net-next v5 20/20] net: WireGuard secure network tunnel
From: Andrew Lunn @ 2018-09-19 12:38 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman
In-Reply-To: <CAHmME9rwVLu+H88Nq+kGaVfZsZjoVUM_SdosjSRRpreUd2uGuQ@mail.gmail.com>
On Wed, Sep 19, 2018 at 04:04:01AM +0200, Jason A. Donenfeld wrote:
> Hi Andrew,
>
> On Wed, Sep 19, 2018 at 1:34 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > I see this BUG_ON() is still here. It really needs to be removed. It
> > does not look like you need to crash the kernel here. Can you add in a
> > test of len >= 128, do a WARN and then return. I think you then leak
> > some memory, but i would much prefer that to a crashed machine.
>
> Sure, I'll change it to that.
Great, thanks. I noticed there is at least one more BUG()
statements. It would be good to remove them all. BUG() should only be
used when something bad has already happened and we want to minimise
the damage by killing the machine immediately.
Andrew
^ permalink raw reply
* [PATCH 21/21] arm64: dts: ls104x: make dma-coherent global to the SoC
From: laurentiu.tudor @ 2018-09-19 12:36 UTC (permalink / raw)
To: devicetree, netdev, linux-kernel, linux-arm-kernel
Cc: roy.pledge, madalin.bucur, davem, shawnguo, leoyang.li,
Laurentiu Tudor
In-Reply-To: <20180919123613.15092-1-laurentiu.tudor@nxp.com>
From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
These SoCs are really completely dma coherent in their entirety so add
the dma-coherent property at the soc level in the device tree and drop
the instances where it's specifically added to a few select devices.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 5 +----
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 1 +
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 3b7b2e60bd9a..d02106cb2116 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -215,6 +215,7 @@
#size-cells = <2>;
ranges;
dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
+ dma-coherent;
clockgen: clocking@1ee1000 {
compatible = "fsl,ls1043a-clockgen";
@@ -680,7 +681,6 @@
reg-names = "ahci", "sata-ecc";
interrupts = <0 69 0x4>;
clocks = <&clockgen 4 0>;
- dma-coherent;
};
msi1: msi-controller1@1571000 {
@@ -715,7 +715,6 @@
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
- dma-coherent;
iommu-map = <0 &mmu 0 1>;
num-lanes = <4>;
bus-range = <0x0 0xff>;
@@ -741,7 +740,6 @@
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
- dma-coherent;
iommu-map = <0 &mmu 0 1>;
num-lanes = <2>;
bus-range = <0x0 0xff>;
@@ -767,7 +765,6 @@
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
- dma-coherent;
iommu-map = <0 &mmu 0 1>;
num-lanes = <2>;
bus-range = <0x0 0xff>;
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 890d1565791f..3bdea0470f69 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -188,6 +188,7 @@
#size-cells = <2>;
ranges;
dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
+ dma-coherent;
ddr: memory-controller@1080000 {
compatible = "fsl,qoriq-memory-controller";
--
2.17.1
^ permalink raw reply related
* [PATCH 19/21] arm64: dts: ls104x: add missing dma ranges property
From: laurentiu.tudor @ 2018-09-19 12:36 UTC (permalink / raw)
To: devicetree, netdev, linux-kernel, linux-arm-kernel
Cc: roy.pledge, madalin.bucur, davem, shawnguo, leoyang.li,
Laurentiu Tudor
In-Reply-To: <20180919123613.15092-1-laurentiu.tudor@nxp.com>
From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
These chips have a 48-bit address size so make sure that the dma-ranges
reflects this. Otherwise the linux kernel's dma sub-system will set
the default dma masks to full 64-bit, badly breaking dmas.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 1 +
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 90296b9fb171..48091409c472 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -214,6 +214,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+ dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
clockgen: clocking@1ee1000 {
compatible = "fsl,ls1043a-clockgen";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 15094dd8400e..40484f6f6d42 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -187,6 +187,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+ dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
ddr: memory-controller@1080000 {
compatible = "fsl,qoriq-memory-controller";
--
2.17.1
^ permalink raw reply related
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