* 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
* [PATCH v4 1/8] Basic kernel memory functionality for the Memory Controller
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, Glauber Costa
In-Reply-To: <1317637123-18306-1-git-send-email-glommer@parallels.com>
This patch lays down the foundation for the kernel memory component
of the Memory Controller.
As of today, I am only laying down the following files:
* memory.independent_kmem_limit
* memory.kmem.limit_in_bytes (currently ignored)
* memory.kmem.usage_in_bytes (always zero)
Signed-off-by: Glauber Costa <glommer@parallels.com>
CC: Paul Menage <paul@paulmenage.org>
CC: Greg Thelen <gthelen@google.com>
---
Documentation/cgroups/memory.txt | 30 +++++++++++-
init/Kconfig | 11 ++++
mm/memcontrol.c | 94 +++++++++++++++++++++++++++++++++++---
3 files changed, 126 insertions(+), 9 deletions(-)
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index 6f3c598..6f1954a 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -44,8 +44,9 @@ Features:
- oom-killer disable knob and oom-notifier
- Root cgroup has no limit controls.
- Kernel memory and Hugepages are not under control yet. We just manage
- pages on LRU. To add more controls, we have to take care of performance.
+ Hugepages is not under control yet. We just manage pages on LRU. To add more
+ controls, we have to take care of performance. Kernel memory support is work
+ in progress, and the current version provides basically functionality.
Brief summary of control files.
@@ -56,8 +57,11 @@ Brief summary of control files.
(See 5.5 for details)
memory.memsw.usage_in_bytes # show current res_counter usage for memory+Swap
(See 5.5 for details)
+ memory.kmem.usage_in_bytes # show current res_counter usage for kmem only.
+ (See 2.7 for details)
memory.limit_in_bytes # set/show limit of memory usage
memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
+ memory.kmem.limit_in_bytes # if allowed, set/show limit of kernel memory
memory.failcnt # show the number of memory usage hits limits
memory.memsw.failcnt # show the number of memory+Swap hits limits
memory.max_usage_in_bytes # show max memory usage recorded
@@ -72,6 +76,9 @@ Brief summary of control files.
memory.oom_control # set/show oom controls.
memory.numa_stat # show the number of memory usage per numa node
+ memory.independent_kmem_limit # select whether or not kernel memory limits are
+ independent of user limits
+
1. History
The memory controller has a long history. A request for comments for the memory
@@ -255,6 +262,25 @@ When oom event notifier is registered, event will be delivered.
per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
zone->lru_lock, it has no lock of its own.
+2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)
+
+ With the Kernel memory extension, the Memory Controller is able to limit
+the amount of kernel memory used by the system. Kernel memory is fundamentally
+different than user memory, since it can't be swapped out, which makes it
+possible to DoS the system by consuming too much of this precious resource.
+Kernel memory limits are not imposed for the root cgroup.
+
+Memory limits as specified by the standard Memory Controller may or may not
+take kernel memory into consideration. This is achieved through the file
+memory.independent_kmem_limit. A Value different than 0 will allow for kernel
+memory to be controlled separately.
+
+When kernel memory limits are not independent, the limit values set in
+memory.kmem files are ignored.
+
+Currently no soft limit is implemented for kernel memory. It is future work
+to trigger slab reclaim when those limits are reached.
+
3. User Interface
0. Configuration
diff --git a/init/Kconfig b/init/Kconfig
index d627783..908220e 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -689,6 +689,17 @@ config CGROUP_MEM_RES_CTLR_SWAP_ENABLED
For those who want to have the feature enabled by default should
select this option (if, for some reason, they need to disable it
then swapaccount=0 does the trick).
+config CGROUP_MEM_RES_CTLR_KMEM
+ bool "Memory Resource Controller Kernel Memory accounting (EXPERIMENTAL)"
+ depends on CGROUP_MEM_RES_CTLR && EXPERIMENTAL
+ default y
+ help
+ The Kernel Memory extension for Memory Resource Controller can limit
+ the amount of memory used by kernel objects in the system. Those are
+ fundamentally different from the entities handled by the standard
+ Memory Controller, which are page-based, and can be swapped. Users of
+ the kmem extension can use it to guarantee that no group of processes
+ will ever exhaust kernel resources alone.
config CGROUP_PERF
bool "Enable perf_event per-cpu per-container group (cgroup) monitoring"
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index ebd1e86..8aaf4ce 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -72,8 +72,6 @@ static int really_do_swap_account __initdata = 0;
#else
#define do_swap_account (0)
#endif
-
-
/*
* Statistics for memory cgroup.
*/
@@ -270,6 +268,10 @@ struct mem_cgroup {
*/
struct res_counter memsw;
/*
+ * the counter to account for kmem usage.
+ */
+ struct res_counter kmem;
+ /*
* Per cgroup active and inactive list, similar to the
* per zone LRU lists.
*/
@@ -321,6 +323,11 @@ struct mem_cgroup {
*/
unsigned long move_charge_at_immigrate;
/*
+ * Should kernel memory limits be stabilished independently
+ * from user memory ?
+ */
+ int kmem_independent_accounting;
+ /*
* percpu counter.
*/
struct mem_cgroup_stat_cpu *stat;
@@ -388,9 +395,14 @@ enum charge_type {
};
/* for encoding cft->private value on file */
-#define _MEM (0)
-#define _MEMSWAP (1)
-#define _OOM_TYPE (2)
+
+enum mem_type {
+ _MEM = 0,
+ _MEMSWAP,
+ _OOM_TYPE,
+ _KMEM,
+};
+
#define MEMFILE_PRIVATE(x, val) (((x) << 16) | (val))
#define MEMFILE_TYPE(val) (((val) >> 16) & 0xffff)
#define MEMFILE_ATTR(val) ((val) & 0xffff)
@@ -3943,10 +3955,15 @@ static inline u64 mem_cgroup_usage(struct mem_cgroup *mem, bool swap)
u64 val;
if (!mem_cgroup_is_root(mem)) {
+ val = 0;
+ if (!mem->kmem_independent_accounting)
+ val = res_counter_read_u64(&mem->kmem, RES_USAGE);
if (!swap)
- return res_counter_read_u64(&mem->res, RES_USAGE);
+ val += res_counter_read_u64(&mem->res, RES_USAGE);
else
- return res_counter_read_u64(&mem->memsw, RES_USAGE);
+ val += res_counter_read_u64(&mem->memsw, RES_USAGE);
+
+ return val;
}
val = mem_cgroup_recursive_stat(mem, MEM_CGROUP_STAT_CACHE);
@@ -3979,6 +3996,10 @@ static u64 mem_cgroup_read(struct cgroup *cont, struct cftype *cft)
else
val = res_counter_read_u64(&mem->memsw, name);
break;
+ case _KMEM:
+ val = res_counter_read_u64(&mem->kmem, name);
+ break;
+
default:
BUG();
break;
@@ -4756,6 +4777,21 @@ static int mem_cgroup_reset_vmscan_stat(struct cgroup *cgrp,
return 0;
}
+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
+static u64 kmem_limit_independent_read(struct cgroup *cont, struct cftype *cft)
+{
+ return mem_cgroup_from_cont(cont)->kmem_independent_accounting;
+}
+
+static int kmem_limit_independent_write(struct cgroup *cont, struct cftype *cft,
+ u64 val)
+{
+ cgroup_lock();
+ mem_cgroup_from_cont(cont)->kmem_independent_accounting = !!val;
+ cgroup_unlock();
+ return 0;
+}
+#endif
static struct cftype mem_cgroup_files[] = {
{
@@ -4877,6 +4913,44 @@ static int register_memsw_files(struct cgroup *cont, struct cgroup_subsys *ss)
}
#endif
+
+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
+static struct cftype kmem_cgroup_files[] = {
+ {
+ .name = "independent_kmem_limit",
+ .read_u64 = kmem_limit_independent_read,
+ .write_u64 = kmem_limit_independent_write,
+ },
+ {
+ .name = "kmem.usage_in_bytes",
+ .private = MEMFILE_PRIVATE(_KMEM, RES_USAGE),
+ .read_u64 = mem_cgroup_read,
+ },
+ {
+ .name = "kmem.limit_in_bytes",
+ .private = MEMFILE_PRIVATE(_KMEM, RES_LIMIT),
+ .read_u64 = mem_cgroup_read,
+ },
+};
+
+static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
+{
+ struct mem_cgroup *mem = mem_cgroup_from_cont(cont);
+ int ret = 0;
+
+ if (!mem_cgroup_is_root(mem))
+ ret = cgroup_add_files(cont, ss, kmem_cgroup_files,
+ ARRAY_SIZE(kmem_cgroup_files));
+ return ret;
+};
+
+#else
+static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
+{
+ return 0;
+}
+#endif
+
static int alloc_mem_cgroup_per_zone_info(struct mem_cgroup *mem, int node)
{
struct mem_cgroup_per_node *pn;
@@ -5075,6 +5149,7 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
if (parent && parent->use_hierarchy) {
res_counter_init(&mem->res, &parent->res);
res_counter_init(&mem->memsw, &parent->memsw);
+ res_counter_init(&mem->kmem, &parent->kmem);
/*
* We increment refcnt of the parent to ensure that we can
* safely access it on res_counter_charge/uncharge.
@@ -5085,6 +5160,7 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
} else {
res_counter_init(&mem->res, NULL);
res_counter_init(&mem->memsw, NULL);
+ res_counter_init(&mem->kmem, NULL);
}
mem->last_scanned_child = 0;
mem->last_scanned_node = MAX_NUMNODES;
@@ -5129,6 +5205,10 @@ static int mem_cgroup_populate(struct cgroup_subsys *ss,
if (!ret)
ret = register_memsw_files(cont, ss);
+
+ if (!ret)
+ ret = register_kmem_files(cont, ss);
+
return ret;
}
--
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 related
* [PATCH v4 2/8] socket: initial cgroup code.
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, Glauber Costa
In-Reply-To: <1317637123-18306-1-git-send-email-glommer@parallels.com>
We aim to control the amount of kernel memory pinned at any
time by tcp sockets. To lay the foundations for this work,
this patch adds a pointer to the kmem_cgroup to the socket
structure.
Signed-off-by: Glauber Costa <glommer@parallels.com>
CC: David S. Miller <davem@davemloft.net>
CC: Hiroyouki Kamezawa <kamezawa.hiroyu@jp.fujitsu.com>
CC: Eric W. Biederman <ebiederm@xmission.com>
---
include/linux/memcontrol.h | 15 +++++++++++++++
include/net/sock.h | 2 ++
mm/memcontrol.c | 33 +++++++++++++++++++++++++++++++++
net/core/sock.c | 3 +++
4 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 3b535db..2cb9226 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -395,5 +395,20 @@ mem_cgroup_print_bad_page(struct page *page)
}
#endif
+#ifdef CONFIG_INET
+struct sock;
+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
+void sock_update_memcg(struct sock *sk);
+void sock_release_memcg(struct sock *sk);
+
+#else
+static inline void sock_update_memcg(struct sock *sk)
+{
+}
+static inline void sock_release_memcg(struct sock *sk)
+{
+}
+#endif /* CONFIG_CGROUP_MEM_RES_CTLR_KMEM */
+#endif /* CONFIG_INET */
#endif /* _LINUX_MEMCONTROL_H */
diff --git a/include/net/sock.h b/include/net/sock.h
index 8e4062f..afe1467 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -228,6 +228,7 @@ struct sock_common {
* @sk_security: used by security modules
* @sk_mark: generic packet mark
* @sk_classid: this socket's cgroup classid
+ * @sk_cgrp: this socket's kernel memory (kmem) cgroup
* @sk_write_pending: a write to stream socket waits to start
* @sk_state_change: callback to indicate change in the state of the sock
* @sk_data_ready: callback to indicate there is data to be processed
@@ -339,6 +340,7 @@ struct sock {
#endif
__u32 sk_mark;
u32 sk_classid;
+ struct mem_cgroup *sk_cgrp;
void (*sk_state_change)(struct sock *sk);
void (*sk_data_ready)(struct sock *sk, int bytes);
void (*sk_write_space)(struct sock *sk);
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 8aaf4ce..08a520e 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -339,6 +339,39 @@ struct mem_cgroup {
spinlock_t pcp_counter_lock;
};
+/* Writing them here to avoid exposing memcg's inner layout */
+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
+#ifdef CONFIG_INET
+#include <net/sock.h>
+
+void sock_update_memcg(struct sock *sk)
+{
+ /* right now a socket spends its whole life in the same cgroup */
+ BUG_ON(sk->sk_cgrp);
+
+ rcu_read_lock();
+ sk->sk_cgrp = mem_cgroup_from_task(current);
+
+ /*
+ * We don't need to protect against anything task-related, because
+ * we are basically stuck with the sock pointer that won't change,
+ * even if the task that originated the socket changes cgroups.
+ *
+ * What we do have to guarantee, is that the chain leading us to
+ * the top level won't change under our noses. Incrementing the
+ * reference count via cgroup_exclude_rmdir guarantees that.
+ */
+ cgroup_exclude_rmdir(mem_cgroup_css(sk->sk_cgrp));
+ rcu_read_unlock();
+}
+
+void sock_release_memcg(struct sock *sk)
+{
+ cgroup_release_and_wakeup_rmdir(mem_cgroup_css(sk->sk_cgrp));
+}
+#endif /* CONFIG_INET */
+#endif /* CONFIG_CGROUP_MEM_RES_CTLR_KMEM */
+
/* Stuffs for move charges at task migration. */
/*
* Types of charges to be moved. "move_charge_at_immitgrate" is treated as a
diff --git a/net/core/sock.c b/net/core/sock.c
index bc745d0..5426ba0 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -125,6 +125,7 @@
#include <net/xfrm.h>
#include <linux/ipsec.h>
#include <net/cls_cgroup.h>
+#include <linux/memcontrol.h>
#include <linux/filter.h>
@@ -1141,6 +1142,7 @@ struct sock *sk_alloc(struct net *net, int family, gfp_t priority,
atomic_set(&sk->sk_wmem_alloc, 1);
sock_update_classid(sk);
+ sock_update_memcg(sk);
}
return sk;
@@ -1172,6 +1174,7 @@ static void __sk_free(struct sock *sk)
put_cred(sk->sk_peer_cred);
put_pid(sk->sk_peer_pid);
put_net(sock_net(sk));
+ sock_release_memcg(sk);
sk_prot_free(sk->sk_prot_creator, sk);
}
--
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 related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox