* Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: Adrian Bunk @ 2006-02-20 2:39 UTC (permalink / raw)
To: Alessandro Zummo; +Cc: Martin Michlmayr, linux-kernel, netdev, John Bowler
In-Reply-To: <20060220030146.11f418dc@inspiron>
On Mon, Feb 20, 2006 at 03:01:46AM +0100, Alessandro Zummo wrote:
> On Mon, 20 Feb 2006 02:47:35 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
>
> > > Some Ethernet hardware implementations have no built-in storage for
> > > allocated MAC values - an example is the Intel IXP420 chip which has
> > > support for Ethernet but no defined way of storing allocated MAC values.
> > > With such hardware different board level implementations store the
> > > allocated MAC (or MACs) in different ways. Rather than put board level
> > > c
> > Silly question:
> >
> > Why can't this be implemented in user space using the SIOCSIFHWADDR
> > ioctl?
>
> Because sometimes you need to have networking available
> well before userspace.
>
> (netconsole, root over nfs, ...)
Why can't setting MAC addresses be done from initramfs?
> Best regards,
> Alessandro Zummo,
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
* (usagi-users 03613) Re: [PATCH] [NET]: NETFILTER: remove duplicated operation and fix order in skb_clone().
From: David S. Miller @ 2006-02-20 6:32 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev, usagi-users, olivier.matz
In-Reply-To: <20060217.215101.09874309.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Fri, 17 Feb 2006 21:51:01 +0900 (JST)
> [NET]: NETFILTER: remove duplicated lines and fix order in skb_clone().
>
> Some of netfilter-related members are initalized / copied twice in
> skb_clone(). Remove one. Pointed out by Olivier MATZ <olivier.matz@6wind.com>.
>
> And this patch also fixes order of copying / clearing members.
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Patch applied to net-2.6, thank you very much.
^ permalink raw reply
* [NETFILTER]: Fix skb->nf_bridge lifetime issues
From: Patrick McHardy @ 2006-02-20 7:44 UTC (permalink / raw)
To: Bart De Schuymer
Cc: Linux Netdev List, Netfilter Development Mailinglist,
David S. Miller
[-- Attachment #1: Type: text/plain, Size: 361 bytes --]
Bart, can you please have a look at this patch and ACK/NACK it?
We have a bugreport in the netfilter bugzilla of broken conntrack
with tunnels on top of bridge devices (#448), which should be cured
by this patch.
There is also another report of broken conntrack with vlan on top
of bridge devices (#400) that looks related, but probably this
patch won't help.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 3216 bytes --]
[NETFILTER]: Fix skb->nf_bridge lifetime issues
The bridge netfilter code simulates the NF_IP_PRE_ROUTING hook and skips
the real hook by registering with high priority and returning NF_STOP if
skb->nf_bridge is present and the BRNF_NF_BRIDGE_PREROUTING flag is not
set. The flag is only set during the simulated hook.
Because skb->nf_bridge is only freed when the packet is destroyed, the
packet will not only skip the first invocation of NF_IP_PRE_ROUTING, but
in the case of tunnel devices on top of the bridge also all further ones.
Forwarded packets from a bridge encapsulated by a tunnel device and sent
as locally outgoing packet will also still have the incorrect bridge
information from the input path attached.
We already have nf_reset calls on all RX/TX paths of tunnel devices,
so simply reset the nf_bridge field there too. As an added bonus,
the bridge information for locally delivered packets is now also freed
when the packet is queued to a socket.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 22e4dcb796d276db47a61c2382bdf2eaf76db32e
tree ccc5173acbe70506aa60e826e1881a4513f8c868
parent 337ba256a7e68f174a88ffba805b40622297fc22
author Patrick McHardy <kaber@trash.net> Mon, 20 Feb 2006 08:41:48 +0100
committer Patrick McHardy <kaber@trash.net> Mon, 20 Feb 2006 08:41:48 +0100
include/linux/skbuff.h | 24 ++++++++++++++----------
net/ipv4/netfilter/ipt_REJECT.c | 4 ----
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 838ce0f..65bf1fa 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1351,16 +1351,6 @@ static inline void nf_conntrack_put_reas
kfree_skb(skb);
}
#endif
-static inline void nf_reset(struct sk_buff *skb)
-{
- nf_conntrack_put(skb->nfct);
- skb->nfct = NULL;
-#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
- nf_conntrack_put_reasm(skb->nfct_reasm);
- skb->nfct_reasm = NULL;
-#endif
-}
-
#ifdef CONFIG_BRIDGE_NETFILTER
static inline void nf_bridge_put(struct nf_bridge_info *nf_bridge)
{
@@ -1373,6 +1363,20 @@ static inline void nf_bridge_get(struct
atomic_inc(&nf_bridge->use);
}
#endif /* CONFIG_BRIDGE_NETFILTER */
+static inline void nf_reset(struct sk_buff *skb)
+{
+ nf_conntrack_put(skb->nfct);
+ skb->nfct = NULL;
+#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
+ nf_conntrack_put_reasm(skb->nfct_reasm);
+ skb->nfct_reasm = NULL;
+#endif
+#ifdef CONFIG_BRIDGE_NETFILTER
+ nf_bridge_put(skb->nfct);
+ skb->nfct = NULL;
+#endif
+}
+
#else /* CONFIG_NETFILTER */
static inline void nf_reset(struct sk_buff *skb) {}
#endif /* CONFIG_NETFILTER */
diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.c
index 26ea6c1..9d3b357 100644
--- a/net/ipv4/netfilter/ipt_REJECT.c
+++ b/net/ipv4/netfilter/ipt_REJECT.c
@@ -154,10 +154,6 @@ static void send_reset(struct sk_buff *o
/* This packet will not be the same as the other: clear nf fields */
nf_reset(nskb);
nskb->nfmark = 0;
-#ifdef CONFIG_BRIDGE_NETFILTER
- nf_bridge_put(nskb->nf_bridge);
- nskb->nf_bridge = NULL;
-#endif
tcph = (struct tcphdr *)((u_int32_t*)nskb->nh.iph + nskb->nh.iph->ihl);
^ permalink raw reply related
* Re: [NETFILTER]: Fix skb->nf_bridge lifetime issues
From: Patrick McHardy @ 2006-02-20 9:33 UTC (permalink / raw)
To: Bart De Schuymer
Cc: Linux Netdev List, Netfilter Development Mailinglist,
David S. Miller
In-Reply-To: <43F97342.9050806@trash.net>
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
Patrick McHardy wrote:
> Bart, can you please have a look at this patch and ACK/NACK it?
> We have a bugreport in the netfilter bugzilla of broken conntrack
> with tunnels on top of bridge devices (#448), which should be cured
> by this patch.
>
> +static inline void nf_reset(struct sk_buff *skb)
> +{
> + nf_conntrack_put(skb->nfct);
> + skb->nfct = NULL;
> +#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
> + nf_conntrack_put_reasm(skb->nfct_reasm);
> + skb->nfct_reasm = NULL;
> +#endif
> +#ifdef CONFIG_BRIDGE_NETFILTER
> + nf_bridge_put(skb->nfct);
> + skb->nfct = NULL;
> +#endif
> +}
This time compile tested and s/nfct/nf_bridge/ above.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 3226 bytes --]
[NETFILTER]: Fix skb->nf_bridge lifetime issues
The bridge netfilter code simulates the NF_IP_PRE_ROUTING hook and skips
the real hook by registering with high priority and returning NF_STOP if
skb->nf_bridge is present and the BRNF_NF_BRIDGE_PREROUTING flag is not
set. The flag is only set during the simulated hook.
Because skb->nf_bridge is only freed when the packet is destroyed, the
packet will not only skip the first invocation of NF_IP_PRE_ROUTING, but
in the case of tunnel devices on top of the bridge also all further ones.
Forwarded packets from a bridge encapsulated by a tunnel device and sent
as locally outgoing packet will also still have the incorrect bridge
information from the input path attached.
We already have nf_reset calls on all RX/TX paths of tunnel devices,
so simply reset the nf_bridge field there too. As an added bonus,
the bridge information for locally delivered packets is now also freed
when the packet is queued to a socket.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 5e5c34345f3ead2608e38d75f998dfeb7bb5df1c
tree 17bbdf2d4efc19888ec4fc0fd27c544677bd1949
parent 337ba256a7e68f174a88ffba805b40622297fc22
author Patrick McHardy <kaber@trash.net> Mon, 20 Feb 2006 10:33:14 +0100
committer Patrick McHardy <kaber@trash.net> Mon, 20 Feb 2006 10:33:14 +0100
include/linux/skbuff.h | 24 ++++++++++++++----------
net/ipv4/netfilter/ipt_REJECT.c | 4 ----
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 838ce0f..1a26110 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1351,16 +1351,6 @@ static inline void nf_conntrack_put_reas
kfree_skb(skb);
}
#endif
-static inline void nf_reset(struct sk_buff *skb)
-{
- nf_conntrack_put(skb->nfct);
- skb->nfct = NULL;
-#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
- nf_conntrack_put_reasm(skb->nfct_reasm);
- skb->nfct_reasm = NULL;
-#endif
-}
-
#ifdef CONFIG_BRIDGE_NETFILTER
static inline void nf_bridge_put(struct nf_bridge_info *nf_bridge)
{
@@ -1373,6 +1363,20 @@ static inline void nf_bridge_get(struct
atomic_inc(&nf_bridge->use);
}
#endif /* CONFIG_BRIDGE_NETFILTER */
+static inline void nf_reset(struct sk_buff *skb)
+{
+ nf_conntrack_put(skb->nfct);
+ skb->nfct = NULL;
+#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
+ nf_conntrack_put_reasm(skb->nfct_reasm);
+ skb->nfct_reasm = NULL;
+#endif
+#ifdef CONFIG_BRIDGE_NETFILTER
+ nf_bridge_put(skb->nf_bridge);
+ skb->nf_bridge = NULL;
+#endif
+}
+
#else /* CONFIG_NETFILTER */
static inline void nf_reset(struct sk_buff *skb) {}
#endif /* CONFIG_NETFILTER */
diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.c
index 26ea6c1..9d3b357 100644
--- a/net/ipv4/netfilter/ipt_REJECT.c
+++ b/net/ipv4/netfilter/ipt_REJECT.c
@@ -154,10 +154,6 @@ static void send_reset(struct sk_buff *o
/* This packet will not be the same as the other: clear nf fields */
nf_reset(nskb);
nskb->nfmark = 0;
-#ifdef CONFIG_BRIDGE_NETFILTER
- nf_bridge_put(nskb->nf_bridge);
- nskb->nf_bridge = NULL;
-#endif
tcph = (struct tcphdr *)((u_int32_t*)nskb->nh.iph + nskb->nh.iph->ihl);
^ permalink raw reply related
* Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: David Vrabel @ 2006-02-20 12:16 UTC (permalink / raw)
To: Alessandro Zummo
Cc: Adrian Bunk, Martin Michlmayr, linux-kernel, netdev, John Bowler
In-Reply-To: <20060220030146.11f418dc@inspiron>
Alessandro Zummo wrote:
> On Mon, 20 Feb 2006 02:47:35 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
>
>
>>>Some Ethernet hardware implementations have no built-in storage for
>>>allocated MAC values - an example is the Intel IXP420 chip which has
>>>support for Ethernet but no defined way of storing allocated MAC values.
>>>With such hardware different board level implementations store the
>>>allocated MAC (or MACs) in different ways. Rather than put board level
>>>code
For those not familar with the IXP4xx, the Ethernet drivers are
proprietary and given that there are no other proposed users of this
maclist code there's no need for it in the kernel at this time.
>>Silly question:
>>
>>Why can't this be implemented in user space using the SIOCSIFHWADDR
>>ioctl?
I'm with Adrian on this -- it's a job for userspace. The storage of the
MAC address isn't something that's necessarily board specific anyway but
could depend on which bootloader is used and/or the bootloader version.
> Because sometimes you need to have networking available
> well before userspace.
In the specific case of the IXP4xx, you presumably have some userspace
available because you've just loaded the NPE firmware from it, yes?
David Vrabel
^ permalink raw reply
* Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: Alessandro Zummo @ 2006-02-20 12:57 UTC (permalink / raw)
To: David Vrabel
Cc: Adrian Bunk, Martin Michlmayr, linux-kernel, netdev, John Bowler
In-Reply-To: <43F9B32B.3090203@cantab.net>
On Mon, 20 Feb 2006 12:16:43 +0000
David Vrabel <dvrabel@cantab.net> wrote:
> >>>Some Ethernet hardware implementations have no built-in storage for
> >>>allocated MAC values - an example is the Intel IXP420 chip which has
> >>>support for Ethernet but no defined way of storing allocated MAC values.
> >>>With such hardware different board level implementations store the
> >>>allocated MAC (or MACs) in different ways. Rather than put board level
> >>>code
> For those not familar with the IXP4xx, the Ethernet drivers are
> proprietary and given that there are no other proposed users of this
> maclist code there's no need for it in the kernel at this time.
> >>Why can't this be implemented in user space using the SIOCSIFHWADDR
> >>ioctl?
> I'm with Adrian on this -- it's a job for userspace. The storage of the
> MAC address isn't something that's necessarily board specific anyway but
> could depend on which bootloader is used and/or the bootloader version.
> > Because sometimes you need to have networking available
> > well before userspace.
>
> In the specific case of the IXP4xx, you presumably have some userspace
> available because you've just loaded the NPE firmware from it, yes?
Hi David,
you're certainly right on the ixp4xx, but the are other uses
for this driver which we are working on.. for example,
some Cirrus Logic ARM based chips (ep93xx) have an ethernet device
that could benefit from that.
I'm pretty sure that there are and will be more devices
with such requirements, with either proprietary or
open source drivers. My opinion is that a maclist alike
facility can clean some of the mess in that area.
If we implement such a thing in userspace every distribution
will need to be aware of a specific trick for a specific
board. If we have a clean facility in the kernel, userspace
will not need to care.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
http://www.towertech.it
^ permalink raw reply
* Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: Russell King @ 2006-02-20 13:02 UTC (permalink / raw)
To: Alessandro Zummo
Cc: David Vrabel, Adrian Bunk, Martin Michlmayr, linux-kernel, netdev,
John Bowler
In-Reply-To: <20060220135718.038b675b@inspiron>
On Mon, Feb 20, 2006 at 01:57:18PM +0100, Alessandro Zummo wrote:
> you're certainly right on the ixp4xx, but the are other uses
> for this driver which we are working on.. for example,
> some Cirrus Logic ARM based chips (ep93xx) have an ethernet device
> that could benefit from that.
An alternative solution (suggested in the past) would be to have a
generic kernel command line option such as: mac=<netdev>,<macaddr>
It nicely solves the "no mac address" issue in a lot (if not all)
of the cases.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: Lennert Buytenhek @ 2006-02-20 13:07 UTC (permalink / raw)
To: Alessandro Zummo
Cc: David Vrabel, Adrian Bunk, Martin Michlmayr, linux-kernel, netdev,
John Bowler
In-Reply-To: <20060220135718.038b675b@inspiron>
On Mon, Feb 20, 2006 at 01:57:18PM +0100, Alessandro Zummo wrote:
> you're certainly right on the ixp4xx, but the are other uses
> for this driver which we are working on.. for example,
> some Cirrus Logic ARM based chips (ep93xx) have an ethernet device
> that could benefit from that.
Many platforms have the same problem (esp. embedded ones), but that
doesn't mean that maclist is necessarily the best solution.
The main problem I see with maclist (correct me if I'm wrong) is that
there can be multiple devices in the system that need to get their
MAC address from somewhere, and maclist doesn't make the distinction
which address belongs to what. The main issue I have with it is that
it's too general, and that it's lots of code.
I don't think something as complex as maclist is necessary to solve
the problem. For example, why don't you just have an unsigned char
ixp4xx_mac_addr[6] in the ixp4xx core code, have the ixp4xx board code
fill that in, and have the ixp4xx ethernet driver use that?
Or just pass the MAC along in platform device style. What I did in
drivers/net/ixp2000/ was to have enp2611.c (board-specific code) read
the MAC from the board, and pass it to ixpdev.c (generic code) in the
net_device structure.
cheers,
Lennert
^ permalink raw reply
* Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: jamal @ 2006-02-20 13:15 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: Alessandro Zummo, David Vrabel, Adrian Bunk, Martin Michlmayr,
linux-kernel, netdev, John Bowler
In-Reply-To: <20060220130712.GA24784@xi.wantstofly.org>
On Mon, 2006-20-02 at 14:07 +0100, Lennert Buytenhek wrote:
> On Mon, Feb 20, 2006 at 01:57:18PM +0100, Alessandro Zummo wrote:
>
> Or just pass the MAC along in platform device style. What I did in
> drivers/net/ixp2000/ was to have enp2611.c (board-specific code) read
> the MAC from the board, and pass it to ixpdev.c (generic code) in the
> net_device structure.
>
yep, this is what i have seen done in a lot of embedded boards
containing switching chips (If i am not mistaken there is a 4 port
switch in the IXP4xx)
cheers,
jamal
^ permalink raw reply
* Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: Alessandro Zummo @ 2006-02-20 13:22 UTC (permalink / raw)
To: Russell King
Cc: David Vrabel, Adrian Bunk, Martin Michlmayr, linux-kernel, netdev,
John Bowler
In-Reply-To: <20060220130203.GA22147@flint.arm.linux.org.uk>
On Mon, 20 Feb 2006 13:02:03 +0000
Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > for this driver which we are working on.. for example,
> > some Cirrus Logic ARM based chips (ep93xx) have an ethernet device
> > that could benefit from that.
>
> An alternative solution (suggested in the past) would be to have a
> generic kernel command line option such as: mac=<netdev>,<macaddr>
>
> It nicely solves the "no mac address" issue in a lot (if not all)
> of the cases.
That would help, but it can't easily be implemented when you are
targeting consumer devices like nas, routers et al which already
have been widely deployed.
I know that the solution would be to fix the bootloader, but
Joe Average is a little bit scared of reflashing it.
A maclist-alike system could help to solve that situation.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
http://www.towertech.it
^ permalink raw reply
* Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: Alessandro Zummo @ 2006-02-20 13:28 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: David Vrabel, Adrian Bunk, Martin Michlmayr, linux-kernel, netdev,
John Bowler
In-Reply-To: <20060220130712.GA24784@xi.wantstofly.org>
On Mon, 20 Feb 2006 14:07:12 +0100
Lennert Buytenhek <buytenh@wantstofly.org> wrote:
> > you're certainly right on the ixp4xx, but the are other uses
> > for this driver which we are working on.. for example,
> > some Cirrus Logic ARM based chips (ep93xx) have an ethernet device
> > that could benefit from that.
> Many platforms have the same problem (esp. embedded ones), but that
> doesn't mean that maclist is necessarily the best solution.
of course, that's why I wrote "maclist-alike"
> The main problem I see with maclist (correct me if I'm wrong) is that
> there can be multiple devices in the system that need to get their
> MAC address from somewhere, and maclist doesn't make the distinction
> which address belongs to what. The main issue I have with it is that
> it's too general, and that it's lots of code.
you're right, usually the first device will get the first mac
and so on. it is general because it has been coded to be that way
I think.
> I don't think something as complex as maclist is necessary to solve
> the problem. For example, why don't you just have an unsigned char
> ixp4xx_mac_addr[6] in the ixp4xx core code, have the ixp4xx board code
> fill that in, and have the ixp4xx ethernet driver use that?
>
> Or just pass the MAC along in platform device style. What I did in
> drivers/net/ixp2000/ was to have enp2611.c (board-specific code) read
> the MAC from the board, and pass it to ixpdev.c (generic code) in the
> net_device structure.
that perfectly doable, but maybe having one common interface could
be a cleaner solution. your setup is board -> netdriver
while maclist implements board -> storage -> netdriver.
It is absolutely not a requirement, just a commodity.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
http://www.towertech.it
^ permalink raw reply
* Re: Diff between Linus' and linux-mips git: declance
From: Martin Michlmayr @ 2006-02-20 14:22 UTC (permalink / raw)
To: netdev, linux-mips
In-Reply-To: <20060220001724.GB17967@deprecation.cyrius.com>
Updated patch, please apply.
[PATCH] Remove delta between Linus' and linux-mips git trees in declance
There are three changes between the Linus' and linux-mips git trees
regarding the declaner driver. The first change is certainly correct
(as it is consistent with the rest of the file) and should be applied
to mainline; the other change seems correct too. And the third is
cosmetic.
Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
---
--- a/drivers/net/declance.c 2006-02-03 03:07:02.000000000 +0000
+++ b/drivers/net/declance.c 2006-02-19 23:50:11.000000000 +0000
@@ -704,8 +704,8 @@
return IRQ_HANDLED;
}
-static irqreturn_t
-lance_interrupt(const int irq, void *dev_id, struct pt_regs *regs)
+static irqreturn_t lance_interrupt(const int irq, void *dev_id,
+ struct pt_regs *regs)
{
struct net_device *dev = (struct net_device *) dev_id;
struct lance_private *lp = netdev_priv(dev);
@@ -1255,7 +1255,7 @@
return 0;
err_out_free_dev:
- kfree(dev);
+ free_netdev(dev);
err_out:
return ret;
@@ -1301,6 +1301,7 @@
while (root_lance_dev) {
struct net_device *dev = root_lance_dev;
struct lance_private *lp = netdev_priv(dev);
+
unregister_netdev(dev);
#ifdef CONFIG_TC
if (lp->slot >= 0)
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply
* Re: From: Carlos Martц╜n <carlos@cmartin.tk>
From: Denis Vlasenko @ 2006-02-20 15:30 UTC (permalink / raw)
To: acx100-devel; +Cc: Carlos Martin, netdev
In-Reply-To: <11403021213131-git-send-email-carlos@cmartin.tk>
On Sunday 19 February 2006 00:35, Carlos Martin wrote:
> [PATCH] acxsm: Fix Kconfig option check
>
> This check never actually worked because CONFIG_ACX_{ACX,USB} are
> tristate. With Adrian Bunk's patch to the Kconfig, this works with the
> _BOOL hidden Kconfig options.
> Also update error message adding that this shouldn't happen anymore.
Carlos, I didn't apply Adrian's patch to my tree.
I am not sure we want to support every imaginable .config.
Realistic goal is:
* allnoconfig must compile
* allyesconfig must compile
* allmodconfig must compile
Adrian's patch makes code more obfuscated and it still has one
corner case (when one choice is 'y' and other is 'm')
If you disagree, please explain why do you want Adrian's patch
applied.
--
vda
-------------------------------------------------------
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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply
* RE: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: John Bowler @ 2006-02-20 16:23 UTC (permalink / raw)
To: 'Adrian Bunk'
Cc: 'Martin Michlmayr', 'Alessandro Zummo',
linux-kernel, netdev
In-Reply-To: <20060220023900.GE4971@stusta.de>
From: Adrian Bunk [mailto:bunk@stusta.de]
>Why can't setting MAC addresses be done from initramfs?
The submitted version of this code is actually an old version,
which has some potential locking problems and doesn't document
how to solve the problem of different drivers getting different
MAC ids.
This stuff *should* be done in the board level code, that should
load the MAC (somehow) and then set it into Ethernet driver resources
so that the (necessarily later) init of the Ethernet device can
pick up the correct address.
Unfortunately on some systems this (the use of machine level
resources in the board init code) is not possible because the
ethernet driver is in a module. The *same* driver may be in kernel
on other systems.
This creates a combinatorial problem - dealing with *all* the
possibilities creates an enormous mess. It doesn't matter where
the solution happens - boot loader, initramfs or kernel init - the
combinatorial problem is still there because there must be handling
for every combination which occurs in practice.
The problem is very much one of embedded systems. In such systems
a generic board will have a specific manufacturing implementation
which stores the MAC in an implementation specific way. E.g. a
vendor may drop the EEPROM from the Gateworks GW2348 board (that
EEPROM costs real money!) and put the MAC in somewhere else. Gateworks
doesn't *document* a specific place to put the MAC (though they *do*
put it in the EEPROM). The lack of documentation and the certainty of
variation in particular IHV uses of the board creates the problem.
maclist simply breaks the problem into two pieces:
1) store this MAC in a linked list.
2) read a MAC from a linked list.
It's a classic "Gordian Knot" problem...
I thought a linked list was pretty simple ;-)
The locking in this version of the code is *wrong*, my assumptions
were bogus and I don't think the code will work correctly on SMP
systems.
The latest version of the code includes significantly more
documentation in the header file and makes the whole thing fail
safe. Again this is an embedded system problem - the ethernet
may be the only thing on the system! The newer code returns an
appropriate 'random' MAC if there isn't one available. This makes
debugging into a tractable problem on systems with just the
ethernet.
The implementation is still a linked list, but insertion is locked
and checking is done to deal with the unavailable MAC case. As in
the simple case the advantage is that common code is in just one
place, not replicated across multiple instances of board/driver
code.
John Bowler <jbowler@acm.org>
^ permalink raw reply
* [PATCH 02/02] add mask options to fwmark masking code
From: Michael Richardson @ 2006-02-20 16:26 UTC (permalink / raw)
To: Jamal Hadi Salim, kuznet; +Cc: netdev, netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 3168 bytes --]
[PATCH] This patch introduces a mask to the fwmark test cases in the advanced
routing. This let's one test individual bits of the fwmark to determine
how things should be routed (pick a routing table). This patch retains
compatibility with tests that do not set the mask by assuming a mask
of 0 is equivalent to a mask of 0xffffffff.
Sign-off-by: Michael Richardson <mcr@xelerance.com>
---
include/linux/rtnetlink.h | 1 +
net/ipv4/fib_rules.c | 19 +++++++++++++++++--
2 files changed, 18 insertions(+), 2 deletions(-)
bcdda64a16d4dfda6d95452bbf8541999121831a
diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index 27fd17e..a5b55c2 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -266,6 +266,7 @@ enum rtattr_type_t
};
#define RTA_FWMARK RTA_PROTOINFO
+#define RTA_FWMARK_MASK RTA_CACHEINFO
#define RTA_MAX (__RTA_MAX - 1)
diff --git a/net/ipv4/fib_rules.c b/net/ipv4/fib_rules.c
index de327b3..69eed89 100644
--- a/net/ipv4/fib_rules.c
+++ b/net/ipv4/fib_rules.c
@@ -68,6 +68,7 @@ struct fib_rule
u8 r_tos;
#ifdef CONFIG_IP_ROUTE_FWMARK
u32 r_fwmark;
+ u32 r_fwmark_mask;
#endif
int r_ifindex;
#ifdef CONFIG_NET_CLS_ROUTE
@@ -117,6 +118,7 @@ int inet_rtm_delrule(struct sk_buff *skb
rtm->rtm_tos == r->r_tos &&
#ifdef CONFIG_IP_ROUTE_FWMARK
(!rta[RTA_FWMARK-1] || memcmp(RTA_DATA(rta[RTA_FWMARK-1]), &r->r_fwmark, 4) == 0) &&
+ (!rta[RTA_FWMARK_MASK-1] || memcmp(RTA_DATA(rta[RTA_FWMARK_MASK-1]), &r->r_fwmark_mask, 4) == 0) &&
#endif
(!rtm->rtm_type || rtm->rtm_type == r->r_action) &&
(!rta[RTA_PRIORITY-1] || memcmp(RTA_DATA(rta[RTA_PRIORITY-1]), &r->r_preference, 4) == 0) &&
@@ -202,6 +204,17 @@ int inet_rtm_newrule(struct sk_buff *skb
#ifdef CONFIG_IP_ROUTE_FWMARK
if (rta[RTA_FWMARK-1])
memcpy(&new_r->r_fwmark, RTA_DATA(rta[RTA_FWMARK-1]), 4);
+ if (rta[RTA_FWMARK_MASK-1])
+ memcpy(&new_r->r_fwmark_mask, RTA_DATA(rta[RTA_FWMARK_MASK-1]), 4);
+ /*
+ * if the user doesn't set a mask, then set it to care about
+ * all bits. This retains compatibility. Note it is impossible
+ * to match SOMETHING & 0xMASK == 0, because fwmark==0 means
+ * do not match fwmark at all.
+ */
+ if(new_r->r_fwmark_mask == 0) {
+ new_r->r_fwmark_mask = 0xffffffff;
+ }
#endif
new_r->r_action = rtm->rtm_type;
new_r->r_flags = rtm->rtm_flags;
@@ -298,7 +311,7 @@ FRprintk("Lookup: %u.%u.%u.%u <- %u.%u.%
((daddr^r->r_dst) & r->r_dstmask) ||
(r->r_tos && r->r_tos != flp->fl4_tos) ||
#ifdef CONFIG_IP_ROUTE_FWMARK
- (r->r_fwmark && r->r_fwmark != flp->fl4_fwmark) ||
+ (r->r_fwmark && r->r_fwmark != (flp->fl4_fwmark & r->r_fwmark_mask)) ||
#endif
(r->r_ifindex && r->r_ifindex != flp->iif))
continue;
@@ -382,8 +395,10 @@ static __inline__ int inet_fill_rule(str
rtm->rtm_src_len = r->r_src_len;
rtm->rtm_tos = r->r_tos;
#ifdef CONFIG_IP_ROUTE_FWMARK
- if (r->r_fwmark)
+ if (r->r_fwmark) {
RTA_PUT(skb, RTA_FWMARK, 4, &r->r_fwmark);
+ RTA_PUT(skb, RTA_FWMARK_MASK, 4, &r->r_fwmark_mask);
+ }
#endif
rtm->rtm_table = r->r_table;
rtm->rtm_protocol = 0;
--
[-- Attachment #2: Type: application/pgp-signature, Size: 480 bytes --]
^ permalink raw reply related
* [PATCH] iproute2 -- add fwmarkmask
From: Michael Richardson @ 2006-02-20 16:27 UTC (permalink / raw)
To: shemminger; +Cc: netdev, netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 3676 bytes --]
{see discussion about RTA_FWMARK in other posting}
diff-tree 573e55d29ef2f014218508d01eee678d82c7c9b7 (from cb420780b79a1d6f5db2082bdac0b310dbc5ebcc)
Author: Michael Richardson <mcr@xelerance.com>
Date: Mon Feb 20 10:21:05 2006 -0500
this patch adds a mask operation to the fwmark rule case, permitting
one to test for only certain bits being set in the fwmark.
(cherry picked from 5fb85fa9da78cc3822f929f181c651391e35de73 commit)
diff --git a/ChangeLog b/ChangeLog
index 68d2342..b67b81d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,9 @@
+2006-02-20 Michael Richardson <mcr@xelerance.com>
+
+ * Added fwmarkmask option to ip rule to go with addition to kernel.
+
2006-01-12 Patrick McHardy <kaber@trash.net>
* Handle DCCP in ipxfrm.c to allow using port numbers in the selector.
2006-01-10 Masahide NAKAMURA <nakam@linux-ipv6.org>
diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index ced29f2..7f4a258 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -263,10 +263,13 @@ enum rtattr_type_t
RTA_SESSION,
RTA_MP_ALGO,
__RTA_MAX
};
+#define RTA_FWMARK RTA_PROTOINFO
+#define RTA_FWMARK_MASK RTA_CACHEINFO
+
#define RTA_MAX (__RTA_MAX - 1)
#define RTM_RTA(r) ((struct rtattr*)(((char*)(r)) + NLMSG_ALIGN(sizeof(struct rtmsg))))
#define RTM_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct rtmsg))
diff --git a/ip/iprule.c b/ip/iprule.c
index ccf699f..90ffcce 100644
--- a/ip/iprule.c
+++ b/ip/iprule.c
@@ -33,11 +33,11 @@ extern struct rtnl_handle rth;
static void usage(void) __attribute__((noreturn));
static void usage(void)
{
fprintf(stderr, "Usage: ip rule [ list | add | del | flush ] SELECTOR ACTION\n");
- fprintf(stderr, "SELECTOR := [ from PREFIX ] [ to PREFIX ] [ tos TOS ] [ fwmark FWMARK ]\n");
+ fprintf(stderr, "SELECTOR := [ from PREFIX ] [ to PREFIX ] [ tos TOS ] [ fwmark FWMARK ] [ fwmarkmask MASK ]\n");
fprintf(stderr, " [ dev STRING ] [ pref NUMBER ]\n");
fprintf(stderr, "ACTION := [ table TABLE_ID ]\n");
fprintf(stderr, " [ prohibit | reject | unreachable ]\n");
fprintf(stderr, " [ realms [SRCREALM/]DSTREALM ]\n");
fprintf(stderr, "TABLE_ID := [ local | main | default | NUMBER ]\n");
@@ -119,14 +119,22 @@ static int print_rule(const struct socka
if (r->rtm_tos) {
SPRINT_BUF(b1);
fprintf(fp, "tos %s ", rtnl_dsfield_n2a(r->rtm_tos, b1, sizeof(b1)));
}
- if (tb[RTA_PROTOINFO]) {
- fprintf(fp, "fwmark %#x ", *(__u32*)RTA_DATA(tb[RTA_PROTOINFO]));
+ if (tb[RTA_FWMARK]) {
+ __u32 value = *(__u32*)RTA_DATA(tb[RTA_PROTOINFO]);
+ if (tb[RTA_FWMARK_MASK]) {
+ __u32 mask;
+ mask=*(__u32*)RTA_DATA(tb[RTA_FWMARK_MASK]);
+ fprintf(fp, "fwmark %#x&%#x ", value, mask);
+ } else {
+ fprintf(fp, "fwmark %#x&0xffffffff ", value);
+ }
}
+
if (tb[RTA_IIF]) {
fprintf(fp, "iif %s ", (char*)RTA_DATA(tb[RTA_IIF]));
}
if (r->rtm_table)
@@ -242,11 +250,17 @@ static int iprule_modify(int cmd, int ar
} else if (strcmp(*argv, "fwmark") == 0) {
__u32 fwmark;
NEXT_ARG();
if (get_u32(&fwmark, *argv, 0))
invarg("fwmark value is invalid\n", *argv);
- addattr32(&req.n, sizeof(req), RTA_PROTOINFO, fwmark);
+ addattr32(&req.n, sizeof(req), RTA_FWMARK, fwmark);
+ } else if (strcmp(*argv, "fwmarkmask") == 0) {
+ __u32 fwmarkmask;
+ NEXT_ARG();
+ if (get_u32(&fwmarkmask, *argv, 0))
+ invarg("fwmarkmask value is invalid\n", *argv);
+ addattr32(&req.n, sizeof(req), RTA_FWMARK_MASK, fwmarkmask);
} else if (matches(*argv, "realms") == 0) {
__u32 realm;
NEXT_ARG();
if (get_rt_realms(&realm, *argv))
invarg("invalid realms\n", *argv);
[-- Attachment #2: Type: application/pgp-signature, Size: 480 bytes --]
^ permalink raw reply related
* Re: [PATCH 02/02] add mask options to fwmark masking code
From: Patrick McHardy @ 2006-02-20 16:57 UTC (permalink / raw)
To: Michael Richardson; +Cc: kuznet, netfilter-devel, Jamal Hadi Salim, netdev
In-Reply-To: <23140.1140452813@sandelman.ottawa.on.ca>
Michael Richardson wrote:
> [PATCH] This patch introduces a mask to the fwmark test cases in the advanced
> routing. This let's one test individual bits of the fwmark to determine
> how things should be routed (pick a routing table). This patch retains
> compatibility with tests that do not set the mask by assuming a mask
> of 0 is equivalent to a mask of 0xffffffff.
> bcdda64a16d4dfda6d95452bbf8541999121831a
> diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
> index 27fd17e..a5b55c2 100644
> --- a/include/linux/rtnetlink.h
> +++ b/include/linux/rtnetlink.h
> @@ -266,6 +266,7 @@ enum rtattr_type_t
> };
>
> #define RTA_FWMARK RTA_PROTOINFO
> +#define RTA_FWMARK_MASK RTA_CACHEINFO
Please introduce a new attribute for this instead of overloading
RTA_CACHEINFO.
> diff --git a/net/ipv4/fib_rules.c b/net/ipv4/fib_rules.c
> index de327b3..69eed89 100644
> --- a/net/ipv4/fib_rules.c
> +++ b/net/ipv4/fib_rules.c
> @@ -68,6 +68,7 @@ struct fib_rule
> u8 r_tos;
> #ifdef CONFIG_IP_ROUTE_FWMARK
> u32 r_fwmark;
> + u32 r_fwmark_mask;
Both patches have whitespace issues. You should also change decnet,
which also supports routing by fwmark. Other than that the patch
looks fine, in fact its nearly identical to a patch I wanted to
send soon which does the same :)
^ permalink raw reply
* Re: Diff between Linus' and linux-mips git: declance
From: Maciej W. Rozycki @ 2006-02-20 17:02 UTC (permalink / raw)
To: Martin Michlmayr; +Cc: netdev, linux-mips
In-Reply-To: <20060220142233.GA3743@deprecation.cyrius.com>
On Mon, 20 Feb 2006, Martin Michlmayr wrote:
> Updated patch, please apply.
>
>
> [PATCH] Remove delta between Linus' and linux-mips git trees in declance
>
> There are three changes between the Linus' and linux-mips git trees
> regarding the declaner driver. The first change is certainly correct
> (as it is consistent with the rest of the file) and should be applied
> to mainline; the other change seems correct too. And the third is
> cosmetic.
>
> Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
Acked-by: Maciej W. Rozycki <macro@linux-mips.org>
Maciej
^ permalink raw reply
* Re: [PATCH] iproute2 -- add fwmarkmask
From: Patrick McHardy @ 2006-02-20 17:03 UTC (permalink / raw)
To: Michael Richardson; +Cc: netdev, netfilter-devel, shemminger
In-Reply-To: <23395.1140452828@sandelman.ottawa.on.ca>
Michael Richardson wrote:
> - if (tb[RTA_PROTOINFO]) {
> - fprintf(fp, "fwmark %#x ", *(__u32*)RTA_DATA(tb[RTA_PROTOINFO]));
> + if (tb[RTA_FWMARK]) {
> + __u32 value = *(__u32*)RTA_DATA(tb[RTA_PROTOINFO]);
> + if (tb[RTA_FWMARK_MASK]) {
> + __u32 mask;
> + mask=*(__u32*)RTA_DATA(tb[RTA_FWMARK_MASK]);
> + fprintf(fp, "fwmark %#x&%#x ", value, mask);
The normal way to display masks is with a "/". Also I think it shouldn't
display the default mask to avoid breaking scripts that parse the
output.
> + } else if (strcmp(*argv, "fwmarkmask") == 0) {
> + __u32 fwmarkmask;
> + NEXT_ARG();
> + if (get_u32(&fwmarkmask, *argv, 0))
> + invarg("fwmarkmask value is invalid\n", *argv);
> + addattr32(&req.n, sizeof(req), RTA_FWMARK_MASK, fwmarkmask);
ip should be able to parse its own output, and it would also look nicer
if I could just say "fwmark 0x1/32". fwmarkmask is really an incredible
ugly expression :)
^ permalink raw reply
* RE: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: John Bowler @ 2006-02-20 17:04 UTC (permalink / raw)
To: 'Alessandro Zummo', linux-kernel
Cc: 'David Vrabel', 'Adrian Bunk',
'Martin Michlmayr', netdev, 'Russell King'
In-Reply-To: <20060220142258.7299170c@inspiron>
My latest version of this patch is here:
http://cvs.sourceforge.net/viewcvs.py/nslu/kernel/2.6.15/91-maclist.patch?rev=1.2&only_with_tag=HEAD&view=markup
In "Recommendations" "With the second strategy" should be "With
the first strategy".
(Note that the '2.6.16' directory in that repo contains an old
version - it is, in fact, rev 1.1 from the 2.6.15 directory.)
John Bowler <jbowler@acm.org>
^ permalink raw reply
* Re: [PATCH 02/02] add mask options to fwmark masking code
From: Patrick McHardy @ 2006-02-20 17:16 UTC (permalink / raw)
To: Michael Richardson; +Cc: kuznet, netfilter-devel, Jamal Hadi Salim, netdev
In-Reply-To: <23140.1140452813@sandelman.ottawa.on.ca>
Michael Richardson wrote:
> [PATCH] This patch introduces a mask to the fwmark test cases in the advanced
> routing. This let's one test individual bits of the fwmark to determine
> how things should be routed (pick a routing table). This patch retains
> compatibility with tests that do not set the mask by assuming a mask
> of 0 is equivalent to a mask of 0xffffffff.
One last comment: instead of looking at the value you should check if
the mask attribute is present to decide when to use the compat mask.
^ permalink raw reply
* Re: [NETFILTER]: Fix skb->nf_bridge lifetime issues
From: Bart De Schuymer @ 2006-02-20 17:56 UTC (permalink / raw)
To: Patrick McHardy
Cc: Linux Netdev List, Netfilter Development Mailinglist,
David S. Miller
In-Reply-To: <43F98CEE.1080609@trash.net>
Op ma, 20-02-2006 te 10:33 +0100, schreef Patrick McHardy:
> Patrick McHardy wrote:
> > Bart, can you please have a look at this patch and ACK/NACK it?
> > We have a bugreport in the netfilter bugzilla of broken conntrack
> > with tunnels on top of bridge devices (#448), which should be cured
> > by this patch.
Looks fine to me. Nice work.
cheers,
Bart
^ permalink raw reply
* Re: 2.6.16-rc4 bridge/iptables Oops
From: Patrick McHardy @ 2006-02-20 18:35 UTC (permalink / raw)
To: earny
Cc: Kernel Netdev Mailing List, Netfilter Development Mailinglist,
linux-kernel, David S. Miller
In-Reply-To: <200602201651.50217.list-lkml@net4u.de>
[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]
Ernst Herzberg wrote:
> This machine oopses one to three (or more?) times a day. Occurs since upgrading
> from -rc3 to -rc4 (and adding/reconfiguring raid).
>
> It is reproducable, i have only to wait 10min to a couple of hours:-)
>
> Opps copy/pasted from a serial console, long lines maybe truncated.
> dmesg is from the _previous_ boot/oops....
>
> -------------------------------------------
> Oops: 0000 [#1]
> PREEMPT
> Modules linked in: ebt_log ebt_ip ebtable_filter ebtables nfsd exportfs lockd sunrpc w83627hf hwmon_vid i2c_isa xt_tcpudp xt_state ipt_MASQUERADE iptable_e
> CPU: 0
> EIP: 0060:[<b033fbf3>] Not tainted VLI
> EFLAGS: 00010282 (2.6.16-rc4 #3)
> EIP is at xfrm_lookup+0x1f/0x47d
> eax: 00000000 ebx: b0452bb4 ecx: 00000000 edx: b0452bb4
> esi: b0452c90 edi: d6c9aa58 ebp: 80000000 esp: b0452b08
> ds: 007b es: 007b ss: 0068
> Process vtund (pid: 12035, threadinfo=b0452000 task=ef8cb030)
> Stack: <0>b0452000 d6c9aa58 b0452bc4 00000000 f153b56a b0452b84 d6c9aa58 f1546181
> b03e5d20 00000000 b0452bb4 b0452bb0 b0452b84 b0452b94 f1546511 d804fd24
> d6c9aa58 b0452b94 d6c9aa58 00000000 b0452b84 f15465a6 d6c9aa58 00000000
> Call Trace:
> [<f153b56a>] ip_conntrack_tuple_taken+0x2c/0x3e [ip_conntrack]
> [<f1546181>] ip_nat_used_tuple+0x1f/0x2b [ip_nat]
> [<f1546511>] get_unique_tuple+0xca/0xe6 [ip_nat]
> [<f15465a6>] ip_nat_setup_info+0x79/0x1fd [ip_nat]
> [<b033ac28>] ip_xfrm_me_harder+0x5d/0x14b
> [<f154b882>] ip_nat_out+0xb2/0xde [iptable_nat]
> [<b034d154>] br_dev_queue_push_xmit+0x0/0x12a
This patch should fix it. Please test it and report if it helps.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1309 bytes --]
[NETFILTER]: Fix crash with bridge-netfilter in xfrm_lookup
Bridge-netfilter attaches a fake dst entry without dst->ops to bridged
packets, which makes xfrm_lookup crash. Skip the lookup since IPsec
isn't supposed to work on a pure bridge anyway.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 98a533612cd7cc51482972b84ac9845a46e81bc9
tree 4b509dae626aaff8cd2e6521425d81ca0bcda1d4
parent d64d19d938ca48d1a4470010f8d48ceac28f4317
author Patrick McHardy <kaber@trash.net> Mon, 20 Feb 2006 19:34:57 +0100
committer Patrick McHardy <kaber@trash.net> Mon, 20 Feb 2006 19:34:57 +0100
net/ipv4/netfilter.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/netfilter.c b/net/ipv4/netfilter.c
index ed42cdc..ae1e75d 100644
--- a/net/ipv4/netfilter.c
+++ b/net/ipv4/netfilter.c
@@ -87,6 +87,13 @@ int ip_xfrm_me_harder(struct sk_buff **p
if (IPCB(*pskb)->flags & IPSKB_XFRM_TRANSFORMED)
return 0;
+#ifdef CONFIG_BRIDGE_NETFILTER
+ /* bridge netfilter attaches a fake dst entry without dst->ops to bridged
+ * packets, which makes xfrm_lookup crash. Skip the lookup since IPsec
+ * isn't supposed to work on a pure bridge anyway. */
+ if ((*pskb)->dst->ops == NULL)
+ return 0;
+#endif
if (xfrm_decode_session(*pskb, &fl, AF_INET) < 0)
return -1;
^ permalink raw reply related
* Re: From: Carlos Martц╜n <carlos@cmartin.tk>
From: Carlos Martín @ 2006-02-20 18:56 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: acx100-devel, netdev
In-Reply-To: <200602201730.20908.vda@ilport.com.ua>
On Monday 20 February 2006 16:30, Denis Vlasenko wrote:
> On Sunday 19 February 2006 00:35, Carlos Martin wrote:
> > [PATCH] acxsm: Fix Kconfig option check
> >
> > This check never actually worked because CONFIG_ACX_{ACX,USB} are
> > tristate. With Adrian Bunk's patch to the Kconfig, this works with the
> > _BOOL hidden Kconfig options.
> > Also update error message adding that this shouldn't happen anymore.
>
> Carlos, I didn't apply Adrian's patch to my tree.
>
> I am not sure we want to support every imaginable .config.
> Realistic goal is:
> * allnoconfig must compile
> * allyesconfig must compile
> * allmodconfig must compile
Which doesn't work with your #error condition.
>
> Adrian's patch makes code more obfuscated and it still has one
> corner case (when one choice is 'y' and other is 'm')
>
> If you disagree, please explain why do you want Adrian's patch
> applied.
It at least compiles. Your tree doesn't compile. It always tells me that I
didn't choose either USB or PCI support which is incorrect.
I've just tested this and CONFIG_ACX_{PCI,USB} only get defined if they are
set to Y. If they're set to M, it doesn't, so it spews out the warning.
I don't like Adrian's patch, and I don't think it's the right way to do it,
but it's what we have that works. I'll try to think of something a bit more
elegant meanwhile.
cmn
--
Carlos Martín Nieto | http://www.cmartin.tk
Hobbyist programmer |
-------------------------------------------------------
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://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
^ permalink raw reply
* Re: [PATCH 02/02] add mask options to fwmark masking code
From: Carl-Daniel Hailfinger @ 2006-02-20 19:58 UTC (permalink / raw)
To: Michael Richardson; +Cc: kuznet, netfilter-devel, Jamal Hadi Salim, netdev
In-Reply-To: <23140.1140452813@sandelman.ottawa.on.ca>
Michael Richardson schrieb:
> [PATCH] This patch introduces a mask to the fwmark test cases in the advanced
> routing. This let's one test individual bits of the fwmark to determine
> how things should be routed (pick a routing table). This patch retains
> compatibility with tests that do not set the mask by assuming a mask
> of 0 is equivalent to a mask of 0xffffffff.
Sorry if I misunderstood the intention of your patch, but isn't similar code
already in mainline?
linux-2.6.16-rc3/net/sched/cls_u32.c:146
#ifdef CONFIG_CLS_U32_MARK
if ((skb->nfmark & n->mark.mask) != n->mark.val) {
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
^ 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