* Re: [PATCH net-next RESEND] sched: sfq: drop packets after root qdisc lock is released
From: Eric Dumazet @ 2017-08-25 12:49 UTC (permalink / raw)
To: gfree.wind; +Cc: jhs, xiyou.wangcong, jiri, davem, edumazet, netdev
In-Reply-To: <1503646997-94678-1-git-send-email-gfree.wind@vip.163.com>
On Fri, 2017-08-25 at 15:43 +0800, gfree.wind@vip.163.com wrote:
> From: Gao Feng <gfree.wind@vip.163.com>
>
> The commit 520ac30f4551 ("net_sched: drop packets after root qdisc lock
> is released) made a big change of tc for performance. But there are
> some points which are not changed in SFQ enqueue operation.
> 1. Fail to find the SFQ hash slot;
> 2. When the queue is full;
>
> Now use qdisc_drop instead free skb directly.
Thanks for doing this work.
I have one comment
>
> Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
> ---
> net/sched/sch_sfq.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
> index 82469ef..8841f4d 100644
> --- a/net/sched/sch_sfq.c
> +++ b/net/sched/sch_sfq.c
> @@ -292,7 +292,7 @@ static inline void slot_queue_add(struct sfq_slot *slot, struct sk_buff *skb)
> slot->skblist_prev = skb;
> }
>
> -static unsigned int sfq_drop(struct Qdisc *sch)
> +static unsigned int sfq_drop(struct Qdisc *sch, struct sk_buff **to_free)
> {
> struct sfq_sched_data *q = qdisc_priv(sch);
> sfq_index x, d = q->cur_depth;
> @@ -310,9 +310,13 @@ static unsigned int sfq_drop(struct Qdisc *sch)
> slot->backlog -= len;
> sfq_dec(q, x);
> sch->q.qlen--;
> - qdisc_qstats_drop(sch);
> qdisc_qstats_backlog_dec(sch, skb);
> - kfree_skb(skb);
> + if (likely(to_free)) {
> + qdisc_drop(skb, sch, to_free);
> + } else {
> + qdisc_qstats_drop(sch);
> + kfree_skb(skb);
rtnl_kfree_skbs(skb, skb); ?
Or even better provide a non NULL to_free from sfq_change()
Then call rtnl_kfree_skbs() once from sfq_change()
> + }
> return len;
> }
>
> @@ -360,7 +364,7 @@ static int sfq_headdrop(const struct sfq_sched_data *q)
> if (hash == 0) {
> if (ret & __NET_XMIT_BYPASS)
> qdisc_qstats_drop(sch);
> - kfree_skb(skb);
> + __qdisc_drop(skb, to_free);
> return ret;
> }
> hash--;
> @@ -465,7 +469,7 @@ static int sfq_headdrop(const struct sfq_sched_data *q)
> return NET_XMIT_SUCCESS;
>
> qlen = slot->qlen;
> - dropped = sfq_drop(sch);
> + dropped = sfq_drop(sch, to_free);
> /* Return Congestion Notification only if we dropped a packet
> * from this flow.
> */
> @@ -675,7 +679,7 @@ static int sfq_change(struct Qdisc *sch, struct nlattr *opt)
>
> qlen = sch->q.qlen;
> while (sch->q.qlen > q->limit)
> - dropped += sfq_drop(sch);
> + dropped += sfq_drop(sch, NULL);
> qdisc_tree_reduce_backlog(sch, qlen - sch->q.qlen, dropped);
>
> del_timer(&q->perturb_timer);
^ permalink raw reply
* [PATCH] cdc_ncm: flag the ublox TOBY-L4 as wwan
From: Aleksander Morgado @ 2017-08-25 12:59 UTC (permalink / raw)
To: oliver, davem
Cc: stefano.godeas, marco.demarco, linux-usb, netdev, linux-kernel,
Aleksander Morgado
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
---
drivers/net/usb/cdc_ncm.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 811b18215cae..47cab1bde065 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1758,6 +1758,13 @@ static const struct usb_device_id cdc_devs[] = {
.driver_info = (unsigned long)&wwan_noarp_info,
},
+ /* u-blox TOBY-L4 */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x1546, 0x1010,
+ USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&wwan_info,
+ },
+
/* Generic CDC-NCM devices */
{ USB_INTERFACE_INFO(USB_CLASS_COMM,
USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
--
2.14.1
^ permalink raw reply related
* [PATCH] net: missing call of trace_napi_poll in busy_poll_stop
From: Jesper Dangaard Brouer @ 2017-08-25 13:04 UTC (permalink / raw)
To: netdev; +Cc: Jesper Dangaard Brouer
Noticed that busy_poll_stop() also invoke the drivers napi->poll()
function pointer, but didn't have an associated call to trace_napi_poll()
like all other call sites.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
net/core/dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 270b54754821..a24d2fb691ed 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5319,6 +5319,7 @@ static void busy_poll_stop(struct napi_struct *napi, void *have_poll_lock)
* Ideally, a new ndo_busy_poll_stop() could avoid another round.
*/
rc = napi->poll(napi, BUSY_POLL_BUDGET);
+ trace_napi_poll(napi, rc, BUSY_POLL_BUDGET);
netpoll_poll_unlock(have_poll_lock);
if (rc == BUSY_POLL_BUDGET)
__napi_schedule(napi);
^ permalink raw reply related
* Re: [PATCH] cdc_ncm: flag the ublox TOBY-L4 as wwan
From: Greg KH @ 2017-08-25 13:22 UTC (permalink / raw)
To: Aleksander Morgado
Cc: oliver, davem, stefano.godeas, marco.demarco, linux-usb, netdev,
linux-kernel
In-Reply-To: <20170825125946.12812-1-aleksander@aleksander.es>
On Fri, Aug 25, 2017 at 02:59:46PM +0200, Aleksander Morgado wrote:
> Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
> ---
> drivers/net/usb/cdc_ncm.c | 7 +++++++
> 1 file changed, 7 insertions(+)
Personally, I require patches to have changelog texts in them...
^ permalink raw reply
* [PATCH net-next] net: mvpp2: fix the packet size configuration for 10G
From: Antoine Tenart @ 2017-08-25 13:24 UTC (permalink / raw)
To: davem
Cc: Antoine Tenart, andrew, gregory.clement, thomas.petazzoni, nadavh,
linux, mw, stefanc, netdev
The MVPP22_XLG_CTRL1_FRAMESIZELIMIT define is used as an offset, but is
defined as BIT(0). Updated its name to contains "OFFS" as in offset and
fix its value using the offset value, 0.
Reported-by: Stefan Chulski <stefanc@marvell.com>
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Fixes: 76eb1b1de5b6 ("net: mvpp2: set maximum packet size for 10G ports")
---
Hi Dave,
This patch fixes a bug only present in net-next as it was introduced
recently.
Thanks!
Antoine
drivers/net/ethernet/marvell/mvpp2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 7fa251bf91ae..fea9ae5b70ba 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -367,7 +367,7 @@
#define MVPP22_XLG_CTRL0_RX_FLOW_CTRL_EN BIT(7)
#define MVPP22_XLG_CTRL0_MIB_CNT_DIS BIT(14)
#define MVPP22_XLG_CTRL1_REG 0x104
-#define MVPP22_XLG_CTRL1_FRAMESIZELIMIT BIT(0)
+#define MVPP22_XLG_CTRL1_FRAMESIZELIMIT_OFFS 0
#define MVPP22_XLG_CTRL1_FRAMESIZELIMIT_MASK 0x1fff
#define MVPP22_XLG_CTRL3_REG 0x11c
#define MVPP22_XLG_CTRL3_MACMODESELECT_MASK (7 << 13)
@@ -4669,7 +4669,7 @@ static inline void mvpp2_xlg_max_rx_size_set(struct mvpp2_port *port)
val = readl(port->base + MVPP22_XLG_CTRL1_REG);
val &= ~MVPP22_XLG_CTRL1_FRAMESIZELIMIT_MASK;
val |= ((port->pkt_size - MVPP2_MH_SIZE) / 2) <<
- MVPP22_XLG_CTRL1_FRAMESIZELIMIT;
+ MVPP22_XLG_CTRL1_FRAMESIZELIMIT_OFFS;
writel(val, port->base + MVPP22_XLG_CTRL1_REG);
}
--
2.13.5
^ permalink raw reply related
* Re: [PATCH v3 3/4] net: stmmac: register parent MDIO node for sun8i-h3-emac
From: Andrew Lunn @ 2017-08-25 13:26 UTC (permalink / raw)
To: Florian Fainelli
Cc: Chen-Yu Tsai, Corentin Labbe, Maxime Ripard, Rob Herring,
Mark Rutland, Russell King, Giuseppe Cavallaro, Alexandre Torgue,
devicetree, linux-arm-kernel, linux-kernel, netdev
In-Reply-To: <3d74f0e3-9baf-195d-1e59-dbd8210b3c6f@gmail.com>
> > Just tested. Yes the MDIO/MDC lines are also muxed and controlled through
> > the same mux bit.
>
> Alright then the mdio-mux seems appropriate, thanks.
Please add a comment that it muxes the MII lines as well. That is not
normal for an mdio-mux, so we should document it in the dtsi file.
Thanks
Andrew
^ permalink raw reply
* [PATCH net-next] tcp: fix hang in tcp_sendpage_locked()
From: Eric Dumazet @ 2017-08-25 13:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Tom Herbert, Dmitry Vyukov
From: Eric Dumazet <edumazet@google.com>
syszkaller got a hang in tcp stack, related to a bug in
tcp_sendpage_locked()
root@syzkaller:~# cat /proc/3059/stack
[<ffffffff83de926c>] __lock_sock+0x1dc/0x2f0
[<ffffffff83de9473>] lock_sock_nested+0xf3/0x110
[<ffffffff8408ce01>] tcp_sendmsg+0x21/0x50
[<ffffffff84163b6f>] inet_sendmsg+0x11f/0x5e0
[<ffffffff83dd8eea>] sock_sendmsg+0xca/0x110
[<ffffffff83dd9547>] kernel_sendmsg+0x47/0x60
[<ffffffff83de35dc>] sock_no_sendpage+0x1cc/0x280
[<ffffffff8408916b>] tcp_sendpage_locked+0x10b/0x160
[<ffffffff84089203>] tcp_sendpage+0x43/0x60
[<ffffffff841641da>] inet_sendpage+0x1aa/0x660
[<ffffffff83dd4fcd>] kernel_sendpage+0x8d/0xe0
[<ffffffff83dd50ac>] sock_sendpage+0x8c/0xc0
[<ffffffff81b63300>] pipe_to_sendpage+0x290/0x3b0
[<ffffffff81b67243>] __splice_from_pipe+0x343/0x750
[<ffffffff81b6a459>] splice_from_pipe+0x1e9/0x330
[<ffffffff81b6a5e0>] generic_splice_sendpage+0x40/0x50
[<ffffffff81b6b1d7>] SyS_splice+0x7b7/0x1610
[<ffffffff84d77a01>] entry_SYSCALL_64_fastpath+0x1f/0xbe
Fixes: 306b13eb3cf9 ("proto_ops: Add locked held versions of sendmsg and sendpage")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Tom Herbert <tom@quantonium.net>
---
net/ipv4/tcp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 0cce4472b4a1b0e3c110692571ac2a5c51467c42..566083ee2654c25410d80ff56ce5adb49bb28ae7 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1052,8 +1052,7 @@ int tcp_sendpage_locked(struct sock *sk, struct page *page, int offset,
{
if (!(sk->sk_route_caps & NETIF_F_SG) ||
!sk_check_csum_caps(sk))
- return sock_no_sendpage(sk->sk_socket, page, offset, size,
- flags);
+ return sock_no_sendpage_locked(sk, page, offset, size, flags);
tcp_rate_check_app_limited(sk); /* is sending application-limited? */
^ permalink raw reply related
* Re: [PATCH] cdc_ncm: flag the ublox TOBY-L4 as wwan
From: Aleksander Morgado @ 2017-08-25 13:30 UTC (permalink / raw)
To: Greg KH
Cc: Oliver Neukum, David S. Miller, Stefano Godeas, Marco De Marco,
linux-usb, netdev@vger.kernel.org, linux-kernel
In-Reply-To: <20170825132236.GB16203@kroah.com>
On Fri, Aug 25, 2017 at 3:22 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Fri, Aug 25, 2017 at 02:59:46PM +0200, Aleksander Morgado wrote:
>> Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
>> ---
>> drivers/net/usb/cdc_ncm.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>
> Personally, I require patches to have changelog texts in them...
Sure, will push a v2 with more info.
--
Aleksander
https://aleksander.es
^ permalink raw reply
* pull-request: wireless-drivers 2017-08-25
From: Kalle Valo @ 2017-08-25 13:37 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's pull request to net tree for 4.13, more info in the signed tag
below. Please let me know if there are any problems.
Kalle
The following changes since commit e9bf53ab1ee34bb05c104bbfd2b77c844773f8e6:
brcmfmac: feature check for multi-scheduled scan fails on bcm4343x devices (2017-08-14 11:09:30 +0300)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2017-08-25
for you to fetch changes up to 10a54d8196d11f6cc0db2f71249f93854cb9fe55:
iwlwifi: pcie: move rx workqueue initialization to iwl_trans_pcie_alloc() (2017-08-24 16:49:00 +0300)
----------------------------------------------------------------
wireless-drivers fixes for 4.13
Only one iwlwifi patch this time.
iwlwifi
* fix multiple times reported lockdep warning found by new locking
annotation introduced in v4.13-rc1
----------------------------------------------------------------
Luca Coelho (1):
iwlwifi: pcie: move rx workqueue initialization to iwl_trans_pcie_alloc()
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 2 ++
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 10 +---------
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 9 +++++++++
3 files changed, 12 insertions(+), 9 deletions(-)
^ permalink raw reply
* [PATCH v2] cdc_ncm: flag the u-blox TOBY-L4 as wwan
From: Aleksander Morgado @ 2017-08-25 13:39 UTC (permalink / raw)
To: oliver, davem
Cc: stefano.godeas, marco.demarco, linux-usb, netdev, linux-kernel,
gregkh, Aleksander Morgado
In-Reply-To: <20170825125946.12812-1-aleksander@aleksander.es>
The u-blox TOBY-L4 is a LTE Advanced (Cat 6) module with HSPA+ and 2G
fallback.
Unlike the TOBY-L2, this module has one single USB layout and exposes
several TTYs for control and a NCM interface for data. Connecting this
module may be done just by activating the desired PDP context with
'AT+CGACT=1,<cid>' and then running DHCP on the NCM interface.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
---
drivers/net/usb/cdc_ncm.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 811b18215cae..47cab1bde065 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1758,6 +1758,13 @@ static const struct usb_device_id cdc_devs[] = {
.driver_info = (unsigned long)&wwan_noarp_info,
},
+ /* u-blox TOBY-L4 */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x1546, 0x1010,
+ USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&wwan_info,
+ },
+
/* Generic CDC-NCM devices */
{ USB_INTERFACE_INFO(USB_CLASS_COMM,
USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
--
2.14.1
^ permalink raw reply related
* Re: [PATCH] staging: rtlwifi: Improve debugging by using debugfs
From: Larry Finger @ 2017-08-25 13:47 UTC (permalink / raw)
To: Andrew Lunn
Cc: gregkh, netdev, devel, Ping-Ke Shih, Yan-Hsuan Chuang,
Birming Chiu, Shaofu, Steven Ting
In-Reply-To: <20170825015421.GA8852@lunn.ch>
On 08/24/2017 08:54 PM, Andrew Lunn wrote:
> netdev frowns upon debugfs. You should try to keep this altogether,
> making it easy to throw away before the driver is moved out of
> staging.
>
> You might want to look at ethtool -d. That will be accepted.
Andrew,
What is the problem with debugfs?
Please suggest which driver has the best example of an ethtool -d implementation
that we might study.
The first version of the debugfs changes were sent to wireless-drivers on July
2. Why are we first hearing of this objection nearly 2 months later?
Larry
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: mvpp2: fix the mac address retrieval logic
From: Antoine Tenart @ 2017-08-25 13:58 UTC (permalink / raw)
To: David Miller
Cc: antoine.tenart, thomas.petazzoni, andrew, gregory.clement, nadavh,
linux, linux-kernel, mw, stefanc, netdev
In-Reply-To: <20170824.214624.250495333472785242.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]
Hi Dave,
On Thu, Aug 24, 2017 at 09:46:24PM -0700, David Miller wrote:
> From: Antoine Tenart <antoine.tenart@free-electrons.com>
> Date: Thu, 24 Aug 2017 11:46:54 +0200
>
> > The MAC address retrieval logic was broken and when using the PPv2
> > driver on PPv2.2 engines I ended up using the same mac address on all
> > ports. This series of patches fixes this, and also tackle a possible bug
> > when defining the mac address in the device tree.
> >
> > To fix this in a nice way I ended up using a dedicated function to
> > handle the mac retrieval logic. This can be hard to backport into stable
> > kernels. This is why I also made a quick fix which is easy to backport
> > (patch 1/14), to tackle down the PPv2.2 mac retrieval bug. Let me know
> > if this approach is the proper way to handle this or if I should do
> > something else.
>
> This patch series doesn't apply to any of my trees, that is the first
> thing.
That is very strange, my patches were based on top of net-next. I'll
double check if they apply correctly before sending the v2.
> Secondly, this is a bug fix, and the bug exists in the 'net' tree.
> Therefore this patch series should target the 'net' tree.
OK, that's the question I was asking. I'll resent everything to net
then.
> Please always target legitimate bug fixes at the 'net' tree, rather
> than 'net-next'.
Sure, will do.
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Possible race in nsc-ircc.ko
From: Anton Volkov @ 2017-08-25 14:05 UTC (permalink / raw)
To: dagb, jt, samuel; +Cc: netdev, linux-kernel, ldv-project, Alexey Khoroshilov
Hello.
While searching for races in the Linux kernel I've come across
"drivers/net/irda/nsc-ircc.ko" module. Here is a question that I came up
with while analyzing results. Lines are given using the info from Linux
v4.12.
Consider the following case:
Thread 1: Thread 2:
nsc_ircc_init
->nsc_ircc_open
self = netdev_priv(dev)
register_netdev(dev)
nsc_ircc_net_ioctl
->nsc_ircc_change_speed
self->dongle_id = ... <READ self->io.dongle_id>
(nsc-ircc.c: line 485) (nsc-ircc.c: line 1318)
platform_device_register_simple
Before the initialization of self->dongle_id in msc_ircc_open() its
value is 0. Thus if read access to its value in nsc_ircc_change_speed
occurs before the initialization there will be an attempt to change
speed of dongle with undesired id (if the dongle with id 0 exists). Is
this case feasible from your point of view?
Thank you for your time.
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avolkov@ispras.ru
^ permalink raw reply
* [PATCH net v2 0/4] net: mvpp2: fix the mac address retrieval logic
From: Antoine Tenart @ 2017-08-25 14:14 UTC (permalink / raw)
To: davem, thomas.petazzoni
Cc: Antoine Tenart, andrew, gregory.clement, nadavh, linux,
linux-kernel, mw, stefanc, netdev
Hi all,
The MAC address retrieval logic was broken and when using the PPv2
driver on PPv2.2 engines I ended up using the same mac address on all
ports. This series of patches fixes this, and also tackle a possible bug
when defining the mac address in the device tree.
Patch 1/4 can be applied to relevant stable trees (4.12+).
The series applies on net/master (9b4e946ce14e).
Thanks!
Antoine
Since v1:
- Rebased onto net (was on net-next).
Antoine Tenart (4):
net: mvpp2: fix the mac address used when using PPv2.2
net: mvpp2: move the mac retrieval/copy logic into its own function
net: mvpp2: fix use of the random mac address for PPv2.2
net: mvpp2: fallback using h/w and random mac if the dt one isn't
valid
drivers/net/ethernet/marvell/mvpp2.c | 48 ++++++++++++++++++++++--------------
1 file changed, 30 insertions(+), 18 deletions(-)
--
2.13.5
^ permalink raw reply
* [PATCH net v2 1/4] net: mvpp2: fix the mac address used when using PPv2.2
From: Antoine Tenart @ 2017-08-25 14:14 UTC (permalink / raw)
To: davem, thomas.petazzoni
Cc: Antoine Tenart, andrew, gregory.clement, nadavh, linux,
linux-kernel, mw, stefanc, netdev
In-Reply-To: <20170825141420.14027-1-antoine.tenart@free-electrons.com>
The mac address is only retrieved from h/w when using PPv2.1. Otherwise
the variable holding it is still checked and used if it contains a valid
value. As the variable isn't initialized to an invalid mac address
value, we end up with random mac addresses which can be the same for all
the ports handled by this PPv2 driver.
Fixes this by initializing the h/w mac address variable to {0}, which is
an invalid mac address value. This way the random assignation fallback
is called and all ports end up with their own addresses.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Fixes: 2697582144dd ("net: mvpp2: handle misc PPv2.1/PPv2.2 differences")
---
drivers/net/ethernet/marvell/mvpp2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 48d21c1e09f2..4d598ca8503a 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -6504,7 +6504,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
struct resource *res;
const char *dt_mac_addr;
const char *mac_from;
- char hw_mac_addr[ETH_ALEN];
+ char hw_mac_addr[ETH_ALEN] = {0};
u32 id;
int features;
int phy_mode;
--
2.13.5
^ permalink raw reply related
* [PATCH net v2 2/4] net: mvpp2: move the mac retrieval/copy logic into its own function
From: Antoine Tenart @ 2017-08-25 14:14 UTC (permalink / raw)
To: davem, thomas.petazzoni
Cc: Antoine Tenart, andrew, gregory.clement, nadavh, linux,
linux-kernel, mw, stefanc, netdev
In-Reply-To: <20170825141420.14027-1-antoine.tenart@free-electrons.com>
The MAC retrieval has a quite complicated logic (which is broken). Moves
it to its own function to prepare for patches fixing its logic, so that
reviews are easier.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 45 +++++++++++++++++++++---------------
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 4d598ca8503a..a1593134ed96 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -6492,6 +6492,31 @@ static int mvpp2_port_init(struct mvpp2_port *port)
return err;
}
+static void mvpp2_port_copy_mac_addr(struct net_device *dev, struct mvpp2 *priv,
+ struct device_node *port_node,
+ char **mac_from)
+{
+ struct mvpp2_port *port = netdev_priv(dev);
+ char hw_mac_addr[ETH_ALEN] = {0};
+ const char *dt_mac_addr;
+
+ dt_mac_addr = of_get_mac_address(port_node);
+ if (dt_mac_addr && is_valid_ether_addr(dt_mac_addr)) {
+ *mac_from = "device tree";
+ ether_addr_copy(dev->dev_addr, dt_mac_addr);
+ } else {
+ if (priv->hw_version == MVPP21)
+ mvpp21_get_mac_address(port, hw_mac_addr);
+ if (is_valid_ether_addr(hw_mac_addr)) {
+ *mac_from = "hardware";
+ ether_addr_copy(dev->dev_addr, hw_mac_addr);
+ } else {
+ *mac_from = "random";
+ eth_hw_addr_random(dev);
+ }
+ }
+}
+
/* Ports initialization */
static int mvpp2_port_probe(struct platform_device *pdev,
struct device_node *port_node,
@@ -6502,9 +6527,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
struct mvpp2_port_pcpu *port_pcpu;
struct net_device *dev;
struct resource *res;
- const char *dt_mac_addr;
- const char *mac_from;
- char hw_mac_addr[ETH_ALEN] = {0};
+ char *mac_from = "";
u32 id;
int features;
int phy_mode;
@@ -6585,21 +6608,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
goto err_free_irq;
}
- dt_mac_addr = of_get_mac_address(port_node);
- if (dt_mac_addr && is_valid_ether_addr(dt_mac_addr)) {
- mac_from = "device tree";
- ether_addr_copy(dev->dev_addr, dt_mac_addr);
- } else {
- if (priv->hw_version == MVPP21)
- mvpp21_get_mac_address(port, hw_mac_addr);
- if (is_valid_ether_addr(hw_mac_addr)) {
- mac_from = "hardware";
- ether_addr_copy(dev->dev_addr, hw_mac_addr);
- } else {
- mac_from = "random";
- eth_hw_addr_random(dev);
- }
- }
+ mvpp2_port_copy_mac_addr(dev, priv, port_node, &mac_from);
port->tx_ring_size = MVPP2_MAX_TXD;
port->rx_ring_size = MVPP2_MAX_RXD;
--
2.13.5
^ permalink raw reply related
* [PATCH net v2 3/4] net: mvpp2: fix use of the random mac address for PPv2.2
From: Antoine Tenart @ 2017-08-25 14:14 UTC (permalink / raw)
To: davem, thomas.petazzoni
Cc: Antoine Tenart, andrew, gregory.clement, nadavh, linux,
linux-kernel, mw, stefanc, netdev
In-Reply-To: <20170825141420.14027-1-antoine.tenart@free-electrons.com>
The MAC retrieval logic is using a variable to store an h/w stored mac
address and checks this mac against invalid ones before using it. But
the mac address is only read from h/w when using PPv2.1. So when using
PPv2.2 it defaults to its init state.
This patches fixes the logic to only check if the h/w mac is valid when
actually retrieving a mac from h/w.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index a1593134ed96..162e334fda37 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -6505,15 +6505,17 @@ static void mvpp2_port_copy_mac_addr(struct net_device *dev, struct mvpp2 *priv,
*mac_from = "device tree";
ether_addr_copy(dev->dev_addr, dt_mac_addr);
} else {
- if (priv->hw_version == MVPP21)
+ if (priv->hw_version == MVPP21) {
mvpp21_get_mac_address(port, hw_mac_addr);
- if (is_valid_ether_addr(hw_mac_addr)) {
- *mac_from = "hardware";
- ether_addr_copy(dev->dev_addr, hw_mac_addr);
- } else {
- *mac_from = "random";
- eth_hw_addr_random(dev);
+ if (is_valid_ether_addr(hw_mac_addr)) {
+ *mac_from = "hardware";
+ ether_addr_copy(dev->dev_addr, hw_mac_addr);
+ return;
+ }
}
+
+ *mac_from = "random";
+ eth_hw_addr_random(dev);
}
}
--
2.13.5
^ permalink raw reply related
* [PATCH net v2 4/4] net: mvpp2: fallback using h/w and random mac if the dt one isn't valid
From: Antoine Tenart @ 2017-08-25 14:14 UTC (permalink / raw)
To: davem, thomas.petazzoni
Cc: Antoine Tenart, andrew, gregory.clement, nadavh, linux,
linux-kernel, mw, stefanc, netdev
In-Reply-To: <20170825141420.14027-1-antoine.tenart@free-electrons.com>
When using a mac address described in the device tree, a check is made
to see if it is valid. When it's not, no fallback is defined. This
patches tries to get the mac address from h/w (or use a random one if
the h/w one isn't valid) when the dt mac address isn't valid.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 162e334fda37..2f1284f23e66 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -6504,19 +6504,20 @@ static void mvpp2_port_copy_mac_addr(struct net_device *dev, struct mvpp2 *priv,
if (dt_mac_addr && is_valid_ether_addr(dt_mac_addr)) {
*mac_from = "device tree";
ether_addr_copy(dev->dev_addr, dt_mac_addr);
- } else {
- if (priv->hw_version == MVPP21) {
- mvpp21_get_mac_address(port, hw_mac_addr);
- if (is_valid_ether_addr(hw_mac_addr)) {
- *mac_from = "hardware";
- ether_addr_copy(dev->dev_addr, hw_mac_addr);
- return;
- }
- }
+ return;
+ }
- *mac_from = "random";
- eth_hw_addr_random(dev);
+ if (priv->hw_version == MVPP21) {
+ mvpp21_get_mac_address(port, hw_mac_addr);
+ if (is_valid_ether_addr(hw_mac_addr)) {
+ *mac_from = "hardware";
+ ether_addr_copy(dev->dev_addr, hw_mac_addr);
+ return;
+ }
}
+
+ *mac_from = "random";
+ eth_hw_addr_random(dev);
}
/* Ports initialization */
--
2.13.5
^ permalink raw reply related
* Re: [PATCH] staging: rtlwifi: Improve debugging by using debugfs
From: Andrew Lunn @ 2017-08-25 14:16 UTC (permalink / raw)
To: Larry Finger
Cc: devel, Yan-Hsuan Chuang, gregkh, Birming Chiu, netdev,
Steven Ting
In-Reply-To: <1a1ca849-3aec-60e3-b5a3-98a6e095d298@lwfinger.net>
On Fri, Aug 25, 2017 at 08:47:00AM -0500, Larry Finger wrote:
> On 08/24/2017 08:54 PM, Andrew Lunn wrote:
> >netdev frowns upon debugfs. You should try to keep this altogether,
> >making it easy to throw away before the driver is moved out of
> >staging.
> >
> >You might want to look at ethtool -d. That will be accepted.
>
> Andrew,
>
> What is the problem with debugfs?
You should probably look back in the discussions on the netdev
mailling list. But basically, anything you want to export should
follow generic well defined interface, which can be used by other
drivers. debugfs tends to be a mess, a wild west, each driver doing
its own thing, not standardisation. It is O.K. for your own
development work, you can have your own out of tree patches adding in
debugfs, but such patches are unlikely to be accepted into mainline.
David has threatened to simply rip out all debugfs code from all
network drivers. There is push back on adding any new debugfs code,
and some driver writers have taken out debugfs code in their own
drivers, often replacing it with something generic all drivers can
use.
> Please suggest which driver has the best example of an ethtool -d
> implementation that we might study.
The API is very simple. In your ethtool_ops you need to function:
.get_regs_len, returns an int, the number of registers you can dump.
.get_regs returns the contents.
There are plenty of examples, e.g.:
http://elixir.free-electrons.com/linux/latest/source/drivers/net/ethernet/amd/pcnet32.c#L1436
If you need something more structured, look around, see if other
drivers have similar needs, and propose something generic.
> The first version of the debugfs changes were sent to wireless-drivers on
> July 2. Why are we first hearing of this objection nearly 2 months later?
Different reviewers tend to review different things. I personally
don't care so much who the vendor is, but look out for some specific
things i feel qualified to review. Ethernet PHYs and MDIO drivers,
drivers which make use of Ethernet PHYs, APIs which allow userspace to
write to registers, debugfs, changing MTUs, etc.
There are plenty of patches on netdev for me to review, so i don't
cast a wider net to other lists, like for example wireless-drivers.
You would of got this comment sooner or later, since you should be
posting to netdev at some point anyway. I can also imaging there is
also some reluctance to review staging code, until it is getting close
to moving out of staging.
Andrew
^ permalink raw reply
* Re: [PATCH net v2 1/4] net: mvpp2: fix the mac address used when using PPv2.2
From: Andrew Lunn @ 2017-08-25 14:19 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, thomas.petazzoni, gregory.clement, nadavh, linux,
linux-kernel, mw, stefanc, netdev
In-Reply-To: <20170825141420.14027-2-antoine.tenart@free-electrons.com>
On Fri, Aug 25, 2017 at 04:14:17PM +0200, Antoine Tenart wrote:
> The mac address is only retrieved from h/w when using PPv2.1. Otherwise
> the variable holding it is still checked and used if it contains a valid
> value. As the variable isn't initialized to an invalid mac address
> value, we end up with random mac addresses which can be the same for all
> the ports handled by this PPv2 driver.
>
> Fixes this by initializing the h/w mac address variable to {0}, which is
> an invalid mac address value. This way the random assignation fallback
> is called and all ports end up with their own addresses.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> Fixes: 2697582144dd ("net: mvpp2: handle misc PPv2.1/PPv2.2 differences")
Hi Antoine
Is this patch alone sufficient to fix the problem?
Ideally, you want a minimal patch for stable, i.e. -net, and a fuller
fix can go into net-next.
Andrew
^ permalink raw reply
* [PATCH net-next v6 0/3] openvswitch: add NSH support
From: Yi Yang @ 2017-08-25 14:20 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: dev-yBygre7rU0TnMu66kgdUjQ, jbenc-H+wXaHxf7aLQT0dZR+AlfA, e
v5->v6
- Fix the rest comments for v4.
- Add NSH GSO support for VxLAN-gpe + NSH and
Eth + NSH.
v4->v5
- Fix many comments by Jiri Benc and Eric Garver
for v4.
v3->v4
- Add new NSH match field ttl
- Update NSH header to the latest format
which will be final format and won't change
per its author's confirmation.
- Fix comments for v3.
v2->v3
- Change OVS_KEY_ATTR_NSH to nested key to handle
length-fixed attributes and length-variable
attriubte more flexibly.
- Remove struct ovs_action_push_nsh completely
- Add code to handle nested attribute for SET_MASKED
- Change PUSH_NSH to use the nested OVS_KEY_ATTR_NSH
to transfer NSH header data.
- Fix comments and coding style issues by Jiri and Eric
v1->v2
- Change encap_nsh and decap_nsh to push_nsh and pop_nsh
- Dynamically allocate struct ovs_action_push_nsh for
length-variable metadata.
This patch series is to enable NSH support in OVS kernel
data path, it also adds NSH GSO support for big packet.
Yi Yang (3):
net: add NSH header structures and helpers
net: gso: Add GSO support for NSH
openvswitch: enable NSH support
drivers/net/vxlan.c | 7 +
include/linux/netdevice.h | 1 +
include/linux/skbuff.h | 8 +-
include/net/nsh.h | 307 +++++++++++++++++++++++++++++
include/uapi/linux/if_ether.h | 1 +
include/uapi/linux/openvswitch.h | 28 +++
net/Kconfig | 1 +
net/Makefile | 1 +
net/core/dev.c | 14 ++
net/ipv4/udp_offload.c | 7 +
net/nsh/Kconfig | 11 ++
net/nsh/Makefile | 4 +
net/nsh/nsh_gso.c | 106 ++++++++++
net/openvswitch/actions.c | 178 +++++++++++++++++
net/openvswitch/flow.c | 55 ++++++
net/openvswitch/flow.h | 11 ++
net/openvswitch/flow_netlink.c | 404 ++++++++++++++++++++++++++++++++++++++-
net/openvswitch/flow_netlink.h | 4 +
18 files changed, 1145 insertions(+), 3 deletions(-)
create mode 100644 include/net/nsh.h
create mode 100644 net/nsh/Kconfig
create mode 100644 net/nsh/Makefile
create mode 100644 net/nsh/nsh_gso.c
--
2.5.5
^ permalink raw reply
* [PATCH 0/7] net: make some structures const
From: Bhumika Goyal @ 2017-08-25 14:21 UTC (permalink / raw)
To: julia.lawall, marcel, gustavo, johan.hedberg, davem, pablo,
kadlec, fw, stephen, alex.aring, stefan, kuznet, yoshfuji,
santosh.shilimkar, trond.myklebust, anna.schumaker, bfields,
jlayton, linux-bluetooth, netdev, linux-kernel, netfilter-devel,
coreteam, bridge, linux-wpan, linux-rdma, rds-devel, linux-nfs
Cc: Bhumika Goyal
Make these const as they are not modified.
Bhumika Goyal (7):
Bluetooth: 6lowpan: make header_ops const
bridge: make ebt_table const
ieee802154: 6lowpan: make header_ops const
ipv4: make net_protocol const
RDS: make rhashtable_params const
netfilter: nat: make rhashtable_params const
SUNRPC: make kvec const
net/bluetooth/6lowpan.c | 2 +-
net/bridge/netfilter/ebtable_nat.c | 2 +-
net/ieee802154/6lowpan/core.c | 2 +-
net/ipv4/af_inet.c | 4 ++--
net/netfilter/nf_nat_core.c | 2 +-
net/rds/bind.c | 2 +-
net/sunrpc/xdr.c | 2 +-
7 files changed, 8 insertions(+), 8 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 2/7] bridge: make ebt_table const
From: Bhumika Goyal @ 2017-08-25 14:21 UTC (permalink / raw)
To: julia.lawall, marcel, gustavo, johan.hedberg, davem, pablo,
kadlec, fw, stephen, alex.aring, stefan, kuznet, yoshfuji,
santosh.shilimkar, trond.myklebust, anna.schumaker, bfields,
jlayton, linux-bluetooth, netdev, linux-kernel, netfilter-devel,
coreteam, bridge, linux-wpan, linux-rdma, rds-devel, linux-nfs
Cc: Bhumika Goyal
In-Reply-To: <1503670907-23221-1-git-send-email-bhumirks@gmail.com>
Make this const as it is only passed to a const argument of the function
ebt_register_table.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
net/bridge/netfilter/ebtable_nat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bridge/netfilter/ebtable_nat.c b/net/bridge/netfilter/ebtable_nat.c
index 4ecf506..57cd5bb 100644
--- a/net/bridge/netfilter/ebtable_nat.c
+++ b/net/bridge/netfilter/ebtable_nat.c
@@ -48,7 +48,7 @@ static int check(const struct ebt_table_info *info, unsigned int valid_hooks)
return 0;
}
-static struct ebt_table frame_nat = {
+static const struct ebt_table frame_nat = {
.name = "nat",
.table = &initial_table,
.valid_hooks = NAT_VALID_HOOKS,
--
1.9.1
^ permalink raw reply related
* [PATCH 6/7] netfilter: nat: make rhashtable_params const
From: Bhumika Goyal @ 2017-08-25 14:21 UTC (permalink / raw)
To: julia.lawall, marcel, gustavo, johan.hedberg, davem, pablo,
kadlec, fw, stephen, alex.aring, stefan, kuznet, yoshfuji,
santosh.shilimkar, trond.myklebust, anna.schumaker, bfields,
jlayton, linux-bluetooth, netdev, linux-kernel, netfilter-devel,
coreteam, bridge, linux-wpan, linux-rdma, rds-devel, linux-nfs
Cc: Bhumika Goyal
In-Reply-To: <1503670907-23221-1-git-send-email-bhumirks@gmail.com>
Make this const as it is either used during a copy operation or passed
to a const argument of the function rhltable_init.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
net/netfilter/nf_nat_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nf_nat_core.c b/net/netfilter/nf_nat_core.c
index b1d3740..df983ea 100644
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -198,7 +198,7 @@ static int nf_nat_bysource_cmp(struct rhashtable_compare_arg *arg,
return 0;
}
-static struct rhashtable_params nf_nat_bysource_params = {
+static const struct rhashtable_params nf_nat_bysource_params = {
.head_offset = offsetof(struct nf_conn, nat_bysource),
.obj_hashfn = nf_nat_bysource_hash,
.obj_cmpfn = nf_nat_bysource_cmp,
--
1.9.1
^ permalink raw reply related
* [PATCH 7/7] SUNRPC: make kvec const
From: Bhumika Goyal @ 2017-08-25 14:21 UTC (permalink / raw)
To: julia.lawall-L2FTfq7BK8M, marcel-kz+m5ild9QBg9hUCZPvPmw,
gustavo-THi1TnShQwVAfugRpC6u6w,
johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, pablo-Cap9r6Oaw4JrovVCs/uTlw,
kadlec-K40Dz/62t/MgiyqX0sVFJYdd74u8MsAO,
fw-HFFVJYpyMKqzQB+pC5nmwQ,
stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
alex.aring-Re5JQEeQqe8AvxtiuMwx3w, stefan-JPH+aEBZ4P+UEJcrhfAQsw,
kuznet-v/Mj1YrvjDBInbfyfbPRSQ, yoshfuji-VfPWfsRibaP+Ru+s062T9g,
santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA,
trond.myklebust-7I+n7zu2hftEKMMhf/gKZA,
anna.schumaker-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw, jlayton-vpEMnDpepFuMZCB2o+C8xQ,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
coreteam-Cap9r6Oaw4JrovVCs/uTlw,
bridge-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-wpan-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-nfs-u79uwXL29TY76Z2rM5mHXA
Cc: Bhumika Goyal
In-Reply-To: <1503670907-23221-1-git-send-email-bhumirks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Make this const as it is only used during a copy operation.
Signed-off-by: Bhumika Goyal <bhumirks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/sunrpc/xdr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sunrpc/xdr.c b/net/sunrpc/xdr.c
index e34f4ee..a096025 100644
--- a/net/sunrpc/xdr.c
+++ b/net/sunrpc/xdr.c
@@ -998,7 +998,7 @@ void xdr_enter_page(struct xdr_stream *xdr, unsigned int len)
}
EXPORT_SYMBOL_GPL(xdr_enter_page);
-static struct kvec empty_iov = {.iov_base = NULL, .iov_len = 0};
+static const struct kvec empty_iov = {.iov_base = NULL, .iov_len = 0};
void
xdr_buf_from_iov(struct kvec *iov, struct xdr_buf *buf)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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