* Re: [PATCH 1/5 v2]wireless:hostap_main.c warning: variable 'iface' set but not used
From: Justin P. Mattock @ 2010-06-22 18:34 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100622181320.GD2583@tuxdriver.com>
On 06/22/2010 11:13 AM, John W. Linville wrote:
> On Mon, Jun 21, 2010 at 03:02:13PM -0700, Justin P. Mattock wrote:
>> This is a resend from version one due to trying a different approach
>> than the original(probably important to leave netdev_priv() in).
>>
>> In any case have a look, if there's another approach let me know
>> and ill test it out. The below patch fixes a warning im seeing
>> when compiling with gcc 4.6.0
>>
>> CC [M] drivers/net/wireless/hostap/hostap_main.o
>> drivers/net/wireless/hostap/hostap_main.c: In function 'hostap_set_multicast_list_queue':
>> drivers/net/wireless/hostap/hostap_main.c:744:27: warning: variable 'iface' set but not used
>> Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>
> I already applied the other version to wireless-next-2.6. I can't
> imagine what you mean to accomplish by leaving in a call to netdev_priv
> w/o assigning the result to something.
>
> John
alright..
as for the netdev_priv, I was getting confused on this one.
Thanks for taking the time to look at this.
Justin P. Mattock
^ permalink raw reply
* Re: can multi app capture on same NIC?(use packet_mmap)
From: Paul LeoNerd Evans @ 2010-06-22 18:31 UTC (permalink / raw)
To: Jon Zhou, netdev
In-Reply-To: <4A6A2125329CFD4D8CC40C9E8ABCAB9F24985FE8F8@MILEXCH2.ds.jdsu.net>
[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]
On Tue, Jun 22, 2010 at 02:40:13AM -0700, Jon Zhou wrote:
> I'd like to know multi-app can work with packet_mmap (or traditional AF_PACKET system call)?
> i.e.
> app1 & app2 capture on the same NIC
>
> will both of them receive the same packet?
>
> Or this situation will happen?
>
> 1.app1 start to receive a packet#1
> 2.app1 complete receiving, then set the packet_status->TP_STATUS_KERNEL
> 3.how about app2 at this time? Will it see packet_status=KERNEL, then packet#1 got lost?
Sure; each PF_PACKET socket gets its own memory buffer.
> I tried to find the relevant code in af_packet.c, seems it doesn't guarantee multi-app capture on same NIC?
> Can someone help to point it out?
That's because af_packet.c doesn't need to care. All the relevant code
is found in net/core/dev.c
PF_PACKET sockets get installed into the ptype_all list:
void dev_add_pack(struct packet_type *pt)
{
int hash;
spin_lock_bh(&ptype_lock);
if (pt->type == htons(ETH_P_ALL))
list_add_rcu(&pt->list, &ptype_all);
...
Thereafter, every packet that's received is delivered, individually, to
every handler in that list:
int netif_receive_skb(struct sk_buff *skb)
{
...
list_for_each_entry_rcu(ptype, &ptype_all, list) {
if (ptype->dev == null_or_orig || ptype->dev == skb->dev ||
ptype->dev == orig_dev) {
if (pt_prev)
ret = deliver_skb(skb, pt_prev, orig_dev);
...
Finally, in net/packet/af_packet.c, each PF_PACKET socket gets a copy of
this skb anyway; look for the call to skb_copy_bits() in the function
tpacket_rcv()
Hope that helps,
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5 v2]wireless:hostap_main.c warning: variable 'iface' set but not used
From: John W. Linville @ 2010-06-22 18:13 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1277157733-14071-1-git-send-email-justinmattock@gmail.com>
On Mon, Jun 21, 2010 at 03:02:13PM -0700, Justin P. Mattock wrote:
> This is a resend from version one due to trying a different approach
> than the original(probably important to leave netdev_priv() in).
>
> In any case have a look, if there's another approach let me know
> and ill test it out. The below patch fixes a warning im seeing
> when compiling with gcc 4.6.0
>
> CC [M] drivers/net/wireless/hostap/hostap_main.o
> drivers/net/wireless/hostap/hostap_main.c: In function 'hostap_set_multicast_list_queue':
> drivers/net/wireless/hostap/hostap_main.c:744:27: warning: variable 'iface' set but not used
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
I already applied the other version to wireless-next-2.6. I can't
imagine what you mean to accomplish by leaving in a call to netdev_priv
w/o assigning the result to something.
John
--
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
* Re: pull request: wireless-2.6 2010-06-22
From: David Miller @ 2010-06-22 17:54 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100622174136.GC2583@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 22 Jun 2010 13:41:37 -0400
> Just a single fix this time, a patch for ath5k to avoid a null pointer
> dereference that can happen when executing certain operations against a
> newly created interface. This is, of course, intended for 2.6.35.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* [PATCH net-next-2.6] arp: RCU change in arp_solicit()
From: Eric Dumazet @ 2010-06-22 17:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Avoid two atomic ops in arp_solicit()
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/arp.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index cf78f41..09ead1b 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -333,11 +333,14 @@ static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb)
struct net_device *dev = neigh->dev;
__be32 target = *(__be32*)neigh->primary_key;
int probes = atomic_read(&neigh->probes);
- struct in_device *in_dev = in_dev_get(dev);
+ struct in_device *in_dev;
- if (!in_dev)
+ rcu_read_lock();
+ in_dev = __in_dev_get_rcu(dev);
+ if (!in_dev) {
+ rcu_read_unlock();
return;
-
+ }
switch (IN_DEV_ARP_ANNOUNCE(in_dev)) {
default:
case 0: /* By default announce any local IP */
@@ -358,9 +361,8 @@ static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb)
case 2: /* Avoid secondary IPs, get a primary/preferred one */
break;
}
+ rcu_read_unlock();
- if (in_dev)
- in_dev_put(in_dev);
if (!saddr)
saddr = inet_select_addr(dev, target, RT_SCOPE_LINK);
^ permalink raw reply related
* pull request: wireless-2.6 2010-06-22
From: John W. Linville @ 2010-06-22 17:41 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Just a single fix this time, a patch for ath5k to avoid a null pointer
dereference that can happen when executing certain operations against a
newly created interface. This is, of course, intended for 2.6.35.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 25442e06d20aaba7d7b16438078a562b3e4cf19b:
stephen hemminger (1):
bridge: fdb cleanup runs too often
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Bob Copeland (1):
ath5k: initialize ah->ah_current_channel
drivers/net/wireless/ath/ath5k/attach.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/attach.c b/drivers/net/wireless/ath/ath5k/attach.c
index e0c244b..31c0080 100644
--- a/drivers/net/wireless/ath/ath5k/attach.c
+++ b/drivers/net/wireless/ath/ath5k/attach.c
@@ -126,6 +126,7 @@ int ath5k_hw_attach(struct ath5k_softc *sc)
ah->ah_ant_mode = AR5K_ANTMODE_DEFAULT;
ah->ah_noise_floor = -95; /* until first NF calibration is run */
sc->ani_state.ani_mode = ATH5K_ANI_MODE_AUTO;
+ ah->ah_current_channel = &sc->channels[0];
/*
* Find the mac version
--
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 net-next-2.6 v2] net: Introduce u64_stats_sync infrastructure
From: Eric Dumazet @ 2010-06-22 17:31 UTC (permalink / raw)
To: David Miller; +Cc: npiggin, netdev, bhutchings
In-Reply-To: <20100622.102455.232729115.davem@davemloft.net>
Le mardi 22 juin 2010 à 10:24 -0700, David Miller a écrit :
> That's a really weird patch hunk for a newly added file.
>
> The hunk header is saying that the new file start 1 line
> in. Which doesn't make any sense, and GIT reject this
> saying that you're trying to make a modification to a
> file which doesn't exist.
>
> I applied this by hand, but I really wonder how you managed
> to create such a patch :-)
Now you mention it, I remember I had problems about this newly added
file, and had to use several git commands to stabilize my tree.
I really dont know what happened exactly, sorry :!)
Thanks !
^ permalink raw reply
* Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
From: James Bottomley @ 2010-06-22 17:26 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: lethal, davem, mchan, vapier, netdev, linux-parisc, linux-kernel
In-Reply-To: <20100622152823R.fujita.tomonori@lab.ntt.co.jp>
On Tue, 2010-06-22 at 15:30 +0900, FUJITA Tomonori wrote:
> On Fri, 18 Jun 2010 00:30:51 +0900
> Paul Mundt <lethal@linux-sh.org> wrote:
>
> > On Thu, Jun 17, 2010 at 11:50:35PM +0900, FUJITA Tomonori wrote:
> > > On Thu, 17 Jun 2010 07:36:53 -0700 (PDT)
> > > David Miller <davem@davemloft.net> wrote:
> > >
> > > > From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> > > > Date: Thu, 17 Jun 2010 21:21:13 +0900
> > > >
> > > > > On Wed, 16 Jun 2010 23:24:44 -0700
> > > > > "Michael Chan" <mchan@broadcom.com> wrote:
> > > > >
> > > > >> David, why is dma_is_consistent() always returning 1 on sparc? The
> > > > >> streaming DMA is not consistent.
> > > > >
> > > > > I think that there are some confusion about dma_is_consistent(). Some
> > > > > architectures think that dma_is_consistent() is supposed to return 1
> > > > > if they can allocate coherent memory (note that some architectures
> > > > > can't allocate coherent memory).
> > > >
> > > > Right, and that's why it's defined this way.
> > > >
> > > > If the desired meaning is different, just me know and I'll fix the
> > > > sparc definition.
> > >
> > > I think that there are some other architectures do the same. We need
> > > to make sure that all the architectures define dma_is_consistent() in
> > > the same meaning if drivers need it. However, I'm not sure we really
> > > need dma_is_consistent(). There is only one user of it (and I think we
> > > could remove it).
> > >
> > > In the bnx2 case, we can simply prefetch on all the archs (or just
> > > remove the optimization).
> >
> > I think its worthwhile keeping, especially since the consistency can vary
> > on a per struct device level. If there's a benefit with these sorts of
> > prefetch micro-optimizations in drivers when it doesn't cost us that much
> > to provide the hint, I don't really see the harm. If dma_is_consistent()
> > is suddenly supposed to take on other meanings, or it's supposed to mean
> > something entirely different, then this is something we should deal with
> > separately.
> >
> > I don't see any harm in letting drivers know whether we can support
> > consistent DMA allocs for a given struct device or not though, even if
> > the micro-optimization is marginal at best.
>
> I'm happier with exporting less DMA APIs to drivers because looks like
> new original ways to use the APIs wrongly can be always invented.
>
>
> > At least I've conditionalized the definition on SH, and it seems other
> > archictures have done so too. It's not clear what we'd gain from throwing
>
> >From a quick look, except for SH and POWERPC (and always-coherent
> architectures), everyone does differently?
>
> There are architectures that need to turn off the CPU cache for
> coherent memory, I can't find none of them that see if an address is
> coherent or not in dma_is_consistent().
Yes, I fear ... parisc. We have a class of machines where this is the
only way (and we also have a class of machines where the cache disable
doesn't work properly and we can't manufacture coherent memory at all).
All our pa2.0 systems are fully integrated between the iommu cache and
the CPU cache, so they can manufacture coherent memory properly, but the
pa1.0 systems are a mixed bag of dirty tricks.
> As I wrote, there is only one user of this API and we can remove it
> easily. Then I'm not sure it's worth fixing dma_is_consistent() in
> many architectures. I prefer to add this to
> feature-removal-schedule.txt to see if driver writers oppose.
Let me check our two drivers: lasi and 53c700; they're the only ones we
support on the architecture that can't do any coherence. I think we
don't need to tell because the dma_sync_cache calls which replace
coherent memory handling are indirected on the platform so we don't need
a global dma_is_coherent() flag.
James
^ permalink raw reply
* Re: [PATCH net-next-2.6] bridge: 64bit rx/tx counters
From: David Miller @ 2010-06-22 17:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, netdev, bhutchings, npiggin
In-Reply-To: <1276598376.2541.93.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 15 Jun 2010 12:39:36 +0200
> Note : should be applied after "net: Introduce
> u64_stats_sync infrastructure", if accepted.
>
>
> Thanks
>
> [PATCH net-next-2.6] bridge: 64bit rx/tx counters
>
> Use u64_stats_sync infrastructure to provide 64bit rx/tx
> counters even on 32bit hosts.
>
> It is safe to use a single u64_stats_sync for rx and tx,
> because BH is disabled on both, and we use per_cpu data.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] net: Introduce u64_stats_sync infrastructure
From: David Miller @ 2010-06-22 17:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: npiggin, netdev, bhutchings
In-Reply-To: <1276608594.2541.119.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 15 Jun 2010 15:29:54 +0200
> diff --git a/include/linux/u64_stats_sync.h b/include/linux/u64_stats_sync.h
> index e69de29..5a4f318 100644
> --- a/include/linux/u64_stats_sync.h
> +++ b/include/linux/u64_stats_sync.h
> @@ -0,0 +1,107 @@
> +#ifndef _LINUX_U64_STATS_SYNC_H
> +#define _LINUX_U64_STATS_SYNC_H
> +
That's a really weird patch hunk for a newly added file.
The hunk header is saying that the new file start 1 line
in. Which doesn't make any sense, and GIT reject this
saying that you're trying to make a modification to a
file which doesn't exist.
I applied this by hand, but I really wonder how you managed
to create such a patch :-)
^ permalink raw reply
* Re: Link-local address handling for IPv4
From: Eric Dumazet @ 2010-06-22 17:21 UTC (permalink / raw)
To: Fischer, Anna; +Cc: netdev
In-Reply-To: <0199E0D51A61344794750DC57738F58E739702DDAE@GVW1118EXC.americas.hpqcorp.net>
Le mardi 22 juin 2010 à 13:17 +0000, Fischer, Anna a écrit :
> Hi,
>
> Does the Linux kernel network stack do any specific handling of
> link-local address configuration and handling according to RFC 3927?
> I know that there is user-level code like Zeroconf / Avahi and these
> tools create ARP sockets directly on the specified network interfaces
> in order to support link-local address handling. But if I do not
> run any of these tools, does the kernel's ARP code take care of this, too?
>
There is no RFC 3927 support in kernel, you need user space support (or
switch to DHCP ;) )
Note that ARP replies MUST also be broadcasted for this particular
169.254/16 network (RFC 3927, 2.5), you need a kernel patch too, this
was discussed 4 years ago on netdev, and nothing was decided/changed.
http://marc.info/?l=linux-netdev&m=114427223811197&w=2
BTW I believe that our forwarding path doesnt test source/destination
address not being part of 169.254/16 network, I am not sure it
is a real problem or not. A netfilter rule can fix it eventually.
7. Router Considerations
A router MUST NOT forward a packet with an IPv4 Link-Local source or
destination address, irrespective of the router's default route
configuration or routes obtained from dynamic routing protocols.
A router which receives a packet with an IPv4 Link-Local source or
destination address MUST NOT forward the packet. This prevents
forwarding of packets back onto the network segment from which they
originated, or to any other segment.
^ permalink raw reply
* Re: inconsistent lock state
From: Paul E. McKenney @ 2010-06-22 17:17 UTC (permalink / raw)
To: Andrew Morton
Cc: Sergey Senozhatsky, Alexander Viro, Peter Zijlstra, Sage Weil,
linux-fsdevel, linux-kernel, Dominik Brodowski, Maciej Rutecki,
Eric Dumazet, Lai Jiangshan, David S. Miller, netdev
In-Reply-To: <20100618133004.228c2223.akpm@linux-foundation.org>
On Fri, Jun 18, 2010 at 01:30:04PM -0700, Andrew Morton wrote:
>
> This was also reported by Dominik and is being tracked at
> https://bugzilla.kernel.org/show_bug.cgi?id=16230
>
> On Tue, 15 Jun 2010 14:24:34 +0300
> Sergey Senozhatsky <sergey.senozhatsky@gmail.com> wrote:
>
> > Hello,
> >
> > kernel: [ 3272.351191]
> > kernel: [ 3272.351194] =================================
> > kernel: [ 3272.351199] [ INFO: inconsistent lock state ]
> > kernel: [ 3272.351204] 2.6.35-rc3-dbg-00106-ga75e02b-dirty #15
> > kernel: [ 3272.351206] ---------------------------------
> > kernel: [ 3272.351210] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> > kernel: [ 3272.351215] X/3827 [HC0[0]:SC0[0]:HE1:SE1] takes:
> > kernel: [ 3272.351218] (&(&new->fa_lock)->rlock){?.-...}, at: [<c10aefb4>] kill_fasync+0x37/0x71
> > kernel: [ 3272.351232] {IN-HARDIRQ-W} state was registered at:
> > kernel: [ 3272.351235] [<c104e95c>] __lock_acquire+0x281/0xbe1
> > kernel: [ 3272.351243] [<c104f652>] lock_acquire+0x59/0x70
> > kernel: [ 3272.351248] [<c12c6c48>] _raw_spin_lock+0x25/0x34
> > kernel: [ 3272.351255] [<c10aefb4>] kill_fasync+0x37/0x71
> > kernel: [ 3272.351261] [<fd220c81>] evdev_event+0x135/0x190 [evdev]
> > kernel: [ 3272.351275] [<c1232003>] input_pass_event+0x6f/0xae
> > kernel: [ 3272.351283] [<c1232ef5>] input_handle_event+0x38d/0x396
> > kernel: [ 3272.351288] [<c1232fbf>] input_event+0x4f/0x62
> > kernel: [ 3272.351293] [<c12368e4>] input_sync+0xe/0x11
> > kernel: [ 3272.351299] [<c1236d72>] atkbd_interrupt+0x48b/0x541
> > kernel: [ 3272.351304] [<c122ecb2>] serio_interrupt+0x35/0x68
> > kernel: [ 3272.351309] [<c122fbff>] i8042_interrupt+0x264/0x26e
> > kernel: [ 3272.351314] [<c106bb02>] handle_IRQ_event+0x1d/0x98
> > kernel: [ 3272.351321] [<c106d506>] handle_edge_irq+0xc0/0x107
> > kernel: [ 3272.351326] [<c10045ca>] handle_irq+0x1a/0x20
> > kernel: [ 3272.351332] [<c100435f>] do_IRQ+0x43/0x8d
> > kernel: [ 3272.351337] [<c1002d75>] common_interrupt+0x35/0x3c
> > kernel: [ 3272.351342] [<c124723d>] cpuidle_idle_call+0x6a/0xa0
> > kernel: [ 3272.351349] [<c100170d>] cpu_idle+0x89/0xbe
> > kernel: [ 3272.351354] [<c12b6d11>] rest_init+0xb5/0xba
> > kernel: [ 3272.351361] [<c148a7bf>] start_kernel+0x33b/0x340
> > kernel: [ 3272.351368] [<c148a0c9>] i386_start_kernel+0xc9/0xd0
> > kernel: [ 3272.351374] irq event stamp: 54104917
> > kernel: [ 3272.351377] hardirqs last enabled at (54104917): [<c12c70f2>] _raw_spin_unlock_irqrestore+0x36/0x5b
> > kernel: [ 3272.351384] hardirqs last disabled at (54104916): [<c12c6ced>] _raw_spin_lock_irqsave+0x13/0x42
> > kernel: [ 3272.351391] softirqs last enabled at (54104732): [<c1032cf2>] __do_softirq+0xfd/0x10c
> > kernel: [ 3272.351398] softirqs last disabled at (54104703): [<c1032d30>] do_softirq+0x2f/0x47
> > kernel: [ 3272.351404]
> > kernel: [ 3272.351405] other info that might help us debug this:
> > kernel: [ 3272.351409] 3 locks held by X/3827:
> > kernel: [ 3272.351412] #0: (rcu_read_lock){.+.+..}, at: [<c124fdfa>] rcu_read_lock+0x0/0x26
> > kernel: [ 3272.351423] #1: (rcu_read_lock){.+.+..}, at: [<c124d5d9>] rcu_read_lock+0x0/0x26
> > kernel: [ 3272.351432] #2: (rcu_read_lock){.+.+..}, at: [<c10ae429>] rcu_read_lock+0x0/0x26
> > kernel: [ 3272.351442]
> > kernel: [ 3272.351443] stack backtrace:
> > kernel: [ 3272.351448] Pid: 3827, comm: X Not tainted 2.6.35-rc3-dbg-00106-ga75e02b-dirty #15
> > kernel: [ 3272.351451] Call Trace:
> > kernel: [ 3272.351456] [<c12c4ff1>] ? printk+0xf/0x11
> > kernel: [ 3272.351462] [<c104e51a>] valid_state+0x133/0x141
> > kernel: [ 3272.351468] [<c104e5f7>] mark_lock+0xcf/0x1b3
> > kernel: [ 3272.351473] [<c104e54e>] ? mark_lock+0x26/0x1b3
> > kernel: [ 3272.351479] [<c104dfd2>] ? check_usage_backwards+0x0/0x68
> > kernel: [ 3272.351484] [<c104e9d0>] __lock_acquire+0x2f5/0xbe1
> > kernel: [ 3272.351489] [<c104ea44>] ? __lock_acquire+0x369/0xbe1
> > kernel: [ 3272.351495] [<c104ea44>] ? __lock_acquire+0x369/0xbe1
> > kernel: [ 3272.351502] [<c102ab40>] ? try_to_wake_up+0x2a8/0x2bb
> > kernel: [ 3272.351508] [<c104f652>] lock_acquire+0x59/0x70
> > kernel: [ 3272.351513] [<c10aefb4>] ? kill_fasync+0x37/0x71
> > kernel: [ 3272.351519] [<c12c6c48>] _raw_spin_lock+0x25/0x34
> > kernel: [ 3272.351524] [<c10aefb4>] ? kill_fasync+0x37/0x71
> > kernel: [ 3272.351529] [<c10aefb4>] kill_fasync+0x37/0x71
> > kernel: [ 3272.351534] [<c124d694>] sock_wake_async+0x77/0x83
> > kernel: [ 3272.351540] [<c124fe4d>] sk_wake_async+0x2d/0x32
> > kernel: [ 3272.351545] [<c1250004>] sock_def_readable+0x45/0x51
> > kernel: [ 3272.351551] [<c12b0247>] unix_stream_sendmsg+0x1e2/0x269
> > kernel: [ 3272.351557] [<c124fe6e>] ? rcu_read_unlock+0x1c/0x1e
> > kernel: [ 3272.351562] [<c124cf1a>] __sock_sendmsg+0x51/0x5a
> > kernel: [ 3272.351567] [<c124cff7>] sock_aio_write+0xd4/0xdd
> > kernel: [ 3272.351575] [<c10a4d95>] do_sync_readv_writev+0x84/0xb7
> > kernel: [ 3272.351582] [<c10a4288>] ? copy_from_user+0x8/0xa
> > kernel: [ 3272.351587] [<c10a4e69>] ? rw_copy_check_uvector+0x55/0xc7
> > kernel: [ 3272.351594] [<c1164082>] ? security_file_permission+0xf/0x11
> > kernel: [ 3272.351599] [<c10a47e5>] ? rw_verify_area+0x90/0xac
> > kernel: [ 3272.351605] [<c10a4f58>] do_readv_writev+0x7d/0xdf
> > kernel: [ 3272.351610] [<c124cf23>] ? sock_aio_write+0x0/0xdd
> > kernel: [ 3272.351615] [<c1164082>] ? security_file_permission+0xf/0x11
> > kernel: [ 3272.351621] [<c10a47e5>] ? rw_verify_area+0x90/0xac
> > kernel: [ 3272.351626] [<c10a4ff3>] vfs_writev+0x39/0x42
> > kernel: [ 3272.351632] [<c10a5102>] sys_writev+0x3b/0x8c
> > kernel: [ 3272.351637] [<c10027d3>] sysenter_do_call+0x12/0x32
> >
>
> This, I think?
>
>
> From: Andrew Morton <akpm@linux-foundation.org>
>
> Fix a lockdep-splat-causing regression introduced by
>
> : commit 989a2979205dd34269382b357e6d4b4b6956b889
> : Author: Eric Dumazet <eric.dumazet@gmail.com>
> : AuthorDate: Wed Apr 14 09:55:35 2010 +0000
> : Commit: David S. Miller <davem@davemloft.net>
> : CommitDate: Wed Apr 21 16:19:29 2010 -0700
> :
> : fasync: RCU and fine grained locking
>
> kill_fasync() can be called from both process and hard-irq context, so
> fa_lock must be taken with IRQs disabled.
>
> Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16230
>
> Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
> Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> fs/fcntl.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff -puN fs/fcntl.c~fs-fcntlc-kill_fasync_rcu-fa_lock-must-be-irq-safe fs/fcntl.c
> --- a/fs/fcntl.c~fs-fcntlc-kill_fasync_rcu-fa_lock-must-be-irq-safe
> +++ a/fs/fcntl.c
> @@ -733,12 +733,14 @@ static void kill_fasync_rcu(struct fasyn
> {
> while (fa) {
> struct fown_struct *fown;
> + unsigned long flags;
> +
> if (fa->magic != FASYNC_MAGIC) {
> printk(KERN_ERR "kill_fasync: bad magic number in "
> "fasync_struct!\n");
> return;
> }
> - spin_lock(&fa->fa_lock);
> + spin_lock_irqsave(&fa->fa_lock, flags);
> if (fa->fa_file) {
> fown = &fa->fa_file->f_owner;
> /* Don't send SIGURG to processes which have not set a
> @@ -747,7 +749,7 @@ static void kill_fasync_rcu(struct fasyn
> if (!(sig == SIGURG && fown->signum == 0))
> send_sigio(fown, fa->fa_fd, band);
> }
> - spin_unlock(&fa->fa_lock);
> + spin_unlock_irqrestore(&fa->fa_lock, flags);
> fa = rcu_dereference(fa->fa_next);
> }
> }
> _
>
>
> afaict all other lockers of fa_lock are OK (but one never really knows
> with spin_lock_irq()).
>
> Guys, please review-and-ack and I'll get it merged up.
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [RFC] [PATCH] ethtool: Flags for fibre speed switching
From: David Miller @ 2010-06-22 17:17 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, jgarzik, linux-net-drivers
In-Reply-To: <1276543562.2074.41.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 14 Jun 2010 20:26:02 +0100
> ethtool.h currently defines only SUPPORTED_FIBRE to cover all fibre
> modes. However, SFP+ slots support both 1G and 10G fibre modules and
> some modules are dual-speed. Some drivers use the BASE-T flags for SFP+
> modules of all media types, but this is strictly incorrect and can be
> confusing as there are real BASE-T modules for SFP+. There should be
> distinct flags for fibre modes. However I'm not sure whether it's worth
> defining flags for each fibre mode (there are quite a few) or only for
> each speed.
>
> Similarly there is only ADVERTISED_FIBRE to cover all fibre modes.
> Although there is no AN protocol for fibre, an SFP+ NIC effectively
> autonegotiates its speed with the module. By default, an SFP+ NIC will
> accept both 1G and 10G modules and switch speed automatically. With a
> dual-speed module, the NIC driver can allow forcing the speed through
> ethtool, but unless it maintains some hidden state it must reset the
> speed whenever the module is hotplugged (perhaps accidentally). So it
> should be possible for the administrator to control speed selection in a
> sticky way through the advertising mask.
I'm fine with this, feel free to make a formal submission for
net-next-2.6
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface
From: David Miller @ 2010-06-22 17:15 UTC (permalink / raw)
To: shemminger; +Cc: joakim.tjernlund, netdev
In-Reply-To: <20100611084854.0680c014@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 11 Jun 2010 08:48:54 -0700
> The initial problem report was for a management application that used ICMP
> to check link availability.
That application is buggy, and even if we apply this patch it will
only properly function when speaking to systems in a non-default
configuration. And, it would be a non-default setting which, by your
own admission below, cannot function properly in valid interface
configurations.
It's easier to fix the app to work in all cases than to add another
sysctl knob hack for a segment of the world that can't seem to wrap
their head around the fact that our behavior is valid, specified, and
an explicit design decision meant to increase the chances of
successful communication between two systems.
> The default is disabled to maintain compatibility with previous behavior.
> This is not recommended for server systems because it makes fail over more
> difficult, and does not account for configurations where multiple interfaces
> have the same IP address.
The fact that the syctl knob, when enabled, can't even function properly
in this "multiple interfaces with same address" case is another reason I
have decided to not apply this.
^ permalink raw reply
* Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
From: Grant Grundler @ 2010-06-22 17:14 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: lethal, davem, mchan, vapier, JBottomley, netdev, linux-parisc,
linux-kernel
In-Reply-To: <20100622152823R.fujita.tomonori@lab.ntt.co.jp>
On Tue, Jun 22, 2010 at 03:30:08PM +0900, FUJITA Tomonori wrote:
...
> > I don't see any harm in letting drivers know whether we can support
> > consistent DMA allocs for a given struct device or not though, even if
> > the micro-optimization is marginal at best.
>
> I'm happier with exporting less DMA APIs to drivers because looks like
> new original ways to use the APIs wrongly can be always invented.
Agree.
...
> There are architectures that need to turn off the CPU cache for
> coherent memory, I can't find none of them that see if an address is
> coherent or not in dma_is_consistent().
parisc "knows" primarily based on chipset and then checks CPU model.
We hook in the correct dma_ops early in boot before any device drivers
are probed.
hth,
grant
^ permalink raw reply
* Re: [PATCH] hso: remove setting of low_latency flag
From: David Miller @ 2010-06-22 17:10 UTC (permalink / raw)
To: f.aben; +Cc: gregkh, linux-usb, netdev
In-Reply-To: <1276765415.1532.5.camel@filip-linux>
From: Filip Aben <f.aben@option.com>
Date: Thu, 17 Jun 2010 11:03:35 +0200
> Did the patch below get accepted or is there a problem with it ?
> Haven't seen it appearing in any git trees so far.
I've applied your patch.
^ permalink raw reply
* Re: 2.6.34 Crash in dmaengine_put()
From: Jeffrey Merkey @ 2010-06-22 16:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Andrew Morton, linux-kernel, Dan Williams, netdev
In-Reply-To: <1277217804.3057.428.camel@edumazet-laptop>
>
>> OK. This bug occurs if you OR in the IFF_UP flag while creating
>> virtual interfaces without going through the normal ifup/ifdown
>> scripts. Looks like a hole. I will post the trace shortly. It's
>> easy to reproduce, take the dummy net driver, OR in the IFF_UP flag in
>> dummy_setup, and watch the kernel crash.
>>
>
> Then dont do that ?
>
> No need to send us a trace, unless you use a pristine kernel.
>
> IFF_UP changes rules are very strict, dont try to avoid them and claim
> there is a hole or something wrong.
>
> Check __dev_open() , __dev_close() and __dev_change_flags() were OR/AND
> IFF_UP is done by core network.
>
> Net drivers are not allowed to change IFF_UP themselves.
>
> (DE-600 & DE-620 being the exceptions to confirm this rule, of course)
>
Gee. OK, its a bug. I see the crash when unregister_netdev is
called. Changing a flag in a driver should not cause the kernel to
crash. You should check the code. The dmaengine registration should
have nothing to do with registering a netdev -- period. I have coded
arounnd it but its damn convenient to create virtual drivers on the
fly and mark them as UP without needing to configure a bunch of text
scripts to bring one up or down.
The code itself is busted because it has a check if the dmaengine ref
count goes negative. If you are going to have a registration layer
the rest of the OS should not have to wonder about its disconnected
state. The busted code is right at the top of dmaengine_put where it
decrements the ref count then immediately jumps to a bug. Need a
better way here I think to prevent needless crashes. Someone could
just alter this flag remotely and crash a server -- HOLE - :)
Jeff
^ permalink raw reply
* Re: [PATCH] sky2: enable rx/tx in sky2_phy_reinit()
From: Mike McCormack @ 2010-06-22 14:57 UTC (permalink / raw)
To: Brandon Philips; +Cc: Stephen Hemminger, netdev, davem
In-Reply-To: <20100617022158.GA4135@jenkins.ifup.org>
Tested, and verified that it fixes the bug reported.
Tested-by: Mike McCormack <mikem@ring3k.org>
On 17 June 2010 11:21, Brandon Philips <brandon@ifup.org> wrote:
> sky2_phy_reinit is called by the ethtool helpers sky2_set_settings,
> sky2_nway_reset and sky2_set_pauseparam when netif_running.
>
> However, at the end of sky2_phy_init GM_GP_CTRL has GM_GPCR_RX_ENA and
> GM_GPCR_TX_ENA cleared. So, doing these commands causes the device to
> stop working:
>
> $ ethtool -r eth0
> $ ethtool -A eth0 autoneg off
>
> Fix this issue by enabling Rx/Tx after running sky2_phy_init in
> sky2_phy_reinit.
>
> Signed-off-by: Brandon Philips <bphilips@suse.de>
> Tested-by: Brandon Philips <bphilips@suse.de>
> Cc: stable@kernel.org
>
> ---
> drivers/net/sky2.c | 19 ++++++++++++++-----
> 1 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
> index 2111c7b..7985165 100644
> --- a/drivers/net/sky2.c
> +++ b/drivers/net/sky2.c
> @@ -717,11 +717,24 @@ static void sky2_phy_power_down(struct sky2_hw *hw, unsigned port)
> sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
> }
>
> +/* Enable Rx/Tx */
> +static void sky2_enable_rx_tx(struct sky2_port *sky2)
> +{
> + struct sky2_hw *hw = sky2->hw;
> + unsigned port = sky2->port;
> + u16 reg;
> +
> + reg = gma_read16(hw, port, GM_GP_CTRL);
> + reg |= GM_GPCR_RX_ENA | GM_GPCR_TX_ENA;
> + gma_write16(hw, port, GM_GP_CTRL, reg);
> +}
> +
> /* Force a renegotiation */
> static void sky2_phy_reinit(struct sky2_port *sky2)
> {
> spin_lock_bh(&sky2->phy_lock);
> sky2_phy_init(sky2->hw, sky2->port);
> + sky2_enable_rx_tx(sky2);
> spin_unlock_bh(&sky2->phy_lock);
> }
>
> @@ -2040,7 +2053,6 @@ static void sky2_link_up(struct sky2_port *sky2)
> {
> struct sky2_hw *hw = sky2->hw;
> unsigned port = sky2->port;
> - u16 reg;
> static const char *fc_name[] = {
> [FC_NONE] = "none",
> [FC_TX] = "tx",
> @@ -2048,10 +2060,7 @@ static void sky2_link_up(struct sky2_port *sky2)
> [FC_BOTH] = "both",
> };
>
> - /* enable Rx/Tx */
> - reg = gma_read16(hw, port, GM_GP_CTRL);
> - reg |= GM_GPCR_RX_ENA | GM_GPCR_TX_ENA;
> - gma_write16(hw, port, GM_GP_CTRL, reg);
> + sky2_enable_rx_tx(sky2);
>
> gm_phy_write(hw, port, PHY_MARV_INT_MASK, PHY_M_DEF_MSK);
>
> --
> 1.7.1
>
>
> --
> 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
>
^ permalink raw reply
* Re: 2.6.34 Crash in dmaengine_put()
From: Eric Dumazet @ 2010-06-22 14:43 UTC (permalink / raw)
To: Jeffrey Merkey; +Cc: Andrew Morton, linux-kernel, Dan Williams, netdev
In-Reply-To: <AANLkTimsDSrEL8vT877pLYSa4A338p4Y8w0Ya6Xm7BFJ@mail.gmail.com>
Le mardi 22 juin 2010 à 08:08 -0600, Jeffrey Merkey a écrit :
Please dont top post on lkml (or netdev) messages
> OK. This bug occurs if you OR in the IFF_UP flag while creating
> virtual interfaces without going through the normal ifup/ifdown
> scripts. Looks like a hole. I will post the trace shortly. It's
> easy to reproduce, take the dummy net driver, OR in the IFF_UP flag in
> dummy_setup, and watch the kernel crash.
>
Then dont do that ?
No need to send us a trace, unless you use a pristine kernel.
IFF_UP changes rules are very strict, dont try to avoid them and claim
there is a hole or something wrong.
Check __dev_open() , __dev_close() and __dev_change_flags() were OR/AND
IFF_UP is done by core network.
Net drivers are not allowed to change IFF_UP themselves.
(DE-600 & DE-620 being the exceptions to confirm this rule, of course)
> Jeff
>
> On Mon, Jun 21, 2010 at 9:28 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Mon, 21 Jun 2010 20:57:40 -0600 Jeffrey Merkey <jeffmerkey@gmail.com> wrote:
> >
> >> If someone sets the IFF_UP flags in the netdev structure without going
> >> through ifup userspace stuff, during unregister of the the netdev
> >> the dmaengine-put code will decrement the reference counter negative,
> >> and crash at BUG! in the driver/dma/dmaengine.c code. This seems
> >> busted.
> >>
> >
> > Please send a copy of the kernel BUG trace.
> >
> -
^ permalink raw reply
* Link-local address handling for IPv4
From: Fischer, Anna @ 2010-06-22 13:17 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi,
Does the Linux kernel network stack do any specific handling of link-local address configuration and handling according to RFC 3927? I know that there is user-level code like Zeroconf / Avahi and these tools create ARP sockets directly on the specified network interfaces in order to support link-local address handling. But if I do not run any of these tools, does the kernel's ARP code take care of this, too?
Thanks,
Anna
^ permalink raw reply
* [PATCH NEXT 8/8] qlcnic: update version to 5.0.6
From: amit.salecha @ 2010-06-22 13:19 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Amit Kumar Salecha
In-Reply-To: <1277212745-26857-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index 7fa761a..3675678 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -51,8 +51,8 @@
#define _QLCNIC_LINUX_MAJOR 5
#define _QLCNIC_LINUX_MINOR 0
-#define _QLCNIC_LINUX_SUBVERSION 5
-#define QLCNIC_LINUX_VERSIONID "5.0.5"
+#define _QLCNIC_LINUX_SUBVERSION 6
+#define QLCNIC_LINUX_VERSIONID "5.0.6"
#define QLCNIC_DRV_IDC_VER 0x01
#define QLCNIC_VERSION_CODE(a, b, c) (((a) << 24) + ((b) << 16) + (c))
--
1.6.0.2
^ permalink raw reply related
* [PATCH NEXT 7/8] qlcnic: mark context state freed after destroy
From: amit.salecha @ 2010-06-22 13:19 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Amit Kumar Salecha
In-Reply-To: <1277212745-26857-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
After destroying recv ctx, context state remain same.
Fix it by marking as FREED.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 2 +-
drivers/net/qlcnic/qlcnic_ctx.c | 2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index 6ec34a7..7fa761a 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -573,7 +573,7 @@ struct qlcnic_recv_context {
/*
* Context state
*/
-
+#define QLCNIC_HOST_CTX_STATE_FREED 0
#define QLCNIC_HOST_CTX_STATE_ACTIVE 2
/*
diff --git a/drivers/net/qlcnic/qlcnic_ctx.c b/drivers/net/qlcnic/qlcnic_ctx.c
index be341c1..941cd08 100644
--- a/drivers/net/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/qlcnic/qlcnic_ctx.c
@@ -280,6 +280,8 @@ qlcnic_fw_cmd_destroy_rx_ctx(struct qlcnic_adapter *adapter)
dev_err(&adapter->pdev->dev,
"Failed to destroy rx ctx in firmware\n");
}
+
+ recv_ctx->state = QLCNIC_HOST_CTX_STATE_FREED;
}
static int
--
1.6.0.2
^ permalink raw reply related
* [PATCH NEXT 1/8] qlcnic: cleanup skb allocation
From: amit.salecha @ 2010-06-22 13:18 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Amit Kumar Salecha
In-Reply-To: <1277212745-26857-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
No need to maintian separate state for alloced and freed skb.
This can be done by null check.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 2 --
drivers/net/qlcnic/qlcnic_ethtool.c | 2 --
drivers/net/qlcnic/qlcnic_init.c | 30 +++++++++++++-----------------
3 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index 99ccdd8..86e4781 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -381,7 +381,6 @@ struct qlcnic_rx_buffer {
struct sk_buff *skb;
u64 dma;
u16 ref_handle;
- u16 state;
};
/* Board types */
@@ -423,7 +422,6 @@ struct qlcnic_adapter_stats {
u64 xmit_on;
u64 xmit_off;
u64 skb_alloc_failure;
- u64 null_skb;
u64 null_rxbuf;
u64 rx_dma_map_error;
u64 tx_dma_map_error;
diff --git a/drivers/net/qlcnic/qlcnic_ethtool.c b/drivers/net/qlcnic/qlcnic_ethtool.c
index 3e4822a..a4f1120 100644
--- a/drivers/net/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/qlcnic/qlcnic_ethtool.c
@@ -69,8 +69,6 @@ static const struct qlcnic_stats qlcnic_gstrings_stats[] = {
QLC_SIZEOF(stats.xmit_off), QLC_OFF(stats.xmit_off)},
{"skb_alloc_failure", QLC_SIZEOF(stats.skb_alloc_failure),
QLC_OFF(stats.skb_alloc_failure)},
- {"null skb",
- QLC_SIZEOF(stats.null_skb), QLC_OFF(stats.null_skb)},
{"null rxbuf",
QLC_SIZEOF(stats.null_rxbuf), QLC_OFF(stats.null_rxbuf)},
{"rx dma map error", QLC_SIZEOF(stats.rx_dma_map_error),
diff --git a/drivers/net/qlcnic/qlcnic_init.c b/drivers/net/qlcnic/qlcnic_init.c
index 058ce61..1c3d5a9 100644
--- a/drivers/net/qlcnic/qlcnic_init.c
+++ b/drivers/net/qlcnic/qlcnic_init.c
@@ -112,14 +112,15 @@ void qlcnic_release_rx_buffers(struct qlcnic_adapter *adapter)
rds_ring = &recv_ctx->rds_rings[ring];
for (i = 0; i < rds_ring->num_desc; ++i) {
rx_buf = &(rds_ring->rx_buf_arr[i]);
- if (rx_buf->state == QLCNIC_BUFFER_FREE)
+ if (rx_buf->skb == NULL)
continue;
+
pci_unmap_single(adapter->pdev,
rx_buf->dma,
rds_ring->dma_size,
PCI_DMA_FROMDEVICE);
- if (rx_buf->skb != NULL)
- dev_kfree_skb_any(rx_buf->skb);
+
+ dev_kfree_skb_any(rx_buf->skb);
}
}
}
@@ -266,7 +267,6 @@ int qlcnic_alloc_sw_resources(struct qlcnic_adapter *adapter)
list_add_tail(&rx_buf->list,
&rds_ring->free_list);
rx_buf->ref_handle = i;
- rx_buf->state = QLCNIC_BUFFER_FREE;
rx_buf++;
}
spin_lock_init(&rds_ring->lock);
@@ -1281,14 +1281,12 @@ qlcnic_alloc_rx_skb(struct qlcnic_adapter *adapter,
dma_addr_t dma;
struct pci_dev *pdev = adapter->pdev;
- buffer->skb = dev_alloc_skb(rds_ring->skb_size);
- if (!buffer->skb) {
+ skb = dev_alloc_skb(rds_ring->skb_size);
+ if (!skb) {
adapter->stats.skb_alloc_failure++;
return -ENOMEM;
}
- skb = buffer->skb;
-
skb_reserve(skb, 2);
dma = pci_map_single(pdev, skb->data,
@@ -1297,13 +1295,11 @@ qlcnic_alloc_rx_skb(struct qlcnic_adapter *adapter,
if (pci_dma_mapping_error(pdev, dma)) {
adapter->stats.rx_dma_map_error++;
dev_kfree_skb_any(skb);
- buffer->skb = NULL;
return -ENOMEM;
}
buffer->skb = skb;
buffer->dma = dma;
- buffer->state = QLCNIC_BUFFER_BUSY;
return 0;
}
@@ -1316,14 +1312,15 @@ static struct sk_buff *qlcnic_process_rxbuf(struct qlcnic_adapter *adapter,
buffer = &rds_ring->rx_buf_arr[index];
+ if (unlikely(buffer->skb == NULL)) {
+ WARN_ON(1);
+ return NULL;
+ }
+
pci_unmap_single(adapter->pdev, buffer->dma, rds_ring->dma_size,
PCI_DMA_FROMDEVICE);
skb = buffer->skb;
- if (!skb) {
- adapter->stats.null_skb++;
- goto no_skb;
- }
if (likely(adapter->rx_csum && cksum == STATUS_CKSUM_OK)) {
adapter->stats.csummed++;
@@ -1335,8 +1332,7 @@ static struct sk_buff *qlcnic_process_rxbuf(struct qlcnic_adapter *adapter,
skb->dev = adapter->netdev;
buffer->skb = NULL;
-no_skb:
- buffer->state = QLCNIC_BUFFER_FREE;
+
return skb;
}
@@ -1511,7 +1507,7 @@ qlcnic_process_rcv_ring(struct qlcnic_host_sds_ring *sds_ring, int max)
WARN_ON(desc_cnt > 1);
- if (rxbuf)
+ if (likely(rxbuf))
list_add_tail(&rxbuf->list, &sds_ring->free_list[ring]);
else
adapter->stats.null_rxbuf++;
--
1.6.0.2
^ permalink raw reply related
* [PATCH NEXT 5/8] qlcnic: dont free host resources during fw recovery
From: amit.salecha @ 2010-06-22 13:19 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Amit Kumar Salecha
In-Reply-To: <1277212745-26857-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
There is no need to free/alloc host resources during firmware
recovery.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic_main.c | 32 +++-----------------------------
1 files changed, 3 insertions(+), 29 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index 38d8fe0..c4602fa 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -1392,8 +1392,6 @@ static int __qlcnic_shutdown(struct pci_dev *pdev)
cancel_work_sync(&adapter->tx_timeout_task);
- qlcnic_detach(adapter);
-
qlcnic_clr_all_drv_state(adapter);
clear_bit(__QLCNIC_RESETTING, &adapter->state);
@@ -1454,28 +1452,16 @@ qlcnic_resume(struct pci_dev *pdev)
}
if (netif_running(netdev)) {
- err = qlcnic_attach(adapter);
- if (err)
- goto err_out;
-
err = qlcnic_up(adapter, netdev);
if (err)
- goto err_out_detach;
-
+ goto done;
qlcnic_config_indev_addr(netdev, NETDEV_UP);
}
-
+done:
netif_device_attach(netdev);
qlcnic_schedule_work(adapter, qlcnic_fw_poll_work, FW_POLL_DELAY);
return 0;
-
-err_out_detach:
- qlcnic_detach(adapter);
-err_out:
- qlcnic_clr_all_drv_state(adapter);
- netif_device_attach(netdev);
- return err;
}
#endif
@@ -2426,10 +2412,6 @@ qlcnic_detach_work(struct work_struct *work)
qlcnic_down(adapter, netdev);
- rtnl_lock();
- qlcnic_detach(adapter);
- rtnl_unlock();
-
status = QLCRD32(adapter, QLCNIC_PEG_HALT_STATUS1);
if (status & QLCNIC_RCODE_FATAL_ERROR)
@@ -2518,18 +2500,10 @@ qlcnic_attach_work(struct work_struct *work)
struct qlcnic_adapter *adapter = container_of(work,
struct qlcnic_adapter, fw_work.work);
struct net_device *netdev = adapter->netdev;
- int err;
if (netif_running(netdev)) {
- err = qlcnic_attach(adapter);
- if (err)
- goto done;
-
- err = qlcnic_up(adapter, netdev);
- if (err) {
- qlcnic_detach(adapter);
+ if (qlcnic_up(adapter, netdev))
goto done;
- }
qlcnic_config_indev_addr(netdev, NETDEV_UP);
}
--
1.6.0.2
^ permalink raw reply related
* [PATCH NEXT 0/8]qlcnic: driver update
From: amit.salecha @ 2010-06-22 13:18 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
Hi
Major changes:
1) Previously device context were created in probe and released in remove.
Now create during interface up and release in interface down.
2) Dont deallocate and allocate host memory during device reset.
3) Offload tx timeout recovery to fw recovery functions. Later will
check fw health before doing tx timeout recovery.
Series of 8 patches. Please apply them on net-next branch.
-Amit
^ 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