* Re: Possible networking regression in 3.6.0
From: Eric Dumazet @ 2012-09-27 21:03 UTC (permalink / raw)
To: Chris Clayton; +Cc: netdev, gpiez
In-Reply-To: <50649567.2010704@googlemail.com>
On Thu, 2012-09-27 at 19:05 +0100, Chris Clayton wrote:
> On 09/27/12 13:14, Eric Dumazet wrote:
> > On Thu, 2012-09-27 at 12:50 +0100, Chris Clayton wrote:
> >> Just for information - I've pulled Linus' tree this morning and the
> >> problem is still present. Also, Gunther Piaz has reported, via the
> >> bugzilla entry, that he too has hit this regression.
> >
> > I tried to reproduce the bug, and my kvm guests have no problem.
> >
> > I guess you need to precisely describe how you setup your network, so
> > that I can reproduce the problem and eventually fix it.
> >
>
> You've seen the bits from my firewall setup script that relate to this
> issue. I start the WinXP client with another script:
>
> #!/bin/sh
> if [ -e $HOME/kvm/var/run/kvm-winxp.pid ]; then
> echo "winxp is already running ..." > /dev/stderr
> exit 1
> fi
>
> # make sure the kvm modules are loaded
> if test -z "$(grep '\<kvm\>' /proc/misc)"; then
> sudo modprobe kvm-intel
> while test -z "$(grep '\<kvm\>' /proc/misc)"; do
> true
> done
> fi
>
> # make sure tun module is loaded
> if test ! -e /dev/net/tun; then
> sudo modprobe tun
> fi
>
> # figure out the cpu to use
> QVER=$(qemu-kvm --version | cut -d' ' -f 4 | sed 's/,/./')
> # assumes major version is 1
> MINORVER=$(echo $QVER | cut -d'.' -f 2)
> if [ $MINORVER -ge 1 ]; then
> CPU="host"
> else
> CPU="qemu64"
> fi
>
> # set up the network interface
> TAPDEV=$(sudo tunctl -b -u $(whoami))
> sudo ifconfig $TAPDEV 192.168.200.254 netmask 255.255.255.0 broadcast
> 192.168.200.255
>
> # start Windows XP
> qemu-kvm -drive file=$HOME/kvm/winxp.qcow2,index=0,cache=none,if=virtio
> -cpu $CPU -smp cores=1,threads=2 -soundhw es1370 \
> -m 768 -net nic,model=virtio,macaddr=$(getmacaddr) -net
> tap,ifname=$TAPDEV -startdate $(date +%Y-%m-%dT%H:%M:%S) \
> -name kxplaptop -pidfile $HOME/kvm/var/run/kvm-winxp.pid $*
>
> # stop the network interface
> sudo ifconfig $TAPDEV down
> sudo tunctl -d $TAPDEV &>/dev/null
>
> # tidy up
> rm -f $HOME/kvm/var/run/kvm-winxp.pid
>
>
> The call to getmacaddr just returns the next in a sequence of mac
> addresses. qemu-kvm is a symlink to /usr/bin/qemu-system-i386. I first
> found the problem whilst running qemu-kvm version 1.1.1 although I've
> since updated to 1.2.0.
>
> By the way, I doubt it will make a difference, but, although my laptop
> has a 64bit CPU, I am running a 32 bit kernel and, obviously, user space.
>
> Let me know if you need anything else.
It works for me.
Hmm, maybe your guest is using DHCP and DHCP fails ?
Could you check ?
^ permalink raw reply
* Netfilter lacks ability to filter packets via Application-origin
From: Chad Gray @ 2012-09-27 21:04 UTC (permalink / raw)
To: netdev@vger.kernel.org
In-Reply-To: <COL002-W8067088C0C0B4682A10A0F39B0@phx.gbl>
Users need the ability for Linux firewall to filter packets based on what
Application they are originating from. This ability is present in Mac and
Windows firewalls, but not Linux.
For example, users would like ability to open Port 80 for Firefox, but keep
Port 80 closed for other applications.
This ability enhances Privacy & Security of the user but also helps to better
inform the user about the comings and goings of internet traffic and what
application/s are causing the traffic.
https://bugzilla.kernel.org/show_bug.cgi?id=47531
^ permalink raw reply
* Re: Possible networking regression in 3.6.0
From: Eric Dumazet @ 2012-09-27 21:17 UTC (permalink / raw)
To: Chris Clayton, David Miller; +Cc: netdev, gpiez
In-Reply-To: <1348779826.5093.1750.camel@edumazet-glaptop>
On Thu, 2012-09-27 at 23:03 +0200, Eric Dumazet wrote:
> On Thu, 2012-09-27 at 19:05 +0100, Chris Clayton wrote:
> > On 09/27/12 13:14, Eric Dumazet wrote:
> > > On Thu, 2012-09-27 at 12:50 +0100, Chris Clayton wrote:
> > >> Just for information - I've pulled Linus' tree this morning and the
> > >> problem is still present. Also, Gunther Piaz has reported, via the
> > >> bugzilla entry, that he too has hit this regression.
> > >
> > > I tried to reproduce the bug, and my kvm guests have no problem.
> > >
> > > I guess you need to precisely describe how you setup your network, so
> > > that I can reproduce the problem and eventually fix it.
> > >
> >
> > You've seen the bits from my firewall setup script that relate to this
> > issue. I start the WinXP client with another script:
> >
> > #!/bin/sh
> > if [ -e $HOME/kvm/var/run/kvm-winxp.pid ]; then
> > echo "winxp is already running ..." > /dev/stderr
> > exit 1
> > fi
> >
> > # make sure the kvm modules are loaded
> > if test -z "$(grep '\<kvm\>' /proc/misc)"; then
> > sudo modprobe kvm-intel
> > while test -z "$(grep '\<kvm\>' /proc/misc)"; do
> > true
> > done
> > fi
> >
> > # make sure tun module is loaded
> > if test ! -e /dev/net/tun; then
> > sudo modprobe tun
> > fi
> >
> > # figure out the cpu to use
> > QVER=$(qemu-kvm --version | cut -d' ' -f 4 | sed 's/,/./')
> > # assumes major version is 1
> > MINORVER=$(echo $QVER | cut -d'.' -f 2)
> > if [ $MINORVER -ge 1 ]; then
> > CPU="host"
> > else
> > CPU="qemu64"
> > fi
> >
> > # set up the network interface
> > TAPDEV=$(sudo tunctl -b -u $(whoami))
> > sudo ifconfig $TAPDEV 192.168.200.254 netmask 255.255.255.0 broadcast
> > 192.168.200.255
> >
> > # start Windows XP
> > qemu-kvm -drive file=$HOME/kvm/winxp.qcow2,index=0,cache=none,if=virtio
> > -cpu $CPU -smp cores=1,threads=2 -soundhw es1370 \
> > -m 768 -net nic,model=virtio,macaddr=$(getmacaddr) -net
> > tap,ifname=$TAPDEV -startdate $(date +%Y-%m-%dT%H:%M:%S) \
> > -name kxplaptop -pidfile $HOME/kvm/var/run/kvm-winxp.pid $*
> >
> > # stop the network interface
> > sudo ifconfig $TAPDEV down
> > sudo tunctl -d $TAPDEV &>/dev/null
> >
> > # tidy up
> > rm -f $HOME/kvm/var/run/kvm-winxp.pid
> >
> >
> > The call to getmacaddr just returns the next in a sequence of mac
> > addresses. qemu-kvm is a symlink to /usr/bin/qemu-system-i386. I first
> > found the problem whilst running qemu-kvm version 1.1.1 although I've
> > since updated to 1.2.0.
> >
> > By the way, I doubt it will make a difference, but, although my laptop
> > has a 64bit CPU, I am running a 32 bit kernel and, obviously, user space.
> >
> > Let me know if you need anything else.
>
> It works for me.
>
> Hmm, maybe your guest is using DHCP and DHCP fails ?
Yes it seems the problem. On the host I tried :
# ip ro get 8.8.8.8 from 192.168.200.1 iif tap1
8.8.8.8 from 192.168.200.1 via 172.30.42.1 dev eth0
cache iif *
So if the guest tries to send a frame to 8.8.8.8 we are going to forward
the packet to eth0
But if the guest tries to send to 255.255.255.255, we try to deliver the
packet to the host itself, instead of broadcasting to eth0
# ip ro get 255.255.255.255 from 192.168.200.1 iif tap1
broadcast 255.255.255.255 from 192.168.200.1 dev lo
cache <local,brd> iif *
David, maybe you'll have an idea ?
Thanks
^ permalink raw reply
* Re: [PATCH 0/7] Add Chelsio T4 firmware configuration file support
From: David Miller @ 2012-09-27 21:56 UTC (permalink / raw)
To: vipul; +Cc: netdev, divy, dm, swise, leedom, felix
In-Reply-To: <1348663182-20190-1-git-send-email-vipul@chelsio.com>
From: Vipul Pandya <vipul@chelsio.com>
Date: Wed, 26 Sep 2012 18:09:35 +0530
> This patch series adds aupport for firmware configuration file for Chelsio T4
> adapters.
>
> The Firmware Configuration file was primarily developed in order to centralize
> all of the configuration, resource allocation, etc. for Unified Wire operation
> where multiple Physical / Virtual Function Drivers would be using a T4 adapter
> simultaneously.
>
> The patch series also has bug fixes which can occur while upgrading the T4
> firmware.
>
> The patch series is built against David Miller's net-next tree.
Series applied.
^ permalink raw reply
* Re: [PATCH v4] lxt PHY: Support for the buggy LXT973 rev A2
From: David Miller @ 2012-09-27 21:58 UTC (permalink / raw)
To: richardcochran; +Cc: christophe.leroy, netdev, linux-kernel
In-Reply-To: <20120925074736.GB2169@netboy.at.omicron.at>
From: Richard Cochran <richardcochran@gmail.com>
Date: Tue, 25 Sep 2012 09:47:36 +0200
> On Tue, Sep 25, 2012 at 08:23:42AM +0200, leroy christophe wrote:
>>
>> A2 chip has phy_id 0x00137a10
>> A3 chip has phy_id 0x00137a11
>
> Okay then, thanks.
>
> Acked-by: Richard Cochran <richardcochran@gmail.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] smsc75xx: fix resume after device reset
From: David Miller @ 2012-09-27 22:00 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev
In-Reply-To: <1348497779-10042-1-git-send-email-steve.glendinning@shawell.net>
From: Steve Glendinning <steve.glendinning@shawell.net>
Date: Mon, 24 Sep 2012 15:42:59 +0100
> On some systems this device fails to properly resume after suspend,
> this patch fixes it by running the usbnet_resume handler.
>
> I suspect this also fixes this bug:
>
> http://code.google.com/p/chromium-os/issues/detail?id=31871
Applied, thanks.
^ permalink raw reply
* [PATCH] IB/ipoib: Add more rtnl_link_ops callbacks
From: Or Gerlitz @ 2012-09-27 22:02 UTC (permalink / raw)
To: davem; +Cc: roland, netdev, kaber, Or Gerlitz
Add the rtnl_link_ops changelink and fill_info callbacks, through
which the admin can now set/get the driver mode, etc policies.
Maintain the proprietary sysfs entries only for legacy childs.
For child devices, set dev->iflink to point to the parent
device ifindex, such that user space tools can now correctly
show the uplink relation as done for vlan, macvlan, etc
devices. Pointed out by Patrick McHardy <kaber@trash.net>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/infiniband/ulp/ipoib/ipoib.h | 3 +
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 34 ++++++++++----
drivers/infiniband/ulp/ipoib/ipoib_main.c | 16 +++++--
drivers/infiniband/ulp/ipoib/ipoib_netlink.c | 60 +++++++++++++++++++++++++-
drivers/infiniband/ulp/ipoib/ipoib_vlan.c | 24 ++++++----
include/linux/if_link.h | 7 +++
6 files changed, 118 insertions(+), 26 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h b/drivers/infiniband/ulp/ipoib/ipoib.h
index 381f51b..8956f6f 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib.h
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h
@@ -520,6 +520,9 @@ int __ipoib_vlan_add(struct ipoib_dev_priv *ppriv, struct ipoib_dev_priv *priv,
int __init ipoib_netlink_init(void);
void __exit ipoib_netlink_fini(void);
+void ipoib_set_umcast(struct net_device *ndev, int umcast_val);
+int ipoib_set_mode(struct net_device *dev, const char *buf);
+
void ipoib_setup(struct net_device *dev);
void ipoib_pkey_poll(struct work_struct *work);
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index 24683fd..ef6d5a3 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -1448,15 +1448,10 @@ static ssize_t show_mode(struct device *d, struct device_attribute *attr,
return sprintf(buf, "datagram\n");
}
-static ssize_t set_mode(struct device *d, struct device_attribute *attr,
- const char *buf, size_t count)
+int ipoib_set_mode(struct net_device *dev, const char *buf)
{
- struct net_device *dev = to_net_dev(d);
struct ipoib_dev_priv *priv = netdev_priv(dev);
- if (!rtnl_trylock())
- return restart_syscall();
-
/* flush paths if we switch modes so that connections are restarted */
if (IPOIB_CM_SUPPORTED(dev->dev_addr) && !strcmp(buf, "connected\n")) {
set_bit(IPOIB_FLAG_ADMIN_CM, &priv->flags);
@@ -1467,7 +1462,8 @@ static ssize_t set_mode(struct device *d, struct device_attribute *attr,
priv->tx_wr.send_flags &= ~IB_SEND_IP_CSUM;
ipoib_flush_paths(dev);
- return count;
+ rtnl_lock();
+ return 0;
}
if (!strcmp(buf, "datagram\n")) {
@@ -1476,14 +1472,32 @@ static ssize_t set_mode(struct device *d, struct device_attribute *attr,
dev_set_mtu(dev, min(priv->mcast_mtu, dev->mtu));
rtnl_unlock();
ipoib_flush_paths(dev);
-
- return count;
+ rtnl_lock();
+ return 0;
}
- rtnl_unlock();
return -EINVAL;
}
+static ssize_t set_mode(struct device *d, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct net_device *dev = to_net_dev(d);
+ int ret;
+
+ if (!rtnl_trylock())
+ return restart_syscall();
+
+ ret = ipoib_set_mode(dev, buf);
+
+ rtnl_unlock();
+
+ if (!ret)
+ return count;
+
+ return ret;
+}
+
static DEVICE_ATTR(mode, S_IWUSR | S_IRUGO, show_mode, set_mode);
int ipoib_cm_add_mode_attr(struct net_device *dev)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index b3e9709..6c5c771 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -1386,12 +1386,9 @@ static ssize_t show_umcast(struct device *dev,
return sprintf(buf, "%d\n", test_bit(IPOIB_FLAG_UMCAST, &priv->flags));
}
-static ssize_t set_umcast(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count)
+void ipoib_set_umcast(struct net_device *ndev, int umcast_val)
{
- struct ipoib_dev_priv *priv = netdev_priv(to_net_dev(dev));
- unsigned long umcast_val = simple_strtoul(buf, NULL, 0);
+ struct ipoib_dev_priv *priv = netdev_priv(ndev);
if (umcast_val > 0) {
set_bit(IPOIB_FLAG_UMCAST, &priv->flags);
@@ -1399,6 +1396,15 @@ static ssize_t set_umcast(struct device *dev,
"by userspace\n");
} else
clear_bit(IPOIB_FLAG_UMCAST, &priv->flags);
+}
+
+static ssize_t set_umcast(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ unsigned long umcast_val = simple_strtoul(buf, NULL, 0);
+
+ ipoib_set_umcast(to_net_dev(dev), umcast_val);
return count;
}
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_netlink.c b/drivers/infiniband/ulp/ipoib/ipoib_netlink.c
index a7dc5ea..42f6756 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_netlink.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_netlink.c
@@ -37,8 +37,60 @@
static const struct nla_policy ipoib_policy[IFLA_IPOIB_MAX + 1] = {
[IFLA_IPOIB_PKEY] = { .type = NLA_U16 },
+ [IFLA_IPOIB_MODE] = { .type = NLA_U16 },
+ [IFLA_IPOIB_UMCAST] = { .type = NLA_U16 },
};
+static int ipoib_fill_info(struct sk_buff *skb, const struct net_device *dev)
+{
+ struct ipoib_dev_priv *priv = netdev_priv(dev);
+ u16 val;
+
+ if (nla_put_u16(skb, IFLA_IPOIB_PKEY, priv->pkey))
+ goto nla_put_failure;
+
+ val = test_bit(IPOIB_FLAG_ADMIN_CM, &priv->flags);
+ if (nla_put_u16(skb, IFLA_IPOIB_MODE, val))
+ goto nla_put_failure;
+
+ val = test_bit(IPOIB_FLAG_UMCAST, &priv->flags);
+ if (nla_put_u16(skb, IFLA_IPOIB_UMCAST, val))
+ goto nla_put_failure;
+
+ return 0;
+
+nla_put_failure:
+ return -EMSGSIZE;
+}
+
+static int ipoib_changelink(struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
+{
+ u16 mode, umcast;
+ int ret = 0;
+
+ if (data[IFLA_IPOIB_MODE]) {
+ mode = nla_get_u16(data[IFLA_IPOIB_MODE]);
+ if (mode == IPOIB_MODE_DATAGRAM)
+ ret = ipoib_set_mode(dev, "datagram\n");
+ else if (mode == IPOIB_MODE_CONNECTED)
+ ret = ipoib_set_mode(dev, "connected\n");
+ else
+ ret = -EINVAL;
+
+ if (ret < 0)
+ goto out_err;
+ }
+
+ if (data[IFLA_IPOIB_UMCAST]) {
+ umcast = nla_get_u16(data[IFLA_IPOIB_UMCAST]);
+ ipoib_set_umcast(dev, umcast);
+ }
+
+out_err:
+ return ret;
+}
+
static int ipoib_new_child_link(struct net *src_net, struct net_device *dev,
struct nlattr *tb[], struct nlattr *data[])
{
@@ -69,6 +121,8 @@ static int ipoib_new_child_link(struct net *src_net, struct net_device *dev,
err = __ipoib_vlan_add(ppriv, netdev_priv(dev), child_pkey, IPOIB_RTNL_CHILD);
+ if (!err && data)
+ err = ipoib_changelink(dev, tb, data);
return err;
}
@@ -87,7 +141,9 @@ static void ipoib_unregister_child_dev(struct net_device *dev, struct list_head
static size_t ipoib_get_size(const struct net_device *dev)
{
- return nla_total_size(2); /* IFLA_IPOIB_PKEY */
+ return nla_total_size(2) + /* IFLA_IPOIB_PKEY */
+ nla_total_size(2) + /* IFLA_IPOIB_MODE */
+ nla_total_size(2); /* IFLA_IPOIB_UMCAST */
}
static struct rtnl_link_ops ipoib_link_ops __read_mostly = {
@@ -97,8 +153,10 @@ static struct rtnl_link_ops ipoib_link_ops __read_mostly = {
.priv_size = sizeof(struct ipoib_dev_priv),
.setup = ipoib_setup,
.newlink = ipoib_new_child_link,
+ .changelink = ipoib_changelink,
.dellink = ipoib_unregister_child_dev,
.get_size = ipoib_get_size,
+ .fill_info = ipoib_fill_info,
};
int __init ipoib_netlink_init(void)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
index 238bbf9..8292554 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
@@ -88,17 +88,21 @@ int __ipoib_vlan_add(struct ipoib_dev_priv *ppriv, struct ipoib_dev_priv *priv,
ipoib_create_debug_files(priv->dev);
- if (ipoib_cm_add_mode_attr(priv->dev))
- goto sysfs_failed;
- if (ipoib_add_pkey_attr(priv->dev))
- goto sysfs_failed;
- if (ipoib_add_umcast_attr(priv->dev))
- goto sysfs_failed;
-
- if (device_create_file(&priv->dev->dev, &dev_attr_parent))
- goto sysfs_failed;
+ /* RTNL childs don't need proprietary sysfs entries */
+ if (type == IPOIB_LEGACY_CHILD) {
+ if (ipoib_cm_add_mode_attr(priv->dev))
+ goto sysfs_failed;
+ if (ipoib_add_pkey_attr(priv->dev))
+ goto sysfs_failed;
+ if (ipoib_add_umcast_attr(priv->dev))
+ goto sysfs_failed;
+
+ if (device_create_file(&priv->dev->dev, &dev_attr_parent))
+ goto sysfs_failed;
+ }
- priv->child_type = type;
+ priv->child_type = type;
+ priv->dev->iflink = ppriv->dev->ifindex;
list_add_tail(&priv->list, &ppriv->child_intfs);
return 0;
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 24c0dd0..4491177 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -404,9 +404,16 @@ struct ifla_port_vsi {
enum {
IFLA_IPOIB_UNSPEC,
IFLA_IPOIB_PKEY,
+ IFLA_IPOIB_MODE,
+ IFLA_IPOIB_UMCAST,
__IFLA_IPOIB_MAX
};
+enum {
+ IPOIB_MODE_DATAGRAM = 0, /* using unreliable datagram QPs */
+ IPOIB_MODE_CONNECTED = 1, /* using connected QPs */
+};
+
#define IFLA_IPOIB_MAX (__IFLA_IPOIB_MAX - 1)
#endif /* _LINUX_IF_LINK_H */
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next 3/3] ipv4: gre: add GRO capability
From: Jesse Gross @ 2012-09-27 22:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1348769294.5093.1566.camel@edumazet-glaptop>
On Thu, Sep 27, 2012 at 11:08 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2012-09-27 at 10:52 -0700, Jesse Gross wrote:
>
>> When I was thinking about doing this, my original plan was to handle
>> GRO/GSO by extending the current handlers to be able to look inside
>> GRE and then loop around to process the inner packet (similar to what
>> is done today with skb_flow_dissect() for RPS). Is there a reason to
>> do it in the device?
>>
>> Pushing it earlier/later in the stack obviously increases the benefit
>> and it will also be more compatible with the forthcoming OVS tunneling
>> hooks, which will be flow based and therefore won't have a device.
>>
>> Also, the next generation of NICs will support this type of thing in
>> hardware so putting the software versions very close to the NIC will
>> give us a more similar abstraction.
>
> This sounds not feasible with all kind of tunnels, for example IPIP
> tunnels, or UDP encapsulation, at least with current stack (not OVS)
Hmm, I think we might be talking about different things since I can't
think of why it wouldn't be feasible (and none of it should be
specific to OVS). What I was planning would result in the creation of
large but still encapsulated packets. The merging would be purely
based on the headers in each layer being the same (as GRO is today) so
the logic of the IP stack, UDP stack, etc. isn't processed until
later.
> Also note that pushing earlier means forcing the checksumming earlier
> and it consumes a lot of cpu cycles. Hopefully NIC will help us in the
> future.
It is a good point that if the packet isn't actually destined to us
then probably none of this is worth it (although I suspect that the
relative number of tunnel packets that are passed through vs.
terminated is fairly low). Many NICs are capable of supplying
CHECKSUM_COMPLETE packets here, even if it is not exposed by the
drivers.
> Using a napi_struct permits to eventually have separate cpus, and things
> like RPS/RSS to split the load.
We should be able to split the load today using RPS since we can look
into the GRE flow once the packet comes off the NIC (assuming that it
is using NAPI).
^ permalink raw reply
* Re: [PATCH net-next 3/3] ipv4: gre: add GRO capability
From: Jesse Gross @ 2012-09-27 22:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1348769990.5093.1584.camel@edumazet-glaptop>
On Thu, Sep 27, 2012 at 11:19 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2012-09-27 at 20:08 +0200, Eric Dumazet wrote:
>
>>
>> This sounds not feasible with all kind of tunnels, for example IPIP
>> tunnels, or UDP encapsulation, at least with current stack (not OVS)
>>
>> Also note that pushing earlier means forcing the checksumming earlier
>> and it consumes a lot of cpu cycles. Hopefully NIC will help us in the
>> future.
>>
>> Using a napi_struct permits to eventually have separate cpus, and things
>> like RPS/RSS to split the load.
>
> Also please note that my implementation doesnt bypass first IP stack
> traversal (and firewalling if any), so its changing nothing in term
> of existing setups.
>
> So packets that should be forwarded will stay as they are (no tunnels
> decapsulation/recapsulation)
>
> Doing this in the generic GRO layer sounds a bit difficult.
We wouldn't actually do the decapsulation at the point of GRO. This
is actually pretty similar to what we do with TCP - we merge TCP
payloads even though we haven't done any real IP processing yet.
However, we do check firewall rules later if we actually hit the IP
stack. GRE would work the same way in this case.
What I'm describing is pretty much exactly what NICs will be doing, so
if that doesn't work we'll have a problem...
^ permalink raw reply
* Re: [PATCH net-next] sparc: bpf_jit_comp: add XOR instruction for BPF JIT JIT
From: David Miller @ 2012-09-27 22:05 UTC (permalink / raw)
To: dxchgb; +Cc: netdev
In-Reply-To: <20120924215753.GA31312@thinkbox>
From: Daniel Borkmann <dxchgb@gmail.com>
Date: Mon, 24 Sep 2012 23:57:54 +0200
> This patch is a follow-up for patch "filter: add XOR instruction for use
> with X/K" that implements BPF SPARC JIT parts for the BPF XOR operation.
>
> Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Looks good, applied, thanks Daniel.
^ permalink raw reply
* [PATCH net-next REPOST] IB/ipoib: Add more rtnl_link_ops callbacks
From: Or Gerlitz @ 2012-09-27 22:06 UTC (permalink / raw)
To: davem; +Cc: roland, netdev, kaber, Or Gerlitz
Add the rtnl_link_ops changelink and fill_info callbacks, through
which the admin can now set/get the driver mode, etc policies.
Maintain the proprietary sysfs entries only for legacy childs.
For child devices, set dev->iflink to point to the parent
device ifindex, such that user space tools can now correctly
show the uplink relation as done for vlan, macvlan, etc
devices. Pointed out by Patrick McHardy <kaber@trash.net>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
removed white space damage that went in by mistake, sorry for that
drivers/infiniband/ulp/ipoib/ipoib.h | 3 +
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 34 ++++++++++----
drivers/infiniband/ulp/ipoib/ipoib_main.c | 16 +++++--
drivers/infiniband/ulp/ipoib/ipoib_netlink.c | 60 +++++++++++++++++++++++++-
drivers/infiniband/ulp/ipoib/ipoib_vlan.c | 24 ++++++----
include/linux/if_link.h | 7 +++
6 files changed, 118 insertions(+), 26 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h b/drivers/infiniband/ulp/ipoib/ipoib.h
index 381f51b..8956f6f 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib.h
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h
@@ -520,6 +520,9 @@ int __ipoib_vlan_add(struct ipoib_dev_priv *ppriv, struct ipoib_dev_priv *priv,
int __init ipoib_netlink_init(void);
void __exit ipoib_netlink_fini(void);
+void ipoib_set_umcast(struct net_device *ndev, int umcast_val);
+int ipoib_set_mode(struct net_device *dev, const char *buf);
+
void ipoib_setup(struct net_device *dev);
void ipoib_pkey_poll(struct work_struct *work);
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index 24683fd..ef6d5a3 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -1448,15 +1448,10 @@ static ssize_t show_mode(struct device *d, struct device_attribute *attr,
return sprintf(buf, "datagram\n");
}
-static ssize_t set_mode(struct device *d, struct device_attribute *attr,
- const char *buf, size_t count)
+int ipoib_set_mode(struct net_device *dev, const char *buf)
{
- struct net_device *dev = to_net_dev(d);
struct ipoib_dev_priv *priv = netdev_priv(dev);
- if (!rtnl_trylock())
- return restart_syscall();
-
/* flush paths if we switch modes so that connections are restarted */
if (IPOIB_CM_SUPPORTED(dev->dev_addr) && !strcmp(buf, "connected\n")) {
set_bit(IPOIB_FLAG_ADMIN_CM, &priv->flags);
@@ -1467,7 +1462,8 @@ static ssize_t set_mode(struct device *d, struct device_attribute *attr,
priv->tx_wr.send_flags &= ~IB_SEND_IP_CSUM;
ipoib_flush_paths(dev);
- return count;
+ rtnl_lock();
+ return 0;
}
if (!strcmp(buf, "datagram\n")) {
@@ -1476,14 +1472,32 @@ static ssize_t set_mode(struct device *d, struct device_attribute *attr,
dev_set_mtu(dev, min(priv->mcast_mtu, dev->mtu));
rtnl_unlock();
ipoib_flush_paths(dev);
-
- return count;
+ rtnl_lock();
+ return 0;
}
- rtnl_unlock();
return -EINVAL;
}
+static ssize_t set_mode(struct device *d, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct net_device *dev = to_net_dev(d);
+ int ret;
+
+ if (!rtnl_trylock())
+ return restart_syscall();
+
+ ret = ipoib_set_mode(dev, buf);
+
+ rtnl_unlock();
+
+ if (!ret)
+ return count;
+
+ return ret;
+}
+
static DEVICE_ATTR(mode, S_IWUSR | S_IRUGO, show_mode, set_mode);
int ipoib_cm_add_mode_attr(struct net_device *dev)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index b3e9709..6c5c771 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -1386,12 +1386,9 @@ static ssize_t show_umcast(struct device *dev,
return sprintf(buf, "%d\n", test_bit(IPOIB_FLAG_UMCAST, &priv->flags));
}
-static ssize_t set_umcast(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count)
+void ipoib_set_umcast(struct net_device *ndev, int umcast_val)
{
- struct ipoib_dev_priv *priv = netdev_priv(to_net_dev(dev));
- unsigned long umcast_val = simple_strtoul(buf, NULL, 0);
+ struct ipoib_dev_priv *priv = netdev_priv(ndev);
if (umcast_val > 0) {
set_bit(IPOIB_FLAG_UMCAST, &priv->flags);
@@ -1399,6 +1396,15 @@ static ssize_t set_umcast(struct device *dev,
"by userspace\n");
} else
clear_bit(IPOIB_FLAG_UMCAST, &priv->flags);
+}
+
+static ssize_t set_umcast(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ unsigned long umcast_val = simple_strtoul(buf, NULL, 0);
+
+ ipoib_set_umcast(to_net_dev(dev), umcast_val);
return count;
}
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_netlink.c b/drivers/infiniband/ulp/ipoib/ipoib_netlink.c
index a7dc5ea..42f6756 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_netlink.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_netlink.c
@@ -37,8 +37,60 @@
static const struct nla_policy ipoib_policy[IFLA_IPOIB_MAX + 1] = {
[IFLA_IPOIB_PKEY] = { .type = NLA_U16 },
+ [IFLA_IPOIB_MODE] = { .type = NLA_U16 },
+ [IFLA_IPOIB_UMCAST] = { .type = NLA_U16 },
};
+static int ipoib_fill_info(struct sk_buff *skb, const struct net_device *dev)
+{
+ struct ipoib_dev_priv *priv = netdev_priv(dev);
+ u16 val;
+
+ if (nla_put_u16(skb, IFLA_IPOIB_PKEY, priv->pkey))
+ goto nla_put_failure;
+
+ val = test_bit(IPOIB_FLAG_ADMIN_CM, &priv->flags);
+ if (nla_put_u16(skb, IFLA_IPOIB_MODE, val))
+ goto nla_put_failure;
+
+ val = test_bit(IPOIB_FLAG_UMCAST, &priv->flags);
+ if (nla_put_u16(skb, IFLA_IPOIB_UMCAST, val))
+ goto nla_put_failure;
+
+ return 0;
+
+nla_put_failure:
+ return -EMSGSIZE;
+}
+
+static int ipoib_changelink(struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
+{
+ u16 mode, umcast;
+ int ret = 0;
+
+ if (data[IFLA_IPOIB_MODE]) {
+ mode = nla_get_u16(data[IFLA_IPOIB_MODE]);
+ if (mode == IPOIB_MODE_DATAGRAM)
+ ret = ipoib_set_mode(dev, "datagram\n");
+ else if (mode == IPOIB_MODE_CONNECTED)
+ ret = ipoib_set_mode(dev, "connected\n");
+ else
+ ret = -EINVAL;
+
+ if (ret < 0)
+ goto out_err;
+ }
+
+ if (data[IFLA_IPOIB_UMCAST]) {
+ umcast = nla_get_u16(data[IFLA_IPOIB_UMCAST]);
+ ipoib_set_umcast(dev, umcast);
+ }
+
+out_err:
+ return ret;
+}
+
static int ipoib_new_child_link(struct net *src_net, struct net_device *dev,
struct nlattr *tb[], struct nlattr *data[])
{
@@ -69,6 +121,8 @@ static int ipoib_new_child_link(struct net *src_net, struct net_device *dev,
err = __ipoib_vlan_add(ppriv, netdev_priv(dev), child_pkey, IPOIB_RTNL_CHILD);
+ if (!err && data)
+ err = ipoib_changelink(dev, tb, data);
return err;
}
@@ -87,7 +141,9 @@ static void ipoib_unregister_child_dev(struct net_device *dev, struct list_head
static size_t ipoib_get_size(const struct net_device *dev)
{
- return nla_total_size(2); /* IFLA_IPOIB_PKEY */
+ return nla_total_size(2) + /* IFLA_IPOIB_PKEY */
+ nla_total_size(2) + /* IFLA_IPOIB_MODE */
+ nla_total_size(2); /* IFLA_IPOIB_UMCAST */
}
static struct rtnl_link_ops ipoib_link_ops __read_mostly = {
@@ -97,8 +153,10 @@ static struct rtnl_link_ops ipoib_link_ops __read_mostly = {
.priv_size = sizeof(struct ipoib_dev_priv),
.setup = ipoib_setup,
.newlink = ipoib_new_child_link,
+ .changelink = ipoib_changelink,
.dellink = ipoib_unregister_child_dev,
.get_size = ipoib_get_size,
+ .fill_info = ipoib_fill_info,
};
int __init ipoib_netlink_init(void)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
index 238bbf9..8292554 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
@@ -88,17 +88,21 @@ int __ipoib_vlan_add(struct ipoib_dev_priv *ppriv, struct ipoib_dev_priv *priv,
ipoib_create_debug_files(priv->dev);
- if (ipoib_cm_add_mode_attr(priv->dev))
- goto sysfs_failed;
- if (ipoib_add_pkey_attr(priv->dev))
- goto sysfs_failed;
- if (ipoib_add_umcast_attr(priv->dev))
- goto sysfs_failed;
-
- if (device_create_file(&priv->dev->dev, &dev_attr_parent))
- goto sysfs_failed;
+ /* RTNL childs don't need proprietary sysfs entries */
+ if (type == IPOIB_LEGACY_CHILD) {
+ if (ipoib_cm_add_mode_attr(priv->dev))
+ goto sysfs_failed;
+ if (ipoib_add_pkey_attr(priv->dev))
+ goto sysfs_failed;
+ if (ipoib_add_umcast_attr(priv->dev))
+ goto sysfs_failed;
+
+ if (device_create_file(&priv->dev->dev, &dev_attr_parent))
+ goto sysfs_failed;
+ }
- priv->child_type = type;
+ priv->child_type = type;
+ priv->dev->iflink = ppriv->dev->ifindex;
list_add_tail(&priv->list, &ppriv->child_intfs);
return 0;
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 24c0dd0..4491177 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -404,9 +404,16 @@ struct ifla_port_vsi {
enum {
IFLA_IPOIB_UNSPEC,
IFLA_IPOIB_PKEY,
+ IFLA_IPOIB_MODE,
+ IFLA_IPOIB_UMCAST,
__IFLA_IPOIB_MAX
};
+enum {
+ IPOIB_MODE_DATAGRAM = 0, /* using unreliable datagram QPs */
+ IPOIB_MODE_CONNECTED = 1, /* using connected QPs */
+};
+
#define IFLA_IPOIB_MAX (__IFLA_IPOIB_MAX - 1)
#endif /* _LINUX_IF_LINK_H */
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 2/2] Fix a typo in PTP_1588_CLOCK_PCH Kconfig help info.
From: David Miller @ 2012-09-27 22:06 UTC (permalink / raw)
To: haicheng.li; +Cc: netdev, tshimizu818, linux-kernel, haicheng.lee
In-Reply-To: <5060F9C4.4050303@linux.intel.com>
From: Haicheng Li <haicheng.li@linux.intel.com>
Date: Tue, 25 Sep 2012 08:24:36 +0800
> From 5911413366d37aafcc19ddfc9c0f2db31855431e Mon Sep 17 00:00:00 2001
> From: Haicheng Li <haicheng.li@linux.intel.com>
> Date: Mon, 24 Sep 2012 15:55:27 +0800
> Subject: [PATCH 2/2] Fix a typo in PTP_1588_CLOCK_PCH Kconfig help
> info.
>
> Signed-off-by: Haicheng Li <haicheng.lee@gmail.com>
> ---
> drivers/ptp/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
> index ffdf712..82c4a26 100644
> --- a/drivers/ptp/Kconfig
> +++ b/drivers/ptp/Kconfig
> @@ -87,6 +87,6 @@ config PTP_1588_CLOCK_PCH
> SO_TIMESTAMPING API.
>
> To compile this driver as a module, choose M here: the module
> - will be called ptp_pch.
> + will be called by pch_ptp.
The original sentence is correct, it is stating the name of the module
that will be built not the module that will call it.
Rather, the "pch_ptp" is what might need to be adjusted.
^ permalink raw reply
* Re: [PATCH 1/2] Fix build error caused by broken PCH_PTP module dependency.
From: David Miller @ 2012-09-27 22:09 UTC (permalink / raw)
To: haicheng.li; +Cc: netdev, tshimizu818, linux-kernel, haicheng.lee
In-Reply-To: <5060F97F.3040809@linux.intel.com>
From: Haicheng Li <haicheng.li@linux.intel.com>
Date: Tue, 25 Sep 2012 08:23:27 +0800
> From 898e3214b3406c620571cedf704719784b0df049 Mon Sep 17 00:00:00 2001
> From: Haicheng Li <haicheng.li@linux.intel.com>
> Date: Mon, 24 Sep 2012 15:52:30 +0800
> Subject: [PATCH 1/2] Fix build error caused by broken PCH_PTP module
> dependency.
>
> The .config is:
> CONFIG_PCH_GBE=y
> CONFIG_PCH_PTP=y
> CONFIG_PTP_1588_CLOCK=m
>
> The build error:
Your patch submissions are of a very low quality.
And the main reason is that you microscopically look at problems and
do not investigate how the same thing might be handled elsewhere.
Therefore you will never become accustomed to the proper way problems
are fixed, and the proper way to submit patches.
Look at how other people submit patches, do any other patch submissions
look like your's having all of this metadata in the message body:
> From 898e3214b3406c620571cedf704719784b0df049 Mon Sep 17 00:00:00 2001
> From: Haicheng Li <haicheng.li@linux.intel.com>
> Date: Mon, 24 Sep 2012 15:52:30 +0800
> Subject: [PATCH 1/2] Fix build error caused by broken PCH_PTP module
> dependency.
No, nobody else does this.
As for this specific patch:
> - depends on PTP_1588_CLOCK_PCH
> + depends on PTP_1588_CLOCK_PCH = PCH_GBE
This is not the correct way to ensure that the module'ness of one
config option meets the module'ness requirements of another.
The correct way is to say something like "&& (PCH_GBE || PCH_GBE=n)"
^ permalink raw reply
* Re: [PATCH net-next 0/4] Tunnel related patches
From: David Miller @ 2012-09-27 22:13 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20120925041222.056704869@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 24 Sep 2012 21:12:22 -0700
> These are a set of small tunnel related patches.
Series applied, with the updated version of patch #4.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] be2net: fix vfs enumeration
From: David Miller @ 2012-09-27 22:14 UTC (permalink / raw)
To: ivecera; +Cc: netdev, sathya.perla, ajit.khaparde
In-Reply-To: <1348577442-7720-1-git-send-email-ivecera@redhat.com>
From: Ivan Vecera <ivecera@redhat.com>
Date: Tue, 25 Sep 2012 14:50:42 +0200
> Current VFs enumeration algorithm used in be_find_vfs does not take domain
> number into the match. The match found in igb/ixgbe is more elegant and
> safe.
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Applied, thanks Ivan.
^ permalink raw reply
* Re: [PATCH linux-next] nf_defrag_ipv6: fix oops on module unloading
From: David Miller @ 2012-09-27 22:18 UTC (permalink / raw)
To: khlebnikov; +Cc: netdev, amwang
In-Reply-To: <20120925160750.30475.77562.stgit@zurg>
From: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date: Tue, 25 Sep 2012 20:07:50 +0400
> fix copy-paste error introduced in linux-next commit
> "ipv6: add a new namespace for nf_conntrack_reasm"
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] qlcnic - Fix scheduling while atomic bug
From: David Miller @ 2012-09-27 22:21 UTC (permalink / raw)
To: Narendra_K; +Cc: netdev, sony.chacko, jitendra.kalsaria, john.r.fastabend
In-Reply-To: <20120925175212.GA1324@fedora-17-guest.blr.amer.dell.com>
Is it really the case that not one Qlogic person feels like ACK'ing
this patch that fixes an obvious bug in their driver for 2 full days?
For real?
^ permalink raw reply
* Re: Netfilter lacks ability to filter packets via Application-origin
From: richard -rw- weinberger @ 2012-09-27 22:25 UTC (permalink / raw)
To: Chad Gray; +Cc: netdev@vger.kernel.org
In-Reply-To: <COL002-W881A56C786C9972B7654E3F3830@phx.gbl>
On Thu, Sep 27, 2012 at 11:04 PM, Chad Gray <chad938@hotmail.com> wrote:
> Users need the ability for Linux firewall to filter packets based on what
> Application they are originating from. This ability is present in Mac and
> Windows firewalls, but not Linux.
>
> For example, users would like ability to open Port 80 for Firefox, but keep
> Port 80 closed for other applications.
You can implement such filters using LSM like SELinux.
> This ability enhances Privacy & Security of the user but also helps to better
> inform the user about the comings and goings of internet traffic and what
> application/s are causing the traffic.
I seriously doubt that.
--
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH] rtlwifi: use %*ph[C] to dump small buffers
From: Larry Finger @ 2012-09-27 22:28 UTC (permalink / raw)
To: Joe Perches
Cc: Andy Shevchenko, Chaoming Li, David S. Miller,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1348677946.15175.8.camel@joe-AO722>
On 09/26/2012 11:45 AM, Joe Perches wrote:
> On Wed, 2012-09-26 at 16:57 +0300, Andy Shevchenko wrote:
>> Signed-off-by: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>
> Hi Andy.
>
> (adding Larry and Chaoming to cc's)
>
> Please use scripts/get_maintainer.pl on your patches to
> see who maintains these files so you can cc them.
>
> One comment below, it looks like a possible endian bug.
> (not in your patch)
>
>> ---
>> drivers/net/wireless/rtlwifi/cam.c | 7 ++-----
>> drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 6 ++----
>> drivers/net/wireless/rtlwifi/rtl8192cu/hw.c | 6 ++----
>> 3 files changed, 6 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/net/wireless/rtlwifi/cam.c b/drivers/net/wireless/rtlwifi/cam.c
>> index 5b4b4d4..6ba9f80 100644
>> --- a/drivers/net/wireless/rtlwifi/cam.c
>> +++ b/drivers/net/wireless/rtlwifi/cam.c
>> @@ -52,11 +52,8 @@ static void rtl_cam_program_entry(struct ieee80211_hw *hw, u32 entry_no,
>> u32 target_content = 0;
>> u8 entry_i;
>>
>> - RT_TRACE(rtlpriv, COMP_SEC, DBG_LOUD,
>> - "key_cont_128:\n %x:%x:%x:%x:%x:%x\n",
>> - key_cont_128[0], key_cont_128[1],
>> - key_cont_128[2], key_cont_128[3],
>> - key_cont_128[4], key_cont_128[5]);
>> + RT_TRACE(rtlpriv, COMP_SEC, DBG_LOUD, "key_cont_128: %*ph\n",
>> + 6, key_cont_128);
>>
>> for (entry_i = 0; entry_i < CAM_CONTENT_COUNT; entry_i++) {
>> target_command = entry_i + CAM_CONTENT_COUNT * entry_no;
>> diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
>> index 86d73b3..932780d 100644
>> --- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
>> +++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
>> @@ -1918,10 +1918,8 @@ static void rtl92ce_update_hal_rate_mask(struct ieee80211_hw *hw,
>> (ratr_index << 28);
>> rate_mask[4] = macid | (shortgi ? 0x20 : 0x00) | 0x80;
>> RT_TRACE(rtlpriv, COMP_RATR, DBG_DMESG,
>> - "Rate_index:%x, ratr_val:%x, %x:%x:%x:%x:%x\n",
>> - ratr_index, ratr_bitmap,
>> - rate_mask[0], rate_mask[1], rate_mask[2], rate_mask[3],
>> - rate_mask[4]);
>> + "Rate_index:%x, ratr_val:%x, %*phC\n",
>> + ratr_index, ratr_bitmap, 5, rate_mask);
>> rtl92c_fill_h2c_cmd(hw, H2C_RA_MASK, 5, rate_mask);
>>
>> if (macid != 0)
>> diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
>> index 4bbb711..7554501 100644
>> --- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
>> +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
>> @@ -2169,10 +2169,8 @@ void rtl92cu_update_hal_rate_mask(struct ieee80211_hw *hw, u8 rssi_level)
>> ratr_index << 28);
>> rate_mask[4] = macid | (shortgi ? 0x20 : 0x00) | 0x80;
>> RT_TRACE(rtlpriv, COMP_RATR, DBG_DMESG,
>> - "Rate_index:%x, ratr_val:%x, %x:%x:%x:%x:%x\n",
>> - ratr_index, ratr_bitmap,
>> - rate_mask[0], rate_mask[1], rate_mask[2], rate_mask[3],
>> - rate_mask[4]);
>> + "Rate_index:%x, ratr_val:%x, %*phC\n",
>> + ratr_index, ratr_bitmap, 5, rate_mask);
>> rtl92c_fill_h2c_cmd(hw, H2C_RA_MASK, 5, rate_mask);
>> }
>>
>
> rate_mask uses:
>
> u32 ratr_bitmap = (u32) mac->basic_rates;
> ...
> u8 rate_mask[5];
> ...
> [sets ratr_bitmap as u32]
> ...
> *(u32 *)&rate_mask = ((ratr_bitmap & 0x0fffffff) |
> ratr_index << 28);
> ...
> rtl92c_fill_h2c_cmd(hw, H2C_RA_MASK, 5, rate_mask);
>
> Looks like a possible endian misuse to me.
After a second look at the code, I don't think this is an endian issue; however,
I am proposing the following changes to remove any doubt:
Index: wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
+++ wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
@@ -1964,8 +1965,9 @@ static void rtl92ce_update_hal_rate_mask
RT_TRACE(rtlpriv, COMP_RATR, DBG_DMESG,
"ratr_bitmap :%x\n", ratr_bitmap);
- *(u32 *)&rate_mask = (ratr_bitmap & 0x0fffffff) |
- (ratr_index << 28);
+ for (i = 0; i < 3; i++)
+ rate_mask[i] = ratr_bitmap & (0xff << (i * 4));
+ rate_mask[3] = (ratr_bitmap & 0x0f000000) | (ratr_index << 28);
rate_mask[4] = macid | (shortgi ? 0x20 : 0x00) | 0x80;
RT_TRACE(rtlpriv, COMP_RATR, DBG_DMESG,
"Rate_index:%x, ratr_val:%x, %*phC\n",
The downstream routine uses this info as an array of u8, thus it is OK. A proper
patch will be sent later. At least we avoid that ugly cast.
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: phy: smsc: Implement PHY config_init for LAN87xx
From: David Miller @ 2012-09-27 22:28 UTC (permalink / raw)
To: otavio; +Cc: marex, netdev, chohnstaedt, fabio.estevam, peppe.cavallaro
In-Reply-To: <CAP9ODKqC5PhkWxuMsFgA019-wZuygr_hhEme_xyP9dy4C6bLmw@mail.gmail.com>
From: Otavio Salvador <otavio@ossystems.com.br>
Date: Thu, 27 Sep 2012 15:21:37 -0300
> On Tue, Sep 25, 2012 at 5:17 PM, Marek Vasut <marex@denx.de> wrote:
>> The LAN8710/LAN8720 chips do have broken the "FlexPWR" smart power-saving
>> capability. Enabling it leads to the PHY not being able to detect Link when
>> cold-started without cable connected. Thus, make sure this is disabled.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>
> Acked-by: Otavio Salvador <otavio@ossystems.com.br>
Applied, thanks.
^ permalink raw reply
* [PATCH] bna: Fix warning false positive.
From: David Miller @ 2012-09-27 22:32 UTC (permalink / raw)
To: netdev
GCC can't see that in all non-error-return paths we do in fact
set *using_dac to something.
Add an explicit initialization to remove this warning:
drivers/net/ethernet/brocade/bna/bnad.c: In function ‘bnad_pci_probe’:
drivers/net/ethernet/brocade/bna/bnad.c:3079:5: warning: ‘using_dac’ may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/net/ethernet/brocade/bna/bnad.c:3233:7: note: ‘using_dac’ was declared here
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/ethernet/brocade/bna/bnad.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c
index b441f33..ce1eac5 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -3268,6 +3268,7 @@ bnad_pci_probe(struct pci_dev *pdev,
* Output : using_dac = 1 for 64 bit DMA
* = 0 for 32 bit DMA
*/
+ using_dac = false;
err = bnad_pci_init(bnad, pdev, &using_dac);
if (err)
goto unlock_mutex;
--
1.7.11.4
^ permalink raw reply related
* You have to fix this
From: David Miller @ 2012-09-27 22:34 UTC (permalink / raw)
To: vipul; +Cc: netdev
You cannot put such monster sized local data objects on the stack:
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: In function ‘t4_memory_rw.constprop.6’:
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:484:1: warning: the frame size of 2056 bytes is larger than 2048 bytes [-Wframe-larger-than=]
That's because of this thing:
__be32 data[MEMWIN0_APERTURE/sizeof(__be32)];
I'm really surprised this didn't show up in any of your test builds.
Or are you ignoring warnings that your changes add?
^ permalink raw reply
* [PATCH] pkt_sched: Fix warning false positives.
From: David Miller @ 2012-09-27 22:36 UTC (permalink / raw)
To: netdev
GCC refuses to recognize that all error control flows do in fact
set err to something.
Add an explicit initialization to shut it up.
net/sched/sch_drr.c: In function ‘drr_enqueue’:
net/sched/sch_drr.c:359:11: warning: ‘err’ may be used uninitialized in this function [-Wmaybe-uninitialized]
net/sched/sch_qfq.c: In function ‘qfq_enqueue’:
net/sched/sch_qfq.c:885:11: warning: ‘err’ may be used uninitialized in this function [-Wmaybe-uninitialized]
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/sched/sch_drr.c | 2 +-
net/sched/sch_qfq.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sched/sch_drr.c b/net/sched/sch_drr.c
index 9ce0b4f..71e50c8 100644
--- a/net/sched/sch_drr.c
+++ b/net/sched/sch_drr.c
@@ -352,7 +352,7 @@ static int drr_enqueue(struct sk_buff *skb, struct Qdisc *sch)
{
struct drr_sched *q = qdisc_priv(sch);
struct drr_class *cl;
- int err;
+ int err = 0;
cl = drr_classify(skb, sch, &err);
if (cl == NULL) {
diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index e4723d3..2556620 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -878,7 +878,7 @@ static int qfq_enqueue(struct sk_buff *skb, struct Qdisc *sch)
{
struct qfq_sched *q = qdisc_priv(sch);
struct qfq_class *cl;
- int err;
+ int err = 0;
cl = qfq_classify(skb, sch, &err);
if (cl == NULL) {
--
1.7.11.4
^ permalink raw reply related
* RE: [PATCH] qlcnic - Fix scheduling while atomic bug
From: Jitendra Kalsaria @ 2012-09-27 22:40 UTC (permalink / raw)
To: Narendra_K@Dell.com, netdev; +Cc: Sony Chacko, john.r.fastabend@intel.com
In-Reply-To: <20120925175212.GA1324@fedora-17-guest.blr.amer.dell.com>
>-----Original Message-----
>From: Narendra_K@Dell.com [mailto:Narendra_K@Dell.com]
>Sent: Tuesday, September 25, 2012 10:53 AM
>To: netdev
>Cc: Sony Chacko; Jitendra Kalsaria; john.r.fastabend@intel.com
>Subject: [PATCH] qlcnic - Fix scheduling while atomic bug
>
>From: Narendra K <narendra_k@dell.com>
>
>In the device close path, 'qlcnic_fw_destroy_ctx' and
>'qlcnic_poll_rsp' call msleep. But 'qlcnic_fw_destroy_ctx' and
>'qlcnic_poll_rsp' are called with 'adapter->tx_clean_lock' spin lock
>held resulting in scheduling while atomic bug causing the following
>trace.
>
>I observed that the commit 012dc19a45b2b9cc2ebd14aaa401cf782c2abba4
>from John Fastabend addresses a similar issue in ixgbevf driver.
>Adopting the same approach used in the commit, this patch uses mdelay
>to address the issue.
>
>[79884.999115] BUG: scheduling while atomic: ip/30846/0x00000002
>[79885.005562] INFO: lockdep is turned off.
>[79885.009958] Modules linked in: qlcnic fuse nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE bnep bluetooth rfkill ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables iptable_nat >nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter ip_tables dcdbas coretemp kvm_intel kvm iTCO_wdt ixgbe iTCO_vendor_support crc32c_intel ghash_clmulni_intel nfsd microcode >sb_edac pcspkr edac_core dca bnx2x shpchp auth_rpcgss nfs_acl lpc_ich mfd_core mdio lockd libcrc32c wmi acpi_pad acpi_power_meter sunrpc uinput sd_mod sr_mod cdrom crc_t10dif ahci libahci libata megaraid_sas usb_storage dm_mirror >dm_region_hash dm_log dm_mod [last unloaded: qlcnic]
>[79885.083608] Pid: 30846, comm: ip Tainted: G W O 3.6.0-rc7+ #1
>[79885.090805] Call Trace:
>[79885.093569] [<ffffffff816764d8>] __schedule_bug+0x68/0x76
>[79885.099699] [<ffffffff8168358e>] __schedule+0x99e/0xa00
>[79885.105634] [<ffffffff81683929>] schedule+0x29/0x70
>[79885.111186] [<ffffffff81680def>] schedule_timeout+0x16f/0x350
>[79885.117724] [<ffffffff811afb7a>] ? init_object+0x4a/0x90
>[79885.123770] [<ffffffff8107c190>] ? __internal_add_timer+0x140/0x140
>[79885.130873] [<ffffffff81680fee>] schedule_timeout_uninterruptible+0x1e/0x20
>[79885.138773] [<ffffffff8107e830>] msleep+0x20/0x30
>[79885.144159] [<ffffffffa04c7fbf>] qlcnic_issue_cmd+0xef/0x290 [qlcnic]
>[79885.151478] [<ffffffffa04c8265>] qlcnic_fw_cmd_destroy_rx_ctx+0x55/0x90 [qlcnic]
>[79885.159868] [<ffffffffa04c92fd>] qlcnic_fw_destroy_ctx+0x2d/0xa0 [qlcnic]
>[79885.167576] [<ffffffffa04bf2ed>] __qlcnic_down+0x11d/0x180 [qlcnic]
>[79885.174708] [<ffffffffa04bf6f8>] qlcnic_close+0x18/0x20 [qlcnic]
>[79885.181547] [<ffffffff8153b4c5>] __dev_close_many+0x95/0xe0
>[79885.187899] [<ffffffff8153b548>] __dev_close+0x38/0x50
>[79885.193761] [<ffffffff81545101>] __dev_change_flags+0xa1/0x180
>[79885.200419] [<ffffffff81545298>] dev_change_flags+0x28/0x70
>[79885.206779] [<ffffffff815531b8>] do_setlink+0x378/0xa00
>[79885.212731] [<ffffffff81354fe1>] ? nla_parse+0x31/0xe0
>[79885.218612] [<ffffffff815558ee>] rtnl_newlink+0x37e/0x560
>[79885.224768] [<ffffffff812cfa19>] ? selinux_capable+0x39/0x50
>[79885.231217] [<ffffffff812cbf98>] ? security_capable+0x18/0x20
>[79885.237765] [<ffffffff81555114>] rtnetlink_rcv_msg+0x114/0x2f0
>[79885.244412] [<ffffffff81551f87>] ? rtnl_lock+0x17/0x20
>[79885.250280] [<ffffffff81551f87>] ? rtnl_lock+0x17/0x20
>[79885.256148] [<ffffffff81555000>] ? __rtnl_unlock+0x20/0x20
>[79885.262413] [<ffffffff81570fc1>] netlink_rcv_skb+0xa1/0xb0
>[79885.268661] [<ffffffff81551fb5>] rtnetlink_rcv+0x25/0x40
>[79885.274727] [<ffffffff815708bd>] netlink_unicast+0x19d/0x220
>[79885.281146] [<ffffffff81570c45>] netlink_sendmsg+0x305/0x3f0
>[79885.287595] [<ffffffff8152b188>] ? sock_update_classid+0x148/0x2e0
>[79885.294650] [<ffffffff81525c2c>] sock_sendmsg+0xbc/0xf0
>[79885.300600] [<ffffffff8152600c>] __sys_sendmsg+0x3ac/0x3c0
>[79885.306853] [<ffffffff8109be23>] ? up_read+0x23/0x40
>[79885.312510] [<ffffffff816896cc>] ? do_page_fault+0x2bc/0x570
>[79885.318968] [<ffffffff81191854>] ? sys_brk+0x44/0x150
>[79885.324715] [<ffffffff811c458c>] ? fget_light+0x24c/0x520
>[79885.330875] [<ffffffff815286f9>] sys_sendmsg+0x49/0x90
>[79885.336707] [<ffffffff8168e429>] system_call_fastpath+0x16/0x1b
>
>Signed-off-by: Narendra K <narendra_k@dell.com>
>---
>The patch applies to latest mainline kernel version 3.6-rc7
>
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
>index b8ead69..2a179d0 100644
>--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
>+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
>@@ -15,7 +15,7 @@ qlcnic_poll_rsp(struct qlcnic_adapter *adapter)
>
> do {
> /* give atleast 1ms for firmware to respond */
>- msleep(1);
>+ mdelay(1);
>
> if (++timeout > QLCNIC_OS_CRB_RETRY_COUNT)
> return QLCNIC_CDRP_RSP_TIMEOUT;
>@@ -601,7 +601,7 @@ void qlcnic_fw_destroy_ctx(struct qlcnic_adapter *adapter)
> qlcnic_fw_cmd_destroy_tx_ctx(adapter);
>
> /* Allow dma queues to drain after context reset */
>- msleep(20);
>+ mdelay(20);
> }
> }
Looks good to me.
--
1.7.10.2
--
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCH] 8139too: add 1013:1211 PCI ID for a strange SMC1211TX.
From: David Miller @ 2012-09-27 22:40 UTC (permalink / raw)
To: wking; +Cc: netdev, jasowang, greearb, joe, linux-kernel
In-Reply-To: <eaafda75f4966acad08dd10e2627d7615b61206c.1348599606.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
Date: Tue, 25 Sep 2012 16:35:54 -0400
> The FCC ID on the board is HEDEN1207DTXR01, which belongs to Accton
> Technology Corporation. This matches the expected 1113 ID. Perhaps
> my board just has a dying EEPROM?
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> I'm not sure if this qualifies as a patch-able issue, but I thought
> I'd send it in in case someone else gets bitten by this.
That indeed looks like a bit flip to me, 0x1013 is Cirrus Logic who,
last time I checked, hasn't made any 8139too network cards :-)
I think I'll pass on this patch until we have someone else hit it.
^ 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