netdev
[Top] [All Lists]

Re: [BUG] overflow in net/ipv4/route.c rt_check_expire()

To: Eric Dumazet <dada1@xxxxxxxxxxxxx>
Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire()
From: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Fri, 1 Apr 2005 12:28:02 -0800
Cc: netdev@xxxxxxxxxxx
In-reply-to: <424D5D34.4030800@xxxxxxxxxxxxx>
References: <42370997.6010302@xxxxxxxxxxxxx> <20050315103253.590c8bfc.davem@xxxxxxxxxxxxx> <42380EC6.60100@xxxxxxxxxxxxx> <20050316140915.0f6b9528.davem@xxxxxxxxxxxxx> <4239E00C.4080309@xxxxxxxxxxxxx> <20050331221352.13695124.davem@xxxxxxxxxxxxx> <424D5D34.4030800@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Fri, 01 Apr 2005 16:39:48 +0200
Eric Dumazet <dada1@xxxxxxxxxxxxx> wrote:

> > If spinlock_t is a zero sized structure on UP, how can this save memory
> > on UP? :-)
> 
> Because I deleted the  __attribute__((__aligned__(8))) constraint on struct 
> rt_hash_bucket.

Right.

> > Anyways, I think perhaps you should dynamically allocate this lock table.
> 
> Maybe I should make a static sizing, (replace the 256 constant by something 
> based on MAX_CPUS) ?

Even for NR_CPUS, I think the table should be dynamically allocated.

It is a goal to eliminate all of these huge arrays in the static
kernel image, which has grown incredibly too much in recent times.
I work often to eliminate such things, let's not add new ones :-)

<Prev in Thread] Current Thread [Next in Thread>