G'day list
Coverity found 3 'OVERRUN_STATIC' in de4x5.c, @ lines 4814, 5115 and
5125.
Looking at the code these look like very minor problems, but as they are
easy to fix I though I would do a patch.
The patch below just adds an explicit check for the array index in
type3_infoblock() and correct
On Saturday 25 March 2006 23:32, Mark Butler wrote:
> A true firewall should never need to do anything but drop packets and
> reset connections. Changes to the way packets are routed should be done
> at the routing layer, using the flow information from the transport
> layer.
The real world
On 3/24/06, Zhu Yi <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-03-23 at 15:02 +0100, Alessandro Suardi wrote:
> > That scp test shows 50%ish - but that was a quickie. The VNC
> > client even reported a 719Kbps throughput down from the more
> > usual 11500Kbps it starts off with. The first scp I tri
David S. Miller wrote:
From: Mark Butler <[EMAIL PROTECTED]>
Date: Fri, 24 Mar 2006 22:37:26 -0700
On a more general note, I find the idea that a current dst entry doesn't
actually reflect the interface (even a logical interface) and nexthop
that will be used to deliver a packet a little d
On Thu, 2006-03-23 at 22:01 -0800, David S. Miller wrote:
> Otherwise looks fine.
>
> Please find a non-x86_64 64-bit system to at least cross compile test
> into, preferably big-endian to really get all the nasties out :-)
That reminds me that I should really add something to the ppc64 iommu
co
On Fri, Mar 24, 2006 at 02:32:41PM -0800, Stephen Hemminger wrote:
> On Fri, 24 Mar 2006 22:13:54 +
> Michael Menegakis <[EMAIL PROTECTED]> wrote:
>
> >
> > were they any helpfull?
>
> The first thing to look for is are packets showing up (and being transmitted)
> by doing
> ethtool -S
Up to now, we were using ACX_PACKED after every field. I've finally
found out how to use only one at the end of each struct whilst
maintaining the typedef where it is now.
This should also apply to acx with a bit of fuzz, but I consider it to
be in maintenance mode, so this doesn't qualify for it.
On Sat, Feb 25, 2006 at 11:46:31PM +0100, Olaf Hering wrote:
> On Sat, Feb 25, Adrian Bunk wrote:
>
> > CONFIG_UNIX=m doesn't make much sense.
>
> There is likely more code to support a modular unix.ko, this has to go
> as well.
Sounds resonable, updated patch below.
cu
Adrian
<-- snip -->
On 3/25/06, jamal <[EMAIL PROTECTED]> wrote:
> On Sat, 2006-25-03 at 21:06 +0530, Balbir Singh wrote:
> > On Sat, Mar 25, 2006 at 07:52:13AM -0500, jamal wrote:
>
>
> I didnt pay attention to failure paths etc; i suppose your testing
> should catch those. Getting there, a couple more comments:
>
Y
On Sat, 2006-25-03 at 21:06 +0530, Balbir Singh wrote:
> On Sat, Mar 25, 2006 at 07:52:13AM -0500, jamal wrote:
I didnt pay attention to failure paths etc; i suppose your testing
should catch those. Getting there, a couple more comments:
> +enum {
> + TASKSTATS_CMD_UNSPEC = 0, /* Rese
On Sat, Mar 25, 2006 at 03:16:20PM +0100, Michael Buesch wrote:
> Hm, and I think someone already reported that issue, John:
>
> [EMAIL PROTECTED]:~/develop/git/buesch-wireless-2.6$ git pull linville softmac
> error: no such remote ref refs/heads/softmac
> Fetch failure:
> git://kernel.org/pub/sc
On Sat, Mar 25, 2006 at 07:52:13AM -0500, jamal wrote:
> On Sat, 2006-25-03 at 15:11 +0530, Balbir Singh wrote:
>
> >
> > Thanks for the advice, I will dive into nesting. I could not find any
> > in tree users who use nesting, so I have a few questions
> >
>
> Hrm - I have to say i am suprised
The spectrum_cs driver uses request_firmware()
and thus needs to select FW_LOADER.
Signed-off-by: maximilian attems <[EMAIL PROTECTED]>
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index 6a1033e..3f02b87 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wirel
On Fri, Mar 24, 2006 at 10:40:38PM -0800, Greg KH wrote:
> On Fri, Mar 24, 2006 at 09:24:53PM -0800, Jouni Malinen wrote:
> > Please apply following two patches to Host AP driver in wireless-2.6.
> > The second patch ("Fix EAPOL frame encryption") is a trivial bug fix for
> > a somewhat unfortunate
> host in the internet is able to hang any such machine by sending an
The ipv6-enabled internet of course :-)
Hugo
signature.asc
Description: Digital signature
> I'd rather the suggested cleanup occur to solve this, and I think
> the fix is not so urgent that we can wait for the correct version
> to get coded up.
I would be glad to code a better version like i specified in an
earlier mail. I just didn't do it yet because Herbert said he would do
it.
On Sat, 2006-25-03 at 15:11 +0530, Balbir Singh wrote:
>
> Thanks for the advice, I will dive into nesting. I could not find any
> in tree users who use nesting, so I have a few questions
>
Hrm - I have to say i am suprised theres nothing; i could have sworn
Thomas had done some conversions al
Previously we added NET_IP_ALIGN so an architecture can override the
padding done to align headers. The next step is to allow the skb
headroom to be overridden.
We currently always reserve 16 bytes to grow into, meaning all DMAs
start 16 bytes into a cacheline. On ppc64 we really want DMA writes
On Fri, Mar 24, 2006 at 08:19:25PM -0500, jamal wrote:
> On Fri, 2006-24-03 at 20:24 +0530, Balbir Singh wrote:
>
> > Hmm... Would it be ok to send one message with the following format
> >
> > 1. TLV=TASKSTATS_TYPE_PID
> > 2. TLV=TASKSTATS_TYPE_STATS
> > 3. TLV=TASKSTATS_TYPE_TGID
> > 4. TLV=TAS
On Sat, Mar 25, 2006 at 01:24:55AM -0800, David S. Miller wrote:
>
> Looks great, applied.
>
> Did you actually encounter some bug due to this or it is purely
> from code audit?
It's code inspection arising out of the parameterised crypto stuff
that I'm currently working on.
Cheers,
--
Visit Op
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 24 Mar 2006 22:51:16 +1100
> On Thu, Feb 16, 2006 at 10:04:14PM +0200, Ilia Sotnikov wrote:
> >
> > Here it is, against 2.6.16-rc3.
>
> OK, I've brought this patch up-to-date with 2.6.16 and got rid of a few
> more references to tos in ip_rt_redire
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 24 Mar 2006 09:23:27 -0800
> We should also tag tcp_rmem/tcp_wmem as __read_mostly
I've done this, thanks for the suggestion.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
Mo
From: John Heffner <[EMAIL PROTECTED]>
Date: Fri, 24 Mar 2006 11:47:29 -0500
> This patch sets the maximum TCP buffer sizes (available to automatic buffer
> tuning, not to setsockopt) based on the TCP memory pool size. The maximum
> sndbuf and rcvbuf each will be up to 4 MB, but no more than 1/
From: Rick Jones <[EMAIL PROTECTED]>
Date: Fri, 24 Mar 2006 09:45:51 -0800
> Stephen Hemminger wrote:
> > We should also tag tcp_rmem/tcp_wmem as __read_mostly
>
> That would apply to just about all the tcp sysctl's yes?
Yes, absolutely.
-
To unsubscribe from this list: send the line "unsubscrib
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 25 Mar 2006 08:45:39 +1100
> Hugo Santos <[EMAIL PROTECTED]> wrote:
> > This patch fixes a soft lockup in ip6_tunnel when not using
> > xfrm6_tunnel (CONFIG_INET6_TUNNEL). It is triggered when an encapsula-
> > ted packet reaches ip6ip6_rcv() and t
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 25 Mar 2006 16:42:56 +1100
> I was working on the ipip/xfrm problem and as usual I get side-tracked by
> other problems.
It is the nature of the game :-)
> As part of an attempt to change the IPv4 protocol handler calling
> convention I found that
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 25 Mar 2006 16:00:51 +1100
> The netdev notifier call chain is currently unregistered without taking
> any locks outside the notifier system. Because the notifier system itself
> does not synchronise unregistration with respect to the calling of the
From: [EMAIL PROTECTED]
Date: Sat, 25 Mar 2006 00:33:46 -0800
> A possible bug:
>
> rt_fill_info() calls ipmr_get_route().
>
> ipmr_get_route() calls ipmr_cache_unresolved()
>
> ipmr_cache_unresolved() gets an error and does kfree_skb(skb)
>
> ipmr_cache_unres
From: Mark Butler <[EMAIL PROTECTED]>
Date: Fri, 24 Mar 2006 22:37:26 -0700
> On a more general note, I find the idea that a current dst entry doesn't
> actually reflect the interface (even a logical interface) and nexthop
> that will be used to deliver a packet a little disturbing. It would
>
From: Huyen Nguyen <[EMAIL PROTECTED]>
A possible bug:
rt_fill_info() calls ipmr_get_route().
ipmr_get_route() calls ipmr_cache_unresolved()
ipmr_cache_unresolved() gets an error and does kfree_skb(skb)
ipmr_cache_unresolved() returns a -ve errno to
30 matches
Mail list logo
