* Re: [PATCH 07/18 v2] isdn: avm: call disable_pci_device() if pci_probe() failed
From: David Miller @ 2010-08-10 8:43 UTC (permalink / raw)
To: segooon; +Cc: kernel-janitors, isdn, adobriyan, tilman, netdev
In-Reply-To: <1281383448-14050-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Mon, 9 Aug 2010 23:50:47 +0400
> Driver should call disable_pci_device() if it returns from pci_probe()
> with error.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied, but as previously mentioned disable_pci_device() is wrong.
^ permalink raw reply
* Re: [PATCH 06/18 v2] isdn: avm: call disable_pci_device() if pci_probe() failed
From: David Miller @ 2010-08-10 8:42 UTC (permalink / raw)
To: segooon; +Cc: kernel-janitors, isdn, adobriyan, tilman, tj, netdev
In-Reply-To: <1281383439-13988-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Mon, 9 Aug 2010 23:50:37 +0400
> Driver should call disable_pci_device() if it returns from pci_probe()
> with error.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied, but please fix the template you're using for the commit
message header and the message itself, because in all of your
patches you've transposed "disable" and "pci" in "pci_disable_device()"
So I have to fix it up two times in every patch I apply of your's.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] pkt_sched: Add some basic qdisc class ops verification. Was: [PATCH] sfq: add dummy bind/unbind handles
From: David Miller @ 2010-08-10 8:41 UTC (permalink / raw)
To: jarkao2; +Cc: franchoze, shemminger, netdev
In-Reply-To: <20100809221848.GB18629@del.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Tue, 10 Aug 2010 00:18:48 +0200
> Verify in register_qdisc() some basic qdisc class handlers are present.
>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] pkt_sched: sch_sfq: Add dummy unbind_tcf and put handles. Was: [PATCH] sfq: add dummy bind/unbind handles
From: David Miller @ 2010-08-10 8:41 UTC (permalink / raw)
To: jarkao2; +Cc: franchoze, shemminger, netdev
In-Reply-To: <20100809221817.GA18629@del.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Tue, 10 Aug 2010 00:18:17 +0200
> Add dummy .unbind_tcf and .put qdisc class ops for easier verification.
> (All other schedulers have it like this.)
>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] usbnet: rx_submit() should return an error code.
From: David Miller @ 2010-08-10 8:41 UTC (permalink / raw)
To: oneukum; +Cc: ellyjones, stern, netdev, linux-usb, jglasgow
In-Reply-To: <201008100942.05887.oneukum@suse.de>
From: Oliver Neukum <oneukum@suse.de>
Date: Tue, 10 Aug 2010 09:42:05 +0200
> Am Dienstag, 10. August 2010, 09:18:55 schrieb David Miller:
>> From: Elly Jones <ellyjones@google.com>
>> Date: Mon, 9 Aug 2010 18:37:50 -0400
>>
>> > This patch makes rx_submit() return an error code, and makes some call sites
>> > that care check the return value. This is important because it lets us properly
>> > handle cases where the device isn't ready to handle URB submissions (e.g., when
>> > it is autosuspended under some drivers); previously, we would attempt and fail
>> > to submit URBs and reschedule ourselves to try and fail again. This patch is
>> > against Linus's 2.6 repo commit 45d7f32c7a43cbb9592886d38190e379e2eb2226.
>> >
>> > Signed-Off-By: Elizabeth Jones <ellyjones@google.com>
>>
>> What gets kevent() running again to run the rx_submit() calls when the
>> device comes back from being suspended?
>>
>
> usbnet_resume() schedules usbnet_bh() which will take care of that.
That makes sense, I've applied Elizabeth's patch.
But Elizabeth, your patch was severely corrupted by your email client.
Long lines were split up into two, etc. This corrupts the patch and
makes it unusable for us. Please make sure that you have fixed your
email client setup for the next patch you submit.
Thanks.
^ permalink raw reply
* RE: [PATCH] [Bug 16494] NFS client over TCP hangs due to packet loss
From: Andy Chittenden @ 2010-08-10 8:40 UTC (permalink / raw)
To: 'Trond Myklebust'
Cc: 'Andrew Morton', 'David Miller',
kuznet-v/Mj1YrvjDBInbfyfbPRSQ, pekkas-UjJjq++bwZ7HOG6cAo2yLw,
jmorris-gx6/JNMH7DfYtjvyW6yDsg, yoshfuji-VfPWfsRibaP+Ru+s062T9g,
kaber-dcUjhNyLwpNeoWH0uzbU5w, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
William.Allen.Simpson-Re5JQEeQqe8AvxtiuMwx3w,
gilad-f4XOiQkOAtcdH0auuBZGHA,
ilpo.jarvinen-pxSi+dnQzZMxHbG02/KK1g,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, 'J. Bruce Fields',
'Neil Brown', 'Chuck Lever',
'Benny Halevy', 'Alexandros Batsakis',
'Joe Perches', Andy Chittenden
In-Reply-To: <1281372927.8950.3.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
> On Mon, 2010-08-09 at 10:27 +0100, Andy Chittenden wrote:
> > A weekend run with that patch applied to 2.6.34.2 was successful. As
> nobody has objected, what's the next step to getting it applied to the
> official source trees?
>
> Please resend me a version with a cleaned up changelog entry. I can
> then
> push it as a bugfix.
>
> Cheers
> Trond
Thanks. I think this sums it up:
SUNRPC: fix NFS client over TCP hangs due to packet loss (Bug 16494)
When reusing a TCP connection, ensure that it's aborted if a previous shutdown attempt has been made on that connection so that the RPC over TCP recovery mechanism succeeds.
# diff -up /home/company/software/src/linux-2.6.34.2/net/sunrpc/xprtsock.c net/sunrpc/xprtsock.c
--- /home/company/software/src/linux-2.6.34.2/net/sunrpc/xprtsock.c 2010-08-02 18:30:51.000000000 +0100
+++ net/sunrpc/xprtsock.c 2010-08-06 08:09:08.000000000 +0100
@@ -1322,10 +1322,11 @@ static void xs_tcp_state_change(struct s
if (!(xprt = xprt_from_sock(sk)))
goto out;
dprintk("RPC: xs_tcp_state_change client %p...\n", xprt);
- dprintk("RPC: state %x conn %d dead %d zapped %d\n",
+ dprintk("RPC: state %x conn %d dead %d zapped %d sk_shutdown %d\n",
sk->sk_state, xprt_connected(xprt),
sock_flag(sk, SOCK_DEAD),
- sock_flag(sk, SOCK_ZAPPED));
+ sock_flag(sk, SOCK_ZAPPED),
+ sk->sk_shutdown);
switch (sk->sk_state) {
case TCP_ESTABLISHED:
@@ -1796,10 +1797,25 @@ static void xs_tcp_reuse_connection(stru
{
unsigned int state = transport->inet->sk_state;
- if (state == TCP_CLOSE && transport->sock->state == SS_UNCONNECTED)
- return;
- if ((1 << state) & (TCPF_ESTABLISHED|TCPF_SYN_SENT))
- return;
+ if (state == TCP_CLOSE && transport->sock->state == SS_UNCONNECTED) {
+ /* we don't need to abort the connection if the socket
+ * hasn't undergone a shutdown
+ */
+ if (transport->inet->sk_shutdown == 0)
+ return;
+ dprintk("RPC: %s: TCP_CLOSEd and sk_shutdown set to %d\n",
+ __func__, transport->inet->sk_shutdown);
+ }
+ if ((1 << state) & (TCPF_ESTABLISHED|TCPF_SYN_SENT)) {
+ /* we don't need to abort the connection if the socket
+ * hasn't undergone a shutdown
+ */
+ if (transport->inet->sk_shutdown == 0)
+ return;
+ dprintk("RPC: %s: ESTABLISHED/SYN_SENT "
+ "sk_shutdown set to %d\n",
+ __func__, transport->inet->sk_shutdown);
+ }
xs_abort_connection(xprt, transport);
}
Signed-off-by: Andy Chittenden <andyc.bluearc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Is it a possible bug in dev_gro_receive()?
From: Jarek Poplawski @ 2010-08-10 8:34 UTC (permalink / raw)
To: Xin, Xiaohui
Cc: netdev@vger.kernel.org, herbert@gondor.apana.org.au,
davem@davemloft.net
In-Reply-To: <F2E9EB7348B8264F86B6AB8151CE2D7920AD46E911@shsmsx502.ccr.corp.intel.com>
On Tue, Aug 10, 2010 at 04:11:54PM +0800, Xin, Xiaohui wrote:
> Jarek,
> Seems community agree with your patch more.
> So may you send out your patch then? Thanks!
> Some of my related patches still need this fix.
Hmm... But there was no my patch. Only a tiny, cosmetical suggestion
to your patch. I'd be glad if you add some credit or my "Acked-by",
of course. But if you really have a big problem, e.g. you don't like
my suggestion, please confirm.
Thanks,
Jarek P.
>
> Thanks
> Xiaohui
>
> >-----Original Message-----
> >From: Jarek Poplawski [mailto:jarkao2@gmail.com]
> >Sent: Tuesday, August 03, 2010 2:45 PM
> >To: Xin, Xiaohui
> >Cc: netdev@vger.kernel.org; herbert@gondor.apana.org.au; davem@davemloft.net
> >Subject: Re: Is it a possible bug in dev_gro_receive()?
> >
> >On Tue, Aug 03, 2010 at 10:33:24AM +0800, Xin, Xiaohui wrote:
> >> >-----Original Message-----
> >> >From: Jarek Poplawski [mailto:jarkao2@gmail.com]
> >> >Sent: Monday, August 02, 2010 6:29 PM
> >> >To: Xin, Xiaohui
> >> >Cc: netdev@vger.kernel.org; herbert@gondor.apana.org.au; davem@davemloft.net
> >> >Subject: Re: Is it a possible bug in dev_gro_receive()?
> >> >
> >> >Xin Xiaohui wrote:
> >> >> I looked into the code dev_gro_receive(), found the code here:
> >> >> if the frags[0] is pulled to 0, then the page will be released,
> >> >> and memmove() frags left.
> >> >> Is that right? I'm not sure if memmove do right or not, but
> >> >> frags[0].size is never set after memove at least. what I think
> >> >> a simple way is not to do anything if we found frags[0].size == 0.
> >> >> The patch is as followed.
> >> >>
> >> >> Or am I missing something here?
> >> >
> >> >I think, you're right, but fixing memmove looks nicer to me:
> >> >
> >> > - --skb_shinfo(skb)->nr_frags);
> >> > + --skb_shinfo(skb)->nr_frags * sizeof(skb_frag_t));
> >> >
> >> >Jarek P.
> >>
> >> Is there a little hurt of performance to do memmove() if skb_shinfo(skb)->nr_frags is
> >large?
> >> We're now working on the zero-copy patches based on napi_gro_frags() interface, and in
> >> this case, we have found a lot of skbs which frags[0] is pulled to 0. And after the memmove
> >is
> >> fixed, each frags[x].size is needed to modify too.
> >> So I think don't do anything is better. Or is there any side effect with a null page in the
> >stack?
> >
> >Even if it's better, generally you should separate fixes from
> >optimizations. On the other hand, it was expected to be "unlikely" by
> >design, so you should probably explain more why it has to be changed
> >here too.
> >
> >Thanks,
> >Jarek P.
> >
> >>
> >> Thanks
> >> Xiaohui
> >> >
> >> >>
> >> >> ---
> >> >> net/core/dev.c | 7 -------
> >> >> 1 files changed, 0 insertions(+), 7 deletions(-)
> >> >>
> >> >> diff --git a/net/core/dev.c b/net/core/dev.c
> >> >> index 264137f..28cdbbf 100644
> >> >> --- a/net/core/dev.c
> >> >> +++ b/net/core/dev.c
> >> >> @@ -2730,13 +2730,6 @@ pull:
> >> >>
> >> >> skb_shinfo(skb)->frags[0].page_offset += grow;
> >> >> skb_shinfo(skb)->frags[0].size -= grow;
> >> >> -
> >> >> - if (unlikely(!skb_shinfo(skb)->frags[0].size)) {
> >> >> - put_page(skb_shinfo(skb)->frags[0].page);
> >> >> - memmove(skb_shinfo(skb)->frags,
> >> >> - skb_shinfo(skb)->frags + 1,
> >> >> - --skb_shinfo(skb)->nr_frags);
> >> >> - }
> >> >> }
> >> >>
> >> >> ok:
> >> >
> >> >
> >>
^ permalink raw reply
* Re: [patch 2/2 v2] qlcnic: using too much stack
From: David Miller @ 2010-08-10 8:34 UTC (permalink / raw)
To: error27
Cc: amit.salecha, anirban.chakraborty, linux-driver,
sucheta.chakraborty, netdev, kernel-janitors
In-Reply-To: <20100810074936.GG18431@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Tue, 10 Aug 2010 09:49:36 +0200
> qlcnic_pci_info structs are 128 bytes so an array of 8 uses 1024 bytes.
> That's a lot if you run with 4K stacks. I allocated them with kcalloc()
> instead.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied.
^ permalink raw reply
* Re: [patch 1/2 v2] qlcnic: clean up qlcnic_init_pci_info()
From: David Miller @ 2010-08-10 8:34 UTC (permalink / raw)
To: error27
Cc: amit.salecha, anirban.chakraborty, linux-driver,
sucheta.chakraborty, netdev, kernel-janitors
In-Reply-To: <20100810074756.GF18431@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Tue, 10 Aug 2010 09:47:56 +0200
> In the original code we allocated memory conditionally and freed it in
> the error handling unconditionally. It turns out that this function is
> only called during initialization and "adapter->npars" and
> "adapter->eswitch" are always NULL at the start of the function. I
> removed those checks.
>
> Also since I was cleaning things, I changed the error handling for
> qlcnic_get_pci_info() and pulled everything in an indent level.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied.
^ permalink raw reply
* Re: [RFC] [PATCH] Don't destroy TCP sockets twice
From: Andi Kleen @ 2010-08-10 8:30 UTC (permalink / raw)
To: Herbert Xu; +Cc: Andi Kleen, netdev
In-Reply-To: <20100809213002.GA23736@gondor.apana.org.au>
On Mon, Aug 09, 2010 at 05:30:02PM -0400, Herbert Xu wrote:
> Andi Kleen <andi@firstfloor.org> wrote:
> >
> > While working on something else I noticed that tcp_v4/6_destroy_sock()
> > can get called twice on a socket. This happens because when a reset or
> > similar happens tcp_done destroys the connection socket state, and
> > then eventually when the socket is released it is destroyed again.
>
> I'm still having problems understanding why you're getting a call
> to send a FIN after tcp_done. This shouldn't happen at all because
> tcp_done moves the socket to the TCP_CLOSE state, where FINs should
> not be sent.
>
> Can you clarify on how we can reproduce this problem in the
> upstream kernel?
This simple patch demonstrates double destroy. I have patches for showing
the more complicated case too, but they're much more ugly.
-Andi
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index a778ee0..bfbb06b 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -459,6 +459,8 @@ struct tcp_sock {
* contains related tcp_cookie_transactions fields.
*/
struct tcp_cookie_values *cookie_values;
+
+ int destroyed;
};
static inline struct tcp_sock *tcp_sk(const struct sock *sk)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 0207662..25bf80a 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1919,6 +1919,9 @@ void tcp_v4_destroy_sock(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
+ BUG_ON(tp->destroyed != 0);
+ tp->destroyed = 1;
+
tcp_clear_xmit_timers(sk);
tcp_cleanup_congestion_control(sk);
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply related
* RE: Is it a possible bug in dev_gro_receive()?
From: Xin, Xiaohui @ 2010-08-10 8:11 UTC (permalink / raw)
To: Jarek Poplawski
Cc: netdev@vger.kernel.org, herbert@gondor.apana.org.au,
davem@davemloft.net
In-Reply-To: <20100803064515.GA6430@ff.dom.local>
Jarek,
Seems community agree with your patch more.
So may you send out your patch then? Thanks!
Some of my related patches still need this fix.
Thanks
Xiaohui
>-----Original Message-----
>From: Jarek Poplawski [mailto:jarkao2@gmail.com]
>Sent: Tuesday, August 03, 2010 2:45 PM
>To: Xin, Xiaohui
>Cc: netdev@vger.kernel.org; herbert@gondor.apana.org.au; davem@davemloft.net
>Subject: Re: Is it a possible bug in dev_gro_receive()?
>
>On Tue, Aug 03, 2010 at 10:33:24AM +0800, Xin, Xiaohui wrote:
>> >-----Original Message-----
>> >From: Jarek Poplawski [mailto:jarkao2@gmail.com]
>> >Sent: Monday, August 02, 2010 6:29 PM
>> >To: Xin, Xiaohui
>> >Cc: netdev@vger.kernel.org; herbert@gondor.apana.org.au; davem@davemloft.net
>> >Subject: Re: Is it a possible bug in dev_gro_receive()?
>> >
>> >Xin Xiaohui wrote:
>> >> I looked into the code dev_gro_receive(), found the code here:
>> >> if the frags[0] is pulled to 0, then the page will be released,
>> >> and memmove() frags left.
>> >> Is that right? I'm not sure if memmove do right or not, but
>> >> frags[0].size is never set after memove at least. what I think
>> >> a simple way is not to do anything if we found frags[0].size == 0.
>> >> The patch is as followed.
>> >>
>> >> Or am I missing something here?
>> >
>> >I think, you're right, but fixing memmove looks nicer to me:
>> >
>> > - --skb_shinfo(skb)->nr_frags);
>> > + --skb_shinfo(skb)->nr_frags * sizeof(skb_frag_t));
>> >
>> >Jarek P.
>>
>> Is there a little hurt of performance to do memmove() if skb_shinfo(skb)->nr_frags is
>large?
>> We're now working on the zero-copy patches based on napi_gro_frags() interface, and in
>> this case, we have found a lot of skbs which frags[0] is pulled to 0. And after the memmove
>is
>> fixed, each frags[x].size is needed to modify too.
>> So I think don't do anything is better. Or is there any side effect with a null page in the
>stack?
>
>Even if it's better, generally you should separate fixes from
>optimizations. On the other hand, it was expected to be "unlikely" by
>design, so you should probably explain more why it has to be changed
>here too.
>
>Thanks,
>Jarek P.
>
>>
>> Thanks
>> Xiaohui
>> >
>> >>
>> >> ---
>> >> net/core/dev.c | 7 -------
>> >> 1 files changed, 0 insertions(+), 7 deletions(-)
>> >>
>> >> diff --git a/net/core/dev.c b/net/core/dev.c
>> >> index 264137f..28cdbbf 100644
>> >> --- a/net/core/dev.c
>> >> +++ b/net/core/dev.c
>> >> @@ -2730,13 +2730,6 @@ pull:
>> >>
>> >> skb_shinfo(skb)->frags[0].page_offset += grow;
>> >> skb_shinfo(skb)->frags[0].size -= grow;
>> >> -
>> >> - if (unlikely(!skb_shinfo(skb)->frags[0].size)) {
>> >> - put_page(skb_shinfo(skb)->frags[0].page);
>> >> - memmove(skb_shinfo(skb)->frags,
>> >> - skb_shinfo(skb)->frags + 1,
>> >> - --skb_shinfo(skb)->nr_frags);
>> >> - }
>> >> }
>> >>
>> >> ok:
>> >
>> >
>>
^ permalink raw reply
* [patch 2/2 v2] qlcnic: using too much stack
From: Dan Carpenter @ 2010-08-10 7:49 UTC (permalink / raw)
To: Amit Kumar Salecha
Cc: Anirban Chakraborty, linux-driver, David S. Miller,
Sucheta Chakraborty, netdev, kernel-janitors
qlcnic_pci_info structs are 128 bytes so an array of 8 uses 1024 bytes.
That's a lot if you run with 4K stacks. I allocated them with kcalloc()
instead.
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
V2: No change. I had to respin because of the 1/1 patch.
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index 6b8df55..bf6d87a 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -473,14 +473,20 @@ qlcnic_cleanup_pci_map(struct qlcnic_adapter *adapter)
static int
qlcnic_init_pci_info(struct qlcnic_adapter *adapter)
{
- struct qlcnic_pci_info pci_info[QLCNIC_MAX_PCI_FUNC];
+ struct qlcnic_pci_info *pci_info;
int i, ret = 0, err;
u8 pfn;
+ pci_info = kcalloc(QLCNIC_MAX_PCI_FUNC, sizeof(*pci_info), GFP_KERNEL);
+ if (!pci_info)
+ return -ENOMEM;
+
adapter->npars = kzalloc(sizeof(struct qlcnic_npar_info) *
QLCNIC_MAX_PCI_FUNC, GFP_KERNEL);
- if (!adapter->npars)
- return -ENOMEM;
+ if (!adapter->npars) {
+ err = -ENOMEM;
+ goto err_pci_info;
+ }
adapter->eswitch = kzalloc(sizeof(struct qlcnic_eswitch) *
QLCNIC_NIU_MAX_XG_PORTS, GFP_KERNEL);
@@ -508,6 +514,7 @@ qlcnic_init_pci_info(struct qlcnic_adapter *adapter)
for (i = 0; i < QLCNIC_NIU_MAX_XG_PORTS; i++)
adapter->eswitch[i].flags |= QLCNIC_SWITCH_ENABLE;
+ kfree(pci_info);
return 0;
err_eswitch:
@@ -516,6 +523,8 @@ err_eswitch:
err_npars:
kfree(adapter->npars);
adapter->npars = NULL;
+err_pci_info:
+ kfree(pci_info);
return ret;
}
@@ -3362,15 +3371,21 @@ qlcnic_sysfs_read_pci_config(struct file *file, struct kobject *kobj,
struct device *dev = container_of(kobj, struct device, kobj);
struct qlcnic_adapter *adapter = dev_get_drvdata(dev);
struct qlcnic_pci_func_cfg pci_cfg[QLCNIC_MAX_PCI_FUNC];
- struct qlcnic_pci_info pci_info[QLCNIC_MAX_PCI_FUNC];
+ struct qlcnic_pci_info *pci_info;
int i, ret;
if (size != sizeof(pci_cfg))
return QL_STATUS_INVALID_PARAM;
+ pci_info = kcalloc(QLCNIC_MAX_PCI_FUNC, sizeof(*pci_info), GFP_KERNEL);
+ if (!pci_info)
+ return -ENOMEM;
+
ret = qlcnic_get_pci_info(adapter, pci_info);
- if (ret)
+ if (ret) {
+ kfree(pci_info);
return ret;
+ }
for (i = 0; i < QLCNIC_MAX_PCI_FUNC ; i++) {
pci_cfg[i].pci_func = pci_info[i].id;
@@ -3381,8 +3396,8 @@ qlcnic_sysfs_read_pci_config(struct file *file, struct kobject *kobj,
memcpy(&pci_cfg[i].def_mac_addr, &pci_info[i].mac, ETH_ALEN);
}
memcpy(buf, &pci_cfg, size);
+ kfree(pci_info);
return size;
-
}
static struct bin_attribute bin_attr_npar_config = {
.attr = {.name = "npar_config", .mode = (S_IRUGO | S_IWUSR)},
^ permalink raw reply related
* [patch 1/2 v2] qlcnic: clean up qlcnic_init_pci_info()
From: Dan Carpenter @ 2010-08-10 7:47 UTC (permalink / raw)
To: Amit Kumar Salecha
Cc: Anirban Chakraborty, linux-driver, David S. Miller,
Sucheta Chakraborty, netdev, kernel-janitors
In the original code we allocated memory conditionally and freed it in
the error handling unconditionally. It turns out that this function is
only called during initialization and "adapter->npars" and
"adapter->eswitch" are always NULL at the start of the function. I
removed those checks.
Also since I was cleaning things, I changed the error handling for
qlcnic_get_pci_info() and pulled everything in an indent level.
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
V2: fixed a typo. I set eswitch to NULL twice instead of npars by
mistake.
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index b9615bd..6b8df55 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -477,44 +477,45 @@ qlcnic_init_pci_info(struct qlcnic_adapter *adapter)
int i, ret = 0, err;
u8 pfn;
- if (!adapter->npars)
- adapter->npars = kzalloc(sizeof(struct qlcnic_npar_info) *
+ adapter->npars = kzalloc(sizeof(struct qlcnic_npar_info) *
QLCNIC_MAX_PCI_FUNC, GFP_KERNEL);
if (!adapter->npars)
return -ENOMEM;
- if (!adapter->eswitch)
- adapter->eswitch = kzalloc(sizeof(struct qlcnic_eswitch) *
+ adapter->eswitch = kzalloc(sizeof(struct qlcnic_eswitch) *
QLCNIC_NIU_MAX_XG_PORTS, GFP_KERNEL);
if (!adapter->eswitch) {
err = -ENOMEM;
- goto err_eswitch;
+ goto err_npars;
}
ret = qlcnic_get_pci_info(adapter, pci_info);
- if (!ret) {
- for (i = 0; i < QLCNIC_MAX_PCI_FUNC; i++) {
- pfn = pci_info[i].id;
- if (pfn > QLCNIC_MAX_PCI_FUNC)
- return QL_STATUS_INVALID_PARAM;
- adapter->npars[pfn].active = pci_info[i].active;
- adapter->npars[pfn].type = pci_info[i].type;
- adapter->npars[pfn].phy_port = pci_info[i].default_port;
- adapter->npars[pfn].mac_learning = DEFAULT_MAC_LEARN;
- adapter->npars[pfn].min_bw = pci_info[i].tx_min_bw;
- adapter->npars[pfn].max_bw = pci_info[i].tx_max_bw;
- }
-
- for (i = 0; i < QLCNIC_NIU_MAX_XG_PORTS; i++)
- adapter->eswitch[i].flags |= QLCNIC_SWITCH_ENABLE;
+ if (ret)
+ goto err_eswitch;
- return ret;
+ for (i = 0; i < QLCNIC_MAX_PCI_FUNC; i++) {
+ pfn = pci_info[i].id;
+ if (pfn > QLCNIC_MAX_PCI_FUNC)
+ return QL_STATUS_INVALID_PARAM;
+ adapter->npars[pfn].active = pci_info[i].active;
+ adapter->npars[pfn].type = pci_info[i].type;
+ adapter->npars[pfn].phy_port = pci_info[i].default_port;
+ adapter->npars[pfn].mac_learning = DEFAULT_MAC_LEARN;
+ adapter->npars[pfn].min_bw = pci_info[i].tx_min_bw;
+ adapter->npars[pfn].max_bw = pci_info[i].tx_max_bw;
}
+ for (i = 0; i < QLCNIC_NIU_MAX_XG_PORTS; i++)
+ adapter->eswitch[i].flags |= QLCNIC_SWITCH_ENABLE;
+
+ return 0;
+
+err_eswitch:
kfree(adapter->eswitch);
adapter->eswitch = NULL;
-err_eswitch:
+err_npars:
kfree(adapter->npars);
+ adapter->npars = NULL;
return ret;
}
^ permalink raw reply related
* Re: [PATCH] usbnet: rx_submit() should return an error code.
From: Oliver Neukum @ 2010-08-10 7:42 UTC (permalink / raw)
To: David Miller
Cc: ellyjones-hpIqsD4AKlfQT0dZR+AlfA,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
jglasgow-hpIqsD4AKlfQT0dZR+AlfA
In-Reply-To: <20100810.001855.179947437.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Am Dienstag, 10. August 2010, 09:18:55 schrieb David Miller:
> From: Elly Jones <ellyjones-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> Date: Mon, 9 Aug 2010 18:37:50 -0400
>
> > This patch makes rx_submit() return an error code, and makes some call sites
> > that care check the return value. This is important because it lets us properly
> > handle cases where the device isn't ready to handle URB submissions (e.g., when
> > it is autosuspended under some drivers); previously, we would attempt and fail
> > to submit URBs and reschedule ourselves to try and fail again. This patch is
> > against Linus's 2.6 repo commit 45d7f32c7a43cbb9592886d38190e379e2eb2226.
> >
> > Signed-Off-By: Elizabeth Jones <ellyjones-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
>
> What gets kevent() running again to run the rx_submit() calls when the
> device comes back from being suspended?
>
usbnet_resume() schedules usbnet_bh() which will take care of that.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] usbnet: rx_submit() should return an error code.
From: David Miller @ 2010-08-10 7:18 UTC (permalink / raw)
To: ellyjones; +Cc: oneukum, stern, netdev, linux-usb, jglasgow
In-Reply-To: <AANLkTimubaXzLjROeaNB0dV09thKfpLDyaEA-t_yzyV1@mail.gmail.com>
From: Elly Jones <ellyjones@google.com>
Date: Mon, 9 Aug 2010 18:37:50 -0400
> This patch makes rx_submit() return an error code, and makes some call sites
> that care check the return value. This is important because it lets us properly
> handle cases where the device isn't ready to handle URB submissions (e.g., when
> it is autosuspended under some drivers); previously, we would attempt and fail
> to submit URBs and reschedule ourselves to try and fail again. This patch is
> against Linus's 2.6 repo commit 45d7f32c7a43cbb9592886d38190e379e2eb2226.
>
> Signed-Off-By: Elizabeth Jones <ellyjones@google.com>
What gets kevent() running again to run the rx_submit() calls when the
device comes back from being suspended?
^ permalink raw reply
* Re: [PATCH 3/3] phy.c: fix kernel-doc warnings
From: David Miller @ 2010-08-10 7:09 UTC (permalink / raw)
To: randy.dunlap; +Cc: netdev
In-Reply-To: <20100809164159.c81cd1c4.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Mon, 9 Aug 2010 16:41:59 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix phy.c kernel-doc notation:
>
> Warning(drivers/net/phy/phy.c:313): No description found for parameter 'ifr'
> Warning(drivers/net/phy/phy.c:313): Excess function parameter 'mii_data' description in 'phy_mii_ioctl'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] net/sock.h: add missing kernel-doc notation
From: David Miller @ 2010-08-10 7:09 UTC (permalink / raw)
To: randy.dunlap; +Cc: netdev
In-Reply-To: <20100809164107.a992561a.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Mon, 9 Aug 2010 16:41:07 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Add missing kernel-doc notation to struct sock:
>
> Warning(include/net/sock.h:324): No description found for parameter 'sk_peer_pid'
> Warning(include/net/sock.h:324): No description found for parameter 'sk_peer_cred'
> Warning(include/net/sock.h:324): No description found for parameter 'sk_classid'
> Warning(include/net/sock.h:324): Excess struct/union/enum/typedef member 'sk_peercred' description in 'sock'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] etherdevice.h: fix kernel-doc typo
From: David Miller @ 2010-08-10 7:09 UTC (permalink / raw)
To: randy.dunlap; +Cc: netdev
In-Reply-To: <20100809164003.39c496ee.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Mon, 9 Aug 2010 16:40:03 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix etherdevice.h parameter name typo in kernel-doc:
>
> Warning(include/linux/etherdevice.h:138): No description found for parameter 'hwaddr'
> Warning(include/linux/etherdevice.h:138): Excess function parameter 'addr' description in 'dev_hw_addr_random'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied.
^ permalink raw reply
* Re: i386 allmodconfig, current mainline
From: David Miller @ 2010-08-10 7:07 UTC (permalink / raw)
To: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
Cc: greg-U8xfFu+wG4EAvxtiuMwx3w, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
vapier-aBrp7R+bbdUdnm+yROfE0A, jbarnes-Y1mF5jBUw70BENJcbMCuUQ,
kevin.curtis-AP8L3A0T/wQqdlJmJB21zg,
phillip-cnXvMjJKhjYG2Il/BtU0GPXRex20P6io,
faisal.latif-ral2JQCrhuEAvxtiuMwx3w,
chien.tin.tung-ral2JQCrhuEAvxtiuMwx3w,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
samuel.ortiz-ral2JQCrhuEAvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100809164346.6e30cf8c.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
From: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Date: Mon, 9 Aug 2010 16:43:46 -0700
> drivers/net/wan/farsync.c: In function 'fst_intr_rx':
> drivers/net/wan/farsync.c:1312: warning: cast to pointer from integer of different size
> drivers/net/wan/farsync.c: In function 'do_bottom_half_tx':
> drivers/net/wan/farsync.c:1407: warning: cast to pointer from integer of different size
I'll toss the following into net-2.6:
--------------------
farsync: Fix compile warnings.
drivers/net/wan/farsync.c: In function 'fst_intr_rx':
drivers/net/wan/farsync.c:1312: warning: cast to pointer from integer of different size
drivers/net/wan/farsync.c: In function 'do_bottom_half_tx':
drivers/net/wan/farsync.c:1407: warning: cast to pointer from integer of different size
The "skb" and "mem" arguments being passed here are DMA addresses
being programmed into the hardware registers, so pass them as the type
that they actually are. And use the correct printf formatting in
debug logging statements for these things to match the type change.
Reported-by: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Signed-off-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
---
drivers/net/wan/farsync.c | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wan/farsync.c b/drivers/net/wan/farsync.c
index ad7719f..e050bd6 100644
--- a/drivers/net/wan/farsync.c
+++ b/drivers/net/wan/farsync.c
@@ -885,20 +885,21 @@ fst_rx_dma_complete(struct fst_card_info *card, struct fst_port_info *port,
* Receive a frame through the DMA
*/
static inline void
-fst_rx_dma(struct fst_card_info *card, unsigned char *skb,
- unsigned char *mem, int len)
+fst_rx_dma(struct fst_card_info *card, dma_addr_t skb,
+ dma_addr_t mem, int len)
{
/*
* This routine will setup the DMA and start it
*/
- dbg(DBG_RX, "In fst_rx_dma %p %p %d\n", skb, mem, len);
+ dbg(DBG_RX, "In fst_rx_dma %lx %lx %d\n",
+ (unsigned long) skb, (unsigned long) mem, len);
if (card->dmarx_in_progress) {
dbg(DBG_ASS, "In fst_rx_dma while dma in progress\n");
}
- outl((unsigned long) skb, card->pci_conf + DMAPADR0); /* Copy to here */
- outl((unsigned long) mem, card->pci_conf + DMALADR0); /* from here */
+ outl(skb, card->pci_conf + DMAPADR0); /* Copy to here */
+ outl(mem, card->pci_conf + DMALADR0); /* from here */
outl(len, card->pci_conf + DMASIZ0); /* for this length */
outl(0x00000000c, card->pci_conf + DMADPR0); /* In this direction */
@@ -1309,8 +1310,8 @@ fst_intr_rx(struct fst_card_info *card, struct fst_port_info *port)
card->dma_port_rx = port;
card->dma_len_rx = len;
card->dma_rxpos = rxp;
- fst_rx_dma(card, (char *) card->rx_dma_handle_card,
- (char *) BUF_OFFSET(rxBuffer[pi][rxp][0]), len);
+ fst_rx_dma(card, card->rx_dma_handle_card,
+ BUF_OFFSET(rxBuffer[pi][rxp][0]), len);
}
if (rxp != port->rxpos) {
dbg(DBG_ASS, "About to increment rxpos by more than 1\n");
--
1.7.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [patch 2/2] qlcnic: using too much stack
From: David Miller @ 2010-08-10 7:01 UTC (permalink / raw)
To: joe
Cc: anirban.chakraborty, error27, amit.salecha, Linux-Driver,
sucheta.chakraborty, netdev, kernel-janitors
In-Reply-To: <1281411546.1954.102.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Mon, 09 Aug 2010 20:39:06 -0700
> On Mon, 2010-08-09 at 20:31 -0700, Anirban Chakraborty wrote:
>> On Aug 10, 2010, at 7:33 AM, Joe Perches wrote:
>> > On Mon, 2010-08-09 at 18:43 -0700, Anirban Chakraborty wrote:
>> >> Your patch is fine except that the preferred way is to use kzalloc over kaclloc. kzalloc does not need that extra
>> >> argument that you are passing to kcalloc.
>> > You probably meant to write "my preferred way"
>> > as the kcalloc to "kzalloc with a multiply"
>> > ratio is pretty high.
>> I was suggesting based on the following:
>> http://lwn.net/Articles/147014/
>
> Note that article suggests kzalloc for allocating
> a single zeroed object.
>
> kcalloc is used for multiple zeroed objects and
> protects against oversized allocations.
Agreed, kcalloc should be used here.
^ permalink raw reply
* [patch] Staging: vt6656: problems in error handling
From: Dan Carpenter @ 2010-08-10 6:00 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Andres More, Forest Bond, Jim Lieb, devel, netdev,
kernel-janitors
The first kfree(pDevice) is pointless because pDevice is NULL. The
second kfree(pDevice) is a double free because pDevice is the driver's
private data and that is already freed by free_netdev(netdev). Also the
free_netdev() error path doesn't call usb_put_dev().
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/staging/vt6656/main_usb.c b/drivers/staging/vt6656/main_usb.c
index c528ef0..4fdf837 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -771,10 +771,9 @@ vt6656_probe(struct usb_interface *intf, const struct usb_device_id *id)
udev = usb_get_dev(udev);
netdev = alloc_etherdev(sizeof(DEVICE_INFO));
-
if (!netdev) {
printk(KERN_ERR DEVICE_NAME ": allocate net device failed\n");
- kfree(pDevice);
+ rc = -ENOMEM;
goto err_nomem;
}
@@ -800,9 +799,7 @@ vt6656_probe(struct usb_interface *intf, const struct usb_device_id *id)
rc = register_netdev(netdev);
if (rc) {
printk(KERN_ERR DEVICE_NAME " Failed to register netdev\n");
- free_netdev(netdev);
- kfree(pDevice);
- return -ENODEV;
+ goto err_netdev;
}
usb_device_reset(pDevice);
@@ -820,10 +817,12 @@ vt6656_probe(struct usb_interface *intf, const struct usb_device_id *id)
return 0;
+err_netdev:
+ free_netdev(netdev);
err_nomem:
usb_put_dev(udev);
- return -ENOMEM;
+ return rc;
}
static void device_free_tx_bufs(PSDevice pDevice)
^ permalink raw reply related
* Re: i386 allmodconfig, current mainline
From: Roland Dreier @ 2010-08-10 4:52 UTC (permalink / raw)
To: Andrew Morton
Cc: Greg KH, David Woodhouse, Mike Frysinger, Jesse Barnes,
Kevin Curtis, Phillip Lougher, Faisal Latif, Chien Tung,
Dan Williams, Samuel Ortiz, linux-kernel, netdev, linux-wireless,
x86, linux-rdma
In-Reply-To: <20100809164346.6e30cf8c.akpm@linux-foundation.org>
Will queue up fixes as below:
> drivers/infiniband/hw/nes/nes_verbs.c: In function 'nes_alloc_fast_reg_page_list':
> drivers/infiniband/hw/nes/nes_verbs.c:477: warning: cast to pointer from integer of different size
> drivers/infiniband/hw/nes/nes_verbs.c: In function 'nes_post_send':
> drivers/infiniband/hw/nes/nes_verbs.c:3486: warning: cast to pointer from integer of different size
> drivers/infiniband/hw/nes/nes_verbs.c:3486: warning: cast to pointer from integer of different size
--- a/drivers/infiniband/hw/nes/nes_verbs.c
+++ b/drivers/infiniband/hw/nes/nes_verbs.c
@@ -476,9 +476,9 @@ static struct ib_fast_reg_page_list *nes_alloc_fast_reg_page_list(
}
nes_debug(NES_DBG_MR, "nes_alloc_fast_reg_pbl: nes_frpl = %p, "
"ibfrpl = %p, ibfrpl.page_list = %p, pbl.kva = %p, "
- "pbl.paddr= %p\n", pnesfrpl, &pnesfrpl->ibfrpl,
+ "pbl.paddr = %llx\n", pnesfrpl, &pnesfrpl->ibfrpl,
pnesfrpl->ibfrpl.page_list, pnesfrpl->nes_wqe_pbl.kva,
- (void *)pnesfrpl->nes_wqe_pbl.paddr);
+ (unsigned long long) pnesfrpl->nes_wqe_pbl.paddr);
return pifrpl;
}
@@ -3483,13 +3483,13 @@ static int nes_post_send(struct ib_qp *ibqp, struct ib_send_wr *ib_wr,
for (i = 0; i < ib_wr->wr.fast_reg.page_list_len; i++)
dst_page_list[i] = cpu_to_le64(src_page_list[i]);
- nes_debug(NES_DBG_IW_TX, "SQ_FMR: iova_start: %p, "
- "length: %d, rkey: %0x, pgl_paddr: %p, "
+ nes_debug(NES_DBG_IW_TX, "SQ_FMR: iova_start: %llx, "
+ "length: %d, rkey: %0x, pgl_paddr: %llx, "
"page_list_len: %u, wqe_misc: %x\n",
- (void *)ib_wr->wr.fast_reg.iova_start,
+ (unsigned long long) ib_wr->wr.fast_reg.iova_start,
ib_wr->wr.fast_reg.length,
ib_wr->wr.fast_reg.rkey,
- (void *)pnesfrpl->nes_wqe_pbl.paddr,
+ (unsigned long long) pnesfrpl->nes_wqe_pbl.paddr,
ib_wr->wr.fast_reg.page_list_len,
wqe_misc);
break;
> drivers/infiniband/hw/cxgb4/cq.c: In function 'destroy_cq':
> drivers/infiniband/hw/cxgb4/cq.c:58: warning: cast from pointer to integer of different size
> drivers/infiniband/hw/cxgb4/cq.c: In function 'create_cq':
> drivers/infiniband/hw/cxgb4/cq.c:135: warning: cast from pointer to integer of different size
There were a few more here, will queue:
--- a/drivers/infiniband/hw/cxgb4/cm.c
+++ b/drivers/infiniband/hw/cxgb4/cm.c
@@ -2323,7 +2323,7 @@ static int fw6_msg(struct c4iw_dev *dev, struct sk_buff *skb)
switch (rpl->type) {
case 1:
ret = (int)((be64_to_cpu(rpl->data[0]) >> 8) & 0xff);
- wr_waitp = (__force struct c4iw_wr_wait *)rpl->data[1];
+ wr_waitp = (struct c4iw_wr_wait *)(__force unsigned long) rpl->data[1];
PDBG("%s wr_waitp %p ret %u\n", __func__, wr_waitp, ret);
if (wr_waitp) {
wr_waitp->ret = ret;
diff --git a/drivers/infiniband/hw/cxgb4/cq.c b/drivers/infiniband/hw/cxgb4/cq.c
index b3daf39..af684fc 100644
--- a/drivers/infiniband/hw/cxgb4/cq.c
+++ b/drivers/infiniband/hw/cxgb4/cq.c
@@ -55,7 +55,7 @@ static int destroy_cq(struct c4iw_rdev *rdev, struct t4_cq *cq,
V_FW_RI_RES_WR_NRES(1) |
FW_WR_COMPL(1));
res_wr->len16_pkd = cpu_to_be32(DIV_ROUND_UP(wr_len, 16));
- res_wr->cookie = (u64)&wr_wait;
+ res_wr->cookie = (unsigned long) &wr_wait;
res = res_wr->res;
res->u.cq.restype = FW_RI_RES_TYPE_CQ;
res->u.cq.op = FW_RI_RES_OP_RESET;
@@ -132,7 +132,7 @@ static int create_cq(struct c4iw_rdev *rdev, struct t4_cq *cq,
V_FW_RI_RES_WR_NRES(1) |
FW_WR_COMPL(1));
res_wr->len16_pkd = cpu_to_be32(DIV_ROUND_UP(wr_len, 16));
- res_wr->cookie = (u64)&wr_wait;
+ res_wr->cookie = (unsigned long) &wr_wait;
res = res_wr->res;
res->u.cq.restype = FW_RI_RES_TYPE_CQ;
res->u.cq.op = FW_RI_RES_OP_WRITE;
--- a/drivers/infiniband/hw/cxgb4/mem.c
+++ b/drivers/infiniband/hw/cxgb4/mem.c
@@ -71,7 +71,7 @@ static int write_adapter_mem(struct c4iw_rdev *rdev, u32 addr, u32 len,
if (i == (num_wqe-1)) {
req->wr.wr_hi = cpu_to_be32(FW_WR_OP(FW_ULPTX_WR) |
FW_WR_COMPL(1));
- req->wr.wr_lo = (__force __be64)&wr_wait;
+ req->wr.wr_lo = (__force __be64)(unsigned long) &wr_wait;
} else
req->wr.wr_hi = cpu_to_be32(FW_WR_OP(FW_ULPTX_WR));
req->wr.wr_mid = cpu_to_be32(
--- a/drivers/infiniband/hw/cxgb4/qp.c
+++ b/drivers/infiniband/hw/cxgb4/qp.c
@@ -144,7 +144,7 @@ static int create_qp(struct c4iw_rdev *rdev, struct t4_wq *wq,
V_FW_RI_RES_WR_NRES(2) |
FW_WR_COMPL(1));
res_wr->len16_pkd = cpu_to_be32(DIV_ROUND_UP(wr_len, 16));
- res_wr->cookie = (u64)&wr_wait;
+ res_wr->cookie = (unsigned long) &wr_wait;
res = res_wr->res;
res->u.sqrq.restype = FW_RI_RES_TYPE_SQ;
res->u.sqrq.op = FW_RI_RES_OP_WRITE;
@@ -985,7 +985,7 @@ static int rdma_fini(struct c4iw_dev *rhp, struct c4iw_qp *qhp,
wqe->flowid_len16 = cpu_to_be32(
FW_WR_FLOWID(ep->hwtid) |
FW_WR_LEN16(DIV_ROUND_UP(sizeof *wqe, 16)));
- wqe->cookie = (u64)&wr_wait;
+ wqe->cookie = (unsigned long) &wr_wait;
wqe->u.fini.type = FW_RI_TYPE_FINI;
c4iw_init_wr_wait(&wr_wait);
@@ -1060,7 +1060,7 @@ static int rdma_init(struct c4iw_dev *rhp, struct c4iw_qp *qhp)
FW_WR_FLOWID(qhp->ep->hwtid) |
FW_WR_LEN16(DIV_ROUND_UP(sizeof *wqe, 16)));
- wqe->cookie = (u64)&wr_wait;
+ wqe->cookie = (unsigned long) &wr_wait;
wqe->u.init.type = FW_RI_TYPE_INIT;
wqe->u.init.mpareqbit_p2ptype =
--
Roland Dreier <rolandd@cisco.com> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
^ permalink raw reply related
* Re: [PATCH net-next-2.6] bridge: 64bit rx/tx counters
From: Andrew Morton @ 2010-08-10 4:47 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Stephen Hemminger, netdev, bhutchings, Nick Piggin
In-Reply-To: <1276598376.2541.93.camel@edumazet-laptop>
On Tue, 15 Jun 2010 12:39:36 +0200 Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 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.
>
Oh for fuck's sake. Will you guys just stop adding generic kernel
infrastructure behind everyone's backs?
Had I actually been aware that this stuff was going into the tree I'd
have pointed out that the u64_stats_* api needs renaming.
s/stats/counter/ because it has no business assuming that the counter
is being used for statistics.
And all this open-coded per-cpu counter stuff added all over the place.
Were percpu_counters tested or reviewed and found inadequate and unfixable?
If so, please do tell.
^ permalink raw reply
* Re: Auto generation of IPv6 link local address
From: Michał Mirosław @ 2010-08-10 4:32 UTC (permalink / raw)
To: Jon Smirl; +Cc: Netdev
In-Reply-To: <AANLkTik80QZ=KdHGuT99ftx19RcHq2KOUPMR-Lhho5aL@mail.gmail.com>
2010/8/10 Jon Smirl <jonsmirl@gmail.com>:
> When I bring my Ethernet interface up it automatically gets a link
> local IPv6 address.
>
> eth3 Link encap:Ethernet HWaddr 00:1b:21:59:65:32
> inet addr:192.168.1.8 Bcast:192.168.1.255 Mask:255.255.255.0
> inet6 addr: fe80::21b:21ff:fe59:6532/64 Scope:Link -->
> Missing from my driver
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:1836635 errors:0 dropped:0 overruns:0 frame:0
> TX packets:1283010 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:2259859914 (2.2 GB) TX bytes:121836850 (121.8 MB)
> Interrupt:16 Memory:dbd60000-dbd80000
>
> I'm writing a device driver for new 802.15.4 hardware. When I bring it
> up I don't get an automatic IPv6 link local address. What controls
> whether an adapter gets a link local address added or not? My driver
> should get one so I must have something wrong in my code.
>
> wpan0 Link encap:IEEE 802.15.4 HWaddr 00:50:c2:ff:fe:a8:a8:c5
> UP BROADCAST RUNNING NOARP MTU:1280 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:10
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
addrconf_notify() in linux-2.6.34/net/ipv6/addrconf.c does not have
code for IEEE 802.15.4. I don't know much about 802.15.4, but if IPv6
with static addresses works over it, then adding support for
autogenerated addresses should be easy (just addrconf_dev_config() and
ipv6_generate_eui64()?).
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [patch 2/2] qlcnic: using too much stack
From: Joe Perches @ 2010-08-10 3:39 UTC (permalink / raw)
To: Anirban Chakraborty
Cc: Dan Carpenter, Amit Salecha, Linux Driver, David S. Miller,
Sucheta Chakraborty, netdev@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <D084A42E-7F2A-44F7-9273-DDD9214CB877@qlogic.com>
On Mon, 2010-08-09 at 20:31 -0700, Anirban Chakraborty wrote:
> On Aug 10, 2010, at 7:33 AM, Joe Perches wrote:
> > On Mon, 2010-08-09 at 18:43 -0700, Anirban Chakraborty wrote:
> >> Your patch is fine except that the preferred way is to use kzalloc over kaclloc. kzalloc does not need that extra
> >> argument that you are passing to kcalloc.
> > You probably meant to write "my preferred way"
> > as the kcalloc to "kzalloc with a multiply"
> > ratio is pretty high.
> I was suggesting based on the following:
> http://lwn.net/Articles/147014/
Note that article suggests kzalloc for allocating
a single zeroed object.
kcalloc is used for multiple zeroed objects and
protects against oversized allocations.
^ 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