* Re: [PATCH 1/3][NETLABEL]: Compilation for CONFIG_AUDIT=n case.
From: David Miller @ 2008-02-13 6:35 UTC (permalink / raw)
To: xemul; +Cc: netdev
In-Reply-To: <47AB3DDE.8050109@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Thu, 07 Feb 2008 20:20:30 +0300
> The audit_log_start() will expand into an empty do { } while (0)
> construction and the audit_ctx becomes unused.
>
> The solution: push current->audit_context into audit_log_start()
> directly, since it is not required in any other place in the
> calling function.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH][GENETLINK]: Relax dances with genl_lock.
From: David Miller @ 2008-02-13 6:16 UTC (permalink / raw)
To: xemul; +Cc: netdev
In-Reply-To: <47B1D45D.3020409@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 12 Feb 2008 20:16:13 +0300
> The genl_unregister_family() calls the genl_unregister_mc_groups(),
> which takes and releases the genl_lock and then locks and releases
> this lock itself.
>
> Relax this behavior, all the more so the genl_unregister_mc_groups()
> is called from genl_unregister_family() only.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Ok, applied, thanks.
^ permalink raw reply
* Re: [PATCH][NETLABEL]: Fix lookup logic of netlbl_domhsh_search_def.
From: David Miller @ 2008-02-13 6:15 UTC (permalink / raw)
To: paul.moore; +Cc: xemul, netdev
In-Reply-To: <200802121134.09965.paul.moore@hp.com>
From: Paul Moore <paul.moore@hp.com>
Date: Tue, 12 Feb 2008 11:34:09 -0500
> On Tuesday 12 February 2008 11:27:16 am Pavel Emelyanov wrote:
> > Currently, if the call to netlbl_domhsh_search succeeds the
> > return result will still be NULL.
> >
> > Fix that, by returning the found entry (if any).
> >
> > Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>
> Good catch, thanks.
>
> Acked-by: Paul Moore <paul.moore@hp.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] [IPV6] Minor cleanup: remove unused method declaration (net/ndisc.h).
From: David Miller @ 2008-02-13 6:07 UTC (permalink / raw)
To: ramirose; +Cc: netdev
In-Reply-To: <eb3ff54b0802100840g52a5eb68y8140d3e2e2d94c26@mail.gmail.com>
From: "Rami Rosen" <ramirose@gmail.com>
Date: Sun, 10 Feb 2008 18:40:13 +0200
> This patch removes unused declaration of dflt_rt_lookup() method in
> include/net/ndisc.h
>
> Signed-off-by: Rami Rosen <ramirose@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC, PATCH]: Pass link level header from/to PPP interface
From: David Miller @ 2008-02-13 6:06 UTC (permalink / raw)
To: urs; +Cc: netdev
In-Reply-To: <ygfprv55egs.fsf@janus.isnogud.escape.de>
From: Urs Thuermann <urs@isnogud.escape.de>
Date: 10 Feb 2008 10:48:51 +0100
> So what is your opinion about this change?
No general objections from me.
But if libpcap and tcpdump can already identify PPP packets
then, besides "consistency", what does this buy us other
than potential breakage?
^ permalink raw reply
* Re: [PATCH] Fix comment for skb_pull_rcsum
From: David Miller @ 2008-02-13 6:03 UTC (permalink / raw)
To: urs; +Cc: netdev
In-Reply-To: <ygftzkh5ei0.fsf@janus.isnogud.escape.de>
From: Urs Thuermann <urs@isnogud.escape.de>
Date: 10 Feb 2008 10:48:07 +0100
> Fix comment for skb_pull_rcsum
>
> Signed-off-by: Urs Thuermann <urs@isnogud.escape.de>
Applied, thanks.
^ permalink raw reply
* Re: An ioctl to delete an ipv6 tunnel leads to a kernel panic
From: Natalie Protasevich @ 2008-02-13 6:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev, akpm
In-Reply-To: <20080212.214946.168597748.davem@davemloft.net>
On Feb 12, 2008 9:49 PM, David Miller <davem@davemloft.net> wrote:
> From: "Natalie Protasevich" <protasnb@gmail.com>
> Date: Mon, 11 Feb 2008 12:49:12 -0800
>
> > Possible reason for this failure was identified and tested by the
> > submitter and several other reporters that ran into the same problem.
> > Can the patch be reviewed and pushed upstream if accepted (if the
> > problem hasn't been addressed already)?
>
> There are a lot of bogus patches in there, using funny
> long variable names, and mainly they were meant for testing
> and verification of the problem.
>
> I see no real serious patch submissions in that bug and furthermore
> the patch, if ready, should be submitted formally here to netdev not
> rot in bugzilla.
>
> Finally, what appears to be the proposal cannot be correct. If the
> fib6_add_rt2node() finds that the new route is a duplicate, we should
> disconnect it from the fn->leaf and do a dst_release(). The bug
> appears to be rather that we leave the route attached to the fn, not
> that we drop the refrence to it.
>
> Thank you.
Thanks David for looking in this. I will give this thought to the
diligent reporters, unless someone on the net team can produce a patch
for them to test.
Sometimes reporters come up with patches and I always try to make sure
the patches end up on appropriate mailing list, and I will continue
doing so :)
Regards,
--Natalie
>
^ permalink raw reply
* Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
From: David Miller @ 2008-02-13 6:00 UTC (permalink / raw)
To: jchapman; +Cc: jarkao2, netdev
In-Reply-To: <47B17BCD.2070903@katalix.com>
From: James Chapman <jchapman@katalix.com>
Date: Tue, 12 Feb 2008 10:58:21 +0000
> Here is a trace from when we had _bh locks.
The problem is that the pppol2tp code calls sk_dst_get() in software
interrupt context and that is not allowed.
sk_dst_get() grabs sk->sk_dst_lock without any BH enabling or
disabling.
It can do that because the usage is to make all the lock
taking calls in user context, and in the packet processing
paths use __sk_dst_get().
Probably what the pppol2tp code should do is use __sk_dst_check()
instead of sk_dst_get(). You then have to be able to handle
NULL returns, just like UDP sendmsg() does, which means you'll
need to cook up a routing lookup if __sk_dst_check() gives you
NULL because the route became obsolete.
^ permalink raw reply
* Re: An ioctl to delete an ipv6 tunnel leads to a kernel panic
From: David Miller @ 2008-02-13 5:49 UTC (permalink / raw)
To: protasnb; +Cc: netdev, akpm
In-Reply-To: <32209efe0802111249x16a6bbe0l4c152b3cf3aa0470@mail.gmail.com>
From: "Natalie Protasevich" <protasnb@gmail.com>
Date: Mon, 11 Feb 2008 12:49:12 -0800
> Possible reason for this failure was identified and tested by the
> submitter and several other reporters that ran into the same problem.
> Can the patch be reviewed and pushed upstream if accepted (if the
> problem hasn't been addressed already)?
There are a lot of bogus patches in there, using funny
long variable names, and mainly they were meant for testing
and verification of the problem.
I see no real serious patch submissions in that bug and furthermore
the patch, if ready, should be submitted formally here to netdev not
rot in bugzilla.
Finally, what appears to be the proposal cannot be correct. If the
fib6_add_rt2node() finds that the new route is a duplicate, we should
disconnect it from the fn->leaf and do a dst_release(). The bug
appears to be rather that we leave the route attached to the fn, not
that we drop the refrence to it.
Thank you.
^ permalink raw reply
* Re: [PATCH] [NET]: Add per-connection option to set max TSO frame size
From: Stephen Hemminger @ 2008-02-13 5:22 UTC (permalink / raw)
To: netdev
In-Reply-To: <20080212220132.8446.88493.stgit@localhost.localdomain>
On Tue, 12 Feb 2008 14:01:32 -0800
PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com> wrote:
> This patch adds the ability for device drivers to control the size of the
> TSO frames being sent to them, per TCP connection. By setting the
> netdevice's max_gso_frame_size value, the socket layer will set the GSO
> frame size based on that value. This will propogate into the TCP layer,
> and send TSO's of that size to the hardware.
>
> This can be desirable to help tune the bursty nature of TSO on a
> per-adapter basis, where one may have 1 GbE and 10 GbE devices coexisting
> in a system, one running multiqueue and the other not, etc.
>
> This can also be desirable for devices that cannot support full 64 KB
> TSO's, but still want to benefit from some level of segmentation
> offloading.
>
> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> ---
>
> include/linux/netdevice.h | 6 ++++++
> include/net/sock.h | 2 ++
> net/core/dev.c | 1 +
> net/core/sock.c | 6 ++++--
> net/ipv4/tcp_output.c | 4 ++--
> 5 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 047d432..ed1cc32 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -616,6 +616,7 @@ struct net_device
>
> /* Partially transmitted GSO packet. */
> struct sk_buff *gso_skb;
> + int max_gso_frame_size;
should use unsigned rather than int (yes the older code is sloppy).
Also what about IPV6?
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* [PATCH] [NET]: Add per-connection option to set max TSO frame size
From: PJ Waskiewicz @ 2008-02-12 22:01 UTC (permalink / raw)
To: davem; +Cc: netdev
This patch adds the ability for device drivers to control the size of the
TSO frames being sent to them, per TCP connection. By setting the
netdevice's max_gso_frame_size value, the socket layer will set the GSO
frame size based on that value. This will propogate into the TCP layer,
and send TSO's of that size to the hardware.
This can be desirable to help tune the bursty nature of TSO on a
per-adapter basis, where one may have 1 GbE and 10 GbE devices coexisting
in a system, one running multiqueue and the other not, etc.
This can also be desirable for devices that cannot support full 64 KB
TSO's, but still want to benefit from some level of segmentation
offloading.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
---
include/linux/netdevice.h | 6 ++++++
include/net/sock.h | 2 ++
net/core/dev.c | 1 +
net/core/sock.c | 6 ++++--
net/ipv4/tcp_output.c | 4 ++--
5 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 047d432..ed1cc32 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -616,6 +616,7 @@ struct net_device
/* Partially transmitted GSO packet. */
struct sk_buff *gso_skb;
+ int max_gso_frame_size;
/* ingress path synchronizer */
spinlock_t ingress_lock;
@@ -1475,6 +1476,11 @@ static inline int netif_needs_gso(struct net_device *dev, struct sk_buff *skb)
unlikely(skb->ip_summed != CHECKSUM_PARTIAL));
}
+static inline void netif_set_max_gso_size(struct net_device *dev, int size)
+{
+ dev->max_gso_frame_size = size;
+}
+
/* On bonding slaves other than the currently active slave, suppress
* duplicates except for 802.3ad ETH_P_SLOW, alb non-mcast/bcast, and
* ARP on active-backup slaves with arp_validate enabled.
diff --git a/include/net/sock.h b/include/net/sock.h
index 8a7889b..1977c05 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -151,6 +151,7 @@ struct sock_common {
* @sk_no_check: %SO_NO_CHECK setting, wether or not checkup packets
* @sk_route_caps: route capabilities (e.g. %NETIF_F_TSO)
* @sk_gso_type: GSO type (e.g. %SKB_GSO_TCPV4)
+ * @sk_gso_max_size: Maximum GSO segment size to build
* @sk_lingertime: %SO_LINGER l_linger setting
* @sk_backlog: always used with the per-socket spinlock held
* @sk_callback_lock: used with the callbacks in the end of this struct
@@ -236,6 +237,7 @@ struct sock {
gfp_t sk_allocation;
int sk_route_caps;
int sk_gso_type;
+ int sk_gso_max_size;
int sk_rcvlowat;
unsigned long sk_flags;
unsigned long sk_lingertime;
diff --git a/net/core/dev.c b/net/core/dev.c
index 9549417..f635b29 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4022,6 +4022,7 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
}
dev->egress_subqueue_count = queue_count;
+ dev->max_gso_frame_size = 65536;
dev->get_stats = internal_stats;
netpoll_netdev_init(dev);
diff --git a/net/core/sock.c b/net/core/sock.c
index 433715f..a8b0ae5 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1076,10 +1076,12 @@ void sk_setup_caps(struct sock *sk, struct dst_entry *dst)
if (sk->sk_route_caps & NETIF_F_GSO)
sk->sk_route_caps |= NETIF_F_GSO_SOFTWARE;
if (sk_can_gso(sk)) {
- if (dst->header_len)
+ if (dst->header_len) {
sk->sk_route_caps &= ~NETIF_F_GSO_MASK;
- else
+ } else {
sk->sk_route_caps |= NETIF_F_SG | NETIF_F_HW_CSUM;
+ sk->sk_gso_max_size = dst->dev->max_gso_frame_size;
+ }
}
}
EXPORT_SYMBOL_GPL(sk_setup_caps);
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index ed750f9..8cd128d 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -998,7 +998,7 @@ unsigned int tcp_current_mss(struct sock *sk, int large_allowed)
xmit_size_goal = mss_now;
if (doing_tso) {
- xmit_size_goal = (65535 -
+ xmit_size_goal = ((sk->sk_gso_max_size - 1) -
inet_csk(sk)->icsk_af_ops->net_header_len -
inet_csk(sk)->icsk_ext_hdr_len -
tp->tcp_header_len);
@@ -1274,7 +1274,7 @@ static int tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb)
limit = min(send_win, cong_win);
/* If a full-sized TSO skb can be sent, do it. */
- if (limit >= 65536)
+ if (limit >= sk->sk_gso_max_size)
goto send_now;
if (sysctl_tcp_tso_win_divisor) {
^ permalink raw reply related
* [PATCH] [IPROUTE2] Update various classifiers' help output for expected CLASSID syntax
From: PJ Waskiewicz @ 2008-02-12 21:51 UTC (permalink / raw)
To: stephen.hemminger; +Cc: netdev
This updates the help output to specify that CLASSID should be hexidecimal.
This makes sure that a user entering "flowid 1:10" gets his flow put into
band 15 (0x10) and knows why.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
---
doc/actions/actions-general | 3 +++
tc/f_basic.c | 1 +
tc/f_fw.c | 1 +
tc/f_route.c | 1 +
tc/f_rsvp.c | 1 +
tc/f_u32.c | 1 +
6 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/doc/actions/actions-general b/doc/actions/actions-general
index 6561eda..70f7cd6 100644
--- a/doc/actions/actions-general
+++ b/doc/actions/actions-general
@@ -88,6 +88,9 @@ tc filter add dev lo parent ffff: protocol ip prio 8 u32 \
match ip dst 127.0.0.8/32 flowid 1:12 \
action ipt -j mark --set-mark 2
+NOTE: flowid 1:12 is parsed flowid 0x1:0x12. Make sure if you want flowid
+decimal 12, then use flowid 1:c.
+
3) A feature i call pipe
The motivation is derived from Unix pipe mechanism but applied to packets.
Essentially take a matching packet and pass it through
diff --git a/tc/f_basic.c b/tc/f_basic.c
index 19a7edf..d6d7767 100644
--- a/tc/f_basic.c
+++ b/tc/f_basic.c
@@ -32,6 +32,7 @@ static void explain(void)
fprintf(stderr, "\n");
fprintf(stderr, "Where: SELECTOR := SAMPLE SAMPLE ...\n");
fprintf(stderr, " FILTERID := X:Y:Z\n");
+ fprintf(stderr, "\nNOTE: CLASSID is parsed as hexidecimal input.\n");
}
static int basic_parse_opt(struct filter_util *qu, char *handle,
diff --git a/tc/f_fw.c b/tc/f_fw.c
index 6d1490b..9f4ef6e 100644
--- a/tc/f_fw.c
+++ b/tc/f_fw.c
@@ -28,6 +28,7 @@ static void explain(void)
fprintf(stderr, "Usage: ... fw [ classid CLASSID ] [ police POLICE_SPEC ]\n");
fprintf(stderr, " POLICE_SPEC := ... look at TBF\n");
fprintf(stderr, " CLASSID := X:Y\n");
+ fprintf(stderr, "\nNOTE: CLASSID is parsed as hexidecimal input.\n");
}
#define usage() return(-1)
diff --git a/tc/f_route.c b/tc/f_route.c
index a41b9d5..3bb963c 100644
--- a/tc/f_route.c
+++ b/tc/f_route.c
@@ -31,6 +31,7 @@ static void explain(void)
fprintf(stderr, " [ flowid CLASSID ] [ police POLICE_SPEC ]\n");
fprintf(stderr, " POLICE_SPEC := ... look at TBF\n");
fprintf(stderr, " CLASSID := X:Y\n");
+ fprintf(stderr, "\nNOTE: CLASSID is parsed as hexidecimal input.\n");
}
#define usage() return(-1)
diff --git a/tc/f_rsvp.c b/tc/f_rsvp.c
index 13fcf97..9019ee2 100644
--- a/tc/f_rsvp.c
+++ b/tc/f_rsvp.c
@@ -34,6 +34,7 @@ static void explain(void)
fprintf(stderr, " u{8|16|32} NUMBER mask MASK at OFFSET}\n");
fprintf(stderr, " POLICE_SPEC := ... look at TBF\n");
fprintf(stderr, " FILTERID := X:Y\n");
+ fprintf(stderr, "\nNOTE: CLASSID is parsed as hexidecimal input.\n");
}
#define usage() return(-1)
diff --git a/tc/f_u32.c b/tc/f_u32.c
index 91f2838..d38c536 100644
--- a/tc/f_u32.c
+++ b/tc/f_u32.c
@@ -36,6 +36,7 @@ static void explain(void)
fprintf(stderr, "Where: SELECTOR := SAMPLE SAMPLE ...\n");
fprintf(stderr, " SAMPLE := { ip | ip6 | udp | tcp | icmp | u{32|16|8} | mark } SAMPLE_ARGS [divisor DIVISOR]\n");
fprintf(stderr, " FILTERID := X:Y:Z\n");
+ fprintf(stderr, "\nNOTE: CLASSID is parsed at hexidecimal input.\n");
}
#define usage() return(-1)
^ permalink raw reply related
* RE: [PATCH] [TC U32] Fix input parsing to support more than 9 flow id'scorrectly
From: Waskiewicz Jr, Peter P @ 2008-02-13 4:25 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <47B2637C.4070608@vyatta.com>
> Sorry, can't change the api, update the documentation instead.
Yes, this is much more reasonable. I'll send a patch shortly to do
that.
Thanks
-PJ Waskiewicz
^ permalink raw reply
* CONTACT THE SECRETARY FOR MORE INFORMATION ON YOUR CLAIMS.
From: David Cincibus @ 2008-02-13 4:07 UTC (permalink / raw)
The Foundation De France would like to notify you on this short note
that you are a grant winner of ($1,000,000)one million us dollars.
CONTACT THE SECRETARY FOR MORE INFORMATION ON YOUR CLAIMS.
Executive Secrtary:Mr.Bernard leroy
Tel:+4470-3196-8499
Email:fdf.secretarybernardleroy_08@yahoo.fr
Regards
^ permalink raw reply
* Re: [PATCH] [TC U32] Fix input parsing to support more than 9 flow id'scorrectly
From: Stephen Hemminger @ 2008-02-13 3:26 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P; +Cc: netdev
In-Reply-To: <D5C1322C3E673F459512FB59E0DDC3290482CDB1@orsmsx414.amr.corp.intel.com>
Waskiewicz Jr, Peter P wrote:
>> From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
>>
>> Using strtoul with a base of 16 converts flowid 10 into 0x10,
>> which makes it flowid 16. This is interpreted by the kernel
>> incorrectly, and causes traffic flows above 9 to be
>> classified into band 0 on multiband qdiscs.
>> This changes the base to 10, which will correctly parse input
>> into the proper hexidecimal value.
>>
>
> Stephen,
> We can go one of two ways I suppose. Once is this way, since
> most user input for CLASSID is base 10, or we can update documentation
> to say that CLASSID input is expected to be base 16. What do you think?
>
> Thanks,
> -PJ Waskiewicz
> peter.p.waskiewicz.jr@intel.com
>
>
Sorry, can't change the api, update the documentation instead.
^ permalink raw reply
* Re: [PATCH 2/4] fib_trie: improve output format for /proc/net/fib_trie
From: Stephen Hemminger @ 2008-02-13 3:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: Stephen Hemminger, linux-kernel, netdev
In-Reply-To: <20080212182823.6f8a3a12.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Tue, 12 Feb 2008 16:50:44 -0800 Stephen Hemminger <shemminger@vyatta.com> wrote:
>
>
>> Make output format prettier (more tree like).
>>
>> <local>:
>> --- 0.0.0.0/0
>> |--- 10.111.111.0/24
>> | +-- 10.111.111.0/32 link broadcast
>> | |--- 10.111.111.254/31
>> | | +-- 10.111.111.254/32 host local
>> | | +-- 10.111.111.255/32 link broadcast
>> |--- 127.0.0.0/8
>> | |--- 127.0.0.0/31
>> | | +-- 127.0.0.0/32 link broadcast
>> | | +-- 127.0.0.0/8 host local
>> | | +-- 127.0.0.1/32 host local
>> | +-- 127.255.255.255/32 link broadcast
>> |--- 192.168.1.0/24
>> | |--- 192.168.1.0/28
>> | | +-- 192.168.1.0/32 link broadcast
>> | | +-- 192.168.1.9/32 host local
>> | +-- 192.168.1.255/32 link broadcast
>> <main>:
>> --- 0.0.0.0/0
>> |--- 0.0.0.0/4
>> | +-- 0.0.0.0/0 universe unicast
>> | +-- 10.111.111.0/24 link unicast
>> +-- 169.254.0.0/16 link unicast
>> +-- 192.168.1.0/24 link unicast
>>
>
> isn't that a non-back-compatible kernel ABI change? It might
> break pre-existing parsers?
>
>
Fib trie was always experimental and the output format was intended to
be tree like
but was broken. There are no known parsers of fib trie, and I think
Vyatta will probably
be the first distro to ship with it enabled.
> aside: how lame are we to put pretty-printers in the kernel?
> English-only ones, at that? Root cause: kernel developers still
> don't have a sufficiently easy way of shipping userspace tools.
Agreed, the structure of the trie doesn't come out via netlink (only the
addresses).
^ permalink raw reply
* RE: [PATCH] [TC U32] Fix input parsing to support more than 9 flow id'scorrectly
From: Waskiewicz Jr, Peter P @ 2008-02-13 3:03 UTC (permalink / raw)
To: stephen.hemminger; +Cc: netdev
In-Reply-To: <20080212193725.4137.62287.stgit@localhost.localdomain>
> From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
>
> Using strtoul with a base of 16 converts flowid 10 into 0x10,
> which makes it flowid 16. This is interpreted by the kernel
> incorrectly, and causes traffic flows above 9 to be
> classified into band 0 on multiband qdiscs.
> This changes the base to 10, which will correctly parse input
> into the proper hexidecimal value.
Stephen,
We can go one of two ways I suppose. Once is this way, since
most user input for CLASSID is base 10, or we can update documentation
to say that CLASSID input is expected to be base 16. What do you think?
Thanks,
-PJ Waskiewicz
peter.p.waskiewicz.jr@intel.com
>
> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> ---
>
> tc/tc_util.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tc/tc_util.c b/tc/tc_util.c index cdbae42..a277eac 100644
> --- a/tc/tc_util.c
> +++ b/tc/tc_util.c
> @@ -65,7 +65,7 @@ int get_tc_classid(__u32 *h, const char *str)
> maj = TC_H_UNSPEC;
> if (strcmp(str, "none") == 0)
> goto ok;
> - maj = strtoul(str, &p, 16);
> + maj = strtoul(str, &p, 10);
> if (p == str) {
> maj = 0;
> if (*p != ':')
> @@ -76,7 +76,7 @@ int get_tc_classid(__u32 *h, const char *str)
> return -1;
> maj <<= 16;
> str = p+1;
> - min = strtoul(str, &p, 16);
> + min = strtoul(str, &p, 10);
> if (*p != 0)
> return -1;
> if (min >= (1<<16))
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> netdev" in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] e1000e: Fix CRC stripping in hardware context bug
From: Andy Gospodarek @ 2008-02-13 2:33 UTC (permalink / raw)
To: Auke Kok; +Cc: jeff, netdev, johan.andersson, andy, e1000-devel
In-Reply-To: <20080212232024.13842.10804.stgit@localhost.localdomain>
On Tue, Feb 12, 2008 at 03:20:24PM -0800, Auke Kok wrote:
> CRC stripping was only correctly enabled for packet split recieves
> which is used when receiving jumbo frames. Correctly enable SECRC
> also for normal buffer packet receives.
>
> Tested by Andy Gospodarek and Johan Andersson, see bugzilla #9940.
>
This works well on my systems.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
^ permalink raw reply
* [PATCH] [TC U32] Fix input parsing to support more than 9 flow id's correctly
From: PJ Waskiewicz @ 2008-02-12 19:37 UTC (permalink / raw)
To: stephen.hemminger; +Cc: netdev
From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
Using strtoul with a base of 16 converts flowid 10 into 0x10, which makes
it flowid 16. This is interpreted by the kernel incorrectly, and causes
traffic flows above 9 to be classified into band 0 on multiband qdiscs.
This changes the base to 10, which will correctly parse input into the
proper hexidecimal value.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
---
tc/tc_util.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tc/tc_util.c b/tc/tc_util.c
index cdbae42..a277eac 100644
--- a/tc/tc_util.c
+++ b/tc/tc_util.c
@@ -65,7 +65,7 @@ int get_tc_classid(__u32 *h, const char *str)
maj = TC_H_UNSPEC;
if (strcmp(str, "none") == 0)
goto ok;
- maj = strtoul(str, &p, 16);
+ maj = strtoul(str, &p, 10);
if (p == str) {
maj = 0;
if (*p != ':')
@@ -76,7 +76,7 @@ int get_tc_classid(__u32 *h, const char *str)
return -1;
maj <<= 16;
str = p+1;
- min = strtoul(str, &p, 16);
+ min = strtoul(str, &p, 10);
if (*p != 0)
return -1;
if (min >= (1<<16))
^ permalink raw reply related
* Re: [PATCH 2/4] fib_trie: improve output format for /proc/net/fib_trie
From: Andrew Morton @ 2008-02-13 2:28 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: linux-kernel, netdev
In-Reply-To: <20080213005122.727447010@vyatta.com>
On Tue, 12 Feb 2008 16:50:44 -0800 Stephen Hemminger <shemminger@vyatta.com> wrote:
> Make output format prettier (more tree like).
>
> <local>:
> --- 0.0.0.0/0
> |--- 10.111.111.0/24
> | +-- 10.111.111.0/32 link broadcast
> | |--- 10.111.111.254/31
> | | +-- 10.111.111.254/32 host local
> | | +-- 10.111.111.255/32 link broadcast
> |--- 127.0.0.0/8
> | |--- 127.0.0.0/31
> | | +-- 127.0.0.0/32 link broadcast
> | | +-- 127.0.0.0/8 host local
> | | +-- 127.0.0.1/32 host local
> | +-- 127.255.255.255/32 link broadcast
> |--- 192.168.1.0/24
> | |--- 192.168.1.0/28
> | | +-- 192.168.1.0/32 link broadcast
> | | +-- 192.168.1.9/32 host local
> | +-- 192.168.1.255/32 link broadcast
> <main>:
> --- 0.0.0.0/0
> |--- 0.0.0.0/4
> | +-- 0.0.0.0/0 universe unicast
> | +-- 10.111.111.0/24 link unicast
> +-- 169.254.0.0/16 link unicast
> +-- 192.168.1.0/24 link unicast
isn't that a non-back-compatible kernel ABI change? It might
break pre-existing parsers?
aside: how lame are we to put pretty-printers in the kernel?
English-only ones, at that? Root cause: kernel developers still
don't have a sufficiently easy way of shipping userspace tools.
^ permalink raw reply
* Re: [PATCH] [IRDA] irda_init() nuke useless debug printk
From: David Miller @ 2008-02-13 2:17 UTC (permalink / raw)
To: max; +Cc: netdev
In-Reply-To: <1202812247-6878-1-git-send-email-max@stro.at>
From: maximilian attems <max@stro.at>
Date: Tue, 12 Feb 2008 11:30:47 +0100
> irda_init()
> dmesg line is not really informative, thus remove it.
> There are better ways to know that a module is loaded.
>
> Seen on a debian config with IRDA_DEBUG enabled.
>
> Signed-off-by: maximilian attems <max@stro.at>
Well if you look at how IRDA_DEBUG is predominantly used,
it's a function tracer, and that's exactly how it's being
used here.
Either we decide that this is OK and leave it there, or
we start moving the whole IRDA tree over to not do this.
Not something in between.
^ permalink raw reply
* Re: [Bug 9750] [patch 2.6.25] dev: avoid a race that triggers assertion failure
From: David Miller @ 2008-02-13 2:16 UTC (permalink / raw)
To: mattilinnanvuori; +Cc: jgarzik, netdev, bugme-daemon
In-Reply-To: <190693.34289.qm@web52005.mail.re2.yahoo.com>
From: Matti Linnanvuori <mattilinnanvuori@yahoo.com>
Date: Tue, 12 Feb 2008 02:45:22 -0800 (PST)
> From: Matti Linnanvuori <mattilinnanvuori@yahoo.com>
>
> There is a race in Linux kernel file net/core/dev.c, function dev_close.
> The function calls function dev_deactivate, which calls function
> dev_watchdog_down that deletes the watchdog timer. However, after that, a
> driver can call netif_carrier_ok, which calls function
> __netdev_watchdog_up that can add the watchdog timer again. Function
> unregister_netdevice calls function dev_shutdown that traps the bug
> !timer_pending(&dev->watchdog_timer). Moving dev_deactivate after
> netif_running() has been cleared prevents function netif_carrier_on
> from calling __netdev_watchdog_up and adding the watchdog timer again.
>
> Signed-off-by: Matti Linnanvuori <mattilinnanvuori@yahoo.com>
Your patch won't apply because it has been whitespace damanged
by your email client.
This is what I let you know last time you posted this patch.
Please fix this up so that your patch can be applied.
Thanks.
^ permalink raw reply
* Re: [IPV6]: Fix IPsec datagram fragmentation
From: David Miller @ 2008-02-13 2:08 UTC (permalink / raw)
To: herbert; +Cc: yoshfuji, netdev, dlstevens, kazunori
In-Reply-To: <20080213000437.GA19976@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 13 Feb 2008 11:04:37 +1100
> [IPV6]: Fix IPsec datagram fragmentation
>
> This is a long-standing bug in the IPsec IPv6 code that breaks
> when we emit a IPsec tunnel-mode datagram packet. The problem
> is that the code the emits the packet assumes the IPv6 stack
> will fragment it later, but the IPv6 stack assumes that whoever
> is emitting the packet is going to pre-fragment the packet.
>
> In the long term we need to fix both sides, e.g., to get the
> datagram code to pre-fragment as well as to get the IPv6 stack
> to fragment locally generated tunnel-mode packet.
>
> For now this patch does the second part which should make it
> work for the IPsec host case.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, and I'll queue this up to -stable as well.
Thanks!
^ permalink raw reply
* Re: [ofa-general] [PATCH 2.6.25] RDMA/cxgb3: Fail loopback connections.
From: Steve Wise @ 2008-02-13 1:41 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev, linux-kernel, general
In-Reply-To: <adafxvxvgz3.fsf@cisco.com>
Roland Dreier wrote:
> applied, although:
>
> > +static void is_loopback_dst(struct iw_cm_id *cm_id)
> > +{
> > + struct net_device *dev;
> > +
> > + dev = ip_dev_find(&init_net, cm_id->remote_addr.sin_addr.s_addr);
> > + if (!dev)
> > + return 0;
> > + dev_put(dev);
> > + return 1;
> > +}
>
> is there any way this could trigger when it should, like if I'm trying
> to make a connection from one local device to a different local device
> (which should work fine)?
>
As far as I can tell, if the app does a rdma_resolve_addr() on the dst
addr (which is a local address), then the routing lookup will find the
local interface with that dst addr, and that device will be used for the
connect. IE src and dst devices are the same.
Maybe if the app does an explicit bind to the addr on one device, then
connects to the addr on the other device. But that's not gonna work
either, I think. I still think it will resolve to one device and that
device cannot do loopback...
Steve.
^ permalink raw reply
* [PATCH BUGFIX 25-rc1] Smack: Don't fail against Nulled sk sockets
From: Ahmed S. Darwish @ 2008-02-13 1:25 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: Casey Schaufler, Joerg Platte, LKML, Netdev
Hi!,
Appropriately handle sockets with sk = NULL. This is usually the socket
case when starting kernel nfsd.
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
Acked-by: Casey Schaufler <casey@schuafler-ca.com>
Tested-by: Joerg Platte <jplatte@naasa.net>
--
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 1c11e42..eb04278 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -701,7 +701,7 @@ static int smack_inode_getsecurity(const struct inode *inode,
return -EOPNOTSUPP;
sock = SOCKET_I(ip);
- if (sock == NULL)
+ if (sock == NULL || sock->sk == NULL)
return -EOPNOTSUPP;
ssp = sock->sk->sk_security;
@@ -1280,10 +1280,12 @@ static void smack_to_secattr(char *smack, struct netlbl_lsm_secattr *nlsp)
*/
static int smack_netlabel(struct sock *sk)
{
- struct socket_smack *ssp = sk->sk_security;
+ struct socket_smack *ssp;
struct netlbl_lsm_secattr secattr;
int rc = 0;
+ BUG_ON(sk == NULL);
+ ssp = sk->sk_security;
netlbl_secattr_init(&secattr);
smack_to_secattr(ssp->smk_out, &secattr);
if (secattr.flags != NETLBL_SECATTR_NONE)
@@ -1331,7 +1333,7 @@ static int smack_inode_setsecurity(struct inode *inode, const char *name,
return -EOPNOTSUPP;
sock = SOCKET_I(inode);
- if (sock == NULL)
+ if (sock == NULL || sock->sk == NULL)
return -EOPNOTSUPP;
ssp = sock->sk->sk_security;
@@ -1362,7 +1364,7 @@ static int smack_inode_setsecurity(struct inode *inode, const char *name,
static int smack_socket_post_create(struct socket *sock, int family,
int type, int protocol, int kern)
{
- if (family != PF_INET)
+ if (family != PF_INET || sock->sk == NULL)
return 0;
/*
* Set the outbound netlbl.
Warm regards
--
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com
^ 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