* Re: [PATCH net-next] bridge: add NTF_USE support
From: David Miller @ 2011-11-14 5:42 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20111109203008.6bebce8d@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 9 Nov 2011 20:30:08 -0800
> More changes to the recent code to support control of forwarding
> database via netlink.
> * Support NTF_USE like neighbour table
> * Validate state bits from application
> * Only send notifications (and change bits) if new entry is
> different.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH series][6LoWPAN][net-next]
From: Alexander Smirnov @ 2011-11-14 5:43 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20111114.002202.1201536915576676890.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Dear David, thank you!
Best regards,
Alexander
2011/11/14 David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>:
> From: Alexander Smirnov <alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Thu, 10 Nov 2011 20:32:58 +0300
>
>> Hello all,
>>
>> The following patch series adds both major feature and minor fixes.
>> Please find detailed description in each of the patches.
>>
>> Just to summarize current development status:
>> By using MAC and PHY layers support from
>> "http://sourceforge.net/projects/linux-zigbee"
>> project now it's possible to run generic network applications (ssh, iperf) over
>> ieee802.15.4 network.
>>
>> iperf shows about ~40Kbits/sec for TCP
>
> All applied, thanks.
>
> In future patch submissions, please layout your Subject lines
> correctly.
>
> Everything that is inside of brackes "[]" will be removed before
> the subject line is placed at the top of the commit message. So
> as-is, your commits would lack any kind of indication of where
> the code changes were occuring since the "6LowPAN" part was removed.
>
> In fact, you didn't mention 6LowPAN at all in the subject line
> of some of your commits. This is unacceptable. There must always
> be a subject prefix of the form "${SUBSYSTEM}: " so that what
> ends up in the commit message lets readers know the general area
> where the change was made.
>
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
^ permalink raw reply
* Re: [PATCH RESUBMITTED net-next 1/2] IPv6 - support for NLM_F_* flags at IPv6 routing requests
From: David Miller @ 2011-11-14 5:44 UTC (permalink / raw)
To: matti.vaittinen; +Cc: netdev
In-Reply-To: <1320919619.17667.0.camel@hakki>
The subject lines are completely identical in patches #1 and #2.
How in the world is someone scanning the commit header lines going to
be able to tell what's different about one change vs. the other?
Please correc this and resubmit.
^ permalink raw reply
* Re: [PATCH -next 0/4] netfilter reverse path filter matches
From: David Miller @ 2011-11-14 5:47 UTC (permalink / raw)
To: fw; +Cc: netfilter-devel, netdev
In-Reply-To: <1320877188-1972-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Wed, 9 Nov 2011 23:19:44 +0100
> Version 3 of the ipv4/v6 reverse path filter matches discussed
> during nfws 2011.
I fully support these changes, please feel free to merge them in
via the netfilter tree and to add my ack:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH V5 net-next] neigh: new unresolved queue limits
From: David Miller @ 2011-11-14 5:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1320876434.3272.12.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 09 Nov 2011 23:07:14 +0100
> Ouch, this was fixed on one machine yesterday, but not the other one I
> used this morning, sorry.
>
> [PATCH V5 net-next] neigh: new unresolved queue limits
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH][RESEND] net/usb: Misc. fixes for the LG-VL600 LTE USB modem
From: David Miller @ 2011-11-14 5:49 UTC (permalink / raw)
To: prox; +Cc: oliver, gregkh, linux-usb, netdev, linux-kernel
In-Reply-To: <1320875290-29407-1-git-send-email-prox@prolixium.com>
From: Mark Kamichoff <prox@prolixium.com>
Date: Wed, 9 Nov 2011 16:48:10 -0500
> Add checking for valid magic values (needed for stability in the event
> corrupted packets are received) and remove some other unneeded checks.
> Also, fix flagging device as WWAN (Bugzilla bug #39952).
>
> Signed-off-by: Mark Kamichoff <prox@prolixium.com>
Applied, thanks Mark.
^ permalink raw reply
* Re: [PATCH] net/can/mscan: add listen only mode
From: David Miller @ 2011-11-14 5:51 UTC (permalink / raw)
To: mkl; +Cc: linux-can, netdev
In-Reply-To: <1320871849-24719-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Wed, 9 Nov 2011 21:50:49 +0100
> This patch adds listen only mode to the mscan controller.
>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
> Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] Sweep additional floors of strcpy in .get_drvinfo routines
From: David Miller @ 2011-11-14 5:54 UTC (permalink / raw)
To: raj
Cc: cooldavid, leedom, e1000-devel, netdev, dm, rl, venza, pcnet32,
romieu, divy
In-Reply-To: <20111109195807.440D229004BE@tardy>
From: raj@tardy.cup.hp.com (Rick Jones)
Date: Wed, 9 Nov 2011 11:58:07 -0800 (PST)
> From: Rick Jones <rick.jones2@hp.com>
>
> Perform another round of floor sweeping, converting the .get_drvinfo
> routines of additional drivers from strcpy to strlcpy along with
> some conversion of sprintf to snprintf.
>
> Signed-off-by: Rick Jones <rick.jones2@hp.com>
Applied, thanks Rick.
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: fsl_pq_mdio: Clean up tbi address configuration
From: Baruch Siach @ 2011-11-14 6:13 UTC (permalink / raw)
To: Andy Fleming; +Cc: David Miller, netdev
In-Reply-To: <1321024239-18861-1-git-send-email-afleming@freescale.com>
Hi Andy,
On Fri, Nov 11, 2011 at 05:10:39AM -0000, Andy Fleming wrote:
> The code for setting the address of the internal TBI PHY was
> convoluted enough without a maze of ifdefs. Clean it up a bit
> so we allow the logic to fail down to -ENODEV at the end of
> the if/else ladder, rather than using ifdefs to repeat the same
> failure code over and over.
>
> Also, remove the support for the auto-configuration. I'm not aware of
> anyone using it, and it ends up using the bus mutex before it's been
> initialized.
With this applied I'm getting
fsl-pq_mdio: probe of ffe24000.mdio failed with error -16
on my P1011 board which does not have a "tbi-phy" node. I'll post a fix
shortly.
baruch
> Signed-off-by: Andy Fleming <afleming@freescale.com>
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH] net: fsl_pq_mdio: fix non tbi phy access
From: Baruch Siach @ 2011-11-14 6:21 UTC (permalink / raw)
To: netdev; +Cc: Baruch Siach, Andy Fleming
Since 952c5ca1 (fsl_pq_mdio: Clean up tbi address configuration) .probe returns
-EBUSY when the "tbi-phy" node is missing. Fix this.
Cc: Andy Fleming <afleming@freescale.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fsl_pq_mdio.c b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
index 4d9f84b..8dee1ae 100644
--- a/drivers/net/ethernet/freescale/fsl_pq_mdio.c
+++ b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
@@ -356,16 +356,16 @@ static int fsl_pq_mdio_probe(struct platform_device *ofdev)
if (prop)
tbiaddr = *prop;
- }
- if (tbiaddr == -1) {
- err = -EBUSY;
+ if (tbiaddr == -1) {
+ err = -EBUSY;
- goto err_free_irqs;
+ goto err_free_irqs;
+ } else {
+ out_be32(tbipa, tbiaddr);
+ }
}
- out_be32(tbipa, tbiaddr);
-
err = of_mdiobus_register(new_bus, np);
if (err) {
printk (KERN_ERR "%s: Cannot register as MDIO bus\n",
--
1.7.7.1
^ permalink raw reply related
* Re: [PATCH net-next] bnx2x: reduce skb truesize by 50%
From: Eric Dumazet @ 2011-11-14 6:25 UTC (permalink / raw)
To: David Miller; +Cc: eilong, bhutchings, pstaszewski, netdev
In-Reply-To: <20111114.000811.780218767629149648.davem@davemloft.net>
Le lundi 14 novembre 2011 à 00:08 -0500, David Miller a écrit :
> I fully support bringing this thing back to life :-)
I'll make extensive tests today and provide two patches when ready, with
all performance results.
Some prefetch() calls will be removed, since build_skb() provides
already cache hot skb.
Thanks
^ permalink raw reply
* Re: [PATCH] net: fsl_pq_mdio: fix non tbi phy access
From: David Miller @ 2011-11-14 6:45 UTC (permalink / raw)
To: baruch; +Cc: netdev, afleming
In-Reply-To: <b693b45a689d42b60a8a9e29dcdd2fb27e20df82.1321251618.git.baruch@tkos.co.il>
From: Baruch Siach <baruch@tkos.co.il>
Date: Mon, 14 Nov 2011 08:21:30 +0200
> Since 952c5ca1 (fsl_pq_mdio: Clean up tbi address configuration) .probe returns
> -EBUSY when the "tbi-phy" node is missing. Fix this.
>
> Cc: Andy Fleming <afleming@freescale.com>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] tcp: fixes for DSACK-based undo of cwnd reduction during fast recovery
From: David Miller @ 2011-11-14 6:45 UTC (permalink / raw)
To: ycheng; +Cc: ncardwell, netdev, ilpo.jarvinen, nanditad, therbert
In-Reply-To: <CAK6E8=dXtgi+W9JQg9ruwU8JxYJf-T7OMad7RhNckFAxsYFndg@mail.gmail.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Tue, 8 Nov 2011 17:18:34 -0800
> On Tue, Nov 8, 2011 at 10:07 AM, Neal Cardwell <ncardwell@google.com> wrote:
>> Fixes for some issues that prevent DSACKs from allowing TCP senders to
>> undo cwnd reductions made during fast recovery.
...
>> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Acked-by: Yuchung Cheng <ycheng@google.com>
>
>
> FWIW. This undo-fix patch on Google Web servers increased the undos in
> loss by 46% and in disorder by 17%. It also corrects the SNMP stats
> TCPTimeouts, TCPRenoFailures, TCPSackFailures by moving state into
> open, instead of disorder, after recovery.
Just wanted to give you guys a heads-up that this patch will take me
some time to review properly.
^ permalink raw reply
* Re: [PATCH V5 net-next] neigh: new unresolved queue limits
From: Eric Dumazet @ 2011-11-14 6:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111114.004813.220637143497418040.davem@davemloft.net>
Le lundi 14 novembre 2011 à 00:48 -0500, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 09 Nov 2011 23:07:14 +0100
>
> > Ouch, this was fixed on one machine yesterday, but not the other one I
> > used this morning, sorry.
> >
> > [PATCH V5 net-next] neigh: new unresolved queue limits
>
> Applied, thanks Eric.
Hi David
I realize changelog was truncated, because it contained a copy of ping
message (--- 192.168.20.108 ping statistics ---)
Normally, the marker line should contains only "---", it seems patchwork
has a too strict behavior.
Thanks
^ permalink raw reply
* Re: [PATCH V5 net-next] neigh: new unresolved queue limits
From: Eric Dumazet @ 2011-11-14 6:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111114.004813.220637143497418040.davem@davemloft.net>
Le lundi 14 novembre 2011 à 00:48 -0500, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 09 Nov 2011 23:07:14 +0100
>
> > Ouch, this was fixed on one machine yesterday, but not the other one I
> > used this morning, sorry.
> >
> > [PATCH V5 net-next] neigh: new unresolved queue limits
>
> Applied, thanks Eric.
Hi David
I realize changelog was truncated, because it contained a copy of ping
message (--- 192.168.20.108 ping statistics ---)
Normally, the marker line should contains only "---", it seems patchwork
has a too strict behavior ?
Thanks
^ permalink raw reply
* [PATCH RESUBMIT2 net-next 1/2] IPv6 routing, NLM_F_* flag support: warn if NEWROUTE lacks of both CREATE and REPLACE flags
From: Matti Vaittinen @ 2011-11-14 7:10 UTC (permalink / raw)
To: davem; +Cc: netdev
The support for NLM_F_* flags at IPv6 routing requests.
If RTM_NEWROUTE request, has neither NLM_F_CREATE, nor NLM_F_REPLACE
specified, a warning is printed but no error is returned.
Patch created against linux-3.2-rc1
Signed-off-by: Matti Vaittinen <Mazziesaccount@gmail.com>
--
diff -uNr Linux-3.2-rc1.orig/net/ipv6/route.c Linux-3.2-rc1.new/net/ipv6/route.c
--- Linux-3.2-rc1.orig/net/ipv6/route.c 2011-11-10 08:44:18.000000000 +0200
+++ Linux-3.2-rc1.new/net/ipv6/route.c 2011-11-10 08:46:15.000000000 +0200
@@ -1230,9 +1230,18 @@
if (cfg->fc_metric == 0)
cfg->fc_metric = IP6_RT_PRIO_USER;
- table = fib6_new_table(net, cfg->fc_table);
+ err = -ENOBUFS;
+ if (NULL != cfg->fc_nlinfo.nlh &&
+ !(cfg->fc_nlinfo.nlh->nlmsg_flags&NLM_F_CREATE)) {
+ table = fib6_get_table(net, cfg->fc_table);
+ if (table == NULL) {
+ printk(KERN_WARNING "NLM_F_CREATE should be specified when creating new rt\n");
+ table = fib6_new_table(net, cfg->fc_table);
+ }
+ } else {
+ table = fib6_new_table(net, cfg->fc_table);
+ }
if (table == NULL) {
- err = -ENOBUFS;
goto out;
}
^ permalink raw reply
* [PATCH RESUBMIT2 net-next 2/2] IPv6 routing, NLM_F_* flag support: REPLACE and EXCL flags support, warn about missing CREATE flag
From: Matti Vaittinen @ 2011-11-14 7:10 UTC (permalink / raw)
To: davem; +Cc: netdev
The support for NLM_F_* flags at IPv6 routing requests.
If NLM_F_CREATE flag is not defined for RTM_NEWROUTE request,
warning is printed, but no error is returned. Instead new route is
added.
Exception is when NLM_F_REPLACE flag is given without NLM_F_CREATE, and
no matching route is found. In this case it should be safe to assume
that the request issuer is familiar with NLM_F_* flags, and does really
not want route to be created.
Specifying NLM_F_REPLACE flag will now make the kernel to search for
matching route, and replace it with new one. If no route is found and
NLM_F_CREATE is specified as well, then new route is created.
Also, specifying NLM_F_EXCL will yield returning of error if matching
route
is found.
Patch created against linux-3.2-rc1
Signed-off-by: Matti Vaittinen <Mazziesaccount@gmail.com>
--
diff -uNr Linux-3.2-rc1.orig/net/ipv6/ip6_fib.c Linux-3.2-rc1.new/net/ipv6/ip6_fib.c
--- Linux-3.2-rc1.orig/net/ipv6/ip6_fib.c 2011-11-10 08:44:18.000000000 +0200
+++ Linux-3.2-rc1.new/net/ipv6/ip6_fib.c 2011-11-10 08:46:00.000000000 +0200
@@ -425,7 +425,8 @@
static struct fib6_node * fib6_add_1(struct fib6_node *root, void *addr,
int addrlen, int plen,
- int offset)
+ int offset, int allow_create,
+ int replace_required)
{
struct fib6_node *fn, *in, *ln;
struct fib6_node *pn = NULL;
@@ -447,8 +448,12 @@
* Prefix match
*/
if (plen < fn->fn_bit ||
- !ipv6_prefix_equal(&key->addr, addr, fn->fn_bit))
+ !ipv6_prefix_equal(&key->addr, addr, fn->fn_bit)) {
+ if (!allow_create)
+ printk(KERN_WARNING
+ "NLM_F_CREATE should be specified when creating new rt\n");
goto insert_above;
+ }
/*
* Exact match ?
@@ -477,10 +482,26 @@
fn = dir ? fn->right: fn->left;
} while (fn);
+ if (replace_required && !allow_create) {
+ /* We should not create new node because
+ * NLM_F_REPLACE was specified without NLM_F_CREATE
+ * I assume it is safe to require NLM_F_CREATE when
+ * REPLACE flag is used! Later we may want to remove the
+ * check for replace_required, because according
+ * to netlink specification, NLM_F_CREATE
+ * MUST be specified if new route is created.
+ * That would keep IPv6 consistent with IPv4
+ */
+ printk(KERN_WARNING
+ "NLM_F_CREATE should be specified when creating new rt - ignoring request\n");
+ return ERR_PTR(-ENOENT);
+ }
/*
* We walked to the bottom of tree.
* Create new leaf node without children.
*/
+ if (!allow_create)
+ printk(KERN_WARNING "NLM_F_CREATE should be specified when creating new rt\n");
ln = node_alloc();
@@ -614,6 +635,12 @@
{
struct rt6_info *iter = NULL;
struct rt6_info **ins;
+ int replace = (NULL != info &&
+ NULL != info->nlh &&
+ (info->nlh->nlmsg_flags&NLM_F_REPLACE));
+ int add = ((NULL == info || NULL == info->nlh) ||
+ (info->nlh->nlmsg_flags&NLM_F_CREATE));
+ int found = 0;
ins = &fn->leaf;
@@ -626,6 +653,13 @@
/*
* Same priority level
*/
+ if (NULL != info->nlh &&
+ (info->nlh->nlmsg_flags&NLM_F_EXCL))
+ return -EEXIST;
+ if (replace) {
+ found++;
+ break;
+ }
if (iter->rt6i_dev == rt->rt6i_dev &&
iter->rt6i_idev == rt->rt6i_idev &&
@@ -655,17 +689,40 @@
/*
* insert node
*/
+ if (!replace) {
+ if (!add)
+ printk(KERN_WARNING "NLM_F_CREATE should be specified when creating new rt\n");
+
+add:
+ rt->dst.rt6_next = iter;
+ *ins = rt;
+ rt->rt6i_node = fn;
+ atomic_inc(&rt->rt6i_ref);
+ inet6_rt_notify(RTM_NEWROUTE, rt, info);
+ info->nl_net->ipv6.rt6_stats->fib_rt_entries++;
+
+ if ((fn->fn_flags & RTN_RTINFO) == 0) {
+ info->nl_net->ipv6.rt6_stats->fib_route_nodes++;
+ fn->fn_flags |= RTN_RTINFO;
+ }
- rt->dst.rt6_next = iter;
- *ins = rt;
- rt->rt6i_node = fn;
- atomic_inc(&rt->rt6i_ref);
- inet6_rt_notify(RTM_NEWROUTE, rt, info);
- info->nl_net->ipv6.rt6_stats->fib_rt_entries++;
-
- if ((fn->fn_flags & RTN_RTINFO) == 0) {
- info->nl_net->ipv6.rt6_stats->fib_route_nodes++;
- fn->fn_flags |= RTN_RTINFO;
+ } else {
+ if (!found) {
+ if (add)
+ goto add;
+ printk(KERN_WARNING "add rtinfo to node - NLM_F_REPLACE specified, but no existing node found! bailing out\n");
+ return -ENOENT;
+ }
+ *ins = rt;
+ rt->rt6i_node = fn;
+ rt->dst.rt6_next = iter->dst.rt6_next;
+ atomic_inc(&rt->rt6i_ref);
+ inet6_rt_notify(RTM_NEWROUTE, rt, info);
+ rt6_release(iter);
+ if ((fn->fn_flags & RTN_RTINFO) == 0) {
+ info->nl_net->ipv6.rt6_stats->fib_route_nodes++;
+ fn->fn_flags |= RTN_RTINFO;
+ }
}
return 0;
@@ -696,9 +753,25 @@
{
struct fib6_node *fn, *pn = NULL;
int err = -ENOMEM;
+ int allow_create = 1;
+ int replace_required = 0;
+ if (NULL != info && NULL != info->nlh) {
+ if (!(info->nlh->nlmsg_flags&NLM_F_CREATE))
+ allow_create = 0;
+ if ((info->nlh->nlmsg_flags&NLM_F_REPLACE))
+ replace_required = 1;
+ }
+ if (!allow_create && !replace_required)
+ printk(KERN_WARNING "RTM_NEWROUTE with no NLM_F_CREATE or NLM_F_REPLACE\n");
fn = fib6_add_1(root, &rt->rt6i_dst.addr, sizeof(struct in6_addr),
- rt->rt6i_dst.plen, offsetof(struct rt6_info, rt6i_dst));
+ rt->rt6i_dst.plen, offsetof(struct rt6_info, rt6i_dst),
+ allow_create, replace_required);
+
+ if (IS_ERR(fn)) {
+ err = PTR_ERR(fn);
+ fn = NULL;
+ }
if (fn == NULL)
goto out;
@@ -736,7 +809,8 @@
sn = fib6_add_1(sfn, &rt->rt6i_src.addr,
sizeof(struct in6_addr), rt->rt6i_src.plen,
- offsetof(struct rt6_info, rt6i_src));
+ offsetof(struct rt6_info, rt6i_src),
+ allow_create, replace_required);
if (sn == NULL) {
/* If it is failed, discard just allocated
@@ -753,8 +827,13 @@
} else {
sn = fib6_add_1(fn->subtree, &rt->rt6i_src.addr,
sizeof(struct in6_addr), rt->rt6i_src.plen,
- offsetof(struct rt6_info, rt6i_src));
+ offsetof(struct rt6_info, rt6i_src),
+ allow_create, replace_required);
+ if (IS_ERR(sn)) {
+ err = PTR_ERR(sn);
+ sn = NULL;
+ }
if (sn == NULL)
goto st_failure;
}
^ permalink raw reply
* Re: [PATCH V5 net-next] neigh: new unresolved queue limits
From: David Miller @ 2011-11-14 7:02 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1321253495.17837.61.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 14 Nov 2011 07:51:35 +0100
> Le lundi 14 novembre 2011 à 00:48 -0500, David Miller a écrit :
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Wed, 09 Nov 2011 23:07:14 +0100
>>
>> > Ouch, this was fixed on one machine yesterday, but not the other one I
>> > used this morning, sorry.
>> >
>> > [PATCH V5 net-next] neigh: new unresolved queue limits
>>
>> Applied, thanks Eric.
>
> Hi David
>
> I realize changelog was truncated, because it contained a copy of ping
> message (--- 192.168.20.108 ping statistics ---)
>
> Normally, the marker line should contains only "---", it seems patchwork
> has a too strict behavior.
>
> Thanks
It's not patchwork, it's "git am"
^ permalink raw reply
* Re: [PATCH] net, bridge: print log message after state changed
From: Fritz, Wolfgang @ 2011-11-14 7:03 UTC (permalink / raw)
To: David Miller; +Cc: netdev, shemminger, bridge, Brunck, Holger
In-Reply-To: <20111114.003702.1097206603722725705.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 1675 bytes --]
Am Montag, den 14.11.2011, 00:37 -0500 schrieb David Miller:
> From: Holger Brunck <holger.brunck@keymile.com>
> Date: Thu, 10 Nov 2011 17:18:54 +0100
>
> > From: Wolfgang Fritz <wolfgang.fritz@keymile.com>
> >
> > Function br_log_state writes log message "... entering XXXX state" so it
> > should be called after the state has changed and not before.
> >
> > Signed-off-by: Wolfgang Fritz <wolfgang.fritz@keymile.com>
> > Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
>
> "entering" can roughly mean "about to enter"
>
Exactly.
> The message is therefore appropriately timed as far as I'm concerned.
>
It's not.
Please test: create a bridge with STP disabled, add an interface to the
bridge and set that interface down. You get the message "... entering
forwarding state". That's wrong because it's "about to enter" disabled
state some lines later.
All other (4) calls to br_log_state are located after the state change,
see for example br_stp_enable_port() just some lines above the patch.
Regards,
Wolfgang
> I'm not applying this patch.
>
--
"I love deadlines. I like the whooshing sound they make as they fly by"
(Douglas Adams)
=======================================================================
KEYMILE GmbH mailto:wolfgang.fritz@keymile.com
Wolfgang Fritz Phone: +49 (0)511 6747-692
Wohlenbergstr. 3 Fax: +49 (0)511 6747-777
D-30179 Hannover http://www.keymile.com
Managing Directors: Björn Claaßen, Dipl.-Kfm. Andreas Gebauer
Legal structure: GmbH, Registered office: Hanover, HRB 61069
Local court Hanover, VAT-Reg.-No.: DE 812282795,
WEEE-Reg.-No.: DE 59336750
[-- Attachment #1.2: Type: text/html, Size: 2591 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Bridge mailing list
Bridge@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bridge
^ permalink raw reply
* Re: [PATCH RESUBMIT2 net-next 1/2] IPv6 routing, NLM_F_* flag support: warn if NEWROUTE lacks of both CREATE and REPLACE flags
From: David Miller @ 2011-11-14 7:06 UTC (permalink / raw)
To: matti.vaittinen; +Cc: netdev
In-Reply-To: <1321254611.23935.15.camel@hakki>
These changes still has problems.
These warning messages are poorly formatted. Some of them don't even indicate
that ipv6 is involved by printing out an appropriate subsystem prefix.
And frankly, they are ugly, and not the kind of thing I want the networking
code spitting out.
Consolidate these messages into something that has good form and will indicate,
consistently, where the trouble is occuring.
And I still submit that perhaps these ugly messages are an indicate of how
bad an idea these changes are in the first place. We've lived with the
current behavior for 15 years or more, nobody cared. What changed?
What can't you do with the current setup? And why can't you do it without
requiring operations that work currently to change semantics?
^ permalink raw reply
* Re: [PATCH] net, bridge: print log message after state changed
From: David Miller @ 2011-11-14 7:07 UTC (permalink / raw)
To: Wolfgang.Fritz; +Cc: netdev, shemminger, bridge, holger.brunck
In-Reply-To: <1321254211.4072.29.camel@pc005091.de.keymile.net>
From: "Fritz, Wolfgang" <Wolfgang.Fritz@keymile.com>
Date: Mon, 14 Nov 2011 08:03:31 +0100
>
> Am Montag, den 14.11.2011, 00:37 -0500 schrieb David Miller:
>> From: Holger Brunck <holger.brunck@keymile.com>
>> Date: Thu, 10 Nov 2011 17:18:54 +0100
>>
>> > From: Wolfgang Fritz <wolfgang.fritz@keymile.com>
>> >
>> > Function br_log_state writes log message "... entering XXXX state" so it
>> > should be called after the state has changed and not before.
>> >
>> > Signed-off-by: Wolfgang Fritz <wolfgang.fritz@keymile.com>
>> > Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
>>
>> "entering" can roughly mean "about to enter"
>>
>
> Exactly.
>
>> The message is therefore appropriately timed as far as I'm concerned.
>>
>
> It's not.
>
> Please test: create a bridge with STP disabled, add an interface to the
> bridge and set that interface down. You get the message "... entering
> forwarding state". That's wrong because it's "about to enter" disabled
> state some lines later.
>
> All other (4) calls to br_log_state are located after the state change,
> see for example br_stp_enable_port() just some lines above the patch.
I would never expect an "entering" message to print out after the event
happens, and in fact I'd _always_ want to see it beforehand so that if
the state change caused a crash or similar it'd be that much easier
to pinpoint the proper location.
I'm still not applying this. If the other log messages behave
differently, they are broken, so go fix those instead.
^ permalink raw reply
* [PATCH] Phonet: set the pipe handle using setsockopt
From: Hemant Vilas RAMDASI @ 2011-11-14 7:53 UTC (permalink / raw)
To: netdev-owner
Cc: netdev, remi.denis-courmont, Dinesh Kumar Sharma, Hemant Ramdasi
From: Dinesh Kumar Sharma <dinesh.sharma@stericsson.com>
This provides flexibility to set the pipe handle
using setsockopt. The pipe can be enabled (if disabled) later
using ioctl.
Signed-off-by: Hemant Ramdasi <hemant.ramdasi@stericsson.com>
Signed-off-by: Dinesh Kumar Sharma <dinesh.sharma@stericsson.com>
---
include/linux/phonet.h | 3 +
net/phonet/pep.c | 105 +++++++++++++++++++++++++++++++++++++++++++-----
2 files changed, 98 insertions(+), 10 deletions(-)
diff --git a/include/linux/phonet.h b/include/linux/phonet.h
index 6fb1384..4c00551 100644
--- a/include/linux/phonet.h
+++ b/include/linux/phonet.h
@@ -37,6 +37,8 @@
#define PNPIPE_ENCAP 1
#define PNPIPE_IFINDEX 2
#define PNPIPE_HANDLE 3
+#define PNPIPE_ENABLE 4
+#define PNPIPE_INITSTATE 5
#define PNADDR_ANY 0
#define PNADDR_BROADCAST 0xFC
@@ -180,6 +182,7 @@ static inline __u8 pn_sockaddr_get_resource(const struct sockaddr_pn *spn)
/* Phonet device ioctl requests */
#ifdef __KERNEL__
#define SIOCPNGAUTOCONF (SIOCDEVPRIVATE + 0)
+#define SIOPNPIPE_ENABLE _IO(SIOCPNGAUTOCONF, 1)
struct if_phonet_autoconf {
uint8_t device;
diff --git a/net/phonet/pep.c b/net/phonet/pep.c
index f17fd84..48339b9 100644
--- a/net/phonet/pep.c
+++ b/net/phonet/pep.c
@@ -533,6 +533,29 @@ static int pep_connresp_rcv(struct sock *sk, struct sk_buff *skb)
return pipe_handler_send_created_ind(sk);
}
+static int pep_enableresp_rcv(struct sock *sk, struct sk_buff *skb)
+{
+ struct pnpipehdr *hdr = pnp_hdr(skb);
+
+ if (hdr->error_code != PN_PIPE_NO_ERROR)
+ return -ECONNREFUSED;
+
+ return pep_indicate(sk, PNS_PIPE_ENABLED_IND, 0 /* sub-blocks */,
+ NULL, 0, GFP_ATOMIC);
+
+}
+
+static void pipe_start_flow_control(struct sock *sk)
+{
+ struct pep_sock *pn = pep_sk(sk);
+
+ if (!pn_flow_safe(pn->tx_fc)) {
+ atomic_set(&pn->tx_credits, 1);
+ sk->sk_write_space(sk);
+ }
+ pipe_grant_credits(sk, GFP_ATOMIC);
+}
+
/* Queue an skb to an actively connected sock.
* Socket lock must be held. */
static int pipe_handler_do_rcv(struct sock *sk, struct sk_buff *skb)
@@ -578,13 +601,25 @@ static int pipe_handler_do_rcv(struct sock *sk, struct sk_buff *skb)
sk->sk_state = TCP_CLOSE_WAIT;
break;
}
+ if (pn->init_enable == PN_PIPE_DISABLE)
+ sk->sk_state = TCP_SYN_RECV;
+ else {
+ sk->sk_state = TCP_ESTABLISHED;
+ pipe_start_flow_control(sk);
+ }
+ break;
- sk->sk_state = TCP_ESTABLISHED;
- if (!pn_flow_safe(pn->tx_fc)) {
- atomic_set(&pn->tx_credits, 1);
- sk->sk_write_space(sk);
+ case PNS_PEP_ENABLE_RESP:
+ if (sk->sk_state != TCP_SYN_SENT)
+ break;
+
+ if (pep_enableresp_rcv(sk, skb)) {
+ sk->sk_state = TCP_CLOSE_WAIT;
+ break;
}
- pipe_grant_credits(sk, GFP_ATOMIC);
+
+ sk->sk_state = TCP_ESTABLISHED;
+ pipe_start_flow_control(sk);
break;
case PNS_PEP_DISCONNECT_RESP:
@@ -863,14 +898,31 @@ static int pep_sock_connect(struct sock *sk, struct sockaddr *addr, int len)
int err;
u8 data[4] = { 0 /* sub-blocks */, PAD, PAD, PAD };
- pn->pipe_handle = 1; /* anything but INVALID_HANDLE */
+ if (pn->pipe_handle == PN_PIPE_INVALID_HANDLE)
+ pn->pipe_handle = 1; /* anything but INVALID_HANDLE */
+
err = pipe_handler_request(sk, PNS_PEP_CONNECT_REQ,
- PN_PIPE_ENABLE, data, 4);
- if (err) {
- pn->pipe_handle = PN_PIPE_INVALID_HANDLE;
+ pn->init_enable, data, 4);
+ if (err)
return err;
- }
+
+ sk->sk_state = TCP_SYN_SENT;
+
+ return 0;
+}
+
+static int pep_sock_enable(struct sock *sk, struct sockaddr *addr, int len)
+{
+ int err;
+
+ err = pipe_handler_request(sk, PNS_PEP_ENABLE_REQ, PAD,
+ NULL, 0);
+
+ if (err)
+ return err;
+
sk->sk_state = TCP_SYN_SENT;
+
return 0;
}
@@ -894,6 +946,16 @@ static int pep_ioctl(struct sock *sk, int cmd, unsigned long arg)
answ = 0;
release_sock(sk);
return put_user(answ, (int __user *)arg);
+ break;
+
+ case SIOPNPIPE_ENABLE:
+ if (sk->sk_state == TCP_SYN_SENT)
+ return -EBUSY;
+ else if (sk->sk_state == TCP_ESTABLISHED)
+ return -EISCONN;
+ else
+ return pep_sock_enable(sk, NULL, 0);
+ break;
}
return -ENOIOCTLCMD;
@@ -959,6 +1021,18 @@ static int pep_setsockopt(struct sock *sk, int level, int optname,
}
goto out_norel;
+ case PNPIPE_HANDLE:
+ if ((sk->sk_state == TCP_CLOSE) &&
+ (val >= 0) && (val < PN_PIPE_INVALID_HANDLE))
+ pn->pipe_handle = val;
+ else
+ err = -EINVAL;
+ break;
+
+ case PNPIPE_INITSTATE:
+ pn->init_enable = !!val;
+ break;
+
default:
err = -ENOPROTOOPT;
}
@@ -994,6 +1068,17 @@ static int pep_getsockopt(struct sock *sk, int level, int optname,
return -EINVAL;
break;
+ case PNPIPE_ENABLE:
+ if (sk->sk_state == TCP_ESTABLISHED)
+ val = 1;
+ else
+ val = 0;
+ break;
+
+ case PNPIPE_INITSTATE:
+ val = pn->init_enable;
+ break;
+
default:
return -ENOPROTOOPT;
}
--
1.7.4.3
^ permalink raw reply related
* [PATCH] ipv4: fix a memory leak in ic_bootp_send_if
From: roy.qing.li @ 2011-11-14 7:54 UTC (permalink / raw)
To: netdev
From: RongQing.Li <roy.qing.li@gmail.com>
when dev_hard_header() failed, the newly allocated skb should be freed.
Signed-off-by: RongQing.Li <roy.qing.li@gmail.com>
---
net/ipv4/ipconfig.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 0da2afc..7f17ba8 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -822,8 +822,13 @@ static void __init ic_bootp_send_if(struct ic_device *d, unsigned long jiffies_d
skb->dev = dev;
skb->protocol = htons(ETH_P_IP);
if (dev_hard_header(skb, dev, ntohs(skb->protocol),
- dev->broadcast, dev->dev_addr, skb->len) < 0 ||
- dev_queue_xmit(skb) < 0)
+ dev->broadcast, dev->dev_addr, skb->len) < 0) {
+ kfree_skb(skb);
+ printk("E");
+ return;
+ }
+
+ if (dev_queue_xmit(skb) < 0)
printk("E");
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH RESUBMIT2 net-next 1/2] IPv6 routing, NLM_F_* flag support: warn if NEWROUTE lacks of both CREATE and REPLACE flags
From: Matti Vaittinen @ 2011-11-14 8:31 UTC (permalink / raw)
To: ext David Miller; +Cc: netdev
In-Reply-To: <20111114.020617.136865443034405914.davem@davemloft.net>
On Mon, 2011-11-14 at 02:06 -0500, ext David Miller wrote:
> These changes still has problems.
>
> These warning messages are poorly formatted. Some of them don't even indicate
> that ipv6 is involved by printing out an appropriate subsystem prefix.
>
> And frankly, they are ugly, and not the kind of thing I want the networking
> code spitting out.
>
> Consolidate these messages into something that has good form and will indicate,
> consistently, where the trouble is occuring.
Messages can be changed, that's no problem. I would like to hear suggestions
because I personally see not much problems in current messages.
(Of course printing out the subsystem is obvious improvement now that you
mentioned it).
It is hard for me to think something better that would still be short
warning telling what's wrong.
> And I still submit that perhaps these ugly messages are an indicate of how
> bad an idea these changes are in the first place. We've lived with the
> current behavior for 15 years or more, nobody cared. What changed?
Need for IPv6 is what changed for me. I've lived past 15 years purely with IPv4.
I expect this change to be true for more users in the future - although I
cant say I expect IPv6 to be be suddenly utilized everywhere.
> What can't you do with the current setup? And why can't you do it without
> requiring operations that work currently to change semantics?
Short answers: I cant just easily replace a route. And I cannot maintain
old way if I want to respect netlink specifications.
Longer story:
Why I started writing this patch is that I had unpleasant surprizes when I
tried using netlink for IPv6 route manipulations first time. I noticed that
IPv6 does not use netlink API as user (I) could expect.
1. Replacing a route surprised me. I did not expect that request with no
CREATE flag would create a new route. That's what happens. Even with
NLM_F_REPLACE
2. Also it was not possible to replace a route in single netlink message.
What got me even more puzzled is, that no warning, no error, no nothing was
returned to me when I set NLM_F_REPLACE flag. I would have expected -ENOTSUP
if there's no support. Or -EINVAL. I had no idea that flag was not supported.
I addmitt it was propably stupid to expect IPv6 to work in same way as IPv4
does. However I used netlink for IPv4 too, so I assumed whatI tried with IPv6
was correct. Finally I had to look at the kernel sources to find out what
happens. I believe that prints (even ugly ones) are better than making
averaǵe Joe like me to search for the answers from kernel sources.
Anyways, what really improves usability is support for REPLACE flag.
Instead of issuing REPLACE request user now needs to:
1. issue GET request to see if there is routes to given destination
2. explisitly delete the matching route
3. create new route and
4. keep on eye the changes done by other processes.
That is whole a lot more work for user, and that requires route manipulation
tools to do different handling for IPv4 and IPv6 routes.
I believe respecting all flags according to netlink specifications would be
what new users expect. Thats why my patch also handles NLM_F_CREATE and
NLM_F_EXCL flags.
However, I think that in usability point of view the support for
NLM_F_REPLACE would be sufficient. Rest is more to fullfill the
specification.
[siedenote: And if we further ponder the NLM_F_* flags that would
improve usability, then NLM_F_MATCH with GET requests is what I would
like. (Returning only routes matching values given in request).
However that's not really supported by IPv4 either, so not having it in IPv6
is not really a priority.]
Anyways, this is the discussion I hoped for before I wrote the patches.
And in my first post to this list I asked if the support for these flags
was left out in purpose. So please let me know, if you think these changes
are unnecessary and wont be included in any case. Then I can just give up
polluting your list with mails and patches, and stop wasting your and my
time. However if you think these changes are worthy, then no problem,
I can do required fixups to these patches. I just would like to know
what changes are acceptable / wanted.
--
Matti Vaittinen
+358 504863070
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Told a UDP joke the other night...
...but I'm not sure everyone got it...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply
* Re: [PATCH v3 net-next 09/12] bnx2x: add fan failure event handling
From: Dmitry Kravkov @ 2011-11-14 8:28 UTC (permalink / raw)
To: Joe Perches, davem, netdev; +Cc: Ariel Elior, Eilon Greenstein
In-Reply-To: <80A6ED01A151614884EE6C5D6AF0F2E9099806AF42@SJEXCHCCR01.corp.ad.broadcom.com>
> -----Original Message-----
> From: Joe Perches [mailto:joe@perches.com]
> Sent: Sunday, November 13, 2011 11:12 PM
> To: Dmitry Kravkov
> Cc: davem@davemloft.net; netdev@vger.kernel.org; Ariel Elior; Eilon Greenstein
> Subject: Re: [PATCH v3 net-next 09/12] bnx2x: add fan failure event handling
>
> On Sun, 2011-11-13 at 16:34 +0200, Dmitry Kravkov wrote:
> > From: Ariel Elior <ariele@broadcom.com>
> > Shut down the device in case of fan failure to prevent HW damage.
> trivia.
> > diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> []
> > @@ -8503,6 +8514,17 @@ sp_rtnl_not_reset:
> []
> > + if (test_and_clear_bit(BNX2X_SP_RTNL_FAN_FAILURE, &bp->sp_rtnl_state)) {
> > + DP(BNX2X_MSG_SP, "fan failure detected. Unloading driver");
>
> Missing a trailing "\n".
>
Reported-by: Joe Perches <joe@perches.com>
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 33ff60d..c09e59a 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -8520,7 +8520,7 @@ sp_rtnl_not_reset:
* damage
*/
if (test_and_clear_bit(BNX2X_SP_RTNL_FAN_FAILURE, &bp->sp_rtnl_state)) {
- DP(BNX2X_MSG_SP, "fan failure detected. Unloading driver");
+ DP(BNX2X_MSG_SP, "fan failure detected. Unloading driver\n");
netif_device_detach(bp->dev);
bnx2x_close(bp->dev);
}
--
1.7.7.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox