* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Michael Tokarev @ 2011-03-02 7:15 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, arnd, mirqus, netdev, Ben Hutchings, David Miller,
kuznet, pekkas, jmorris, yoshfuji, kaber, eric.dumazet, therbert,
xiaosuo, jesse, kees.cook, eugene, dan.j.rosenberg, akpm
In-Reply-To: <20110301213313.GA6507@albatros>
02.03.2011 00:33, Vasiliy Kulikov wrote:
> Since a8f80e8ff94ecba629542d9b4b5f5a8ee3eb565c any process with
> CAP_NET_ADMIN may load any module from /lib/modules/. This doesn't mean
> that CAP_NET_ADMIN is a superset of CAP_SYS_MODULE as modules are
> limited to /lib/modules/**. However, CAP_NET_ADMIN capability shouldn't
> allow anybody load any module not related to networking.
>
> This patch restricts an ability of autoloading modules to netdev modules
> with explicit aliases. This fixes CVE-2011-1019.
[]
> Reference: https://lkml.org/lkml/2011/2/24/203
>
> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
This looks much saner :)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
/mjt
^ permalink raw reply
* Re: [PATCH 1/2] tlan: Remove changelog
From: Sakari Ailus @ 2011-03-02 7:13 UTC (permalink / raw)
To: Joe Perches; +Cc: Samuel Chessman, netdev, linux-kernel
In-Reply-To: <901ce76108a5ab7327159b57a1b8c9283673532b.1298998514.git.joe@perches.com>
Joe Perches wrote:
> As it isn't necessary nor really useful any longer.
>
> Signed-off-by: Joe Perches<joe@perches.com>
Thanks, Joe!
I had your patches still but have had practically no time since you sent
your last set. So, for both:
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
--
Sakari Ailus
sakari.ailus@iki.fi
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Tom Herbert @ 2011-03-02 7:12 UTC (permalink / raw)
To: Herbert Xu
Cc: Eric Dumazet, Thomas Graf, David Miller, rick.jones2, wsommerfeld,
daniel.baluta, netdev
In-Reply-To: <20110302023920.GA16072@gondor.apana.org.au>
On Tue, Mar 1, 2011 at 6:39 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Mar 02, 2011 at 03:00:03AM +0100, Eric Dumazet wrote:
>> >
>> > Think about it, a TCP socket cannot be used by a multi-threaded app
>> > in a scalable way.
>>
>> Well...
>>
>> If you think about it, SO_REUSEPORT patch has exactly the same goal :
>
In a sense. SO_RESUSEPORT for TCP is intended to provide a scalable
listener solution. Sharing an established socket is not very
efficient, something like a multiplexing socket layer on top of TCP
might be good.
> UDP is a datagram protocol, TCP is not.
>
> Anyway, here is an alternate proposal. When a TCP socket transmits
> for the first time (SYN or SYN-ACK), we pick a queue based on CPU and
> store it in the socket. From then on we stick to that selection.
>
> We would only allow changes if we can ensure that all transmitted
> packets have left the queue. Or we just never change it like we
> do now.
>
XPS does all this already.
> For datagram protocols we simply use the current CPU.
>
Probably need to set skb->ooo_okay (for UDP etc.) also so that XPS
will change queues.
Tom
^ permalink raw reply
* Re: net-next: warnings from sysctl_net_exit
From: Stephen Hemminger @ 2011-03-02 7:09 UTC (permalink / raw)
To: Lucian Adrian Grijincu; +Cc: David S. Miller, netdev
In-Reply-To: <AANLkTinL3UhjOtmr3uyEkSiDT5NFJo=FbG5mKm3XaU8R@mail.gmail.com>
On Mon, 28 Feb 2011 03:11:46 +0200
Lucian Adrian Grijincu <lucian.grijincu@gmail.com> wrote:
> On Mon, Feb 28, 2011 at 2:08 AM, Stephen Hemminger
> <shemminger@vyatta.com> wrote:
> >> The check is triggered at network namespace deletion, so a moment
> >> before deleting the netns should be fine.
> >
> > Although the kernel was compiled with netns, I never use net namespaces.
>
>
> This can be triggered at shutdown when the init_net network namespace
> is dismantled.
>
> Are you getting this at shutdown time? If not, is it easily reproducible?
> Can you post a .config?
>
It seems to happen right after ip6tables starts at boot.
I added more backtrace info to walk the list of remaining entries,
and got this but it doesn't help much.
[ 59.700687] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 60.413111] header=ffff8803239db000 count=1 used=0 unregistering= (null)
[ 60.413113] procname=net
[ 60.413115] ------------[ cut here ]------------
[ 60.413119] WARNING: at net/sysctl_net.c:98 sysctl_net_exit+0x94/0x9d()
[ 60.413121] Hardware name: System Product Name
[ 60.413122] Modules linked in: ip6table_filter ip6_tables nfs lockd fscache nfs_acl auth_rpcgss sunrpc binfmt_misc ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc kvm_intel kvm snd_hda_codec_analog lm63 radeon snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq ttm psmouse snd_timer drm_kms_helper serio_raw snd_seq_device pl2303 usbserial snd drm soundcore i7core_edac snd_page_alloc edac_core asus_atk0110 i2c_algo_bit hid_belkin usbhid hid pata_marvell ahci sky2 libahci igb e1000e dca floppy btrfs lzo_compress zlib_deflate crc32c libcrc32c
[ 60.413170] Pid: 67, comm: kworker/u:5 Not tainted 2.6.38-rc5-net-next+ #19
[ 60.413171] Call Trace:
[ 60.413176] [<ffffffff81040dce>] ? warn_slowpath_common+0x85/0x9d
[ 60.413180] [<ffffffff8136183a>] ? cleanup_net+0x0/0x19a
[ 60.413182] [<ffffffff81040e00>] ? warn_slowpath_null+0x1a/0x1c
[ 60.413184] [<ffffffff81414ebb>] ? sysctl_net_exit+0x94/0x9d
[ 60.413187] [<ffffffff81361492>] ? ops_exit_list+0x2a/0x5b
[ 60.413189] [<ffffffff81361934>] ? cleanup_net+0xfa/0x19a
[ 60.413193] [<ffffffff810575bd>] ? process_one_work+0x233/0x3aa
[ 60.413196] [<ffffffff81057524>] ? process_one_work+0x19a/0x3aa
[ 60.413199] [<ffffffff810599be>] ? worker_thread+0x13b/0x25a
[ 60.413201] [<ffffffff81059883>] ? worker_thread+0x0/0x25a
[ 60.413204] [<ffffffff8105d0f1>] ? kthread+0x9d/0xa5
[ 60.413207] [<ffffffff8106d614>] ? trace_hardirqs_on_caller+0x10c/0x130
[ 60.413210] [<ffffffff810030d4>] ? kernel_thread_helper+0x4/0x10
[ 60.413215] [<ffffffff8142ed40>] ? restore_args+0x0/0x30
[ 60.413217] [<ffffffff8105d054>] ? kthread+0x0/0xa5
[ 60.413219] [<ffffffff810030d0>] ? kernel_thread_helper+0x0/0x10
[ 60.413221] ---[ end trace 9b655d61bf30c4f8 ]---
^ permalink raw reply
* Re: txqueuelen has wrong units; should be time
From: Stephen Hemminger @ 2011-03-02 7:07 UTC (permalink / raw)
To: Mikael Abrahamsson
Cc: John Heffner, Bill Sommerfeld, Hagen Paul Pfeifer, Albert Cahalan,
Jussi Kivilinna, Eric Dumazet, linux-kernel, netdev
In-Reply-To: <alpine.DEB.1.10.1103020736260.7942@uplift.swm.pp.se>
On Wed, 2 Mar 2011 07:41:30 +0100 (CET)
Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Tue, 1 Mar 2011, Stephen Hemminger wrote:
>
> > It is possible to build an equivalent to WRED out existing GRED queuing
> > discipline but it does require a lot of tc knowledge to get right.
>
> To me who has worked with cisco routers for 10+ years and who is used to
> the different variants Cisco use, tc is just weird. It must come from a
> completely different school of thinking compared to what router people are
> used to, because I have tried and failed twice to do anything sensible
> with it.
Vyatta has scripting that handles all that:
vyatta@napa:~$ configure
[edit]
yatta@napa# set traffic-policy random-detect MyWFQ bandwidth 1gbps
[edit]
vyatta@napa# set interfaces ethernet eth0 traffic-policy out MyWFQ
[edit]
vyatta@napa# commit
[edit]
vyatta@napa# exit
vyatta@napa:~$ show queueing ethernet eth0
eth0 Queueing:
Class Policy Sent Rate Dropped Overlimit Backlog
root weighted-random 16550 0 0 0
vyatta@napa:~$ /sbin/tc qdisc show dev eth0
qdisc dsmark 1: root refcnt 2 indices 0x0008 set_tc_index
qdisc gred 2: parent 1:
DP:0 (prio 8) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 82 (bytes 9540) ewma 3 Plog 17 Scell_log 3
DP:1 (prio 7) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0) ewma 2 Plog 17 Scell_log 2
DP:2 (prio 6) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0) ewma 2 Plog 17 Scell_log 2
DP:3 (prio 5) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0) ewma 2 Plog 16 Scell_log 2
DP:4 (prio 4) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0) ewma 2 Plog 16 Scell_log 2
DP:5 (prio 3) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0) ewma 2 Plog 16 Scell_log 2
DP:6 (prio 2) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0) ewma 2 Plog 15 Scell_log 2
DP:7 (prio 1) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0) ewma 1 Plog 15 Scell_log 1
QoS on Cisco has different/other problems mostly because various groups
tried to fix the QoS problem over time and never got it quite right.
Also WRED is not default on faster links because it can't be done
fast enough.
^ permalink raw reply
* Re: [PATCH] ipv6: Make icmp route lookup code a bit clearer.
From: Herbert Xu @ 2011-03-02 7:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110301.221543.226770795.davem@davemloft.net>
On Tue, Mar 01, 2011 at 10:15:43PM -0800, David Miller wrote:
>
> The route lookup code in icmpv6_send() is slightly tricky as a result of
> having to handle all of the requirements of RFC 4301 host relookups.
>
> Pull the route resolution into a seperate function, so that the error
> handling and route reference counting is hopefully easier to see and
> contained wholly within this new routine.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Looks good to me too.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Bug-Fix][Patch 1/1] dccp: fix oops on Reset after close
From: David Miller @ 2011-03-02 7:02 UTC (permalink / raw)
To: gerrit; +Cc: netdev, jhovold
In-Reply-To: <20110302063447.GB4902@gerrit.erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Wed, 2 Mar 2011 07:34:47 +0100
> could you please apply the below bug fix for a condition where a simple packet
> reception can trigger oops.
Applied, thanks Gerrit.
^ permalink raw reply
* Re: inet: Replace left-over references to inet->cork
From: David Miller @ 2011-03-02 7:01 UTC (permalink / raw)
To: herbert; +Cc: rick.jones2, therbert, wsommerfeld, daniel.baluta, netdev, tgraf
In-Reply-To: <20110302061517.GA17891@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 2 Mar 2011 14:15:17 +0800
> On Tue, Mar 01, 2011 at 08:36:47PM +0800, Herbert Xu wrote:
>> inet: Remove explicit write references to sk/inet in ip_append_data
>
> Just found a couple of spots where inet->cork was still used
> instead of just cork.
>
> inet: Replace left-over references to inet->cork
Applied, thanks Herbert.
^ permalink raw reply
* Re: [PATCH net-next] pfkey: fix warning
From: David Miller @ 2011-03-02 6:52 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20110301223913.2caf53c3@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 1 Mar 2011 22:39:13 -0800
> If CONFIG_NET_KEY_MIGRATE is not defined the arguments of
> pfkey_migrate stub do not match causing warning.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks!
^ permalink raw reply
* Re: txqueuelen has wrong units; should be time
From: Mikael Abrahamsson @ 2011-03-02 6:41 UTC (permalink / raw)
To: Stephen Hemminger
Cc: John Heffner, Bill Sommerfeld, Hagen Paul Pfeifer, Albert Cahalan,
Jussi Kivilinna, Eric Dumazet, linux-kernel, netdev
In-Reply-To: <20110301222531.24832a93@nehalam>
On Tue, 1 Mar 2011, Stephen Hemminger wrote:
> It is possible to build an equivalent to WRED out existing GRED queuing
> discipline but it does require a lot of tc knowledge to get right.
To me who has worked with cisco routers for 10+ years and who is used to
the different variants Cisco use, tc is just weird. It must come from a
completely different school of thinking compared to what router people are
used to, because I have tried and failed twice to do anything sensible
with it.
> The inventor of RED (Van Jacobsen) has issues with WRED because of the
> added complexity of queue selection. RED requires some parameters which
> the average user has no idea how to set.
Of course there are issues and some of them can be adressed by simply
lowering the queue depth. Yes, that might bring down the performance of
some sessions, but for most of the interactive traffic, never buffering
more than 40ms is a good thing.
> There are several problems with RED that prevent prevent VJ from
> recommending it in the current form.
Ask if he prefers FIFO+tail drop to RED in current form.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* [PATCH net-next] pfkey: fix warning
From: Stephen Hemminger @ 2011-03-02 6:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev
If CONFIG_NET_KEY_MIGRATE is not defined the arguments of
pfkey_migrate stub do not match causing warning.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/key/af_key.c 2011-03-01 22:32:30.608511083 -0800
+++ b/net/key/af_key.c 2011-03-01 22:33:55.703791987 -0800
@@ -2560,7 +2560,7 @@ static int pfkey_migrate(struct sock *sk
}
#else
static int pfkey_migrate(struct sock *sk, struct sk_buff *skb,
- struct sadb_msg *hdr, void **ext_hdrs)
+ const struct sadb_msg *hdr, void * const *ext_hdrs)
{
return -ENOPROTOOPT;
}
^ permalink raw reply
* [Bug-Fix][Patch 1/1] dccp: fix oops on Reset after close
From: Gerrit Renker @ 2011-03-02 6:34 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Johan Hovold
Dave,
could you please apply the below bug fix for a condition where a simple packet
reception can trigger oops.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Patch <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
dccp: fix oops on Reset after close
This fixes a bug in the order of dccp_rcv_state_process() that still permitted
reception even after closing the socket. A Reset after close thus causes a NULL
pointer dereference by not preventing operations on an already torn-down socket.
dccp_v4_do_rcv()
|
| state other than OPEN
v
dccp_rcv_state_process()
|
| DCCP_PKT_RESET
v
dccp_rcv_reset()
|
v
dccp_time_wait()
WARNING: at net/ipv4/inet_timewait_sock.c:141 __inet_twsk_hashdance+0x48/0x128()
Modules linked in: arc4 ecb carl9170 rt2870sta(C) mac80211 r8712u(C) crc_ccitt ah
[<c0038850>] (unwind_backtrace+0x0/0xec) from [<c0055364>] (warn_slowpath_common)
[<c0055364>] (warn_slowpath_common+0x4c/0x64) from [<c0055398>] (warn_slowpath_n)
[<c0055398>] (warn_slowpath_null+0x1c/0x24) from [<c02b72d0>] (__inet_twsk_hashd)
[<c02b72d0>] (__inet_twsk_hashdance+0x48/0x128) from [<c031caa0>] (dccp_time_wai)
[<c031caa0>] (dccp_time_wait+0x40/0xc8) from [<c031c15c>] (dccp_rcv_state_proces)
[<c031c15c>] (dccp_rcv_state_process+0x120/0x538) from [<c032609c>] (dccp_v4_do_)
[<c032609c>] (dccp_v4_do_rcv+0x11c/0x14c) from [<c0286594>] (release_sock+0xac/0)
[<c0286594>] (release_sock+0xac/0x110) from [<c031fd34>] (dccp_close+0x28c/0x380)
[<c031fd34>] (dccp_close+0x28c/0x380) from [<c02d9a78>] (inet_release+0x64/0x70)
The fix is by testing the socket state first. Receiving a packet in Closed state
now also produces the required "No connection" Reset reply of RFC 4340, 8.3.1.
Reported-and-tested-by: Johan Hovold <jhovold@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/input.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -614,6 +614,9 @@ int dccp_rcv_state_process(struct sock *
/* Caller (dccp_v4_do_rcv) will send Reset */
dcb->dccpd_reset_code = DCCP_RESET_CODE_NO_CONNECTION;
return 1;
+ } else if (sk->sk_state == DCCP_CLOSED) {
+ dcb->dccpd_reset_code = DCCP_RESET_CODE_NO_CONNECTION;
+ return 1;
}
if (sk->sk_state != DCCP_REQUESTING && sk->sk_state != DCCP_RESPOND) {
@@ -668,10 +671,6 @@ int dccp_rcv_state_process(struct sock *
}
switch (sk->sk_state) {
- case DCCP_CLOSED:
- dcb->dccpd_reset_code = DCCP_RESET_CODE_NO_CONNECTION;
- return 1;
-
case DCCP_REQUESTING:
queued = dccp_rcv_request_sent_state_process(sk, skb, dh, len);
if (queued >= 0)
^ permalink raw reply
* Re: txqueuelen has wrong units; should be time
From: Stephen Hemminger @ 2011-03-02 6:25 UTC (permalink / raw)
To: Mikael Abrahamsson
Cc: John Heffner, Bill Sommerfeld, Hagen Paul Pfeifer, Albert Cahalan,
Jussi Kivilinna, Eric Dumazet, linux-kernel, netdev
In-Reply-To: <alpine.DEB.1.10.1103010137400.7942@uplift.swm.pp.se>
On Tue, 1 Mar 2011 01:46:51 +0100 (CET)
Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Mon, 28 Feb 2011, John Heffner wrote:
>
> > Right... while I generally agree that a fixed-length drop-tail queue
> > isn't optimal, isn't this problem what the various AQM schemes try to
> > solve?
>
> I am not an expert on exactly how Linux does this, but for Cisco and for
> instance ATM interfaces, there are two stages of queuing. One is the
> "hardware queue", which is a FIFO queue going into the ATM framer. If one
> wants low CPU usage, then this needs to be high so multiple packets can be
> put there per interrupt. Since AQM is working before this, it also means
> the low-latency-queue will have a higher latency as it ends up behind
> larger packets in the hw queue.
>
> So on what level does the AQM work in Linux? Does it work similarily, that
> txqueuelen is a FIFO queue to the hardware that AQM feeds packets into?
>
> Also, when one uses WRED the thinking is generally to keep the average
> queue len down, but still allow for bursts by dynamically changing the
> drop probability and where it happens. When there is no queuing, allow for
> big queue (so it can fill up if needed), but if the queue is large for
> several seconds, start to apply WRED to bring it down.
>
> There is generally no need at all to constantly buffer > 50 ms of data,
> then it's better to just start selectively dropping it. In time of
> burstyness (perhaps when re-routing traffic) there is need to buffer
> 200-500ms of during perhaps 1-2 seconds before things stabilize.
>
> So one queuing scheme and one queue limit isn't going to solve this, there
> need to be some dynamic built into the system for it to work well.
>
> AQM needs to feed into a relatively short hw queue and AQM needs to exist
> on output also when the traffic is sourced from the box itself, no tonly
> routed. It would also help if the default would be to use let's say 25% of
> the bandwidth for smaller packets (< 200 bytes or so) which generally are
> for interactive uses or are ACKs.
>
It is possible to build an equivalent to WRED out existing GRED queuing
discipline but it does require a lot of tc knowledge to get right.
The inventor of RED (Van Jacobsen) has issues with WRED because of
the added complexity of queue selection. RED requires some parameters
which the average user has no idea how to set.
There are several problems with RED that prevent prevent VJ from
recommending it in the current form.
http://gettys.wordpress.com/2010/12/17/red-in-a-different-light/
--
^ permalink raw reply
* inet: Replace left-over references to inet->cork
From: Herbert Xu @ 2011-03-02 6:15 UTC (permalink / raw)
To: David Miller, rick.jones2, therbert, wsommerfeld, daniel.baluta,
netdev, Thomas Graf
In-Reply-To: <E1PuOop-0001xh-HK@gondolin.me.apana.org.au>
On Tue, Mar 01, 2011 at 08:36:47PM +0800, Herbert Xu wrote:
> inet: Remove explicit write references to sk/inet in ip_append_data
Just found a couple of spots where inet->cork was still used
instead of just cork.
inet: Replace left-over references to inet->cork
The patch to replace inet->cork with cork left out two spots in
__ip_append_data that can result in bogus packet construction.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 460308c..3e8637c 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -789,7 +789,7 @@ static int __ip_append_data(struct sock *sk, struct sk_buff_head *queue,
struct inet_sock *inet = inet_sk(sk);
struct sk_buff *skb;
- struct ip_options *opt = inet->cork.opt;
+ struct ip_options *opt = cork->opt;
int hh_len;
int exthdrlen;
int mtu;
@@ -803,7 +803,7 @@ static int __ip_append_data(struct sock *sk, struct sk_buff_head *queue,
exthdrlen = transhdrlen ? rt->dst.header_len : 0;
length += exthdrlen;
transhdrlen += exthdrlen;
- mtu = inet->cork.fragsize;
+ mtu = cork->fragsize;
hh_len = LL_RESERVED_SPACE(rt->dst.dev);
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* [PATCH] ipv6: Make icmp route lookup code a bit clearer.
From: David Miller @ 2011-03-02 6:15 UTC (permalink / raw)
To: netdev; +Cc: herbert
The route lookup code in icmpv6_send() is slightly tricky as a result of
having to handle all of the requirements of RFC 4301 host relookups.
Pull the route resolution into a seperate function, so that the error
handling and route reference counting is hopefully easier to see and
contained wholly within this new routine.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv6/icmp.c | 117 +++++++++++++++++++++++++++++++------------------------
1 files changed, 66 insertions(+), 51 deletions(-)
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index a31d91b..e332bae 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -300,6 +300,70 @@ static void mip6_addr_swap(struct sk_buff *skb)
static inline void mip6_addr_swap(struct sk_buff *skb) {}
#endif
+static struct dst_entry *icmpv6_route_lookup(struct net *net, struct sk_buff *skb,
+ struct sock *sk, struct flowi *fl)
+{
+ struct dst_entry *dst, *dst2;
+ struct flowi fl2;
+ int err;
+
+ err = ip6_dst_lookup(sk, &dst, fl);
+ if (err)
+ return ERR_PTR(err);
+
+ /*
+ * We won't send icmp if the destination is known
+ * anycast.
+ */
+ if (((struct rt6_info *)dst)->rt6i_flags & RTF_ANYCAST) {
+ LIMIT_NETDEBUG(KERN_DEBUG "icmpv6_send: acast source\n");
+ dst_release(dst);
+ return ERR_PTR(-EINVAL);
+ }
+
+ /* No need to clone since we're just using its address. */
+ dst2 = dst;
+
+ err = xfrm_lookup(net, &dst, fl, sk, 0);
+ switch (err) {
+ case 0:
+ if (dst != dst2)
+ return dst;
+ break;
+ case -EPERM:
+ dst = NULL;
+ break;
+ default:
+ return ERR_PTR(err);
+ }
+
+ err = xfrm_decode_session_reverse(skb, &fl2, AF_INET6);
+ if (err)
+ goto relookup_failed;
+
+ err = ip6_dst_lookup(sk, &dst2, &fl2);
+ if (err)
+ goto relookup_failed;
+
+ err = xfrm_lookup(net, &dst2, &fl2, sk, XFRM_LOOKUP_ICMP);
+ switch (err) {
+ case 0:
+ dst_release(dst);
+ dst = dst2;
+ break;
+ case -EPERM:
+ dst_release(dst);
+ return ERR_PTR(err);
+ default:
+ goto relookup_failed;
+ }
+
+relookup_failed:
+ if (dst)
+ return dst;
+ return ERR_PTR(err);
+}
+
/*
* Send an ICMP message in response to a packet in error
*/
@@ -312,10 +376,8 @@ void icmpv6_send(struct sk_buff *skb, u8 type, u8 code, __u32 info)
struct ipv6_pinfo *np;
struct in6_addr *saddr = NULL;
struct dst_entry *dst;
- struct dst_entry *dst2;
struct icmp6hdr tmp_hdr;
struct flowi fl;
- struct flowi fl2;
struct icmpv6_msg msg;
int iif = 0;
int addr_type = 0;
@@ -408,57 +470,10 @@ void icmpv6_send(struct sk_buff *skb, u8 type, u8 code, __u32 info)
if (!fl.oif && ipv6_addr_is_multicast(&fl.fl6_dst))
fl.oif = np->mcast_oif;
- err = ip6_dst_lookup(sk, &dst, &fl);
- if (err)
- goto out;
-
- /*
- * We won't send icmp if the destination is known
- * anycast.
- */
- if (((struct rt6_info *)dst)->rt6i_flags & RTF_ANYCAST) {
- LIMIT_NETDEBUG(KERN_DEBUG "icmpv6_send: acast source\n");
- goto out_dst_release;
- }
-
- /* No need to clone since we're just using its address. */
- dst2 = dst;
-
- err = xfrm_lookup(net, &dst, &fl, sk, 0);
- switch (err) {
- case 0:
- if (dst != dst2)
- goto route_done;
- break;
- case -EPERM:
- dst = NULL;
- break;
- default:
+ dst = icmpv6_route_lookup(net, skb, sk, &fl);
+ if (IS_ERR(dst))
goto out;
- }
-
- if (xfrm_decode_session_reverse(skb, &fl2, AF_INET6))
- goto relookup_failed;
-
- if (ip6_dst_lookup(sk, &dst2, &fl2))
- goto relookup_failed;
-
- err = xfrm_lookup(net, &dst2, &fl2, sk, XFRM_LOOKUP_ICMP);
- switch (err) {
- case 0:
- dst_release(dst);
- dst = dst2;
- break;
- case -EPERM:
- goto out_dst_release;
- default:
-relookup_failed:
- if (!dst)
- goto out;
- break;
- }
-route_done:
if (ipv6_addr_is_multicast(&fl.fl6_dst))
hlimit = np->mcast_hops;
else
--
1.7.4.1
^ permalink raw reply related
* fcoe: correct checking for bonding
From: Jiri Pirko @ 2011-03-02 6:05 UTC (permalink / raw)
To: linux-scsi; +Cc: devel, robert.w.love, netdev, fubar, joe.eykholt
Check for bonding master and refuse to use that.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/scsi/fcoe/fcoe.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
index 9f9600b..3becc6a 100644
--- a/drivers/scsi/fcoe/fcoe.c
+++ b/drivers/scsi/fcoe/fcoe.c
@@ -285,9 +285,7 @@ static int fcoe_interface_setup(struct fcoe_interface *fcoe,
}
/* Do not support for bonding device */
- if ((netdev->priv_flags & IFF_MASTER_ALB) ||
- (netdev->priv_flags & IFF_SLAVE_INACTIVE) ||
- (netdev->priv_flags & IFF_MASTER_8023AD)) {
+ if (netdev->priv_flags & IFF_BONDING && netdev->flags & IFF_MASTER) {
FCOE_NETDEV_DBG(netdev, "Bonded interfaces not supported\n");
return -EOPNOTSUPP;
}
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 0/7] Final BKL removal, take 2
From: Greg KH @ 2011-03-02 4:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, Andi Kleen, Andrew Hendry, Arnaldo Carvalho de Melo,
David Miller, Eric Dumazet, Evgeniy Dushistov, linux-fsdevel,
linux-x25, Mauro Carvalho Chehab, Max Vozeler, Mikulas Patocka,
netdev, Nick Bowler, Nick Piggin, Palash Bandyopadhyay,
Takahiro Hirofuchi
In-Reply-To: <1299021191-17961-1-git-send-email-arnd@arndb.de>
On Wed, Mar 02, 2011 at 12:13:04AM +0100, Arnd Bergmann wrote:
> This is the set of patches that remain from
> my previous submission one month ago. I've
> dropped the ones that have either gone into
> linux-next or got a sufficient number of
> Acked-by:s so I put them into my own tree.
>
> I've updated the usbip, hpfs, ufs and appletalk
> patches according to the feedback I got.
>
> If possible, I'd like the three networking patches
> to go through the net-next tree, and the two
> staging patches through the staging tree. I'll
> add the other ones to my own series if I hear
> no objections.
I'll queue up the staging patches in the staging-next tree in a day or
so, thanks for digging them up.
greg k-h
^ permalink raw reply
* Re: [PATCH] ipv4: Make icmp route lookup code a bit clearer.
From: David Miller @ 2011-03-02 4:53 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20110302004325.GB15009@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 2 Mar 2011 08:43:25 +0800
> Looks good to me.
Thanks for reviewing.
^ permalink raw reply
* Re: [PATCH] Fix possible null pointer dereference in ariadne.c
From: Huzaifa Sidhpurwala @ 2011-03-02 4:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev, geert, tj, eric.dumazet
In-Reply-To: <20110301.115300.112595321.davem@davemloft.net>
On 03/02/2011 01:23 AM, David Miller wrote:
> From: huzaifas@redhat.com
> Date: Tue, 1 Mar 2011 17:03:27 +0530
>
>> + *lance = (struct Am79C960*)dev->base_addr;
>
> If you had actually compiled this, the compiler would have given
> you a warning shoing that the leading "*" in "*lance" is not
> appropriate for this assignment.
i did build, but looks like something happened after that :(
Sorry about the mess-up , will repost the patch.
^ permalink raw reply
* Re: [PATCH 2/4] slub,rcu: don't assume the size of struct rcu_head
From: Hugh Dickins @ 2011-03-02 4:31 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Lai Jiangshan, Ingo Molnar, Paul E. McKenney,
Eric Dumazet, David S. Miller, Matt Mackall, linux-mm,
linux-kernel, netdev
In-Reply-To: <alpine.DEB.2.00.1103010909320.6253@router.home>
On Tue, Mar 1, 2011 at 7:11 AM, Christoph Lameter <cl@linux.com> wrote:
> On Tue, 1 Mar 2011, Pekka Enberg wrote:
>
> > The SLAB and SLUB patches are fine by me if there are going to be real
> > users for this. Christoph, Paul?
>
> The solution is a bit overkill. It would be much simpler to add a union to
> struct page that has lru and the rcu in there similar things can be done
> for SLAB and the network layer. A similar issue already exists for the
> spinlock in struct page. Lets follow the existing way of handling this.
>
> Struct page may be larger for debugging purposes already because of the
> need for extended spinlock data.
That was so for a long time, but I stopped it just over a year ago
with commit a70caa8ba48f21f46d3b4e71b6b8d14080bbd57a, stop ptlock
enlarging struct page.
Partly out of shame at how large struct page was growing when lockdep
is on, but also a subtle KSM reason which might apply here too: KSM
relies on the content of page->mapping to be kernel pointer to a
relevant structure, NULLed when the page is freed.
If a union leads to "random junk" overwriting the page->mapping field
when the page is reused, and that junk could resemble the pointer in
question, then KSM would mistakenly think it still owned the page.
Very remote chance, and maybe it amounts to no more than a leak. But
I'd still prefer we keep page->mapping for pointers (sometimes with
lower bits set as flags).
Hugh
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Eric Dumazet @ 2011-03-02 3:44 UTC (permalink / raw)
To: Herbert Xu
Cc: Thomas Graf, David Miller, rick.jones2, therbert, wsommerfeld,
daniel.baluta, netdev
In-Reply-To: <20110302030902.GA16416@gondor.apana.org.au>
Le mercredi 02 mars 2011 à 11:09 +0800, Herbert Xu a écrit :
> On Wed, Mar 02, 2011 at 03:56:38AM +0100, Eric Dumazet wrote:
> >
> > Anyway, the SYN-ACK is generated by softirq, not really user choice.
> > CPU depends if NIC is RX multiqueue or RPS is setup.
>
> Which is exactly what we want. The RX queue selection should
> determine the TX cpu.
>
This is working today with RFS/XPS. Or it should, indirectly.
OOO problem is handled as well.
^ permalink raw reply
* Re: [PATCH] sysctl: ipv6: use correct net in ipv6_sysctl_rtcache_flush
From: Shan Wei @ 2011-03-02 3:25 UTC (permalink / raw)
To: Lucian Adrian Grijincu
Cc: netdev, David S . Miller, Daniel Lezcano, Benjamin Thery
In-Reply-To: <1298612883-18762-1-git-send-email-lucian.grijincu@gmail.com>
Lucian Adrian Grijincu wrote, at 02/25/2011 01:48 PM:
> Before this patch issuing these commands:
>
> fd = open("/proc/sys/net/ipv6/route/flush")
> unshare(CLONE_NEWNET)
> write(fd, "stuff")
>
> would flush the newly created net, not the original one.
After appling your patch, when excuting above commands,
router cache still not be flushed in init net namespace.
But IPv4 is ok.
Host1: Host2
ping6 Host2
(shell1)
open(/proc/sys/net/ipv6/route/flush)
unshare(CLONE_NEWNET)
while(1) {write(fd, "stuff")}
(shell2)
ip -6 route show cache <==1*
1*: IPv6 will show one route cache entry.
But IPv4 shows nothing.
As changlog said, after this patch, shell1 only fulsh the original
net namespace, not the newly created one. But from shell2, we
can see that IPv6 route cache is not flushed.
Have i missed something?
--
Best Regards
-----
Shan Wei
>
> The equivalent ipv4 code is correct (stores the net inside ->extra1).
> ---
> net/ipv6/route.c | 17 ++++++++++-------
> 1 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index f786aed..522563e 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -2604,14 +2604,16 @@ static
> int ipv6_sysctl_rtcache_flush(ctl_table *ctl, int write,
> void __user *buffer, size_t *lenp, loff_t *ppos)
> {
> - struct net *net = current->nsproxy->net_ns;
> - int delay = net->ipv6.sysctl.flush_delay;
> - if (write) {
> - proc_dointvec(ctl, write, buffer, lenp, ppos);
> - fib6_run_gc(delay <= 0 ? ~0UL : (unsigned long)delay, net);
> - return 0;
> - } else
> + struct net *net;
> + int delay;
> + if (!write)
> return -EINVAL;
> +
> + net = (struct net *)ctl->extra1;
> + delay = net->ipv6.sysctl.flush_delay;
> + proc_dointvec(ctl, write, buffer, lenp, ppos);
> + fib6_run_gc(delay <= 0 ? ~0UL : (unsigned long)delay, net);
> + return 0;
> }
>
> ctl_table ipv6_route_table_template[] = {
> @@ -2698,6 +2700,7 @@ struct ctl_table * __net_init ipv6_route_sysctl_init(struct net *net)
>
> if (table) {
> table[0].data = &net->ipv6.sysctl.flush_delay;
> + table[0].extra1 = net;
> table[1].data = &net->ipv6.ip6_dst_ops.gc_thresh;
> table[2].data = &net->ipv6.sysctl.ip6_rt_max_size;
> table[3].data = &net->ipv6.sysctl.ip6_rt_gc_min_interval;
^ permalink raw reply
* Re: txqueuelen has wrong units; should be time
From: Mikael Abrahamsson @ 2011-03-02 3:10 UTC (permalink / raw)
To: Eric Dumazet
Cc: Albert Cahalan, David Miller, johnwheffner, linville,
jussi.kivilinna, linux-kernel, netdev
In-Reply-To: <1298964381.2676.58.camel@edumazet-laptop>
On Tue, 1 Mar 2011, Eric Dumazet wrote:
> We should allow some trafic spikes, or many applications will stop
> working. Unless all applications are fixed, we are stuck.
>
> Only if the queue stay loaded a long time (yet another parameter) we can
> try to drop packets.
Are we talking forwarding of packets or originating them ourselves, or
trying to use the same mechanism for both?
In the case of routing a packet, I envision a WRED kind of behaviour is
the most efficient.
<http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/12stbwr.html>
"QoS: Time-Based Thresholds for WRED and Queue Limit for the Cisco 12000
Series Router" You can set the drop probabilites in milliseconds.
Unfortunately ECN isn't supported on this platform but on other platforms
it can be configured and used instead of WRED dropping packets.
For the case when we're ourselves originating the traffic (for instance to
a wifi card with varying speed and jitter due to retransmits on the wifi
layer), I think it's taking the too easy way out to use the same
mechanisms (dropping packets or marking ECN for our own originated packets
seems really weird), here we should be able to pushback information to the
applications somehow and do prioritization between flows since we're
sitting on all information ourselves including the application.
For this case, I think there is something to be learnt from:
<http://www.cisco.com/en/US/tech/tk39/tk824/technologies_tech_note09186a00800fbafc.shtml>
Here you have the IP part and the ATM part, and you can limit the number
of cells/packets sent to the ATM hardware at any given time (this queue is
FIFO so no AQM when the packet has been sent here). We need the same here,
to properly keep latency down and make AQM work, the hardware FIFO queue
needs to be kept low.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Herbert Xu @ 2011-03-02 3:09 UTC (permalink / raw)
To: Eric Dumazet
Cc: Thomas Graf, David Miller, rick.jones2, therbert, wsommerfeld,
daniel.baluta, netdev
In-Reply-To: <1299034598.2930.47.camel@edumazet-laptop>
On Wed, Mar 02, 2011 at 03:56:38AM +0100, Eric Dumazet wrote:
>
> Anyway, the SYN-ACK is generated by softirq, not really user choice.
> CPU depends if NIC is RX multiqueue or RPS is setup.
Which is exactly what we want. The RX queue selection should
determine the TX cpu.
> All this discussion is about letting process scheduler decide TX queue,
> (because user/admin used cpu affinity) or let network stack drive
> scheduler : Please migrate this thread on this cpu.
>
> Both schems should be allowed/configurable so that best results are
> available.
Whatever scheme we end up with, hashing different sockets running
in the same thread to different queues is just broken.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Fabio Checconi @ 2011-03-02 2:06 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Luigi Rizzo, netdev
In-Reply-To: <20110228171738.2cc8c9a0@nehalam>
Hi,
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Mon, Feb 28, 2011 05:17:38PM -0800
>
> This is an implementation of the Quick Fair Queue scheduler developed
> by Fabio Checconi. The same algorithm is already implemented in ipfw
> in FreeBSD. Fabio had an earlier version developed on Linux, I just
> cleaned it up and tested it. All bugs are mine.
>
thanks for posting, I'm pretty sure that bugs are more likely to be
ours than yours :)
During the development of the algorithm we used a simple traffic
simulator to verify (informally) the timestamping and the guarantees
provided. I've tested this version of the code with the simulator and
so far it worked fine, so I think that timestamping and guarantees should
be OK.
Please let us know if we can be of any help,
fabio
^ 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