* Re: [PATCH 3/4] bitops: Introduce generic set_bit_le()
From: Takuya Yoshikawa @ 2012-06-12 13:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Takuya Yoshikawa, bhutchings, grundler, avi, mtosatti,
linux-net-drivers, netdev, linux-kernel, linux-arch, kvm
In-Reply-To: <201206111410.26359.arnd@arndb.de>
On Mon, 11 Jun 2012 14:10:26 +0000
Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 11 June 2012, Takuya Yoshikawa wrote:
> > From: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
> >
> > Needed to replace test_and_set_bit_le() in virt/kvm/kvm_main.c which is
> > being used for this missing function.
> >
> > Signed-off-by: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
> > Cc: Arnd Bergmann <arnd@arndb.de>
>
> I would recommend adding the corresponding clear_bit_le() along with
> set_bit_le, so the next person who needs that doesn't have to make
> yet another patch.
I will do in the next version.
Now I have also noticed that I need to add the same code to powerpc's
bitops file.
Takuya
^ permalink raw reply
* Re: [PATCH 1/4] drivers/net/ethernet/sfc: Add efx_ prefix to set_bit_le()
From: Arnd Bergmann @ 2012-06-12 13:12 UTC (permalink / raw)
To: Takuya Yoshikawa
Cc: Takuya Yoshikawa, bhutchings, grundler, avi, mtosatti,
linux-net-drivers, netdev, linux-kernel, linux-arch, kvm
In-Reply-To: <20120612220654.fd0246e6e687f7c79e5c988c@gmail.com>
On Tuesday 12 June 2012, Takuya Yoshikawa wrote:
> >
> > Hmm, any reason why we're not just using the existing non-atomic
> > __set_bit_le() here? I think the helpers in sfc and tulip can
> > just get removed if you use those.
>
> __set_bit_le() assumes long word alignment and does endian conversion
> when needed.
Ah, I see.
> To be honest, I am a bit scared of changing drivers which I cannot test
> on real hardware.
Ok, let's take your patches as they are then.
With the change to add clear_bit_le:
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH v10] tilegx network driver: initial support
From: Chris Metcalf @ 2012-06-12 13:14 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, bhutchings, arnd, linux-kernel, netdev
In-Reply-To: <20120611.170336.1197560839526564340.davem@davemloft.net>
On 6/11/2012 8:03 PM, David Miller wrote:
> From: Chris Metcalf <cmetcalf@tilera.com>
> Date: Thu, 7 Jun 2012 16:45:02 -0400
>
>> This change adds support for the tilegx network driver based on the
>> GXIO IORPC support in the tilegx software stack, using the on-chip
>> mPIPE packet processing engine.
>>
>> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
> Applied.
Glad to hear it. Thanks for bearing with the multiple revisions. I (we)
appreciate all your feedback, and that of Ben, Eric, Arnd, and other folks
who contributed their time.
The driver does depend on tilegx iorpc framework code that is currently
only in linux-next, but it should all come together properly for 3.6.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: [PATCH] netpoll: Fix skb tail pointer in netpoll_send_udp()
From: Eric Dumazet @ 2012-06-12 13:15 UTC (permalink / raw)
To: Bogdan Hamciuc; +Cc: davem, netdev
In-Reply-To: <1339503766.22704.116.camel@edumazet-glaptop>
On Tue, 2012-06-12 at 14:22 +0200, Eric Dumazet wrote:
> On Tue, 2012-06-12 at 13:26 +0300, Bogdan Hamciuc wrote:
> > As skb->tail wasn't updated after skb_copy_to_linear_data(), subsequent
> > calls to skb_realloc_headroom() (as made by an ethernet driver's
> > ndo_start_xmit routine) would only effectively copy the packet headers,
> > leaving garbage in the payload.
> >
> > In the process, removed some unnecessary code.
> >
> > Signed-off-by: Bogdan Hamciuc <bogdan.hamciuc@freescale.com>
> > ---
> > net/core/netpoll.c | 8 ++++----
> > 1 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/core/netpoll.c b/net/core/netpoll.c
> > index 3d84fb9..9a08068 100644
> > --- a/net/core/netpoll.c
> > +++ b/net/core/netpoll.c
> > @@ -362,22 +362,22 @@ EXPORT_SYMBOL(netpoll_send_skb_on_dev);
> >
> > void netpoll_send_udp(struct netpoll *np, const char *msg, int len)
> > {
> > - int total_len, eth_len, ip_len, udp_len;
> > + int total_len, ip_len, udp_len;
> > struct sk_buff *skb;
> > struct udphdr *udph;
> > struct iphdr *iph;
> > struct ethhdr *eth;
> >
> > udp_len = len + sizeof(*udph);
> > - ip_len = eth_len = udp_len + sizeof(*iph);
> > - total_len = eth_len + ETH_HLEN + NET_IP_ALIGN;
> > + ip_len = udp_len + sizeof(*iph);
> > + total_len = ip_len + ETH_HLEN + NET_IP_ALIGN;
> >
> > skb = find_skb(np, total_len, total_len - len);
> > if (!skb)
> > return;
> >
> > skb_copy_to_linear_data(skb, msg, len);
> > - skb->len += len;
> > + skb_put(skb, len);
> >
> > skb_push(skb, sizeof(*udph));
> > skb_reset_transport_header(skb);
>
> Hmm, real question is why skb_realloc_headroom() is even necessary...
>
> I suspect we need to reserve more bytes.
>
> total_len = ip_len + ETH_HLEN + NET_IP_ALIGN + NET_SKB_PAD;
>
> or something like that ?
>
> Which driver triggers the bug ?
>
Please try the following :
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 3d84fb9..1c6fb72 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -362,17 +362,18 @@ EXPORT_SYMBOL(netpoll_send_skb_on_dev);
void netpoll_send_udp(struct netpoll *np, const char *msg, int len)
{
- int total_len, eth_len, ip_len, udp_len;
+ int total_len, ip_len, udp_len;
struct sk_buff *skb;
struct udphdr *udph;
struct iphdr *iph;
struct ethhdr *eth;
udp_len = len + sizeof(*udph);
- ip_len = eth_len = udp_len + sizeof(*iph);
- total_len = eth_len + ETH_HLEN + NET_IP_ALIGN;
+ ip_len = udp_len + sizeof(*iph);
+ total_len = ip_len + LL_RESERVED_SPACE(np->dev);
- skb = find_skb(np, total_len, total_len - len);
+ skb = find_skb(np, total_len + np->dev->needed_tailroom,
+ total_len - len);
if (!skb)
return;
^ permalink raw reply related
* Re: [PATCH] netpoll: Fix skb tail pointer in netpoll_send_udp()
From: Eric Dumazet @ 2012-06-12 13:34 UTC (permalink / raw)
To: Bogdan Hamciuc; +Cc: davem, netdev
In-Reply-To: <1339506917.22704.134.camel@edumazet-glaptop>
On Tue, 2012-06-12 at 15:15 +0200, Eric Dumazet wrote:
> On Tue, 2012-06-12 at 14:22 +0200, Eric Dumazet wrote:
> > Hmm, real question is why skb_realloc_headroom() is even necessary...
> >
> > I suspect we need to reserve more bytes.
> >
> > total_len = ip_len + ETH_HLEN + NET_IP_ALIGN + NET_SKB_PAD;
> >
> > or something like that ?
> >
> > Which driver triggers the bug ?
> >
In case you wonder why I try so hard to avoid the
skb_realloc_headroom() :
netpoll has complicated^Wspecial^Wnice skb cache, to make sure it can
work even if memory is exhausted.
But if we trigger skb_realloc_headroom() the whole thing is useless.
Thanks
^ permalink raw reply
* [RFC] net/sched/em_canid: Ematch rule to match CAN frames according to their CAN IDs
From: Rostislav Lisovy @ 2012-06-12 13:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, linux-can, lartc, pisa, sojkam1, Rostislav Lisovy
em_canid is an ematch capable of classifying CAN frames according to
their CAN IDs.
This RFC/Patch contains a reworked classifier initially posted in
http://www.spinics.net/lists/netdev/msg200114.html
The functionality is the same however there is almost 50% reduction
in the source code length.
There is a slight difference between this ematch and other available
ematches. Other ematches implement only a simple match operation and
are meant to be combined with logic conjunctions (e.g. AND, OR).
Our ematch makes it possible to use up to 32 rules in single
'configuration statement' (with OR semantics). This allows us to take
the advantage of the bit field data-structure in the implementation of
the match function.
Example: canid(sff 0x123 eff 0x124 sff 0x230:0x7f0)
This ematch would match CAN SFF frames with the following IDs:
0x123, 0x230--0x23f or EFF frame with ID 0x124.
Signed-off-by: Rostislav Lisovy <lisovy@gmail.com>
---
include/linux/can.h | 3 +
include/linux/pkt_cls.h | 5 +-
net/sched/Kconfig | 10 +++
net/sched/Makefile | 1 +
net/sched/em_canid.c | 217 +++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 234 insertions(+), 2 deletions(-)
create mode 100644 net/sched/em_canid.c
diff --git a/include/linux/can.h b/include/linux/can.h
index 9a19bcb..08d1610 100644
--- a/include/linux/can.h
+++ b/include/linux/can.h
@@ -38,6 +38,9 @@
*/
typedef __u32 canid_t;
+#define CAN_SFF_ID_BITS 11
+#define CAN_EFF_ID_BITS 29
+
/*
* Controller Area Network Error Frame Mask structure
*
diff --git a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h
index defbde2..6b16f90 100644
--- a/include/linux/pkt_cls.h
+++ b/include/linux/pkt_cls.h
@@ -451,8 +451,9 @@ enum {
#define TCF_EM_U32 3
#define TCF_EM_META 4
#define TCF_EM_TEXT 5
-#define TCF_EM_VLAN 6
-#define TCF_EM_MAX 6
+#define TCF_EM_VLAN 6
+#define TCF_EM_CANID 7
+#define TCF_EM_MAX 7
enum {
TCF_EM_PROG_TC
diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index 75b58f8..bc0ceab 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -485,6 +485,16 @@ config NET_EMATCH_TEXT
To compile this code as a module, choose M here: the
module will be called em_text.
+config NET_EMATCH_CANID
+ tristate "CAN ID"
+ depends on NET_EMATCH && CAN
+ ---help---
+ Say Y here if you want to be able to classify CAN frames based
+ on CAN ID.
+
+ To compile this code as a module, choose M here: the
+ module will be called em_canid.
+
config NET_CLS_ACT
bool "Actions"
---help---
diff --git a/net/sched/Makefile b/net/sched/Makefile
index 8cdf4e2..47f9262 100644
--- a/net/sched/Makefile
+++ b/net/sched/Makefile
@@ -53,3 +53,4 @@ obj-$(CONFIG_NET_EMATCH_NBYTE) += em_nbyte.o
obj-$(CONFIG_NET_EMATCH_U32) += em_u32.o
obj-$(CONFIG_NET_EMATCH_META) += em_meta.o
obj-$(CONFIG_NET_EMATCH_TEXT) += em_text.o
+obj-$(CONFIG_NET_EMATCH_CANID) += em_canid.o
diff --git a/net/sched/em_canid.c b/net/sched/em_canid.c
new file mode 100644
index 0000000..ef68eef
--- /dev/null
+++ b/net/sched/em_canid.c
@@ -0,0 +1,217 @@
+/*
+ * net/sched/em_canid.c CAN ID ematch
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: Rostislav Lisovy (lisovy@gmail.com)
+ */
+
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/string.h>
+#include <linux/skbuff.h>
+#include <net/pkt_cls.h>
+#include <linux/can.h>
+
+#define EM_CAN_RULES_SIZE 32
+
+struct canid_match {
+ struct can_filter rules_raw[EM_CAN_RULES_SIZE]; /* Raw rules copied
+ from netlink message; Used for sending information to
+ userspace (when 'tc filter show' is invoked) AND when
+ matching EFF frames*/
+ DECLARE_BITMAP(match_sff, (1 << CAN_SFF_ID_BITS)); /* For each SFF CAN
+ ID (11 bit) there is one record in this bitfield */
+ int rules_count;
+ int eff_rules_count;
+ int sff_rules_count;
+
+ struct rcu_head rcu;
+};
+
+/**
+ * em_canid_get_id() - Extracts Can ID out of the sk_buff structure.
+ */
+static canid_t em_canid_get_id(struct sk_buff *skb)
+{
+ /* CAN ID is stored within the data field */
+ struct can_frame *cf = (struct can_frame *)skb->data;
+
+ return cf->can_id;
+}
+
+static void em_canid_sff_match_add(struct canid_match *cm, u32 can_id, u32 can_mask)
+{
+ int i;
+
+ /* Limit can_mask and can_id to SFF range to
+ protect against write after end of array */
+ can_mask &= CAN_SFF_MASK;
+ can_id &= can_mask;
+
+ /* single frame */
+ if (can_mask == CAN_SFF_MASK) {
+ set_bit(can_id, cm->match_sff);
+ return;
+ }
+
+ /* all frames */
+ if (can_mask == 0) {
+ bitmap_fill(cm->match_sff, (1 << CAN_SFF_ID_BITS));
+ return;
+ }
+
+ /* individual frame filter */
+ /* Add record (set bit to 1) for each ID that
+ conforms particular rule */
+ for (i = 0; i < (1 << CAN_SFF_ID_BITS); i++) {
+ if ((i & can_mask) == can_id)
+ set_bit(i, cm->match_sff);
+ }
+}
+
+static inline struct canid_match *em_canid_priv(struct tcf_ematch *m)
+{
+ return (struct canid_match *) (m)->data;
+}
+
+static int em_canid_match(struct sk_buff *skb, struct tcf_ematch *m,
+ struct tcf_pkt_info *info)
+{
+ struct canid_match *cm = em_canid_priv(m);
+ canid_t can_id;
+ unsigned int match = false;
+ int i;
+
+ can_id = em_canid_get_id(skb);
+
+ if (can_id & CAN_EFF_FLAG) {
+ can_id &= CAN_EFF_MASK;
+
+ for (i = 0; i < cm->eff_rules_count; i++) {
+ if (!(((cm->rules_raw[i].can_id ^ can_id) &
+ cm->rules_raw[i].can_mask) & CAN_EFF_MASK)) {
+ match = true;
+ break;
+ }
+ }
+ } else { /* SFF */
+ can_id &= CAN_SFF_MASK;
+ match = test_bit(can_id, cm->match_sff);
+ }
+
+ if (match)
+ return 1;
+
+ return 0;
+}
+
+static int em_canid_change(struct tcf_proto *tp, void *data, int len,
+ struct tcf_ematch *m)
+{
+ struct can_filter *conf = data; /* Array with rules,
+ fixed size EM_CAN_RULES_SIZE */
+ struct canid_match *cm;
+ int err;
+ int i;
+
+ if (len < sizeof(struct can_filter))
+ return -EINVAL;
+
+ err = -ENOBUFS;
+ cm = kzalloc(sizeof(*cm), GFP_KERNEL);
+ if (cm == NULL)
+ goto errout;
+
+ cm->sff_rules_count = 0;
+ cm->eff_rules_count = 0;
+ cm->rules_count = len/sizeof(struct can_filter);
+ err = -EINVAL;
+ if (cm->rules_count > EM_CAN_RULES_SIZE) /* Be sure to fit into the array */
+ goto errout_free;
+
+ /* We need two for() loops for copying rules into
+ two contiguous areas in rules_raw */
+
+ /* Process EFF frame rules*/
+ for (i = 0; i < cm->rules_count; i++) {
+ if ((conf[i].can_id & CAN_EFF_FLAG) &&
+ (conf[i].can_mask & CAN_EFF_FLAG)) {
+ memcpy(cm->rules_raw + cm->eff_rules_count,
+ &conf[i],
+ sizeof(struct can_filter));
+ cm->eff_rules_count++;
+ } else {
+ continue;
+ }
+ }
+
+ /* Process SFF frame rules */
+ for (i = 0; i < cm->rules_count; i++) {
+ if ((conf[i].can_id & CAN_EFF_FLAG) &&
+ (conf[i].can_mask & CAN_EFF_FLAG)) {
+ continue;
+ } else {
+ memcpy(cm->rules_raw + cm->eff_rules_count + cm->sff_rules_count,
+ &conf[i],
+ sizeof(struct can_filter));
+ cm->sff_rules_count++;
+ em_canid_sff_match_add(cm,
+ conf[i].can_id, conf[i].can_mask);
+ }
+ }
+
+ m->datalen = sizeof(*cm);
+ m->data = (unsigned long) cm;
+
+ return 0;
+
+errout_free:
+ kfree(cm);
+errout:
+ return err;
+}
+
+static void em_canid_destroy(struct tcf_proto *tp, struct tcf_ematch *m)
+{
+ struct canid_match *cm = em_canid_priv(m);
+
+ kfree(cm);
+}
+
+static int em_canid_dump(struct sk_buff *skb, struct tcf_ematch *m)
+{
+ return 0;
+}
+
+static struct tcf_ematch_ops em_canid_ops = {
+ .kind = TCF_EM_CANID,
+ .change = em_canid_change,
+ .match = em_canid_match,
+ .destroy = em_canid_destroy,
+ .dump = em_canid_dump,
+ .owner = THIS_MODULE,
+ .link = LIST_HEAD_INIT(em_canid_ops.link)
+};
+
+static int __init init_em_canid(void)
+{
+ return tcf_em_register(&em_canid_ops);
+}
+
+static void __exit exit_em_canid(void)
+{
+ tcf_em_unregister(&em_canid_ops);
+}
+
+MODULE_LICENSE("GPL");
+
+module_init(init_em_canid);
+module_exit(exit_em_canid);
+
+MODULE_ALIAS_TCF_EMATCH(TCF_EM_CANID);
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC] net/sched/em_canid: Ematch rule to match CAN frames according to their CAN IDs
From: Eric Dumazet @ 2012-06-12 14:03 UTC (permalink / raw)
To: Rostislav Lisovy; +Cc: netdev, linux-can, lartc, pisa, sojkam1
In-Reply-To: <1339508913-7784-1-git-send-email-lisovy@gmail.com>
On Tue, 2012-06-12 at 15:48 +0200, Rostislav Lisovy wrote:
> em_canid is an ematch capable of classifying CAN frames according to
> their CAN IDs.
>
> This RFC/Patch contains a reworked classifier initially posted in
> http://www.spinics.net/lists/netdev/msg200114.html
> The functionality is the same however there is almost 50% reduction
> in the source code length.
>
> There is a slight difference between this ematch and other available
> ematches. Other ematches implement only a simple match operation and
> are meant to be combined with logic conjunctions (e.g. AND, OR).
> Our ematch makes it possible to use up to 32 rules in single
> 'configuration statement' (with OR semantics). This allows us to take
> the advantage of the bit field data-structure in the implementation of
> the match function.
>
> Example: canid(sff 0x123 eff 0x124 sff 0x230:0x7f0)
> This ematch would match CAN SFF frames with the following IDs:
> 0x123, 0x230--0x23f or EFF frame with ID 0x124.
>
> Signed-off-by: Rostislav Lisovy <lisovy@gmail.com>
> ---
> include/linux/can.h | 3 +
> include/linux/pkt_cls.h | 5 +-
> net/sched/Kconfig | 10 +++
> net/sched/Makefile | 1 +
> net/sched/em_canid.c | 217 +++++++++++++++++++++++++++++++++++++++++++++++
> 5 files changed, 234 insertions(+), 2 deletions(-)
> create mode 100644 net/sched/em_canid.c
>
> diff --git a/include/linux/can.h b/include/linux/can.h
> index 9a19bcb..08d1610 100644
> --- a/include/linux/can.h
> +++ b/include/linux/can.h
> @@ -38,6 +38,9 @@
> */
> typedef __u32 canid_t;
>
> +#define CAN_SFF_ID_BITS 11
> +#define CAN_EFF_ID_BITS 29
> +
> +struct canid_match {
> + struct can_filter rules_raw[EM_CAN_RULES_SIZE]; /* Raw rules copied
> + from netlink message; Used for sending information to
> + userspace (when 'tc filter show' is invoked) AND when
> + matching EFF frames*/
> + DECLARE_BITMAP(match_sff, (1 << CAN_SFF_ID_BITS)); /* For each SFF CAN
> + ID (11 bit) there is one record in this bitfield */
> + int rules_count;
> + int eff_rules_count;
> + int sff_rules_count;
> +
> + struct rcu_head rcu;
> +};
The size of kmalloc() blob to hold this structure is 4 Mbytes
This is a huge cost, and unlikely to succeed but shortly after boot...
(this happens to be the largest possible kmalloc() allocation by the way
on x86)
^ permalink raw reply
* Re: [net-next.git 4/4 (v4)] stmmac: add the Energy Efficient Ethernet support
From: Giuseppe CAVALLARO @ 2012-06-12 14:24 UTC (permalink / raw)
To: Yuval Mintz
Cc: netdev@vger.kernel.org, bhutchings@solarflare.com,
rayagond@vayavyalabs.com, davem@davemloft.net
In-Reply-To: <979A8436335E3744ADCD3A9F2A2B68A5027BDB@SJEXCHMB10.corp.ad.broadcom.com>
On 6/12/2012 3:09 PM, Yuval Mintz wrote:
> Hi Giuseppe,
>
>> @@ -1541,10 +1663,37 @@ static irqreturn_t stmmac_interrupt(int irq,
>> void *dev_id)
>> + if (unlikely(status)) {
>> + if (status & core_mmc_tx_irq)
>> + priv->xstats.mmc_tx_irq_n++;
>> + if (status & core_mmc_rx_irq)
>> + priv->xstats.mmc_rx_irq_n++;
>> + if (status & core_mmc_rx_csum_offload_irq)
>> + priv->xstats.mmc_rx_csum_offload_irq_n++;
>> + if (status & core_irq_receive_pmt_irq)
>> + priv->xstats.irq_receive_pmt_irq_n++;
>> +
>
> Are these EEE related?
>
>> + /* To handle DMA interrupts */
>
> Is this related?
>
To clearly manage and expose the lpi interrupt status and eee ethtool
stats I've had to do some modifications to the driver's design and I
found really useful to move other parts of the code (e.g. mmc irq stat)
in the main directly. So this just is the result of a complete reworking
made to introduce the EEE. I could better document it in the patch's
comment or create a separate patch that could take a while.
Cheers
Peppe
>
> Cheers,
> Yuval Mintz
>
>
>
^ permalink raw reply
* Re: [PATCH RFC] c_can_pci: generic module for c_can on PCI
From: Federico Vaga @ 2012-06-12 14:25 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Wolfgang Grandegger, Giancarlo Asnaghi, Alan Cox,
Alessandro Rubini, linux-can, netdev, linux-kernel
In-Reply-To: <4FCCC077.7000303@pengutronix.de>
> > +out_free_clock:
> > + if (!priv->priv)
>
> ^^^
>
> looks fishy
Also c_can_platform.c use priv->priv when it needs to get clk. I can add
a comment to specify what the statement do.
--
Federico Vaga
^ permalink raw reply
* Re: [net-next.git 2/4] stmmac: do not use strict_strtoul but kstrtoul
From: Eric Dumazet @ 2012-06-12 14:28 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: netdev, bhutchings, rayagond, davem, yuvalmin
In-Reply-To: <1339505153-26731-3-git-send-email-peppe.cavallaro@st.com>
On Tue, 2012-06-12 at 14:45 +0200, Giuseppe CAVALLARO wrote:
> This patch replaces the obsolete strict_strtoul with kstrtoul.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 26 ++++++++-------------
> 1 files changed, 10 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 8899e10..e33abf5 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2126,42 +2126,36 @@ static int __init stmmac_cmdline_opt(char *str)
> return -EINVAL;
> while ((opt = strsep(&str, ",")) != NULL) {
> if (!strncmp(opt, "debug:", 6)) {
> - if (strict_strtoul(opt + 6, 0, (unsigned long *)&debug))
> + if (kstrtoul(opt + 6, 0, (unsigned long *)&debug))
> goto err;
int debug;
...
if (kstrtoul(opt + 6, 0, (unsigned long *)&debug))
Please get rid of these wrong casts.
^ permalink raw reply
* Re: [RFC] net/sched/em_canid: Ematch rule to match CAN frames according to their CAN IDs
From: Eric Dumazet @ 2012-06-12 14:33 UTC (permalink / raw)
To: Rostislav Lisovy; +Cc: netdev, linux-can, lartc, pisa, sojkam1
In-Reply-To: <1339509809.22704.149.camel@edumazet-glaptop>
On Tue, 2012-06-12 at 16:03 +0200, Eric Dumazet wrote:
> On Tue, 2012-06-12 at 15:48 +0200, Rostislav Lisovy wrote:
> > em_canid is an ematch capable of classifying CAN frames according to
> > their CAN IDs.
> >
> > This RFC/Patch contains a reworked classifier initially posted in
> > http://www.spinics.net/lists/netdev/msg200114.html
> > The functionality is the same however there is almost 50% reduction
> > in the source code length.
> >
> > There is a slight difference between this ematch and other available
> > ematches. Other ematches implement only a simple match operation and
> > are meant to be combined with logic conjunctions (e.g. AND, OR).
> > Our ematch makes it possible to use up to 32 rules in single
> > 'configuration statement' (with OR semantics). This allows us to take
> > the advantage of the bit field data-structure in the implementation of
> > the match function.
> >
> > Example: canid(sff 0x123 eff 0x124 sff 0x230:0x7f0)
> > This ematch would match CAN SFF frames with the following IDs:
> > 0x123, 0x230--0x23f or EFF frame with ID 0x124.
> >
> > Signed-off-by: Rostislav Lisovy <lisovy@gmail.com>
> > ---
> > include/linux/can.h | 3 +
> > include/linux/pkt_cls.h | 5 +-
> > net/sched/Kconfig | 10 +++
> > net/sched/Makefile | 1 +
> > net/sched/em_canid.c | 217 +++++++++++++++++++++++++++++++++++++++++++++++
> > 5 files changed, 234 insertions(+), 2 deletions(-)
> > create mode 100644 net/sched/em_canid.c
> >
> > diff --git a/include/linux/can.h b/include/linux/can.h
> > index 9a19bcb..08d1610 100644
> > --- a/include/linux/can.h
> > +++ b/include/linux/can.h
> > @@ -38,6 +38,9 @@
> > */
> > typedef __u32 canid_t;
> >
> > +#define CAN_SFF_ID_BITS 11
> > +#define CAN_EFF_ID_BITS 29
> > +
>
> > +struct canid_match {
> > + struct can_filter rules_raw[EM_CAN_RULES_SIZE]; /* Raw rules copied
> > + from netlink message; Used for sending information to
> > + userspace (when 'tc filter show' is invoked) AND when
> > + matching EFF frames*/
> > + DECLARE_BITMAP(match_sff, (1 << CAN_SFF_ID_BITS)); /* For each SFF CAN
> > + ID (11 bit) there is one record in this bitfield */
> > + int rules_count;
> > + int eff_rules_count;
> > + int sff_rules_count;
> > +
> > + struct rcu_head rcu;
> > +};
>
> The size of kmalloc() blob to hold this structure is 4 Mbytes
>
> This is a huge cost, and unlikely to succeed but shortly after boot...
>
> (this happens to be the largest possible kmalloc() allocation by the way
> on x86)
>
>
Oh well, I mixed CAN_SFF_ID_BITS / CAN_EFF_ID_BITS
^ permalink raw reply
* Re: 3.4-rc: NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
From: Tomas Papan @ 2012-06-12 14:34 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <CAMGsXDSsSMWfrV1vjnqkWH45ypZw+ZtYF7=ytc79MWRJ5RF5jQ@mail.gmail.com>
Hi Francois,
Unfortunately after the warning occurred once again after 28 000 seconds.
Is there anything else what can I do?
Regards
Tomas
[28914.344765] ------------[ cut here ]------------
[28914.344775] WARNING: at net/sched/sch_generic.c:256
dev_watchdog+0x16b/0x20f()
[28914.344779] Hardware name: SH55J
[28914.344782] NETDEV WATCHDOG: eth1 (r8169): transmit queue 0 timed out
[28914.344785] Modules linked in: vhost_net cls_route cls_u32 cls_fw
sch_sfq sch_htb ipt_REDIRECT ipt_MASQUERADE xt_limit xt_tcpudp
nf_conntrack_ipv6 nf_defrag_ipv6 xt_state iptable_nat nf_nat
nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip6table_filter
ip6_tables iptable_filter ip_tables x_tables kvm_intel kvm fuse r8169
[28914.344819] Pid: 0, comm: swapper/2 Not tainted 3.4.2 #1
[28914.344822] Call Trace:
[28914.344825] <IRQ> [<ffffffff81026881>] ? warn_slowpath_common+0x78/0x8c
[28914.344837] [<ffffffff81026936>] ? warn_slowpath_fmt+0x45/0x4a
[28914.344843] [<ffffffff81042fc2>] ? scheduler_tick+0xaf/0xc3
[28914.344850] [<ffffffff81049f70>] ? ktime_get+0x5f/0xb9
[28914.344855] [<ffffffff812535a0>] ? dev_watchdog+0x16b/0x20f
[28914.344861] [<ffffffff8102f3ae>] ? run_timer_softirq+0x177/0x209
[28914.344868] [<ffffffff8103e7b3>] ? hrtimer_interrupt+0x100/0x19b
[28914.344872] [<ffffffff81253435>] ? qdisc_reset+0x35/0x35
[28914.344879] [<ffffffff8102b256>] ? __do_softirq+0x7f/0x106
[28914.344884] [<ffffffff812e298c>] ? call_softirq+0x1c/0x30
[28914.344890] [<ffffffff81003376>] ? do_softirq+0x31/0x67
[28914.344895] [<ffffffff8102b503>] ? irq_exit+0x44/0x75
[28914.344899] [<ffffffff810032b5>] ? do_IRQ+0x94/0xad
[28914.344905] [<ffffffff812e10a7>] ? common_interrupt+0x67/0x67
[28914.344908] <EOI> [<ffffffff81163f07>] ? intel_idle+0xde/0x103
[28914.344919] [<ffffffff81163ee3>] ? intel_idle+0xba/0x103
[28914.344926] [<ffffffff81220bfa>] ? cpuidle_idle_call+0x7e/0xc4
[28914.344933] [<ffffffff81008e92>] ? cpu_idle+0x53/0x7c
[28914.344937] ---[ end trace 3d8459064a9171b4 ]---
[28914.347829] r8169 0000:01:00.0: eth1: link up
^ permalink raw reply
* Re: [PATCH RFC] c_can_pci: generic module for c_can on PCI
From: Marc Kleine-Budde @ 2012-06-12 14:46 UTC (permalink / raw)
To: Federico Vaga
Cc: Wolfgang Grandegger, Giancarlo Asnaghi, Alan Cox,
Alessandro Rubini, linux-can, netdev, linux-kernel
In-Reply-To: <2105333.GQGP4hKIYU@harkonnen>
[-- Attachment #1: Type: text/plain, Size: 684 bytes --]
On 06/12/2012 04:25 PM, Federico Vaga wrote:
>>> +out_free_clock:
>>> + if (!priv->priv)
>>
>> ^^^
>>
>> looks fishy
>
> Also c_can_platform.c use priv->priv when it needs to get clk. I can add
> a comment to specify what the statement do.
> +out_free_clock:
> + if (!priv->priv)
> + clk_put(priv->priv);
Why do you call clk_put on priv->priv, if priv->priv is NULL?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [RFC] net/sched/em_canid: Ematch rule to match CAN frames according to their CAN IDs
From: Rostislav Lisovy @ 2012-06-12 14:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-can, lartc, pisa, sojkam1
In-Reply-To: <1339511593.22704.157.camel@edumazet-glaptop>
On Tue, 2012-06-12 at 16:33 +0200, Eric Dumazet wrote:
> On Tue, 2012-06-12 at 16:03 +0200, Eric Dumazet wrote:
> > On Tue, 2012-06-12 at 15:48 +0200, Rostislav Lisovy wrote:
> > > em_canid is an ematch capable of classifying CAN frames according to
> > > their CAN IDs.
> > >
> > > This RFC/Patch contains a reworked classifier initially posted in
> > > http://www.spinics.net/lists/netdev/msg200114.html
> > > The functionality is the same however there is almost 50% reduction
> > > in the source code length.
> > >
> > > There is a slight difference between this ematch and other available
> > > ematches. Other ematches implement only a simple match operation and
> > > are meant to be combined with logic conjunctions (e.g. AND, OR).
> > > Our ematch makes it possible to use up to 32 rules in single
> > > 'configuration statement' (with OR semantics). This allows us to take
> > > the advantage of the bit field data-structure in the implementation of
> > > the match function.
> > >
> > > Example: canid(sff 0x123 eff 0x124 sff 0x230:0x7f0)
> > > This ematch would match CAN SFF frames with the following IDs:
> > > 0x123, 0x230--0x23f or EFF frame with ID 0x124.
> > >
> > > Signed-off-by: Rostislav Lisovy <lisovy@gmail.com>
> > > ---
> > > include/linux/can.h | 3 +
> > > include/linux/pkt_cls.h | 5 +-
> > > net/sched/Kconfig | 10 +++
> > > net/sched/Makefile | 1 +
> > > net/sched/em_canid.c | 217 +++++++++++++++++++++++++++++++++++++++++++++++
> > > 5 files changed, 234 insertions(+), 2 deletions(-)
> > > create mode 100644 net/sched/em_canid.c
> > >
> > > diff --git a/include/linux/can.h b/include/linux/can.h
> > > index 9a19bcb..08d1610 100644
> > > --- a/include/linux/can.h
> > > +++ b/include/linux/can.h
> > > @@ -38,6 +38,9 @@
> > > */
> > > typedef __u32 canid_t;
> > >
> > > +#define CAN_SFF_ID_BITS 11
> > > +#define CAN_EFF_ID_BITS 29
> > > +
> >
> > > +struct canid_match {
> > > + struct can_filter rules_raw[EM_CAN_RULES_SIZE]; /* Raw rules copied
> > > + from netlink message; Used for sending information to
> > > + userspace (when 'tc filter show' is invoked) AND when
> > > + matching EFF frames*/
> > > + DECLARE_BITMAP(match_sff, (1 << CAN_SFF_ID_BITS)); /* For each SFF CAN
> > > + ID (11 bit) there is one record in this bitfield */
> > > + int rules_count;
> > > + int eff_rules_count;
> > > + int sff_rules_count;
> > > +
> > > + struct rcu_head rcu;
> > > +};
> >
> > The size of kmalloc() blob to hold this structure is 4 Mbytes
> >
> > This is a huge cost, and unlikely to succeed but shortly after boot...
> >
> > (this happens to be the largest possible kmalloc() allocation by the way
> > on x86)
> >
> >
>
> Oh well, I mixed CAN_SFF_ID_BITS / CAN_EFF_ID_BITS
>
>
Indeed; On x86_64 the sizeof(struct canid_match) is 544 bytes;
Regards;
Rostislav Lisovy
^ permalink raw reply
* Re: [PATCH RFC] c_can_pci: generic module for c_can on PCI
From: Federico Vaga @ 2012-06-12 14:53 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Wolfgang Grandegger, Giancarlo Asnaghi, Alan Cox,
Alessandro Rubini, linux-can, netdev, linux-kernel
In-Reply-To: <4FD75648.7060702@pengutronix.de>
> > +out_free_clock:
> > + if (!priv->priv)
> > + clk_put(priv->priv);
>
> Why do you call clk_put on priv->priv, if priv->priv is NULL?
Right!
if(priv->priv)
clk_put(priv->priv);
--
Federico Vaga
^ permalink raw reply
* RE: [PATCH] netpoll: Fix skb tail pointer in netpoll_send_udp()
From: Hamciuc Bogdan-BHAMCIU1 @ 2012-06-12 15:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <1339508049.22704.143.camel@edumazet-glaptop>
Hi Eric,
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Tuesday, June 12, 2012 4:34 PM
> To: Hamciuc Bogdan-BHAMCIU1
> Cc: davem@davemloft.net; netdev@vger.kernel.org
> Subject: Re: [PATCH] netpoll: Fix skb tail pointer in netpoll_send_udp()
>
> On Tue, 2012-06-12 at 15:15 +0200, Eric Dumazet wrote:
> > On Tue, 2012-06-12 at 14:22 +0200, Eric Dumazet wrote:
>
> > > Hmm, real question is why skb_realloc_headroom() is even necessary...
Our driver (Freescale P4080, unfortunately not upstream yet) needs a minimum amount of headroom in order to communicate metadata to the NIC.
For instance, frame offsets to the protocol headers are stored there, which the NIC then uses to fill in the egress checksum.
Originating frames, on the other hand, don't always have that amount of headroom, so we occasionally need to realloc.
> > >
> > > I suspect we need to reserve more bytes.
> > >
> > > total_len = ip_len + ETH_HLEN + NET_IP_ALIGN + NET_SKB_PAD;
> > >
> > > or something like that ?
Indeed, your counter-proposal patch (adding LL_RESERVED_SPACE()) worked fine.
> > >
> > > Which driver triggers the bug ?
> > >
>
> In case you wonder why I try so hard to avoid the
> skb_realloc_headroom() :
>
> netpoll has complicated^Wspecial^Wnice skb cache, to make sure it can
> work even if memory is exhausted.
>
> But if we trigger skb_realloc_headroom() the whole thing is useless.
>
Thank you,
Bogdan
^ permalink raw reply
* Re: [RFC] net/sched/em_canid: Ematch rule to match CAN frames according to their CAN IDs
From: Oliver Hartkopp @ 2012-06-12 15:42 UTC (permalink / raw)
To: Rostislav Lisovy, Eric Dumazet; +Cc: netdev, linux-can, lartc, pisa, sojkam1
In-Reply-To: <1339512622.8536.3.camel@lolumad>
Hello Rostislav, hello Eric,
On 12.06.2012 16:50, Rostislav Lisovy wrote:
> On Tue, 2012-06-12 at 16:33 +0200, Eric Dumazet wrote:
>> On Tue, 2012-06-12 at 16:03 +0200, Eric Dumazet wrote:
>>> On Tue, 2012-06-12 at 15:48 +0200, Rostislav Lisovy wrote:
>>>> em_canid is an ematch capable of classifying CAN frames according to
>>>> their CAN IDs.
>>>>
>>>> This RFC/Patch contains a reworked classifier initially posted in
>>>> http://www.spinics.net/lists/netdev/msg200114.html
>>>> The functionality is the same however there is almost 50% reduction
>>>> in the source code length.
>>>>
>>>> There is a slight difference between this ematch and other available
>>>> ematches. Other ematches implement only a simple match operation and
>>>> are meant to be combined with logic conjunctions (e.g. AND, OR).
>>>> Our ematch makes it possible to use up to 32 rules in single
>>>> 'configuration statement' (with OR semantics). This allows us to take
>>>> the advantage of the bit field data-structure in the implementation of
>>>> the match function.
>>>>
>>>> Example: canid(sff 0x123 eff 0x124 sff 0x230:0x7f0)
>>>> This ematch would match CAN SFF frames with the following IDs:
>>>> 0x123, 0x230--0x23f or EFF frame with ID 0x124.
i tried to figure out the difference between the implementation as classifier
(link above) and this implementation as an ematch.
Do we have any disadvantages using the ematch? E.g. is it still possible to
add additional ematches like checking for patterns inside can_frame.data[]
(which is located in skb->data) with ematch_u32 or e.g. ematch_text ??
...
Btw.
>>>> +struct canid_match {
>>>> + struct can_filter rules_raw[EM_CAN_RULES_SIZE]; /* Raw rules copied
>>>> + from netlink message; Used for sending information to
>>>> + userspace (when 'tc filter show' is invoked) AND when
>>>> + matching EFF frames*/
>>>> + DECLARE_BITMAP(match_sff, (1 << CAN_SFF_ID_BITS)); /* For each SFF CAN
>>>> + ID (11 bit) there is one record in this bitfield */
these comments have a styling problem :-)
Additional to these checkpatch warnings:
WARNING: line over 80 characters
#144: FILE: net/sched/em_canid.c:48:
+static void em_canid_sff_match_add(struct canid_match *cm, u32 can_id, u32 can_mask)
WARNING: line over 80 characters
#231: FILE: net/sched/em_canid.c:135:
+ if (cm->rules_count > EM_CAN_RULES_SIZE) /* Be sure to fit into the array */
WARNING: line over 80 characters
#256: FILE: net/sched/em_canid.c:160:
+ memcpy(cm->rules_raw + cm->eff_rules_count + cm->sff_rules_count,
Tnx & regards,
Oliver
^ permalink raw reply
* Re: net/netfilter/nf_conntrack_proto_tcp.c:1606:9: error: ‘struct nf_proto_net’ has no member named ‘user’
From: Pablo Neira Ayuso @ 2012-06-12 16:03 UTC (permalink / raw)
To: Gao feng; +Cc: David Miller, wfg, netdev
In-Reply-To: <4FD72203.9090005@cn.fujitsu.com>
On Tue, Jun 12, 2012 at 07:03:31PM +0800, Gao feng wrote:
> 于 2012年06月12日 17:29, Pablo Neira Ayuso 写道:
>
> >> nf_proto_net.users has different meaning when SYSCTL enabled or disabled.
> >>
> >> when SYSCTL enabled,it means if both tcpv4 and tcpv6 register the sysctl,
> >> it is increased when register sysctl success and decreased when unregister sysctl.
> >> we can regard it as the refcnt of ctl_table.
> >>
> >> when SYSCTL disabled,it just used to identify if the proto's pernet data
> >> has been initialized.
> >
> > We have to use two different counters for this. The conditional
> > meaning of that variable is really confusing.
> >
> Hi David & Pablo
>
> Please have a look at this patch and tell me if it's OK.
> it base on Pable's patch.
I think we have to merge those tcpv4_init_net and tcpv6_init_net
functions into one single function tcp_init_net. Then, we can pass
l4proto->l3proto to init_net:
if (proto->init_net) {
ret = proto->init_net(net, l4proto->l3proto);
if (ret < 0)
return ret;
}
Thus, we can check if this is IPv4 or IPv6 and initialize the compat
part accordingly.
Still, we have that pn->users thing:
if (!pn->users++) {
for (i = 0; i < TCP_CONNTRACK_TIMEOUT_MAX; i++)
tn->timeouts[i] = tcp_timeouts[i];
tn->tcp_loose = nf_ct_tcp_loose;
tn->tcp_be_liberal = nf_ct_tcp_be_liberal;
tn->tcp_max_retrans = nf_ct_tcp_max_retrans;
}
Define some pn->initialized boolean. Set it to true at the end of
the new tcp_init_net.
Similar thing for other protocol trackers.
Let me know if you are going to send me patches. In that case, please
do it on top of the current tree.
Once that has been cleaned up, we can prepare follow-up patches to
move the sysctl code to nf_conntrack_proto_*_sysctl.c to reduce the
ifdef pollution.
^ permalink raw reply
* [PATCH v2] bonding: Fix corrupted queue_mapping
From: Eric Dumazet @ 2012-06-12 16:03 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Tom Herbert, John Fastabend, Roland Dreier
From: Eric Dumazet <edumazet@google.com>
In the transmit path of the bonding driver, skb->cb is used to
stash the skb->queue_mapping so that the bonding device can set its
own queue mapping. This value becomes corrupted since the skb->cb is
also used in __dev_xmit_skb.
When transmitting through bonding driver, bond_select_queue is
called from dev_queue_xmit. In bond_select_queue the original
skb->queue_mapping is copied into skb->cb (via bond_queue_mapping)
and skb->queue_mapping is overwritten with the bond driver queue.
Subsequently in dev_queue_xmit, __dev_xmit_skb is called which writes
the packet length into skb->cb, thereby overwriting the stashed
queue mappping. In bond_dev_queue_xmit (called from hard_start_xmit),
the queue mapping for the skb is set to the stashed value which is now
the skb length and hence is an invalid queue for the slave device.
If we want to save skb->queue_mapping into skb->cb[], best place is to
add a field in struct qdisc_skb_cb, to make sure it wont conflict with
other layers (eg : Qdiscc, Infiniband...)
This patchs also makes sure (struct qdisc_skb_cb)->data is aligned on 8
bytes :
netem qdisc for example assumes it can store an u64 in it, without
misalignment penalty.
Note : we only have 20 bytes left in (struct qdisc_skb_cb)->data[].
The largest user is CHOKe and it fills it.
Based on a previous patch from Tom Herbert.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Tom Herbert <therbert@google.com>
Cc: John Fastabend <john.r.fastabend@intel.com>
Cc: Roland Dreier <roland@kernel.org>
---
drivers/net/bonding/bond_main.c | 9 +++++----
include/net/sch_generic.h | 7 +++++--
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 2ee8cf9..b9c2ae6 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -76,6 +76,7 @@
#include <net/route.h>
#include <net/net_namespace.h>
#include <net/netns/generic.h>
+#include <net/pkt_sched.h>
#include "bonding.h"
#include "bond_3ad.h"
#include "bond_alb.h"
@@ -381,8 +382,6 @@ struct vlan_entry *bond_next_vlan(struct bonding *bond, struct vlan_entry *curr)
return next;
}
-#define bond_queue_mapping(skb) (*(u16 *)((skb)->cb))
-
/**
* bond_dev_queue_xmit - Prepare skb for xmit.
*
@@ -395,7 +394,9 @@ int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb,
{
skb->dev = slave_dev;
- skb->queue_mapping = bond_queue_mapping(skb);
+ BUILD_BUG_ON(sizeof(skb->queue_mapping) !=
+ sizeof(qdisc_skb_cb(skb)->bond_queue_mapping));
+ skb->queue_mapping = qdisc_skb_cb(skb)->bond_queue_mapping;
if (unlikely(netpoll_tx_running(slave_dev)))
bond_netpoll_send_skb(bond_get_slave_by_dev(bond, slave_dev), skb);
@@ -4171,7 +4172,7 @@ static u16 bond_select_queue(struct net_device *dev, struct sk_buff *skb)
/*
* Save the original txq to restore before passing to the driver
*/
- bond_queue_mapping(skb) = skb->queue_mapping;
+ qdisc_skb_cb(skb)->bond_queue_mapping = skb->queue_mapping;
if (unlikely(txq >= dev->real_num_tx_queues)) {
do {
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 55ce96b..9d7d54a 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -220,13 +220,16 @@ struct tcf_proto {
struct qdisc_skb_cb {
unsigned int pkt_len;
- unsigned char data[24];
+ u16 bond_queue_mapping;
+ u16 _pad;
+ unsigned char data[20];
};
static inline void qdisc_cb_private_validate(const struct sk_buff *skb, int sz)
{
struct qdisc_skb_cb *qcb;
- BUILD_BUG_ON(sizeof(skb->cb) < sizeof(unsigned int) + sz);
+
+ BUILD_BUG_ON(sizeof(skb->cb) < offsetof(struct qdisc_skb_cb, data) + sz);
BUILD_BUG_ON(sizeof(qcb->data) < sz);
}
^ permalink raw reply related
* Re: [net-next PATCH 00/02] net/ipv4: Add support for new tunnel type VTI.
From: Nicolas Dichtel @ 2012-06-12 16:17 UTC (permalink / raw)
To: Saurabh; +Cc: netdev
In-Reply-To: <20120608173225.GA11928@debian-saurabh-64.vyatta.com>
Hi,
thank you for pushing this feature upstream Saurabh.
This feature is very usefull, we have implemented something similar in our system.
Regards,
Nicolas
Le 08/06/2012 19:32, Saurabh a écrit :
>
>
> Introduction:
> Virtual tunnel interface is a way to represent policy based IPsec tunnels as virtual interfaces in linux. This is similar to Cisco's VTI (virtual tunnel interface) and Juniper's representaion of secure tunnel (st.xx). The advantage of representing an IPsec tunnel as an interface is that it is possible to plug Ipsec tunnels into the routing protocol infrastructure of a router. Therefore it becomes possible to influence the packet path by toggling the link state of the tunnel or based on routing metrics.
>
> Overview:
> Natively linux kernel does not support ipsec as an interface. Also secure interface assume a ipsec policy 4 tupple of {dst-ip-any, src-ip-any, dst-port-any, src-port-any}. Applying this 4 tuple in linux would result in all traffic matching the ipsec policy. What is needed is a tunnel distinguisher. The linux kernel skbuff has fwmark which is used for policy based routing (PBR). Linux kernel version 2.6.35 enhanced SPD/SADB to use fwmark as part of the IPsec policy. Strongswan has also introduced support for this kernel feature with version 4.5.0. We can therefore use the fwmark as the distinguisher for tunnel interface. We can also create a light weight tunnel kernel module (vti) to give the notion of an interface for rest of the kernel routing system. The tunnel module does not do any encapsulation/decapsulation. The kernel's xfrm modules still do the esp encryption/decryption.
>
> Usage:
> ip tunnel add sti15 mode vti remote 12.0.0.1 local 12.0.0.3 ikey 15
> or
> ip link add sti15 type vti key 15 remote 12.0.0.1 local 12.0.0.3
>
> Signed-off-by: Saurabh Mohan<saurabh.mohan@vyatta.com>
> Reviewed-by: Stephen Hemminger<shemminger@vyatta.com>
>
> ---
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next.git 4/4 (v4)] stmmac: add the Energy Efficient Ethernet support
From: Ben Hutchings @ 2012-06-12 16:42 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: netdev, rayagond, davem, yuvalmin
In-Reply-To: <1339505153-26731-5-git-send-email-peppe.cavallaro@st.com>
On Tue, 2012-06-12 at 14:45 +0200, Giuseppe CAVALLARO wrote:
> This patch adds the Energy Efficient Ethernet support to the stmmac.
>
> Please see the driver's documentation for further details about this support
> in the driver.
[...]
> +static int stmmac_ethtool_op_set_eee(struct net_device *dev,
> + struct ethtool_eee *edata)
> +{
> + struct stmmac_priv *priv = netdev_priv(dev);
> +
> + priv->eee_enabled = edata->eee_enabled;
> +
> + if (!priv->eee_enabled)
> + stmmac_disable_eee_mode(priv);
> + else {
> + /* We are asking for enabling the EEE but it is safe
> + * to verify all by invoking the eee_init function.
> + * In case of failure it will return an error.
> + */
It would be better if you could avoid changing any settings in the case
of failure, though.
> + priv->tx_lpi_timer = edata->tx_lpi_timer;
> + priv->eee_enabled = stmmac_eee_init(priv);
> + if (!priv->eee_enabled)
> + return -EPERM;
[...]
Surely -EOPNOTSUPP?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [net-next.git 1/4 (v4)] phy: add the EEE support and the way to access to the MMD registers.
From: Ben Hutchings @ 2012-06-12 16:50 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: netdev, rayagond, davem, yuvalmin
In-Reply-To: <1339505153-26731-2-git-send-email-peppe.cavallaro@st.com>
On Tue, 2012-06-12 at 14:45 +0200, Giuseppe CAVALLARO wrote:
> This patch adds the support for the Energy-Efficient Ethernet (EEE)
> to the Physical Abstraction Layer.
> To support the EEE we have to access to the MMD registers 3.20 and
> 7.60/61. So two new functions have been added to read/write the MMD
> registers (clause 45).
>
> An Ethernet driver (I tested the stmmac) can invoke the phy_init_eee to properly
> check if the EEE is supported by the PHYs and it can also set the clock
> stop enable bit in the 3.0 register.
> The phy_get_eee_err can be used for reporting the number of time where
> the PHY failed to complete its normal wake sequence.
>
> In the end, this patch also adds the EEE ethtool support implementing:
> o phy_ethtool_set_eee
> o phy_ethtool_get_eee
[...]
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
[...]
> +static int phy_eee_to_adv(int eee_adv)
> +{
> + int adv = 0;
> +
> + if (eee_adv & MDIO_EEE_100TX)
> + adv |= ADVERTISED_100baseT_Full;
> + if (eee_adv & MDIO_EEE_1000T)
> + adv |= ADVERTISED_1000baseT_Full;
> + if (eee_adv & MDIO_EEE_10GT)
> + adv |= ADVERTISED_10000baseT_Full;
> + if (eee_adv & MDIO_EEE_1000KX)
> + adv |= ADVERTISED_1000baseKX_Full;
> + if (eee_adv & MDIO_EEE_10GKX4)
> + adv |= ADVERTISED_10000baseKX4_Full;
> + if (eee_adv & MDIO_EEE_10GKR)
> + adv |= ADVERTISED_10000baseKR_Full;
> +
> + return adv;
> +}
The type of 'adv' and the return type should be u32 (per ethtool API);
the type of 'eee_adv' should be u16 (16-bit register).
Similarly in phy_eee_to_supported() and phy_adv_to_eee().
[...]
> --- a/include/linux/mii.h
> +++ b/include/linux/mii.h
[...]
> @@ -141,6 +143,15 @@
> #define FLOW_CTRL_TX 0x01
> #define FLOW_CTRL_RX 0x02
>
> +/* MMD Access Control register fields */
> +#define MII_MMD_CTRL_DEVAD_MASK 0x1f /* Mask MMD DEVAD*/
> +#define MII_MMD_CTRL_FUNC_ADDR 0x0000 /* Address */
> +#define MII_MMD_CTRL_FUNC_DATA_NOINCR 0x4000 /* no post increment */
> +#define MII_MMD_CTRL_FUNC_DATA_INCR_ON_RDWT 0x8000 /* post increment on
> + * reads & writes */
> +#define MII_MMD_CTRL_FUNC_DATA_INCR_ON_WT 0xC000 /* post increment on
> + * writes only */
> +
[...]
These names are quite long; could they reasonably be shortened, e.g. by
dropping 'FUNC_' and 'DATA_' parts?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: kernel ipsec error
From: Ben Hutchings @ 2012-06-12 16:53 UTC (permalink / raw)
To: Marco Berizzi; +Cc: netdev
In-Reply-To: <DUB108-W54AAF31BD3E442DF275349B2F60@phx.gbl>
On Tue, 2012-06-12 at 08:31 +0200, Marco Berizzi wrote:
> bhutchings@solarflare.com wrote:
> > On Mon, 2012-06-11 at 14:45 +0200, Marco Berizzi wrote:
> > > Hello everybody.
> > >
> > > After 12 days uptime I got this message.
> > > Linux is 3.3.5 32bit, running openswan
> > > (this is an ipsec gateway/netfilter
> > > firewall) and squid.
> > >
> > > Jun 11 12:53:02 Pleiadi kernel: SLUB: Unable to allocate memory on node -1 (gfp=0x20)
> > > Jun 11 12:53:02 Pleiadi kernel: cache: kmalloc-2048, object size: 2048, buffer size: 2048, default order: 2, min order: 0
> > > Jun 11 12:53:02 Pleiadi kernel: node 0: slabs: 61, objs: 476, free: 0
> > > Jun 11 12:53:02 Pleiadi kernel: kworker/0:2: page allocation failure: order:0, mode:0x4020
> >
> > So a single page allocation in atomic (non-sleeping) context failed.
> >
> > [...]
> > > Jun 11 12:53:02 Pleiadi kernel: Free swap = 130908kB
> > > Jun 11 12:53:02 Pleiadi kernel: Total swap = 151164kB
> > > Jun 11 12:53:02 Pleiadi kernel: 40944 pages RAM
> > [...]
> >
> > Not too surprising with this little RAM available (swap didn't help
> > since we couldn't wait for swap-out).
>
> yes, this is really a very old hardware.
>
> > There could be a memory leak, but you would need to read /proc/meminfo
> > and /proc/slabinfo at intervals to work out whether that was the case.
>
> Kindly, may you tell me which should be the intervals? One second? one minute?
Given that you saw this after 12 days, I would think somewhere between
an hour and a day would be appropriate.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v2] bonding: Fix corrupted queue_mapping
From: Neil Horman @ 2012-06-12 17:16 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Tom Herbert, John Fastabend, Roland Dreier
In-Reply-To: <1339517031.22704.202.camel@edumazet-glaptop>
On Tue, Jun 12, 2012 at 06:03:51PM +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> In the transmit path of the bonding driver, skb->cb is used to
> stash the skb->queue_mapping so that the bonding device can set its
> own queue mapping. This value becomes corrupted since the skb->cb is
> also used in __dev_xmit_skb.
>
> When transmitting through bonding driver, bond_select_queue is
> called from dev_queue_xmit. In bond_select_queue the original
> skb->queue_mapping is copied into skb->cb (via bond_queue_mapping)
> and skb->queue_mapping is overwritten with the bond driver queue.
>
> Subsequently in dev_queue_xmit, __dev_xmit_skb is called which writes
> the packet length into skb->cb, thereby overwriting the stashed
> queue mappping. In bond_dev_queue_xmit (called from hard_start_xmit),
> the queue mapping for the skb is set to the stashed value which is now
> the skb length and hence is an invalid queue for the slave device.
>
> If we want to save skb->queue_mapping into skb->cb[], best place is to
> add a field in struct qdisc_skb_cb, to make sure it wont conflict with
> other layers (eg : Qdiscc, Infiniband...)
>
> This patchs also makes sure (struct qdisc_skb_cb)->data is aligned on 8
> bytes :
>
> netem qdisc for example assumes it can store an u64 in it, without
> misalignment penalty.
>
> Note : we only have 20 bytes left in (struct qdisc_skb_cb)->data[].
> The largest user is CHOKe and it fills it.
>
> Based on a previous patch from Tom Herbert.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Tom Herbert <therbert@google.com>
> Cc: John Fastabend <john.r.fastabend@intel.com>
> Cc: Roland Dreier <roland@kernel.org>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Looking at this, it would be really nice if we could have some sort of layer
independent space in an skb. It seems we're often looking to shoehorn more
stuff into the control bock.
Neil
^ permalink raw reply
* Bug in net/ipv6/ip6_fib.c:fib6_dump_table()
From: Debabrata Banerjee @ 2012-06-12 17:22 UTC (permalink / raw)
To: netdev, davem, kaber, yoshfuji, jmorris, pekkas, kuznet
Cc: linux-kernel, eric.dumazet, Joshua Hunt
Looks like commit 2bec5a369ee79576a3eea2c23863325089785a2c "ipv6: fib:
fix crash when changing large fib while dumping" is the culprit. The
result of this code is that if there is a tree addition while a dump
has suspended because the netlink skb is full, it will simply go back
to the top of the tree and you end up with duplicate/triplicate/etc
routes. It looks like the code attempts to count nodes, but it's a
linear count and the data structure is a tree so that's a big problem.
The net result is potentially DOSable, since if route table updates
happen often enough in proportion to table size, a dump will attempt
to return an infinite amount of routes (observed). So this commit
should be reverted. However I am interested in the problem that commit
tried to solve, if anyone has more information on that. My assumption
is the fib tree gets corrupted and eventually it crashes in
fib6_dump_table(), which I assume can still happen.
I can easily demonstrate the bug by adding cloned/cache routes while I
check the results of fib6_dump_table:
root@a172-25-43-12.deploy.akamaitechnologies.com:~# ip -6 -o route
show table cache |tee tmp | wc -l; sort tmp | uniq -u | wc -l
593
189
root@a172-25-43-12.deploy.akamaitechnologies.com:~# ip -6 -o route
show table cache |tee tmp | wc -l; sort tmp | uniq -u | wc -l
884
16
root@a172-25-43-12.deploy.akamaitechnologies.com:~# ip -6 -o route
show table cache |tee tmp | wc -l; sort tmp | uniq -u | wc -l
888
78
root@a172-25-43-12.deploy.akamaitechnologies.com:~# ip -6 -o route
show table cache |tee tmp | wc -l; sort tmp | uniq -u | wc -l
507
507
root@a172-25-43-12.deploy.akamaitechnologies.com:~# ip -6 -o route
show table cache |tee tmp | wc -l; sort tmp | uniq -u | wc -l
533
533
root@a172-25-43-12.deploy.akamaitechnologies.com:~# ip -6 -o route
show table cache |tee tmp | wc -l; sort tmp | uniq -u | wc -l
571
571
Thanks,
Debabrata
^ permalink raw reply
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