* [PATCH 4/4] net: ftgmac100: Select ASPEED MDIO driver for the AST2600
From: Andrew Jeffery @ 2019-07-29 4:39 UTC (permalink / raw)
To: netdev
Cc: Andrew Jeffery, davem, robh+dt, mark.rutland, joel, andrew,
f.fainelli, hkallweit1, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel
In-Reply-To: <20190729043926.32679-1-andrew@aj.id.au>
Ensures we can talk to a PHY via MDIO on the AST2600, as the MDIO
controller is now separate from the MAC.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
drivers/net/ethernet/faraday/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/faraday/Kconfig b/drivers/net/ethernet/faraday/Kconfig
index a9b105803fb7..73e4f2648e49 100644
--- a/drivers/net/ethernet/faraday/Kconfig
+++ b/drivers/net/ethernet/faraday/Kconfig
@@ -32,6 +32,7 @@ config FTGMAC100
depends on ARM || NDS32 || COMPILE_TEST
depends on !64BIT || BROKEN
select PHYLIB
+ select MDIO_ASPEED if MACH_ASPEED_G6
---help---
This driver supports the FTGMAC100 Gigabit Ethernet controller
from Faraday. It is used on Faraday A369, Andes AG102 and some
--
2.20.1
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: net: Add aspeed,ast2600-mdio binding
From: Andrew Jeffery @ 2019-07-29 4:39 UTC (permalink / raw)
To: netdev
Cc: Andrew Jeffery, davem, robh+dt, mark.rutland, joel, andrew,
f.fainelli, hkallweit1, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel
In-Reply-To: <20190729043926.32679-1-andrew@aj.id.au>
The AST2600 splits out the MDIO bus controller from the MAC into its own
IP block and rearranges the register layout. Add a new binding to
describe the new hardware.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
.../bindings/net/aspeed,ast2600-mdio.yaml | 61 +++++++++++++++++++
1 file changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
diff --git a/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
new file mode 100644
index 000000000000..fa86f6438473
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/aspeed,ast2600-mdio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED AST2600 MDIO Controller
+
+maintainers:
+ - Andrew Jeffery <andrew@aj.id.au>
+
+description: |+
+ The ASPEED AST2600 MDIO controller is the third iteration of ASPEED's MDIO
+ bus register interface, this time also separating out the controller from the
+ MAC.
+
+properties:
+ compatible:
+ const: aspeed,ast2600-mdio
+ reg:
+ maxItems: 1
+ description: The register range of the MDIO controller instance
+ "#address-cells":
+ const: 1
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^ethernet-phy@[a-f0-9]$":
+ properties:
+ reg:
+ description:
+ The MDIO bus index of the PHY
+ compatible:
+ enum:
+ - ethernet-phy-ieee802.3-c22
+ - ethernet-phy-ieee802.3-c45
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+examples:
+ - |
+ mdio0: mdio@1e650000 {
+ compatible = "aspeed,ast2600-mdio";
+ reg = <0x1e650000 0x8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "okay";
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+ };
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next v4 2/3] flow_offload: Support get default block from tc immediately
From: Jakub Kicinski @ 2019-07-29 4:42 UTC (permalink / raw)
To: wenxu; +Cc: pablo, fw, netfilter-devel, netdev
In-Reply-To: <5eed91c1-20ed-c08c-4700-979392bc5f33@ucloud.cn>
On Mon, 29 Jul 2019 10:43:56 +0800, wenxu wrote:
> On 7/29/2019 4:16 AM, Jakub Kicinski wrote:
> > I don't know the nft code, but it seems unlikely it wouldn't have the
> > same problem/need..
>
> nft don't have the same problem. The offload rule can only attached
> to offload base chain.
>
> Th offload base chain is created after the device driver loaded (the
> device exist).
For indirect blocks the block is on the tunnel device and the offload
target is another device. E.g. you offload rules from a VXLAN device
onto the ASIC. The ASICs driver does not have to be loaded when VXLAN
device is created.
So I feel like either the chain somehow directly references the offload
target (in which case the indirect infrastructure with hash lookup etc
is not needed for nft), or indirect infra is needed, and we need to take
care of replays.
^ permalink raw reply
* Re: [PATCH v3] net: dsa: qca8k: enable port flow control
From: xiaofeis @ 2019-07-29 5:01 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem, vkoul, netdev, linux-arm-msm, bjorn.andersson,
vivien.didelot, f.fainelli, niklas.cassel, xiazha
In-Reply-To: <20190728223114.GD23125@lunn.ch>
On 2019-07-29 06:31, Andrew Lunn wrote:
> On Sun, Jul 28, 2019 at 08:57:50AM +0800, xiaofeis wrote:
>> Set phy device advertising to enable MAC flow control.
>
> Hi Xiaofei.
>
> This is half of the needed change for MAC flow control.
>
> phy_support_asym_pause(phy) is used by the MAC to tell the PHY layer
> that the MAC supports flow control. The PHY will then advertise
> this. When auto-negotiation is completed, the PHY layer will call
> qca8k_adjust_link() with the results. It could be that the peer does
> not support flow control, or only supports symmetric flow control. So
> in that function, you need to program the MAC with the results of the
> auto-neg. This is currently missing. You need to look at phydev->pause
> and phydev->asym_pause to decide how to configure the MAC.
>
> Andrew
Hi Andrew
You are correct. With the change, the auto-negotiation result still
depends on the peer.
But our qca8k HW can auto sync the pause status to MAC from phy with the
auto-negotiated result.
So no need to set in qca8k_adjust_link, since there is one setting in
qca8k_port_set_status: mask |= QCA8K_PORT_STATUS_LINK_AUTO;
This change's purpose is to keep enable advertise on our side.
Thanks
Xiaofeis
^ permalink raw reply
* Re: [PATCH V4 net-next 00/10] net: hns3: some code optimizations & bugfixes & features
From: Saeed Mahameed @ 2019-07-29 5:48 UTC (permalink / raw)
To: tanhuazhong@huawei.com, davem@davemloft.net
Cc: yisen.zhuang@huawei.com, salil.mehta@huawei.com,
linuxarm@huawei.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1564368811-65492-1-git-send-email-tanhuazhong@huawei.com>
On Mon, 2019-07-29 at 10:53 +0800, Huazhong Tan wrote:
> This patch-set includes code optimizations, bugfixes and features for
> the HNS3 ethernet controller driver.
>
> [patch 1/10] checks reset status before setting channel.
>
> [patch 2/10] adds a NULL pointer checking.
>
> [patch 3/10] removes reset level upgrading when current reset fails.
>
> [patch 4/10] fixes a GFP flags errors when holding spin_lock.
>
> [patch 5/10] modifies firmware version format.
>
> [patch 6/10] adds some print information which is off by default.
>
> [patch 7/10 - 8/10] adds two code optimizations about interrupt
> handler
> and work task.
>
> [patch 9/10] adds support for using order 1 pages with a 4K buffer.
>
> [patch 10/10] modifies messages prints with dev_info() instead of
> pr_info().
>
> Change log:
> V3->V4: replace netif_info with netif_dbg in [patch 6/10]
> V2->V3: fixes comments from Saeed Mahameed and Joe Perches.
> V1->V2: fixes comments from Saeed Mahameed and
> removes previous [patch 4/11] and [patch 11/11]
> which needs further discussion, and adds a new
> patch [10/10] suggested by Saeed Mahameed.
>
Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
^ permalink raw reply
* Re: [PATCH] net: bridge: Allow bridge to joing multicast groups
From: Ido Schimmel @ 2019-07-29 6:09 UTC (permalink / raw)
To: Allan W. Nielsen
Cc: Andrew Lunn, Horatiu Vultur, Nikolay Aleksandrov, roopa, davem,
bridge, netdev, linux-kernel
In-Reply-To: <20190728191558.zuopgfqza2iz5d5b@lx-anielsen.microsemi.net>
On Sun, Jul 28, 2019 at 09:15:59PM +0200, Allan W. Nielsen wrote:
> If we assume that the SwitchDev driver implemented such that all multicast
> traffic goes to the CPU, then we should really have a way to install a HW
> offload path in the silicon, such that these packets does not go to the CPU (as
> they are known not to be use full, and a frame every 3 us is a significant load
> on small DMA connections and CPU resources).
>
> If we assume that the SwitchDev driver implemented such that only "needed"
> multicast packets goes to the CPU, then we need a way to get these packets in
> case we want to implement the DLR protocol.
I'm not familiar with the HW you're working with, so the below might not
be relevant.
In case you don't want to send all multicast traffic to the CPU (I'll
refer to it later), you can install an ingress tc filter that traps to
the CPU the packets you do want to receive. Something like:
# tc qdisc add dev swp1 clsact
# tc filter add dev swp1 pref 1 ingress flower skip_sw dst_mac \
01:21:6C:00:00:01 action trap
If your HW supports sharing the same filter among multiple ports, then
you can install your filter in a tc shared block and bind multiple ports
to it.
Another option is to always send a *copy* of multicast packets to the
CPU, but make sure the HW uses a policer that prevents the CPU from
being overwhelmed. To avoid packets being forwarded twice (by HW and
SW), you will need to mark such packets in your driver with
'skb->offload_fwd_mark = 1'.
Now, in case user wants to allow the CPU to receive certain packets at a
higher rate, a tc filter can be used. It will be identical to the filter
I mentioned earlier, but with a 'police' action chained before 'trap'.
I don't think this is currently supported by any driver, but I believe
it's the right way to go: By default the CPU receives all the traffic it
should receive and user can fine-tune it using ACLs.
^ permalink raw reply
* Re: [PATCH net-next] rt2800usb: Add new rt2800usb device PLANEX GW-USMicroN
From: Stanislaw Gruszka @ 2019-07-29 6:46 UTC (permalink / raw)
To: Masanari Iida
Cc: helmut.schaa, kvalo, davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <20190728140742.3280-1-standby24x7@gmail.com>
On Sun, Jul 28, 2019 at 11:07:42PM +0900, Masanari Iida wrote:
> This patch add a device ID for PLANEX GW-USMicroN.
> Without this patch, I had to echo the device IDs in order to
> recognize the device.
>
> # lsusb |grep PLANEX
> Bus 002 Device 005: ID 2019:ed14 PLANEX GW-USMicroN
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
^ permalink raw reply
* Re: [PATCH] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jiri Pirko @ 2019-07-29 6:56 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: jhs, xiyou.wangcong, davem, netdev, linux-kernel
In-Reply-To: <20190729022157.18090-1-baijiaju1990@gmail.com>
Mon, Jul 29, 2019 at 04:21:57AM CEST, baijiaju1990@gmail.com wrote:
>In dequeue_func(), there is an if statement on line 74 to check whether
>skb is NULL:
> if (skb)
>
>When skb is NULL, it is used on line 77:
> prefetch(&skb->end);
>
>Thus, a possible null-pointer dereference may occur.
>
>To fix this bug, skb->end is used when skb is not NULL.
>
>This bug is found by a static analysis tool STCheck written by us.
>
>Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Fixes tag, please?
>---
> net/sched/sch_codel.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/net/sched/sch_codel.c b/net/sched/sch_codel.c
>index 25ef172c23df..30169b3adbbb 100644
>--- a/net/sched/sch_codel.c
>+++ b/net/sched/sch_codel.c
>@@ -71,10 +71,10 @@ static struct sk_buff *dequeue_func(struct codel_vars *vars, void *ctx)
> struct Qdisc *sch = ctx;
> struct sk_buff *skb = __qdisc_dequeue_head(&sch->q);
>
>- if (skb)
>+ if (skb) {
> sch->qstats.backlog -= qdisc_pkt_len(skb);
>-
>- prefetch(&skb->end); /* we'll need skb_shinfo() */
>+ prefetch(&skb->end); /* we'll need skb_shinfo() */
>+ }
> return skb;
> }
>
>--
>2.17.0
>
^ permalink raw reply
* Re: [PATCH net-next v4 2/3] flow_offload: Support get default block from tc immediately
From: wenxu @ 2019-07-29 7:05 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: pablo, fw, netfilter-devel, netdev
In-Reply-To: <20190728214237.2c0687db@cakuba.netronome.com>
On 7/29/2019 12:42 PM, Jakub Kicinski wrote:
> On Mon, 29 Jul 2019 10:43:56 +0800, wenxu wrote:
>> On 7/29/2019 4:16 AM, Jakub Kicinski wrote:
>>> I don't know the nft code, but it seems unlikely it wouldn't have the
>>> same problem/need..
>> nft don't have the same problem. The offload rule can only attached
>> to offload base chain.
>>
>> Th offload base chain is created after the device driver loaded (the
>> device exist).
> For indirect blocks the block is on the tunnel device and the offload
> target is another device. E.g. you offload rules from a VXLAN device
> onto the ASIC. The ASICs driver does not have to be loaded when VXLAN
> device is created.
>
> So I feel like either the chain somehow directly references the offload
> target (in which case the indirect infrastructure with hash lookup etc
> is not needed for nft), or indirect infra is needed, and we need to take
> care of replays.
So you mean the case is there are two card A and B both can offload vxlan.
First vxlan device offload with A. And then the B driver loaded, So the rules
should replay to B device?
^ permalink raw reply
* RE: [PATCH net-next v3 0/2] qed*: Support for NVM config attributes.
From: Sudarsana Reddy Kalluru @ 2019-07-29 7:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Michal Kalderon, Ariel Elior
In-Reply-To: <20190727.191328.1351271863559760336.davem@davemloft.net>
> -----Original Message-----
> From: David Miller <davem@davemloft.net>
> Sent: Sunday, July 28, 2019 7:43 AM
> To: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> Cc: netdev@vger.kernel.org; Michal Kalderon <mkalderon@marvell.com>;
> Ariel Elior <aelior@marvell.com>
> Subject: Re: [PATCH net-next v3 0/2] qed*: Support for NVM config
> attributes.
>
> From: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> Date: Sat, 27 Jul 2019 18:55:47 -0700
>
> > The patch series adds support for managing the NVM config attributes.
> > Patch (1) adds functionality to update config attributes via MFW.
> > Patch (2) adds driver interface for updating the config attributes.
> >
> > Changes from previous versions:
> > -------------------------------
> > v3: Removed unused variable.
> > v2: Removed unused API.
> >
> > Please consider applying this series to "net-next".
>
> I don't see where an existing ethtool method hooks into and calls this new
> NVM code.
Dave,
The new API/functionality is invoked as part of ethtool flash (ethtool -f) implementation.
Example code path:
ethtool_ops-->flash_device--> qede_flash_device() --> qed_nvm_flash() --> qed_nvm_flash_cfg_write() --> qed_mcp_nvm_set_cfg()
Thanks,
Sudarsana
^ permalink raw reply
* Re: [PATCH net-next v4 2/3] flow_offload: Support get default block from tc immediately
From: wenxu @ 2019-07-29 7:18 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: pablo, fw, netfilter-devel, netdev
In-Reply-To: <20190728214237.2c0687db@cakuba.netronome.com>
On 7/29/2019 12:42 PM, Jakub Kicinski wrote:
> On Mon, 29 Jul 2019 10:43:56 +0800, wenxu wrote:
>> On 7/29/2019 4:16 AM, Jakub Kicinski wrote:
>>> I don't know the nft code, but it seems unlikely it wouldn't have the
>>> same problem/need..
>> nft don't have the same problem. The offload rule can only attached
>> to offload base chain.
>>
>> Th offload base chain is created after the device driver loaded (the
>> device exist).
> For indirect blocks the block is on the tunnel device and the offload
> target is another device. E.g. you offload rules from a VXLAN device
> onto the ASIC. The ASICs driver does not have to be loaded when VXLAN
> device is created.
>
> So I feel like either the chain somehow directly references the offload
> target (in which case the indirect infrastructure with hash lookup etc
> is not needed for nft), or indirect infra is needed, and we need to take
> care of replays.
I think the nft is different with tc.
In tc case we can create vxlan device add a ingress qdisc with a block success
Then the ASIC driver loaded, then register the vxlan indr-dev and get the block
adn replay it to hardware
But in the nft case, The base chain flags with offload. Create an offload netdev
base chain on vxlan device will fail if there is no indr-device to offload.
^ permalink raw reply
* Re: [PATCH] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jia-Ju Bai @ 2019-07-29 7:32 UTC (permalink / raw)
To: Jiri Pirko; +Cc: jhs, xiyou.wangcong, davem, netdev, linux-kernel
In-Reply-To: <20190729065653.GA2211@nanopsycho>
On 2019/7/29 14:56, Jiri Pirko wrote:
> Mon, Jul 29, 2019 at 04:21:57AM CEST, baijiaju1990@gmail.com wrote:
>> In dequeue_func(), there is an if statement on line 74 to check whether
>> skb is NULL:
>> if (skb)
>>
>> When skb is NULL, it is used on line 77:
>> prefetch(&skb->end);
>>
>> Thus, a possible null-pointer dereference may occur.
>>
>> To fix this bug, skb->end is used when skb is not NULL.
>>
>> This bug is found by a static analysis tool STCheck written by us.
>>
>> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
> Fixes tag, please?
Sorry, I do not know what "fixes tag" means...
I just find a possible bug and fix it in this patch.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jiri Pirko @ 2019-07-29 7:41 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: jhs, xiyou.wangcong, davem, netdev, linux-kernel
In-Reply-To: <4752bf67-7a0c-7bc9-3d54-f18361085ba2@gmail.com>
Mon, Jul 29, 2019 at 09:32:00AM CEST, baijiaju1990@gmail.com wrote:
>
>
>On 2019/7/29 14:56, Jiri Pirko wrote:
>> Mon, Jul 29, 2019 at 04:21:57AM CEST, baijiaju1990@gmail.com wrote:
>> > In dequeue_func(), there is an if statement on line 74 to check whether
>> > skb is NULL:
>> > if (skb)
>> >
>> > When skb is NULL, it is used on line 77:
>> > prefetch(&skb->end);
>> >
>> > Thus, a possible null-pointer dereference may occur.
>> >
>> > To fix this bug, skb->end is used when skb is not NULL.
>> >
>> > This bug is found by a static analysis tool STCheck written by us.
>> >
>> > Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
>> Fixes tag, please?
>
>Sorry, I do not know what "fixes tag" means...
>I just find a possible bug and fix it in this patch.
git log |grep Fixes:
If A fix goes to -net tree, it most probably fixes some bug introduced
by some commit in the past. So this tag is to put a reference.
>
>
>Best wishes,
>Jia-Ju Bai
^ permalink raw reply
* [PATCH iproute2-rc 0/2] Control CQ adaptive moderation (RDMA DIM)
From: Leon Romanovsky @ 2019-07-29 7:42 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Leon Romanovsky, netdev, David Ahern, RDMA mailing list,
Yamin Friedman
From: Leon Romanovsky <leonro@mellanox.com>
Hi,
This is supplementary part of RDMA DIM feature [1] accepted
for the kernel v5.3. In this patch set Yamin extends rdmatool
to get/set as a default this adaptive-moderation setting on
IB device level and provides an information about DIM on/off
status per-CQ.
Thanks
[1] https://lore.kernel.org/linux-rdma/20190708105905.27468-1-leon@kernel.org/
Yamin Friedman (2):
rdma: Control CQ adaptive moderation (DIM)
rdma: Document adaptive-moderation
man/man8/rdma-dev.8 | 16 ++++++++++++-
rdma/dev.c | 55 ++++++++++++++++++++++++++++++++++++++++++++-
rdma/rdma.h | 1 +
rdma/res-cq.c | 15 +++++++++++++
rdma/utils.c | 6 +++++
5 files changed, 91 insertions(+), 2 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH iproute2-rc 1/2] rdma: Control CQ adaptive moderation (DIM)
From: Leon Romanovsky @ 2019-07-29 7:42 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Leon Romanovsky, netdev, David Ahern, RDMA mailing list,
Yamin Friedman
In-Reply-To: <20190729074226.4335-1-leon@kernel.org>
From: Yamin Friedman <yaminf@mellanox.com>
In order to set adaptive-moderation for an ib device the command is:
rdma dev set [DEV] adaptive-moderation [on|off]
rdma dev show -d
0: mlx5_0: node_type ca fw 16.25.0319 node_guid 248a:0703:00a5:29d0
sys_image_guid 248a:0703:00a5:29d0 adaptive-moderation on
caps: <BAD_PKEY_CNTR, BAD_QKEY_CNTR, AUTO_PATH_MIG, CHANGE_PHY_PORT,
PORT_ACTIVE_EVENT, SYS_IMAGE_GUID, RC_RNR_NAK_GEN, MEM_WINDOW, XRC,
MEM_MGT_EXTENSIONS, BLOCK_MULTICAST_LOOPBACK, MEM_WINDOW_TYPE_2B,
RAW_IP_CSUM, CROSS_CHANNEL, MANAGED_FLOW_STEERING, SIGNATURE_HANDOVER,
ON_DEMAND_PAGING, SG_GAPS_REG, RAW_SCATTER_FCS, PCI_WRITE_END_PADDING>
rdma resource show cq
dev mlx5_0 cqn 0 cqe 1023 users 4 poll-ctx UNBOUND_WORKQUEUE
adaptive-moderation off comm [ib_core]
Signed-off-by: Yamin Friedman <yaminf@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
rdma/dev.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++-
rdma/rdma.h | 1 +
rdma/res-cq.c | 15 ++++++++++++++
rdma/utils.c | 6 ++++++
4 files changed, 76 insertions(+), 1 deletion(-)
diff --git a/rdma/dev.c b/rdma/dev.c
index d28bf6b3..c597cba5 100644
--- a/rdma/dev.c
+++ b/rdma/dev.c
@@ -12,6 +12,7 @@ static int dev_help(struct rd *rd)
pr_out("Usage: %s dev show [DEV]\n", rd->filename);
pr_out(" %s dev set [DEV] name DEVNAME\n", rd->filename);
pr_out(" %s dev set [DEV] netns NSNAME\n", rd->filename);
+ pr_out(" %s dev set [DEV] adaptive-moderation [on|off]\n", rd->filename);
return 0;
}
@@ -167,6 +168,21 @@ static void dev_print_sys_image_guid(struct rd *rd, struct nlattr **tb)
pr_out("sys_image_guid %s ", str);
}
+static void dev_print_dim_setting(struct rd *rd, struct nlattr **tb)
+{
+ uint8_t dim_setting;
+
+ if (!tb[RDMA_NLDEV_ATTR_DEV_DIM])
+ return;
+
+ dim_setting = mnl_attr_get_u8(tb[RDMA_NLDEV_ATTR_DEV_DIM]);
+ if (dim_setting > 1)
+ return;
+
+ print_on_off(rd, "adaptive-moderation", dim_setting);
+
+}
+
static const char *node_type_to_str(uint8_t node_type)
{
static const char * const node_type_str[] = { "unknown", "ca",
@@ -219,8 +235,10 @@ static int dev_parse_cb(const struct nlmsghdr *nlh, void *data)
dev_print_fw(rd, tb);
dev_print_node_guid(rd, tb);
dev_print_sys_image_guid(rd, tb);
- if (rd->show_details)
+ if (rd->show_details) {
+ dev_print_dim_setting(rd, tb);
dev_print_caps(rd, tb);
+ }
if (!rd->json_output)
pr_out("\n");
@@ -308,12 +326,47 @@ done:
return ret;
}
+static int dev_set_dim_sendmsg(struct rd *rd, uint8_t dim_setting)
+{
+ uint32_t seq;
+
+ rd_prepare_msg(rd, RDMA_NLDEV_CMD_SET, &seq,
+ (NLM_F_REQUEST | NLM_F_ACK));
+ mnl_attr_put_u32(rd->nlh, RDMA_NLDEV_ATTR_DEV_INDEX, rd->dev_idx);
+ mnl_attr_put_u8(rd->nlh, RDMA_NLDEV_ATTR_DEV_DIM, dim_setting);
+
+ return rd_sendrecv_msg(rd, seq);
+}
+
+static int dev_set_dim_off(struct rd *rd)
+{
+ return dev_set_dim_sendmsg(rd, 0);
+}
+
+static int dev_set_dim_on(struct rd *rd)
+{
+ return dev_set_dim_sendmsg(rd, 1);
+}
+
+static int dev_set_dim(struct rd *rd)
+{
+ const struct rd_cmd cmds[] = {
+ { NULL, dev_help},
+ { "on", dev_set_dim_on},
+ { "off", dev_set_dim_off},
+ { 0 }
+ };
+
+ return rd_exec_cmd(rd, cmds, "parameter");
+}
+
static int dev_one_set(struct rd *rd)
{
const struct rd_cmd cmds[] = {
{ NULL, dev_help},
{ "name", dev_set_name},
{ "netns", dev_set_netns},
+ { "adaptive-moderation", dev_set_dim},
{ 0 }
};
diff --git a/rdma/rdma.h b/rdma/rdma.h
index 23157743..dfd1b70b 100644
--- a/rdma/rdma.h
+++ b/rdma/rdma.h
@@ -136,6 +136,7 @@ int rd_attr_check(const struct nlattr *attr, int *typep);
void print_driver_table(struct rd *rd, struct nlattr *tb);
void newline(struct rd *rd);
void newline_indent(struct rd *rd);
+void print_on_off(struct rd *rd, const char *key_str, bool on);
#define MAX_LINE_LENGTH 80
#endif /* _RDMA_TOOL_H_ */
diff --git a/rdma/res-cq.c b/rdma/res-cq.c
index 5afb97c5..d2591fbe 100644
--- a/rdma/res-cq.c
+++ b/rdma/res-cq.c
@@ -30,6 +30,20 @@ static void print_poll_ctx(struct rd *rd, uint8_t poll_ctx, struct nlattr *attr)
pr_out("poll-ctx %s ", poll_ctx_to_str(poll_ctx));
}
+static void print_cq_dim_setting(struct rd *rd, struct nlattr *attr)
+{
+ uint8_t dim_setting;
+
+ if (!attr)
+ return;
+
+ dim_setting = mnl_attr_get_u8(attr);
+ if (dim_setting > 1)
+ return;
+
+ print_on_off(rd, "adaptive-moderation", dim_setting);
+}
+
static int res_cq_line(struct rd *rd, const char *name, int idx,
struct nlattr **nla_line)
{
@@ -97,6 +111,7 @@ static int res_cq_line(struct rd *rd, const char *name, int idx,
res_print_uint(rd, "users", users,
nla_line[RDMA_NLDEV_ATTR_RES_USECNT]);
print_poll_ctx(rd, poll_ctx, nla_line[RDMA_NLDEV_ATTR_RES_POLL_CTX]);
+ print_cq_dim_setting(rd, nla_line[RDMA_NLDEV_ATTR_DEV_DIM]);
res_print_uint(rd, "ctxn", ctxn, nla_line[RDMA_NLDEV_ATTR_RES_CTXN]);
res_print_uint(rd, "pid", pid, nla_line[RDMA_NLDEV_ATTR_RES_PID]);
print_comm(rd, comm, nla_line);
diff --git a/rdma/utils.c b/rdma/utils.c
index 95b669f3..37659011 100644
--- a/rdma/utils.c
+++ b/rdma/utils.c
@@ -449,6 +449,7 @@ static const enum mnl_attr_data_type nldev_policy[RDMA_NLDEV_ATTR_MAX] = {
[RDMA_NLDEV_ATTR_STAT_MODE] = MNL_TYPE_U32,
[RDMA_NLDEV_ATTR_STAT_RES] = MNL_TYPE_U32,
[RDMA_NLDEV_ATTR_STAT_AUTO_MODE_MASK] = MNL_TYPE_U32,
+ [RDMA_NLDEV_ATTR_DEV_DIM] = MNL_TYPE_U8,
};
int rd_attr_check(const struct nlattr *attr, int *typep)
@@ -789,6 +790,11 @@ static int print_driver_string(struct rd *rd, const char *key_str,
}
}
+void print_on_off(struct rd *rd, const char *key_str, bool on)
+{
+ print_driver_string(rd, key_str, (on) ? "on":"off");
+}
+
static int print_driver_s32(struct rd *rd, const char *key_str, int32_t val,
enum rdma_nldev_print_type print_type)
{
--
2.20.1
^ permalink raw reply related
* [PATCH iproute2-rc 2/2] rdma: Document adaptive-moderation
From: Leon Romanovsky @ 2019-07-29 7:42 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Leon Romanovsky, netdev, David Ahern, RDMA mailing list,
Yamin Friedman
In-Reply-To: <20190729074226.4335-1-leon@kernel.org>
From: Yamin Friedman <yaminf@mellanox.com>
Add document of setting the adaptive-moderation for the ib device.
Signed-off-by: Yamin Friedman <yaminf@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
man/man8/rdma-dev.8 | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/man/man8/rdma-dev.8 b/man/man8/rdma-dev.8
index e77e7cd0..368cdc7c 100644
--- a/man/man8/rdma-dev.8
+++ b/man/man8/rdma-dev.8
@@ -34,11 +34,17 @@ rdma-dev \- RDMA device configuration
.BR netns
.BR NSNAME
+.ti -8
+.B rdma dev set
+.RI "[ " DEV " ]"
+.BR adaptive-moderation
+.BR [on/off]
+
.ti -8
.B rdma dev help
.SH "DESCRIPTION"
-.SS rdma dev set - rename RDMA device or set network namespace
+.SS rdma dev set - rename RDMA device or set network namespace or set RDMA device adaptive-moderation
.SS rdma dev show - display RDMA device attributes
@@ -70,6 +76,14 @@ Changes the network namespace of RDMA device to foo where foo is
previously created using iproute2 ip command.
.RE
.PP
+rdma dev set mlx5_3 adaptive-moderation [on/off]
+.RS 4
+Sets the state of adaptive interrupt moderation for the RDMA device.
+.RE
+.RS 4
+This is a global setting for the RDMA device but the value is printed for each CQ individually because the state is constant from CQ allocation.
+.RE
+.PP
.SH SEE ALSO
.BR ip (8),
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 1/1] qed[net-next] Add new ethtool supported port types based on media.
From: Rahul Verma @ 2019-07-29 7:49 UTC (permalink / raw)
To: davem; +Cc: netdev, aelior, mkalderon
Supported ports in ethtool <eth1> are displayed based on media type.
For media type fibre and twinaxial, port type is "FIBRE". Media type
Base-T is "TP" and media KR is "Backplane".
Signed-off-by: Rahul Verma <rahulv@marvell.com>
Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
---
drivers/net/ethernet/qlogic/qed/qed_main.c | 6 +++++-
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 3 ++-
include/linux/qed/qed_if.h | 2 +-
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 829dd60..e5ac8bd 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -1688,6 +1688,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
switch (media_type) {
case MEDIA_DA_TWINAX:
+ *if_capability |= QED_LM_FIBRE_BIT;
if (capability & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_20G)
*if_capability |= QED_LM_20000baseKR2_Full_BIT;
/* For DAC media multiple speed capabilities are supported*/
@@ -1707,6 +1708,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
*if_capability |= QED_LM_100000baseCR4_Full_BIT;
break;
case MEDIA_BASE_T:
+ *if_capability |= QED_LM_TP_BIT;
if (board_cfg & NVM_CFG1_PORT_PORT_TYPE_EXT_PHY) {
if (capability &
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_1G) {
@@ -1718,6 +1720,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
}
}
if (board_cfg & NVM_CFG1_PORT_PORT_TYPE_MODULE) {
+ *if_capability |= QED_LM_FIBRE_BIT;
if (tcvr_type == ETH_TRANSCEIVER_TYPE_1000BASET)
*if_capability |= QED_LM_1000baseT_Full_BIT;
if (tcvr_type == ETH_TRANSCEIVER_TYPE_10G_BASET)
@@ -1728,6 +1731,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
case MEDIA_SFPP_10G_FIBER:
case MEDIA_XFP_FIBER:
case MEDIA_MODULE_FIBER:
+ *if_capability |= QED_LM_FIBRE_BIT;
if (capability &
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_1G) {
if ((tcvr_type == ETH_TRANSCEIVER_TYPE_1G_LX) ||
@@ -1770,6 +1774,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
break;
case MEDIA_KR:
+ *if_capability |= QED_LM_Backplane_BIT;
if (capability & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_20G)
*if_capability |= QED_LM_20000baseKR2_Full_BIT;
if (capability &
@@ -1821,7 +1826,6 @@ static void qed_fill_link(struct qed_hwfn *hwfn,
if_link->link_up = true;
/* TODO - at the moment assume supported and advertised speed equal */
- if_link->supported_caps = QED_LM_FIBRE_BIT;
if (link_caps.default_speed_autoneg)
if_link->supported_caps |= QED_LM_Autoneg_BIT;
if (params.pause.autoneg ||
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index e85f9fe..abcee47 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -424,12 +424,13 @@ struct qede_link_mode_mapping {
};
static const struct qede_link_mode_mapping qed_lm_map[] = {
+ {QED_LM_FIBRE_BIT, ETHTOOL_LINK_MODE_FIBRE_BIT},
{QED_LM_Autoneg_BIT, ETHTOOL_LINK_MODE_Autoneg_BIT},
{QED_LM_Asym_Pause_BIT, ETHTOOL_LINK_MODE_Asym_Pause_BIT},
{QED_LM_Pause_BIT, ETHTOOL_LINK_MODE_Pause_BIT},
{QED_LM_1000baseT_Full_BIT, ETHTOOL_LINK_MODE_1000baseT_Full_BIT},
{QED_LM_10000baseT_Full_BIT, ETHTOOL_LINK_MODE_10000baseT_Full_BIT},
- {QED_LM_2500baseX_Full_BIT, ETHTOOL_LINK_MODE_2500baseX_Full_BIT},
+ {QED_LM_TP_BIT, ETHTOOL_LINK_MODE_TP_BIT},
{QED_LM_Backplane_BIT, ETHTOOL_LINK_MODE_Backplane_BIT},
{QED_LM_1000baseKX_Full_BIT, ETHTOOL_LINK_MODE_1000baseKX_Full_BIT},
{QED_LM_10000baseKX4_Full_BIT, ETHTOOL_LINK_MODE_10000baseKX4_Full_BIT},
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index eef02e6..2302136 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -689,7 +689,7 @@ enum qed_link_mode_bits {
QED_LM_40000baseLR4_Full_BIT = BIT(9),
QED_LM_50000baseKR2_Full_BIT = BIT(10),
QED_LM_100000baseKR4_Full_BIT = BIT(11),
- QED_LM_2500baseX_Full_BIT = BIT(12),
+ QED_LM_TP_BIT = BIT(12),
QED_LM_Backplane_BIT = BIT(13),
QED_LM_1000baseKX_Full_BIT = BIT(14),
QED_LM_10000baseKX4_Full_BIT = BIT(15),
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jia-Ju Bai @ 2019-07-29 7:59 UTC (permalink / raw)
To: Jiri Pirko; +Cc: jhs, xiyou.wangcong, davem, netdev, linux-kernel
In-Reply-To: <20190729074125.GB2211@nanopsycho>
On 2019/7/29 15:41, Jiri Pirko wrote:
> Mon, Jul 29, 2019 at 09:32:00AM CEST, baijiaju1990@gmail.com wrote:
>>
>> On 2019/7/29 14:56, Jiri Pirko wrote:
>>> Mon, Jul 29, 2019 at 04:21:57AM CEST, baijiaju1990@gmail.com wrote:
>>>> In dequeue_func(), there is an if statement on line 74 to check whether
>>>> skb is NULL:
>>>> if (skb)
>>>>
>>>> When skb is NULL, it is used on line 77:
>>>> prefetch(&skb->end);
>>>>
>>>> Thus, a possible null-pointer dereference may occur.
>>>>
>>>> To fix this bug, skb->end is used when skb is not NULL.
>>>>
>>>> This bug is found by a static analysis tool STCheck written by us.
>>>>
>>>> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
>>> Fixes tag, please?
>> Sorry, I do not know what "fixes tag" means...
>> I just find a possible bug and fix it in this patch.
> git log |grep Fixes:
>
> If A fix goes to -net tree, it most probably fixes some bug introduced
> by some commit in the past. So this tag is to put a reference.
Thanks for the explanation.
I will add it and submit a v2 patch.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* [PATCH v2] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jia-Ju Bai @ 2019-07-29 8:00 UTC (permalink / raw)
To: jhs, xiyou.wangcong, jiri, davem; +Cc: netdev, linux-kernel, Jia-Ju Bai
In dequeue_func(), there is an if statement on line 74 to check whether
skb is NULL:
if (skb)
When skb is NULL, it is used on line 77:
prefetch(&skb->end);
Thus, a possible null-pointer dereference may occur.
To fix this bug, skb->end is used when skb is not NULL.
This bug is found by a static analysis tool STCheck written by us.
Fixes: 79bdc4c862af ("codel: generalize the implementation")
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
v2:
* Add a fix tag.
Thank Jiri Pirko for helpful advice.
---
net/sched/sch_codel.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/sched/sch_codel.c b/net/sched/sch_codel.c
index 25ef172c23df..30169b3adbbb 100644
--- a/net/sched/sch_codel.c
+++ b/net/sched/sch_codel.c
@@ -71,10 +71,10 @@ static struct sk_buff *dequeue_func(struct codel_vars *vars, void *ctx)
struct Qdisc *sch = ctx;
struct sk_buff *skb = __qdisc_dequeue_head(&sch->q);
- if (skb)
+ if (skb) {
sch->qstats.backlog -= qdisc_pkt_len(skb);
-
- prefetch(&skb->end); /* we'll need skb_shinfo() */
+ prefetch(&skb->end); /* we'll need skb_shinfo() */
+ }
return skb;
}
--
2.17.0
^ permalink raw reply related
* Re: [BUG] net: xfrm: possible null-pointer dereferences in xfrm_policy()
From: Steffen Klassert @ 2019-07-29 8:03 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: herbert, davem, netdev, linux-kernel
In-Reply-To: <464bb93d-75b2-c21b-ee32-25a10ff61622@gmail.com>
On Mon, Jul 29, 2019 at 11:43:49AM +0800, Jia-Ju Bai wrote:
> In xfrm_policy(), the while loop on lines 3802-3830 ends when dst->xfrm is
> NULL.
We don't have a xfrm_policy() function, and as said already the
line numbers does not help much as long as you don't say which
tree/branch this is and which commit is the head commit.
> Then, dst->xfrm is used on line 3840:
> xfrm_state_mtu(dst->xfrm, mtu);
> if (x->km.state != XFRM_STATE_VALID...)
> aead = x->data;
>
> Thus, possible null-pointer dereferences may occur.
I guess you refer to xfrm_bundle_ok(). The dst pointer
is reoaded after the loop, so the dereferenced pointer
is not the one that had NULL at dst->xfrm.
>
> These bugs are found by a static analysis tool STCheck written by us.
>
> I do not know how to correctly fix these bugs, so I only report them.
I'd suggest you to manually review the reports of your
tool and to fix the tool accordingly.
^ permalink raw reply
* Re: [BUG] net: xfrm: possible null-pointer dereferences in xfrm_policy()
From: Jia-Ju Bai @ 2019-07-29 8:06 UTC (permalink / raw)
To: Steffen Klassert; +Cc: herbert, davem, netdev, linux-kernel
In-Reply-To: <20190729080341.GJ2879@gauss3.secunet.de>
On 2019/7/29 16:03, Steffen Klassert wrote:
> On Mon, Jul 29, 2019 at 11:43:49AM +0800, Jia-Ju Bai wrote:
>> In xfrm_policy(), the while loop on lines 3802-3830 ends when dst->xfrm is
>> NULL.
> We don't have a xfrm_policy() function, and as said already the
> line numbers does not help much as long as you don't say which
> tree/branch this is and which commit is the head commit.
>
>> Then, dst->xfrm is used on line 3840:
>> xfrm_state_mtu(dst->xfrm, mtu);
>> if (x->km.state != XFRM_STATE_VALID...)
>> aead = x->data;
>>
>> Thus, possible null-pointer dereferences may occur.
> I guess you refer to xfrm_bundle_ok(). The dst pointer
> is reoaded after the loop, so the dereferenced pointer
> is not the one that had NULL at dst->xfrm.
>
>> These bugs are found by a static analysis tool STCheck written by us.
>>
>> I do not know how to correctly fix these bugs, so I only report them.
> I'd suggest you to manually review the reports of your
> tool and to fix the tool accordingly.
Oh, sorry for my mistakes.
I have found that dst is updated:
dst = &xdst->u.dst;
I will fix my tool, thanks.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* Re: memory leak in __nf_hook_entries_try_shrink
From: syzbot @ 2019-07-29 8:16 UTC (permalink / raw)
To: catalin.marinas, coreteam, davem, deller, fw, jejb, kadlec,
linux-kernel, linux-mm, linux-parisc, mingo, netdev,
netfilter-devel, pablo, rostedt, syzkaller-bugs
In-Reply-To: <0000000000005718ef058b3a0fcf@google.com>
syzbot has bisected this bug to:
commit fc79168a7c75423047d60a033dc4844955ccae0b
Author: Helge Deller <deller@gmx.de>
Date: Wed Apr 13 20:44:54 2016 +0000
parisc: Add syscall tracepoint support
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16ad2cd8600000
start commit: b076173a Merge tag 'selinux-pr-20190612' of git://git.kern..
git tree: upstream
final crash: https://syzkaller.appspot.com/x/report.txt?x=15ad2cd8600000
console output: https://syzkaller.appspot.com/x/log.txt?x=11ad2cd8600000
kernel config: https://syzkaller.appspot.com/x/.config?x=cb38d33cd06d8d48
dashboard link: https://syzkaller.appspot.com/bug?extid=c51f73e78e7e2ce3a31e
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=105a958ea00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=103c758ea00000
Reported-by: syzbot+c51f73e78e7e2ce3a31e@syzkaller.appspotmail.com
Fixes: fc79168a7c75 ("parisc: Add syscall tracepoint support")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply
* RE: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jose Abreu @ 2019-07-29 8:16 UTC (permalink / raw)
To: Jon Hunter, Jose Abreu, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Cc: Joao Pinto, Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai,
Maxime Coquelin, linux-tegra, Giuseppe Cavallaro, Robin Murphy,
David S . Miller
In-Reply-To: <BYAPR12MB326922CDCB1D4B3D4A780CFDD3C30@BYAPR12MB3269.namprd12.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]
From: Jose Abreu <joabreu@synopsys.com>
Date: Jul/27/2019, 16:56:37 (UTC+00:00)
> From: Jon Hunter <jonathanh@nvidia.com>
> Date: Jul/26/2019, 15:11:00 (UTC+00:00)
>
> >
> > On 25/07/2019 16:12, Jose Abreu wrote:
> > > From: Jon Hunter <jonathanh@nvidia.com>
> > > Date: Jul/25/2019, 15:25:59 (UTC+00:00)
> > >
> > >>
> > >> On 25/07/2019 14:26, Jose Abreu wrote:
> > >>
> > >> ...
> > >>
> > >>> Well, I wasn't expecting that :/
> > >>>
> > >>> Per documentation of barriers I think we should set descriptor fields
> > >>> and then barrier and finally ownership to HW so that remaining fields
> > >>> are coherent before owner is set.
> > >>>
> > >>> Anyway, can you also add a dma_rmb() after the call to
> > >>> stmmac_rx_status() ?
> > >>
> > >> Yes. I removed the debug print added the barrier, but that did not help.
> > >
> > > So, I was finally able to setup NFS using your replicated setup and I
> > > can't see the issue :(
> > >
> > > The only difference I have from yours is that I'm using TCP in NFS
> > > whilst you (I believe from the logs), use UDP.
> >
> > So I tried TCP by setting the kernel boot params to 'nfsvers=3' and
> > 'proto=tcp' and this does appear to be more stable, but not 100% stable.
> > It still appears to fail in the same place about 50% of the time.
> >
> > > You do have flow control active right ? And your HW FIFO size is >= 4k ?
> >
> > How can I verify if flow control is active?
>
> You can check it by dumping register MTL_RxQ_Operation_Mode (0xd30).
>
> Can you also add IOMMU debug in file "drivers/iommu/iommu.c" ?
And, please try attached debug patch.
---
Thanks,
Jose Miguel Abreu
[-- Attachment #2: 0001-net-page_pool-Do-not-skip-CPU-sync.patch --]
[-- Type: application/octet-stream, Size: 1532 bytes --]
From d203a4f055a36ae20efbcee7cdf70ce13fff12c9 Mon Sep 17 00:00:00 2001
Message-Id: <d203a4f055a36ae20efbcee7cdf70ce13fff12c9.1564388075.git.joabreu@synopsys.com>
From: Jose Abreu <joabreu@synopsys.com>
Date: Mon, 29 Jul 2019 10:14:21 +0200
Subject: [PATCH net] net: page_pool: Do not skip CPU sync
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Jesper Dangaard Brouer <hawk@kernel.org>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
net/core/page_pool.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index 3272dc7a8c81..0262fcdf217e 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -156,7 +156,7 @@ static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool,
*/
dma = dma_map_page_attrs(pool->p.dev, page, 0,
(PAGE_SIZE << pool->p.order),
- pool->p.dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
+ pool->p.dma_dir, 0);
if (dma_mapping_error(pool->p.dev, dma)) {
put_page(page);
return NULL;
@@ -230,8 +230,7 @@ static void __page_pool_clean_page(struct page_pool *pool,
dma = page->dma_addr;
/* DMA unmap */
dma_unmap_page_attrs(pool->p.dev, dma,
- PAGE_SIZE << pool->p.order, pool->p.dma_dir,
- DMA_ATTR_SKIP_CPU_SYNC);
+ PAGE_SIZE << pool->p.order, pool->p.dma_dir, 0);
page->dma_addr = 0;
skip_dma_unmap:
atomic_inc(&pool->pages_state_release_cnt);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jiri Pirko @ 2019-07-29 8:18 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: jhs, xiyou.wangcong, davem, netdev, linux-kernel
In-Reply-To: <20190729080018.28678-1-baijiaju1990@gmail.com>
Mon, Jul 29, 2019 at 10:00:18AM CEST, baijiaju1990@gmail.com wrote:
>In dequeue_func(), there is an if statement on line 74 to check whether
>skb is NULL:
> if (skb)
>
>When skb is NULL, it is used on line 77:
> prefetch(&skb->end);
>
>Thus, a possible null-pointer dereference may occur.
>
>To fix this bug, skb->end is used when skb is not NULL.
>
>This bug is found by a static analysis tool STCheck written by us.
>
>Fixes: 79bdc4c862af ("codel: generalize the implementation")
Looks like this is something being there since the beginning:
commit 76e3cc126bb223013a6b9a0e2a51238d1ef2e409
Author: Eric Dumazet <edumazet@google.com>
Date: Thu May 10 07:51:25 2012 +0000
codel: Controlled Delay AQM
Please adjust "Fixes:".
The fix itself looks fine to me.
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
>Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
>---
>v2:
>* Add a fix tag.
> Thank Jiri Pirko for helpful advice.
>
>---
> net/sched/sch_codel.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/net/sched/sch_codel.c b/net/sched/sch_codel.c
>index 25ef172c23df..30169b3adbbb 100644
>--- a/net/sched/sch_codel.c
>+++ b/net/sched/sch_codel.c
>@@ -71,10 +71,10 @@ static struct sk_buff *dequeue_func(struct codel_vars *vars, void *ctx)
> struct Qdisc *sch = ctx;
> struct sk_buff *skb = __qdisc_dequeue_head(&sch->q);
>
>- if (skb)
>+ if (skb) {
> sch->qstats.backlog -= qdisc_pkt_len(skb);
>-
>- prefetch(&skb->end); /* we'll need skb_shinfo() */
>+ prefetch(&skb->end); /* we'll need skb_shinfo() */
>+ }
> return skb;
> }
>
>--
>2.17.0
>
^ permalink raw reply
* [PATCH] mac80211_hwsim: Fix possible null-pointer dereferences in hwsim_dump_radio_nl()
From: Jia-Ju Bai @ 2019-07-29 8:23 UTC (permalink / raw)
To: johannes, kvalo, davem; +Cc: linux-wireless, netdev, linux-kernel, Jia-Ju Bai
In hwsim_dump_radio_nl(), when genlmsg_put() on line 3617 fails, hdr is
assigned to NULL. Then hdr is used on lines 3622 and 3623:
genl_dump_check_consistent(cb, hdr);
genlmsg_end(skb, hdr);
Thus, possible null-pointer dereferences may occur.
To fix these bugs, hdr is used here when it is not NULL.
This bug is found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/net/wireless/mac80211_hwsim.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 519b4ee88c5c..61a8b6429e09 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3617,10 +3617,11 @@ static int hwsim_dump_radio_nl(struct sk_buff *skb,
hdr = genlmsg_put(skb, NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq, &hwsim_genl_family,
NLM_F_MULTI, HWSIM_CMD_GET_RADIO);
- if (!hdr)
+ if (hdr) {
+ genl_dump_check_consistent(cb, hdr);
+ genlmsg_end(skb, hdr);
+ } else
res = -EMSGSIZE;
- genl_dump_check_consistent(cb, hdr);
- genlmsg_end(skb, hdr);
}
done:
--
2.17.0
^ 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