* oops in 2.6.38, possibly nf_conntrak_ipv4 related
From: Mikael Abrahamsson @ 2011-10-02 6:54 UTC (permalink / raw)
To: netdev
Hello.
I just upgraded from ubuntu 10.10 (2.6.35) to 11.04 (2.6.38) on an amd64
machine.
2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12 21:17:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
About 12-14 hours after reboot, the machine oopsed and went offline. I
took a picture of the trace which can be found here:
<http://swm.pp.se/IMG_0937.JPG>
To me, it looks like something went wrong in nf_conntrak_ipv4, but I am
quite the novice regarding this.
I did not have any NAT rules enabled, the only iptables that is enabled
are some simple port blocks with "-j REJECT --reject-with tcp-reset" for
the world with a few exceptions (my own networks).
Any ideas? If this is the wrong place to turn to, pointers on where to go
is much appreciated.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
From: Eric Dumazet @ 2011-10-02 7:21 UTC (permalink / raw)
To: starlight; +Cc: linux-kernel, netdev, Willy Tarreau, Peter Zijlstra
In-Reply-To: <6.2.5.6.2.20111001215241.03a7ed48@binnacle.cx>
Le dimanche 02 octobre 2011 à 01:33 -0400, starlight@binnacle.cx a
écrit :
> Did some additional testing and have an update:
>
> 1) compiled 2.6.32.27 with CGROUP and NAMESPACES
> disabled as much as 'make menuconfig' will allow.
> Made no difference on performance--same exact
> result.
>
> 2) did observe that the IRQ rate is 100k on
> 2.6.32.27 where it is 33k on 2.6.18(rhel).
>
> 3) compiled 2.6.39.4 with same config used
> in (1) above, allowing 'make menuconfig'
> to fill in differences. Tried 'make defconfig'
> but it left out too many modules and the kernel
> would not even install. The config used to
> build this kernel is attached.
>
> .39 Runs 7% better than .32 but still 27.5% worse
> than 2.6.18(rhel) on total reported CPU and 97%
> worse on system CPU. The IRQ rate was 50k here.
>
> 4) Ran the full 30 minute test again with
>
> perf record -a
>
> running and generated a report (attached).
> This was done in packet socket mode because
> all the newer kernels have some serious bug
> where UDP data is not delivered to about
> half of the sockets even though it arrives
> to the interface. [I've been ignoring
> this since packet socket performance is
> close to UDP socket performance and I'm more
> worried about network overhead than the
> UDP bug. Comparisons are with same mode
> test on the 2.6.18(rhel) kernel.]
>
> The application '_raw_spin_lock' number
> stands out to me--makes me think that
> 2.6.39 has greater bias toward spinning
> futexes than 2.6.18(rhel) as the user
> CPU was 6.5% higher. The .32(rhel) kernel
> is exactly the same on user CPU. In UDP
> mode there is little or none of this lock-
> contention CPU--it appears here due to the
> need for queuing messages to worker
> threads in packet-socket mode.
>
> Beyond that it looks to me like the kernel paths
> have no notable hot-spots, which makes me think
> that the code path has gotten longer everywhere
> or that subtle changes have interacted badly
> with cache behavior to cause the performance
> loss. However someone who knows the kernel
> code may see things here that I cannot.
>
> -----
>
> This popped into my head. About two years ago
> I tried benchmarking SLES RT with our application.
> The results were horrifically bad. Don't know
> if anything from the RT work was merged into
> the kernel, but my overall impression was that
> RT traded CPU for latency to the extreme point
> where any application that used more than
> 10% of the much higher CPU consumption would
> not work. Haven't looked at latency during
> these tests, but I suppose if there are
> improvements it might be worth the extra CPU
> it's costing. Any thoughts on this?
You might try to disable any fancy power saving mode in your machine.
Maybe on your machine, cost to enter/exit deep sleep state is too high.
I see nothing obvious in the profile but userland processing, futex
calls.
Network processing seems to account less than 10% of total cpu...
All this sounds more a process scheduling regression than a network
stack one..
On new kernels, you can check if your udp sockets drops frames because
of rcvbuffer being full (cat /proc/net/udp, check last column 'drops')
To check if softirq processing hit some limits :
cat /proc/net/softnet_stat
Please send full "dmesg" output
^ permalink raw reply
* Re: RFS issue: no HW filter for paused stream
From: Amir Vadai @ 2011-10-02 7:59 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Tom Herbert, oren, liranl, netdev, Diego Crupnicoff
In-Reply-To: <1317166968.2845.45.camel@bwh-desktop>
Yes - checked it and it works.
- Amir
On 09/28/2011 02:42 AM, Ben Hutchings wrote:
> On Thu, 2011-09-22 at 09:11 +0300, Amir Vadai wrote:
>> Looks good.
>> and now the code is much clearer
> Does that mean that this change *works* for you?
>
> Ben.
>
> [...]
>>> But that means we never move the flow to a new CPU in the non-
>>> accelerated case. So maybe the proper change would be:
>>>
>>> --- a/net/core/dev.c
>>> +++ b/net/core/dev.c
>>> @@ -2652,10 +2652,7 @@ static struct rps_dev_flow *
>>> set_rps_cpu(struct net_device *dev, struct sk_buff *skb,
>>> struct rps_dev_flow *rflow, u16 next_cpu)
>>> {
>>> - u16 tcpu;
>>> -
>>> - tcpu = rflow->cpu = next_cpu;
>>> - if (tcpu != RPS_NO_CPU) {
>>> + if (next_cpu != RPS_NO_CPU) {
>>> #ifdef CONFIG_RFS_ACCEL
>>> struct netdev_rx_queue *rxqueue;
>>> struct rps_dev_flow_table *flow_table;
>>> @@ -2683,16 +2680,16 @@ set_rps_cpu(struct net_device *dev, struct sk_buff *skb,
>>> goto out;
>>> old_rflow = rflow;
>>> rflow =&flow_table->flows[flow_id];
>>> - rflow->cpu = next_cpu;
>>> rflow->filter = rc;
>>> if (old_rflow->filter == rflow->filter)
>>> old_rflow->filter = RPS_NO_FILTER;
>>> out:
>>> #endif
>>> rflow->last_qtail =
>>> - per_cpu(softnet_data, tcpu).input_queue_head;
>>> + per_cpu(softnet_data, next_cpu).input_queue_head;
>>> }
>>>
>>> + rflow->cpu = next_cpu;
>>> return rflow;
>>> }
>>>
>>> --- END ---
>>>
^ permalink raw reply
* Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
From: Eric Dumazet @ 2011-10-02 8:03 UTC (permalink / raw)
To: starlight; +Cc: linux-kernel, netdev, Willy Tarreau, Peter Zijlstra
In-Reply-To: <1317540066.3802.32.camel@edumazet-laptop>
Le dimanche 02 octobre 2011 à 09:21 +0200, Eric Dumazet a écrit :
> You might try to disable any fancy power saving mode in your machine.
> Maybe on your machine, cost to enter/exit deep sleep state is too high.
>
> I see nothing obvious in the profile but userland processing, futex
> calls.
Just to clarify a bit :
Sometimes, optimizing one part of the kernel can have a negative impact
on some workloads because we end up doing more sleep/wakeup of
consumers : Several threads might try to acquire a lock at the same
time, while previously they got no contention.
In 2.6.35, commit c377411f2494a (net: sk_add_backlog() take rmem_alloc
into account) changed backlog limit, avoid taking socket lock on flood,
allowing to receive 200.000 pps on a test machine instead of 100pps.
But the receiver was doing a plain
while (1)
recv(...);
And maximum throughput was reached because task never called
scheduler...
^ permalink raw reply
* RE: [PATCH] mlx4_en: fix transmit of packages when blue frame is enabled
From: Yevgeny Petrilin @ 2011-10-02 8:58 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo, netdev@vger.kernel.org
In-Reply-To: <1317388995-411-1-git-send-email-cascardo@linux.vnet.ibm.com>
> With the addition of Blue Frame support in the network driver for mlx4, the doorbell is not written in the path where blue frame is enabled and the package follows some characteristics.
>
> The consequence of that is that ICMP ECHO requests, for example, were not transmitted by the device. A ping flood, for example, would make the
> watchdog dispatch, because the ring was full and transmissions have timed out.
>
> After this fix, I could ping two systems using mlx4_en (both with the fix).
>
> Signed-off-by: Thadeu Lima de Souza Cascardo
> <cascardo@linux.vnet.ibm.com>
> Cc: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_tx.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> index 6e03de0..270da80 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> @@ -811,10 +811,11 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb,
> struct net_device *dev)
> * before setting ownership of this descriptor to HW */
> wmb();
> tx_desc->ctrl.owner_opcode = op_own;
> - wmb();
> - writel(ring->doorbell_qpn, ring->bf.uar->map + MLX4_SEND_DOORBELL);
> }
>
> + wmb();
> + writel(ring->doorbell_qpn, ring->bf.uar->map + MLX4_SEND_DOORBELL);
> +
> /* Poll CQ here */
> mlx4_en_xmit_poll(priv, tx_ind);
>
> --
> 1.7.4.4
What this patch does is ringing the doorbell unconditionally, whether blue flame is used or not.
The whole idea, is to copy the data to the blueflame register and have the HW take the data from there and save the memory access to the work queue entry.
In this patch you do both, copy the data to the register, and then still the HW accesses the memory to take it.
For some reason Blue flame is not working on your system and we need to understand why, I'll be glad to work with you to debug it.
Anyway, this patch is not the solution (even that it works on your systems) for the problem.
Yevgeny
^ permalink raw reply
* Re: [PATCH] virtio-net: Read MAC only after initializing MSI-X
From: Michael S. Tsirkin @ 2011-10-02 9:09 UTC (permalink / raw)
To: Rusty Russell; +Cc: Sasha Levin, linux-kernel, virtualization, netdev, kvm
In-Reply-To: <874o09x97m.fsf@rustcorp.com.au>
On Mon, Sep 19, 2011 at 05:19:49PM +0930, Rusty Russell wrote:
> On Mon, 19 Sep 2011 09:01:50 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Mon, Sep 19, 2011 at 01:05:17PM +0930, Rusty Russell wrote:
> > > On Sat, 20 Aug 2011 23:00:44 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > > On Fri, Aug 19, 2011 at 07:33:07PM +0300, Sasha Levin wrote:
> > > > > Maybe this is better solved by copying the way it was done in PCI itself
> > > > > with capability linked list?
> > > >
> > > > There are any number of ways to lay out the structure. I went for what
> > > > seemed a simplest one. For MSI-X the train has left the station. We
> > > > can probably still tweak where the high 32 bit features
> > > > for 64 bit features are. No idea if it's worth it.
> > >
> > > Sorry, this has been in the back of my mind. I think it's a good idea;
> > > can we use the capability linked list for pre-device specific stuff from
> > > now on?
> > >
> > > Thanks,
> > > Rusty.
> >
> > Do we even want capability bits then?
> > We can give each capability an ack flag ...
>
> We could have, and if I'd known PCI when I designed virtio I might have.
>
> But it's not easy now to map structure offsets to that scheme, and we
> can't really force such a change on the non-PCI users. So I'd say we
> should only do it for the non-device-specific options. ie. we'll still
> have the MSI-X case move the device-specific config, but we'll use a
> linked list from now on, eg. for the next 32 features bits...
>
> Thoughts?
> Rusty.
So I thought about this some more. It probably makes sense to
stop adding info in the io space, and start adding new stuff in
memory space which is much less contrained.
As we need to keep compatibility, and also because memory access is
much slower with kvm so we prefer io for datapath, we could have the
first X bytes still mirrored in io space.
MSIX is there, and it's pointed to from config space,
so we could just put our stuff at offset 0.
Or if we wanted a lot of flexibility, we could add pointers, in config
space, to device specific and non device specific regions in memory
space.
Makes sense?
--
MST
^ permalink raw reply
* Re: [PATCH] virtio-net: Read MAC only after initializing MSI-X
From: Michael S. Tsirkin @ 2011-10-02 9:11 UTC (permalink / raw)
To: Sasha Levin; +Cc: Rusty Russell, linux-kernel, virtualization, netdev, kvm
In-Reply-To: <1317234651.11915.6.camel@lappy>
On Wed, Sep 28, 2011 at 09:30:51PM +0300, Sasha Levin wrote:
> On Mon, 2011-09-19 at 17:19 +0930, Rusty Russell wrote:
> > On Mon, 19 Sep 2011 09:01:50 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > On Mon, Sep 19, 2011 at 01:05:17PM +0930, Rusty Russell wrote:
> > > > On Sat, 20 Aug 2011 23:00:44 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > > > On Fri, Aug 19, 2011 at 07:33:07PM +0300, Sasha Levin wrote:
> > > > > > Maybe this is better solved by copying the way it was done in PCI itself
> > > > > > with capability linked list?
> > > > >
> > > > > There are any number of ways to lay out the structure. I went for what
> > > > > seemed a simplest one. For MSI-X the train has left the station. We
> > > > > can probably still tweak where the high 32 bit features
> > > > > for 64 bit features are. No idea if it's worth it.
> > > >
> > > > Sorry, this has been in the back of my mind. I think it's a good idea;
> > > > can we use the capability linked list for pre-device specific stuff from
> > > > now on?
> > > >
> > > > Thanks,
> > > > Rusty.
> > >
> > > Do we even want capability bits then?
> > > We can give each capability an ack flag ...
> >
> > We could have, and if I'd known PCI when I designed virtio I might have.
> >
> > But it's not easy now to map structure offsets to that scheme, and we
> > can't really force such a change on the non-PCI users. So I'd say we
> > should only do it for the non-device-specific options. ie. we'll still
> > have the MSI-X case move the device-specific config, but we'll use a
> > linked list from now on, eg. for the next 32 features bits...
> >
> > Thoughts?
> > Rusty.
>
> What if we create a capability list but place it in the virtio-pci
> config space instead of the PCI space?
Pls note that virtio-pci config space is io so it is very constrained,
we do need to pack it densely. If we want to add a lot of stuff there
we probably should move it to memory space. It's slower than io
on kvm, but most uses of it aren't on data path.
> It'll work fine with non-PCI users and would leave MSI-X as the only
> thing that changes offsets (and we could probably deprecate and remove
> it at some point in the future).
>
> --
>
> Sasha.
^ permalink raw reply
* Why might packets go into a tunnel and not come out
From: Jan Ceuleers @ 2011-10-02 9:25 UTC (permalink / raw)
To: netdev
All,
This is a question that I would have posted to linux-net had it still
existed. I beg your indulgence.
I have established an SSH tunnel (device tunX) between two remote hosts.
This tunnel is operating properly in that I can ping each peer from the
other.
I am now trying to route traffic through this tunnel to onward
destinations. This is not working: when I ping such an onward
destination I can see the packets going into the tunnel (using tcpdump)
but they're not coming out of the other end (again as seen by tcpdump).
I have added logging to all firewall rules that drop or reject traffic;
nothing is logged. (And yes I have checked that logging itself works by
briefly adding logging to an ACCEPT rule). Routing is enabled on both
hosts. The counters for the tun devices (as seen using ifconfig) do not
show any dropped traffic.
I am not asking you to debug my problem for me, but could anyone please
point me to an overview of the reasons why packets might be going into
one end of a tunnel and not come out the other end? I have studied the
diagram at the following link and I think I've checked the potential
issues that it prompts:
http://www.shorewall.net/Shorewall_and_Routing.html
Many thanks.
Jan
^ permalink raw reply
* [PATCH v3] tcp: properly update lost_cnt_hint during shifting
From: Yan, Zheng @ 2011-10-02 14:21 UTC (permalink / raw)
To: netdev@vger.kernel.org, Ilpo Järvinen, Nandita Dukkipati,
ycheng
lost_skb_hint is used by tcp_mark_head_lost() to mark the first unhandled skb.
lost_cnt_hint is the number of packets or sacked packets before the lost_skb_hint;
When shifting a skb that is before the lost_skb_hint, if tcp_is_fack() is ture,
the skb has already been counted in the lost_cnt_hint; if tcp_is_fack() is false,
tcp_sacktag_one() will increase the lost_cnt_hint. So tcp_shifted_skb() does not
need to adjust the lost_cnt_hint by itself. When shifting a skb that is equal to
lost_skb_hint, the shifted packets will not be counted by tcp_mark_head_lost().
So tcp_shifted_skb() should adjust the lost_cnt_hint even tcp_is_fack(tp) is true.
Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
---
Changes since v2:
adjust the lost_cnt_hint even tcp_is_fack(tp) is true.
net/ipv4/tcp_input.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 21fab3e..d73aab3 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1389,9 +1389,7 @@ static int tcp_shifted_skb(struct sock *sk, struct sk_buff *skb,
BUG_ON(!pcount);
- /* Tweak before seqno plays */
- if (!tcp_is_fack(tp) && tcp_is_sack(tp) && tp->lost_skb_hint &&
- !before(TCP_SKB_CB(tp->lost_skb_hint)->seq, TCP_SKB_CB(skb)->seq))
+ if (skb == tp->lost_skb_hint)
tp->lost_cnt_hint += pcount;
TCP_SKB_CB(prev)->end_seq += shifted;
--
1.7.4.4
^ permalink raw reply related
* Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
From: Stephen Hemminger @ 2011-10-02 14:47 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, netdev, Willy Tarreau, Peter Zijlstra, starlight
In-Reply-To: <1317540066.3802.32.camel@edumazet-laptop>
Try disabling PCI DMA remapping. The additional overhead of setting
up IO mapping can be a performance buzz kill. Try CONGIG_DMAR=n
^ permalink raw reply
* Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
From: starlight @ 2011-10-02 15:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev, Willy Tarreau, Peter Zijlstra
In-Reply-To: <1317540066.3802.32.camel@edumazet-laptop>
At 09:21 AM 10/2/2011 +0200, Eric Dumazet wrote:
>Le dimanche 02 octobre 2011 Ã 01:33 -0400,
>
>You might try to disable any fancy power saving
>mode in your machine. Maybe on your machine, cost
>to enter/exit deep sleep state is too high.
I'll check this out. It's an Opteron 6174 and
so recent and with all the aggressive power
saving AMD can dish out. Note that 'cpuspeed'
is turned off. Only thing I can think of
off the top of my head is to boot with
'nohalt' (which used to be idle=poll). If
anyone knows further Magney Cours tweaks
please let me know.
>Just to clarify a bit :
>
>Sometimes, optimizing one part of the kernel can
>have a negative impact on some workloads because
>we end up doing more sleep/wakeup of consumers :
>Several threads might try to acquire a lock at the
>same time, while previously they got no
>contention.
>
>In 2.6.35, commit c377411f2494a (net:
>sk_add_backlog() take rmem_alloc into account)
>changed backlog limit, avoid taking socket lock on
>flood, allowing to receive 200.000 pps on a test
>machine instead of 100pps. But the receiver was
>doing a plain
>
>while (1)
> recv(...);
>
>And maximum throughput was reached because task
>never called scheduler...
Sometimes I think it might be nice to run without
an OS at all :-)
We are looking at various kernel bypass approaches
for receiving packets and it's in my mind that
one of these may get us to running on newer
kernels without giving up performance.
>I see nothing obvious in the profile but userland
>processing, futex calls.
Indeed, this is from the app-internal queuing
I mentioned in the last post. Because UDP is
presently unusable in any .32 or .39 kernel
I'm stuck with using packet sockets as a proxy
for them. As mentioned, the two produce very
similar results in all past tests.
>Network processing seems to account less than 10%
>of total cpu... All this sounds more a process
>scheduling regression than a network stack one..
Interesting. When I start testing kernel bypass
the degree to which this is the case should become
clear.
>On new kernels, you can check if your udp sockets
>drops frames because of rcvbuffer being full (cat
>/proc/net/udp, check last column 'drops')
As I've stated several times, all these tests are
run with verifiable zero data loss. The max-load
test is the highest rate were zero data loss can
be maintained. UDP socket buffers are set to 64MB.
>To check if softirq processing hit some limits :
>cat /proc/net/softnet_stat
Ok.
>Please send full "dmesg" output
Ok.
At 07:47 AM 10/2/2011 -0700, Stephen Hemminger wrote:
>Try disabling PCI DMA remapping. The additional
>overhead of setting up IO mapping can be a
>performance buzz kill. Try CONGIG_DMAR=n
Definitely. Thanks for the tip!
-----
Probably won't get to these until Monday or
Tuesday.
^ permalink raw reply
* Re: Fwd: wrong VENDOR_ID 10ac
From: Ben Hutchings @ 2011-10-02 15:14 UTC (permalink / raw)
To: Christian Vasquez Perales; +Cc: netdev
In-Reply-To: <CAPZBsTg_UjUGuNFbyh+D31swOaQSdA_U9Apx8z6oQsrSNe3ohw@mail.gmail.com>
On Sun, 2011-10-02 at 06:31 +0100, Christian Vasquez Perales wrote:
> Hello,
>
> May be you can help me, I have bought 2 identical trendnet TEG-PCITXR
> gigabit cards, and my centos has detected automatically just 1 of the
> 2 cards and this card is working fine with the driver r8169, but the
> other is not recognized,
>
> As per my investigation, the VENDOR_ID in the wrong card is 10ac, and
> it must to be 10ec (according the PCI database), please see the
> attached with the output from lspci and setpci,
>
> Could you give me some ideas? or do you know how to change the
> Vendor_ID in a network card?
[...]
There's no generic way to do this. I suggest you return the faulty card
for a refund/replacement; there is quite possibly more wrong with it
than this one-bit error.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* 802.11u/HotStop 2.0 on Linux
From: Eduardo Panisset @ 2011-10-02 18:11 UTC (permalink / raw)
To: netdev
Hi Guys,
I'm taking part in a project that intends to use Flow Mobility
(RFC6089) over GPRS and wifi based on HotSpot 2.0/802.11u
specification.
The devices to be used are both running Linux kernel 2.6.32 and using
wifi hardware based on chipsets wl1271 and wl1273 from Texas
Instruments.
Do you know if there is any device driver/firmware based on 802.11u
for those devices ? if there isn't, how should be the better way to
get an implementation done ?
Rgds,
Eduardo Panisset.
^ permalink raw reply
* Re: How to use macvtap/macvlan correctly
From: Chris Webb @ 2011-10-02 19:46 UTC (permalink / raw)
To: qemu-devel, netdev
In-Reply-To: <20110930084935.GC12879@arachsys.com>
Chris Webb <chris@arachsys.com> writes:
> I'm trying to get bridge-mode communication between a macvtap and a host
> macvlan working correctly, but I think I must be doing something wrong as
> the host macvlan and guest macvtap apparently can't communicate. I'm aware
> that the underlying eth0 interface can't communicate with the macvtap, but I
> thought that creating a host macvlan device and configuring that was the
> standard work-around?
This turns out to be a bug in the kernel I'm using, 3.0.4, fixed by this
patch:
http://patchwork.ozlabs.org/patch/115273/
Cheers,
Chris.
^ permalink raw reply
* Re: [PATCH v2] tcp: properly handle md5sig_pool references
From: David Miller @ 2011-10-03 0:33 UTC (permalink / raw)
To: zheng.z.yan; +Cc: netdev
In-Reply-To: <4E853312.1050107@intel.com>
From: "Yan, Zheng" <zheng.z.yan@intel.com>
Date: Fri, 30 Sep 2011 11:10:10 +0800
> tcp_v4_clear_md5_list() assumes that multiple tcp md5sig peers
> only hold one reference to md5sig_pool. but tcp_v4_md5_do_add()
> increases use count of md5sig_pool for each peer. This patch
> makes tcp_v4_md5_do_add() only increases use count for the first
> tcp md5sig peer.
>
> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3] tcp: properly update lost_cnt_hint during shifting
From: David Miller @ 2011-10-03 0:33 UTC (permalink / raw)
To: zheng.z.yan; +Cc: netdev, ilpo.jarvinen, nanditad, ycheng
In-Reply-To: <4E88737E.5030906@intel.com>
From: "Yan, Zheng" <zheng.z.yan@intel.com>
Date: Sun, 02 Oct 2011 22:21:50 +0800
> lost_skb_hint is used by tcp_mark_head_lost() to mark the first unhandled skb.
> lost_cnt_hint is the number of packets or sacked packets before the lost_skb_hint;
> When shifting a skb that is before the lost_skb_hint, if tcp_is_fack() is ture,
> the skb has already been counted in the lost_cnt_hint; if tcp_is_fack() is false,
> tcp_sacktag_one() will increase the lost_cnt_hint. So tcp_shifted_skb() does not
> need to adjust the lost_cnt_hint by itself. When shifting a skb that is equal to
> lost_skb_hint, the shifted packets will not be counted by tcp_mark_head_lost().
> So tcp_shifted_skb() should adjust the lost_cnt_hint even tcp_is_fack(tp) is true.
>
> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: macvlan/macvtap patch in patchwork
From: David Miller @ 2011-10-03 0:33 UTC (permalink / raw)
To: david.ward; +Cc: kaber, netdev, herbert, krkumar2
In-Reply-To: <4E825804.2010603@ll.mit.edu>
From: "Ward, David - 0663 - MITLL" <david.ward@ll.mit.edu>
Date: Tue, 27 Sep 2011 19:11:00 -0400
> The problem is that I was forwarding the frame to the lowerdev the
> wrong way, by calling vlan->forward which serves a different purpose.
> vlan->forward points to dev_forward_skb for macvlan (so the forwarding
> works fine), but it points to macvtap_forward for macvtap (which
> causes an oops when called here). We need to always use
> dev_forward_skb to forward to a lowerdev.
Thanks for explaining, patch applied.
^ permalink raw reply
* Re: [PATCH 01/15] add Documentation/namespaces/user_namespace.txt (v3)
From: Eric W. Biederman @ 2011-10-03 1:46 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Vasiliy Kulikov, Serge Hallyn, akpm, linux-kernel, netdev,
containers, dhowells, rdunlap, kernel-hardening
In-Reply-To: <20111001170047.GA2935@sergelap>
"Serge E. Hallyn" <serge.hallyn@canonical.com> writes:
> Quoting Vasiliy Kulikov (segoon@openwall.com):
>> On Tue, Sep 27, 2011 at 08:21 -0500, Serge E. Hallyn wrote:
>> > > First, the patches by design expose much kernel code to unprivileged
>> > > userspace processes. This code doesn't expect malformed data (e.g. VFS,
>> > > specific filesystems, block layer, char drivers, sysadmin part of LSMs,
>> > > etc. etc.). By relaxing permission rules you greatly increase attack
>> > > surface of the kernel from unprivileged users. Are you (or somebody
>> > > else) planning to audit this code?
Well in theory this codes does expose this code to unprivileged user
space in a way that increases the attack surface. However right now
there are a lot of cases where because the kernel lacks a sufficient
mechanism people are just given root provileges so that can get things
done. Network manager controlling the network stack as an unprivileged
user. Random filesystems on usb sticks being mounted and unmounted
automatically when the usb sticks are inserted and removed.
I completely agree that auditing and looking at the code is necessary I
think most of what will happen is that we will start directly supporting
how the kernel is actually used in the real world. Which should
actually reduce our level of vulnerability, because we give up the
delusion that large classes of operations don't need careful
attention because only root can perform them. Operations which the
user space authors turn around and write a suid binary for and
unprivileged user space performs those operations all day long.
>> > I had wanted to (but didn't) propose a discussion at ksummit about how
>> > best to approach the filesystem code. That's not even just for user
>> > namespaces - patches have been floated in the past to make mount an
>> > unprivileged operation depending on the FS and the user's permission
>> > over the device and target.
>>
>> This is a dangerous operation by itself.
>
> Of course it is :) And it's been a while since it has been brought up,
> but it *was* quite well thought through and throrougly discussed - see
> i.e. https://lkml.org/lkml/2008/1/8/131
>
> Oh, that's right. In the end the reason it didn't go in had to do with
> the ability for an unprivileged user to prevent a privileged user from
> unmounting trees by leaving a busy mount in a hidden namespace.
>
> Eric, in the past we didn't know what to do about that, but I wonder
> if setns could be used in some clever way to solve it from userspace.
Oh. That is a good objection. I had not realized that unprivileged
mounts had that problem.
Still the solution is straight forward. If the concern is that an
unprivileged user can prevent a privileged user from unmounting trees,
we need to require that a forced unmount of the filesystem triggers a
revoke on all open files. sysfs and proc already support revoke at the
per file level so we can safely remove modules, we just need to extend
that support to the forced unmount case.
This is problem that actually needs to be solved for ordinary file
systems as well because of hot pluggable usb drives. For filesystems
like ext4 it is more difficult because we need a solution that does
not sacrafice performance in the common case. I was talking to
Ted Tso a bit about this at plumbers conf. It happens that hot unplug
of usb devices with mount filesystems are currently a non-ending source
of subtle bugs in the extN code.
The one implementation detail that sounds a bit trick is what to do
about mount structures in mount namespaces when we forcibly unmount
a filesystem. That could get a bit complicated but if that is the only
hang up I'm certain we can figure something out.
Eric
^ permalink raw reply
* Re: [net-next 1/9] igb: Update RXDCTL/TXDCTL configurations
From: Arnaud Lacombe @ 2011-10-03 1:47 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Jeff Kirsher, davem, netdev, gospo
In-Reply-To: <4E84E344.2090201@intel.com>
Hi,
On Thu, Sep 29, 2011 at 5:29 PM, Alexander Duyck
<alexander.h.duyck@intel.com> wrote:
> This is due to a HW errata. Specifically HW errata 26 in the spec update at
> http://download.intel.com/design/network/specupdt/82576_SPECUPDATE.pdf.
>
> It essentially states that write back does not occur on MSI-X interrupt
> events so we need to keep WTHRESH at 1 in order to avoid any false hangs.
>
Could it be possible in the future to include this kind of information
in the commit log ? That might always be useful in a few years when
trying to understand why the code has such or such limitation.
Thanks!
- Arnaud
> Thanks,
>
> Alex
>
> On 09/29/2011 10:41 AM, Arnaud Lacombe wrote:
>>
>> Hi,
>>
>> On Tue, Sep 20, 2011 at 3:11 AM, Jeff Kirsher
>> <jeffrey.t.kirsher@intel.com> wrote:
>>>
>>> From: Alexander Duyck<alexander.h.duyck@intel.com>
>>>
>>> This change cleans up the RXDCTL and TXDCTL configurations and optimizes
>>> RX
>>> performance by allowing back write-backs on all hardware other than
>>> 82576.
>>>
>> Where does this limitation comes from ? The "Intel 82576EB GbE
>> Controller - Programming Interface" from May 2011 advertises that both
>> the RXDCTL and TXDCTL register have a 5bit wide WTHRESH field.
>>
>> Thanks,
>> - Arnaud
>>
>>> Signed-off-by: Alexander Duyck<alexander.h.duyck@intel.com>
>>> Tested-by: Aaron Brown<aaron.f.brown@intel.com>
>>> Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
>>> ---
>>> drivers/net/ethernet/intel/igb/igb.h | 5 +++--
>>> drivers/net/ethernet/intel/igb/igb_main.c | 23 +++++++++--------------
>>> 2 files changed, 12 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/intel/igb/igb.h
>>> b/drivers/net/ethernet/intel/igb/igb.h
>>> index 265e151..577fd3e 100644
>>> --- a/drivers/net/ethernet/intel/igb/igb.h
>>> +++ b/drivers/net/ethernet/intel/igb/igb.h
>>> @@ -100,11 +100,12 @@ struct vf_data_storage {
>>> */
>>> #define IGB_RX_PTHRESH 8
>>> #define IGB_RX_HTHRESH 8
>>> -#define IGB_RX_WTHRESH 1
>>> #define IGB_TX_PTHRESH 8
>>> #define IGB_TX_HTHRESH 1
>>> +#define IGB_RX_WTHRESH ((hw->mac.type ==
>>> e1000_82576&& \
>>> + adapter->msix_entries) ? 1 :
>>> 4)
>>> #define IGB_TX_WTHRESH ((hw->mac.type ==
>>> e1000_82576&& \
>>> - adapter->msix_entries) ? 1
>>> : 16)
>>> + adapter->msix_entries) ? 1 :
>>> 16)
>>>
>>> /* this is the size past which hardware will drop packets when setting
>>> LPE=0 */
>>> #define MAXIMUM_ETHERNET_VLAN_SIZE 1522
>>> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
>>> b/drivers/net/ethernet/intel/igb/igb_main.c
>>> index 3cb1bc9..aa78c10 100644
>>> --- a/drivers/net/ethernet/intel/igb/igb_main.c
>>> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
>>> @@ -2666,14 +2666,12 @@ void igb_configure_tx_ring(struct igb_adapter
>>> *adapter,
>>> struct igb_ring *ring)
>>> {
>>> struct e1000_hw *hw =&adapter->hw;
>>> - u32 txdctl;
>>> + u32 txdctl = 0;
>>> u64 tdba = ring->dma;
>>> int reg_idx = ring->reg_idx;
>>>
>>> /* disable the queue */
>>> - txdctl = rd32(E1000_TXDCTL(reg_idx));
>>> - wr32(E1000_TXDCTL(reg_idx),
>>> - txdctl& ~E1000_TXDCTL_QUEUE_ENABLE);
>>> + wr32(E1000_TXDCTL(reg_idx), 0);
>>> wrfl();
>>> mdelay(10);
>>>
>>> @@ -2685,7 +2683,7 @@ void igb_configure_tx_ring(struct igb_adapter
>>> *adapter,
>>>
>>> ring->head = hw->hw_addr + E1000_TDH(reg_idx);
>>> ring->tail = hw->hw_addr + E1000_TDT(reg_idx);
>>> - writel(0, ring->head);
>>> + wr32(E1000_TDH(reg_idx), 0);
>>> writel(0, ring->tail);
>>>
>>> txdctl |= IGB_TX_PTHRESH;
>>> @@ -3028,12 +3026,10 @@ void igb_configure_rx_ring(struct igb_adapter
>>> *adapter,
>>> struct e1000_hw *hw =&adapter->hw;
>>> u64 rdba = ring->dma;
>>> int reg_idx = ring->reg_idx;
>>> - u32 srrctl, rxdctl;
>>> + u32 srrctl = 0, rxdctl = 0;
>>>
>>> /* disable the queue */
>>> - rxdctl = rd32(E1000_RXDCTL(reg_idx));
>>> - wr32(E1000_RXDCTL(reg_idx),
>>> - rxdctl& ~E1000_RXDCTL_QUEUE_ENABLE);
>>> + wr32(E1000_RXDCTL(reg_idx), 0);
>>>
>>> /* Set DMA base address registers */
>>> wr32(E1000_RDBAL(reg_idx),
>>> @@ -3045,7 +3041,7 @@ void igb_configure_rx_ring(struct igb_adapter
>>> *adapter,
>>> /* initialize head and tail */
>>> ring->head = hw->hw_addr + E1000_RDH(reg_idx);
>>> ring->tail = hw->hw_addr + E1000_RDT(reg_idx);
>>> - writel(0, ring->head);
>>> + wr32(E1000_RDH(reg_idx), 0);
>>> writel(0, ring->tail);
>>>
>>> /* set descriptor configuration */
>>> @@ -3076,13 +3072,12 @@ void igb_configure_rx_ring(struct igb_adapter
>>> *adapter,
>>> /* set filtering for VMDQ pools */
>>> igb_set_vmolr(adapter, reg_idx& 0x7, true);
>>>
>>> - /* enable receive descriptor fetching */
>>> - rxdctl = rd32(E1000_RXDCTL(reg_idx));
>>> - rxdctl |= E1000_RXDCTL_QUEUE_ENABLE;
>>> - rxdctl&= 0xFFF00000;
>>> rxdctl |= IGB_RX_PTHRESH;
>>> rxdctl |= IGB_RX_HTHRESH<< 8;
>>> rxdctl |= IGB_RX_WTHRESH<< 16;
>>> +
>>> + /* enable receive descriptor fetching */
>>> + rxdctl |= E1000_RXDCTL_QUEUE_ENABLE;
>>> wr32(E1000_RXDCTL(reg_idx), rxdctl);
>>> }
>>>
>>> --
>>> 1.7.6.2
>>>
>>> --
>>> 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
>>>
>> --
>> 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: GTSM and TCP accept problem
From: venkatesh natarajan @ 2011-10-03 1:46 UTC (permalink / raw)
To: netdev
In-Reply-To: <20100818.144837.179941999.davem@davemloft.net>
David Miller <davem <at> davemloft.net> writes:
>
> From: Stephen Hemminger <shemminger <at> vyatta.com>
> Date: Wed, 18 Aug 2010 14:39:13 -0700
>
> > On Mon, 16 Aug 2010 11:43:45 +0200
> > Eric Dumazet <eric.dumazet <at> gmail.com> wrote:
> >
> >> Another idea would be to store the TTL of the SYN packet (or third
> >> packet) and let application read it after accept(), allowing it to
> >> reject the connection if it doesnt match expected TTL.
> >
> > could be in tcp_info?
>
> I'm sure we can squeeze a byte out of there
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
I am facing the same issue with the implementation of GTSM for BGP. Typically
the outbound TTL value set is 64. With min_ttl implementaion we set the outbound
TTL value of 255 by default. So all bgp speakers will send out 255 in their
connect SYN packets. Lets say we configure the min_ttl of 254 on the listen
socket then it will allow only those peers that are 2 hops away to connect
(Which is correct for eBGP Peers) but it will also filter out legitimate connect
SYN packets that come from iBGP peers that are more than 2 hops away (Which I
feel is a unexpected behavior).
How can accept check for iBGP peers and not check for the MIN_TTL. I feel this
could be done only by pushing the iBGP Peer ip-address information to accept so
that it can bypass MIN_TTL Checks for them.
If I apply the MIN_TTL setsockopt on the accepted socket (Instead of seting it
on the listen socket) then I open up the port for DOS attack at the tcp level by
allowing attackers to establish connection and repeatedly..
Have I understood the problem correctly or have gone off-tangent on this.
Thanks
Venks
^ permalink raw reply
* x25: remote-triggerable heap overflow in call user data processing
From: matt d @ 2011-10-03 3:23 UTC (permalink / raw)
To: netdev
Refer to the x25 packet layer's handling of incoming call user data,
namely at these two locations, in x25_rx_call_request and
x25_state1_machine:
https://github.com/mirrors/linux/blob/master/net/x25/af_x25.c#L1039
https://github.com/mirrors/linux/blob/master/net/x25/x25_in.c#L126
Call user data from an incoming message is copied into
(make)x25->calluserdata.cuddata buffers, which are 128 bytes long.
However, the length copied is based on the remaining message length,
and is not limited to the output buffer size. This allows a remote
attacker to overflow data onto the heap.
There is an appropriate constant defined for the length, but it
seemingly isn't used there:
https://github.com/mirrors/linux/blob/master/include/net/x25.h#L104
It seems this issue was noticed some time ago:
http://www.spinics.net/lists/linux-x25/msg00043.html
http://patchwork.ozlabs.org/patch/23917/
...however nothing was done about the bigger problem.
I have written a simple exploit for this vulnerability if it needs to
be posted, however I think the problem is pretty straightforward to
see as-is.
- Matthew Daley
^ permalink raw reply
* Re: x25: remote-triggerable heap overflow in call user data processing
From: Eric Dumazet @ 2011-10-03 5:45 UTC (permalink / raw)
To: matt d; +Cc: netdev
In-Reply-To: <CA+nUz_K-mWFbFbSGKDFDGUufQmDA9+qW-0=1BDJ9QGe2Dxi-3w@mail.gmail.com>
Le lundi 03 octobre 2011 à 16:23 +1300, matt d a écrit :
> Refer to the x25 packet layer's handling of incoming call user data,
> namely at these two locations, in x25_rx_call_request and
> x25_state1_machine:
> https://github.com/mirrors/linux/blob/master/net/x25/af_x25.c#L1039
> https://github.com/mirrors/linux/blob/master/net/x25/x25_in.c#L126
>
> Call user data from an incoming message is copied into
> (make)x25->calluserdata.cuddata buffers, which are 128 bytes long.
> However, the length copied is based on the remaining message length,
> and is not limited to the output buffer size. This allows a remote
> attacker to overflow data onto the heap.
>
> There is an appropriate constant defined for the length, but it
> seemingly isn't used there:
> https://github.com/mirrors/linux/blob/master/include/net/x25.h#L104
>
> It seems this issue was noticed some time ago:
> http://www.spinics.net/lists/linux-x25/msg00043.html
> http://patchwork.ozlabs.org/patch/23917/
> ...however nothing was done about the bigger problem.
>
> I have written a simple exploit for this vulnerability if it needs to
> be posted, however I think the problem is pretty straightforward to
> see as-is.
Please send a patch, it seems you have everything done to do it
properly ;)
^ permalink raw reply
* Re: x25: remote-triggerable heap overflow in call user data processing
From: Andrew Hendry @ 2011-10-03 6:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: matt d, netdev
In-Reply-To: <1317620731.3802.50.camel@edumazet-laptop>
x25_in.c looks straightforward.
with af_x25.c we might want to move the incoming call user data check
before the call accept block above.
Otherwise it could send call accept/call clear right next to each
other and it might get bad state
On Mon, Oct 3, 2011 at 4:45 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 03 octobre 2011 à 16:23 +1300, matt d a écrit :
>> Refer to the x25 packet layer's handling of incoming call user data,
>> namely at these two locations, in x25_rx_call_request and
>> x25_state1_machine:
>> https://github.com/mirrors/linux/blob/master/net/x25/af_x25.c#L1039
>> https://github.com/mirrors/linux/blob/master/net/x25/x25_in.c#L126
>>
>> Call user data from an incoming message is copied into
>> (make)x25->calluserdata.cuddata buffers, which are 128 bytes long.
>> However, the length copied is based on the remaining message length,
>> and is not limited to the output buffer size. This allows a remote
>> attacker to overflow data onto the heap.
>>
>> There is an appropriate constant defined for the length, but it
>> seemingly isn't used there:
>> https://github.com/mirrors/linux/blob/master/include/net/x25.h#L104
>>
>> It seems this issue was noticed some time ago:
>> http://www.spinics.net/lists/linux-x25/msg00043.html
>> http://patchwork.ozlabs.org/patch/23917/
>> ...however nothing was done about the bigger problem.
>>
>> I have written a simple exploit for this vulnerability if it needs to
>> be posted, however I think the problem is pretty straightforward to
>> see as-is.
>
> Please send a patch, it seems you have everything done to do it
> properly ;)
>
>
>
> --
> 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] w5300: add WIZnet W5300 Ethernet driver
From: Taehun Kim @ 2011-10-03 9:15 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, linux-kernel
In-Reply-To: <20110927174523.GA12600@electric-eye.fr.zoreil.com>
2011/9/28 Francois Romieu <romieu@fr.zoreil.com>:
>> +/* Opening channels of W5300 */
>> +static int
>> +w5300_open(struct wiz_private *wp, u32 type)
>
> Name it w5300_channel_open or more adequately w5300_channel_0_open
> as it is hardwired to channel 0 ?
The W5300 Ethernet function is only available in channel 0. The other channels
(1~7) is used hardwired TCP/IP stack.
I was limited to the Ethernet function in this driver because hardwired TCP/IP
stack to use the TCP/IP stack in linux kernel be modified.
>> + int s;
>> +
>> + isr = w5300_read(wp, IR);
>> +
>> + /* Completing all interrupts at a time. */
>> + while (isr) {
>> + w5300_write(wp, IR, isr);
>> +
>> + /* Finding the channel to create the interrupt */
>> + s = find_first_bit(&isr, sizeof(u16));
>> + ssr = w5300_read(wp, Sn_IR(s));
>> + /* socket interrupt is cleared. */
>> + w5300_write(wp, Sn_IR(s), ssr);
>> + DPRINTK("%s: ISR = %X, SSR = %X, s = %X\n",
>> + __func__, isr, ssr, s);
>> + if (likely(!s)) {
>> + if (ssr & Sn_IR_RECV) {
>> + /* De-activation of interrupt */
>> + w5300_interrupt_disable(wp, 0);
>> + /* Receiving by polling method */
>> + napi_schedule(&wp->napi);
>> + }
>> + }
>> +
>> + /* Is there any interrupt to be processed? */
>> + isr = w5300_read(wp, IR);
>> + }
>> +
>> + return IRQ_HANDLED;
>
> The hardware implementation is supposed to enforce that the 'while' is
> always entered, right ?
>
If isr is 0, it is to ensure that the W5300 is received an interrupt responses.
You mean that there is a need to the loop exit routine. right?
Thank you for your detailed feedback.
I will rewrite the driver code by applied your feedback. When the work is
completed, I will suggest the rewritten driver code to this thread.
Thank you.
T.K.
^ permalink raw reply
* [PATCH v4 0/8] per-cgroup tcp buffer pressure settings
From: Glauber Costa @ 2011-10-03 10:18 UTC (permalink / raw)
To: linux-kernel
Cc: paul, lizf, kamezawa.hiroyu, ebiederm, davem, gthelen, netdev,
linux-mm, kirill, avagin
[[ v3: merge Kirill's suggestions, + a destroy-related bugfix ]]
[[ v4: Fix a bug with non-mounted cgroups + disallow task movement ]]
This patch introduces per-cgroup tcp buffers limitation. This allows
sysadmins to specify a maximum amount of kernel memory that
tcp connections can use at any point in time. TCP is the main interest
in this work, but extending it to other protocols would be easy.
For this to work, I am hooking it into memcg, after the introdution of
an extension for tracking and controlling objects in kernel memory.
Since they are usually not found in page granularity, and are fundamentally
different from userspace memory (not swappable, can't overcommit), they
need their special place inside the Memory Controller.
Right now, the kmem extension is quite basic, and just lays down the
basic infrastucture for the ongoing work.
Although it does not account kernel memory allocated - I preferred to
keep this series simple and leave accounting to the slab allocations when
they arrive.
What it does is to piggyback in the memory control mechanism already present in
/proc/sys/net/ipv4/tcp_mem. There is a soft limit, and a hard limit,
that will suppress allocation when reached. For each non-root cgroup, however,
the file kmem.tcp_maxmem will be used to cap those values.
The usage I have in mind here is containers. Each container will
define its own values for soft and hard limits, but none of them will
be possibly bigger than the value the box' sysadmin specified from
the outside.
To test for any performance impacts of this patch, I used netperf's
TCP_RR benchmark on localhost, so we can have both recv and snd in action.
For this iteration, I am using the 1% confidence interval as suggested by Rick.
Command line used was ./src/netperf -t TCP_RR -H localhost -i 30,3 -I 99,1 and the
results:
Without the patch
=================
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 1 1 10.00 35356.22
16384 87380
With the patch
==============
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 1 1 10.00 35399.12
16384 87380
The difference is less than 0.5 %
A simple test with a 1000 level nesting yields more or less the same
difference:
1000 level nesting
==================
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 1 1 10.00 35304.35
16384 87380
Glauber Costa (8):
Basic kernel memory functionality for the Memory Controller
socket: initial cgroup code.
foundations of per-cgroup memory pressure controlling.
per-cgroup tcp buffers control
per-netns ipv4 sysctl_tcp_mem
tcp buffer limitation: per-cgroup limit
Display current tcp memory allocation in kmem cgroup
Disable task moving when using kernel memory accounting
Documentation/cgroups/memory.txt | 32 +++-
crypto/af_alg.c | 7 +-
include/linux/memcontrol.h | 56 ++++++
include/net/netns/ipv4.h | 1 +
include/net/sock.h | 127 +++++++++++++-
include/net/tcp.h | 29 +++-
include/net/udp.h | 3 +-
include/trace/events/sock.h | 10 +-
init/Kconfig | 11 ++
mm/memcontrol.c | 360 ++++++++++++++++++++++++++++++++++++--
net/core/sock.c | 104 ++++++++---
net/decnet/af_decnet.c | 21 ++-
net/ipv4/proc.c | 7 +-
net/ipv4/sysctl_net_ipv4.c | 71 +++++++-
net/ipv4/tcp.c | 58 ++++---
net/ipv4/tcp_input.c | 12 +-
net/ipv4/tcp_ipv4.c | 24 ++-
net/ipv4/tcp_output.c | 2 +-
net/ipv4/tcp_timer.c | 2 +-
net/ipv4/udp.c | 20 ++-
net/ipv6/tcp_ipv6.c | 20 ++-
net/ipv6/udp.c | 4 +-
net/sctp/socket.c | 35 +++-
23 files changed, 883 insertions(+), 133 deletions(-)
--
1.7.6
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ 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