* Re: [PATCH] Fix netdev_printk null dereference
From: Joe Perches @ 2010-03-05 14:50 UTC (permalink / raw)
To: David Miller; +Cc: steve.glendinning, netdev
In-Reply-To: <20100305.063909.26489418.davem@davemloft.net>
On Fri, 2010-03-05 at 06:39 -0800, David Miller wrote:
> From: Steve Glendinning <steve.glendinning@smsc.com>
> Date: Fri, 5 Mar 2010 12:47:05 +0000
>
> > This patch fixes a reproducible null dereference in smsc95xx (and I
> > suspect others) when the device is removed during a control register
> > access. This can be reproduced by rapidly plugging and unplugging
> > the device during its initialisation.
> >
> > Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
>
> The parent shouldn't become NULL until the device is totally quiesced
> and is no longer accesses.
>
> Maybe you can instead fix the smsc95xx driver to abide by this rule
> instead of adding a conditional check to thousands of other drivers in
> the tree that do not need this?
>
> I really have no intention of adding your change, please fix this
> properly, thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Perhaps something like this is appropriate in the mean time:
const char *get_netdev_parent_name(const struct net_device *dev)
{
if (!dev->dev.parent)
return "Unparented net_device, please report this";
return netdev->dev.parent;
}
^ permalink raw reply
* Re: KS8695: possible NAPI issue
From: Yegor Yefremov @ 2010-03-05 15:00 UTC (permalink / raw)
To: Figo.zhang; +Cc: Dick Hollenbeck, netdev, zealcook
In-Reply-To: <1267798077.2576.17.camel@myhost>
>> My tests look like following:
>>
>> 1. system start
>> 2. ping one host: O.K.
>> 3. nc -l -p 5000 > /var/test (about 1Mb): O.K.
>> 4. ping the same host: failed
> 1. type "arp" command, see the arp is exit or expire?
debian:~# nc -l -p 5000 > /var/zImage
debian:~# ping -c 1 192.168.1.38
PING 192.168.1.38 (192.168.1.38) 56(84) bytes of data.
>From 192.168.1.66 icmp_seq=1 Destination Host Unreachable
--- 192.168.1.38 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
debian:~# arp
Address HWtype HWaddress Flags Mask Iface
192.168.1.38 (incomplete) eth0
192.168.1.36 ether 00:10:18:39:19:aa C eth0
> 2. at this point, see is it still have RX interrpt and receive packet in
> ks8695_rx()? (in some watchpoint add printk).
I've inserted some printks and I can see that interrupts are coming
and the received count will be increased. I can also see my system
sending arp requests. Even this ping request is visible in wireshark
and its reply, but the ping utility sees nothing of it.
^ permalink raw reply
* Re: KS8695: possible NAPI issue
From: Yegor Yefremov @ 2010-03-05 15:03 UTC (permalink / raw)
To: Figo.zhang; +Cc: Dick Hollenbeck, netdev, zealcook
In-Reply-To: <1267797137.2576.11.camel@myhost>
On Fri, Mar 5, 2010 at 2:52 PM, Figo.zhang <figo1802@gmail.com> wrote:
>
>>
>> and even if the fourth test succeeds, if I then send a file from other
>> host the next ping or any other communication fails. I just tried to
>> make some SSH sessions. It goes without a problem till I issue a ping
>> after that.
>>
>> If I test the system with nuttcp I have no problem.
> the network driver seems work well for system. the "netcat" application
> is build in busybox? you can check busybox configure.
I'm using Debian for ARM. So it is standard netcat for Debian 5.0.
^ permalink raw reply
* Re: [PATCH] Fix netdev_printk null dereference
From: David Miller @ 2010-03-05 15:03 UTC (permalink / raw)
To: joe; +Cc: steve.glendinning, netdev
In-Reply-To: <1267800620.3832.17.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Fri, 05 Mar 2010 06:50:20 -0800
> On Fri, 2010-03-05 at 06:39 -0800, David Miller wrote:
>> From: Steve Glendinning <steve.glendinning@smsc.com>
>> Date: Fri, 5 Mar 2010 12:47:05 +0000
>>
>> > This patch fixes a reproducible null dereference in smsc95xx (and I
>> > suspect others) when the device is removed during a control register
>> > access. This can be reproduced by rapidly plugging and unplugging
>> > the device during its initialisation.
>> >
>> > Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
>>
>> The parent shouldn't become NULL until the device is totally quiesced
>> and is no longer accesses.
>>
>> Maybe you can instead fix the smsc95xx driver to abide by this rule
>> instead of adding a conditional check to thousands of other drivers in
>> the tree that do not need this?
>>
>> I really have no intention of adding your change, please fix this
>> properly, thanks.
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Perhaps something like this is appropriate in the mean time:
>
> const char *get_netdev_parent_name(const struct net_device *dev)
> {
> if (!dev->dev.parent)
> return "Unparented net_device, please report this";
> return netdev->dev.parent;
> }
Yes, but in the smsc95xx driver. :-)
^ permalink raw reply
* Re: [PATCH] Fix netdev_printk null dereference
From: David Miller @ 2010-03-05 15:43 UTC (permalink / raw)
To: Steve.Glendinning; +Cc: netdev
In-Reply-To: <OF33DF005A.0C447DF0-ON802576DD.00538FB8-802576DD.00552375@smsc.com>
From: Steve.Glendinning@smsc.com
Date: Fri, 5 Mar 2010 15:29:41 +0000
> The failure I'm seeing is caused when the usb device is disconnected.
> smsc95xx detects that a pending USB control operation failed
> and tries to print a message via netdev_printk to report this.
>
> Unfortunately, something else (the USB subsystem?) has already set
> parent to null at this time so the netdev_printk causes a null
> dereference.
>
> So netdev_printk suddenly changes from safe to use to unsafe to use?
It seems to me that really you only need this parent NULL check where
you notice the USB control operation failed and want to print a
message about that.
That should cover all the necessary cases shouldn't it?
Even more importantly, why does a USB disconnect NULL out the netdev
parent device pointer? Until you actually release this USB device in
the driver, the parent pointer should stay there.
^ permalink raw reply
* Re: [PATCH] Fix netdev_printk null dereference
From: Steve.Glendinning @ 2010-03-05 15:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100305.063909.26489418.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote on 05/03/2010 14:39:09:
> From: Steve Glendinning <steve.glendinning@smsc.com>
> Date: Fri, 5 Mar 2010 12:47:05 +0000
>
> > This patch fixes a reproducible null dereference in smsc95xx (and I
> > suspect others) when the device is removed during a control register
> > access. This can be reproduced by rapidly plugging and unplugging
> > the device during its initialisation.
> >
> > Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
>
> The parent shouldn't become NULL until the device is totally quiesced
> and is no longer accesses.
The failure I'm seeing is caused when the usb device is disconnected.
smsc95xx detects that a pending USB control operation failed
and tries to print a message via netdev_printk to report this.
Unfortunately, something else (the USB subsystem?) has already set
parent to null at this time so the netdev_printk causes a null
dereference.
So netdev_printk suddenly changes from safe to use to unsafe to use?
I could change all instances in smsc95xx to defensively check this
at each call, but what should I test to see if the device is still
valid? Is testing parent != null the correct thing to do?
I think other usbnet drivers may have the same problem, but I don't have
any hardware to test them.
> Maybe you can instead fix the smsc95xx driver to abide by this rule
> instead of adding a conditional check to thousands of other drivers in
> the tree that do not need this?
I agree it'd be better to avoid this check where it's unnecessary, but
if netdev_printk isn't necessarily safe to call for *removable* interfaces
then shouldn't all such callers be checking that it's safe to do so?
Steve
^ permalink raw reply
* Re: Help On function to get IPV6 address of an interface in kernel
From: Venkata Mohan Reddy @ 2010-03-05 15:49 UTC (permalink / raw)
To: Brian Haley; +Cc: netdev
In-Reply-To: <4B8FDD23.3070000@hp.com>
Thanks a lot Brain. ipv6_get_lladdr() helped me. Actually I want to get site-local or univeral(global) address. Though there is no direct function to get theseaddresses, ipv6_get_lladdr() shows how we can get the other addresses too.
Thanks,
Mohan Reddy
On Thu, Mar 04, 2010 at 11:17:39AM -0500, Brian Haley wrote:
> Mohan Reddy wrote:
> > Hi,
> >
> > Is there a function or a way in kernel to get an interface ipv6 address if interface name or net_device object is known? I searched in the kernel i got a function ipv6_get_ifaddr(). But it is expecting an ipv6 address as a parameter.
>
> What type of IPv6 address? For link-locals you can use ipv6_get_lladdr(), but
> for others ipv6_dev_get_saddr() is more comprehensive, but you'll need a
> destination address. There's lots of reference code in addrconf.c to do
> other things.
>
> -Brian
^ permalink raw reply
* Re: KS8695: possible NAPI issue
From: Stephen Hemminger @ 2010-03-05 16:22 UTC (permalink / raw)
To: Yegor Yefremov; +Cc: Figo.zhang, Dick Hollenbeck, netdev, zealcook
In-Reply-To: <f69abfc31003050700y57718a6aje3c1ff41d04748ae@mail.gmail.com>
On Fri, 5 Mar 2010 16:00:11 +0100
Yegor Yefremov <yegorslists@googlemail.com> wrote:
> >> My tests look like following:
> >>
> >> 1. system start
> >> 2. ping one host: O.K.
> >> 3. nc -l -p 5000 > /var/test (about 1Mb): O.K.
> >> 4. ping the same host: failed
> > 1. type "arp" command, see the arp is exit or expire?
>
> debian:~# nc -l -p 5000 > /var/zImage
>
> debian:~# ping -c 1 192.168.1.38
>
> PING 192.168.1.38 (192.168.1.38) 56(84) bytes of data.
>
> From 192.168.1.66 icmp_seq=1 Destination Host Unreachable
>
>
>
> --- 192.168.1.38 ping statistics ---
>
> 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
>
>
>
> debian:~# arp
>
> Address HWtype HWaddress Flags Mask Iface
> 192.168.1.38 (incomplete) eth0
>
> 192.168.1.36 ether 00:10:18:39:19:aa C eth0
>
>
> > 2. at this point, see is it still have RX interrpt and receive packet in
> > ks8695_rx()? (in some watchpoint add printk).
>
> I've inserted some printks and I can see that interrupts are coming
> and the received count will be increased. I can also see my system
> sending arp requests. Even this ping request is visible in wireshark
> and its reply, but the ping utility sees nothing of it.
One of the requirements for NAPI to work is that the IRQ is level triggered.
Otherwise there can be a race between packet arrival and the end of
NAPI processing:
static int ks8695_poll(struct napi_struct *napi, int budget)
{
struct ks8695_priv *ksp = container_of(napi, struct ks8695_priv, napi);
unsigned long work_done;
unsigned long isr = readl(KS8695_IRQ_VA + KS8695_INTEN);
unsigned long mask_bit = 1 << ks8695_get_rx_enable_bit(ksp);
work_done = ks8695_rx(ksp, budget);
if (work_done < budget) {
unsigned long flags;
spin_lock_irqsave(&ksp->rx_lock, flags);
>>> packet arrives >>
/*enable rx interrupt*/
writel(isr | mask_bit, KS8695_IRQ_VA + KS8695_INTEN);
>>> or here >>
__napi_complete(napi);
spin_unlock_irqrestore(&ksp->rx_lock, flags);
If the hardware can't be reprogrammed to level mode;
the solution used in some drivers is to poll for lost packet after re-enabling
NAPI.
--
^ permalink raw reply
* Re: [PATCH] Fix netdev_printk null dereference
From: Steve.Glendinning @ 2010-03-05 16:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100305.074335.248610315.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote on 05/03/2010 15:43:35:
> It seems to me that really you only need this parent NULL check where
> you notice the USB control operation failed and want to print a
> message about that.
>
> That should cover all the necessary cases shouldn't it?
That's the easily reproducible case - during initialisation there are
a lot of register reads and writes, so it's quite easy to trigger by
manually unplugging ~500ms after connection. In this case usbnet is
still in usbnet_probe.
Theoretically though, this device could be disconnected at any time,
and there are other places in the code where we print messages not
triggered by a usb failure (for example set_multicast). Could it
be possibly unsafe to call netdev_printk here?
> Even more importantly, why does a USB disconnect NULL out the netdev
> parent device pointer? Until you actually release this USB device in
> the driver, the parent pointer should stay there.
Most of the time it's not nulled out, and the code succesfully prints
errors as expected, but maybe 1 time in 20 dev.parent is NULL.
^ permalink raw reply
* Re: [PATCH] Fix netdev_printk null dereference
From: David Miller @ 2010-03-05 16:42 UTC (permalink / raw)
To: Steve.Glendinning; +Cc: netdev
In-Reply-To: <OFD404CD3D.9F15042C-ON802576DD.00595AB8-802576DD.005AD9A8@smsc.com>
From: Steve.Glendinning@smsc.com
Date: Fri, 5 Mar 2010 16:32:03 +0000
> David Miller <davem@davemloft.net> wrote on 05/03/2010 15:43:35:
>
>> Even more importantly, why does a USB disconnect NULL out the netdev
>> parent device pointer? Until you actually release this USB device in
>> the driver, the parent pointer should stay there.
>
> Most of the time it's not nulled out, and the code succesfully prints
> errors as expected, but maybe 1 time in 20 dev.parent is NULL.
I think until the device driver puts it's references and whatnot
of the device it's driving, that parent pointer should be kept
non-NULL.
As long as the netdevice exists and is registered, for example, people
can get at the parent device chain via SYSFS file accesses and
similar.
So it seems to me this is a huge problem waiting to happen anyways and
this netdev_printk() issue is merely making the problem more obvious
:-)
^ permalink raw reply
* bnx2x crash dump on high network load
From: Fischer, Anna @ 2010-03-05 17:07 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: eliezert@broadcom.com, eilong@broadcom.com, Michael Chan
[-- Attachment #1: Type: text/plain, Size: 540 bytes --]
I am seeing driver crashes with a bnx2x version 1.50.16. I have attached two crash dumps that I have captured.
I run Linux with the following kernel:
# uname -a
Linux sup-prj-441106 2.6.16.60-0.54.5-debug #1 SMP Fri Sep 4 01:28:03 UTC 2009 x86_64 x86_64 x86_64 GNU/Linux
I am seeing these driver crashes when I run virtual machines (VMware Server) and those VMs do high bandwidth network I/O, so there are a lot of packets going through the NIC.
Can you give me any hints for what the problem here could be?
Thanks,
Anna
[-- Attachment #2: sup-prj-441104-bnx-crash-dump.log --]
[-- Type: application/octet-stream, Size: 108012 bytes --]
[-- Attachment #3: sup-prj-441104-bnx-crash-dump2.log --]
[-- Type: application/octet-stream, Size: 105323 bytes --]
^ permalink raw reply
* RE: bnx2x crash dump on high network load
From: Eilon Greenstein @ 2010-03-05 17:31 UTC (permalink / raw)
To: Fischer, Anna; +Cc: eliezert, Michael Chan, netdev@vger.kernel.org
In-Reply-To: <0199E0D51A61344794750DC57738F58E6D79C12E3E@GVW1118EXC.americas.hpqcorp.net>
Hi Anna,
On this kernel, enabling bridging (like you do on virtualization) does not turn off LRO automatically. Please try to load the bnx2x with disable_tpa=1 (TPA is the HW based LRO feature).
Regards,
Eilon
-----Original Message-----
From: Fischer, Anna [mailto:anna.fischer@hp.com]
Sent: Friday, March 05, 2010 7:08 PM
To: netdev@vger.kernel.org
Cc: eliezert; Eilon Greenstein; Michael Chan
Subject: bnx2x crash dump on high network load
I am seeing driver crashes with a bnx2x version 1.50.16. I have attached two crash dumps that I have captured.
I run Linux with the following kernel:
# uname -a
Linux sup-prj-441106 2.6.16.60-0.54.5-debug #1 SMP Fri Sep 4 01:28:03 UTC 2009 x86_64 x86_64 x86_64 GNU/Linux
I am seeing these driver crashes when I run virtual machines (VMware Server) and those VMs do high bandwidth network I/O, so there are a lot of packets going through the NIC.
Can you give me any hints for what the problem here could be?
Thanks,
Anna
^ permalink raw reply
* net: smc91x: Support Qualcomm MSM development boards.
From: Daniel Walker @ 2010-03-05 19:12 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: David Brown, netdev
From: David Brown <davidb@quicinc.com>
Signed-off-by: David Brown <davidb@quicinc.com>
Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
---
drivers/net/smc91x.h | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
index 5479954..a6ee883 100644
--- a/drivers/net/smc91x.h
+++ b/drivers/net/smc91x.h
@@ -330,6 +330,20 @@ static inline void LPD7_SMC_outsw (unsigned char* a, int r,
#include <unit/smc91111.h>
+#elif defined(CONFIG_ARCH_MSM)
+
+#define SMC_CAN_USE_8BIT 0
+#define SMC_CAN_USE_16BIT 1
+#define SMC_CAN_USE_32BIT 0
+#define SMC_NOWAIT 1
+
+#define SMC_inw(a, r) readw((a) + (r))
+#define SMC_outw(v, a, r) writew(v, (a) + (r))
+#define SMC_insw(a, r, p, l) readsw((a) + (r), p, l)
+#define SMC_outsw(a, r, p, l) writesw((a) + (r), p, l)
+
+#define SMC_IRQ_FLAGS IRQF_TRIGGER_HIGH
+
#else
/*
--
1.6.3.3
^ permalink raw reply related
* Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.
From: Pavel Emelyanov @ 2010-03-05 19:18 UTC (permalink / raw)
To: Eric W. Biederman, Sukadev Bhattiprolu
Cc: Daniel Lezcano, Serge Hallyn, Linux Netdev List, containers,
Netfilter Development Mailinglist, Ben Greear
In-Reply-To: <m17hptjh3m.fsf@fess.ebiederm.org>
> 2 parallel enters? I meant you have pid 0 in the entered pid namespace.
> You have pid 0 because your pid simply does not map.
Oh, I see.
> There is nothing that makes to parallel enters impossible in that.
> Even today we have one thread per cpu that has task->pid == &init_struct_pid
> which is pid 0.
How about the forked processes then? Who will be their parent?
> For the case of unshare where we are designed to be used with PAM I don't
> think my proposed semantics work. For a join needed an extra fork before
> you are really in the pid namespace should be minor.
Hm... One more proposal - can we adopt the planned new fork_with_pids system
call to fork the process right into a new pid namespace?
> That doesn't handle the case of cached struct pids. A good example is
> waitpid, where it waits for a specific struct pid. Which means that
> allocating a new struct pid and changing task->pid will cause
> waitpid(pid) to wait forever...
OK. Good example. Thanks.
> To change struct pid would require the refcount on struct pid to show
> no references from anywhere except the task_struct.
I think this is OK to return -EBUSY for this. And fix the waitpid
respectively not to block this common case. All the others I think
can be stayed as is.
> At the cost of a little memory we can solve that problem for unshare
> if we have a an extra upid in struct pid, how we verify there is space
> in struct pid I'm not certain.
>
> I do think that at least until someone calls exec the namespace pids are
> reported to the process itself should not change. That is kill and
Wait a second - in that case the wait will be blocked too! No?
> waitpid etc. Which suggests an implementation the opposite of what
> I proposed. With ns_of_pid(task_pid(current)) being used as the
> pid namespace of children, and current->nsproxy->pid_ns not changing
> in the case of unshare.
>
> Shrug.
>
> Or perhaps this is a case where we use we can implement join with
> an extra process but we can't implement unshare, because the effect
> cannot be immediate.
Well, I'm talking only about the join now.
> Eric
>
^ permalink raw reply
* [PATCH] net: Fix race condition on receive path.
From: Daniel Walker @ 2010-03-05 19:34 UTC (permalink / raw)
To: David S. Miller; +Cc: Jim Harford, netdev
From: Jim Harford <c_jharfo@quicinc.com>
Fixes a race condition on the networking receive path that causes all
received packets to be dropped after 15-60 minutes of heavy network usage.
Function process_backlog() empties the receive queue, re-enables
interrupts, then "completes" the softIRQ. This provides a time window for
netif_rx() to execute (in IRQ context) and enqueue a received packet
without re-scheduling the softIRQ. After this, the receive queue is never
processed and the system eventually begins to drop all received packets.
The fix has netif_rx() calling napi_schedule(), whether or not the
receive queue is empty. There are two questions that must be addressed:
1) Is the fix correct? Or, is it safe to always call napi_schedule()?
2) Does the fix result in a performance degradation?
With respect to correctness, the napi softIRQ routine should NOT be
scheduled if it is already running. This is controlled by the bit flag
NAPI_STATE_SCHED in the "state" field of struct napi_struct. When this
flag is set, it means the softIRQ routine is either already pending or
currently running. When the softIRQ is finished, the bit is cleared via
__napi_complete(), which is called by napi_complete(), which is called by
process_backlog() after re-enabling interrupts and just prior to
returning.
When netif_rx() calls napi_schedule(), that routine checks the
NAPI_STATE_SCHED bit flag by calling napi_schedule_prep(), which calls
test_and_set_bit(); if the flag is already set, napi_schedule() returns
without doing anything. Note that test_and_set_bit() implements an
atomic "test and set" operation that is commonly used as the foundation
of mutual exclusion mechanisms.
So it is safe for netif_rx() to call napi_schedule(), whether or not the
receive queue is empty.
With respect to performance, the following behavior was observed using an
ARM CPU and cross-compiling for ARM using gcc. Removing the test of
whether the receive queue is empty saves 2 assembly instructions. The
addition of calling napi_schedule(), when that routine does nothing
(because the NAPI_STATE_SCHED flag is set) adds 11 assembly instructions.
Thus, there is a net addition of 9 assembly instructions. Furthermore,
we observe in our testing that even under heavy network load, the receive
queue is empty on at least 95% of netif_rx() invocations. The 9 assembly
instructions amortized over all netif_rx() invocations yield an average
performance penalty of less than 1 assembly instruction per invocation of
netif_rx(). Finally, the test-and-set operation does not entail testing
common memory shared by multiple CPU cores (which can be costly), because
the data structures in question are specific to a single CPU by design.
So calling napi_schedule() at every invocation of netif_rx() does not
impair performance.
CRs-fixed: 184599
Signed-off-by: Jim Harford <c_jharfo@quicinc.com>
Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
---
net/core/dev.c | 11 +++--------
1 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index be9924f..43161c6 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2150,15 +2150,10 @@ int netif_rx(struct sk_buff *skb)
__get_cpu_var(netdev_rx_stat).total++;
if (queue->input_pkt_queue.qlen <= netdev_max_backlog) {
- if (queue->input_pkt_queue.qlen) {
-enqueue:
- __skb_queue_tail(&queue->input_pkt_queue, skb);
- local_irq_restore(flags);
- return NET_RX_SUCCESS;
- }
-
+ __skb_queue_tail(&queue->input_pkt_queue, skb);
napi_schedule(&queue->backlog);
- goto enqueue;
+ local_irq_restore(flags);
+ return NET_RX_SUCCESS;
}
__get_cpu_var(netdev_rx_stat).dropped++;
--
1.6.3.3
^ permalink raw reply related
* Re: net: smc91x: Support Qualcomm MSM development boards.
From: Nicolas Pitre @ 2010-03-05 19:49 UTC (permalink / raw)
To: Daniel Walker; +Cc: David Brown, netdev
In-Reply-To: <1267816354.30393.4.camel@c-dwalke-linux.qualcomm.com>
On Fri, 5 Mar 2010, Daniel Walker wrote:
> From: David Brown <davidb@quicinc.com>
>
> Signed-off-by: David Brown <davidb@quicinc.com>
> Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
> ---
> drivers/net/smc91x.h | 14 ++++++++++++++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
> index 5479954..a6ee883 100644
> --- a/drivers/net/smc91x.h
> +++ b/drivers/net/smc91x.h
> @@ -330,6 +330,20 @@ static inline void LPD7_SMC_outsw (unsigned char* a, int r,
>
> #include <unit/smc91111.h>
>
> +#elif defined(CONFIG_ARCH_MSM)
> +
> +#define SMC_CAN_USE_8BIT 0
> +#define SMC_CAN_USE_16BIT 1
> +#define SMC_CAN_USE_32BIT 0
> +#define SMC_NOWAIT 1
> +
> +#define SMC_inw(a, r) readw((a) + (r))
> +#define SMC_outw(v, a, r) writew(v, (a) + (r))
> +#define SMC_insw(a, r, p, l) readsw((a) + (r), p, l)
> +#define SMC_outsw(a, r, p, l) writesw((a) + (r), p, l)
> +
> +#define SMC_IRQ_FLAGS IRQF_TRIGGER_HIGH
> +
> #else
>
> /*
> --
> 1.6.3.3
>
>
>
^ permalink raw reply
* Re: net: smc91x: Support Qualcomm MSM development boards.
From: Daniel Walker @ 2010-03-05 20:05 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: David Brown, netdev
In-Reply-To: <alpine.LFD.2.00.1003051449000.31128@xanadu.home>
On Fri, 2010-03-05 at 14:49 -0500, Nicolas Pitre wrote:
> On Fri, 5 Mar 2010, Daniel Walker wrote:
>
> > From: David Brown <davidb@quicinc.com>
> >
> > Signed-off-by: David Brown <davidb@quicinc.com>
> > Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
>
> Acked-by: Nicolas Pitre <nico@fluxnic.net>
>
>
Are you going to send it up stream, or should I?
Daniel
^ permalink raw reply
* Re: net: smc91x: Support Qualcomm MSM development boards.
From: David Miller @ 2010-03-05 20:09 UTC (permalink / raw)
To: dwalker; +Cc: nico, davidb, netdev
In-Reply-To: <1267819507.30393.9.camel@c-dwalke-linux.qualcomm.com>
From: Daniel Walker <dwalker@codeaurora.org>
Date: Fri, 05 Mar 2010 12:05:07 -0800
> On Fri, 2010-03-05 at 14:49 -0500, Nicolas Pitre wrote:
>> On Fri, 5 Mar 2010, Daniel Walker wrote:
>>
>> > From: David Brown <davidb@quicinc.com>
>> >
>> > Signed-off-by: David Brown <davidb@quicinc.com>
>> > Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
>>
>> Acked-by: Nicolas Pitre <nico@fluxnic.net>
>>
>>
>
> Are you going to send it up stream, or should I?
By virtue of having been properly posted to netdev it's in patchwork
and therefore I'll integrate it.
^ permalink raw reply
* Re: net: smc91x: Support Qualcomm MSM development boards.
From: Daniel Walker @ 2010-03-05 20:11 UTC (permalink / raw)
To: David Miller; +Cc: nico, davidb, netdev
In-Reply-To: <20100305.120945.51475611.davem@davemloft.net>
On Fri, 2010-03-05 at 12:09 -0800, David Miller wrote:
> From: Daniel Walker <dwalker@codeaurora.org>
> Date: Fri, 05 Mar 2010 12:05:07 -0800
>
> > On Fri, 2010-03-05 at 14:49 -0500, Nicolas Pitre wrote:
> >> On Fri, 5 Mar 2010, Daniel Walker wrote:
> >>
> >> > From: David Brown <davidb@quicinc.com>
> >> >
> >> > Signed-off-by: David Brown <davidb@quicinc.com>
> >> > Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
> >>
> >> Acked-by: Nicolas Pitre <nico@fluxnic.net>
> >>
> >>
> >
> > Are you going to send it up stream, or should I?
>
> By virtue of having been properly posted to netdev it's in patchwork
> and therefore I'll integrate it.
Well I didn't add [PATCH] to the subject , but I guess that doesn't
matter..
Ok.. Thanks.
Daniel
^ permalink raw reply
* Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.
From: Eric W. Biederman @ 2010-03-05 20:26 UTC (permalink / raw)
To: Pavel Emelyanov
Cc: Sukadev Bhattiprolu, Daniel Lezcano, Serge Hallyn,
Linux Netdev List, containers, Netfilter Development Mailinglist,
Ben Greear
In-Reply-To: <4B9158F5.5040205@parallels.com>
Pavel Emelyanov <xemul@parallels.com> writes:
>> 2 parallel enters? I meant you have pid 0 in the entered pid namespace.
>> You have pid 0 because your pid simply does not map.
>
> Oh, I see.
>
>> There is nothing that makes to parallel enters impossible in that.
>> Even today we have one thread per cpu that has task->pid == &init_struct_pid
>> which is pid 0.
>
> How about the forked processes then? Who will be their parent?
The normal rules of parentage apply. So the child will see simply
see it's parent as ppid == 0. If that child daemonizes it will become
a child of the pid namespaces init.
This is a lot like something that gets started from call_usermodehelper. It's
parent process is not a descendant of init either.
The implementation of the join is to simply change current->nsproxy->pid_ns.
Then to use it you simply fork to get a child in the target pid namespace.
>> For the case of unshare where we are designed to be used with PAM I don't
>> think my proposed semantics work. For a join needed an extra fork before
>> you are really in the pid namespace should be minor.
>
> Hm... One more proposal - can we adopt the planned new fork_with_pids system
> call to fork the process right into a new pid namespace?
In a lot of ways I like this idea of sys_hijack/sys_cloneat, and I
don't think anything I am doing fundamentally undermines it. The use
case of doing things in fork is that there is automatic inheritance of
everything. All of the namespaces and all of the control groups, and
possibly also the parent process. It does have the high cost that the
process we are copying from must be stopped because there are no locks
that let us take everything. I haven't looked at the recent proposals
to see if anyone has solved that problem cleanly.
If we can do a sys_hijack/sys_cloneat style of join, that means we can
afford a fork. At which point the my proposed pid namespace semantics
should be fine.
aka:
setns(NSTYPE_PID);
pid = fork();
if (pid == 0) {
getpid() == 2; /* Or whatever the first free pid is joined pid namespace */
getppid() == 0;
} else {
pid == 6400; /* Or whatever the first free pid is in the original pid namespace */
waitpid(pid);
}
>> That doesn't handle the case of cached struct pids. A good example is
>> waitpid, where it waits for a specific struct pid. Which means that
>> allocating a new struct pid and changing task->pid will cause
>> waitpid(pid) to wait forever...
>
> OK. Good example. Thanks.
>
>> To change struct pid would require the refcount on struct pid to show
>> no references from anywhere except the task_struct.
>
> I think this is OK to return -EBUSY for this. And fix the waitpid
> respectively not to block this common case. All the others I think
> can be stayed as is.
That would probably work. setsid() and setpgrp() have similar sorts
of restrictions. That is both more challenging and more limiting than
the semantics that come out of my unshare(CLONE_NEWPID) patch. So I
would prefer to keep this sort of thing as a last resort.
>> At the cost of a little memory we can solve that problem for unshare
>> if we have a an extra upid in struct pid, how we verify there is space
>> in struct pid I'm not certain.
>>
>> I do think that at least until someone calls exec the namespace pids are
>> reported to the process itself should not change. That is kill and
>
> Wait a second - in that case the wait will be blocked too! No?
If all we do is populate an unused struct upid in struct pid there
isn't a chance of a problem.
>> waitpid etc. Which suggests an implementation the opposite of what
>> I proposed. With ns_of_pid(task_pid(current)) being used as the
>> pid namespace of children, and current->nsproxy->pid_ns not changing
>> in the case of unshare.
>>
>> Shrug.
>>
>> Or perhaps this is a case where we use we can implement join with
>> an extra process but we can't implement unshare, because the effect
>> cannot be immediate.
>
> Well, I'm talking only about the join now.
Overall it sounds like the semantics I have proposed with
unshare(CLONE_NEWPID) are workable, and simple to implement. The
extra fork is a bit surprising but it certainly does not
look like a show stopper for implementing a pid namespace join.
Eric
^ permalink raw reply
* RE: [PATCH V3 6/8] tipc: use limited socket backlog
From: Stephens, Allan @ 2010-03-05 20:48 UTC (permalink / raw)
To: Zhu Yi; +Cc: netdev, Jon Maloy, davem, Eric Dumazet
In-Reply-To: <1267761707-15605-6-git-send-email-yi.zhu@intel.com>
>
> Make tipc adapt to the limited socket backlog change.
>
> Cc: Jon Maloy <jon.maloy@ericsson.com>
> Cc: Allan Stephens <allan.stephens@windriver.com>
> Signed-off-by: Zhu Yi <yi.zhu@intel.com>
>From visual inspection and basic sanity testing:
Acked-by: Allan Stephens <allan.stephens@windriver.com>
Nice work!
-- Al
^ permalink raw reply
* Re: net: smc91x: Support Qualcomm MSM development boards.
From: Nicolas Pitre @ 2010-03-05 20:57 UTC (permalink / raw)
To: Daniel Walker; +Cc: David Brown, netdev
In-Reply-To: <1267819507.30393.9.camel@c-dwalke-linux.qualcomm.com>
On Fri, 5 Mar 2010, Daniel Walker wrote:
> On Fri, 2010-03-05 at 14:49 -0500, Nicolas Pitre wrote:
> > On Fri, 5 Mar 2010, Daniel Walker wrote:
> >
> > > From: David Brown <davidb@quicinc.com>
> > >
> > > Signed-off-by: David Brown <davidb@quicinc.com>
> > > Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
> >
> > Acked-by: Nicolas Pitre <nico@fluxnic.net>
> >
> >
>
> Are you going to send it up stream, or should I?
Please do it.
Nicolas
^ permalink raw reply
* Re: net: smc91x: Support Qualcomm MSM development boards.
From: Nicolas Pitre @ 2010-03-05 20:57 UTC (permalink / raw)
To: David Miller; +Cc: dwalker, davidb, netdev
In-Reply-To: <20100305.120945.51475611.davem@davemloft.net>
On Fri, 5 Mar 2010, David Miller wrote:
> From: Daniel Walker <dwalker@codeaurora.org>
> Date: Fri, 05 Mar 2010 12:05:07 -0800
>
> > On Fri, 2010-03-05 at 14:49 -0500, Nicolas Pitre wrote:
> >> On Fri, 5 Mar 2010, Daniel Walker wrote:
> >>
> >> > From: David Brown <davidb@quicinc.com>
> >> >
> >> > Signed-off-by: David Brown <davidb@quicinc.com>
> >> > Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
> >>
> >> Acked-by: Nicolas Pitre <nico@fluxnic.net>
> >>
> >>
> >
> > Are you going to send it up stream, or should I?
>
> By virtue of having been properly posted to netdev it's in patchwork
> and therefore I'll integrate it.
Good.
Nicolas
^ permalink raw reply
* Re: [PATCH] net: Fix race condition on receive path.
From: Stephen Hemminger @ 2010-03-05 21:21 UTC (permalink / raw)
To: Daniel Walker; +Cc: David S. Miller, Jim Harford, netdev
In-Reply-To: <1267817699.30393.8.camel@c-dwalke-linux.qualcomm.com>
On Fri, 05 Mar 2010 11:34:59 -0800
Daniel Walker <dwalker@codeaurora.org> wrote:
> Fixes a race condition on the networking receive path that causes all
> received packets to be dropped after 15-60 minutes of heavy network usage.
> Function process_backlog() empties the receive queue, re-enables
> interrupts, then "completes" the softIRQ. This provides a time window for
> netif_rx() to execute (in IRQ context) and enqueue a received packet
> without re-scheduling the softIRQ. After this, the receive queue is never
> processed and the system eventually begins to drop all received packets.
I wonder why this hasn't shown up before?
Where exactly is the window between empty process_backlog and netif_rx?
Maybe it is ARM specific behavior of softirq?
^ permalink raw reply
* Re: [PATCH V3 8/8] net: backlog functions rename
From: David Miller @ 2010-03-05 21:36 UTC (permalink / raw)
To: eric.dumazet; +Cc: yi.zhu, netdev
In-Reply-To: <1267770735.2867.9.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 05 Mar 2010 07:32:15 +0100
> Le vendredi 05 mars 2010 à 12:01 +0800, Zhu Yi a écrit :
>> sk_add_backlog -> __sk_add_backlog
>> sk_add_backlog_limited -> sk_add_backlog
>>
>> Signed-off-by: Zhu Yi <yi.zhu@intel.com>
>> ---
>> include/net/sock.h | 6 +++---
>> net/core/sock.c | 2 +-
>> net/dccp/minisocks.c | 2 +-
>> net/ipv4/tcp_ipv4.c | 2 +-
>> net/ipv4/tcp_minisocks.c | 2 +-
>> net/ipv4/udp.c | 2 +-
>> net/ipv6/tcp_ipv6.c | 2 +-
>> net/ipv6/udp.c | 4 ++--
>> net/llc/llc_c_ac.c | 2 +-
>> net/llc/llc_conn.c | 2 +-
>> net/sctp/input.c | 4 ++--
>> net/tipc/socket.c | 2 +-
>> net/x25/x25_dev.c | 2 +-
>> 13 files changed, 17 insertions(+), 17 deletions(-)
>>
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
All 8 patches applied to net-2.6, thanks Zhu!
Feel free to send me a patch which adds the "__must_check"
tag to sk_add_backlog() so that any failure to check and
drop packets will be at least warned about.
Thanks!
^ 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