* [PATCH 2/4] slab: fix starting index for finding another object
From: Mel Gorman @ 2012-09-04 17:24 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux-MM, Linux-Netdev, LKML, David Miller, Chuck Lever,
Joonsoo Kim, Pekka, "Enberg <penberg", David Rientjes,
Mel Gorman
In-Reply-To: <1346779479-1097-1-git-send-email-mgorman@suse.de>
From: Joonsoo Kim <js1304@gmail.com>
In array cache, there is a object at index 0, check it.
Signed-off-by: Joonsoo Kim <js1304@gmail.com>
Signed-off-by: Mel Gorman <mgorman@suse.de>
---
mm/slab.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/slab.c b/mm/slab.c
index d34a903..c685475 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -983,7 +983,7 @@ static void *__ac_get_obj(struct kmem_cache *cachep, struct array_cache *ac,
}
/* The caller cannot use PFMEMALLOC objects, find another one */
- for (i = 1; i < ac->avail; i++) {
+ for (i = 0; i < ac->avail; i++) {
/* If a !PFMEMALLOC object is found, swap them */
if (!is_obj_pfmemalloc(ac->entry[i])) {
objp = ac->entry[i];
--
1.7.9.2
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH 3/4] slub: consider pfmemalloc_match() in get_partial_node()
From: Mel Gorman @ 2012-09-04 17:24 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux-MM, Linux-Netdev, LKML, David Miller, Chuck Lever,
Joonsoo Kim, Pekka, "Enberg <penberg", David Rientjes,
Mel Gorman
In-Reply-To: <1346779479-1097-1-git-send-email-mgorman@suse.de>
From: Joonsoo Kim <js1304@gmail.com>
The function get_partial() is currently not checking pfmemalloc_match()
meaning that it is possible for pfmemalloc pages to leak to non-pfmemalloc
users. This is a problem in the following situation. Assume that there is
a request from normal allocation and there are no objects in the per-cpu
cache and no node-partial slab.
In this case, slab_alloc enters the slow path and new_slab_objects()
is called which may return a PFMEMALLOC page. As the current user is not
allowed to access PFMEMALLOC page, deactivate_slab() is called ([5091b74a:
mm: slub: optimise the SLUB fast path to avoid pfmemalloc checks]) and
returns an object from PFMEMALLOC page.
Next time, when we get another request from normal allocation, slab_alloc()
enters the slow-path and calls new_slab_objects(). In new_slab_objects(),
we call get_partial() and get a partial slab which was just deactivated
but is a pfmemalloc page. We extract one object from it and re-deactivate.
"deactivate -> re-get in get_partial -> re-deactivate" occures repeatedly.
As a result, access to PFMEMALLOC page is not properly restricted and it
can cause a performance degradation due to frequent deactivation.
deactivation frequently.
This patch changes get_partial_node() to take pfmemalloc_match() into
account and prevents the "deactivate -> re-get in get_partial() scenario.
Instead, new_slab() is called.
Signed-off-by: Joonsoo Kim <js1304@gmail.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Mel Gorman <mgorman@suse.de>
---
mm/slub.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index 8f78e25..2fdd96f9e9 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1524,12 +1524,13 @@ static inline void *acquire_slab(struct kmem_cache *s,
}
static int put_cpu_partial(struct kmem_cache *s, struct page *page, int drain);
+static inline bool pfmemalloc_match(struct page *page, gfp_t gfpflags);
/*
* Try to allocate a partial slab from a specific node.
*/
-static void *get_partial_node(struct kmem_cache *s,
- struct kmem_cache_node *n, struct kmem_cache_cpu *c)
+static void *get_partial_node(struct kmem_cache *s, struct kmem_cache_node *n,
+ struct kmem_cache_cpu *c, gfp_t flags)
{
struct page *page, *page2;
void *object = NULL;
@@ -1545,9 +1546,13 @@ static void *get_partial_node(struct kmem_cache *s,
spin_lock(&n->list_lock);
list_for_each_entry_safe(page, page2, &n->partial, lru) {
- void *t = acquire_slab(s, n, page, object == NULL);
+ void *t;
int available;
+ if (!pfmemalloc_match(page, flags))
+ continue;
+
+ t = acquire_slab(s, n, page, object == NULL);
if (!t)
break;
@@ -1614,7 +1619,7 @@ static void *get_any_partial(struct kmem_cache *s, gfp_t flags,
if (n && cpuset_zone_allowed_hardwall(zone, flags) &&
n->nr_partial > s->min_partial) {
- object = get_partial_node(s, n, c);
+ object = get_partial_node(s, n, c, flags);
if (object) {
/*
* Return the object even if
@@ -1643,7 +1648,7 @@ static void *get_partial(struct kmem_cache *s, gfp_t flags, int node,
void *object;
int searchnode = (node == NUMA_NO_NODE) ? numa_node_id() : node;
- object = get_partial_node(s, get_node(s, searchnode), c);
+ object = get_partial_node(s, get_node(s, searchnode), c, flags);
if (object || node != NUMA_NO_NODE)
return object;
--
1.7.9.2
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH 4/4] Squelch compiler warning in sk_rmem_schedule()
From: Mel Gorman @ 2012-09-04 17:24 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux-MM, Linux-Netdev, LKML, David Miller, Chuck Lever,
Joonsoo Kim, Pekka, "Enberg <penberg", David Rientjes,
Mel Gorman
In-Reply-To: <1346779479-1097-1-git-send-email-mgorman@suse.de>
From: Chuck Lever <chuck.lever@oracle.com>
In file included from linux/include/linux/tcp.h:227:0,
from linux/include/linux/ipv6.h:221,
from linux/include/net/ipv6.h:16,
from linux/include/linux/sunrpc/clnt.h:26,
from linux/net/sunrpc/stats.c:22:
linux/include/net/sock.h: In function ‘sk_rmem_schedule’:
linux/nfs-2.6/include/net/sock.h:1339:13: warning: comparison between
signed and unsigned integer expressions [-Wsign-compare]
Seen with gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2) using the
-Wextra option.
[c76562b6: netvm: prevent a stream-specific deadlock] accidentally replaced
the "size" parameter of sk_rmem_schedule() with an unsigned int. This
changes the semantics of the comparison in the return statement.
In sk_wmem_schedule we have syntactically the same comparison, but
"size" is a signed integer. In addition, __sk_mem_schedule() takes
a signed integer for its "size" parameter, so there is an implicit
type conversion in sk_rmem_schedule() anyway.
Revert the "size" parameter back to a signed integer so that the
semantics of the expressions in both sk_[rw]mem_schedule() are
exactly the same.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Mel Gorman <mgorman@suse.de>
---
include/net/sock.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 72132ae..adb7da2 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1332,7 +1332,7 @@ static inline bool sk_wmem_schedule(struct sock *sk, int size)
}
static inline bool
-sk_rmem_schedule(struct sock *sk, struct sk_buff *skb, unsigned int size)
+sk_rmem_schedule(struct sock *sk, struct sk_buff *skb, int size)
{
if (!sk_has_account(sk))
return true;
--
1.7.9.2
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH] net: don't allow INET to be not configured
From: Stephen Hemminger @ 2012-09-04 17:44 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, netdev
In-Reply-To: <50463941.9070703@xenotime.net>
There is no reason to expose turning off TCP/IP networking.
If networking is enabled force TCP/IP to enabled. This also
eliminates the time chasing down errors with bogus configurations
generated by 'make randconfig'
For testing, it is still possible to edit Kconfig
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/Kconfig 2012-08-15 08:59:22.910704705 -0700
+++ b/net/Kconfig 2012-09-04 10:39:53.654585718 -0700
@@ -51,26 +51,7 @@ source "net/xfrm/Kconfig"
source "net/iucv/Kconfig"
config INET
- bool "TCP/IP networking"
- ---help---
- These are the protocols used on the Internet and on most local
- Ethernets. It is highly recommended to say Y here (this will enlarge
- your kernel by about 400 KB), since some programs (e.g. the X window
- system) use TCP/IP even if your machine is not connected to any
- other computer. You will get the so-called loopback device which
- allows you to ping yourself (great fun, that!).
-
- For an excellent introduction to Linux networking, please read the
- Linux Networking HOWTO, available from
- <http://www.tldp.org/docs.html#howto>.
-
- If you say Y here and also to "/proc file system support" and
- "Sysctl support" below, you can change various aspects of the
- behavior of the TCP/IP code by writing to the (virtual) files in
- /proc/sys/net/ipv4/*; the options are explained in the file
- <file:Documentation/networking/ip-sysctl.txt>.
-
- Short answer: say Y.
+ def_bool y
if INET
source "net/ipv4/Kconfig"
^ permalink raw reply
* [PATCH] netfilter: take care of timewait sockets
From: Eric Dumazet @ 2012-09-04 17:49 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Patrick McHardy, netfilter-devel, netdev
From: Eric Dumazet <edumazet@google.com>
Sami Farin reported crashes in xt_LOG because it assumes skb->sk is a
full blown socket.
But with TCP early demux, we can have skb->sk pointing to a timewait
socket.
Same fix is needed in netfnetlink_log
Diagnosed-by: Florian Westphal <fw@strlen.de>
Reported-by: Sami Farin <hvtaifwkbgefbaei@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/netfilter/nfnetlink_log.c | 14 +++++++------
net/netfilter/xt_LOG.c | 33 ++++++++++++++++----------------
2 files changed, 25 insertions(+), 22 deletions(-)
diff --git a/net/netfilter/nfnetlink_log.c b/net/netfilter/nfnetlink_log.c
index 14e2f39..5cfb5be 100644
--- a/net/netfilter/nfnetlink_log.c
+++ b/net/netfilter/nfnetlink_log.c
@@ -381,6 +381,7 @@ __build_packet_message(struct nfulnl_instance *inst,
struct nlmsghdr *nlh;
struct nfgenmsg *nfmsg;
sk_buff_data_t old_tail = inst->skb->tail;
+ struct sock *sk;
nlh = nlmsg_put(inst->skb, 0, 0,
NFNL_SUBSYS_ULOG << 8 | NFULNL_MSG_PACKET,
@@ -499,18 +500,19 @@ __build_packet_message(struct nfulnl_instance *inst,
}
/* UID */
- if (skb->sk) {
- read_lock_bh(&skb->sk->sk_callback_lock);
- if (skb->sk->sk_socket && skb->sk->sk_socket->file) {
- struct file *file = skb->sk->sk_socket->file;
+ sk = skb->sk;
+ if (sk && sk->sk_state != TCP_TIME_WAIT) {
+ read_lock_bh(&sk->sk_callback_lock);
+ if (sk->sk_socket && sk->sk_socket->file) {
+ struct file *file = sk->sk_socket->file;
__be32 uid = htonl(file->f_cred->fsuid);
__be32 gid = htonl(file->f_cred->fsgid);
- read_unlock_bh(&skb->sk->sk_callback_lock);
+ read_unlock_bh(&sk->sk_callback_lock);
if (nla_put_be32(inst->skb, NFULA_UID, uid) ||
nla_put_be32(inst->skb, NFULA_GID, gid))
goto nla_put_failure;
} else
- read_unlock_bh(&skb->sk->sk_callback_lock);
+ read_unlock_bh(&sk->sk_callback_lock);
}
/* local sequence number */
diff --git a/net/netfilter/xt_LOG.c b/net/netfilter/xt_LOG.c
index ff5f75f..2a4f969 100644
--- a/net/netfilter/xt_LOG.c
+++ b/net/netfilter/xt_LOG.c
@@ -145,6 +145,19 @@ static int dump_tcp_header(struct sbuff *m, const struct sk_buff *skb,
return 0;
}
+static void dump_sk_uid_gid(struct sbuff *m, struct sock *sk)
+{
+ if (!sk || sk->sk_state == TCP_TIME_WAIT)
+ return;
+
+ read_lock_bh(&sk->sk_callback_lock);
+ if (sk->sk_socket && sk->sk_socket->file)
+ sb_add(m, "UID=%u GID=%u ",
+ sk->sk_socket->file->f_cred->fsuid,
+ sk->sk_socket->file->f_cred->fsgid);
+ read_unlock_bh(&sk->sk_callback_lock);
+}
+
/* One level of recursion won't kill us */
static void dump_ipv4_packet(struct sbuff *m,
const struct nf_loginfo *info,
@@ -361,14 +374,8 @@ static void dump_ipv4_packet(struct sbuff *m,
}
/* Max length: 15 "UID=4294967295 " */
- if ((logflags & XT_LOG_UID) && !iphoff && skb->sk) {
- read_lock_bh(&skb->sk->sk_callback_lock);
- if (skb->sk->sk_socket && skb->sk->sk_socket->file)
- sb_add(m, "UID=%u GID=%u ",
- skb->sk->sk_socket->file->f_cred->fsuid,
- skb->sk->sk_socket->file->f_cred->fsgid);
- read_unlock_bh(&skb->sk->sk_callback_lock);
- }
+ if ((logflags & XT_LOG_UID) && !iphoff)
+ dump_sk_uid_gid(m, skb->sk);
/* Max length: 16 "MARK=0xFFFFFFFF " */
if (!iphoff && skb->mark)
@@ -717,14 +724,8 @@ static void dump_ipv6_packet(struct sbuff *m,
}
/* Max length: 15 "UID=4294967295 " */
- if ((logflags & XT_LOG_UID) && recurse && skb->sk) {
- read_lock_bh(&skb->sk->sk_callback_lock);
- if (skb->sk->sk_socket && skb->sk->sk_socket->file)
- sb_add(m, "UID=%u GID=%u ",
- skb->sk->sk_socket->file->f_cred->fsuid,
- skb->sk->sk_socket->file->f_cred->fsgid);
- read_unlock_bh(&skb->sk->sk_callback_lock);
- }
+ if ((logflags & XT_LOG_UID) && recurse)
+ dump_sk_uid_gid(m, skb->sk);
/* Max length: 16 "MARK=0xFFFFFFFF " */
if (!recurse && skb->mark)
^ permalink raw reply related
* Re: [PATCH iproute2 2/2] iplink: added support for ipoib rtnl link ops
From: Stephen Hemminger @ 2012-09-04 17:48 UTC (permalink / raw)
To: Or Gerlitz; +Cc: davem, roland, netdev
In-Reply-To: <1345724119-32110-3-git-send-email-ogerlitz@mellanox.com>
On Thu, 23 Aug 2012 15:15:19 +0300
Or Gerlitz <ogerlitz@mellanox.com> wrote:
> Added basic support to create/delete IPoIB child devices,
> where the user can optionally specify the IB PKEY (Partition Key)
> to be used by the newly created device. If nothing is provided,
> the child will use the same pkey as the parent.
>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
This is a good way to manage the child devices.
But I am holding off merging it into iproute2 until after the
kernel parts are final (in Linus's tree). Please resubmit
after the kernel parts are merged.
^ permalink raw reply
* Re: Commit "ipconfig wait for carrier" makes boot hang for 2 mins if no carrier
From: Joakim Tjernlund @ 2012-09-04 18:04 UTC (permalink / raw)
To: Micha Nelissen; +Cc: netdev
In-Reply-To: <504627A4.9080306@neli.hopto.org>
-----Micha Nelissen <micha@neli.hopto.org> wrote: -----
>
> Op 2012-09-04 16:41, Joakim Tjernlund schreef: > Above mentioned
> commit(3fb72f1e6e6165c5f495e8dc11c5bbd14c73385c) changes
> a ~1 sec delay to ~120 sec boot delay
> if no carrier. This is a really
> long time to wait if you just want to set an IP address but
> doesn't
> care about NFS root, holds up the boot with 2 minutes.
>
> Why not set the IP address then in your rootfs yourself? Micha
I could ask you the same question, why do you need to have nfs in kernel?
The answer is probably the same, it is much easier to
manage our IP config in one place for our embedded system.
I don't understand why you need 2 minutes timeout for carrier either?
The wait should be conditional on NFS root or not so that non NFS roots
can skip this stage altogether.
Jocke
^ permalink raw reply
* Re: [PATCH] net: don't allow INET to be not configured
From: David Miller @ 2012-09-04 18:07 UTC (permalink / raw)
To: shemminger; +Cc: rdunlap, sfr, linux-next, linux-kernel, netdev
In-Reply-To: <20120904104451.29819808@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 4 Sep 2012 10:44:51 -0700
> There is no reason to expose turning off TCP/IP networking.
> If networking is enabled force TCP/IP to enabled. This also
> eliminates the time chasing down errors with bogus configurations
> generated by 'make randconfig'
>
> For testing, it is still possible to edit Kconfig
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
People have legitimate reasons to enable NET without INET, so let's
just fix the dependency bugs as they are reported.
^ permalink raw reply
* Re: [PATCH] l2tp: fix a lockdep splat
From: David Miller @ 2012-09-04 18:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1346779137.13121.54.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 04 Sep 2012 19:18:57 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Fixes following lockdep splat :
...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] xfrm: Workaround incompatibility of ESN and async crypto
From: David Miller @ 2012-09-04 18:10 UTC (permalink / raw)
To: herbert; +Cc: steffen.klassert, netdev
In-Reply-To: <20120904123155.GA3152@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 4 Sep 2012 05:31:55 -0700
> On Tue, Sep 04, 2012 at 12:03:29PM +0200, Steffen Klassert wrote:
>> ESN for esp is defined in RFC 4303. This RFC assumes that the
>> sequence number counters are always up to date. However,
>> this is not true if an async crypto algorithm is employed.
>>
>> If the sequence number counters are not up to date on sequence
>> number check, we may incorrectly update the upper 32 bit of
>> the sequence number. This leads to a DOS.
>>
>> We workaround this by comparing the upper sequence number,
>> (used for authentication) with the upper sequence number
>> computed after the async processing. We drop the packet
>> if these numbers are different.
>>
>> To do this, we introduce a recheck function that does this
>> check in the ESN case.
>>
>> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> It took me a while to understand the problem but Steffen was
> correct again as usual.
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] sctp: use list_move_tail instead of list_del/list_add_tail
From: David Miller @ 2012-09-04 18:16 UTC (permalink / raw)
To: weiyj.lk; +Cc: vyasevich, sri, yongjun_wei, linux-sctp, netdev
In-Reply-To: <CAPgLHd_w3-iAT66PW2i_jYyqmNrF-fKczcUEdBemPMvWX+fbOQ@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Tue, 4 Sep 2012 17:58:16 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Using list_move_tail() instead of list_del() + list_add_tail().
>
> spatch with a semantic match is used to found this problem.
> (http://coccinelle.lip6.fr/)
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied to net-next, thank you.
^ permalink raw reply
* Re: [PATCH net-next 4/7] openvswitch: Reset upper layer protocol info on internal devices.
From: David Miller @ 2012-09-04 18:22 UTC (permalink / raw)
To: jesse-l0M0P4e3n4LQT0dZR+AlfA
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
chrisw-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <CAEP_g=_+Q4Axi0vH8nce6zVZgs++62PbiTWum_z+s_PbpwzgOA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Date: Mon, 3 Sep 2012 18:07:29 -0700
> On Mon, Sep 3, 2012 at 6:00 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>> From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
>> Date: Mon, 3 Sep 2012 17:57:39 -0700
>>
>>> On Fri, Jul 20, 2012 at 3:26 PM, Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org> wrote:
>>>> It's possible that packets that are sent on internal devices (from
>>>> the OVS perspective) have already traversed the local IP stack.
>>>> After they go through the internal device, they will again travel
>>>> through the IP stack which may get confused by the presence of
>>>> existing information in the skb. The problem can be observed
>>>> when switching between namespaces. This clears out that information
>>>> to avoid problems but deliberately leaves other metadata alone.
>>>> This is to provide maximum flexibility in chaining together OVS
>>>> and other Linux components.
>>>>
>>>> Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
>>>
>>> It was recently discovered that the bug that this patch fixes is
>>> causing problems in the real world. Can you please queue this for
>>> stable in 3.4/3.5? It's currently in Linus's tree as
>>> 7fe99e2d434eafeac0c57b279a77e5de39212636.
>>>
>>
>> What vendor is shipping openvswitch enabled and requires the fix to
>> be in -stable before they'll ship it to customers?
>>
>> That goes into what is 'real world'
>
> Fedora is running into it I believe. Chris Wright asked for it so he
> might be able to elaborate more on their plans.
Anyways, I've meanwhile queued it up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next 4/7] openvswitch: Reset upper layer protocol info on internal devices.
From: Chris Wright @ 2012-09-04 18:23 UTC (permalink / raw)
To: Jesse Gross
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
chrisw-H+wXaHxf7aLQT0dZR+AlfA, David Miller
In-Reply-To: <CAEP_g=_+Q4Axi0vH8nce6zVZgs++62PbiTWum_z+s_PbpwzgOA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
* Jesse Gross (jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org) wrote:
> On Mon, Sep 3, 2012 at 6:00 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> > From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
> > Date: Mon, 3 Sep 2012 17:57:39 -0700
> >
> >> On Fri, Jul 20, 2012 at 3:26 PM, Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org> wrote:
> >>> It's possible that packets that are sent on internal devices (from
> >>> the OVS perspective) have already traversed the local IP stack.
> >>> After they go through the internal device, they will again travel
> >>> through the IP stack which may get confused by the presence of
> >>> existing information in the skb. The problem can be observed
> >>> when switching between namespaces. This clears out that information
> >>> to avoid problems but deliberately leaves other metadata alone.
> >>> This is to provide maximum flexibility in chaining together OVS
> >>> and other Linux components.
> >>>
> >>> Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
> >>
> >> It was recently discovered that the bug that this patch fixes is
> >> causing problems in the real world. Can you please queue this for
> >> stable in 3.4/3.5? It's currently in Linus's tree as
> >> 7fe99e2d434eafeac0c57b279a77e5de39212636.
> >>
> >
> > What vendor is shipping openvswitch enabled and requires the fix to
> > be in -stable before they'll ship it to customers?
> >
> > That goes into what is 'real world'
>
> Fedora is running into it I believe. Chris Wright asked for it so he
> might be able to elaborate more on their plans.
I've not hit the bug myself, but been made aware of the issue from
OpenStack/Quantum folks.
There's a testing scenario that hits this as described in this launchpad
bug:
https://bugs.launchpad.net/quantum/+bug/1044318
thanks,
-chris
^ permalink raw reply
* Re: [PATCH 1/4] net: mvneta: driver for Marvell Armada 370/XP network unit
From: Andrew Lunn @ 2012-09-04 18:31 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
Lennert Buytenhek, David Marlin, Rami Rosen, Yehuda Yitschak,
Jani Monoses, Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Li Li,
Leif Lindholm, Sebastian Hesselbarth, Jason Cooper, Arnd Bergmann,
Jon Masters, Ben Dooks, Gregory Clement, linux-arm-kernel,
Chris Van Hoof, Nicolas Pitre <n
In-Reply-To: <20120904175610.2c2934f1@skate>
> > I think we normally put the phy into a separate device node on an
> > mdio bus and then use the of_phy_* functions to connect it to
> > the ethernet device.
>
> Even though it may not be a convincing argument, none of the existing DT
> files in arch/arm/boot/dts seem to instantiate a separate PHY device
> and a proper MDIO bus. However, the PowerPC platforms indeed make this
> distinction a lot clearer.
>
> However, this network unit has a clever MAC that autonomously queries
> the PHY for the link status, and reports changes (link, duplex, speed)
> in the form of MAC interrupts and MAC registers. Therefore, for basic
> operation, there is no need for a separate PHY driver nor to expose the
> MDIO bus in any way. The only thing needed is the PHY address, which is
> filled into a register of the MAC so that it can start its automatic
> query of the PHY.
Hi Thomas
I've used Marvell switch chipsets, which have a phy polling unit,
PPU. This sounds very similar. You can do a lot with the PPU, but when
you want to configure subsets of auto-negotiation rates/duplex modes,
or fixed speeds/duplex modes, the PPU could not do it. You had to
disable the PPU and configure the PHY directly.
I see you have some of the ethtools API calls implemented, but not the
ones needed for auto-neg and rates/duplex mode configurations. Does
the neta PPU support this, or will you need to export the MDIO bus for
these sorts of configuration options?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH iproute2 2/2] iplink: added support for ipoib rtnl link ops
From: Or Gerlitz @ 2012-09-04 18:35 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Or Gerlitz, davem, roland, netdev
In-Reply-To: <20120904104841.3e9f848b@nehalam.linuxnetplumber.net>
On Tue, Sep 4, 2012 at 8:48 PM, Stephen Hemminger <shemminger@vyatta.com> wrote:
> This is a good way to manage the child devices.
> But I am holding off merging it into iproute2 until after the
> kernel parts are final (in Linus's tree). Please resubmit
> after the kernel parts are merged.
sure,
Or.
^ permalink raw reply
* Re: [PATCH v7 1/1] ieee802154: MRF24J40 driver
From: David Miller @ 2012-09-04 18:46 UTC (permalink / raw)
To: alan
Cc: alex.bluesman.smirnov, dbaryshkov, tony.cheneau,
linux-zigbee-devel, netdev, linux-kernel
In-Reply-To: <1346636653-28903-2-git-send-email-alan@signal11.us>
From: Alan Ott <alan@signal11.us>
Date: Sun, 2 Sep 2012 21:44:13 -0400
> Driver for the Microchip MRF24J40 802.15.4 WPAN module.
>
> Signed-off-by: Alan Ott <alan@signal11.us>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Or Gerlitz @ 2012-09-04 18:50 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Eric W. Biederman, Or Gerlitz, davem, roland, netdev, sean.hefty,
Erez Shitrit, Ali Ayoub, Doug Ledford
In-Reply-To: <20120903212230.GA6795@redhat.com>
On Tue, Sep 4, 2012 at 12:22 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Mon, Sep 03, 2012 at 11:53:56PM +0300, Or Gerlitz wrote:
>> So we are remained with #3 - the ARPs -- thinking on this a little
>> further, FWIW there --are-- components in the kernel which
>> mangle/generate ARPs and are exposing netdevice, such as openvswitch, anyway:
>> does it make sense to forward ARPs received into / sent over the
>> eIPoIB netdevice (e.g using some sort of rule) to some outer entity
>> such as user-space daemon for interception and later re-injection into eIPoIB?
> Well if this is all you want to do, you can bind a packet socket to the
> interface, and drop them at the nic. It is harder to do for incoming
> ARP requests though.
> I would do something else: send ARPs out to some defined IB address.
> This could be local host or queries from some SA property. Said remote
> side could send you the responses in ethernet format so you do not need
> to mangle responses at all. Similarly for incoming ARP requests.
> The rule to do this can also just redirect non IP packets - this is IPoIB after all.
Thanks for the heads up on the possible implementation route, will
look into that.
>> Documentation we will fix,
> And just to stress the point, document the limitations as well.
sure, not that I see concrete limitations for the **user** at this point, but
if there are such, will put them clearly written.
Or.
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Or Gerlitz @ 2012-09-04 18:57 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Eric W. Biederman, Or Gerlitz, davem, roland, netdev, sean.hefty,
Erez Shitrit, Ali Ayoub, Doug Ledford
In-Reply-To: <20120903212230.GA6795@redhat.com>
On Tue, Sep 4, 2012 at 12:22 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Mon, Sep 03, 2012 at 11:53:56PM +0300, Or Gerlitz wrote:
>> Michael S. Tsirkin <mst@redhat.com> wrote:
>> > [...] so it seems that a sane solution would involve an extra level of
>> > indirection, with guest addresses being translated to host IB addresses.
>> > As long as you do this, maybe using an ethernet frame format makes sense.
>>
>> > So far the things that make sense. Here are some that don't, to me:
>>
>> > - Is a pdf presentation all you have in terms of documentation?
>> > We are talking communication protocols here - I would expect a
>> > proper spec, and some effort to standardize, otherwise where's the
>> > guarantee it won't change in an incompatible way?
>> > Other things that I would expect to be addressed in such a spec is
>> > interaction with other IPoIB features, such as connected
>> > mode, checksum offloading etc, and IB features such as multipath etc.
>> >
>> > - The way you encode LID/QPN in the MAC seems questionable. IIRC there's
>> > more to IB addressing than just the LID. Since everyone on the subnet
>> > need access to this translation, I think it makes sense to store it in
>> > the SM. I think this would also obviate some IPv4 specific hacks in kernel.
>>
>> > - IGMP/MAC snooping in a driver is just too hairy.
>> > As you point out, bridge currently needs the uplink in promisc mode.
>> > I don't think a driver should work around that limitation.
>> > For some setups, it might be interesting to remove the promisc
>> > mode requirement, failing that, I think you could use macvtap passthrough.
>> >
>> > - Currently migration works without host kernel help, would be
>> > preferable to keep it that way.
>> If we rewind to this point, basically, you had few concerns
> I think some other people gave feedback too, you need to address it in
> the patch (as opposed to by mail - even if it's in documentation or
> comments) don't just focus on what I wrote.
The other feedback was:
1. suggesting to introduce new link layer for the para-virtualized
network stack, a direction pointed by Dave and you, for which I
responded that it doesn't address a hard requirement I got, which is
provide service to an arbitrary VM which have any OS and a virtual
Ethernet NIC on, emulated or para-virtualized.
2. Suggestions to use solutions which involve routing and/or
proxt-arp, for which I responded that in most/practical cases this
will require for the host to know the VM IP, something which isn't
valid assumption in many cases AND that bunch of cloud stacks,
specifically the leading ones, don't even support that option, which
also violates a hard requirement we got, to support these stacks which
are in use by customers.
3. Suggestions to invent EoIB -- I said, OK but this is long termish
process that we're looking on, might be around at some future point,
but still we are required to support whole echo systems which use
IPoIB, and there's no point to "route" between EoIB segment to IPoIB
segments, its back to #2 which we didn't accept
4. Other feedback saying the eIPoIB driver is messy and "we don't like
it" -- hard to exactly address in code changes
----> all in all, we were suggested few directions which don't allow
us to address the problem statement, so there's no way to change the
code so they are fullfilled, and some not concrete comments which are
also hard to address --> we took the route of design changes along
your **concrete** comments, doesn't it make sense?
Or.
^ permalink raw reply
* Re: [RFC PATCH 0/5] net: socket bind to file descriptor introduced
From: J. Bruce Fields @ 2012-09-04 19:00 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Eric W. Biederman, tglx@linutronix.de, mingo@redhat.com,
davem@davemloft.net, hpa@zytor.com,
thierry.reding@avionic-design.de, bfields@redhat.com,
eric.dumazet@gmail.com, Pavel Emelianov, neilb@suse.de,
netdev@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, paul.gortmaker@windriver.com,
viro@zeniv.linux.org.uk, gorcunov@openvz.org,
akpm@linux-foundation.org, tim.c.chen@linux.intel.com,
"devel@ope
In-Reply-To: <50320EE5.10307@parallels.com>
On Mon, Aug 20, 2012 at 02:18:13PM +0400, Stanislav Kinsbursky wrote:
> 16.08.2012 07:03, Eric W. Biederman пишет:
> >Stanislav Kinsbursky <skinsbursky@parallels.com> writes:
> >
> >>This patch set introduces new socket operation and new system call:
> >>sys_fbind(), which allows to bind socket to opened file.
> >>File to bind to can be created by sys_mknod(S_IFSOCK) and opened by
> >>open(O_PATH).
> >>
> >>This system call is especially required for UNIX sockets, which has name
> >>lenght limitation.
> >>
> >>The following series implements...
> >
> >Hmm. I just realized this patchset is even sillier than I thought.
> >
> >Stanislav is the problem you are ultimately trying to solve nfs clients
> >in a container connecting to the wrong user space rpciod?
> >
>
> Hi, Eric.
> The problem you mentioned was the reason why I started to think about this.
> But currently I believe, that limitations in unix sockets connect or
> bind should be removed, because it will be useful it least for CRIU
> project.
>
> >Aka net/sunrpc/xprtsock.c:xs_setup_local only taking an absolute path
> >and then creating a delayed work item to actually open the unix domain
> >socket?
> >
> >The straight correct and straight forward thing to do appears to be:
> >- Capture the root from current->fs in xs_setup_local.
> >- In xs_local_finish_connect change current->fs.root to the captured
> > version of root before kernel_connect, and restore current->fs.root
> > after kernel_connect.
> >
> >It might not be a bad idea to implement open on unix domain sockets in
> >a filesystem as create(AF_LOCAL)+connect() which would allow you to
> >replace __sock_create + kernel_connect with a simple file_open_root.
> >
>
> I like the idea of introducing new family (AF_LOCAL_AT for example)
> and new sockaddr for connecting or binding from specified root. The
> only thing I'm worrying is passing file descriptor to unix bind or
> connect routine. Because this approach doesn't provide easy way to
> use such family and sockaddr in kernel (like in NFS example).
>
> >But I think the simple scheme of:
> >struct path old_root;
> >old_root = current->fs.root;
> >kernel_connect(...);
> >current->fs.root = old_root;
> >
> >Is more than sufficient and will remove the need for anything
> >except a purely local change to get nfs clients to connect from
> >containers.
> >
>
> That was my first idea.
So is this what you're planning on doing now?
> And probably it would be worth to change all
> fs_struct to support sockets with relative path.
> What do you think about it?
I didn't understand the question. Are you suggesting that changes to
fs_struct would be required to make this work? I don't see why.
--b.
^ permalink raw reply
* [PATCH net 1/3] openvswitch: Relax set header validation.
From: Jesse Gross @ 2012-09-04 19:08 UTC (permalink / raw)
To: David Miller; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1346785688-2910-1-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
When installing a flow with an action to set a particular field we
need to validate that the packets that are part of the flow actually
contain that header. With IP we use zeroed addresses and with TCP/UDP
the check is for zeroed ports. This check is overly broad and can catch
packets like DHCP requests that have a zero source address in a
legitimate header. This changes the check to look for a zeroed protocol
number for IP or for both ports be zero for TCP/UDP before considering
the header to not exist.
Reported-by: Ethan Jackson <ethan-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
---
net/openvswitch/datapath.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index d8277d2..cf58ced 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -425,10 +425,10 @@ static int validate_sample(const struct nlattr *attr,
static int validate_tp_port(const struct sw_flow_key *flow_key)
{
if (flow_key->eth.type == htons(ETH_P_IP)) {
- if (flow_key->ipv4.tp.src && flow_key->ipv4.tp.dst)
+ if (flow_key->ipv4.tp.src || flow_key->ipv4.tp.dst)
return 0;
} else if (flow_key->eth.type == htons(ETH_P_IPV6)) {
- if (flow_key->ipv6.tp.src && flow_key->ipv6.tp.dst)
+ if (flow_key->ipv6.tp.src || flow_key->ipv6.tp.dst)
return 0;
}
@@ -460,7 +460,7 @@ static int validate_set(const struct nlattr *a,
if (flow_key->eth.type != htons(ETH_P_IP))
return -EINVAL;
- if (!flow_key->ipv4.addr.src || !flow_key->ipv4.addr.dst)
+ if (!flow_key->ip.proto)
return -EINVAL;
ipv4_key = nla_data(ovs_key);
--
1.7.9.5
^ permalink raw reply related
* [PATCH net 2/3] openvswitch: Fix typo
From: Jesse Gross @ 2012-09-04 19:08 UTC (permalink / raw)
To: David Miller; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1346785688-2910-1-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
From: Joe Stringer <joe-Q1GJJQv1iO6lP80pJB477g@public.gmane.org>
Signed-off-by: Joe Stringer <joe-Q1GJJQv1iO6lP80pJB477g@public.gmane.org>
Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
---
net/openvswitch/actions.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index f3f96ba..954405c 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -45,7 +45,7 @@ static int make_writable(struct sk_buff *skb, int write_len)
return pskb_expand_head(skb, 0, 0, GFP_ATOMIC);
}
-/* remove VLAN header from packet and update csum accrodingly. */
+/* remove VLAN header from packet and update csum accordingly. */
static int __pop_vlan_tci(struct sk_buff *skb, __be16 *current_tci)
{
struct vlan_hdr *vhdr;
--
1.7.9.5
^ permalink raw reply related
* [PATCH net 3/3] openvswitch: Fix FLOW_BUFSIZE definition.
From: Jesse Gross @ 2012-09-04 19:08 UTC (permalink / raw)
To: David Miller; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1346785688-2910-1-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
The vlan encapsulation fields in the maximum flow defintion were
never updated when the representation changed before upstreaming.
In theory this could cause a kernel panic when a maximum length
flow is used. In practice this has never happened (to my knowledge)
because skb allocations are padded out to a cache line so you would
need the right combination of flow and packet being sent to userspace.
Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
---
net/openvswitch/flow.h | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
index 9b75617..c30df1a 100644
--- a/net/openvswitch/flow.h
+++ b/net/openvswitch/flow.h
@@ -145,15 +145,17 @@ u64 ovs_flow_used_time(unsigned long flow_jiffies);
* OVS_KEY_ATTR_PRIORITY 4 -- 4 8
* OVS_KEY_ATTR_IN_PORT 4 -- 4 8
* OVS_KEY_ATTR_ETHERNET 12 -- 4 16
+ * OVS_KEY_ATTR_ETHERTYPE 2 2 4 8 (outer VLAN ethertype)
* OVS_KEY_ATTR_8021Q 4 -- 4 8
- * OVS_KEY_ATTR_ETHERTYPE 2 2 4 8
+ * OVS_KEY_ATTR_ENCAP 0 -- 4 4 (VLAN encapsulation)
+ * OVS_KEY_ATTR_ETHERTYPE 2 2 4 8 (inner VLAN ethertype)
* OVS_KEY_ATTR_IPV6 40 -- 4 44
* OVS_KEY_ATTR_ICMPV6 2 2 4 8
* OVS_KEY_ATTR_ND 28 -- 4 32
* -------------------------------------------------
- * total 132
+ * total 144
*/
-#define FLOW_BUFSIZE 132
+#define FLOW_BUFSIZE 144
int ovs_flow_to_nlattrs(const struct sw_flow_key *, struct sk_buff *);
int ovs_flow_from_nlattrs(struct sw_flow_key *swkey, int *key_lenp,
--
1.7.9.5
^ permalink raw reply related
* [GIT net] Open vSwitch
From: Jesse Gross @ 2012-09-04 19:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, dev
A few bug fixes intended for net/3.6.
The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee:
Linux 3.6-rc1 (2012-08-02 16:38:10 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jesse/openvswitch.git fixes
for you to fetch changes up to c303aa94cdae483a7577230e61720e126e600a52:
openvswitch: Fix FLOW_BUFSIZE definition. (2012-09-03 19:06:27 -0700)
----------------------------------------------------------------
Jesse Gross (2):
openvswitch: Relax set header validation.
openvswitch: Fix FLOW_BUFSIZE definition.
Joe Stringer (1):
openvswitch: Fix typo
net/openvswitch/actions.c | 2 +-
net/openvswitch/datapath.c | 6 +++---
net/openvswitch/flow.h | 8 +++++---
3 files changed, 9 insertions(+), 7 deletions(-)
^ permalink raw reply
* Re: [PATCH] i825xx: fix paging fault on znet_probe()
From: David Miller @ 2012-09-04 19:13 UTC (permalink / raw)
To: fengguang.wu; +Cc: jeffrey.t.kirsher, netdev, linux-kernel
In-Reply-To: <20120902072546.GA20290@localhost>
From: Fengguang Wu <fengguang.wu@intel.com>
Date: Sun, 2 Sep 2012 15:25:46 +0800
> In znet_probe(), strncmp() may access beyond 0x100000 and
> trigger the below oops in kvm. Fix it by limiting the loop
> under 0x100000-8. I suspect the limit could be further decreased
> to 0x100000-sizeof(struct netidblk), however no datasheet at hand..
...
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
This also makes the code actually match the description in the comment
above the loop :-)
Applied, thanks.
^ permalink raw reply
* [GIT net-next] Open vSwitch
From: Jesse Gross @ 2012-09-04 19:14 UTC (permalink / raw)
To: David Miller; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
Two feature additions to Open vSwitch for net-next/3.7.
The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee:
Linux 3.6-rc1 (2012-08-02 16:38:10 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jesse/openvswitch.git master
for you to fetch changes up to 15eac2a74277bc7de68a7c2a64a7c91b4b6f5961:
openvswitch: Increase maximum number of datapath ports. (2012-09-03 19:20:49 -0700)
----------------------------------------------------------------
Pravin B Shelar (2):
openvswitch: Add support for network namespaces.
openvswitch: Increase maximum number of datapath ports.
net/openvswitch/actions.c | 2 +-
net/openvswitch/datapath.c | 375 +++++++++++++++++++++-------------
net/openvswitch/datapath.h | 50 ++++-
net/openvswitch/dp_notify.c | 8 +-
net/openvswitch/flow.c | 11 +-
net/openvswitch/flow.h | 3 +-
net/openvswitch/vport-internal_dev.c | 7 +-
net/openvswitch/vport-netdev.c | 2 +-
net/openvswitch/vport.c | 23 ++-
net/openvswitch/vport.h | 7 +-
10 files changed, 317 insertions(+), 171 deletions(-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox