* Re: [PATCH] net: af802154: Fix wrong structure declaration
From: Joe Perches @ 2013-10-06 22:20 UTC (permalink / raw)
To: Guenter Roeck
Cc: Dmitry, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
David S. Miller
In-Reply-To: <1381095841-15031-1-git-send-email-linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
On Sun, 2013-10-06 at 14:44 -0700, Guenter Roeck wrote:
> net_devce doesn't exist.
[]
> diff --git a/net/ieee802154/af802154.h b/net/ieee802154/af802154.h
[]
> @@ -25,7 +25,7 @@
> #define AF802154_H
>
> struct sk_buff;
> -struct net_devce;
> +struct net_device;
That argues more for deletion than correction.
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
^ permalink raw reply
* [PATCH] net: af802154: Fix wrong structure declaration
From: Guenter Roeck @ 2013-10-06 21:44 UTC (permalink / raw)
To: Alexander Smirnov, Dmitry Eremin-Solenikov
Cc: David S. Miller, netdev, linux-zigbee-devel, Guenter Roeck
net_devce doesn't exist.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
net/ieee802154/af802154.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ieee802154/af802154.h b/net/ieee802154/af802154.h
index b1ec525..62f5f63 100644
--- a/net/ieee802154/af802154.h
+++ b/net/ieee802154/af802154.h
@@ -25,7 +25,7 @@
#define AF802154_H
struct sk_buff;
-struct net_devce;
+struct net_device;
extern struct proto ieee802154_raw_prot;
extern struct proto ieee802154_dgram_prot;
void ieee802154_raw_deliver(struct net_device *dev, struct sk_buff *skb);
--
1.7.9.7
^ permalink raw reply related
* Re: [PATCH 0/4] connector fixes
From: Рустафа Джамурахметов @ 2013-10-06 20:46 UTC (permalink / raw)
To: David Miller, minipli@googlemail.com; +Cc: netdev@vger.kernel.org
In-Reply-To: <20131002.160430.1701387005902696709.davem@davemloft.net>
03.10.2013, 00:04, "David Miller" <davem@davemloft.net>:
> From: Mathias Krause <minipli@googlemail.com>
> Date: Mon, 30 Sep 2013 22:03:05 +0200
>
>> This series fixes a few netlink related issues of the connector interface.
>>
>> The first two patches are bug fixes. The last two are cleanups.
>>
>> Please apply!
>
> Series applied and first two patches queued up for -stable, thanks.
Thank you.
^ permalink raw reply
* VERY URGENT..!
From: Mr. M. Barlow @ 2013-10-06 20:30 UTC (permalink / raw)
To: Recipients
Hello, I am Mr. M. Barlow from Paris, France. I have been advised to contact you regarding my business investment in your country. For urgent response and more details, kindly get back to me via this E-mail: bc82022@gmail.com or Telephone number below. Thank you as I wait for your response.
Mr. M. Barlow.
+33-753-194-496
Sent from Orange Wireless BlackBerry Smartphone, France.
^ permalink raw reply
* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Oussama Ghorbel @ 2013-10-06 19:18 UTC (permalink / raw)
To: Oussama Ghorbel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <20131006161910.GC9295@order.stressinduktion.org>
Yes, to summarize, the idea of this patch was to fix the incoherence
in the condition of ip6gre_tunnel_change_mtu function
if (new_mtu < 68 ||
new_mtu > 0xFFF8 - dev->hard_header_len - tunnel->hlen)
>From the ip6gre_tnl_link_config function we can see that:
The variable addend is equal the ipv6 header + gre header (including
the gre options)
On the other hand hard_header_len equal to the header of the lower
layer + addend.
So the quantity - (dev->hard_header_len + tunnel->hlen) equals - (eth
header + ipv6 header + gre header + ipv6 header + gre header) which by
no means this would represent anything! (I've just taken ipv6 over
ethernet as example)
As we have seen there is another approach to fix this issue is to
re-factor the hlen to hold only the length of gre as it's done for
ipv4 gre, however the solution provided in the patch seems to be
regression risk-less.
Although the value hold by hlen is not coherent with the variable name
nor with ipv4, I think there is an advantage of the current approach
of ipv6 hlen over ipv4 hlen, because we save the calculation of ipv6
header each time. Ex:
In ipv4 gre and in the function ipgre_header:
iph = (struct iphdr *)skb_push(skb, t->hlen + sizeof(*iph));
In ipv6 and in the function ip6gre_header
ipv6h = (struct ipv6hdr *)skb_push(skb, t->hlen);
Thanks,
Oussama
On Sun, Oct 6, 2013 at 5:19 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Sun, Oct 06, 2013 at 04:36:56PM +0100, Oussama Ghorbel wrote:
>> On Sun, Oct 6, 2013 at 4:13 PM, Hannes Frederic Sowa
>> <hannes@stressinduktion.org> wrote:
>> > On Sun, Oct 06, 2013 at 03:42:15PM +0100, Oussama Ghorbel wrote:
>> >> The initialization in ip6gre_tnl_link_config is done as the following:
>> >> static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu)
>> >> {
>> >> ...
>> >> int addend = sizeof(struct ipv6hdr) + 4;
>> >> ...
>> >> /* Precalculate GRE options length */
>> >> if (t->parms.o_flags&(GRE_CSUM|GRE_KEY|GRE_SEQ)) {
>> >> if (t->parms.o_flags&GRE_CSUM)
>> >> addend += 4;
>> >> if (t->parms.o_flags&GRE_KEY)
>> >> addend += 4;
>> >> if (t->parms.o_flags&GRE_SEQ)
>> >> addend += 4;
>> >> }
>> >> ...
>> >> dev->hard_header_len = rt->dst.dev->hard_header_len + addend;
>> >> ...
>> >> t->hlen = addend;
>> >> ..
>> >> }
>> >>
>> >> Unless they are other reasons, the hard_header_len is taken into
>> >> account the GRE_KEY, GRE_SEQ ..
>> >
>> > But only if a new route is found. The hard_header_len reinitialization is
>> > guarded by a (rt == NULL). We may have not found one on boot up.
>> >
>> In that case the function will make a return and hlen will be zero.
>> Subtracting hlen in ip6gre_tunnel_change_mtu has no effect ...
>
> Oh yes, somehow I missed that.
>
> We depend on t->hlen when pushing the gre header onto the skb. t->hlen == 0
> should never be the case because we assume t->hlen > sizeof(struct ipv6_hdr).
>
^ permalink raw reply
* CONTACT FEDEX EXPRESS COURIER SERVICE FOR YOUR PACKAGE
From: 019 @ 2013-10-06 18:52 UTC (permalink / raw)
To: Recipients
Dear Friend,
I cashed your shell oil company's compensation check of $1.5Million USD which has been with me for a very long time to avoid expiration,contact fedex Courier service with the below info for your fund consignment delivery,Note that security and insurance fees has been paid,all you will pay them is their delivery fees 150 USD only,
Director:Dr.Dennis Meijs,
E-mail ( fedexcourierserviii@yahoo.fr )
Tel: +9178-3835-5947
Please make sure you send this needed info to the Director Dr.Dennis Meijs
with the E-mail given to you to avoid wrong delivery of your consignment
Full Name.....................
Country...............
Home address.................
Home & Mobile phone numbers......
Your picture..........
Call Dr Dennis Meijs on phone Tel:+9178-3835-5947 as soon as you send email to him because your call would facilitate the immediate attention to you due to his tight delivery schedule.
I waiting for your urgent response
Remain blessed
Best Regards.
Barrister.Don Philip
^ permalink raw reply
* [PATCH] static_key: WARN on usage before jump_label_init was called
From: Hannes Frederic Sowa @ 2013-10-06 18:29 UTC (permalink / raw)
To: Steven Rostedt, netdev, linux-kernel, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Jason Baron, Peter Zijlstra,
Eric Dumazet, andi @ firstfloor. org David S. Miller, x86
In-Reply-To: <20131006001247.GB25076@order.stressinduktion.org>
On Sun, Oct 06, 2013 at 02:12:47AM +0200, Hannes Frederic Sowa wrote:
> On Sat, Oct 05, 2013 at 08:05:58PM -0400, Steven Rostedt wrote:
> > > if (type == JUMP_LABEL_ENABLE) {
> > > - /*
> > > - * We are enabling this jump label. If it is not a nop
> > > - * then something must have gone wrong.
> > > - */
> > > - if (unlikely(memcmp((void *)entry->code, ideal_nop, 5) != 0))
> > > - bug_at((void *)entry->code, __LINE__);
> > > + if (init) {
> > > + /*
> > > + * Jump label is enabled for the first time.
> > > + * So we expect a default_nop...
> > > + */
> > > + if (unlikely(memcmp((void *)entry->code, default_nop, 5)
> > > + != 0))
> > > + bug_at((void *)entry->code, __LINE__);
> > > + } else {
> > > + /*
> > > + * ...otherwise expect an ideal_nop. Otherwise
> > > + * something went horribly wrong.
> > > + */
> > > + if (unlikely(memcmp((void *)entry->code, ideal_nop, 5)
> > > + != 0))
> > > + bug_at((void *)entry->code, __LINE__);
> > > + }
> >
> > I don't know if I like this change. This is similar to a bug we had
> > with the Xen folks, where they didn't realize that jump labels are not
> > suppose to be used (or set) before jump_label_init() is called.
> >
> > I'll have to take a deeper look at this on Monday.
>
> Yes, I understand and saw the commit to call jump_label_init
> earlier. Maybe the default could be to insert illegal instructions by
> default if we try to replace them with nops or branches afterwards anyway.
This would not help, but maybe someting like this patch. Andi Kleen
also recently posted something similar, I cleaned it up a bit.
[PATCH] static_key: WARN on usage before jump_label_init was called
Based on a patch from Andi Kleen.
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/linux/jump_label.h | 11 +++++++++++
include/linux/jump_label_ratelimit.h | 2 ++
kernel/jump_label.c | 5 +++++
lib/Makefile | 2 +-
lib/jump_label_initialized.c | 6 ++++++
5 files changed, 25 insertions(+), 1 deletion(-)
create mode 100644 lib/jump_label_initialized.c
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index a507907..ed3a4bd 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -48,6 +48,14 @@
#include <linux/types.h>
#include <linux/compiler.h>
+#include <linux/bug.h>
+
+extern bool static_key_initialized;
+
+#define STATIC_KEY_CHECK_USE() do { \
+ WARN(!static_key_initialized, "%s used before call to jump_label_init", \
+ __func__); \
+} while (0)
#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
@@ -128,6 +136,7 @@ struct static_key {
static __always_inline void jump_label_init(void)
{
+ static_key_initialized = true;
}
static __always_inline bool static_key_false(struct static_key *key)
@@ -146,11 +155,13 @@ static __always_inline bool static_key_true(struct static_key *key)
static inline void static_key_slow_inc(struct static_key *key)
{
+ STATIC_KEY_CHECK_USE();
atomic_inc(&key->enabled);
}
static inline void static_key_slow_dec(struct static_key *key)
{
+ STATIC_KEY_CHECK_USE();
atomic_dec(&key->enabled);
}
diff --git a/include/linux/jump_label_ratelimit.h b/include/linux/jump_label_ratelimit.h
index 1137883..089f70f 100644
--- a/include/linux/jump_label_ratelimit.h
+++ b/include/linux/jump_label_ratelimit.h
@@ -23,12 +23,14 @@ struct static_key_deferred {
};
static inline void static_key_slow_dec_deferred(struct static_key_deferred *key)
{
+ STATIC_KEY_CHECK_USE();
static_key_slow_dec(&key->key);
}
static inline void
jump_label_rate_limit(struct static_key_deferred *key,
unsigned long rl)
{
+ STATIC_KEY_CHECK_USE();
}
#endif /* HAVE_JUMP_LABEL */
#endif /* _LINUX_JUMP_LABEL_RATELIMIT_H */
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 297a924..9019f15 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -58,6 +58,7 @@ static void jump_label_update(struct static_key *key, int enable);
void static_key_slow_inc(struct static_key *key)
{
+ STATIC_KEY_CHECK_USE();
if (atomic_inc_not_zero(&key->enabled))
return;
@@ -103,12 +104,14 @@ static void jump_label_update_timeout(struct work_struct *work)
void static_key_slow_dec(struct static_key *key)
{
+ STATIC_KEY_CHECK_USE();
__static_key_slow_dec(key, 0, NULL);
}
EXPORT_SYMBOL_GPL(static_key_slow_dec);
void static_key_slow_dec_deferred(struct static_key_deferred *key)
{
+ STATIC_KEY_CHECK_USE();
__static_key_slow_dec(&key->key, key->timeout, &key->work);
}
EXPORT_SYMBOL_GPL(static_key_slow_dec_deferred);
@@ -116,6 +119,7 @@ EXPORT_SYMBOL_GPL(static_key_slow_dec_deferred);
void jump_label_rate_limit(struct static_key_deferred *key,
unsigned long rl)
{
+ STATIC_KEY_CHECK_USE();
key->timeout = rl;
INIT_DELAYED_WORK(&key->work, jump_label_update_timeout);
}
@@ -212,6 +216,7 @@ void __init jump_label_init(void)
key->next = NULL;
#endif
}
+ static_key_initialized = true;
jump_label_unlock();
}
diff --git a/lib/Makefile b/lib/Makefile
index f3bb2cb..7f48ddc 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -26,7 +26,7 @@ obj-y += bcd.o div64.o sort.o parser.o halfmd4.o debug_locks.o random32.o \
bust_spinlocks.o hexdump.o kasprintf.o bitmap.o scatterlist.o \
gcd.o lcm.o list_sort.o uuid.o flex_array.o iovec.o clz_ctz.o \
bsearch.o find_last_bit.o find_next_bit.o llist.o memweight.o kfifo.o \
- percpu_ida.o
+ percpu_ida.o jump_label_initialized.o
obj-y += string_helpers.o
obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o
obj-y += kstrtox.o
diff --git a/lib/jump_label_initialized.c b/lib/jump_label_initialized.c
new file mode 100644
index 0000000..a668a40
--- /dev/null
+++ b/lib/jump_label_initialized.c
@@ -0,0 +1,6 @@
+#include <linux/types.h>
+#include <linux/cache.h>
+
+bool static_key_initialized __read_mostly = false;
+EXPORT_SYMBOL_GPL(static_key_initialized);
+
--
1.8.3.1
^ permalink raw reply related
* [PATCH] tun: don't look at current when non-blocking
From: Michael S. Tsirkin @ 2013-10-06 18:25 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: David S. Miller, Jason Wang, Eric Dumazet, Pavel Emelyanov
We play with a wait queue even if socket is
non blocking. This is an obvious waste.
Besides, it will prevent calling the non blocking
variant when current is not valid.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/net/tun.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 807815f..7cb105c 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1293,7 +1293,8 @@ static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
if (unlikely(!noblock))
add_wait_queue(&tfile->wq.wait, &wait);
while (len) {
- current->state = TASK_INTERRUPTIBLE;
+ if (unlikely(!noblock))
+ current->state = TASK_INTERRUPTIBLE;
/* Read frames from the queue */
if (!(skb = skb_dequeue(&tfile->socket.sk->sk_receive_queue))) {
@@ -1320,9 +1321,10 @@ static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
break;
}
- current->state = TASK_RUNNING;
- if (unlikely(!noblock))
+ if (unlikely(!noblock)) {
+ current->state = TASK_RUNNING;
remove_wait_queue(&tfile->wq.wait, &wait);
+ }
return ret;
}
--
MST
^ permalink raw reply related
* Re: [PATCH] usbnet: smsc95xx: Add device tree input for MAC address
From: Dan Murphy @ 2013-10-06 17:31 UTC (permalink / raw)
To: Ming Lei
Cc: Steve Glendinning, Network Development, Linux Kernel Mailing List,
linux-usb, mugunthanvnm-l0cyMroinI0
In-Reply-To: <CACVXFVOVMvP=3y9h2Jrqn2sBQdKOZtrhQDAFYkdHKXFgQj=d0Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 10/06/2013 10:05 AM, Ming Lei wrote:
> On Sat, Oct 5, 2013 at 2:25 AM, Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org> wrote:
>> If the smsc95xx does not have a valid MAC address stored within
>> the eeprom then a random number is generated. The MAC can also
>> be set by uBoot but the smsc95xx does not have a way to read this.
>>
>> Create the binding for the smsc95xx so that uBoot can set the MAC
>> and the code can retrieve the MAC from the modified DTB file.
> Suppose there are two smsc95xx usbnet devices connected to usb bus, and
> one is built-in, another is hotplug device, can your patch handle the situation
> correctly?
Look at this line in the patch below
sprintf(of_name, "%s%i", SMSC95XX_OF_NAME, dev->udev->dev.id);
I am appending the dev ID of the device to the of_name here. As long as init_mac_address is called, the dev.id and the uBoot
entry match then yes.
>> Signed-off-by: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/net/smsc95xx.txt | 17 ++++++++++++++
>> drivers/net/usb/smsc95xx.c | 24 ++++++++++++++++++++
>> 2 files changed, 41 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/smsc95xx.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/smsc95xx.txt b/Documentation/devicetree/bindings/net/smsc95xx.txt
>> new file mode 100644
>> index 0000000..4c37280
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/smsc95xx.txt
>> @@ -0,0 +1,17 @@
>> +* Smart Mixed-Signal Connectivity (SMSC) 95xx Controller
>> +
>> +Required properties:
>> +None
>> +
>> +Optional properties:
>> +- mac-address - Read the mac address that was stored by uBoot
>> +- local-address - Read the mac address that was stored by uBoot
>> +- address - Read the mac address that was stored by uBoot
>> +
>> +Examples:
>> +
>> +smsc0: smsc95xx@0 {
>> + /* Filled in by U-Boot */
>> + mac-address = [ 00 00 00 00 00 00 ];
>> +};
>> +
>> diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
>> index 3f38ba8..baee0bd 100644
>> --- a/drivers/net/usb/smsc95xx.c
>> +++ b/drivers/net/usb/smsc95xx.c
>> @@ -31,6 +31,9 @@
>> #include <linux/crc32.h>
>> #include <linux/usb/usbnet.h>
>> #include <linux/slab.h>
>> +#include <linux/of.h>
>> +#include <linux/of_net.h>
>> +
>> #include "smsc95xx.h"
>>
>> #define SMSC_CHIPNAME "smsc95xx"
>> @@ -62,6 +65,8 @@
>> #define SUSPEND_ALLMODES (SUSPEND_SUSPEND0 | SUSPEND_SUSPEND1 | \
>> SUSPEND_SUSPEND2 | SUSPEND_SUSPEND3)
>>
>> +#define SMSC95XX_OF_NAME "/smsc95xx@"
>> +
>> struct smsc95xx_priv {
>> u32 mac_cr;
>> u32 hash_hi;
>> @@ -767,6 +772,25 @@ static int smsc95xx_ioctl(struct net_device *netdev, struct ifreq *rq, int cmd)
>>
>> static void smsc95xx_init_mac_address(struct usbnet *dev)
>> {
>> +
>> +#ifdef CONFIG_OF
>> + struct device_node *ap;
>> + const char *mac = NULL;
>> + char *of_name = SMSC95XX_OF_NAME;
>> +
>> + sprintf(of_name, "%s%i", SMSC95XX_OF_NAME, dev->udev->dev.id);
>> + ap = of_find_node_by_path(of_name);
>> + if (ap) {
>> + mac = of_get_mac_address(ap);
>> + if (is_valid_ether_addr(mac)) {
>> + /* Device tree has a mac for this so use that */
>> + memcpy(dev->net->dev_addr, mac, ETH_ALEN);
>> + netif_dbg(dev, ifup, dev->net, "MAC address read from DTB\n");
>> + return;
>> + }
>> + }
>> +#endif
>> +
>> /* try reading mac address from EEPROM */
>> if (smsc95xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
>> dev->net->dev_addr) == 0) {
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
> Thanks,
--
------------------
Dan Murphy
--
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: [PATCH net-next] net: Separate the close_list and the unreg_list
From: Francesco Ruggeri @ 2013-10-06 17:13 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev
>
> Can you verify this incremental change fixes it for you?
>
Sure, I will.
Thanks,
Francesco
^ permalink raw reply
* Re: [PATCH v4 net-next] fix unsafe set_memory_rw from softirq
From: Eric Dumazet @ 2013-10-06 16:56 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Daniel Borkmann, Eric Dumazet, Heiko Carstens,
linux-arm-kernel, linuxppc-dev, linux-s390, netdev
In-Reply-To: <1380870846-3357-1-git-send-email-ast@plumgrid.com>
On Fri, 2013-10-04 at 00:14 -0700, Alexei Starovoitov wrote:
> on x86 system with net.core.bpf_jit_enable = 1
> cannot reuse jited filter memory, since it's readonly,
> so use original bpf insns memory to hold work_struct
>
> defer kfree of sk_filter until jit completed freeing
>
> tested on x86_64 and i386
>
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH] net: secure_seq: Move net_secret_init() definition into CONFIG_IPV6 if block
From: Fabio Estevam @ 2013-10-06 16:29 UTC (permalink / raw)
To: Olof Johansson
Cc: David Miller, edumazet, hannes, Network Development,
Fabio Estevam
In-Reply-To: <CAOesGMi6LuP7uVJnHOgpG2RK2Q0R3bJ4kG1ZY3=b-W3k0YhnBg@mail.gmail.com>
Hi Olof,
On Sun, Oct 6, 2013 at 2:25 AM, Olof Johansson <olof@lixom.net> wrote:
> You get it if you have CONFIG_NET enabled, but CONFIG_INET off. We
> seem to have a few defconfigs on arm that has that setting, likely
> because they lack native network interfaces but need local unix
> sockets. Or whatever. But that's how you hit it.
>
> Steps to reproduce, even with ARCH=sparc:
>
> make allnoconfig
> edit .config, set CONFIG_NET=y
> yes "" | make oldconfig
> make
Yes, I fixed the commit log and patch in v2.
Regards,
Fabio Estevam
^ permalink raw reply
* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Hannes Frederic Sowa @ 2013-10-06 16:19 UTC (permalink / raw)
To: Oussama Ghorbel
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <CABfLueGefWM6m6h44yAMBo7=BMUcA=OvcFVYka06QvsxXUAJtw@mail.gmail.com>
On Sun, Oct 06, 2013 at 04:36:56PM +0100, Oussama Ghorbel wrote:
> On Sun, Oct 6, 2013 at 4:13 PM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> > On Sun, Oct 06, 2013 at 03:42:15PM +0100, Oussama Ghorbel wrote:
> >> The initialization in ip6gre_tnl_link_config is done as the following:
> >> static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu)
> >> {
> >> ...
> >> int addend = sizeof(struct ipv6hdr) + 4;
> >> ...
> >> /* Precalculate GRE options length */
> >> if (t->parms.o_flags&(GRE_CSUM|GRE_KEY|GRE_SEQ)) {
> >> if (t->parms.o_flags&GRE_CSUM)
> >> addend += 4;
> >> if (t->parms.o_flags&GRE_KEY)
> >> addend += 4;
> >> if (t->parms.o_flags&GRE_SEQ)
> >> addend += 4;
> >> }
> >> ...
> >> dev->hard_header_len = rt->dst.dev->hard_header_len + addend;
> >> ...
> >> t->hlen = addend;
> >> ..
> >> }
> >>
> >> Unless they are other reasons, the hard_header_len is taken into
> >> account the GRE_KEY, GRE_SEQ ..
> >
> > But only if a new route is found. The hard_header_len reinitialization is
> > guarded by a (rt == NULL). We may have not found one on boot up.
> >
> In that case the function will make a return and hlen will be zero.
> Subtracting hlen in ip6gre_tunnel_change_mtu has no effect ...
Oh yes, somehow I missed that.
We depend on t->hlen when pushing the gre header onto the skb. t->hlen == 0
should never be the case because we assume t->hlen > sizeof(struct ipv6_hdr).
^ permalink raw reply
* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Oussama Ghorbel @ 2013-10-06 15:36 UTC (permalink / raw)
To: Oussama Ghorbel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <20131006151351.GB9295@order.stressinduktion.org>
On Sun, Oct 6, 2013 at 4:13 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Sun, Oct 06, 2013 at 03:42:15PM +0100, Oussama Ghorbel wrote:
>> The initialization in ip6gre_tnl_link_config is done as the following:
>> static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu)
>> {
>> ...
>> int addend = sizeof(struct ipv6hdr) + 4;
>> ...
>> /* Precalculate GRE options length */
>> if (t->parms.o_flags&(GRE_CSUM|GRE_KEY|GRE_SEQ)) {
>> if (t->parms.o_flags&GRE_CSUM)
>> addend += 4;
>> if (t->parms.o_flags&GRE_KEY)
>> addend += 4;
>> if (t->parms.o_flags&GRE_SEQ)
>> addend += 4;
>> }
>> ...
>> dev->hard_header_len = rt->dst.dev->hard_header_len + addend;
>> ...
>> t->hlen = addend;
>> ..
>> }
>>
>> Unless they are other reasons, the hard_header_len is taken into
>> account the GRE_KEY, GRE_SEQ ..
>
> But only if a new route is found. The hard_header_len reinitialization is
> guarded by a (rt == NULL). We may have not found one on boot up.
>
In that case the function will make a return and hlen will be zero.
Subtracting hlen in ip6gre_tunnel_change_mtu has no effect ...
>> > To make this correct we would have to refactor the usage of the variables a
>> > bit as is done in ipv4/ip_tunnel.c. The safest thing would be to leave this
>> > check as-is currently although we exclude some allowed mtus.
>> >
>> > Perhaps you want to take a look how to achieve that? ;)
>> >
>> Why not, consistency is good ...
>
> Thanks,
>
> Hannes
>
Thanks,
Oussama
^ permalink raw reply
* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Hannes Frederic Sowa @ 2013-10-06 15:13 UTC (permalink / raw)
To: Oussama Ghorbel
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <CABfLueFYZkzpEpDJ7YcHJaXfm-=QcgnL3-Es8gybea2cAacQQw@mail.gmail.com>
On Sun, Oct 06, 2013 at 03:42:15PM +0100, Oussama Ghorbel wrote:
> The initialization in ip6gre_tnl_link_config is done as the following:
> static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu)
> {
> ...
> int addend = sizeof(struct ipv6hdr) + 4;
> ...
> /* Precalculate GRE options length */
> if (t->parms.o_flags&(GRE_CSUM|GRE_KEY|GRE_SEQ)) {
> if (t->parms.o_flags&GRE_CSUM)
> addend += 4;
> if (t->parms.o_flags&GRE_KEY)
> addend += 4;
> if (t->parms.o_flags&GRE_SEQ)
> addend += 4;
> }
> ...
> dev->hard_header_len = rt->dst.dev->hard_header_len + addend;
> ...
> t->hlen = addend;
> ..
> }
>
> Unless they are other reasons, the hard_header_len is taken into
> account the GRE_KEY, GRE_SEQ ..
But only if a new route is found. The hard_header_len reinitialization is
guarded by a (rt == NULL). We may have not found one on boot up.
> > To make this correct we would have to refactor the usage of the variables a
> > bit as is done in ipv4/ip_tunnel.c. The safest thing would be to leave this
> > check as-is currently although we exclude some allowed mtus.
> >
> > Perhaps you want to take a look how to achieve that? ;)
> >
> Why not, consistency is good ...
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: Fix pages never dma unmapped on rx
From: Amir Vadai @ 2013-10-06 15:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Or Gerlitz, Eugenia Emantayev, Eric Dumazet
In-Reply-To: <1381069372.3564.68.camel@edumazet-glaptop.roam.corp.google.com>
On 06/10/2013 17:22, Eric Dumazet wrote:
> On Sun, 2013-10-06 at 14:57 +0200, Amir Vadai wrote:
>> This patch fixes a bug introduced by commit 51151a16 (mlx4: allow
>> order-0 memory allocations in RX path).
>>
>> dma_unmap_page never reached because condition to detect last fragment
>> in page is wrong. offset+frag_stride can't be greater than size, need to
>> make sure no additional frag will fit in page => compare offset +
>> frag_stride + next_frag_size instead.
>> next_frag_size could be next frag in the same skb, or the first frag in
>> the next.
>>
>> CC: Eric Dumazet <edumazet@google.com>
>> Signed-off-by: Amir Vadai <amirv@mellanox.com>
>> ---
>> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
>> index dec455c..44d8865 100644
>> --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
>> +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
>> @@ -131,8 +131,11 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
>> int i)
>> {
>> const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
>> + u16 next_frag_end = frags[i].offset + frag_info->frag_stride;
>>
>
> Hmm, could you make this an u32 ?
>
> frags[i].offset and frags[i].size are u32
>
> Maybe some folks want to use PAGE_SIZE=65536 or whatever high order
> allocs
>
>
>> - if (frags[i].offset + frag_info->frag_stride > frags[i].size)
>> + next_frag_end += frags[(i + 1) % priv->num_frags].size;
>> +
>> + if (next_frag_end > frags[i].size)
>> dma_unmap_page(priv->ddev, frags[i].dma, frags[i].size,
>> PCI_DMA_FROMDEVICE);
>>
>
> Not sure I understand how this can work. How was this tested ?
>
> frags[i + 1].size is the size of the page containing next fragment,
> so now test should _always_ trigger.
>
> (We could rename @size to @page_size to avoid confusion)
>
> I think you meant to add the size of the next fragment ?
>
> What about following instead (I also removed the divide operation)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> index dec455c..22444de 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> @@ -131,10 +131,17 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
> int i)
> {
> const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
> + u32 next_frag_end = frags[i].offset + frag_info->frag_stride;
>
> - if (frags[i].offset + frag_info->frag_stride > frags[i].size)
> + frag_info++;
> + if (i + 1 == priv->num_frags)
> + frag_info = &priv->frag_info[0];
> +
> + next_frag_end += frag_info->frag_stride;
> +
> + if (next_frag_end > frags[i].size)
> dma_unmap_page(priv->ddev, frags[i].dma, frags[i].size,
> - PCI_DMA_FROMDEVICE);
> + PCI_DMA_FROMDEVICE);
>
> if (frags[i].page)
> put_page(frags[i].page);
>
>
It looks good.
Will also change it into a small patchset with a new patch to rename
@size to @page_size and @offset to @page_offset.
I Will send it after I finish testing.
(Previously I had the typo added just after I removed the prints I used
while testing).
Thanks,
Amir
^ permalink raw reply
* Re: [PATCH] usbnet: smsc95xx: Add device tree input for MAC address
From: Ming Lei @ 2013-10-06 15:05 UTC (permalink / raw)
To: Dan Murphy
Cc: Steve Glendinning, Network Development, Linux Kernel Mailing List,
linux-usb, mugunthanvnm
In-Reply-To: <1380911156-14112-1-git-send-email-dmurphy@ti.com>
On Sat, Oct 5, 2013 at 2:25 AM, Dan Murphy <dmurphy@ti.com> wrote:
> If the smsc95xx does not have a valid MAC address stored within
> the eeprom then a random number is generated. The MAC can also
> be set by uBoot but the smsc95xx does not have a way to read this.
>
> Create the binding for the smsc95xx so that uBoot can set the MAC
> and the code can retrieve the MAC from the modified DTB file.
Suppose there are two smsc95xx usbnet devices connected to usb bus, and
one is built-in, another is hotplug device, can your patch handle the situation
correctly?
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> Documentation/devicetree/bindings/net/smsc95xx.txt | 17 ++++++++++++++
> drivers/net/usb/smsc95xx.c | 24 ++++++++++++++++++++
> 2 files changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/smsc95xx.txt
>
> diff --git a/Documentation/devicetree/bindings/net/smsc95xx.txt b/Documentation/devicetree/bindings/net/smsc95xx.txt
> new file mode 100644
> index 0000000..4c37280
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/smsc95xx.txt
> @@ -0,0 +1,17 @@
> +* Smart Mixed-Signal Connectivity (SMSC) 95xx Controller
> +
> +Required properties:
> +None
> +
> +Optional properties:
> +- mac-address - Read the mac address that was stored by uBoot
> +- local-address - Read the mac address that was stored by uBoot
> +- address - Read the mac address that was stored by uBoot
> +
> +Examples:
> +
> +smsc0: smsc95xx@0 {
> + /* Filled in by U-Boot */
> + mac-address = [ 00 00 00 00 00 00 ];
> +};
> +
> diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
> index 3f38ba8..baee0bd 100644
> --- a/drivers/net/usb/smsc95xx.c
> +++ b/drivers/net/usb/smsc95xx.c
> @@ -31,6 +31,9 @@
> #include <linux/crc32.h>
> #include <linux/usb/usbnet.h>
> #include <linux/slab.h>
> +#include <linux/of.h>
> +#include <linux/of_net.h>
> +
> #include "smsc95xx.h"
>
> #define SMSC_CHIPNAME "smsc95xx"
> @@ -62,6 +65,8 @@
> #define SUSPEND_ALLMODES (SUSPEND_SUSPEND0 | SUSPEND_SUSPEND1 | \
> SUSPEND_SUSPEND2 | SUSPEND_SUSPEND3)
>
> +#define SMSC95XX_OF_NAME "/smsc95xx@"
> +
> struct smsc95xx_priv {
> u32 mac_cr;
> u32 hash_hi;
> @@ -767,6 +772,25 @@ static int smsc95xx_ioctl(struct net_device *netdev, struct ifreq *rq, int cmd)
>
> static void smsc95xx_init_mac_address(struct usbnet *dev)
> {
> +
> +#ifdef CONFIG_OF
> + struct device_node *ap;
> + const char *mac = NULL;
> + char *of_name = SMSC95XX_OF_NAME;
> +
> + sprintf(of_name, "%s%i", SMSC95XX_OF_NAME, dev->udev->dev.id);
> + ap = of_find_node_by_path(of_name);
> + if (ap) {
> + mac = of_get_mac_address(ap);
> + if (is_valid_ether_addr(mac)) {
> + /* Device tree has a mac for this so use that */
> + memcpy(dev->net->dev_addr, mac, ETH_ALEN);
> + netif_dbg(dev, ifup, dev->net, "MAC address read from DTB\n");
> + return;
> + }
> + }
> +#endif
> +
> /* try reading mac address from EEPROM */
> if (smsc95xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
> dev->net->dev_addr) == 0) {
> --
> 1.7.9.5
>
> --
> 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/
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Oussama Ghorbel @ 2013-10-06 14:42 UTC (permalink / raw)
To: Oussama Ghorbel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <20131005140636.GA25076@order.stressinduktion.org>
On Sat, Oct 5, 2013 at 3:06 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Fri, Oct 04, 2013 at 10:52:13AM +0100, Oussama Ghorbel wrote:
>> Unlike ipv4, the struct member hlen holds the length of the GRE and ipv6
>> headers. This length is also counted in dev->hard_header_len.
>> Perhaps, it's more clean to modify the hlen to count only the GRE header
>> without ipv6 header as the variable name suggest, but the simple way to fix
>> this without regression risk is simply modify the calculation of the limit
>> in ip6gre_tunnel_change_mtu function.
>> Verified in kernel version v3.11.
>>
>> Signed-off-by: Oussama Ghorbel <ou.ghorbel@gmail.com>
>> ---
>> net/ipv6/ip6_gre.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
>> index 90747f1..41487ab 100644
>> --- a/net/ipv6/ip6_gre.c
>> +++ b/net/ipv6/ip6_gre.c
>> @@ -1175,9 +1175,8 @@ done:
>>
>> static int ip6gre_tunnel_change_mtu(struct net_device *dev, int new_mtu)
>> {
>> - struct ip6_tnl *tunnel = netdev_priv(dev);
>> if (new_mtu < 68 ||
>> - new_mtu > 0xFFF8 - dev->hard_header_len - tunnel->hlen)
>> + new_mtu > 0xFFF8 - dev->hard_header_len)
>> return -EINVAL;
>> dev->mtu = new_mtu;
>> return 0;
>
> Hmmm...
>
> dev->hard_header_len is initialized to LL_MAX_HEADER + sizeof(struct ipv6hdr)
> + 4 but won't include the additional head space needed for GRE_SEQ, GRE_KEY
> etc. if at time of tunnel creation the routing table did not had a good guess
> for the outgoing device.
>
This hard_header_len initialization that you have shown above is taken
from ip6gre_tunnel_setup, however this same variable seems to be
reinitialized in ip6gre_tnl_link_config() which are called from
ip6gre_newlink()
The initialization in ip6gre_tnl_link_config is done as the following:
static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu)
{
...
int addend = sizeof(struct ipv6hdr) + 4;
...
/* Precalculate GRE options length */
if (t->parms.o_flags&(GRE_CSUM|GRE_KEY|GRE_SEQ)) {
if (t->parms.o_flags&GRE_CSUM)
addend += 4;
if (t->parms.o_flags&GRE_KEY)
addend += 4;
if (t->parms.o_flags&GRE_SEQ)
addend += 4;
}
...
dev->hard_header_len = rt->dst.dev->hard_header_len + addend;
...
t->hlen = addend;
..
}
Unless they are other reasons, the hard_header_len is taken into
account the GRE_KEY, GRE_SEQ ..
> To make this correct we would have to refactor the usage of the variables a
> bit as is done in ipv4/ip_tunnel.c. The safest thing would be to leave this
> check as-is currently although we exclude some allowed mtus.
>
> Perhaps you want to take a look how to achieve that? ;)
>
Why not, consistency is good ...
> Greetings,
>
> Hannes
>
Thanks,
Oussama
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: Fix pages never dma unmapped on rx
From: Eric Dumazet @ 2013-10-06 14:22 UTC (permalink / raw)
To: Amir Vadai; +Cc: netdev, Or Gerlitz, Eugenia Emantayev, Eric Dumazet
In-Reply-To: <1381064240-12902-1-git-send-email-amirv@mellanox.com>
On Sun, 2013-10-06 at 14:57 +0200, Amir Vadai wrote:
> This patch fixes a bug introduced by commit 51151a16 (mlx4: allow
> order-0 memory allocations in RX path).
>
> dma_unmap_page never reached because condition to detect last fragment
> in page is wrong. offset+frag_stride can't be greater than size, need to
> make sure no additional frag will fit in page => compare offset +
> frag_stride + next_frag_size instead.
> next_frag_size could be next frag in the same skb, or the first frag in
> the next.
>
> CC: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> index dec455c..44d8865 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> @@ -131,8 +131,11 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
> int i)
> {
> const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
> + u16 next_frag_end = frags[i].offset + frag_info->frag_stride;
>
Hmm, could you make this an u32 ?
frags[i].offset and frags[i].size are u32
Maybe some folks want to use PAGE_SIZE=65536 or whatever high order
allocs
> - if (frags[i].offset + frag_info->frag_stride > frags[i].size)
> + next_frag_end += frags[(i + 1) % priv->num_frags].size;
> +
> + if (next_frag_end > frags[i].size)
> dma_unmap_page(priv->ddev, frags[i].dma, frags[i].size,
> PCI_DMA_FROMDEVICE);
>
Not sure I understand how this can work. How was this tested ?
frags[i + 1].size is the size of the page containing next fragment,
so now test should _always_ trigger.
(We could rename @size to @page_size to avoid confusion)
I think you meant to add the size of the next fragment ?
What about following instead (I also removed the divide operation)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index dec455c..22444de 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -131,10 +131,17 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
int i)
{
const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
+ u32 next_frag_end = frags[i].offset + frag_info->frag_stride;
- if (frags[i].offset + frag_info->frag_stride > frags[i].size)
+ frag_info++;
+ if (i + 1 == priv->num_frags)
+ frag_info = &priv->frag_info[0];
+
+ next_frag_end += frag_info->frag_stride;
+
+ if (next_frag_end > frags[i].size)
dma_unmap_page(priv->ddev, frags[i].dma, frags[i].size,
- PCI_DMA_FROMDEVICE);
+ PCI_DMA_FROMDEVICE);
if (frags[i].page)
put_page(frags[i].page);
^ permalink raw reply related
* [PATCH net] net/mlx4_en: Fix pages never dma unmapped on rx
From: Amir Vadai @ 2013-10-06 12:57 UTC (permalink / raw)
To: netdev; +Cc: Amir Vadai, Or Gerlitz, Eugenia Emantayev, Eric Dumazet
This patch fixes a bug introduced by commit 51151a16 (mlx4: allow
order-0 memory allocations in RX path).
dma_unmap_page never reached because condition to detect last fragment
in page is wrong. offset+frag_stride can't be greater than size, need to
make sure no additional frag will fit in page => compare offset +
frag_stride + next_frag_size instead.
next_frag_size could be next frag in the same skb, or the first frag in
the next.
CC: Eric Dumazet <edumazet@google.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index dec455c..44d8865 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -131,8 +131,11 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
int i)
{
const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
+ u16 next_frag_end = frags[i].offset + frag_info->frag_stride;
- if (frags[i].offset + frag_info->frag_stride > frags[i].size)
+ next_frag_end += frags[(i + 1) % priv->num_frags].size;
+
+ if (next_frag_end > frags[i].size)
dma_unmap_page(priv->ddev, frags[i].dma, frags[i].size,
PCI_DMA_FROMDEVICE);
--
1.8.3.4
^ permalink raw reply related
* Re: IPv6 path MTU discovery broken
From: Steinar H. Gunderson @ 2013-10-06 12:48 UTC (permalink / raw)
To: netdev, edumazet
In-Reply-To: <20131006124403.GA9295@order.stressinduktion.org>
On Sun, Oct 06, 2013 at 02:44:03PM +0200, Hannes Frederic Sowa wrote:
> Do you know which remote IP address is part in the failing communication? Same
> as above?
It's in 2001:67c:a4:3::/64 or 2001:67c:a4:1::/64. Unsure which, because now
I rebooted the client for a different reason (giving it a different privacy
address and possibly subnet), and now it's unreproducible again...
/* Steinar */
--
Homepage: http://www.sesse.net/
^ permalink raw reply
* Re: IPv6 path MTU discovery broken
From: Hannes Frederic Sowa @ 2013-10-06 12:44 UTC (permalink / raw)
To: Steinar H. Gunderson; +Cc: netdev, edumazet
In-Reply-To: <20131006120612.GA27852@sesse.net>
On Sun, Oct 06, 2013 at 02:06:12PM +0200, Steinar H. Gunderson wrote:
> On Sat, Sep 28, 2013 at 10:33:18PM +0200, Hannes Frederic Sowa wrote:
> >> So the “packet too big” packets really look like they're being ignored.
> >> However, they _do_ reach the kernel somehow, since Icmp6InPktTooBigs
> >> seems to increase.
> >>
> >> Could this be related somehow to the packets coming from 2001:67c:29f4::31,
> >> while the default route is to a link-local address? (An RPF issue?) This used
> >> to work (although it was often flaky for me) in 3.10 and before. I can't
> >> easily bisect, though, as I don't boot this machine too often.
> > This looks like a bug and should definitely get fixed. There should be
> > no RPF issue. May I have a look at your /proc/net/ipv6_route?
>
> It started again, so now I could capture what you asked for:
Thanks!
Do you know which remote IP address is part in the failing communication? Same
as above?
Greetings,
Hannes
^ permalink raw reply
* Re: IPv6 path MTU discovery broken
From: Steinar H. Gunderson @ 2013-10-06 12:06 UTC (permalink / raw)
To: netdev, edumazet
In-Reply-To: <20130928203318.GC23654@order.stressinduktion.org>
On Sat, Sep 28, 2013 at 10:33:18PM +0200, Hannes Frederic Sowa wrote:
>> So the “packet too big” packets really look like they're being ignored.
>> However, they _do_ reach the kernel somehow, since Icmp6InPktTooBigs
>> seems to increase.
>>
>> Could this be related somehow to the packets coming from 2001:67c:29f4::31,
>> while the default route is to a link-local address? (An RPF issue?) This used
>> to work (although it was often flaky for me) in 3.10 and before. I can't
>> easily bisect, though, as I don't boot this machine too often.
> This looks like a bug and should definitely get fixed. There should be
> no RPF issue. May I have a look at your /proc/net/ipv6_route?
It started again, so now I could capture what you asked for:
pannekake:~> cat /proc/net/ipv6_route
20010500007200000000000000000000 30 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000400 00000000 00000000 00000003 eth0
2001067c00a400037c4d9ae8ab73230f 80 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000000 00000001 00000137 01000023 eth0
2001067c00a400000000000000000000 30 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000064 00000000 00000000 00000003 eth0
2001067c29f400000000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00003dc0 01000001 eth0
2001067c29f400000000000000000031 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00047359 01000001 eth0
2001067c29f400000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000001 00000001 eth0
2001067c29f400010000000000000000 40 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000064 00000000 00000000 00000003 eth0
2001067c29f410000000000000000000 40 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000064 00000000 00000000 00000003 eth0
2001067c29f410010000000000000000 40 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000064 00000000 00000000 00000003 eth0
2001067c29f410030000000000000000 40 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000064 00000000 00000000 00000003 eth0
2001067c29f410050000000000000000 40 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000064 00000000 00000000 00000003 eth0
2001067c29f410070000000000000000 40 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000064 00000000 00000000 00000003 eth0
2001067c29f400000000000000000000 30 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000400 00000000 00000000 00000003 eth0
20010700000000000000000000000000 20 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000400 00000000 00000000 00000003 eth0
2001070800402001a822bafffec42428 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000001 0000ab13 01000003 eth0
20010840000010000001000000000001 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000001 0001114c 01000003 eth0
26200000105f0004be305bfffed17063 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000003 0000002f 01000003 eth0
2a01023842d7aa006667669799990042 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000001 000081ef 01000003 eth0
2a022368000000000000000000000000 20 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000400 00000000 00000000 00000003 eth0
fe80000000000000000000002ae38049 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000001 01000001 k_magne
fe80000000000000000000002cb7a217 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000004 01000001 k_molvenfinnoy
fe8000000000000000000000315e851e 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000001 01000001 k_trygve
fe8000000000000000000000419b407a 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000001 01000001 k_molven
fe80000000000000000000005ccc2ed1 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000001 01000001 k_sessesveits
fe800000000000000000000077707d72 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000001 01000001 k_berge
fe8000000000000000000000c2faf88c 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000001 01000001 k_wikene
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_sessesveits
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_trygve
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_wikene
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_molven
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_magne
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_berge
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_molvenfinnoy
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 eth0
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_sessesveits
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_trygve
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_wikene
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_molven
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_magne
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_berge
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_molvenfinnoy
00000000000000000000000000000000 00 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000400 00000000 00000000 00000003 eth0
00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 0009a4db 00200200 lo
00000000000000000000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 0000a62c 80200001 lo
2001067c29f400000000000000000000 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000000 00300001 lo
2001067c29f400000000000000000050 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 0000000a 1a692b94 80200001 lo
fe800000000000000000000000000000 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000000 00300001 lo
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 0000602f 80200001 lo
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 00003c59 80200001 lo
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 0000530e 80200001 lo
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 00005bbb 80200001 lo
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 00003fad 80200001 lo
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 00002953 80200001 lo
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000000 80200001 lo
fe80000000000000022590fffe006b52 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 0000541c 80200001 lo
ff020000000000000000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000002 01000001 eth0
ff02000000000000000000000000000d 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 0000003a 01000001 eth0
ff02000000000000000000000000000d 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 0000000b 01000001 k_sessesveits
ff02000000000000000000000000000d 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 0000000b 01000001 k_molven
ff020000000000000000000000010002 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000004 01000001 eth0
ff0200000000000000000001ff000020 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000001 01000001 eth0
ff0200000000000000000001ff000029 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 0000000a 01000001 eth0
ff0200000000000000000001ff000030 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000004 01000001 eth0
ff0200000000000000000001ff000031 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000001 01000001 eth0
ff0200000000000000000001ff000032 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000045 01000001 eth0
ff0200000000000000000001ff000057 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000001 01000001 eth0
ff0200000000000000000001ff003004 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000001 01000001 eth0
ff0200000000000000000001ff003005 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000002 01000001 eth0
ff0200000000000000000001ff4793da 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000003 01000001 eth0
ff0200000000000000000001ff5945c2 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000003 01000001 eth0
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 eth0
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_sessesveits
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_trygve
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_wikene
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_molven
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_magne
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_berge
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_molvenfinnoy
00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 0009a4db 00200200 lo
/* Steinar */
--
Homepage: http://www.sesse.net/
^ permalink raw reply
* Sometimes things happen much quicker than you would love to.
From: JeffreyCHaber @ 2013-10-06 10:25 UTC (permalink / raw)
Dear Customer
Why missing moments with your loved ones when you have the solution at one click distance?
Never miss a moment again
http://translate.googleusercontent.com/translate_c?depth=1&hl=auto&sl=fr&url=www.google.ch&u=http://myonlinestore1.yolasite.com/shop&usg=ALkJrhiQ-uda4tZHsm2mYWAuq6KLfgZUuA
Best Regards,
^ permalink raw reply
* Re: Bug - regression - Via velocity interface coming up freezes kernel
From: Jamie Heilman @ 2013-10-06 8:19 UTC (permalink / raw)
To: netdev; +Cc: Francois Romieu
In-Reply-To: <CAFES+i+9Wk6GMo8jMPH4uAz0AFi16RCWaRjG2YOyjRiBnx7OVQ@mail.gmail.com>
FWIW, I encountered this same issue on my EPIA-SN with its onboard
VT6130, I bisected back to the same commit, and Francois's patch
against 3.11.4 also eliminated the warning for me. Hopefully a fix
is queued up for stable soon.
For the record the full trace was:
WARNING: CPU: 0 PID: 0 at kernel/softirq.c:159 _local_bh_enable_ip.isra.14+0x32/0x6e()
Modules linked in: quota_v2 quota_tree nfsd auth_rpcgss oid_registry exportfs nfs lockd fscache sunrpc xt_mark cls_fw sch_htb xt_nat iptable_nat nf_nat_ipv4 nf_nat ipt_REJECT xt_tcpudp xt_multiport iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_LOG xt_limit iptable_filter ip_tables x_tables dm_crypt dm_mod snd_hda_codec_via snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore psmouse via_rhine mii via_velocity evdev via_agp ioapic agpgart
CPU: 0 PID: 0 Comm: swapper Not tainted 3.11.4 #1
Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080014 06/01/2009
00000000 00000000 c1355d04 c125c0f9 c1355d34 c1024360 c12ecca6 00000000
00000000 c12ece5c 0000009f c1026769 c1026769 f5041cc0 c138cb2c f5ae3000
c1355d44 c10243f3 00000009 00000000 c1355d4c c1026769 c1355d54 c10267ad
Call Trace:
[<c125c0f9>] dump_stack+0x16/0x18
[<c1024360>] warn_slowpath_common+0x70/0x87
[<c1026769>] ? _local_bh_enable_ip.isra.14+0x32/0x6e
[<c1026769>] ? _local_bh_enable_ip.isra.14+0x32/0x6e
[<c10243f3>] warn_slowpath_null+0x1d/0x1f
[<c1026769>] _local_bh_enable_ip.isra.14+0x32/0x6e
[<c10267ad>] local_bh_enable+0x8/0xa
[<c120e15f>] neigh_lookup+0x95/0x9e
[<c124239a>] __neigh_lookup.constprop.16+0x1b/0x4e
[<c1242b3f>] arp_process+0x3ac/0x461
[<c1216860>] ? sch_direct_xmit+0x37/0xd9
[<c10267ad>] ? local_bh_enable+0x8/0xa
[<c1208ccd>] ? dev_queue_xmit+0x2aa/0x2b7
[<c1242cc2>] arp_rcv+0xc4/0x107
[<c1242714>] ? arp_xmit+0x18/0x4f
[<c1206c67>] __netif_receive_skb_core+0x366/0x39f
[<c1004f09>] ? text_poke_smp_batch+0x2a/0x2a
[<c1206cb1>] __netif_receive_skb+0x11/0x4d
[<c1004f09>] ? text_poke_smp_batch+0x2a/0x2a
[<c1207747>] netif_receive_skb+0x30/0x33
[<f84465aa>] velocity_rx_srv+0x229/0x304 [via_velocity]
[<f84466b6>] velocity_poll+0x31/0x7a [via_velocity]
[<c12078bb>] net_rx_action+0x69/0xe9
[<c1026a0b>] __do_softirq+0x87/0x12d
[<c1026b57>] irq_exit+0x36/0x6d
[<c1002c4e>] do_IRQ+0x74/0x87
[<c125ef73>] common_interrupt+0x33/0x38
[<c1006739>] ? default_idle+0x5/0x7
[<c1006a9d>] arch_cpu_idle+0x12/0x17
[<c1040a04>] cpu_startup_entry+0xbe/0x109
[<c1257758>] rest_init+0x57/0x59
[<c1394920>] start_kernel+0x2be/0x2c4
[<c1394494>] ? repair_env_string+0x51/0x51
[<c13942c3>] i386_start_kernel+0x79/0x7d
---[ end trace 96eca78d04cc6ac3 ]---
--
Jamie Heilman http://audible.transient.net/~jamie/
^ 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