* [PATCH] iproute2: act_ipt fix xtables breakage
From: Jamal Hadi Salim @ 2012-12-16 20:41 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Hasan Chowdhury, Jan Engelhardt, Yury Stankevich,
netdev@vger.kernel.org, pablo, netfilter-devel
In-Reply-To: <alpine.LNX.2.01.1212162003340.27614@nerf07.vanv.qr>
[-- Attachment #1: Type: text/plain, Size: 307 bytes --]
Attached.
I am going to send a kernel patch as well.
There is an "intermediate solution" from Hasan which doesnt require
the kernel change. It changes the kernel endpoint to "ipt". I am
conflicted because it is a quick hack while otoh forcing people to
upgrade kernel is a usability issue.
cheers,
jamal
[-- Attachment #2: patch-xt --]
[-- Type: text/plain, Size: 4163 bytes --]
commit ff707eaa1fd51435958ae2afcd09d4b3600160b4
Author: Hasan Chowdhury <shemonc@gmail.com>
Date: Sun Dec 16 14:09:38 2012 -0500
Fixes breakage with xtables API starting with version 1.4.10
Signed-off-by: Hasan Chowdhury <shemonc@gmail.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
diff --git a/tc/m_xt.c b/tc/m_xt.c
index bcc4d75..e1c3f38 100644
--- a/tc/m_xt.c
+++ b/tc/m_xt.c
@@ -118,6 +118,7 @@ static int parse_ipt(struct action_util *a,int *argc_p,
struct xtables_target *m = NULL;
struct ipt_entry fw;
struct rtattr *tail;
+
int c;
int rargc = *argc_p;
char **argv = *argv_p;
@@ -126,6 +127,7 @@ static int parse_ipt(struct action_util *a,int *argc_p,
int size = 0;
int iok = 0, ok = 0;
__u32 hook = 0, index = 0;
+ struct option *opts = NULL;
xtables_init_all(&tcipt_globals, NFPROTO_IPV4);
set_lib_dir();
@@ -158,14 +160,22 @@ static int parse_ipt(struct action_util *a,int *argc_p,
printf(" %s error \n", m->name);
return -1;
}
- tcipt_globals.opts =
- xtables_merge_options(
#if (XTABLES_VERSION_CODE >= 6)
- tcipt_globals.orig_opts,
+ opts = xtables_options_xfrm(tcipt_globals.orig_opts,
+ tcipt_globals.opts,
+ m->x6_options,
+ &m->option_offset);
+#else
+ opts = xtables_merge_options(tcipt_globals.orig_opts,
+ tcipt_globals.opts,
+ m->extra_opts,
+ &m->option_offset);
#endif
- tcipt_globals.opts,
- m->extra_opts,
- &m->option_offset);
+ if (opts == NULL) {
+ fprintf(stderr, " failed to find aditional options for target %s\n\n", optarg);
+ return -1;
+ } else
+ tcipt_globals.opts = opts;
} else {
fprintf(stderr," failed to find target %s\n\n", optarg);
return -1;
@@ -175,17 +185,21 @@ static int parse_ipt(struct action_util *a,int *argc_p,
default:
memset(&fw, 0, sizeof (fw));
- if (m) {
- m->parse(c - m->option_offset, argv, 0,
- &m->tflags, NULL, &m->t);
+#if (XTABLES_VERSION_CODE >= 6)
+ if (m != NULL && m->x6_parse != NULL ) {
+ xtables_option_tpcall(c, argv, 0 , m, NULL);
+#else
+ if (m != NULL && m->parse != NULL ) {
+ m->parse(c - m->option_offset, argv, 0, &m->tflags,
+ NULL, &m->t);
+#endif
} else {
- fprintf(stderr," failed to find target %s\n\n", optarg);
+ fprintf(stderr,"failed to find target %s\n\n", optarg);
return -1;
}
ok++;
break;
-
}
}
@@ -208,8 +222,13 @@ static int parse_ipt(struct action_util *a,int *argc_p,
}
/* check that we passed the correct parameters to the target */
+#if (XTABLES_VERSION_CODE >= 6)
+ if (m)
+ xtables_option_tfcall(m);
+#else
if (m && m->final_check)
m->final_check(m->tflags);
+#endif
{
struct tcmsg *t = NLMSG_DATA(n);
@@ -271,6 +290,7 @@ print_ipt(struct action_util *au,FILE * f, struct rtattr *arg)
{
struct rtattr *tb[TCA_IPT_MAX + 1];
struct xt_entry_target *t = NULL;
+ struct option *opts = NULL;
if (arg == NULL)
return -1;
@@ -309,14 +329,22 @@ print_ipt(struct action_util *au,FILE * f, struct rtattr *arg)
return -1;
}
- tcipt_globals.opts =
- xtables_merge_options(
#if (XTABLES_VERSION_CODE >= 6)
- tcipt_globals.orig_opts,
+ opts = xtables_options_xfrm(tcipt_globals.orig_opts,
+ tcipt_globals.opts,
+ m->x6_options,
+ &m->option_offset);
+#else
+ opts = xtables_merge_options(tcipt_globals.orig_opts,
+ tcipt_globals.opts,
+ m->extra_opts,
+ &m->option_offset);
#endif
- tcipt_globals.opts,
- m->extra_opts,
- &m->option_offset);
+ if (opts == NULL) {
+ fprintf(stderr, " failed to find aditional options for target %s\n\n", optarg);
+ return -1;
+ } else
+ tcipt_globals.opts = opts;
} else {
fprintf(stderr, " failed to find target %s\n\n",
t->u.user.name);
@@ -355,4 +383,3 @@ struct action_util xt_action_util = {
.parse_aopt = parse_ipt,
.print_aopt = print_ipt,
};
-
^ permalink raw reply related
* Re: tc ipt action
From: Jamal Hadi Salim @ 2012-12-16 20:36 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Hasan Chowdhury, Yury Stankevich, netdev@vger.kernel.org, pablo,
netfilter-devel
In-Reply-To: <alpine.LNX.2.01.1212162003340.27614@nerf07.vanv.qr>
On 12-12-16 02:13 PM, Jan Engelhardt wrote:
>
> "xfrm" is one of these pictogram-based abbreviations like "xing" (the
> thing they paint on roads/signs), apparently standing for "trans"form
> and "cross"ing, respectively, though 'x' is ambiguous and open to a lot
> of other interpretations.
Ok, In that case i'll push half of Hasan's patch. I have a kernel change
that works with it.
cheers,
jamal
^ permalink raw reply
* Re: tc ipt action
From: Jamal Hadi Salim @ 2012-12-16 20:35 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Pablo Neira Ayuso, Yury Stankevich, shemonc,
netdev@vger.kernel.org, netfilter-devel
In-Reply-To: <alpine.LNX.2.01.1212161850530.27614@nerf07.vanv.qr>
On 12-12-16 01:59 PM, Jan Engelhardt wrote:
>
>
> A certainly safe bet would be to write, at the top of tc/m_xt.c,
>
> #if XTABLES_VERSION_CODE > 9
> # error Someone call the guy who changed iptables and \
> make him fix it^W^W^W^W say you need help.
> #endif
>
Excellent idea ;->
> The following is a rough, it-compiles, untested never-run, draft of a
> module. The vision here is that userspace only ever sends a chain
> name to the kernel. The git tree/branch for it is
>
> git://git.inai.de/linux xt2-pktsched
>
> commit 42c559c148cbbc22bf2cc29f2ad08bc330891838
>
I'll look at it later - very slow connection at the moment so cloning
will take a while.
cheers,
jamal
^ permalink raw reply
* Re: tc ipt action
From: Jan Engelhardt @ 2012-12-16 19:13 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Hasan Chowdhury, Yury Stankevich, netdev@vger.kernel.org, pablo,
netfilter-devel
In-Reply-To: <50CE1A04.1000405@mojatatu.com>
On Sunday 2012-12-16 19:59, Jamal Hadi Salim wrote:
> Hasan,
>
> I can confirm that xtables_options_xfrm() works.
> Just suspicious of that call, "xfrm" seems too specific to xfrm
> subsystem but generic enough.
Heh, nah.
"xfrm" is one of these pictogram-based abbreviations like "xing" (the
thing they paint on roads/signs), apparently standing for "trans"form
and "cross"ing, respectively, though 'x' is ambiguous and open to a lot
of other interpretations.
^ permalink raw reply
* Re: tc ipt action
From: Jan Engelhardt @ 2012-12-16 18:59 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Pablo Neira Ayuso, Yury Stankevich, shemonc,
netdev@vger.kernel.org, netfilter-devel
In-Reply-To: <50CE0921.7060306@mojatatu.com>
On Sunday 2012-12-16 18:47, Jamal Hadi Salim wrote:
>
>> old parse has not entered any deprecation stage yet, since there are still
>> plugins out there (both the 5 and external ones) that make use of it.
>> Right now, both parse and x6_parse are valid.
>
> True - but we are getting broken because we are using a call that only 5 or so
> users provide. It would have saved us time if we got the
> a good log message instead of checking for if !m->parse()
A certainly safe bet would be to write, at the top of tc/m_xt.c,
#if XTABLES_VERSION_CODE > 9
# error Someone call the guy who changed iptables and \
make him fix it^W^W^W^W say you need help.
#endif
Then I would automatically notify myself of "oh I need fix that too" when I
feed any new releases of {iptables, iproute} through the Open Build Service.
>> Yes, all those with an x6_ prefix are new.
>> Mh, I already dream of plans reducing m_xt to something that
>> does not require libxtables.so anymore.
>
> That would be nice - but someone is going to have to link to libxtables, no?
I hope the complete opposite.
The following is a rough, it-compiles, untested never-run, draft of a
module. The vision here is that userspace only ever sends a chain
name to the kernel. The git tree/branch for it is
git://git.inai.de/linux xt2-pktsched
commit 42c559c148cbbc22bf2cc29f2ad08bc330891838
net_sched: act: new action to call into Xtables2 chains
include/net/netfilter/xt_core.h | 8 ++
include/uapi/linux/tc_act/tc_ipt.h | 2 +
net/netfilter/xt_core.c | 3 +-
net/sched/Kconfig | 9 ++
net/sched/Makefile | 1 +
net/sched/act_xtables.c | 238 ++++++++++++++++++++++++++++++++++++
6 files changed, 260 insertions(+), 1 deletion(-)
^ permalink raw reply
* Re: tc ipt action
From: Jamal Hadi Salim @ 2012-12-16 18:59 UTC (permalink / raw)
To: Hasan Chowdhury
Cc: Jan Engelhardt, Yury Stankevich, netdev@vger.kernel.org, pablo,
netfilter-devel
In-Reply-To: <50CDFB6A.3090806@mojatatu.com>
Hasan,
I can confirm that xtables_options_xfrm() works.
Just suspicious of that call, "xfrm" seems too specific to xfrm
subsystem but generic enough.
Dont bother resending the patch, it works right now, I am just
waiting for confirmation from Pablo/Jan and i will proceed from there.
I am also still struggling with whether to add your intermediate
solution to rename the xt->ipt.
I think i will go ahead and add a kernel change.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] build: unbreak linkage of m_xt.so
From: Jamal Hadi Salim @ 2012-12-16 18:05 UTC (permalink / raw)
To: Jan Engelhardt
Cc: stephen.hemminger, vapier, netdev, urykhy, shemonc, pablo,
netfilter-devel
In-Reply-To: <alpine.LNX.2.01.1212161841070.27614@nerf07.vanv.qr>
On 12-12-16 12:43 PM, Jan Engelhardt wrote:
> On Sunday 2012-12-16 18:03, Jamal Hadi Salim wrote:
>
>
> I saw the same during make, _but_, on running `ldd tc/m_xt.so`, I got a
> libxtables.so entry, so I thought I was fine.
>
Sorry, you are right. Without your patch that doesnt happen. I had
removed the global dlopen while debugging, so it was using the wrong
m_xt.so
So my Ack is back on;->
cheers,
jamal
^ permalink raw reply
* Re: tc ipt action
From: Jamal Hadi Salim @ 2012-12-16 17:47 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Pablo Neira Ayuso, Yury Stankevich, shemonc,
netdev@vger.kernel.org, netfilter-devel
In-Reply-To: <alpine.LNX.2.01.1212161815310.27614@nerf07.vanv.qr>
On 12-12-16 12:21 PM, Jan Engelhardt wrote:
>
>
> As you can see, the old ->parse() that goes back to libxtables.so.0
> still remains. It's just that... only 5 out of 99 plugins still come
> with an old parse function.
>
I see.
So calling m->XXX may not be a wise long term solution.
Hasan's patch has a call to xtables_option_tpcall(), if that is the
right interface I hope that going forward if any of the m->parseXX
changes you will take care of hiding all that stuff.
> old parse has not entered any deprecation stage yet, since there are still
> plugins out there (both the 5 and external ones) that make use of it.
> Right now, both parse and x6_parse are valid.
>
True - but we are getting broken because we are using a call that only 5
or so users provide. It would have saved us time if we got the
a good log message instead of checking for if !m->parse()
> Yes, all those with an x6_ prefix are new.
> Mh, I already dream of plans reducing m_xt to something that
> does not require libxtables.so anymore.
>
That would be nice - but someone is going to have to link to libxtables, no?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] build: unbreak linkage of m_xt.so
From: Jan Engelhardt @ 2012-12-16 17:43 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: stephen.hemminger, vapier, netdev, urykhy, shemonc, pablo,
netfilter-devel
In-Reply-To: <50CDFEFB.2070208@mojatatu.com>
On Sunday 2012-12-16 18:03, Jamal Hadi Salim wrote:
> On 12-12-16 05:30 AM, Jamal Hadi Salim wrote:
>
>> I can confirm it builds fine for me now if i take out the hack I had and
>> use this patch.
>
>
> Sorry, I take what i said back and went back to explicitly adding -l xtables.
> The problem is still the intepretation of tc/Makefile. Here's the compile
> output.
> ----
> gcc -Wall -Wstrict-prototypes -O2 -I../include -DRESOLVE_HOSTNAMES
> -DLIBDIR=\"/usr/lib\" -DCONFDIR=\"/etc/iproute2\" -D_GNU_SOURCE -DCONFIG_GACT
> -DCONFIG_GACT_PROB -DIPT_LIB_DIR=\"/lib/xtables\" -DYY_NO_INPUT
> -Wl,-export-dynamic -shared -fpic -o m_xt.so m_xt.c $(pkg-config xtables
> --cflags --libs)
> ----
I saw the same during make, _but_, on running `ldd tc/m_xt.so`, I got a
libxtables.so entry, so I thought I was fine.
"$() "is something for the shell to expand, not make. See this testcase.
$ make
echo $(pkg-config xtables --cflags --libs)
-I/usr/include/iptables-1.4.16.3 -lxtables
$ cat Makefile
a:
echo $$(pkg-config xtables --cflags --libs)
^ permalink raw reply
* Re: tc ipt action
From: Jan Engelhardt @ 2012-12-16 17:21 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Pablo Neira Ayuso, Yury Stankevich, shemonc,
netdev@vger.kernel.org, netfilter-devel
In-Reply-To: <50CDA5BE.2080800@mojatatu.com>
On Sunday 2012-12-16 11:43, Jamal Hadi Salim wrote:
> On 12-12-15 07:59 PM, Jan Engelhardt wrote:
>>
>
>> For the C level, there is XTABLES_VERSION_CODE.
>>
>> #if XTABLES_VERSION_CODE >= 6
>> if (m != NULL && m->x6_parse != NULL)
>> m->x6_parse(...)
>> #else
>> else if (m != NULL && m->parse != NULL)
>> m->parse(...)
>> ...
>>
>
> I think you are suggesting this to be done in tc. That would make it easier to
> fix.
> IMO, it is easier to keep backward compat if you left the old
> APIs around for a period of time
As you can see, the old ->parse() that goes back to libxtables.so.0
still remains. It's just that... only 5 out of 99 plugins still come
with an old parse function.
[m_xt] -> [libxtables] <- (plugins: libxt_*.so)
> and maybe log a warning that they
> will be deprecated over a period of time (sort of like kernel approach to
> changing APIs).
old parse has not entered any deprecation stage yet, since there are still
plugins out there (both the 5 and external ones) that make use of it.
Right now, both parse and x6_parse are valid.
> BTW: another interface that seems to have changed that we
> need is m->final_check().
Yes, all those with an x6_ prefix are new.
Mh, I already dream of plans reducing m_xt to something that
does not require libxtables.so anymore.
^ permalink raw reply
* Re: [PATCH] ipv6: Fix Makefile offload objects
From: David Miller @ 2012-12-16 17:17 UTC (permalink / raw)
To: simon; +Cc: linux-kernel, netdev, vyasevic
In-Reply-To: <50CDFB36.1020604@simon.arlott.org.uk>
From: Simon Arlott <simon@fire.lp0.eu>
Date: Sun, 16 Dec 2012 16:47:50 +0000
> The following commit breaks IPv6 TCP transmission for me:
> Commit 75fe83c32248d99e6d5fe64155e519b78bb90481
> Author: Vlad Yasevich <vyasevic@redhat.com>
> Date: Fri Nov 16 09:41:21 2012 +0000
> ipv6: Preserve ipv6 functionality needed by NET
>
> This patch fixes the typo "ipv6_offload" which should be
> "ipv6-offload".
>
> I don't know why not including the offload modules should
> break TCP. Disabling all offload options on the NIC didn't
> help. Outgoing pulseaudio traffic kept stalling.
>
> Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Applied, since the fix is so obvious.
I'll let Vlad explain why it has such an unexpected
effect.
Thanks.
^ permalink raw reply
* Re: [PATCH] build: unbreak linkage of m_xt.so
From: Jamal Hadi Salim @ 2012-12-16 17:03 UTC (permalink / raw)
To: Jan Engelhardt
Cc: stephen.hemminger, vapier, netdev, urykhy, shemonc, pablo,
netfilter-devel
In-Reply-To: <50CDA2DA.3060805@mojatatu.com>
On 12-12-16 05:30 AM, Jamal Hadi Salim wrote:
> I can confirm it builds fine for me now if i take out the hack I had and
> use this patch.
Sorry, I take what i said back and went back to explicitly adding -l
xtables. The problem is still the intepretation of tc/Makefile. Here's
the compile output.
----
gcc -Wall -Wstrict-prototypes -O2 -I../include -DRESOLVE_HOSTNAMES
-DLIBDIR=\"/usr/lib\" -DCONFDIR=\"/etc/iproute2\" -D_GNU_SOURCE
-DCONFIG_GACT -DCONFIG_GACT_PROB -DIPT_LIB_DIR=\"/lib/xtables\"
-DYY_NO_INPUT -Wl,-export-dynamic -shared -fpic -o m_xt.so m_xt.c
$(pkg-config xtables --cflags --libs)
----
Note the missing expansion.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] ipv6: Fix Makefile offload objects
From: Simon Arlott @ 2012-12-16 16:52 UTC (permalink / raw)
To: netdev
In-Reply-To: <50CDFB36.1020604@simon.arlott.org.uk>
[-- Attachment #1: Type: text/plain, Size: 612 bytes --]
On 16/12/12 16:47, Simon Arlott wrote:
> The following commit breaks IPv6 TCP transmission for me:
> Commit 75fe83c32248d99e6d5fe64155e519b78bb90481
> Author: Vlad Yasevich <vyasevic@redhat.com>
> Date: Fri Nov 16 09:41:21 2012 +0000
> ipv6: Preserve ipv6 functionality needed by NET
>
> This patch fixes the typo "ipv6_offload" which should be
> "ipv6-offload".
>
> I don't know why not including the offload modules should
> break TCP. Disabling all offload options on the NIC didn't
> help. Outgoing pulseaudio traffic kept stalling.
Attached packet capture (on the affected host).
--
Simon Arlott
[-- Attachment #2: tcpv6-stalls.pcap.bz2 --]
[-- Type: application/x-bzip, Size: 254391 bytes --]
^ permalink raw reply
* Re: tc ipt action
From: Jamal Hadi Salim @ 2012-12-16 16:48 UTC (permalink / raw)
To: Hasan Chowdhury
Cc: Jan Engelhardt, Yury Stankevich, netdev@vger.kernel.org, pablo,
netfilter-devel
In-Reply-To: <CAASe=fQT2pVOK0uctdaKL+aOrF8nYeTMfoF15kmd-rC02+7Vnw@mail.gmail.com>
On 12-12-16 10:17 AM, Hasan Chowdhury wrote:
>
>
> [Hasan**] I thought "xt" is a supported action kind for
> iproute2-3.6.0. Besides with a default compilation it compiled m_xt.c
> (not m_ipt.c ) linked with shared object m_xt.so
>
It is - but my hope is not to change the interface to existing scripts.
One approach is rename "xt" to "ipt" and make the old vs new ways
mutually exclusive based on Config options. But that will add more to
baggage of all sorts of workarounds for 13 versions of iptables changing
interfaces. My goal was to have a staged way to kill the old way but
maintain the same command interface. I was hoping not to change
the kernel but based on your patch, that may be the best place to place
warnings about deprecating APIs (so maybe i will add support for "xt"
and warn about "ipt"). Would you be able to test that kernel patch?
> the workaround exits in the patch for file m_action (see the changes
> there ) as netlink reply from kernel for this tc u32 action xt command
> comes as .kind = "ipt" instead of xt (assumed act_ipt.c in kernle
> is not aware of new xt extensions .)
The most important part of your patch that i missed is you took
care of some of the new API changes Pablo mentioned. I am suspicious of
one of them: why call xtables_options_xfrm(). Pablo/Jan, could you
please look at Hasan's patch in m_xt.c?
Also, your patch doesnt compile for me. Can you please provide a version
against the latest iproute2 git tree?
cheers,
jamal
^ permalink raw reply
* [PATCH] ipv6: Fix Makefile offload objects
From: Simon Arlott @ 2012-12-16 16:47 UTC (permalink / raw)
To: David Miller; +Cc: Linux Kernel Mailing List, netdev, Vlad Yasevich
The following commit breaks IPv6 TCP transmission for me:
Commit 75fe83c32248d99e6d5fe64155e519b78bb90481
Author: Vlad Yasevich <vyasevic@redhat.com>
Date: Fri Nov 16 09:41:21 2012 +0000
ipv6: Preserve ipv6 functionality needed by NET
This patch fixes the typo "ipv6_offload" which should be
"ipv6-offload".
I don't know why not including the offload modules should
break TCP. Disabling all offload options on the NIC didn't
help. Outgoing pulseaudio traffic kept stalling.
Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
---
net/ipv6/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/Makefile b/net/ipv6/Makefile
index 2068ac4..4ea2448 100644
--- a/net/ipv6/Makefile
+++ b/net/ipv6/Makefile
@@ -41,6 +41,6 @@ obj-$(CONFIG_IPV6_TUNNEL) += ip6_tunnel.o
obj-$(CONFIG_IPV6_GRE) += ip6_gre.o
obj-y += addrconf_core.o exthdrs_core.o
-obj-$(CONFIG_INET) += output_core.o protocol.o $(ipv6_offload)
+obj-$(CONFIG_INET) += output_core.o protocol.o $(ipv6-offload)
obj-$(subst m,y,$(CONFIG_IPV6)) += inet6_hashtables.o
--
1.7.8.rc3
--
Simon Arlott
^ permalink raw reply related
* [PATCH 2/2] ssb: SSB_DRIVER_GPIO should depend on GPIOLIB instead of selecting it
From: Geert Uytterhoeven @ 2012-12-16 15:35 UTC (permalink / raw)
To: Hauke Mehrtens, Rafał Miłecki, Michael Buesch
Cc: linux-wireless, netdev, linux-kernel, Geert Uytterhoeven
In-Reply-To: <1355672136-24808-1-git-send-email-geert@linux-m68k.org>
Commit ec43b08b5733494ad88aa618ecdf534320dd8207 ("ssb: add GPIO driver")
added SSB_DRIVER_GPIO, which unconditionally selects GPIOLIB, causing
a Kconfig warning:
warning: (ARCH_REQUIRE_GPIOLIB && SSB_DRIVER_GPIO && BCMA_DRIVER_GPIO && MFD_TC6393XB && FB_VIA) selects GPIOLIB which has unmet direct dependencies (ARCH_WANT_OPTIONAL_GPIOLIB || ARCH_REQUIRE_GPIOLIB)
and build failure for m68k/allmodconfig:
In file included from drivers/ssb/ssb_private.h:5,
from drivers/ssb/main.c:12:
include/linux/ssb/ssb.h:440: error: field ‘gpio’ has incomplete type
make[4]: *** [drivers/ssb/main.o] Error 1
make[3]: *** [drivers/ssb/] Error 2
Turn the select into a dependency to fix this.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/ssb/Kconfig | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/ssb/Kconfig b/drivers/ssb/Kconfig
index ff3c8a2..5d6f2ec 100644
--- a/drivers/ssb/Kconfig
+++ b/drivers/ssb/Kconfig
@@ -162,8 +162,7 @@ config SSB_DRIVER_GIGE
config SSB_DRIVER_GPIO
bool "SSB GPIO driver"
- depends on SSB
- select GPIOLIB
+ depends on SSB && GPIOLIB
help
Driver to provide access to the GPIO pins on the bus.
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] bcma: BCMA_DRIVER_GPIO should depend on GPIOLIB instead of selecting it
From: Geert Uytterhoeven @ 2012-12-16 15:35 UTC (permalink / raw)
To: Hauke Mehrtens, Rafał Miłecki, Michael Buesch
Cc: linux-wireless, netdev, linux-kernel, Geert Uytterhoeven
Commit cf0936b06d8e98a157630e99f647e2ff6d29d7ad ("bcma: add GPIO driver")
added BCMA_DRIVER_GPIO, which unconditionally selects GPIOLIB, causing
a Kconfig warning:
warning: (ARCH_REQUIRE_GPIOLIB && SSB_DRIVER_GPIO && BCMA_DRIVER_GPIO && MFD_TC6393XB && FB_VIA) selects GPIOLIB which has unmet direct dependencies (ARCH_WANT_OPTIONAL_GPIOLIB || ARCH_REQUIRE_GPIOLIB)
and build failure for m68k/allmodconfig:
In file included from include/linux/bcma/bcma.h:8,
from drivers/bcma/bcma_private.h:9,
from drivers/bcma/main.c:9:
include/linux/bcma/bcma_driver_chipcommon.h:582: error: field ‘gpio’ has incomplete type
In file included from include/linux/bcma/bcma.h:12,
from drivers/bcma/bcma_private.h:9,
from drivers/bcma/main.c:9:
include/linux/ssb/ssb.h:440: error: field ‘gpio’ has incomplete type
make[4]: *** [drivers/bcma/main.o] Error 1
make[3]: *** [drivers/bcma/] Error 2
Turn the select into a dependency to fix this.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/bcma/Kconfig | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
index d7b56a8..8b4221c 100644
--- a/drivers/bcma/Kconfig
+++ b/drivers/bcma/Kconfig
@@ -67,8 +67,7 @@ config BCMA_DRIVER_GMAC_CMN
config BCMA_DRIVER_GPIO
bool "BCMA GPIO driver"
- depends on BCMA
- select GPIOLIB
+ depends on BCMA && GPIOLIB
help
Driver to provide access to the GPIO pins of the bcma bus.
--
1.7.0.4
^ permalink raw reply related
* BUG: unable to handle kernel NULL pointer dereference + panic on 3.2.11 (with various networking pointers, on Dell r720xd)
From: Tomasz Chmielewski @ 2012-12-16 12:56 UTC (permalink / raw)
To: linux-kernel, netdev
Hi,
a server running 3.2.11 just crashed with rather lengthy (~3 MB) dump:
http://www.virtall.com/files/temp/3.2.11-panic.txt
Any pointers, info if it was fixed or not, appreciated.
The server is Dell r720xd, 128 GB RAM, plenty of disks and around 1 Gbit/s constant traffic.
# lspci
00:00.0 Host bridge: Intel Corporation Sandy Bridge DMI2 (rev 07)
00:01.0 PCI bridge: Intel Corporation Sandy Bridge IIO PCI Express Root Port 1a (rev 07)
00:01.1 PCI bridge: Intel Corporation Sandy Bridge IIO PCI Express Root Port 1b (rev 07)
00:02.0 PCI bridge: Intel Corporation Sandy Bridge IIO PCI Express Root Port 2a (rev 07)
00:02.2 PCI bridge: Intel Corporation Sandy Bridge IIO PCI Express Root Port 2c (rev 07)
00:03.0 PCI bridge: Intel Corporation Sandy Bridge IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
00:05.0 System peripheral: Intel Corporation Sandy Bridge Address Map, VTd_Misc, System Management (rev 07)
00:05.2 System peripheral: Intel Corporation Sandy Bridge Control Status and Global Errors (rev 07)
00:11.0 PCI bridge: Intel Corporation Patsburg PCI Express Virtual Root Port (rev 05)
00:16.0 Communication controller: Intel Corporation X79 series chipset HECI Controller #2 (rev 05)
00:16.1 Communication controller: Intel Corporation X79 series chipset IDE-r Controller (rev 05)
00:1a.0 USB controller: Intel Corporation X79 series chipset USB2 Enhanced Host Controller #2 (rev 05)
00:1c.0 PCI bridge: Intel Corporation X79 series chipset PCI Express Root Port 1 (rev b5)
00:1c.7 PCI bridge: Intel Corporation X79 series chipset PCI Express Root Port 8 (rev b5)
00:1d.0 USB controller: Intel Corporation X79 series chipset USB2 Enhanced Host Controller #1 (rev 05)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5)
00:1f.0 ISA bridge: Intel Corporation X79 series chipset LPC Controller (rev 05)
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet PCIe
01:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet PCIe
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet PCIe
02:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet PCIe
03:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 2208 [Thunderbolt] (rev 01)
08:00.0 PCI bridge: Renesas Technology Corp. SH7757 PCIe Switch [PS]
09:00.0 PCI bridge: Renesas Technology Corp. SH7757 PCIe Switch [PS]
09:01.0 PCI bridge: Renesas Technology Corp. SH7757 PCIe Switch [PS]
0a:00.0 PCI bridge: Renesas Technology Corp. SH7757 PCIe-PCI Bridge [PPB]
0b:00.0 VGA compatible controller: Matrox Graphics, Inc. G200eR2
3f:08.0 System peripheral: Intel Corporation Sandy Bridge QPI Link 0 (rev 07)
3f:09.0 System peripheral: Intel Corporation Sandy Bridge QPI Link 1 (rev 07)
3f:0a.0 System peripheral: Intel Corporation Sandy Bridge Power Control Unit 0 (rev 07)
3f:0a.1 System peripheral: Intel Corporation Sandy Bridge Power Control Unit 1 (rev 07)
3f:0a.2 System peripheral: Intel Corporation Sandy Bridge Power Control Unit 2 (rev 07)
3f:0a.3 System peripheral: Intel Corporation Sandy Bridge Power Control Unit 3 (rev 07)
3f:0b.0 System peripheral: Intel Corporation Sandy Bridge Interrupt Control Registers (rev 07)
3f:0b.3 System peripheral: Intel Corporation Sandy Bridge Semaphore and Scratchpad Configuration Registers (rev 07)
3f:0c.0 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07)
3f:0c.1 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07)
3f:0c.2 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07)
3f:0c.3 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07)
3f:0c.6 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 0 (rev 07)
3f:0c.7 System peripheral: Intel Corporation Sandy Bridge System Address Decoder (rev 07)
3f:0d.0 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07)
3f:0d.1 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07)
3f:0d.2 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07)
3f:0d.3 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07)
3f:0d.6 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 1 (rev 07)
3f:0e.0 System peripheral: Intel Corporation Sandy Bridge Processor Home Agent (rev 07)
3f:0e.1 Performance counters: Intel Corporation Sandy Bridge Processor Home Agent Performance Monitoring (rev 07)
3f:0f.0 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Registers (rev 07)
3f:0f.1 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller RAS Registers (rev 07)
3f:0f.2 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 0 (rev 07)
3f:0f.3 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 1 (rev 07)
3f:0f.4 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 2 (rev 07)
3f:0f.5 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 3 (rev 07)
3f:0f.6 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 4 (rev 07)
3f:10.0 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
3f:10.1 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
3f:10.2 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 0 (rev 07)
3f:10.3 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 1 (rev 07)
3f:10.4 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
3f:10.5 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
3f:10.6 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 2 (rev 07)
3f:10.7 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 3 (rev 07)
3f:11.0 System peripheral: Intel Corporation Sandy Bridge DDRIO (rev 07)
3f:13.0 System peripheral: Intel Corporation Sandy Bridge R2PCIe (rev 07)
3f:13.1 Performance counters: Intel Corporation Sandy Bridge Ring to PCI Express Performance Monitor (rev 07)
3f:13.4 Performance counters: Intel Corporation Sandy Bridge QuickPath Interconnect Agent Ring Registers (rev 07)
3f:13.5 Performance counters: Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
3f:13.6 System peripheral: Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)
40:01.0 PCI bridge: Intel Corporation Sandy Bridge IIO PCI Express Root Port 1a (rev 07)
40:02.0 PCI bridge: Intel Corporation Sandy Bridge IIO PCI Express Root Port 2a (rev 07)
40:03.0 PCI bridge: Intel Corporation Sandy Bridge IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
40:03.2 PCI bridge: Intel Corporation Sandy Bridge IIO PCI Express Root Port 3c (rev 07)
40:05.0 System peripheral: Intel Corporation Sandy Bridge Address Map, VTd_Misc, System Management (rev 07)
40:05.2 System peripheral: Intel Corporation Sandy Bridge Control Status and Global Errors (rev 07)
7f:08.0 System peripheral: Intel Corporation Sandy Bridge QPI Link 0 (rev 07)
7f:09.0 System peripheral: Intel Corporation Sandy Bridge QPI Link 1 (rev 07)
7f:0a.0 System peripheral: Intel Corporation Sandy Bridge Power Control Unit 0 (rev 07)
7f:0a.1 System peripheral: Intel Corporation Sandy Bridge Power Control Unit 1 (rev 07)
7f:0a.2 System peripheral: Intel Corporation Sandy Bridge Power Control Unit 2 (rev 07)
7f:0a.3 System peripheral: Intel Corporation Sandy Bridge Power Control Unit 3 (rev 07)
7f:0b.0 System peripheral: Intel Corporation Sandy Bridge Interrupt Control Registers (rev 07)
7f:0b.3 System peripheral: Intel Corporation Sandy Bridge Semaphore and Scratchpad Configuration Registers (rev 07)
7f:0c.0 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07)
7f:0c.1 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07)
7f:0c.2 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07)
7f:0c.3 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07)
7f:0c.6 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 0 (rev 07)
7f:0c.7 System peripheral: Intel Corporation Sandy Bridge System Address Decoder (rev 07)
7f:0d.0 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07)
7f:0d.1 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07)
7f:0d.2 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07)
7f:0d.3 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07)
7f:0d.6 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 1 (rev 07)
7f:0e.0 System peripheral: Intel Corporation Sandy Bridge Processor Home Agent (rev 07)
7f:0e.1 Performance counters: Intel Corporation Sandy Bridge Processor Home Agent Performance Monitoring (rev 07)
7f:0f.0 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Registers (rev 07)
7f:0f.1 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller RAS Registers (rev 07)
7f:0f.2 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 0 (rev 07)
7f:0f.3 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 1 (rev 07)
7f:0f.4 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 2 (rev 07)
7f:0f.5 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 3 (rev 07)
7f:0f.6 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 4 (rev 07)
7f:10.0 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
7f:10.1 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
7f:10.2 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 0 (rev 07)
7f:10.3 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 1 (rev 07)
7f:10.4 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
7f:10.5 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
7f:10.6 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 2 (rev 07)
7f:10.7 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 3 (rev 07)
7f:11.0 System peripheral: Intel Corporation Sandy Bridge DDRIO (rev 07)
7f:13.0 System peripheral: Intel Corporation Sandy Bridge R2PCIe (rev 07)
7f:13.1 Performance counters: Intel Corporation Sandy Bridge Ring to PCI Express Performance Monitor (rev 07)
7f:13.4 Performance counters: Intel Corporation Sandy Bridge QuickPath Interconnect Agent Ring Registers (rev 07)
7f:13.5 Performance counters: Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
7f:13.6 System peripheral: Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)
--
Tomasz Chmielewski
^ permalink raw reply
* Re: [patch net-next 0/4] net: allow to change carrier from userspace
From: Jiri Pirko @ 2012-12-16 10:54 UTC (permalink / raw)
To: netdev; +Cc: davem, edumazet, bhutchings, mirqus, shemminger, greearb, fbl
In-Reply-To: <1355309887-1081-1-git-send-email-jiri@resnulli.us>
I see that the patchset is in state "Rejected" in patchwork.
Stephen convinced me for a moment that the problem can be handled by operstate.
As it turned out (in last 3-4 emails in thread) operstate use would not
be an option.
So how should I proceed? Should I repost the patchset? Anyone has any other
comments?
thanks.
Wed, Dec 12, 2012 at 11:58:03AM CET, jiri@resnulli.us wrote:
>This is basically a repost of my previous patchset:
>"[patch net-next-2.6 0/2] net: allow to change carrier via sysfs" from Aug 30
>
>The way net-sysfs stores values changed and this patchset reflects it.
>Also, I exposed carrier via rtnetlink iface.
>
>So far, only dummy driver uses carrier change ndo. In very near future
>team driver will use that as well.
>
>Jiri Pirko (4):
> net: add change_carrier netdev op
> net: allow to change carrier via sysfs
> rtnl: expose carrier value with possibility to set it
> dummy: implement carrier change
>
> drivers/net/dummy.c | 10 ++++++++++
> include/linux/netdevice.h | 7 +++++++
> include/uapi/linux/if_link.h | 1 +
> net/core/dev.c | 19 +++++++++++++++++++
> net/core/net-sysfs.c | 15 ++++++++++++++-
> net/core/rtnetlink.c | 10 ++++++++++
> 6 files changed, 61 insertions(+), 1 deletion(-)
>
>--
>1.8.0
>
^ permalink raw reply
* Re: tc ipt action
From: Jamal Hadi Salim @ 2012-12-16 10:43 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Pablo Neira Ayuso, Yury Stankevich, shemonc,
netdev@vger.kernel.org, netfilter-devel
In-Reply-To: <alpine.LNX.2.01.1212160144110.26218@nerf07.vanv.qr>
On 12-12-15 07:59 PM, Jan Engelhardt wrote:
>
> For the C level, there is XTABLES_VERSION_CODE.
>
> #if XTABLES_VERSION_CODE >= 6
> if (m != NULL && m->x6_parse != NULL)
> m->x6_parse(...)
> #else
> else if (m != NULL && m->parse != NULL)
> m->parse(...)
> ...
>
I think you are suggesting this to be done in tc. That would make it
easier to fix.
IMO, it is easier to keep backward compat if you left the old
APIs around for a period of time and maybe log a warning that they
will be deprecated over a period of time (sort of like kernel approach
to changing APIs).
BTW: another interface that seems to have changed that we
need is m->final_check().
cheers,
jamal
> We can also export this through pkgconfig, similar to how
> downstream users are to discover the plugin dir
> (`pkg-config xtables --variable libdir`).
>
^ permalink raw reply
* Re: [PATCH] build: unbreak linkage of m_xt.so
From: Jamal Hadi Salim @ 2012-12-16 10:30 UTC (permalink / raw)
To: Jan Engelhardt
Cc: stephen.hemminger, vapier, netdev, urykhy, shemonc, pablo,
netfilter-devel
In-Reply-To: <1355617968-26138-1-git-send-email-jengelh@inai.de>
On 12-12-15 07:32 PM, Jan Engelhardt wrote:
> Commit v3.7.0~10 caused the variable new PKG_CONFIG variable never
> to be present at the time of calling make, leading to tc/m_xt.so
> not linked with -lxtables (result from pkg-config xtables --libs),
> that in turn leading to
>
> tc: symbol lookup error: /usr/lib64/tc//m_xt.so: undefined symbol:
> xtables_init_all
>
Yep - run into this problem, scratching my head thinking something
wrong with my environment with latest iproute2 git tree. I hacked
mine to just always include xtables in LDLIBS.
> Fixing that.
>
> Signed-off-by: Jan Engelhardt <jengelh@inai.de>
I can confirm it builds fine for me now if i take out the hack I had and
use this patch.
Acked-by: Jamal Hadi Salim <hadi@mojatatu.com>
Stephen, I think this patch would be equivalent of "stable fix".
cheers,
jamal
^ permalink raw reply
* Re: tc ipt action
From: Jamal Hadi Salim @ 2012-12-16 10:26 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Yury Stankevich, shemonc, netdev@vger.kernel.org, netfilter-devel
In-Reply-To: <20121216002755.GA11773@1984>
Hi Pablo,
On 12-12-15 07:27 PM, Pablo Neira Ayuso wrote:
> The binary interface was broken in 1.4.11 with the guided option
> parser:
Ah. Thanks that would explain it.
> You need a patch to use the new interface to stay in sync with current
> iptables libraries. I'll make it for tc and send it to you.
>
Much thanks. I just scanned it and things have changed; old way used to
take multiparams. New one a single struct, so would have taken much
longer for me to resolve.
> BTW, I think it would be good if we find the way to check for
> libxtables current version (see iptables/configure.ac), so you can
> know that we broke binary compatibility again.
>
will do.
cheers,
jamal
^ permalink raw reply
* Re: tc ipt action
From: Jamal Hadi Salim @ 2012-12-16 10:22 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Yury Stankevich, shemonc, netdev@vger.kernel.org, pablo,
netfilter-devel
In-Reply-To: <alpine.LNX.2.01.1212160002330.4901@nerf07.vanv.qr>
On 12-12-15 06:06 PM, Jan Engelhardt wrote:
> If I try that command (substituting ipt->xt and eth0->dummy0,
> ifb0->dummy1), all I get is the dreaded "Invalid argument".
> So the kernel rejected the command, which could indicate that
> userspace construction might have been ok.
>
> # tc filter add dev dummy0 parent ffff: protocol ip u32 match u32 0 0 \
> action xt -j CONNMARK action mirred egress redirect dev dummy1
>
> tablename: mangle hook: NF_IP_PRE_ROUTING
> target: CONNMARK and 0x0 index 0
> RTNETLINK answers: Invalid argument
> We have an error talking to the kernel
>
No problem sending it to the kernel here on ubuntu 12.04.
I also upgraded to current linus git tree, same result.
The problem is the parameters are not accepted in user space as
you can see for connmark and what gets sent (eg CONNMARK and 0x0)
doesnt seem sensible.
> What was the last combination that worked?
First time this got reported to me (or i got CCed on the problem) - I am
told it broke after iptables 1.4.11.
cheers,
jamal
^ permalink raw reply
* [PATCH] netlink: validate addr_len on bind
From: Hannes Frederic Sowa @ 2012-12-16 1:42 UTC (permalink / raw)
To: netdev
Otherwise an out of bounds read could happen.
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/netlink/af_netlink.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index fdb7494..5321bab 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -669,6 +669,9 @@ static int netlink_bind(struct socket *sock, struct sockaddr *addr,
struct sockaddr_nl *nladdr = (struct sockaddr_nl *)addr;
int err;
+ if (addr_len < sizeof(struct sockaddr_nl))
+ return -EINVAL;
+
if (nladdr->nl_family != AF_NETLINK)
return -EINVAL;
^ permalink raw reply related
* Re: [PATCH net] sctp: jsctp_sf_eat_sack: fix jprobes function signature mismatch
From: David Miller @ 2012-12-16 1:17 UTC (permalink / raw)
To: dborkman; +Cc: vyasevich, netdev
In-Reply-To: <a910a63d58d95aed8caeea8a43a21cab863b3bfb.1355602097.git.dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Sat, 15 Dec 2012 21:12:43 +0100
> Commit 24cb81a6a (sctp: Push struct net down into all of the
> state machine functions) introduced the net structure into all
> state machine functions, but jsctp_sf_eat_sack was not updated,
> hence when SCTP association probing is enabled in the kernel,
> any simple SCTP client/server program from userspace will panic
> the kernel.
>
> Cc: Vlad Yasevich <vyasevich@gmail.com>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Applied.
^ 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