* Re: [PATCH] af_unix: unix_write_space() use keyed wakeups
From: Eric Dumazet @ 2010-11-24 0:28 UTC (permalink / raw)
To: Alban Crequy
Cc: Pauli Nieminen, Davide Libenzi, David S. Miller,
Stephen Hemminger, Cyrill Gorcunov, Alexey Dobriyan, netdev,
linux-kernel, Rainer Weikusat
In-Reply-To: <20101124002032.572b7292@chocolatine.cbg.collabora.co.uk>
Le mercredi 24 novembre 2010 à 00:20 +0000, Alban Crequy a écrit :
> Le Wed, 24 Nov 2010 01:27:56 +0200,
> Pauli Nieminen <pauli.nieminen@collabora.co.uk> a écrit :
>
> > ----- Original message -----
> > > Le Sat, 30 Oct 2010 08:44:44 +0200,
> > > Eric Dumazet <eric.dumazet@gmail.com> a écrit :
> > >
> > > > We still loop on 800 items, on each
> > > > wake_up_interruptible_sync_poll() call, so maybe we want to
> > > > optimize this later, adding a global key, ORing all items keys. I
> > > > dont think its worth the added complexity, given the biased usage
> > > > of your program (800 'listeners' to one event). Is it a real life
> > > > scenario ?
> > >
> > > Pauli Nieminen told me about his performance problem in select() so
> > > I wrote the test program but I don't know what exactly is the real
> > > life scenario.
> > >
> >
> > Real world scenario is xsever that has tens client connections to
> > manage. When xserver is happily sleeping at seclect call some client
> > reading events/replies from server triggers in kernel looping over
> > all xserver fds. xserver isn't waiting for socket to became writeable
> > in ussual cases so kernel schedules back to client.
>
> But are they SOCK_STREAM or SOCK_DGRAM sockets? The patches fix
> performances with SOCK_DGRAM. If the xserver scenario is with
> SOCK_STREAM sockets, your problem is probably still unfixed.
>
It should not matter ?
commit 67426b756c4d52c51 (af_unix: use keyed wakeups ) makes
unix_write_space() call wake_up_interruptible_sync_poll() instead of
wake_up_interruptible_sync().
So it should be fixed for both STREAM/DGRAM sockets ?
^ permalink raw reply
* Re: [PATCH] af_unix: unix_write_space() use keyed wakeups
From: Alban Crequy @ 2010-11-24 0:20 UTC (permalink / raw)
To: Pauli Nieminen
Cc: Eric Dumazet, Davide Libenzi, David S. Miller, Stephen Hemminger,
Cyrill Gorcunov, Alexey Dobriyan, netdev, linux-kernel,
Rainer Weikusat
In-Reply-To: <1290554876.2158.5.camel@Nokia-N900-51-1>
Le Wed, 24 Nov 2010 01:27:56 +0200,
Pauli Nieminen <pauli.nieminen@collabora.co.uk> a écrit :
> ----- Original message -----
> > Le Sat, 30 Oct 2010 08:44:44 +0200,
> > Eric Dumazet <eric.dumazet@gmail.com> a écrit :
> >
> > > We still loop on 800 items, on each
> > > wake_up_interruptible_sync_poll() call, so maybe we want to
> > > optimize this later, adding a global key, ORing all items keys. I
> > > dont think its worth the added complexity, given the biased usage
> > > of your program (800 'listeners' to one event). Is it a real life
> > > scenario ?
> >
> > Pauli Nieminen told me about his performance problem in select() so
> > I wrote the test program but I don't know what exactly is the real
> > life scenario.
> >
>
> Real world scenario is xsever that has tens client connections to
> manage. When xserver is happily sleeping at seclect call some client
> reading events/replies from server triggers in kernel looping over
> all xserver fds. xserver isn't waiting for socket to became writeable
> in ussual cases so kernel schedules back to client.
But are they SOCK_STREAM or SOCK_DGRAM sockets? The patches fix
performances with SOCK_DGRAM. If the xserver scenario is with
SOCK_STREAM sockets, your problem is probably still unfixed.
^ permalink raw reply
* [PATCH net-next-2.6] scm: lower SCM_MAX_FD
From: Eric Dumazet @ 2010-11-24 0:09 UTC (permalink / raw)
To: Vegard Nossum, David Miller; +Cc: LKML, Andrew Morton, Eugene Teo, netdev
In-Reply-To: <1290553918.2866.80.camel@edumazet-laptop>
> David, commit f8d570a4 added one "struct list_head list;" to struct
> scm_fp_list, enlarging it by a two factor because of power of two
> kmalloc() sizes. (2048 bytes on 64bit arches instead of 1024
> previously)
>
> We might lower SCM_MAX_FD from 255 to 253 ?
>
>
This wont correct Vegard reported problem yet, but following patch
should reduce ram usage a lot (32 bytes instead of 2048 bytes per scm in
Vegard test program)
Thanks
[PATCH net-next-2.6] net: scm: lower SCM_MAX_FD
Lower SCM_MAX_FD from 255 to 253 so that allocations for scm_fp_list are
halved. (commit f8d570a4 added two pointers in this structure)
scm_fp_dup() should not copy whole structure (and trigger kmemcheck
warnings), but only the used part. While we are at it, only allocate
needed size.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/scm.h | 5 +++--
net/core/scm.c | 10 ++++++----
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/include/net/scm.h b/include/net/scm.h
index 3165650..745460f 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -10,11 +10,12 @@
/* Well, we should have at least one descriptor open
* to accept passed FDs 8)
*/
-#define SCM_MAX_FD 255
+#define SCM_MAX_FD 253
struct scm_fp_list {
struct list_head list;
- int count;
+ short count;
+ short max;
struct file *fp[SCM_MAX_FD];
};
diff --git a/net/core/scm.c b/net/core/scm.c
index 413cab8..bbe4544 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -79,10 +79,11 @@ static int scm_fp_copy(struct cmsghdr *cmsg, struct scm_fp_list **fplp)
return -ENOMEM;
*fplp = fpl;
fpl->count = 0;
+ fpl->max = SCM_MAX_FD;
}
fpp = &fpl->fp[fpl->count];
- if (fpl->count + num > SCM_MAX_FD)
+ if (fpl->count + num > fpl->max)
return -EINVAL;
/*
@@ -331,11 +332,12 @@ struct scm_fp_list *scm_fp_dup(struct scm_fp_list *fpl)
if (!fpl)
return NULL;
- new_fpl = kmalloc(sizeof(*fpl), GFP_KERNEL);
+ new_fpl = kmemdup(fpl, offsetof(struct scm_fp_list, fp[fpl->count]),
+ GFP_KERNEL);
if (new_fpl) {
- for (i=fpl->count-1; i>=0; i--)
+ for (i = 0; i < fpl->count; i++)
get_file(fpl->fp[i]);
- memcpy(new_fpl, fpl, sizeof(*fpl));
+ new_fpl->max = new_fpl->count;
}
return new_fpl;
}
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v3] can: Topcliff: PCH_CAN driver: Add Flow control,
From: Tomoya MORINAGA @ 2010-11-24 0:09 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w, Samuel Ortiz,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w, qi.wang-ral2JQCrhuEAvxtiuMwx3w,
David S. Miller, Christian Pellegrin, Wolfgang Grandegger
In-Reply-To: <4CEA2986.4080607@pengutronix.de>
On Monday, November 22, 2010 5:27 PM, Marc Kleine-Budde wrote:
>>>>> Still we have the busy waiting in the TX path. Maybe you can move the
>>>>> waiting before accessing the if[1] and remove the busy waiting here.
>>>> I can't understand your saying.
>>>> For transmitting data, calling pch_can_rw_msg_obj is mandatory.
>>> Yes, but the busy wait is not needed. It should be enough to do the
>>> busy-waiting _before_ accessing the if[1].
>>
>> Do you mean we should create other pch_can_rw_msg_obj which doesn't have busy wait ?
>ACK, and this non busy waiting is use in the TX path. But you add a busy
>wait only function before accessing the if[1] in the TX path.
The "busy waiting" of pch_can_rw_msg_obj is for next processing accesses to Message object.
If deleting this busy waiting, next processing can access to Message object, regardless previous transfer doesn't
complete yet.
Thus, I think, the "busy waiting" is necessary.
---
Thanks,
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
----- Original Message -----
From: "Marc Kleine-Budde" <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
To: "Tomoya MORINAGA" <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Cc: <andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; <socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org>; "Samuel Ortiz" <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>;
<margie.foster-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; "Christian Pellegrin" <chripell-VaTbYqLCNhc@public.gmane.org>;
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; <yong.y.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; "Masayuki Ohtake" <masa-korg-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>;
<kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; <joel.clark-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>; "Wolfgang Grandegger"
<wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>; <qi.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Sent: Monday, November 22, 2010 5:27 PM
Subject: Re: [PATCH net-next-2.6 v3] can: Topcliff: PCH_CAN driver: Add Flow control,
^ permalink raw reply
* Re: Unix socket local DOS (OOM)
From: Vegard Nossum @ 2010-11-23 23:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, LKML, Andrew Morton, Eugene Teo, netdev
In-Reply-To: <1290553918.2866.80.camel@edumazet-laptop>
On 24 November 2010 00:11, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 23 novembre 2010 à 23:21 +0100, Vegard Nossum a écrit :
>> Hi,
>>
>> I found this program lying around on my laptop. It kills my box
>> (2.6.35) instantly by consuming a lot of memory (allocated by the
>> kernel, so the process doesn't get killed by the OOM killer). As far
>> as I can tell, the memory isn't being freed when the program exits
>> either. Maybe it will eventually get cleaned up the UNIX socket
>> garbage collector thing, but in that case it doesn't get called
>> quickly enough to save my machine at least.
>
> Hi Vegard
>
> Do you have a patch to correct this problem ?
No, sorry, I didn't look into it.
Vegard
^ permalink raw reply
* [PATCH net-next-2.6] ipv6: mcast: RCU conversion
From: Eric Dumazet @ 2010-11-23 23:12 UTC (permalink / raw)
To: David Miller; +Cc: netdev
ipv6_sk_mc_lock rwlock becomes a spinlock.
readers (inet6_mc_check()) now takes rcu_read_lock() instead of read
lock. Writers dont need to disable BH anymore.
struct ipv6_mc_socklist objects are reclaimed after one RCU grace
period.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/linux/ipv6.h | 2 -
include/net/if_inet6.h | 3 +
net/ipv6/mcast.c | 75 ++++++++++++++++++++++-----------------
3 files changed, 47 insertions(+), 33 deletions(-)
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 8e429d0..0c99776 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -364,7 +364,7 @@ struct ipv6_pinfo {
__u32 dst_cookie;
- struct ipv6_mc_socklist *ipv6_mc_list;
+ struct ipv6_mc_socklist __rcu *ipv6_mc_list;
struct ipv6_ac_socklist *ipv6_ac_list;
struct ipv6_fl_socklist *ipv6_fl_list;
diff --git a/include/net/if_inet6.h b/include/net/if_inet6.h
index f95ff8d..04977ee 100644
--- a/include/net/if_inet6.h
+++ b/include/net/if_inet6.h
@@ -89,10 +89,11 @@ struct ip6_sf_socklist {
struct ipv6_mc_socklist {
struct in6_addr addr;
int ifindex;
- struct ipv6_mc_socklist *next;
+ struct ipv6_mc_socklist __rcu *next;
rwlock_t sflock;
unsigned int sfmode; /* MCAST_{INCLUDE,EXCLUDE} */
struct ip6_sf_socklist *sflist;
+ struct rcu_head rcu;
};
struct ip6_sf_list {
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 9c50745..49f986d 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -82,7 +82,7 @@ static void *__mld2_query_bugs[] __attribute__((__unused__)) = {
static struct in6_addr mld2_all_mcr = MLD2_ALL_MCR_INIT;
/* Big mc list lock for all the sockets */
-static DEFINE_RWLOCK(ipv6_sk_mc_lock);
+static DEFINE_SPINLOCK(ipv6_sk_mc_lock);
static void igmp6_join_group(struct ifmcaddr6 *ma);
static void igmp6_leave_group(struct ifmcaddr6 *ma);
@@ -123,6 +123,11 @@ int sysctl_mld_max_msf __read_mostly = IPV6_MLD_MAX_MSF;
* socket join on multicast group
*/
+#define for_each_pmc_rcu(np, pmc) \
+ for (pmc = rcu_dereference(np->ipv6_mc_list); \
+ pmc != NULL; \
+ pmc = rcu_dereference(pmc->next))
+
int ipv6_sock_mc_join(struct sock *sk, int ifindex, const struct in6_addr *addr)
{
struct net_device *dev = NULL;
@@ -134,15 +139,15 @@ int ipv6_sock_mc_join(struct sock *sk, int ifindex, const struct in6_addr *addr)
if (!ipv6_addr_is_multicast(addr))
return -EINVAL;
- read_lock_bh(&ipv6_sk_mc_lock);
- for (mc_lst=np->ipv6_mc_list; mc_lst; mc_lst=mc_lst->next) {
+ rcu_read_lock();
+ for_each_pmc_rcu(np, mc_lst) {
if ((ifindex == 0 || mc_lst->ifindex == ifindex) &&
ipv6_addr_equal(&mc_lst->addr, addr)) {
- read_unlock_bh(&ipv6_sk_mc_lock);
+ rcu_read_unlock();
return -EADDRINUSE;
}
}
- read_unlock_bh(&ipv6_sk_mc_lock);
+ rcu_read_unlock();
mc_lst = sock_kmalloc(sk, sizeof(struct ipv6_mc_socklist), GFP_KERNEL);
@@ -186,33 +191,41 @@ int ipv6_sock_mc_join(struct sock *sk, int ifindex, const struct in6_addr *addr)
return err;
}
- write_lock_bh(&ipv6_sk_mc_lock);
+ spin_lock(&ipv6_sk_mc_lock);
mc_lst->next = np->ipv6_mc_list;
- np->ipv6_mc_list = mc_lst;
- write_unlock_bh(&ipv6_sk_mc_lock);
+ rcu_assign_pointer(np->ipv6_mc_list, mc_lst);
+ spin_unlock(&ipv6_sk_mc_lock);
rcu_read_unlock();
return 0;
}
+static void ipv6_mc_socklist_reclaim(struct rcu_head *head)
+{
+ kfree(container_of(head, struct ipv6_mc_socklist, rcu));
+}
/*
* socket leave on multicast group
*/
int ipv6_sock_mc_drop(struct sock *sk, int ifindex, const struct in6_addr *addr)
{
struct ipv6_pinfo *np = inet6_sk(sk);
- struct ipv6_mc_socklist *mc_lst, **lnk;
+ struct ipv6_mc_socklist *mc_lst;
+ struct ipv6_mc_socklist __rcu **lnk;
struct net *net = sock_net(sk);
- write_lock_bh(&ipv6_sk_mc_lock);
- for (lnk = &np->ipv6_mc_list; (mc_lst = *lnk) !=NULL ; lnk = &mc_lst->next) {
+ spin_lock(&ipv6_sk_mc_lock);
+ for (lnk = &np->ipv6_mc_list;
+ (mc_lst = rcu_dereference_protected(*lnk,
+ lockdep_is_held(&ipv6_sk_mc_lock))) !=NULL ;
+ lnk = &mc_lst->next) {
if ((ifindex == 0 || mc_lst->ifindex == ifindex) &&
ipv6_addr_equal(&mc_lst->addr, addr)) {
struct net_device *dev;
*lnk = mc_lst->next;
- write_unlock_bh(&ipv6_sk_mc_lock);
+ spin_unlock(&ipv6_sk_mc_lock);
rcu_read_lock();
dev = dev_get_by_index_rcu(net, mc_lst->ifindex);
@@ -225,11 +238,12 @@ int ipv6_sock_mc_drop(struct sock *sk, int ifindex, const struct in6_addr *addr)
} else
(void) ip6_mc_leave_src(sk, mc_lst, NULL);
rcu_read_unlock();
- sock_kfree_s(sk, mc_lst, sizeof(*mc_lst));
+ atomic_sub(sizeof(*mc_lst), &sk->sk_omem_alloc);
+ call_rcu(&mc_lst->rcu, ipv6_mc_socklist_reclaim);
return 0;
}
}
- write_unlock_bh(&ipv6_sk_mc_lock);
+ spin_unlock(&ipv6_sk_mc_lock);
return -EADDRNOTAVAIL;
}
@@ -272,12 +286,13 @@ void ipv6_sock_mc_close(struct sock *sk)
struct ipv6_mc_socklist *mc_lst;
struct net *net = sock_net(sk);
- write_lock_bh(&ipv6_sk_mc_lock);
- while ((mc_lst = np->ipv6_mc_list) != NULL) {
+ spin_lock(&ipv6_sk_mc_lock);
+ while ((mc_lst = rcu_dereference_protected(np->ipv6_mc_list,
+ lockdep_is_held(&ipv6_sk_mc_lock))) != NULL) {
struct net_device *dev;
np->ipv6_mc_list = mc_lst->next;
- write_unlock_bh(&ipv6_sk_mc_lock);
+ spin_unlock(&ipv6_sk_mc_lock);
rcu_read_lock();
dev = dev_get_by_index_rcu(net, mc_lst->ifindex);
@@ -290,11 +305,13 @@ void ipv6_sock_mc_close(struct sock *sk)
} else
(void) ip6_mc_leave_src(sk, mc_lst, NULL);
rcu_read_unlock();
- sock_kfree_s(sk, mc_lst, sizeof(*mc_lst));
- write_lock_bh(&ipv6_sk_mc_lock);
+ atomic_sub(sizeof(*mc_lst), &sk->sk_omem_alloc);
+ call_rcu(&mc_lst->rcu, ipv6_mc_socklist_reclaim);
+
+ spin_lock(&ipv6_sk_mc_lock);
}
- write_unlock_bh(&ipv6_sk_mc_lock);
+ spin_unlock(&ipv6_sk_mc_lock);
}
int ip6_mc_source(int add, int omode, struct sock *sk,
@@ -328,8 +345,7 @@ int ip6_mc_source(int add, int omode, struct sock *sk,
err = -EADDRNOTAVAIL;
- read_lock(&ipv6_sk_mc_lock);
- for (pmc=inet6->ipv6_mc_list; pmc; pmc=pmc->next) {
+ for_each_pmc_rcu(inet6, pmc) {
if (pgsr->gsr_interface && pmc->ifindex != pgsr->gsr_interface)
continue;
if (ipv6_addr_equal(&pmc->addr, group))
@@ -428,7 +444,6 @@ int ip6_mc_source(int add, int omode, struct sock *sk,
done:
if (pmclocked)
write_unlock(&pmc->sflock);
- read_unlock(&ipv6_sk_mc_lock);
read_unlock_bh(&idev->lock);
rcu_read_unlock();
if (leavegroup)
@@ -466,14 +481,13 @@ int ip6_mc_msfilter(struct sock *sk, struct group_filter *gsf)
dev = idev->dev;
err = 0;
- read_lock(&ipv6_sk_mc_lock);
if (gsf->gf_fmode == MCAST_INCLUDE && gsf->gf_numsrc == 0) {
leavegroup = 1;
goto done;
}
- for (pmc=inet6->ipv6_mc_list; pmc; pmc=pmc->next) {
+ for_each_pmc_rcu(inet6, pmc) {
if (pmc->ifindex != gsf->gf_interface)
continue;
if (ipv6_addr_equal(&pmc->addr, group))
@@ -521,7 +535,6 @@ int ip6_mc_msfilter(struct sock *sk, struct group_filter *gsf)
write_unlock(&pmc->sflock);
err = 0;
done:
- read_unlock(&ipv6_sk_mc_lock);
read_unlock_bh(&idev->lock);
rcu_read_unlock();
if (leavegroup)
@@ -562,7 +575,7 @@ int ip6_mc_msfget(struct sock *sk, struct group_filter *gsf,
* so reading the list is safe.
*/
- for (pmc=inet6->ipv6_mc_list; pmc; pmc=pmc->next) {
+ for_each_pmc_rcu(inet6, pmc) {
if (pmc->ifindex != gsf->gf_interface)
continue;
if (ipv6_addr_equal(group, &pmc->addr))
@@ -612,13 +625,13 @@ int inet6_mc_check(struct sock *sk, const struct in6_addr *mc_addr,
struct ip6_sf_socklist *psl;
int rv = 1;
- read_lock(&ipv6_sk_mc_lock);
- for (mc = np->ipv6_mc_list; mc; mc = mc->next) {
+ rcu_read_lock();
+ for_each_pmc_rcu(np, mc) {
if (ipv6_addr_equal(&mc->addr, mc_addr))
break;
}
if (!mc) {
- read_unlock(&ipv6_sk_mc_lock);
+ rcu_read_unlock();
return 1;
}
read_lock(&mc->sflock);
@@ -638,7 +651,7 @@ int inet6_mc_check(struct sock *sk, const struct in6_addr *mc_addr,
rv = 0;
}
read_unlock(&mc->sflock);
- read_unlock(&ipv6_sk_mc_lock);
+ rcu_read_unlock();
return rv;
}
^ permalink raw reply related
* Re: Unix socket local DOS (OOM)
From: Eric Dumazet @ 2010-11-23 23:11 UTC (permalink / raw)
To: Vegard Nossum, David Miller; +Cc: LKML, Andrew Morton, Eugene Teo, netdev
In-Reply-To: <AANLkTi=Q967xpX0KLMwX-=_4_1AKO5wjHEuJ1TrNjCj9@mail.gmail.com>
Le mardi 23 novembre 2010 à 23:21 +0100, Vegard Nossum a écrit :
> Hi,
>
> I found this program lying around on my laptop. It kills my box
> (2.6.35) instantly by consuming a lot of memory (allocated by the
> kernel, so the process doesn't get killed by the OOM killer). As far
> as I can tell, the memory isn't being freed when the program exits
> either. Maybe it will eventually get cleaned up the UNIX socket
> garbage collector thing, but in that case it doesn't get called
> quickly enough to save my machine at least.
>
> #include <sys/mount.h>
> #include <sys/socket.h>
> #include <sys/un.h>
> #include <sys/wait.h>
>
> #include <errno.h>
> #include <fcntl.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <unistd.h>
>
> static int send_fd(int unix_fd, int fd)
> {
> struct msghdr msgh;
> struct cmsghdr *cmsg;
> char buf[CMSG_SPACE(sizeof(fd))];
>
> memset(&msgh, 0, sizeof(msgh));
>
> memset(buf, 0, sizeof(buf));
> msgh.msg_control = buf;
> msgh.msg_controllen = sizeof(buf);
>
> cmsg = CMSG_FIRSTHDR(&msgh);
> cmsg->cmsg_len = CMSG_LEN(sizeof(fd));
> cmsg->cmsg_level = SOL_SOCKET;
> cmsg->cmsg_type = SCM_RIGHTS;
>
> msgh.msg_controllen = cmsg->cmsg_len;
>
> memcpy(CMSG_DATA(cmsg), &fd, sizeof(fd));
> return sendmsg(unix_fd, &msgh, 0);
> }
>
> int main(int argc, char *argv[])
> {
> while (1) {
> pid_t child;
>
> child = fork();
> if (child == -1)
> exit(EXIT_FAILURE);
>
> if (child == 0) {
> int fd[2];
> int i;
>
> if (socketpair(PF_UNIX, SOCK_SEQPACKET, 0, fd) == -1)
> goto out_error;
>
> for (i = 0; i < 100; ++i) {
> if (send_fd(fd[0], fd[0]) == -1)
> goto out_error;
>
> if (send_fd(fd[1], fd[1]) == -1)
> goto out_error;
> }
>
> close(fd[0]);
> close(fd[1]);
> goto out;
>
> out_error:
> fprintf(stderr, "error: %s\n", strerror(errno));
> out:
> exit(EXIT_SUCCESS);
> }
>
> while (1) {
> pid_t kid;
> int status;
>
> kid = wait(&status);
> if (kid == -1) {
> if (errno == ECHILD)
> break;
> if (errno == EINTR)
> continue;
>
> exit(EXIT_FAILURE);
> }
>
> if (WIFEXITED(status)) {
> if (WEXITSTATUS(status))
> exit(WEXITSTATUS(status));
> break;
> }
> }
> }
>
> return EXIT_SUCCESS;
> }
>
>
> Vegard
> --
Hi Vegard
Do you have a patch to correct this problem ?
I suppose we should add a machine wide limit of pending struct
scm_fp_list. (percpu_counter I guess)
David, commit f8d570a4 added one "struct list_head list;" to struct
scm_fp_list, enlarging it by a two factor because of power of two
kmalloc() sizes. (2048 bytes on 64bit arches instead of 1024
previously)
We might lower SCM_MAX_FD from 255 to 253 ?
^ permalink raw reply
* Re: [PATCH] iproute2: support xfrm upper protocol gre key
From: Ben Hutchings @ 2010-11-23 22:26 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Timo Teräs, netdev
In-Reply-To: <20101123101302.54a9e4be@nehalam>
On Tue, 2010-11-23 at 10:13 -0800, Stephen Hemminger wrote:
> On Tue, 23 Nov 2010 18:44:44 +0200
> Timo Teräs <timo.teras@iki.fi> wrote:
>
> > On 11/23/2010 06:24 PM, Stephen Hemminger wrote:
> > > On Tue, 23 Nov 2010 17:02:39 +0200
> > > Timo Teräs <timo.teras@iki.fi> wrote:
> > >
> > >> + case IPPROTO_GRE:
> > >> + if (sel->sport_mask || sel->dport_mask) {
> > >> + struct in_addr key;
> > >> + key.s_addr = htonl((ntohs(sel->sport) << 16) + ntohs(sel->dport));
> > >> + inet_ntop(AF_INET, &key, abuf, sizeof(abuf));
> > >> + fprintf(fp, "key %s ", abuf);
> > >> + }
> > >
> > > The GRE key is not really an IPv4 address. Why should the utilities
> > > use IPv4 address manipulation to format/scan it. It makes more sense
> > > to me to just use u32 an do the necessary ntohl.
> >
> > This is pretty much how iptunnel.c does it, so I copied the code. Would
> > you prefer to format it as single u32 number? Or use something else for
> > formatting it similar to IPv4?
> >
> > In either case, we should change iptunnel.c to match ipxfrm.c. It'll be
> > easier if both parts handling the gre key treat it equivalently.
> >
> > I think Cisco does indeed treat it as u32 number in the configurations.
> > So I'm okay updating this patch, and fixing iptunnel.c side too. We
> > might still want to keep the parsing of ipv4 format to keep backwards
> > compatibility.
>
> My preference would be to take both dotted quad and a single
> number.
inet_aton() covers that.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH net-2.6] net, ppp: Report correct error code if unit allocation failed
From: Cyrill Gorcunov @ 2010-11-23 21:43 UTC (permalink / raw)
To: LNML; +Cc: Paul Mackerras, David Miller, linux-ppp, linux-kernel
Allocating unit from ird might return several error codes
not only -EAGAIN, so it should not be changed and returned
precisely. Same time unit release procedure should be invoked
only if device is unregistering.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
CC: Paul Mackerras <paulus@samba.org>
---
Please review, thanks! (I've tested it a bit but more tests would
be really appreciated as well as comments)
drivers/net/ppp_generic.c | 43 ++++++++++++++++++++++---------------------
1 file changed, 22 insertions(+), 21 deletions(-)
Index: linux-2.6.git/drivers/net/ppp_generic.c
=====================================================================
--- linux-2.6.git.orig/drivers/net/ppp_generic.c
+++ linux-2.6.git/drivers/net/ppp_generic.c
@@ -2584,16 +2584,16 @@ ppp_create_interface(struct net *net, in
*/
dev_net_set(dev, net);
- ret = -EEXIST;
mutex_lock(&pn->all_ppp_mutex);
if (unit < 0) {
unit = unit_get(&pn->units_idr, ppp);
if (unit < 0) {
- *retp = unit;
+ ret = unit;
goto out2;
}
} else {
+ ret = -EEXIST;
if (unit_find(&pn->units_idr, unit))
goto out2; /* unit already exists */
/*
@@ -2668,10 +2668,10 @@ static void ppp_shutdown_interface(struc
ppp->closing = 1;
ppp_unlock(ppp);
unregister_netdev(ppp->dev);
+ unit_put(&pn->units_idr, ppp->file.index);
} else
ppp_unlock(ppp);
- unit_put(&pn->units_idr, ppp->file.index);
ppp->file.dead = 1;
ppp->owner = NULL;
wake_up_interruptible(&ppp->file.rwait);
@@ -2859,8 +2859,7 @@ static void __exit ppp_cleanup(void)
* by holding all_ppp_mutex
*/
-/* associate pointer with specified number */
-static int unit_set(struct idr *p, void *ptr, int n)
+static int __unit_alloc(struct idr *p, void *ptr, int n)
{
int unit, err;
@@ -2871,10 +2870,24 @@ again:
}
err = idr_get_new_above(p, ptr, n, &unit);
- if (err == -EAGAIN)
- goto again;
+ if (err < 0) {
+ if (err == -EAGAIN)
+ goto again;
+ return err;
+ }
+
+ return unit;
+}
+
+/* associate pointer with specified number */
+static int unit_set(struct idr *p, void *ptr, int n)
+{
+ int unit;
- if (unit != n) {
+ unit = __unit_alloc(p, ptr, n);
+ if (unit < 0)
+ return unit;
+ else if (unit != n) {
idr_remove(p, unit);
return -EINVAL;
}
@@ -2885,19 +2898,7 @@ again:
/* get new free unit number and associate pointer with it */
static int unit_get(struct idr *p, void *ptr)
{
- int unit, err;
-
-again:
- if (!idr_pre_get(p, GFP_KERNEL)) {
- printk(KERN_ERR "PPP: No free memory for idr\n");
- return -ENOMEM;
- }
-
- err = idr_get_new_above(p, ptr, 0, &unit);
- if (err == -EAGAIN)
- goto again;
-
- return unit;
+ return __unit_alloc(p, ptr, 0);
}
/* put unit number back to a pool */
^ permalink raw reply
* pull request: wireless-2.6 2010-11-23
From: John W. Linville @ 2010-11-23 21:05 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here are some fixes intended for 2.6.37 -- a collection of one-liners! :-)
The carl9170 patch fixes a NULL pointer dereference. The b43-pci-bridge
one just adds a device ID. The ath9k patch fixes a timeout that also
triggers a warning in dmesg. Finally, the b43 patch fixes a resource
leak on an error path.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit cf41a51db89850033efc11c18a5257de810b5417:
of/phylib: Use device tree properties to initialize Marvell PHYs. (2010-11-22 08:34:23 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Christian Lamparter (1):
carl9170: fix virtual interface setup crash
Daniel Klaffenbach (1):
ssb: b43-pci-bridge: Add new vendor for BCM4318
Felix Fietkau (1):
ath9k: fix timeout on stopping rx dma
Guennadi Liakhovetski (1):
wireless: b43: fix error path in SDIO
drivers/net/wireless/ath/ath9k/recv.c | 2 +-
drivers/net/wireless/ath/carl9170/main.c | 2 +-
drivers/net/wireless/b43/sdio.c | 1 +
drivers/ssb/b43_pci_bridge.c | 1 +
include/linux/pci_ids.h | 1 +
5 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index c76ea53..1a62e35 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -518,7 +518,7 @@ bool ath_stoprecv(struct ath_softc *sc)
bool stopped;
spin_lock_bh(&sc->rx.rxbuflock);
- ath9k_hw_stoppcurecv(ah);
+ ath9k_hw_abortpcurecv(ah);
ath9k_hw_setrxfilter(ah, 0);
stopped = ath9k_hw_stopdmarecv(ah);
diff --git a/drivers/net/wireless/ath/carl9170/main.c b/drivers/net/wireless/ath/carl9170/main.c
index 980ae70..a314c2c 100644
--- a/drivers/net/wireless/ath/carl9170/main.c
+++ b/drivers/net/wireless/ath/carl9170/main.c
@@ -647,7 +647,7 @@ init:
}
unlock:
- if (err && (vif_id != -1)) {
+ if (err && (vif_id >= 0)) {
vif_priv->active = false;
bitmap_release_region(&ar->vif_bitmap, vif_id, 0);
ar->vifs--;
diff --git a/drivers/net/wireless/b43/sdio.c b/drivers/net/wireless/b43/sdio.c
index 9a55338..09e2dfd 100644
--- a/drivers/net/wireless/b43/sdio.c
+++ b/drivers/net/wireless/b43/sdio.c
@@ -163,6 +163,7 @@ static int b43_sdio_probe(struct sdio_func *func,
err_free_ssb:
kfree(sdio);
err_disable_func:
+ sdio_claim_host(func);
sdio_disable_func(func);
err_release_host:
sdio_release_host(func);
diff --git a/drivers/ssb/b43_pci_bridge.c b/drivers/ssb/b43_pci_bridge.c
index ef9c6a0..744d3f6 100644
--- a/drivers/ssb/b43_pci_bridge.c
+++ b/drivers/ssb/b43_pci_bridge.c
@@ -24,6 +24,7 @@ static const struct pci_device_id b43_pci_bridge_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4312) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4315) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4318) },
+ { PCI_DEVICE(PCI_VENDOR_ID_BCM_GVC, 0x4318) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4319) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4320) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4321) },
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index d278dd9..f29c25e 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2043,6 +2043,7 @@
#define PCI_DEVICE_ID_AFAVLAB_P030 0x2182
#define PCI_SUBDEVICE_ID_AFAVLAB_P061 0x2150
+#define PCI_VENDOR_ID_BCM_GVC 0x14a4
#define PCI_VENDOR_ID_BROADCOM 0x14e4
#define PCI_DEVICE_ID_TIGON3_5752 0x1600
#define PCI_DEVICE_ID_TIGON3_5752M 0x1601
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [PATCH] arch/tile: fix rwlock so would-be write lockers don't block new readers
From: Chris Metcalf @ 2010-11-23 21:02 UTC (permalink / raw)
To: Cypher Wu; +Cc: linux-kernel, Américo Wang, Eric Dumazet, netdev
In-Reply-To: <AANLkTim1YyujwGZfenU_m52HEJJSFmTg3Wswn2DkqA3a@mail.gmail.com>
On 11/22/2010 8:36 PM, Cypher Wu wrote:
> Say, if core A try to write_lock() rwlock and current_ticket_ is 0 and
> it write next_ticket_ to 1, when it processing the lock, core B try to
> write_lock() again and write next_ticket_ to 2, then when A
> write_unlock() it seen that (current_ticket_+1) is not equal to
> next_ticket_, so it increment current_ticket_, and core B get the
> lock. If core A try write_lock again before core B write_unlock, it
> will increment next_ticket_ to 3. And so on.
> This may rarely happened, I've tested it yesterday for several hours
> it goes very well under pressure.
This should be OK when it happens (other than starving out the readers, but
that was the decision made by doing a ticket lock in the first place).
Even if we wrap around 255 back to zero on the tickets, the ticket queue
will work correctly. The key is not to need more than 256 concurrent write
lock waiters, which we don't.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* [PATCH] DECnet: don't leak uninitialized stack byte
From: Dan Rosenberg @ 2010-11-23 21:02 UTC (permalink / raw)
To: davem; +Cc: netdev
A single uninitialized padding byte is leaked to userspace.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
CC: stable <stable@kernel.org>
---
net/decnet/af_decnet.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c
index d6b93d1..cf38f52 100644
--- a/net/decnet/af_decnet.c
+++ b/net/decnet/af_decnet.c
@@ -1556,6 +1556,8 @@ static int __dn_getsockopt(struct socket *sock, int level,int optname, char __us
if (r_len > sizeof(struct linkinfo_dn))
r_len = sizeof(struct linkinfo_dn);
+ memset(&link, 0, sizeof(link));
+
switch(sock->state) {
case SS_CONNECTING:
link.idn_linkstate = LL_CONNECTING;
^ permalink raw reply related
* [PATCH net-next-2.6] net: add netif_tx_queue_frozen_or_stopped
From: Eric Dumazet @ 2010-11-23 20:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev
When testing struct netdev_queue state against FROZEN bit, we also test
XOFF bit. We can test both bits at once and save some cycles.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/linux/netdevice.h | 6 ++++--
net/core/netpoll.c | 3 +--
net/core/pktgen.c | 2 +-
net/sched/sch_generic.c | 8 +++-----
net/sched/sch_teql.c | 3 +--
5 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index b45c1b8..0a03d8a 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -493,6 +493,8 @@ static inline void napi_synchronize(const struct napi_struct *n)
enum netdev_queue_state_t {
__QUEUE_STATE_XOFF,
__QUEUE_STATE_FROZEN,
+#define QUEUE_STATE_XOFF_OR_FROZEN ((1 << __QUEUE_STATE_XOFF) | \
+ (1 << __QUEUE_STATE_FROZEN))
};
struct netdev_queue {
@@ -1599,9 +1601,9 @@ static inline int netif_queue_stopped(const struct net_device *dev)
return netif_tx_queue_stopped(netdev_get_tx_queue(dev, 0));
}
-static inline int netif_tx_queue_frozen(const struct netdev_queue *dev_queue)
+static inline int netif_tx_queue_frozen_or_stopped(const struct netdev_queue *dev_queue)
{
- return test_bit(__QUEUE_STATE_FROZEN, &dev_queue->state);
+ return dev_queue->state & QUEUE_STATE_XOFF_OR_FROZEN;
}
/**
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 4e98ffa..ee38acb 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -76,8 +76,7 @@ static void queue_process(struct work_struct *work)
local_irq_save(flags);
__netif_tx_lock(txq, smp_processor_id());
- if (netif_tx_queue_stopped(txq) ||
- netif_tx_queue_frozen(txq) ||
+ if (netif_tx_queue_frozen_or_stopped(txq) ||
ops->ndo_start_xmit(skb, dev) != NETDEV_TX_OK) {
skb_queue_head(&npinfo->txq, skb);
__netif_tx_unlock(txq);
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 2e57830..2953b2a 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -3527,7 +3527,7 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
__netif_tx_lock_bh(txq);
- if (unlikely(netif_tx_queue_stopped(txq) || netif_tx_queue_frozen(txq))) {
+ if (unlikely(netif_tx_queue_frozen_or_stopped(txq))) {
ret = NETDEV_TX_BUSY;
pkt_dev->last_ok = 0;
goto unlock;
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 5dbb3cd..470e046 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -60,8 +60,7 @@ static inline struct sk_buff *dequeue_skb(struct Qdisc *q)
/* check the reason of requeuing without tx lock first */
txq = netdev_get_tx_queue(dev, skb_get_queue_mapping(skb));
- if (!netif_tx_queue_stopped(txq) &&
- !netif_tx_queue_frozen(txq)) {
+ if (!netif_tx_queue_frozen_or_stopped(txq)) {
q->gso_skb = NULL;
q->q.qlen--;
} else
@@ -122,7 +121,7 @@ int sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q,
spin_unlock(root_lock);
HARD_TX_LOCK(dev, txq, smp_processor_id());
- if (!netif_tx_queue_stopped(txq) && !netif_tx_queue_frozen(txq))
+ if (!netif_tx_queue_frozen_or_stopped(txq))
ret = dev_hard_start_xmit(skb, dev, txq);
HARD_TX_UNLOCK(dev, txq);
@@ -144,8 +143,7 @@ int sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q,
ret = dev_requeue_skb(skb, q);
}
- if (ret && (netif_tx_queue_stopped(txq) ||
- netif_tx_queue_frozen(txq)))
+ if (ret && netif_tx_queue_frozen_or_stopped(txq))
ret = 0;
return ret;
diff --git a/net/sched/sch_teql.c b/net/sched/sch_teql.c
index 401af95..106479a 100644
--- a/net/sched/sch_teql.c
+++ b/net/sched/sch_teql.c
@@ -309,8 +309,7 @@ restart:
if (__netif_tx_trylock(slave_txq)) {
unsigned int length = qdisc_pkt_len(skb);
- if (!netif_tx_queue_stopped(slave_txq) &&
- !netif_tx_queue_frozen(slave_txq) &&
+ if (!netif_tx_queue_frozen_or_stopped(slave_txq) &&
slave_ops->ndo_start_xmit(skb, slave) == NETDEV_TX_OK) {
txq_trans_update(slave_txq);
__netif_tx_unlock(slave_txq);
^ permalink raw reply related
* Re: [PATCH net-next-2.6] RPS: enables setting CONFIG_RPS config option.
From: David Miller @ 2010-11-23 20:12 UTC (permalink / raw)
To: ramirose; +Cc: netdev
In-Reply-To: <AANLkTikLP0_Xphc7ECwF7yuffqU0dmw1QWdpc36dfMAT@mail.gmail.com>
From: Rami Rosen <ramirose@gmail.com>
Date: Tue, 23 Nov 2010 22:10:37 +0200
> The patch enables setting CONFIG_RPS config option for
> Receive packet steering (net/Kconfig.).
We do not want it to be choosable by the user.
CONFIG_RPS acts merely a dependency description mechanism, nothing
more.
^ permalink raw reply
* [PATCH net-next-2.6] RPS: enables setting CONFIG_RPS config option.
From: Rami Rosen @ 2010-11-23 20:10 UTC (permalink / raw)
To: davem, netdev
[-- Attachment #1: Type: text/plain, Size: 171 bytes --]
Hi,
The patch enables setting CONFIG_RPS config option for
Receive packet steering (net/Kconfig.).
Regards,
Rami Rosen
Signed-off-by: Rami Rosen <ramirose@gmail.com>
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 462 bytes --]
diff --git a/net/Kconfig b/net/Kconfig
index 55fd82e..d15c3cb 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -216,9 +216,12 @@ source "net/dcb/Kconfig"
source "net/dns_resolver/Kconfig"
config RPS
- boolean
+ bool "Receive packet steering (RPS)"
depends on SMP && SYSFS && USE_GENERIC_SMP_HELPERS
default y
+ ---help---
+ Support for Receive packet steering (RPS), which distributes the work of
+ outgoing data across CPUs.
menu "Network testing"
^ permalink raw reply related
* Re: [PATCH 2/2] SELinux: indicate fatal error in compat netfilter code
From: David Miller @ 2010-11-23 18:59 UTC (permalink / raw)
To: paul.moore; +Cc: eparis, netdev, selinux, sds
In-Reply-To: <1290529928.5359.19.camel@sifl>
From: Paul Moore <paul.moore@hp.com>
Date: Tue, 23 Nov 2010 11:32:08 -0500
> On Tue, 2010-11-23 at 11:28 -0500, Eric Paris wrote:
>> The SELinux ip postroute code indicates when policy rejected a packet and
>> passes the error back up the stack. The compat code does not. This patch
>> sends the same kind of error back up the stack in the compat code.
>>
>> Based-on-patch-by: Paul Moore <paul.moore@hp.com>
>> Signed-off-by: Eric Paris <eparis@redhat.com>
>
> Reviewed-by: Paul Moore <paul.moore@hp.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] SELinux: Only return netlink error when we know the return is fatal
From: David Miller @ 2010-11-23 18:59 UTC (permalink / raw)
To: paul.moore; +Cc: eparis, netdev, selinux, sds
In-Reply-To: <1290529955.5359.20.camel@sifl>
From: Paul Moore <paul.moore@hp.com>
Date: Tue, 23 Nov 2010 11:32:35 -0500
> On Tue, 2010-11-23 at 11:28 -0500, Eric Paris wrote:
>> Some of the SELinux netlink code returns a fatal error when the error might
>> actually be transient. This patch just silently drops packets on
>> potentially transient errors but continues to return a permanant error
>> indicator when the denial was because of policy.
>>
>> Based-on-comments-by: Paul Moore <paul.moore@hp.com>
>> Signed-off-by: Eric Paris <eparis@redhat.com>
>
> Thanks for fixing this up.
>
> Reviewed-by: Paul Moore <paul.moore@hp.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] usbnet: changes for upcoming cdc_ncm driver
From: David Brownell @ 2010-11-23 18:58 UTC (permalink / raw)
To: Alexey Orishko
Cc: gregkh, linux-usb, netdev, oliver, yauheni.kaliuta, felipe.balbi,
sjur.brandeland, Alexey Orishko
In-Reply-To: <1290531088-2393-1-git-send-email-alexey.orishko@stericsson.com>
On Tue, 2010-11-23 at 17:51 +0100, Alexey Orishko wrote:
> - skb_queue_tail (&dev->done, skb);
> + if (skb->len) {
> + /* all data was already cloned inside NCM driver */
Fix this comment. NCM isn't the only framing policy which un-batches
RX packets ... RNDIS has done so for a number of years already, and
more recently EEM needs it too ... plus at least one hardware driver.
Also, check pending patches, since I seem to recall one that supports
some hardware (SMSC?) that batches, and needed to update the calling
convention you're using here (i.e. the original one).
> + if (dev->driver_info->flags & FLAG_MULTI_PACKET)
except ... you documented this flag as affecting TX paths not RX...
> + dev_kfree_skb_any(skb);
> + else
> + usbnet_skb_return(dev, skb);
> + return;
> }
> +
> + netif_dbg(dev, rx_err, dev->net, "drop\n");
> +error:
> + dev->net->stats.rx_errors++;
> + skb_queue_tail(&dev->done, skb);
> }
>
^ permalink raw reply
* Re: [PATCH] iproute2: support xfrm upper protocol gre key
From: Stephen Hemminger @ 2010-11-23 18:54 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <4CEC0A42.60209@iki.fi>
On Tue, 23 Nov 2010 20:38:58 +0200
Timo Teräs <timo.teras@iki.fi> wrote:
> On 11/23/2010 08:13 PM, Stephen Hemminger wrote:
> > On Tue, 23 Nov 2010 18:44:44 +0200
> > Timo Teräs <timo.teras@iki.fi> wrote:
> >> On 11/23/2010 06:24 PM, Stephen Hemminger wrote:
> >>> The GRE key is not really an IPv4 address. Why should the utilities
> >>> use IPv4 address manipulation to format/scan it. It makes more sense
> >>> to me to just use u32 an do the necessary ntohl.
> >>
> >> This is pretty much how iptunnel.c does it, so I copied the code. Would
> >> you prefer to format it as single u32 number? Or use something else for
> >> formatting it similar to IPv4?
> >>
> >> In either case, we should change iptunnel.c to match ipxfrm.c. It'll be
> >> easier if both parts handling the gre key treat it equivalently.
> >>
> >> I think Cisco does indeed treat it as u32 number in the configurations.
> >> So I'm okay updating this patch, and fixing iptunnel.c side too. We
> >> might still want to keep the parsing of ipv4 format to keep backwards
> >> compatibility.
> >
> > My preference would be to take both dotted quad and a single
> > number.
>
> And I assume that when dumping stuff, it should be output as single
> number. Or make that configurable with some switch?
>
> I'll refresh my patch and fix iptunnel.c output tomorrow.
Just show it as a decimal number. That is what Cisco and Juniper do.
--
^ permalink raw reply
* Re: [PATCH 4/9] AF_UNIX: find the recipients for multicast messages
From: David Miller @ 2010-11-23 18:39 UTC (permalink / raw)
To: alban.crequy
Cc: eric.dumazet, shemminger, gorcunov, adobriyan, lennart,
kay.sievers, ian.molton, netdev, linux-kernel
In-Reply-To: <20101123174701.1b2f6f16@chocolatine.cbg.collabora.co.uk>
From: Alban Crequy <alban.crequy@collabora.co.uk>
Date: Tue, 23 Nov 2010 17:47:01 +0000
> Le Tue, 23 Nov 2010 17:08:37 +0100,
> Eric Dumazet <eric.dumazet@gmail.com> a écrit :
>> I am not sure if doing 90 clones of skb and filtering them one by one
>> is going to be fast :-(
>
> Yes... I think it can be optimized. Run the socket filter first by
> calling sk_run_filter() directly and then call skb_clone() + pskb_trim()
> only on the few remaining sockets.
BTW, we have and have talked about the same exact problem with
AF_PACKET socket users such as DHCP.
We clone and push the packet down into the AF_PACKET protocol
code from the pt_type callback when %99 of the time the socket
filter doesn't match and thus the clone is completely wasted
work.
If we know the socket, or more specifically the filter, early enough,
we could have a special interface like:
struct sk_buff *skb_filter_or_clone(struct sk_buff *skb, ...)
Which returns a non-NULL cloned SKB if the filter accepts the
packet.
^ permalink raw reply
* Re: [PATCH] iproute2: support xfrm upper protocol gre key
From: Timo Teräs @ 2010-11-23 18:38 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20101123101302.54a9e4be@nehalam>
On 11/23/2010 08:13 PM, Stephen Hemminger wrote:
> On Tue, 23 Nov 2010 18:44:44 +0200
> Timo Teräs <timo.teras@iki.fi> wrote:
>> On 11/23/2010 06:24 PM, Stephen Hemminger wrote:
>>> The GRE key is not really an IPv4 address. Why should the utilities
>>> use IPv4 address manipulation to format/scan it. It makes more sense
>>> to me to just use u32 an do the necessary ntohl.
>>
>> This is pretty much how iptunnel.c does it, so I copied the code. Would
>> you prefer to format it as single u32 number? Or use something else for
>> formatting it similar to IPv4?
>>
>> In either case, we should change iptunnel.c to match ipxfrm.c. It'll be
>> easier if both parts handling the gre key treat it equivalently.
>>
>> I think Cisco does indeed treat it as u32 number in the configurations.
>> So I'm okay updating this patch, and fixing iptunnel.c side too. We
>> might still want to keep the parsing of ipv4 format to keep backwards
>> compatibility.
>
> My preference would be to take both dotted quad and a single
> number.
And I assume that when dumping stuff, it should be output as single
number. Or make that configurable with some switch?
I'll refresh my patch and fix iptunnel.c output tomorrow.
^ permalink raw reply
* RE: [PATCH net-next] bnx2x: Resolving a possible dead-lock situation
From: Vladislav Zolotarov @ 2010-11-23 18:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Dave Miller, Eilon Greenstein, netdev list
In-Reply-To: <1290531342.3046.115.camel@edumazet-laptop>
>
> I was only suggesting an alternate patch, I am not able to test it ;)
I think I forgot to thank u for your suggestion... ;)
>
>
>
^ permalink raw reply
* RE: [PATCH net-next] bnx2x: Resolving a possible dead-lock situation
From: Vladislav Zolotarov @ 2010-11-23 18:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Dave Miller, Eilon Greenstein, netdev list
In-Reply-To: <1290531342.3046.115.camel@edumazet-laptop>
> I was only suggesting an alternate patch, I am not able to test it ;)
Sure ;) So, I'll test it and send a patch with u signed-off...
>
>
>
^ permalink raw reply
* Re: [PATCH] iproute2: support xfrm upper protocol gre key
From: Stephen Hemminger @ 2010-11-23 18:13 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <4CEBEF7C.2060806@iki.fi>
On Tue, 23 Nov 2010 18:44:44 +0200
Timo Teräs <timo.teras@iki.fi> wrote:
> On 11/23/2010 06:24 PM, Stephen Hemminger wrote:
> > On Tue, 23 Nov 2010 17:02:39 +0200
> > Timo Teräs <timo.teras@iki.fi> wrote:
> >
> >> + case IPPROTO_GRE:
> >> + if (sel->sport_mask || sel->dport_mask) {
> >> + struct in_addr key;
> >> + key.s_addr = htonl((ntohs(sel->sport) << 16) + ntohs(sel->dport));
> >> + inet_ntop(AF_INET, &key, abuf, sizeof(abuf));
> >> + fprintf(fp, "key %s ", abuf);
> >> + }
> >
> > The GRE key is not really an IPv4 address. Why should the utilities
> > use IPv4 address manipulation to format/scan it. It makes more sense
> > to me to just use u32 an do the necessary ntohl.
>
> This is pretty much how iptunnel.c does it, so I copied the code. Would
> you prefer to format it as single u32 number? Or use something else for
> formatting it similar to IPv4?
>
> In either case, we should change iptunnel.c to match ipxfrm.c. It'll be
> easier if both parts handling the gre key treat it equivalently.
>
> I think Cisco does indeed treat it as u32 number in the configurations.
> So I'm okay updating this patch, and fixing iptunnel.c side too. We
> might still want to keep the parsing of ipv4 format to keep backwards
> compatibility.
My preference would be to take both dotted quad and a single
number.
--
^ permalink raw reply
* [PATCH] MAINTAINERS: add second list for IRDA
From: Wolfram Sang @ 2010-11-23 18:10 UTC (permalink / raw)
To: netdev; +Cc: Wolfram Sang, Samuel Ortiz, David Miller
The irda-users-list is currently almost dead and subscribers-only. Adding
netdev increases the audience which might help to not overlook a bugreport
(again).
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: David Miller <davem@davemloft.net>
---
MAINTAINERS | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8b6ca96..2596a78 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3261,6 +3261,7 @@ F: net/ipx/
IRDA SUBSYSTEM
M: Samuel Ortiz <samuel@sortiz.org>
L: irda-users@lists.sourceforge.net (subscribers-only)
+L: netdev@vger.kernel.org
W: http://irda.sourceforge.net/
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/irda-2.6.git
--
1.7.2.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox