* Re: [PATCH 1/3] netdev: introduce new NETIF_F_HW_SWITCH_OFFLOAD feature flag for switch device offloads
From: Jiri Pirko @ 2014-12-05 7:41 UTC (permalink / raw)
To: roopa
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, linville,
nhorman, nicolas.dichtel, vyasevic, f.fainelli, buytenh, aviadr,
netdev, davem, shm, gospo
In-Reply-To: <1417746401-8140-2-git-send-email-roopa@cumulusnetworks.com>
Fri, Dec 05, 2014 at 03:26:39AM CET, roopa@cumulusnetworks.com wrote:
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>This is a generic high level feature flag for all switch asic features today.
>
>switch drivers set this flag on switch ports. Logical devices like
>bridge, bonds, vxlans can inherit this flag from their slaves/ports.
Can you please elaborate on how exactly would this inheritance look
like?
>
>I had to use SWITCH in the name to avoid ambiguity with other feature
>flags. But, since i have been harping about not calling it 'switch',
>I am welcome to any suggestions :)
>
>An alternative to using a feature flag is to use a IFF_HW_OFFLOAD
>in net_device_flags.
>---
> include/linux/netdev_features.h | 2 ++
> 1 file changed, 2 insertions(+)
>
>diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
>index 8e30685..68db1de 100644
>--- a/include/linux/netdev_features.h
>+++ b/include/linux/netdev_features.h
>@@ -66,6 +66,7 @@ enum {
> NETIF_F_HW_VLAN_STAG_FILTER_BIT,/* Receive filtering on VLAN STAGs */
> NETIF_F_HW_L2FW_DOFFLOAD_BIT, /* Allow L2 Forwarding in Hardware */
> NETIF_F_BUSY_POLL_BIT, /* Busy poll */
>+ NETIF_F_HW_SWITCH_OFFLOAD_BIT, /* HW switch offload */
>
> /*
> * Add your fresh new feature above and remember to update
>@@ -124,6 +125,7 @@ enum {
> #define NETIF_F_HW_VLAN_STAG_TX __NETIF_F(HW_VLAN_STAG_TX)
> #define NETIF_F_HW_L2FW_DOFFLOAD __NETIF_F(HW_L2FW_DOFFLOAD)
> #define NETIF_F_BUSY_POLL __NETIF_F(BUSY_POLL)
>+#define NETIF_F_HW_SWITCH_OFFLOAD __NETIF_F(HW_SWITCH_OFFLOAD)
>
> /* Features valid for ethtool to change */
> /* = all defined minus driver/device-class-related */
>--
>1.7.10.4
>
^ permalink raw reply
* Re: [PATCH iproute2] bridge link: add option 'self'
From: Jiri Pirko @ 2014-12-05 7:55 UTC (permalink / raw)
To: roopa
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, linville,
nhorman, nicolas.dichtel, vyasevic, f.fainelli, buytenh, aviadr,
netdev, davem, shm, gospo
In-Reply-To: <1417746436-41023-1-git-send-email-roopa@cumulusnetworks.com>
Fri, Dec 05, 2014 at 03:27:16AM CET, roopa@cumulusnetworks.com wrote:
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>Currently self is set internally only if hwmode is set.
>This makes it necessary for the hw to have a mode.
>There is no hwmode really required to go to hardware. So, introduce
>self for anybody who wants to target hardware.
Signed-off line is missing.
Other than that, the patch looks fine.
Reviewed-by: Jiri Pirko <jiri@resnulli.us>
Feel free to add my review line to the repost.
>---
> bridge/link.c | 3 +++
> 1 file changed, 3 insertions(+)
>
>diff --git a/bridge/link.c b/bridge/link.c
>index 90d9e7f..2b86141 100644
>--- a/bridge/link.c
>+++ b/bridge/link.c
>@@ -321,6 +321,9 @@ static int brlink_modify(int argc, char **argv)
> "\"veb\".\n");
> exit(-1);
> }
>+ } else if (strcmp(*argv, "self") == 0) {
>+ NEXT_ARG();
>+ flags = BRIDGE_FLAGS_SELF;
> } else {
> usage();
> }
>--
>1.7.10.4
>
^ permalink raw reply
* Re: [PATCH v2 1/6] net-PPP: Replacement of a printk() call by pr_warn() in mppe_rekey()
From: Joe Perches @ 2014-12-05 7:57 UTC (permalink / raw)
To: SF Markus Elfring
Cc: Sergei Shtylyov, Paul Mackerras, linux-ppp, netdev, Eric Dumazet,
LKML, kernel-janitors, Julia Lawall
In-Reply-To: <54815C5F.8090702@users.sourceforge.net>
On Fri, 2014-12-05 at 08:18 +0100, SF Markus Elfring wrote:
> >>> It's generally nicer to replace embedded function names
> >>> with "%s: ", __func__
> >>>
> >>> pr_warn("%s: cipher_encrypt failed\n", __func__);
> >>
> >> Do you want that I send a third patch series for the fine-tuning of these parameters?
> >
> > If you want.
>
> Would "a committer" fix such a small source code adjustment also without a resend of
> a patch series?
Depends on the committer. Some might, most wouldn't.
drivers/net/ppp doesn't have a specific maintainer.
The networking maintainer generally asks for resends
of patches that don't suit his taste, but lots of
non-perfect patches still get applied there.
It's a process, and it's not immediate. Wait to see
if these get applied as-is. If the embedded function
name use, which is trivial, bothers you, send another
patch later on that changes it.
> Does it make sense to express such implementation details in the Linux coding
> style documentation more explicitly (besides the fact that this update suggestion
> was also triggered by a warning from the script "checkpatch.pl").
Probably not.
Overly formalized coding style rules are perhaps
more of a barrier to entry than most want.
^ permalink raw reply
* Re: [RESEND PATCH] net: introduce helper macra CMSG_FOREACH_HDR
From: Joe Perches @ 2014-12-05 8:02 UTC (permalink / raw)
To: Gu Zheng; +Cc: davem, netdev, linux-kernel
In-Reply-To: <54815B40.1050909@cn.fujitsu.com>
On Fri, 2014-12-05 at 15:14 +0800, Gu Zheng wrote:
> Introduce helper macra
macro
> CMSG_FOREACH_HDR as a wrapper of the enumerating
> cmsghdr from msghdr, just cleanup.
maybe better to use lower case "for_each_cmsg_hdr"
or some such.
checkpatch would recognize that too as long as it
uses "for_each".
> diff --git a/include/linux/socket.h b/include/linux/socket.h
[]
> @@ -94,6 +94,10 @@ struct cmsghdr {
> (cmsg)->cmsg_len <= (unsigned long) \
> ((mhdr)->msg_controllen - \
> ((char *)(cmsg) - (char *)(mhdr)->msg_control)))
> +#define CMSG_FOREACH_HDR(cmsg, msg) \
> + for (cmsg = CMSG_FIRSTHDR(msg); \
> + cmsg; \
> + cmsg = CMSG_NXTHDR(msg, cmsg))
^ permalink raw reply
* Re: [PATCH v2 1/6] net-PPP: Replacement of a printk() call by pr_warn() in mppe_rekey()
From: SF Markus Elfring @ 2014-12-05 8:04 UTC (permalink / raw)
To: Julia Lawall, Joe Perches
Cc: Sergei Shtylyov, Paul Mackerras, linux-ppp, netdev, Eric Dumazet,
LKML, kernel-janitors
In-Reply-To: <alpine.DEB.2.02.1412050726000.2059@localhost6.localdomain6>
> Markus, are you sure that you cannot use netdev_warn in this case?
No. - I did not become familiar enough with the software infrastructure around
the mppe_rekey() function.
I do not see so far how I could determine a pointer for the first parameter there.
The data structure "ppp_mppe_state" (which is referenced by the input variable
"state") does not contain corresponding context information, does it?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH] net: ethernet: rocker: Add select to CONFIG_BRIDGE in Kconfig
From: Andreas Ruprecht @ 2014-12-05 8:28 UTC (permalink / raw)
To: David Miller
Cc: jim.epost, sfr, linux-next, linux-kernel, jiri, sfeldma, netdev
In-Reply-To: <20141204.202404.32587724475591669.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]
> On 05.12.2014 05:24, David Miller wrote:
> Do not use select, please.
>
> You can only use select on leaf node Kconfig symbols, ie. those
> which do not have any dependencies whatsoever.
>
> Select does not recursively walk down the dependency chain turning
> things on for you when you say "select X".
>
Okay, sure, my bad for not looking that up properly.
If we change this into a "depends on", this should not be a problem,
right? If CONFIG_BRIDGE is selected as 'm', then CONFIG_ROCKER can only
be 'n' or 'm', if CONFIG_BRIDGE is set to 'y', it can be 'n', 'm' or 'y'.
This also means that the prompt associated with CONFIG_ROCKER will only
show up in menuconfig when CONFIG_BRIDGE has been enabled (either 'm' or
'y').
I've attached an updated patch.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-net-ethernet-rocker-Add-dependency-to-CONFIG_BRIDGE-.patch --]
[-- Type: text/x-patch; name="0001-net-ethernet-rocker-Add-dependency-to-CONFIG_BRIDGE-.patch", Size: 1439 bytes --]
From 931a36cc5ec67ec23ba2373d42840d968ed78120 Mon Sep 17 00:00:00 2001
From: Andreas Ruprecht <rupran@einserver.de>
Date: Thu, 4 Dec 2014 18:28:09 +0100
Subject: [PATCH] net: ethernet: rocker: Add dependency to CONFIG_BRIDGE in
Kconfig
In a configuration with CONFIG_BRIDGE set to 'm' and CONFIG_ROCKER
set to 'y', undefined references occur at link time:
> drivers/built-in.o: In function `rocker_port_fdb_learn_work':
> /home/jim/linux/drivers/net/ethernet/rocker/rocker.c:3014: undefined
> reference to `br_fdb_external_learn_del'
> /home/jim/linux/drivers/net/ethernet/rocker/rocker.c:3016: undefined
> reference to `br_fdb_external_learn_add'
This patch fixes these by declaring CONFIG_ROCKER as being dependent
on CONFIG_BRIDGE.
Reported-by: Jim Davis <jim.epost@gmail.com>
Signed-off-by: Andreas Ruprecht <rupran@einserver.de>
---
drivers/net/ethernet/rocker/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/rocker/Kconfig b/drivers/net/ethernet/rocker/Kconfig
index 11a850eab628..b9952ef040e4 100644
--- a/drivers/net/ethernet/rocker/Kconfig
+++ b/drivers/net/ethernet/rocker/Kconfig
@@ -17,7 +17,7 @@ if NET_VENDOR_ROCKER
config ROCKER
tristate "Rocker switch driver (EXPERIMENTAL)"
- depends on PCI && NET_SWITCHDEV
+ depends on PCI && NET_SWITCHDEV && BRIDGE
---help---
This driver supports Rocker switch device.
--
1.9.1
^ permalink raw reply related
* Re: [RESEND PATCH] net: introduce helper macra CMSG_FOREACH_HDR
From: Gu Zheng @ 2014-12-05 8:29 UTC (permalink / raw)
To: Joe Perches; +Cc: davem, netdev, linux-kernel
In-Reply-To: <1417766552.2721.45.camel@perches.com>
Hi Joe,
Thanks for your comment.
On 12/05/2014 04:02 PM, Joe Perches wrote:
> On Fri, 2014-12-05 at 15:14 +0800, Gu Zheng wrote:
>> Introduce helper macra
>
> macro
Ah~, it's a typo.
>
>> CMSG_FOREACH_HDR as a wrapper of the enumerating
>> cmsghdr from msghdr, just cleanup.
>
> maybe better to use lower case "for_each_cmsg_hdr"
> or some such.
But this will make it out of the ordinary, as the existed ones
are all upper.
David, what's your opinion?
Regards,
Gu
>
> checkpatch would recognize that too as long as it
> uses "for_each".
>
>> diff --git a/include/linux/socket.h b/include/linux/socket.h
> []
>> @@ -94,6 +94,10 @@ struct cmsghdr {
>> (cmsg)->cmsg_len <= (unsigned long) \
>> ((mhdr)->msg_controllen - \
>> ((char *)(cmsg) - (char *)(mhdr)->msg_control)))
>> +#define CMSG_FOREACH_HDR(cmsg, msg) \
>> + for (cmsg = CMSG_FIRSTHDR(msg); \
>> + cmsg; \
>> + cmsg = CMSG_NXTHDR(msg, cmsg))
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [PATCH] net: ethernet: rocker: Add select to CONFIG_BRIDGE in Kconfig
From: Jiri Pirko @ 2014-12-05 8:32 UTC (permalink / raw)
To: Andreas Ruprecht
Cc: David Miller, jim.epost, sfr, linux-next, linux-kernel, sfeldma,
netdev
In-Reply-To: <54816C93.2020009@rupran.de>
Fri, Dec 05, 2014 at 09:28:03AM CET, mail@rupran.de wrote:
>
>> On 05.12.2014 05:24, David Miller wrote:
>> Do not use select, please.
>>
>> You can only use select on leaf node Kconfig symbols, ie. those
>> which do not have any dependencies whatsoever.
>>
>> Select does not recursively walk down the dependency chain turning
>> things on for you when you say "select X".
>>
>
>Okay, sure, my bad for not looking that up properly.
>
>If we change this into a "depends on", this should not be a problem,
>right? If CONFIG_BRIDGE is selected as 'm', then CONFIG_ROCKER can only
>be 'n' or 'm', if CONFIG_BRIDGE is set to 'y', it can be 'n', 'm' or 'y'.
>
>This also means that the prompt associated with CONFIG_ROCKER will only
>show up in menuconfig when CONFIG_BRIDGE has been enabled (either 'm' or
>'y').
>
>I've attached an updated patch.
>From 931a36cc5ec67ec23ba2373d42840d968ed78120 Mon Sep 17 00:00:00 2001
>From: Andreas Ruprecht <rupran@einserver.de>
>Date: Thu, 4 Dec 2014 18:28:09 +0100
>Subject: [PATCH] net: ethernet: rocker: Add dependency to CONFIG_BRIDGE in
> Kconfig
>
>In a configuration with CONFIG_BRIDGE set to 'm' and CONFIG_ROCKER
>set to 'y', undefined references occur at link time:
>
>> drivers/built-in.o: In function `rocker_port_fdb_learn_work':
>> /home/jim/linux/drivers/net/ethernet/rocker/rocker.c:3014: undefined
>> reference to `br_fdb_external_learn_del'
>> /home/jim/linux/drivers/net/ethernet/rocker/rocker.c:3016: undefined
>> reference to `br_fdb_external_learn_add'
>
>This patch fixes these by declaring CONFIG_ROCKER as being dependent
>on CONFIG_BRIDGE.
>
>Reported-by: Jim Davis <jim.epost@gmail.com>
>Signed-off-by: Andreas Ruprecht <rupran@einserver.de>
Acked-by: Jiri Pirko <jiri@resnulli.us>
>---
> drivers/net/ethernet/rocker/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/net/ethernet/rocker/Kconfig b/drivers/net/ethernet/rocker/Kconfig
>index 11a850eab628..b9952ef040e4 100644
>--- a/drivers/net/ethernet/rocker/Kconfig
>+++ b/drivers/net/ethernet/rocker/Kconfig
>@@ -17,7 +17,7 @@ if NET_VENDOR_ROCKER
>
> config ROCKER
> tristate "Rocker switch driver (EXPERIMENTAL)"
>- depends on PCI && NET_SWITCHDEV
>+ depends on PCI && NET_SWITCHDEV && BRIDGE
> ---help---
> This driver supports Rocker switch device.
>
>--
>1.9.1
>
^ permalink raw reply
* Re: [PATCH v2 1/6] net-PPP: Replacement of a printk() call by pr_warn() in mppe_rekey()
From: Julia Lawall @ 2014-12-05 8:40 UTC (permalink / raw)
To: SF Markus Elfring
Cc: Julia Lawall, Joe Perches, Sergei Shtylyov, Paul Mackerras,
linux-ppp, netdev, Eric Dumazet, LKML, kernel-janitors
In-Reply-To: <54816700.6090501@users.sourceforge.net>
On Fri, 5 Dec 2014, SF Markus Elfring wrote:
> > Markus, are you sure that you cannot use netdev_warn in this case?
>
> No. - I did not become familiar enough with the software infrastructure around
> the mppe_rekey() function.
>
> I do not see so far how I could determine a pointer for the first parameter there.
> The data structure "ppp_mppe_state" (which is referenced by the input variable
> "state") does not contain corresponding context information, does it?
Indeed, I also don't see anything promising.
julia
^ permalink raw reply
* CAN presume-ack feature
From: Nikita Edward Baruzdin @ 2014-12-05 8:41 UTC (permalink / raw)
To: linux-can, netdev
In-Reply-To: <1417766390-4587-1-git-send-email-nebaruzdin@gmail.com>
Hello, all.
I just remembered about this small patch I promised to submit.
It corresponds to an earlier introduced change in SocketCAN subsystem, see
http://thread.gmane.org/gmane.linux.can/6110
^ permalink raw reply
* [PATCH] iproute2: Add support for CAN presume-ack feature
From: Nikita Edward Baruzdin @ 2014-12-05 8:41 UTC (permalink / raw)
To: linux-can, netdev
In-Reply-To: <1417768902-5404-1-git-send-email-nebaruzdin@gmail.com>
This patch makes CAN_CTRLMODE_PRESUME_ACK netlink feature configurable.
When enabled, the feature sets CAN controller in mode in which
acknowledgement absence is ignored.
Signed-off-by: Nikita Edward Baruzdin <nebaruzdin@gmail.com>
---
ip/iplink_can.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/ip/iplink_can.c b/ip/iplink_can.c
index 5b92426..fb50332 100644
--- a/ip/iplink_can.c
+++ b/ip/iplink_can.c
@@ -37,6 +37,7 @@ static void print_usage(FILE *f)
"\t[ one-shot { on | off } ]\n"
"\t[ berr-reporting { on | off } ]\n"
"\t[ fd { on | off } ]\n"
+ "\t[ presume-ack { on | off } ]\n"
"\n"
"\t[ restart-ms TIME-MS ]\n"
"\t[ restart ]\n"
@@ -99,6 +100,7 @@ static void print_ctrlmode(FILE *f, __u32 cm)
_PF(CAN_CTRLMODE_ONE_SHOT, "ONE-SHOT");
_PF(CAN_CTRLMODE_BERR_REPORTING, "BERR-REPORTING");
_PF(CAN_CTRLMODE_FD, "FD");
+ _PF(CAN_CTRLMODE_PRESUME_ACK, "PRESUME-ACK");
#undef _PF
if (cm)
fprintf(f, "%x", cm);
@@ -201,6 +203,10 @@ static int can_parse_opt(struct link_util *lu, int argc, char **argv,
NEXT_ARG();
set_ctrlmode("fd", *argv, &cm,
CAN_CTRLMODE_FD);
+ } else if (matches(*argv, "presume-ack") == 0) {
+ NEXT_ARG();
+ set_ctrlmode("presume-ack", *argv, &cm,
+ CAN_CTRLMODE_PRESUME_ACK);
} else if (matches(*argv, "restart") == 0) {
__u32 val = 1;
--
2.1.3
^ permalink raw reply related
* Re: [PATCH v2 1/6] net-PPP: Replacement of a printk() call by pr_warn() in mppe_rekey()
From: SF Markus Elfring @ 2014-12-05 8:49 UTC (permalink / raw)
To: Joe Perches
Cc: Sergei Shtylyov, Paul Mackerras, linux-ppp, netdev, Eric Dumazet,
LKML, kernel-janitors, Julia Lawall
In-Reply-To: <1417766255.2721.43.camel@perches.com>
> It's a process, and it's not immediate. Wait to see
> if these get applied as-is.
Thanks for your constructive feedback.
> If the embedded function name use, which is trivial, bothers you,
> send another patch later on that changes it.
Not really at the moment ...
I guess that I would prefer a general development of another semantic
patch approach according to your request with the topic "Finding embedded
function names?" a moment ago.
https://systeme.lip6.fr/pipermail/cocci/2014-December/001517.html
http://article.gmane.org/gmane.comp.version-control.coccinelle/4399
Regards,
Markus
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Bjørn Mork @ 2014-12-05 9:42 UTC (permalink / raw)
To: Kevin Zhu
Cc: Enrico Mioso, Midge Shaojun Tan, Eli Britstein, Alex Strizhevsky,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <54811670.5030703-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> writes:
> Regarding the location of NDP, it should be easy to fix. It can be added
> to the end of the NTB only after it's ready to send.
Yes, but this will require a bit of redesign. Note that this code is
shared with cdc_mbim, which might have to add multiple NDPs for
multiplexed sessions. In theory up to 512 different, but that is so
unlinkely that we can ignore it. We could set a fixed limit
significantly lower than that if necessary.
I'd really like to refactor this code to simply queue the skbs, creating
the linear NTB only when the queue is flushed. Then we'll have all the
info we need and can order the contents any way we want without adding
unnecessary padding.
> Regarding the
> concern to other devices, as there's a particular driver for Huawei
> devices in kernel, which is huawei_cdc_ncm, maybe we can just fix the TX
> function there to avoid breaking other devices.
Sure. That is definitely an alternative if we don't want to touch the
generic driver.
But making the generic driver flexible enough to accommodate any device
would be preferable. I do hope we can do that.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* [PATCH] net: fix the flow limitation computation
From: roy.qing.li @ 2014-12-05 9:48 UTC (permalink / raw)
To: netdev
From: Li RongQing <roy.qing.li@gmail.com>
Once RPS is enabled, the skb maybe enqueue to different CPU, so the
flow limitation computation should use the enqueued CPU, not the local
CPU
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
net/core/dev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 945bbd0..e70507d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3250,7 +3250,7 @@ static int rps_ipi_queued(struct softnet_data *sd)
int netdev_flow_limit_table_len __read_mostly = (1 << 12);
#endif
-static bool skb_flow_limit(struct sk_buff *skb, unsigned int qlen)
+static bool skb_flow_limit(struct sk_buff *skb, unsigned int qlen, int cpu)
{
#ifdef CONFIG_NET_FLOW_LIMIT
struct sd_flow_limit *fl;
@@ -3260,7 +3260,7 @@ static bool skb_flow_limit(struct sk_buff *skb, unsigned int qlen)
if (qlen < (netdev_max_backlog >> 1))
return false;
- sd = this_cpu_ptr(&softnet_data);
+ sd = &per_cpu(softnet_data, cpu);
rcu_read_lock();
fl = rcu_dereference(sd->flow_limit);
@@ -3303,7 +3303,7 @@ static int enqueue_to_backlog(struct sk_buff *skb, int cpu,
rps_lock(sd);
qlen = skb_queue_len(&sd->input_pkt_queue);
- if (qlen <= netdev_max_backlog && !skb_flow_limit(skb, qlen)) {
+ if (qlen <= netdev_max_backlog && !skb_flow_limit(skb, qlen, cpu)) {
if (skb_queue_len(&sd->input_pkt_queue)) {
enqueue:
__skb_queue_tail(&sd->input_pkt_queue, skb);
--
2.1.0
^ permalink raw reply related
* [PATCH][net-next] net: avoid to call skb_queue_len again
From: roy.qing.li @ 2014-12-05 9:49 UTC (permalink / raw)
To: netdev
From: Li RongQing <roy.qing.li@gmail.com>
the queue length of sd->input_pkt_queue has been putted into qlen,
and impossible to change, since hold the lock
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 0814a56..b954400 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3297,7 +3297,7 @@ static int enqueue_to_backlog(struct sk_buff *skb, int cpu,
rps_lock(sd);
qlen = skb_queue_len(&sd->input_pkt_queue);
if (qlen <= netdev_max_backlog && !skb_flow_limit(skb, qlen)) {
- if (skb_queue_len(&sd->input_pkt_queue)) {
+ if (qlen) {
enqueue:
__skb_queue_tail(&sd->input_pkt_queue, skb);
input_queue_tail_incr_save(sd, qtail);
--
2.1.0
^ permalink raw reply related
* RE: [patch iproute2 1/6] iproute2: ipa: show switch id
From: David Laight @ 2014-12-05 9:54 UTC (permalink / raw)
To: 'Eric W. Biederman', Jiri Pirko
Cc: netdev@vger.kernel.org, davem@davemloft.net,
nhorman@tuxdriver.com, andy@greyhouse.net, tgraf@suug.ch,
dborkman@redhat.com, ogerlitz@mellanox.com, jesse@nicira.com,
pshelar@nicira.com, azhou@nicira.com, ben@decadent.org.uk,
stephen@networkplumber.org, jeffrey.t.kirsher@intel.com,
vyasevic@redhat.com, xiyou.wangcong@gmail.com,
john.r.fastabend@intel.com, edumazet@google.com, jhs@mojatatu.com,
sfeldma@gmail.com
In-Reply-To: <87388vw2xg.fsf@x220.int.ebiederm.org>
From: Eric W. Biederman
> Jiri Pirko <jiri@resnulli.us> writes:
>
> > Thu, Dec 04, 2014 at 09:06:14PM CET, ebiederm@xmission.com wrote:
> >>ebiederm@xmission.com (Eric W. Biederman) writes:
> >>
> >>> Jiri Pirko <jiri@resnulli.us> writes:
> >>>
> >>>>>So this id needs to be globally unique?
> >>>>
> >>>> No. It is enough to be unique within a single system. It serves for no
> >>>> more than to find out 2 ids are same or not, no other info value.
> >>>>
> >>>> So when the drivers uses sane ids (like mac for example, or in case of
> >>>> rocker an id which is passed by qemu command line), the chances of
> >>>> collision are very very close to none (never say never).
> >>
> >>Thinking about what you said a little more.
> >>
> >>Two different sources of persistent numbers picking numbers by
> >>completely different algorithms can give you no assurance that you don't
> >>produce conflicts.
> >>
> >>The switch id as desisgned can not work.
> >>
> >>There are expected to be between 2**36 to 2**40 devices in this world.
> >>Your first switch id is a 64it number. At the very best by the birthday
> >>pardox predicts there will be a conflict ever 2**32 devices or between
> >>2**4 and 2**8 devices in the world with conflicts. If the ids are not
> >>randomly distributed (which they won't be) things could easily be much
> >>much worse.
> >>
> >>That is just good enough the code could get out there and run for years
> >>before you have the nightmare of having to fix all of userspace. That
> >>is a nightmare no one needs.
> >>
> >>So please remove this broken code, and this broken concept from the
> >>kernel and go back to the drawing board.
> >
> > In that case the phys port id is broken in the same way. Let's rather
> > think about how to avoid conflicts for both. Given the fact the
> > conflicts should be avoided only on a single baremetal, that should be
> > doable (for (bad) example using driver name mixed with driver created
> > id).
>
> No. phys_port_id is not broken in the same way, and phys_port_id does
> not have the same set of properties.
>
> phys_port_id's in practice all have an IEEE prefix that identifies the
> manufacturer and a manufacture assigned serial number. Aka a mac
> address or a EUID-64. What the mlx4 ethernet driver is doing retunring
> a 64bit EUID-64 I don't know. If there are problems in the worst
> case issues with phys_port_id are fixable by simple driver tweaks,
> because fundamentally we are working with globally uniuqe identifiers.
> Well globally unique baring manufacturing bugs in eeproms.
Manufacturers have to generate unique MAC addresses - otherwise people complain.
But can't be assumed to put different 'serial numbers' in other devices.
If you look at USB memory sticks you are likely to find that the serial
number in the (equivalent of the) ATA identify response isn't unique.
So I doubt you can use the value to distinguish between devices.
You also get the situation where ethernet MAC addresses only have to be
unique within a collision domain. Many old sun systems used a single MAC
address - valid because they assumed/required that multiple interfaces
be connected to different networks.
So even MAC addresses aren't per-interface.
David
^ permalink raw reply
* Re: 3.12.33 - BUG xfrm_selector_match+0x25/0x2f6
From: Julian Anastasov @ 2014-12-05 9:55 UTC (permalink / raw)
To: Smart Weblications GmbH - Florian Wiessner
Cc: Steffen Klassert, netdev, LKML, stable, Simon Horman, lvs-devel
In-Reply-To: <5481173A.9060308@smart-weblications.de>
Hello,
Adding Simon to CC...
On Fri, 5 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:
> i tried with 3.12.33 without any XFRM and now got this one (which is reproducable):
>
> [ 233.956012] BUG: unable to handle kernel NULL pointer dereference at 00000000
> 00000014
> [ 233.956218] IP: [<ffffffffa013a470>] nf_ct_seqadj_set+0x60/0x90 [nf_conntrack
It seems fix from 3.13 was not sent to 3.12 stable:
commit b25adce1606427fd8 ("ipvs: correct usage/allocation of seqadj ext in
ipvs")
There was related change but it is not needed
for stable kernels:
commit db12cf27435356017e ("netfilter: WARN about wrong usage of sequence
number adjustments"
Simon, can we try commit b25adce1606427fd8 for 3.12?
> setup is like this:
>
>
> #virtual=<myVIP>:21
> # real=10.10.1.20:21 masq
> # real=10.10.1.21:21 masq
> # real=10.10.1.22:21 masq
> # real=10.10.1.23:21 masq
> # persistent=600
> # service=ftp
> # scheduler=rr
> # protocol=tcp
> # checktype=connect
>
> ( i remarked it to prevent fruther crashes...)
>
> when ip_vs_ftp is loaded and someone trying to make a ftp connection, the system
> panics instantly.
>
> 10.10.1.20 - 10.10.1.23 are lxc-containers using veth connected to the bridge
> running on 4 different nodes. The node running ldirector/ipvsadm has also one of
> those containers running (don't know if that matters)
It is always good to know the setup. Do you access VIP
from local clients (from director)?
> brctl show
> bridge name bridge id STP enabled interfaces
> br0 8000.00259052bbf4 no bond0
> vethMKELUc
> vethXdWGqf
> vethgJMmEb
> vethmKNqFc
>
>
> I disabled the ftp server lxc container on the node doing ip_vs, so that the
> endpoint of the connection is not on the same node and tried again but with the
> same result.
>
> Unfortunatelly i cannot test with newer kernels than 3.12, because ocfs2 is
> somehow broken in >= 3.14
Before I create patch to avoid rerouting for
LOCAL_IN you can try to set IPVS sysctl var "snat_reroute" to 0
or even to change ip_vs_route_me_harder() function just to return 0.
snat_reroute=1 (a default value) is needed if you have
multiple links to clients and use ip rules to select
correct route by src ip (after SNAT). If you have single
uplink snat_reroute can be 0.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* RE: [patch net-next v2 1/2] rocker: introduce be put/get variants and use it when appropriate
From: David Laight @ 2014-12-05 9:57 UTC (permalink / raw)
To: 'Scott Feldman', Jiri Pirko; +Cc: Netdev, David S. Miller
In-Reply-To: <CAE4R7bAgSji_rt3147Kt8jqyT5_yqBCbKjSLgZVa8xkRc0dndA@mail.gmail.com>
From: Scott Feldman
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
>
> On Wed, Dec 3, 2014 at 5:14 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> > This kills the sparse warnings.
> >
> > Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> > ---
> > v1->v2:
> > -no change
> > ---
> > drivers/net/ethernet/rocker/rocker.c | 79 ++++++++++++++++++++++--------------
> > 1 file changed, 48 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
> > index fded127..4b060fb 100644
> > --- a/drivers/net/ethernet/rocker/rocker.c
> > +++ b/drivers/net/ethernet/rocker/rocker.c
> > @@ -648,6 +648,11 @@ static u16 rocker_tlv_get_u16(const struct rocker_tlv *tlv)
> > return *(u16 *) rocker_tlv_data(tlv);
> > }
> >
> > +static __be16 rocker_tlv_get_be16(const struct rocker_tlv *tlv)
> > +{
> > + return *(__be16 *) rocker_tlv_data(tlv);
> > +}
*(int_type *)foo always rings alarm bells.....
That looks dubious on systems where misaligned transfers fault.
David
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Enrico Mioso @ 2014-12-05 9:59 UTC (permalink / raw)
To: Bjørn Mork
Cc: Kevin Zhu, Midge Shaojun Tan, Eli Britstein, Alex Strizhevsky,
youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <8761dqjuuh.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
Yes Bjorn: I should say that's true.
and - in general, touching the device driver to make it flexible is surely
important, especially to make it more easy to fix / "expand" in the future.
I was referring to modifying the huawei_cdc_ncm.c driver only for specific
huawei workarounds / firmware misbehaviours.
thank to everyone,
Enrico
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* Re: am335x: cpsw: interrupt failure
From: Yegor Yefremov @ 2014-12-05 10:03 UTC (permalink / raw)
To: Felipe Balbi; +Cc: netdev, N, Mugunthan V
In-Reply-To: <20141204165609.GJ18045@saruman>
[-- Attachment #1: Type: text/plain, Size: 2645 bytes --]
On Thu, Dec 4, 2014 at 5:56 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Thu, Dec 04, 2014 at 05:41:38PM +0100, Yegor Yefremov wrote:
>> I have following problem. My systems reboots at high network load
>> after this commit (found via git bissect):
>>
>> commit 55601c9f24670ba926ebdd4d712ac3b177232330
>> Author: Felipe Balbi <balbi@ti.com>
>> Date: Mon Sep 8 17:54:58 2014 -0700
>>
>> arm: omap: intc: switch over to linear irq domain
>>
>> now that we don't need to support legacy board-files,
>> we can completely switch over to a linear irq domain
>> and make use of irq_alloc_domain_generic_chips() to
>> allocate all generic irq chips for us.
>>
>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>>
>> and I get following error messages:
>>
>> irq 0, desc: cf004000, depth: 1, count: 0, unhandled: 0
>
> irq 0 ? Weird, that's not a valid IRQ.
>
>> ->handle_irq(): c0087fc0, handle_bad_irq+0x0/0x258
>> ->irq_data.chip(): c08e7174, no_irq_chip+0x0/0x68
>> ->action(): (null)
>> IRQ_NOPROBE set
>> IRQ_NOREQUEST set
>> irq 0, desc: cf004000, depth: 1, count: 0, unhandled: 0
>> ->handle_irq(): c0087fc0, handle_bad_irq+0x0/0x258
>> ->irq_data.chip(): c08e7174, no_irq_chip+0x0/0x68
>> ->action(): (null)
>> IRQ_NOPROBE set
>> IRQ_NOREQUEST set
>> irq 0, desc: cf004000, depth: 1, count: 0, unhandled: 0
>> ->handle_irq(): c0087fc0, handle_bad_irq+0x0/0x258
>> ->irq_data.chip(): c08e7174, no_irq_chip+0x0/0x68
>> ->action(): (null)
>> IRQ_NOPROBE set
>> IRQ_NOREQUEST set
>> irq 0, desc: cf004000, depth: 1, count: 0, unhandled: 0
>> ->handle_irq(): c0087fc0, handle_bad_irq+0x0/0x258
>> ->irq_data.chip(): c08e7174, no_irq_chip+0x0/0x68
>> ->action(): (null)
>>
>> My system: am335x with fast ethernet on the first slave and gigabit
>> Ethernet on second CPSW slave. This issue occurs, when I ran nuttcp
>> with default settings.
>>
>> With commit above I can at least see these messages, but 3.18-rc7 for
>> example reboots without any messages.
>>
>> Any idea?
>
> if you take v3.18-rc7 and just revert that commit, does the problem go
> away ?
git revert failed as the driver has more changes meanwhile or I'm
missing some params. I've tried to force the driver to use legacy
routines, but then I don't get pass U-Boot's "Starting kernel ..." See
attached patch.
Compiler used:
Linux version 3.18.0-rc7 (...) (gcc version 4.8.3 20140320
(prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #309 SMP Fri Dec 5
10:59:38 CET 2014
Btw, what am335x based hardware do you have? I can run tests on both
BBB and am335x-evmsk.
Yegor
[-- Attachment #2: 0001-Irq-patch-revert.patch --]
[-- Type: application/octet-stream, Size: 2338 bytes --]
From 889a0588e884083399e644909ec39e834f37c4d3 Mon Sep 17 00:00:00 2001
From: Yegor Yefremov <yegorslists@googlemail.com>
Date: Fri, 5 Dec 2014 10:54:37 +0100
Subject: [PATCH] Irq patch revert
---
drivers/irqchip/irq-omap-intc.c | 21 +++++++++++++++------
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index 28718d3..a60a0ac 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -186,6 +186,7 @@ void omap3_intc_suspend(void)
omap_ack_irq(NULL);
}
+#if 0
static int __init omap_alloc_gc_of(struct irq_domain *d, void __iomem *base)
{
int ret;
@@ -222,7 +223,7 @@ static int __init omap_alloc_gc_of(struct irq_domain *d, void __iomem *base)
return 0;
}
-
+#endif
static void __init omap_alloc_gc_legacy(void __iomem *base,
unsigned int irq_start, unsigned int num)
{
@@ -243,6 +244,7 @@ static void __init omap_alloc_gc_legacy(void __iomem *base,
IRQ_NOREQUEST | IRQ_NOPROBE, 0);
}
+#if 0
static int __init omap_init_irq_of(struct device_node *node)
{
int ret;
@@ -262,6 +264,7 @@ static int __init omap_init_irq_of(struct device_node *node)
return ret;
}
+#endif
static int __init omap_init_irq_legacy(u32 base)
{
@@ -301,13 +304,13 @@ static int __init omap_init_irq(u32 base, struct device_node *node)
{
int ret;
- if (node)
+ /*if (node)
ret = omap_init_irq_of(node);
- else
+ else*/
ret = omap_init_irq_legacy(base);
- if (ret == 0)
- omap_irq_enable_protection();
+ /*if (ret == 0)
+ omap_irq_enable_protection();*/
return ret;
}
@@ -376,6 +379,7 @@ static int __init intc_of_init(struct device_node *node,
struct device_node *parent)
{
int ret;
+ struct resource res;
omap_nr_pending = 3;
omap_nr_irqs = 96;
@@ -383,12 +387,17 @@ static int __init intc_of_init(struct device_node *node,
if (WARN_ON(!node))
return -ENODEV;
+ if (of_address_to_resource(node, 0, &res)) {
+ WARN(1, "unable to get intc registers\n");
+ return -EINVAL;
+ }
+
if (of_device_is_compatible(node, "ti,am33xx-intc")) {
omap_nr_irqs = 128;
omap_nr_pending = 4;
}
- ret = omap_init_irq(-1, of_node_get(node));
+ ret = omap_init_irq(res.start, of_node_get(node));
if (ret < 0)
return ret;
--
1.7.7
^ permalink raw reply related
* [PATCH] broadcom: Add BCM54616S phy support
From: Alessio Igor Bogani @ 2014-12-05 9:16 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, Alessio Igor Bogani
Signed-off-by: Alessio Igor Bogani <alessio.bogani@elettra.eu>
---
drivers/net/phy/Kconfig | 4 ++--
drivers/net/phy/broadcom.c | 14 ++++++++++++++
include/linux/brcmphy.h | 1 +
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 75472cf7..eb35dcb 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -68,8 +68,8 @@ config SMSC_PHY
config BROADCOM_PHY
tristate "Drivers for Broadcom PHYs"
---help---
- Currently supports the BCM5411, BCM5421, BCM5461, BCM5464, BCM5481
- and BCM5482 PHYs.
+ Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S, BCM5464,
+ BCM5481 and BCM5482 PHYs.
config BCM63XX_PHY
tristate "Drivers for Broadcom 63xx SOCs internal PHY"
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 854f2c9..74cbf45 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -549,6 +549,19 @@ static struct phy_driver broadcom_drivers[] = {
.config_intr = bcm54xx_config_intr,
.driver = { .owner = THIS_MODULE },
}, {
+ .phy_id = PHY_ID_BCM54616S,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Broadcom BCM54616S",
+ .features = PHY_GBIT_FEATURES |
+ SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = bcm54xx_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = bcm54xx_ack_interrupt,
+ .config_intr = bcm54xx_config_intr,
+ .driver = { .owner = THIS_MODULE },
+}, {
.phy_id = PHY_ID_BCM5464,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5464",
@@ -673,6 +686,7 @@ static struct mdio_device_id __maybe_unused broadcom_tbl[] = {
{ PHY_ID_BCM5411, 0xfffffff0 },
{ PHY_ID_BCM5421, 0xfffffff0 },
{ PHY_ID_BCM5461, 0xfffffff0 },
+ { PHY_ID_BCM54616S, 0xfffffff0 },
{ PHY_ID_BCM5464, 0xfffffff0 },
{ PHY_ID_BCM5482, 0xfffffff0 },
{ PHY_ID_BCM5482, 0xfffffff0 },
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index 7ccd928..1c9920b 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -11,6 +11,7 @@
#define PHY_ID_BCM5421 0x002060e0
#define PHY_ID_BCM5464 0x002060b0
#define PHY_ID_BCM5461 0x002060c0
+#define PHY_ID_BCM54616S 0x03625d10
#define PHY_ID_BCM57780 0x03625d90
#define PHY_ID_BCM7250 0xae025280
--
2.1.3
^ permalink raw reply related
* Re: [patch net-next v2 1/2] rocker: introduce be put/get variants and use it when appropriate
From: Jiri Pirko @ 2014-12-05 10:25 UTC (permalink / raw)
To: David Laight; +Cc: 'Scott Feldman', Netdev, David S. Miller
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CA033CC@AcuExch.aculab.com>
Fri, Dec 05, 2014 at 10:57:43AM CET, David.Laight@ACULAB.COM wrote:
>From: Scott Feldman
>> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
>>
>> On Wed, Dec 3, 2014 at 5:14 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> > This kills the sparse warnings.
>> >
>> > Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> > ---
>> > v1->v2:
>> > -no change
>> > ---
>> > drivers/net/ethernet/rocker/rocker.c | 79 ++++++++++++++++++++++--------------
>> > 1 file changed, 48 insertions(+), 31 deletions(-)
>> >
>> > diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
>> > index fded127..4b060fb 100644
>> > --- a/drivers/net/ethernet/rocker/rocker.c
>> > +++ b/drivers/net/ethernet/rocker/rocker.c
>> > @@ -648,6 +648,11 @@ static u16 rocker_tlv_get_u16(const struct rocker_tlv *tlv)
>> > return *(u16 *) rocker_tlv_data(tlv);
>> > }
>> >
>> > +static __be16 rocker_tlv_get_be16(const struct rocker_tlv *tlv)
>> > +{
>> > + return *(__be16 *) rocker_tlv_data(tlv);
>> > +}
>
>*(int_type *)foo always rings alarm bells.....
>
>That looks dubious on systems where misaligned transfers fault.
This is common use:
for example nla_get_be16
but when you grep kernel, you see many more.
Also, rocker has all accesses like these aligned.
>
> David
>
^ permalink raw reply
* [PATCH 0/2] DMA API usage fixes in gianfar
From: Arseny Solokha @ 2014-12-05 10:37 UTC (permalink / raw)
To: Claudiu Manoil; +Cc: netdev, linux-kernel, Arseny Solokha
Hello.
This patch set fixes DMA API usage issues in gianfar ethernet driver
reported by the kernel w/ DMA API debug enabled.
There were even reports that the kernel sometimes oopsed in the past
because of kernel paging request handling failures, though it was likely
observed on some ancient versions. And while I personally doesn't have
any strong evidence of this, there's no reason to let these possible
failures live any longer.
Arseny Solokha (2):
gianfar: handle map error in gfar_new_rxbdp()
gianfar: handle map error in gfar_start_xmit()
drivers/net/ethernet/freescale/gianfar.c | 49 ++++++++++++++++++++++++++------
1 file changed, 41 insertions(+), 8 deletions(-)
--
Regards,
Arseny Solokha.
^ permalink raw reply
* [PATCH 1/2] gianfar: handle map error in gfar_new_rxbdp()
From: Arseny Solokha @ 2014-12-05 10:37 UTC (permalink / raw)
To: Claudiu Manoil; +Cc: netdev, linux-kernel, Arseny Solokha
In-Reply-To: <1417775874-17775-1-git-send-email-asolokha@kb.kras.ru>
From: Arseny Solokha <asolokha@kb.kras.ru>
When DMA-API debugging is enabled in the kernel, it spews the following
upon upping the link:
fsl-gianfar ffe25000.ethernet: DMA-API: device driver failed to check map error[device address=0x0000000005f41012] [size=90 bytes] [map-
WARNING: at lib/dma-debug.c:1135
Modules linked in:
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G O 3.18.0-rc7 #1
task: ee06f080 ti: effde000 task.ti: ee0b2000
NIP: c01d7c1c LR: c01d7c1c CTR: 00000000
REGS: effdfd40 TRAP: 0700 Tainted: G O (3.18.0-rc7)
MSR: 00021000 <CE,ME> CR: 42804442 XER: 00000000
GPR00: c01d7c1c effdfdf0 ee06f080 00000097 00000001 c0066dd8 00000000 00000001
GPR08: 00000000 00000000 effde000 0000029e 00000000 00000000 c55fa740 ee0d6818
GPR16: r00000600 c5a6a9c0 ee0d6830 ee0d6850 ffff8100 00000008 00000000 c5bbc800
GPR24: c0730000 00029000 c0d0b828 c072c394 effdfe48 c075baec c0d0f020 ee308300
NIP [c01d7c1c] check_unmap+0x5b4/0xae4
LR [c01d7c1c] check_unmap+0x5b4/0xae4
Call Trace:
[effdfdf0] [c01d7c1c] check_unmap+0x5b4/0xae4 (unreliable)
[effdfe40] [c01d81c4] debug_dma_unmap_page+0x78/0x8c
[effdfec0] [c028b270] gfar_clean_rx_ring+0x114/0x4c0
[effdff30] [c028b814] gfar_poll_rx_sq+0x3c/0xa4
[effdff50] [c030c388] net_rx_action+0x130/0x1ac
[effdff80] [c00319e0] __do_softirq+0x134/0x240
[effdffe0] [c0031dd0] irq_exit+0xa4/0xc8
[effdfff0] [c000e01c] call_do_irq+0x24/0x3c
[ee0b3e60] [c0004a04] do_IRQ+0x8c/0x108
[ee0b3e80] [c0010068] ret_from_except+0x0/0x18
--- interrupt: 501 at arch_cpu_idle+0x24/0x5c
LR = arch_cpu_idle+0x24/0x5c
[ee0b3f40] [c007d2e4] rcu_idle_enter+0xc8/0xcc (unreliable)
[ee0b3f50] [c006587c] cpu_startup_entry+0x1d4/0x29c
[ee0b3fa0] [c00111cc] start_secondary+0x364/0x478
[ee0b3ff0] [c000217c] __secondary_start+0x7c/0xc8
Instruction dump:
394adb30 80fc0018 811c001c 3c60c04f 5529103a 7cca482e 38639e60 813c0020
815c0024 90c10008 4cc63182 48240b01 <0fe00000> 3c60c04f 3863971c 4cc63182
---[ end trace 3eb7bf62ba1b80f8 ]---
oMapped at:
[<c02887cc>] gfar_new_rxbdp.isra.4+0x120/0x16c
[<c0288968>] gfar_init_bds+0x150/0x1b0
[<c028a800>] startup_gfar+0x334/0x3d8
[<c028ac64>] gfar_enet_open+0x2b8/0x460
[<c03100c0>] __dev_open+0xdc/0x150
And the underlying code indeed doesn't perform the check.
Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
---
drivers/net/ethernet/freescale/gianfar.c | 32 ++++++++++++++++++++++++++------
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index 4fdf0aa..f34ca55 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -117,8 +117,8 @@ static void gfar_reset_task(struct work_struct *work);
static void gfar_timeout(struct net_device *dev);
static int gfar_close(struct net_device *dev);
struct sk_buff *gfar_new_skb(struct net_device *dev);
-static void gfar_new_rxbdp(struct gfar_priv_rx_q *rx_queue, struct rxbd8 *bdp,
- struct sk_buff *skb);
+static int gfar_new_rxbdp(struct gfar_priv_rx_q *rx_queue, struct rxbd8 *bdp,
+ struct sk_buff *skb);
static int gfar_set_mac_address(struct net_device *dev);
static int gfar_change_mtu(struct net_device *dev, int new_mtu);
static irqreturn_t gfar_error(int irq, void *dev_id);
@@ -214,6 +214,8 @@ static int gfar_init_bds(struct net_device *ndev)
gfar_init_rxbdp(rx_queue, rxbdp,
rxbdp->bufPtr);
} else {
+ int ret;
+
skb = gfar_new_skb(ndev);
if (!skb) {
netdev_err(ndev, "Can't allocate RX buffers\n");
@@ -221,7 +223,11 @@ static int gfar_init_bds(struct net_device *ndev)
}
rx_queue->rx_skbuff[j] = skb;
- gfar_new_rxbdp(rx_queue, rxbdp, skb);
+ ret = gfar_new_rxbdp(rx_queue, rxbdp, skb);
+ if (ret) {
+ netdev_err(ndev, "Buffer mapping error\n");
+ return ret;
+ }
}
rxbdp++;
@@ -2606,8 +2612,8 @@ static void gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
netdev_tx_completed_queue(txq, howmany, bytes_sent);
}
-static void gfar_new_rxbdp(struct gfar_priv_rx_q *rx_queue, struct rxbd8 *bdp,
- struct sk_buff *skb)
+static int gfar_new_rxbdp(struct gfar_priv_rx_q *rx_queue, struct rxbd8 *bdp,
+ struct sk_buff *skb)
{
struct net_device *dev = rx_queue->dev;
struct gfar_private *priv = netdev_priv(dev);
@@ -2615,7 +2621,12 @@ static void gfar_new_rxbdp(struct gfar_priv_rx_q *rx_queue, struct rxbd8 *bdp,
buf = dma_map_single(priv->dev, skb->data,
priv->rx_buffer_size, DMA_FROM_DEVICE);
+ if (dma_mapping_error(priv->dev, buf))
+ return -EFAULT;
+
gfar_init_rxbdp(rx_queue, bdp, buf);
+
+ return 0;
}
static struct sk_buff *gfar_alloc_skb(struct net_device *dev)
@@ -2805,6 +2816,7 @@ int gfar_clean_rx_ring(struct gfar_priv_rx_q *rx_queue, int rx_work_limit)
while (!((bdp->status & RXBD_EMPTY) || (--rx_work_limit < 0))) {
struct sk_buff *newskb;
+ int rxbdpret;
rmb();
@@ -2854,7 +2866,15 @@ int gfar_clean_rx_ring(struct gfar_priv_rx_q *rx_queue, int rx_work_limit)
rx_queue->rx_skbuff[rx_queue->skb_currx] = newskb;
/* Setup the new bdp */
- gfar_new_rxbdp(rx_queue, bdp, newskb);
+ rxbdpret = gfar_new_rxbdp(rx_queue, bdp, newskb);
+ if (unlikely(rxbdpret)) {
+ /* We drop the frame if we failed to map a new DMA
+ * buffer
+ */
+ count_errors(bdp->status, dev);
+ dev_kfree_skb(newskb);
+ continue;
+ }
/* Update to the next pointer */
bdp = next_bd(bdp, base, rx_queue->rx_ring_size);
--
2.2.0
^ permalink raw reply related
* [PATCH 2/2] gianfar: handle map error in gfar_start_xmit()
From: Arseny Solokha @ 2014-12-05 10:37 UTC (permalink / raw)
To: Claudiu Manoil; +Cc: netdev, linux-kernel, Arseny Solokha
In-Reply-To: <1417775874-17775-1-git-send-email-asolokha@kb.kras.ru>
From: Arseny Solokha <asolokha@kb.kras.ru>
When DMA-API debugging is enabled in the kernel, it spews the following
upon upping the link:
WARNING: at lib/dma-debug.c:1135
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W O 3.18.0-rc7 #1
task: c0720340 ti: effe2000 task.ti: c0750000
NIP: c01d7c1c LR: c01d7c1c CTR: c02250fc
REGS: effe3d40 TRAP: 0700 Tainted: G W O (3.18.0-rc7)
MSR: 00021000 <CE,ME> CR: 22044242 XER: 20000000
GPR00: c01d7c1c effe3df0 c0720340 00000095 c201e404 c201e9f0 00021000 01a9d000
GPR08: 00000007 00000000 01a9d000 00000313 22044242 00583f60 05f41012 00000000
GPR16: 00000000 000000ff 00000000 00000000 00000000 c5dc3b40 c5677720 00000001
GPR24: c0730000 00029000 c0d0d828 c072c394 effe3e48 c075baec c0d0f020 ee31e600
NIP [c01d7c1c] check_unmap+0x5b4/0xae4
LR [c01d7c1c] check_unmap+0x5b4/0xae4
Call Trace:
[effe3df0] [c01d7c1c] check_unmap+0x5b4/0xae4 (unreliable)
[effe3e40] [c01d81c4] debug_dma_unmap_page+0x78/0x8c
[effe3ec0] [c0286ba0] gfar_clean_tx_ring+0x120/0x3c0
[effe3f30] [c0286f90] gfar_poll_tx_sq+0x48/0x94
o[effe3f50] [c030c388] net_rx_action+0x130/0x1ac
[effe3f80] [c00319e0] __do_softirq+0x134/0x240
[effe3fe0] [c0031dd0] irq_exit+0xa4/0xc8
[effe3ff0] [c000e01c] call_do_irq+0x24/0x3c
[c0751e70] [c0004a04] do_IRQ+0x8c/0x108
[c0751e90] [c0010068] ret_from_except+0x0/0x18
--- interrupt: 501 at arch_cpu_idle+0x24/0x5c
LR = arch_cpu_idle+0x24/0x5c
[c0751f50] [c007d2e4] rcu_idle_enter+0xc8/0xcc (unreliable)
[c0751f60] [c006587c] cpu_startup_entry+0x1d4/0x29c
[c0751fb0] [c054399c] start_kernel+0x338/0x34c
[c0751ff0] [c000046c] set_ivor+0x154/0x190
Instruction dump:
394adb30 80fc0018 811c001c 3c60c04f 5529103a 7cca482e 38639e60 813c0020
815c0024 90c10008 4cc63182 48240b01 <0fe00000> 3c60c04f 3863971c 4cc63182
---[ end trace 3eb7bf62ba1b80f9 ]---
Mapped at:
[<c0287420>] gfar_start_xmit+0x424/0x910
[<c030e964>] dev_hard_start_xmit+0x20c/0x3d8
[<c032cc3c>] sch_direct_xmit+0x124/0x22c
[<c030ede8>] __dev_queue_xmit+0x2b8/0x674
Or the following upon starting transmission of some large chunks
of data:
fsl-gianfar ffe25000.ethernet: DMA-API: device driver failed to check map error[device address=0x0000000005fa8000]
------------[ cut here ]------------
WARNING: at lib/dma-debug.c:1135
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 3.18.0-rc7 #35
task: c071d340 ti: effe2000 task.ti: c074e000
NIP: c01d7c1c LR: c01d7c1c CTR: c022339c
REGS: effe3d40 TRAP: 0700 Tainted: G O (3.18.0-rc7)
MSR: 00021000 <CE,ME> CR: 22044242 XER: 20000000
GPR00: c01d7c1c effe3df0 c071d340 00000094 00000001 c0071750 00000000 00000001
GPR08: 00000000 00000000 effe2000 00000000 20044242 00581f60 05fa8000 000001c4
GPR16: 00000000 000000ff 00000000 000000e4 00000039 c5b1a9c0 c5679c60 00000002
GPR24: c0730000 00029000 c0d0c528 c0729394 effe3e48 c0759aec c0d0d020 ee315900
NIP [c01d7c1c] check_unmap+0x5b4/0xae4
LR [c01d7c1c] check_unmap+0x5b4/0xae4
Call Trace:
[effe3df0] [c01d7c1c] check_unmap+0x5b4/0xae4 (unreliable)
[effe3e40] [c01d81c4] debug_dma_unmap_page+0x78/0x8c
[effe3ec0] [c0284c78] gfar_clean_tx_ring+0x1b4/0x3c0
[effe3f30] [c0284fd4] gfar_poll_tx_sq+0x48/0x94
[effe3f50] [c030a5c4] net_rx_action+0x130/0x1ac
[effe3f80] [c00319e0] __do_softirq+0x134/0x240
[effe3fe0] [c0031dd0] irq_exit+0xa4/0xc8
[effe3ff0] [c000e01c] call_do_irq+0x24/0x3c
[c074fe70] [c0004a04] do_IRQ+0x8c/0x108
[c074fe90] [c0010068] ret_from_except+0x0/0x18
--- interrupt: 501 at arch_cpu_idle+0x24/0x5c
LR = arch_cpu_idle+0x24/0x5c
[c074ff50] [c007d2e4] rcu_idle_enter+0xc8/0xcc (unreliable)
[c074ff60] [c006587c] cpu_startup_entry+0x1d4/0x29c
[c074ffb0] [c054199c] start_kernel+0x338/0x34c
[c074fff0] [c000046c] set_ivor+0x154/0x190
Instruction dump:
394abb30 80fc0018 811c001c 3c60c04e 5529103a 7cca482e 386379f0 813c0020
815c0024 90c10008 4cc63182 4823ed39 <0fe00000> 3c60c04e 386372ac 4cc63182
---[ end trace 008c59ca7ca1f712 ]---
Mapped at:
[<c0285264>] gfar_start_xmit+0x224/0x95c
[<c030cba0>] dev_hard_start_xmit+0x20c/0x3d8
[<c032ae78>] sch_direct_xmit+0x124/0x22c
[<c032b008>] __qdisc_run+0x88/0x1c0
[<c0307920>] net_tx_action+0xf0/0x19c
Ignore these mapping failures in hope we'll have more luck next time.
Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
---
drivers/net/ethernet/freescale/gianfar.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index f34ca55..9ea887e 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -2296,6 +2296,12 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
0,
frag_len,
DMA_TO_DEVICE);
+ if (unlikely(dma_mapping_error(priv->dev, bufaddr))) {
+ /* As DMA mapping failed, pretend the TX path
+ * is busy to retry later
+ */
+ return NETDEV_TX_BUSY;
+ }
/* set the TxBD length and buffer pointer */
txbdp->bufPtr = bufaddr;
@@ -2345,8 +2351,15 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
fcb->ptp = 1;
}
- txbdp_start->bufPtr = dma_map_single(priv->dev, skb->data,
- skb_headlen(skb), DMA_TO_DEVICE);
+ bufaddr = dma_map_single(priv->dev, skb->data, skb_headlen(skb),
+ DMA_TO_DEVICE);
+ if (unlikely(dma_mapping_error(priv->dev, bufaddr))) {
+ /* As DMA mapping failed, pretend the TX path is busy to retry
+ * later
+ */
+ return NETDEV_TX_BUSY;
+ }
+ txbdp_start->bufPtr = bufaddr;
/* If time stamping is requested one additional TxBD must be set up. The
* first TxBD points to the FCB and must have a data length of
--
2.2.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