* Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.
From: Serge E. Hallyn @ 2010-03-08 21:49 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Daniel Lezcano, Pavel Emelyanov, Sukadev Bhattiprolu,
Linux Netdev List, containers, Netfilter Development Mailinglist,
Ben Greear
In-Reply-To: <m1lje2qzf4.fsf@fess.ebiederm.org>
Quoting Eric W. Biederman (ebiederm@xmission.com):
> Daniel Lezcano <daniel.lezcano@free.fr> writes:
> I guess my meaning is I was expecting.
> child = fork();
> if (child == 0) {
> execve(...);
> }
> waitpid(child);
>
> This puts /bin/sh in the container as well.
>
> I'm not certain about the /proc/self thing I have never encountered that.
> But I guess if your pid is outside of the pid namespace of that instance
> of proc /proc/self will be a broken symlink.
>
> Eric
Hmm, worse than a broken symlink, will it be a wrong symlink if just
the right pid is created in the container?
-serge
^ permalink raw reply
* Re: [net-next-2.6 PATCH] bonding: refuse to change bond type if it's used
From: Jiri Pirko @ 2010-03-08 21:35 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev, fubar, bonding-devel
In-Reply-To: <20100308.121632.232613075.davem@davemloft.net>
Mon, Mar 08, 2010 at 09:16:32PM CET, davem@davemloft.net wrote:
>From: Stephen Hemminger <shemminger@linux-foundation.org>
>Date: Mon, 8 Mar 2010 10:24:48 -0800
>
>> On Mon, 8 Mar 2010 18:54:06 +0100
>> Jiri Pirko <jpirko@redhat.com> wrote:
>>
>>> It's not desirable to be able to change the type of net_device in bond device if
>>> it's in use by bridge, or vlan, or so. At the moment, there is possible for
>>> example to have INFINIBAND bond type in bridge (by adding bond with eth type to
>>> a bridge first and then enslave INFINIBAND device).
>>
>> Rather than building lots of back pointer dependencies, why not
>> have another netdevice notifier that allows other subsystems to
>> see the type change and reject it if they care? That way the code
>> would be more modular and expandable.
>
>Agreed.
Fair enough, I will rework this.
Thanks a lot guys for looking at this.
Jirka
^ permalink raw reply
* [PATCH] netlink: convert DIY reader/writer to mutex and RCU
From: Stephen Hemminger @ 2010-03-08 21:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev
The netlink table locking was open coded of reader/writer
sleeping lock. Change to using mutex and RCU which makes
code clearer, shorter, and simpler.
The genetlink code is simplified because it is allowable
to acquire mutex with RCU lock.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
include/linux/netlink.h | 3
include/net/sock.h | 2
net/netlink/af_netlink.c | 146 ++++++++++++++---------------------------------
net/netlink/genetlink.c | 4 -
4 files changed, 47 insertions(+), 108 deletions(-)
--- a/net/netlink/af_netlink.c 2010-03-08 09:07:15.104547875 -0800
+++ b/net/netlink/af_netlink.c 2010-03-08 11:02:01.263297712 -0800
@@ -128,15 +128,11 @@ struct netlink_table {
};
static struct netlink_table *nl_table;
-
-static DECLARE_WAIT_QUEUE_HEAD(nl_table_wait);
+static DEFINE_MUTEX(nltable_mutex);
static int netlink_dump(struct sock *sk);
static void netlink_destroy_callback(struct netlink_callback *cb);
-static DEFINE_RWLOCK(nl_table_lock);
-static atomic_t nl_table_users = ATOMIC_INIT(0);
-
static ATOMIC_NOTIFIER_HEAD(netlink_chain);
static u32 netlink_group_mask(u32 group)
@@ -171,61 +167,6 @@ static void netlink_sock_destruct(struct
WARN_ON(nlk_sk(sk)->groups);
}
-/* This lock without WQ_FLAG_EXCLUSIVE is good on UP and it is _very_ bad on
- * SMP. Look, when several writers sleep and reader wakes them up, all but one
- * immediately hit write lock and grab all the cpus. Exclusive sleep solves
- * this, _but_ remember, it adds useless work on UP machines.
- */
-
-void netlink_table_grab(void)
- __acquires(nl_table_lock)
-{
- might_sleep();
-
- write_lock_irq(&nl_table_lock);
-
- if (atomic_read(&nl_table_users)) {
- DECLARE_WAITQUEUE(wait, current);
-
- add_wait_queue_exclusive(&nl_table_wait, &wait);
- for (;;) {
- set_current_state(TASK_UNINTERRUPTIBLE);
- if (atomic_read(&nl_table_users) == 0)
- break;
- write_unlock_irq(&nl_table_lock);
- schedule();
- write_lock_irq(&nl_table_lock);
- }
-
- __set_current_state(TASK_RUNNING);
- remove_wait_queue(&nl_table_wait, &wait);
- }
-}
-
-void netlink_table_ungrab(void)
- __releases(nl_table_lock)
-{
- write_unlock_irq(&nl_table_lock);
- wake_up(&nl_table_wait);
-}
-
-static inline void
-netlink_lock_table(void)
-{
- /* read_lock() synchronizes us to netlink_table_grab */
-
- read_lock(&nl_table_lock);
- atomic_inc(&nl_table_users);
- read_unlock(&nl_table_lock);
-}
-
-static inline void
-netlink_unlock_table(void)
-{
- if (atomic_dec_and_test(&nl_table_users))
- wake_up(&nl_table_wait);
-}
-
static inline struct sock *netlink_lookup(struct net *net, int protocol,
u32 pid)
{
@@ -234,9 +175,9 @@ static inline struct sock *netlink_looku
struct sock *sk;
struct hlist_node *node;
- read_lock(&nl_table_lock);
+ rcu_read_lock();
head = nl_pid_hashfn(hash, pid);
- sk_for_each(sk, node, head) {
+ sk_for_each_rcu(sk, node, head) {
if (net_eq(sock_net(sk), net) && (nlk_sk(sk)->pid == pid)) {
sock_hold(sk);
goto found;
@@ -244,7 +185,7 @@ static inline struct sock *netlink_looku
}
sk = NULL;
found:
- read_unlock(&nl_table_lock);
+ rcu_read_unlock();
return sk;
}
@@ -353,7 +294,7 @@ static int netlink_insert(struct sock *s
struct hlist_node *node;
int len;
- netlink_table_grab();
+ mutex_lock(&nltable_mutex);
head = nl_pid_hashfn(hash, pid);
len = 0;
sk_for_each(osk, node, head) {
@@ -380,18 +321,18 @@ static int netlink_insert(struct sock *s
err = 0;
err:
- netlink_table_ungrab();
+ mutex_unlock(&nltable_mutex);
return err;
}
static void netlink_remove(struct sock *sk)
{
- netlink_table_grab();
+ mutex_lock(&nltable_mutex);
if (sk_del_node_init(sk))
nl_table[sk->sk_protocol].hash.entries--;
if (nlk_sk(sk)->subscriptions)
__sk_del_bind_node(sk);
- netlink_table_ungrab();
+ mutex_unlock(&nltable_mutex);
}
static struct proto netlink_proto = {
@@ -444,12 +385,14 @@ static int netlink_create(struct net *ne
if (protocol < 0 || protocol >= MAX_LINKS)
return -EPROTONOSUPPORT;
- netlink_lock_table();
+ mutex_lock(&nltable_mutex);
#ifdef CONFIG_MODULES
if (!nl_table[protocol].registered) {
- netlink_unlock_table();
+ mutex_unlock(&nltable_mutex);
+
request_module("net-pf-%d-proto-%d", PF_NETLINK, protocol);
- netlink_lock_table();
+
+ mutex_lock(&nltable_mutex);
}
#endif
if (nl_table[protocol].registered &&
@@ -458,7 +401,7 @@ static int netlink_create(struct net *ne
else
err = -EPROTONOSUPPORT;
cb_mutex = nl_table[protocol].cb_mutex;
- netlink_unlock_table();
+ mutex_unlock(&nltable_mutex);
if (err < 0)
goto out;
@@ -515,7 +458,7 @@ static int netlink_release(struct socket
module_put(nlk->module);
- netlink_table_grab();
+ mutex_lock(&nltable_mutex);
if (netlink_is_kernel(sk)) {
BUG_ON(nl_table[sk->sk_protocol].registered == 0);
if (--nl_table[sk->sk_protocol].registered == 0) {
@@ -525,7 +468,7 @@ static int netlink_release(struct socket
}
} else if (nlk->subscriptions)
netlink_update_listeners(sk);
- netlink_table_ungrab();
+ mutex_unlock(&nltable_mutex);
kfree(nlk->groups);
nlk->groups = NULL;
@@ -533,6 +476,8 @@ static int netlink_release(struct socket
local_bh_disable();
sock_prot_inuse_add(sock_net(sk), &netlink_proto, -1);
local_bh_enable();
+
+ synchronize_rcu();
sock_put(sk);
return 0;
}
@@ -551,7 +496,7 @@ static int netlink_autobind(struct socke
retry:
cond_resched();
- netlink_table_grab();
+ mutex_lock(&nltable_mutex);
head = nl_pid_hashfn(hash, pid);
sk_for_each(osk, node, head) {
if (!net_eq(sock_net(osk), net))
@@ -561,11 +506,11 @@ retry:
pid = rover--;
if (rover > -4097)
rover = -4097;
- netlink_table_ungrab();
+ mutex_unlock(&nltable_mutex);
goto retry;
}
}
- netlink_table_ungrab();
+ mutex_unlock(&nltable_mutex);
err = netlink_insert(sk, net, pid);
if (err == -EADDRINUSE)
@@ -603,7 +548,7 @@ static int netlink_realloc_groups(struct
unsigned long *new_groups;
int err = 0;
- netlink_table_grab();
+ mutex_lock(&nltable_mutex);
groups = nl_table[sk->sk_protocol].groups;
if (!nl_table[sk->sk_protocol].registered) {
@@ -625,7 +570,7 @@ static int netlink_realloc_groups(struct
nlk->groups = new_groups;
nlk->ngroups = groups;
out_unlock:
- netlink_table_ungrab();
+ mutex_unlock(&nltable_mutex);
return err;
}
@@ -664,13 +609,13 @@ static int netlink_bind(struct socket *s
if (!nladdr->nl_groups && (nlk->groups == NULL || !(u32)nlk->groups[0]))
return 0;
- netlink_table_grab();
+ mutex_lock(&nltable_mutex);
netlink_update_subscriptions(sk, nlk->subscriptions +
hweight32(nladdr->nl_groups) -
hweight32(nlk->groups[0]));
nlk->groups[0] = (nlk->groups[0] & ~0xffffffffUL) | nladdr->nl_groups;
netlink_update_listeners(sk);
- netlink_table_ungrab();
+ mutex_unlock(&nltable_mutex);
return 0;
}
@@ -1059,15 +1004,12 @@ int netlink_broadcast(struct sock *ssk,
/* While we sleep in clone, do not allow to change socket list */
- netlink_lock_table();
-
- sk_for_each_bound(sk, node, &nl_table[ssk->sk_protocol].mc_list)
+ rcu_read_lock();
+ sk_for_each_bound_rcu(sk, node, &nl_table[ssk->sk_protocol].mc_list)
do_one_broadcast(sk, &info);
+ rcu_read_unlock();
kfree_skb(skb);
-
- netlink_unlock_table();
-
kfree_skb(info.skb2);
if (info.delivery_failure)
@@ -1129,12 +1071,12 @@ void netlink_set_err(struct sock *ssk, u
/* sk->sk_err wants a positive error value */
info.code = -code;
- read_lock(&nl_table_lock);
+ rcu_read_lock();
- sk_for_each_bound(sk, node, &nl_table[ssk->sk_protocol].mc_list)
+ sk_for_each_bound_rcu(sk, node, &nl_table[ssk->sk_protocol].mc_list)
do_one_set_err(sk, &info);
- read_unlock(&nl_table_lock);
+ rcu_read_unlock();
}
EXPORT_SYMBOL(netlink_set_err);
@@ -1187,10 +1129,10 @@ static int netlink_setsockopt(struct soc
return err;
if (!val || val - 1 >= nlk->ngroups)
return -EINVAL;
- netlink_table_grab();
+ mutex_lock(&nltable_mutex);
netlink_update_socket_mc(nlk, val,
optname == NETLINK_ADD_MEMBERSHIP);
- netlink_table_ungrab();
+ mutex_unlock(&nltable_mutex);
err = 0;
break;
}
@@ -1515,7 +1457,7 @@ netlink_kernel_create(struct net *net, i
nlk = nlk_sk(sk);
nlk->flags |= NETLINK_KERNEL_SOCKET;
- netlink_table_grab();
+ mutex_lock(&nltable_mutex);
if (!nl_table[unit].registered) {
nl_table[unit].groups = groups;
nl_table[unit].listeners = listeners;
@@ -1526,7 +1468,7 @@ netlink_kernel_create(struct net *net, i
kfree(listeners);
nl_table[unit].registered++;
}
- netlink_table_ungrab();
+ mutex_unlock(&nltable_mutex);
return sk;
out_sock_release:
@@ -1557,7 +1499,7 @@ static void netlink_free_old_listeners(s
kfree(lrh->ptr);
}
-int __netlink_change_ngroups(struct sock *sk, unsigned int groups)
+static int __netlink_change_ngroups(struct sock *sk, unsigned int groups)
{
unsigned long *listeners, *old = NULL;
struct listeners_rcu_head *old_rcu_head;
@@ -1608,14 +1550,14 @@ int netlink_change_ngroups(struct sock *
{
int err;
- netlink_table_grab();
+ mutex_lock(&nltable_mutex);
err = __netlink_change_ngroups(sk, groups);
- netlink_table_ungrab();
+ mutex_unlock(&nltable_mutex);
return err;
}
-void __netlink_clear_multicast_users(struct sock *ksk, unsigned int group)
+static void __netlink_clear_multicast_users(struct sock *ksk, unsigned int group)
{
struct sock *sk;
struct hlist_node *node;
@@ -1635,9 +1577,9 @@ void __netlink_clear_multicast_users(str
*/
void netlink_clear_multicast_users(struct sock *ksk, unsigned int group)
{
- netlink_table_grab();
+ mutex_lock(&nltable_mutex);
__netlink_clear_multicast_users(ksk, group);
- netlink_table_ungrab();
+ mutex_unlock(&nltable_mutex);
}
void netlink_set_nonroot(int protocol, unsigned int flags)
@@ -1902,7 +1844,7 @@ static struct sock *netlink_seq_socket_i
struct nl_pid_hash *hash = &nl_table[i].hash;
for (j = 0; j <= hash->mask; j++) {
- sk_for_each(s, node, &hash->table[j]) {
+ sk_for_each_rcu(s, node, &hash->table[j]) {
if (sock_net(s) != seq_file_net(seq))
continue;
if (off == pos) {
@@ -1918,9 +1860,9 @@ static struct sock *netlink_seq_socket_i
}
static void *netlink_seq_start(struct seq_file *seq, loff_t *pos)
- __acquires(nl_table_lock)
+ __acquires(RCU)
{
- read_lock(&nl_table_lock);
+ rcu_read_lock();
return *pos ? netlink_seq_socket_idx(seq, *pos - 1) : SEQ_START_TOKEN;
}
@@ -1967,9 +1909,9 @@ static void *netlink_seq_next(struct seq
}
static void netlink_seq_stop(struct seq_file *seq, void *v)
- __releases(nl_table_lock)
+ __releases(RCU)
{
- read_unlock(&nl_table_lock);
+ rcu_read_unlock();
}
--- a/include/net/sock.h 2010-03-08 10:52:34.113924084 -0800
+++ b/include/net/sock.h 2010-03-08 10:52:50.222986495 -0800
@@ -507,6 +507,8 @@ static __inline__ void sk_add_bind_node(
hlist_for_each_entry_safe(__sk, node, tmp, list, sk_node)
#define sk_for_each_bound(__sk, node, list) \
hlist_for_each_entry(__sk, node, list, sk_bind_node)
+#define sk_for_each_bound_rcu(__sk, node, list) \
+ hlist_for_each_entry_rcu(__sk, node, list, sk_bind_node)
/* Sock flags */
enum sock_flags {
--- a/include/linux/netlink.h 2010-03-08 10:56:35.314235687 -0800
+++ b/include/linux/netlink.h 2010-03-08 11:04:33.414547616 -0800
@@ -170,18 +170,13 @@ struct netlink_skb_parms {
#define NETLINK_CREDS(skb) (&NETLINK_CB((skb)).creds)
-extern void netlink_table_grab(void);
-extern void netlink_table_ungrab(void);
-
extern struct sock *netlink_kernel_create(struct net *net,
int unit,unsigned int groups,
void (*input)(struct sk_buff *skb),
struct mutex *cb_mutex,
struct module *module);
extern void netlink_kernel_release(struct sock *sk);
-extern int __netlink_change_ngroups(struct sock *sk, unsigned int groups);
extern int netlink_change_ngroups(struct sock *sk, unsigned int groups);
-extern void __netlink_clear_multicast_users(struct sock *sk, unsigned int group);
extern void netlink_clear_multicast_users(struct sock *sk, unsigned int group);
extern void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err);
extern int netlink_has_listeners(struct sock *sk, unsigned int group);
--- a/net/netlink/genetlink.c 2010-03-08 10:56:02.194547526 -0800
+++ b/net/netlink/genetlink.c 2010-03-08 11:01:05.865177057 -0800
@@ -168,10 +168,9 @@ int genl_register_mc_group(struct genl_f
if (family->netnsok) {
struct net *net;
- netlink_table_grab();
rcu_read_lock();
for_each_net_rcu(net) {
- err = __netlink_change_ngroups(net->genl_sock,
+ err = netlink_change_ngroups(net->genl_sock,
mc_groups_longs * BITS_PER_LONG);
if (err) {
/*
@@ -181,12 +180,10 @@ int genl_register_mc_group(struct genl_f
* increased on some sockets which is ok.
*/
rcu_read_unlock();
- netlink_table_ungrab();
goto out;
}
}
rcu_read_unlock();
- netlink_table_ungrab();
} else {
err = netlink_change_ngroups(init_net.genl_sock,
mc_groups_longs * BITS_PER_LONG);
@@ -212,12 +209,10 @@ static void __genl_unregister_mc_group(s
struct net *net;
BUG_ON(grp->family != family);
- netlink_table_grab();
rcu_read_lock();
for_each_net_rcu(net)
- __netlink_clear_multicast_users(net->genl_sock, grp->id);
+ netlink_clear_multicast_users(net->genl_sock, grp->id);
rcu_read_unlock();
- netlink_table_ungrab();
clear_bit(grp->id, mc_groups);
list_del(&grp->list);
^ permalink raw reply
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode (v2)
From: David Miller @ 2010-03-08 21:26 UTC (permalink / raw)
To: nhorman; +Cc: netdev, jon.maloy, allan.stephens, tipc-discussion
In-Reply-To: <20100308211308.GI23634@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Mon, 8 Mar 2010 16:13:08 -0500
> On Mon, Mar 08, 2010 at 12:19:42PM -0800, David Miller wrote:
>>
>> Doesn't apply to net-2.6, Neil please respin.
>>
> Yes, sorry David, didn't mean to reply so quickly before. I just looked at your
> net-2.6 tree, and d0021b252eaf65ca07ed14f0d66425dd9ccab9a6 is in there just
> fine. Not sure if I'm missing something or not, but as far as I can see you've
> already apply the patch properly.
Perfect.
^ permalink raw reply
* Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.
From: Eric W. Biederman @ 2010-03-08 21:25 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Pavel Emelyanov, Sukadev Bhattiprolu, Serge Hallyn,
Linux Netdev List, containers, Netfilter Development Mailinglist,
Ben Greear
In-Reply-To: <4B956852.7050804@free.fr>
Daniel Lezcano <daniel.lezcano@free.fr> writes:
> Eric W. Biederman wrote:
>> Daniel Lezcano <daniel.lezcano@free.fr> writes:
>>
>>
>>> Eric W. Biederman wrote:
>>>
>>>> Daniel Lezcano <daniel.lezcano@free.fr> writes:
>>>>
>>>>
>>>>> Eric W. Biederman wrote:
>>>>>
>>>>>> Daniel Lezcano <daniel.lezcano@free.fr> writes:
>>>>>>
>>>>>>
>>>>>>> Eric W. Biederman wrote:
>>>>>>>
>>>>>>>> I have take an snapshot of my development tree and placed it at.
>>>>>>>>
>>>>>>>>
>>>>>>>> git://git.kernel.org/pub/scm/linux/people/ebiederm/linux-2.6.33-nsfd-v5.git
>>>>>>>>
>>>>>>> Hi Eric,
>>>>>>>
>>>>>>> thanks for the pointer.
>>>>>>>
>>>>>>> I tried to boot the kernel under qemu and I got this oops:
>>>>>>>
>>>>>> I am clearly running an old userspace on my test machine. No udev.
>>>>>> It looks like udev has a long standing netlink misfeature, where
>>>>>> it does not initializing NETLINK_CB....
>>>>>>
>>>>>>
>>>>>> >From 8d85e3ab88718eda3d94cf8e1be14b69dae2b8f1 Mon Sep 17 00:00:00 2001
>>>>>> From: Eric W. Biederman <ebiederm@xmission.com>
>>>>>> Date: Mon, 8 Mar 2010 09:25:20 -0800
>>>>>> Subject: [PATCH] kobject_uevent: Use the netlink allocator helper...
>>>>>>
>>>>>> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>>>>>>
>>>>> Thanks.
>>>>>
>>>>> I was able to boot but I have the following warning:
>>>>>
>>>> Thanks for the bug report.
>>>>
>>> Thanks to you for the patchset :)
>>>
>>>
>>>> For the moment you might want to drop:
>>>> af_netlink: Allow credentials to work across namespaces.
>>>> af_netlink: Debugging in case I have missed something.
>>>>
>>>> Although I am curious if you hit my debugging messages in
>>>> netlink recv.
>>>>
>>> No, it does not appear (looked for "missing NETLINK_CB proto").
>>>
>>>
>>>> I guess if the goal is to test my nsfd bits you can drop everything
>>>> starting with my 'scm: Reorder scm_cookie.' commit. The rest is what
>>>> it takes to get get uids, gid and pids translated when the cross
>>>> namespaces on an af_unix of an af_netlink socket.
>>>>
>>>> At least in the af_netlink case it appears clear I am have missed
>>>> something.
>>>>
>>>> This is a warning that netlink throws when the packet accounting messed
>>>> up. So it sounds like you are exercising another path that I failed
>>>> to exercise and fix.
>>>>
>>> I will look forward if I find more clues for this warning.
>>>
>>> In the meantime was able to enter the container with the ugly following
>>> program:
>>>
>>> #include <unistd.h>
>>> #include <stdlib.h>
>>> #include <stdio.h>
>>> #include <syscall.h>
>>> #include <sys/types.h>
>>> #include <sys/stat.h>
>>> #include <fcntl.h>
>>> #include <sys/param.h>
>>>
>>> #define __NR_setns 300
>>>
>>> int setns(int nstype, int fd)
>>> {
>>> return syscall (__NR_setns, nstype, fd);
>>> }
>>>
>>> int main(int argc, char *argv[])
>>> {
>>> char path[MAXPATHLEN];
>>> char *ns[] = { "pid", "mnt", "net", "pid", "uts" };
>>> const int size = sizeof(ns) / sizeof(char *);
>>> int fd[size];
>>> int i;
>>>
>>> if (argc != 3) {
>>> fprintf(stderr, "mynsenter <pid> <command>\n");
>>> exit(1);
>>> }
>>>
>>> for (i = 0; i < size; i++) {
>>> sprintf(path, "/proc/%s/ns/%s", argv[1], ns[i]);
>>>
>>> fd[i] = open(path, O_RDONLY);
>>> if (fd[i] < 0) {
>>> perror("open");
>>> return -1;
>>> }
>>>
>>> }
>>>
>>> for (i = 0; i < size; i++) {
>>>
>>> if (setns(0, fd[i])) {
>>> perror("setns");
>>> return -1;
>>> }
>>> }
>>>
>>> execve(argv[2], &argv[2], NULL);
>>> perror("execve");
>>>
>>> return 0;
>>> }
>>>
>>> At the fist glance, no problem :)
>>>
>>
>> No fork() so your processes is completely in the pid namespace?
>>
> What I do is to attach "/bin/sh" to the container with this program.
> The container is a VPS running busybox with the full isolation.
>
> echo $$ gives the real pid.
> All the forked processes appears in the pid namespace, they are visible through
> /proc with the virtual pid.
> I am not able to change to the /proc/self directory (I assume this is normal).
I guess my meaning is I was expecting.
child = fork();
if (child == 0) {
execve(...);
}
waitpid(child);
This puts /bin/sh in the container as well.
I'm not certain about the /proc/self thing I have never encountered that.
But I guess if your pid is outside of the pid namespace of that instance
of proc /proc/self will be a broken symlink.
Eric
^ permalink raw reply
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode (v2)
From: Neil Horman @ 2010-03-08 21:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jon.maloy, allan.stephens, tipc-discussion
In-Reply-To: <20100308.121942.67584963.davem@davemloft.net>
On Mon, Mar 08, 2010 at 12:19:42PM -0800, David Miller wrote:
>
> Doesn't apply to net-2.6, Neil please respin.
>
Yes, sorry David, didn't mean to reply so quickly before. I just looked at your
net-2.6 tree, and d0021b252eaf65ca07ed14f0d66425dd9ccab9a6 is in there just
fine. Not sure if I'm missing something or not, but as far as I can see you've
already apply the patch properly.
Regards
Neil
^ permalink raw reply
* Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.
From: Daniel Lezcano @ 2010-03-08 21:12 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Pavel Emelyanov, Sukadev Bhattiprolu, Serge Hallyn,
Linux Netdev List, containers, Netfilter Development Mailinglist,
Ben Greear
In-Reply-To: <m1sk8ar15b.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> Daniel Lezcano <daniel.lezcano@free.fr> writes:
>
>
>> Eric W. Biederman wrote:
>>
>>> Daniel Lezcano <daniel.lezcano@free.fr> writes:
>>>
>>>
>>>
>>>> Eric W. Biederman wrote:
>>>>
>>>>
>>>>> Daniel Lezcano <daniel.lezcano@free.fr> writes:
>>>>>
>>>>>
>>>>>
>>>>>> Eric W. Biederman wrote:
>>>>>>
>>>>>>
>>>>>>> I have take an snapshot of my development tree and placed it at.
>>>>>>>
>>>>>>>
>>>>>>> git://git.kernel.org/pub/scm/linux/people/ebiederm/linux-2.6.33-nsfd-v5.git
>>>>>>>
>>>>>>>
>>>>>> Hi Eric,
>>>>>>
>>>>>> thanks for the pointer.
>>>>>>
>>>>>> I tried to boot the kernel under qemu and I got this oops:
>>>>>>
>>>>>>
>>>>> I am clearly running an old userspace on my test machine. No udev.
>>>>> It looks like udev has a long standing netlink misfeature, where
>>>>> it does not initializing NETLINK_CB....
>>>>>
>>>>>
>>>>> >From 8d85e3ab88718eda3d94cf8e1be14b69dae2b8f1 Mon Sep 17 00:00:00 2001
>>>>> From: Eric W. Biederman <ebiederm@xmission.com>
>>>>> Date: Mon, 8 Mar 2010 09:25:20 -0800
>>>>> Subject: [PATCH] kobject_uevent: Use the netlink allocator helper...
>>>>>
>>>>> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>>>>>
>>>>>
>>>> Thanks.
>>>>
>>>> I was able to boot but I have the following warning:
>>>>
>>>>
>>> Thanks for the bug report.
>>>
>>>
>> Thanks to you for the patchset :)
>>
>>
>>> For the moment you might want to drop:
>>> af_netlink: Allow credentials to work across namespaces.
>>> af_netlink: Debugging in case I have missed something.
>>>
>>> Although I am curious if you hit my debugging messages in
>>> netlink recv.
>>>
>>>
>> No, it does not appear (looked for "missing NETLINK_CB proto").
>>
>>
>>> I guess if the goal is to test my nsfd bits you can drop everything
>>> starting with my 'scm: Reorder scm_cookie.' commit. The rest is what
>>> it takes to get get uids, gid and pids translated when the cross
>>> namespaces on an af_unix of an af_netlink socket.
>>>
>>> At least in the af_netlink case it appears clear I am have missed
>>> something.
>>>
>>> This is a warning that netlink throws when the packet accounting messed
>>> up. So it sounds like you are exercising another path that I failed
>>> to exercise and fix.
>>>
>>>
>> I will look forward if I find more clues for this warning.
>>
>> In the meantime was able to enter the container with the ugly following
>> program:
>>
>> #include <unistd.h>
>> #include <stdlib.h>
>> #include <stdio.h>
>> #include <syscall.h>
>> #include <sys/types.h>
>> #include <sys/stat.h>
>> #include <fcntl.h>
>> #include <sys/param.h>
>>
>> #define __NR_setns 300
>>
>> int setns(int nstype, int fd)
>> {
>> return syscall (__NR_setns, nstype, fd);
>> }
>>
>> int main(int argc, char *argv[])
>> {
>> char path[MAXPATHLEN];
>> char *ns[] = { "pid", "mnt", "net", "pid", "uts" };
>> const int size = sizeof(ns) / sizeof(char *);
>> int fd[size];
>> int i;
>>
>> if (argc != 3) {
>> fprintf(stderr, "mynsenter <pid> <command>\n");
>> exit(1);
>> }
>>
>> for (i = 0; i < size; i++) {
>> sprintf(path, "/proc/%s/ns/%s", argv[1], ns[i]);
>>
>> fd[i] = open(path, O_RDONLY);
>> if (fd[i] < 0) {
>> perror("open");
>> return -1;
>> }
>>
>> }
>>
>> for (i = 0; i < size; i++) {
>>
>> if (setns(0, fd[i])) {
>> perror("setns");
>> return -1;
>> }
>> }
>>
>> execve(argv[2], &argv[2], NULL);
>> perror("execve");
>>
>> return 0;
>> }
>>
>> At the fist glance, no problem :)
>>
>
> No fork() so your processes is completely in the pid namespace?
>
What I do is to attach "/bin/sh" to the container with this program.
The container is a VPS running busybox with the full isolation.
echo $$ gives the real pid.
All the forked processes appears in the pid namespace, they are visible
through /proc with the virtual pid.
I am not able to change to the /proc/self directory (I assume this is
normal).
^ permalink raw reply
* Re: [PATCH] tipc: fix endianness on tipc subscriber messages
From: Neil Horman @ 2010-03-08 21:09 UTC (permalink / raw)
To: Stephens, Allan; +Cc: davem, netdev
In-Reply-To: <29C1DC0826876849BDD9F1C67ABA29430728D116@ala-mail09.corp.ad.wrs.com>
On Mon, Mar 08, 2010 at 12:48:38PM -0800, Stephens, Allan wrote:
> Hi there:
>
> There are a couple of problems with this patch that need to be resolved
> before it can be applied to the upstream kernel.
>
> 1) Neil's replacement of the htohl() call with the equivalent
> htonl()/ntohl() calls, while well intentioned, was done without
> understanding why the htohl() calls were put there in the first place.
I'd love to hear what those reasons are. You're formating on-the-wire data to
an endianness defined by the receiving entity. I'm hard pressed to imagine a
reason why thats sane.
> In addition, the TIPC specification that he used to justify some of his
> decisions is out-dated, and doesn't reflect the latest version of the
> TIPC protocol. (I'll discuss this further in a follow-up email.)
>
Please, point out a more recent spec. The one I referenced is the most recent
publically available spec that I can find. although again, I'm hard pressed to
believe that the spec has changed to include a requirement to send data in
receiver byte order.
> 2) Neil's alteration of the memcpy() in the subscription cancelation
> routine is simply wrong. The pieces of the data structure that he
> claims are local are not local, and must be checked to ensure that the
> cancellation is done properly.
>
The origional memcmp checks sizeof(tipc_subscr) bytes of each entry in the
array. tipc_subscr is defined as:
struct tipc_subscr {
struct tipc_name_seq seq; /* name sequence of interest */
__u32 timeout; /* subscription duration (in ms) */
__u32 filter; /* bitmask of filter options */
char usr_handle[8]; /* available for subscriber use */
};
In subscr_subscribe (from which we also call subscr_cancel), we allocate new
entries for that list, only fillingout the seq.type, seq.lower, seq.upper,
timeout and filter. So if anyone locally changes usr_handle (which I see
several places that do), the memcmp won't match up properly. Additionally, I'm
hard pressed to believe (and this would be supported by the section of the spec
that I referenced), timeout, and filter also don't bear on the uniqueness of the
subscriber Id. Of course a subsequent version of the spec might have changed
that, But if it is, please point it out to me.
> I'm also surprised to see that this patch was immediately applied to
> net-2.6. First, there was no opportunity given for people to comment on
> the patch. Secondly, I would have expected this patch to be applied to
> net-next-2.6, since the functionality being changed here (at least the
> first part of it) is more like a feature enhancement than a bug fix. Am
> I misunderstanding the process being followed here? If so, please
> explain ...
>
I'll let David Comment of this, since the destination tree is his final
decision.
Neil
> Regards,
> Al
>
> > -----Original Message-----
> > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > Sent: Monday, March 08, 2010 3:03 PM
> > To: netdev@vger.kernel.org
> > Cc: Stephens, Allan; davem@davemloft.net; nhorman@tuxdriver.com
> > Subject: [PATCH] tipc: fix endianness on tipc subscriber messages
> >
> > Remove htohl implementation from tipc
> >
> > I was working on forward porting the downstream commits for
> > TIPC and ran accross this one:
> > http://tipc.cslab.ericsson.net/cgi-bin/gitweb.cgi?p=people/all
> > an/tipc.git;a=commitdiff;h=894279b9437b63cbb02405ad5b8e033b51e4e31e
> >
> > I was going to just take it, when I looked closer and noted
> > what it was doing.
> > This is basically a routine to byte swap fields of data in
> > sent/received packets for tipc, dependent upon the receivers
> > guessed endianness of the peer when a connection is
> > established. Asside from just seeming silly to me, it
> > appears to violate the latest RFC draft for tipc:
> > http://tipc.sourceforge.net/doc/draft-spec-tipc-02.txt
> > Which, according to section 4.2 and 4.3.3, requires that all
> > fields of all commands be sent in network byte order. So
> > instead of just taking this patch, instead I'm removing the
> > htohl function and replacing the calls with calls to ntohl in
> > the rx path and htonl in the send path.
> >
> > As part of this fix, I'm also changing the subscr_cancel
> > function, which searches the list of subscribers, using a
> > memcmp of the entire subscriber list, for the entry to tear
> > down. unfortunately it memcmps the entire tipc_subscr
> > structure which has several bits that are private to the
> > local side, so nothing will ever match. section 5.2 of the
> > draft spec indicates the <type,upper,lower> tuple should
> > uniquely identify a subscriber, so convert subscr_cancel to
> > just match on those fields (properly endian swapped).
> >
> > I've tested this using the tipc test suite, and its passed
> > without issue.
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > CC: Allan Stephens <allan.stephens@windriver.com>
> >
> >
> > subscr.c | 57
> > ++++++++++++++++++++++-----------------------------------
> > subscr.h | 2 --
> > 2 files changed, 22 insertions(+), 37 deletions(-)
> >
> > diff --git a/net/tipc/subscr.c b/net/tipc/subscr.c index
> > ac91f0d..ff123e5 100644
> > --- a/net/tipc/subscr.c
> > +++ b/net/tipc/subscr.c
> > @@ -76,19 +76,6 @@ struct top_srv {
> > static struct top_srv topsrv = { 0 };
> >
> > /**
> > - * htohl - convert value to endianness used by destination
> > - * @in: value to convert
> > - * @swap: non-zero if endianness must be reversed
> > - *
> > - * Returns converted value
> > - */
> > -
> > -static u32 htohl(u32 in, int swap)
> > -{
> > - return swap ? swab32(in) : in;
> > -}
> > -
> > -/**
> > * subscr_send_event - send a message containing a
> > tipc_event to the subscriber
> > *
> > * Note: Must not hold subscriber's server port lock, since
> > tipc_send() will @@ -107,11 +94,11 @@ static void
> > subscr_send_event(struct subscription *sub,
> > msg_sect.iov_base = (void *)&sub->evt;
> > msg_sect.iov_len = sizeof(struct tipc_event);
> >
> > - sub->evt.event = htohl(event, sub->swap);
> > - sub->evt.found_lower = htohl(found_lower, sub->swap);
> > - sub->evt.found_upper = htohl(found_upper, sub->swap);
> > - sub->evt.port.ref = htohl(port_ref, sub->swap);
> > - sub->evt.port.node = htohl(node, sub->swap);
> > + sub->evt.event = htonl(event);
> > + sub->evt.found_lower = htonl(found_lower);
> > + sub->evt.found_upper = htonl(found_upper);
> > + sub->evt.port.ref = htonl(port_ref);
> > + sub->evt.port.node = htonl(node);
> > tipc_send(sub->server_ref, 1, &msg_sect); }
> >
> > @@ -287,16 +274,23 @@ static void subscr_cancel(struct
> > tipc_subscr *s, {
> > struct subscription *sub;
> > struct subscription *sub_temp;
> > + __u32 type, lower, upper;
> > int found = 0;
> >
> > /* Find first matching subscription, exit if not found */
> >
> > + type = ntohl(s->seq.type);
> > + lower = ntohl(s->seq.lower);
> > + upper = ntohl(s->seq.upper);
> > +
> > list_for_each_entry_safe(sub, sub_temp,
> > &subscriber->subscription_list,
> > subscription_list) {
> > - if (!memcmp(s, &sub->evt.s, sizeof(struct
> > tipc_subscr))) {
> > - found = 1;
> > - break;
> > - }
> > + if ((type == sub->seq.type) &&
> > + (lower == sub->seq.lower) &&
> > + (upper == sub->seq.upper)) {
> > + found = 1;
> > + break;
> > + }
> > }
> > if (!found)
> > return;
> > @@ -325,16 +319,10 @@ static struct subscription
> > *subscr_subscribe(struct tipc_subscr *s,
> > struct subscriber
> > *subscriber) {
> > struct subscription *sub;
> > - int swap;
> > -
> > - /* Determine subscriber's endianness */
> > -
> > - swap = !(s->filter & (TIPC_SUB_PORTS | TIPC_SUB_SERVICE));
> >
> > /* Detect & process a subscription cancellation request */
> >
> > - if (s->filter & htohl(TIPC_SUB_CANCEL, swap)) {
> > - s->filter &= ~htohl(TIPC_SUB_CANCEL, swap);
> > + if (ntohl(s->filter) & TIPC_SUB_CANCEL) {
> > subscr_cancel(s, subscriber);
> > return NULL;
> > }
> > @@ -359,11 +347,11 @@ static struct subscription
> > *subscr_subscribe(struct tipc_subscr *s,
> >
> > /* Initialize subscription object */
> >
> > - sub->seq.type = htohl(s->seq.type, swap);
> > - sub->seq.lower = htohl(s->seq.lower, swap);
> > - sub->seq.upper = htohl(s->seq.upper, swap);
> > - sub->timeout = htohl(s->timeout, swap);
> > - sub->filter = htohl(s->filter, swap);
> > + sub->seq.type = ntohl(s->seq.type);
> > + sub->seq.lower = ntohl(s->seq.lower);
> > + sub->seq.upper = ntohl(s->seq.upper);
> > + sub->timeout = ntohl(s->timeout);
> > + sub->filter = ntohl(s->filter);
> > if ((!(sub->filter & TIPC_SUB_PORTS) ==
> > !(sub->filter & TIPC_SUB_SERVICE)) ||
> > (sub->seq.lower > sub->seq.upper)) { @@ -376,7
> > +364,6 @@ static struct subscription *subscr_subscribe(struct
> > tipc_subscr *s,
> > INIT_LIST_HEAD(&sub->nameseq_list);
> > list_add(&sub->subscription_list,
> > &subscriber->subscription_list);
> > sub->server_ref = subscriber->port_ref;
> > - sub->swap = swap;
> > memcpy(&sub->evt.s, s, sizeof(struct tipc_subscr));
> > atomic_inc(&topsrv.subscription_count);
> > if (sub->timeout != TIPC_WAIT_FOREVER) { diff --git
> > a/net/tipc/subscr.h b/net/tipc/subscr.h index 45d89bf..c20f496 100644
> > --- a/net/tipc/subscr.h
> > +++ b/net/tipc/subscr.h
> > @@ -53,7 +53,6 @@ typedef void (*tipc_subscr_event) (struct
> > subscription *sub,
> > * @nameseq_list: adjacent subscriptions in name sequence's
> > subscription list
> > * @subscription_list: adjacent subscriptions in
> > subscriber's subscription list
> > * @server_ref: object reference of server port associated
> > with subscription
> > - * @swap: indicates if subscriber uses opposite endianness
> > in its messages
> > * @evt: template for events generated by subscription
> > */
> >
> > @@ -66,7 +65,6 @@ struct subscription {
> > struct list_head nameseq_list;
> > struct list_head subscription_list;
> > u32 server_ref;
> > - int swap;
> > struct tipc_event evt;
> > };
> >
> >
>
^ permalink raw reply
* Re: [PATCH RESEND #2] ipg: Remove device claimed by dl2k from pci id table
From: Jeff Mahoney @ 2010-03-08 20:58 UTC (permalink / raw)
To: David Miller; +Cc: romieu, sorbica, netdev
In-Reply-To: <20100308.125700.04760925.davem@davemloft.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/08/2010 03:57 PM, David Miller wrote:
> From: Jeff Mahoney <jeffm@suse.com>
> Date: Mon, 08 Mar 2010 15:53:10 -0500
>
>> ipg: Remove device claimed by dl2k from pci id table
>>
>> This patch removes D-Link DGE-550T PCI ID (1186:4000) from the ipg
>> driver. The ipg driver is for IP2000-based cards and the DGE-550T is
>> a DL2000-based card. The driver loads and works for a few moments, but
>> once a real workload is applied it stops operating. The ipg driver
>> claimed this ID since it was introduced in 2.6.24 and it's forced many
>> users to blacklist it.
>>
>> The correct driver for this hardware is the dl2k driver, which has been
>> claiming this PCI ID since the 2.4 days.
>>
>> Signed-off-by: Jeff Mahoney <jeffm@suse.com>
>
> Please stop re-submitting this, it's already in the tree:
Heh ok. You just asked me to re-send it since it was corrupted. I never
got a response when I posted it the first time. Sorry for the noise.
- -Jeff
> commit 25cca5352712561fba97bd37c495593d641c1d39
> Author: Jeff Mahoney <jeffm@suse.com>
> Date: Thu Feb 11 10:26:38 2010 +0000
>
> ipg: Remove device claimed by dl2k from pci id table
>
> This patch removes D-Link DGE-550T PCI ID (1186:4000) from the ipg
> driver. The ipg driver is for IP2000-based cards and the DGE-550T is
> a DL2000-based card. The driver loads and works for a few moments, but
> once a real workload is applied it stops operating. The ipg driver
> claimed this ID since it was introduced in 2.6.24 and it's forced many
> users to blacklist it.
>
> The correct driver for this hardware is the dl2k driver, which has been
> claiming this PCI ID since the 2.4 days.
>
> Signed-off-by: Jeff Mahoney <jeffm@suse.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAkuVZRAACgkQLPWxlyuTD7LlYQCdHUd1KJTaHAmYc+MC822H/3Or
qqEAn31TdDxLMiO4sUUgWtoTGZKCfh1j
=SJDe
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH RESEND #2] ipg: Remove device claimed by dl2k from pci id table
From: David Miller @ 2010-03-08 20:57 UTC (permalink / raw)
To: jeffm; +Cc: romieu, sorbica, netdev
In-Reply-To: <4B9563B6.9070803@suse.com>
From: Jeff Mahoney <jeffm@suse.com>
Date: Mon, 08 Mar 2010 15:53:10 -0500
> ipg: Remove device claimed by dl2k from pci id table
>
> This patch removes D-Link DGE-550T PCI ID (1186:4000) from the ipg
> driver. The ipg driver is for IP2000-based cards and the DGE-550T is
> a DL2000-based card. The driver loads and works for a few moments, but
> once a real workload is applied it stops operating. The ipg driver
> claimed this ID since it was introduced in 2.6.24 and it's forced many
> users to blacklist it.
>
> The correct driver for this hardware is the dl2k driver, which has been
> claiming this PCI ID since the 2.4 days.
>
> Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Please stop re-submitting this, it's already in the tree:
commit 25cca5352712561fba97bd37c495593d641c1d39
Author: Jeff Mahoney <jeffm@suse.com>
Date: Thu Feb 11 10:26:38 2010 +0000
ipg: Remove device claimed by dl2k from pci id table
This patch removes D-Link DGE-550T PCI ID (1186:4000) from the ipg
driver. The ipg driver is for IP2000-based cards and the DGE-550T is
a DL2000-based card. The driver loads and works for a few moments, but
once a real workload is applied it stops operating. The ipg driver
claimed this ID since it was introduced in 2.6.24 and it's forced many
users to blacklist it.
The correct driver for this hardware is the dl2k driver, which has been
claiming this PCI ID since the 2.4 days.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] tipc: fix endianness on tipc subscriber messages
From: David Miller @ 2010-03-08 20:54 UTC (permalink / raw)
To: allan.stephens; +Cc: nhorman, netdev
In-Reply-To: <29C1DC0826876849BDD9F1C67ABA29430728D116@ala-mail09.corp.ad.wrs.com>
From: "Stephens, Allan" <allan.stephens@windriver.com>
Date: Mon, 8 Mar 2010 12:48:38 -0800
> Secondly, I would have expected this patch to be applied to
> net-next-2.6, since the functionality being changed here (at least
> the first part of it) is more like a feature enhancement than a bug
> fix.
It fixes a bug so I'm going to apply it.
You can't disappear from maintaining this shinking ship for years then
complain about people who are actually working to get upstream back
into shape.
^ permalink raw reply
* [PATCH RESEND #2] ipg: Remove device claimed by dl2k from pci id table
From: Jeff Mahoney @ 2010-03-08 20:53 UTC (permalink / raw)
To: Francois Romieu, Sorbica Shieh; +Cc: Network Development
Hi all -
This is a re-send of a patch I sent out nearly a month ago but didn't
get a response[2]. Re-sent without the GPG signing bit.
I've seen this report a bunch of times but google didn't point to any
resolution. I'm not really involved with network driver development, so
I'm hoping that someone who knows the history here can speak up.
I have a report[1] where the D-Link DGE-550T is being associated with the
ipg driver. It works for a very short amount of time and then fails.
Unloading the driver and loading dl2k instead results in a working
system. The DGE-550T is a DL2000 based card, but the ipg (IP1000)
driver is claiming it and has been since the driver was added to the
kernel in 2.6.24. dl2k has been claiming this ID since the 2.4 days.
Which driver is correct? Can we remove the PCI IDs associated with the
wrong driver? Users keep working around this with module blacklisting
but they shouldn't have to.
Thanks.
-Jeff
[1] https://bugzilla.novell.com/show_bug.cgi?id=579219
[2] http://marc.info/?l=linux-netdev&m=126592001219784&w=2
---
ipg: Remove device claimed by dl2k from pci id table
This patch removes D-Link DGE-550T PCI ID (1186:4000) from the ipg
driver. The ipg driver is for IP2000-based cards and the DGE-550T is
a DL2000-based card. The driver loads and works for a few moments, but
once a real workload is applied it stops operating. The ipg driver
claimed this ID since it was introduced in 2.6.24 and it's forced many
users to blacklist it.
The correct driver for this hardware is the dl2k driver, which has been
claiming this PCI ID since the 2.4 days.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
---
drivers/net/ipg.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/net/ipg.c
+++ b/drivers/net/ipg.c
@@ -88,7 +88,6 @@ static const char *ipg_brand_name[] = {
"Sundance Technology ST2021 based NIC",
"Tamarack Microelectronics TC9020/9021 based NIC",
"Tamarack Microelectronics TC9020/9021 based NIC",
- "D-Link NIC",
"D-Link NIC IP1000A"
};
@@ -97,8 +96,7 @@ static struct pci_device_id ipg_pci_tbl[
{ PCI_VDEVICE(SUNDANCE, 0x2021), 1 },
{ PCI_VDEVICE(SUNDANCE, 0x1021), 2 },
{ PCI_VDEVICE(DLINK, 0x9021), 3 },
- { PCI_VDEVICE(DLINK, 0x4000), 4 },
- { PCI_VDEVICE(DLINK, 0x4020), 5 },
+ { PCI_VDEVICE(DLINK, 0x4020), 4 },
{ 0, }
};
--
Jeff Mahoney
SUSE Labs
^ permalink raw reply
* Re: [PATCH RESEND] ipg: Remove device claimed by dl2k from pci id table
From: David Miller @ 2010-03-08 20:52 UTC (permalink / raw)
To: jeffm; +Cc: romieu, sorbica, jesse, netdev
In-Reply-To: <4B956283.3000007@suse.com>
From: Jeff Mahoney <jeffm@suse.com>
Date: Mon, 08 Mar 2010 15:48:03 -0500
> @@ -88,7 +88,6 @@ static const char *ipg_brand_name[] = {
> "Sundance Technology ST2021 based NIC",
> "Tamarack Microelectronics TC9020/9021 based NIC",
> "Tamarack Microelectronics TC9020/9021 based NIC",
> - - "D-Link NIC",
> "D-Link NIC IP1000A"
> };
> @@ -97,8 +96,7 @@ static struct pci_device_id ipg_pci_tbl[
> { PCI_VDEVICE(SUNDANCE, 0x2021), 1 },
> { PCI_VDEVICE(SUNDANCE, 0x1021), 2 },
> { PCI_VDEVICE(DLINK, 0x9021), 3 },
> - - { PCI_VDEVICE(DLINK, 0x4000), 4 },
> - - { PCI_VDEVICE(DLINK, 0x4020), 5 },
> + { PCI_VDEVICE(DLINK, 0x4020), 4 },
Your patch is severely corrupted. Please fix this up and
resubmit.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: add netdev to CAN network layer and drivers entries
From: David Miller @ 2010-03-08 20:51 UTC (permalink / raw)
To: wg; +Cc: netdev, socketcan-core, oliver
In-Reply-To: <4B95623F.7010704@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Mon, 08 Mar 2010 21:46:55 +0100
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Applied, thanks Wolfgang.
^ permalink raw reply
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode (v2)
From: Neil Horman @ 2010-03-08 20:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jon.maloy, allan.stephens, tipc-discussion
In-Reply-To: <20100308.121942.67584963.davem@davemloft.net>
On Mon, Mar 08, 2010 at 12:19:42PM -0800, David Miller wrote:
>
> Doesn't apply to net-2.6, Neil please respin.
>
Will do. I'll repost in a few hours
Neil
^ permalink raw reply
* RE: [PATCH] tipc: fix endianness on tipc subscriber messages
From: Stephens, Allan @ 2010-03-08 20:48 UTC (permalink / raw)
To: Neil Horman, davem; +Cc: netdev
In-Reply-To: <20100308200315.GE23634@hmsreliant.think-freely.org>
Hi there:
There are a couple of problems with this patch that need to be resolved
before it can be applied to the upstream kernel.
1) Neil's replacement of the htohl() call with the equivalent
htonl()/ntohl() calls, while well intentioned, was done without
understanding why the htohl() calls were put there in the first place.
In addition, the TIPC specification that he used to justify some of his
decisions is out-dated, and doesn't reflect the latest version of the
TIPC protocol. (I'll discuss this further in a follow-up email.)
2) Neil's alteration of the memcpy() in the subscription cancelation
routine is simply wrong. The pieces of the data structure that he
claims are local are not local, and must be checked to ensure that the
cancellation is done properly.
I'm also surprised to see that this patch was immediately applied to
net-2.6. First, there was no opportunity given for people to comment on
the patch. Secondly, I would have expected this patch to be applied to
net-next-2.6, since the functionality being changed here (at least the
first part of it) is more like a feature enhancement than a bug fix. Am
I misunderstanding the process being followed here? If so, please
explain ...
Regards,
Al
> -----Original Message-----
> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> Sent: Monday, March 08, 2010 3:03 PM
> To: netdev@vger.kernel.org
> Cc: Stephens, Allan; davem@davemloft.net; nhorman@tuxdriver.com
> Subject: [PATCH] tipc: fix endianness on tipc subscriber messages
>
> Remove htohl implementation from tipc
>
> I was working on forward porting the downstream commits for
> TIPC and ran accross this one:
> http://tipc.cslab.ericsson.net/cgi-bin/gitweb.cgi?p=people/all
> an/tipc.git;a=commitdiff;h=894279b9437b63cbb02405ad5b8e033b51e4e31e
>
> I was going to just take it, when I looked closer and noted
> what it was doing.
> This is basically a routine to byte swap fields of data in
> sent/received packets for tipc, dependent upon the receivers
> guessed endianness of the peer when a connection is
> established. Asside from just seeming silly to me, it
> appears to violate the latest RFC draft for tipc:
> http://tipc.sourceforge.net/doc/draft-spec-tipc-02.txt
> Which, according to section 4.2 and 4.3.3, requires that all
> fields of all commands be sent in network byte order. So
> instead of just taking this patch, instead I'm removing the
> htohl function and replacing the calls with calls to ntohl in
> the rx path and htonl in the send path.
>
> As part of this fix, I'm also changing the subscr_cancel
> function, which searches the list of subscribers, using a
> memcmp of the entire subscriber list, for the entry to tear
> down. unfortunately it memcmps the entire tipc_subscr
> structure which has several bits that are private to the
> local side, so nothing will ever match. section 5.2 of the
> draft spec indicates the <type,upper,lower> tuple should
> uniquely identify a subscriber, so convert subscr_cancel to
> just match on those fields (properly endian swapped).
>
> I've tested this using the tipc test suite, and its passed
> without issue.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: Allan Stephens <allan.stephens@windriver.com>
>
>
> subscr.c | 57
> ++++++++++++++++++++++-----------------------------------
> subscr.h | 2 --
> 2 files changed, 22 insertions(+), 37 deletions(-)
>
> diff --git a/net/tipc/subscr.c b/net/tipc/subscr.c index
> ac91f0d..ff123e5 100644
> --- a/net/tipc/subscr.c
> +++ b/net/tipc/subscr.c
> @@ -76,19 +76,6 @@ struct top_srv {
> static struct top_srv topsrv = { 0 };
>
> /**
> - * htohl - convert value to endianness used by destination
> - * @in: value to convert
> - * @swap: non-zero if endianness must be reversed
> - *
> - * Returns converted value
> - */
> -
> -static u32 htohl(u32 in, int swap)
> -{
> - return swap ? swab32(in) : in;
> -}
> -
> -/**
> * subscr_send_event - send a message containing a
> tipc_event to the subscriber
> *
> * Note: Must not hold subscriber's server port lock, since
> tipc_send() will @@ -107,11 +94,11 @@ static void
> subscr_send_event(struct subscription *sub,
> msg_sect.iov_base = (void *)&sub->evt;
> msg_sect.iov_len = sizeof(struct tipc_event);
>
> - sub->evt.event = htohl(event, sub->swap);
> - sub->evt.found_lower = htohl(found_lower, sub->swap);
> - sub->evt.found_upper = htohl(found_upper, sub->swap);
> - sub->evt.port.ref = htohl(port_ref, sub->swap);
> - sub->evt.port.node = htohl(node, sub->swap);
> + sub->evt.event = htonl(event);
> + sub->evt.found_lower = htonl(found_lower);
> + sub->evt.found_upper = htonl(found_upper);
> + sub->evt.port.ref = htonl(port_ref);
> + sub->evt.port.node = htonl(node);
> tipc_send(sub->server_ref, 1, &msg_sect); }
>
> @@ -287,16 +274,23 @@ static void subscr_cancel(struct
> tipc_subscr *s, {
> struct subscription *sub;
> struct subscription *sub_temp;
> + __u32 type, lower, upper;
> int found = 0;
>
> /* Find first matching subscription, exit if not found */
>
> + type = ntohl(s->seq.type);
> + lower = ntohl(s->seq.lower);
> + upper = ntohl(s->seq.upper);
> +
> list_for_each_entry_safe(sub, sub_temp,
> &subscriber->subscription_list,
> subscription_list) {
> - if (!memcmp(s, &sub->evt.s, sizeof(struct
> tipc_subscr))) {
> - found = 1;
> - break;
> - }
> + if ((type == sub->seq.type) &&
> + (lower == sub->seq.lower) &&
> + (upper == sub->seq.upper)) {
> + found = 1;
> + break;
> + }
> }
> if (!found)
> return;
> @@ -325,16 +319,10 @@ static struct subscription
> *subscr_subscribe(struct tipc_subscr *s,
> struct subscriber
> *subscriber) {
> struct subscription *sub;
> - int swap;
> -
> - /* Determine subscriber's endianness */
> -
> - swap = !(s->filter & (TIPC_SUB_PORTS | TIPC_SUB_SERVICE));
>
> /* Detect & process a subscription cancellation request */
>
> - if (s->filter & htohl(TIPC_SUB_CANCEL, swap)) {
> - s->filter &= ~htohl(TIPC_SUB_CANCEL, swap);
> + if (ntohl(s->filter) & TIPC_SUB_CANCEL) {
> subscr_cancel(s, subscriber);
> return NULL;
> }
> @@ -359,11 +347,11 @@ static struct subscription
> *subscr_subscribe(struct tipc_subscr *s,
>
> /* Initialize subscription object */
>
> - sub->seq.type = htohl(s->seq.type, swap);
> - sub->seq.lower = htohl(s->seq.lower, swap);
> - sub->seq.upper = htohl(s->seq.upper, swap);
> - sub->timeout = htohl(s->timeout, swap);
> - sub->filter = htohl(s->filter, swap);
> + sub->seq.type = ntohl(s->seq.type);
> + sub->seq.lower = ntohl(s->seq.lower);
> + sub->seq.upper = ntohl(s->seq.upper);
> + sub->timeout = ntohl(s->timeout);
> + sub->filter = ntohl(s->filter);
> if ((!(sub->filter & TIPC_SUB_PORTS) ==
> !(sub->filter & TIPC_SUB_SERVICE)) ||
> (sub->seq.lower > sub->seq.upper)) { @@ -376,7
> +364,6 @@ static struct subscription *subscr_subscribe(struct
> tipc_subscr *s,
> INIT_LIST_HEAD(&sub->nameseq_list);
> list_add(&sub->subscription_list,
> &subscriber->subscription_list);
> sub->server_ref = subscriber->port_ref;
> - sub->swap = swap;
> memcpy(&sub->evt.s, s, sizeof(struct tipc_subscr));
> atomic_inc(&topsrv.subscription_count);
> if (sub->timeout != TIPC_WAIT_FOREVER) { diff --git
> a/net/tipc/subscr.h b/net/tipc/subscr.h index 45d89bf..c20f496 100644
> --- a/net/tipc/subscr.h
> +++ b/net/tipc/subscr.h
> @@ -53,7 +53,6 @@ typedef void (*tipc_subscr_event) (struct
> subscription *sub,
> * @nameseq_list: adjacent subscriptions in name sequence's
> subscription list
> * @subscription_list: adjacent subscriptions in
> subscriber's subscription list
> * @server_ref: object reference of server port associated
> with subscription
> - * @swap: indicates if subscriber uses opposite endianness
> in its messages
> * @evt: template for events generated by subscription
> */
>
> @@ -66,7 +65,6 @@ struct subscription {
> struct list_head nameseq_list;
> struct list_head subscription_list;
> u32 server_ref;
> - int swap;
> struct tipc_event evt;
> };
>
>
^ permalink raw reply
* Re: uninterruptible sleep in unix_dgram_recvmsg
From: David Miller @ 2010-03-08 20:48 UTC (permalink / raw)
To: mschmidt; +Cc: netdev
In-Reply-To: <20100304184114.62881b21@leela>
From: Michal Schmidt <mschmidt@redhat.com>
Date: Thu, 4 Mar 2010 18:41:14 +0100
> So instead of that I started to think about why u->readlock is held
> across skb_recv_datagram() anyway. I found that it was added in 2.6.10
> by your patch "[AF_UNIX]: Serialize dgram read using semaphore just
> like stream" which apparently fixed an exploitable race condition
> (CAN-2004-1068).
>
> I don't know what exactly u->readlock protects here.
> IOW, what race would this patch cause?:
Unfortunately I can't find any discussions about that change
and I can't find my own personal email archives from that far
back.
This is what irks me about handling security issues off-list
and in private.
In any event, I'm pretty sure we need to protect the dequeue
of SKBs from the datagram recv_queue with that mutex. So
I'm weary to apply your patch.
Can you find a way to fix this without moving the SKB
dequeue outside of the lock?
Thanks.
^ permalink raw reply
* [PATCH] MAINTAINERS: add netdev to CAN network layer and drivers entries
From: Wolfgang Grandegger @ 2010-03-08 20:46 UTC (permalink / raw)
To: Linux Netdev List
Cc: SocketCAN Core Mailing List, David Miller, Oliver Hartkopp
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 66418dd..c685ee2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1376,6 +1376,7 @@ M: Oliver Hartkopp <socketcan@hartkopp.net>
M: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
M: Urs Thuermann <urs.thuermann@volkswagen.de>
L: socketcan-core@lists.berlios.de
+L: netdev@vger.kernel.org
W: http://developer.berlios.de/projects/socketcan/
S: Maintained
F: net/can/
@@ -1387,6 +1388,7 @@ F: include/linux/can/raw.h
CAN NETWORK DRIVERS
M: Wolfgang Grandegger <wg@grandegger.com>
L: socketcan-core@lists.berlios.de
+L: netdev@vger.kernel.org
W: http://developer.berlios.de/projects/socketcan/
S: Maintained
F: drivers/net/can/
^ permalink raw reply related
* [PATCH RESEND] ipg: Remove device claimed by dl2k from pci id table
From: Jeff Mahoney @ 2010-03-08 20:48 UTC (permalink / raw)
To: Francois Romieu, Sorbica Shieh, Jesse Huang; +Cc: Network Development
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all -
This is a re-send of a patch I sent out nearly a month ago but didn't
get a response[2].
I've seen this report a bunch of times but google didn't point to any
resolution. I'm not really involved with network driver development, so
I'm hoping that someone who knows the history here can speak up.
I have a report[1] where the D-Link DGE-550T is being associated with the
ipg driver. It works for a very short amount of time and then fails.
Unloading the driver and loading dl2k instead results in a working
system. The DGE-550T is a DL2000 based card, but the ipg (IP1000)
driver is claiming it and has been since the driver was added to the
kernel in 2.6.24. dl2k has been claiming this ID since the 2.4 days.
Which driver is correct? Can we remove the PCI IDs associated with the
wrong driver? Users keep working around this with module blacklisting
but they shouldn't have to.
Thanks.
- -Jeff
[1] https://bugzilla.novell.com/show_bug.cgi?id=579219
[2] http://marc.info/?l=linux-netdev&m=126592001219784&w=2
- ---
ipg: Remove device claimed by dl2k from pci id table
This patch removes D-Link DGE-550T PCI ID (1186:4000) from the ipg
driver. The ipg driver is for IP2000-based cards and the DGE-550T is
a DL2000-based card. The driver loads and works for a few moments, but
once a real workload is applied it stops operating. The ipg driver
claimed this ID since it was introduced in 2.6.24 and it's forced many
users to blacklist it.
The correct driver for this hardware is the dl2k driver, which has been
claiming this PCI ID since the 2.4 days.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
- ---
drivers/net/ipg.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
- --- a/drivers/net/ipg.c
+++ b/drivers/net/ipg.c
@@ -88,7 +88,6 @@ static const char *ipg_brand_name[] = {
"Sundance Technology ST2021 based NIC",
"Tamarack Microelectronics TC9020/9021 based NIC",
"Tamarack Microelectronics TC9020/9021 based NIC",
- - "D-Link NIC",
"D-Link NIC IP1000A"
};
@@ -97,8 +96,7 @@ static struct pci_device_id ipg_pci_tbl[
{ PCI_VDEVICE(SUNDANCE, 0x2021), 1 },
{ PCI_VDEVICE(SUNDANCE, 0x1021), 2 },
{ PCI_VDEVICE(DLINK, 0x9021), 3 },
- - { PCI_VDEVICE(DLINK, 0x4000), 4 },
- - { PCI_VDEVICE(DLINK, 0x4020), 5 },
+ { PCI_VDEVICE(DLINK, 0x4020), 4 },
{ 0, }
};
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAkuVYoMACgkQLPWxlyuTD7LGZwCcCjktCbVANOJcnT20Hn7FRvWf
WmcAn3fFOMOIZnwtehy0njdy0Bc+i4ge
=2rTZ
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.
From: Eric W. Biederman @ 2010-03-08 20:47 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Pavel Emelyanov, Sukadev Bhattiprolu, Serge Hallyn,
Linux Netdev List, containers, Netfilter Development Mailinglist,
Ben Greear
In-Reply-To: <4B95611C.5060403@free.fr>
Daniel Lezcano <daniel.lezcano@free.fr> writes:
> Eric W. Biederman wrote:
>> Daniel Lezcano <daniel.lezcano@free.fr> writes:
>>
>>
>>> Eric W. Biederman wrote:
>>>
>>>> Daniel Lezcano <daniel.lezcano@free.fr> writes:
>>>>
>>>>
>>>>> Eric W. Biederman wrote:
>>>>>
>>>>>> I have take an snapshot of my development tree and placed it at.
>>>>>>
>>>>>>
>>>>>> git://git.kernel.org/pub/scm/linux/people/ebiederm/linux-2.6.33-nsfd-v5.git
>>>>>>
>>>>> Hi Eric,
>>>>>
>>>>> thanks for the pointer.
>>>>>
>>>>> I tried to boot the kernel under qemu and I got this oops:
>>>>>
>>>> I am clearly running an old userspace on my test machine. No udev.
>>>> It looks like udev has a long standing netlink misfeature, where
>>>> it does not initializing NETLINK_CB....
>>>>
>>>>
>>>> >From 8d85e3ab88718eda3d94cf8e1be14b69dae2b8f1 Mon Sep 17 00:00:00 2001
>>>> From: Eric W. Biederman <ebiederm@xmission.com>
>>>> Date: Mon, 8 Mar 2010 09:25:20 -0800
>>>> Subject: [PATCH] kobject_uevent: Use the netlink allocator helper...
>>>>
>>>> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>>>>
>>> Thanks.
>>>
>>> I was able to boot but I have the following warning:
>>>
>>
>> Thanks for the bug report.
>>
> Thanks to you for the patchset :)
>
>> For the moment you might want to drop:
>> af_netlink: Allow credentials to work across namespaces.
>> af_netlink: Debugging in case I have missed something.
>>
>> Although I am curious if you hit my debugging messages in
>> netlink recv.
>>
> No, it does not appear (looked for "missing NETLINK_CB proto").
>
>> I guess if the goal is to test my nsfd bits you can drop everything
>> starting with my 'scm: Reorder scm_cookie.' commit. The rest is what
>> it takes to get get uids, gid and pids translated when the cross
>> namespaces on an af_unix of an af_netlink socket.
>>
>> At least in the af_netlink case it appears clear I am have missed
>> something.
>>
>> This is a warning that netlink throws when the packet accounting messed
>> up. So it sounds like you are exercising another path that I failed
>> to exercise and fix.
>>
> I will look forward if I find more clues for this warning.
>
> In the meantime was able to enter the container with the ugly following
> program:
>
> #include <unistd.h>
> #include <stdlib.h>
> #include <stdio.h>
> #include <syscall.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <sys/param.h>
>
> #define __NR_setns 300
>
> int setns(int nstype, int fd)
> {
> return syscall (__NR_setns, nstype, fd);
> }
>
> int main(int argc, char *argv[])
> {
> char path[MAXPATHLEN];
> char *ns[] = { "pid", "mnt", "net", "pid", "uts" };
> const int size = sizeof(ns) / sizeof(char *);
> int fd[size];
> int i;
>
> if (argc != 3) {
> fprintf(stderr, "mynsenter <pid> <command>\n");
> exit(1);
> }
>
> for (i = 0; i < size; i++) {
> sprintf(path, "/proc/%s/ns/%s", argv[1], ns[i]);
>
> fd[i] = open(path, O_RDONLY);
> if (fd[i] < 0) {
> perror("open");
> return -1;
> }
>
> }
>
> for (i = 0; i < size; i++) {
>
> if (setns(0, fd[i])) {
> perror("setns");
> return -1;
> }
> }
>
> execve(argv[2], &argv[2], NULL);
> perror("execve");
>
> return 0;
> }
>
> At the fist glance, no problem :)
No fork() so your processes is completely in the pid namespace?
Eric
^ permalink raw reply
* Re: [PATCH] tipc: filter out messages not intended for this host
From: David Miller @ 2010-03-08 20:44 UTC (permalink / raw)
To: nhorman; +Cc: netdev, allan.stephens
In-Reply-To: <20100308203924.GF23634@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Mon, 8 Mar 2010 15:39:24 -0500
> Apologies, heres the repost, whitespace fixed
Applied, thanks Neil.
^ permalink raw reply
* Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.
From: Daniel Lezcano @ 2010-03-08 20:42 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Pavel Emelyanov, Sukadev Bhattiprolu, Serge Hallyn,
Linux Netdev List, containers, Netfilter Development Mailinglist,
Ben Greear
In-Reply-To: <m11vfusgsa.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> Daniel Lezcano <daniel.lezcano@free.fr> writes:
>
>
>> Eric W. Biederman wrote:
>>
>>> Daniel Lezcano <daniel.lezcano@free.fr> writes:
>>>
>>>
>>>
>>>> Eric W. Biederman wrote:
>>>>
>>>>
>>>>> I have take an snapshot of my development tree and placed it at.
>>>>>
>>>>>
>>>>> git://git.kernel.org/pub/scm/linux/people/ebiederm/linux-2.6.33-nsfd-v5.git
>>>>>
>>>>>
>>>> Hi Eric,
>>>>
>>>> thanks for the pointer.
>>>>
>>>> I tried to boot the kernel under qemu and I got this oops:
>>>>
>>>>
>>> I am clearly running an old userspace on my test machine. No udev.
>>> It looks like udev has a long standing netlink misfeature, where
>>> it does not initializing NETLINK_CB....
>>>
>>>
>>> >From 8d85e3ab88718eda3d94cf8e1be14b69dae2b8f1 Mon Sep 17 00:00:00 2001
>>> From: Eric W. Biederman <ebiederm@xmission.com>
>>> Date: Mon, 8 Mar 2010 09:25:20 -0800
>>> Subject: [PATCH] kobject_uevent: Use the netlink allocator helper...
>>>
>>> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>>>
>>>
>> Thanks.
>>
>> I was able to boot but I have the following warning:
>>
>
> Thanks for the bug report.
>
Thanks to you for the patchset :)
> For the moment you might want to drop:
> af_netlink: Allow credentials to work across namespaces.
> af_netlink: Debugging in case I have missed something.
>
> Although I am curious if you hit my debugging messages in
> netlink recv.
>
No, it does not appear (looked for "missing NETLINK_CB proto").
> I guess if the goal is to test my nsfd bits you can drop everything
> starting with my 'scm: Reorder scm_cookie.' commit. The rest is what
> it takes to get get uids, gid and pids translated when the cross
> namespaces on an af_unix of an af_netlink socket.
>
> At least in the af_netlink case it appears clear I am have missed
> something.
>
> This is a warning that netlink throws when the packet accounting messed
> up. So it sounds like you are exercising another path that I failed
> to exercise and fix.
>
I will look forward if I find more clues for this warning.
In the meantime was able to enter the container with the ugly following
program:
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <syscall.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/param.h>
#define __NR_setns 300
int setns(int nstype, int fd)
{
return syscall (__NR_setns, nstype, fd);
}
int main(int argc, char *argv[])
{
char path[MAXPATHLEN];
char *ns[] = { "pid", "mnt", "net", "pid", "uts" };
const int size = sizeof(ns) / sizeof(char *);
int fd[size];
int i;
if (argc != 3) {
fprintf(stderr, "mynsenter <pid> <command>\n");
exit(1);
}
for (i = 0; i < size; i++) {
sprintf(path, "/proc/%s/ns/%s", argv[1], ns[i]);
fd[i] = open(path, O_RDONLY);
if (fd[i] < 0) {
perror("open");
return -1;
}
}
for (i = 0; i < size; i++) {
if (setns(0, fd[i])) {
perror("setns");
return -1;
}
}
execve(argv[2], &argv[2], NULL);
perror("execve");
return 0;
}
At the fist glance, no problem :)
^ permalink raw reply
* Re: [PATCH] tipc: filter out messages not intended for this host
From: Neil Horman @ 2010-03-08 20:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev, allan.stephens
In-Reply-To: <20100308.122030.112176481.davem@davemloft.net>
On Mon, Mar 08, 2010 at 12:20:30PM -0800, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Mon, 8 Mar 2010 14:41:49 -0500
>
> > Port commit 20deb48d16fdd07ce2fdc8d03ea317362217e085
> > from git://tipc.cslab.ericsson.net/pub/git/people/allan/tipc.git
> >
> > Part of the larger effort I'm trying to help with getting all the downstreamed
> > code from windriver forward ported to the upstream tree
> >
> > Origional commit message
> > Restore check to filter out inadverdently received messages
> > This patch reimplements a check that allows TIPC to discard messages
> > that are not intended for it. This check was present in TIPC 1.5/1.6,
> > but was removed by accident during the development of TIPC 1.7; it has
> > now been updated to account for new features present in TIPC 1.7 and
> > reinserted into TIPC. The main benefit of this check is to filter
> > out messages arriving from orphaned link endpoints, which can arise
> > when a node exits the network and then re-enters it with a different
> > TIPC network address (i.e. <Z.C.N> value).
> >
> > tested with the tipc sanity test suite.
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > Origionally-authored-by: Allan Stephens <allan.stephens@windriver.com>
>
> Adds trailing whitespace, please fix:
>
> davem@sunset:~/src/GIT/net-2.6$ pcheck diff
> + git apply --check --whitespace=error-all diff
> diff:11: trailing whitespace.
> if (unlikely(!msg_isdata(msg) &&
> fatal: 1 line adds whitespace errors.
>
>
Apologies, heres the repost, whitespace fixed
Port commit 20deb48d16fdd07ce2fdc8d03ea317362217e085
from git://tipc.cslab.ericsson.net/pub/git/people/allan/tipc.git
Part of the large effort I'm trying to help with getting all the downstreamed
code from windriver forward ported to the upstream tree
Origional commit message
Restore check to filter out inadverdently received messages
This patch reimplements a check that allows TIPC to discard messages
that are not intended for it. This check was present in TIPC 1.5/1.6,
but was removed by accident during the development of TIPC 1.7; it has
now been updated to account for new features present in TIPC 1.7 and
reinserted into TIPC. The main benefit of this check is to filter
out messages arriving from orphaned link endpoints, which can arise
when a node exits the network and then re-enters it with a different
TIPC network address (i.e. <Z.C.N> value).
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Origionally-authored-by: Allan Stephens <allan.stephens@windriver.com>
link.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 6f50f64..da3a384 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1882,6 +1882,15 @@ void tipc_recv_msg(struct sk_buff *head, struct tipc_bearer *tb_ptr)
(msg_destnode(msg) != tipc_own_addr)))
goto cont;
+ /* Discard non-routeable messages destined for another node */
+
+ if (unlikely(!msg_isdata(msg) &&
+ (msg_destnode(msg) != tipc_own_addr))) {
+ if ((msg_user(msg) != CONN_MANAGER) &&
+ (msg_user(msg) != MSG_FRAGMENTER))
+ goto cont;
+ }
+
/* Locate unicast link endpoint that should handle message */
n_ptr = tipc_node_find(msg_prevnode(msg));
^ permalink raw reply related
* Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.
From: Eric W. Biederman @ 2010-03-08 20:24 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Pavel Emelyanov, Sukadev Bhattiprolu, Serge Hallyn,
Linux Netdev List, containers, Netfilter Development Mailinglist,
Ben Greear
In-Reply-To: <4B9556A9.60206@free.fr>
Daniel Lezcano <daniel.lezcano@free.fr> writes:
> Eric W. Biederman wrote:
>> Daniel Lezcano <daniel.lezcano@free.fr> writes:
>>
>>
>>> Eric W. Biederman wrote:
>>>
>>>> I have take an snapshot of my development tree and placed it at.
>>>>
>>>>
>>>> git://git.kernel.org/pub/scm/linux/people/ebiederm/linux-2.6.33-nsfd-v5.git
>>>>
>>> Hi Eric,
>>>
>>> thanks for the pointer.
>>>
>>> I tried to boot the kernel under qemu and I got this oops:
>>>
>>
>> I am clearly running an old userspace on my test machine. No udev.
>> It looks like udev has a long standing netlink misfeature, where
>> it does not initializing NETLINK_CB....
>>
>>
>> >From 8d85e3ab88718eda3d94cf8e1be14b69dae2b8f1 Mon Sep 17 00:00:00 2001
>> From: Eric W. Biederman <ebiederm@xmission.com>
>> Date: Mon, 8 Mar 2010 09:25:20 -0800
>> Subject: [PATCH] kobject_uevent: Use the netlink allocator helper...
>>
>> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>>
> Thanks.
>
> I was able to boot but I have the following warning:
Thanks for the bug report.
For the moment you might want to drop:
af_netlink: Allow credentials to work across namespaces.
af_netlink: Debugging in case I have missed something.
Although I am curious if you hit my debugging messages in
netlink recv.
I guess if the goal is to test my nsfd bits you can drop everything
starting with my 'scm: Reorder scm_cookie.' commit. The rest is what
it takes to get get uids, gid and pids translated when the cross
namespaces on an af_unix of an af_netlink socket.
At least in the af_netlink case it appears clear I am have missed
something.
This is a warning that netlink throws when the packet accounting messed
up. So it sounds like you are exercising another path that I failed
to exercise and fix.
> ------------[ cut here ]------------
> WARNING: at net/netlink/af_netlink.c:198 netlink_sock_destruct+0x72/0xac()
> Hardware name:
> Modules linked in: [last unloaded: scsi_wait_scan]
> Pid: 840, comm: nash-hotplug Tainted: G W 2.6.33 #2
> Call Trace:
> [<ffffffff812df182>] ? netlink_sock_destruct+0x72/0xac
> [<ffffffff8102ca29>] warn_slowpath_common+0x77/0xa4
> [<ffffffff8102ca65>] warn_slowpath_null+0xf/0x11
> [<ffffffff812df182>] netlink_sock_destruct+0x72/0xac
> [<ffffffff812bb2a4>] __sk_free+0x1e/0x118
> [<ffffffff812bb40d>] sk_free+0x19/0x1b
> [<ffffffff812e0dc2>] netlink_release+0x246/0x253
> [<ffffffff812b825a>] sock_release+0x1a/0x6b
> [<ffffffff812b82cd>] sock_close+0x22/0x26
> [<ffffffff810c7823>] __fput+0x11b/0x1d7
> [<ffffffff810c78f6>] fput+0x17/0x19
> [<ffffffff810c4ae2>] filp_close+0x67/0x72
> [<ffffffff8102e75c>] put_files_struct+0x6a/0xd4
> [<ffffffff8102e80d>] exit_files+0x47/0x4f
> [<ffffffff8102fe59>] do_exit+0x1eb/0x693
> [<ffffffff813864c2>] ? _raw_spin_unlock_irq+0x2b/0x31
> [<ffffffff81030373>] do_group_exit+0x72/0x9b
> [<ffffffff8103f37c>] get_signal_to_deliver+0x3a1/0x3c1
> [<ffffffff81001e8e>] do_notify_resume+0x8d/0x6ea
> [<ffffffff810538c9>] ? trace_hardirqs_on_caller+0x110/0x13a
> [<ffffffff8102851e>] ? finish_task_switch+0x6a/0xb3
> [<ffffffff810284b4>] ? finish_task_switch+0x0/0xb3
> [<ffffffff813867aa>] ? retint_signal+0x11/0x87
> [<ffffffff810538c9>] ? trace_hardirqs_on_caller+0x110/0x13a
> [<ffffffff813867df>] retint_signal+0x46/0x87
> ---[ end trace d4a1e4cbaa70d63d ]---
>
>
> And I have a kernel panic when exiting a network namespace using a macvlan:
I wonder/hope this is simply the result of corruption from earlier problems.
I haven't touched anything that should affect the macvlan driver in 2.6.33.
> linux-swk0 login: BUG: unable to handle kernel paging request at
> ffff880035475678
> IP: [<ffffffff8128dbef>] macvlan_stop+0x54/0x7a
> PGD 160b063 PUD 160f063 PMD 2aa067 PTE 35475160
> Oops: 0002 [#1] DEBUG_PAGEALLOC
> last sysfs file: /sys/devices/pci0000:00/0000:00:03.0/net/eth0/flags
> CPU 0
> Pid: 10, comm: netns Tainted: G W 2.6.33 #2 /
> RIP: 0010:[<ffffffff8128dbef>] [<ffffffff8128dbef>] macvlan_stop+0x54/0x7a
> RSP: 0018:ffff88003f92bc50 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff880035440800 RCX: ffff880035440800
> RDX: ffff880035475678 RSI: ffff88003f913710 RDI: ffff88003cde9800
> RBP: ffff88003f92bc70 R08: 0000000000000004 R09: 0000000000000000
> R10: 0080000000000000 R11: ffff88003f92bbf0 R12: ffff88003cde9800
> R13: ffff880035440de0 R14: 0080000000000000 R15: 0000000800000000
> FS: 0000000000000000(0000) GS:ffffffff8161b000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: ffff880035475678 CR3: 000000003eb41000 CR4: 00000000000006f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process netns (pid: 10, threadinfo ffff88003f92a000, task ffff88003f913058)
> Stack:
> ffffffff814328a0 ffff880035440800 ffffffff814328a0 ffff88003553a800
> <0> ffff88003f92bc90 ffffffff812c9150 ffff880035440800 ffff88003f92bd00
> <0> ffff88003f92bcd0 ffffffff812c9259 ffff88003f92bcd0 ffff88003f92bd00
> Call Trace:
> [<ffffffff812c9150>] dev_close+0x86/0xa8
> [<ffffffff812c9259>] rollback_registered_many+0xe7/0x208
> [<ffffffff812c9390>] unregister_netdevice_many+0x16/0x62
> [<ffffffff812c952d>] default_device_exit_batch+0x9f/0xb3
> [<ffffffff812c3906>] ops_exit_list+0x4e/0x56
> [<ffffffff812c40f4>] cleanup_net+0xfe/0x1b7
> [<ffffffff81042db6>] worker_thread+0x227/0x32d
> [<ffffffff81042d60>] ? worker_thread+0x1d1/0x32d
> [<ffffffff813864c2>] ? _raw_spin_unlock_irq+0x2b/0x31
> [<ffffffff812c3ff6>] ? cleanup_net+0x0/0x1b7
> [<ffffffff810466ae>] ? autoremove_wake_function+0x0/0x38
> [<ffffffff81042b8f>] ? worker_thread+0x0/0x32d
> [<ffffffff810462e0>] kthread+0x7c/0x84
> [<ffffffff810035b4>] kernel_thread_helper+0x4/0x10
> [<ffffffff8138673a>] ? restore_args+0x0/0x30
> [<ffffffff81046264>] ? kthread+0x0/0x84
> [<ffffffff810035b0>] ? kernel_thread_helper+0x0/0x10
> Code: 01 00 00 02 74 0b 83 ce ff 4c 89 e7 e8 a1 8f 03 00 48 8b b3 50 02 00 00 4c
> 89 e7 e8 df 8e 03 00 49 8b 45 18 49 8b 55 20 48 85 c0 <48> 89 02 74 04 48 89 50
> 08 48 be 00 02 20 00 00 00 ad de 49 89
> RIP [<ffffffff8128dbef>] macvlan_stop+0x54/0x7a
> RSP <ffff88003f92bc50>
> CR2: ffff880035475678
> ---[ end trace d4a1e4cbaa70d63e ]---
>
> addr2line -e ./vmlinux ffffffff812c9150 gives net/core/dev.c:1252
Eric
^ permalink raw reply
* Re: [PATCH] socket: Merge getsockname and getpeername into a single function
From: David Miller @ 2010-03-08 20:24 UTC (permalink / raw)
To: kenan; +Cc: netdev
In-Reply-To: <20100304032612.GB9016@home.unix.ba>
From: Kenan Kalajdzic <kenan@unix.ba>
Date: Thu, 4 Mar 2010 04:26:13 +0100
> The code of getsockname is almost identical to getpeername. This patch removes
> duplicate code and merges both functions into a single common function.
>
> Signed-off-by: Kenan Kalajdzic <kenan@unix.ba>
Since you still have to conditionalize things like the security
calls, this doesn't look any cleaner to me than what we have
there already.
I'm not applying this, sorry.
^ 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