* [PATCH v2 12/19] irda: sh_irda: Enable the driver on all ARM platforms
From: Laurent Pinchart @ 2013-10-29 22:37 UTC (permalink / raw)
To: linux-sh; +Cc: linux-arm-kernel, Samuel Ortiz, netdev
In-Reply-To: <1383086274-11049-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Renesas ARM platforms are transitioning from single-platform to
multi-platform kernels using the new ARCH_SHMOBILE_MULTI. Make the
driver available on all ARM platforms to enable it on both ARCH_SHMOBILE
and ARCH_SHMOBILE_MULTI, and increase build testing coverage with
COMPILE_TEST.
Cc: Samuel Ortiz <samuel@sortiz.org>
Cc: netdev@vger.kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
drivers/net/irda/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig
index 2a30193..e04b907 100644
--- a/drivers/net/irda/Kconfig
+++ b/drivers/net/irda/Kconfig
@@ -403,7 +403,7 @@ config MCS_FIR
config SH_IRDA
tristate "SuperH IrDA driver"
- depends on IRDA && ARCH_SHMOBILE
+ depends on IRDA && (ARM || COMPILE_TEST)
help
Say Y here if your want to enable SuperH IrDA devices.
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH v3 0/4] Fix MDIO bus timeout issues on Dreamplug
From: David Miller @ 2013-10-29 22:54 UTC (permalink / raw)
To: leigh
Cc: thomas.petazzoni, sebastian.hesselbarth, netdev, linux-arm-kernel,
jason
In-Reply-To: <cover.1383038973.git.leigh@solinno.co.uk>
From: Leigh Brown <leigh@solinno.co.uk>
Date: Tue, 29 Oct 2013 09:33:30 +0000
> I think I have addressed all comments.
>
> Changes since v2:
> - Fix coding style in ordio_mdio_wait_ready, as identified by David
> - Remove un-needed operator change in orion_mdio_write, as identified by David
>
> This patchset fixes an issue with the Dreamplug MDIO bus timeout since the
> mv643xx_eth driver was converted to use the mvmdio driver to access the bus.
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [net-next 11/11] i40e: fix error return code in i40e_probe()
From: David Miller @ 2013-10-29 22:57 UTC (permalink / raw)
To: joe; +Cc: jeffrey.t.kirsher, yongjun_wei, netdev, gospo, sassmann
In-Reply-To: <1383066330.2713.20.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Tue, 29 Oct 2013 10:05:30 -0700
> On Tue, 2013-10-29 at 05:02 -0700, Jeff Kirsher wrote:
>> Fix to return -ENOMEM in the memory alloc error handling
>> case instead of 0, as done elsewhere in this function.
>
> trivial note:
>
>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
> []
>> @@ -7204,8 +7204,10 @@ static int i40e_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>> */
>> len = sizeof(struct i40e_vsi *) * pf->hw.func_caps.num_vsis;
>> pf->vsi = kzalloc(len, GFP_KERNEL);
>> - if (!pf->vsi)
>> + if (!pf->vsi) {
>> + err = -ENOMEM;
>> goto err_switch_setup;
>> + }
>
> This might be better as:
>
> pf->vsi = kcalloc(pf->hw.func_caps.num_vsis, struct i40e_vsi *),
> GFP_KERNEL);
>
> and removing the now unused u32 len; declaration.
Agreed but that's a follow-on patch rather than something to block this
pull request.
^ permalink raw reply
* Re: [net-next 00/11][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2013-10-29 22:58 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1383048151-15002-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Oct 2013 05:02:20 -0700
> This series contains updates to vxlan, net, ixgbe, ixgbevf, and i40e.
Pulled, thanks a lot Jeff.
^ permalink raw reply
* Re: [net-next 11/11] i40e: fix error return code in i40e_probe()
From: Joe Perches @ 2013-10-29 23:02 UTC (permalink / raw)
To: David Miller; +Cc: jeffrey.t.kirsher, yongjun_wei, netdev, gospo, sassmann
In-Reply-To: <20131029.185722.1940335622558600585.davem@davemloft.net>
On Tue, 2013-10-29 at 18:57 -0400, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> > On Tue, 2013-10-29 at 05:02 -0700, Jeff Kirsher wrote:
> >> Fix to return -ENOMEM in the memory alloc error handling
> >> case instead of 0, as done elsewhere in this function.
> > trivial note:
> >> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
> > []
> >> @@ -7204,8 +7204,10 @@ static int i40e_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> >> */
> >> len = sizeof(struct i40e_vsi *) * pf->hw.func_caps.num_vsis;
> >> pf->vsi = kzalloc(len, GFP_KERNEL);
> >> - if (!pf->vsi)
> >> + if (!pf->vsi) {
> >> + err = -ENOMEM;
> >> goto err_switch_setup;
> >> + }
> >
> > This might be better as:
> >
> > pf->vsi = kcalloc(pf->hw.func_caps.num_vsis, struct i40e_vsi *),
> > GFP_KERNEL);
> >
> > and removing the now unused u32 len; declaration.
>
> Agreed but that's a follow-on patch rather than something to block this
> pull request.
I don't think any trivial note should block anything
and if a submitter wants to update it later that's
just fine.
^ permalink raw reply
* [PATCH v2] octeon_mgmt: drop redundant mac address check
From: Luka Perkov @ 2013-10-29 23:09 UTC (permalink / raw)
To: netdev; +Cc: Luka Perkov, David Miller
Checking if MAC address is valid using is_valid_ether_addr() is already done in
of_get_mac_address().
Signed-off-by: Luka Perkov <luka@openwrt.org>
Acked-by: David Daney <david.daney@cavium.com>
CC: David Miller <davem@davemloft.net>
---
v1->v2:
* cosmetic commit message fix based on comment from David Miller
---
drivers/net/ethernet/octeon/octeon_mgmt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/octeon/octeon_mgmt.c b/drivers/net/ethernet/octeon/octeon_mgmt.c
index 622aa75..1b326cbc 100644
--- a/drivers/net/ethernet/octeon/octeon_mgmt.c
+++ b/drivers/net/ethernet/octeon/octeon_mgmt.c
@@ -1545,7 +1545,7 @@ static int octeon_mgmt_probe(struct platform_device *pdev)
mac = of_get_mac_address(pdev->dev.of_node);
- if (mac && is_valid_ether_addr(mac))
+ if (mac)
memcpy(netdev->dev_addr, mac, ETH_ALEN);
else
eth_hw_addr_random(netdev);
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2] mvneta: drop redundant mac address check
From: Luka Perkov @ 2013-10-29 23:10 UTC (permalink / raw)
To: netdev; +Cc: Luka Perkov, David Miller
Checking if MAC address is valid using is_valid_ether_addr() is already done in
of_get_mac_address().
Signed-off-by: Luka Perkov <luka@openwrt.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
CC: David Miller <davem@davemloft.net>
---
v1->v2:
* cosmetic commit message fix based on comment from David Miller
---
drivers/net/ethernet/marvell/mvneta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index e35bac7..7d99e695 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2811,7 +2811,7 @@ static int mvneta_probe(struct platform_device *pdev)
}
dt_mac_addr = of_get_mac_address(dn);
- if (dt_mac_addr && is_valid_ether_addr(dt_mac_addr)) {
+ if (dt_mac_addr) {
mac_from = "device tree";
memcpy(dev->dev_addr, dt_mac_addr, ETH_ALEN);
} else {
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2] arc_emac: drop redundant mac address check
From: Luka Perkov @ 2013-10-29 23:11 UTC (permalink / raw)
To: netdev; +Cc: Luka Perkov, Alexey Brodkin, David Miller
Checking if MAC address is valid using is_valid_ether_addr() is already done in
of_get_mac_address(). While at it, reorganize checking so it matches checks in
other drivers.
Signed-off-by: Luka Perkov <luka@openwrt.org>
CC: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
CC: David Miller <davem@davemloft.net>
---
v1->v2:
* cosmetic commit message fix based on comment from David Miller
---
drivers/net/ethernet/arc/emac_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
index 9e16014..d818ded 100644
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -725,10 +725,10 @@ static int arc_emac_probe(struct platform_device *pdev)
/* Get MAC address from device tree */
mac_addr = of_get_mac_address(pdev->dev.of_node);
- if (!mac_addr || !is_valid_ether_addr(mac_addr))
- eth_hw_addr_random(ndev);
- else
+ if (mac_addr)
memcpy(ndev->dev_addr, mac_addr, ETH_ALEN);
+ else
+ eth_hw_addr_random(ndev);
dev_info(&pdev->dev, "MAC address is now %pM\n", ndev->dev_addr);
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH 1/4 net-next] net: phy: add Generic Netlink Ethernet switch configuration API
From: Maxime Bizon @ 2013-10-29 23:12 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Felix Fietkau, Florian Fainelli, Neil Horman, John Fastabend,
netdev, David Miller, Sascha Hauer, John Crispin, Jonas Gorski,
Gary Thomas, Vlad Yasevich, Stephen Hemminger
In-Reply-To: <5267C6B9.4000704@mojatatu.com>
On Wed, 2013-10-23 at 08:53 -0400, Jamal Hadi Salim wrote:
> So exposing the 5-8 ports as netdevs would be useful. Giving access to
> their stats through per-port netdevs etc. i.e a switch/bridge will
While the intent is to make it look familiar to users, IMO this breaks
the rule of the least surprise.
>From a user POV, when you see a netdevice, you expect to be able to
receive or send packets from/to it. The ability to read stats/link is
only a secondary feature.
Wireless subsystem moved away from using dummy/additional netdevices
because it caused confusion.
multiqueue devices forced us to separate struct netdevice and struct
netdev_queue, maybe it's time for more surgery :)
--
Maxime
^ permalink raw reply
* Re: [PATCH net-next] xen-netback: allocate xenvif arrays using vzalloc.
From: Eric Dumazet @ 2013-10-29 23:24 UTC (permalink / raw)
To: Joby Poriyath
Cc: netdev, wei.liu2, ian.campbell, xen-devel, andrew.bennieston,
david.vrabel, malcolm.crossley
In-Reply-To: <20131029184647.GA3261@citrix.com>
On Tue, 2013-10-29 at 18:46 +0000, Joby Poriyath wrote:
> On Tue, Oct 29, 2013 at 08:43:50AM -0700, Eric Dumazet wrote:
> > On Tue, 2013-10-29 at 15:27 +0000, Joby Poriyath wrote:
> > > This will reduce memory pressure when allocating struct xenvif.
> > >
> > > The size of xenvif struct has increased from 168 to 36632 bytes (on x86-32).
> > > See commit b3f980bd827e6e81a050c518d60ed7811a83061d. This resulted in
> > > occasional netdev allocation failure in dom0 with 752MiB RAM, due to
> > > fragmented memory.
> >
> > This looks overkill.
> >
> > Replacing a single allocation of ~36 KB into 5 vmalloc() looks like you
> > did not really tried other things...
> >
> > This should be done generically in alloc_netdev_mqs()
>
> Sorry Eric, I didn't quite understand how this can be generically done.
>
> The netback interfaces are tied to the Xen guests (VMs) and these are created
> when guests are started and deleted when guest are halted.
They are created by alloc_netdev_mqs()
>
> >
> > Take a look at commit 60877a32bce00041
> > ("net: allow large number of tx queues")
> >
>
> I could try allocating using kmalloc and if that fails, then fall back
> to vmalloc.
My point is the patch should be done in net/core, not in your driver.
^ permalink raw reply
* patch "mdio_bus: convert bus code to use dev_groups" added to driver-core tree
From: gregkh @ 2013-10-29 23:25 UTC (permalink / raw)
To: gregkh, broonie, davem, nbowler, netdev
This is a note to let you know that I've just added the patch titled
mdio_bus: convert bus code to use dev_groups
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 4192c74940e23da727eb02b7b4ee779dde2f670a Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Sun, 6 Oct 2013 23:55:41 -0700
Subject: mdio_bus: convert bus code to use dev_groups
The dev_attrs field of struct bus_type is going away soon, dev_groups
should be used instead. This converts the MDIO bus code to use the
correct field.
Cc: David S. Miller <davem@davemloft.net>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Nick Bowler <nbowler@elliptictech.com>
Cc: <netdev@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/phy/mdio_bus.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index dc920974..56178761 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -438,17 +438,19 @@ phy_id_show(struct device *dev, struct device_attribute *attr, char *buf)
return sprintf(buf, "0x%.8lx\n", (unsigned long)phydev->phy_id);
}
+static DEVICE_ATTR_RO(phy_id);
-static struct device_attribute mdio_dev_attrs[] = {
- __ATTR_RO(phy_id),
- __ATTR_NULL
+static struct attribute *mdio_dev_attrs[] = {
+ &dev_attr_phy_id.attr,
+ NULL,
};
+ATTRIBUTE_GROUPS(mdio_dev);
struct bus_type mdio_bus_type = {
.name = "mdio_bus",
.match = mdio_bus_match,
.pm = MDIO_BUS_PM_OPS,
- .dev_attrs = mdio_dev_attrs,
+ .dev_groups = mdio_dev_groups,
};
EXPORT_SYMBOL(mdio_bus_type);
--
1.8.4.3.gca3854a
^ permalink raw reply related
* Re: [PATCH net-next] xen-netback: allocate xenvif arrays using vzalloc.
From: Eric Dumazet @ 2013-10-29 23:32 UTC (permalink / raw)
To: Joby Poriyath
Cc: netdev, wei.liu2, ian.campbell, xen-devel, andrew.bennieston,
david.vrabel, malcolm.crossley
In-Reply-To: <1383089055.4176.1.camel@edumazet-glaptop.roam.corp.google.com>
On Tue, 2013-10-29 at 16:24 -0700, Eric Dumazet wrote:
> On Tue, 2013-10-29 at 18:46 +0000, Joby Poriyath wrote:
> > On Tue, Oct 29, 2013 at 08:43:50AM -0700, Eric Dumazet wrote:
> > > On Tue, 2013-10-29 at 15:27 +0000, Joby Poriyath wrote:
> > > > This will reduce memory pressure when allocating struct xenvif.
> > > >
> > > > The size of xenvif struct has increased from 168 to 36632 bytes (on x86-32).
> > > > See commit b3f980bd827e6e81a050c518d60ed7811a83061d. This resulted in
> > > > occasional netdev allocation failure in dom0 with 752MiB RAM, due to
> > > > fragmented memory.
> > >
> > > This looks overkill.
> > >
> > > Replacing a single allocation of ~36 KB into 5 vmalloc() looks like you
> > > did not really tried other things...
> > >
> > > This should be done generically in alloc_netdev_mqs()
> >
> > Sorry Eric, I didn't quite understand how this can be generically done.
> >
> > The netback interfaces are tied to the Xen guests (VMs) and these are created
> > when guests are started and deleted when guest are halted.
>
> They are created by alloc_netdev_mqs()
Something like the following should be fine.
diff --git a/net/core/dev.c b/net/core/dev.c
index 0054c8c..874a57a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6239,7 +6239,9 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
/* ensure 32-byte alignment of whole construct */
alloc_size += NETDEV_ALIGN - 1;
- p = kzalloc(alloc_size, GFP_KERNEL);
+ p = kzalloc(alloc_size, GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
+ if (!p)
+ p = vzalloc(alloc_size);
if (!p)
return NULL;
@@ -6302,7 +6304,10 @@ free_pcpu:
#endif
free_p:
- kfree(p);
+ if (is_vmalloc_addr(p))
+ vfree(p);
+ else
+ kfree(p);
return NULL;
}
EXPORT_SYMBOL(alloc_netdev_mqs);
@@ -6339,7 +6344,12 @@ void free_netdev(struct net_device *dev)
/* Compatibility with error handling in drivers */
if (dev->reg_state == NETREG_UNINITIALIZED) {
- kfree((char *)dev - dev->padded);
+ char *addr = (char *)dev - dev->padded;
+
+ if (is_vmalloc_addr(addr))
+ vfree(addr);
+ else
+ kfree(addr);
return;
}
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index d954b56..406c54b 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -1259,11 +1259,16 @@ exit:
static void netdev_release(struct device *d)
{
struct net_device *dev = to_net_dev(d);
+ char *addr;
BUG_ON(dev->reg_state != NETREG_RELEASED);
kfree(dev->ifalias);
- kfree((char *)dev - dev->padded);
+ addr = (char *)dev - dev->padded;
+ if (is_vmalloc_addr(addr))
+ vfree(addr);
+ else
+ kfree(addr);
}
static const void *net_namespace(struct device *d)
^ permalink raw reply related
* Re: [PATCH] mvneta: remove double validation of mac address
From: Thomas Petazzoni @ 2013-10-29 23:35 UTC (permalink / raw)
To: Laurent Navet; +Cc: netdev, linux-kernel
In-Reply-To: <1383081906-12342-1-git-send-email-laurent.navet@gmail.com>
Dear Laurent Navet,
On Tue, 29 Oct 2013 22:25:06 +0100, Laurent Navet wrote:
> Mac address validity is already checked in of_get_mac_address().
> No need to do it twice.
>
> Signed-off-by: Laurent Navet <laurent.navet@gmail.com>
Thanks, but an identical patch has been posted by Luka Perkov
<luka@openwrt.org> just a few days ago. See
http://www.spinics.net/lists/netdev/msg255454.html.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 net-next] net: introduce gro_frag_list_enable sysctl
From: David Miller @ 2013-10-29 23:44 UTC (permalink / raw)
To: eric.dumazet; +Cc: christoph.paasch, herbert, netdev, hkchu, mwdalton
In-Reply-To: <1383059555.5464.33.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 29 Oct 2013 08:12:35 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Christoph Paasch and Jerry Chu reported crashes in skb_segment() caused
> by commit 8a29111c7ca6 ("net: gro: allow to build full sized skb")
>
> (Jerry is working on adding native GRO support for tunnels)
>
> skb_segment() only deals with a frag_list chain containing MSS sized
> fragments.
>
> This patch adds support any kind of frag, and adds a new sysctl,
> as clearly the GRO layer should avoid building frag_list skbs
> on a router, as the segmentation is adding cpu overhead.
>
> Note that we could try to reuse page fragments instead of doing
> copy to linear skbs, but this requires a fair amount of work,
> and possible truesize nightmares, as we do not track individual
> (per page fragment) truesizes.
>
> /proc/sys/net/core/gro_frag_list_enable possible values are :
>
> 0 : GRO layer is not allowed to use frag_list to extend skb capacity
> 1 : GRO layer is allowed to use frag_list, but skb_segment()
> automatically sets the sysctl to 0.
> 2 : GRO is allowed to use frag_list, and skb_segment() wont
> clear the sysctl.
>
> Default value is 1 : automatic discovery
>
> Reported-by: Christoph Paasch <christoph.paasch@uclouvain.be>
> Reported-by: Jerry Chu <hkchu@google.com>
> Cc: Michael Dalton <mwdalton@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> v2: added missing sysctl definition in skbuff.c
I do not like the idea of packet actions indirectly changing sysctl
values, even if you document it sufficiently as you have here.
Plus this puts the sysctl change logic in a fast path.
I would suggest instead making it change in response to changes to
ip_forward, as we do with per-device LRO settings. This means that,
like ip_forward, you should also make this sysctl a global + devinet
per-device sysctl.
You might even emit a pr_info() when this logic triggers, and if you
are ambitious enough keep track of the previous GRO sysctl state so
you can restore it if ip_forward is set back to zero.
Thanks.
^ permalink raw reply
* Re: [PATCH] ibm emac: Don't call napi_complete if napi_reschedule failed
From: Alistair Popple @ 2013-10-29 23:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, benh
In-Reply-To: <20131025.191301.1496864269923138314.davem@davemloft.net>
On Fri, 25 Oct 2013 19:13:01 David Miller wrote:
> The mistaken napi_complete() call and the locking change are two different
> bugs, fix them in two different patches.
OK - I've resubmitted as two separate patches.
^ permalink raw reply
* [PATCH 1/2] ibm emac: Don't call napi_complete if napi_reschedule failed
From: Alistair Popple @ 2013-10-29 23:50 UTC (permalink / raw)
To: netdev, davem; +Cc: benh, Alistair Popple
This patch fixes a bug which would trigger the BUG_ON() at
net/core/dev.c:4156. It was found that this was due to continuing
processing in the current poll call even when the call to
napi_reschedule failed, indicating the device was already on the
polling list. This resulted in an extra call to napi_complete which
triggered the BUG_ON().
This patch ensures that we only contine processing rotting packets in
the current mal_poll call if we are not already on the polling list.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
---
drivers/net/ethernet/ibm/emac/mal.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/ibm/emac/mal.c b/drivers/net/ethernet/ibm/emac/mal.c
index 856ea66..dcb623a 100644
--- a/drivers/net/ethernet/ibm/emac/mal.c
+++ b/drivers/net/ethernet/ibm/emac/mal.c
@@ -442,15 +442,11 @@ static int mal_poll(struct napi_struct *napi, int budget)
if (unlikely(mc->ops->peek_rx(mc->dev) ||
test_bit(MAL_COMMAC_RX_STOPPED, &mc->flags))) {
MAL_DBG2(mal, "rotting packet" NL);
- if (napi_reschedule(napi))
- mal_disable_eob_irq(mal);
- else
- MAL_DBG2(mal, "already in poll list" NL);
-
- if (budget > 0)
- goto again;
- else
+ if (!napi_reschedule(napi))
goto more_work;
+
+ mal_disable_eob_irq(mal);
+ goto again;
}
mc->ops->poll_tx(mc->dev);
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] ibm emac: Fix locking for enable/disable eob irq
From: Alistair Popple @ 2013-10-29 23:50 UTC (permalink / raw)
To: netdev, davem; +Cc: benh, Alistair Popple
In-Reply-To: <1383090638-21526-1-git-send-email-alistair@popple.id.au>
Calls to mal_enable_eob_irq perform a read-write-modify of a dcr to
enable device irqs which is protected by a spin lock. However calls to
mal_disable_eob_irq do not take the corresponding lock.
This patch resolves the problem by ensuring that calls to
mal_disable_eob_irq also take the lock.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
---
drivers/net/ethernet/ibm/emac/mal.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/ibm/emac/mal.c b/drivers/net/ethernet/ibm/emac/mal.c
index dcb623a..2d2e1dd 100644
--- a/drivers/net/ethernet/ibm/emac/mal.c
+++ b/drivers/net/ethernet/ibm/emac/mal.c
@@ -263,7 +263,9 @@ static inline void mal_schedule_poll(struct mal_instance *mal)
{
if (likely(napi_schedule_prep(&mal->napi))) {
MAL_DBG2(mal, "schedule_poll" NL);
+ spin_lock(&mal->lock);
mal_disable_eob_irq(mal);
+ spin_unlock(&mal->lock);
__napi_schedule(&mal->napi);
} else
MAL_DBG2(mal, "already in poll" NL);
@@ -445,7 +447,9 @@ static int mal_poll(struct napi_struct *napi, int budget)
if (!napi_reschedule(napi))
goto more_work;
+ spin_lock_irqsave(&mal->lock, flags);
mal_disable_eob_irq(mal);
+ spin_unlock_irqrestore(&mal->lock, flags);
goto again;
}
mc->ops->poll_tx(mc->dev);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v2 net-next] net: introduce gro_frag_list_enable sysctl
From: Jerry Chu @ 2013-10-30 0:03 UTC (permalink / raw)
To: Eric Dumazet
Cc: Christoph Paasch, David Miller, Herbert Xu, netdev,
Michael Dalton
In-Reply-To: <1383059555.5464.33.camel@edumazet-glaptop.roam.corp.google.com>
On Tue, Oct 29, 2013 at 8:12 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Christoph Paasch and Jerry Chu reported crashes in skb_segment() caused
> by commit 8a29111c7ca6 ("net: gro: allow to build full sized skb")
>
> (Jerry is working on adding native GRO support for tunnels)
>
> skb_segment() only deals with a frag_list chain containing MSS sized
> fragments.
>
> This patch adds support any kind of frag, and adds a new sysctl,
> as clearly the GRO layer should avoid building frag_list skbs
> on a router, as the segmentation is adding cpu overhead.
>
> Note that we could try to reuse page fragments instead of doing
> copy to linear skbs, but this requires a fair amount of work,
> and possible truesize nightmares, as we do not track individual
> (per page fragment) truesizes.
>
> /proc/sys/net/core/gro_frag_list_enable possible values are :
>
> 0 : GRO layer is not allowed to use frag_list to extend skb capacity
> 1 : GRO layer is allowed to use frag_list, but skb_segment()
> automatically sets the sysctl to 0.
> 2 : GRO is allowed to use frag_list, and skb_segment() wont
> clear the sysctl.
>
> Default value is 1 : automatic discovery
>
> Reported-by: Christoph Paasch <christoph.paasch@uclouvain.be>
> Reported-by: Jerry Chu <hkchu@google.com>
> Cc: Michael Dalton <mwdalton@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> v2: added missing sysctl definition in skbuff.c
>
> Documentation/sysctl/net.txt | 19 +++++++++++++++++++
> include/linux/netdevice.h | 1 +
> net/core/skbuff.c | 31 ++++++++++++++++++++++---------
> net/core/sysctl_net_core.c | 10 ++++++++++
> 4 files changed, 52 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt
> index 9a0319a82470..8778568ae64e 100644
> --- a/Documentation/sysctl/net.txt
> +++ b/Documentation/sysctl/net.txt
> @@ -87,6 +87,25 @@ sysctl.net.busy_read globally.
> Will increase power usage.
> Default: 0 (off)
>
> +gro_frag_list_enable
> +--------------------
> +
> +GRO layer can build full size GRO packets (~64K of payload) if it is allowed
> +to extend skb using the frag_list pointer. However, this strategy is a win
> +on hosts, where TCP flows are terminated. For a router, using frag_list
> +skbs is not a win because we have to segment skbs before transmit,
> +as most NIC drivers do not support frag_list.
> +As soon as one frag_list skb has to be segmented, this sysctl is automatically
> +changed from 1 to 0.
> +If the value is set to 2, kernel wont change it.
> +
> +Choices : 0 (off),
> + 1 (on, with automatic change to 0)
> + 2 (on, permanent)
> +
> +Default: 1 (on, with automatic downgrade on a router)
> +
> +
> rmem_default
> ------------
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 27f62f746621..b82ff52f301e 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -2807,6 +2807,7 @@ extern int netdev_max_backlog;
> extern int netdev_tstamp_prequeue;
> extern int weight_p;
> extern int bpf_jit_enable;
> +extern int sysctl_gro_frag_list_enable;
>
> bool netdev_has_upper_dev(struct net_device *dev, struct net_device *upper_dev);
> bool netdev_has_any_upper_dev(struct net_device *dev);
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 0ab32faa520f..e089cd2782e5 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -74,6 +74,8 @@
> struct kmem_cache *skbuff_head_cache __read_mostly;
> static struct kmem_cache *skbuff_fclone_cache __read_mostly;
>
> +int sysctl_gro_frag_list_enable __read_mostly = 1;
> +
> static void sock_pipe_buf_release(struct pipe_inode_info *pipe,
> struct pipe_buffer *buf)
> {
> @@ -2761,7 +2763,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> unsigned int len;
> __be16 proto;
> bool csum;
> - int sg = !!(features & NETIF_F_SG);
> + bool sg = !!(features & NETIF_F_SG);
> int nfrags = skb_shinfo(skb)->nr_frags;
> int err = -ENOMEM;
> int i = 0;
> @@ -2793,7 +2795,13 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> hsize = len;
>
> if (!hsize && i >= nfrags) {
> - BUG_ON(fskb->len != len);
> + if (fskb->len != len) {
> + if (sysctl_gro_frag_list_enable == 1)
> + sysctl_gro_frag_list_enable = 0;
> + hsize = len;
> + sg = false;
> + goto do_linear;
> + }
>
> pos += len;
> nskb = skb_clone(fskb, GFP_ATOMIC);
> @@ -2812,6 +2820,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> skb_release_head_state(nskb);
> __skb_push(nskb, doffset);
> } else {
> +do_linear:
> nskb = __alloc_skb(hsize + doffset + headroom,
> GFP_ATOMIC, skb_alloc_rx_flag(skb),
> NUMA_NO_NODE);
> @@ -2838,9 +2847,6 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> nskb->data - tnl_hlen,
> doffset + tnl_hlen);
>
> - if (fskb != skb_shinfo(skb)->frag_list)
> - goto perform_csum_check;
> -
> if (!sg) {
> nskb->ip_summed = CHECKSUM_NONE;
> nskb->csum = skb_copy_and_csum_bits(skb, offset,
> @@ -2849,6 +2855,9 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> continue;
> }
>
> + if (fskb != skb_shinfo(skb)->frag_list)
> + goto perform_csum_check;
> +
> frag = skb_shinfo(nskb)->frags;
>
> skb_copy_from_linear_data_offset(skb, offset,
> @@ -2944,9 +2953,11 @@ int skb_gro_receive(struct sk_buff **head, struct sk_buff *skb)
> int i = skbinfo->nr_frags;
> int nr_frags = pinfo->nr_frags + i;
>
> - if (nr_frags > MAX_SKB_FRAGS)
> + if (unlikely(nr_frags > MAX_SKB_FRAGS)) {
> + if (!sysctl_gro_frag_list_enable)
> + return -E2BIG;
> goto merge;
> -
> + }
> offset -= headlen;
> pinfo->nr_frags = nr_frags;
> skbinfo->nr_frags = 0;
> @@ -2977,9 +2988,11 @@ int skb_gro_receive(struct sk_buff **head, struct sk_buff *skb)
> unsigned int first_size = headlen - offset;
> unsigned int first_offset;
>
> - if (nr_frags + 1 + skbinfo->nr_frags > MAX_SKB_FRAGS)
> + if (unlikely(nr_frags + 1 + skbinfo->nr_frags > MAX_SKB_FRAGS)) {
> + if (!sysctl_gro_frag_list_enable)
> + return -E2BIG;
> goto merge;
> -
> + }
> first_offset = skb->data -
> (unsigned char *)page_address(page) +
> offset;
> diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
> index cca444190907..2d6aaf6d5838 100644
> --- a/net/core/sysctl_net_core.c
> +++ b/net/core/sysctl_net_core.c
> @@ -24,6 +24,7 @@
>
> static int zero = 0;
> static int one = 1;
> +static int two = 2;
> static int ushort_max = USHRT_MAX;
>
> #ifdef CONFIG_RPS
> @@ -360,6 +361,15 @@ static struct ctl_table net_core_table[] = {
> .mode = 0644,
> .proc_handler = proc_dointvec
> },
> + {
> + .procname = "gro_frag_list_enable",
> + .data = &sysctl_gro_frag_list_enable,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec_minmax,
> + .extra1 = &zero,
> + .extra2 = &two,
> + },
> { }
> };
>
>
>
I've tested all three values of sysctl_gro_frag_list_enable with my
yet-to-submitted GRE-GRO patch running on a router. The BUG panic is
gone and the patch seems to work as documented. Also setting the value
to 0 or 1 does seem to save a bit of CPU time on the forwarding path
and also help throughput a little (a combined of 5-8%).
Tested by: Jerry Chu <hkchu@google.com>
^ permalink raw reply
* Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
From: Simon Horman @ 2013-10-30 0:05 UTC (permalink / raw)
To: Mark Brown
Cc: linux-fbdev, Wolfram Sang, Linus Walleij, Guennadi Liakhovetski,
Thierry Reding, linux-mtd, Laurent Pinchart, Laurent Pinchart,
Vinod Koul, Joerg Roedel, linux-sh, Magnus Damm, Eduardo Valentin,
Tomi Valkeinen, linux-serial, linux-input, Zhang Rui, Chris Ball,
Jean-Christophe Plagniol-Villard, linux-media, linux-pwm,
Samuel Ortiz, linux-pm, Ian Molton
In-Reply-To: <20131029175834.GD20251@sirena.org.uk>
On Tue, Oct 29, 2013 at 10:58:34AM -0700, Mark Brown wrote:
> On Tue, Oct 29, 2013 at 06:29:59PM +0100, Laurent Pinchart wrote:
> > On Tuesday 29 October 2013 10:23:31 Mark Brown wrote:
> > > On Tue, Oct 29, 2013 at 06:05:53PM +0100, Laurent Pinchart wrote:
> > > > The first one is that I can't compile-test all those drivers on all
> > > > architectures. The spi-sh-msiof driver, for instance, uses
> > > > io(read|write)(16|
>
> > > Which architectures are these and is there not a symbol we can depend on
> > > for them?
>
> > arch/cris for instance. We can use readl/writel instead (maybe it would be
> > time to rationalize and document the I/O accessors across all architectures,
> > but that's another topic).
>
> It'd certainly be sensible, or adding a config option to depend on if
> you rely on these functions.
>
> > My point is that there might be other issues that I won't be able to easily
> > catch. This would break compilation for everybody for no reason, as the
> > drivers are useless on non-SuperH, non-ARM platforms. That's why I believe
> > COMPILE_TEST would be a better option as a first step.
>
> Yes, it would - please do that. Note that it won't stop anyone running
> into build issues on other architectures though, it's just about
> stopping Kconfig noise.
FWIW, I am happy with using COMPILE_TEST for this series.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: introduce gro_frag_list_enable sysctl
From: Ben Hutchings @ 2013-10-30 0:06 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet, christoph.paasch, herbert, netdev, hkchu, mwdalton
In-Reply-To: <20131029.194446.2215574000648693370.davem@davemloft.net>
On Tue, 2013-10-29 at 19:44 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 29 Oct 2013 08:12:35 -0700
>
> > From: Eric Dumazet <edumazet@google.com>
> >
> > Christoph Paasch and Jerry Chu reported crashes in skb_segment() caused
> > by commit 8a29111c7ca6 ("net: gro: allow to build full sized skb")
> >
> > (Jerry is working on adding native GRO support for tunnels)
> >
> > skb_segment() only deals with a frag_list chain containing MSS sized
> > fragments.
> >
> > This patch adds support any kind of frag, and adds a new sysctl,
> > as clearly the GRO layer should avoid building frag_list skbs
> > on a router, as the segmentation is adding cpu overhead.
> >
> > Note that we could try to reuse page fragments instead of doing
> > copy to linear skbs, but this requires a fair amount of work,
> > and possible truesize nightmares, as we do not track individual
> > (per page fragment) truesizes.
> >
> > /proc/sys/net/core/gro_frag_list_enable possible values are :
> >
> > 0 : GRO layer is not allowed to use frag_list to extend skb capacity
> > 1 : GRO layer is allowed to use frag_list, but skb_segment()
> > automatically sets the sysctl to 0.
> > 2 : GRO is allowed to use frag_list, and skb_segment() wont
> > clear the sysctl.
> >
> > Default value is 1 : automatic discovery
> >
> > Reported-by: Christoph Paasch <christoph.paasch@uclouvain.be>
> > Reported-by: Jerry Chu <hkchu@google.com>
> > Cc: Michael Dalton <mwdalton@google.com>
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > ---
> > v2: added missing sysctl definition in skbuff.c
>
> I do not like the idea of packet actions indirectly changing sysctl
> values, even if you document it sufficiently as you have here.
>
> Plus this puts the sysctl change logic in a fast path.
>
> I would suggest instead making it change in response to changes to
> ip_forward, as we do with per-device LRO settings. This means that,
> like ip_forward, you should also make this sysctl a global + devinet
> per-device sysctl.
>
> You might even emit a pr_info() when this logic triggers, and if you
> are ambitious enough keep track of the previous GRO sysctl state so
> you can restore it if ip_forward is set back to zero.
Speaking of which: insteading of disabling LRO once, we really ought to
keep count of the forwarders (IPv4 routing, IPv6 routing, bridge) and
use that to mask out LRO in netdev_fix_features().
I think that the forwarder count is also needed for this.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: ipv6 fragmentation-related panic in netfilter
From: Patrick McHardy @ 2013-10-30 0:07 UTC (permalink / raw)
To: Tomas Hlavacek; +Cc: netdev, netfilter-devel
In-Reply-To: <2060a7d2-c307-4e30-b1d4-0bd26c904d6f@gmail.com>
On Tue, Oct 29, 2013 at 10:07:59PM +0100, Tomas Hlavacek wrote:
> Hi!
>
> I have encountered following condition on 3 distinct hosts in last
> few days. Hosts are failing several times a day (4 to 7 times) and
> it usually happens roughly at the same time. Affected hosts has
> almost exactly the same HW, but different kernel versions from
> Debian (Wheezy) default 3.2 up to 3.11.6.
>
>
> KERNEL: /usr/src/vmlinux DUMPFILE:
> dump.201310291545 [PARTIAL DUMP]
> CPUS: 16
> DATE: Tue Oct 29 15:45:11 2013
> UPTIME: 06:04:17
> LOAD AVERAGE: 0.04, 0.25, 0.32
> TASKS: 211
> NODENAME: fw03a
> RELEASE: 3.11.6
> VERSION: #2 SMP Mon Oct 28 20:29:03 CET 2013
> MACHINE: x86_64 (2393 Mhz)
> MEMORY: 12 GB
> PANIC: PID: 0
> COMMAND: "swapper/1"
> TASK: ffff8801b90ac7b0 (1 of 16) [THREAD_INFO: ffff8801b90b4000]
> CPU: 1
> STATE: TASK_RUNNING (PANIC)
>
> crash> bt
> PID: 0 TASK: ffff8801b90ac7b0 CPU: 1 COMMAND: "swapper/1"
> #0 [ffff8801bfc235d0] machine_kexec at ffffffff81032f68
> #1 [ffff8801bfc23610] crash_kexec at ffffffff8109e055
> #2 [ffff8801bfc236e0] oops_end at ffffffff81005e90
> #3 [ffff8801bfc23700] do_invalid_op at ffffffff81003004
> #4 [ffff8801bfc237a0] invalid_op at ffffffff8142b368
> [exception RIP: pskb_expand_head+596]
> RIP: ffffffff81333c74 RSP: ffff8801bfc23850 RFLAGS: 00010202
> RAX: 0000000000000003 RBX: ffff8801b6d99080 RCX: 0000000000000020
> RDX: 00000000000005f4 RSI: 0000000000000000 RDI: ffff8801b6d99080
> RBP: 0000000040115833 R8: 00000000000002c0 R9: ffff8801b8cf2c00
> R10: 000000000000ffff R11: 00000000197033fe R12: 0000000000000000
> R13: ffff880337b59a00 R14: ffffffffa03fb160 R15: ffff880337b59a00
> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
> #5 [ffff8801bfc23858] __nf_conntrack_confirm at ffffffffa03ace16
> [nf_conntrack]
> #6 [ffff8801bfc238c8] vlan_netlink_fini at ffffffffa03fb160 [8021q]
> #7 [ffff8801bfc23928] dev_queue_xmit at ffffffff81342d79
> #8 [ffff8801bfc23978] ip6_finish_output2 at ffffffff813d26ee
> #9 [ffff8801bfc239c8] ip6_forward at ffffffff813d44be
> #10 [ffff8801bfc23a48] __ipv6_conntrack_in at ffffffffa034f7b6
> [nf_conntrack_ipv6]
> #11 [ffff8801bfc23a98] nf_iterate at ffffffff8136ba0d
> #12 [ffff8801bfc23af8] nf_hook_slow at ffffffff8136baae
> #13 [ffff8801bfc23b68] nf_ct_frag6_output at ffffffffa039decf
> [nf_defrag_ipv6]
> #14 [ffff8801bfc23bd8] ipv6_defrag at ffffffffa039d0c1 [nf_defrag_ipv6]
> #15 [ffff8801bfc23c18] nf_iterate at ffffffff8136ba0d
> #16 [ffff8801bfc23c78] nf_hook_slow at ffffffff8136baae
> #17 [ffff8801bfc23ce8] ipv6_rcv at ffffffff813d59f5
> #18 [ffff8801bfc23d38] __netif_receive_skb_core at ffffffff813410db
> #19 [ffff8801bfc23db8] napi_gro_receive at ffffffff81341d88
> #20 [ffff8801bfc23dd8] igb_poll at ffffffffa0035867 [igb]
> #21 [ffff8801bfc23e88] net_rx_action at ffffffff81341ac9
> #22 [ffff8801bfc23ed8] __do_softirq at ffffffff81049fb6
> #23 [ffff8801bfc23f38] call_softirq at ffffffff8142b4fc
> #24 [ffff8801bfc23f50] do_softirq at ffffffff8100481d
> #25 [ffff8801bfc23f80] do_IRQ at ffffffff810043bb
> --- <IRQ stack> ---
> #26 [ffff8801b90b5db8] ret_from_intr at ffffffff81429baa
> [exception RIP: cpuidle_enter_state+86]
> RIP: ffffffff813107a6 RSP: ffff8801b90b5e68 RFLAGS: 00000216
> RAX: 000000000007ff2b RBX: 0000000140523c4c RCX: 0000000000000018
> RDX: 0000000225c17d03 RSI: 0000000000000000 RDI: ffffffff81812600
> RBP: 0000000000000004 R8: 0000000000000018 R9: 00000000000006cf
> R10: 0000000000000001 R11: 0000000000000006 R12: 0000000100523c4e
> R13: 0000000000000000 R14: ffffffff81066415 R15: 0000000000000086
> ORIG_RAX: ffffffffffffff94 CS: 0010 SS: 0018
> #27 [ffff8801b90b5eb0] cpuidle_idle_call at ffffffff813108ce
> #28 [ffff8801b90b5ee0] arch_cpu_idle at ffffffff8100b769
> #29 [ffff8801b90b5ef0] cpu_startup_entry at ffffffff81086b1d
> #30 [ffff8801b90b5f30] start_secondary at ffffffff8102af40
>
> I am investigating at the moment. All suggestions/help would be
> appreciated.
The problem is that the reassembled packet is referenced by the individual
fragments, so we trigger the BUG_ON in pskb_expand_head(). In this
particular case the case we BUG() on is actually OK, but I'm looking at
a way we can fix this without special casing. Hope to have a patch for
testing in the next hours.
^ permalink raw reply
* From Mr. Charles Kabore.
From: Mr. Charles Kabore @ 2013-10-30 0:08 UTC (permalink / raw)
>From Mr. Charles Kabore.
Ouagadougou,
Burkina Faso.
Dear Friend,
Good day to you. I must say sorry for interfering into your privacy without seeking for permission. It's because of urgency of this matter. Firstly, I am Mr. Charles Kabore a lawyer and personal confidant to Abdullah Senussi who was the intelligence chief of Colonel Muammar Gaddafi. I need your urgent assistance in transferring the sum of ($39.5) million to your account within 14 banking days from a bank in Burkina Faso. This money belongs to my master Abdullah Senussi and was deposited in the bank on the name of his son. The urgent need for the transfer of this fund is to avoid confiscation by the Libyan government as they quest the seizure of every related assets belonging to Late Colonel Muammar Gaddafi and his aides. I am contacting you in a good faith so that the bank will release the
money to you for safe keeping/investments till the release of my master who is now in custody.
So if you are capable of receiving this huge amount of money,let me have a positive response from you via return mail for more personal discussions on how we are going to go about it. but if you are not convinced to handle this deal with me then do me a favor by deleting this message from your mail box and help me seal the confidentiality of this matter. thank you for your understanding and hope to hear from you soon.
Best.Regards,
Mr. Charles Kabore.
^ permalink raw reply
* named network namespace -- setns() with Invalid argument (errno 22)
From: Dilip Daya @ 2013-10-30 0:16 UTC (permalink / raw)
To: netdev; +Cc: Eric W. Biederman
Hi All,
Is the following intended behavior for adding "nested" named network namespaces ?
Steps to reproduce:
# uname -r
3.10.1
# /sbin/ip -V
ip utility, iproute2-ss130903
Existing network namespaces:
# ip netns list
NETNS0
NETNS1
List of named network namespace objects with inode/permissions:
# ls -li /var/run/netns/
total 0
4026532310 -r--r--r-- 1 root root 0 Oct 29 09:11 NETNS0
4026532366 -r--r--r-- 1 root root 0 Oct 29 09:13 NETNS1
Enter existing named network namespace:
# ip netns exec NETNS0 bash
List network devices for named netns:
# ls -l /sys/class/net/
total 0
lrwxrwxrwx 1 root root 0 Oct 29 12:25 lo -> ../../devices/virtual/net/lo/
List of named network namespace objects with inode/permissions:
# ls -li /var/run/netns/
total 0
4026532310 -r--r--r-- 1 root root 0 Oct 29 09:11 NETNS0
4026532366 -r--r--r-- 1 root root 0 Oct 29 09:13 NETNS1
# ip netns add NETNS0a <<< adding NETNS0a from within NETNS0
# ls -li /var/run/netns/
total 0
4026532310 -r--r--r-- 1 root root 0 Oct 29 09:11 NETNS0
4026532366 -r--r--r-- 1 root root 0 Oct 29 09:13 NETNS1
4026532423 -r--r--r-- 1 root root 0 Oct 29 12:28 NETNS0a
^^^^^^^^^^ ^^^^^^^^^^
inode permissions
# ip netns exec NETNS0a ls -l /sys/class/net/
total 0
lrwxrwxrwx 1 root root 0 Oct 29 12:28 lo -> ../../devices/virtual/net/lo
# exit <<< exiting from NETNS0
Listing from host/default namespace:
# ls -li /var/run/netns/
total 0
4026532310 -r--r--r-- 1 root root 0 Oct 29 09:11 NETNS0
4026532366 -r--r--r-- 1 root root 0 Oct 29 09:13 NETNS1
964863 ---------- 1 root root 0 Oct 29 12:28 NETNS0a <<< NULL permissions
^^^^^^ ^^^^^^^^^^
Re-enter NETNS0:
# ip netns exec NETNS0 bash
# ls -li /var/run/netns/
total 0
4026532310 -r--r--r-- 1 root root 0 Oct 29 09:11 NETNS0
4026532366 -r--r--r-- 1 root root 0 Oct 29 09:13 NETNS1
964863 ---------- 1 root root 0 Oct 29 12:28 NETNS0a <<< NULL permissions
^^^^^^^^^^
# ip netns exec NETNS0a ls -l /sys/class/net/
seting the network namespace "NETNS0a" failed: Invalid argument
=> It seems the bash shell that created the nested named netns is the only
one that can view/enter the nested named netns. All other attempts from
either another bash shell or host/default namespace will get a different
inode with NULL permissions. Once the initial bash shell that created the
nested named netns exists the nested netns is rendered unusable due to
NULL permissions on its inode. setns() Invalid argument (errno 22) seems
to be due to NULL permissions on /var/run/netns/<netnsName> object.
Thanks.
^ permalink raw reply
* [PATCH net-next 02/11] openvswitch: remove duplicated include from vport-vxlan.c
From: Jesse Gross @ 2013-10-30 0:22 UTC (permalink / raw)
To: David Miller
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
Wei Yongjun
In-Reply-To: <1383092544-50599-1-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
From: Wei Yongjun <yongjun_wei-zrsr2BFq86L20UzCJQGyNP8+0UxHXcjY@public.gmane.org>
Remove duplicated include.
Signed-off-by: Wei Yongjun <yongjun_wei-zrsr2BFq86L20UzCJQGyNP8+0UxHXcjY@public.gmane.org>
Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
---
net/openvswitch/vport-vxlan.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/openvswitch/vport-vxlan.c b/net/openvswitch/vport-vxlan.c
index a481c03..b0da394 100644
--- a/net/openvswitch/vport-vxlan.c
+++ b/net/openvswitch/vport-vxlan.c
@@ -29,7 +29,6 @@
#include <net/ip.h>
#include <net/udp.h>
#include <net/ip_tunnels.h>
-#include <net/udp.h>
#include <net/rtnetlink.h>
#include <net/route.h>
#include <net/dsfield.h>
--
1.8.3.2
^ permalink raw reply related
* [GIT net-next] Open vSwitch
From: Jesse Gross @ 2013-10-30 0:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev, dev
A set of updates for net-next/3.13. Major changes are:
* Restructure flow handling code to be more logically organized and
easier to read.
* Previously flow state was effectively per-CPU but this is no longer
true with the addition of wildcarded flows (megaflows). While good
for flow setup rates, it is bad for stats updates. Stats are now
per-CPU again to get the best of both worlds.
* Rehashing of the flow table is moved from a workqueue to flow
installation time. Before, heavy load could block the workqueue for
excessive periods of time.
* Additional debugging information is provided to help diagnose megaflows.
* It's now possible to match on TCP flags.
The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:
Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jesse/openvswitch.git master
for you to fetch changes up to c7e8b9659587449b21ee68d7aee0cacadf650cce:
openvswitch: TCP flags matching support. (2013-10-23 02:19:50 -0700)
----------------------------------------------------------------
Andy Zhou (1):
openvswitch: collect mega flow mask stats
Jarno Rajahalme (2):
openvswitch: Widen TCP flags handling.
openvswitch: TCP flags matching support.
Pravin B Shelar (6):
openvswitch: Move flow table rehashing to flow install.
openvswitch: Restructure datapath.c and flow.c
openvswitch: Move mega-flow list out of rehashing struct.
openvswitch: Simplify mega-flow APIs.
openvswitch: Per cpu flow stats.
openvswitch: Enable all GSO features on internal port.
Wei Yongjun (2):
openvswitch: remove duplicated include from vport-vxlan.c
openvswitch: remove duplicated include from vport-gre.c
include/uapi/linux/openvswitch.h | 18 +-
net/openvswitch/Makefile | 2 +
net/openvswitch/datapath.c | 721 ++-------------
net/openvswitch/datapath.h | 9 +-
net/openvswitch/flow.c | 1631 ++--------------------------------
net/openvswitch/flow.h | 148 +--
net/openvswitch/flow_netlink.c | 1630 +++++++++++++++++++++++++++++++++
net/openvswitch/flow_netlink.h | 60 ++
net/openvswitch/flow_table.c | 600 +++++++++++++
net/openvswitch/flow_table.h | 81 ++
net/openvswitch/vport-gre.c | 2 -
net/openvswitch/vport-internal_dev.c | 2 +-
net/openvswitch/vport-vxlan.c | 1 -
13 files changed, 2590 insertions(+), 2315 deletions(-)
create mode 100644 net/openvswitch/flow_netlink.c
create mode 100644 net/openvswitch/flow_netlink.h
create mode 100644 net/openvswitch/flow_table.c
create mode 100644 net/openvswitch/flow_table.h
^ 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