Re: Broken commit: [NETFILTER]: ipt_REJECT: remove largely duplicate route_reverse function
Krzysztof Halasa wrote: Patrick McHardy [EMAIL PROTECTED] writes: It might be the case that your network device has a hard_header_len LL_MAX_HEADER, which could trigger a corruption. Hmm... GRE tunnels add 24 bytes... I just noticed the following code in include/linux/netdevice.h: /* * Compute the worst case header length according to the protocols * used. */ #if !defined(CONFIG_NET_IPIP) \ !defined(CONFIG_IPV6) !defined(CONFIG_IPV6_MODULE) #define MAX_HEADER LL_MAX_HEADER #else #define MAX_HEADER (LL_MAX_HEADER + 48) #endif I don't use AX25, Token Ring, the old IPIP tunnels nor IPv6 here, but I wonder if GRE tunnel (which is basically another, more compatible form of IPIP) need the same treatment as IPIP. Both ipip and gre do this: dev-hard_header_len= LL_MAX_HEADER + sizeof(struct iphdr); which explains it. It is a bug in the REJECT target, but I was wondering whether you were really seeing this. It looks like it makes sense to add GRE to the MAX_HEADER case above though. Please try this patch on top of the REJECT patch (ideally after verifying that the REJECT patch is really introducing the corruption). That was certain. The patch fixed the problem, confirmed with current git tree as well. Thanks for looking at it. Thanks. Dave, please apply this patch. [NETFILTER]: ipt_REJECT: fix memory corruption On devices with hard_header_len LL_MAX_HEADER ip_route_me_harder() reallocates the skb, leading to memory corruption when using the stale tcph pointer to update the checksum. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.c index ad0312d..264763a 100644 --- a/net/ipv4/netfilter/ipt_REJECT.c +++ b/net/ipv4/netfilter/ipt_REJECT.c @@ -114,6 +114,14 @@ static void send_reset(struct sk_buff *o tcph-window = 0; tcph-urg_ptr = 0; + /* Adjust TCP checksum */ + tcph-check = 0; + tcph-check = tcp_v4_check(tcph, sizeof(struct tcphdr), + nskb-nh.iph-saddr, + nskb-nh.iph-daddr, + csum_partial((char *)tcph, + sizeof(struct tcphdr), 0)); + /* Set DF, id = 0 */ nskb-nh.iph-frag_off = htons(IP_DF); nskb-nh.iph-id = 0; @@ -129,14 +137,8 @@ #endif if (ip_route_me_harder(nskb, addr_type)) goto free_nskb; - /* Adjust TCP checksum */ nskb-ip_summed = CHECKSUM_NONE; - tcph-check = 0; - tcph-check = tcp_v4_check(tcph, sizeof(struct tcphdr), - nskb-nh.iph-saddr, - nskb-nh.iph-daddr, - csum_partial((char *)tcph, - sizeof(struct tcphdr), 0)); + /* Adjust IP TTL */ nskb-nh.iph-ttl = dst_metric(nskb-dst, RTAX_HOPLIMIT);
Re: 2.6.19-rc6 : Spontaneous reboots, stack overflows - seems to implicate xfs, scsi, networking, SMP
On Thu, Nov 23, 2006 at 12:18:09PM +1100, David Chinner wrote: On Wed, Nov 22, 2006 at 01:58:11PM +0100, Jesper Juhl wrote: Attached are two files. The one named stack_overflows.txt.gz contains one instance of each unique stack overflow + trace that I've got. The other file named kernel_BUG.txt.gz contains a few BUG() messages that were also in the logs. I've just checked on a 2.6.17 build on i386 how much stack we are using (from checkstack.pl with min size reported set to 32 bytes) here in XFS: So, assuming the stacks less than 32 bytes are 32 bytes, we've got 1380 bytes in the XFS stack there, and very few functions where it can be reduced further. Still, 1380 bytes is way, way short of 4KB, so unless there is extra stack usage that checkstack doesn't tell us about I'm not sure why this amount of usage is causing repeated stack overflows with very little stack usage on either side of it. Can someone enlighten me as to where all the rest of the stack is being used up here? FYI. With some help from Keith Owens, we've determined that gcc 3.3.5 resulted in XFS stack usage of about 1.9KB through the writeback and allocation path with another ~800 bytes of stack usage in generic code in this path. The big difference between the numbers I was getting from checkstack and reality was CONFIG_CC_OPTIMISE_FOR_SIZE=y being set on the kernels I was stack checking. IOWs, CONFIG_CC_OPTIMISE_FOR_SIZE=y appears to reduce XFS stack usage by at least 20% and so probably should be used with XFS on 4k stacks. Keith also confirmed that gcc-4.1's aggressive inlining of static functions substantially increases stack usage (by ~15%) through this call chain. Given that many of the inlined static functions are not required by the critical path (i.e. they'd previously been factored out to reduce stack usage), gcc is effectively undoing past mods that had substantially reduced XFS's stack usage. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Broken commit: [NETFILTER]: ipt_REJECT: remove largely duplicate route_reverse function
From: Patrick McHardy [EMAIL PROTECTED] Date: Wed, 29 Nov 2006 03:28:25 +0100 [NETFILTER]: ipt_REJECT: fix memory corruption On devices with hard_header_len LL_MAX_HEADER ip_route_me_harder() reallocates the skb, leading to memory corruption when using the stale tcph pointer to update the checksum. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Applied, thanks Patrick. And based upon your discovery wrt. MAX_HEADER I'm also applying the following. commit 93e3a20d6c67a09b867431e7d5b3e7bc97154fab Author: David S. Miller [EMAIL PROTECTED] Date: Tue Nov 28 20:24:10 2006 -0800 [NET]: Fix MAX_HEADER setting. MAX_HEADER is either set to LL_MAX_HEADER or LL_MAX_HEADER + 48, and this is controlled by a set of CONFIG_* ifdef tests. It is trying to use LL_MAX_HEADER + 48 when any of the tunnels are enabled which set hard_header_len like this: dev-hard_header_len = LL_MAX_HEADER + sizeof(struct xxx); The correct set of tunnel drivers which do this are: ipip ip_gre ip6_tunnel sit so make the ifdef test match. Noticed by Patrick McHardy. Signed-off-by: David S. Miller [EMAIL PROTECTED] diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 9264139..95e86ac 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -94,7 +94,9 @@ #endif #endif #if !defined(CONFIG_NET_IPIP) \ -!defined(CONFIG_IPV6) !defined(CONFIG_IPV6_MODULE) +!defined(CONFIG_NET_IPGRE) \ +!defined(CONFIG_IPV6_SIT) \ +!defined(CONFIG_IPV6_TUNNEL) #define MAX_HEADER LL_MAX_HEADER #else #define MAX_HEADER (LL_MAX_HEADER + 48) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Broken commit: [NETFILTER]: ipt_REJECT: remove largely duplicate route_reverse function
David Miller [EMAIL PROTECTED] wrote:
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 9264139..95e86ac 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -94,7 +94,9 @@ #endif
#endif
#if !defined(CONFIG_NET_IPIP) \
-!defined(CONFIG_IPV6) !defined(CONFIG_IPV6_MODULE)
+!defined(CONFIG_NET_IPGRE) \
+!defined(CONFIG_IPV6_SIT) \
+!defined(CONFIG_IPV6_TUNNEL)
#define MAX_HEADER LL_MAX_HEADER
#else
#define MAX_HEADER (LL_MAX_HEADER + 48)
What if ipip/gre are modules?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Broken commit: [NETFILTER]: ipt_REJECT: remove largely duplicate route_reverse function
From: Herbert Xu [EMAIL PROTECTED] Date: Wed, 29 Nov 2006 15:38:29 +1100 David Miller [EMAIL PROTECTED] wrote: diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 9264139..95e86ac 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -94,7 +94,9 @@ #endif #endif #if !defined(CONFIG_NET_IPIP) \ -!defined(CONFIG_IPV6) !defined(CONFIG_IPV6_MODULE) +!defined(CONFIG_NET_IPGRE) \ +!defined(CONFIG_IPV6_SIT) \ +!defined(CONFIG_IPV6_TUNNEL) #define MAX_HEADER LL_MAX_HEADER #else #define MAX_HEADER (LL_MAX_HEADER + 48) What if ipip/gre are modules? Good catch, I'll fix that up by adding the missing CONFIG_*_MODULE cases. Longer term this is really messy, we should handle this some other way. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Broken commit: [NETFILTER]: ipt_REJECT: remove largely duplicate route_reverse function
David Miller [EMAIL PROTECTED] wrote:
Longer term this is really messy, we should handle this some
other way.
Definitely. I'm not sure whether 48 is enough even for recursive
tunnels. This should really just be a hint. It's OK to spend a
bit of time reallocating skb's if it's too small, but it's not OK
to die.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Broken commit: [NETFILTER]: ipt_REJECT: remove largely duplicate route_reverse function
From: Herbert Xu [EMAIL PROTECTED] Date: Wed, 29 Nov 2006 15:56:57 +1100 David Miller [EMAIL PROTECTED] wrote: Longer term this is really messy, we should handle this some other way. Definitely. I'm not sure whether 48 is enough even for recursive tunnels. This should really just be a hint. It's OK to spend a bit of time reallocating skb's if it's too small, but it's not OK to die. The recursive tunnel case is handled by the PMTU reductions in the route, isn't it? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Broken commit: [NETFILTER]: ipt_REJECT: remove largely duplicate route_reverse function
On Tue, Nov 28, 2006 at 09:04:16PM -0800, David Miller wrote:
Definitely. I'm not sure whether 48 is enough even for recursive
tunnels. This should really just be a hint. It's OK to spend a
bit of time reallocating skb's if it's too small, but it's not OK
to die.
The recursive tunnel case is handled by the PMTU reductions
in the route, isn't it?
Oh I wasn't suggesting that the current code is broken.
I'm just emphasising that LL_MAX_HEADER is by no means the *maximum*
header size in a Linux system. Anybody should be able to load a
new NIC module with a hard header size exceeding what LL_MAX_HEADER
is and the system should still function (albeit slower since every
packet sent down that device has to be reallocated).
In particular, nested tunnels is one such device which anybody can
construct without writing a kernel module.
As to getting rid of those ifdefs, here is one idea. We keep a
read-mostly global variable that represents the actual current
maximum LL header size. Everytime a new device appears (or if
its hard header size changes) we update this variable if needed.
Hmm, we don't actually update the hard header size should the
underlying device change for tunnels. Good thing the tunnels
only use that as a hint and reallocate if necessary :)
This is not optimal in that it never decreases, but it's certainly
better than a compile-time constant (e.g., people using distribution
kernels don't necessarily use tunnels).
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] genapic: default to physical mode on hotplug CPU kernels
* Siddha, Suresh B [EMAIL PROTECTED] wrote:
On Tue, Nov 28, 2006 at 09:23:22PM +0100, Ingo Molnar wrote:
* Siddha, Suresh B [EMAIL PROTECTED] wrote:
On Tue, Nov 28, 2006 at 07:33:46AM +0100, Ingo Molnar wrote:
- if (clusters = 1 max_cluster = 8 cluster_cnt[0] ==
max_cluster)
+ if (max_apic 8)
Patch mostly looks good. Instead of checking for max_apic, can we use
cpus_weight(cpu_possible_map) = 8
ok - but i think it's still possible the BIOS tells us APIC IDs that are
larger than 7, even if there are fewer CPUs. So i think the patch below
should cover it. Agreed?
I think it is ok to use flat mode even when APIC IDs are larger than
7, as we rely on LDR's which are programmed using smp_processor_id().
IMO, cpus_weight check should be fine.
hm - indeed. Then we can indeed do the patch below. Nice simplification!
Ingo
From: Ingo Molnar [EMAIL PROTECTED]
Subject: [patch] genapic: default to physical mode on hotplug CPU kernels
default to physical mode on hotplug CPU kernels. Furher simplify and
clean up the APIC initialization code.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
---
arch/x86_64/kernel/genapic.c | 20 +++-
arch/x86_64/kernel/mpparse.c |2 +-
include/asm-x86_64/apic.h|2 +-
3 files changed, 5 insertions(+), 19 deletions(-)
Index: linux/arch/x86_64/kernel/genapic.c
===
--- linux.orig/arch/x86_64/kernel/genapic.c
+++ linux/arch/x86_64/kernel/genapic.c
@@ -33,25 +33,11 @@ u8 x86_cpu_to_log_apicid[NR_CPUS] = { [0
struct genapic __read_mostly *genapic = apic_flat;
/*
- * Check the APIC IDs in bios_cpu_apicid and choose the APIC mode.
+ * Choose the APIC routing mode:
*/
-void __init clustered_apic_check(void)
+void __init setup_apic_routing(void)
{
- unsigned int i, max_apic = 0;
- u8 id;
-
- /*
-* Determine the maximum APIC ID in use:
-*/
- for (i = 0; i NR_CPUS; i++) {
- id = bios_cpu_apicid[i];
- if (id == BAD_APICID)
- continue;
- if (id max_apic)
- max_apic = id;
- }
-
- if (max_apic 8)
+ if (cpus_weight(cpu_possible_map) = 8)
genapic = apic_flat;
else
genapic = apic_physflat;
Index: linux/arch/x86_64/kernel/mpparse.c
===
--- linux.orig/arch/x86_64/kernel/mpparse.c
+++ linux/arch/x86_64/kernel/mpparse.c
@@ -302,7 +302,7 @@ static int __init smp_read_mpc(struct mp
}
}
}
- clustered_apic_check();
+ setup_apic_routing();
if (!num_processors)
printk(KERN_ERR MPTABLE: no processors registered!\n);
return num_processors;
Index: linux/include/asm-x86_64/apic.h
===
--- linux.orig/include/asm-x86_64/apic.h
+++ linux/include/asm-x86_64/apic.h
@@ -82,7 +82,7 @@ extern void setup_secondary_APIC_clock (
extern int APIC_init_uniprocessor (void);
extern void disable_APIC_timer(void);
extern void enable_APIC_timer(void);
-extern void clustered_apic_check(void);
+extern void setup_apic_routing(void);
static inline void lapic_timer_idle_broadcast(int broadcast) { }
extern void setup_APIC_extened_lvt(unsigned char lvt_off, unsigned char vector,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Broken commit: [NETFILTER]: ipt_REJECT: remove largely duplicate route_reverse function
On 29-11-2006 05:25, David Miller wrote: ... commit 93e3a20d6c67a09b867431e7d5b3e7bc97154fab Author: David S. Miller [EMAIL PROTECTED] Date: Tue Nov 28 20:24:10 2006 -0800 [NET]: Fix MAX_HEADER setting. MAX_HEADER is either set to LL_MAX_HEADER or LL_MAX_HEADER + 48, and this is controlled by a set of CONFIG_* ifdef tests. ... Noticed by Patrick McHardy. And if we talk about names: + Spotted by Krzysztof Halasa. probably wouldn't be too exaggerated... Signed-off-by: David S. Miller [EMAIL PROTECTED] Jarek P. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc6-mm1: drivers/net/chelsio/: unused code
On Mon, Nov 27, 2006 at 10:24:55AM -0800, Stephen Hemminger wrote: On Fri, 24 Nov 2006 01:17:31 +0100 Adrian Bunk [EMAIL PROTECTED] wrote: On Thu, Nov 23, 2006 at 02:17:03AM -0800, Andrew Morton wrote: ... Changes since 2.6.19-rc5-mm2: ... +chelsio-22-driver.patch ... netdev updates It is suspicious that the following newly added code is completely unused: drivers/net/chelsio/ixf1010.o t1_ixf1010_ops drivers/net/chelsio/mac.o t1_chelsio_mac_ops drivers/net/chelsio/vsc8244.o t1_vsc8244_ops cu Adrian All that is gone in later version. I reposted new patches after -mm2 was done. It seems these patches didn't make it into 2.6.19-rc6-mm2 ? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lockdep: fix sk-sk_callback_lock locking
Peter Zijlstra [EMAIL PROTECTED] wrote:
=
[ INFO: possible irq lock inversion dependency detected ]
2.6.19-rc6 #4
-
nc/1854 just changed the state of lock:
(af_callback_keys + sk-sk_family#2){-.-?}, at: [c0268a7f]
sock_def_error_report+0x1f/0x90
but this lock was taken by another, soft-irq-safe lock in the past:
(slock-AF_INET){-+..}
and interrupts could create inverse lock ordering between them.
I think this is bogus. The slock is not a standard lock. When we
hold it in process context we don't actually hold the spin lock part
of it. However, it does prevent the softirq path from running in
critical sections which also prevents any attempt to grab the
callback lock from softirq context.
If you still think there is a problem, please show an actual scenario
where it dead locks.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc6-mm1: drivers/net/chelsio/: unused code
On Wed, 29 Nov 2006 08:36:09 +0100 Adrian Bunk [EMAIL PROTECTED] wrote: On Mon, Nov 27, 2006 at 10:24:55AM -0800, Stephen Hemminger wrote: On Fri, 24 Nov 2006 01:17:31 +0100 Adrian Bunk [EMAIL PROTECTED] wrote: On Thu, Nov 23, 2006 at 02:17:03AM -0800, Andrew Morton wrote: ... Changes since 2.6.19-rc5-mm2: ... +chelsio-22-driver.patch ... netdev updates It is suspicious that the following newly added code is completely unused: drivers/net/chelsio/ixf1010.o t1_ixf1010_ops drivers/net/chelsio/mac.o t1_chelsio_mac_ops drivers/net/chelsio/vsc8244.o t1_vsc8244_ops cu Adrian All that is gone in later version. I reposted new patches after -mm2 was done. It seems these patches didn't make it into 2.6.19-rc6-mm2 ? I dropped that patch and picked up Francois's tree instead. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Help for kernel module programming
Hi: I am writing a kernel module for assging an ip address to an interface. I have included linux/igmp.h but still whenever i use the function declared in igmp.h file, it says unresolved symbol for that function. I am new to this programming. i use the following command to compile it: gcc -c -D__KERNEL__ -DMODULE -I/home/newkernelsource/linux-2.4.22/include hello.c -- - - Regards, Prajakta Choudhari, Project Engineer, Networking and Internet Software Group, CDAC,Pune Email:[EMAIL PROTECTED] Mobile:9890302701 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
