Sizes in bytes (allyesconfig, i386) and files where those inlines
are used:
238 sock_queue_rcv_skb 2.6.16/net/x25/x25_in.o
238 sock_queue_rcv_skb 2.6.16/net/rose/rose_in.o
238 sock_queue_rcv_skb 2.6.16/net/packet/af_packet.o
238 sock_queue_rcv_skb 2.6.16/net/netrom/nr_in.o
238 sock_queue_rcv_skb 2
David S. Miller
> From: walt <[EMAIL PROTECTED]>
> Date: Sun, 26 Mar 2006 08:35:50 -0800
>
> > Can you think of which of those recent changes might be
> > a likely candidate?
>
> I think you'll need to use something like "git bisect" to narrow down
> the changeset.
Try this patch first before g
On Sunday 26 March 2006 21:18, Lennert Buytenhek wrote:
> gcc4 doesn't allow declaring a static function inside another function,
> so convert to extern. (The function whose prototype we're changing is
> not defined anywhere and intended purely to cause a link error when some
> internal calculatio
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Sun, 26 Mar 2006 14:24:10 +0200
> From: Norbert Kiesel <[EMAIL PROTECTED]>
>
> Just noticed that request_sock.[ch] contain a useless assignment of
> rskq_accept_head to itself. I assume this is a typo and the 2nd one
> was supposed to be _tail. Howeve
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sun, 26 Mar 2006 22:39:02 +1100
> The error handling in ipcomp6_tunnel_create is broken in two ways:
>
> 1) If we fail to allocate an SPI (this should never happen in practice
> since there are plenty of 32-bit SPI values for us to use), we will
> still
On Thu, 2006-03-02 at 13:40 -0600, Santiago Leon wrote:
> From: Michael Ellerman <[EMAIL PROTECTED]>
>
> After a kexec the veth driver will fail when trying to register with the
> Hypervisor because the previous kernel has not unregistered.
>
> So if the registration fails, we unregister and then
Andi Kleen wrote:
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.
From: walt <[EMAIL PROTECTED]>
Date: Sun, 26 Mar 2006 08:35:50 -0800
> Can you think of which of those recent changes might be
> a likely candidate?
I think you'll need to use something like "git bisect" to narrow down
the changeset.
-
To unsubscribe from this list: send the line "unsubscribe net
gcc4 doesn't allow declaring a static function inside another function,
so convert to extern. (The function whose prototype we're changing is
not defined anywhere and intended purely to cause a link error when some
internal calculations go awry.)
Signed-off-by: Lennert Buytenhek <[EMAIL PROTECTED
On Sun, Mar 26, 2006 at 09:12:15PM +0200, richard lucassen wrote:
> Here are two patches against 2.6.16 to make the number of IFB devices
> variable (1-8).
Why not pass a module parameter?
module_param(numifbs, int, 0);
MODULE_PARM_DESC(numifbs, "Number of ifb devices");
--L
-
Hello Dave,
Here are two patches against 2.6.16 to make the number of IFB devices
variable (1-8).
Richard.
--
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.
+
On Sun, 2006-26-03 at 22:14 +0530, Balbir Singh wrote:
> Jamal,
>
> Does the implementation of these utilities look ok? We use genlmsg_data()
> in the delay accounting code but not genlmsg_len(), hence it might not
> be very well tested (just reviewed).
>
They look fine to me - please resubmit
On Mon, Mar 13, 2006 at 07:55:05PM -0500, Shailabh Nagar wrote:
> genetlink-utils.patch
>
> Two utilities for simplifying usage of NETLINK_GENERIC
> interface.
>
> Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
> Signed-off-by: Shailabh Nagar <[EMAIL PROTECTED]>
>
> include/net/genetlink.h |
On Sun, Mar 26, 2006 at 09:05:18AM -0500, jamal wrote:
> On Sat, 2006-25-03 at 23:52 +0530, Balbir Singh wrote:
>
>
> > No, we cannot have both passed. If we pass both a PID and a TGID and
> > then the code returns just the stats for the PID.
> >
>
> ok, that clears it then; i think you are rea
Michael Chan wrote:
> Walt wrote:
>
>> Nope, it was the second one: Skip phy power down...
>> Let me know if can test any patches, etc.
>
> It doesn't make sense. This code should have no effect on your
> 5702
Wait -- new developments! You are right, it wasn't that code
at all. I've concl
On Sat, 2006-03-25 20:47:39 +0100, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> 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
On Sat, 2006-25-03 at 23:52 +0530, Balbir Singh wrote:
> No, we cannot have both passed. If we pass both a PID and a TGID and
> then the code returns just the stats for the PID.
>
ok, that clears it then; i think you are ready to go.
> >
> > Also in regards to the nesting, isnt there a need fo
From: Norbert Kiesel <[EMAIL PROTECTED]>
Just noticed that request_sock.[ch] contain a useless assignment of
rskq_accept_head to itself. I assume this is a typo and the 2nd one
was supposed to be _tail. However, setting _tail to NULL is not
needed, so the patch below just drops the 2nd assignmen
Hi Dave:
Just when I think I've almost got the ipip/xfrm stuff finished I get
caught by yet another bug :) I should have that stuff ready tomorrow
though.
The error handling in ipcomp6_tunnel_create is broken in two ways:
1) If we fail to allocate an SPI (this should never happen in practice
si
19 matches
Mail list logo
