* [PATCH net-next-2.6] inetpeer: do not use zero refcnt for freed entries
From: Eric Dumazet @ 2010-06-16 2:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, paulmck
In-Reply-To: <20100615.142506.02275206.davem@davemloft.net>
Le mardi 15 juin 2010 à 14:25 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 15 Jun 2010 20:23:14 +0200
>
> > inetpeer currently uses an AVL tree protected by an rwlock.
> >
> > It's possible to make most lookups use RCU
> ...
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Applied, nice work Eric.
Thanks David !
Re-reading patch I realize refcnt is expected to be 0 for unused entries
(obviously), so we should use a different marker for 'about to be freed'
ones.
Thanks
[PATCH net-next-2.6] inetpeer: do not use zero refcnt for freed entries
Followup of commit aa1039e73cc2 (inetpeer: RCU conversion)
Unused inet_peer entries have a null refcnt.
Using atomic_inc_not_zero() in rcu lookups is not going to work for
them, and slow path is taken.
Fix this using -1 marker instead of 0 for deleted entries.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/inetpeer.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
index 58fbc7e..39a14ba 100644
--- a/net/ipv4/inetpeer.c
+++ b/net/ipv4/inetpeer.c
@@ -187,7 +187,12 @@ static struct inet_peer *lookup_rcu_bh(__be32 daddr)
while (u != peer_avl_empty) {
if (daddr == u->v4daddr) {
- if (unlikely(!atomic_inc_not_zero(&u->refcnt)))
+ /* Before taking a reference, check if this entry was
+ * deleted, unlink_from_pool() sets refcnt=-1 to make
+ * distinction between an unused entry (refcnt=0) and
+ * a freed one.
+ */
+ if (unlikely(!atomic_add_unless(&u->refcnt, 1, -1)))
u = NULL;
return u;
}
@@ -322,8 +327,9 @@ static void unlink_from_pool(struct inet_peer *p)
* in cleanup() function to prevent sudden disappearing. If we can
* atomically (because of lockless readers) take this last reference,
* it's safe to remove the node and free it later.
+ * We use refcnt=-1 to alert lockless readers this entry is deleted.
*/
- if (atomic_cmpxchg(&p->refcnt, 1, 0) == 1) {
+ if (atomic_cmpxchg(&p->refcnt, 1, -1) == 1) {
struct inet_peer **stack[PEER_MAXDEPTH];
struct inet_peer ***stackptr, ***delp;
if (lookup(p->v4daddr, stack) != p)
^ permalink raw reply related
* Re: [PATCH] virtio_net: implements ethtool_ops.get_drvinfo
From: Rusty Russell @ 2010-06-16 1:54 UTC (permalink / raw)
To: Taku Izumi; +Cc: David S. Miller, netdev@vger.kernel.org, Michael S. Tsirkin
In-Reply-To: <4C170D9E.5090407@jp.fujitsu.com>
On Tue, 15 Jun 2010 02:50:30 pm Taku Izumi wrote:
> Hi Rusty,
>
> (2010/06/15 13:28), Rusty Russell wrote:
> > On Fri, 11 Jun 2010 10:59:02 am Taku Izumi wrote:
> >> This patch implements ethtool_ops.get_drvinfo interface of virtio_net driver.
> >>
> >> Signed-off-by: Taku Izumi<izumi.taku@jp.fujitsu.com>
> >
> > Hi Taku!
> >
> > Does this have any useful effect?
>
> I often use "ethtool -i" command to check what driver controls the ehternet device.
> But because current virtio_net driver doesn't support "ethtool -i", it becomes the
> following:
>
> # ethtool -i eth3
> Cannot get driver information: Operation not supported
>
> My patch simply adds the "ethtool -i" support. The following is the result when
> using the virtio_net driver with my patch applied to.
>
> # ethtool -i eth3
> driver: virtio_net
> version: N/A
> firmware-version: N/A
> bus-info: virtio0
>
> Personally, "-i" is one of the most frequently-used option, and
> most network drivers support "ethtool -i", so I think virtio_net also should do.
Thanks, Taku.
I put this explanation in the commit message, and changed 32 to ARRAY_SIZE().
It's queued for sending to DaveM for the next merge window.
Result below.
Thanks!
Rusty.
Subject: virtio_net: implements ethtool_ops.get_drvinfo
Date: Fri, 11 Jun 2010 10:29:02 +0900
From: Taku Izumi <izumi.taku@jp.fujitsu.com>
I often use "ethtool -i" command to check what driver controls the
ehternet device. But because current virtio_net driver doesn't
support "ethtool -i", it becomes the following:
# ethtool -i eth3
Cannot get driver information: Operation not supported
This patch simply adds the "ethtool -i" support. The following is the
result when using the virtio_net driver with my patch applied to.
# ethtool -i eth3
driver: virtio_net
version: N/A
firmware-version: N/A
bus-info: virtio0
Personally, "-i" is one of the most frequently-used option, and most
network drivers support "ethtool -i", so I think virtio_net also
should do.
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (use ARRAY_SIZE)
---
0 files changed
Index: net-next.35/drivers/net/virtio_net.c
===================================================================
--- net-next.35.orig/drivers/net/virtio_net.c
+++ net-next.35/drivers/net/virtio_net.c
@@ -701,6 +701,19 @@ static int virtnet_close(struct net_devi
return 0;
}
+static void virtnet_get_drvinfo(struct net_device *dev,
+ struct ethtool_drvinfo *drvinfo)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ struct virtio_device *vdev = vi->vdev;
+
+ strncpy(drvinfo->driver, KBUILD_MODNAME, ARRAY_SIZE(drvinfo->driver));
+ strncpy(drvinfo->version, "N/A", ARRAY_SIZE(drvinfo->version));
+ strncpy(drvinfo->fw_version, "N/A", ARRAY_SIZE(drvinfo->fw_version));
+ strncpy(drvinfo->bus_info, dev_name(&vdev->dev),
+ ARRAY_SIZE(drvinfo->bus_info));
+}
+
static int virtnet_set_tx_csum(struct net_device *dev, u32 data)
{
struct virtnet_info *vi = netdev_priv(dev);
@@ -813,6 +825,7 @@ static void virtnet_vlan_rx_kill_vid(str
}
static const struct ethtool_ops virtnet_ethtool_ops = {
+ .get_drvinfo = virtnet_get_drvinfo,
.set_tx_csum = virtnet_set_tx_csum,
.set_sg = ethtool_op_set_sg,
.set_tso = ethtool_op_set_tso,
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: NET_SKB_PAD should depend on L1_CACHE_BYTES
From: David Miller @ 2010-06-16 1:16 UTC (permalink / raw)
To: eric.dumazet
Cc: alexander.h.duyck, jeffrey.t.kirsher, mingo, tglx, hpa, x86,
linux-kernel, netdev, gospo
In-Reply-To: <1276520234.2478.82.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 14 Jun 2010 14:57:14 +0200
> [PATCH net-next-2.6] net: NET_SKB_PAD should depend on L1_CACHE_BYTES
>
> In old kernels, NET_SKB_PAD was defined to 16.
>
> Then commit d6301d3dd1c2 (net: Increase default NET_SKB_PAD to 32), and
> commit 18e8c134f4e9 (net: Increase NET_SKB_PAD to 64 bytes) increased it
> to 64.
>
> While first patch was governed by network stack needs, second was more
> driven by performance issues on current hardware. Real intent was to
> align data on a cache line boundary.
>
> So use max(32, L1_CACHE_BYTES) instead of 64, to be more generic.
>
> Remove microblaze and powerpc own NET_SKB_PAD definitions.
>
> Thanks to Alexander Duyck and David Miller for their comments.
>
> Suggested-by: David Miller <davem@davemloft.net>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 0/3]netxen: bug fixes
From: David Miller @ 2010-06-16 1:15 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman
In-Reply-To: <1276508345-17070-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Mon, 14 Jun 2010 02:39:02 -0700
> Sending series of 3 bug fixes. Please apply them on net-2.6.
All applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipfrag : frag_kfree_skb() cleanup
From: David Miller @ 2010-06-16 1:13 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1276507363.2478.43.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 14 Jun 2010 11:22:43 +0200
> Third param (work) is unused, remove it.
>
> Remove __inline__ and inline qualifiers.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ip_frag: Remove some atomic ops
From: David Miller @ 2010-06-16 1:13 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1276506144.2478.40.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 14 Jun 2010 11:02:24 +0200
> Instead of doing one atomic operation per frag, we can factorize them.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv6: syncookies: do not skip ->iif initialization
From: David Miller @ 2010-06-16 1:10 UTC (permalink / raw)
To: fw; +Cc: netdev, ggriffin.kernel
In-Reply-To: <1276464579-4399-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Sun, 13 Jun 2010 23:29:39 +0200
> When syncookies are in effect, req->iif is left uninitialized.
> In case of e.g. link-local addresses the route lookup then fails
> and no syn-ack is sent.
>
> Rearrange things so ->iif is also initialized in the syncookie case.
>
> want_cookie can only be true when the isn was zero, thus move the want_cookie
> check into the "!isn" branch.
>
> Cc: Glenn Griffin <ggriffin.kernel@gmail.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] syncookies: check decoded options against sysctl settings
From: David Miller @ 2010-06-16 1:09 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <1276464875-4460-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Sun, 13 Jun 2010 23:34:35 +0200
> - if (tcp_opt->sack_ok)
> - tcp_sack_reset(tcp_opt);
> + if (tcp_opt->sack_ok && !sysctl_tcp_sack)
> + return false;
>
If you remove the tcp_sack_reset() call here, who is going to
do it?
^ permalink raw reply
* Re: RX/close vcc race with solos/atmtcp/usbatm/he
From: Nathan Williams @ 2010-06-16 0:33 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-atm-general, netdev
In-Reply-To: <1275904970.17903.4658.camel@macbook.infradead.org>
On 7/06/2010 8:02 PM, David Woodhouse wrote:
> On Wed, 2010-05-26 at 12:16 +0100, David Woodhouse wrote:
>> I've had this crash reported to me...
>>
>> [18842.727906] EIP: [<e082f490>] br2684_push+0x19/0x234 [br2684]
>> SS:ESP 0068:dfb89d14
>
> Nathan, did you manage to get your customer to confirm that this fixes
> the problem? It'd be useful to get this into 2.6.35 and -stable.
>
No, I still haven't heard back from the customer. I'll keep sending email reminders.
^ permalink raw reply
* Re: [PATCH] drivers/staging/batman-adv: Use (pr|netdev)_<level> macro helpers
From: Joe Perches @ 2010-06-15 22:58 UTC (permalink / raw)
To: Sven Eckelmann, netdev
Cc: devel, Greg Kroah-Hartman,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwlltHuzzzSOjJt,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Simon Wunderlich,
Marek Lindner
In-Reply-To: <201006160037.48573.sven.eckelmann-Mmb7MZpHnFY@public.gmane.org>
On Wed, 2010-06-16 at 00:37 +0200, Sven Eckelmann wrote:
> Sven Eckelmann wrote:
Hi Sven.
> > The problem seems to be that dev_printk is used by netdev_printk (which is
> > used by netdev_info). netdev_printk will add (netdev)->dev.parent as second
> > parameter of dev_printk (and parent is NULL in our case). This macro will
> > now call dev_driver_string with NULL as parameter and just dereference
> > this null pointer.
> >
> > Maybe it is related to something else, but at least I think that this could
> > be the cause of the crash.
Nope, I think that's exactly correct.
> As far as I understand, the netdev_* stuff is made to be used by real drivers
> with more or less physical hardware. batman-adv is a virtual bridge used for
> mesh networks. Like net/bridge/ it has no physical parent device and only
> other net_devices are used inside of it - which may have real physical network
> devices as parents.
> Please correct me if my assumption is wrong.
No correction necessary...
netdev_printk and netdev_<level> are meant to be used
with parented network devices.
I think that netdev_<level> will eventually do the right
thing when dev->dev.parent is NULL. Right now, that'd
be a bit of an expensive test as it would be expanded in
place for every use of the macro.
Right now it's:
#define netdev_printk(level, netdev, format, args...) \
dev_printk(level, (netdev)->dev.parent, \
"%s: " format, \
netdev_name(netdev), ##args)
It could be something like:
#define netdev_printk(level, netdev, format, args...) \
do { \
if ((netdev)->dev.parent) \
dev_printk(level, (netdev)->dev.parent, \
"%s: " format, \
netdev_name(netdev), ##args); \
else \
printk(level "%s: " format, \
netdev_name(netdev), ##args); \
} while (0)
Unfortunately, that just about doubles the format string space,
so I don't really want to do that.
If/when %pV is accepted,
http://lkml.org/lkml/2010/3/4/17
http://lkml.org/lkml/2010/3/4/18
then the netdev_<level> macros will be converted to functions,
so size reduced with an added test for dev.parent == NULL without
the need to double the string space.
^ permalink raw reply
* Re: [PATCH 2/8] user_ns: Introduce user_nsmap_uid and user_ns_map_gid.
From: Eric W. Biederman @ 2010-06-15 22:37 UTC (permalink / raw)
To: Pavel Emelyanov
Cc: David Miller, Serge Hallyn, Linux Containers, Daniel Lezcano,
netdev
In-Reply-To: <4C173389.1010000@openvz.org>
Pavel Emelyanov <xemul@openvz.org> writes:
> On 06/13/2010 05:28 PM, Eric W. Biederman wrote:
>>
>> Define what happens when a we view a uid from one user_namespace
>> in another user_namepece.
>>
>> - If the user namespaces are the same no mapping is necessary.
>>
>> - For most cases of difference use overflowuid and overflowgid,
>> the uid and gid currently used for 16bit apis when we have a 32bit uid
>> that does fit in 16bits. Effectively the situation is the same,
>> we want to return a uid or gid that is not assigned to any user.
>>
>> - For the case when we happen to be mapping the uid or gid of the
>> creator of the target user namespace use uid 0 and gid as confusing
>> that user with root is not a problem.
>>
>> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>
> I suppose this one should go via Andrew, not Dave.
If it was stand alone I would send it that way.
In this case I'm hope Dave will indulge me because this bit is
simple, the only user for now is the network stack, and the people
maintaining the code have already acked the patch.
Eric
^ permalink raw reply
* Re: [PATCH] net: Fix error in comment on net_device_ops::ndo_get_stats
From: Ben Hutchings @ 2010-06-15 22:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <20100615.151040.191416638.davem@davemloft.net>
On Tue, 2010-06-15 at 15:10 -0700, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Mon, 14 Jun 2010 16:19:41 +0100
>
> > ndo_get_stats still returns struct net_device_stats *; there is
> > no struct net_device_stats64.
> >
> > Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
>
> Applied.
>
> But, I am ignoring every single patch you submit from here on
> out that lacks a proper "net-2.6" or "net-next-2.6" destination
> tree indication in your Subject line.
>
> I've asked this of you at least 3 times, and you seem content to just
> ignore my request. But that's OK, as I think you'll stop ignoring
> me when it starts causing patches you care about to be dropped.
>
> Thanks :-)
Sorry Dave, I thought net-next-2.6 was still the default and I only
needed to make it more obvious when I wanted patches to go to net-2.6.
I've added the suffix to my git configuration now.
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
* Re: [PATCH] net: Fix error in comment on net_device_ops::ndo_get_stats
From: David Miller @ 2010-06-15 22:10 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1276528781.2074.0.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 14 Jun 2010 16:19:41 +0100
> ndo_get_stats still returns struct net_device_stats *; there is
> no struct net_device_stats64.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
But, I am ignoring every single patch you submit from here on
out that lacks a proper "net-2.6" or "net-next-2.6" destination
tree indication in your Subject line.
I've asked this of you at least 3 times, and you seem content to just
ignore my request. But that's OK, as I think you'll stop ignoring
me when it starts causing patches you care about to be dropped.
Thanks :-)
^ permalink raw reply
* Re: [PATCH 6/8] scm: Capture the full credentials of the scm sender.
From: Eric W. Biederman @ 2010-06-15 22:08 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: David Miller, Linux Containers, Serge Hallyn, Pavel Emelyanov,
netdev
In-Reply-To: <20100615214541.GA22570@hallyn.com>
"Serge E. Hallyn" <serge@hallyn.com> writes:
> Quoting Eric W. Biederman (ebiederm@xmission.com):
>>
>> Start capturing not only the userspace pid, uid and gid values of the
>> sending process but also the struct pid and struct cred of the sending
>> process as well.
>>
>> This is in preparation for properly supporting SCM_CREDENTIALS for
>> sockets that have different uid and/or pid namespaces at the different
>> ends.
>>
>> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>> ---
>> include/net/scm.h | 28 ++++++++++++++++++++++++----
>> net/core/scm.c | 24 ++++++++++++++++++++++++
>> 2 files changed, 48 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/net/scm.h b/include/net/scm.h
>> index 17d9d2e..3165650 100644
>> --- a/include/net/scm.h
>> +++ b/include/net/scm.h
>> @@ -19,6 +19,8 @@ struct scm_fp_list {
>> };
>>
>> struct scm_cookie {
>> + struct pid *pid; /* Skb credentials */
>> + const struct cred *cred;
>> struct scm_fp_list *fp; /* Passed files */
>> struct ucred creds; /* Skb credentials */
>> #ifdef CONFIG_SECURITY_NETWORK
>> @@ -42,8 +44,27 @@ static __inline__ void unix_get_peersec_dgram(struct socket *sock, struct scm_co
>> { }
>> #endif /* CONFIG_SECURITY_NETWORK */
>>
>> +static __inline__ void scm_set_cred(struct scm_cookie *scm,
>> + struct pid *pid, const struct cred *cred)
>> +{
>> + scm->pid = get_pid(pid);
>> + scm->cred = get_cred(cred);
>> + cred_to_ucred(pid, cred, &scm->creds);
>> +}
>> +
>> +static __inline__ void scm_destroy_cred(struct scm_cookie *scm)
>> +{
>> + put_pid(scm->pid);
>> + scm->pid = NULL;
>> +
>> + if (scm->cred)
>> + put_cred(scm->cred);
>> + scm->cred = NULL;
>> +}
>> +
>> static __inline__ void scm_destroy(struct scm_cookie *scm)
>> {
>> + scm_destroy_cred(scm);
>> if (scm && scm->fp)
>> __scm_destroy(scm);
>> }
>> @@ -51,10 +72,7 @@ static __inline__ void scm_destroy(struct scm_cookie *scm)
>> static __inline__ int scm_send(struct socket *sock, struct msghdr *msg,
>> struct scm_cookie *scm)
>> {
>> - struct task_struct *p = current;
>> - scm->creds.uid = current_uid();
>> - scm->creds.gid = current_gid();
>> - scm->creds.pid = task_tgid_vnr(p);
>> + scm_set_cred(scm, task_tgid(current), current_cred());
>> scm->fp = NULL;
>> unix_get_peersec_dgram(sock, scm);
>> if (msg->msg_controllen <= 0)
>> @@ -96,6 +114,8 @@ static __inline__ void scm_recv(struct socket *sock, struct msghdr *msg,
>> if (test_bit(SOCK_PASSCRED, &sock->flags))
>> put_cmsg(msg, SOL_SOCKET, SCM_CREDENTIALS, sizeof(scm->creds), &scm->creds);
>>
>> + scm_destroy_cred(scm);
>> +
>> scm_passec(sock, msg, scm);
>>
>> if (!scm->fp)
>> diff --git a/net/core/scm.c b/net/core/scm.c
>> index b88f6f9..681c976 100644
>> --- a/net/core/scm.c
>> +++ b/net/core/scm.c
>> @@ -170,6 +170,30 @@ int __scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie *p)
>> err = scm_check_creds(&p->creds);
>> if (err)
>> goto error;
>> +
>
> I think this hunk needs to be documented. I.e. given that scm_send()
> will call scm_set_cred() before calling __scm_send, I don't see how
> these conditions could happen? If the condition can legitimately
> happen, then given all of the pid_t vs struct pid and 'cred' vs. 'creds'
> in these two hunks, I think a comment over each would be nice.
I think if you have the full context of __scm_send it becomes pretty obvious.
case SCM_CREDENTIALS:
if (cmsg->cmsg_len != CMSG_LEN(sizeof(struct ucred)))
goto error;
memcpy(&p->creds, CMSG_DATA(cmsg), sizeof(struct ucred));
err = scm_check_creds(&p->creds);
if (err)
goto error;
At this point we have just copied ucred from userspace. We have done
scm_check_creds to ensure we allow the user to send the pid, uid, and
gid they have passed in.
These tests catch the case where the user is legitimately sending
something other than their own credentials.
>> + if (pid_vnr(p->pid) != p->creds.pid) {
>> + struct pid *pid;
>> + err = -ESRCH;
>> + pid = find_get_pid(p->creds.pid);
>> + if (!pid)
>> + goto error;
>> + put_pid(p->pid);
>> + p->pid = pid;
>> + }
>> +
>> + if ((p->cred->euid != p->creds.uid) ||
>> + (p->cred->egid != p->creds.gid)) {
>> + struct cred *cred;
>> + err = -ENOMEM;
>> + cred = prepare_creds();
>> + if (!cred)
>> + goto error;
>> +
>> + cred->uid = cred->euid = p->creds.uid;
>> + cred->gid = cred->egid = p->creds.uid;
>> + put_cred(p->cred);
>> + p->cred = cred;
>> + }
>> break;
>> default:
>> goto error;
Eric
^ permalink raw reply
* Re: [PATCH v4] netdev:bfin_mac: reclaim and free tx skb as soon as possible after transfer
From: David Miller @ 2010-06-15 22:04 UTC (permalink / raw)
To: sonic.adi; +Cc: netdev, uclinux-dist-devel
In-Reply-To: <1276250702.30044.2.camel@eight.analog.com>
From: sonic zhang <sonic.adi@gmail.com>
Date: Fri, 11 Jun 2010 18:05:02 +0800
>>From 4779e43a5a8446f695f8d6f5a006cfb45dc093d8 Mon Sep 17 00:00:00 2001
> From: Sonic Zhang <sonic.zhang@analog.com>
> Date: Fri, 11 Jun 2010 17:44:31 +0800
> Subject: [PATCH v4] netdev:bfin_mac: reclaim and free tx skb as soon as possible after transfer
>
> SKBs hold onto resources that can't be held indefinitely, such as TCP
> socket references and netfilter conntrack state. So if a packet is left
> in TX ring for a long time, there might be a TCP socket that cannot be
> closed and freed up.
>
> Current blackfin EMAC driver always reclaim and free used tx skbs in future
> transfers. The problem is that future transfer may not come as soon as
> possible. This patch start a timer after transfer to reclaim and free skb.
> There is nearly no performance drop with this patch.
>
> TX interrupt is not enabled because of a strange behavior of the Blackfin EMAC.
> If EMAC TX transfer control is turned on, endless TX interrupts are triggered
> no matter if TX DMA is enabled or not. Since DMA walks down the ring automatically,
> TX transfer control can't be turned off in the middle. The only way is to disable
> TX interrupt completely.
>
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] pktgen: receive packets and process incoming rate
From: David Miller @ 2010-06-15 21:59 UTC (permalink / raw)
To: daniel.turull; +Cc: eric.dumazet, netdev, robert, jens.laas, voravit
In-Reply-To: <4C10F117.60800@gmail.com>
From: Daniel Turull <daniel.turull@gmail.com>
Date: Thu, 10 Jun 2010 16:05:11 +0200
> This patch adds receiver part to pktgen taking advantages of SMP systems
> with multiple rx queues:
> - Creation of new proc file /proc/net/pktgen/pgrx to control and display the receiver.
> - It uses PER-CPU variable to store the results per each CPU.
> - Results displayed per CPU and aggregated.
> - The packet handler is add in the protocols handlers (dev_add_pack())
> - Available statistics: packets and bytes received, work time and rate
> - Only process pktgen packets
> - It is possible to select the incoming interface
> - Documentation updated with the new commands to control the receiver part.
>
> Signed-off-by: Daniel Turull <daniel.turull@gmail.com>
I completely disagree with this patch on two levels:
1) pktgen is for "generating" packets, not receiving them.
Trying to put lipstick on a pig is never a good idea.
2) The information it gathers and shows is completely useless.
What's interesting as "RX work cost" is what happens deep
down in the netif_receive_skb() code paths, IP input, routing,
netfilter, whatever... but that is not what this thing is
measuring at all.
Sorry, I'm not applying this. You can probably do something more
clever with tracepoints.
^ permalink raw reply
* Re: [PATCH 6/8] scm: Capture the full credentials of the scm sender.
From: Serge E. Hallyn @ 2010-06-15 21:45 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, Linux Containers, Serge Hallyn, Pavel Emelyanov,
netdev
In-Reply-To: <m1d3vvgirx.fsf@fess.ebiederm.org>
Quoting Eric W. Biederman (ebiederm@xmission.com):
>
> Start capturing not only the userspace pid, uid and gid values of the
> sending process but also the struct pid and struct cred of the sending
> process as well.
>
> This is in preparation for properly supporting SCM_CREDENTIALS for
> sockets that have different uid and/or pid namespaces at the different
> ends.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
> ---
> include/net/scm.h | 28 ++++++++++++++++++++++++----
> net/core/scm.c | 24 ++++++++++++++++++++++++
> 2 files changed, 48 insertions(+), 4 deletions(-)
>
> diff --git a/include/net/scm.h b/include/net/scm.h
> index 17d9d2e..3165650 100644
> --- a/include/net/scm.h
> +++ b/include/net/scm.h
> @@ -19,6 +19,8 @@ struct scm_fp_list {
> };
>
> struct scm_cookie {
> + struct pid *pid; /* Skb credentials */
> + const struct cred *cred;
> struct scm_fp_list *fp; /* Passed files */
> struct ucred creds; /* Skb credentials */
> #ifdef CONFIG_SECURITY_NETWORK
> @@ -42,8 +44,27 @@ static __inline__ void unix_get_peersec_dgram(struct socket *sock, struct scm_co
> { }
> #endif /* CONFIG_SECURITY_NETWORK */
>
> +static __inline__ void scm_set_cred(struct scm_cookie *scm,
> + struct pid *pid, const struct cred *cred)
> +{
> + scm->pid = get_pid(pid);
> + scm->cred = get_cred(cred);
> + cred_to_ucred(pid, cred, &scm->creds);
> +}
> +
> +static __inline__ void scm_destroy_cred(struct scm_cookie *scm)
> +{
> + put_pid(scm->pid);
> + scm->pid = NULL;
> +
> + if (scm->cred)
> + put_cred(scm->cred);
> + scm->cred = NULL;
> +}
> +
> static __inline__ void scm_destroy(struct scm_cookie *scm)
> {
> + scm_destroy_cred(scm);
> if (scm && scm->fp)
> __scm_destroy(scm);
> }
> @@ -51,10 +72,7 @@ static __inline__ void scm_destroy(struct scm_cookie *scm)
> static __inline__ int scm_send(struct socket *sock, struct msghdr *msg,
> struct scm_cookie *scm)
> {
> - struct task_struct *p = current;
> - scm->creds.uid = current_uid();
> - scm->creds.gid = current_gid();
> - scm->creds.pid = task_tgid_vnr(p);
> + scm_set_cred(scm, task_tgid(current), current_cred());
> scm->fp = NULL;
> unix_get_peersec_dgram(sock, scm);
> if (msg->msg_controllen <= 0)
> @@ -96,6 +114,8 @@ static __inline__ void scm_recv(struct socket *sock, struct msghdr *msg,
> if (test_bit(SOCK_PASSCRED, &sock->flags))
> put_cmsg(msg, SOL_SOCKET, SCM_CREDENTIALS, sizeof(scm->creds), &scm->creds);
>
> + scm_destroy_cred(scm);
> +
> scm_passec(sock, msg, scm);
>
> if (!scm->fp)
> diff --git a/net/core/scm.c b/net/core/scm.c
> index b88f6f9..681c976 100644
> --- a/net/core/scm.c
> +++ b/net/core/scm.c
> @@ -170,6 +170,30 @@ int __scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie *p)
> err = scm_check_creds(&p->creds);
> if (err)
> goto error;
> +
I think this hunk needs to be documented. I.e. given that scm_send()
will call scm_set_cred() before calling __scm_send, I don't see how
these conditions could happen? If the condition can legitimately
happen, then given all of the pid_t vs struct pid and 'cred' vs. 'creds'
in these two hunks, I think a comment over each would be nice.
> + if (pid_vnr(p->pid) != p->creds.pid) {
> + struct pid *pid;
> + err = -ESRCH;
> + pid = find_get_pid(p->creds.pid);
> + if (!pid)
> + goto error;
> + put_pid(p->pid);
> + p->pid = pid;
> + }
> +
> + if ((p->cred->euid != p->creds.uid) ||
> + (p->cred->egid != p->creds.gid)) {
> + struct cred *cred;
> + err = -ENOMEM;
> + cred = prepare_creds();
> + if (!cred)
> + goto error;
> +
> + cred->uid = cred->euid = p->creds.uid;
> + cred->gid = cred->egid = p->creds.uid;
> + put_cred(p->cred);
> + p->cred = cred;
> + }
> break;
> default:
> goto error;
> --
> 1.6.5.2.143.g8cc62
>
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: [Bugme-new] [Bug 16187] New: Carrier detection failed in dhcpcd when link is up
From: Andrew Morton @ 2010-06-15 21:24 UTC (permalink / raw)
To: netdev, Grant Grundler, Kyle McMartin
Cc: bugzilla-daemon, bugme-daemon, casteyde.christian
In-Reply-To: <bug-16187-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Sat, 12 Jun 2010 15:15:31 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=16187
>
> Summary: Carrier detection failed in dhcpcd when link is up
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.35-rc2
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: acme@ghostprotocols.net
> ReportedBy: casteyde.christian@free.fr
> Regression: Yes
>
>
> Created an attachment (id=26742)
> --> (https://bugzilla.kernel.org/attachment.cgi?id=26742)
> lspci output for 2.6.34 on my computer
>
> Kernel at least 2.6.35-rc2, 2.6.34 works fine
Seems to be post-2.6.34 breakage in the tulip driver.
> Athlon X2 3000 in 64bits mode
> Slackware 13.1
> "Ethernet controller: ALi Corporation ULi 1689,1573 integrated ethernet. (rev
> 40)" (from lspci)
>
> Since 2.6.35-rc2 (didn't checked -rc1), dhcpcd hangs fails to detect carrier
> appearance at boot.
>
> The Slackware network script uses dhcpcd to bring DHCP interfaces up. At boot,
> it seems my network device doesn't have the link up immediatly. dhcpcd tries to
> bring it up, and wait for the carrier. The carrier indeed goes up, but dhcpcd
> gets absolutly no notification of that, and therefore times out.
>
> logs says that:
> Jun 12 16:53:58 sirius logger: /etc/rc.d/rc.inet1: /sbin/route add -net
> 127.0.0.0 netmask 255.0.0.0 lo
> Jun 12 16:53:58 sirius logger: /etc/rc.d/rc.inet1: /sbin/dhcpcd -t 10 eth0
> Jun 12 16:53:58 sirius dhcpcd: version 5.2.2 starting
> Jun 12 16:53:58 sirius kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
> Jun 12 16:53:58 sirius dhcpcd: eth0: waiting for carrier
> Jun 12 16:54:01 sirius kernel: uli526x: eth0 NIC Link is Up 100 Mbps Full
> duplex
> Jun 12 16:54:01 sirius kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes
> ready
> then dhcpcd times out a little later (10 seconds as -t 10 is specified).
>
> If I use the -K option (no carrier detection), and does ifconfig eth0 up just
> before issueing the dhcpcd command, dhcpcd doesn't wait for the carrier and
> gets a lease correctly.
>
> Reversely, with the 2.6.34 kernel, dhcpcd indeed gets the link up notification,
> and gets the lease immediatly. In this case, the log says:
>
> Jun 12 17:04:21 sirius logger: /etc/rc.d/rc.inet1: /sbin/route add -net
> 127.0.0.0 netmask 255.0.0.0 lo
> Jun 12 17:04:21 sirius logger: /etc/rc.d/rc.inet1: /sbin/dhcpcd -t 10 eth0
> Jun 12 17:04:22 sirius dhcpcd: version 5.2.2 starting
> Jun 12 17:04:22 sirius kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
> Jun 12 17:04:22 sirius dhcpcd: eth0: waiting for carrier
> Jun 12 17:04:25 sirius dhcpcd: eth0: carrier acquired
> Jun 12 17:04:25 sirius kernel: uli526x: eth0 NIC Link is Up 100 Mbps Full
> duplex
> Jun 12 17:04:25 sirius kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes
> ready
> Jun 12 17:04:25 sirius dhcpcd: eth0: broadcasting for a lease
> Jun 12 17:04:29 sirius dhcpcd: eth0: offered 192.168.1.3 from 192.168.1.1
> Jun 12 17:04:29 sirius dhcpcd: eth0: acknowledged 192.168.1.3 from 192.168.1.1
> Jun 12 17:04:29 sirius dhcpcd: eth0: checking for 192.168.1.3
> Jun 12 17:04:34 sirius dhcpcd: eth0: leased 192.168.1.3 for 864000 seconds
> Jun 12 17:04:34 sirius dhcpcd: forking to background
>
> As you can see, dhcpcd asks for a lease as soon as the kernel tells it the link
> is up (message "carrier acquired").
>
> Therefore, I think 2.6.35-rc* notification of carrier is broken, and at least
> it broke dhcpcd way of watching the link.
>
^ permalink raw reply
* Re: [PATCH net-next-2.6] inetpeer: RCU conversion
From: David Miller @ 2010-06-15 21:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, paulmck
In-Reply-To: <1276626194.2541.186.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 15 Jun 2010 20:23:14 +0200
> inetpeer currently uses an AVL tree protected by an rwlock.
>
> It's possible to make most lookups use RCU
...
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, nice work Eric.
^ permalink raw reply
* Re: [PATCH net-next 4/4] cnic: Fix cnic_cm_abort() error handling.
From: David Miller @ 2010-06-15 21:24 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1276628223-27125-4-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 15 Jun 2010 11:57:03 -0700
> Fix the code that handles the error case when cnic_cm_abort() cannot
> proceed normally. We cannot just set the csk->state and we must
> go through cnic_ready_to_close() to handle all the conditions. We
> also add error return code in cnic_cm_abort().
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> Signed-off-by: Eddie Wai <waie@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 3/4] cnic: Refactor and fix cnic_ready_to_close().
From: David Miller @ 2010-06-15 21:24 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1276628223-27125-3-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 15 Jun 2010 11:57:02 -0700
> Combine RESET_RECEIVED and RESET_COMP logic and fix race condition
> between these 2 events and cnic_cm_close(). In particular, we need
> to (test_and_clear_bit(SK_F_OFFLD_COMPLETE, &csk->flags)) before we
> update csk->state.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> Signed-off-by: Eddie Wai <waie@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/4] cnic: Refactor code in cnic_cm_process_kcqe().
From: David Miller @ 2010-06-15 21:24 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1276628223-27125-2-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 15 Jun 2010 11:57:01 -0700
> Move chip-specific code to the respective chip's ->close_conn() functions
> for better code organization.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> Signed-off-by: Eddie Wai <waie@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/4] cnic: Return error code in cnic_cm_close() if unsuccessful.
From: David Miller @ 2010-06-15 21:24 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1276628223-27125-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 15 Jun 2010 11:57:00 -0700
> So that bnx2i can handle the error condition immediately and not have to
> wait for timeout.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com.
> Signed-off-by: Eddie Wai <waie@broadcom.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ixgbe: update set_rx_mode to fix issues w/ macvlan
From: David Miller @ 2010-06-15 21:24 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, xma, alexander.h.duyck
In-Reply-To: <20100615192432.3011.29215.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 15 Jun 2010 12:25:48 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change corrects issues where macvlan was not correctly triggering
> promiscuous mode on ixgbe due to the filters not being correctly set. It
> also corrects the fact that VF rar filters were being overwritten when the
> PF was reset.
>
> CC: Shirley Ma <xma@us.ibm.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 00/17] netfilter: netfilter update
From: David Miller @ 2010-06-15 21:19 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1276616323-20880-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Tue, 15 Jun 2010 17:38:26 +0200
> Please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-next-2.6.git master
Pulled, thanks Patrick.
^ 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