* [PATCH net-next 06/28] tipc: Update obsolete references to multicast link
From: Paul Gortmaker @ 2011-09-18 3:32 UTC (permalink / raw)
To: davem; +Cc: netdev, allan.stephens, ying.xue, Paul Gortmaker
In-Reply-To: <1316316744-29514-1-git-send-email-paul.gortmaker@windriver.com>
From: Allan Stephens <allan.stephens@windriver.com>
Updates TIPC's broadcast link in a couple of places that were missed
during the transition from its former name ("multicast-link") to its
current name ("broadcast-link"). These changes are essentially cosmetic
and do not affect the overall operation of TIPC.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/bcast.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
index 759b318..411c54b 100644
--- a/net/tipc/bcast.c
+++ b/net/tipc/bcast.c
@@ -764,7 +764,7 @@ int tipc_bclink_init(void)
bcbearer = kzalloc(sizeof(*bcbearer), GFP_ATOMIC);
bclink = kzalloc(sizeof(*bclink), GFP_ATOMIC);
if (!bcbearer || !bclink) {
- warn("Multicast link creation failed, no memory\n");
+ warn("Broadcast link creation failed, no memory\n");
kfree(bcbearer);
bcbearer = NULL;
kfree(bclink);
@@ -775,7 +775,7 @@ int tipc_bclink_init(void)
INIT_LIST_HEAD(&bcbearer->bearer.cong_links);
bcbearer->bearer.media = &bcbearer->media;
bcbearer->media.send_msg = tipc_bcbearer_send;
- sprintf(bcbearer->media.name, "tipc-multicast");
+ sprintf(bcbearer->media.name, "tipc-broadcast");
bcl = &bclink->link;
INIT_LIST_HEAD(&bcl->waiting_ports);
--
1.7.4.4
^ permalink raw reply related
* [PATCH net-next 04/28] tipc: Initialize peer session field of newly created link endpoint
From: Paul Gortmaker @ 2011-09-18 3:32 UTC (permalink / raw)
To: davem; +Cc: netdev, allan.stephens, ying.xue, Paul Gortmaker
In-Reply-To: <1316316744-29514-1-git-send-email-paul.gortmaker@windriver.com>
From: Allan Stephens <allan.stephens@windriver.com>
Initializes the peer session number field of a newly created link
endpoint to an invalid value. This eliminates the remote possibility
that it will accidentally match the session number used by the peer
the first time the link is activated, and cause the link to ignore
a valid RESET message.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/link.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 4cb500b..e0bf6d5 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -341,6 +341,7 @@ struct link *tipc_link_create(struct tipc_node *n_ptr,
memcpy(&l_ptr->media_addr, media_addr, sizeof(*media_addr));
l_ptr->owner = n_ptr;
l_ptr->checkpoint = 1;
+ l_ptr->peer_session = INVALID_SESSION;
l_ptr->b_ptr = b_ptr;
link_set_supervision_props(l_ptr, b_ptr->media->tolerance);
l_ptr->state = RESET_UNKNOWN;
--
1.7.4.4
^ permalink raw reply related
* [PATCH net-next 05/28] tipc: Enhance filtering of out-dated link reset messages
From: Paul Gortmaker @ 2011-09-18 3:32 UTC (permalink / raw)
To: davem; +Cc: netdev, allan.stephens, ying.xue, Paul Gortmaker
In-Reply-To: <1316316744-29514-1-git-send-email-paul.gortmaker@windriver.com>
From: Allan Stephens <allan.stephens@windriver.com>
Ensure TIPC ignores an out-dated link reset message whose session
number predates the current session number. (Previously, TIPC only
ignored an out-date reset message whose session number was equal
to the current link session number.)
Out-dated link reset messages should not occur under normal circumstances;
however, they can be generated if a link endpoint is unable to send a
link reset message right away and queues it for later delivery, but the
queued message is not sent until after the link is established.
Thanks to Laser [gotolaser@gmail.com] for diagnosing the problem and
contributing a prototype patch.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/link.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index e0bf6d5..b43beea 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -2045,8 +2045,8 @@ static void link_recv_proto_msg(struct link *l_ptr, struct sk_buff *buf)
case RESET_MSG:
if (!link_working_unknown(l_ptr) &&
(l_ptr->peer_session != INVALID_SESSION)) {
- if (msg_session(msg) == l_ptr->peer_session)
- break; /* duplicate: ignore */
+ if (less_eq(msg_session(msg), l_ptr->peer_session))
+ break; /* duplicate or old reset: ignore */
}
/* fall thru' */
case ACTIVATE_MSG:
--
1.7.4.4
^ permalink raw reply related
* [PATCH net-next 01/28] tipc: Remove obsolete manipulation of message re-route count field
From: Paul Gortmaker @ 2011-09-18 3:31 UTC (permalink / raw)
To: davem; +Cc: netdev, allan.stephens, ying.xue, Paul Gortmaker
In-Reply-To: <1316316744-29514-1-git-send-email-paul.gortmaker@windriver.com>
From: Allan Stephens <allan.stephens@windriver.com>
Eliminates code that increments and validates the re-route count field
of payload messages, since the elimination of multi-cluster support
means that it is no longer necessary for TIPC to forward incoming messages
to another node. (The obsolete code was incorrect anyway, since it
incorrectly incremented the re-route count field of messages that
originated on the node that forwarded the message.)
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/net.c | 11 -----------
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/net/tipc/net.c b/net/tipc/net.c
index 68b3dd6..fafef6c 100644
--- a/net/tipc/net.c
+++ b/net/tipc/net.c
@@ -141,17 +141,6 @@ void tipc_net_route_msg(struct sk_buff *buf)
return;
msg = buf_msg(buf);
- msg_incr_reroute_cnt(msg);
- if (msg_reroute_cnt(msg) > 6) {
- if (msg_errcode(msg)) {
- buf_discard(buf);
- } else {
- tipc_reject_msg(buf, msg_destport(msg) ?
- TIPC_ERR_NO_PORT : TIPC_ERR_NO_NAME);
- }
- return;
- }
-
/* Handle message for this node */
dnode = msg_short(msg) ? tipc_own_addr : msg_destnode(msg);
if (tipc_in_scope(dnode, tipc_own_addr)) {
--
1.7.4.4
^ permalink raw reply related
* [PATCH net-next 02/28] tipc: Eliminate obsolete filter for unexpected unicast messages
From: Paul Gortmaker @ 2011-09-18 3:31 UTC (permalink / raw)
To: davem; +Cc: netdev, allan.stephens, ying.xue, Paul Gortmaker
In-Reply-To: <1316316744-29514-1-git-send-email-paul.gortmaker@windriver.com>
From: Allan Stephens <allan.stephens@windriver.com>
Removes a test that ensures unicast link endpoints discard an incoming
message if it will not be consumed by the node itself and cannot be
forwarded to another node, since the preceding test already ensures that
the message is destined for this node and single-cluster TIPC no longer
performs message forwarding.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/link.c | 11 ++---------
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index f89570c..933764c 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1658,19 +1658,12 @@ void tipc_recv_msg(struct sk_buff *head, struct tipc_bearer *b_ptr)
continue;
}
+ /* Discard unicast link messages destined for another node */
+
if (unlikely(!msg_short(msg) &&
(msg_destnode(msg) != tipc_own_addr)))
goto cont;
- /* Discard non-routeable messages destined for another node */
-
- if (unlikely(!msg_isdata(msg) &&
- (msg_destnode(msg) != tipc_own_addr))) {
- if ((msg_user(msg) != CONN_MANAGER) &&
- (msg_user(msg) != MSG_FRAGMENTER))
- goto cont;
- }
-
/* Locate neighboring node that sent message */
n_ptr = tipc_node_find(msg_prevnode(msg));
--
1.7.4.4
^ permalink raw reply related
* [PATCH net-next 00/28] misc. TIPC updates for what will be 3.2
From: Paul Gortmaker @ 2011-09-18 3:31 UTC (permalink / raw)
To: davem; +Cc: netdev, allan.stephens, ying.xue, Paul Gortmaker
Another mixed bag of misc TIPC fixes and enhancements. Some commits
here from Ying, who Al is working with to impart/share his TIPC
experience with -- we'll definitely be seeing more commits from Ying
on TIPC in the future. Active TIPC users may have already met Ying
on the TIPC users [sourceforge] mailing list. Thanks Ying!
The merge-base of these is roughly net-next of around when kernel.org
went down -- so I had to temporarily revert 0856a304091 (the use
after free scm pid thing) during validation since my 64bit test box
would simply die at boot. But I see that same revert is now in. Just
thought I'd mention it in case someone wondered how I tested when
0856a was preventing booting. The self test was run between 32bit and
64bit boxes, each alternating between client and server respectively.
Thanks,
Paul.
---
The following changes since commit ab7e11d9d0293ef1802d6ae8aab39ce58472b167:
greth: convert to SKB paged frag API. (2011-08-30 17:58:03 -0400)
are available in the git repository at:
git://openlinux.windriver.com/people/paulg/net-next tipc-Sep17-2011
Allan Stephens (23):
tipc: Remove obsolete manipulation of message re-route count field
tipc: Eliminate obsolete filter for unexpected unicast messages
tipc: Display meaningful peer interface name during link creation
tipc: Initialize peer session field of newly created link endpoint
tipc: Enhance filtering of out-dated link reset messages
tipc: Update obsolete references to multicast link
tipc: Cosmetic changes to broadcast bearer send routine
tipc: Remove non-executable code to handle broadcast bearer congestion
tipc: Enhance cleanup of broadcast link when contact with node is lost
tipc: Prevent broadcast link stalling when another node fails
tipc: Fix node lock problems during broadcast message reception
tipc: Remove deferred queue head caching during broadcast message reception
tipc: Discard incoming broadcast messages that are unexpected
tipc: Remove obsolete congestion handling when sending a broadcast NACK
tipc: Eliminate redundant check when sending messages
tipc: Prevent rounding issues when saving connect timeout option
tipc: Ensure congested links receive bearer status updates
tipc: Ensure both nodes recognize loss of contact between them
tipc: Fix unsafe device list search when enabling bearer
tipc: Remove redundant search when enabling bearer
tipc: Lower limits for number of bearers and media types
tipc: Prevent fragmented messages during initial name table exchange
tipc: Enhance sending of bulk name table messages
Paul Gortmaker (1):
tipc: relocate/coalesce node cast in tipc_named_node_up
Ying Xue (4):
tipc: Add support for SO_SNDTIMEO socket option
tipc: Simplify prohibition of listen and accept for connectionless sockets
tipc: Remove callback field from subscription structure
tipc: Remove unused link event tracking code
net/tipc/bcast.c | 111 +++++++++++++++++++++++--------------------------
net/tipc/bcast.h | 1 -
net/tipc/bearer.c | 8 +--
net/tipc/bearer.h | 4 +-
net/tipc/config.h | 1 -
net/tipc/discover.c | 6 ---
net/tipc/eth_media.c | 32 ++++++--------
net/tipc/link.c | 111 +++++++++++++++++++++++++++++++++++--------------
net/tipc/link.h | 1 +
net/tipc/name_distr.c | 35 +++++++++++++---
net/tipc/net.c | 11 -----
net/tipc/node.c | 45 +++++++++++---------
net/tipc/node.h | 10 ++++-
net/tipc/socket.c | 51 +++++++++++------------
net/tipc/subscr.c | 3 +-
net/tipc/subscr.h | 6 ---
16 files changed, 239 insertions(+), 197 deletions(-)
--
1.7.4.4
^ permalink raw reply
* [PATCH net-next 03/28] tipc: Display meaningful peer interface name during link creation
From: Paul Gortmaker @ 2011-09-18 3:31 UTC (permalink / raw)
To: davem; +Cc: netdev, allan.stephens, ying.xue, Paul Gortmaker
In-Reply-To: <1316316744-29514-1-git-send-email-paul.gortmaker@windriver.com>
From: Allan Stephens <allan.stephens@windriver.com>
Sets the peer interface portion of the name of a newly created link
endpoint to "unknown". This ensures that state and statistics information
can be properly displayed during the time between the link endpoint's
creation and the time handshaking with its peer is completed.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/link.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 933764c..4cb500b 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -332,12 +332,12 @@ struct link *tipc_link_create(struct tipc_node *n_ptr,
l_ptr->addr = peer;
if_name = strchr(b_ptr->name, ':') + 1;
- sprintf(l_ptr->name, "%u.%u.%u:%s-%u.%u.%u:",
+ sprintf(l_ptr->name, "%u.%u.%u:%s-%u.%u.%u:unknown",
tipc_zone(tipc_own_addr), tipc_cluster(tipc_own_addr),
tipc_node(tipc_own_addr),
if_name,
tipc_zone(peer), tipc_cluster(peer), tipc_node(peer));
- /* note: peer i/f is appended to link name by reset/activate */
+ /* note: peer i/f name is updated by reset/activate message */
memcpy(&l_ptr->media_addr, media_addr, sizeof(*media_addr));
l_ptr->owner = n_ptr;
l_ptr->checkpoint = 1;
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH v2 2/7] socket: initial cgroup code.
From: Glauber Costa @ 2011-09-18 3:32 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm
In-Reply-To: <20110917175207.GB1658@shutemov.name>
On 09/17/2011 02:52 PM, Kirill A. Shutemov wrote:
> On Wed, Sep 14, 2011 at 10:46:10PM -0300, Glauber Costa wrote:
>> 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 | 38 ++++++++++++++++++++++++++++++++++++++
>> include/net/sock.h | 2 ++
>> net/core/sock.c | 3 +++
>> 3 files changed, 43 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
>> index 3b535db..be457ce 100644
>> --- a/include/linux/memcontrol.h
>> +++ b/include/linux/memcontrol.h
>> @@ -395,5 +395,43 @@ mem_cgroup_print_bad_page(struct page *page)
>> }
>> #endif
>>
>> +#ifdef CONFIG_INET
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +#include<net/sock.h>
>> +static inline 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();
>> +}
>> +
>> +static inline void sock_release_memcg(struct sock *sk)
>> +{
>> + cgroup_release_and_wakeup_rmdir(mem_cgroup_css(sk->sk_cgrp));
>> +}
>
> Do we really need to have these functions in the header?
>
No, I can move it to memcontrol.c
--
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
* RE: Very confused about broute DROP
From: Greg Scott @ 2011-09-18 1:47 UTC (permalink / raw)
To: Christian Benvenuti (benve), netdev; +Cc: Graham Parenteau
In-Reply-To: <925A849792280C4E80C5461017A4B8A2A0443B@mail733.InfraSupportEtc.com>
A clarification - hopefully my embarrassing mistake can be of some use.
ARP is an L2 protocol, not an L3 protocol. ARP is **not** part of IPv4
or IPv6. Look in the IANA list of IP protocol numbers - there's none
for ARP. ARP is defined in Layer 2, not L3. I would have missed that
question on a cert test. That's why my broute rules need to take ARPs
into account.
- Greg
^ permalink raw reply
* Congratulations!!! You Are a Certified Winner of Our 2011 Promo?
From: PEPSI BOTTLING COMPANY PLC @ 2011-09-17 20:50 UTC (permalink / raw)
Your email has won £500,000.00 POUNDS (Five Hundred Thousand Pounds)
from Pepsi online promotions2011,send your Full names, Age,
Sex,Occupation,Phone and Address to the Promotion Manager via email at
: marketingmanager2011@hotmail.co.uk for claims. Tel: +447011150911
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: Bridge stays down until a port is added
From: Marc Haber @ 2011-09-17 20:42 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110811081706.7307e8b2@nehalam.ftrdhcpuser.net>
On Thu, Aug 11, 2011 at 08:17:06AM -0700, Stephen Hemminger wrote:
> On Thu, 11 Aug 2011 09:06:59 +0200
> Marc Haber <mh+netdev@zugschlus.de> wrote:
> > New new behavior is somewhat unhandy when one uses the bridge address
> > for services that the host offers, to save on IP addresses and
> > networks (for example, when one has only a single IP address and a
> > single additional network), since one has to take extra measures to
> > have the addresses on the bridge interface reachable.
> >
> > Or am I doing things wrong?
>
> The goal is to make the bridge behave the same as a vlan or
> a physical device. Could you explain better what the application(s)
> would expect.
The situation of a bridge is quite different from a physical ethernet
interface. The physical interface is usually connected to a switch and
is thus immediately up, even if no systems other than the switch are
online.
In the case of a bridge on a virtualization host used to connect
virtual machines, the bridge only goes up after the first VM was
started.
In the IPv6 SLAAC case, the host tries start its radvd on the bridge
well before the first VM comes up, the radvd barfs since the interface
is not up, does not come up, and the VMs are without network. In this
case, it is needed to force the bridge into an UP state earlier so
that radvd can start.
If people are supposed to add a dummy interface to the bridge if they
want to use ipv6, this should be documented. And it's ugly.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
^ permalink raw reply
* Re: [net-next RFC V2 PATCH 0/5] Multiqueue support in tun/tap
From: Michael S. Tsirkin @ 2011-09-17 19:17 UTC (permalink / raw)
To: Jason Wang
Cc: krkumar2, kvm, eric.dumazet, qemu-devel, netdev, rusty,
linux-kernel, virtualization, joe, shemminger, mirq-linux, davem
In-Reply-To: <20110917055639.32666.89940.stgit@dhcp-91-7.nay.redhat.com.englab.nay.redhat.com>
On Sat, Sep 17, 2011 at 02:02:04PM +0800, Jason Wang wrote:
> A wiki-page was created to narrate the detail design of all parts
> involved in the multi queue implementation:
> http://www.linux-kvm.org/page/Multiqueue and some basic tests result
> could be seen in this page
> http://www.linux-kvm.org/page/Multiqueue-performance-Sep-13. I would
> post the detail numbers in attachment as the reply of this thread.
Does it make sense to test both with and without RPS in guest?
--
MST
^ permalink raw reply
* Re: [PATCH v2 4/7] per-cgroup tcp buffers control
From: Cyrill Gorcunov @ 2011-09-17 18:33 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Glauber Costa, linux-kernel, paul, lizf, kamezawa.hiroyu,
ebiederm, davem, gthelen, netdev, linux-mm
In-Reply-To: <20110917181132.GC1658@shutemov.name>
On Sat, Sep 17, 2011 at 09:11:32PM +0300, Kirill A. Shutemov wrote:
> On Wed, Sep 14, 2011 at 10:46:12PM -0300, Glauber Costa wrote:
> > +int tcp_init_cgroup_fill(struct proto *prot, struct cgroup *cgrp,
> > + struct cgroup_subsys *ss)
> > +{
> > + prot->enter_memory_pressure = tcp_enter_memory_pressure;
> > + prot->memory_allocated = memory_allocated_tcp;
> > + prot->prot_mem = tcp_sysctl_mem;
> > + prot->sockets_allocated = sockets_allocated_tcp;
> > + prot->memory_pressure = memory_pressure_tcp;
>
> No fancy formatting, please.
>
What's wrong with having fancy formatting? It's indeed easier to read
when members are assigned this way. It's always up to maintainer to
choose what he prefers, but I see nothing wrong in such style (if only it
doesn't break the style of the whole file).
Cyrill
--
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
* Re: [PATCH v2 4/7] per-cgroup tcp buffers control
From: Kirill A. Shutemov @ 2011-09-17 18:11 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm
In-Reply-To: <1316051175-17780-5-git-send-email-glommer@parallels.com>
On Wed, Sep 14, 2011 at 10:46:12PM -0300, Glauber Costa wrote:
> +int tcp_init_cgroup_fill(struct proto *prot, struct cgroup *cgrp,
> + struct cgroup_subsys *ss)
> +{
> + prot->enter_memory_pressure = tcp_enter_memory_pressure;
> + prot->memory_allocated = memory_allocated_tcp;
> + prot->prot_mem = tcp_sysctl_mem;
> + prot->sockets_allocated = sockets_allocated_tcp;
> + prot->memory_pressure = memory_pressure_tcp;
No fancy formatting, please.
--
Kirill A. Shutemov
--
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
* Re: [PATCH v2 2/7] socket: initial cgroup code.
From: Kirill A. Shutemov @ 2011-09-17 17:52 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm
In-Reply-To: <1316051175-17780-3-git-send-email-glommer@parallels.com>
On Wed, Sep 14, 2011 at 10:46:10PM -0300, Glauber Costa wrote:
> 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 | 38 ++++++++++++++++++++++++++++++++++++++
> include/net/sock.h | 2 ++
> net/core/sock.c | 3 +++
> 3 files changed, 43 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 3b535db..be457ce 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -395,5 +395,43 @@ mem_cgroup_print_bad_page(struct page *page)
> }
> #endif
>
> +#ifdef CONFIG_INET
> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
> +#include <net/sock.h>
> +static inline 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();
> +}
> +
> +static inline void sock_release_memcg(struct sock *sk)
> +{
> + cgroup_release_and_wakeup_rmdir(mem_cgroup_css(sk->sk_cgrp));
> +}
Do we really need to have these functions in the header?
--
Kirill A. Shutemov
--
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
* Re: [PATCH v2 1/7] Basic kernel memory functionality for the Memory Controller
From: Kirill A. Shutemov @ 2011-09-17 17:45 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm
In-Reply-To: <1316051175-17780-2-git-send-email-glommer@parallels.com>
On Wed, Sep 14, 2011 at 10:46:09PM -0300, Glauber Costa wrote:
> 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 | 29 ++++++++++-
> init/Kconfig | 11 ++++
> mm/memcontrol.c | 105 ++++++++++++++++++++++++++++++++++++-
> 3 files changed, 140 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
> index 6f3c598..ca58eff 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,24 @@ 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.
> +
> +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..49e5839 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"
> + depends on CGROUP_MEM_RES_CTLR
> + 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..1c5d01a 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -73,7 +73,11 @@ static int really_do_swap_account __initdata = 0;
> #define do_swap_account (0)
> #endif
>
> -
> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
> +int do_kmem_account __read_mostly = 1;
> +#else
> +#define do_kmem_account (0)
Redundant brackets.
> +#endif
> /*
> * Statistics for memory cgroup.
> */
> @@ -270,6 +274,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 +329,11 @@ struct mem_cgroup {
> */
> unsigned long move_charge_at_immigrate;
> /*
> + * Should kernel memory limits be stabilished independently
> + * from user memory ?
> + */
> + int kmem_independent;
> + /*
> * percpu counter.
> */
> struct mem_cgroup_stat_cpu *stat;
> @@ -391,6 +404,7 @@ enum charge_type {
> #define _MEM (0)
> #define _MEMSWAP (1)
> #define _OOM_TYPE (2)
> +#define _KMEM (3)
Ditto. Can we use enum instead?
> #define MEMFILE_PRIVATE(x, val) (((x) << 16) | (val))
> #define MEMFILE_TYPE(val) (((val) >> 16) & 0xffff)
> #define MEMFILE_ATTR(val) ((val) & 0xffff)
> @@ -3941,12 +3955,18 @@ static unsigned long mem_cgroup_recursive_stat(struct mem_cgroup *mem,
> static inline u64 mem_cgroup_usage(struct mem_cgroup *mem, bool swap)
> {
> u64 val;
> + u64 kmem = 0;
Why kmem? It's not only a kernel memory. Why not reuse val?
> +
> + if (!mem->kmem_independent)
> + kmem = res_counter_read_u64(&mem->kmem, RES_USAGE);
This should be inside if (!mem_cgroup_is_root(mem)), I think.
>
> if (!mem_cgroup_is_root(mem)) {
> if (!swap)
> - return res_counter_read_u64(&mem->res, RES_USAGE);
> + kmem += res_counter_read_u64(&mem->res, RES_USAGE);
> else
> - return res_counter_read_u64(&mem->memsw, RES_USAGE);
> + kmem += res_counter_read_u64(&mem->memsw, RES_USAGE);
> +
> + return kmem;
> }
>
> val = mem_cgroup_recursive_stat(mem, MEM_CGROUP_STAT_CACHE);
No kernel memory accounting for root cgroup, right?
> @@ -3979,6 +3999,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;
> +
Always zero in root cgroup?
> default:
> BUG();
> break;
> @@ -4756,6 +4780,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;
> +}
> +
> +static int kmem_limit_independent_write(struct cgroup *cont, struct cftype *cft,
> + u64 val)
> +{
> + cgroup_lock();
> + mem_cgroup_from_cont(cont)->kmem_independent = !!val;
> + cgroup_unlock();
> + return 0;
> +}
> +#endif
>
> static struct cftype mem_cgroup_files[] = {
> {
> @@ -4877,6 +4916,46 @@ 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,
> + .register_event = mem_cgroup_usage_register_event,
> + .unregister_event = mem_cgroup_usage_unregister_event,
mem_cgroup_usage_register_event() doesn't support _KMEM. You will get
BUG(), if try to use.
> + },
> + {
> + .name = "kmem.limit_in_bytes",
> + .private = MEMFILE_PRIVATE(_KMEM, RES_LIMIT),
> + .read_u64 = mem_cgroup_read,
> + .register_event = mem_cgroup_usage_register_event,
> + .unregister_event = mem_cgroup_usage_unregister_event,
events have no sense for limit.
> + },
> +};
> +
> +static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
> +{
> + if (!do_kmem_account)
> + return 0;
> +
> + return cgroup_add_files(cont, ss, kmem_cgroup_files,
> + ARRAY_SIZE(kmem_cgroup_files));
> +};
> +
> +#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 +5154,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 +5165,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 +5210,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;
> }
>
> @@ -5665,3 +5750,17 @@ static int __init enable_swap_account(char *s)
> __setup("swapaccount=", enable_swap_account);
>
> #endif
> +
> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
> +static int __init disable_kmem_account(char *s)
> +{
> + /* consider enabled if no parameter or 1 is given */
> + if (!strcmp(s, "1"))
> + do_kmem_account = 1;
> + else if (!strcmp(s, "0"))
> + do_kmem_account = 0;
> + return 1;
> +}
> +__setup("kmemaccount=", disable_kmem_account);
> +
> +#endif
> --
> 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>
--
Kirill A. Shutemov
--
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
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Ben Hutchings @ 2011-09-17 17:04 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Alexander Duyck, netdev, gospo
In-Reply-To: <1316246677-8830-12-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, 2011-09-17 at 01:04 -0700, Jeff Kirsher wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change is meant to make the NAPI budget limits for transmit
> adjustable. By doing this it is possible to tune the value for optimal
> performance with applications such as routing.
[...]
> --- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
> +++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> @@ -1989,6 +1989,9 @@ static int igb_set_coalesce(struct net_device *netdev,
> if ((adapter->flags & IGB_FLAG_QUEUE_PAIRS) && ec->tx_coalesce_usecs)
> return -EINVAL;
>
> + if (ec->tx_max_coalesced_frames_irq)
> + adapter->tx_work_limit = ec->tx_max_coalesced_frames_irq;
> +
[...]
I don't think it really makes sense to conflate NAPI and interrupt
moderation parameters. This really ought to be added to NAPI itself.
(NAPI contexts really ought to be exposed through sysfs somehow. I
think we've discussed this before, and it's tricky due to the lack of a
consistent mapping between those contexts and net devices.)
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
* Re: [net-next 01/11] ixgb: convert to ndo_fix_features
From: Michał Mirosław @ 2011-09-17 13:21 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo
In-Reply-To: <1316225752-1709-2-git-send-email-jeffrey.t.kirsher@intel.com>
On Fri, Sep 16, 2011 at 07:15:42PM -0700, Jeff Kirsher wrote:
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Private rx_csum flags are now duplicate of netdev->features & NETIF_F_RXCSUM.
> Removing this needs deeper surgery.
[...]
Hmm. Looks like this patch is not complete: part removing get/set_flags
from ethtool_ops is missing. I don't remember if this was included or not
in the patch I sent originally. I'm attaching it now, rebased on current
net-next (not tested).
Best Regards,
Michał Mirosław
---
Finish conversion to unified ethtool ops: convert get_flags.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c b/drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c
index fdb30cc..ab404e7 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c
@@ -634,43 +634,6 @@ ixgb_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
}
}
-static int ixgb_set_flags(struct net_device *netdev, u32 data)
-{
- struct ixgb_adapter *adapter = netdev_priv(netdev);
- bool need_reset;
- int rc;
-
- /*
- * Tx VLAN insertion does not work per HW design when Rx stripping is
- * disabled. Disable txvlan when rxvlan is turned off, and enable
- * rxvlan when txvlan is turned on.
- */
- if (!(data & ETH_FLAG_RXVLAN) &&
- (netdev->features & NETIF_F_HW_VLAN_TX))
- data &= ~ETH_FLAG_TXVLAN;
- else if (data & ETH_FLAG_TXVLAN)
- data |= ETH_FLAG_RXVLAN;
-
- need_reset = (data & ETH_FLAG_RXVLAN) !=
- (netdev->features & NETIF_F_HW_VLAN_RX);
-
- rc = ethtool_op_set_flags(netdev, data, ETH_FLAG_RXVLAN |
- ETH_FLAG_TXVLAN);
- if (rc)
- return rc;
-
- if (need_reset) {
- if (netif_running(netdev)) {
- ixgb_down(adapter, true);
- ixgb_up(adapter);
- ixgb_set_speed_duplex(netdev);
- } else
- ixgb_reset(adapter);
- }
-
- return 0;
-}
-
static const struct ethtool_ops ixgb_ethtool_ops = {
.get_settings = ixgb_get_settings,
.set_settings = ixgb_set_settings,
@@ -691,8 +654,6 @@ static const struct ethtool_ops ixgb_ethtool_ops = {
.set_phys_id = ixgb_set_phys_id,
.get_sset_count = ixgb_get_sset_count,
.get_ethtool_stats = ixgb_get_ethtool_stats,
- .get_flags = ethtool_op_get_flags,
- .set_flags = ixgb_set_flags,
};
void ixgb_set_ethtool_ops(struct net_device *netdev)
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
index b8fb163..1bb794c 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
@@ -325,13 +325,26 @@ ixgb_reset(struct ixgb_adapter *adapter)
}
}
+static u32
+ixgb_fix_features(struct net_device *netdev, u32 features)
+{
+ /*
+ * Tx VLAN insertion does not work per HW design when Rx stripping is
+ * disabled.
+ */
+ if (!(features & NETIF_F_HW_VLAN_RX))
+ features &= ~NETIF_F_HW_VLAN_TX;
+
+ return features;
+}
+
static int
ixgb_set_features(struct net_device *netdev, u32 features)
{
struct ixgb_adapter *adapter = netdev_priv(netdev);
u32 changed = features ^ netdev->features;
- if (!(changed & NETIF_F_RXCSUM))
+ if (!(changed & (NETIF_F_RXCSUM|NETIF_F_HW_VLAN_RX)))
return 0;
adapter->rx_csum = !!(features & NETIF_F_RXCSUM);
@@ -362,6 +375,7 @@ static const struct net_device_ops ixgb_netdev_ops = {
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = ixgb_netpoll,
#endif
+ .ndo_fix_features = ixgb_fix_features,
.ndo_set_features = ixgb_set_features,
};
@@ -464,10 +478,10 @@ ixgb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
netdev->hw_features = NETIF_F_SG |
NETIF_F_TSO |
- NETIF_F_HW_CSUM;
- netdev->features = netdev->hw_features |
+ NETIF_F_HW_CSUM |
NETIF_F_HW_VLAN_TX |
- NETIF_F_HW_VLAN_RX |
+ NETIF_F_HW_VLAN_RX;
+ netdev->features = netdev->hw_features |
NETIF_F_HW_VLAN_FILTER;
netdev->hw_features |= NETIF_F_RXCSUM;
^ permalink raw reply related
* Re: [PATCH v2 6/7] tcp buffer limitation: per-cgroup limit
From: Glauber Costa @ 2011-09-17 12:12 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm
In-Reply-To: <1316051175-17780-7-git-send-email-glommer@parallels.com>
On 09/14/2011 10:46 PM, Glauber Costa wrote:
> This patch uses the "tcp_max_mem" field of the kmem_cgroup to
> effectively control the amount of kernel memory pinned by a cgroup.
>
> We have to make sure that none of the memory pressure thresholds
> specified in the namespace are bigger than the current cgroup.
>
> 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>
> ---
heads up: I found a small problem in a corner case here yesterday.
So I will resubmit this series.
It you guys have any other comments let me know, so I can address them
as well.
^ permalink raw reply
* unicast hash in ixgbe and ixgbevf
From: J.Hwan.Kim @ 2011-09-17 11:02 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi, everyone
I'm using intel ixgbe and ixgbevf driver and SR-IOV option.
Is there any method for distributing the random IP packet stream
into several VF queues evenly?
For example, for each 4 VF queues,
can each a quarter of the IP stream be distributed to each 4 VF queues?
I checked the PFUTA register and tested it, but as far as I know,
with the 4K bit hash table, the stream is directed to queues
of which ROPE bit is set.
So, the stream is duplicated to the queues of which ROPE bit is set.
That is not what I want to do.
How can I distribute the random IP packets to several VF queues
without duplicating?
Thanks in advance.
Best Regards,
J.Hwan Kim
^ permalink raw reply
* Re: mac80211 regression (deadlock) with built-in ipw2200
From: Josh Boyer @ 2011-09-17 10:32 UTC (permalink / raw)
To: Ferenc Wagner
Cc: Stanislaw Gruszka, Johannes Berg, David S. Miller,
John W. Linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <877h57jwmh.fsf@tac.ki.iif.hu>
On Sat, Sep 17, 2011 at 6:23 AM, Ferenc Wagner <wferi@niif.hu> wrote:
> Hi,
>
> As pointed out by git-bisect, commit ecb44335 (mac80211: fix
> suspend/resume races with unregister hw) broke booting on my ThinkPad
> R50e. Looks like the rtnl_lock() around rdev->wiphy.registered = true
> leads to a deadlock, possibly because ipw2200 is built-in in my
> config. Testing with the additional debug patch
>
> --- a/net/wireless/core.c
> +++ b/net/wireless/core.c
> @@ -616,9 +616,8 @@ int wiphy_register(struct wiphy *wiphy)
> if (res)
> goto out_rm_dev;
>
> - rtnl_lock();
> + WARN_ON(rtnl_is_locked());
> rdev->wiphy.registered = true;
> - rtnl_unlock();
> return 0;
>
> on top of c455ea4f (rc6+) leads to a working system with
>
> [ 1.020738] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2kmpr
> [ 1.020812] ipw2200: Copyright(c) 2003-2006 Intel Corporation
> [ 1.023406] ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 11
> [ 1.025717] ipw2200 0000:02:02.0: PCI INT A -> Link[LNKF] -> GSI 11 (level, low
> ) -> IRQ 11
> [ 1.028048] ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
> [ 1.148058] ------------[ cut here ]------------
> [ 1.150393] WARNING: at net/wireless/core.c:619 wiphy_register+0x4c1/0x58c()
> [ 1.152781] Hardware name: 1834S5G
> [ 1.155126] Pid: 1, comm: swapper Not tainted 3.1.0-rc6+ #86
> [ 1.157520] Call Trace:
> [ 1.159871] [<c1028b98>] warn_slowpath_common+0x69/0x90
> [ 1.162241] [<c13ee7a8>] ? wiphy_register+0x4c1/0x58c
> [ 1.164617] [<c13ee7a8>] ? wiphy_register+0x4c1/0x58c
> [ 1.166924] [<c1028be1>] warn_slowpath_null+0x22/0x24
> [ 1.169230] [<c13ee7a8>] wiphy_register+0x4c1/0x58c
> [ 1.171564] [<c12daad0>] ? ipw_net_init+0x1e6/0x2d0
> [ 1.173890] [<c12da995>] ipw_net_init+0xab/0x2d0
> [ 1.176173] [<c1375032>] register_netdevice+0x70/0x271
> [ 1.178446] [<c137524e>] register_netdev+0x1b/0x28
> [ 1.180688] [<c142f5b8>] ipw_pci_probe+0x7c3/0x891
> [ 1.182892] [<c11a6f93>] local_pci_probe+0x40/0x9a
> [ 1.185086] [<c11a7c98>] pci_device_probe+0x56/0x71
> [ 1.187259] [<c128c902>] driver_probe_device+0x6c/0x177
> [ 1.189453] [<c11a6ed9>] ? pci_match_device+0x80/0x85
> [ 1.191615] [<c128ca79>] __driver_attach+0x6c/0x6e
> [ 1.193794] [<c128c257>] bus_for_each_dev+0x4a/0x68
> [ 1.195936] [<c128c7b4>] driver_attach+0x1e/0x20
> [ 1.198043] [<c128ca0d>] ? driver_probe_device+0x177/0x177
> [ 1.200151] [<c128bce5>] bus_add_driver+0x186/0x231
> [ 1.202247] [<c11a7b3c>] ? pci_dev_put+0x16/0x16
> [ 1.204320] [<c128cfac>] driver_register+0x6a/0x118
> [ 1.206386] [<c120665f>] ? misc_register+0xc2/0x133
> [ 1.208425] [<c15ee31e>] ? parse_early_options+0x25/0x25
> [ 1.210423] [<c11a7e66>] __pci_register_driver+0x33/0x8c
> [ 1.212393] [<c15ee31e>] ? parse_early_options+0x25/0x25
> [ 1.214384] [<c160e0e8>] ipw_init+0x30/0x75
> [ 1.216356] [<c15ee24c>] do_one_initcall+0x86/0x133
> [ 1.218340] [<c160e0b8>] ? tun_init+0x8b/0x8b
> [ 1.220315] [<c15ee31e>] ? parse_early_options+0x25/0x25
> [ 1.222270] [<c15ee393>] kernel_init+0x75/0x10c
> [ 1.224214] [<c14349b6>] kernel_thread_helper+0x6/0x10
> [ 1.226124] ---[ end trace 4ef665623022622c ]---
> [ 1.228121] ipw2200: Detected geography ZZR (14 802.11bg channels, 0 802.11a channels)
>
> in dmesg. It's a shoot in the dark, but register_netdev() issues
> rtnl_lock() before calling register_netdevice(), so wiphy_register()
> can't possibly acquire the rtnl mutex in the same call chain, or can
> it?
This is fixed here:
http://article.gmane.org/gmane.linux.kernel.wireless.general/77103
josh
^ permalink raw reply
* mac80211 regression (deadlock) with built-in ipw2200
From: Ferenc Wagner @ 2011-09-17 10:23 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Johannes Berg, David S. Miller, John W. Linville, linux-wireless,
netdev, linux-kernel
Hi,
As pointed out by git-bisect, commit ecb44335 (mac80211: fix
suspend/resume races with unregister hw) broke booting on my ThinkPad
R50e. Looks like the rtnl_lock() around rdev->wiphy.registered = true
leads to a deadlock, possibly because ipw2200 is built-in in my
config. Testing with the additional debug patch
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -616,9 +616,8 @@ int wiphy_register(struct wiphy *wiphy)
if (res)
goto out_rm_dev;
- rtnl_lock();
+ WARN_ON(rtnl_is_locked());
rdev->wiphy.registered = true;
- rtnl_unlock();
return 0;
on top of c455ea4f (rc6+) leads to a working system with
[ 1.020738] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2kmpr
[ 1.020812] ipw2200: Copyright(c) 2003-2006 Intel Corporation
[ 1.023406] ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 11
[ 1.025717] ipw2200 0000:02:02.0: PCI INT A -> Link[LNKF] -> GSI 11 (level, low
) -> IRQ 11
[ 1.028048] ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
[ 1.148058] ------------[ cut here ]------------
[ 1.150393] WARNING: at net/wireless/core.c:619 wiphy_register+0x4c1/0x58c()
[ 1.152781] Hardware name: 1834S5G
[ 1.155126] Pid: 1, comm: swapper Not tainted 3.1.0-rc6+ #86
[ 1.157520] Call Trace:
[ 1.159871] [<c1028b98>] warn_slowpath_common+0x69/0x90
[ 1.162241] [<c13ee7a8>] ? wiphy_register+0x4c1/0x58c
[ 1.164617] [<c13ee7a8>] ? wiphy_register+0x4c1/0x58c
[ 1.166924] [<c1028be1>] warn_slowpath_null+0x22/0x24
[ 1.169230] [<c13ee7a8>] wiphy_register+0x4c1/0x58c
[ 1.171564] [<c12daad0>] ? ipw_net_init+0x1e6/0x2d0
[ 1.173890] [<c12da995>] ipw_net_init+0xab/0x2d0
[ 1.176173] [<c1375032>] register_netdevice+0x70/0x271
[ 1.178446] [<c137524e>] register_netdev+0x1b/0x28
[ 1.180688] [<c142f5b8>] ipw_pci_probe+0x7c3/0x891
[ 1.182892] [<c11a6f93>] local_pci_probe+0x40/0x9a
[ 1.185086] [<c11a7c98>] pci_device_probe+0x56/0x71
[ 1.187259] [<c128c902>] driver_probe_device+0x6c/0x177
[ 1.189453] [<c11a6ed9>] ? pci_match_device+0x80/0x85
[ 1.191615] [<c128ca79>] __driver_attach+0x6c/0x6e
[ 1.193794] [<c128c257>] bus_for_each_dev+0x4a/0x68
[ 1.195936] [<c128c7b4>] driver_attach+0x1e/0x20
[ 1.198043] [<c128ca0d>] ? driver_probe_device+0x177/0x177
[ 1.200151] [<c128bce5>] bus_add_driver+0x186/0x231
[ 1.202247] [<c11a7b3c>] ? pci_dev_put+0x16/0x16
[ 1.204320] [<c128cfac>] driver_register+0x6a/0x118
[ 1.206386] [<c120665f>] ? misc_register+0xc2/0x133
[ 1.208425] [<c15ee31e>] ? parse_early_options+0x25/0x25
[ 1.210423] [<c11a7e66>] __pci_register_driver+0x33/0x8c
[ 1.212393] [<c15ee31e>] ? parse_early_options+0x25/0x25
[ 1.214384] [<c160e0e8>] ipw_init+0x30/0x75
[ 1.216356] [<c15ee24c>] do_one_initcall+0x86/0x133
[ 1.218340] [<c160e0b8>] ? tun_init+0x8b/0x8b
[ 1.220315] [<c15ee31e>] ? parse_early_options+0x25/0x25
[ 1.222270] [<c15ee393>] kernel_init+0x75/0x10c
[ 1.224214] [<c14349b6>] kernel_thread_helper+0x6/0x10
[ 1.226124] ---[ end trace 4ef665623022622c ]---
[ 1.228121] ipw2200: Detected geography ZZR (14 802.11bg channels, 0 802.11a channels)
in dmesg. It's a shoot in the dark, but register_netdev() issues
rtnl_lock() before calling register_netdevice(), so wiphy_register()
can't possibly acquire the rtnl mutex in the same call chain, or can
it?
--
Thanks,
Feri.
^ permalink raw reply
* [PATCH 5/5] r8169: do not enable the TBI for anything but the original 8169.
From: Francois Romieu @ 2011-09-17 9:59 UTC (permalink / raw)
To: davem; +Cc: netdev, Realtek linux nic maintainers, Hayes Wang
In-Reply-To: <20110917095617.GA21630@electric-eye.fr.zoreil.com>
The TBI bit in PHYStatus is reserved on anything but the oldest 8169.
Nobody complained after I disabled it for the 8168 and the 810x (see
66ec5d4fb1ce6f0bd9df4bc4b758f0916d9f37ab).
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index dff0bf0..c236670 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -3080,6 +3080,14 @@ static void rtl8169_phy_reset(struct net_device *dev,
netif_err(tp, link, dev, "PHY reset failed\n");
}
+static bool rtl_tbi_enabled(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+
+ return (tp->mac_version == RTL_GIGA_MAC_VER_01) &&
+ (RTL_R8(PHYstatus) & TBI_Enable);
+}
+
static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -3112,7 +3120,7 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
ADVERTISED_1000baseT_Half |
ADVERTISED_1000baseT_Full : 0));
- if (RTL_R8(PHYstatus) & TBI_Enable)
+ if (rtl_tbi_enabled(tp))
netif_info(tp, link, dev, "TBI auto-negotiating\n");
}
@@ -3738,8 +3746,7 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
tp->features |= rtl_try_msi(pdev, ioaddr, cfg);
RTL_W8(Cfg9346, Cfg9346_Lock);
- if ((tp->mac_version <= RTL_GIGA_MAC_VER_06) &&
- (RTL_R8(PHYstatus) & TBI_Enable)) {
+ if (rtl_tbi_enabled(tp)) {
tp->set_speed = rtl8169_set_speed_tbi;
tp->get_settings = rtl8169_gset_tbi;
tp->phy_reset_enable = rtl8169_tbi_reset_enable;
--
1.7.6
^ permalink raw reply related
* [PATCH 4/5] r8169: remove erroneous processing of always set bit.
From: Francois Romieu @ 2011-09-17 9:58 UTC (permalink / raw)
To: davem; +Cc: netdev, Realtek linux nic maintainers, Hayes Wang
In-Reply-To: <20110917095617.GA21630@electric-eye.fr.zoreil.com>
When set, RxFOVF (resp. RxBOVF) is always 1 (resp. 0).
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Hayes <hayeswang@realtek.com>
---
drivers/net/r8169.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 78c1d58..dff0bf0 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -407,6 +407,7 @@ enum rtl_register_content {
RxOK = 0x0001,
/* RxStatusDesc */
+ RxBOVF = (1 << 24),
RxFOVF = (1 << 23),
RxRWT = (1 << 22),
RxRES = (1 << 21),
@@ -682,6 +683,7 @@ struct rtl8169_private {
struct mii_if_info mii;
struct rtl8169_counters counters;
u32 saved_wolopts;
+ u32 opts1_mask;
struct rtl_fw {
const struct firmware *fw;
@@ -3786,6 +3788,9 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
tp->intr_event = cfg->intr_event;
tp->napi_event = cfg->napi_event;
+ tp->opts1_mask = (tp->mac_version != RTL_GIGA_MAC_VER_01) ?
+ ~(RxBOVF | RxFOVF) : ~0;
+
init_timer(&tp->timer);
tp->timer.data = (unsigned long) dev;
tp->timer.function = rtl8169_phy_timer;
@@ -5324,7 +5329,7 @@ static int rtl8169_rx_interrupt(struct net_device *dev,
u32 status;
rmb();
- status = le32_to_cpu(desc->opts1);
+ status = le32_to_cpu(desc->opts1) & tp->opts1_mask;
if (status & DescOwn)
break;
--
1.7.6
^ permalink raw reply related
* [PATCH 3/5] r8169: fix WOL setting for 8105 and 8111evl
From: Francois Romieu @ 2011-09-17 9:58 UTC (permalink / raw)
To: davem; +Cc: netdev, Realtek linux nic maintainers, Hayes Wang
In-Reply-To: <20110917095617.GA21630@electric-eye.fr.zoreil.com>
rtl8105, rtl8111E, and rtl8111evl need enable RxConfig bit 1 ~ 3
for supporting wake on lan.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index b55fba7..78c1d58 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -3320,9 +3320,16 @@ static void r810x_phy_power_up(struct rtl8169_private *tp)
static void r810x_pll_power_down(struct rtl8169_private *tp)
{
+ void __iomem *ioaddr = tp->mmio_addr;
+
if (__rtl8169_get_wol(tp) & WAKE_ANY) {
rtl_writephy(tp, 0x1f, 0x0000);
rtl_writephy(tp, MII_BMCR, 0x0000);
+
+ if (tp->mac_version == RTL_GIGA_MAC_VER_29 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_30)
+ RTL_W32(RxConfig, RTL_R32(RxConfig) | AcceptBroadcast |
+ AcceptMulticast | AcceptMyPhys);
return;
}
@@ -3418,7 +3425,8 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
rtl_writephy(tp, MII_BMCR, 0x0000);
if (tp->mac_version == RTL_GIGA_MAC_VER_32 ||
- tp->mac_version == RTL_GIGA_MAC_VER_33)
+ tp->mac_version == RTL_GIGA_MAC_VER_33 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_34)
RTL_W32(RxConfig, RTL_R32(RxConfig) | AcceptBroadcast |
AcceptMulticast | AcceptMyPhys);
return;
--
1.7.6
^ 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