* Re: [PATCH 02/16] user_ns: use new hashtable implementation
From: Eric W. Biederman @ 2012-08-14 23:52 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds, tj, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, aarcange, ericvh, netdev, josh, eric.dumazet,
mathieu.desnoyers, axboe, agk, dm-devel, neilb, ccaulfie,
teigland, Trond.Myklebust, bfields, fweisbec, jesse,
venkat.x.venkatsubra, ejt, snitzer, edumazet, linux-nfs, dev,
rds-devel, lw
In-Reply-To: <1344961490-4068-3-git-send-email-levinsasha928@gmail.com>
Sasha Levin <levinsasha928@gmail.com> writes:
> Switch user_ns to use the new hashtable implementation. This reduces the amount of
> generic unrelated code in user_ns.
Two concerns here.
1) When adding a new entry you recompute the hash where previously that
was not done. I believe that will slow down adding of new entries.
2) Using hash_32 for uids is an interesting choice. hash_32 discards
the low bits. Last I checked for uids the low bits were the bits
that were most likely to be different and had the most entropy.
I'm not certain how multiplying by the GOLDEN_RATION_PRIME_32 will
affect things but I would be surprised if it shifted all of the
randomness from the low bits to the high bits.
And just a nit. struct user is essentially orthogonal to the user namespace
at this point, making the description of the patch a little weird.
Eric
> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> ---
> kernel/user.c | 33 +++++++++++++--------------------
> 1 files changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/kernel/user.c b/kernel/user.c
> index b815fef..d10c484 100644
> --- a/kernel/user.c
> +++ b/kernel/user.c
> @@ -16,6 +16,7 @@
> #include <linux/interrupt.h>
> #include <linux/export.h>
> #include <linux/user_namespace.h>
> +#include <linux/hashtable.h>
>
> /*
> * userns count is 1 for root user, 1 for init_uts_ns,
> @@ -52,13 +53,9 @@ EXPORT_SYMBOL_GPL(init_user_ns);
> */
>
> #define UIDHASH_BITS (CONFIG_BASE_SMALL ? 3 : 7)
> -#define UIDHASH_SZ (1 << UIDHASH_BITS)
> -#define UIDHASH_MASK (UIDHASH_SZ - 1)
> -#define __uidhashfn(uid) (((uid >> UIDHASH_BITS) + uid) & UIDHASH_MASK)
> -#define uidhashentry(uid) (uidhash_table + __uidhashfn((__kuid_val(uid))))
>
> static struct kmem_cache *uid_cachep;
> -struct hlist_head uidhash_table[UIDHASH_SZ];
> +static DEFINE_HASHTABLE(uidhash_table, UIDHASH_BITS)
>
> /*
> * The uidhash_lock is mostly taken from process context, but it is
> @@ -84,22 +81,22 @@ struct user_struct root_user = {
> /*
> * These routines must be called with the uidhash spinlock held!
> */
> -static void uid_hash_insert(struct user_struct *up, struct hlist_head *hashent)
> +static void uid_hash_insert(struct user_struct *up)
> {
> - hlist_add_head(&up->uidhash_node, hashent);
> + hash_add(uidhash_table, &up->uidhash_node, __kuid_val(up->uid));
> }
>
> static void uid_hash_remove(struct user_struct *up)
> {
> - hlist_del_init(&up->uidhash_node);
> + hash_del(&up->uidhash_node);
> }
>
> -static struct user_struct *uid_hash_find(kuid_t uid, struct hlist_head *hashent)
> +static struct user_struct *uid_hash_find(kuid_t uid)
> {
> struct user_struct *user;
> struct hlist_node *h;
>
> - hlist_for_each_entry(user, h, hashent, uidhash_node) {
> + hash_for_each_possible(uidhash_table, user, h, uidhash_node, __kuid_val(uid)) {
> if (uid_eq(user->uid, uid)) {
> atomic_inc(&user->__count);
> return user;
> @@ -135,7 +132,7 @@ struct user_struct *find_user(kuid_t uid)
> unsigned long flags;
>
> spin_lock_irqsave(&uidhash_lock, flags);
> - ret = uid_hash_find(uid, uidhashentry(uid));
> + ret = uid_hash_find(uid);
> spin_unlock_irqrestore(&uidhash_lock, flags);
> return ret;
> }
> @@ -156,11 +153,10 @@ void free_uid(struct user_struct *up)
>
> struct user_struct *alloc_uid(kuid_t uid)
> {
> - struct hlist_head *hashent = uidhashentry(uid);
> struct user_struct *up, *new;
>
> spin_lock_irq(&uidhash_lock);
> - up = uid_hash_find(uid, hashent);
> + up = uid_hash_find(uid);
> spin_unlock_irq(&uidhash_lock);
>
> if (!up) {
> @@ -176,13 +172,13 @@ struct user_struct *alloc_uid(kuid_t uid)
> * on adding the same user already..
> */
> spin_lock_irq(&uidhash_lock);
> - up = uid_hash_find(uid, hashent);
> + up = uid_hash_find(uid);
> if (up) {
> key_put(new->uid_keyring);
> key_put(new->session_keyring);
> kmem_cache_free(uid_cachep, new);
> } else {
> - uid_hash_insert(new, hashent);
> + uid_hash_insert(new);
> up = new;
> }
> spin_unlock_irq(&uidhash_lock);
> @@ -196,17 +192,14 @@ out_unlock:
>
> static int __init uid_cache_init(void)
> {
> - int n;
> -
> uid_cachep = kmem_cache_create("uid_cache", sizeof(struct user_struct),
> 0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
>
> - for(n = 0; n < UIDHASH_SZ; ++n)
> - INIT_HLIST_HEAD(uidhash_table + n);
> + hash_init(uidhash_table);
>
> /* Insert the root user immediately (init already runs as root) */
> spin_lock_irq(&uidhash_lock);
> - uid_hash_insert(&root_user, uidhashentry(GLOBAL_ROOT_UID));
> + uid_hash_insert(&root_user);
> spin_unlock_irq(&uidhash_lock);
>
> return 0;
--
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
* Re: [PATCH net 1/3] llc2: Fix silent failure of llc_station_init()
From: David Miller @ 2012-08-14 23:52 UTC (permalink / raw)
To: ben; +Cc: acme, netdev
In-Reply-To: <1344862199.824.140.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 13 Aug 2012 13:49:59 +0100
> llc_station_init() creates and processes an event skb with no effect
> other than to change the state from DOWN to UP. Allocation failure is
> reported, but then ignored by its caller, llc2_init(). Remove this
> possibility by simply initialising the state as UP.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH net 2/3] llc2: Call llc_station_exit() on llc2_init() failure path
From: David Miller @ 2012-08-14 23:52 UTC (permalink / raw)
To: ben; +Cc: acme, netdev
In-Reply-To: <1344862243.824.141.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 13 Aug 2012 13:50:43 +0100
> Otherwise the station packet handler will remain registered even though
> the module is unloaded.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
This will cause section mismatch errors, you'll need to remove
the __exit tag from llc_station_exit() if you want to start
invoking it from llc2_init() which is __init.
I took care of this when applying this patch to 'net'.
^ permalink raw reply
* Re: [PATCH net 3/3] llc: Fix races between llc2 handler use and (un)registration
From: David Miller @ 2012-08-14 23:52 UTC (permalink / raw)
To: ben; +Cc: acme, netdev
In-Reply-To: <1344862255.824.142.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 13 Aug 2012 13:50:55 +0100
> When registering the handlers, any state they rely on must be
> completely initialised first. When unregistering, we must wait until
> they are definitely no longer running. llc_rcv() must also avoid
> reading the handler pointers again after checking for NULL.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/4] packet: Sock-diag extension for packet sockets (beginning)
From: David Miller @ 2012-08-14 23:56 UTC (permalink / raw)
To: xemul; +Cc: netdev
In-Reply-To: <5029219C.20305@parallels.com>
From: Pavel Emelyanov <xemul@parallels.com>
Date: Mon, 13 Aug 2012 19:47:40 +0400
> There's a set of stuff residing on a AF_PACKET socket which is currently
> write-only -- rings, copy_thresh and mclist. But we need to know these
> while doing the checkpoint-restore.
>
> As a solution for the similar problem with unix sockets, the sock-diag
> engine was developed, so here's the basic implementation of the packet
> sockets extension. It doesn't report rings, fanout and stats, but it can
> be easily added later.
>
> I'd like to mention, that it's not a strict requirement, that the diag is
> used for getting info about sockets, it would be perfectly fine just to
> fix the packet getsockopt callback to return the desired info. So, if the
> diag for packet sockets is for any reason unacceptable, just let me know.
All applied, looks fine.
Please number your patches properly next time, patch #3 was listed as 2/4
^ permalink raw reply
* Re: [PATCH 4/5] drivers/net/ethernet/ti/davinci_cpdma.c: Remove potential NULL dereference
From: David Miller @ 2012-08-15 0:00 UTC (permalink / raw)
To: Julia.Lawall; +Cc: netdev, kernel-janitors, linux-kernel
In-Reply-To: <1344959388-19719-5-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Tue, 14 Aug 2012 17:49:47 +0200
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> If the NULL test is necessary, the initialization involving a dereference of
> the tested value should be moved after the NULL test.
>
> The sematic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 3/5] drivers/net/ethernet/freescale/fs_enet: fix error return code
From: David Miller @ 2012-08-15 0:01 UTC (permalink / raw)
To: Julia.Lawall
Cc: pantelis.antoniou, kernel-janitors, vbordug, linuxppc-dev, netdev,
linux-kernel
In-Reply-To: <1344949115-13266-4-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Tue, 14 Aug 2012 14:58:33 +0200
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Convert a 0 error return code to a negative one, as returned elsewhere in the
> function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied.
^ permalink raw reply
* Re: [PATCH 4/5] drivers/net/ethernet/mellanox/mlx4/mcg.c: fix error return code
From: David Miller @ 2012-08-15 0:01 UTC (permalink / raw)
To: Julia.Lawall; +Cc: netdev, kernel-janitors, linux-kernel
In-Reply-To: <1344949115-13266-5-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Tue, 14 Aug 2012 14:58:34 +0200
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Convert a 0 error return code to a negative one, as returned elsewhere in the
> function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied.
^ permalink raw reply
* Re: [PATCH net] ipv6: addrconf: Avoid calling netdevice notifiers with RCU read-side lock
From: David Miller @ 2012-08-15 0:02 UTC (permalink / raw)
To: bhutchings
Cc: netdev, john.r.fastabend, gregory.v.rose, tgraf, edumazet, amwang
In-Reply-To: <1344970491.2690.8.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 14 Aug 2012 19:54:51 +0100
> Cong Wang reports that lockdep detected suspicious RCU usage while
> enabling IPV6 forwarding:
...
> addrconf_forward_change() uses RCU iteration over the netdev list,
> which is unnecessary since it already holds the RTNL lock. We also
> cannot reasonably require netdevice notifier functions not to sleep.
>
> Reported-by: Cong Wang <amwang@redhat.com>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied and queued up for -stable, thanks Ben.
^ permalink raw reply
* Re: pull request: wireless 2012-08-14
From: David Miller @ 2012-08-15 0:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20120814190245.GA22136@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 14 Aug 2012 15:02:46 -0400
> Alexey Khoroshilov provides a potential memory leak in rndis_wlan.
>
> Bob Copeland gives us an ath5k fix for a lockdep problem.
>
> Dan Carpenter fixes a signedness mismatch in at76c50x.
>
> Felix Fietkau corrects a regression caused by an earlier commit that can
> lead to an IRQ storm.
>
> Lorenzo Bianconi offers a fix for a bad variable initialization in ath9k
> that can cause it to improperly mark decrypted frames.
>
> Rajkumar Manoharan fixes ath9k to prevent the btcoex time from running
> when the hardware is asleep.
>
> The remainder are Bluetooth fixes, about which Gustavo says:
>
> "Here goes some fixes for 3.6-rc1, there are a few fix to
> thte inquiry code by Ram Malovany, support for 2 new devices,
> and few others fixes for NULL dereference, possible deadlock
> and a memory leak."
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [REVIEW][PATCH 0/21] User namespace changes to the networking stack.
From: David Miller @ 2012-08-15 0:12 UTC (permalink / raw)
To: ebiederm-aS9lmoZGLiVWk0Htik3J/w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
In-Reply-To: <87ehnav9n5.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
Date: Mon, 13 Aug 2012 13:07:10 -0700
>
> This is a modest set of changes against the current networking stack to
> enable basic user namespace support. Allowing the code to compile with
> user namespaces enabled and removing the assumption that there is only
> the initial user namespace.
>
> Work to relax the privilege checks in the networking stack from
> "capable(CAP_NET_ADMIN)" or "capable(CAP_NET_RAW)" to
> "ns_capable(net->user_ns, CAP_NET_ADMIN)" or
> "ns_capable(net->user_ns, CAP_NET_RAW)" allowing root in a user
> namespace to control a network namespace will come later.
>
> David there are just enough interdependencies between the user namespace
> bits that I intend to merge them all through my user namespace tree.
> After the review is complete I will add these patches to my for-next
> branch of my user-namespace.git tree where I do not intend to rebase.
> If it make sense to pull these into net-next to avoid or reduce
> conflicts that should not be a problem.
Looks fine to me, you can add:
Acked-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
to all of this stuff. Let me know when something is stable in your
tree, and I can therefore pull from it into net-next.
^ permalink raw reply
* Re: [PATCH 01/16] hashtable: introduce a small and naive hashtable
From: Sasha Levin @ 2012-08-15 0:24 UTC (permalink / raw)
To: NeilBrown
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, rostedt-nx8X9YLhiw1AfugRpC6u6w,
lw-BthXqXjhjHXQFUHtdCDX3A,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ejt-H+wXaHxf7aLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, tj-DgEjT+Ai2ygdnm+yROfE0A,
teigland-H+wXaHxf7aLQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20120815092523.00a909ef-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
On 08/15/2012 01:25 AM, NeilBrown wrote:
> On Tue, 14 Aug 2012 18:24:35 +0200 Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> wrote:
>
>
>> +static inline void hash_init_size(struct hlist_head *hashtable, int bits)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < HASH_SIZE(bits); i++)
>> + INIT_HLIST_HEAD(hashtable + i);
>> +}
>
> This seems like an inefficient way to do "memset(hashtable, 0, ...);".
> And in many cases it isn't needed as the hash table is static and initialised
> to zero.
> I note that in the SUNRPC/cache patch you call hash_init(), but in the lockd
> patch you don't. You don't actually need to in either case.
Agreed that the code will run just fine if we wouldn't use hash_init().
> I realise that any optimisation here is for code that is only executed once
> per boot, so no big deal, and even the presence of extra code making the
> kernel bigger is unlikely to be an issue. But I'd at least like to see
> consistency: Either use hash_init everywhere, even when not needed, or only
> use it where absolutely needed which might be no-where because static tables
> are already initialised, and dynamic tables can use GFP_ZERO.
This is a consistency problem. I didn't want to add a module_init() to modules that didn't have it just to get hash_init() in there.
I'll get it fixed.
> And if you keep hash_init_size I would rather see a memset(0)....
My concern with using a memset(0) is that I'm going to break layering.
The hashtable uses hlist. hlist provides us with an entire family of init functions which I'm supposed to use to initialize hlist heads.
So while a memset(0) will work perfectly here, I consider that cheating - it results in an uglier code that assumes to know about hlist internals, and will probably break as soon as someone tries to do something to hlist.
I can think of several alternatives here, and all of them involve changes to hlist instead of the hashtable:
- Remove INIT_HLIST_HEAD()/HLIST_HEAD()/HLIST_HEAD_INIT() and introduce a CLEAR_HLIST instead, documenting that it's enough to memset(0) the hlist to initialize it properly.
- Add a block initializer INIT_HLIST_HEADS() or something similar that would initialize an array of heads.
^ permalink raw reply
* Re: [PATCH 01/16] hashtable: introduce a small and naive hashtable
From: Tejun Heo @ 2012-08-15 0:28 UTC (permalink / raw)
To: Sasha Levin
Cc: NeilBrown, torvalds, akpm, linux-kernel, linux-mm, paul.gortmaker,
davem, rostedt, mingo, ebiederm, aarcange, ericvh, netdev, josh,
eric.dumazet, mathieu.desnoyers, axboe, agk, dm-devel, ccaulfie,
teigland, Trond.Myklebust, bfields, fweisbec, jesse,
venkat.x.venkatsubra, ejt, snitzer, edumazet, linux-nfs, dev,
rds-devel, lw
In-Reply-To: <502AEC51.2010305@gmail.com>
Hello,
(Sasha, would it be possible to change your MUA so that it breaks long
lines. It's pretty difficult to reply to.)
On Wed, Aug 15, 2012 at 02:24:49AM +0200, Sasha Levin wrote:
> The hashtable uses hlist. hlist provides us with an entire family of
> init functions which I'm supposed to use to initialize hlist heads.
>
> So while a memset(0) will work perfectly here, I consider that
> cheating - it results in an uglier code that assumes to know about
> hlist internals, and will probably break as soon as someone tries to
> do something to hlist.
I think we should stick with INIT_HLIST_HEAD(). It's not a hot path
and we might add, say, debug fields or initialization magics added
later. If this really matters, the right thing to do would be adding
something like INIT_HLIST_HEAD_ARRAY().
Thanks.
--
tejun
--
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
* Re: [PATCH 02/16] user_ns: use new hashtable implementation
From: Sasha Levin @ 2012-08-15 0:47 UTC (permalink / raw)
To: Eric W. Biederman
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, rostedt-nx8X9YLhiw1AfugRpC6u6w,
lw-BthXqXjhjHXQFUHtdCDX3A,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ejt-H+wXaHxf7aLQT0dZR+AlfA,
tj-DgEjT+Ai2ygdnm+yROfE0A, teigland-H+wXaHxf7aLQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <87txw5hw0s.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
On 08/15/2012 01:52 AM, Eric W. Biederman wrote:
> Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> Switch user_ns to use the new hashtable implementation. This reduces the amount of
>> generic unrelated code in user_ns.
>
> Two concerns here.
> 1) When adding a new entry you recompute the hash where previously that
> was not done. I believe that will slow down adding of new entries.
I figured that the price for the extra hashing isn't significant since hash_32
is just a multiplication and a shift.
I'll modify the code to calculate the key just once.
> 2) Using hash_32 for uids is an interesting choice. hash_32 discards
> the low bits. Last I checked for uids the low bits were the bits
> that were most likely to be different and had the most entropy.
>
> I'm not certain how multiplying by the GOLDEN_RATION_PRIME_32 will
> affect things but I would be surprised if it shifted all of the
> randomness from the low bits to the high bits.
"Is hash_* good enough for our purpose?" - I was actually surprised that no one
raised that question during the RFC and assumed it was because everybody agreed
that it's indeed good enough.
I can offer the following: I'll write a small module that will hash 1...10000
into a hashtable which uses 7 bits (just like user_ns) and post the distribution
we'll get.
If the results of the above will be satisfactory we can avoid the discussion
about which hash function we should really be using. If not, I guess now is a
good time for that :)
^ permalink raw reply
* Re: [REVIEW][PATCH 0/21] User namespace changes to the networking stack.
From: Eric W. Biederman @ 2012-08-15 0:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev, containers, serge
In-Reply-To: <20120814.171203.1784557890475348401.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: ebiederm@xmission.com (Eric W. Biederman)
> Date: Mon, 13 Aug 2012 13:07:10 -0700
>
>>
>> This is a modest set of changes against the current networking stack to
>> enable basic user namespace support. Allowing the code to compile with
>> user namespaces enabled and removing the assumption that there is only
>> the initial user namespace.
>>
>> Work to relax the privilege checks in the networking stack from
>> "capable(CAP_NET_ADMIN)" or "capable(CAP_NET_RAW)" to
>> "ns_capable(net->user_ns, CAP_NET_ADMIN)" or
>> "ns_capable(net->user_ns, CAP_NET_RAW)" allowing root in a user
>> namespace to control a network namespace will come later.
>>
>> David there are just enough interdependencies between the user namespace
>> bits that I intend to merge them all through my user namespace tree.
>> After the review is complete I will add these patches to my for-next
>> branch of my user-namespace.git tree where I do not intend to rebase.
>> If it make sense to pull these into net-next to avoid or reduce
>> conflicts that should not be a problem.
>
> Looks fine to me, you can add:
>
> Acked-by: David S. Miller <davem@davemloft.net>
>
> to all of this stuff. Let me know when something is stable in your
> tree, and I can therefore pull from it into net-next.
Will do. It doesn't look like anyone has any problems with this stuff,
so that should be shortly.
Eric
^ permalink raw reply
* Re: [PATCH 02/16] user_ns: use new hashtable implementation
From: Eric W. Biederman @ 2012-08-15 1:08 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
tj-DgEjT+Ai2ygdnm+yROfE0A, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, rostedt-nx8X9YLhiw1AfugRpC6u6w,
mingo-X9Un+BFzKDI, aarcange-H+wXaHxf7aLQT0dZR+AlfA,
ericvh-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
josh-iaAMLnmF4UmaiuxdJuQwMA, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, agk-H+wXaHxf7aLQT0dZR+AlfA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, teigland-H+wXaHxf7aLQT0dZR+AlfA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw, fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
jesse-l0M0P4e3n4LQT0dZR+AlfA,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ejt-H+wXaHxf7aLQT0dZR+AlfA, snitzer-H+wXaHxf7aLQT0dZR+AlfA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
lw-BthXqXjhjHXQFUHtdCDX3A
In-Reply-To: <502AF184.4010907-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On 08/15/2012 01:52 AM, Eric W. Biederman wrote:
>> Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>
>>> Switch user_ns to use the new hashtable implementation. This reduces the amount of
>>> generic unrelated code in user_ns.
>>
>> Two concerns here.
>> 1) When adding a new entry you recompute the hash where previously that
>> was not done. I believe that will slow down adding of new entries.
>
> I figured that the price for the extra hashing isn't significant since hash_32
> is just a multiplication and a shift.
>
> I'll modify the code to calculate the key just once.
Honestly I don't know either way, but it seemed a shame to give up a
common and trivial optimization.
>> 2) Using hash_32 for uids is an interesting choice. hash_32 discards
>> the low bits. Last I checked for uids the low bits were the bits
>> that were most likely to be different and had the most entropy.
>>
>> I'm not certain how multiplying by the GOLDEN_RATION_PRIME_32 will
>> affect things but I would be surprised if it shifted all of the
>> randomness from the low bits to the high bits.
>
> "Is hash_* good enough for our purpose?" - I was actually surprised that no one
> raised that question during the RFC and assumed it was because everybody agreed
> that it's indeed good enough.
>
> I can offer the following: I'll write a small module that will hash 1...10000
> into a hashtable which uses 7 bits (just like user_ns) and post the distribution
> we'll get.
That won't hurt. I think 1-100 then 1000-1100 may actually be more
representative. Not that I would mind seeing the larger range.
Especially since I am in the process of encouraging the use of more
uids.
> If the results of the above will be satisfactory we can avoid the discussion
> about which hash function we should really be using. If not, I guess now is a
> good time for that :)
Yes. A small emperical test sounds good.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC net-next 3/4] gianfar: Separate out the Rx and Tx coalescing functions
From: Paul Gortmaker @ 2012-08-15 1:29 UTC (permalink / raw)
To: Claudiu Manoil; +Cc: netdev, David S. Miller
In-Reply-To: <1344428810-29923-4-git-send-email-claudiu.manoil@freescale.com>
[[RFC net-next 3/4] gianfar: Separate out the Rx and Tx coalescing functions] On 08/08/2012 (Wed 15:26) Claudiu Manoil wrote:
> Split the coalescing programming support by Rx and Tx h/w queues, in order to
> introduce a separate NAPI for the Tx confirmation path (next patch). This way,
> the Rx processing path will handle the coalescing settings for the Rx queues
> only, resp. the Tx confirmation processing path will handle the Tx queues.
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
> ---
> drivers/net/ethernet/freescale/gianfar.c | 36 +++++++++++++++++++++++------
> 1 files changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
> index ddd350a..919acb3 100644
> --- a/drivers/net/ethernet/freescale/gianfar.c
> +++ b/drivers/net/ethernet/freescale/gianfar.c
> @@ -1794,8 +1794,8 @@ void gfar_start(struct net_device *dev)
> dev->trans_start = jiffies; /* prevent tx timeout */
> }
>
> -void gfar_configure_coalescing(struct gfar_private *priv,
> - unsigned long tx_mask, unsigned long rx_mask)
> +static inline void gfar_configure_tx_coalescing(struct gfar_private *priv,
> + unsigned long mask)
Hi Claudiu,
I had it in mind to mention this earlier, but forgot. Align line two
(and three, and four...) of args with the 1st arg in line one, and
you'll save yourself needing a resend for basic formatting issues.
In other words, you need:
void foo(int some_really_long_line, struct blah *more_long_line,
int b, ... )
i.e. allowing for mail mangling, make sure you have the the two int
directly over each other, in the example above.
Thanks,
Paul.
--
> {
> struct gfar __iomem *regs = priv->gfargrp[0].regs;
> u32 __iomem *baddr;
> @@ -1803,14 +1803,31 @@ void gfar_configure_coalescing(struct gfar_private *priv,
> if (priv->mode == MQ_MG_MODE) {
> int i;
> baddr = ®s->txic0;
> - for_each_set_bit(i, &tx_mask, priv->num_tx_queues) {
> + for_each_set_bit(i, &mask, priv->num_tx_queues) {
> gfar_write(baddr + i, 0);
> if (likely(priv->tx_queue[i]->txcoalescing))
> gfar_write(baddr + i, priv->tx_queue[i]->txic);
> }
> + } else {
> + /* Backward compatible case ---- even if we enable
> + * multiple queues, there's only single reg to program
> + */
> + gfar_write(®s->txic, 0);
> + if (likely(priv->tx_queue[0]->txcoalescing))
> + gfar_write(®s->txic, priv->tx_queue[0]->txic);
> + }
> +}
> +
> +static inline void gfar_configure_rx_coalescing(struct gfar_private *priv,
> + unsigned long mask)
> +{
> + struct gfar __iomem *regs = priv->gfargrp[0].regs;
> + u32 __iomem *baddr;
>
> + if (priv->mode == MQ_MG_MODE) {
> + int i;
> baddr = ®s->rxic0;
> - for_each_set_bit(i, &rx_mask, priv->num_rx_queues) {
> + for_each_set_bit(i, &mask, priv->num_rx_queues) {
> gfar_write(baddr + i, 0);
> if (likely(priv->rx_queue[i]->rxcoalescing))
> gfar_write(baddr + i, priv->rx_queue[i]->rxic);
> @@ -1819,16 +1836,19 @@ void gfar_configure_coalescing(struct gfar_private *priv,
> /* Backward compatible case ---- even if we enable
> * multiple queues, there's only single reg to program
> */
> - gfar_write(®s->txic, 0);
> - if (likely(priv->tx_queue[0]->txcoalescing))
> - gfar_write(®s->txic, priv->tx_queue[0]->txic);
> -
> gfar_write(®s->rxic, 0);
> if (likely(priv->rx_queue[0]->rxcoalescing))
> gfar_write(®s->rxic, priv->rx_queue[0]->rxic);
> }
> }
>
> +void gfar_configure_coalescing(struct gfar_private *priv,
> + unsigned long tx_mask, unsigned long rx_mask)
> +{
> + gfar_configure_tx_coalescing(priv, tx_mask);
> + gfar_configure_rx_coalescing(priv, rx_mask);
> +}
> +
> static int register_grp_irqs(struct gfar_priv_grp *grp)
> {
> struct gfar_private *priv = grp->priv;
> --
> 1.6.6
>
>
^ permalink raw reply
* Re: [PATCH 02/16] user_ns: use new hashtable implementation
From: Sasha Levin @ 2012-08-15 1:35 UTC (permalink / raw)
To: Eric W. Biederman
Cc: torvalds, tj, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, aarcange, ericvh, netdev, josh, eric.dumazet,
mathieu.desnoyers, axboe, agk, dm-devel, neilb, ccaulfie,
teigland, Trond.Myklebust, bfields, fweisbec, jesse,
venkat.x.venkatsubra, ejt, snitzer, edumazet, linux-nfs, dev,
rds-devel, lw
In-Reply-To: <87393phshy.fsf@xmission.com>
On 08/15/2012 03:08 AM, Eric W. Biederman wrote:
>> I can offer the following: I'll write a small module that will hash 1...10000
>> > into a hashtable which uses 7 bits (just like user_ns) and post the distribution
>> > we'll get.
> That won't hurt. I think 1-100 then 1000-1100 may actually be more
> representative. Not that I would mind seeing the larger range.
> Especially since I am in the process of encouraging the use of more
> uids.
>
Alrighty, the results are in (numbers are objects in bucket):
For the 0...10000 range:
Average: 78.125
Std dev: 1.4197704151
Min: 75
Max: 80
For the 1...100 range:
Average: 0.78125
Std dev: 0.5164613088
Min: 0
Max: 2
For the 1000...1100 range:
Average: 0.7890625
Std dev: 0.4964812206
Min: 0
Max: 2
Looks like hash_32 is pretty good with small numbers.
--
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
* [PATCH v2] XFRM: remove redundant parameter "int dir" in struct xfrm_mgr.acquire
From: Fan Du @ 2012-08-15 2:13 UTC (permalink / raw)
To: davem; +Cc: netdev
Sematically speaking, xfrm_mgr.acquire is called when kernel intends to ask
user space IKE daemon to negotiate SAs with peers. IOW the direction will
*always* be XFRM_POLICY_OUT, so remove int dir for clarity.
Signed-off-by: Fan Du <fan.du@windriver.com>
---
Changelog for V2:
- Remove "int dir" in build_acquire parameter suggested by Steffen Klassert.
include/net/xfrm.h | 2 +-
net/key/af_key.c | 4 ++--
net/xfrm/xfrm_state.c | 2 +-
net/xfrm/xfrm_user.c | 9 ++++-----
4 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 62b619e..5e1662d 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -571,7 +571,7 @@ struct xfrm_mgr {
struct list_head list;
char *id;
int (*notify)(struct xfrm_state *x, const struct km_event *c);
- int (*acquire)(struct xfrm_state *x, struct xfrm_tmpl *, struct xfrm_policy *xp, int dir);
+ int (*acquire)(struct xfrm_state *x, struct xfrm_tmpl *, struct xfrm_policy *xp);
struct xfrm_policy *(*compile_policy)(struct sock *sk, int opt, u8 *data, int len, int *dir);
int (*new_mapping)(struct xfrm_state *x, xfrm_address_t *ipaddr, __be16 sport);
int (*notify_policy)(struct xfrm_policy *x, int dir, const struct km_event *c);
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 34e4185..ec7d161 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -3024,7 +3024,7 @@ static u32 get_acqseq(void)
return res;
}
-static int pfkey_send_acquire(struct xfrm_state *x, struct xfrm_tmpl *t, struct xfrm_policy *xp, int dir)
+static int pfkey_send_acquire(struct xfrm_state *x, struct xfrm_tmpl *t, struct xfrm_policy *xp)
{
struct sk_buff *skb;
struct sadb_msg *hdr;
@@ -3105,7 +3105,7 @@ static int pfkey_send_acquire(struct xfrm_state *x, struct xfrm_tmpl *t, struct
pol->sadb_x_policy_len = sizeof(struct sadb_x_policy)/sizeof(uint64_t);
pol->sadb_x_policy_exttype = SADB_X_EXT_POLICY;
pol->sadb_x_policy_type = IPSEC_POLICY_IPSEC;
- pol->sadb_x_policy_dir = dir+1;
+ pol->sadb_x_policy_dir = XFRM_POLICY_OUT + 1;
pol->sadb_x_policy_id = xp->index;
/* Set sadb_comb's. */
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 87cd0e4..7856c33 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1700,7 +1700,7 @@ int km_query(struct xfrm_state *x, struct xfrm_tmpl *t, struct xfrm_policy *pol)
read_lock(&xfrm_km_lock);
list_for_each_entry(km, &xfrm_km_list, list) {
- acqret = km->acquire(x, t, pol, XFRM_POLICY_OUT);
+ acqret = km->acquire(x, t, pol);
if (!acqret)
err = acqret;
}
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index e75d8e4..ab58034 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -2567,8 +2567,7 @@ static inline size_t xfrm_acquire_msgsize(struct xfrm_state *x,
}
static int build_acquire(struct sk_buff *skb, struct xfrm_state *x,
- struct xfrm_tmpl *xt, struct xfrm_policy *xp,
- int dir)
+ struct xfrm_tmpl *xt, struct xfrm_policy *xp)
{
__u32 seq = xfrm_get_acqseq();
struct xfrm_user_acquire *ua;
@@ -2583,7 +2582,7 @@ static int build_acquire(struct sk_buff *skb, struct xfrm_state *x,
memcpy(&ua->id, &x->id, sizeof(ua->id));
memcpy(&ua->saddr, &x->props.saddr, sizeof(ua->saddr));
memcpy(&ua->sel, &x->sel, sizeof(ua->sel));
- copy_to_user_policy(xp, &ua->policy, dir);
+ copy_to_user_policy(xp, &ua->policy, XFRM_POLICY_OUT);
ua->aalgos = xt->aalgos;
ua->ealgos = xt->ealgos;
ua->calgos = xt->calgos;
@@ -2605,7 +2604,7 @@ static int build_acquire(struct sk_buff *skb, struct xfrm_state *x,
}
static int xfrm_send_acquire(struct xfrm_state *x, struct xfrm_tmpl *xt,
- struct xfrm_policy *xp, int dir)
+ struct xfrm_policy *xp)
{
struct net *net = xs_net(x);
struct sk_buff *skb;
@@ -2614,7 +2613,7 @@ static int xfrm_send_acquire(struct xfrm_state *x, struct xfrm_tmpl *xt,
if (skb == NULL)
return -ENOMEM;
- if (build_acquire(skb, x, xt, xp, dir) < 0)
+ if (build_acquire(skb, x, xt, xp) < 0)
BUG();
return nlmsg_multicast(net->xfrm.nlsk, skb, 0, XFRMNLGRP_ACQUIRE, GFP_ATOMIC);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net] ipv6: addrconf: Avoid calling netdevice notifiers with RCU read-side lock
From: Cong Wang @ 2012-08-15 3:10 UTC (permalink / raw)
To: Ben Hutchings
Cc: David Miller, netdev, John Fastabend, Greg Rose, Thomas Graf,
Eric Dumazet
In-Reply-To: <1344970491.2690.8.camel@bwh-desktop.uk.solarflarecom.com>
On Tue, 2012-08-14 at 19:54 +0100, Ben Hutchings wrote:
> Cong Wang reports that lockdep detected suspicious RCU usage while
> enabling IPV6 forwarding:
>
> [ 1123.310275] ===============================
> [ 1123.442202] [ INFO: suspicious RCU usage. ]
> [ 1123.558207] 3.6.0-rc1+ #109 Not tainted
> [ 1123.665204] -------------------------------
> [ 1123.768254] include/linux/rcupdate.h:430 Illegal context switch in RCU read-side critical section!
> [ 1123.992320]
> [ 1123.992320] other info that might help us debug this:
> [ 1123.992320]
> [ 1124.307382]
> [ 1124.307382] rcu_scheduler_active = 1, debug_locks = 0
> [ 1124.522220] 2 locks held by sysctl/5710:
> [ 1124.648364] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff81768498>] rtnl_trylock+0x15/0x17
> [ 1124.882211] #1: (rcu_read_lock){.+.+.+}, at: [<ffffffff81871df8>] rcu_lock_acquire+0x0/0x29
> [ 1125.085209]
> [ 1125.085209] stack backtrace:
> [ 1125.332213] Pid: 5710, comm: sysctl Not tainted 3.6.0-rc1+ #109
> [ 1125.441291] Call Trace:
> [ 1125.545281] [<ffffffff8109d915>] lockdep_rcu_suspicious+0x109/0x112
> [ 1125.667212] [<ffffffff8107c240>] rcu_preempt_sleep_check+0x45/0x47
> [ 1125.781838] [<ffffffff8107c260>] __might_sleep+0x1e/0x19b
> [...]
> [ 1127.445223] [<ffffffff81757ac5>] call_netdevice_notifiers+0x4a/0x4f
> [...]
> [ 1127.772188] [<ffffffff8175e125>] dev_disable_lro+0x32/0x6b
> [ 1127.885174] [<ffffffff81872d26>] dev_forward_change+0x30/0xcb
> [ 1128.013214] [<ffffffff818738c4>] addrconf_forward_change+0x85/0xc5
> [...]
>
> addrconf_forward_change() uses RCU iteration over the netdev list,
> which is unnecessary since it already holds the RTNL lock. We also
> cannot reasonably require netdevice notifier functions not to sleep.
>
> Reported-by: Cong Wang <amwang@redhat.com>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Thanks for your patch, Ben!
^ permalink raw reply
* Re: [PATCH 02/16] user_ns: use new hashtable implementation
From: Eric W. Biederman @ 2012-08-15 3:13 UTC (permalink / raw)
To: Sasha Levin
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, rostedt-nx8X9YLhiw1AfugRpC6u6w,
lw-BthXqXjhjHXQFUHtdCDX3A,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ejt-H+wXaHxf7aLQT0dZR+AlfA,
tj-DgEjT+Ai2ygdnm+yROfE0A, teigland-H+wXaHxf7aLQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <502AFCD5.6070104-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On 08/15/2012 03:08 AM, Eric W. Biederman wrote:
>>> I can offer the following: I'll write a small module that will hash 1...10000
>>> > into a hashtable which uses 7 bits (just like user_ns) and post the distribution
>>> > we'll get.
>> That won't hurt. I think 1-100 then 1000-1100 may actually be more
>> representative. Not that I would mind seeing the larger range.
>> Especially since I am in the process of encouraging the use of more
>> uids.
>>
>
> Alrighty, the results are in (numbers are objects in bucket):
>
> For the 0...10000 range:
>
> Average: 78.125
> Std dev: 1.4197704151
> Min: 75
> Max: 80
>
>
> For the 1...100 range:
>
> Average: 0.78125
> Std dev: 0.5164613088
> Min: 0
> Max: 2
>
>
> For the 1000...1100 range:
>
> Average: 0.7890625
> Std dev: 0.4964812206
> Min: 0
> Max: 2
>
>
> Looks like hash_32 is pretty good with small numbers.
Yes hash_32 seems reasonable for the uid hash. With those long hash
chains I wouldn't like to be on a machine with 10,000 processes with
each with a different uid, and a processes calling setuid in the fast
path.
The uid hash that we are playing with is one that I sort of wish that
the hash table could grow in size, so that we could scale up better.
Aw well. Most of the time we only have a very small number of uids
in play, so it doesn't matter at this point.
Eric
^ permalink raw reply
* Re: [PATCH net-next 0/7] sctp: network namespace support Part 2: per net tunables
From: Vlad Yasevich @ 2012-08-15 3:16 UTC (permalink / raw)
To: David Miller
Cc: ebiederm, linux-sctp, netdev, linux-kernel, jan.ariyasu,
jan.ariyasu, nhorman, tgraf, xi.wang
In-Reply-To: <20120814.141415.556937052577510995.davem@davemloft.net>
On 08/14/2012 05:14 PM, David Miller wrote:
>
> Come on Vlad, please review this stuff some time this century. If you
> want inclusion to be dependent upon your review, then the onus is on
> you to review it in a timely manner. And you are not doing so here.
>
> I'm not letting Eric's patches rot in patchwork for more than a week,
> this is completely unacceptable.
>
I swear I sent an ACK 2 days ago, but I now see it sitting in my draft
folder. My bad. I'll go now and dust off the ACK...
-vlad
^ permalink raw reply
* Re: [PATCH net-next 1/9] sctp: Make the port hash table use struct net in it's key.
From: Vlad Yasevich @ 2012-08-15 3:18 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, linux-sctp, netdev, linux-kernel, Jan Ariyasu,
Jan Ariyasu, Neil Horman, Thomas Graf, Xi Wang
In-Reply-To: <87txwfq2z9.fsf_-_@xmission.com>
On 08/06/2012 02:39 PM, Eric W. Biederman wrote:
>
> - Add struct net into the port hash table hash calculation
> - Add struct net inot the struct sctp_bind_bucket so there
> is a memory of which network namespace a port is allocated in.
> No need for a ref count because sctp_bind_bucket only exists
> when there are sockets in the hash table and sockets can not
> change their network namspace, and sockets already ref count
> their network namespace.
> - Add struct net into the key comparison when we are testing
> to see if we have found the port hash table entry we are
> looking for.
>
> With these changes lookups in the port hash table becomes
> safe to use in multiple network namespaces.
>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
> ---
> include/net/sctp/sctp.h | 4 ++--
> include/net/sctp/structs.h | 1 +
> net/sctp/socket.c | 22 +++++++++++++---------
> 3 files changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> index ff49964..7c05040 100644
> --- a/include/net/sctp/sctp.h
> +++ b/include/net/sctp/sctp.h
> @@ -632,9 +632,9 @@ static inline int sctp_sanity_check(void)
>
> /* Warning: The following hash functions assume a power of two 'size'. */
> /* This is the hash function for the SCTP port hash table. */
> -static inline int sctp_phashfn(__u16 lport)
> +static inline int sctp_phashfn(struct net *net, __u16 lport)
> {
> - return lport & (sctp_port_hashsize - 1);
> + return (net_hash_mix(net) + lport) & (sctp_port_hashsize - 1);
> }
>
> /* This is the hash function for the endpoint hash table. */
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index fc5e600..c089bb1 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -102,6 +102,7 @@ struct sctp_bind_bucket {
> unsigned short fastreuse;
> struct hlist_node node;
> struct hlist_head owner;
> + struct net *net;
> };
>
> struct sctp_bind_hashbucket {
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 5e25981..4316b0f 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -5769,7 +5769,7 @@ static void sctp_unhash(struct sock *sk)
> * a fastreuse flag (FIXME: NPI ipg).
> */
> static struct sctp_bind_bucket *sctp_bucket_create(
> - struct sctp_bind_hashbucket *head, unsigned short snum);
> + struct sctp_bind_hashbucket *head, struct net *, unsigned short snum);
>
> static long sctp_get_port_local(struct sock *sk, union sctp_addr *addr)
> {
> @@ -5799,11 +5799,12 @@ static long sctp_get_port_local(struct sock *sk, union sctp_addr *addr)
> rover = low;
> if (inet_is_reserved_local_port(rover))
> continue;
> - index = sctp_phashfn(rover);
> + index = sctp_phashfn(sock_net(sk), rover);
> head = &sctp_port_hashtable[index];
> sctp_spin_lock(&head->lock);
> sctp_for_each_hentry(pp, node, &head->chain)
> - if (pp->port == rover)
> + if ((pp->port == rover) &&
> + net_eq(sock_net(sk), pp->net))
> goto next;
> break;
> next:
> @@ -5827,10 +5828,10 @@ static long sctp_get_port_local(struct sock *sk, union sctp_addr *addr)
> * to the port number (snum) - we detect that with the
> * port iterator, pp being NULL.
> */
> - head = &sctp_port_hashtable[sctp_phashfn(snum)];
> + head = &sctp_port_hashtable[sctp_phashfn(sock_net(sk), snum)];
> sctp_spin_lock(&head->lock);
> sctp_for_each_hentry(pp, node, &head->chain) {
> - if (pp->port == snum)
> + if ((pp->port == snum) && net_eq(pp->net, sock_net(sk)))
> goto pp_found;
> }
> }
> @@ -5881,7 +5882,7 @@ pp_found:
> pp_not_found:
> /* If there was a hash table miss, create a new port. */
> ret = 1;
> - if (!pp && !(pp = sctp_bucket_create(head, snum)))
> + if (!pp && !(pp = sctp_bucket_create(head, sock_net(sk), snum)))
> goto fail_unlock;
>
> /* In either case (hit or miss), make sure fastreuse is 1 only
> @@ -6113,7 +6114,7 @@ unsigned int sctp_poll(struct file *file, struct socket *sock, poll_table *wait)
> ********************************************************************/
>
> static struct sctp_bind_bucket *sctp_bucket_create(
> - struct sctp_bind_hashbucket *head, unsigned short snum)
> + struct sctp_bind_hashbucket *head, struct net *net, unsigned short snum)
> {
> struct sctp_bind_bucket *pp;
>
> @@ -6123,6 +6124,7 @@ static struct sctp_bind_bucket *sctp_bucket_create(
> pp->port = snum;
> pp->fastreuse = 0;
> INIT_HLIST_HEAD(&pp->owner);
> + pp->net = net;
> hlist_add_head(&pp->node, &head->chain);
> }
> return pp;
> @@ -6142,7 +6144,8 @@ static void sctp_bucket_destroy(struct sctp_bind_bucket *pp)
> static inline void __sctp_put_port(struct sock *sk)
> {
> struct sctp_bind_hashbucket *head =
> - &sctp_port_hashtable[sctp_phashfn(inet_sk(sk)->inet_num)];
> + &sctp_port_hashtable[sctp_phashfn(sock_net(sk),
> + inet_sk(sk)->inet_num)];
> struct sctp_bind_bucket *pp;
>
> sctp_spin_lock(&head->lock);
> @@ -6809,7 +6812,8 @@ static void sctp_sock_migrate(struct sock *oldsk, struct sock *newsk,
> newsp->hmac = NULL;
>
> /* Hook this new socket in to the bind_hash list. */
> - head = &sctp_port_hashtable[sctp_phashfn(inet_sk(oldsk)->inet_num)];
> + head = &sctp_port_hashtable[sctp_phashfn(sock_net(oldsk),
> + inet_sk(oldsk)->inet_num)];
> sctp_local_bh_disable();
> sctp_spin_lock(&head->lock);
> pp = sctp_sk(oldsk)->bind_hash;
>
^ permalink raw reply
* Re: [PATCH net-next 2/9] sctp: Make the endpoint hashtable handle multiple network namespaces
From: Vlad Yasevich @ 2012-08-15 3:18 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, linux-sctp, netdev, linux-kernel, Jan Ariyasu,
Jan Ariyasu, Neil Horman, Thomas Graf, Xi Wang
In-Reply-To: <87obmnq2y2.fsf_-_@xmission.com>
On 08/06/2012 02:40 PM, Eric W. Biederman wrote:
>
> - Use struct net in the hash calculation
> - Use sock_net(endpoint.base.sk) in the endpoint lookups.
> - On receive calculate the network namespace from skb->dev.
>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
> ---
> include/net/sctp/sctp.h | 4 ++--
> include/net/sctp/structs.h | 2 +-
> net/sctp/endpointola.c | 4 +++-
> net/sctp/input.c | 19 ++++++++++++-------
> 4 files changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> index 7c05040..87b119f 100644
> --- a/include/net/sctp/sctp.h
> +++ b/include/net/sctp/sctp.h
> @@ -638,9 +638,9 @@ static inline int sctp_phashfn(struct net *net, __u16 lport)
> }
>
> /* This is the hash function for the endpoint hash table. */
> -static inline int sctp_ep_hashfn(__u16 lport)
> +static inline int sctp_ep_hashfn(struct net *net, __u16 lport)
> {
> - return lport & (sctp_ep_hashsize - 1);
> + return (net_hash_mix(net) + lport) & (sctp_ep_hashsize - 1);
> }
>
> /* This is the hash function for the association hash table. */
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index c089bb1..9f9de55 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -1426,7 +1426,7 @@ struct sctp_association *sctp_endpoint_lookup_assoc(
> int sctp_endpoint_is_peeled_off(struct sctp_endpoint *,
> const union sctp_addr *);
> struct sctp_endpoint *sctp_endpoint_is_match(struct sctp_endpoint *,
> - const union sctp_addr *);
> + struct net *, const union sctp_addr *);
> int sctp_has_association(const union sctp_addr *laddr,
> const union sctp_addr *paddr);
>
> diff --git a/net/sctp/endpointola.c b/net/sctp/endpointola.c
> index 68a385d..50c87b4 100644
> --- a/net/sctp/endpointola.c
> +++ b/net/sctp/endpointola.c
> @@ -302,11 +302,13 @@ void sctp_endpoint_put(struct sctp_endpoint *ep)
>
> /* Is this the endpoint we are looking for? */
> struct sctp_endpoint *sctp_endpoint_is_match(struct sctp_endpoint *ep,
> + struct net *net,
> const union sctp_addr *laddr)
> {
> struct sctp_endpoint *retval = NULL;
>
> - if (htons(ep->base.bind_addr.port) == laddr->v4.sin_port) {
> + if ((htons(ep->base.bind_addr.port) == laddr->v4.sin_port) &&
> + net_eq(sock_net(ep->base.sk), net)) {
> if (sctp_bind_addr_match(&ep->base.bind_addr, laddr,
> sctp_sk(ep->base.sk)))
> retval = ep;
> diff --git a/net/sctp/input.c b/net/sctp/input.c
> index e64d521..c0ca893 100644
> --- a/net/sctp/input.c
> +++ b/net/sctp/input.c
> @@ -70,7 +70,8 @@ static struct sctp_association *__sctp_rcv_lookup(struct sk_buff *skb,
> const union sctp_addr *laddr,
> const union sctp_addr *paddr,
> struct sctp_transport **transportp);
> -static struct sctp_endpoint *__sctp_rcv_lookup_endpoint(const union sctp_addr *laddr);
> +static struct sctp_endpoint *__sctp_rcv_lookup_endpoint(struct net *net,
> + const union sctp_addr *laddr);
> static struct sctp_association *__sctp_lookup_association(
> const union sctp_addr *local,
> const union sctp_addr *peer,
> @@ -129,6 +130,7 @@ int sctp_rcv(struct sk_buff *skb)
> union sctp_addr dest;
> int family;
> struct sctp_af *af;
> + struct net *net = dev_net(skb->dev);
>
> if (skb->pkt_type!=PACKET_HOST)
> goto discard_it;
> @@ -181,7 +183,7 @@ int sctp_rcv(struct sk_buff *skb)
> asoc = __sctp_rcv_lookup(skb, &src, &dest, &transport);
>
> if (!asoc)
> - ep = __sctp_rcv_lookup_endpoint(&dest);
> + ep = __sctp_rcv_lookup_endpoint(net, &dest);
>
> /* Retrieve the common input handling substructure. */
> rcvr = asoc ? &asoc->base : &ep->base;
> @@ -723,12 +725,13 @@ discard:
> /* Insert endpoint into the hash table. */
> static void __sctp_hash_endpoint(struct sctp_endpoint *ep)
> {
> + struct net *net = sock_net(ep->base.sk);
> struct sctp_ep_common *epb;
> struct sctp_hashbucket *head;
>
> epb = &ep->base;
>
> - epb->hashent = sctp_ep_hashfn(epb->bind_addr.port);
> + epb->hashent = sctp_ep_hashfn(net, epb->bind_addr.port);
> head = &sctp_ep_hashtable[epb->hashent];
>
> sctp_write_lock(&head->lock);
> @@ -747,12 +750,13 @@ void sctp_hash_endpoint(struct sctp_endpoint *ep)
> /* Remove endpoint from the hash table. */
> static void __sctp_unhash_endpoint(struct sctp_endpoint *ep)
> {
> + struct net *net = sock_net(ep->base.sk);
> struct sctp_hashbucket *head;
> struct sctp_ep_common *epb;
>
> epb = &ep->base;
>
> - epb->hashent = sctp_ep_hashfn(epb->bind_addr.port);
> + epb->hashent = sctp_ep_hashfn(net, epb->bind_addr.port);
>
> head = &sctp_ep_hashtable[epb->hashent];
>
> @@ -770,7 +774,8 @@ void sctp_unhash_endpoint(struct sctp_endpoint *ep)
> }
>
> /* Look up an endpoint. */
> -static struct sctp_endpoint *__sctp_rcv_lookup_endpoint(const union sctp_addr *laddr)
> +static struct sctp_endpoint *__sctp_rcv_lookup_endpoint(struct net *net,
> + const union sctp_addr *laddr)
> {
> struct sctp_hashbucket *head;
> struct sctp_ep_common *epb;
> @@ -778,12 +783,12 @@ static struct sctp_endpoint *__sctp_rcv_lookup_endpoint(const union sctp_addr *l
> struct hlist_node *node;
> int hash;
>
> - hash = sctp_ep_hashfn(ntohs(laddr->v4.sin_port));
> + hash = sctp_ep_hashfn(net, ntohs(laddr->v4.sin_port));
> head = &sctp_ep_hashtable[hash];
> read_lock(&head->lock);
> sctp_for_each_hentry(epb, node, &head->chain) {
> ep = sctp_ep(epb);
> - if (sctp_endpoint_is_match(ep, laddr))
> + if (sctp_endpoint_is_match(ep, net, laddr))
> goto hit;
> }
>
>
^ permalink raw reply
* Re: [PATCH net-next 3/9] sctp: Make the association hashtable handle multiple network namespaces
From: Vlad Yasevich @ 2012-08-15 3:18 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, linux-sctp, netdev, linux-kernel, Jan Ariyasu,
Jan Ariyasu, Neil Horman, Thomas Graf, Xi Wang
In-Reply-To: <87ipcvq2wm.fsf_-_@xmission.com>
On 08/06/2012 02:41 PM, Eric W. Biederman wrote:
>
> - Use struct net in the hash calculation
> - Use sock_net(association.base.sk) in the association lookups.
> - On receive calculate the network namespace from skb->dev.
> - Pass struct net from receive down to the functions that actually
> do the association lookup.
>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
> ---
> include/net/sctp/sctp.h | 6 ++--
> include/net/sctp/structs.h | 3 +-
> net/sctp/associola.c | 4 ++-
> net/sctp/endpointola.c | 6 +++-
> net/sctp/input.c | 64 +++++++++++++++++++++++++++----------------
> net/sctp/ipv6.c | 3 +-
> 6 files changed, 54 insertions(+), 32 deletions(-)
>
> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> index 87b119f..640915a 100644
> --- a/include/net/sctp/sctp.h
> +++ b/include/net/sctp/sctp.h
> @@ -156,7 +156,7 @@ void sctp_hash_established(struct sctp_association *);
> void sctp_unhash_established(struct sctp_association *);
> void sctp_hash_endpoint(struct sctp_endpoint *);
> void sctp_unhash_endpoint(struct sctp_endpoint *);
> -struct sock *sctp_err_lookup(int family, struct sk_buff *,
> +struct sock *sctp_err_lookup(struct net *net, int family, struct sk_buff *,
> struct sctphdr *, struct sctp_association **,
> struct sctp_transport **);
> void sctp_err_finish(struct sock *, struct sctp_association *);
> @@ -644,9 +644,9 @@ static inline int sctp_ep_hashfn(struct net *net, __u16 lport)
> }
>
> /* This is the hash function for the association hash table. */
> -static inline int sctp_assoc_hashfn(__u16 lport, __u16 rport)
> +static inline int sctp_assoc_hashfn(struct net *net, __u16 lport, __u16 rport)
> {
> - int h = (lport << 16) + rport;
> + int h = (lport << 16) + rport + net_hash_mix(net);
> h ^= h>>8;
> return h & (sctp_assoc_hashsize - 1);
> }
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index 9f9de55..c0563d1 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -1427,7 +1427,7 @@ int sctp_endpoint_is_peeled_off(struct sctp_endpoint *,
> const union sctp_addr *);
> struct sctp_endpoint *sctp_endpoint_is_match(struct sctp_endpoint *,
> struct net *, const union sctp_addr *);
> -int sctp_has_association(const union sctp_addr *laddr,
> +int sctp_has_association(struct net *net, const union sctp_addr *laddr,
> const union sctp_addr *paddr);
>
> int sctp_verify_init(const struct sctp_association *asoc, sctp_cid_t,
> @@ -2014,6 +2014,7 @@ void sctp_assoc_control_transport(struct sctp_association *,
> sctp_transport_cmd_t, sctp_sn_error_t);
> struct sctp_transport *sctp_assoc_lookup_tsn(struct sctp_association *, __u32);
> struct sctp_transport *sctp_assoc_is_match(struct sctp_association *,
> + struct net *,
> const union sctp_addr *,
> const union sctp_addr *);
> void sctp_assoc_migrate(struct sctp_association *, struct sock *);
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index ebaef3e..a3601f3 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -1089,13 +1089,15 @@ out:
>
> /* Is this the association we are looking for? */
> struct sctp_transport *sctp_assoc_is_match(struct sctp_association *asoc,
> + struct net *net,
> const union sctp_addr *laddr,
> const union sctp_addr *paddr)
> {
> struct sctp_transport *transport;
>
> if ((htons(asoc->base.bind_addr.port) == laddr->v4.sin_port) &&
> - (htons(asoc->peer.port) == paddr->v4.sin_port)) {
> + (htons(asoc->peer.port) == paddr->v4.sin_port) &&
> + net_eq(sock_net(asoc->base.sk), net)) {
> transport = sctp_assoc_lookup_paddr(asoc, paddr);
> if (!transport)
> goto out;
> diff --git a/net/sctp/endpointola.c b/net/sctp/endpointola.c
> index 50c87b4..6b76393 100644
> --- a/net/sctp/endpointola.c
> +++ b/net/sctp/endpointola.c
> @@ -345,7 +345,8 @@ static struct sctp_association *__sctp_endpoint_lookup_assoc(
>
> rport = ntohs(paddr->v4.sin_port);
>
> - hash = sctp_assoc_hashfn(ep->base.bind_addr.port, rport);
> + hash = sctp_assoc_hashfn(sock_net(ep->base.sk), ep->base.bind_addr.port,
> + rport);
> head = &sctp_assoc_hashtable[hash];
> read_lock(&head->lock);
> sctp_for_each_hentry(epb, node, &head->chain) {
> @@ -388,13 +389,14 @@ int sctp_endpoint_is_peeled_off(struct sctp_endpoint *ep,
> {
> struct sctp_sockaddr_entry *addr;
> struct sctp_bind_addr *bp;
> + struct net *net = sock_net(ep->base.sk);
>
> bp = &ep->base.bind_addr;
> /* This function is called with the socket lock held,
> * so the address_list can not change.
> */
> list_for_each_entry(addr, &bp->address_list, list) {
> - if (sctp_has_association(&addr->a, paddr))
> + if (sctp_has_association(net, &addr->a, paddr))
> return 1;
> }
>
> diff --git a/net/sctp/input.c b/net/sctp/input.c
> index c0ca893..a7e9a85 100644
> --- a/net/sctp/input.c
> +++ b/net/sctp/input.c
> @@ -66,13 +66,15 @@
>
> /* Forward declarations for internal helpers. */
> static int sctp_rcv_ootb(struct sk_buff *);
> -static struct sctp_association *__sctp_rcv_lookup(struct sk_buff *skb,
> +static struct sctp_association *__sctp_rcv_lookup(struct net *net,
> + struct sk_buff *skb,
> const union sctp_addr *laddr,
> const union sctp_addr *paddr,
> struct sctp_transport **transportp);
> static struct sctp_endpoint *__sctp_rcv_lookup_endpoint(struct net *net,
> const union sctp_addr *laddr);
> static struct sctp_association *__sctp_lookup_association(
> + struct net *net,
> const union sctp_addr *local,
> const union sctp_addr *peer,
> struct sctp_transport **pt);
> @@ -180,7 +182,7 @@ int sctp_rcv(struct sk_buff *skb)
> !af->addr_valid(&dest, NULL, skb))
> goto discard_it;
>
> - asoc = __sctp_rcv_lookup(skb, &src, &dest, &transport);
> + asoc = __sctp_rcv_lookup(net, skb, &src, &dest, &transport);
>
> if (!asoc)
> ep = __sctp_rcv_lookup_endpoint(net, &dest);
> @@ -476,7 +478,7 @@ void sctp_icmp_proto_unreachable(struct sock *sk,
> }
>
> /* Common lookup code for icmp/icmpv6 error handler. */
> -struct sock *sctp_err_lookup(int family, struct sk_buff *skb,
> +struct sock *sctp_err_lookup(struct net *net, int family, struct sk_buff *skb,
> struct sctphdr *sctphdr,
> struct sctp_association **app,
> struct sctp_transport **tpp)
> @@ -505,7 +507,7 @@ struct sock *sctp_err_lookup(int family, struct sk_buff *skb,
> /* Look for an association that matches the incoming ICMP error
> * packet.
> */
> - asoc = __sctp_lookup_association(&saddr, &daddr, &transport);
> + asoc = __sctp_lookup_association(net, &saddr, &daddr, &transport);
> if (!asoc)
> return NULL;
>
> @@ -588,6 +590,7 @@ void sctp_v4_err(struct sk_buff *skb, __u32 info)
> struct inet_sock *inet;
> sk_buff_data_t saveip, savesctp;
> int err;
> + struct net *net = dev_net(skb->dev);
>
> if (skb->len < ihlen + 8) {
> ICMP_INC_STATS_BH(&init_net, ICMP_MIB_INERRORS);
> @@ -599,7 +602,7 @@ void sctp_v4_err(struct sk_buff *skb, __u32 info)
> savesctp = skb->transport_header;
> skb_reset_network_header(skb);
> skb_set_transport_header(skb, ihlen);
> - sk = sctp_err_lookup(AF_INET, skb, sctp_hdr(skb), &asoc, &transport);
> + sk = sctp_err_lookup(net, AF_INET, skb, sctp_hdr(skb), &asoc, &transport);
> /* Put back, the original values. */
> skb->network_header = saveip;
> skb->transport_header = savesctp;
> @@ -803,13 +806,15 @@ hit:
> /* Insert association into the hash table. */
> static void __sctp_hash_established(struct sctp_association *asoc)
> {
> + struct net *net = sock_net(asoc->base.sk);
> struct sctp_ep_common *epb;
> struct sctp_hashbucket *head;
>
> epb = &asoc->base;
>
> /* Calculate which chain this entry will belong to. */
> - epb->hashent = sctp_assoc_hashfn(epb->bind_addr.port, asoc->peer.port);
> + epb->hashent = sctp_assoc_hashfn(net, epb->bind_addr.port,
> + asoc->peer.port);
>
> head = &sctp_assoc_hashtable[epb->hashent];
>
> @@ -832,12 +837,13 @@ void sctp_hash_established(struct sctp_association *asoc)
> /* Remove association from the hash table. */
> static void __sctp_unhash_established(struct sctp_association *asoc)
> {
> + struct net *net = sock_net(asoc->base.sk);
> struct sctp_hashbucket *head;
> struct sctp_ep_common *epb;
>
> epb = &asoc->base;
>
> - epb->hashent = sctp_assoc_hashfn(epb->bind_addr.port,
> + epb->hashent = sctp_assoc_hashfn(net, epb->bind_addr.port,
> asoc->peer.port);
>
> head = &sctp_assoc_hashtable[epb->hashent];
> @@ -860,6 +866,7 @@ void sctp_unhash_established(struct sctp_association *asoc)
>
> /* Look up an association. */
> static struct sctp_association *__sctp_lookup_association(
> + struct net *net,
> const union sctp_addr *local,
> const union sctp_addr *peer,
> struct sctp_transport **pt)
> @@ -874,12 +881,13 @@ static struct sctp_association *__sctp_lookup_association(
> /* Optimize here for direct hit, only listening connections can
> * have wildcards anyways.
> */
> - hash = sctp_assoc_hashfn(ntohs(local->v4.sin_port), ntohs(peer->v4.sin_port));
> + hash = sctp_assoc_hashfn(net, ntohs(local->v4.sin_port),
> + ntohs(peer->v4.sin_port));
> head = &sctp_assoc_hashtable[hash];
> read_lock(&head->lock);
> sctp_for_each_hentry(epb, node, &head->chain) {
> asoc = sctp_assoc(epb);
> - transport = sctp_assoc_is_match(asoc, local, peer);
> + transport = sctp_assoc_is_match(asoc, net, local, peer);
> if (transport)
> goto hit;
> }
> @@ -897,27 +905,29 @@ hit:
>
> /* Look up an association. BH-safe. */
> SCTP_STATIC
> -struct sctp_association *sctp_lookup_association(const union sctp_addr *laddr,
> +struct sctp_association *sctp_lookup_association(struct net *net,
> + const union sctp_addr *laddr,
> const union sctp_addr *paddr,
> struct sctp_transport **transportp)
> {
> struct sctp_association *asoc;
>
> sctp_local_bh_disable();
> - asoc = __sctp_lookup_association(laddr, paddr, transportp);
> + asoc = __sctp_lookup_association(net, laddr, paddr, transportp);
> sctp_local_bh_enable();
>
> return asoc;
> }
>
> /* Is there an association matching the given local and peer addresses? */
> -int sctp_has_association(const union sctp_addr *laddr,
> +int sctp_has_association(struct net *net,
> + const union sctp_addr *laddr,
> const union sctp_addr *paddr)
> {
> struct sctp_association *asoc;
> struct sctp_transport *transport;
>
> - if ((asoc = sctp_lookup_association(laddr, paddr, &transport))) {
> + if ((asoc = sctp_lookup_association(net, laddr, paddr, &transport))) {
> sctp_association_put(asoc);
> return 1;
> }
> @@ -943,7 +953,8 @@ int sctp_has_association(const union sctp_addr *laddr,
> * in certain circumstances.
> *
> */
> -static struct sctp_association *__sctp_rcv_init_lookup(struct sk_buff *skb,
> +static struct sctp_association *__sctp_rcv_init_lookup(struct net *net,
> + struct sk_buff *skb,
> const union sctp_addr *laddr, struct sctp_transport **transportp)
> {
> struct sctp_association *asoc;
> @@ -983,7 +994,7 @@ static struct sctp_association *__sctp_rcv_init_lookup(struct sk_buff *skb,
>
> af->from_addr_param(paddr, params.addr, sh->source, 0);
>
> - asoc = __sctp_lookup_association(laddr, paddr, &transport);
> + asoc = __sctp_lookup_association(net, laddr, paddr, &transport);
> if (asoc)
> return asoc;
> }
> @@ -1006,6 +1017,7 @@ static struct sctp_association *__sctp_rcv_init_lookup(struct sk_buff *skb,
> * subsequent ASCONF Chunks. If found, proceed to rule D4.
> */
> static struct sctp_association *__sctp_rcv_asconf_lookup(
> + struct net *net,
> sctp_chunkhdr_t *ch,
> const union sctp_addr *laddr,
> __be16 peer_port,
> @@ -1025,7 +1037,7 @@ static struct sctp_association *__sctp_rcv_asconf_lookup(
>
> af->from_addr_param(&paddr, param, peer_port, 0);
>
> - return __sctp_lookup_association(laddr, &paddr, transportp);
> + return __sctp_lookup_association(net, laddr, &paddr, transportp);
> }
>
>
> @@ -1038,7 +1050,8 @@ static struct sctp_association *__sctp_rcv_asconf_lookup(
> * This means that any chunks that can help us identify the association need
> * to be looked at to find this association.
> */
> -static struct sctp_association *__sctp_rcv_walk_lookup(struct sk_buff *skb,
> +static struct sctp_association *__sctp_rcv_walk_lookup(struct net *net,
> + struct sk_buff *skb,
> const union sctp_addr *laddr,
> struct sctp_transport **transportp)
> {
> @@ -1080,7 +1093,8 @@ static struct sctp_association *__sctp_rcv_walk_lookup(struct sk_buff *skb,
>
> case SCTP_CID_ASCONF:
> if (have_auth || sctp_addip_noauth)
> - asoc = __sctp_rcv_asconf_lookup(ch, laddr,
> + asoc = __sctp_rcv_asconf_lookup(
> + net, ch, laddr,
> sctp_hdr(skb)->source,
> transportp);
> default:
> @@ -1103,7 +1117,8 @@ static struct sctp_association *__sctp_rcv_walk_lookup(struct sk_buff *skb,
> * include looking inside of INIT/INIT-ACK chunks or after the AUTH
> * chunks.
> */
> -static struct sctp_association *__sctp_rcv_lookup_harder(struct sk_buff *skb,
> +static struct sctp_association *__sctp_rcv_lookup_harder(struct net *net,
> + struct sk_buff *skb,
> const union sctp_addr *laddr,
> struct sctp_transport **transportp)
> {
> @@ -1123,11 +1138,11 @@ static struct sctp_association *__sctp_rcv_lookup_harder(struct sk_buff *skb,
> switch (ch->type) {
> case SCTP_CID_INIT:
> case SCTP_CID_INIT_ACK:
> - return __sctp_rcv_init_lookup(skb, laddr, transportp);
> + return __sctp_rcv_init_lookup(net, skb, laddr, transportp);
> break;
>
> default:
> - return __sctp_rcv_walk_lookup(skb, laddr, transportp);
> + return __sctp_rcv_walk_lookup(net, skb, laddr, transportp);
> break;
> }
>
> @@ -1136,21 +1151,22 @@ static struct sctp_association *__sctp_rcv_lookup_harder(struct sk_buff *skb,
> }
>
> /* Lookup an association for an inbound skb. */
> -static struct sctp_association *__sctp_rcv_lookup(struct sk_buff *skb,
> +static struct sctp_association *__sctp_rcv_lookup(struct net *net,
> + struct sk_buff *skb,
> const union sctp_addr *paddr,
> const union sctp_addr *laddr,
> struct sctp_transport **transportp)
> {
> struct sctp_association *asoc;
>
> - asoc = __sctp_lookup_association(laddr, paddr, transportp);
> + asoc = __sctp_lookup_association(net, laddr, paddr, transportp);
>
> /* Further lookup for INIT/INIT-ACK packets.
> * SCTP Implementors Guide, 2.18 Handling of address
> * parameters within the INIT or INIT-ACK.
> */
> if (!asoc)
> - asoc = __sctp_rcv_lookup_harder(skb, laddr, transportp);
> + asoc = __sctp_rcv_lookup_harder(net, skb, laddr, transportp);
>
> return asoc;
> }
> diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
> index ed7139e..2165a7e 100644
> --- a/net/sctp/ipv6.c
> +++ b/net/sctp/ipv6.c
> @@ -154,6 +154,7 @@ SCTP_STATIC void sctp_v6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
> struct ipv6_pinfo *np;
> sk_buff_data_t saveip, savesctp;
> int err;
> + struct net *net = dev_net(skb->dev);
>
> idev = in6_dev_get(skb->dev);
>
> @@ -162,7 +163,7 @@ SCTP_STATIC void sctp_v6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
> savesctp = skb->transport_header;
> skb_reset_network_header(skb);
> skb_set_transport_header(skb, offset);
> - sk = sctp_err_lookup(AF_INET6, skb, sctp_hdr(skb), &asoc, &transport);
> + sk = sctp_err_lookup(net, AF_INET6, skb, sctp_hdr(skb), &asoc, &transport);
> /* Put back, the original pointers. */
> skb->network_header = saveip;
> skb->transport_header = savesctp;
>
^ 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