* [PATCH net-next v2 01/10] headers, pppox: Add missing #include to <linux/if_pppox.h>
From: Ben Hutchings @ 2011-08-25 4:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Michal Ostrowski
In-Reply-To: <1314247131.27179.116.camel@deadeye>
[-- Attachment #1: Type: text/plain, Size: 633 bytes --]
<linux/if_ppox.h> uses ETH_ALEN, defined in <linux/if_ether.h>.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
include/linux/if_pppox.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/if_pppox.h b/include/linux/if_pppox.h
index 397921b..60e5558 100644
--- a/include/linux/if_pppox.h
+++ b/include/linux/if_pppox.h
@@ -20,8 +20,8 @@
#include <linux/types.h>
#include <asm/byteorder.h>
-#ifdef __KERNEL__
#include <linux/if_ether.h>
+#ifdef __KERNEL__
#include <linux/if.h>
#include <linux/netdevice.h>
#include <linux/ppp_channel.h>
--
1.7.5.4
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply related
* [PATCH net-next v2 00/10] Fix net header dependencies
From: Ben Hutchings @ 2011-08-25 4:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 2998 bytes --]
Various networking headers depend on definitions from others which they
don't include. We can't fix all of these, because some definitions are
duplicated between kernel headers and glibc headers and we cannot tell
which is the right one to include. We also have to be wary of
introducing a dependency cycle.
Since v1, I've dropped the patches to <linux/scc.h> and <linux/if_ppp.h>
and added the acknowledgements I got last time.
Ben.
Ben Hutchings (10):
headers, pppox: Add missing #include to <linux/if_pppox.h>
headers, ax25: Add missing #include to <linux/netrom.h>,
<linux/rose.h>
headers, pppol2tp: Use __kernel_pid_t in <linux/pppol2tp.h>
headers, net: Use __kernel_sa_family_t in more definitions shared
with userland
headers, net: Define struct __kernel_sockaddr, replacing struct
sockaddr
headers, netfilter: Use kernel type names __u8, __u16, __u32
headers, tipc: Add missing #include to <linux/tipc_config.h> for
userland
headers, netfilter: Add missing #include <limits.h> for userland
headers, xtables: Add missing #include <linux/netfilter.h>
headers, can: Add missing #include to <linux/can/bcm.h>
include/linux/atalk.h | 3 ++-
include/linux/ax25.h | 2 +-
include/linux/caif/caif_socket.h | 7 +------
include/linux/can.h | 2 +-
include/linux/can/bcm.h | 1 +
include/linux/if.h | 12 ++++++------
include/linux/if_pppol2tp.h | 2 +-
include/linux/if_pppox.h | 9 +++++----
include/linux/in.h | 2 +-
include/linux/ipx.h | 2 +-
include/linux/irda.h | 9 +++------
include/linux/l2tp.h | 7 ++++---
include/linux/llc.h | 10 +++++++---
include/linux/netfilter/xt_connlimit.h | 1 +
include/linux/netfilter/xt_conntrack.h | 1 +
include/linux/netfilter/xt_iprange.h | 1 +
include/linux/netfilter_arp/arp_tables.h | 14 +++++++-------
include/linux/netfilter_decnet.h | 3 +++
include/linux/netfilter_ipv4.h | 3 +++
include/linux/netfilter_ipv4/ip_tables.h | 20 ++++++++++----------
include/linux/netfilter_ipv6.h | 3 +++
include/linux/netfilter_ipv6/ip6_tables.h | 22 +++++++++++-----------
include/linux/netlink.h | 2 +-
include/linux/netrom.h | 2 ++
include/linux/phonet.h | 6 ++++--
include/linux/rose.h | 7 +++++--
include/linux/socket.h | 17 +++++++++--------
include/linux/tipc_config.h | 4 ++++
include/linux/un.h | 4 +++-
include/linux/x25.h | 3 ++-
30 files changed, 104 insertions(+), 77 deletions(-)
--
1.7.5.4
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: pull request: wireless 2011-08-22
From: Jeff Chua @ 2011-08-25 3:33 UTC (permalink / raw)
To: David Miller, IvDoorn; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20110822.123326.1795268471389412471.davem@davemloft.net>
On Tue, Aug 23, 2011 at 3:33 AM, David Miller <davem@davemloft.net> wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Mon, 22 Aug 2011 15:01:37 -0400
>
>> This is a batch of fixes intended for 3.1. Included is rewrite of an
>> earlier iwlagn fix that was revealed to be flawed (bad pointer access
>> during module unload), a fix for a memory leak, and a trio of rt2x00
>> fixes with detailed changelogs. These have all been in linux-next
>> for the last week with no reported complaints.
>>
>> Please let me know if there are problems!
>
> Pulled, thanks John.
I'm using the rt2800usb module for the Buffalo WLI-UC-GNM using ad-hoc mode.
T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0411 ProdID=01a2 Rev= 1.01
S: Manufacturer=Ralink
S: Product=802.11 n WLAN
It works ok, but after idling for a while, it does not response, and
module needs to unloaded and modprobe again to make it work.
The same mac80211 and cfg80211 works for iwlagn and no problem with
idling timeout.
Is there any parameter to control the rt2800usb to make turn off power saving?
I've tried "iwconfig lwan0 power timeout 0 power off" but no effect.
Linux 3.1.0-rc3 with commit caca9510ff4e5d842c0589110243d60927836222.
Thanks,
Jeff.
^ permalink raw reply
* Re: [Patch] Scm: Remove unnecessary pid & credential references in Unix socket's send and receive path
From: David Miller @ 2011-08-25 2:43 UTC (permalink / raw)
To: tim.c.chen
Cc: eric.dumazet, viro, ebiederm, ak, matt.fleming, linux-kernel,
netdev
In-Reply-To: <1314061046.2576.2922.camel@schen9-DESK>
From: Tim Chen <tim.c.chen@linux.intel.com>
Date: Mon, 22 Aug 2011 17:57:26 -0700
> On Mon, 2011-08-22 at 17:40 -0700, David Miller wrote:
>> From: Tim Chen <tim.c.chen@linux.intel.com>
>> Date: Fri, 19 Aug 2011 09:44:58 -0700
>>
>> > - /* Only send the fds in the first buffer */
>> > - err = unix_scm_to_skb(siocb->scm, skb, !fds_sent);
>> > + /* Only send the fds and no ref to pid in the first buffer */
>> > + if (fds_sent)
>> > + err = unix_scm_to_skb(siocb->scm, skb, !fds_sent, true);
>> > + else
>> > + err = unix_scm_to_skb(siocb->scm, skb, !fds_sent, false);
>>
>> Just set this final boolean the way the third argument is, there is no
>> reason to replicate the entire function call twice just to set the
>> final argument to what "fds_sent" evaluates to as a boolean.
>>
>> err = unix_scm_to_skb(siocb->scm, skb, !fds_sent, fds_sent);
>>
>> ought to suffice.
>
> Good point. Patch updated as suggested.
Applied.
^ permalink raw reply
* Re: [PATCH 0/2] sctp: patches for HEARTBEAT bug fix and improvement
From: David Miller @ 2011-08-25 2:43 UTC (permalink / raw)
To: micchie; +Cc: netdev, weiyj.lk
In-Reply-To: <D42EEC2F-E0C8-4620-9841-98F7E68C88FA@sfc.wide.ad.jp>
From: Michio Honda <micchie@sfc.wide.ad.jp>
Date: Tue, 23 Aug 2011 00:44:32 +0900
> Series of 2 patches for bug fix and improvement around HEARTBEAT after the
> ASCONF event
>
> Michio Honda (2):
> sctp: HEARTBEAT negotiation after ASCONF
> sctp: Bundle HEAERTBEAT into ASCONF_ACK
Both applied.
^ permalink raw reply
* Re: [PATCH v4] Proportional Rate Reduction for TCP.
From: David Miller @ 2011-08-25 2:43 UTC (permalink / raw)
To: nanditad; +Cc: netdev, therbert, mattmathis, ycheng
In-Reply-To: <1313994117-7374-1-git-send-email-nanditad@google.com>
From: Nandita Dukkipati <nanditad@google.com>
Date: Sun, 21 Aug 2011 23:21:57 -0700
> This patch implements Proportional Rate Reduction (PRR) for TCP.
> PRR is an algorithm that determines TCP's sending rate in fast
> recovery. PRR avoids excessive window reductions and aims for
> the actual congestion window size at the end of recovery to be as
> close as possible to the window determined by the congestion control
> algorithm. PRR also improves accuracy of the amount of data sent
> during loss recovery.
>
> The patch implements the recommended flavor of PRR called PRR-SSRB
> (Proportional rate reduction with slow start reduction bound) and
> replaces the existing rate halving algorithm. PRR improves upon the
> existing Linux fast recovery under a number of conditions including:
> 1) burst losses where the losses implicitly reduce the amount of
> outstanding data (pipe) below the ssthresh value selected by the
> congestion control algorithm and,
> 2) losses near the end of short flows where application runs out of
> data to send.
>
> As an example, with the existing rate halving implementation a single
> loss event can cause a connection carrying short Web transactions to
> go into the slow start mode after the recovery. This is because during
> recovery Linux pulls the congestion window down to packets_in_flight+1
> on every ACK. A short Web response often runs out of new data to send
> and its pipe reduces to zero by the end of recovery when all its packets
> are drained from the network. Subsequent HTTP responses using the same
> connection will have to slow start to raise cwnd to ssthresh. PRR on
> the other hand aims for the cwnd to be as close as possible to ssthresh
> by the end of recovery.
>
> A description of PRR and a discussion of its performance can be found at
> the following links:
> - IETF Draft:
> http://tools.ietf.org/html/draft-mathis-tcpm-proportional-rate-reduction-01
> - IETF Slides:
> http://www.ietf.org/proceedings/80/slides/tcpm-6.pdf
> http://tools.ietf.org/agenda/81/slides/tcpm-2.pdf
> - Paper to appear in Internet Measurements Conference (IMC) 2011:
> Improving TCP Loss Recovery
> Nandita Dukkipati, Matt Mathis, Yuchung Cheng
>
> Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v5 2/2] af-packet: TPACKET_V3 flexible buffer implementation.
From: David Miller @ 2011-08-25 2:43 UTC (permalink / raw)
To: loke.chetan; +Cc: netdev
In-Reply-To: <1313785096-911-3-git-send-email-loke.chetan@gmail.com>
From: Chetan Loke <loke.chetan@gmail.com>
Date: Fri, 19 Aug 2011 16:18:16 -0400
> 1) Blocks can be configured with non-static frame-size.
> 2) Read/poll is at a block-level(as opposed to packet-level).
> 3) Added poll timeout to avoid indefinite user-space wait on idle links.
> 4) Added user-configurable knobs:
> 4.1) block::timeout.
> 4.2) tpkt_hdr::sk_rxhash.
>
>
> Changes:
> C1) tpacket_rcv()
> C1.1) packet_current_frame() is replaced by packet_current_rx_frame()
> The bulk of the processing is then moved in the following chain:
> packet_current_rx_frame()
> __packet_lookup_frame_in_block
> fill_curr_block()
> or
> retire_current_block
> dispatch_next_block
> or
> return NULL(queue is plugged/paused)
>
> Signed-off-by: Chetan Loke <loke.chetan@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v5 1/2] af-packet: Added TPACKET_V3 headers.
From: David Miller @ 2011-08-25 2:43 UTC (permalink / raw)
To: loke.chetan; +Cc: netdev
In-Reply-To: <1313785096-911-2-git-send-email-loke.chetan@gmail.com>
From: Chetan Loke <loke.chetan@gmail.com>
Date: Fri, 19 Aug 2011 16:18:15 -0400
> Added TPACKET_V3 definitions.
>
> Signed-off-by: Chetan Loke <loke.chetan@gmail.com>
Applied.
I would suggest, as a follow-up patch, we add some appropriate
prefixes to these new datastructures added to if_packet.h as
these are exposed to userspace.
For example "hdr_v1", "bd_ts", "bd_header_u", and "block_desc" are
just asking for namespace conflicts with something other API in
userspace or the user's own datastructures.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: one more case for non-local saddr in ICMP
From: David Miller @ 2011-08-25 2:37 UTC (permalink / raw)
To: ja; +Cc: netdev, herbert
In-Reply-To: <alpine.LFD.2.00.1108151857420.1481@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Mon, 15 Aug 2011 19:21:23 +0300 (EEST)
> May be there is one more case that we can avoid using
> non-local source for ICMP errors: xfrm_lookup, num_xfrms = 0 when
> reverse "Flow passes untransformed". Avoid using the input route
> if xfrm_lookup returns same dst.
>
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
Julian I'm going to defer on this patch unless you think there is
a real pressing reason to apply it.
Thanks.
^ permalink raw reply
* Re: [PATCH] [IEEE802.15.4] 6LoWPAN basic support
From: David Miller @ 2011-08-25 2:36 UTC (permalink / raw)
To: alex.bluesman.smirnov; +Cc: netdev
In-Reply-To: <1313519811-22352-1-git-send-email-alex.bluesman.smirnov@gmail.com>
From: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
Date: Tue, 16 Aug 2011 22:36:51 +0400
> This patch provides base support for transmission of IPv6 packets as
> well as the formation of IPv6 link-local addresses and statelessly
> autoconfigured addresses on top of IEEE 802.15.4 networks.
>
> For more information please look at the RFC4944 "Compression Format
> for IPv6 Datagrams in Low Power and Losst Networks (6LoWPAN).
>
> Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
Patch applied, thanks.
^ permalink raw reply
* Re: [RFC] per-containers tcp buffer limitation
From: Eric W. Biederman @ 2011-08-25 2:16 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Glauber Costa, Linux Containers, netdev, David Miller,
Pavel Emelyanov
In-Reply-To: <20110825104956.41c4b60e.kamezawa.hiroyu@jp.fujitsu.com>
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> writes:
> On Wed, 24 Aug 2011 22:28:59 -0300
> Glauber Costa <glommer@parallels.com> wrote:
>
>> On 08/24/2011 09:35 PM, Eric W. Biederman wrote:
>> > Glauber Costa<glommer@parallels.com> writes:
>> Hi Eric,
>>
>> Thanks for your attention.
>>
>> So, this that you propose was my first implementation. I ended up
>> throwing it away after playing with it for a while.
>>
>> One of the first problems that arise from that, is that the sysctls are
>> a tunable visible from inside the container. Those limits, however, are
>> to be set from the outside world. The code is not much better than that
>> either, and instead of creating new cgroup structures and linking them
>> to the protocol, we end up doing it for net ns. We end up increasing
>> structures just the same...
You don't need to add a netns member to sockets.
But I do agree that there are odd permission issues with using the
existing sysctls and making them per namespace.
However almost everything I have seen with memory limits I have found
very strange. They all seem like a very bad version of disabling memory
over commits.
>> Also, since we're doing resource control, it seems more natural to use
>> cgroups. Now, the fact that there are no correlation whatsoever between
>> cgroups and namespaces does bother me. But that's another story, much
>> more broader and general than this patch.
>>
>
> I think using cgroup makes sense. A question in mind is whehter it is
> better to integrate this kind of 'memory usage' controls to memcg or
> not.
Maybe. When sockets start getting a cgroup member I start wondering,
how many cgroup members will sockets potentially belong to.
> How do you think ? IMHO, having cgroup per class of object is messy.
> ...
> How about adding
> memory.tcp_mem
> to memcg ?
>
> Or, adding kmem cgroup ?
>
>> About overhead, since this is the first RFC, I did not care about
>> measuring. However, it seems trivial to me to guarantee that at least
>> that it won't impose a significant performance penalty when it is
>> compiled out. If we're moving forward with this implementation, I will
>> include data in the next release so we can discuss in this basis.
>>
>
> IMHO, you should show performance number even if RFC. Then, people will
> see patch with more interests.
And also compiled out doesn't really count. Cgroups are something you
want people to compile into distributions for the common case, and you
don't want to impose a noticeable performance penalty for the common
case.
Eric
^ permalink raw reply
* Re: [RFC] per-containers tcp buffer limitation
From: KAMEZAWA Hiroyuki @ 2011-08-25 1:49 UTC (permalink / raw)
To: Glauber Costa
Cc: Eric W. Biederman, Linux Containers, netdev, David Miller,
Pavel Emelyanov
In-Reply-To: <4E55A55B.8090608@parallels.com>
On Wed, 24 Aug 2011 22:28:59 -0300
Glauber Costa <glommer@parallels.com> wrote:
> On 08/24/2011 09:35 PM, Eric W. Biederman wrote:
> > Glauber Costa<glommer@parallels.com> writes:
> >
> >> Hello,
> >>
> >> This is a proof of concept of some code I have here to limit tcp send and
> >> receive buffers per-container (in our case). At this phase, I am more concerned
> >> in discussing my approach, so please curse my family no further than the 3rd
> >> generation.
> >>
> >> The problem we're trying to attack here, is that buffers can grow and fill
> >> non-reclaimable kernel memory. When doing containers, we can't afford having a
> >> malicious container pinning kernel memory at will, therefore exhausting all the
> >> others.
> >>
> >> So here a container will be seen in the host system as a group of tasks, grouped
> >> in a cgroup. This cgroup will have files allowing us to specify global
> >> per-cgroup limits on buffers. For that purpose, I created a new sockets cgroup -
> >> didn't really think any other one of the existing would do here.
> >>
> >> As for the network code per-se, I tried to keep the same code that deals with
> >> memory schedule as a basis and make it per-cgroup.
> >> You will notice that struct proto now take function pointers to values
> >> controlling memory pressure and will return per-cgroup data instead of global
> >> ones. So the current behavior is maintained: after the first threshold is hit,
> >> we enter memory pressure. After that, allocations are suppressed.
> >>
> >> Only tcp code was really touched here. udp had the pointers filled, but we're
> >> not really controlling anything. But the fact that this lives in generic code,
> >> makes it easier to do the same for other protocols in the future.
> >>
> >> For this patch specifically, I am not touching - just provisioning -
> >> rmem and wmem specific knobs. I should also #ifdef a lot of this, but hey,
> >> remember: rfc...
> >>
> >> One drawback of this approach I found, is that cgroups does not really work well
> >> with modules. A lot of the network code is modularized, so this would have to be
> >> fixed somehow.
> >>
> >> Let me know what you think.
> >
> > Can you implement this by making the existing network sysctls per
> > network namespace?
> >
> > At a quick skim it looks to me like you can make the existing sysctls
> > per network namespace and solve the issues you are aiming at solving and
> > that should make the code much simpler, than your proof of concept code.
> >
> > Any implementation of this needs to answer the question how much
> > overhead does this extra accounting add. I don't have a clue how much
> > overhead you are adding but you are making structures larger and I
> > suspect adding at least another cache line miss, so I suspect your
> > changes will impact real world socket performance.
>
> Hi Eric,
>
> Thanks for your attention.
>
> So, this that you propose was my first implementation. I ended up
> throwing it away after playing with it for a while.
>
> One of the first problems that arise from that, is that the sysctls are
> a tunable visible from inside the container. Those limits, however, are
> to be set from the outside world. The code is not much better than that
> either, and instead of creating new cgroup structures and linking them
> to the protocol, we end up doing it for net ns. We end up increasing
> structures just the same...
>
> Also, since we're doing resource control, it seems more natural to use
> cgroups. Now, the fact that there are no correlation whatsoever between
> cgroups and namespaces does bother me. But that's another story, much
> more broader and general than this patch.
>
I think using cgroup makes sense. A question in mind is whehter it is
better to integrate this kind of 'memory usage' controls to memcg or not.
How do you think ? IMHO, having cgroup per class of object is messy.
...
How about adding
memory.tcp_mem
to memcg ?
Or, adding kmem cgroup ?
> About overhead, since this is the first RFC, I did not care about
> measuring. However, it seems trivial to me to guarantee that at least
> that it won't impose a significant performance penalty when it is
> compiled out. If we're moving forward with this implementation, I will
> include data in the next release so we can discuss in this basis.
>
IMHO, you should show performance number even if RFC. Then, people will
see patch with more interests.
Thanks,
-Kame
^ permalink raw reply
* Re: [PATCH] tcp: bound RTO to minimum
From: Yuchung Cheng @ 2011-08-25 1:50 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: netdev, eric.dumazet
In-Reply-To: <1314229310-8074-1-git-send-email-hagen@jauu.net>
On Wed, Aug 24, 2011 at 4:41 PM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
> Check if calculated RTO is less then TCP_RTO_MIN. If this is true we
> adjust the value to TCP_RTO_MIN.
>
but tp->rttvar is already lower-bounded via tcp_rto_min()?
static inline void tcp_set_rto(struct sock *sk)
{
...
/* NOTE: clamping at TCP_RTO_MIN is not required, current algo
* guarantees that rto is higher.
*/
tcp_bound_rto(sk);
}
^ permalink raw reply
* (unknown),
From: con@telus.net @ 2011-08-25 1:39 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 27 bytes --]
KINDLY DOWNLOAD ATTACHMENT
[-- Attachment #2: NOTIFICATION BOARD.txt --]
[-- Type: application/octet-stream, Size: 674 bytes --]
You have been selected in the on-going COCA COLA award held this August
2011.We the Promo Board are pleased to inform you that you alongside four(4)
otherlucky winners have been approved for a payment of 1,000 000GBP (One
Million Pounds Sterling).
If you did receive this email, it means you are one of the five(5)lucky
winners.
*CLAIMS PROCESSING OFFICER:
*Name:Mr TOMMY ROGER
E.mail: claimsgroup222@qatar.io
You are also advised to provide him with the under listed information
as soon as possible:
*NAME IN FULL:
*DELIVERY ADDRESS:
*SEX:
*AGE:
*COUNTRY:
*NATIONALITY:
*OCCUPATION:
*PHONE:
We are glad to have you as one of our luckly winners.
^ permalink raw reply
* Re: [RFC] per-containers tcp buffer limitation
From: Glauber Costa @ 2011-08-25 1:28 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev, David Miller, Linux Containers, Pavel Emelyanov
In-Reply-To: <m1k4a2qqew.fsf@fess.ebiederm.org>
On 08/24/2011 09:35 PM, Eric W. Biederman wrote:
> Glauber Costa<glommer@parallels.com> writes:
>
>> Hello,
>>
>> This is a proof of concept of some code I have here to limit tcp send and
>> receive buffers per-container (in our case). At this phase, I am more concerned
>> in discussing my approach, so please curse my family no further than the 3rd
>> generation.
>>
>> The problem we're trying to attack here, is that buffers can grow and fill
>> non-reclaimable kernel memory. When doing containers, we can't afford having a
>> malicious container pinning kernel memory at will, therefore exhausting all the
>> others.
>>
>> So here a container will be seen in the host system as a group of tasks, grouped
>> in a cgroup. This cgroup will have files allowing us to specify global
>> per-cgroup limits on buffers. For that purpose, I created a new sockets cgroup -
>> didn't really think any other one of the existing would do here.
>>
>> As for the network code per-se, I tried to keep the same code that deals with
>> memory schedule as a basis and make it per-cgroup.
>> You will notice that struct proto now take function pointers to values
>> controlling memory pressure and will return per-cgroup data instead of global
>> ones. So the current behavior is maintained: after the first threshold is hit,
>> we enter memory pressure. After that, allocations are suppressed.
>>
>> Only tcp code was really touched here. udp had the pointers filled, but we're
>> not really controlling anything. But the fact that this lives in generic code,
>> makes it easier to do the same for other protocols in the future.
>>
>> For this patch specifically, I am not touching - just provisioning -
>> rmem and wmem specific knobs. I should also #ifdef a lot of this, but hey,
>> remember: rfc...
>>
>> One drawback of this approach I found, is that cgroups does not really work well
>> with modules. A lot of the network code is modularized, so this would have to be
>> fixed somehow.
>>
>> Let me know what you think.
>
> Can you implement this by making the existing network sysctls per
> network namespace?
>
> At a quick skim it looks to me like you can make the existing sysctls
> per network namespace and solve the issues you are aiming at solving and
> that should make the code much simpler, than your proof of concept code.
>
> Any implementation of this needs to answer the question how much
> overhead does this extra accounting add. I don't have a clue how much
> overhead you are adding but you are making structures larger and I
> suspect adding at least another cache line miss, so I suspect your
> changes will impact real world socket performance.
Hi Eric,
Thanks for your attention.
So, this that you propose was my first implementation. I ended up
throwing it away after playing with it for a while.
One of the first problems that arise from that, is that the sysctls are
a tunable visible from inside the container. Those limits, however, are
to be set from the outside world. The code is not much better than that
either, and instead of creating new cgroup structures and linking them
to the protocol, we end up doing it for net ns. We end up increasing
structures just the same...
Also, since we're doing resource control, it seems more natural to use
cgroups. Now, the fact that there are no correlation whatsoever between
cgroups and namespaces does bother me. But that's another story, much
more broader and general than this patch.
About overhead, since this is the first RFC, I did not care about
measuring. However, it seems trivial to me to guarantee that at least
that it won't impose a significant performance penalty when it is
compiled out. If we're moving forward with this implementation, I will
include data in the next release so we can discuss in this basis.
^ permalink raw reply
* Re: [PATCH 2/4] net: ipv4: convert to SKB frag APIs
From: David Miller @ 2011-08-25 0:52 UTC (permalink / raw)
To: ian.campbell; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <1314092701-4347-2-git-send-email-ian.campbell@citrix.com>
From: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 23 Aug 2011 10:44:59 +0100
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/4] net: ipv6: convert to SKB frag APIs
From: David Miller @ 2011-08-25 0:52 UTC (permalink / raw)
To: ian.campbell; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <1314092701-4347-3-git-send-email-ian.campbell@citrix.com>
From: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 23 Aug 2011 10:45:00 +0100
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ibmveth: Fix leak when recycling skb and hypervisor returns error
From: David Miller @ 2011-08-25 0:56 UTC (permalink / raw)
To: anton; +Cc: santil, netdev
In-Reply-To: <20110825105520.5ba7ae90@kryten>
From: Anton Blanchard <anton@samba.org>
Date: Thu, 25 Aug 2011 10:55:20 +1000
>> Please generate this patch against Linus's tree, instead of -next
>
> Sure, here it is.
Applied, thanks.
^ permalink raw reply
* Re: (3.1.0-rc2-git7) include/linux/inetdevice.h:209 invoked rcu_dereference_check() without protection!
From: David Miller @ 2011-08-25 0:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: davej, netdev
In-Reply-To: <1314077562.4791.21.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 23 Aug 2011 07:32:42 +0200
> [PATCH] arp: fix rcu lockdep splat in arp_process()
>
> Dave Jones reported a lockdep splat triggered by an arp_process() call
> from parp_redo().
>
> Commit faa9dcf793be (arp: RCU changes) is the origin of the bug, since
> it assumed arp_process() was called under rcu_read_lock(), which is not
> true in this particular path.
>
> Instead of adding rcu_read_lock() in parp_redo(), I chose to add it in
> neigh_proxy_process() to take care of IPv6 side too.
...
> Reported-by: Dave Jones <davej@redhat.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* [PATCH] ibmveth: Fix leak when recycling skb and hypervisor returns error
From: Anton Blanchard @ 2011-08-25 0:55 UTC (permalink / raw)
To: David Miller; +Cc: santil, netdev
In-Reply-To: <20110824.174353.1962229766905714384.davem@davemloft.net>
Hi Dave,
> Please generate this patch against Linus's tree, instead of -next
Sure, here it is.
Anton
--
If h_add_logical_lan_buffer returns an error we need to free
the skb.
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: stable <stable@kernel.org>
---
Index: linux-2.6-work/drivers/net/ibmveth.c
===================================================================
--- linux-2.6-work.orig/drivers/net/ibmveth.c 2011-07-31 20:45:29.729141545 +1000
+++ linux-2.6-work/drivers/net/ibmveth.c 2011-08-25 10:49:04.200718870 +1000
@@ -395,7 +395,7 @@ static inline struct sk_buff *ibmveth_rx
}
/* recycle the current buffer on the rx queue */
-static void ibmveth_rxq_recycle_buffer(struct ibmveth_adapter *adapter)
+static int ibmveth_rxq_recycle_buffer(struct ibmveth_adapter *adapter)
{
u32 q_index = adapter->rx_queue.index;
u64 correlator = adapter->rx_queue.queue_addr[q_index].correlator;
@@ -403,6 +403,7 @@ static void ibmveth_rxq_recycle_buffer(s
unsigned int index = correlator & 0xffffffffUL;
union ibmveth_buf_desc desc;
unsigned long lpar_rc;
+ int ret = 1;
BUG_ON(pool >= IBMVETH_NUM_BUFF_POOLS);
BUG_ON(index >= adapter->rx_buff_pool[pool].size);
@@ -410,7 +411,7 @@ static void ibmveth_rxq_recycle_buffer(s
if (!adapter->rx_buff_pool[pool].active) {
ibmveth_rxq_harvest_buffer(adapter);
ibmveth_free_buffer_pool(adapter, &adapter->rx_buff_pool[pool]);
- return;
+ goto out;
}
desc.fields.flags_len = IBMVETH_BUF_VALID |
@@ -423,12 +424,16 @@ static void ibmveth_rxq_recycle_buffer(s
netdev_dbg(adapter->netdev, "h_add_logical_lan_buffer failed "
"during recycle rc=%ld", lpar_rc);
ibmveth_remove_buffer_from_pool(adapter, adapter->rx_queue.queue_addr[adapter->rx_queue.index].correlator);
+ ret = 0;
}
if (++adapter->rx_queue.index == adapter->rx_queue.num_slots) {
adapter->rx_queue.index = 0;
adapter->rx_queue.toggle = !adapter->rx_queue.toggle;
}
+
+out:
+ return ret;
}
static void ibmveth_rxq_harvest_buffer(struct ibmveth_adapter *adapter)
@@ -1084,8 +1089,9 @@ restart_poll:
if (rx_flush)
ibmveth_flush_buffer(skb->data,
length + offset);
+ if (!ibmveth_rxq_recycle_buffer(adapter))
+ kfree_skb(skb);
skb = new_skb;
- ibmveth_rxq_recycle_buffer(adapter);
} else {
ibmveth_rxq_harvest_buffer(adapter);
skb_reserve(skb, offset);
^ permalink raw reply
* Re: [PATCH 1/4] net: convert core to skb paged frag APIs
From: David Miller @ 2011-08-25 0:52 UTC (permalink / raw)
To: ian.campbell; +Cc: netdev, eric.dumazet, mirq-linux
In-Reply-To: <1314092701-4347-1-git-send-email-ian.campbell@citrix.com>
From: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 23 Aug 2011 10:44:58 +0100
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Applied.
^ permalink raw reply
* Re: [PATCH 4/4] net: xfrm: convert to SKB frag APIs
From: David Miller @ 2011-08-25 0:52 UTC (permalink / raw)
To: ian.campbell; +Cc: netdev
In-Reply-To: <1314092701-4347-4-git-send-email-ian.campbell@citrix.com>
From: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 23 Aug 2011 10:45:01 +0100
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bridge: Pseudo-header required for the checksum of ICMPv6
From: David Miller @ 2011-08-25 0:51 UTC (permalink / raw)
To: zheng.z.yan; +Cc: netdev, wcang
In-Reply-To: <4E54BC49.6090506@intel.com>
From: "Yan, Zheng" <zheng.z.yan@intel.com>
Date: Wed, 24 Aug 2011 16:54:33 +0800
> Checksum of ICMPv6 is not properly computed because the pseudo header is not used.
> Thus, the MLD packet gets dropped by the bridge.
>
> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
> Reported-by: Ang Way Chuang <wcang@sfc.wide.ad.jp>
Applied.
^ permalink raw reply
* Re: [PATCH] bridge: fix a possible use after free
From: David Miller @ 2011-08-25 0:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, herbert, shemminger
In-Reply-To: <1314165425.4478.19.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 24 Aug 2011 07:57:05 +0200
> br_multicast_ipv6_rcv() can call pskb_trim_rcsum() and therefore skb
> head can be reallocated.
>
> Cache icmp6_type field instead of dereferencing twice the struct
> icmp6hdr pointer.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] mcast: Fix source address selection for multicast listener report
From: David Miller @ 2011-08-25 0:46 UTC (permalink / raw)
To: zheng.z.yan; +Cc: netdev, dlstevens
In-Reply-To: <4E54BC4D.8090008@intel.com>
From: "Yan, Zheng" <zheng.z.yan@intel.com>
Date: Wed, 24 Aug 2011 16:54:37 +0800
> Should check use count of include mode filter instead of total number
> of include mode filters.
>
> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
Applied, thank you.
^ 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