* [PATCH] net: fix potential neighbour race in dst_ifdown()
From: Eric Dumazet @ 2011-08-09 6:56 UTC (permalink / raw)
To: David Miller; +Cc: synapse, netdev
In-Reply-To: <20110803.033442.1456080508068739176.davem@davemloft.net>
Le mercredi 03 août 2011 à 03:34 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Sat, 30 Jul 2011 07:00:53 +0200
>
> > [PATCH] net: fix NULL dereferences in check_peer_redir()
>
> I'm adding this now to my tree so it gets more widespread
> testing.
Thanks David
We probably have other races, here is a followup patch, probably suited
for net-next, since its not clear if its a real problem while device is
unregistering. Consider it as a cleanup at very least.
[PATCH] net: fix potential neighbour race in dst_ifdown()
Followup of commit f2c31e32b378a (fix NULL dereferences in
check_peer_redir()).
We need to make sure dst neighbour doesnt change in dst_ifdown().
Fix some sparse errors.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/dst.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/net/core/dst.c b/net/core/dst.c
index 14b33baf..d5e2c4c 100644
--- a/net/core/dst.c
+++ b/net/core/dst.c
@@ -171,7 +171,7 @@ void *dst_alloc(struct dst_ops *ops, struct net_device *dev,
dst_init_metrics(dst, dst_default_metrics, true);
dst->expires = 0UL;
dst->path = dst;
- dst->_neighbour = NULL;
+ RCU_INIT_POINTER(dst->_neighbour, NULL);
#ifdef CONFIG_XFRM
dst->xfrm = NULL;
#endif
@@ -229,11 +229,11 @@ struct dst_entry *dst_destroy(struct dst_entry * dst)
smp_rmb();
again:
- neigh = dst->_neighbour;
+ neigh = rcu_dereference_protected(dst->_neighbour, 1);
child = dst->child;
if (neigh) {
- dst->_neighbour = NULL;
+ RCU_INIT_POINTER(dst->_neighbour, NULL);
neigh_release(neigh);
}
@@ -360,14 +360,19 @@ static void dst_ifdown(struct dst_entry *dst, struct net_device *dev,
if (!unregister) {
dst->input = dst->output = dst_discard;
} else {
+ struct neighbour *neigh;
+
dst->dev = dev_net(dst->dev)->loopback_dev;
dev_hold(dst->dev);
dev_put(dev);
- if (dst->_neighbour && dst->_neighbour->dev == dev) {
- dst->_neighbour->dev = dst->dev;
+ rcu_read_lock();
+ neigh = dst_get_neighbour(dst);
+ if (neigh && neigh->dev == dev) {
+ neigh->dev = dst->dev;
dev_hold(dst->dev);
dev_put(dev);
}
+ rcu_read_unlock();
}
}
^ permalink raw reply related
* Re: gianfar.c null pointer deref in gfar_start_xmit().
From: Eric Dumazet @ 2011-08-09 7:10 UTC (permalink / raw)
To: Robin Holt; +Cc: Sandeep Gopalpet, David S. Miller, netdev
In-Reply-To: <20110809065407.GF3709@sgi.com>
Le mardi 09 août 2011 à 01:54 -0500, Robin Holt a écrit :
> On Tue, Aug 02, 2011 at 09:44:38PM -0500, Robin Holt wrote:
> >
> > While using the v3.0 kernel on a Freescale P1010RDB with 3 minor patches
> > (None which affect gianfar.c), I get a NULL pointer deref at:
> >
> > static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
> > {
> > ...
> > regs = tx_queue->grp->regs;
> >
> > I put a BUG_ON(tx_queue->grp) just before this line and it did trip.
> > I have not looked at this any more than that.
> >
> > Any suggestions would be welcome. To reproduce, all I need to do is
> > a few sequences of pings.
>
> I was able to reproduce this with the net-next-2.6 kernel as well.
>
This driver incorrectly assumes a non dense txqueue array is possible
for a netdev, but its not true.
In the meantime, you could force it to use one tx_queue only.
tx_queues = (u32 *)of_get_property(np, "fsl,num_tx_queues", NULL);
num_tx_qs = tx_queues ? *tx_queues : 1;
^ permalink raw reply
* Re: [RFC 4/4] [powerpc] Add flexcan device support for p1010rdb.
From: Wolfgang Grandegger @ 2011-08-09 7:11 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w, U Bhaskar-B22300,
Marc Kleine-Budde, PPC list, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110809063319.GK4926-sJ/iWh9BUns@public.gmane.org>
On 08/09/2011 08:33 AM, Robin Holt wrote:
> Argh. I sent an earlier (non-working) version of this patch. Here is
> the correct one.
Please always resend the complete series of patches with an incremented
version number. Furthermore, this is not an RFC any more. A prefix
similar to [PATCH nfsl_get_sys_freq() et-next-2.6 v2] would be perfect.
> I added a clock source for the p1010rdb so the flexcan driver
> could find its clock frequency.
>
> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
> To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
> To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
> Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> ---
> arch/powerpc/platforms/85xx/Kconfig | 6 +++
> arch/powerpc/platforms/85xx/Makefile | 1 +
> arch/powerpc/platforms/85xx/clock.c | 59 ++++++++++++++++++++++++++++++++
> arch/powerpc/platforms/85xx/p1010rdb.c | 10 +++++
> 4 files changed, 76 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/platforms/85xx/clock.c
>
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index 498534c..ed4cf92 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -26,6 +26,10 @@ config MPC8560_ADS
> help
> This option enables support for the MPC 8560 ADS board
>
> +config 85xx_HAVE_CAN_FLEXCAN
> + bool
> + select HAVE_CAN_FLEXCAN if NET && CAN
> +
Why do you need that? More below...
> config MPC85xx_CDS
> bool "Freescale MPC85xx CDS"
> select DEFAULT_UIMAGE
> @@ -70,6 +74,8 @@ config MPC85xx_RDB
> config P1010_RDB
> bool "Freescale P1010RDB"
> select DEFAULT_UIMAGE
> + select 85xx_HAVE_CAN_FLEXCAN
> + select PPC_CLOCK if CAN_FLEXCAN
select HAVE_CAN_FLEXCAN
select PPC_CLOCK
Should just be fine, or have I missed something.
> help
> This option enables support for the MPC85xx RDB (P1010 RDB) board
>
> diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
> index a971b32..64ad7a4 100644
> --- a/arch/powerpc/platforms/85xx/Makefile
> +++ b/arch/powerpc/platforms/85xx/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_MPC85xx_DS) += mpc85xx_ds.o
> obj-$(CONFIG_MPC85xx_MDS) += mpc85xx_mds.o
> obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o
> obj-$(CONFIG_P1010_RDB) += p1010rdb.o
> +obj-$(CONFIG_PPC_CLOCK) += clock.o
I would put that to the beginning or before the board settings.
> obj-$(CONFIG_P1022_DS) += p1022_ds.o
> obj-$(CONFIG_P1023_RDS) += p1023_rds.o
> obj-$(CONFIG_P2040_RDB) += p2040_rdb.o corenet_ds.o
> diff --git a/arch/powerpc/platforms/85xx/clock.c b/arch/powerpc/platforms/85xx/clock.c
> new file mode 100644
> index 0000000..a25cbf3
> --- /dev/null
> +++ b/arch/powerpc/platforms/85xx/clock.c
> @@ -0,0 +1,59 @@
> +
> +#include <linux/device.h>
> +#include <linux/err.h>
> +
> +#include <asm/clk_interface.h>
> +
> +#include <sysdev/fsl_soc.h>
> +
> +/*
> + * p1010rdb needs to provide a clock source for the flexcan driver.
> + */
> +struct clk {
> + unsigned long rate;
> +} p1010_rdb_system_clock;
> +
> +static struct clk *p1010_rdb_clk_get(struct device *dev, const char *id)
> +{
> + const char *dev_init_name;
> +
> + if (!dev)
> + return ERR_PTR(-ENOENT);
> +
> + /*
> + * The can devices are named ffe1c000.can0 and ffe1d000.can1 on
> + * the p1010rdb. Check for the "can" portion of that name before
> + * returning a clock source.
> + */
> + dev_init_name = dev_name(dev);
> + if (strlen(dev_init_name) != 13)
> + return ERR_PTR(-ENOENT);
> + dev_init_name += 9;
> + if (strncmp(dev_init_name, "can", 3))
> + return ERR_PTR(-ENOENT);
What's that good for? Also it's wrong to rely on the special name of the
node. I think it can be removed.
> + return &p1010_rdb_system_clock;
Just returning fsl_get_sys_freq() here would already be fine. I'm also
missing the factor of two here:
return fsl_get_sys_freq() / 2; ????
> +}
> +
> +static void p1010_rdb_clk_put(struct clk *clk)
> +{
> + return;
> +}
> +
> +static unsigned long p1010_rdb_clk_get_rate(struct clk *clk)
> +{
> + return clk->rate;
> +}
> +
> +static struct clk_interface p1010_rdb_clk_functions = {
> + .clk_get = p1010_rdb_clk_get,
> + .clk_get_rate = p1010_rdb_clk_get_rate,
> + .clk_put = p1010_rdb_clk_put,
> +};
> +
> +void __init p1010_rdb_clk_init(void)
> +{
> + p1010_rdb_system_clock.rate = fsl_get_sys_freq();
> + clk_functions = p1010_rdb_clk_functions;
> +}
The name is too specific. The idea is that the interface could be used
for other 85xx processors as well, not only the p1010. The prefix
"mpc85xx_" instead of "p1010_rdb" seems more appropriate to me.
> diff --git a/arch/powerpc/platforms/85xx/p1010rdb.c b/arch/powerpc/platforms/85xx/p1010rdb.c
> index d7387fa..d0afbf9 100644
> --- a/arch/powerpc/platforms/85xx/p1010rdb.c
> +++ b/arch/powerpc/platforms/85xx/p1010rdb.c
> @@ -81,6 +81,15 @@ static void __init p1010_rdb_setup_arch(void)
> printk(KERN_INFO "P1010 RDB board from Freescale Semiconductor\n");
> }
>
> +extern void p1010_rdb_clk_init(void);
> +
> +static void __init p1010_rdb_init(void)
> +{
> +#ifdef CONFIG_PPC_CLOCK
> + p1010_rdb_clk_init();
> +#endif
> +}
The #ifdef's are not needed if CONFIG_PPC_CLOCK is selected in the Kconfig.
> static struct of_device_id __initdata p1010rdb_ids[] = {
> { .type = "soc", },
> { .compatible = "soc", },
> @@ -111,6 +120,7 @@ define_machine(p1010_rdb) {
> .name = "P1010 RDB",
> .probe = p1010_rdb_probe,
> .setup_arch = p1010_rdb_setup_arch,
> + .init = p1010_rdb_init,
> .init_IRQ = p1010_rdb_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
We also need cleanup patches for the Freescale stuff.
Thanks,
Wolfgang.
^ permalink raw reply
* Re: [PATCH 11/12] headers, scc: Add missing #include to <linux/scc.h>
From: walter harms @ 2011-08-09 7:14 UTC (permalink / raw)
To: Ben Hutchings
Cc: David Miller, netdev, Joerg Reuter, Klaus Kudielka, linux-hams
In-Reply-To: <20110808182018.GG29924@decadent.org.uk>
Am 08.08.2011 20:20, schrieb Ben Hutchings:
> On Mon, Aug 08, 2011 at 02:24:29PM +0100, Ben Hutchings wrote:
>> <linux/scc.h> uses SIOCDEVPRIVATE, defined in <linux/sockios.h>.
>
> Unfortunately SIOCDEVPRIVATE is also defined elsewhere by glibc,
> so including <linux/sockios.h> can result in duplicate definitions.
> So I don't think we can make this change.
>
Maybe that is something the glibc and the kernel guys should know about.
Did someone tell them ? Is that problem documented somewhere ?
re,
wh
> Ben.
>
>> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>> ---
>> This file isn't listed in MAINTAINERS but appears to be associated with
>> one of the hamradio drivers; please could one of the hams claim it?
>>
>> Ben.
>>
>> include/linux/scc.h | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/scc.h b/include/linux/scc.h
>> index 3495bd9..d5916e5 100644
>> --- a/include/linux/scc.h
>> +++ b/include/linux/scc.h
>> @@ -3,6 +3,7 @@
>> #ifndef _SCC_H
>> #define _SCC_H
>>
>> +#include <linux/sockios.h>
>>
>> /* selection of hardware types */
>>
>> --
>> 1.7.5.4
>>
>>
>>
>
^ permalink raw reply
* Re: [PATCH 12/12] headers, ppp: Add missing #include to <linux/if_ppp.h>
From: David Miller @ 2011-08-09 7:27 UTC (permalink / raw)
To: ben; +Cc: netdev, paulus, linux-ppp
In-Reply-To: <1312809919.2591.1152.camel@deadeye>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 08 Aug 2011 14:25:19 +0100
> <linux/if_ppp.h> uses various types defined in <linux/ppp_defs.h>.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Unfortunately there is a "net/if_ppp.h" provided by glibc that
includes "net/ppp_defs.h", and all of this is presumably in order
to discourage direct use of the kernel headers.
Even though net/ppp_defs.h ends up including linux/ppp_defs.h
anyways.
Whilst I think your efforts are to be commended, we can't start doing
or else we'll start breaking the build in various unexpected ways.
The SIOCDEVPRIVATE (defined by GLIBC in bits/ioctls.h) case is just
one such example.
^ permalink raw reply
* [v2 PATCH 0/6] Export the sock's security context to proc
From: rongqing.li @ 2011-08-09 7:28 UTC (permalink / raw)
To: netdev, selinux, linux-security-module, sds
-------
Any review would be much appreciated.
Comments:
--------
Export the sock's security context to proc.
The element sk_security of struct sock represents the socket
security context ID, which is inheriting from the process when
creates this socket on most of the time.
but when SELinux type_transition rule is applied to socket, or
application sets /proc/xxx/attr/createsock, the socket security
context would be different from the creating process. on this
condition, the "netstat -Z" will return wrong value, since
"netstat -Z" only returns the process security context as socket
process security.
Export the raw sock's security context to proc, so that "netstat -Z"
could be fixed by reading procfs.
Test:
--------
1. When Enable SELinux.
1.1 check the socket security context has been exported in procfs
root@qemu-host:/root> head -n 3 /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode seclabel
0: 00000000:05FE 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 4723 1 ffff88001b7f8c00 100 0 0 10 -1 system_u:system_r:initrc_t:s0-s15:c0.c1023
1: 0100007F:024B 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 5070 1 ffff88001b7f9e00 100 0 0 10 -1 system_u:system_r:sendmail_t:s0-s15:c0.c1023
root@qemu-host:/root> head -n 3 /proc/net/udp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops seclabel
54: 00000000:03F2 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4540 2 ffff88001ba30340 0 system_u:system_r:rpcbind_t:s0-s15:c0.c1023
133: 00000000:B641 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4601 2 ffff88001ba30d00 0 system_u:system_r:rpcd_t:s0-s15:c0.c1023
root@qemu-host:/root> head -n 3 /proc/net/unix
Num RefCount Protocol Flags Type St Inode Path SecLabel
ffff88001ea1cc00: 00000002 00000000 00000000 0002 01 972 @/org/kernel/udev/udevd system_u:system_r:udev_t:s0-s15:c0.c1023
ffff88001ea1d500: 00000002 00000000 00010000 0001 01 4371 /var/evlog/evlconfsoc system_u:system_r:initrc_t:s0-s15:c0.c1023
root@qemu-host:/root>
root@qemu-host:/root> tail -n 3 /proc/net/unix
ffff88001e0e2300: 00000003 00000000 00000000 0001 03 4706 - system_u:system_r:rpcd_t:s0-s15:c0.c1023
ffff88001ea1d200: 00000003 00000000 00000000 0002 01 979 - system_u:system_r:udev_t:s0-s15:c0.c1023
ffff88001ea1cf00: 00000003 00000000 00000000 0002 01 978 - system_u:system_r:udev_t:s0-s15:c0.c1023
root@qemu-host:/root>
root@qemu-host:/root> head -n 3 /proc/net/raw
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops seclabel
root@qemu-host:/root>
1.2 check these patches do not affect the netstat, it can still work
root@qemu-host:/root> netstat -a
Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:1534 *:* LISTEN
tcp 0 0 *:56290 *:* LISTEN
tcp 0 0 localhost:submission *:* LISTEN
tcp 0 0 *:sunrpc *:* LISTEN
...
1.3 When syslog creates socket, and type transition has been applied on them, the security context of
socket would be syslogd_s_t, not same as its own process security context
syslogd_t, the "netstat -Z" returns wrong value, but the security context in procfs is correct
root@qemu-host:/etc> cat /proc/net/unix |grep syslog
ffff88001f856000: 00000002 00000000 00010000 0001 01 6385 /var/lib/syslog-ng/syslog-ng.ctl system_u:system_r:syslogd_t:s15:c0.c1023
ffff88001f856300: 00000002 00000000 00000000 0002 01 6383 /dev/log system_u:system_r:syslogd_s_t:s15:c0.c1023
root@qemu-host:/etc>
root@qemu-host:/etc> netstat -aZ|grep 6383
unix 2 [ ] DGRAM 6383 793/syslog-ng
system_u:system_r:syslogd_t:s15:c0.c1023 /dev/log
root@qemu-host:/etc>
2. When SElinux is disabled, output - on seclabel column
root@qemu-host:/root> head -n 3 /proc/net/raw
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops seclabel
root@qemu-host:/root> head -n 3 /proc/net/unix
Num RefCount Protocol Flags Type St Inode Path SecLabel
ffff88001e118000: 0000000A 00000000 00000000 0002 01 2647 /dev/log -
ffff88001ea1cc00: 00000002 00000000 00000000 0002 01 897 @/org/kernel/udev/udevd -
root@qemu-host:/root> head -n 3 /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode seclabel
0: 00000000:05FE 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 2935 1 ffff88001d598c00 100 0 0 10 -1 -
1: 0100007F:024B 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 3201 1 ffff88001d599e00 100 0 0 10 -1 -
root@qemu-host:/root> head -n 3 /proc/net/udp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops seclabel
42: 00000000:03E6 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 2754 2 ffff88001da38340 0 -
56: 00000000:B5F4 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 2810 2 ffff88001da389c0 0 -
root@qemu-host:/root>
3. Disable security module configuration, no compiling error.
^ permalink raw reply
* [PATCH 2/6] Define the function to write sock's security context to seq_file.
From: rongqing.li @ 2011-08-09 7:28 UTC (permalink / raw)
To: netdev, selinux, linux-security-module, sds
In-Reply-To: <1312874910-31010-1-git-send-email-rongqing.li@windriver.com>
From: Roy.Li <rongqing.li@windriver.com>
sock_write_secctx will write the sock's security context to a seq_file
and return the number of characters successfully written.
This function will be called when export socket information to proc.
Signed-off-by: Roy.Li <rongqing.li@windriver.com>
---
include/net/sock.h | 1 +
net/core/sock.c | 28 ++++++++++++++++++++++++++++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 8e4062f..8bedb0c 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1828,6 +1828,7 @@ static inline struct sock *skb_steal_sock(struct sk_buff *skb)
extern void sock_enable_timestamp(struct sock *sk, int flag);
extern int sock_get_timestamp(struct sock *, struct timeval __user *);
extern int sock_get_timestampns(struct sock *, struct timespec __user *);
+extern int sock_write_secctx(struct sock *sk, struct seq_file *seq);
/*
* Enable debug/info messages
diff --git a/net/core/sock.c b/net/core/sock.c
index bc745d0..032ea72 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2254,6 +2254,34 @@ void sk_common_release(struct sock *sk)
}
EXPORT_SYMBOL(sk_common_release);
+int sock_write_secctx(struct sock *sk, struct seq_file *seq)
+{
+ char *ctx = NULL;
+ u32 ctxlen, secid;
+ int len;
+
+ if (sk == NULL)
+ goto error;
+
+ if (security_socket_getsockname(sk->sk_socket))
+ goto error;
+
+ security_sk_getsecid(sk, &secid);
+ if (!secid)
+ goto error;
+
+ if (security_secid_to_secctx(secid, &ctx, &ctxlen))
+ goto error;
+
+ seq_printf(seq, " %s%n", ctx, &len);
+ security_release_secctx(ctx, ctxlen);
+ return len;
+
+error:
+ seq_printf(seq, " %s%n", "-", &len);
+ return len;
+}
+
static DEFINE_RWLOCK(proto_list_lock);
static LIST_HEAD(proto_list);
--
1.7.1
^ permalink raw reply related
* [PATCH 1/6] Security: define security_sk_getsecid.
From: rongqing.li @ 2011-08-09 7:28 UTC (permalink / raw)
To: netdev, selinux, linux-security-module, sds
In-Reply-To: <1312874910-31010-1-git-send-email-rongqing.li@windriver.com>
From: Roy.Li <rongqing.li@windriver.com>
Define security_sk_getsecid to get the security id of a sock.
Signed-off-by: Roy.Li <rongqing.li@windriver.com>
---
include/linux/security.h | 6 ++++++
security/security.c | 6 ++++++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/include/linux/security.h b/include/linux/security.h
index ebd2a53..739ac39 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -2560,6 +2560,7 @@ int security_sk_alloc(struct sock *sk, int family, gfp_t priority);
void security_sk_free(struct sock *sk);
void security_sk_clone(const struct sock *sk, struct sock *newsk);
void security_sk_classify_flow(struct sock *sk, struct flowi *fl);
+void security_sk_getsecid(struct sock *sk, u32 *secid);
void security_req_classify_flow(const struct request_sock *req, struct flowi *fl);
void security_sock_graft(struct sock*sk, struct socket *parent);
int security_inet_conn_request(struct sock *sk,
@@ -2701,6 +2702,11 @@ static inline void security_sk_classify_flow(struct sock *sk, struct flowi *fl)
{
}
+static inline void security_sk_getsecid(struct sock *sk, u32 *secid)
+{
+ *secid = 0;
+}
+
static inline void security_req_classify_flow(const struct request_sock *req, struct flowi *fl)
{
}
diff --git a/security/security.c b/security/security.c
index 0e4fccf..b0e0825 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1104,6 +1104,12 @@ void security_sk_classify_flow(struct sock *sk, struct flowi *fl)
}
EXPORT_SYMBOL(security_sk_classify_flow);
+void security_sk_getsecid(struct sock *sk, u32 *secid)
+{
+ security_ops->sk_getsecid(sk, secid);
+}
+EXPORT_SYMBOL(security_sk_getsecid);
+
void security_req_classify_flow(const struct request_sock *req, struct flowi *fl)
{
security_ops->req_classify_flow(req, fl);
--
1.7.1
^ permalink raw reply related
* [PATCH 3/6] Export the raw sock's security context to proc.
From: rongqing.li @ 2011-08-09 7:28 UTC (permalink / raw)
To: netdev, selinux, linux-security-module, sds
In-Reply-To: <1312874910-31010-1-git-send-email-rongqing.li@windriver.com>
From: Roy.Li <rongqing.li@windriver.com>
The element sk_security of struct sock represents the socket
security context ID, which is inheriting from the process when
creates this socket on most of the time.
but when SELinux type_transition rule is applied to socket, or
application sets /proc/xxx/attr/createsock, the socket security
context would be different from the creating process. on this
condition, the "netstat -Z" will return wrong value, since
"netstat -Z" only returns the process security context as socket
process security.
Export the raw sock's security context to proc, so that "netstat -Z"
could be fixed by reading procfs.
Signed-off-by: Roy.Li <rongqing.li@windriver.com>
---
net/ipv4/raw.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 1457acb..79c17e5 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -979,12 +979,15 @@ static void raw_sock_seq_show(struct seq_file *seq, struct sock *sp, int i)
srcp = inet->inet_num;
seq_printf(seq, "%4d: %08X:%04X %08X:%04X"
- " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %pK %d\n",
+ " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %pK %d",
i, src, srcp, dest, destp, sp->sk_state,
sk_wmem_alloc_get(sp),
sk_rmem_alloc_get(sp),
0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
atomic_read(&sp->sk_refcnt), sp, atomic_read(&sp->sk_drops));
+
+ sock_write_secctx(sp, seq);
+ seq_putc(seq, '\n');
}
static int raw_seq_show(struct seq_file *seq, void *v)
@@ -992,7 +995,7 @@ static int raw_seq_show(struct seq_file *seq, void *v)
if (v == SEQ_START_TOKEN)
seq_printf(seq, " sl local_address rem_address st tx_queue "
"rx_queue tr tm->when retrnsmt uid timeout "
- "inode ref pointer drops\n");
+ "inode ref pointer drops seclabel\n");
else
raw_sock_seq_show(seq, v, raw_seq_private(seq)->bucket);
return 0;
--
1.7.1
^ permalink raw reply related
* [PATCH 4/6] Export the udp sock's security context to proc.
From: rongqing.li @ 2011-08-09 7:28 UTC (permalink / raw)
To: netdev, selinux, linux-security-module, sds
In-Reply-To: <1312874910-31010-1-git-send-email-rongqing.li@windriver.com>
From: Roy.Li <rongqing.li@windriver.com>
Export the udp sock's security context to proc, since it maybe
different from the sock's owner process security context.
Signed-off-by: Roy.Li <rongqing.li@windriver.com>
---
net/ipv4/udp.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 1b5a193..6a1aff9 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2102,21 +2102,23 @@ static void udp4_format_sock(struct sock *sp, struct seq_file *f,
0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
atomic_read(&sp->sk_refcnt), sp,
atomic_read(&sp->sk_drops), len);
+
+ *len += sock_write_secctx(sp, f);
}
int udp4_seq_show(struct seq_file *seq, void *v)
{
if (v == SEQ_START_TOKEN)
- seq_printf(seq, "%-127s\n",
+ seq_printf(seq, "%-150s\n",
" sl local_address rem_address st tx_queue "
"rx_queue tr tm->when retrnsmt uid timeout "
- "inode ref pointer drops");
+ "inode ref pointer drops seclabel");
else {
struct udp_iter_state *state = seq->private;
int len;
udp4_format_sock(v, seq, state->bucket, &len);
- seq_printf(seq, "%*s\n", 127 - len, "");
+ seq_printf(seq, "%*s\n", (150 - len) > 0 ? 150 - len : 0, "");
}
return 0;
}
--
1.7.1
^ permalink raw reply related
* [PATCH 5/6] Export the unix sock's security context to proc.
From: rongqing.li @ 2011-08-09 7:28 UTC (permalink / raw)
To: netdev, selinux, linux-security-module, sds
In-Reply-To: <1312874910-31010-1-git-send-email-rongqing.li@windriver.com>
From: Roy.Li <rongqing.li@windriver.com>
Export the unix sock's security context to proc, since it maybe
different from the sock's owner process security context.
Output '-' on Path column if the addr of unix_sock is NULL, rather
than nothing.
Signed-off-by: Roy.Li <rongqing.li@windriver.com>
---
net/unix/af_unix.c | 20 ++++++++++++++++----
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index ec68e1c..9021f9b 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -2239,12 +2239,14 @@ static void unix_seq_stop(struct seq_file *seq, void *v)
spin_unlock(&unix_table_lock);
}
+#define OFFSET_PATH_START 40
static int unix_seq_show(struct seq_file *seq, void *v)
{
+ int len, offset = OFFSET_PATH_START;
if (v == SEQ_START_TOKEN)
seq_puts(seq, "Num RefCount Protocol Flags Type St "
- "Inode Path\n");
+ "Inode Path SecLabel\n");
else {
struct sock *s = v;
struct unix_sock *u = unix_sk(s);
@@ -2261,9 +2263,9 @@ static int unix_seq_show(struct seq_file *seq, void *v)
(s->sk_state == TCP_ESTABLISHED ? SS_CONNECTING : SS_DISCONNECTING),
sock_i_ino(s));
+ seq_putc(seq, ' ');
if (u->addr) {
- int i, len;
- seq_putc(seq, ' ');
+ int i;
i = 0;
len = u->addr->len - sizeof(short);
@@ -2275,7 +2277,17 @@ static int unix_seq_show(struct seq_file *seq, void *v)
}
for ( ; i < len; i++)
seq_putc(seq, u->addr->name->sun_path[i]);
- }
+ } else
+ seq_printf(seq, " %s%n", "-", &len);
+
+ if (offset > len)
+ offset -= (len + 1);
+ else
+ offset = 0;
+
+ seq_printf(seq, "%*s", offset, " ");
+ sock_write_secctx(s, seq);
+
unix_state_unlock(s);
seq_putc(seq, '\n');
}
--
1.7.1
^ permalink raw reply related
* [PATCH 6/6] Export the tcp sock's security context to proc.
From: rongqing.li @ 2011-08-09 7:28 UTC (permalink / raw)
To: netdev, selinux, linux-security-module, sds
In-Reply-To: <1312874910-31010-1-git-send-email-rongqing.li@windriver.com>
From: Roy.Li <rongqing.li@windriver.com>
Export the tcp sock's security context to proc, since it maybe
different from the sock's owner process security context.
Signed-off-by: Roy.Li <rongqing.li@windriver.com>
---
net/ipv4/tcp_ipv4.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 955b8e6..ddac912 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2479,12 +2479,13 @@ static int tcp4_seq_show(struct seq_file *seq, void *v)
{
struct tcp_iter_state *st;
int len;
+ struct sock *s = NULL;
if (v == SEQ_START_TOKEN) {
seq_printf(seq, "%-*s\n", TMPSZ - 1,
" sl local_address rem_address st tx_queue "
"rx_queue tr tm->when retrnsmt uid timeout "
- "inode");
+ "inode seclabel");
goto out;
}
st = seq->private;
@@ -2493,15 +2494,20 @@ static int tcp4_seq_show(struct seq_file *seq, void *v)
case TCP_SEQ_STATE_LISTENING:
case TCP_SEQ_STATE_ESTABLISHED:
get_tcp4_sock(v, seq, st->num, &len);
+ s = v;
break;
case TCP_SEQ_STATE_OPENREQ:
get_openreq4(st->syn_wait_sk, v, seq, st->num, st->uid, &len);
+ s = st->syn_wait_sk;
break;
case TCP_SEQ_STATE_TIME_WAIT:
get_timewait4_sock(v, seq, st->num, &len);
break;
}
- seq_printf(seq, "%*s\n", TMPSZ - 1 - len, "");
+
+ len += sock_write_secctx(s, seq);
+ len = TMPSZ - 1 - len;
+ seq_printf(seq, "%*s\n", len > 0 ? len : 0, "");
out:
return 0;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 6/6] Export the tcp sock's security context to proc.
From: David Miller @ 2011-08-09 7:33 UTC (permalink / raw)
To: rongqing.li; +Cc: netdev, selinux, linux-security-module, sds
In-Reply-To: <1312874910-31010-7-git-send-email-rongqing.li@windriver.com>
From: <rongqing.li@windriver.com>
Date: Tue, 9 Aug 2011 15:28:30 +0800
> if (v == SEQ_START_TOKEN) {
> seq_printf(seq, "%-*s\n", TMPSZ - 1,
> " sl local_address rem_address st tx_queue "
> "rx_queue tr tm->when retrnsmt uid timeout "
> - "inode");
> + "inode seclabel");
> goto out;
> }
Unfortunately you cannot change the layout of procfs file output in
this way. It has the potential to break programs which are parsing
this file in userspace already.
The layout hasn't changed in a very long time because it is essentially
a uservisible ABI.
If you want to export new information you'll have to do it using the
facility that is extensible, and that's the netlink based socket dumping
facility implemented in inet_diag.c, tcp_diag.c and friends.
There, you can simply add a new netlink attribute that gets dumped with
the entry, which will provide the security context.
^ permalink raw reply
* Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits
From: David Miller @ 2011-08-09 7:41 UTC (permalink / raw)
To: shemminger; +Cc: therbert, netdev
In-Reply-To: <20110808111917.4b2669de@nehalam.ftrdhcpuser.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 8 Aug 2011 11:19:17 -0700
> On Mon, 8 Aug 2011 11:01:57 -0700
> Tom Herbert <therbert@google.com> wrote:
>
>> > Since transmit completion means calling dev_kfree_skb() why not account
>> > there? You could add some info to netdev if necessary to get compile
>> > the statistics.
>> >
>> The algorithm depends on knowing the total number of packets competed
>> in a single execution of transmit completion (epic based). We only
>> want to recalculate the limits once per completion, which happens when
>> the completion function is called.
>
> So just add some stats to netdev and count the number of dev_kfree_skb
> calls and do your work at napi complete.
No, I think what Tom's doing here is reasonable.
First off, drivers have never been required to do specific things if
they return success for ->ndo_start_xmit(). They can kfree_skb(skb)
and return NET_TX_SUCCESS, and that's fine.
This mean we can't use ->ndo_start_xmit() return values to drive the
BQL engine.
So we simply have a way for the driver to say when it really does
queue up a packet, and that might be useful for other things.
Second, you absolutely do not want to run the BQL engine on every
single dev_kfree_skb() call. You want to batch it, and that's what
Tom's new interface does, and that is therefore quite reasonable
too.
In fact, I think the best part about this revision of the BQL patches
is the device driver interface. :-)
^ permalink raw reply
* RE: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: U Bhaskar-B22300 @ 2011-08-09 7:57 UTC (permalink / raw)
To: Marc Kleine-Budde, Wolfgang Grandegger
Cc: socketcan-core@lists.berlios.de, netdev@vger.kernel.org
In-Reply-To: <4E403097.4020306@pengutronix.de>
> -----Original Message-----
> From: Marc Kleine-Budde [mailto:mkl@pengutronix.de]
> Sent: Tuesday, August 09, 2011 12:23 AM
> To: Wolfgang Grandegger
> Cc: socketcan-core@lists.berlios.de; netdev@vger.kernel.org; U Bhaskar-
> B22300
> Subject: Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
>
> On 08/08/2011 05:33 PM, Wolfgang Grandegger wrote:
> >> ACK - The device tree bindings as in mainline's Documentation is a
> mess.
> >> If the powerpc guys are happy with a clock interfaces based approach
> >> somewhere in arch/ppc, I'm more than happy to remove:
> >> - fsl,flexcan-clock-source (not implemented, even in the fsl driver)
[Bhaskar]I have pushed the FlexCAN series of patches, It contains the usage of all the fields posted in the FlexCAN bindings at
http://git.kernel.org/?p=linux/kernel/git/stable/linux-3.0.y.git;a=blob;f=Documentation/devicetree/bindings/net/can/fsl-flexcan.txt;h=1a729f089866259ef82d0db5893ff7a8c54d5ccf;hb=94ed5b4788a7cdbe68bc7cb8516972cbebdc8274
> >>
> >> - fsl,flexcan-clock-divider \__ replace with code in arch/ppc, or
> >> - clock-frequency / a single clock-frequency attribute
> >
> > In the "net-next-2.6" tree there is also:
> >
> > $ grep flexcan arch/powerpc/boots/dts/*.dts
> > p1010rdb.dts: fsl,flexcan-clock-source = "platform";
> > p1010rdb.dts: fsl,flexcan-clock-source = "platform";
> > p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
> > p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
> > p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
> > p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
> >
> > Especially the fsl,flexcan-clock-divider = <2>; might make people
> > think, that they could set something else.
>
[Bhaskar] As it is mentioned in the Flexcan bindings, the need of fsl,flexcan-clock-divider = <2>;
But I kept it as "2" because FlexCan clock source is the platform clock and it is CCB/2
If the "2" is misleading, the bindings can be changed or some text can be written to make the meaning of "2"
Understandable , Please suggest ..
> ARGH... :D
>
> Marc
>
> --
> Pengutronix e.K. | Marc Kleine-Budde |
> Industrial Linux Solutions | Phone: +49-231-2826-924 |
> Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
^ permalink raw reply
* Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits
From: Eric Dumazet @ 2011-08-09 8:06 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, therbert, netdev
In-Reply-To: <20110809.004123.2080217558650594315.davem@davemloft.net>
Le mardi 09 août 2011 à 00:41 -0700, David Miller a écrit :
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Mon, 8 Aug 2011 11:19:17 -0700
>
> > On Mon, 8 Aug 2011 11:01:57 -0700
> > Tom Herbert <therbert@google.com> wrote:
> >
> >> > Since transmit completion means calling dev_kfree_skb() why not account
> >> > there? You could add some info to netdev if necessary to get compile
> >> > the statistics.
> >> >
> >> The algorithm depends on knowing the total number of packets competed
> >> in a single execution of transmit completion (epic based). We only
> >> want to recalculate the limits once per completion, which happens when
> >> the completion function is called.
> >
> > So just add some stats to netdev and count the number of dev_kfree_skb
> > calls and do your work at napi complete.
>
> No, I think what Tom's doing here is reasonable.
>
> First off, drivers have never been required to do specific things if
> they return success for ->ndo_start_xmit(). They can kfree_skb(skb)
> and return NET_TX_SUCCESS, and that's fine.
>
> This mean we can't use ->ndo_start_xmit() return values to drive the
> BQL engine.
>
> So we simply have a way for the driver to say when it really does
> queue up a packet, and that might be useful for other things.
>
> Second, you absolutely do not want to run the BQL engine on every
> single dev_kfree_skb() call. You want to batch it, and that's what
> Tom's new interface does, and that is therefore quite reasonable
> too.
>
> In fact, I think the best part about this revision of the BQL patches
> is the device driver interface. :-)
>
I agree, it permits a smooth transition to selected drivers, even some
non NAPI ones ;)
In some stress situations, NAPI never completes, so it would also mean
adding a dql call in this case...
^ permalink raw reply
* Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: Marc Kleine-Budde @ 2011-08-09 8:13 UTC (permalink / raw)
To: U Bhaskar-B22300
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Wolfgang Grandegger
In-Reply-To: <9C64B7751C3BCA41B64A68E23005A7BE1B9D6C-TcFNo7jSaXPiTqIcKZ1S2K4g8xLGJsHaLnY5E4hWTkheoWH0uzbU5w@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2316 bytes --]
On 08/09/2011 09:57 AM, U Bhaskar-B22300 wrote:
>> On 08/08/2011 05:33 PM, Wolfgang Grandegger wrote:
>>>> ACK - The device tree bindings as in mainline's Documentation is a
>> mess.
>>>> If the powerpc guys are happy with a clock interfaces based approach
>>>> somewhere in arch/ppc, I'm more than happy to remove:
>>>> - fsl,flexcan-clock-source (not implemented, even in the fsl driver)
> [Bhaskar]I have pushed the FlexCAN series of patches, It contains the
> usage of all the fields posted in the FlexCAN bindings at
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-3.0.y.git;a=blob;f=Documentation/devicetree/bindings/net/can/fsl-flexcan.txt;h=1a729f089866259ef82d0db5893ff7a8c54d5ccf;hb=94ed5b4788a7cdbe68bc7cb8516972cbebdc8274
I've commented the patches. They are in a very bad shape. Please test
Robin's patches.
>>>>
>>>> - fsl,flexcan-clock-divider \__ replace with code in arch/ppc, or
>>>> - clock-frequency / a single clock-frequency attribute
>>>
>>> In the "net-next-2.6" tree there is also:
>>>
>>> $ grep flexcan arch/powerpc/boots/dts/*.dts
>>> p1010rdb.dts: fsl,flexcan-clock-source = "platform";
>>> p1010rdb.dts: fsl,flexcan-clock-source = "platform";
>>> p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
>>> p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
>>> p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
>>> p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
>>>
>>> Especially the fsl,flexcan-clock-divider = <2>; might make people
>>> think, that they could set something else.
>>
> [Bhaskar] As it is mentioned in the Flexcan bindings, the need of
> fsl,flexcan-clock-divider = <2>; But I kept it as "2" because FlexCan
> clock source is the platform clock and it is CCB/2 If the "2" is
> misleading, the bindings can be changed or some text can be written
> to make the meaning of "2" Understandable , Please suggest ..
The clock devider is crap. Why not specify the clockrate that goes into
the flexcan core?
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [RFC PATCH v2 9/9] sfc: Support for byte queue limits
From: Eric Dumazet @ 2011-08-09 8:21 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.00.1108072151500.13386@pokey.mtv.corp.google.com>
Le dimanche 07 août 2011 à 21:53 -0700, Tom Herbert a écrit :
> Changes to sfc to use byte queue limits.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> void efx_fini_tx_queue(struct efx_tx_queue *tx_queue)
> @@ -1168,6 +1181,8 @@ static int efx_enqueue_skb_tso(struct efx_tx_queue *tx_queue,
> /* Pass off to hardware */
> efx_nic_push_buffers(tx_queue);
>
> + netdev_tx_sent_queue(tx_queue->core_txq, 1, skb->len);
> +
> tx_queue->tso_bursts++;
> return NETDEV_TX_OK;
>
Hmm, thats too late at this point : Hardware might have sent the buffer
and tx completion already freed skb.
^ permalink raw reply
* BUG: null pointer deref in rt2800usb_get_txwi
From: Marc Kleine-Budde @ 2011-08-09 8:23 UTC (permalink / raw)
To: Netdev; +Cc: linux-wireless, Stanislaw Gruszka
[-- Attachment #1: Type: text/plain, Size: 10116 bytes --]
Hello,
I'm a running a sheeva plug (ARM/kirkwood) with a rt2800 USB stick in AP mode.
Bus 001 Device 002: ID 1737:0071 Linksys WUSB600N v1 Dual-Band Wireless-N Network Adapter [Ralink RT2870]
kernel is v3.0.1 +
00898a47269ae5e6dda04defad00234b96692d95 rt2x00: fix usage of NULL queue
b52398b6e4522176dd125722c72c301015d24520 rt2x00: rt2800: fix zeroing skb structure
Which is here for reference:
(http://git.pengutronix.de/?p=mkl/linux-2.6.git;a=shortlog;h=refs/heads/wireless/rt2x00/v3.0.1)
The Kernel crashes after ~1d with this oopses:
(Same oops with stock v3.0.0 and v3.0.1)
[69638.429744] Unable to handle kernel NULL pointer dereference at virtual address 000000ac
[69638.438515] pgd = c0004000
[69638.441322] [000000ac] *pgd=00000000
[69638.444974] Internal error: Oops: 17 [#1]
[69638.449001] Modules linked in: nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc bridge ipv6 stp ext2 arc4 rt2800usb rt2800lib crc_ccitt rt2x00usb rt2x00
lib mac80211 cfg80211 rfkill hmac sha1_generic mv_cesa aes_generic ext4 mbcache jbd2 mmc_block ehci_hcd mvsdio usbcore mmc_core mv643xx_eth libphy inet_lro
[69638.476620] CPU: 0 Not tainted (3.0.1-100-bs-kirkwood+ #3)
[69638.482489] PC is at rt2800usb_get_txwi+0x10/0x1c [rt2800usb]
[69638.488273] LR is at rt2800_txdone_entry+0x34/0xe0 [rt2800lib]
[69638.494131] pc : [<bf1bb194>] lr : [<bf1affa4>] psr: 80000013
[69638.494136] sp : de44df08 ip : 00000001 fp : 00000022
[69638.505672] r10: 0000000e r9 : 00000001 r8 : 0000003c
[69638.510914] r7 : 00000000 r6 : de6aafc0 r5 : 818c22fd r4 : de6d99c8
[69638.517472] r3 : 00000000 r2 : 00000000 r1 : 818c22fd r0 : de6d99c8
[69638.524030] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[69638.531371] Control: 0005397f Table: 0105c000 DAC: 00000017
[69638.537144] Process kworker/u:0 (pid: 2089, stack limit = 0xde44c270)
[69638.543614] Stack: (0xde44df08 to 0xde44e000)
[69638.547997] df00: 00000000 818c22fd 00000000 de6aafc0 de6d99c8 818c22fd
[69638.556221] df20: df958eb4 bf1b0128 c041a384 de6aafc0 df959600 de6ab3c4 de6ab3c4 c043defc
[69638.564443] df40: 00000089 00000012 00000000 bf1bba00 de6ab3c4 c043defc 00000000 df8b86a0
[69638.572666] df60: df959600 bf1bb9e8 de6ab3c4 c043defc 00000089 00000012 00000000 c005beac
[69638.580881] df80: df8b86a0 df959605 00000081 df8b86a0 de44c000 c043defc c043def4 df8b86b0
[69638.589103] dfa0: 00000089 c043defc 00000000 c005ca38 de4c7f30 df8b86a0 c005c878 00000013
[69638.597325] dfc0: 00000000 00000000 00000000 c005fdcc 00000000 00000000 df8b86a0 00000000
[69638.605542] dfe0: de44dfe0 de44dfe0 de4c7f30 c005fd50 c0030a94 c0030a94 ebfffffe e3500000
[69638.613787] [<bf1bb194>] (rt2800usb_get_txwi+0x10/0x1c [rt2800usb]) from [<bf1affa4>] (rt2800_txdone_entry+0x34/0xe0 [rt2800lib])
[69638.625518] [<bf1affa4>] (rt2800_txdone_entry+0x34/0xe0 [rt2800lib]) from [<bf1b0128>] (rt2800_txdone+0xd8/0x124 [rt2800lib])
[69638.636894] [<bf1b0128>] (rt2800_txdone+0xd8/0x124 [rt2800lib]) from [<bf1bba00>] (rt2800usb_work_txdone+0x18/0x110 [rt2800usb])
[69638.648522] [<bf1bba00>] (rt2800usb_work_txdone+0x18/0x110 [rt2800usb]) from [<c005beac>] (process_one_work+0x240/0x404)
[69638.659451] [<c005beac>] (process_one_work+0x240/0x404) from [<c005ca38>] (worker_thread+0x1c0/0x2e0)
[69638.668722] [<c005ca38>] (worker_thread+0x1c0/0x2e0) from [<c005fdcc>] (kthread+0x7c/0x84)
[69638.677036] [<c005fdcc>] (kthread+0x7c/0x84) from [<c0030a94>] (kernel_thread_exit+0x0/0x8)
[69638.685433] Code: e5903008 e5933008 e3530010 e590300c (e59300ac)
[69638.691726] ---[ end trace 99d4053be7f17aef ]---
[69638.699949] Unable to handle kernel paging request at virtual address fffffffc
[69638.707210] pgd = c0004000
[69638.709930] [fffffffc] *pgd=1fffe831, *pte=00000000, *ppte=00000000
[69638.716244] Internal error: Oops: 17 [#2]
[69638.720270] Modules linked in: nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc bridge ipv6 stp ext2 arc4 rt2800usb rt2800lib crc_ccitt rt2x00usb rt2x00lib mac80211 cfg80211 rfkill hmac sha1_generic mv_cesa aes_generic ext4 mbcache jbd2 mmc_block ehci_hcd mvsdio usbcore mmc_core mv643xx_eth libphy inet_lro
[69638.747890] CPU: 0 Tainted: G D (3.0.1-100-bs-kirkwood+ #3)
[69638.754628] PC is at kthread_data+0x4/0xc
[69638.758650] LR is at wq_worker_sleeping+0xc/0xc0
[69638.763292] pc : [<c005ffbc>] lr : [<c005cbb8>] psr: 20000093
[69638.763297] sp : de44dc68 ip : c03f1958 fp : de44dcf4
[69638.774833] r10: de44c000 r9 : de755d2c r8 : 00000001
[69638.780084] r7 : df819ac0 r6 : de755da8 r5 : c03f1910 r4 : 00000000
[69638.786641] r3 : 00000000 r2 : 93c085a9 r1 : 00000000 r0 : de755c20
[69638.793199] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
[69638.800454] Control: 0005397f Table: 1fa78000 DAC: 00000015
[69638.806226] Process kworker/u:0 (pid: 2089, stack limit = 0xde44c270)
[69638.812696] Stack: (0xde44dc68 to 0xde44e000)
[69638.817079] dc60: de755c20 c02d84c8 de7583e0 c01228b4 00000000 00000000
[69638.825293] dc80: 00000003 c0048920 00393830 de755c50 0ecbd14a 00000000 0ecbd14a 00000000
[69638.833507] dca0: c03f1dcc c0061c4c 0ecbd14a 00000000 de755c20 debe0840 00000001 c041c348
[69638.841722] dcc0: de755c20 c0046ffc de755c20 00000001 00000000 de755c20 ffffffff de44dcfc
[69638.849945] dce0: df819ac0 00000001 de755d2c de755d2c de755c18 c0048920 bf1bb194 de44dcfc
[69638.858168] dd00: de44dcfc de755d74 de44dd1c de44dec0 de44c000 00000001 bf1bb196 de44dd72
[69638.866390] dd20: bf1bb194 00000000 00000017 c0033024 de44c270 0000000b 00000001 de44c000
[69638.874606] dd40: 65000001 33303935 20383030 33393565 38303033 35336520 31303033 35652030
[69638.882827] dd60: 30333039 28206330 33393565 63613030 00002029 00000017 00000022 000000ac
[69638.891041] dd80: 00000017 00000000 de44dec0 00000000 00000013 00000017 00000022 c02d5af8
[69638.899257] dda0: de755c20 c0036430 40000013 c0038fc0 c0038f74 def76020 00000f40 c0035840
[69638.907479] ddc0: dee26460 df900574 df900400 bf010dac ffdf5000 ffdf56e0 00000010 df900524
[69638.915702] dde0: 40000013 df9004e4 00000003 00000010 60000093 c0254124 df9004e4 00000006
[69638.923916] de00: 00000017 c03ec210 000000ac de44dec0 0000003c 00000013 0000000e c002a1cc
[69638.932130] de20: 00000080 00000000 df900598 00000000 de6b4418 df9004e4 c04196a0 de44c000
[69638.940344] de40: 00000000 00000001 00000080 00000003 0000012c c02541c0 c043ccf0 0069ca19
[69638.948558] de60: 00000000 00000001 0000000c de44c000 c043cce4 0000003c 00000001 00000003
[69638.956773] de80: 00000001 c004af7c de8960a0 de755c50 c03f1958 c03f5fb8 0000000a 00000014
[69638.964987] dea0: df958eb4 0000000b 00000000 ffffffff de44def4 de6aafc0 00000000 c002f7ac
[69638.973201] dec0: de6d99c8 818c22fd 00000000 00000000 de6d99c8 818c22fd de6aafc0 00000000
[69638.981415] dee0: 0000003c 00000001 0000000e 00000022 00000001 de44df08 bf1affa4 bf1bb194
[69638.989631] df00: 80000013 ffffffff 00000000 818c22fd 00000000 de6aafc0 de6d99c8 818c22fd
[69638.997854] df20: df958eb4 bf1b0128 c041a384 de6aafc0 df959600 de6ab3c4 de6ab3c4 c043defc
[69639.006076] df40: 00000089 00000012 00000000 bf1bba00 de6ab3c4 c043defc 00000000 df8b86a0
[69639.014291] df60: df959600 bf1bb9e8 de6ab3c4 c043defc 00000089 00000012 00000000 c005beac
[69639.022514] df80: df8b86a0 df959605 00000081 df8b86a0 de44c000 c043defc c043def4 df8b86b0
[69639.030737] dfa0: 00000089 c043defc 00000000 c005ca38 de4c7f30 df8b86a0 c005c878 00000013
[69639.038958] dfc0: 00000000 00000000 00000000 c005fdcc 00000000 00000000 df8b86a0 00000001
[69639.047175] dfe0: de44dfe0 de44dfe0 de4c7f30 c005fd50 c0030a94 c0030a94 ebfffffe e3500000
[69639.055402] [<c005ffbc>] (kthread_data+0x4/0xc) from [<c005cbb8>] (wq_worker_sleeping+0xc/0xc0)
[69639.064148] [<c005cbb8>] (wq_worker_sleeping+0xc/0xc0) from [<c02d84c8>] (schedule+0xe8/0x4e8)
[69639.072806] [<c02d84c8>] (schedule+0xe8/0x4e8) from [<c0048920>] (do_exit+0x6b8/0x6f8)
[69639.080764] [<c0048920>] (do_exit+0x6b8/0x6f8) from [<c0033024>] (die+0x2e4/0x324)
[69639.088378] [<c0033024>] (die+0x2e4/0x324) from [<c02d5af8>] (__do_kernel_fault.part.5+0x54/0x74)
[69639.097301] [<c02d5af8>] (__do_kernel_fault.part.5+0x54/0x74) from [<c0036430>] (do_page_fault+0x260/0x27c)
[69639.107091] [<c0036430>] (do_page_fault+0x260/0x27c) from [<c002a1cc>] (do_DataAbort+0x34/0x98)
[69639.115839] [<c002a1cc>] (do_DataAbort+0x34/0x98) from [<c002f7ac>] (__dabt_svc+0x4c/0x60)
[69639.124139] Exception stack(0xde44dec0 to 0xde44df08)
[69639.129219] dec0: de6d99c8 818c22fd 00000000 00000000 de6d99c8 818c22fd de6aafc0 00000000
[69639.137433] dee0: 0000003c 00000001 0000000e 00000022 00000001 de44df08 bf1affa4 bf1bb194
[69639.145643] df00: 80000013 ffffffff
[69639.149165] [<c002f7ac>] (__dabt_svc+0x4c/0x60) from [<bf1bb194>] (rt2800usb_get_txwi+0x10/0x1c [rt2800usb])
[69639.159060] [<bf1bb194>] (rt2800usb_get_txwi+0x10/0x1c [rt2800usb]) from [<bf1affa4>] (rt2800_txdone_entry+0x34/0xe0 [rt2800lib])
[69639.170786] [<bf1affa4>] (rt2800_txdone_entry+0x34/0xe0 [rt2800lib]) from [<bf1b0128>] (rt2800_txdone+0xd8/0x124 [rt2800lib])
[69639.182164] [<bf1b0128>] (rt2800_txdone+0xd8/0x124 [rt2800lib]) from [<bf1bba00>] (rt2800usb_work_txdone+0x18/0x110 [rt2800usb])
[69639.193789] [<bf1bba00>] (rt2800usb_work_txdone+0x18/0x110 [rt2800usb]) from [<c005beac>] (process_one_work+0x240/0x404)
[69639.204711] [<c005beac>] (process_one_work+0x240/0x404) from [<c005ca38>] (worker_thread+0x1c0/0x2e0)
[69639.213980] [<c005ca38>] (worker_thread+0x1c0/0x2e0) from [<c005fdcc>] (kthread+0x7c/0x84)
[69639.222293] [<c005fdcc>] (kthread+0x7c/0x84) from [<c0030a94>] (kernel_thread_exit+0x0/0x8)
[69639.230685] Code: c03f42e8 c02dea14 c02dbd08 e590315c (e5130004)
[69639.237041] ---[ end trace 99d4053be7f17af0 ]---
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [PATCH] ipv4: Fix ip_getsockopt for IP_PKTOPTIONS
From: Jean Sacren @ 2011-08-09 8:24 UTC (permalink / raw)
To: Daniel Baluta; +Cc: David S. Miller, tszocs, Linux Networking
In-Reply-To: <1312672850-13676-1-git-send-email-dbaluta@ixiacom.com>
From: Daniel Baluta <dbaluta@ixiacom.com>
Date: Sun, 07 Aug 2011 02:20:50 +0300
>
> IP_PKTOPTIONS is broken for 32-bit applications running
> in COMPAT mode on 64-bit kernels.
>
> This happens because msghdr's msg_flags field is always
> set to zero. When running in COMPAT mode this should be
> set to MSG_CMSG_COMPAT instead.
>
> Signed-off-by: Tiberiu Szocs-Mihai <tszocs@ixiacom.com>
> Signed-off-by: Daniel Baluta <dbaluta@ixiacom.com>
> ---
> net/ipv4/ip_sockglue.c | 9 +++++----
> 1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> index ab0c9ef..c77f5a8 100644
> --- a/net/ipv4/ip_sockglue.c
> +++ b/net/ipv4/ip_sockglue.c
> @@ -1067,7 +1067,7 @@ EXPORT_SYMBOL(compat_ip_setsockopt);
> */
>
> static int do_ip_getsockopt(struct sock *sk, int level, int optname,
> - char __user *optval, int __user *optlen)
> + char __user *optval, int __user *optlen, unsigned flags)
> {
> struct inet_sock *inet = inet_sk(sk);
> int val;
> @@ -1240,7 +1240,7 @@ static int do_ip_getsockopt(struct sock *sk, int level, int optname,
>
> msg.msg_control = optval;
> msg.msg_controllen = len;
> - msg.msg_flags = 0;
> + msg.msg_flags = flags;
>
> if (inet->cmsg_flags & IP_CMSG_PKTINFO) {
> struct in_pktinfo info;
> @@ -1294,7 +1294,7 @@ int ip_getsockopt(struct sock *sk, int level,
> {
> int err;
>
> - err = do_ip_getsockopt(sk, level, optname, optval, optlen);
> + err = do_ip_getsockopt(sk, level, optname, optval, optlen, 0);
> #ifdef CONFIG_NETFILTER
> /* we need to exclude all possible ENOPROTOOPTs except default case */
> if (err == -ENOPROTOOPT && optname != IP_PKTOPTIONS &&
> @@ -1327,7 +1327,8 @@ int compat_ip_getsockopt(struct sock *sk, int level, int optname,
> return compat_mc_getsockopt(sk, level, optname, optval, optlen,
> ip_getsockopt);
>
> - err = do_ip_getsockopt(sk, level, optname, optval, optlen);
> + err = do_ip_getsockopt(sk, level, optname, optval, optlen,
> + MSG_CMSG_COMPAT);
>
> #ifdef CONFIG_NETFILTER
> /* we need to exclude all possible ENOPROTOOPTs except default case */
> --
> 1.7.2.5
I think the original patch can be simplified. Feedback is greatly
appreciated.
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index ab0c9ef..f6eed68 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1240,7 +1240,7 @@ static int do_ip_getsockopt(struct sock *sk, int level, int optname,
msg.msg_control = optval;
msg.msg_controllen = len;
- msg.msg_flags = 0;
+ msg.msg_flags = MSG_CMSG_COMPAT;
if (inet->cmsg_flags & IP_CMSG_PKTINFO) {
struct in_pktinfo info;
--
Jean Sacren
^ permalink raw reply related
* Re: [PATCH] net: filter: Convert the BPF VM to threaded code
From: Hagen Paul Pfeifer @ 2011-08-09 8:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, rui314, netdev
In-Reply-To: <1312866027.2531.42.camel@edumazet-laptop>
On Tue, 09 Aug 2011 07:00:27 +0200, Eric Dumazet wrote:
> I tried this idea since its already an enum and all enum values are
> handled in the switch, but all gcc versions I used still generate the
> useless compare and branch (always predicted by modern CPU, so harmless
> anyway ?)
Don't think so, the list is rather long - the CPU may not have any
indication. But strange that your gcc generate a conditional sequence of
cmp and conditional jump instruction instead of a jump table! Look at
commit 01f2f3f6ef4d076c, this is what I got after I refactored to an
_dense_ enum list.
> (But this would need to use a larger kernel_sock_filter with not an u16
> code, but the target address).
Not sure if the benefit is worth to try it. Can we avoid any cacheline
misses? I don't think so.
> + switch ((enum bpf_inst)fentry->code) {
That should not differ! Eric, sure that this do the trick?
Hagen
^ permalink raw reply
* Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: Wolfgang Grandegger @ 2011-08-09 8:32 UTC (permalink / raw)
To: U Bhaskar-B22300
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Marc Kleine-Budde
In-Reply-To: <9C64B7751C3BCA41B64A68E23005A7BE1B9D6C-TcFNo7jSaXPiTqIcKZ1S2K4g8xLGJsHaLnY5E4hWTkheoWH0uzbU5w@public.gmane.org>
Hi Bhaskar,
On 08/09/2011 09:57 AM, U Bhaskar-B22300 wrote:
>
>
>> -----Original Message-----
>> From: Marc Kleine-Budde [mailto:mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org]
>> Sent: Tuesday, August 09, 2011 12:23 AM
>> To: Wolfgang Grandegger
>> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; U Bhaskar-
>> B22300
>> Subject: Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
>>
>> On 08/08/2011 05:33 PM, Wolfgang Grandegger wrote:
>>>> ACK - The device tree bindings as in mainline's Documentation is a
>> mess.
>>>> If the powerpc guys are happy with a clock interfaces based approach
>>>> somewhere in arch/ppc, I'm more than happy to remove:
>>>> - fsl,flexcan-clock-source (not implemented, even in the fsl driver)
> [Bhaskar]I have pushed the FlexCAN series of patches, It contains the usage of all the fields posted in the FlexCAN bindings at
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-3.0.y.git;a=blob;f=Documentation/devicetree/bindings/net/can/fsl-flexcan.txt;h=1a729f089866259ef82d0db5893ff7a8c54d5ccf;hb=94ed5b4788a7cdbe68bc7cb8516972cbebdc8274
As Marc already pointed out, Robin already has a much more advanced
patch stack in preparation. Especially your patches do not care about
the already existing Flexcan core on the Freescale's ARM socks.
>>>>
>>>> - fsl,flexcan-clock-divider \__ replace with code in arch/ppc, or
>>>> - clock-frequency / a single clock-frequency attribute
>>>
>>> In the "net-next-2.6" tree there is also:
>>>
>>> $ grep flexcan arch/powerpc/boots/dts/*.dts
>>> p1010rdb.dts: fsl,flexcan-clock-source = "platform";
>>> p1010rdb.dts: fsl,flexcan-clock-source = "platform";
>>> p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
>>> p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
>>> p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
>>> p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
>>>
>>> Especially the fsl,flexcan-clock-divider = <2>; might make people
>>> think, that they could set something else.
>>
> [Bhaskar] As it is mentioned in the Flexcan bindings, the need of fsl,flexcan-clock-divider = <2>;
> But I kept it as "2" because FlexCan clock source is the platform clock and it is CCB/2
> If the "2" is misleading, the bindings can be changed or some text can be written to make the meaning of "2"
> Understandable , Please suggest ..
The clock source and frequency is fixed. Why do we need an extra
properties for that. We have panned to remove these bogus bindings from
the Linux kernel, which sneaked in *without* any review on the relevant
mailing lists (at least I have not realized any posting). We do not
think they are really needed. They just confuse the user. We also prefer
to use the compatibility string "fsl,flexcan" instead
"fsl,flexcan-v1.0". It's unusual to add a version number, which is for
the Flexcan on the PowerPC cores only, I assume, but there will be
device tree for ARM soon. A proper compatibility string would be
"fsl,p1010-flexcan" if we really need to distinguish.
Please join the discussion on the mailing list helping to get this
driver mainline.
Thanks,
Wolfgang.
^ permalink raw reply
* Re: [PATCH] net: filter: Convert the BPF VM to threaded code
From: Eric Dumazet @ 2011-08-09 8:36 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: David Miller, rui314, netdev
In-Reply-To: <7f02f2970d225cddfad74ee660f39d1d@localhost>
Le mardi 09 août 2011 à 10:29 +0200, Hagen Paul Pfeifer a écrit :
> On Tue, 09 Aug 2011 07:00:27 +0200, Eric Dumazet wrote:
>
> > I tried this idea since its already an enum and all enum values are
> > handled in the switch, but all gcc versions I used still generate the
> > useless compare and branch (always predicted by modern CPU, so harmless
> > anyway ?)
>
> Don't think so, the list is rather long - the CPU may not have any
> indication. But strange that your gcc generate a conditional sequence of
> cmp and conditional jump instruction instead of a jump table! Look at
> commit 01f2f3f6ef4d076c, this is what I got after I refactored to an
> _dense_ enum list.
I am speaking of one single conditional branch, the one that is done for
every BPF instruction done in a filter. It's never taken, so must be
predicted by the cpu. A perf session could make sure it is ;)
>
> > (But this would need to use a larger kernel_sock_filter with not an u16
> > code, but the target address).
>
> Not sure if the benefit is worth to try it. Can we avoid any cacheline
> misses? I don't think so.
We avoid some instructions (to load the address from the instruction
code), thats all, for each BPF instruction.
>
>
> > + switch ((enum bpf_inst)fentry->code) {
>
> That should not differ! Eric, sure that this do the trick?
It is the way to tell gcc to make its optimizations, if they exists on
enum switch (), as David suggested.
If I add a new BPF_S_ANC_NEW_INST value in the enum list, not handled in
the switch(), gcc complains correctly.
net/core/filter.c: In function ‘sk_run_filter’:
net/core/filter.c:130:3: warning: enumeration value ‘BPF_S_ANC_NEW_INST’
not handled in switch
^ permalink raw reply
* Re: [PATCH] ipv4: Fix ip_getsockopt for IP_PKTOPTIONS
From: Tiberiu Szocs-Mihai @ 2011-08-09 8:41 UTC (permalink / raw)
To: Jean Sacren; +Cc: Daniel Baluta, David S. Miller, Linux Networking
In-Reply-To: <20110809082404.GA24845@mail.gmail.com>
Hi Jean,
That was my first variant of the patch, but that way the code does more than
it's suppose to do: the call of do_ip_getsockopt becomes unaware of the
context from which it is called (ip_getsockopt or compat_ip_getsockopt). We
should act in a compat manner only when called from compat_ip_getsockopt.
The issue that needed a fix was that in compat mode the flag was set to 0 thus
silently disabling the call of put_cmsg_compat (see net/core/scm.c).
Thanks for the review,
Tiberiu
On Tuesday, August 09, 2011 11:24:04 am Jean Sacren wrote:
> From: Daniel Baluta <dbaluta@ixiacom.com>
> Date: Sun, 07 Aug 2011 02:20:50 +0300
>
> > IP_PKTOPTIONS is broken for 32-bit applications running
> > in COMPAT mode on 64-bit kernels.
> >
> > This happens because msghdr's msg_flags field is always
> > set to zero. When running in COMPAT mode this should be
> > set to MSG_CMSG_COMPAT instead.
> >
> > Signed-off-by: Tiberiu Szocs-Mihai <tszocs@ixiacom.com>
> > Signed-off-by: Daniel Baluta <dbaluta@ixiacom.com>
> > ---
> >
> > net/ipv4/ip_sockglue.c | 9 +++++----
> > 1 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> > index ab0c9ef..c77f5a8 100644
> > --- a/net/ipv4/ip_sockglue.c
> > +++ b/net/ipv4/ip_sockglue.c
> > @@ -1067,7 +1067,7 @@ EXPORT_SYMBOL(compat_ip_setsockopt);
> >
> > */
> >
> > static int do_ip_getsockopt(struct sock *sk, int level, int optname,
> >
> > - char __user *optval, int __user *optlen)
> > + char __user *optval, int __user *optlen, unsigned flags)
> >
> > {
> >
> > struct inet_sock *inet = inet_sk(sk);
> > int val;
> >
> > @@ -1240,7 +1240,7 @@ static int do_ip_getsockopt(struct sock *sk, int
> > level, int optname,
> >
> > msg.msg_control = optval;
> > msg.msg_controllen = len;
> >
> > - msg.msg_flags = 0;
> > + msg.msg_flags = flags;
> >
> > if (inet->cmsg_flags & IP_CMSG_PKTINFO) {
> >
> > struct in_pktinfo info;
> >
> > @@ -1294,7 +1294,7 @@ int ip_getsockopt(struct sock *sk, int level,
> >
> > {
> >
> > int err;
> >
> > - err = do_ip_getsockopt(sk, level, optname, optval, optlen);
> > + err = do_ip_getsockopt(sk, level, optname, optval, optlen, 0);
> >
> > #ifdef CONFIG_NETFILTER
> >
> > /* we need to exclude all possible ENOPROTOOPTs except default case
*/
> > if (err == -ENOPROTOOPT && optname != IP_PKTOPTIONS &&
> >
> > @@ -1327,7 +1327,8 @@ int compat_ip_getsockopt(struct sock *sk, int
> > level, int optname,
> >
> > return compat_mc_getsockopt(sk, level, optname, optval, optlen,
> >
> > ip_getsockopt);
> >
> > - err = do_ip_getsockopt(sk, level, optname, optval, optlen);
> > + err = do_ip_getsockopt(sk, level, optname, optval, optlen,
> > + MSG_CMSG_COMPAT);
> >
> > #ifdef CONFIG_NETFILTER
> >
> > /* we need to exclude all possible ENOPROTOOPTs except default case
*/
>
> I think the original patch can be simplified. Feedback is greatly
> appreciated.
>
> diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> index ab0c9ef..f6eed68 100644
> --- a/net/ipv4/ip_sockglue.c
> +++ b/net/ipv4/ip_sockglue.c
> @@ -1240,7 +1240,7 @@ static int do_ip_getsockopt(struct sock *sk, int
> level, int optname,
>
> msg.msg_control = optval;
> msg.msg_controllen = len;
> - msg.msg_flags = 0;
> + msg.msg_flags = MSG_CMSG_COMPAT;
>
> if (inet->cmsg_flags & IP_CMSG_PKTINFO) {
> struct in_pktinfo info;
^ permalink raw reply
* Re: [PATCH] net: filter: Convert the BPF VM to threaded code
From: Hagen Paul Pfeifer @ 2011-08-09 8:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, rui314, netdev
In-Reply-To: <1312878988.2371.9.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Tue, 09 Aug 2011 10:36:28 +0200, Eric Dumazet wrote:
> I am speaking of one single conditional branch, the one that is done for
> every BPF instruction done in a filter. It's never taken, so must be
> predicted by the cpu. A perf session could make sure it is ;)
Ahh, ok - perf is your friend, I know Eric ;-)
>> > + switch ((enum bpf_inst)fentry->code) {
>>
>> That should not differ! Eric, sure that this do the trick?
>
> It is the way to tell gcc to make its optimizations, if they exists on
> enum switch (), as David suggested.
Argl, I see sock_filter.code is declared as __u16 not enum.
Hagen
^ 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