|
Hi,
In all honesty, I can hardly believe that you want to go through that
hassle of patching any vendor kernel with a vanilla-diffed feature
outside the tree.
I stand corrected; Joe see, it's dead easy to find guinea pigs these
days: People just do everything for ya, don't even need to pay them :).
Just patched SuSE 9.0 version (2.4.22.somthing) with one reject and
Whitebox Linux (Redhat Enterprise linux 3 based) with one reject.
Nice.
The rejects from the RHEL 3.x (kernel 2.4.21-15.ELsmp patched with GFS
support) patched with linux-2.4.20-ipvs-1.0.8-antefacto.patch gives just
the following rejects (see below). I'd say.. good work.
./kernel/ksyms.c.rej
***************
*** 127,132 ****
EXPORT_SYMBOL(kmap_prot);
EXPORT_SYMBOL(kmap_pte);
#endif
EXPORT_SYMBOL(buffermem_pages);
EXPORT_SYMBOL(nr_free_pages);
EXPORT_SYMBOL(page_cache_size);
--- 127,133 ----
EXPORT_SYMBOL(kmap_prot);
EXPORT_SYMBOL(kmap_pte);
#endif
+
EXPORT_SYMBOL(buffermem_pages);
EXPORT_SYMBOL(nr_free_pages);
EXPORT_SYMBOL(page_cache_size);
Ok, just make sure the last three symbols are exported through ksyms.c
./net/ipv4/netfilter/ip_conntrack_core.c.rej
***************
*** 692,697 ****
/* Mark clearly that it's not in the hash table. */
conntrack->tuplehash[IP_CT_DIR_ORIGINAL].list.next = NULL;
WRITE_LOCK(&ip_conntrack_lock);
/* Need finding and deleting of expected ONLY if we win race */
--- 692,698 ----
/* Mark clearly that it's not in the hash table. */
conntrack->tuplehash[IP_CT_DIR_ORIGINAL].list.next = NULL;
+ conntrack->tuplehash[IP_CT_DIR_REPLY].list.next = NULL;
You might need it or the kernel will crash upon the first packet
entering the connection tracking table.
Cheers,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
