* Re: [PATCH] net/core: fix rollback handler in register_netdevice_notifier
From: David Miller @ 2011-12-01 4:43 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1322707070-9514-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Thu, 1 Dec 2011 10:37:50 +0800
> From: RongQing.Li <roy.qing.li@gmail.com>
>
> Within nested statements, the break statement terminates only the
> do, for, switch, or while statement that immediately encloses it,
> So replace the break with goto.
>
> Signed-off-by: RongQing.Li <roy.qing.li@gmail.com>
Good catch, applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: net_device flags is an unsigned int
From: Eric Dumazet @ 2011-12-01 4:48 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111130.233918.564313369312715101.davem@davemloft.net>
Le mercredi 30 novembre 2011 à 23:39 -0500, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 01 Dec 2011 05:34:37 +0100
>
> > - unsigned short old_flags = dev->flags;
> > + typeof(dev->flags) old_flags = dev->flags;
>
> Please, create netdev_flags_t or similar, anything but this :-)
Hmm, I thought Linus hated types like this...
Or how explain we dont have jiffies_t or similar ? ;)
Other choice would be a generic macro...
int dev_set_promiscuity(struct net_device *dev, int inc)
{
DEFINE_VARIABLE(temp, dev->flags);
...
}
Hmm...
^ permalink raw reply
* [PATCH net-next] ipv4: use a 64bit load/store in output path
From: Eric Dumazet @ 2011-12-01 5:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev
gcc compiler is smart enough to use a single load/store if we
memcpy(dptr, sptr, 8) on x86_64, regardless of
CONFIG_CC_OPTIMIZE_FOR_SIZE
In IP header, daddr immediately follows saddr, this wont change in the
future. We only need to make sure our flowi4 (saddr,daddr) fields wont
break the rule.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
Next step is to speedup route lookup in input path
include/net/flow.h | 5 ++++-
net/ipv4/ip_output.c | 21 +++++++++++++++++----
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/include/net/flow.h b/include/net/flow.h
index a094477..9192d69 100644
--- a/include/net/flow.h
+++ b/include/net/flow.h
@@ -59,8 +59,11 @@ struct flowi4 {
#define flowi4_proto __fl_common.flowic_proto
#define flowi4_flags __fl_common.flowic_flags
#define flowi4_secid __fl_common.flowic_secid
- __be32 daddr;
+
+ /* (saddr,daddr) must be grouped, same order as in IP header */
__be32 saddr;
+ __be32 daddr;
+
union flowi_uli uli;
#define fl4_sport uli.ports.sport
#define fl4_dport uli.ports.dport
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 0bc95f3..0d5e567 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -319,6 +319,20 @@ int ip_output(struct sk_buff *skb)
!(IPCB(skb)->flags & IPSKB_REROUTED));
}
+/*
+ * copy saddr and daddr, possibly using 64bit load/stores
+ * Equivalent to :
+ * iph->saddr = fl4->saddr;
+ * iph->daddr = fl4->daddr;
+ */
+static void ip_copy_addrs(struct iphdr *iph, const struct flowi4 *fl4)
+{
+ BUILD_BUG_ON(offsetof(typeof(*fl4), daddr) !=
+ offsetof(typeof(*fl4), saddr) + sizeof(fl4->saddr));
+ memcpy(&iph->saddr, &fl4->saddr,
+ sizeof(fl4->saddr) + sizeof(fl4->daddr));
+}
+
int ip_queue_xmit(struct sk_buff *skb, struct flowi *fl)
{
struct sock *sk = skb->sk;
@@ -381,8 +395,8 @@ packet_routed:
iph->frag_off = 0;
iph->ttl = ip_select_ttl(inet, &rt->dst);
iph->protocol = sk->sk_protocol;
- iph->saddr = fl4->saddr;
- iph->daddr = fl4->daddr;
+ ip_copy_addrs(iph, fl4);
+
/* Transport layer set skb->h.foo itself. */
if (inet_opt && inet_opt->opt.optlen) {
@@ -1337,8 +1351,7 @@ struct sk_buff *__ip_make_skb(struct sock *sk,
ip_select_ident(iph, &rt->dst, sk);
iph->ttl = ttl;
iph->protocol = sk->sk_protocol;
- iph->saddr = fl4->saddr;
- iph->daddr = fl4->daddr;
+ ip_copy_addrs(iph, fl4);
if (opt) {
iph->ihl += opt->optlen>>2;
^ permalink raw reply related
* Re: [PATCH] net: net_device flags is an unsigned int
From: David Miller @ 2011-12-01 5:05 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1322714894.2577.19.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 01 Dec 2011 05:48:14 +0100
> Le mercredi 30 novembre 2011 à 23:39 -0500, David Miller a écrit :
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Thu, 01 Dec 2011 05:34:37 +0100
>>
>> > - unsigned short old_flags = dev->flags;
>> > + typeof(dev->flags) old_flags = dev->flags;
>>
>> Please, create netdev_flags_t or similar, anything but this :-)
>
> Hmm, I thought Linus hated types like this...
Yes, it is true. But look at netdev_features_t
> Or how explain we dont have jiffies_t or similar ? ;)
:-)
Like you I just want something that automatically tracks any future
changes to the type. However I want something that doesn't look so
ugly like that typeof() thing.
Sure, use typeof() in macros, you can hide it in such places.
But please not in plain sight in *.c files.
^ permalink raw reply
* Re: Bug in computing data_len in tcp_sendmsg?
From: Tom Herbert @ 2011-12-01 5:09 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Netdev List, David Miller
In-Reply-To: <1322713032.2577.7.camel@edumazet-laptop>
> Or the "bug" was to assume that skb was headless.
> It was true until recently.
>
> We recently added commit f07d960df33c5aef
> (tcp: avoid frag allocation for small frames)
>
> to avoid page allocation for small frames.
>
> So now, skb can contain in head part of tcp data.
Yes, reverting that patch seems to fix the problem. Eric, do you have
an idea what should be used to determine length of headers in an skb
now (mac through transport).
^ permalink raw reply
* RE: ebtables on a stick
From: Greg Scott @ 2011-12-01 5:46 UTC (permalink / raw)
To: Michal Soltys, David Lamparter; +Cc: netdev
In-Reply-To: <4ED566A8.2000108@ziu.info>
Well this is frustrating. Now my public host can communicate anywhere it wants internally but nothing outside. Maddening - the exact opposite problem I had before.
Here is the config as it sits right now:
Public IP host (a Windows XP system placeholder for now)
IP 1.2.115.157, default gw 1.2.115.146.
My test internal host - 192.168.10.2. This one is an ordinary Windows server.
Firewall eth0 - 1.2.115.146/28
Firewall eth1 - 192.168.10.1.
/sbin/ip neigh add proxy 1.2.115.157 dev eth0
/sbin/ip route add 1.2.115.157/32 dev eth1
As a troubleshooting step, I also put in:
/sbin/ip addr add 1.2.115.146/28 dev eth1; so now both eth0 and eth1 have the same IP Address. This feels ugly and I think I'll take it out because it made no difference.
All evidence of ebtables rules and brnn interfaces are gone.
And the relevant iptables rules:
$IPTABLES -t nat -A POSTROUTING -s $1.2.115.157 -j ACCEPT
$IPTABLES -A FORWARD -s 1.2.115.157 -j ACCEPT
$IPTABLES -A FORWARD -s 192.168.10.0/24 -d 1.2.115.157 -j ACCEPT
$IPTABLES -A FORWARD -p TCP --dport 1720 -d $ADR -j allowed
$IPTABLES -A FORWARD -p TCP -s $MGMT_IP -d $ADR -j allowed
$MGMT_IP is the public side of my home office.
And finally:
$IPTABLES -t nat -A PREROUTING -d 1.2.115.157 -j ACCEPT
When my public host pings, say, google, watching on the firewall with tcpdump, I see the ICMP echo request come in on eth1 and go out eth0. So far so good. The ICMP echo reply comes back on eth0, still good. But I never forward it over to eth1 and it dies right there. The public host never sees the reply.
Nothing nats to/from this address. Tcpdump shows the IP Addresses I expect to see. And I don't have any "-t raw -j NOTRACK" stuff because I will eventually want to use the H.323 conntrack helper with this.
Maybe a good night's sleep will help.
- Greg
^ permalink raw reply
* Re: Is there any necessary to add multicast route for a loopback device?
From: Li Wei @ 2011-12-01 6:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1322714206.2577.13.camel@edumazet-laptop>
Eric Dumazet wrote:
> Le jeudi 01 décembre 2011 à 12:31 +0800, Li Wei a écrit :
>>> From: Li Wei <lw@cn.fujitsu.com>
>>> Date: Thu, 01 Dec 2011 10:30:00 +0800
>>>
>>>> what's your opinion?
>>> I have many higher priority tasks than this issue, so it is a poor
>>> idea to try and force me to look into this.
>>>
>>> If no other developer cares to answer, maybe it isn't all that
>>> important.
>>>
>>>
>> My apologize :(
>
> It would help us if you provide a test program an setup script, because
> we have litle time to figure out what exact problem you hit.
>
>
>
>
>
Thanks Eric!
The following is the test code:
================================= cut ====================================
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <errno.h>
#define MADDR "ff00::00"
int main(int argc, char **argv) {
struct ipv6_mreq mreq;
struct in6_addr addr;
unsigned int mcast_if;
int sk;
if((sk = socket(AF_INET6, SOCK_DGRAM, 0)) == -1) {
printf("socket\n");
exit(1);
}
inet_pton(AF_INET6, MADDR, &addr);
mreq.ipv6mr_multiaddr = addr;
printf("== join a multicast group with the interface index is specified as 0 ==\n");
mreq.ipv6mr_interface = 0;
if (setsockopt(sk, IPPROTO_IPV6, IPV6_JOIN_GROUP,
(char *) &mreq, sizeof(mreq)) == -1) {
perror("setsockopt IPV6_JOIN_GROUP");
exit(1);
}
close(sk);
printf("OK\n");
return 0;
}
================================= cut ====================================
My aim is to join a multicast group without the interface index specified, as the RFC 3493
(5.2 Sending and Receiving Multicast Packets) said "If the interface index is specified as 0,
the kernel chooses the local interface.".
When this test run on Fedora 15(ipv6 enabled), it failed and return error ENODEV.
This problem can be reproduced by the following steps:
1. enable ipv6 if you haven't
# modprobe ipv6
2. make all network interfaces down
# ip link set lo down; ip link set eth0 down; ...
3. set a ipv6 address for lo
# ip addr add ::1/128 dev lo
4. make all interfaces up
# ip link set lo up; ip link set eth0 up; ...
run test and it will return ENODEV
^ permalink raw reply
* Re: Integration of Open vSwitch
From: John Fastabend @ 2011-12-01 6:41 UTC (permalink / raw)
To: Eric Dumazet
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Chris Wright,
Herbert Xu, netdev, jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org,
Stephen Hemminger, David Miller
In-Reply-To: <1322659299.2403.19.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 11/30/2011 5:21 AM, Eric Dumazet wrote:
> Le mercredi 30 novembre 2011 à 08:14 -0500, jamal a écrit :
>> On Wed, 2011-11-30 at 15:00 +0800, Herbert Xu wrote:
>>
>>
>>> The other factor I considered is scalability. The OVS code as is
>>> is not really friendly to SMP/NUMA scalability (but as Eric pointed,
>>> neither is the classifier/action layer).
>>
>> Did you mean the qdisc funnel-to-interface part which Eric is hopefully
>> going to work on now that bql is in? classifier/action happens way
>> before that.
>
> Actually I am waiting for John work on this area, before wasting my
> time ;)
>
I'll try to get these out in the next couple days. Got a few qdiscs
running without the qdisc lock today. After I get some real numbers
and make them at least a bit more presentable I'll post them so
folks can let me know if they think its the right approach.
Thanks,
John.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH net-next] ipv4: use a 64bit load/store in output path
From: David Miller @ 2011-12-01 6:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1322715653.2577.25.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 01 Dec 2011 06:00:53 +0100
> gcc compiler is smart enough to use a single load/store if we
> memcpy(dptr, sptr, 8) on x86_64, regardless of
> CONFIG_CC_OPTIMIZE_FOR_SIZE
>
> In IP header, daddr immediately follows saddr, this wont change in the
> future. We only need to make sure our flowi4 (saddr,daddr) fields wont
> break the rule.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Hmmm, this triggers a strange new build warning:
net/dccp/ipv4.c: In function ‘dccp_v4_route_skb’:
net/dccp/ipv4.c:481:3: warning: initialized field with side-effects overwritten [enabled by default]
net/dccp/ipv4.c:481:3: warning: (near initialization for ‘fl4’) [enabled by default]
^ permalink raw reply
* Re: [PATCH] can: Update logging style
From: Oliver Hartkopp @ 2011-12-01 6:56 UTC (permalink / raw)
To: Joe Perches
Cc: Marc Kleine-Budde, Urs Thuermann, David S. Miller, linux-can,
netdev, linux-kernel
In-Reply-To: <1322677438.10023.7.camel@Joe-Laptop>
On 30.11.2011 19:23, Joe Perches wrote:
> Use pr_fmt, pr_<level> and pr_<level>_ratelimited.
> Coalesce format strings.
>
> V2: Appease Oliver Hartkopp by adding "can" to the banner output.
>
> Signed-off-by: Joe Perches <joe@perches.com>
>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Thanks Joe
> ---
>
>> IMO if you want to use pr_fmt() it should at least look like this:
>> can: controller area network core (rev 20090105 abi 8)
>> NET: Registered protocol family 29
>> can_raw: can raw protocol (rev 20090105)
>> can_gw: can netlink gateway (rev 20101209)
>> can_bcm: can broadcast manager protocol (rev 20090105 t)
>>
>> I'm fine with using pr_fmt() for error/warning output but not for the banner
>> in the currently suggested way.
>
> I think it's duplicative, but it's not my code.
>
> net/can/af_can.c | 31 ++++++++++++++-----------------
> net/can/bcm.c | 14 ++++++++------
> net/can/gw.c | 6 ++++--
> net/can/proc.c | 8 ++++----
> net/can/raw.c | 8 +++++---
> 5 files changed, 35 insertions(+), 32 deletions(-)
>
> diff --git a/net/can/af_can.c b/net/can/af_can.c
> index 0ce2ad0..c4f0da5 100644
> --- a/net/can/af_can.c
> +++ b/net/can/af_can.c
> @@ -40,6 +40,8 @@
> *
> */
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/kmod.h>
> @@ -62,8 +64,8 @@
>
> #include "af_can.h"
>
> -static __initdata const char banner[] = KERN_INFO
> - "can: controller area network core (" CAN_VERSION_STRING ")\n";
> +static __initdata const char banner[] =
> + "controller area network core (" CAN_VERSION_STRING ")";
>
> MODULE_DESCRIPTION("Controller Area Network PF_CAN core");
> MODULE_LICENSE("Dual BSD/GPL");
> @@ -161,8 +163,8 @@ static int can_create(struct net *net, struct socket *sock, int protocol,
> * return -EPROTONOSUPPORT
> */
> if (err)
> - printk_ratelimited(KERN_ERR "can: request_module "
> - "(can-proto-%d) failed.\n", protocol);
> + pr_err_ratelimited("request_module (can-proto-%d) failed\n",
> + protocol);
>
> cp = can_get_proto(protocol);
> }
> @@ -505,8 +507,7 @@ void can_rx_unregister(struct net_device *dev, canid_t can_id, canid_t mask,
>
> d = find_dev_rcv_lists(dev);
> if (!d) {
> - printk(KERN_ERR "BUG: receive list not found for "
> - "dev %s, id %03X, mask %03X\n",
> + pr_err("BUG: receive list not found for dev %s, id %03X, mask %03X\n",
> DNAME(dev), can_id, mask);
> goto out;
> }
> @@ -532,8 +533,7 @@ void can_rx_unregister(struct net_device *dev, canid_t can_id, canid_t mask,
> */
>
> if (!next) {
> - printk(KERN_ERR "BUG: receive list entry not found for "
> - "dev %s, id %03X, mask %03X\n",
> + pr_err("BUG: receive list entry not found for dev %s, id %03X, mask %03X\n",
> DNAME(dev), can_id, mask);
> r = NULL;
> goto out;
> @@ -701,8 +701,7 @@ int can_proto_register(const struct can_proto *cp)
> int err = 0;
>
> if (proto < 0 || proto >= CAN_NPROTO) {
> - printk(KERN_ERR "can: protocol number %d out of range\n",
> - proto);
> + pr_err("protocol number %d out of range\n", proto);
> return -EINVAL;
> }
>
> @@ -713,8 +712,7 @@ int can_proto_register(const struct can_proto *cp)
> mutex_lock(&proto_tab_lock);
>
> if (proto_tab[proto]) {
> - printk(KERN_ERR "can: protocol %d already registered\n",
> - proto);
> + pr_err("protocol %d already registered\n", proto);
> err = -EBUSY;
> } else
> RCU_INIT_POINTER(proto_tab[proto], cp);
> @@ -769,8 +767,7 @@ static int can_notifier(struct notifier_block *nb, unsigned long msg,
> /* create new dev_rcv_lists for this device */
> d = kzalloc(sizeof(*d), GFP_KERNEL);
> if (!d) {
> - printk(KERN_ERR
> - "can: allocation of receive list failed\n");
> + pr_err("allocation of receive list failed\n");
> return NOTIFY_DONE;
> }
> BUG_ON(dev->ml_priv);
> @@ -790,8 +787,8 @@ static int can_notifier(struct notifier_block *nb, unsigned long msg,
> dev->ml_priv = NULL;
> }
> } else
> - printk(KERN_ERR "can: notifier: receive list not "
> - "found for dev %s\n", dev->name);
> + pr_err("notifier: receive list not found for dev %s\n",
> + dev->name);
>
> spin_unlock(&can_rcvlists_lock);
>
> @@ -824,7 +821,7 @@ static struct notifier_block can_netdev_notifier __read_mostly = {
>
> static __init int can_init(void)
> {
> - printk(banner);
> + pr_info("%s\n", banner);
>
> memset(&can_rx_alldev_list, 0, sizeof(can_rx_alldev_list));
>
> diff --git a/net/can/bcm.c b/net/can/bcm.c
> index 151b773..540c804 100644
> --- a/net/can/bcm.c
> +++ b/net/can/bcm.c
> @@ -39,6 +39,8 @@
> *
> */
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/interrupt.h>
> @@ -77,8 +79,8 @@
> (CAN_SFF_MASK | CAN_EFF_FLAG | CAN_RTR_FLAG))
>
> #define CAN_BCM_VERSION CAN_VERSION
> -static __initdata const char banner[] = KERN_INFO
> - "can: broadcast manager protocol (rev " CAN_BCM_VERSION " t)\n";
> +static __initdata const char banner[] =
> + "can broadcast manager protocol (rev " CAN_BCM_VERSION " t)";
>
> MODULE_DESCRIPTION("PF_CAN broadcast manager protocol");
> MODULE_LICENSE("Dual BSD/GPL");
> @@ -729,8 +731,8 @@ static void bcm_rx_unreg(struct net_device *dev, struct bcm_op *op)
> /* mark as removed subscription */
> op->rx_reg_dev = NULL;
> } else
> - printk(KERN_ERR "can-bcm: bcm_rx_unreg: registered device "
> - "mismatch %p %p\n", op->rx_reg_dev, dev);
> + pr_err("%s: registered device mismatch %p %p\n",
> + __func__, op->rx_reg_dev, dev);
> }
>
> /*
> @@ -1606,11 +1608,11 @@ static int __init bcm_module_init(void)
> {
> int err;
>
> - printk(banner);
> + pr_info("%s\n", banner);
>
> err = can_proto_register(&bcm_can_proto);
> if (err < 0) {
> - printk(KERN_ERR "can: registration of bcm protocol failed\n");
> + pr_err("registration of bcm protocol failed\n");
> return err;
> }
>
> diff --git a/net/can/gw.c b/net/can/gw.c
> index 3d79b12..e17253f 100644
> --- a/net/can/gw.c
> +++ b/net/can/gw.c
> @@ -39,6 +39,8 @@
> *
> */
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/types.h>
> @@ -59,7 +61,7 @@
>
> #define CAN_GW_VERSION "20101209"
> static __initdata const char banner[] =
> - KERN_INFO "can: netlink gateway (rev " CAN_GW_VERSION ")\n";
> + "can netlink gateway (rev " CAN_GW_VERSION ")";
>
> MODULE_DESCRIPTION("PF_CAN netlink gateway");
> MODULE_LICENSE("Dual BSD/GPL");
> @@ -913,7 +915,7 @@ static int cgw_remove_job(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
>
> static __init int cgw_module_init(void)
> {
> - printk(banner);
> + pr_info("%s\n", banner);
>
> cgw_cache = kmem_cache_create("can_gw", sizeof(struct cgw_job),
> 0, 0, NULL);
> diff --git a/net/can/proc.c b/net/can/proc.c
> index ba873c3..c3aedf5 100644
> --- a/net/can/proc.c
> +++ b/net/can/proc.c
> @@ -39,6 +39,8 @@
> *
> */
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> #include <linux/module.h>
> #include <linux/proc_fs.h>
> #include <linux/list.h>
> @@ -118,8 +120,7 @@ static unsigned long calc_rate(unsigned long oldjif, unsigned long newjif,
>
> /* see can_stat_update() - this should NEVER happen! */
> if (count > (ULONG_MAX / HZ)) {
> - printk(KERN_ERR "can: calc_rate: count exceeded! %ld\n",
> - count);
> + pr_err("%s: count exceeded! %ld\n", __func__, count);
> return 99999999;
> }
>
> @@ -475,8 +476,7 @@ void can_init_proc(void)
> can_dir = proc_mkdir("can", init_net.proc_net);
>
> if (!can_dir) {
> - printk(KERN_INFO "can: failed to create /proc/net/can . "
> - "CONFIG_PROC_FS missing?\n");
> + pr_info("failed to create /proc/net/can . CONFIG_PROC_FS missing?\n");
> return;
> }
>
> diff --git a/net/can/raw.c b/net/can/raw.c
> index cde1b4a..2875c55 100644
> --- a/net/can/raw.c
> +++ b/net/can/raw.c
> @@ -39,6 +39,8 @@
> *
> */
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/uio.h>
> @@ -56,7 +58,7 @@
>
> #define CAN_RAW_VERSION CAN_VERSION
> static __initdata const char banner[] =
> - KERN_INFO "can: raw protocol (rev " CAN_RAW_VERSION ")\n";
> + "can raw protocol (rev " CAN_RAW_VERSION ")";
>
> MODULE_DESCRIPTION("PF_CAN raw protocol");
> MODULE_LICENSE("Dual BSD/GPL");
> @@ -783,11 +785,11 @@ static __init int raw_module_init(void)
> {
> int err;
>
> - printk(banner);
> + pr_info("%s\n", banner);
>
> err = can_proto_register(&raw_can_proto);
> if (err < 0)
> - printk(KERN_ERR "can: registration of raw protocol failed\n");
> + pr_err("registration of raw protocol failed\n");
>
> return err;
> }
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" 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: [RFC PATCH 00/18] netfilter: IPv6 NAT
From: Krzysztof Olędzki @ 2011-12-01 7:01 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Ulrich Weber, Amos Jeffries, sclark46@earthlink.net,
kaber@trash.net, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <alpine.LNX.2.01.1111301004440.18890@frira.zrqbmnf.qr>
On 2011-11-30 11:07, Jan Engelhardt wrote:
>
> On Wednesday 2011-11-30 01:21, Krzysztof Olędzki wrote:
>>>>
>>>>>> However with NAT you could get some kind of anonymity.
>>>>
>>>> But without NAT you have pretty big chance to have the same IPv6
>>>> *suffix* everywhere, based on you MAC address. without NAT you have
>>>> pretty big chance to have the same IPv6 *suffix* everywhere, based on
>>>> you MAC address.
>>>
>>> Same suffix? Certainly not with [PrivExt...]
>>
>> What if:
>>
>> 1. You or your users don't have modern OS on your device so there is no
>> DHCPv6 or rfc3041/4941 support?
>
> Dedicated separate program (that's what you would probably do on
> Windows XP which lacks DHCPv6, PrivExt and also does not even allow
> manually setting an address via GUI).
Too much effort. Really.
>> 3. You need to have static addresses in your network for access control?
>
> Access control can be done based on MAC within a broadcast domain so
> you don't have to eschew Privacy Extensions if you can do so.
Maybe if you have a very small network - just one or two subnets, one
router... Again - maybe. It is definitely not going to work on a large,
multisite network with many intermediate routers.
All you can do on edge devices is checking client's MAC, requring 802.1X
and making sure that IP matches MAC (and possibly DHCP lease) and
similar things.
Best regards,
Krzysztof Olędzki
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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: [RFC 2/3] if_ether.h: Add IEEE 802.1 Local Experimental Ethertype 1.
From: Rémi Denis-Courmont @ 2011-12-01 7:13 UTC (permalink / raw)
To: netdev
In-Reply-To: <1322685846-7790-3-git-send-email-sjur.brandeland@stericsson.com>
On Wed, 30 Nov 2011 21:44:05 +0100, Sjur Br��ndeland
<sjur.brandeland@stericsson.com> wrote:
> From: Sjur Brændeland <sjur.brandeland@stericsson.com>
>
> Add EthType 0x88b5.
> This Ethertype value is available for public use for prototype and
> vendor-specific protocol development,as defined in Amendment 802a
> to IEEE Std 802.
I don't think you can just go and steal a reserved EtherType. What if some
user-space (using packet sockets) or out-of-tree kernel driver does actual
"experiment" with this type?
Why don't you define your own link-layer, e.g. with a vendor-specific CDC
profile?
--
Rémi Denis-Courmont
http://www.remlab.net/
^ permalink raw reply
* Re: ebtables on a stick
From: David Lamparter @ 2011-12-01 7:14 UTC (permalink / raw)
To: Greg Scott; +Cc: David Lamparter, netdev
In-Reply-To: <925A849792280C4E80C5461017A4B8A2A048F6@mail733.InfraSupportEtc.com>
On Wed, Nov 30, 2011 at 11:46:02PM -0600, Greg Scott wrote:
> Well this is frustrating. Now my public host can communicate anywhere it wants internally but nothing outside. Maddening - the exact opposite problem I had before.
>
> Here is the config as it sits right now:
>
> Public IP host (a Windows XP system placeholder for now)
> IP 1.2.115.157, default gw 1.2.115.146.
Note that since the IP should be 1.2.115.157/_32_, it doesn't make any
difference whether you use 1.2.115.146 for the defgw or 192.168.10.1,
since both are out-of-subnet.
> Firewall eth0 - 1.2.115.146/28
> Firewall eth1 - 192.168.10.1.
>
> /sbin/ip neigh add proxy 1.2.115.157 dev eth0
> /sbin/ip route add 1.2.115.157/32 dev eth1
>
> As a troubleshooting step, I also put in:
> /sbin/ip addr add 1.2.115.146/28 dev eth1; so now both eth0 and eth1 have the same IP Address. This feels ugly and I think I'll take it out because it made no difference.
I agree, please remove.
> And the relevant iptables rules:
>
> $IPTABLES -t nat -A POSTROUTING -s $1.2.115.157 -j ACCEPT
> $IPTABLES -t nat -A PREROUTING -d 1.2.115.157 -j ACCEPT
>
> $IPTABLES -A FORWARD -s 1.2.115.157 -j ACCEPT
Where is the reverse rule of this? -d 1.2.115.157 -j ACCEPT
> $IPTABLES -A FORWARD -s 192.168.10.0/24 -d 1.2.115.157 -j ACCEPT
> $IPTABLES -A FORWARD -p TCP --dport 1720 -d $ADR -j allowed
> $IPTABLES -A FORWARD -p TCP -s $MGMT_IP -d $ADR -j allowed
(what's $ADR?)
[...]
> The ICMP echo reply comes back on eth0, still good. But I never forward it over to eth1 and it dies right there. The public host never sees the reply.
Firewall rules?
-David
^ permalink raw reply
* Re: [GIT PULL v2] Open vSwitch
From: Simon Horman @ 2011-12-01 7:24 UTC (permalink / raw)
To: Herbert Xu
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Fischer, Anna,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org, David Miller
In-Reply-To: <20111130070219.GB32630-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
On Wed, Nov 30, 2011 at 03:02:19PM +0800, Herbert Xu wrote:
> On Tue, Nov 29, 2011 at 10:21:32PM -0800, Jesse Gross wrote:
> >
> > It's userspace which is managing the entries in the kernel hash table
> > and it has some intelligence about aging out entries (and specifically
> > about doing it more aggressively as the number of entries increases),
> > so it's not really unbounded. In practice, userspace actually keeps
> > the number of entries much smaller than the maximum size of the table.
>
> Right, I thought you would have something like this.
>
> But I think you still need to rehash the table periodically, as
> otherwise even with a limited number of entries and attacker could
> construct long chains in a hash bucket, given enough time.
I have done some work on both testing and improving the performance
of Open vSwitch with large number of flows (for some definition of large).
My current opinion is that expanding the hash table beyond its current
maximum size does not seem to yield a performance benefit. This is
primarily because there are other performance issues that come into play
first - in particular the rate at which a dump of statistics for all flows
is made (I intend to fix this, its a user-space problem).
So while I agree that optimizing the hash is a good idea. I don't believe
it is a bottle-neck at this point. Though I could be convinced otherwise if
long collision chains could be constructed with relatively few flows.
Something I had not considered until I rad your email just now.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: use a 64bit load/store in output path
From: Eric Dumazet @ 2011-12-01 7:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111201.014813.1241057161065435427.davem@davemloft.net>
Le jeudi 01 décembre 2011 à 01:48 -0500, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 01 Dec 2011 06:00:53 +0100
>
> > gcc compiler is smart enough to use a single load/store if we
> > memcpy(dptr, sptr, 8) on x86_64, regardless of
> > CONFIG_CC_OPTIMIZE_FOR_SIZE
> >
> > In IP header, daddr immediately follows saddr, this wont change in the
> > future. We only need to make sure our flowi4 (saddr,daddr) fields wont
> > break the rule.
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Hmmm, this triggers a strange new build warning:
>
> net/dccp/ipv4.c: In function ‘dccp_v4_route_skb’:
> net/dccp/ipv4.c:481:3: warning: initialized field with side-effects overwritten [enabled by default]
> net/dccp/ipv4.c:481:3: warning: (near initialization for ‘fl4’) [enabled by default]
Hmm, seems a compiler bug, since following fixes the warning ?
[PATCH net-next] dccp: fix a compiler warning
net/dccp/ipv4.c: In function ‘dccp_v4_route_skb’:
net/dccp/ipv4.c:481:3: warning: initialized field with
side-effects overwritten [enabled by default]
net/dccp/ipv4.c:481:3: warning: (near initialization
for ‘fl4’) [enabled by default]
Reported-by: David Miller <davem@davemloft.net>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/dccp/ipv4.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 3f4e541..1c67fe8 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -474,10 +474,11 @@ static struct dst_entry* dccp_v4_route_skb(struct net *net, struct sock *sk,
struct sk_buff *skb)
{
struct rtable *rt;
+ const struct iphdr *iph = ip_hdr(skb);
struct flowi4 fl4 = {
.flowi4_oif = skb_rtable(skb)->rt_iif,
- .daddr = ip_hdr(skb)->saddr,
- .saddr = ip_hdr(skb)->daddr,
+ .daddr = iph->saddr,
+ .saddr = iph->daddr,
.flowi4_tos = RT_CONN_FLAGS(sk),
.flowi4_proto = sk->sk_protocol,
.fl4_sport = dccp_hdr(skb)->dccph_dport,
^ permalink raw reply related
* [PATCH v2] net: net_device flags is an unsigned int
From: Eric Dumazet @ 2011-12-01 7:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev
commit b00055aacdb ([NET] core: add RFC2863 operstate) changed
net_device flags from unsigned short to unsigned int.
Some core functions still assume its an unsigned short.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/dev.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 5a13edf..2cf02f9 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4539,7 +4539,7 @@ static void dev_change_rx_flags(struct net_device *dev, int flags)
static int __dev_set_promiscuity(struct net_device *dev, int inc)
{
- unsigned short old_flags = dev->flags;
+ unsigned int old_flags = dev->flags;
uid_t uid;
gid_t gid;
@@ -4596,7 +4596,7 @@ static int __dev_set_promiscuity(struct net_device *dev, int inc)
*/
int dev_set_promiscuity(struct net_device *dev, int inc)
{
- unsigned short old_flags = dev->flags;
+ unsigned int old_flags = dev->flags;
int err;
err = __dev_set_promiscuity(dev, inc);
@@ -4623,7 +4623,7 @@ EXPORT_SYMBOL(dev_set_promiscuity);
int dev_set_allmulti(struct net_device *dev, int inc)
{
- unsigned short old_flags = dev->flags;
+ unsigned int old_flags = dev->flags;
ASSERT_RTNL();
@@ -4726,7 +4726,7 @@ EXPORT_SYMBOL(dev_get_flags);
int __dev_change_flags(struct net_device *dev, unsigned int flags)
{
- int old_flags = dev->flags;
+ unsigned int old_flags = dev->flags;
int ret;
ASSERT_RTNL();
@@ -4809,10 +4809,10 @@ void __dev_notify_flags(struct net_device *dev, unsigned int old_flags)
* Change settings on device based state flags. The flags are
* in the userspace exported format.
*/
-int dev_change_flags(struct net_device *dev, unsigned flags)
+int dev_change_flags(struct net_device *dev, unsigned int flags)
{
- int ret, changes;
- int old_flags = dev->flags;
+ int ret;
+ unsigned int changes, old_flags = dev->flags;
ret = __dev_change_flags(dev, flags);
if (ret < 0)
^ permalink raw reply related
* Re: [PATCH next-next 0/2] can: cc770: add support for the Bosch CC770 and Intel AN82527
From: Oliver Hartkopp @ 2011-12-01 7:47 UTC (permalink / raw)
To: David Miller; +Cc: wg, netdev, linux-can, Marc Kleine-Budde, Urs Thuermann
In-Reply-To: <20111130.160727.1989923062226789802.davem@davemloft.net>
On 30.11.2011 22:07, David Miller wrote:
> From: Oliver Hartkopp <socketcan@hartkopp.net>
>>>> Wolfgang Grandegger (2):
>>>> can: cc770: add driver core for the Bosch CC770 and Intel AN82527
>>>> can: cc770: legacy CC770 ISA bus driver
>>>
>>> All applied, thank you.
>>
>>
>> Hello Dave,
>>
>> this patchset was superseded for some time.
>>
>> We're currently in the v4 patchset (dated 2011-11-29).
>>
>> See http://patchwork.ozlabs.org/patch/128244/
>>
>> Do you want to revert the commit or should Wolfgang post a diff patch to get
>> to v4 ??
>
> A not very good job was done here communicating to me what is happening.
> Endless revisions, and not clear indication to me what should or should
> not be applied as a result.
Well in this case i was just astonished why you applied a superseded patch set
- but i must admit that the pile-up of posted versions was a bit confusing.
Even there were platform and devtree patches that needed to be acked by other
maintainers - IMO we should post these patches on netdev only when they are
already acked by the platform/devtree guys.
@Wolfgang/Marc: We should return to discuss the CAN relevant patches on
linux-can@vger.kernel.org before posting them on netdev. Don't know why this
established & good process has changed over the time ...
> I want you guys to appoint someone to be the defacto CAN driver and
> subsystem maintainer who collects and merges all the driver and
> protocol patches into his tree, and acts as the one and only interface
> for me when changes are ready to be included.
I'm also not very happy someone else acking changes of my maintained sources -
sometimes it feels like Wild West to me, who's acking first :-(
To make it clear:
Wolfgang Grandegger maintains drivers/net/can
and
Oliver Hartkopp maintains net/can
As Marc Kleine-Budde is also very active in CAN driver development we should
probably add him to the drivers/net/can maintainers.
We'll continue the discussion on linux-can ML and give an update to the
MAINTAINERS file if we sorted out any changes. So far Wolfgang and me remain
the 'only interface' for you. Sorry for the traffic & confusion on netdev.
Regards,
Oliver
^ permalink raw reply
* Re: Integration of Open vSwitch
From: Simon Horman @ 2011-12-01 7:51 UTC (permalink / raw)
To: Herbert Xu
Cc: dev-yBygre7rU0TnMu66kgdUjQ, Chris Wright, Eric Dumazet, netdev,
jhs-jkUAjuhPggJWk0Htik3J/w, John Fastabend, Stephen Hemminger,
David Miller
In-Reply-To: <20111130134028.GA3226-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
On Wed, Nov 30, 2011 at 09:40:28PM +0800, Herbert Xu wrote:
> On Wed, Nov 30, 2011 at 08:14:51AM -0500, jamal wrote:
> > On Wed, 2011-11-30 at 15:00 +0800, Herbert Xu wrote:
> >
> >
> > > The other factor I considered is scalability. The OVS code as is
> > > is not really friendly to SMP/NUMA scalability (but as Eric pointed,
> > > neither is the classifier/action layer).
> >
> > Did you mean the qdisc funnel-to-interface part which Eric is hopefully
> > going to work on now that bql is in? classifier/action happens way
> > before that.
>
> I actually meant the scalability with adding/deleting flows,
> or in the case with qdiscs, filters.
>
> OVS is quite scalable on the fast-path, but when it comes to
> new flows, you have a bottleneck.
Having done some testing of OVS in relation to both the
number of flows I can stuff into the system and how fast I can do so,
I agree.
As it stands I don't believe that there has been a whole lot
of work so far on optimising for high rates of new flows. I say
this based on a low-hang optimisations I have found (and discussed
on the OVS dev list).
Obviously at some point the low-hanging fruit can all be picked and
making things faster becomes more difficult. And it seems to me
that the user-space controller is only single threaded and that
is a significant bottle-neck to scaling flow creation beyond some point.
But I also suspect there are lot of use-cases for OVS where the
current code scales sufficiently.
^ permalink raw reply
* Re: [GIT PULL v2] Open vSwitch
From: Herbert Xu @ 2011-12-01 7:52 UTC (permalink / raw)
To: Simon Horman
Cc: Jesse Gross, Fischer, Anna, jhs@mojatatu.com, David Miller,
netdev@vger.kernel.org, dev@openvswitch.org
In-Reply-To: <20111201072418.GA18436@verge.net.au>
On Thu, Dec 01, 2011 at 04:24:18PM +0900, Simon Horman wrote:
>
> So while I agree that optimizing the hash is a good idea. I don't believe
> it is a bottle-neck at this point. Though I could be convinced otherwise if
> long collision chains could be constructed with relatively few flows.
> Something I had not considered until I rad your email just now.
It's not an optimisation issue, but a security one. If you leave
a hash like this with a constant seed, an attacker would have an
infinite amount of time to find collisions.
Rehashing isn't all that difficult.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Integration of Open vSwitch
From: Simon Horman @ 2011-12-01 7:59 UTC (permalink / raw)
To: Herbert Xu
Cc: dev-yBygre7rU0TnMu66kgdUjQ, Chris Wright, Eric Dumazet, netdev,
jhs-jkUAjuhPggJWk0Htik3J/w, John Fastabend, Stephen Hemminger,
David Miller
In-Reply-To: <20111130070011.GA32630-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
On Wed, Nov 30, 2011 at 03:00:11PM +0800, Herbert Xu wrote:
> On Tue, Nov 29, 2011 at 10:25:34PM -0800, Jesse Gross wrote:
> > Hi Herbert and Jamal (and everyone else),
> >
> > Sorry about starting yet another thread but the other one went in so
> > many directions that I think a lot of things got lost in it. As I
> > mentioned before, I'd like to have a bit of a design discussion of
> > what it would look like if Open vSwitch were to use some of the
> > existing components (and really focus on just that). There were a
> > number of suggestions made about using parts of the bridge, tc,
> > netfilter, etc. and some of them overlap or conflict so I don't quite
> > have a coherent solution in mind. Would you guys mind walking through
> > what each of you envision it looking like?
>
> Personally I think your patches are fine as is.
>
> It would obviously be nice if we could refactor the code as Jamal
> suggested into classifiers/actions, which would allow us to reuse
> them elsewhere, e.g., the flow cache classifier could be merged
> with the GRO mechanism, or something even grander like the unified
> flow cache, while the using standard actions would make all
> existing actions available and generalise OVS into something
> that allows you to direct traffic at will to any destination
> in a system, without having to have a data-path object at all.
>
> But really I don't see immediate gains that are big enough to
> warrant any actions in that direction right now. If we really
> wanted to do that in future we can always add those classifiers
> and actions and migrate things over.
>
> The other factor I considered is scalability. The OVS code as is
> is not really friendly to SMP/NUMA scalability (but as Eric pointed,
> neither is the classifier/action layer). However, if this were to
> become a problem in future I'm sure we could extend either the
> interface as is (e.g., deploying multiqueue netlink sockets), or
> migrate to something else.
>
> So I don't really have any objections to this going into the tree.
I apologies for being rather quiet in this discussion up until now,
the only reason for which being that I have been rather busy with other things.
I have now made a few comments on some other posts with regards to
scaling of flow counts and creation rates as I have done some work
in that area recently.
But as I have been involved in Open vSwitch for a while now I feel it would
remiss of me to not (finally) publicly state that I am supportive of the
current merge effort.
^ permalink raw reply
* Re: [GIT PULL v2] Open vSwitch
From: Simon Horman @ 2011-12-01 8:06 UTC (permalink / raw)
To: Herbert Xu
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Fischer, Anna,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org, David Miller
In-Reply-To: <20111201075237.GA12799-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
On Thu, Dec 01, 2011 at 03:52:37PM +0800, Herbert Xu wrote:
> On Thu, Dec 01, 2011 at 04:24:18PM +0900, Simon Horman wrote:
> >
> > So while I agree that optimizing the hash is a good idea. I don't believe
> > it is a bottle-neck at this point. Though I could be convinced otherwise if
> > long collision chains could be constructed with relatively few flows.
> > Something I had not considered until I rad your email just now.
>
> It's not an optimisation issue, but a security one. If you leave
> a hash like this with a constant seed, an attacker would have an
> infinite amount of time to find collisions.
>
> Rehashing isn't all that difficult.
Sorry for missing the point. Yes, I agree that rehashing makes a lot of sense.
^ permalink raw reply
* [PATCH] dsa: Include linux/if_ether.h to fix build error
From: Axel Lin @ 2011-12-01 8:07 UTC (permalink / raw)
To: linux-kernel; +Cc: David S. Miller, netdev
Include linux/if_ether.h to fix below build errors:
CC arch/arm/mach-kirkwood/common.o
In file included from arch/arm/mach-kirkwood/common.c:19:
include/net/dsa.h: In function 'dsa_uses_dsa_tags':
include/net/dsa.h:192: error: 'ETH_P_DSA' undeclared (first use in this function)
include/net/dsa.h:192: error: (Each undeclared identifier is reported only once
include/net/dsa.h:192: error: for each function it appears in.)
include/net/dsa.h: In function 'dsa_uses_trailer_tags':
include/net/dsa.h:197: error: 'ETH_P_TRAILER' undeclared (first use in this function)
make[1]: *** [arch/arm/mach-kirkwood/common.o] Error 1
make: *** [arch/arm/mach-kirkwood] Error 2
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
include/net/dsa.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index b78db3c..7828ebf 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -11,6 +11,7 @@
#ifndef __LINUX_NET_DSA_H
#define __LINUX_NET_DSA_H
+#include <linux/if_ether.h>
#include <linux/list.h>
#include <linux/timer.h>
#include <linux/workqueue.h>
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH v3 net-next 2/2] netem: add cell concept to simulate special MAC behavior
From: Hagen Paul Pfeifer @ 2011-12-01 8:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Stephen Hemminger
In-Reply-To: <1322710225.2577.1.camel@edumazet-laptop>
On Thu, 01 Dec 2011 04:30:25 +0100, Eric Dumazet wrote:
> Thats a multiply instead of a divide. On many cpus thats a lot faster.
>
> Think about a super packet (TSO) of 65000 bytes and cell_size=64
I've never imagined that I am going to say the following: you are wrong,
Eric! (ok, maybe you are right ;-)
TSO and Netem is a no-go. With netem you are strongly advised to disable
offloading. I mean TSO will result in _one_ delay of several minutes,
followed by a burst of packets. Instead of packets spaced by several
seconds (with the rate of 1000byte/s) - which is what you wan't.
To sum up: skb->len is _never_ larger as the MTU for (normal, correct)
network emulation setups with netem. This was the assumption why I
preferred the iterative solution over the div/mod solution.
Did I miss something?
Hagen
^ permalink raw reply
* Re: [PATCH next-next 0/2] can: cc770: add support for the Bosch CC770 and Intel AN82527
From: Wolfgang Grandegger @ 2011-12-01 8:26 UTC (permalink / raw)
To: David Miller
Cc: socketcan-fJ+pQTUTwRTk1uMJSBkQmQ,
linux-can-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w
In-Reply-To: <20111130.160727.1989923062226789802.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 11/30/2011 10:07 PM, David Miller wrote:
> From: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
> Date: Wed, 30 Nov 2011 07:37:08 +0100
>
>> On 30.11.2011 00:39, David Miller wrote:
>>
>>> From: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
>>> Date: Thu, 24 Nov 2011 13:07:26 +0100
>>>
>>>> Already since a while we have support for the Bosch CC770 and Intel
>>>> AN82527 CAN controllers in our out-of-tree Socket-CAN repository.
>>>> It would be nice if somebody could test the driver. Unfortunately,
>>>> I currently do not have hardware at hand. I have not yet ported the
>>>> OF platform driver as it needs further attaention due to the merge
>>>> of the platform and OF platform interface.
>>>>
>>>> Wolfgang Grandegger (2):
>>>> can: cc770: add driver core for the Bosch CC770 and Intel AN82527
>>>> can: cc770: legacy CC770 ISA bus driver
>>>
>>> All applied, thank you.
>>
>>
>> Hello Dave,
>>
>> this patchset was superseded for some time.
>>
>> We're currently in the v4 patchset (dated 2011-11-29).
>>
>> See http://patchwork.ozlabs.org/patch/128244/
>>
>> Do you want to revert the commit or should Wolfgang post a diff patch to get
>> to v4 ??
>
> A not very good job was done here communicating to me what is happening.
> Endless revisions, and not clear indication to me what should or should
> not be applied as a result.
Well, not sure what I should have communicated to you, but ...
> I want you guys to appoint someone to be the defacto CAN driver and
> subsystem maintainer who collects and merges all the driver and
> protocol patches into his tree, and acts as the one and only interface
> for me when changes are ready to be included.
... I agree that this will work better and it hopefully will then also
save your valuable time. We will discuss in the Socket-CAN community who
will/can act as the one and only interface to you.
> I sorted this out by reverting the older changes and applying V5.
>
> But I had to fix things up, when applying patch #3 there are empty
> trailing lines in some of the new files generated, and that causes
> git to complain.
Sorry for the bad quality of my patch series. I will try to do a better
job next time.
Thanks,
Wolfgang.
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Markus Trippelsdorf @ 2011-12-01 8:44 UTC (permalink / raw)
To: Christoph Lameter
Cc: Eric Dumazet, Alex,Shi, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, tj, dri-devel, Alex Deucher, Dave Airlie
In-Reply-To: <20111124085040.GA1677@x4.trippels.de>
On 2011.11.24 at 09:50 +0100, Markus Trippelsdorf wrote:
> On 2011.11.23 at 10:06 -0600, Christoph Lameter wrote:
> > On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:
> >
> > > > FIX idr_layer_cache: Marking all objects used
> > >
> > > Yesterday I couldn't reproduce the issue at all. But today I've hit
> > > exactly the same spot again. (CCing the drm list)
> >
> > Well this is looks like write after free.
> >
> > > =============================================================================
> > > BUG idr_layer_cache: Poison overwritten
> > > -----------------------------------------------------------------------------
> > > Object ffff8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > Object ffff8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > Object ffff8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > Object ffff8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > Object ffff880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
> > > Object ffff880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> >
> > And its an integer sized write of 0. If you look at the struct definition
> > and lookup the offset you should be able to locate the field that
> > was modified.
It also happens with CONFIG_SLAB.
(If someone wants to reproduce the issue, just run a kexec boot loop and
the bug will occur after a few (~10) iterations.)
Dec 1 05:04:52 x4 kernel: [drm] Initialized drm 1.1.0 20060810
Dec 1 05:04:52 x4 kernel: [drm] radeon defaulting to kernel modesetting.
Dec 1 05:04:52 x4 kernel: [drm] radeon kernel modesetting enabled.
Dec 1 05:04:52 x4 kernel: radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Dec 1 05:04:52 x4 kernel: radeon 0000:01:05.0: setting latency timer to 64
Dec 1 05:04:52 x4 kernel: [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
Dec 1 05:04:52 x4 kernel: [drm] register mmio base: 0xFBEE0000
Dec 1 05:04:52 x4 kernel: [drm] register mmio size: 65536
Dec 1 05:04:52 x4 kernel: ATOM BIOS: 113
Dec 1 05:04:52 x4 kernel: radeon 0000:01:05.0: VRAM: 128M 0x00000000C0000000 - 0x00000000C7FFFFFF (128M used)
Dec 1 05:04:52 x4 kernel: radeon 0000:01:05.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF
Dec 1 05:04:52 x4 kernel: [drm] Detected VRAM RAM=128M, BAR=128M
Dec 1 05:04:52 x4 kernel: [drm] RAM width 32bits DDR
Dec 1 05:04:52 x4 kernel: [TTM] Zone kernel: Available graphics memory: 4090750 kiB.
Dec 1 05:04:52 x4 kernel: [TTM] Zone dma32: Available graphics memory: 2097152 kiB.
Dec 1 05:04:52 x4 kernel: [TTM] Initializing pool allocator.
Dec 1 05:04:52 x4 kernel: [drm] radeon: 128M of VRAM memory ready
Dec 1 05:04:52 x4 kernel: [drm] radeon: 512M of GTT memory ready.
Dec 1 05:04:52 x4 kernel: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
Dec 1 05:04:52 x4 kernel: [drm] Driver supports precise vblank timestamp query.
Dec 1 05:04:52 x4 kernel: [drm] radeon: irq initialized.
Dec 1 05:04:52 x4 kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072
Dec 1 05:04:52 x4 kernel: [drm] Loading RS780 Microcode
Dec 1 05:04:52 x4 kernel: [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
Dec 1 05:04:52 x4 kernel: radeon 0000:01:05.0: WB enabled
Dec 1 05:04:52 x4 kernel: Slab corruption: size-1024 start=ffff880216cbc730, len=1024
Dec 1 05:04:52 x4 kernel: Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Dec 1 05:04:52 x4 kernel: Last user: [< (null)>](0x0)
Dec 1 05:04:52 x4 kernel: 0d0: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
Dec 1 05:04:52 x4 kernel: Prev obj: start=ffff880216cbc318, len=1024
Dec 1 05:04:52 x4 kernel: Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Dec 1 05:04:52 x4 kernel: Last user: [< (null)>](0x0)
Dec 1 05:04:52 x4 kernel: 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Dec 1 05:04:52 x4 kernel: 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Dec 1 05:04:52 x4 kernel: Next obj: start=ffff880216cbcb48, len=1024
Dec 1 05:04:52 x4 kernel: Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Dec 1 05:04:52 x4 kernel: Last user: [<ffffffff81299874>](radeon_bo_create+0xb4/0x240)
Dec 1 05:04:52 x4 kernel: 000: 48 cb cb 16 02 88 ff ff 48 cb cb 16 02 88 ff ff H.......H.......
Dec 1 05:04:52 x4 kernel: 010: 02 00 27 00 00 00 00 00 00 00 00 00 00 00 00 00 ..'.............
Dec 1 05:04:52 x4 kernel: [drm] ring test succeeded in 0 usecs
Dec 1 05:04:52 x4 kernel: [drm] radeon: ib pool ready.
Dec 1 05:04:52 x4 kernel: [drm] ib test succeeded in 0 usecs
Dec 1 05:04:52 x4 kernel: [drm] Radeon Display Connectors
Dec 1 05:04:52 x4 kernel: [drm] Connector 0:
Dec 1 05:04:52 x4 kernel: [drm] VGA
Dec 1 05:04:52 x4 kernel: [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
Dec 1 05:04:52 x4 kernel: [drm] Encoders:
Dec 1 05:04:52 x4 kernel: [drm] CRT1: INTERNAL_KLDSCP_DAC1
Dec 1 05:04:52 x4 kernel: [drm] Connector 1:
Dec 1 05:04:52 x4 kernel: [drm] DVI-D
Dec 1 05:04:52 x4 kernel: [drm] HPD3
Dec 1 05:04:52 x4 kernel: [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
Dec 1 05:04:52 x4 kernel: [drm] Encoders:
Dec 1 05:04:52 x4 kernel: [drm] DFP3: INTERNAL_KLDSCP_LVTMA
Dec 1 05:04:52 x4 kernel: [drm] radeon: power management initialized
Dec 1 05:04:52 x4 kernel: [drm] fb mappable at 0xF0142000
Dec 1 05:04:52 x4 kernel: [drm] vram apper at 0xF0000000
Dec 1 05:04:52 x4 kernel: [drm] size 7299072
Dec 1 05:04:52 x4 kernel: [drm] fb depth is 24
Dec 1 05:04:52 x4 kernel: [drm] pitch is 6912
Dec 1 05:04:52 x4 kernel: fbcon: radeondrmfb (fb0) is primary device
Dec 1 05:04:52 x4 kernel: Console: switching to colour frame buffer device 131x105
Dec 1 05:04:52 x4 kernel: fb0: radeondrmfb frame buffer device
Dec 1 05:04:52 x4 kernel: drm: registered panic notifier
Dec 1 05:04:52 x4 kernel: [drm] Initialized radeon 2.12.0 20080528 for 0000:01:05.0 on minor 0
Dec 1 05:09:35 x4 kernel: radeon 0000:01:05.0: WB enabled
Dec 1 05:09:35 x4 kernel: [drm] ring test succeeded in 1 usecs
Dec 1 05:09:35 x4 kernel: [drm] radeon: ib pool ready.
Dec 1 05:09:35 x4 kernel: [drm] ib test succeeded in 0 usecs
Dec 1 05:09:35 x4 kernel: Slab corruption: size-512 start=ffff880216f7e760, len=512
Dec 1 05:09:35 x4 kernel: Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Dec 1 05:09:35 x4 kernel: Last user: [< (null)>](0x0)
Dec 1 05:09:35 x4 kernel: 0a0: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
Dec 1 05:09:35 x4 kernel: Prev obj: start=ffff880216f7e548, len=512
Dec 1 05:09:35 x4 kernel: Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Dec 1 05:09:35 x4 kernel: Last user: [< (null)>](0x0)
Dec 1 05:09:35 x4 kernel: 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Dec 1 05:09:35 x4 kernel: 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Dec 1 05:09:35 x4 kernel: Next obj: start=ffff880216f7e978, len=512
Dec 1 05:09:35 x4 kernel: Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Dec 1 05:09:35 x4 kernel: Last user: [<ffffffff812e519d>](radeon_add_atom_encoder+0x7d/0x280)
Dec 1 05:09:35 x4 kernel: 000: f8 d3 f6 16 02 88 ff ff 18 d8 f6 16 02 88 ff ff ................
Dec 1 05:09:35 x4 kernel: 010: 18 d8 f6 16 02 88 ff ff 0c 00 00 00 e0 e0 e0 e0 ................
Dec 1 05:09:35 x4 kernel: [drm] Radeon Display Connectors
Dec 1 05:09:35 x4 kernel: [drm] Connector 0:
Dec 1 05:09:35 x4 kernel: [drm] VGA
Dec 1 05:09:35 x4 kernel: [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
Dec 1 05:09:35 x4 kernel: [drm] Encoders:
Dec 1 05:09:35 x4 kernel: [drm] CRT1: INTERNAL_KLDSCP_DAC1
Dec 1 05:09:35 x4 kernel: [drm] Connector 1:
Dec 1 05:09:35 x4 kernel: [drm] DVI-D
Dec 1 05:09:35 x4 kernel: [drm] HPD3
Dec 1 05:09:35 x4 kernel: [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
Dec 1 05:09:35 x4 kernel: [drm] Encoders:
Dec 1 05:09:35 x4 kernel: [drm] DFP3: INTERNAL_KLDSCP_LVTMA
Dec 1 05:09:35 x4 kernel: [drm] radeon: power management initialized
Dec 1 05:09:35 x4 kernel: [drm] fb mappable at 0xF0142000
Dec 1 05:09:35 x4 kernel: [drm] vram apper at 0xF0000000
Dec 1 05:09:35 x4 kernel: [drm] size 7299072
Dec 1 05:09:35 x4 kernel: [drm] fb depth is 24
Dec 1 05:09:35 x4 kernel: [drm] pitch is 6912
Dec 1 05:09:35 x4 kernel: fbcon: radeondrmfb (fb0) is primary device
Dec 1 05:09:35 x4 kernel: Console: switching to colour frame buffer device 131x105
Dec 1 05:09:35 x4 kernel: fb0: radeondrmfb frame buffer device
Dec 1 05:09:35 x4 kernel: drm: registered panic notifier
Dec 1 05:09:35 x4 kernel: [drm] Initialized radeon 2.12.0 20080528 for 0000:01:05.0 on minor 0
--
Markus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ 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