* Re: ip_conntrack: Make "hashsize" conntrack parameter writable
From: Jesper Dangaard Brouer @ 2005-11-23 14:08 UTC (permalink / raw)
To: Rusty Russell
Cc: Harald Welte, netdev, netfilter-devel, Jesper Dangaard Brouer
In-Reply-To: <1132707085.7720.2.camel@localhost.localdomain>
On Wed, 23 Nov 2005, Rusty Russell wrote:
> On Tue, 2005-11-22 at 15:49 +0100, Jesper Dangaard Brouer wrote:
>> Hi Rusty (and Harald)
>>
>> We met at the Netfilter Workshop 2005, where I complained that the
>> conntrack hashsize were statically set at module load time.
>>
>> Thank you making a kernel patch, which changes this...
>> BUT I cannot make it work! :-(
>>
>> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=eed75f191d8318a2b144da8aae9774e1cfcae492
>>
>> Am I missing some part of the patch?
>>
>> I cannot find the link to the /proc file system. Should there not be
>> any changes to ip_conntrack_standalone.c ??
>
> /sys/module/ip_conntrack/parameters/hashsize
>
> Cheers!
> Rusty.
Aha I see, the sysfs filesystem.
I was confused, because the hashsize is already exported as
/proc/sys/net/ipv4/netfilter/ip_conntrack_buckets.
It is a bit confusing, that the Netfilter team are changing away from the
/proc filesystem, but I don't care, it seems that the sysfs filesystem is
a more powerful choice.
The permissions on "/sys/module/ip_conntrack/parameters/hashsize" is set
to 600, where the /proc/../ip_conntrack_buckets is readable to all (444).
I think we should change the /sys/../hashsize parameter to 644, as it does
not make sense as it is readable through /proc.
Hilsen
Jesper Dangaard Brouer
ps. Cc'ing -> lets keep google updated ;-)
--
-------------------------------------------------------------------
Cand. scient datalog
Dept. of Computer Science, University of Copenhagen
-------------------------------------------------------------------
^ permalink raw reply
* Abolish everything you are indebted for not even paying an other cent
From: gillian wheeler @ 2005-11-23 13:10 UTC (permalink / raw)
To: Victor Hunt
Do away with all you owe not even sending another dollar.
Eliminate the embarrassing collection contacts. Bring to an end to the
sending of payments! Wild as it may seem the majority lending establishments
not following the banking laws here in the US. Incredible but right! Visit
us for thorough fine points on the subject our approach at 0.00 payment or
responsibility. You have not anything to loose and loads to secure.
http://mx.geocities.com/kevinn_diggorysio/?a=XC.Get rid of all that you are
indebted for not even mailing an other dollar
Exhaustive knowledge or to bring to a hault obtaining or to get postal
Multiply leads and business presence quickly through experienced and high
volume electronic mail advertising
Use the the largest and finest markettgroup@emailacc.com
When he found himself outside the village he made for the high plateau in
the center of the island, where he could be safe from the cannibals while he
collected his thoughts. But when he reached the place he found the sides so
steep he could not climb them, so he adjusted the indicator to the word up
and found it had still had enough power to support his body while he
clambered up the rocks to the level, grass-covered space at the top
Then, reclining upon his back, he gave himself up to thoughts of how he
might escape from his unpleasant predicament
^ permalink raw reply
* RE: [2.6 patch] net/sunrpc/xdr.c: remove xdr_decode_string()
From: Lever, Charles @ 2005-11-23 12:31 UTC (permalink / raw)
To: Adrian Bunk
Cc: David Miller, neilb, trond.myklebust, linux-kernel, nfs, netdev
> On Thu, Oct 06, 2005 at 07:13:14AM -0700, Lever, Charles wrote:
>
> > actually, can we hold off on this change? the RPC
> transport switch will
> > eventually need most of those EXPORT_SYMBOLs.
>
> Am I right to assume this will happen in the foreseeable future?
the first portion of the transport switch is in 2.6.15-rcX. at this
point i'm expecting the EXPORT_SYMBOL changes to go in 2.6.17 or later.
so i don't remember why you are removing xdr_decode_string. are we sure
that no-one will need this functionality in the future? it is harmless
to remove today, but i wonder if someone is just going to add it back
sometime.
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_idv28&alloc_id\x16845&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [PATCH 06/13]: [IPV4/6]: Netfilter IPsec input hooks
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-11-23 10:38 UTC (permalink / raw)
To: kaber; +Cc: netdev, netfilter-devel, davem, kozakai, kazunori
In-Reply-To: <438270F2.3000603@trash.net>
Hello.
In article <438270F2.3000603@trash.net> (at Tue, 22 Nov 2005 02:14:26 +0100), Patrick McHardy <kaber@trash.net> says:
> The easiest way would be to store nhoff somewhere in the skb and
> use it to continue at the next header. But I still hope there is
> a way without keeping data in the skb.
We've coded up this.
Though we have still another issue (call chain issue) to resolve,
we're getting closer to the goal.
i.e. we should continue the loop for common case.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Yasuyuki Kozawai <yasuyuki.kozakai@toshiba.co.jp>
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 8c5d600..1101851 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -272,6 +272,9 @@ struct sk_buff {
void (*destructor)(struct sk_buff *skb);
#ifdef CONFIG_NETFILTER
__u32 nfmark;
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+ unsigned int nf_nhoff;
+#endif
struct nf_conntrack *nfct;
#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
struct sk_buff *nfct_reasm;
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 44b979a..0531d0a 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -463,6 +463,8 @@ extern int ip6_dst_lookup(struct sock
extern int ip6_output(struct sk_buff *skb);
extern int ip6_forward(struct sk_buff *skb);
extern int ip6_input(struct sk_buff *skb);
+extern int ip6_input_finish2(struct sk_buff *skb,
+ unsigned int nhoff);
extern int ip6_mc_input(struct sk_buff *skb);
/*
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index e84b3cd..cd0606a 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -134,31 +134,13 @@ out:
* Deliver the packet to the host
*/
-
-static inline int ip6_input_finish(struct sk_buff *skb)
+int ip6_input_finish2(struct sk_buff *skb, unsigned int nhoff)
{
struct inet6_protocol *ipprot;
struct sock *raw_sk;
- unsigned int nhoff;
- int nexthdr;
+ unsigned int nexthdr;
u8 hash;
- skb->h.raw = skb->nh.raw + sizeof(struct ipv6hdr);
-
- /*
- * Parse extension headers
- */
-
- nexthdr = skb->nh.ipv6h->nexthdr;
- nhoff = offsetof(struct ipv6hdr, nexthdr);
-
- /* Skip hop-by-hop options, they are already parsed. */
- if (nexthdr == NEXTHDR_HOP) {
- nhoff = sizeof(struct ipv6hdr);
- nexthdr = skb->h.raw[0];
- skb->h.raw += (skb->h.raw[1]+1)<<3;
- }
-
rcu_read_lock();
resubmit:
if (!pskb_pull(skb, skb->h.raw - skb->data))
@@ -221,6 +203,26 @@ discard:
return 0;
}
+static inline int ip6_input_finish(struct sk_buff *skb)
+{
+ unsigned int nhoff;
+
+ skb->h.raw = skb->nh.raw + sizeof(struct ipv6hdr);
+
+ /*
+ * Parse extension headers
+ */
+
+ nhoff = offsetof(struct ipv6hdr, nexthdr);
+
+ /* Skip hop-by-hop options, they are already parsed. */
+ if (skb->nh.ipv6h->nexthdr == NEXTHDR_HOP) {
+ nhoff = sizeof(struct ipv6hdr);
+ skb->h.raw += (skb->h.raw[1]+1)<<3;
+ }
+
+ return ip6_input_finish2(skb, nhoff);
+}
int ip6_input(struct sk_buff *skb)
{
diff --git a/net/ipv6/ipv6_syms.c b/net/ipv6/ipv6_syms.c
index 1648278..6051783 100644
--- a/net/ipv6/ipv6_syms.c
+++ b/net/ipv6/ipv6_syms.c
@@ -15,6 +15,7 @@ EXPORT_SYMBOL(ndisc_mc_map);
EXPORT_SYMBOL(register_inet6addr_notifier);
EXPORT_SYMBOL(unregister_inet6addr_notifier);
EXPORT_SYMBOL(ip6_route_output);
+EXPORT_SYMBOL(ip6_input_finish2);
EXPORT_SYMBOL(addrconf_lock);
EXPORT_SYMBOL(ipv6_setsockopt);
EXPORT_SYMBOL(ipv6_getsockopt);
diff --git a/net/ipv6/xfrm6_input.c b/net/ipv6/xfrm6_input.c
index 9987416..2e3b28d 100644
--- a/net/ipv6/xfrm6_input.c
+++ b/net/ipv6/xfrm6_input.c
@@ -9,6 +9,7 @@
* IPv6 support
*/
+#include <linux/config.h>
#include <linux/module.h>
#include <linux/string.h>
#include <linux/netfilter.h>
@@ -17,6 +18,7 @@
#include <net/inet_ecn.h>
#include <net/ip.h>
#include <net/ipv6.h>
+#include <net/ip6_route.h>
#include <net/xfrm.h>
static inline void ipip6_ecn_decapsulate(struct sk_buff *skb)
@@ -28,6 +30,25 @@ static inline void ipip6_ecn_decapsulate
IP6_ECN_set_ce(inner_iph);
}
+#ifdef CONFIG_NETFILTER
+static inline int xfrm6_rcv_spi_finish2(struct sk_buff *skb)
+{
+ __skb_pull(skb, skb->h.raw - skb->nh.raw);
+ return ip6_input_finish2(skb, skb->nf_nhoff);
+}
+
+static inline int xfrm6_rcv_spi_finish(struct sk_buff *skb)
+{
+ if (skb->dst == NULL) {
+ ip6_route_input(skb);
+ return dst_input(skb);
+ }
+
+ return NF_HOOK(PF_INET6, NF_IP6_LOCAL_IN, skb, skb->dev, NULL,
+ xfrm6_rcv_spi_finish2);
+}
+#endif
+
int xfrm6_rcv_spi(struct sk_buff **pskb, unsigned int *nhoffp, u32 spi)
{
struct sk_buff *skb = *pskb;
@@ -136,9 +157,10 @@ int xfrm6_rcv_spi(struct sk_buff **pskb,
#ifdef CONFIG_NETFILTER
skb->nh.ipv6h->payload_len = htons(skb->len);
__skb_push(skb, skb->data - skb->nh.raw);
+ skb->nf_nhoff = nhoff;
NF_HOOK(PF_INET6, NF_IP6_PRE_ROUTING, skb, skb->dev, NULL,
- ip6_rcv_finish);
+ xfrm6_rcv_spi_finish);
return -1;
#else
return 1;
--
YOSHIFUJI Hideaki @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply related
* Re: [2.6 patch] do not select NET_CLS
From: Thomas Graf @ 2005-11-23 10:27 UTC (permalink / raw)
To: David S. Miller; +Cc: kaber, bunk, evil, linux-kernel, netdev, zippel
In-Reply-To: <20051122.143713.101129339.davem@davemloft.net>
* David S. Miller <davem@davemloft.net> 2005-11-22 14:37
> From: Patrick McHardy <kaber@trash.net>
> Date: Mon, 21 Nov 2005 17:16:18 +0100
>
> > Adrian Bunk wrote:
> > > This patch therefore changes NET_CLS back to the 2.6.14 status quo of
> > > being an user-visible option.
> >
> > I disagree with this patch. NET_CLS enables the infrastructure support
> > for classifiers. Users generally don't care about infrastructure but
> > directly usable things, so I'd prefer to have it automatically selected.
> > And there are lots of other cases where enabling a module causes changes
> > in the kernel image. Some examples include some of the netfilter stuff,
> > the IPsec transforms, NET_CLS_ROUTE4, the ieee80211 stuff, and a lot
> > more.
>
> I agree with Patrick.
In fact Patrick's explanation was exactly the motivation for me to
change it in the first place a few weeks back.
I thought about making cls_api aware to be built as module but then
the same would apply for ematches and the generic scheduling code
and it gets real complicated. It is possible with some heavy code
shuffling but not worth it I think.
^ permalink raw reply
* Re: Netlink send from the interrupt context
From: Yu Zhiguo @ 2005-11-23 9:04 UTC (permalink / raw)
To: Robert Iakobashvili; +Cc: netdev, netfilter-devel
In-Reply-To: <7e63f56c0511230033w68e60863wb8a026df3eea3077@mail.gmail.com>
yes, it use spinlocks rather than semaphore, and it can use GFP_ATOMIC to clone the message,
so I think it will not go sleep.
regards,
----- Original Message -----
> On 11/23/05, Robert Iakobashvili <coroberti@gmail.com> wrote:
>> On 11/23/05, Yu Zhiguo <yuzg@nanjing-fnst.com> wrote:
>> > Please refer to the function netlink_broadcast(),
>> > int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, u32 pid, u32 group, int allocation)
>> > I think if allocation=GFP_ATOMIC, it can be used in interrupt context.
>> > What's your opinion?
>
> Allocation is OK and it uses only spinlocks in all functions called,
> no semaphores.
>
> My concern actually rises from here:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0407.3/0455.html
>
> Sincerely,
> ----------------------------------------------------------------
> Robert Iakobashvili - NAVIGARE NECESSE EST
> coroberti at gmail dot com
> ---------------------------------------------------------------
^ permalink raw reply
* Re: Netlink send from the interrupt context
From: Robert Iakobashvili @ 2005-11-23 8:33 UTC (permalink / raw)
To: Yu Zhiguo; +Cc: netdev, netfilter-devel
In-Reply-To: <7e63f56c0511230032x5097569dr3ddac4b05bb6019c@mail.gmail.com>
On 11/23/05, Robert Iakobashvili <coroberti@gmail.com> wrote:
> On 11/23/05, Yu Zhiguo <yuzg@nanjing-fnst.com> wrote:
> > Please refer to the function netlink_broadcast(),
> > int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, u32 pid, u32 group, int allocation)
> > I think if allocation=GFP_ATOMIC, it can be used in interrupt context.
> > What's your opinion?
Allocation is OK and it uses only spinlocks in all functions called,
no semaphores.
My concern actually rises from here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0407.3/0455.html
Sincerely,
----------------------------------------------------------------
Robert Iakobashvili - NAVIGARE NECESSE EST
coroberti at gmail dot com
---------------------------------------------------------------
^ permalink raw reply
* Re: [NETLINK]: Use tgid instead of pid for nlmsg_pid
From: David S. Miller @ 2005-11-23 6:18 UTC (permalink / raw)
To: herbert; +Cc: kuznet, cfriesen, netdev, linux-kernel
In-Reply-To: <20051123000337.GA17249@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 23 Nov 2005 11:03:37 +1100
> On Tue, Nov 22, 2005 at 02:43:34PM -0800, David S. Miller wrote:
> > It is possible we accidently reintroduced current->pid when
> > we redid all of the netlink hashing. :-)
>
> I just checked using git-whatchanged and that line goes back to
> 2002 :)
Ho hum, I guess we just missed it on the current->pid
scan then :-)
^ permalink raw reply
* Re: [2.6 patch] do not select NET_CLS
From: Sam Ravnborg @ 2005-11-23 5:57 UTC (permalink / raw)
To: David S. Miller; +Cc: kaber, bunk, evil, linux-kernel, netdev, zippel
In-Reply-To: <20051122.150041.90521592.davem@davemloft.net>
On Tue, Nov 22, 2005 at 03:00:41PM -0800, David S. Miller wrote:
> From: Sam Ravnborg <sam@ravnborg.org>
> Date: Tue, 22 Nov 2005 23:49:14 +0100
>
> > On Tue, Nov 22, 2005 at 02:37:13PM -0800, David S. Miller wrote:
> > >
> > > One thing we can do to prevent human
> > > mistakes, is to make the "make modules" pass do a quick "is vmlinux
> > > uptodate?" check, and if not print out an error message explaining the
> > > situation and aborting the "make modules" attempt.
> >
> > I do not quite follow you here.
>
> If the user tries to do a "make modules" without first rebuilding
> their kernel image, then the make will fail if the dependencies
> are not satisfied for the main kernel image and it is thus not
> up to date.
OK - so a simple 'make -q vmlinux' check, except that the way we utilise
make will let it fail at first build command.
That will obscufate things even more in kbuild - but I will give it a
try sometime. It will be easy to cover 95% but to reach 100%
predictability will be though.
- file dependencies is easy
- command line changes is relatively easy
- but the various scripts and user commands will be tricky..
Not on the top of the TODO list though.
Sam
^ permalink raw reply
* Re: [PATCH 00/13]: Netfilter IPsec support
From: Yasuyuki KOZAKAI @ 2005-11-23 4:52 UTC (permalink / raw)
To: davem; +Cc: netdev, netfilter-devel, herbert, kaber
In-Reply-To: <20051122.193631.76306901.davem@davemloft.net>
From: "David S. Miller" <davem@davemloft.net>
Date: Tue, 22 Nov 2005 19:36:31 -0800 (PST)
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Wed, 23 Nov 2005 12:35:53 +1100
>
> > How about merging the patches that everybody has agreed on first?
> >
> > So far, I haven't see any objections to patches 1 and 2 so they
> > can go in straight away. They don't even touch IPv6.
> >
> > Patches 3-6 could become redundant if you go with my suggestion.
> >
> > The rest of them I haven't read yet so can't comment :)
>
> View the net-2.6.16 GIT tree as a sort of playpen, much like
> -mm, until we get close to the real 2.6.16 upstream development
> openning up.
>
> I rebase all the time, and I can pluck out and change patches
> at will.
Then I agree. It can increase the number of tester, I think.
-- Yasuyuki Kozakai
^ permalink raw reply
* Re: [PATCH 00/13]: Netfilter IPsec support
From: Herbert Xu @ 2005-11-23 4:47 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, netfilter-devel, kaber
In-Reply-To: <20051122.193631.76306901.davem@davemloft.net>
On Tue, Nov 22, 2005 at 07:36:31PM -0800, David S. Miller wrote:
>
> View the net-2.6.16 GIT tree as a sort of playpen, much like
> -mm, until we get close to the real 2.6.16 upstream development
> openning up.
>
> I rebase all the time, and I can pluck out and change patches
> at will.
Sure, I have no objections against merging the patch now and then add
clean-ups later.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 00/13]: Netfilter IPsec support
From: David S. Miller @ 2005-11-23 3:36 UTC (permalink / raw)
To: herbert; +Cc: netdev, netfilter-devel, kaber
In-Reply-To: <E1EejY9-0004fW-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 23 Nov 2005 12:35:53 +1100
> How about merging the patches that everybody has agreed on first?
>
> So far, I haven't see any objections to patches 1 and 2 so they
> can go in straight away. They don't even touch IPv6.
>
> Patches 3-6 could become redundant if you go with my suggestion.
>
> The rest of them I haven't read yet so can't comment :)
View the net-2.6.16 GIT tree as a sort of playpen, much like
-mm, until we get close to the real 2.6.16 upstream development
openning up.
I rebase all the time, and I can pluck out and change patches
at will.
^ permalink raw reply
* Re: [PATCH 00/13]: Netfilter IPsec support
From: David S. Miller @ 2005-11-23 3:35 UTC (permalink / raw)
To: kaber; +Cc: netdev, netfilter-devel
In-Reply-To: <4383C31A.40101@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Wed, 23 Nov 2005 02:17:14 +0100
> I would appreciate that, but I want to have a look closer look
> at Herbert's patches first. Unfortunately its late and I have
> to get up early, so its going to take me a day.
Take your time :)
^ permalink raw reply
* Re: [PATCH 00/13]: Netfilter IPsec support
From: Herbert Xu @ 2005-11-23 1:35 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <4383C31A.40101@trash.net>
Patrick McHardy <kaber@trash.net> wrote:
>
> I would appreciate that, but I want to have a look closer look
> at Herbert's patches first. Unfortunately its late and I have
> to get up early, so its going to take me a day.
How about merging the patches that everybody has agreed on first?
So far, I haven't see any objections to patches 1 and 2 so they
can go in straight away. They don't even touch IPv6.
Patches 3-6 could become redundant if you go with my suggestion.
The rest of them I haven't read yet so can't comment :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [2.6 patch] net/sunrpc/xdr.c: remove xdr_decode_string()
From: Adrian Bunk @ 2005-11-23 1:24 UTC (permalink / raw)
To: Lever, Charles
Cc: David Miller, neilb, trond.myklebust, linux-kernel, nfs, netdev
In-Reply-To: <044B81DE141D7443BCE91E8F44B3C1E288E4FC@exsvl02.hq.netapp.com>
On Thu, Oct 06, 2005 at 07:13:14AM -0700, Lever, Charles wrote:
> actually, can we hold off on this change? the RPC transport switch will
> eventually need most of those EXPORT_SYMBOLs.
Am I right to assume this will happen in the foreseeable future?
> the only harmless change i see below is removing xdr_decode_string().
Patch below.
cu
Adrian
<-- snip -->
This patch removes ths unused function xdr_decode_string().
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
include/linux/sunrpc/xdr.h | 1 -
net/sunrpc/sunrpc_syms.c | 1 -
net/sunrpc/xdr.c | 21 ---------------------
3 files changed, 23 deletions(-)
--- linux-2.6.15-rc1-mm2-full/include/linux/sunrpc/xdr.h.old 2005-11-23 02:03:01.000000000 +0100
+++ linux-2.6.15-rc1-mm2-full/include/linux/sunrpc/xdr.h 2005-11-23 02:03:08.000000000 +0100
@@ -91,7 +91,6 @@
u32 * xdr_encode_opaque_fixed(u32 *p, const void *ptr, unsigned int len);
u32 * xdr_encode_opaque(u32 *p, const void *ptr, unsigned int len);
u32 * xdr_encode_string(u32 *p, const char *s);
-u32 * xdr_decode_string(u32 *p, char **sp, int *lenp, int maxlen);
u32 * xdr_decode_string_inplace(u32 *p, char **sp, int *lenp, int maxlen);
u32 * xdr_encode_netobj(u32 *p, const struct xdr_netobj *);
u32 * xdr_decode_netobj(u32 *p, struct xdr_netobj *);
--- linux-2.6.15-rc1-mm2-full/net/sunrpc/xdr.c.old 2005-11-23 02:03:17.000000000 +0100
+++ linux-2.6.15-rc1-mm2-full/net/sunrpc/xdr.c 2005-11-23 02:03:27.000000000 +0100
@@ -93,27 +93,6 @@
}
u32 *
-xdr_decode_string(u32 *p, char **sp, int *lenp, int maxlen)
-{
- unsigned int len;
- char *string;
-
- if ((len = ntohl(*p++)) > maxlen)
- return NULL;
- if (lenp)
- *lenp = len;
- if ((len % 4) != 0) {
- string = (char *) p;
- } else {
- string = (char *) (p - 1);
- memmove(string, p, len);
- }
- string[len] = '\0';
- *sp = string;
- return p + XDR_QUADLEN(len);
-}
-
-u32 *
xdr_decode_string_inplace(u32 *p, char **sp, int *lenp, int maxlen)
{
unsigned int len;
--- linux-2.6.15-rc1-mm2-full/net/sunrpc/sunrpc_syms.c.old 2005-11-23 02:03:35.000000000 +0100
+++ linux-2.6.15-rc1-mm2-full/net/sunrpc/sunrpc_syms.c 2005-11-23 02:03:38.000000000 +0100
@@ -120,7 +120,6 @@
/* Generic XDR */
EXPORT_SYMBOL(xdr_encode_string);
-EXPORT_SYMBOL(xdr_decode_string);
EXPORT_SYMBOL(xdr_decode_string_inplace);
EXPORT_SYMBOL(xdr_decode_netobj);
EXPORT_SYMBOL(xdr_encode_netobj);
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* [2.6 patch] net/ipv6/: make two functions static
From: Adrian Bunk @ 2005-11-23 1:23 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
net/ipv6/ip6_output.c | 3 ++-
net/ipv6/ipv6_sockglue.c | 4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
--- linux-2.6.15-rc1-mm2-full/net/ipv6/ip6_output.c.old 2005-11-23 02:10:08.000000000 +0100
+++ linux-2.6.15-rc1-mm2-full/net/ipv6/ip6_output.c 2005-11-23 02:10:25.000000000 +0100
@@ -774,7 +774,8 @@
*dst = NULL;
return err;
}
-inline int ip6_ufo_append_data(struct sock *sk,
+
+static inline int ip6_ufo_append_data(struct sock *sk,
int getfrag(void *from, char *to, int offset, int len,
int odd, struct sk_buff *skb),
void *from, int length, int hh_len, int fragheaderlen,
--- linux-2.6.15-rc1-mm2-full/net/ipv6/ipv6_sockglue.c.old 2005-11-23 02:10:43.000000000 +0100
+++ linux-2.6.15-rc1-mm2-full/net/ipv6/ipv6_sockglue.c 2005-11-23 02:11:02.000000000 +0100
@@ -628,8 +628,8 @@
return -EINVAL;
}
-int ipv6_getsockopt_sticky(struct sock *sk, struct ipv6_opt_hdr *hdr,
- char __user *optval, int len)
+static int ipv6_getsockopt_sticky(struct sock *sk, struct ipv6_opt_hdr *hdr,
+ char __user *optval, int len)
{
if (!hdr)
return 0;
^ permalink raw reply
* Re: [PATCH 00/13]: Netfilter IPsec support
From: Patrick McHardy @ 2005-11-23 1:20 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev, netfilter-devel, davem, kaber
In-Reply-To: <20051123.073825.106706639.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki / ^[$B5HF#1QL@^[ wrote:
> I believe he can manage these patches in his tree,
> but anyway...
It is kind of annoying redoing 13 patches for every small change.
> Well, it is very important to fix the packet processing
> path issues (including the extension header issue)
> before we merge it to the mainline. Definitely.
> What I want to ensure is that they will not reach the mainline
> tree without resolving those issues.
How about we put the IPv4 patches in now and I continue working
on the IPv6 side? The main approach is not going to change,
and I think users would appreciate having them available in
2.6.15.
^ permalink raw reply
* Re: [PATCH 00/13]: Netfilter IPsec support
From: Patrick McHardy @ 2005-11-23 1:17 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, netfilter-devel
In-Reply-To: <20051122.143438.84749134.davem@davemloft.net>
David S. Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Sun, 20 Nov 2005 17:31:28 +0100
>
>
>>This is the latest netfilter/IPsec patchset. Its purpose is to make
>>IPsec look as much as a normal tunnel device to netfilter as possible
>>and to enable NAT support.
>
>
> I think there are some of these patches that we can merge in
> right now into net-2.6.16...
>
> I want to do this so that Patrick doesn't have to repost
> 13 or so patches every time one of the parts still under
> discussion gets changed.
>
> Actually, it seems the only part under discussion is how to
> avoid extension header reparsing and routing re-lookups on
> the ipv6 side. That could be fixed by a follow-on patch and
> is not %100 necessary for initial integration in my opinion.
>
> Can I get agreement on that? Patrick sends me a dump of the
> current state of his patch set right now, we put that into
> net-2.6.16, and fix problems with followon patches.
>
> Ok?
I would appreciate that, but I want to have a look closer look
at Herbert's patches first. Unfortunately its late and I have
to get up early, so its going to take me a day.
^ permalink raw reply
* [2.6 patch] net/ipv4/netfilter/: small cleanups
From: Adrian Bunk @ 2005-11-23 0:41 UTC (permalink / raw)
To: coreteam; +Cc: netfilter-devel, netdev, linux-kernel
This patch contains the following cleanups:
- make needlessly global code static
- ip_conntrack_core.c: ip_conntrack_flush() -> ip_conntrack_flush(void)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
net/ipv4/netfilter/ip_conntrack_core.c | 4 ++--
net/ipv4/netfilter/ip_nat_core.c | 2 +-
net/ipv4/netfilter/ipt_LOG.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
--- linux-2.6.15-rc1-mm2-full/net/ipv4/netfilter/ip_conntrack_core.c.old 2005-11-22 22:52:16.000000000 +0100
+++ linux-2.6.15-rc1-mm2-full/net/ipv4/netfilter/ip_conntrack_core.c 2005-11-22 23:00:36.000000000 +0100
@@ -1354,7 +1354,7 @@
get_order(sizeof(struct list_head) * size));
}
-void ip_conntrack_flush()
+void ip_conntrack_flush(void)
{
/* This makes sure all current packets have passed through
netfilter framework. Roll on, two-stage module
@@ -1408,7 +1408,7 @@
return hash;
}
-int set_hashsize(const char *val, struct kernel_param *kp)
+static int set_hashsize(const char *val, struct kernel_param *kp)
{
int i, bucket, hashsize, vmalloced;
int old_vmalloced, old_size;
--- linux-2.6.15-rc1-mm2-full/net/ipv4/netfilter/ipt_LOG.c.old 2005-11-22 22:57:59.000000000 +0100
+++ linux-2.6.15-rc1-mm2-full/net/ipv4/netfilter/ipt_LOG.c 2005-11-22 22:58:08.000000000 +0100
@@ -351,7 +351,7 @@
/* maxlen = 230+ 91 + 230 + 252 = 803 */
}
-struct nf_loginfo default_loginfo = {
+static struct nf_loginfo default_loginfo = {
.type = NF_LOG_TYPE_LOG,
.u = {
.log = {
--- linux-2.6.15-rc1-mm2-full/net/ipv4/netfilter/ip_nat_core.c.old 2005-11-22 22:58:31.000000000 +0100
+++ linux-2.6.15-rc1-mm2-full/net/ipv4/netfilter/ip_nat_core.c 2005-11-22 22:58:39.000000000 +0100
@@ -49,7 +49,7 @@
static struct list_head *bysource;
#define MAX_IP_NAT_PROTO 256
-struct ip_nat_protocol *ip_nat_protos[MAX_IP_NAT_PROTO];
+static struct ip_nat_protocol *ip_nat_protos[MAX_IP_NAT_PROTO];
static inline struct ip_nat_protocol *
__ip_nat_proto_find(u_int8_t protonum)
^ permalink raw reply
* [2.6 patch] net/ipv4/: make two functions static
From: Adrian Bunk @ 2005-11-23 0:38 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
net/ipv4/ip_gre.c | 2 +-
net/ipv4/ip_output.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.15-rc1-mm2-full/net/ipv4/ip_output.c.old 2005-11-22 22:51:16.000000000 +0100
+++ linux-2.6.15-rc1-mm2-full/net/ipv4/ip_output.c 2005-11-22 22:51:29.000000000 +0100
@@ -690,7 +690,7 @@
return csum;
}
-inline int ip_ufo_append_data(struct sock *sk,
+static inline int ip_ufo_append_data(struct sock *sk,
int getfrag(void *from, char *to, int offset, int len,
int odd, struct sk_buff *skb),
void *from, int length, int hh_len, int fragheaderlen,
--- linux-2.6.15-rc1-mm2-full/net/ipv4/ip_gre.c.old 2005-11-22 22:59:32.000000000 +0100
+++ linux-2.6.15-rc1-mm2-full/net/ipv4/ip_gre.c 2005-11-22 22:59:45.000000000 +0100
@@ -1217,7 +1217,7 @@
return 0;
}
-int __init ipgre_fb_tunnel_init(struct net_device *dev)
+static int __init ipgre_fb_tunnel_init(struct net_device *dev)
{
struct ip_tunnel *tunnel = (struct ip_tunnel*)dev->priv;
struct iphdr *iph = &tunnel->parms.iph;
^ permalink raw reply
* Re: [NETLINK]: Use tgid instead of pid for nlmsg_pid
From: Herbert Xu @ 2005-11-23 0:03 UTC (permalink / raw)
To: David S. Miller; +Cc: kuznet, cfriesen, netdev, linux-kernel
In-Reply-To: <20051122.144334.23915283.davem@davemloft.net>
On Tue, Nov 22, 2005 at 02:43:34PM -0800, David S. Miller wrote:
>
> Applied, of course.
Thanks Dave.
> It is possible we accidently reintroduced current->pid when
> we redid all of the netlink hashing. :-)
I just checked using git-whatchanged and that line goes back to
2002 :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: e1000 82571 Packet Splitting
From: Jesse Brandeburg @ 2005-11-22 23:46 UTC (permalink / raw)
To: Jeff V. Merkey; +Cc: linux-kernel, Kernel Netdev Mailing List
In-Reply-To: <43838614.9080807@soleranetworks.com>
this should be on netdev.
On 11/22/05, Jeff V. Merkey <jmerkey@soleranetworks.com> wrote:
>
> I have noted that the e1000 driver is now supporting DMA splitting of
> the packet header and payload into separate pages. I also noticed
> that none of the config options enable it. Is anyone using this feature
> at present and has it even been tested on Linux?
The 6.2.15 driver off http://prdownloads.sf.net/e1000 will enable it
by default. We've gone through our release approval, which includes
quite a bit of testing.
If the patches posted recently don't include that support, I missed
something :-)
This is only on the 82571 and greater hardware that packet split is
supported, BTW.
^ permalink raw reply
* Re: [2.6 patch] do not select NET_CLS
From: Adrian Bunk @ 2005-11-22 23:12 UTC (permalink / raw)
To: David S. Miller; +Cc: kaber, evil, linux-kernel, netdev, zippel
In-Reply-To: <20051122.143713.101129339.davem@davemloft.net>
On Tue, Nov 22, 2005 at 02:37:13PM -0800, David S. Miller wrote:
>...
> Changing config options of any kind can result in the main kernel
> image needing to be rebuilt. One thing we can do to prevent human
> mistakes, is to make the "make modules" pass do a quick "is vmlinux
> uptodate?" check, and if not print out an error message explaining the
> situation and aborting the "make modules" attempt.
This won't work with CONFIG_IKCONFIG=y.
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
^ permalink raw reply
* Re: [2.6 patch] do not select NET_CLS
From: David S. Miller @ 2005-11-22 23:00 UTC (permalink / raw)
To: sam; +Cc: kaber, bunk, evil, linux-kernel, netdev, zippel
In-Reply-To: <20051122224914.GA17575@mars.ravnborg.org>
From: Sam Ravnborg <sam@ravnborg.org>
Date: Tue, 22 Nov 2005 23:49:14 +0100
> On Tue, Nov 22, 2005 at 02:37:13PM -0800, David S. Miller wrote:
> >
> > One thing we can do to prevent human
> > mistakes, is to make the "make modules" pass do a quick "is vmlinux
> > uptodate?" check, and if not print out an error message explaining the
> > situation and aborting the "make modules" attempt.
>
> I do not quite follow you here.
If the user tries to do a "make modules" without first rebuilding
their kernel image, then the make will fail if the dependencies
are not satisfied for the main kernel image and it is thus not
up to date.
^ permalink raw reply
* Re: [2.6 patch] do not select NET_CLS
From: Sam Ravnborg @ 2005-11-22 22:49 UTC (permalink / raw)
To: David S. Miller; +Cc: kaber, bunk, evil, linux-kernel, netdev, zippel
In-Reply-To: <20051122.143713.101129339.davem@davemloft.net>
On Tue, Nov 22, 2005 at 02:37:13PM -0800, David S. Miller wrote:
>
> One thing we can do to prevent human
> mistakes, is to make the "make modules" pass do a quick "is vmlinux
> uptodate?" check, and if not print out an error message explaining the
> situation and aborting the "make modules" attempt.
I do not quite follow you here.
For a while I have considered implementing something that told why a
given file was compiled - like:
CC net/ipv4/ip_gre.o due to net/dsfield.h, net/xfrm.h
CC net/ipv4/raw.c due to include/config/ip/mroute.h
The latter is a config option that I do not see a possibility to change
back to a config option syntax (at least not without doing some effort).
My thinking was that 'make V=2' would give above printout.
But what you request is something that keep the dense printout without
building the kernel - right?
Any suggestion for an intuitive syntax to enable that?
'make -n V=2' will not do it.
Sam
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox