* Re: [PATCH 2.4] sis900: come alive after temporary memory shortage
From: Marcelo Tosatti @ 2005-11-27 8:35 UTC (permalink / raw)
To: Vasily Averin; +Cc: linux-kernel, Konstantin Khorenko, netdev, Daniele Venzano
In-Reply-To: <438829AF.8060101@sw.ru>
On Sat, Nov 26, 2005 at 12:23:59PM +0300, Vasily Averin wrote:
> Hello Marcelo,
>
> I would like to inform you that unfortunately the committed patch is wrong
> http://www.kernel.org/git/?p=linux/kernel/git/marcelo/linux-2.4.git;a=commit;h=ecf3337f76eaa94c5a771308d184dc248b74b725
>
> + int rx_work_limit =
> + (sis_priv->dirty_rx - sis_priv->cur_rx) % NUM_RX_DESC;
>
> when dirty_rx = cur_rx it computes limit=0, but should be NUM_RX_DESC
>
> Could you please drop the wrong patch and use a new one based on the version
> approved by Daniele Venzano and Jeff Garzik
> http://www.kernel.org/git/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commitdiff_plain;h=7380a78a973a8109c13cb0e47617c456b6f6e1f5;hp=b2795f596932286ef12dc08857960d654f577405
Will do - thanks Vasily.
^ permalink raw reply
* memory allocation for DMA operations from network interface
From: Mateusz Berezecki @ 2005-11-27 18:06 UTC (permalink / raw)
To: Linux Kernel Mailing List, netdev
Hello List,
My question is about DMA transfers from network device. I suspect
these transfers require allocating physically contiguous memory
blocks. What is the proper way to allocate such contiguous memory for
DMA purposes inside the kernel? Also what is the proper and
architecture independent way to convert virtual address to physical
one?
kind regards
Mateusz Berezecki
^ permalink raw reply
* Re: memory allocation for DMA operations from network interface
From: Arjan van de Ven @ 2005-11-27 18:19 UTC (permalink / raw)
To: Mateusz Berezecki; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <aec8d6fc0511271006v265a3537r6a90e7d53f706d26@mail.gmail.com>
On Sun, 2005-11-27 at 19:06 +0100, Mateusz Berezecki wrote:
> Hello List,
>
> My question is about DMA transfers from network device. I suspect
> these transfers require allocating physically contiguous memory
> blocks. What is the proper way to allocate such contiguous memory for
> DMA purposes inside the kernel? Also what is the proper and
> architecture independent way to convert virtual address to physical
> one?
see Documentation/DMA-mapping.txt
^ permalink raw reply
* net_device + pci_dev question
From: Mateusz Berezecki @ 2005-11-27 19:58 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
Hello List!
Having only net_device pointer is it possible to retrieve associated pci_dev
pointer basing on this information only?
kind regards,
Mateusz Berezecki
^ permalink raw reply
* Re: net_device + pci_dev question
From: Arjan van de Ven @ 2005-11-27 21:25 UTC (permalink / raw)
To: Mateusz Berezecki; +Cc: linux-kernel, netdev
In-Reply-To: <2510370984.20051127205827@gmail.com>
On Sun, 2005-11-27 at 20:58 +0100, Mateusz Berezecki wrote:
> Hello List!
>
> Having only net_device pointer is it possible to retrieve associated pci_dev
> pointer basing on this information only?
what do you need it for?
(and.. what if the nic isn't a pci one?)
^ permalink raw reply
* Re: [PATCH 05/13]: [IPV4/6]: Netfilter IPsec output hooks
From: Patrick McHardy @ 2005-11-28 1:07 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <20051122121358.GA9057@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 638 bytes --]
Herbert Xu wrote:
> On Tue, Nov 22, 2005 at 09:31:39PM +1100, herbert wrote:
>
>>Unfortunately it looks like gcc 3.3.5 at least is too dumb to optimise
>>it away. I think we'll need a better strategy.
>
>
> OK, the idea is still the same: Move the loop from dst_output into
> xfrm4_output/xfrm6_output since they're the only ones who need to it.
>
> In order to avoid the tail call issue, I've added the inline function
> nf_hook which is nf_hook_slow plus the empty list check.
Thanks, this looks great. I've changed it to only call the hooks
before tunnel mode transforms and added a missing dst_output call
for the final packet.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 8459 bytes --]
[XFRM4/6]: Netfilter IPsec output hooks
Call netfilter hooks before IPsec transforms. Packets visit the FORWARD/LOCAL_OUT
and POST_ROUTING hook before the first encapsulation and the LOCAL_OUT and
POST_ROUTING hook before each following tunnel mode transform.
Based in large parts on patch by Herbert Xu <herbert@gondor.apana.org.au>,
that hides everything within xfrm{4,6}_output.c. Original description:
-
Move the loop from dst_output into xfrm4_output/xfrm6_output since they're
the only ones who need to it.
In order to avoid the tail call issue, I've added the inline function
nf_hook which is nf_hook_slow plus the empty list check.
-
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 7abb84c6c3916fc365051a090c752db682b022ab
tree 31b5c4089aaf23cd2c44516f95fddf2158d0fd70
parent b47e6dc58fa6342f2403a32dd1060bc8b1cef56b
author Patrick McHardy <kaber@trash.net> Mon, 28 Nov 2005 01:56:11 +0100
committer Patrick McHardy <kaber@trash.net> Mon, 28 Nov 2005 01:56:11 +0100
include/linux/netfilter.h | 61 +++++++++++++++++++++++++++------------------
include/net/dst.h | 11 +-------
net/ipv4/xfrm4_output.c | 39 +++++++++++++++++++++++++++--
net/ipv6/xfrm6_output.c | 39 +++++++++++++++++++++++++++--
4 files changed, 112 insertions(+), 38 deletions(-)
diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h
index be365e7..79bb977 100644
--- a/include/linux/netfilter.h
+++ b/include/linux/netfilter.h
@@ -168,6 +168,37 @@ void nf_log_packet(int pf,
const struct net_device *out,
struct nf_loginfo *li,
const char *fmt, ...);
+
+int nf_hook_slow(int pf, unsigned int hook, struct sk_buff **pskb,
+ struct net_device *indev, struct net_device *outdev,
+ int (*okfn)(struct sk_buff *), int thresh);
+
+/**
+ * nf_hook_thresh - call a netfilter hook
+ *
+ * Returns 1 if the hook has allowed the packet to pass. The function
+ * okfn must be invoked by the caller in this case. Any other return
+ * value indicates the packet has been consumed by the hook.
+ */
+static inline int nf_hook_thresh(int pf, unsigned int hook,
+ struct sk_buff **pskb,
+ struct net_device *indev,
+ struct net_device *outdev,
+ int (*okfn)(struct sk_buff *), int thresh)
+{
+#ifndef CONFIG_NETFILTER_DEBUG
+ if (list_empty(&nf_hooks[pf][hook]))
+ return 1;
+#endif
+ return nf_hook_slow(pf, hook, pskb, indev, outdev, okfn, thresh);
+}
+
+static inline int nf_hook(int pf, unsigned int hook, struct sk_buff **pskb,
+ struct net_device *indev, struct net_device *outdev,
+ int (*okfn)(struct sk_buff *))
+{
+ return nf_hook_thresh(pf, hook, pskb, indev, outdev, okfn, INT_MIN);
+}
/* Activate hook; either okfn or kfree_skb called, unless a hook
returns NF_STOLEN (in which case, it's up to the hook to deal with
@@ -188,35 +219,17 @@ void nf_log_packet(int pf,
/* This is gross, but inline doesn't cut it for avoiding the function
call in fast path: gcc doesn't inline (needs value tracking?). --RR */
-#ifdef CONFIG_NETFILTER_DEBUG
-#define NF_HOOK(pf, hook, skb, indev, outdev, okfn) \
-({int __ret; \
-if ((__ret=nf_hook_slow(pf, hook, &(skb), indev, outdev, okfn, INT_MIN)) == 1) \
- __ret = (okfn)(skb); \
-__ret;})
-#define NF_HOOK_THRESH(pf, hook, skb, indev, outdev, okfn, thresh) \
-({int __ret; \
-if ((__ret=nf_hook_slow(pf, hook, &(skb), indev, outdev, okfn, thresh)) == 1) \
- __ret = (okfn)(skb); \
-__ret;})
-#else
-#define NF_HOOK(pf, hook, skb, indev, outdev, okfn) \
-({int __ret; \
-if (list_empty(&nf_hooks[pf][hook]) || \
- (__ret=nf_hook_slow(pf, hook, &(skb), indev, outdev, okfn, INT_MIN)) == 1) \
- __ret = (okfn)(skb); \
-__ret;})
+
+/* HX: It's slightly less gross now. */
+
#define NF_HOOK_THRESH(pf, hook, skb, indev, outdev, okfn, thresh) \
({int __ret; \
-if (list_empty(&nf_hooks[pf][hook]) || \
- (__ret=nf_hook_slow(pf, hook, &(skb), indev, outdev, okfn, thresh)) == 1) \
+if ((__ret=nf_hook_thresh(pf, hook, &(skb), indev, outdev, okfn, thresh)) == 1)\
__ret = (okfn)(skb); \
__ret;})
-#endif
-int nf_hook_slow(int pf, unsigned int hook, struct sk_buff **pskb,
- struct net_device *indev, struct net_device *outdev,
- int (*okfn)(struct sk_buff *), int thresh);
+#define NF_HOOK(pf, hook, skb, indev, outdev, okfn) \
+ NF_HOOK_THRESH(pf, hook, skb, indev, outdev, okfn, INT_MIN)
/* Call setsockopt() */
int nf_setsockopt(struct sock *sk, int pf, int optval, char __user *opt,
diff --git a/include/net/dst.h b/include/net/dst.h
index 6c196a5..e641dd2 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -224,16 +224,7 @@ static inline void dst_set_expires(struc
/* Output packet to network from transport. */
static inline int dst_output(struct sk_buff *skb)
{
- int err;
-
- for (;;) {
- err = skb->dst->output(skb);
-
- if (likely(err == 0))
- return err;
- if (unlikely(err != NET_XMIT_BYPASS))
- return err;
- }
+ return skb->dst->output(skb);
}
/* Input packet from network to transport. */
diff --git a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c
index 66620a9..67b9483 100644
--- a/net/ipv4/xfrm4_output.c
+++ b/net/ipv4/xfrm4_output.c
@@ -8,8 +8,10 @@
* 2 of the License, or (at your option) any later version.
*/
+#include <linux/compiler.h>
#include <linux/skbuff.h>
#include <linux/spinlock.h>
+#include <linux/netfilter_ipv4.h>
#include <net/inet_ecn.h>
#include <net/ip.h>
#include <net/xfrm.h>
@@ -95,7 +97,7 @@ out:
return ret;
}
-int xfrm4_output(struct sk_buff *skb)
+static int xfrm4_output_one(struct sk_buff *skb)
{
struct dst_entry *dst = skb->dst;
struct xfrm_state *x = dst->xfrm;
@@ -133,7 +135,7 @@ int xfrm4_output(struct sk_buff *skb)
err = -EHOSTUNREACH;
goto error_nolock;
}
- err = NET_XMIT_BYPASS;
+ err = 0;
out_exit:
return err;
@@ -143,3 +145,36 @@ error_nolock:
kfree_skb(skb);
goto out_exit;
}
+
+static int xfrm4_output_finish(struct sk_buff *skb)
+{
+ int err;
+
+ while (likely((err = xfrm4_output_one(skb)) == 0)) {
+ if (!skb->dst->xfrm || skb->dst->xfrm->props.mode) {
+ nf_reset(skb);
+ err = nf_hook(PF_INET, NF_IP_LOCAL_OUT, &skb, NULL,
+ skb->dst->dev, dst_output);
+ if (unlikely(err != 1))
+ break;
+
+ if (!skb->dst->xfrm) {
+ err = dst_output(skb);
+ break;
+ }
+
+ err = nf_hook(PF_INET, NF_IP_POST_ROUTING, &skb, NULL,
+ skb->dst->dev, xfrm4_output_finish);
+ if (unlikely(err != 1))
+ break;
+ }
+ }
+
+ return err;
+}
+
+int xfrm4_output(struct sk_buff *skb)
+{
+ return NF_HOOK(PF_INET, NF_IP_POST_ROUTING, skb, NULL, skb->dst->dev,
+ xfrm4_output_finish);
+}
diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c
index 6b98677..69ee2bf 100644
--- a/net/ipv6/xfrm6_output.c
+++ b/net/ipv6/xfrm6_output.c
@@ -9,9 +9,11 @@
* 2 of the License, or (at your option) any later version.
*/
+#include <linux/compiler.h>
#include <linux/skbuff.h>
#include <linux/spinlock.h>
#include <linux/icmpv6.h>
+#include <linux/netfilter_ipv6.h>
#include <net/dsfield.h>
#include <net/inet_ecn.h>
#include <net/ipv6.h>
@@ -92,7 +94,7 @@ static int xfrm6_tunnel_check_size(struc
return ret;
}
-int xfrm6_output(struct sk_buff *skb)
+static int xfrm6_output_one(struct sk_buff *skb)
{
struct dst_entry *dst = skb->dst;
struct xfrm_state *x = dst->xfrm;
@@ -132,7 +134,7 @@ int xfrm6_output(struct sk_buff *skb)
err = -EHOSTUNREACH;
goto error_nolock;
}
- err = NET_XMIT_BYPASS;
+ err = 0;
out_exit:
return err;
@@ -142,3 +144,36 @@ error_nolock:
kfree_skb(skb);
goto out_exit;
}
+
+static int xfrm6_output_finish(struct sk_buff *skb)
+{
+ int err;
+
+ while (likely((err = xfrm6_output_one(skb)) == 0)) {
+ if (!skb->dst->xfrm || skb->dst->xfrm->props.mode) {
+ nf_reset(skb);
+ err = nf_hook(PF_INET6, NF_IP6_LOCAL_OUT, &skb, NULL,
+ skb->dst->dev, dst_output);
+ if (unlikely(err != 1))
+ break;
+
+ if (!skb->dst->xfrm) {
+ err = dst_output(skb);
+ break;
+ }
+
+ err = nf_hook(PF_INET6, NF_IP6_POST_ROUTING, &skb, NULL,
+ skb->dst->dev, xfrm6_output_finish);
+ if (unlikely(err != 1))
+ break;
+ }
+ }
+
+ return err;
+}
+
+int xfrm6_output(struct sk_buff *skb)
+{
+ return NF_HOOK(PF_INET6, NF_IP6_POST_ROUTING, skb, NULL, skb->dst->dev,
+ xfrm6_output_finish);
+}
^ permalink raw reply related
* Re: [PATCH 05/13]: [IPV4/6]: Netfilter IPsec output hooks
From: Herbert Xu @ 2005-11-28 4:56 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <438A5837.5040706@trash.net>
On Mon, Nov 28, 2005 at 02:07:03AM +0100, Patrick McHardy wrote:
>
> Thanks, this looks great. I've changed it to only call the hooks
Glad you liked it :)
> before tunnel mode transforms and added a missing dst_output call
> for the final packet.
This shouldn't be necessary if you apply it on top of my previous
patch which made xfrm[46]_output process the first SA and all subsequent
transport mode SAs. I've included that patch here again.
I think it still makes sense to do that because this corresponds
with the usual representation of an IPsec connection and it
simplifies the handling of netfilter hooks.
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
--
diff --git a/include/net/ip.h b/include/net/ip.h
diff --git a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c
--- a/net/ipv4/xfrm4_output.c
+++ b/net/ipv4/xfrm4_output.c
@@ -113,26 +113,31 @@ int xfrm4_output(struct sk_buff *skb)
goto error_nolock;
}
- spin_lock_bh(&x->lock);
- err = xfrm_state_check(x, skb);
- if (err)
- goto error;
-
- xfrm4_encap(skb);
-
- err = x->type->output(x, skb);
- if (err)
- goto error;
+ do {
+ spin_lock_bh(&x->lock);
+ err = xfrm_state_check(x, skb);
+ if (err)
+ goto error;
+
+ xfrm4_encap(skb);
+
+ err = x->type->output(x, skb);
+ if (err)
+ goto error;
- x->curlft.bytes += skb->len;
- x->curlft.packets++;
+ x->curlft.bytes += skb->len;
+ x->curlft.packets++;
- spin_unlock_bh(&x->lock);
+ spin_unlock_bh(&x->lock);
- if (!(skb->dst = dst_pop(dst))) {
- err = -EHOSTUNREACH;
- goto error_nolock;
- }
+ if (!(skb->dst = dst_pop(dst))) {
+ err = -EHOSTUNREACH;
+ goto error_nolock;
+ }
+ dst = skb->dst;
+ x = dst->xfrm;
+ } while (x && !x->props.mode);
+
err = NET_XMIT_BYPASS;
out_exit:
diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c
--- a/net/ipv6/xfrm6_output.c
+++ b/net/ipv6/xfrm6_output.c
@@ -110,28 +110,33 @@ int xfrm6_output(struct sk_buff *skb)
goto error_nolock;
}
- spin_lock_bh(&x->lock);
- err = xfrm_state_check(x, skb);
- if (err)
- goto error;
-
- xfrm6_encap(skb);
-
- err = x->type->output(x, skb);
- if (err)
- goto error;
-
- x->curlft.bytes += skb->len;
- x->curlft.packets++;
-
- spin_unlock_bh(&x->lock);
+ do {
+ spin_lock_bh(&x->lock);
+ err = xfrm_state_check(x, skb);
+ if (err)
+ goto error;
+
+ xfrm6_encap(skb);
+
+ err = x->type->output(x, skb);
+ if (err)
+ goto error;
+
+ x->curlft.bytes += skb->len;
+ x->curlft.packets++;
+
+ spin_unlock_bh(&x->lock);
+
+ skb->nh.raw = skb->data;
+
+ if (!(skb->dst = dst_pop(dst))) {
+ err = -EHOSTUNREACH;
+ goto error_nolock;
+ }
+ dst = skb->dst;
+ x = dst->xfrm;
+ } while (x && !x->props.mode);
- skb->nh.raw = skb->data;
-
- if (!(skb->dst = dst_pop(dst))) {
- err = -EHOSTUNREACH;
- goto error_nolock;
- }
err = NET_XMIT_BYPASS;
out_exit:
^ permalink raw reply
* Registration_Confirmation
From: office @ 2005-11-28 5:55 UTC (permalink / raw)
To: XFreeMail
[-- Attachment #1: Type: text/plain, Size: 113 bytes --]
Account and Password Information are attached!
***** Go to: http://www.intel.com
***** Email: postman@intel.com
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Your Password
From: office @ 2005-11-28 9:22 UTC (permalink / raw)
To: rbh00
[-- Attachment #1: Type: text/plain, Size: 121 bytes --]
Protected message is attached!
***** Go to: http://www.lists.sourceforge.net
***** Email: postman@lists.sourceforge.net
[-- Attachment #2: reg_pass.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: [PATCH 05/13]: [IPV4/6]: Netfilter IPsec output hooks
From: Patrick McHardy @ 2005-11-28 12:25 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <20051128045611.GA9571@gondor.apana.org.au>
Herbert Xu wrote:
> On Mon, Nov 28, 2005 at 02:07:03AM +0100, Patrick McHardy wrote:
>
>>Thanks, this looks great. I've changed it to only call the hooks
>
>
> Glad you liked it :)
>
>
>>before tunnel mode transforms and added a missing dst_output call
>>for the final packet.
>
>
> This shouldn't be necessary if you apply it on top of my previous
> patch which made xfrm[46]_output process the first SA and all subsequent
> transport mode SAs. I've included that patch here again.
>
> I think it still makes sense to do that because this corresponds
> with the usual representation of an IPsec connection and it
> simplifies the handling of netfilter hooks.
I agree, I missed that your patch based on that one. Let me have
another look :)
^ permalink raw reply
* Re: KERNEL: assertion (!sk->sk_forward_alloc) failed
From: Jesse Brandeburg @ 2005-11-28 16:44 UTC (permalink / raw)
To: Miquel van Smoorenburg, nipsy; +Cc: linux-kernel, Kernel Netdev Mailing List
In-Reply-To: <dmf1kn$t2s$1@news.cistron.nl>
This should really be on netdev, so I copied it.
On 11/28/05, Miquel van Smoorenburg <miquels@cistron.nl> wrote:
> In article <20051128123601.GA32346@king.bitgnome.net>,
> Mark Nipper <nipsy@bitgnome.net> wrote:
> > I received the following in my system logs recently:
> >---
> >Nov 27 22:56:20 king kernel: KERNEL: assertion (!sk->sk_forward_alloc)
> >failed at net/core/stream.c (279)
> >Nov 27 22:56:20 king kernel: KERNEL: assertion (!sk->sk_forward_alloc)
> >failed at net/ipv4/af_inet.c (151)
> >
> > All I could find related to this was some potential bugs
> >mentioned in 2.6.9 and in particular with relation to TSO.
> >However, I'm running a vanilla 2.6.13.4 at the moment. But, I do
> >have an e1000 and checking ethtool does show TSO on.
>
> I'm seeing the same on 2.6.14.2, also with e1000. It wasn't there on
> 2.6.11.12 which I was running previously.
I don't believe this is related to e1000 because we don't mess with
the sock (sk) struct. Did you try disabling TSO? I bet the netdev
guys can help.
^ permalink raw reply
* (no subject)
From: declarator @ 2005-11-28 20:08 UTC (permalink / raw)
^ permalink raw reply
* Re[2]: net_device + pci_dev question
From: Mateusz Berezecki @ 2005-11-28 20:56 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel, netdev
In-Reply-To: <1133126713.2853.45.camel@laptopd505.fenrus.org>
Hello Arjan,
On 27th november 2005 (22:25:13) you wrote:
> On Sun, 2005-11-27 at 20:58 +0100, Mateusz Berezecki wrote:
>> Hello List!
>>
>> Having only net_device pointer is it possible to retrieve associated pci_dev
>> pointer basing on this information only?
> what do you need it for?
for pci_alloc_consistent() which takes pci_dev as a first argument to
allocate contiguous memory block for DMA transfers. I just realized
when I saw your answer that I might have moved the memory allocation to
some routine which is called earlier in time which has access to
pci_dev pointer directly, like net_device->init IIRC. But I'm not
really sure if that would be correct solution.
> (and.. what if the nic isn't a pci one?)
Uh... it's cardbus interface and still uses pci_* stuff without problems. (?)
Do I miss something?
kind regards
Mateusz Berezecki
^ permalink raw reply
* Re: Re[2]: net_device + pci_dev question
From: Arjan van de Ven @ 2005-11-28 21:03 UTC (permalink / raw)
To: Mateusz Berezecki; +Cc: linux-kernel, netdev
In-Reply-To: <1653628458.20051128215644@gmail.com>
On Mon, 2005-11-28 at 21:56 +0100, Mateusz Berezecki wrote:
> Hello Arjan,
>
> On 27th november 2005 (22:25:13) you wrote:
>
> > On Sun, 2005-11-27 at 20:58 +0100, Mateusz Berezecki wrote:
> >> Hello List!
> >>
> >> Having only net_device pointer is it possible to retrieve associated pci_dev
> >> pointer basing on this information only?
>
> > what do you need it for?
>
> for pci_alloc_consistent() which takes pci_dev as a first argument to
> allocate contiguous memory block for DMA transfers. I just realized
oh it's *your own* netdev...
that makes things a lot easier ;)
it's custom to have driver private data per net dev
(see netdev_priv() to get it, alloc_etherdev() takes the size of it as
argument). It's custom to make that private data a struct in which you
can store the pci device pointer yourself, as well as any other per card
data that you need to store
^ permalink raw reply
* Re: [PATCH 07/13]: [NETFILTER]: Fix xfrm lookup in ip_route_me_harder/ip6_route_me_harder
From: Herbert Xu @ 2005-11-28 21:06 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <20051120163137.16666.924.sendpatchset@localhost.localdomain>
On Sun, Nov 20, 2005 at 04:31:37PM +0000, Patrick McHardy wrote:
>
> diff --git a/include/net/ip.h b/include/net/ip.h
> index 9f09882..377036b 100644
> --- a/include/net/ip.h
> +++ b/include/net/ip.h
> @@ -45,6 +45,7 @@ struct inet_skb_parm
> #define IPSKB_TRANSLATED 2
> #define IPSKB_FORWARDED 4
> #define IPSKB_XFRM_TUNNEL_SIZE 8
> +#define IPSKB_XFRM_TRANSFORMED 16
> };
My only question about this patch is where should we clear these flags?
For instance, when ipip/gre transmits a packet, should this flag (and
perhaps other flags here) be cleared?
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[4]: net_device + pci_dev question
From: Mateusz Berezecki @ 2005-11-28 21:08 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel, netdev
In-Reply-To: <1133211819.2824.82.camel@laptopd505.fenrus.org>
Hello Arjan,
On 28th november 2005 (22:03:38) you wrote:
> oh it's *your own* netdev...
Yes:-) Sorry for not being precise
> that makes things a lot easier ;)
> it's custom to have driver private data per net dev
> (see netdev_priv() to get it, alloc_etherdev() takes the size of it as
> argument). It's custom to make that private data a struct in which you
> can store the pci device pointer yourself, as well as any other per card
> data that you need to store
Ok, I will do it like that then. Thank you for the explanation on this
issue.
kind regards,
Mateusz Berezecki
^ permalink raw reply
* Re: [Patch] 2.4.32 - Neighbour Cache (ARP) State machine bug Fixed
From: Roberto Nibali @ 2005-11-28 21:40 UTC (permalink / raw)
To: Pradeep Vincent; +Cc: linux-kernel, torvalds, netdev
In-Reply-To: <9fda5f510511281257o364acb3gd634f8e412cd7301@mail.gmail.com>
> In 2.4.21, arp code uses gc_timer to check for stale arp cache
> entries. In 2.6, each entry has its own timer to check for stale arp
> cache. 2.4.29 to 2.4.32 kernels (atleast) use neither of these timers.
Regarding NUD_REACHABLE <-> NUD_STALE transition it has a timer check.
Due to the fast path it's not enabled per default. Use neigh_sync() to
check, although I believe the installed tasklet does this for you already.
The knowledgeable netdev people will know better.
> This causes problems in environments where IPs or MACs are reassigned
> - saw this problem on load balancing router based networks that use
> VMACs. Tested this code on load balancing router based networks as
> well as peer-linux systems.
How do you use VMACs in 2.4.x?
> diff -Naur old/net/core/neighbour.c new/net/core/neighbour.c
> --- old/net/core/neighbour.c Wed Nov 23 17:15:30 2005
> +++ new/net/core/neighbour.c Wed Nov 23 17:26:01 2005
> @@ -14,6 +14,7 @@
> * Vitaly E. Lavrov releasing NULL neighbor in neigh_add.
> * Harald Welte Add neighbour cache statistics like rtstat
> * Harald Welte port neighbour cache rework from 2.6.9-rcX
> + * Pradeep Vincent Move neighbour cache entry to stale state
> */
>
> #include <linux/config.h>
> @@ -705,6 +706,14 @@
> neigh_release(n);
> continue;
> }
> +
> + /* Mark it stale - To be reconfirmed later when used */
> + if (n->nud_state&NUD_REACHABLE &&
> + now - n->confirmed > n->parms->reachable_time) {
> + n->nud_state = NUD_STALE;
> + neigh_suspect(n);
> + }
> +
If this is really a problem, why not simply call neigh_sync()? Your
patch also seems to be whitespace damaged.
> write_unlock(&n->lock);
>
> next_elt:
I've cc'd netdev since this is where such patches should go for
discussion; left Linus in the loop (netiquette) although he's nothing to
do with this ;).
Cheers,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
^ permalink raw reply
* Re: VIA "Velocity" test report - VLAN reception not working
From: Francois Romieu @ 2005-11-28 22:48 UTC (permalink / raw)
To: linux; +Cc: alan, netdev
In-Reply-To: <20051126004057.11284.qmail@science.horizon.com>
linux@horizon.com <linux@horizon.com> :
[...]
> Link detected: no
>
> Kernel 2.6.15-rc2, monolithic. Only local patch is PPSkit-lite, which
> really shouldn't have any effect. No idea about that "Link detected: no"
> line; I'm ssh- ed in over it right now.
The driver does not correctly handle netif_carrier_{on/off}.
[...]
> I saw a bunch of VLAN filtering stuff in the driver that I didn't
> really follow, so perhaps the problem's there.
>
> (I confess I didn't choose super-carefully. It was advertised as having
> Linux support and VLAN support and was reasonably cheap. I didn't
> actually know the chipset until it arrived. And yes, I *am* asking the
> vendor for support, but I expect that'll take a while.)
If you can put the card in a crashme/testme computer, feel free to try
the patches at:
http://www.zoreil.com/~romieu/linux/kernel/2.6.x/2.6.15-rc2/via-velocity/20051128
The patches apply on top of each other. I'd suggest doing a first round
of testing without VLAN to check that the usual flow did not experience
collateral damages.
If it works fine, enable VLAN when the last patch is applied and add
a single vlan with vconfig. If it does not crash, tcpdump + ping in
both direction w/wo VLAN may help fix the issues.
The patches are quite straightforward even if they are poorly described.
--
Ueimor
^ permalink raw reply
* Re: [RFC] [PATCH 1/3] ioat: DMA subsystem
From: Andrew Grover @ 2005-11-28 22:57 UTC (permalink / raw)
To: linux-kernel, netdev
In-Reply-To: <20051124150433.GA3590@havoc.gtf.org>
(resending in plain text, trimming CCs)
Thanks to everyone for taking the time to provide feedback. We're
going to go make the changes you suggested and will hopefully have the
code fixed up (and add more docs) in a few weeks.
Regards -- Andy
^ permalink raw reply
* Re: [PATCH 07/13]: [NETFILTER]: Fix xfrm lookup in ip_route_me_harder/ip6_route_me_harder
From: Patrick McHardy @ 2005-11-29 7:02 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <20051128210628.GA15057@gondor.apana.org.au>
Herbert Xu wrote:
> On Sun, Nov 20, 2005 at 04:31:37PM +0000, Patrick McHardy wrote:
>
>>diff --git a/include/net/ip.h b/include/net/ip.h
>>index 9f09882..377036b 100644
>>--- a/include/net/ip.h
>>+++ b/include/net/ip.h
>>@@ -45,6 +45,7 @@ struct inet_skb_parm
>> #define IPSKB_TRANSLATED 2
>> #define IPSKB_FORWARDED 4
>> #define IPSKB_XFRM_TUNNEL_SIZE 8
>>+#define IPSKB_XFRM_TRANSFORMED 16
>> };
>
>
> My only question about this patch is where should we clear these flags?
> For instance, when ipip/gre transmits a packet, should this flag (and
> perhaps other flags here) be cleared?
Good point. This specific flags should be cleared when a packet
(re-)enters the IP stack, I guess by definition of the cb, this
holds for the other flags as well. Looking at the other flags:
- IPSKB_MASQUERADED is unused
- IPSKB_TRANSLATED is unused
- IPSKB_FORWARDED is used by ipmr in a way that looks broken,
it expects the flags on the input path to be the same it set
on the output path.
- IPSKB_XFRM_TUNNEL_SIZE should be cleared when a packet enters
the IP stack
It seems in most places where only IPCB(skb)->opt is cleared
the entire CB should be cleared. A couple of spots also look
completely unnecessary, for example all places clearing the CB
before passing the packet to netif_rx. I would expect the next
user beeing responsible for clearing the space he needs if
neccessary.
^ permalink raw reply
* Re: [PATCH 07/13]: [NETFILTER]: Fix xfrm lookup in ip_route_me_harder/ip6_route_me_harder
From: Herbert Xu @ 2005-11-29 7:34 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <438BFD0A.5040105@trash.net>
On Tue, Nov 29, 2005 at 08:02:34AM +0100, Patrick McHardy wrote:
>
> - IPSKB_MASQUERADED is unused
> - IPSKB_TRANSLATED is unused
> - IPSKB_FORWARDED is used by ipmr in a way that looks broken,
> it expects the flags on the input path to be the same it set
> on the output path.
> - IPSKB_XFRM_TUNNEL_SIZE should be cleared when a packet enters
> the IP stack
Yes that looks correct.
> It seems in most places where only IPCB(skb)->opt is cleared
> the entire CB should be cleared. A couple of spots also look
> completely unnecessary, for example all places clearing the CB
> before passing the packet to netif_rx. I would expect the next
> user beeing responsible for clearing the space he needs if
> neccessary.
Agreed. However, it seems that ip_rcv() only clears the CB options
if ihl is greater than 5. So until that's changed the people feeding
netif_rx will have to clear the CB.
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 07/13]: [NETFILTER]: Fix xfrm lookup in ip_route_me_harder/ip6_route_me_harder
From: David S. Miller @ 2005-11-29 7:49 UTC (permalink / raw)
To: herbert; +Cc: netdev, netfilter-devel, kaber
In-Reply-To: <20051129073441.GA18387@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 29 Nov 2005 18:34:41 +1100
> On Tue, Nov 29, 2005 at 08:02:34AM +0100, Patrick McHardy wrote:
> > It seems in most places where only IPCB(skb)->opt is cleared
> > the entire CB should be cleared. A couple of spots also look
> > completely unnecessary, for example all places clearing the CB
> > before passing the packet to netif_rx. I would expect the next
> > user beeing responsible for clearing the space he needs if
> > neccessary.
>
> Agreed. However, it seems that ip_rcv() only clears the CB options
> if ihl is greater than 5. So until that's changed the people feeding
> netif_rx will have to clear the CB.
I wonder if that stuff can be simplified somehow.
We only use those options in two ways:
1) To process early in input via ip_options_compile()
and the source route check in ip_rcv_finish()
2) To do forwarding processing on options in ip_forward_finish()
and the multicast equivalent in ipmr.c
3) For locally destined packets, when the options are to be
passed to the user via a recvmsg() CMSG.
Well, there is a 4th, which is what we're talking about here,
which is all of the zero'ing out of the thing during encapsulation
which is mostly a waste.
I think #1 and #2 can be handled by an on-stack copy of "struct
ip_options" high enough in the call chain, but #3 is a bit less
trivial to cope with like that.
It would be nice to kill the IPCB() copy, and give us 12 bytes back in
skb->cb[] :-)
^ permalink raw reply
* [PATCH] orinoco: fix setting power management parameters
From: Pavel Roskin @ 2005-11-29 7:59 UTC (permalink / raw)
To: orinoco-devel, NetDev
Power management parameters could not be set by iwconfig due to
incorrect error handling.
Signed-off-by: Pavel Roskin <proski-mXXj517/zsQ@public.gmane.org>
---
This is a very simple bugfix, and the bug is serious enough, so I'll
appreciate if the patch gets priority handling and goes to 2.6.15. I
have lots of other stuff that can wait until 2.6.16.
diff --git a/drivers/net/wireless/orinoco.c
b/drivers/net/wireless/orinoco.c
index 2032c56..708b146 100644
--- a/drivers/net/wireless/orinoco.c
+++ b/drivers/net/wireless/orinoco.c
@@ -3492,9 +3492,8 @@ static int orinoco_ioctl_setpower(struct
break;
default:
err = -EINVAL;
- }
- if (err)
goto out;
+ }
if (prq->flags & IW_POWER_TIMEOUT) {
priv->pm_on = 1;
--
Regards,
Pavel Roskin
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply related
* Re: Fw: [Fwd: [Bug 5644] New: NFS v3 TCP 3-way handshake incorrect, iptables blocks access]
From: Jozsef Kadlecsik @ 2005-11-29 10:43 UTC (permalink / raw)
To: Olaf Kirch
Cc: Harald Welte, netdev, netfilter-devel, David S. Miller,
Patrick McHardy
In-Reply-To: <Pine.LNX.4.58.0511250937560.22835@blackhole.kfki.hu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1330 bytes --]
Hi,
On Fri, 25 Nov 2005, Jozsef Kadlecsik wrote:
> On Thu, 24 Nov 2005, Olaf Kirch wrote:
>
> > On Thu, Nov 24, 2005 at 03:08:27PM +0100, Harald Welte wrote:
> > > Jozsef Kadlecsik doesn't recall those patches/changes (even though he's
> > > our "Mr. TCP state tracking" and is indicated as the author of one of
> > > the two patches.
> > >
> > > I also don't recall having seen any of those patches before. But that
> > > doesn't mean all too much, my brain is like a sieve some times.
> >
> > Those patches came out of a discussion on netfilter-devel. Sorry,
> > I don't know exactly when but looking at our CVS log it was Dec 2004.
>
> Yes, it was about a year ago - finally I could dig out the patches from my
> mail archives. I'll prepare an updated version on the weekend and send it
> out to netfilter-devel for reviewing.
Attached is the updated patch. Unfortunately nfsim currently is broken so
I could not test it against the testsuite, but actually it's identical
with the original, not applied patches. The patch takes care both
ip_conntrack and nf_conntrack.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
[-- Attachment #2: tcp-win-half-close.patch --]
[-- Type: TEXT/PLAIN, Size: 5431 bytes --]
Mounting NFS file systems after a (warm) reboot could take a long time if
firewalling and connection tracking was enabled.
The reason is that the NFS clients tends to use the same ports (800 and
counting down). Now on reboot, the server would still have a TCB for an
existing TCP connection client:800 -> server:2049. The client sends a
SYN from port 800 to server:2049, which elicits an ACK from the server.
The firewall on the client drops the ACK because (from its point of
view) the connection is still in half-open state, and it expects to see
a SYNACK.
The client will eventually time out after several minutes.
The following patch corrects this, by accepting ACKs on half open connections
as well.
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
diff -urN --exclude-from=/usr/src/diff.exclude linux-2.6.15-rc2-orig/net/ipv4/netfilter/ip_conntrack_proto_tcp.c linux-2.6.15-rc2-tcp-win/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
--- linux-2.6.15-rc2-orig/net/ipv4/netfilter/ip_conntrack_proto_tcp.c 2005-11-20 04:25:03.000000000 +0100
+++ linux-2.6.15-rc2-tcp-win/net/ipv4/netfilter/ip_conntrack_proto_tcp.c 2005-11-29 11:01:25.000000000 +0100
@@ -272,9 +272,9 @@
* sCL -> sCL
*/
/* sNO, sSS, sSR, sES, sFW, sCW, sLA, sTW, sCL, sLI */
-/*ack*/ { sIV, sIV, sSR, sES, sCW, sCW, sTW, sTW, sCL, sIV },
+/*ack*/ { sIV, sIG, sSR, sES, sCW, sCW, sTW, sTW, sCL, sIV },
/*
- * sSS -> sIV Might be a half-open connection.
+ * sSS -> sIG Might be a half-open connection.
* sSR -> sSR Might answer late resent SYN.
* sES -> sES :-)
* sFW -> sCW Normal close request answered by ACK.
@@ -917,8 +917,12 @@
switch (new_state) {
case TCP_CONNTRACK_IGNORE:
- /* Either SYN in ORIGINAL
- * or SYN/ACK in REPLY. */
+ /* Ignored packets:
+ *
+ * a) SYN in ORIGINAL
+ * b) SYN/ACK in REPLY
+ * c) ACK in reply direction after initial SYN in original.
+ */
if (index == TCP_SYNACK_SET
&& conntrack->proto.tcp.last_index == TCP_SYN_SET
&& conntrack->proto.tcp.last_dir != dir
@@ -985,13 +989,20 @@
}
case TCP_CONNTRACK_CLOSE:
if (index == TCP_RST_SET
- && test_bit(IPS_SEEN_REPLY_BIT, &conntrack->status)
- && conntrack->proto.tcp.last_index == TCP_SYN_SET
+ && ((test_bit(IPS_SEEN_REPLY_BIT, &conntrack->status)
+ && conntrack->proto.tcp.last_index == TCP_SYN_SET)
+ || (!test_bit(IPS_ASSURED_BIT, &conntrack->status)
+ && conntrack->proto.tcp.last_index == TCP_ACK_SET))
&& ntohl(th->ack_seq) == conntrack->proto.tcp.last_end) {
- /* RST sent to invalid SYN we had let trough
- * SYN was in window then, tear down connection.
+ /* RST sent to invalid SYN or ACK we had let trough
+ * at a) and c) above:
+ *
+ * a) SYN was in window then
+ * c) we hold a half-open connection.
+ *
+ * Delete our connection entry.
* We skip window checking, because packet might ACK
- * segments we ignored in the SYN. */
+ * segments we ignored. */
goto in_window;
}
/* Just fall trough */
diff -urN --exclude-from=/usr/src/diff.exclude linux-2.6.15-rc2-orig/net/netfilter/nf_conntrack_proto_tcp.c linux-2.6.15-rc2-tcp-win/net/netfilter/nf_conntrack_proto_tcp.c
--- linux-2.6.15-rc2-orig/net/netfilter/nf_conntrack_proto_tcp.c 2005-11-20 04:25:03.000000000 +0100
+++ linux-2.6.15-rc2-tcp-win/net/netfilter/nf_conntrack_proto_tcp.c 2005-11-29 11:19:00.000000000 +0100
@@ -280,9 +280,9 @@
* sCL -> sCL
*/
/* sNO, sSS, sSR, sES, sFW, sCW, sLA, sTW, sCL, sLI */
-/*ack*/ { sIV, sIV, sSR, sES, sCW, sCW, sTW, sTW, sCL, sIV },
+/*ack*/ { sIV, sIG, sSR, sES, sCW, sCW, sTW, sTW, sCL, sIV },
/*
- * sSS -> sIV Might be a half-open connection.
+ * sSS -> sIG Might be a half-open connection.
* sSR -> sSR Might answer late resent SYN.
* sES -> sES :-)
* sFW -> sCW Normal close request answered by ACK.
@@ -912,8 +912,12 @@
switch (new_state) {
case TCP_CONNTRACK_IGNORE:
- /* Either SYN in ORIGINAL
- * or SYN/ACK in REPLY. */
+ /* Ignored packets:
+ *
+ * a) SYN in ORIGINAL
+ * b) SYN/ACK in REPLY
+ * c) ACK in reply direction after initial SYN in original.
+ */
if (index == TCP_SYNACK_SET
&& conntrack->proto.tcp.last_index == TCP_SYN_SET
&& conntrack->proto.tcp.last_dir != dir
@@ -979,13 +983,20 @@
}
case TCP_CONNTRACK_CLOSE:
if (index == TCP_RST_SET
- && test_bit(IPS_SEEN_REPLY_BIT, &conntrack->status)
- && conntrack->proto.tcp.last_index == TCP_SYN_SET
+ && ((test_bit(IPS_SEEN_REPLY_BIT, &conntrack->status)
+ && conntrack->proto.tcp.last_index == TCP_SYN_SET)
+ || (!test_bit(IPS_ASSURED_BIT, &conntrack->status)
+ && conntrack->proto.tcp.last_index == TCP_ACK_SET))
&& ntohl(th->ack_seq) == conntrack->proto.tcp.last_end) {
- /* RST sent to invalid SYN we had let trough
- * SYN was in window then, tear down connection.
+ /* RST sent to invalid SYN or ACK we had let trough
+ * at a) and c) above:
+ *
+ * a) SYN was in window then
+ * c) we hold a half-open connection.
+ *
+ * Delete our connection entry.
* We skip window checking, because packet might ACK
- * segments we ignored in the SYN. */
+ * segments we ignored. */
goto in_window;
}
/* Just fall trough */
^ permalink raw reply
* Re: [PATCH 07/13]: [NETFILTER]: Fix xfrm lookup in ip_route_me_harder/ip6_route_me_harder
From: Herbert Xu @ 2005-11-29 11:31 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, netfilter-devel, kaber
In-Reply-To: <20051128.234947.117781000.davem@davemloft.net>
On Mon, Nov 28, 2005 at 11:49:47PM -0800, David S. Miller wrote:
>
> I think #1 and #2 can be handled by an on-stack copy of "struct
> ip_options" high enough in the call chain, but #3 is a bit less
> trivial to cope with like that.
>
> It would be nice to kill the IPCB() copy, and give us 12 bytes back in
> skb->cb[] :-)
That would be great. I'm glad that Patrick's patch set is bringing
out potential ways of shrinking sk_buff.
--
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
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