* 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
* 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: 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 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
* [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
* [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
* 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
* 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] 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] 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 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
* [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: 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
* 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: [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][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 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 -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 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 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 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] net/packet: remove dead code and unneeded variable from prb_setup_retire_blk_timer()
From: Ryan Mallon @ 2011-11-14 5:42 UTC (permalink / raw)
To: Jesper Juhl
Cc: netdev, linux-kernel, David S. Miller, Eric Dumazet, Changli Gao,
Ben Greear, Chetan Loke, waltje, gw4pts, waltje, ross.biro, alan
In-Reply-To: <alpine.LNX.2.00.1111132247440.3368@swampdragon.chaosbits.net>
On 14/11/11 08:55, Jesper Juhl wrote:
> We test for 'tx_ring' being != zero and BUG() if that's the case. So after
> that check there is no way that 'tx_ring' could be anything _but_ zero, so
> testing it again is just dead code. Once that dead code is removed, the
> 'pkc' local variable becomes entirely redundant, so remove that as well.
What if CONFIG_BUG=n?
~Ryan
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
> ---
> net/packet/af_packet.c | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> only compile tested.
>
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index 82a6f34..ab10e84 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -516,13 +516,11 @@ static void prb_init_blk_timer(struct packet_sock *po,
>
> static void prb_setup_retire_blk_timer(struct packet_sock *po, int tx_ring)
> {
> - struct tpacket_kbdq_core *pkc;
> -
> if (tx_ring)
> BUG();
>
> - pkc = tx_ring ? &po->tx_ring.prb_bdqc : &po->rx_ring.prb_bdqc;
> - prb_init_blk_timer(po, pkc, prb_retire_rx_blk_timer_expired);
> + prb_init_blk_timer(po, &po->rx_ring.prb_bdqc,
> + prb_retire_rx_blk_timer_expired);
> }
>
> static int prb_calc_retire_blk_tmo(struct packet_sock *po,
^ permalink raw reply
* Re: [PATCH net-next v2] net-forcedeth: Add internal loopback support for forcedeth NICs.
From: Sanjay Hortikar @ 2011-11-14 5:41 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-kernel, david.decotigny, ian.campbell, rick.jones2,
eric.dumazet, maheshb
In-Reply-To: <20111114.002257.1441682753359852153.davem@davemloft.net>
Thank you.
- S.
On Sun, Nov 13, 2011 at 9:22 PM, David Miller <davem@davemloft.net> wrote:
> From: Sanjay Hortikar <horti@google.com>
> Date: Fri, 11 Nov 2011 18:11:21 -0800
>
>> Support enabling/disabling/querying internal loopback mode for
>> forcedeth NICs using ethtool.
>>
>> Signed-off-by: Sanjay Hortikar <horti@google.com>
>> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>
> Applied, thanks.
>
^ permalink raw reply
* Re: [PATCH 1/2] net/smsc911x: Always wait for the chip to be ready
From: David Miller @ 2011-11-14 5:41 UTC (permalink / raw)
To: linus.walleij; +Cc: netdev, steve.glendinning, mathieu.poirier, robert.marklund
In-Reply-To: <CAKnu2MoraoPsqBa9KSHHCG=8avrk_thdNEox1RUTRUGZKr14kA@mail.gmail.com>
From: Linus Walleij <linus.walleij@linaro.org>
Date: Tue, 8 Nov 2011 11:34:01 +0100
> 2011/10/26 Linus Walleij <linus.walleij@stericsson.com>:
>
>> From: Robert Marklund <robert.marklund@stericsson.com>
>>
>> Wait for the chip to be ready before any access to it. On the
>> Snowball platform we need to enable an external regulator before
>> the chip comes online, and then it happens that the device is
>> not yet ready at probe time, so let's wait for it.
>>
>> Signed-off-by: Robert Marklund <robert.marklund@stericsson.com>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
> Since there doesn't seem to be any consternation concerning
> this first patch, can it be applied?
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] bridge: Fix potential deadlock on br->multicast_lock
From: David Miller @ 2011-11-14 5:39 UTC (permalink / raw)
To: avagin; +Cc: shemminger, bridge, netdev, linux-kernel, devel
In-Reply-To: <1320940083-3719823-1-git-send-email-avagin@openvz.org>
From: Andrew Vagin <avagin@openvz.org>
Date: Thu, 10 Nov 2011 18:48:03 +0300
> multicast_lock is taken in softirq context, so we should use
> spin_lock_bh() in userspace.
>
> call-chain in softirq context:
> run_timer_softirq()
> br_multicast_query_expired()
>
> call-chain in userspace:
> sysfs_write_file()
> store_multicast_snooping()
> br_multicast_toggle()
>
> Signed-off-by: Andrew Vagin <avagin@openvz.org>
Applied, thanks.
^ 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