* Re: [net 0/3][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2013-03-27 18:10 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1364382333-14721-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 27 Mar 2013 04:05:30 -0700
> This series contains updates to e1000, ixgb and e1000e for Christoph.
>
> Christoph provides 3 patches to resolve missing dma_error_call's to
> provided Intel drivers which did not have this fix.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: pull request (net): ipsec 2013-03-27
From: David Miller @ 2013-03-27 18:09 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1364370068-20025-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Wed, 27 Mar 2013 08:41:05 +0100
> 1) Initialize the satype field in key_notify_policy_flush(),
> this was left uninitialized. From Nicolas Dichtel.
>
> 2) The sequence number difference for replay notifications
> was misscalculated on ESN sequence number wrap. We need
> a separate replay notify function for esn.
>
> 3) Fix an off by one in the esn replay notify function.
> From Mathias Krause.
>
> Please pull or let me know if there are problems.
Pulled, thanks Steffen.
^ permalink raw reply
* Re: [PATCH v2 1/1 net] enet: fec: fix fail resume from suspend state
From: David Miller @ 2013-03-27 18:09 UTC (permalink / raw)
To: Frank.Li; +Cc: shawn.guo, lznuaa, u.kleine-koenig, netdev, linux-arm-kernel
In-Reply-To: <1364350323-2488-1-git-send-email-Frank.Li@freescale.com>
From: Frank Li <Frank.Li@freescale.com>
Date: Wed, 27 Mar 2013 10:12:03 +0800
> Without this patch
> 1. boot with nfs (no_console_suspend)
> 2. echo mem >/sys/power/state
> 3. wakeup by wakesource
> 4. print "eth0: tx queue full"
>
> This fix above problem by reinit bd queue at restart function
>
> Signed-off-by: Frank Li <Frank.Li@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH] yam: avoid null pointer dereference error
From: Colin Ian King @ 2013-03-27 18:08 UTC (permalink / raw)
To: David Miller; +Cc: bhutchings, jpr, linux-hams, netdev
In-Reply-To: <20130327.134651.702432728001011428.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]
On 27/03/13 17:46, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Wed, 27 Mar 2013 17:44:17 +0000
>
>> On Wed, 2013-03-27 at 11:19 +0000, Colin King wrote:
>>> From: Colin Ian King <colin.king@canonical.com>
>>>
>>> yam_open checks if dev is null, however, before that check it
>>> accesses some of the fields from dev in a proceeding printk which
>>> will cause a null pointer dereference error if dev is nul. Move
>>> the printk to after the null check.
>>
>> This function will never be called with dev == NULL.
>
> Then let's remove at least that part of the check.
>
Good point. How about the following..
[-- Attachment #2: 0001-yam-remove-redundant-null-check-on-dev.patch --]
[-- Type: text/x-diff, Size: 1134 bytes --]
>From 564f111f196d9d7293e922a68ba973210d191129 Mon Sep 17 00:00:00 2001
From: Colin Ian King <colin.king@canonical.com>
Date: Wed, 27 Mar 2013 13:59:05 -0400
Subject: [PATCH] yam: remove redundant null check on dev
yam_open has a redundant null check on null, it will
never be called with dev == NULL. Remove this redundant check.
This also cleans up a smatch warning:
drivers/net/hamradio/yam.c:869 yam_open() warn: variable
dereferenced before check 'dev' (see line 867)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/hamradio/yam.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c
index 4cf8f10..b2d863f 100644
--- a/drivers/net/hamradio/yam.c
+++ b/drivers/net/hamradio/yam.c
@@ -866,7 +866,7 @@ static int yam_open(struct net_device *dev)
printk(KERN_INFO "Trying %s at iobase 0x%lx irq %u\n", dev->name, dev->base_addr, dev->irq);
- if (!dev || !yp->bitrate)
+ if (!yp->bitrate)
return -ENXIO;
if (!dev->base_addr || dev->base_addr > 0x1000 - YAM_EXTENT ||
dev->irq < 2 || dev->irq > 15) {
--
1.7.9.5
^ permalink raw reply related
* Re: Is there a preferred way to get the VXLAN port number?
From: Stephen Hemminger @ 2013-03-27 17:52 UTC (permalink / raw)
To: Alexander Duyck
Cc: netdev, Gasparakis, Joseph, Stephen Hemminger, pshelar,
David Miller
In-Reply-To: <51521B05.6060401@intel.com>
On Tue, 26 Mar 2013 15:02:45 -0700
Alexander Duyck <alexander.h.duyck@intel.com> wrote:
> I was wondering if someone would happen to know if there is already a
> preferred way to get the VXLAN port number for things such as
> configuring a device to recognize a VXLAN frame on receive for parsing
> purposes?
>
> I just wanted to check to make sure I hadn't missed something before
> submitting a patch that would export a simple function for supplying the
> vxlan_port value.
>
> Thanks,
>
> Alex
> --
> 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
There are two views of the world. One view is that the UDP port number
should be a fixed assigned number by IANA, and since VXLAN looks exactly
like Cisco LISP, that is what most people use. Others like DOVE seem
to want to use lots of values.
^ permalink raw reply
* Re: [PATCH 1/2] man/send(2): add EPERM to the list of possible errors
From: Pablo Neira Ayuso @ 2013-03-27 17:51 UTC (permalink / raw)
To: Fernando Luis Vazquez Cao
Cc: Michael Kerrisk, linux-man, netdev, netfilter-devel,
Patrick McHardy, Hirotaka Sasaki
In-Reply-To: <51527239.5070505@lab.ntt.co.jp>
Hi Fernando,
On Wed, Mar 27, 2013 at 01:14:49PM +0900, Fernando Luis Vazquez Cao wrote:
> Hi Pablo,
>
> On 2013/03/26 19:48, Pablo Neira Ayuso wrote:
> >On Tue, Mar 26, 2013 at 05:37:50PM +0900, Fernando Luis Vazquez Cao wrote:
> >>Hi Michael,
> >>
> >>Do you see any problem with these two patches?
> >Please, hold on with the second patch.
>
> Are you Ok with getting patch 1 merged while be discuss
> what to do about the issue that the second patch tried to
> document? Could I get your "Acked-by" for it?
Done.
> >I'd like to find a possible solution for the EPERM problem that we've
> >been discussing. It requires some rework and performance evaluation.
>
> The problem is that there is a huge installed base of
> systems that show this broken behaviour, so even if
> we find a proper fix for it we still should document
> which systems may be affected by the spurious EPERM
> bug, thus giving application programmers a chance to
> add logic to their programs to recover from such
> eventualities.
I see. The problem is that it will take some time until that manpage
update reaches main distributions, by that time we may have fixed it
already in existing kernels. Then, we'll have to remove it again. I
still think patch 1 already provides some clue to programmers
regarding EPERM at this moment (even if not so explicit and detailed).
Please, ping me again if we didn't come up with some solution for this
in some prudential amount of time.
Regards.
^ permalink raw reply
* Re: [RFC][PATCH] iproute: Faster ip link add, set and delete
From: Stephen Hemminger @ 2013-03-27 17:47 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Benoit Lourdelet, Serge Hallyn, netdev@vger.kernel.org
In-Reply-To: <874nfwri6o.fsf@xmission.com>
If you need to do lots of operations the --batch mode will be significantly faster.
One command start and one link map.
I have an updated version of link map hash (index and name). Could you test this patch
which applies to latest version in git.
diff --git a/lib/ll_map.c b/lib/ll_map.c
index e9ae129..bf5b0bc 100644
--- a/lib/ll_map.c
+++ b/lib/ll_map.c
@@ -12,6 +12,7 @@
#include <stdio.h>
#include <stdlib.h>
+#include <stddef.h>
#include <unistd.h>
#include <syslog.h>
#include <fcntl.h>
@@ -23,9 +24,44 @@
#include "libnetlink.h"
#include "ll_map.h"
-struct ll_cache
+
+struct hlist_head {
+ struct hlist_node *first;
+};
+
+struct hlist_node {
+ struct hlist_node *next, **pprev;
+};
+
+static inline void hlist_del(struct hlist_node *n)
+{
+ struct hlist_node *next = n->next;
+ struct hlist_node **pprev = n->pprev;
+ *pprev = next;
+ if (next)
+ next->pprev = pprev;
+}
+
+static inline void hlist_add_head(struct hlist_node *n, struct hlist_head *h)
{
- struct ll_cache *idx_next;
+ struct hlist_node *first = h->first;
+ n->next = first;
+ if (first)
+ first->pprev = &n->next;
+ h->first = n;
+ n->pprev = &h->first;
+}
+
+#define hlist_for_each(pos, head) \
+ for (pos = (head)->first; pos ; pos = pos->next)
+
+#define container_of(ptr, type, member) ({ \
+ const typeof( ((type *)0)->member ) *__mptr = (ptr); \
+ (type *)( (char *)__mptr - offsetof(type,member) );})
+
+struct ll_cache {
+ struct hlist_node idx_hash;
+ struct hlist_node name_hash;
unsigned flags;
int index;
unsigned short type;
@@ -33,49 +69,107 @@ struct ll_cache
};
#define IDXMAP_SIZE 1024
-static struct ll_cache *idx_head[IDXMAP_SIZE];
+static struct hlist_head idx_head[IDXMAP_SIZE];
+static struct hlist_head name_head[IDXMAP_SIZE];
-static inline struct ll_cache *idxhead(int idx)
+static struct ll_cache *ll_get_by_index(unsigned index)
{
- return idx_head[idx & (IDXMAP_SIZE - 1)];
+ struct hlist_node *n;
+ unsigned h = index & (IDXMAP_SIZE - 1);
+
+ hlist_for_each(n, &idx_head[h]) {
+ struct ll_cache *im
+ = container_of(n, struct ll_cache, idx_hash);
+ if (im->index == index)
+ return im;
+ }
+
+ return NULL;
+}
+
+static unsigned namehash(const char *str)
+{
+ unsigned hash = 5381;
+
+ while (*str)
+ hash = ((hash << 5) + hash) + *str++; /* hash * 33 + c */
+
+ return hash;
+}
+
+static struct ll_cache *ll_get_by_name(const char *name)
+{
+ struct hlist_node *n;
+ unsigned h = namehash(name) & (IDXMAP_SIZE - 1);
+
+ hlist_for_each(n, &name_head[h]) {
+ struct ll_cache *im
+ = container_of(n, struct ll_cache, name_hash);
+
+ if (strncmp(im->name, name, IFNAMSIZ) == 0)
+ return im;
+ }
+
+ return NULL;
}
int ll_remember_index(const struct sockaddr_nl *who,
struct nlmsghdr *n, void *arg)
{
- int h;
+ unsigned int h;
+ const char *ifname;
struct ifinfomsg *ifi = NLMSG_DATA(n);
- struct ll_cache *im, **imp;
+ struct ll_cache *im;
struct rtattr *tb[IFLA_MAX+1];
- if (n->nlmsg_type != RTM_NEWLINK)
+ if (n->nlmsg_type != RTM_NEWLINK && n->nlmsg_type != RTM_DELLINK)
return 0;
if (n->nlmsg_len < NLMSG_LENGTH(sizeof(ifi)))
return -1;
+ im = ll_get_by_index(ifi->ifi_index);
+ if (n->nlmsg_type == RTM_DELLINK) {
+ if (im) {
+ hlist_del(&im->name_hash);
+ hlist_del(&im->idx_hash);
+ free(im);
+ }
+ return 0;
+ }
+
memset(tb, 0, sizeof(tb));
parse_rtattr(tb, IFLA_MAX, IFLA_RTA(ifi), IFLA_PAYLOAD(n));
- if (tb[IFLA_IFNAME] == NULL)
+ ifname = rta_getattr_str(tb[IFLA_IFNAME]);
+ if (ifname == NULL)
return 0;
- h = ifi->ifi_index & (IDXMAP_SIZE - 1);
- for (imp = &idx_head[h]; (im=*imp)!=NULL; imp = &im->idx_next)
- if (im->index == ifi->ifi_index)
- break;
-
- if (im == NULL) {
- im = malloc(sizeof(*im));
- if (im == NULL)
- return 0;
- im->idx_next = *imp;
- im->index = ifi->ifi_index;
- *imp = im;
+ if (im) {
+ /* change to existing entry */
+ if (strcmp(im->name, ifname) != 0) {
+ hlist_del(&im->name_hash);
+ h = namehash(ifname) & (IDXMAP_SIZE - 1);
+ hlist_add_head(&im->name_hash, &name_head[h]);
+ }
+
+ im->flags = ifi->ifi_flags;
+ return 0;
}
+ im = malloc(sizeof(*im));
+ if (im == NULL)
+ return 0;
+ im->index = ifi->ifi_index;
+ strcpy(im->name, ifname);
im->type = ifi->ifi_type;
im->flags = ifi->ifi_flags;
- strcpy(im->name, RTA_DATA(tb[IFLA_IFNAME]));
+
+ h = ifi->ifi_index & (IDXMAP_SIZE - 1);
+ hlist_add_head(&im->idx_hash, &idx_head[h]);
+
+ h = namehash(ifname) & (IDXMAP_SIZE - 1);
+ hlist_add_head(&im->name_hash, &name_head[h]);
+
return 0;
}
@@ -86,15 +180,14 @@ const char *ll_idx_n2a(unsigned idx, char *buf)
if (idx == 0)
return "*";
- for (im = idxhead(idx); im; im = im->idx_next)
- if (im->index == idx)
- return im->name;
+ im = ll_get_by_index(idx);
+ if (im)
+ return im->name;
snprintf(buf, IFNAMSIZ, "if%d", idx);
return buf;
}
-
const char *ll_index_to_name(unsigned idx)
{
static char nbuf[IFNAMSIZ];
@@ -108,10 +201,9 @@ int ll_index_to_type(unsigned idx)
if (idx == 0)
return -1;
- for (im = idxhead(idx); im; im = im->idx_next)
- if (im->index == idx)
- return im->type;
- return -1;
+
+ im = ll_get_by_index(idx);
+ return im ? im->type : -1;
}
unsigned ll_index_to_flags(unsigned idx)
@@ -121,35 +213,21 @@ unsigned ll_index_to_flags(unsigned idx)
if (idx == 0)
return 0;
- for (im = idxhead(idx); im; im = im->idx_next)
- if (im->index == idx)
- return im->flags;
- return 0;
+ im = ll_get_by_index(idx);
+ return im ? im->flags : -1;
}
unsigned ll_name_to_index(const char *name)
{
- static char ncache[IFNAMSIZ];
- static int icache;
- struct ll_cache *im;
- int i;
+ const struct ll_cache *im;
unsigned idx;
if (name == NULL)
return 0;
- if (icache && strcmp(name, ncache) == 0)
- return icache;
-
- for (i=0; i<IDXMAP_SIZE; i++) {
- for (im = idx_head[i]; im; im = im->idx_next) {
- if (strcmp(im->name, name) == 0) {
- icache = im->index;
- strcpy(ncache, name);
- return im->index;
- }
- }
- }
+ im = ll_get_by_name(name);
+ if (im)
+ return im->index;
idx = if_nametoindex(name);
if (idx == 0)
^ permalink raw reply related
* Re: [PATCH] yam: avoid null pointer dereference error
From: David Miller @ 2013-03-27 17:46 UTC (permalink / raw)
To: bhutchings; +Cc: colin.king, jpr, linux-hams, netdev
In-Reply-To: <1364406257.2922.11.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 27 Mar 2013 17:44:17 +0000
> On Wed, 2013-03-27 at 11:19 +0000, Colin King wrote:
>> From: Colin Ian King <colin.king@canonical.com>
>>
>> yam_open checks if dev is null, however, before that check it
>> accesses some of the fields from dev in a proceeding printk which
>> will cause a null pointer dereference error if dev is nul. Move
>> the printk to after the null check.
>
> This function will never be called with dev == NULL.
Then let's remove at least that part of the check.
^ permalink raw reply
* Re: [PATCH] yam: avoid null pointer dereference error
From: Ben Hutchings @ 2013-03-27 17:44 UTC (permalink / raw)
To: Colin King; +Cc: Jean-Paul Roubelat, linux-hams, netdev
In-Reply-To: <1364383174-17708-1-git-send-email-colin.king@canonical.com>
On Wed, 2013-03-27 at 11:19 +0000, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> yam_open checks if dev is null, however, before that check it
> accesses some of the fields from dev in a proceeding printk which
> will cause a null pointer dereference error if dev is nul. Move
> the printk to after the null check.
This function will never be called with dev == NULL.
Ben.
> Smatch analysis:
>
> drivers/net/hamradio/yam.c:869 yam_open() warn: variable
> dereferenced before check 'dev' (see line 867)
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/hamradio/yam.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c
> index 4cf8f10..e021e51 100644
> --- a/drivers/net/hamradio/yam.c
> +++ b/drivers/net/hamradio/yam.c
> @@ -864,10 +864,11 @@ static int yam_open(struct net_device *dev)
> int i;
> int ret=0;
>
> - printk(KERN_INFO "Trying %s at iobase 0x%lx irq %u\n", dev->name, dev->base_addr, dev->irq);
> -
> if (!dev || !yp->bitrate)
> return -ENXIO;
> +
> + printk(KERN_INFO "Trying %s at iobase 0x%lx irq %u\n", dev->name, dev->base_addr, dev->irq);
> +
> if (!dev->base_addr || dev->base_addr > 0x1000 - YAM_EXTENT ||
> dev->irq < 2 || dev->irq > 15) {
> return -ENXIO;
--
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 1/2] man/send(2): add EPERM to the list of possible errors
From: Pablo Neira Ayuso @ 2013-03-27 17:42 UTC (permalink / raw)
To: Fernando Luis Vázquez Cao
Cc: Michael Kerrisk, linux-man, netdev, netfilter-devel,
Patrick McHardy, Hirotaka Sasaki
In-Reply-To: <1363675513.4767.6.camel@nexus>
On Tue, Mar 19, 2013 at 03:45:13PM +0900, Fernando Luis Vázquez Cao wrote:
> Subject: [PATCH 1/2] man/send(2): add EPERM to the list of possible errors
>
> System policy (for example netfilter rule) can cause a send* operation
> to fail with EPERM.
>
> Reported-by: Hirotaka Sasaki <sasaki.hirotaka@lab.ntt.co.jp>
> Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
^ permalink raw reply
* Re: Is there a preferred way to get the VXLAN port number?
From: Jesse Gross @ 2013-03-27 17:26 UTC (permalink / raw)
To: Alexander Duyck
Cc: netdev, Gasparakis, Joseph, Stephen Hemminger, pshelar,
David Miller
In-Reply-To: <51521B05.6060401@intel.com>
On Tue, Mar 26, 2013 at 3:02 PM, Alexander Duyck
<alexander.h.duyck@intel.com> wrote:
> I was wondering if someone would happen to know if there is already a
> preferred way to get the VXLAN port number for things such as
> configuring a device to recognize a VXLAN frame on receive for parsing
> purposes?
>
> I just wanted to check to make sure I hadn't missed something before
> submitting a patch that would export a simple function for supplying the
> vxlan_port value.
There isn't a good way to do this at the moment. One thing that would
be nice though is if we can make this as generic as possible to
different tunneling formats that might need to be configured in this
way rather than specific to VXLAN.
Another area think about is how best to supply the information to
GRO/RPS to do the software version of these offloads.
^ permalink raw reply
* Re: [net-next PATCH 3/3] net: frag queue per hash bucket locking
From: Eric Dumazet @ 2013-03-27 17:25 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: David S. Miller, netdev, Florian Westphal, Daniel Borkmann,
Hannes Frederic Sowa
In-Reply-To: <20130327155601.15203.25289.stgit@dragon>
On Wed, 2013-03-27 at 16:56 +0100, Jesper Dangaard Brouer wrote:
> This patch implements per hash bucket locking for the frag queue
> hash. This removes two write locks, and the only remaining write
> lock is for protecting hash rebuild. This essentially reduce the
> readers-writer lock to a rebuild lock.
>
> @@ -226,27 +247,32 @@ static struct inet_frag_queue *inet_frag_intern(struct netns_frags *nf,
> struct inet_frag_queue *qp_in, struct inet_frags *f,
> void *arg)
> {
> + struct inet_frag_bucket *hb;
> struct inet_frag_queue *qp;
> #ifdef CONFIG_SMP
> #endif
> unsigned int hash;
>
> - write_lock(&f->lock);
> + read_lock(&f->lock); /* Protects against hash rebuild */
> /*
> * While we stayed w/o the lock other CPU could update
> * the rnd seed, so we need to re-calculate the hash
> * chain. Fortunatelly the qp_in can be used to get one.
> */
> hash = f->hashfn(qp_in);
> + hb = &f->hash[hash];
> + spin_lock_bh(&hb->chain_lock);
> +
> #ifdef CONFIG_SMP
> /* With SMP race we have to recheck hash table, because
> * such entry could be created on other cpu, while we
> - * promoted read lock to write lock.
> + * released the hash bucket lock.
> */
> - hlist_for_each_entry(qp, &f->hash[hash], list) {
> + hlist_for_each_entry(qp, &hb->chain, list) {
> if (qp->net == nf && f->match(qp, arg)) {
> atomic_inc(&qp->refcnt);
> - write_unlock(&f->lock);
> + spin_unlock_bh(&hb->chain_lock);
> + read_unlock(&f->lock);
> qp_in->last_in |= INET_FRAG_COMPLETE;
> inet_frag_put(qp_in, f);
> return qp;
> @@ -258,8 +284,10 @@ static struct inet_frag_queue *inet_frag_intern(struct netns_frags *nf,
> atomic_inc(&qp->refcnt);
>
> atomic_inc(&qp->refcnt);
> - hlist_add_head(&qp->list, &f->hash[hash]);
> - write_unlock(&f->lock);
> + hlist_add_head(&qp->list, &hb->chain);
> + hb->chain_len++;
> + spin_unlock_bh(&hb->chain_lock);
> + read_unlock(&f->lock);
> inet_frag_lru_add(nf, qp);
> return qp;
> }
I am not sure why you added _bh suffix to spin_lock()/spin_unlock()
here ?
(Please check in other functions as well)
^ permalink raw reply
* Re: [PATCH] phy: Elimination the forced speed reduction algorithm.
From: David Miller @ 2013-03-27 17:11 UTC (permalink / raw)
To: kapranoff
Cc: netdev, bhutchings, peppe.cavallaro, joe, bruce.w.allan,
linux-kernel
In-Reply-To: <1364382973-5047-1-git-send-email-kapranoff@inbox.ru>
From: Kirill Kapranov <kapranoff@inbox.ru>
Date: Wed, 27 Mar 2013 15:16:13 +0400
> In case of fixed speed set up for a NIC (e.g. ethtool -s eth0 autoneg off speed
> 100 duplex full) with an ethernet cable plugged off, the mentioned algorithm
> slows down a NIC speed, so further cable hook-up leads to nonoperable link state.
>
> Signed-off-by: Kirill Kapranov <kapranoff@inbox.ru>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 2/3] net: use the frag lru_lock to protect netns_frags.nqueues update
From: David Miller @ 2013-03-27 17:10 UTC (permalink / raw)
To: eric.dumazet; +Cc: brouer, netdev, fw, dborkman, hannes
In-Reply-To: <1364401308.15753.23.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 27 Mar 2013 09:21:48 -0700
> On Wed, 2013-03-27 at 16:55 +0100, Jesper Dangaard Brouer wrote:
>> Move the protection of netns_frags.nqueues updates under the LRU_lock,
>> instead of the write lock. As they are located on the same cacheline,
>> and this is also needed when transitioning to use per hash bucket locking.
>>
>> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
>> ---
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 1/3] net: frag, avoid several CPUs grabbing same frag queue during LRU evictor loop
From: David Miller @ 2013-03-27 17:10 UTC (permalink / raw)
To: eric.dumazet; +Cc: brouer, netdev, fw, dborkman, hannes
In-Reply-To: <1364400844.15753.18.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 27 Mar 2013 09:14:04 -0700
> On Wed, 2013-03-27 at 16:55 +0100, Jesper Dangaard Brouer wrote:
>> The LRU list is protected by its own lock, since commit 3ef0eb0db4
>> (net: frag, move LRU list maintenance outside of rwlock), and
>> no-longer by a read_lock.
>>
>> This makes it possible, to remove the inet_frag_queue, which is about
>> to be "evicted", from the LRU list head. This avoids the problem, of
>> several CPUs grabbing the same frag queue.
>>
>> Note, cannot remove the inet_frag_lru_del() call in fq_unlink()
>> called by inet_frag_kill(), because inet_frag_kill() is also used in
>> other situations. Thus, we use list_del_init() to allow this
>> double list_del to work.
>>
>> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
>> ---
>>
>> net/ipv4/inet_fragment.c | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] ppp: reuse print_hex_dump_bytes
From: David Miller @ 2013-03-27 17:09 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: paulus, linux-ppp, netdev
In-Reply-To: <1364399654-9729-2-git-send-email-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Wed, 27 Mar 2013 17:54:14 +0200
> There is a native function to dump hex buffers.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] net: core: let's use native isxdigit instead of custom
From: David Miller @ 2013-03-27 17:09 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: paulus, linux-ppp, netdev
In-Reply-To: <1364399654-9729-1-git-send-email-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Wed, 27 Mar 2013 17:54:13 +0200
> In kernel we have fast and pretty implementation of the isxdigit() function.
> Let's use it.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 00/06] bnx2x: net-next patch series
From: David Miller @ 2013-03-27 17:09 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, eilong, ariele
In-Reply-To: <1364382319-24952-1-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Wed, 27 Mar 2013 13:05:13 +0200
> Hi Dave,
>
> This patch series mostly contains patches correcting the
> behaviour of VFs - preventing races, correcting VFs' statistics,
> etc.
>
> It also enhances bnx2x's `ethtool -m' command.
>
> Please consider applying these patches to 'net-next'.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next 1/1] bnx2x: Fix AER semaphore release
From: David Miller @ 2013-03-27 17:08 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, eilong, ariele
In-Reply-To: <1364376483-15050-1-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Wed, 27 Mar 2013 11:28:03 +0200
> Commit 7fa6f34 "AER revised" erroneously inserted an error-flow
> in which a semaphore is released even though the attempt to take it
> has failed.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
> Signed-off-by: Ariel Elior <ariele@broadcom.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 1/1] drivers: net: ethernet: ti: sparse warning fix for ti ethernet drivers
From: David Miller @ 2013-03-27 17:08 UTC (permalink / raw)
To: mugunthanvnm; +Cc: netdev, linux-omap
In-Reply-To: <1364378287-11194-1-git-send-email-mugunthanvnm@ti.com>
From: Mugunthan V N <mugunthanvnm@ti.com>
Date: Wed, 27 Mar 2013 15:28:07 +0530
> @@ -179,7 +179,7 @@ cpdma_desc_pool_create(struct device *dev, u32 phys, u32 hw_addr,
> } else {
> pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
> GFP_KERNEL);
> - pool->iomap = pool->cpumap;
> + pool->iomap = (void __iomem *) pool->cpumap;
This is bogus.
Either a pointer is to RAM, or it's an IOMEM pointer. It cannot be both.
This indicates that pool->iomap's usage in this scenerio is not correct
at all.
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: switch to use skb_probe_transport_header()
From: David Miller @ 2013-03-27 17:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: jasowang, netdev, linux-kernel, mst, edumazet
In-Reply-To: <1364395602.15753.7.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 27 Mar 2013 07:46:42 -0700
> On Wed, 2013-03-27 at 17:11 +0800, Jason Wang wrote:
>> Switch to use the new help skb_probe_transport_header() to do the l4 header
>> probing for untrusted sources. For packets with partial csum, the header should
>> already been set by skb_partial_csum_set().
>>
>> Cc: Eric Dumazet <edumazet@google.com>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> drivers/net/macvtap.c | 9 +--------
>> drivers/net/tun.c | 10 +---------
>> drivers/net/xen-netback/netback.c | 10 +---------
>> net/packet/af_packet.c | 22 +++-------------------
>> 4 files changed, 6 insertions(+), 45 deletions(-)
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: core: introduce skb_probe_transport_header()
From: David Miller @ 2013-03-27 17:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: jasowang, netdev, linux-kernel, mst, edumazet
In-Reply-To: <1364395550.15753.6.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 27 Mar 2013 07:45:50 -0700
> On Wed, 2013-03-27 at 17:11 +0800, Jason Wang wrote:
>> Sometimes, we need probe and set the transport header for packets (e.g from
>> untrusted source). This patch introduces a new helper
>> skb_probe_transport_header() which tries to probe and set the l4 header through
>> skb_flow_dissect(), if not just set the transport header to the hint passed by
>> caller.
>>
>> Cc: Eric Dumazet <edumazet@google.com>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> include/linux/skbuff.h | 14 ++++++++++++++
>> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: core: let skb_partial_csum_set() set transport header
From: David Miller @ 2013-03-27 17:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: jasowang, netdev, linux-kernel, mst, edumazet
In-Reply-To: <1364395376.15753.5.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 27 Mar 2013 07:42:56 -0700
> On Wed, 2013-03-27 at 17:11 +0800, Jason Wang wrote:
>> For untrusted packets with partial checksum, we need to set the transport header
>> for precise packet length estimation. We can just let skb_pratial_csum_set() to
>> do this to avoid extra call to skb_flow_dissect() and simplify the caller.
>>
>> Cc: Eric Dumazet <edumazet@google.com>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> net/core/skbuff.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>> index 31c6737..ba64614 100644
>> --- a/net/core/skbuff.c
>> +++ b/net/core/skbuff.c
>> @@ -3370,6 +3370,7 @@ bool skb_partial_csum_set(struct sk_buff *skb, u16 start, u16 off)
>> skb->ip_summed = CHECKSUM_PARTIAL;
>> skb->csum_start = skb_headroom(skb) + start;
>> skb->csum_offset = off;
>> + skb_set_transport_header(skb, start);
>> return true;
>> }
>> EXPORT_SYMBOL_GPL(skb_partial_csum_set);
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] ptp_pch: eliminate a number of sparse warnings
From: David Miller @ 2013-03-27 17:07 UTC (permalink / raw)
To: kpark3469; +Cc: richardcochran, keun-o.park, netdev
In-Reply-To: <1364360843-6777-1-git-send-email-kpark3469@gmail.com>
From: kpark3469@gmail.com
Date: Wed, 27 Mar 2013 14:07:23 +0900
> From: Sahara <keun-o.park@windriver.com>
>
> This fixes a number of sparse warnings like:
> warning: incorrect type in argument 2 (different address spaces)
> expected void volatile [noderef] <asn:2>*addr
> got unsigned int *<noident>
>
> warning: Using plain integer as NULL pointer
>
> Additionally this fixes a warning from checkpatch.pl like:
> WARNING: sizeof pch_param.station should be sizeof(pch_param.station)
>
> Signed-off-by: Sahara <keun-o.park@windriver.com>
Applied.
^ permalink raw reply
* Difference between Net and Net-Next
From: Jim Baxter @ 2013-03-27 17:02 UTC (permalink / raw)
To: netdev
How do you decide which changes should go into "net" and which ones go into "net-
next"?
At a guess I would think bug fixes are in "net" and feature changes into
"net-next" but it is not obvious from the commit log.
^ 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