* Re: [PATCH net] sctp: jsctp_sf_eat_sack: fix jprobes function signature mismatch
From: Vlad Yasevich @ 2012-12-15 20:39 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: David Miller, netdev
In-Reply-To: <a910a63d58d95aed8caeea8a43a21cab863b3bfb.1355602097.git.dborkman@redhat.com>
On 12/15/2012 03:12 PM, Daniel Borkmann wrote:
> 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.
Aha!!! That makes a lot more sense...
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Thanks
-vlad
>
> Cc: Vlad Yasevich <vyasevich@gmail.com>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> ---
> net/sctp/probe.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/sctp/probe.c b/net/sctp/probe.c
> index bc6cd75..5f7518d 100644
> --- a/net/sctp/probe.c
> +++ b/net/sctp/probe.c
> @@ -122,7 +122,8 @@ static const struct file_operations sctpprobe_fops = {
> .llseek = noop_llseek,
> };
>
> -sctp_disposition_t jsctp_sf_eat_sack(const struct sctp_endpoint *ep,
> +sctp_disposition_t jsctp_sf_eat_sack(struct net *net,
> + const struct sctp_endpoint *ep,
> const struct sctp_association *asoc,
> const sctp_subtype_t type,
> void *arg,
>
^ permalink raw reply
* Re: [PATCH 00/11] Add basic VLAN support to bridges
From: Vlad Yasevich @ 2012-12-15 20:52 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Stephen Hemminger, David Miller, or.gerlitz, netdev, mst,
john.r.fastabend
In-Reply-To: <50CBA15D.6010805@mojatatu.com>
On 12/14/2012 04:59 PM, Jamal Hadi Salim wrote:
> On 12-12-14 11:50 AM, Vlad Yasevich wrote:
>>
>> Interesting. But, but how complex would be be to configure a vlan
>> filter for say 10 different vlans,
>
> Shouldnt be hard. At the simple level you need one rule per VLAN.
> I am assuming only one vm per vlan and that you can key on something
> in the header.
>
>> each one of them only permitted
>> to be forwarded to their respective VM.
>
> Again assuming something in the header is going to say "this packet
> is allowed to go to this VM", a MAC address, an IP src/destination
> etc, correct?
The VLAN id in this case is what should decide where the packet is going.
>
> Oh, and Vlan tags should
>> be stripped when they are being forwarded.
>
> Assuming they are not already stripped at vnetx,
> you could write a very simple action (probably one page of code) to
> strip vlans and do everything at br0;
> Your filter finds them at br0, your action strips them and pipes to
> another action that redirects to the correct device. i.e in unix speak:
> filter at br0 for VMx | strip vlan tag | redirect to vnetx
So you would completely bypass the bridge? Not sure how much I like
that since what would happen if 2 VMs are to share VLAN. In such a
case, broadcasts/multicasts only should only get forwarded to both of
these VMs.
I guess we could add the filters on the vnetx interfaces (which are just
taps). Then its 2 filters per vlan (1 ingress 1 egress). Need to think
about this a bit.
Thanks
-vlad
>
> At the very minimal you need to identify those packets and that depends
> where you want to deploy the policy.
> If you deploy at the br device, you will see the raw packet i.e the vlan
> header wont be stripped.
> i.e youd have to enter some u32 rule with protocol "protocol 802.1q"
> If you deploy at each vnetx device assuming it is a vlan device, you
> wont see the vlan headers and you'll have to key on something else on
> the header "protocol ip"
>
> cheers,
> jamal
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] sctp: jsctp_sf_eat_sack: fix jprobes function signature mismatch
From: Daniel Borkmann @ 2012-12-15 21:02 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: David Miller, netdev
In-Reply-To: <50CCE017.2050407@gmail.com>
On Sat, Dec 15, 2012 at 9:39 PM, Vlad Yasevich <vyasevich@gmail.com> wrote:
> On 12/15/2012 03:12 PM, Daniel Borkmann wrote:
>>
>> 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.
>
>
> Aha!!! That makes a lot more sense...
Indeed. ;-)
> Acked-by: Vlad Yasevich <vyasevich@gmail.com>
>
> Thanks
^ permalink raw reply
* Re: [PATCH 00/11] Add basic VLAN support to bridges
From: Jamal Hadi Salim @ 2012-12-15 21:04 UTC (permalink / raw)
To: vyasevic
Cc: Stephen Hemminger, David Miller, or.gerlitz, netdev, mst,
john.r.fastabend
In-Reply-To: <50CCE2F2.6040503@redhat.com>
sigh. Sorry Vlad - I should have made it clear that the feature
you added IS the way to go. i.e a needed missing piece with or without
VMs. I thought that part of the discussion was done and we were talking
about other things you'd like ON TOP ;->
Example to rate limit or protect the VM from other things.
Totally misunderstood you.
cheers,
jamal
^ permalink raw reply
* Re: tc ipt action
From: Jamal Hadi Salim @ 2012-12-15 21:19 UTC (permalink / raw)
To: Yury Stankevich, shemonc; +Cc: netdev@vger.kernel.org, pablo, netfilter-devel
In-Reply-To: <50C9B4BB.9060609@mojatatu.com>
Yury,
I took a brief look and run some quick tests on ubuntu 12.04. I am going
to be lazy and try and involve the netfilter folks.
It seems that if you left out the args to CONNMARK (includes other
targets like MARK etc) you will succeed - but you get default values.
Example, the following should work for
tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
action ipt -j CONNMARK \
action mirred egress redirect dev ifb0
Here is what the output looks like when you dont pass the parameters.
-------
j@ubuntu:~$ sudo tc filter show dev eth0 parent ffff:
filter protocol ip pref 1 u32
filter protocol ip pref 1 u32 fh 800: ht divisor 1
filter protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
flowid 1:15
match 0a000015/ffffffff at 12
action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING
target MARK and 0xffffffff
index 2 ref 1 bind 1
filter protocol ip pref 49149 u32
filter protocol ip pref 49149 u32 fh 804: ht divisor 1
filter protocol ip pref 49149 u32 fh 804::800 order 2048 key ht 804 bkt
0 flowid 1:12
match 00000000/00000000 at 0
action order 33: tablename: mangle hook: NF_IP_PRE_ROUTING
target CONNMARK and 0x0
index 123 ref 1 bind 1
----------------
Pablo, Hasan Chowdhury tells me this broke after iptable 1.4.10
Hasan also sent me a small patch to fake "xt" instead of "ipt" - but i
think there's more than meets the eye here; some interface we are using
to talk to xtables on user space seems to have changed.
cheers,
jamal
On 12-12-13 05:58 AM, Jamal Hadi Salim wrote:
> Yury,
>
> This appears to be an ABI breakage on iptables/netfilter side.
> I will look at it (and hopefully fix it) over the weekend.
>
> cheers,
> jamal
>
> On 12-12-09 07:20 AM, Yury Stankevich wrote:
>> Hello,
>>
>> i not sure this is correct list, please advise if not.
>>
>> i'm trying to use ipt action, and got a problem:
>>
>> #tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
>> action ipt -j CONNMARK --restore-mark action mirred egress redirect
>> dev ifb0
>> -> bad action type ipt
>>
>> from strace:
>> open("/usr/lib/tc//m_gact.so", O_RDONLY) = -1 ENOENT (No such file or
>> directory)
>> write(2, "bad action type ipt\n", 20bad action type ipt
>>
>> well. i'm trying to use xt:
>> #tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
>> action xt -j CONNMARK --restore-mark action mirred egress redirect dev
>> ifb0
>> xt: unrecognized option '--restore-mark'
>>
>> from strace:
>> open("/lib/xtables/libxt_CONNMARK.so", O_RDONLY) = 4
>> read(4,
>> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\6\0\0004\0\0\0"...,
>> 512) = 512
>> fstat64(4, {st_mode=S_IFREG|0644, st_size=9756, ...}) = 0
>> mmap2(NULL, 12548, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0)
>> = 0xf76f3000
>> mmap2(0xf76f5000, 8192, PROT_READ|PROT_WRITE,
>> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1) = 0xf76f5000
>> close(4) = 0
>> mprotect(0xf76f5000, 4096, PROT_READ) = 0
>> socket(PF_INET, SOCK_RAW, IPPROTO_RAW) = 4
>> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
>> lstat64("/proc/net/ip_tables_names", {st_mode=S_IFREG|0440, st_size=0,
>> ...}) = 0
>> statfs64("/proc/net/ip_tables_names", 84, {f_type="PROC_SUPER_MAGIC",
>> f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0,
>> f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
>> getsockopt(4, SOL_IP, 0x43 /* IP_??? */,
>> "CONNMARK\0\367\f\300\0\0\0po\367l8p\367\364/p\367:}\302\1", [30]) = 0
>> close(4) = 0
>> write(2, "xt: unrecognized option '--resto"..., 41xt: unrecognized
>> option '--restore-mark'
>>
>> so... i make something wrong or this is a bug ?
>>
>> ps: 3.6.8 kernel 64 bit kernel with 32 bit userspace, iproute 20121001
>> from debian-experimental,
>> module act_ipt is loaded.
>> pps: please, cc me in reply.
>>
>>
>
^ permalink raw reply
* Re: tc ipt action
From: Jan Engelhardt @ 2012-12-15 23:06 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Yury Stankevich, shemonc, netdev@vger.kernel.org, pablo,
netfilter-devel
In-Reply-To: <50CCE961.5050204@mojatatu.com>
On Saturday 2012-12-15 22:19, Jamal Hadi Salim wrote:
>
> Example, the following should work for
> tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
> action ipt -j CONNMARK \
> action mirred egress redirect dev ifb0
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
> Pablo, Hasan Chowdhury tells me this broke after iptable 1.4.10
> Hasan also sent me a small patch to fake "xt" instead of "ipt" - but i think
> there's more than meets the eye here; some interface we are using to talk to
> xtables on user space seems to have changed.
What was the last combination that worked?
^ permalink raw reply
* Re: tc ipt action
From: Jan Engelhardt @ 2012-12-16 0:26 UTC (permalink / raw)
To: vapier
Cc: Jamal Hadi Salim, Yury Stankevich, shemonc,
netdev@vger.kernel.org, Pablo Neira Ayuso,
Netfilter Developer Mailing List
In-Reply-To: <alpine.LNX.2.01.1212160002330.4901@nerf07.vanv.qr>
On Sunday 2012-12-16 00:06, Jan Engelhardt wrote:
>On Saturday 2012-12-15 22:19, Jamal Hadi Salim wrote:
>>
>> Example, the following should work for
>> tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
>> action ipt -j CONNMARK \
>> action mirred egress redirect dev ifb0
>
>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
>
>> Pablo, Hasan Chowdhury tells me this broke after iptable 1.4.10
>> Hasan also sent me a small patch to fake "xt" instead of "ipt" - but i think
>> there's more than meets the eye here; some interface we are using to talk to
>> xtables on user space seems to have changed.
>
>What was the last combination that worked?
For added fun, it works even less in iproute2-3.7.0.
commit e4fc4ada3317ea94452576add25981279d705b14
Author: Mike Frysinger <vapier@gentoo.org>
Date: Thu Nov 8 11:41:17 2012 -0500
allow pkg-config to be customized
Rather than hard coding `pkg-config`, use ${PKG_CONFIG} so people can
override it to their specific version (like when cross-compiling).
This is the same way the upstream pkg-config code works.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
broke it by causing tc/m_xt.so to no longer link against libxtables.so,
leading to:
# tc [above parameters]
tc: symbol lookup error: /usr/lib64/tc//m_xt.so: undefined symbol:
xtables_init_all
(Makefiles being simpler than $other_buildsys? A distant reality!)
^ permalink raw reply
* Re: tc ipt action
From: Pablo Neira Ayuso @ 2012-12-16 0:27 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Yury Stankevich, shemonc, netdev@vger.kernel.org, netfilter-devel
In-Reply-To: <50CCE961.5050204@mojatatu.com>
Hi Jamal!
On Sat, Dec 15, 2012 at 04:19:29PM -0500, Jamal Hadi Salim wrote:
> Yury,
>
> I took a brief look and run some quick tests on ubuntu 12.04. I am going
> to be lazy and try and involve the netfilter folks.
> It seems that if you left out the args to CONNMARK (includes other
> targets like MARK etc) you will succeed - but you get default
> values.
>
>
> Example, the following should work for
> tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
> action ipt -j CONNMARK \
> action mirred egress redirect dev ifb0
>
> Here is what the output looks like when you dont pass the parameters.
>
> -------
> j@ubuntu:~$ sudo tc filter show dev eth0 parent ffff:
> filter protocol ip pref 1 u32
> filter protocol ip pref 1 u32 fh 800: ht divisor 1
> filter protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt
> 0 flowid 1:15
> match 0a000015/ffffffff at 12
> action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING
> target MARK and 0xffffffff
> index 2 ref 1 bind 1
>
> filter protocol ip pref 49149 u32
> filter protocol ip pref 49149 u32 fh 804: ht divisor 1
> filter protocol ip pref 49149 u32 fh 804::800 order 2048 key ht 804
> bkt 0 flowid 1:12
> match 00000000/00000000 at 0
> action order 33: tablename: mangle hook: NF_IP_PRE_ROUTING
> target CONNMARK and 0x0
> index 123 ref 1 bind 1
> ----------------
>
> Pablo, Hasan Chowdhury tells me this broke after iptable 1.4.10
> Hasan also sent me a small patch to fake "xt" instead of "ipt" - but
> i think there's more than meets the eye here; some interface we are
> using to talk to xtables on user space seems to have changed.
The binary interface was broken in 1.4.11 with the guided option
parser:
commit 7299fa4b615d7f7ee12cde444266f6b31f667f9f
Author: Jan Engelhardt <jengelh@medozas.de>
Date: Sun Mar 6 15:54:58 2011 +0100
libxt_CONNMARK: use guided option parser
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.
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.
Cheers,
Pablo
^ permalink raw reply
* [PATCH] build: unbreak linkage of m_xt.so
From: Jan Engelhardt @ 2012-12-16 0:32 UTC (permalink / raw)
To: stephen.hemminger
Cc: vapier, netdev, jhs, urykhy, shemonc, pablo, netfilter-devel
In-Reply-To: <alpine.LNX.2.01.1212160119060.7193@nerf07.vanv.qr>
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
Fixing that.
Signed-off-by: Jan Engelhardt <jengelh@inai.de>
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 9912114..573ee55 100755
--- a/configure
+++ b/configure
@@ -4,7 +4,6 @@
INCLUDE=${1:-"$PWD/include"}
: ${PKG_CONFIG:=pkg-config}
: ${CC=gcc}
-echo "PKG_CONFIG:=${PKG_CONFIG}" >>Config
# Make a temp directory in build tree.
TMPDIR=$(mktemp -d config.XXXXXX)
@@ -224,6 +223,7 @@ rm -f $TMPDIR/ipsettest.c $TMPDIR/ipsettest
}
echo "# Generated config based on" $INCLUDE >Config
+echo "PKG_CONFIG:=${PKG_CONFIG}" >>Config
echo "TC schedulers"
--
1.7.10.4
^ permalink raw reply related
* Re: tc ipt action
From: Jan Engelhardt @ 2012-12-16 0:59 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Jamal Hadi Salim, Yury Stankevich, shemonc,
netdev@vger.kernel.org, netfilter-devel
In-Reply-To: <20121216002755.GA11773@1984>
On Sunday 2012-12-16 01:27, Pablo Neira Ayuso wrote:
>On Sat, Dec 15, 2012 at 04:19:29PM -0500, Jamal Hadi Salim wrote:
>> Example, the following should work for
>> tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
>> action ipt -j CONNMARK \
>> action mirred egress redirect dev ifb0
>>
>commit 7299fa4b615d7f7ee12cde444266f6b31f667f9f
> libxt_CONNMARK: use guided option parser
>
>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.
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(...)
...
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
* [PATCH] netlink: change presentation of portid in procfs to unsigned
From: Hannes Frederic Sowa @ 2012-12-16 1:09 UTC (permalink / raw)
To: netdev
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/netlink/af_netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 4da797f..fdb7494 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -2059,7 +2059,7 @@ static int netlink_seq_show(struct seq_file *seq, void *v)
struct sock *s = v;
struct netlink_sock *nlk = nlk_sk(s);
- seq_printf(seq, "%pK %-3d %-6d %08x %-8d %-8d %pK %-8d %-8d %-8lu\n",
+ seq_printf(seq, "%pK %-3d %-6u %08x %-8d %-8d %pK %-8d %-8d %-8lu\n",
s,
s->sk_protocol,
nlk->portid,
^ permalink raw reply related
* Re: [PATCH v2] can: sja1000: fix compilation on x86
From: David Miller @ 2012-12-16 1:16 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, rdunlap, andreas
In-Reply-To: <1355523912-1977-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Fri, 14 Dec 2012 23:25:12 +0100
> Since commit:
> 04df251 can: sja1000: Make sja1000_of_platform selectable and compilable on SPARC
> the driver can be activated on non powerpc platform like x86 or sparc. Without
> this patch the driver fails to compile on platform that don't define NO_IRQ,
> like x86.
>
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Andreas Larsson <andreas@gaisler.com>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Applied.
^ permalink raw reply
* Re: [PATCH] i2400m: add Intel 6150 device IDs
From: David Miller @ 2012-12-16 1:16 UTC (permalink / raw)
To: dcbw; +Cc: netdev, inaky.perez-gonzalez
In-Reply-To: <1355526650.32099.19.camel@dcbw.foobar.com>
From: Dan Williams <dcbw@redhat.com>
Date: Fri, 14 Dec 2012 17:10:50 -0600
> Add device IDs for WiMAX function of Intel 6150 cards.
>
> Signed-off-by: Dan Williams <dcbw@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] sctp: Change defaults on cookie hmac selection
From: David Miller @ 2012-12-16 1:16 UTC (permalink / raw)
To: nhorman; +Cc: netdev, torvalds, vyasevich, linux-sctp
In-Reply-To: <1355534521-32719-1-git-send-email-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 14 Dec 2012 20:22:01 -0500
> Recently I posted commit 3c68198e75 which made selection of the cookie hmac
> algorithm selectable. This is all well and good, but Linus noted that it
> changes the default config:
> http://marc.info/?l=linux-netdev&m=135536629004808&w=2
>
> I've modified the sctp Kconfig file to reflect the recommended way of making
> this choice, using the thermal driver example specified, and brought the
> defaults back into line with the way they were prior to my origional patch
>
> Also, on Linus' suggestion, re-adding ability to select default 'none' hmac
> algorithm, so we don't needlessly bloat the kernel by forcing a non-none
> default. This also led me to note that we won't honor the default none
> condition properly because of how sctp_net_init is encoded. Fix that up as
> well.
>
> Tested by myself (allbeit fairly quickly). All configuration combinations seems
> to work soundly.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] bridge: update selinux perm table for RTM_NEWMDB and RTM_DELMDB
From: David Miller @ 2012-12-16 1:16 UTC (permalink / raw)
To: amwang; +Cc: netdev, bridge, herbert, shemminger
In-Reply-To: <1355558992-32285-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Sat, 15 Dec 2012 16:09:50 +0800
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Stephen Hemminger <shemminger@vyatta.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] bridge: add flags to distinguish permanent mdb entires
From: David Miller @ 2012-12-16 1:16 UTC (permalink / raw)
To: amwang; +Cc: netdev, bridge, herbert, shemminger
In-Reply-To: <1355558992-32285-2-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Sat, 15 Dec 2012 16:09:51 +0800
> This patch adds a flag to each mdb entry, so that we can distinguish
> permanent entries with temporary entries.
>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Stephen Hemminger <shemminger@vyatta.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied, but you _really_ need to lock down the interface and
stop making changes to the user visible side of this _now_.
Thanks.
^ permalink raw reply
* 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
* [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: 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
* 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: [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: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 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
* 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
* [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
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