From: Eugene Teo <[EMAIL PROTECTED]>
Date: Sat, 19 May 2007 13:49:11 +0800
> Spotted by the Coverity checker.
Why am I not surprised :-(
There is no bug here, if Coverity warns every single time skb_peek()
is used and not tested against NULL, that's a very serious shortcoming
of Coverity or what
Randy Dunlap wrote:
> On Sat, 19 May 2007 13:13:07 +0800 Eugene Teo wrote:
>
>> skb_peek() might return an empty list. skb should be checked before calling
>> llc_pdu_sn_hdr() with it.
>>
>> Spotted by the Coverity checker.
>>
>> Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
[...]
>
> Oh, and you
Eugene Teo <[EMAIL PROTECTED]> wrote:
>
> diff --git a/net/llc/llc_conn.c b/net/llc/llc_conn.c
> index 3b8cfbe..28a3994 100644
> --- a/net/llc/llc_conn.c
> +++ b/net/llc/llc_conn.c
> @@ -323,7 +323,8 @@ int llc_conn_remove_acked_pdus(struct sock *sk, u8 nr, u16
> *how_many_unacked)
>
>if (
Stephen Hemminger wrote:
netif_rx() used to return a value in older kernels.
netif_rx() returns a value in current kernels.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kerne
On Fri, 18 May 2007 14:09:03 -0400
"John W. Linville" <[EMAIL PROTECTED]> wrote:
> On Wed, May 16, 2007 at 05:01:27PM -0400, Florin Malita wrote:
> > In libertas_process_rxed_packet() and process_rxed_802_11_packet() the
> > skb is dereferenced after being passed to netif_rx (called from
> > lib
Daniel Schaffrath <[EMAIL PROTECTED]> wrote:
>
> I was wondering what the purpose of the bit shifts in tcp_get_info
> right after the jiffies conversion might be. What's the time unit
> after that shift?
>
> info->tcpi_rtt = jiffies_to_usecs(tp->srtt)>>3;
> info->tcpi_rttvar =
4:03pm Kok, Auke said:
Chuck Ebbert wrote:
We have several reports now of hitting this assertion in
netif_rx_complete(), inlined in e1000_clean():
BUG_ON(!test_bit(__LINK_STATE_RX_SCHED, &dev->state));
[] __queue_work+0x51/0x5e
[] et_rx_action+0x94/0x185
[] __do_softirq+0x5d/
Chuck Ebbert wrote:
We have several reports now of hitting this assertion in
netif_rx_complete(), inlined in e1000_clean():
BUG_ON(!test_bit(__LINK_STATE_RX_SCHED, &dev->state));
[] __queue_work+0x51/0x5e
[] et_rx_action+0x94/0x185
[] __do_softirq+0x5d/0xba
[] do_softirq+0x59/0xb1
We have several reports now of hitting this assertion in
netif_rx_complete(), inlined in e1000_clean():
BUG_ON(!test_bit(__LINK_STATE_RX_SCHED, &dev->state));
[] __queue_work+0x51/0x5e
[] et_rx_action+0x94/0x185
[] __do_softirq+0x5d/0xba
[] do_softirq+0x59/0xb1
[] local_bh_enable_ip+
On Friday 18 May 2007, Andrew Morton wrote:
>On Fri, 18 May 2007 23:46:21 +0200
>
>Mariusz Koz__owski <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> > diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
>> > index 7053026..111f23d 100644
>> > --- a/drivers/net/smc91x.h
>> > +++ b/drivers/net/smc91
> > > diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
> > > index 7053026..111f23d 100644
> > > --- a/drivers/net/smc91x.h
> > > +++ b/drivers/net/smc91x.h
> > > @@ -279,6 +279,40 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg)
> >
> > ...
> >
> > > +#define SMC_outb(v, a, r) __ __
On Fri, 18 May 2007 23:46:21 +0200
Mariusz Koz__owski <[EMAIL PROTECTED]> wrote:
> Hello,
>
> > diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
> > index 7053026..111f23d 100644
> > --- a/drivers/net/smc91x.h
> > +++ b/drivers/net/smc91x.h
> > @@ -279,6 +279,40 @@ SMC_outw(u16 val, void
Hello,
> diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
> index 7053026..111f23d 100644
> --- a/drivers/net/smc91x.h
> +++ b/drivers/net/smc91x.h
> @@ -279,6 +279,40 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg)
...
> +#define SMC_outb(v, a, r) outw(((inw((a)+((r)&~1))*(0xf
On Fri, May 18, 2007 at 02:34:12PM +1000, Herbert Xu wrote:
>
> Actually, I think we should just probe for the specific algorithm
> requested rather than everything. See patch below.
Doh, forgot to actually remove the probe call :)
[IPSEC] pfkey: Load specific algorithm in pfkey_add rather than
Hello Paul,
as you may see in the attached SVN-log i changed some code according
your suggestions.
I additionally made some clarifications of function names.
If you would like to see the af_can.c completely please visit:
http://svn.berlios.de/svnroot/repos/socketcan/trunk/kernel/2.6/net/can/af
Rick Jones wrote:
as an asside, "tcp_max_ssthresh" sounds like the maximum value ssthresh
can take-on. is that correct, or is this more of a "once ssthresh is
above this, behave in this new way?" If that is the case, while the
I don't like it either, but you'll have to talk to Sally Floyd a
John W. Linville wrote:
Also, libertas_upload_rx_packet() unconditionally returns 0 so the error
check is dead code - might as well take it out.
Is this merely an implementation detail? Or an absolute fact?
I believe it's an absolute fact that got lost among implementation
details ;
Baruch Even wrote:
Ilpo Järvinen wrote:
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
Documentation/networking/ip-sysctl.txt | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt
b/Documentation/networking/ip-sysctl.t
On Wed, May 16, 2007 at 05:01:27PM -0400, Florin Malita wrote:
> In libertas_process_rxed_packet() and process_rxed_802_11_packet() the
> skb is dereferenced after being passed to netif_rx (called from
> libertas_upload_rx_packet). Spotted by Coverity (1658, 1659).
Relocating the libertas_uploa
Ilpo Järvinen wrote:
> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
> ---
> Documentation/networking/ip-sysctl.txt | 13 +
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/networking/ip-sysctl.txt
> b/Documentation/networking/ip-sysctl.txt
> in
David Acker wrote:
Kok, Auke wrote:
First impression just came in: It seems RX performance is dropped to
10mbit. TX is unaffected and runs at 94mbit/tcp, but RX the new code
seems to misbehave and fluctuate, dropping below 10mbit after a few
netperf runs and staying there...
ideas?
I foun
Herbert Xu wrote:
Mark Huth <[EMAIL PROTECTED]> wrote:
This patch provides a performance optimization in the pfkey_add path.
Prior versions have a serious performance problem when adding a large
number of SAs to a node. For example, if a backup node needs to be
loaded with the SAs previously
Kok, Auke wrote:
First impression just came in: It seems RX performance is dropped to
10mbit. TX is unaffected and runs at 94mbit/tcp, but RX the new code
seems to misbehave and fluctuate, dropping below 10mbit after a few
netperf runs and staying there...
ideas?
I found the problem. Anot
On Thu, May 17, 2007 at 09:28:53AM +1000, Michael Ellerman wrote:
> On Wed, 2007-05-16 at 17:00 -0500, Linas Vepstas wrote:
> > - pr_err("Not enough memory to allocate rx buffer\n");
> > + pr_err("%s: Not enough memory to allocate rx buffer\n",
> > +
On Thu, May 17, 2007 at 08:46:00PM -0400, Jeff Garzik wrote:
> Linas Vepstas wrote:
>
> applied
Thanks
--linas
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
Documentation/networking/ip-sysctl.txt | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt
b/Documentation/networking/ip-sysctl.txt
index ce16e6a..44ba8d4 100644
--- a/Do
David Acker wrote:
Kok, Auke wrote:
David Acker wrote:
David Acker wrote:
Done. Below is a patch against 2.6.22-rc1. It combines removing the
s-bit patch and applying the patch I previously sent.
Oops. I missed one state in that patch. Since the el-bit buffer will
normally not complete du
Kok, Auke wrote:
David Acker wrote:
David Acker wrote:
Done. Below is a patch against 2.6.22-rc1. It combines removing the
s-bit patch and applying the patch I previously sent.
Oops. I missed one state in that patch. Since the el-bit buffer will
normally not complete due to a zero size,
On Fri, 18 May 2007 09:07:42 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On May 17, 2007, at 8:53 PM, Jeff Garzik wrote:
>
> > Kim Phillips wrote:
> >> On Tue, 15 May 2007 17:45:19 -0400
> >> Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >>> Kim Phillips wrote:
> It was agreed that phy-conne
David Acker wrote:
David Acker wrote:
Kok, Auke wrote:
Jeff Garzik wrote:
Can you resend against the latest kernel (2.6.22-rc1)?
And what does Intel think?
I'm expecting at least a reply from Milton as the patch was sent to
him. I haven't yet tested it but will certainly do so. At first glan
Hm, this is indeed one step further, than i thought :-)
Thanks for this nifty solution!
I will doublecheck your suggestion with Urs and then we'll change it in
our next patch update (after some more feedback on this mailing list).
Additional feedback is welcome.
Tnx & best regards,
Oliver
Pa
On Fri, May 18, 2007 at 11:19:01AM +0200, Oliver Hartkopp wrote:
> Hi Urs, Hello Paul,
>
> i assume Paul refers to the can_rx_delete_all() function that adds each
> receive list entry for rcu removal using the can_rx_delete RCU callback,
> right?
>
> So the idea would be to create a second RCU
David Acker wrote:
Kok, Auke wrote:
Jeff Garzik wrote:
Can you resend against the latest kernel (2.6.22-rc1)?
And what does Intel think?
I'm expecting at least a reply from Milton as the patch was sent to
him. I haven't yet tested it but will certainly do so. At first glance
it looks OK, a
On May 17, 2007, at 8:53 PM, Jeff Garzik wrote:
Kim Phillips wrote:
On Tue, 15 May 2007 17:45:19 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
Kim Phillips wrote:
It was agreed that phy-connection-type was a better name for
the interface-type property, so this patch renames it.
Also, the max
Kok, Auke wrote:
Jeff Garzik wrote:
Can you resend against the latest kernel (2.6.22-rc1)?
And what does Intel think?
I'm expecting at least a reply from Milton as the patch was sent to him.
I haven't yet tested it but will certainly do so. At first glance it
looks OK, and I'll try to put i
This is a repost of some earlier patches to the xen-devel mailing list,
with a number of changes thanks to some useful suggestions from others.
Apologies for the short delay in getting this next version ready.
I've also CC'd netdev@vger.kernel.org as some of the files being patched
may be merged i
Add accel option to vif xend config to allow users to specify which
interfaces should be accelerated using which plugin modules.
diff -r 194f5b88d257 tools/python/xen/xend/server/netif.py
--- a/tools/python/xen/xend/server/netif.py Tue Apr 17 09:04:51 2007
+0100
+++ b/tools/python/xen/xend/server/
Add support to Xen netback to support accelerated plugin module
diff -r da9639486bf2 linux-2.6-xen-sparse/drivers/xen/netback/common.h
--- a/linux-2.6-xen-sparse/drivers/xen/netback/common.h Fri May 18
10:36:47 2007 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/netback/common.h Fri May 18
11:02:49
Provide two helper functions (xenbus_for_each_frontend,
xenbus_for_each_backend) to allow drivers to iterate the xenbus frontend
and backend buses.
diff -r 4f67d849e788 linux-2.6-xen-
sparse/drivers/xen/xenbus/xenbus_probe.c
--- a/linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_probe.c Tue Apr 03
0
On Wednesday 16 May 2007 17:37, Anton Blanchard wrote:
> Hi Hugh,
>
> > It's interesting that compat_core_sys_select() shows this kmalloc(0)
> > failure but core_sys_select() does not. That's because core_sys_select()
> > avoids kmalloc by using a buffer on the stack for small allocations (and
> >
On Wed, 2007-16-05 at 23:25 -0400, jamal wrote:
>
> This patch now includes two changed drivers (tun and e1000). I have
> tested tun with this patch. I tested e1000 earlier and i couldnt find
> any issues - although as the tittle says its a WIP.
>
> As before you need net-2.6. You also need the
On Friday 18 May 2007 06:17, Jeff Garzik wrote:
> Mithlesh Thukral wrote:
> > NetXen: Changes related to registers and their access routines
> > This patch updates the various access routines to access different
> > control and status settings present in different register locations.
> > This will
Hi Urs, Hello Paul,
i assume Paul refers to the can_rx_delete_all() function that adds each
receive list entry for rcu removal using the can_rx_delete RCU callback,
right?
So the idea would be to create a second RCU callback - e.g.
can_rx_delete_list() - that removes the complete list inside
State could become inconsistent in two cases:
1) Userspace disabled FRTO by tuning sysctl when one of the TCP
flows was in the middle of FRTO algorithm (and then RTO is
again triggered)
2) SACK reneging occurs during FRTO algorithm
A simple solution is just to abort the previous FRTO when
The conservative spurious RTO response did not queue CWR even
though the sending rate was lowered. Whenever reduction happens
regardless of reason, CWR should be sent (forgetting to send it
is not very fatal though).
A better approach would be to queue CWR when one of the sending
rate reducing res
From: Julian Anastasov <[EMAIL PROTECTED]>
Date: Fri, 18 May 2007 11:40:54 +0300 (EEST)
> On Thu, 17 May 2007, Patrick McHardy wrote:
>
> > In any case some better solution than the current one needs to be
> > found, allowing users to send spoofed packets is far worse than
> > using a non-desired
Hello,
On Thu, 17 May 2007, Patrick McHardy wrote:
> > But what is preferred is to use VIP in ICMP.
> >
> > ip route add local VIP dev lo table user_defined
> >
> > returns RTCF_LOCAL but inet_addr_type() does not return RTN_LOCAL,
> > we fix one thing but break another :)
>
>
Hi,
Fix looks good. I have couple of comments,
1) Return from s2io_updt_stats function if the PCI bus is offline
(pci_channel_offline).
if (pci_channel_offline(pdev))
return;
2) No Need to call netif_wake_queue() in s2io_io_resume as
netif_device_attach() will take care
David Miller wrote:
> From: "Michael Chan" <[EMAIL PROTECTED]>
> Date: Tue, 15 May 2007 15:05:28 -0700
>
> > For each gso_seg, there will be a header and the payload may span 2
> > pages for 1500-byte packets. We always assume 1500-byte packets
> > because the buggy chips do not support jumbo fr
49 matches
Mail list logo