Re: [PATCH 0/0]: Cassini bug fixes.

2008-01-04 Thread Balazs Scheidler
On Fri, 2008-01-04 at 00:32 -0800, David Miller wrote: > Over the past day I've put together the following set of bug fixes for > the Cassini driver. > > At least with my setup it appears to basically work fine, not leak > memory, and the SKB BUG messages go away too. > > I'll be honest and say

Re: cassini driver skb->truesize bug

2007-12-05 Thread Balazs Scheidler
Some more investigation revealed that the cassini driver leaks the data portion of all RXed packets, this makes the driver completely unusable. We've tested the following combinations: * 2.6.17 (patched, but no cassini related patches) * 2.6.22 Ubuntu Gutsy. It still worked in 2.6.12 where we o

Re: [PATCHv6 0/3] Interface group patches

2007-11-21 Thread Balazs Scheidler
On Wed, 2007-11-21 at 01:25 +0100, Patrick McHardy wrote: > David Miller wrote: > > From: Laszlo Attila Toth <[EMAIL PROTECTED]> > > Date: Tue, 20 Nov 2007 14:52:12 +0100 > > > >> Jan Engelhardt írta: > >>> On Nov 20 2007 14:14, Laszlo Attila Toth wrote: > This is the 6th version of our inte

Re: [IPV4] LVS: Allow to send ICMP unreachable responses when real-servers are removed

2007-06-20 Thread Balazs Scheidler
Hi, Is there a chance that this, or a patch with similar spirit (e.g. a way to send packets from non-local IP addresses) could be merged? On Fri, 2007-06-01 at 02:18 +0300, Julian Anastasov wrote: > Hello, > > On Thu, 31 May 2007, KOVACS Krisztian wrote: > > > So what about this one? >

Re: [PATCH/RFC 01/10] Implement local diversion of IPv4 skbs

2007-01-10 Thread Balazs Scheidler
On Wed, 2007-01-10 at 07:46 +0100, Patrick McHardy wrote: > KOVACS Krisztian wrote: > > + rth->u.dst.lastuse = jiffies; > > + dst_hold(&rth->u.dst); > > + rth->u.dst.__use++; > > + RT_CACHE_STAT_INC(in_hit); > > +

Re: [patch] RFC: matching interface groups

2006-08-07 Thread Balazs Scheidler
On Fri, 2006-08-04 at 12:06 +0200, Patrick McHardy wrote: > Balazs Scheidler wrote: > > The use-case is as follows: > > > > * I have two different subsystems creating interfaces dynamically (for > > example pptpd and serial pppd lines, each creating dynamic pppX >

Re: [patch] RFC: matching interface groups

2006-08-03 Thread Balazs Scheidler
On Wed, 2006-08-02 at 21:08 -0700, Stephen J. Bevan wrote: > Balazs Scheidler writes: > > I would like to easily match a set of dynamically created interfaces > > from my packet filter rules. The attached patch forms the basis of my > > implementation and I would like to k

Re: [patch] RFC: matching interface groups

2006-08-02 Thread Balazs Scheidler
On Tue, 2006-08-01 at 11:29 -0700, Stephen Hemminger wrote: > On Tue, 01 Aug 2006 19:10:09 +0200 > Balazs Scheidler <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > I would like to easily match a set of dynamically created interfaces > > from my packet fil

Re: [patch] RFC: matching interface groups

2006-08-02 Thread Balazs Scheidler
On Tue, 2006-08-01 at 21:18 +0200, Sven Schuster wrote: > Hi Phil, > > On Tue, Aug 01, 2006 at 11:46:55AM -0700, Phil Oester told us: > > Since in this scenario userspace is able to determine ppp vs pptp, > > could you not also do something like have an inbound_ppp and inbound_pptp > > chain, the

[patch] RFC: matching interface groups

2006-08-01 Thread Balazs Scheidler
Hi, I would like to easily match a set of dynamically created interfaces from my packet filter rules. The attached patch forms the basis of my implementation and I would like to know whether something like this is mergeable to mainline. The use-case is as follows: * I have two different subsyste

Re: [NETFILTER] NAT sequence adjustment: Save eight bytes per conntrack

2006-01-31 Thread Balazs Scheidler
On Tue, 2006-01-31 at 00:22 +0100, Harald Welte wrote: > --- > commit 94d3d40c84672b74e59ea5252f61602610e1513e > tree 63e5ae5174af9f982be6d8d1bbe11e750e4ace32 > parent e3c7a1f99300fbd6de35a40fcd9c4dc1b0fbfee2 > author Harald Welte <[EMAIL PROTECTED]> Fri, 27 Jan 2006 16:03:45 +0100 > committer Har

[PATCH] move XFRM state tables from bss to dynamically allocated pages

2005-08-13 Thread Balazs Scheidler
Hi, Against latest net-2.6.14, but should apply to other versions as well. Please apply. diff-tree b13ca94bb73c79cbc1b34c4261b02c3df934498a (from c097bee59e15d4703e53b8c21d9e9ce5da9365bc) Author: Balazs Scheidler <[EMAIL PROTECTED]> Date: Sat Aug 13 16:24:25 2005 +0200 As dis

Re: [PATCH] xfrm: do not use large arrays in BSS

2005-08-11 Thread Balazs Scheidler
On Thu, 2005-08-11 at 14:44 +0200, Balazs Scheidler wrote: > On Thu, 2005-08-11 at 22:31 +1000, Herbert Xu wrote: > > Balazs Scheidler <[EMAIL PROTECTED]> wrote: > > > > > > I've attached a revised patch, this time with complete error checking, > > &g

Re: [PATCH] xfrm: do not use large arrays in BSS

2005-08-11 Thread Balazs Scheidler
On Thu, 2005-08-11 at 22:31 +1000, Herbert Xu wrote: > Balazs Scheidler <[EMAIL PROTECTED]> wrote: > > > > I've attached a revised patch, this time with complete error checking, and > > propagating the error code to the caller. Please apply. > > Sorry, but

Re: [PATCH] xfrm: do not use large arrays in BSS

2005-08-11 Thread Balazs Scheidler
On Mon, 2005-08-08 at 16:27 +0200, Balazs Scheidler wrote: > Is this tiny patchlet worth the trouble of changing > xfrm_init/xfrm_state_init to return int, and do error checking from > ip_rt_init() ? I've attached a revised patch, this time with complete error checking, and propaga

Re: [PATCH] xfrm: do not use large arrays in BSS

2005-08-08 Thread Balazs Scheidler
Sent to myself the first time. > > > > > > @@ -1097,6 +1097,8 @@ void __init xfrm_state_init(void) > > { > > int i; > > > > + xfrm_state_bydst = (struct list_head *) > > __get_free_pages(GFP_KERNEL, get_order(sizeof(struct list_head) * > > XFRM_DST_HSIZE * 2)); > > + xfr

[PATCH] xfrm: do not use large arrays in BSS

2005-08-07 Thread Balazs Scheidler
Hi, Commit log says it all. Signed-off-by: Balazs Scheidler <[EMAIL PROTECTED]> diff-tree a262e285077cb1604c25c5de99d71bbf739823e2 (from 684a28105211367d9040ee945cead597912cc49e) Author: Balazs Scheidler <[EMAIL PROTECTED](none)> Date: Sun Aug 7 20:23:59 2005 +0200 As disc

Re: [PATCH] possible overflow of sock->sk_policy

2005-07-25 Thread Balazs Scheidler
> Hi, > > I'm attaching a small testprogram which tries to install an > XFRM_POLICY_FWD, and I confirmed with a printk that the value of 2 is > successfully propagated to xfrm_sk_policy_insert(). test program originally missed, here it is this time. -- Bazsi #include #include #include #incl

[PATCH] possible overflow of sock->sk_policy

2005-07-25 Thread Balazs Scheidler
gle unsigned int value and no pointers. A possible fix below can be found at the end of this mail. Signed-off-by: Balazs Scheidler <[EMAIL PROTECTED]> --- a/net/xfrm/xfrm_policy.c +++ b/net/xfrm/xfrm_policy.c @@ -571,6 +571,9 @@ int xfrm_policy_delete(struct xfrm_polic int xfrm_sk_policy_inse