* 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
* [2.6 patch] make UNIX a bool
From: Adrian Bunk @ 2006-02-20 22:36 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Christoph Hellwig, Dipankar Sarma, Andrew Morton, linux-kernel,
paulmck, dada1, davem, netdev
In-Reply-To: <1140265890.4035.17.camel@laptopd505.fenrus.org>
On Sat, Feb 18, 2006 at 01:31:30PM +0100, Arjan van de Ven wrote:
> On Sat, 2006-02-18 at 12:14 +0000, Christoph Hellwig wrote:
> > > > - Make the get_max_files export use _GPL - only unix.ko uses it.
> >
> > The real question is, does af_unix really need to allow beeing built
> > modular? It's quite different from other network protocol and deeply
> > tied to the kernel due to things like descriptor passing or using
> > the filesystem namespace. I already had to export another symbol that
> > really should be internal just for it, and if one module acquires lots
> > of such hacks it's usually a bad sign..
>
> in 2.4 the answer would have been simple; modutils back then used
> AF_UNIX stuff before it could load modules, so modular was in practice
> impossible.
>
> Anyway I'd agree with making this non-modular... NOBODY will use this as
> a module, or if they do loading it somehow is the very first thing done.
> You just can't live without this, so making it a module is non-sensical.
So let's send a patch. ;-)
cu
Adrian
<-- snip -->
CONFIG_UNIX=m doesn't make much sense.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.16-rc4-mm1-full/net/unix/Kconfig.old 2006-02-20 14:40:19.000000000 +0100
+++ linux-2.6.16-rc4-mm1-full/net/unix/Kconfig 2006-02-20 14:40:27.000000000 +0100
@@ -3,7 +3,7 @@
#
config UNIX
- tristate "Unix domain sockets"
+ bool "Unix domain sockets"
---help---
If you say Y here, you will include support for Unix domain sockets;
sockets are the standard Unix mechanism for establishing and
^ permalink raw reply
* Re: 2.6.16-rc4 bridge/iptables Oops
From: Ernst Herzberg @ 2006-02-21 1:11 UTC (permalink / raw)
To: linux-kernel
Cc: Patrick McHardy, David S. Miller, Kernel Netdev Mailing List,
Netfilter Development Mailinglist
In-Reply-To: <43FA0C02.8000909@trash.net>
On Monday 20 February 2006 19:35, Patrick McHardy wrote:
> 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
> This patch should fix it. Please test it and report if it helps.
oernie:~ # uname -a ; uptime
Linux oernie 2.6.16-rc4 #1 PREEMPT Mon Feb 20 22:07:34 CET 2006 i686 Intel(R)
Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux
02:06:00 up 3:53, 4 users, load average: 0.08, 0.15, 0.10
No oops so far. Serial console still connected, will report if this or a
similar problem occurs again.
Thanks!
<earn/>
^ permalink raw reply
* Re: 2.6.16-rc4 bridge/iptables Oops
From: Patrick McHardy @ 2006-02-21 3:08 UTC (permalink / raw)
To: Ernst Herzberg
Cc: Kernel Netdev Mailing List, Netfilter Development Mailinglist,
linux-kernel, David S. Miller
In-Reply-To: <200602210211.22364.earny@net4u.de>
[-- Attachment #1: Type: text/plain, Size: 634 bytes --]
Ernst Herzberg wrote:
>>This patch should fix it. Please test it and report if it helps.
>
>
> oernie:~ # uname -a ; uptime
> Linux oernie 2.6.16-rc4 #1 PREEMPT Mon Feb 20 22:07:34 CET 2006 i686 Intel(R)
> Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux
> 02:06:00 up 3:53, 4 users, load average: 0.08, 0.15, 0.10
>
> No oops so far. Serial console still connected, will report if this or a
> similar problem occurs again.
Thanks for testing. Dave, please take this patch instead, it avoids
having to guess whether a packet originates from bridging in IP
netfilter by using DST_NOXFRM for bridge-netfilter's fake dst_entry.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 2136 bytes --]
[NETFILTER]: Fix bridge netfilter related in xfrm_lookup
The bridge-netfilter code attaches a fake dst_entry with dst->ops == NULL
to purely bridged packets. When these packets are SNATed and a policy
lookup is done, xfrm_lookup crashes because it tries to dereference
dst->ops.
Change xfrm_lookup not to dereference dst->ops before checking for the
DST_NOXFRM flag and set this flag in the fake dst_entry.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 6f149cebfdad51205b405058496a501a550dfdb4
tree f87624178d8e9e8b255080f20a5b91a5c25d45e9
parent a8372f035aa2f6717123eb30679a08b619321dd4
author Patrick McHardy <kaber@trash.net> Tue, 21 Feb 2006 04:03:16 +0100
committer Patrick McHardy <kaber@trash.net> Tue, 21 Feb 2006 04:03:16 +0100
net/bridge/br_netfilter.c | 1 +
net/xfrm/xfrm_policy.c | 7 ++++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 6bb0c7e..e060aad 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -90,6 +90,7 @@ static struct rtable __fake_rtable = {
.dev = &__fake_net_device,
.path = &__fake_rtable.u.dst,
.metrics = {[RTAX_MTU - 1] = 1500},
+ .flags = DST_NOXFRM,
}
},
.rt_flags = 0,
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 5e6b05a..8206025 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -782,7 +782,7 @@ int xfrm_lookup(struct dst_entry **dst_p
int nx = 0;
int err;
u32 genid;
- u16 family = dst_orig->ops->family;
+ u16 family;
u8 dir = policy_to_flow_dir(XFRM_POLICY_OUT);
u32 sk_sid = security_sk_sid(sk, fl, dir);
restart:
@@ -796,13 +796,14 @@ restart:
if ((dst_orig->flags & DST_NOXFRM) || !xfrm_policy_list[XFRM_POLICY_OUT])
return 0;
- policy = flow_cache_lookup(fl, sk_sid, family, dir,
- xfrm_policy_lookup);
+ policy = flow_cache_lookup(fl, sk_sid, dst_orig->ops->family,
+ dir, xfrm_policy_lookup);
}
if (!policy)
return 0;
+ family = dst_orig->ops->family;
policy->curlft.use_time = (unsigned long)xtime.tv_sec;
switch (policy->action) {
^ permalink raw reply related
* Re: Re: [PATCH RESEND] net: Move destructor from neigh->ops to neigh_params
From: Roland Dreier @ 2006-02-21 3:42 UTC (permalink / raw)
To: davem
Cc: YOSHIFUJI Hideaki / 吉藤英明, netdev,
openib-general
In-Reply-To: <20060202.103448.118065476.yoshfuji@linux-ipv6.org>
Hi Dave, have you had a chance to look at this? I can resend again if
you've lost the original mail. Also, let me know if you want me to
merge this through my tree when 2.6.17 opens up.
The only feedback I've seen is that Yoshfuji-san has said that this
looks sane.
Thanks,
Roland
^ permalink raw reply
* Re: Re: [PATCH RESEND] net: Move destructor from neigh->ops to neigh_params
From: David S. Miller @ 2006-02-21 4:01 UTC (permalink / raw)
To: rdreier; +Cc: yoshfuji, netdev, openib-general
In-Reply-To: <adalkw55qdq.fsf@cisco.com>
From: Roland Dreier <rdreier@cisco.com>
Date: Mon, 20 Feb 2006 19:42:41 -0800
> Hi Dave, have you had a chance to look at this?
Not yet, it's very low on the priority list at the moment,
but I do still have it in my inbox so don't worry.
^ permalink raw reply
* Re: 2.6.16-rc4 bridge/iptables Oops
From: David S. Miller @ 2006-02-21 4:07 UTC (permalink / raw)
To: kaber; +Cc: earny, linux-kernel, netdev, netfilter-devel
In-Reply-To: <43FA8439.6080009@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 21 Feb 2006 04:08:41 +0100
> Thanks for testing. Dave, please take this patch instead, it avoids
> having to guess whether a packet originates from bridging in IP
> netfilter by using DST_NOXFRM for bridge-netfilter's fake dst_entry.
Applied, thanks Patrick.
^ permalink raw reply
* Re: [NETFILTER]: Fix skb->nf_bridge lifetime issues
From: David S. Miller @ 2006-02-21 4:09 UTC (permalink / raw)
To: kaber; +Cc: netdev, netfilter-devel, bdschuym
In-Reply-To: <43F98CEE.1080609@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Mon, 20 Feb 2006 10:33:34 +0100
> This time compile tested and s/nfct/nf_bridge/ above.
Want me to push this into net-2.6 now that Bart has ACK'd it?
Thanks.
^ permalink raw reply
* Re: [NETFILTER]: Fix skb->nf_bridge lifetime issues
From: Patrick McHardy @ 2006-02-21 4:17 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, netfilter-devel, bdschuym
In-Reply-To: <20060220.200943.51907116.davem@davemloft.net>
David S. Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Mon, 20 Feb 2006 10:33:34 +0100
>
>
>>This time compile tested and s/nfct/nf_bridge/ above.
>
>
> Want me to push this into net-2.6 now that Bart has ACK'd it?
I think net-2.6.17 is better, the bridging stuff is really to
fragile for this to be sure it won't break anything and this
has never worked so far.
^ permalink raw reply
* Re: [NETFILTER]: Fix skb->nf_bridge lifetime issues
From: David S. Miller @ 2006-02-21 4:21 UTC (permalink / raw)
To: kaber; +Cc: netdev, netfilter-devel, bdschuym
In-Reply-To: <43FA9440.6070103@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 21 Feb 2006 05:17:04 +0100
> I think net-2.6.17 is better, the bridging stuff is really to
> fragile for this to be sure it won't break anything and this
> has never worked so far.
Ok, done.
^ 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