* [PATCH net 2/3] 6lowpan: clean up fragments list if module unloaded
From: Alexander Smirnov @ 2012-04-26 9:24 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-zigbee-devel, Alexander Smirnov
In-Reply-To: <1335432298-17161-1-git-send-email-alex.bluesman.smirnov@gmail.com>
Clean all the pending fragments and relative timers if 6lowpan link
is going to be deleted.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
net/ieee802154/6lowpan.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 7ce508f..a21ca6e 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1177,11 +1177,20 @@ static void lowpan_dellink(struct net_device *dev, struct list_head *head)
{
struct lowpan_dev_info *lowpan_dev = lowpan_dev_info(dev);
struct net_device *real_dev = lowpan_dev->real_dev;
- struct lowpan_dev_record *entry;
- struct lowpan_dev_record *tmp;
+ struct lowpan_dev_record *entry, *tmp;
+ struct lowpan_fragment *frame, *tframe;
ASSERT_RTNL();
+ spin_lock(&flist_lock);
+ list_for_each_entry_safe(frame, tframe, &lowpan_fragments, list) {
+ del_timer(&frame->timer);
+ list_del(&frame->list);
+ dev_kfree_skb(frame->skb);
+ kfree(frame);
+ }
+ spin_unlock(&flist_lock);
+
mutex_lock(&lowpan_dev_info(dev)->dev_list_mtx);
list_for_each_entry_safe(entry, tmp, &lowpan_devices, list) {
if (entry->ldev == dev) {
--
1.7.2.3
^ permalink raw reply related
* [PATCH net 1/3] 6lowpan: fix segmentation fault caused by mlme request
From: Alexander Smirnov @ 2012-04-26 9:24 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-zigbee-devel, Alexander Smirnov
In-Reply-To: <1335432298-17161-1-git-send-email-alex.bluesman.smirnov@gmail.com>
Add nescesary mlme callbacks to satisfy "iz list" request from user space.
Due to 6lowpan device doesn't have its own phy, mlme implemented as a pipe
to a real phy to which 6lowpan is attached.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
net/ieee802154/6lowpan.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 58c8895..7ce508f 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1044,6 +1044,24 @@ static void lowpan_dev_free(struct net_device *dev)
free_netdev(dev);
}
+static struct wpan_phy *lowpan_get_phy(const struct net_device *dev)
+{
+ struct net_device *real_dev = lowpan_dev_info(dev)->real_dev;
+ return ieee802154_mlme_ops(real_dev)->get_phy(real_dev);
+}
+
+static u16 lowpan_get_pan_id(const struct net_device *dev)
+{
+ struct net_device *real_dev = lowpan_dev_info(dev)->real_dev;
+ return ieee802154_mlme_ops(real_dev)->get_pan_id(real_dev);
+}
+
+static u16 lowpan_get_short_addr(const struct net_device *dev)
+{
+ struct net_device *real_dev = lowpan_dev_info(dev)->real_dev;
+ return ieee802154_mlme_ops(real_dev)->get_short_addr(real_dev);
+}
+
static struct header_ops lowpan_header_ops = {
.create = lowpan_header_create,
};
@@ -1053,6 +1071,12 @@ static const struct net_device_ops lowpan_netdev_ops = {
.ndo_set_mac_address = eth_mac_addr,
};
+static struct ieee802154_mlme_ops lowpan_mlme = {
+ .get_pan_id = lowpan_get_pan_id,
+ .get_phy = lowpan_get_phy,
+ .get_short_addr = lowpan_get_short_addr,
+};
+
static void lowpan_setup(struct net_device *dev)
{
pr_debug("(%s)\n", __func__);
@@ -1070,6 +1094,7 @@ static void lowpan_setup(struct net_device *dev)
dev->netdev_ops = &lowpan_netdev_ops;
dev->header_ops = &lowpan_header_ops;
+ dev->ml_priv = &lowpan_mlme;
dev->destructor = lowpan_dev_free;
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH net 0/3][6lowpan] fixes for 6lowpan
From: Alexander Smirnov @ 2012-04-26 9:24 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
The following patch set contains several fixes for the 6lowpan holes which lead
to unpredictable module state.
With best regards,
Alex
8<--
The following changes since commit 872f24dbc604ef585ea7eec73020dcdfaffd1956:
tipc: remove inline instances from C source files. (2012-04-24 00:41:03 -0400)
are available in the git repository at:
6lowpan_dev ..BRANCH.NOT.VERIFIED..
Alexander Smirnov (3):
6lowpan: fix segmentation fault caused by mlme request
6lowpan: clean up fragments list if module unloaded
6lowpan: add missing spin_lock_init()
net/ieee802154/6lowpan.c | 40 ++++++++++++++++++++++++++++++++++++++--
1 files changed, 38 insertions(+), 2 deletions(-)
From: Alexander Smirnov <alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: [PATCH net 0/3][6lowpan] fixes for 6lowpan
In-Reply-To:
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply
* Re: [PATCH] tcp repair: Fix unaligned access when repairing options (v2)
From: David Miller @ 2012-04-26 9:23 UTC (permalink / raw)
To: xemul; +Cc: netdev, David.Laight
In-Reply-To: <4F990C71.3020500@parallels.com>
From: Pavel Emelyanov <xemul@parallels.com>
Date: Thu, 26 Apr 2012 12:50:57 +0400
> Don't pick __u8/__u16 values directly from raw pointers, but instead use
> an array of structures of code:value pairs. This is OK, since the buffer
> we take options from is not an skb memory, but a user-to-kernel one.
>
> For those options which don't require any value now, require this to be
> zero (for potential future extension of this API).
>
> v2: Changed tcp_repair_opt to use two __u32-s as spotted by David Laight.
>
> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Hmmm, this didn't show up on netdev, I wonder why?
^ permalink raw reply
* Re: [RFC] allow skb->head to point/alias to first skb frag
From: Eric Dumazet @ 2012-04-26 9:22 UTC (permalink / raw)
To: David Miller
Cc: ilpo.jarvinen, rick.jones2, netdev, therbert, ncardwell, maze,
ycheng
In-Reply-To: <20120426.051800.637617874638567499.davem@davemloft.net>
On Thu, 2012-04-26 at 05:18 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 26 Apr 2012 11:10:02 +0200
>
> > The 'frag' would have a known size : 2048 bytes
> >
> > But the end of it would be used by struct skb_shared_info
> >
> > so data_len would be 0 in fact.
> >
> > This would look like a regular linear skb.
> >
> > Just a bit set in skb to say : Warning, skb->head was not kmalloced :
> > replace kfree(head) by put_page(...)
> >
> > And this bit would be tested in GRO or tcp merge to 'upgrade' this
> > skb->head to proper page/frag
>
> And what happens if this ends up in a piece of code which wants to
> append a page frag?
>
> Or a piece of code which copies an SKB, including page frag parts?
>
> All I'm saying is that the number of tests necessary to make this work
> properly might become prohibitive.
I'll cook a patch, I believe not so many parts assume skb->head can be
kmalloc()/kfree(). This should be contained in net/core/skbuff.c only.
Elsewhere we use skb->head as a pointer to memory. It will stay the
same.
^ permalink raw reply
* Re: [GIT PULL] net/at91: at91_ether fixes for 3.4-rc
From: David Miller @ 2012-04-26 9:20 UTC (permalink / raw)
To: nicolas.ferre
Cc: netdev, linux-arm-kernel, linux-kernel, avictor.za, plagnioj
In-Reply-To: <4F991210.8060409@atmel.com>
From: Nicolas Ferre <nicolas.ferre@atmel.com>
Date: Thu, 26 Apr 2012 11:14:56 +0200
> Can you please pull those fixes for 3.4-rc? The ARM/AT91 part
> of modifications is pretty small and bounded to a single SoC so
> it will not mess with arm-soc git tree.
Please post the patches themselves to netdev.
You can give me pull requests, but those go into the "[PATCH 0/N] ..."
email, it doesn't preclude you're still having to post the actual
patches.
Otherwise nobody can review your work.
^ permalink raw reply
* Re: [RFC] allow skb->head to point/alias to first skb frag
From: David Miller @ 2012-04-26 9:18 UTC (permalink / raw)
To: eric.dumazet
Cc: ilpo.jarvinen, rick.jones2, netdev, therbert, ncardwell, maze,
ycheng
In-Reply-To: <1335431402.2775.24.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 26 Apr 2012 11:10:02 +0200
> The 'frag' would have a known size : 2048 bytes
>
> But the end of it would be used by struct skb_shared_info
>
> so data_len would be 0 in fact.
>
> This would look like a regular linear skb.
>
> Just a bit set in skb to say : Warning, skb->head was not kmalloced :
> replace kfree(head) by put_page(...)
>
> And this bit would be tested in GRO or tcp merge to 'upgrade' this
> skb->head to proper page/frag
And what happens if this ends up in a piece of code which wants to
append a page frag?
Or a piece of code which copies an SKB, including page frag parts?
All I'm saying is that the number of tests necessary to make this work
properly might become prohibitive.
^ permalink raw reply
* [GIT PULL] net/at91: at91_ether fixes for 3.4-rc
From: Nicolas Ferre @ 2012-04-26 9:14 UTC (permalink / raw)
To: David Miller, netdev, linux-arm-kernel
Cc: Andrew Victor, Jean-Christophe PLAGNIOL-VILLARD,
Linux Kernel list
Hi David,
Can you please pull those fixes for 3.4-rc? The ARM/AT91 part
of modifications is pretty small and bounded to a single SoC so
it will not mess with arm-soc git tree.
Tell me if you need other information on this signed tag...
The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:
Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)
are available in the git repository at:
git://github.com/at91linux/linux-at91.git tags/at91-3.4-net-fixes
for you to fetch changes up to cfc991548b5b73c8038f41877da1cd0104945cf5:
net/at91_ether: use gpio_to_irq for phy IRQ line (2012-04-26 10:22:40 +0200)
----------------------------------------------------------------
Both fixes are about at91_ether.c driver: It is only used in a single
Atmel AT91 SoC: AT91RM9200.
The removal of fixed mapping is a long standing refinement which will
convert this driver to a more typical resources management.
The gpio fix is needed now that we have moved AT91 to irqdomains.
----------------------------------------------------------------
Andrew Victor (1):
AT91: Remove fixed mapping for AT91RM9200 ethernet
Nicolas Ferre (1):
net/at91_ether: use gpio_to_irq for phy IRQ line
arch/arm/mach-at91/at91rm9200.c | 10 --
arch/arm/mach-at91/at91rm9200_devices.c | 4 +-
arch/arm/mach-at91/include/mach/hardware.h | 1 -
drivers/net/ethernet/cadence/at91_ether.c | 535 ++++++++++++++++++++++++++++++++++++++++++++-------------------------------------
drivers/net/ethernet/cadence/at91_ether.h | 1 +
5 files changed, 291 insertions(+), 260 deletions(-)
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* RE: [PATCH 00/10] atl1c: update hardware settings - v3
From: Huang, Xiong @ 2012-04-26 9:13 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
qca-linux-team, nic-devel
In-Reply-To: <20120426.050542.243663587525305831.davem@davemloft.net>
Ok, I will update quirks.c for the next patch set. Thanks !
-Xiong
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Thursday, April 26, 2012 17:06
> To: Huang, Xiong
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; qca-linux-team; nic-
> devel
> Subject: Re: [PATCH 00/10] atl1c: update hardware settings - v3
>
> From: xiong <xiong@qca.qualcomm.com>
> Date: Thu, 26 Apr 2012 14:27:08 +0800
>
> > This update contains a serial of patches, most of them are hardware
> > settings related. register definitions are refined (or removed if
> > meaningless) for each patch.
> >
> > This is the third serial patches, after reviewed/applied the fourth
> > serial will be out.
> >
> > The patches have addressed all sparse and checkpatch warnings.
> >
> > Following NICs are tested:
> > AR8131/AR8132/AR8151A/AR8152A/AR8152B
> > Test item includes:
> > build/install/uninstall/dhcp/ping/iperf/wol/reboot/etc.
>
> I've applied patches #1 until #9, patch #10 needs to be done differently.
>
> The PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG bit should be set via a PCI quirk
> entry in drivers/pci/quirks.c just as it is done for other devices which have this
> problem.
>
> Thank you.
^ permalink raw reply
* Re: [net 0/2][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-04-26 9:11 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1335333314-6814-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 24 Apr 2012 22:55:12 -0700
> This series of patches contains fixes for e1000e only.
>
> The following are changes since commit 2a5809499e35b53a6044fd34e72b242688b7a862:
> asix: Fix tx transfer padding for full-speed USB
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net master
>
> Jeff Kirsher (1):
> e1000e: Fix default interrupt throttle rate not set in NIC HW
>
> Prasanna S Panchamukhi (1):
> e1000e: MSI interrupt test failed, using legacy interrupt
Pulled, but longer term you guys might want to take Ben's suggestion
and just take the interrupt self-test out altogether.
Thanks.
^ permalink raw reply
* Re: [RFC] allow skb->head to point/alias to first skb frag
From: Eric Dumazet @ 2012-04-26 9:10 UTC (permalink / raw)
To: David Miller
Cc: ilpo.jarvinen, rick.jones2, netdev, therbert, ncardwell, maze,
ycheng
In-Reply-To: <20120426.043623.1317043382565428400.davem@davemloft.net>
On Thu, 2012-04-26 at 04:36 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 26 Apr 2012 10:10:54 +0200
>
> > Idea would have :
> >
> > 1) struct sk_buff
> > 2) skb->head points to frag (aliasing, no memory allocation)
> > 3) frag of 2048 (or PAGE_SIZE/2 or PAGE_SIZE)
>
> What would you set skb->data_len and skb->len to?
>
> How would you handle tailroom? We have the rule that you can't append
> to the tail of a fragmented SKB (I mean append, the way that IPSEC
> wants to write data to the end of an SKB when encrypting, for
> example). This is only allowed on fully linear SKBs.
>
> So, for this reason and others, you can't pretend that this new
> construction is linear in any way. It would break a bunch of things.
The 'frag' would have a known size : 2048 bytes
But the end of it would be used by struct skb_shared_info
so data_len would be 0 in fact.
This would look like a regular linear skb.
Just a bit set in skb to say : Warning, skb->head was not kmalloced :
replace kfree(head) by put_page(...)
And this bit would be tested in GRO or tcp merge to 'upgrade' this
skb->head to proper page/frag
^ permalink raw reply
* [PATCH] net: usb: smsc95xx: fix mtu
From: Steve Glendinning @ 2012-04-26 9:02 UTC (permalink / raw)
To: netdev; +Cc: Stephane Fillod, David S. Miller, Steve Glendinning
Make smsc95xx recalculate the hard_mtu after adjusting the hard_header_len.
Without this, usbnet adjusts the MTU down to 1492 bytes, and the host is
unable to receive standard 1500-byte frames from the device.
Inspired by same fixes on cdc_eem 78fb72f7936c01d5b426c03a691eca082b03f2b9
and smsc75xx a99ff7d0123b19ecad3b589480b6542716ab6b52.
Tested on i386 with EVB-LAN9500-LC.
Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
---
drivers/net/usb/smsc95xx.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 5f19f84..53a1ba5 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -1017,6 +1017,7 @@ static int smsc95xx_bind(struct usbnet *dev, struct usb_interface *intf)
dev->net->ethtool_ops = &smsc95xx_ethtool_ops;
dev->net->flags |= IFF_MULTICAST;
dev->net->hard_header_len += SMSC95XX_TX_OVERHEAD_CSUM;
+ dev->hard_mtu = dev->net->mtu + dev->net->hard_header_len;
return 0;
}
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 2/2] ehea: fix promiscuous mode
From: David Miller @ 2012-04-26 9:08 UTC (permalink / raw)
To: cascardo; +Cc: netdev, leitao
In-Reply-To: <1335375132-4591-2-git-send-email-cascardo@linux.vnet.ibm.com>
From: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Date: Wed, 25 Apr 2012 14:32:12 -0300
> commit a4910b744486254cfa61995954c118fb2283c4fd has broken promiscuous
> mode, which is never set. port->promisc just reflects the last setting
> of PROMISCUOUS mode to avoid doing an extra hypercall when it's already
> set.
>
> However, since it may fail because of hypervisor permissions, we should
> still respect the multicast settings and not simply exit after setting
> promiscuous mode.
>
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
> Cc: Breno Leitao <leitao@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] ehea: fix allmulticast support
From: David Miller @ 2012-04-26 9:08 UTC (permalink / raw)
To: cascardo; +Cc: netdev
In-Reply-To: <1335375132-4591-1-git-send-email-cascardo@linux.vnet.ibm.com>
From: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Date: Wed, 25 Apr 2012 14:32:11 -0300
> There was a bug in the mask of regtype parameter for registering a
> multicast filter. It was ignoring the scope bit, which was wrongly being
> used for all filters. The SCOPE_ALL value adds a filter that allows all
> multicast packets and ignores the MAC parameter, just what allmulticast
> needs. The normals filters, however, should not use SCOPE_ALL.
>
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/7] be2net fixes
From: David Miller @ 2012-04-26 9:05 UTC (permalink / raw)
To: padmanabh.ratnakar; +Cc: netdev
In-Reply-To: <54ea1f39-fd40-40c9-97a4-271ba9e4df49@exht1.ad.emulex.com>
From: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Date: Wed, 25 Apr 2012 17:15:52 +0530
> Please apply.
> Thanks,
> Padmanabh
>
> Padmanabh Ratnakar (7):
> be2net: Fix VLAN/multicast packet reception
> be2net: Fix FW download in Lancer
> be2net: Fix ethtool self test for Lancer
> be2net: Fix traffic stall INTx mode
> be2net: Fix Lancer statistics
> be2net: Fix wrong status getting returned for MCC commands
> be2net: Fix FW download for BE
All applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH 00/10] atl1c: update hardware settings - v3
From: David Miller @ 2012-04-26 9:05 UTC (permalink / raw)
To: xiong; +Cc: netdev, linux-kernel, qca-linux-team, nic-devel
In-Reply-To: <1335421638-16304-1-git-send-email-xiong@qca.qualcomm.com>
From: xiong <xiong@qca.qualcomm.com>
Date: Thu, 26 Apr 2012 14:27:08 +0800
> This update contains a serial of patches, most of them are hardware
> settings related. register definitions are refined (or removed if
> meaningless) for each patch.
>
> This is the third serial patches, after reviewed/applied the fourth
> serial will be out.
>
> The patches have addressed all sparse and checkpatch warnings.
>
> Following NICs are tested:
> AR8131/AR8132/AR8151A/AR8152A/AR8152B
> Test item includes:
> build/install/uninstall/dhcp/ping/iperf/wol/reboot/etc.
I've applied patches #1 until #9, patch #10 needs to be done
differently.
The PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG bit should be set via a PCI
quirk entry in drivers/pci/quirks.c just as it is done for other
devices which have this problem.
Thank you.
^ permalink raw reply
* Re: [v2 PATCH 1/1] ipvs: kernel oops - do_ip_vs_get_ctl
From: Simon Horman @ 2012-04-26 9:05 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Hans Schillstrom, ja, wensong, rohara, lvs-devel, netdev,
netfilter-devel, hans
In-Reply-To: <1335427841.3131.28.camel@t520>
On Thu, Apr 26, 2012 at 10:10:41AM +0200, Jesper Dangaard Brouer wrote:
> On Thu, 2012-04-26 at 07:47 +0200, Hans Schillstrom wrote:
> > Change order of init so netns init is ready
> > when register ioctl and netlink.
> >
> > Ver2
> > Whitespace fixes and __init added.
> >
> > Reported-by: "Ryan O'Hara" <rohara@redhat.com>
> > Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
>
> Looks good, interdiff says you fixed up things, and I have tested it
> against the net tree, good work :-)
>
> Is this a stable tree candidate?
Yes, I think so.
I now have the following 7 changes in my ipvs tree on kernel.org.
The last two are already in Pablo's net tree and I intend
to send a pull request for the remaining 5 soon.
It is my opinion that all 7 patches are stable tree material.
ipvs: kernel oops - do_ip_vs_get_ctl
ipvs: take care of return value from protocol init_netns
ipvs: null check of net->ipvs in lblc(r) shedulers
ipvs: reset ipvs pointer in netns
ipvs: add check in ftp for initialized core
ipvs: fix crash in ip_vs_control_net_cleanup on unload
ipvs: Verify that IP_VS protocol has been registered
^ permalink raw reply
* Re: [v2 PATCH 0/2] ipvs: netns avoid crash at netns init
From: Simon Horman @ 2012-04-26 8:57 UTC (permalink / raw)
To: Julian Anastasov
Cc: Hans Schillstrom, wensong, lvs-devel, netdev, netfilter-devel,
hans
In-Reply-To: <alpine.LFD.2.00.1204261126340.1879@ja.ssi.bg>
On Thu, Apr 26, 2012 at 11:30:00AM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 26 Apr 2012, Hans Schillstrom wrote:
>
> > Two simple patches that avoid crashes for no memory at netns init.
> >
> > - Check return value of protocoll init.
> > - Null check of net-ipvs in shedulers.
> >
> >
> > Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
>
> Both patches look ok
>
> Acked-by: Julian Anastasov <ja@ssi.bg>
Thanks, applied to ipvs.
^ permalink raw reply
* Re: [RFC] allow skb->head to point/alias to first skb frag
From: David Miller @ 2012-04-26 8:36 UTC (permalink / raw)
To: eric.dumazet
Cc: ilpo.jarvinen, rick.jones2, netdev, therbert, ncardwell, maze,
ycheng
In-Reply-To: <1335427854.2775.15.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 26 Apr 2012 10:10:54 +0200
> Idea would have :
>
> 1) struct sk_buff
> 2) skb->head points to frag (aliasing, no memory allocation)
> 3) frag of 2048 (or PAGE_SIZE/2 or PAGE_SIZE)
What would you set skb->data_len and skb->len to?
How would you handle tailroom? We have the rule that you can't append
to the tail of a fragmented SKB (I mean append, the way that IPSEC
wants to write data to the end of an SKB when encrypting, for
example). This is only allowed on fully linear SKBs.
So, for this reason and others, you can't pretend that this new
construction is linear in any way. It would break a bunch of things.
^ permalink raw reply
* Re: [PATCH 1/2] iproute2: allow IPv6 addresses for l2tp local and remote parameters
From: James Chapman @ 2012-04-26 8:32 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Chris Elston
In-Reply-To: <20120425131311.0de3b94f@nehalam.linuxnetplumber.net>
On 25/04/12 21:13, Stephen Hemminger wrote:
> On Fri, 20 Apr 2012 12:29:42 +0100
> James Chapman <jchapman@katalix.com> wrote:
>
>> From: Chris Elston <celston@katalix.com>
>>
>> Adds support for parsing IPv6 addresses to the parameters local and
>> remote in the l2tp commands. Requires netlink attributes L2TP_ATTR_IP6_SADDR
>> and L2TP_ATTR_IP6_DADDR, added in a required kernel patch already submitted
>> to netdev.
>>
>> Also enables printing of IPv6 addresses returned by the L2TP_CMD_TUNNEL_GET
>> request.
>>
>> Signed-off-by: Chris Elston <celston@katalix.com>
>> Signed-off-by: James Chapman <jchapman@katalix.com>
>
> Accepted.
The kernel patches that this code depends on aren't in the tree yet
(kernel header file update). It uses new netlink attributes so the
iproute2 git compile fails.
I suggest revert the patch for now. I'll resubmit when the dependencies
are in the netdev tree.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: [v2 PATCH 0/2] ipvs: netns avoid crash at netns init
From: Julian Anastasov @ 2012-04-26 8:30 UTC (permalink / raw)
To: Hans Schillstrom; +Cc: horms, wensong, lvs-devel, netdev, netfilter-devel, hans
In-Reply-To: <1335426335-5093-1-git-send-email-hans.schillstrom@ericsson.com>
Hello,
On Thu, 26 Apr 2012, Hans Schillstrom wrote:
> Two simple patches that avoid crashes for no memory at netns init.
>
> - Check return value of protocoll init.
> - Null check of net-ipvs in shedulers.
>
>
> Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
Both patches look ok
Acked-by: Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [v2 PATCH 1/1] ipvs: kernel oops - do_ip_vs_get_ctl
From: Julian Anastasov @ 2012-04-26 8:11 UTC (permalink / raw)
To: Hans Schillstrom
Cc: horms, wensong, brouer, rohara, lvs-devel, netdev,
netfilter-devel, hans
In-Reply-To: <1335419264-1225-1-git-send-email-hans.schillstrom@ericsson.com>
Hello,
On Thu, 26 Apr 2012, Hans Schillstrom wrote:
> Change order of init so netns init is ready
> when register ioctl and netlink.
>
> Ver2
> Whitespace fixes and __init added.
>
> Reported-by: "Ryan O'Hara" <rohara@redhat.com>
> Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
Acked-by: Julian Anastasov <ja@ssi.bg>
> ---
> include/net/ip_vs.h | 2 +
> net/netfilter/ipvs/ip_vs_core.c | 9 ++++++
> net/netfilter/ipvs/ip_vs_ctl.c | 52 ++++++++++++++++++++++----------------
> 3 files changed, 41 insertions(+), 22 deletions(-)
>
> diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
> index f967395..93b81aa 100644
> --- a/include/net/ip_vs.h
> +++ b/include/net/ip_vs.h
> @@ -1201,6 +1201,8 @@ ip_vs_lookup_real_service(struct net *net, int af, __u16 protocol,
>
> extern int ip_vs_use_count_inc(void);
> extern void ip_vs_use_count_dec(void);
> +extern int ip_vs_register_nl_ioctl(void);
> +extern void ip_vs_unregister_nl_ioctl(void);
> extern int ip_vs_control_init(void);
> extern void ip_vs_control_cleanup(void);
> extern struct ip_vs_dest *
> diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
> index d8b1d30..c8f36b9 100644
> --- a/net/netfilter/ipvs/ip_vs_core.c
> +++ b/net/netfilter/ipvs/ip_vs_core.c
> @@ -1995,10 +1995,18 @@ static int __init ip_vs_init(void)
> goto cleanup_dev;
> }
>
> + ret = ip_vs_register_nl_ioctl();
> + if (ret < 0) {
> + pr_err("can't register netlink/ioctl.\n");
> + goto cleanup_hooks;
> + }
> +
> pr_info("ipvs loaded.\n");
>
> return ret;
>
> +cleanup_hooks:
> + nf_unregister_hooks(ip_vs_ops, ARRAY_SIZE(ip_vs_ops));
> cleanup_dev:
> unregister_pernet_device(&ipvs_core_dev_ops);
> cleanup_sub:
> @@ -2014,6 +2022,7 @@ exit:
>
> static void __exit ip_vs_cleanup(void)
> {
> + ip_vs_unregister_nl_ioctl();
> nf_unregister_hooks(ip_vs_ops, ARRAY_SIZE(ip_vs_ops));
> unregister_pernet_device(&ipvs_core_dev_ops);
> unregister_pernet_subsys(&ipvs_core_ops); /* free ip_vs struct */
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 7131417..efaf484 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -3750,21 +3750,10 @@ void __net_exit ip_vs_control_net_cleanup(struct net *net)
> free_percpu(ipvs->tot_stats.cpustats);
> }
>
> -int __init ip_vs_control_init(void)
> +int __init ip_vs_register_nl_ioctl(void)
> {
> - int idx;
> int ret;
>
> - EnterFunction(2);
> -
> - /* Initialize svc_table, ip_vs_svc_fwm_table, rs_table */
> - for(idx = 0; idx < IP_VS_SVC_TAB_SIZE; idx++) {
> - INIT_LIST_HEAD(&ip_vs_svc_table[idx]);
> - INIT_LIST_HEAD(&ip_vs_svc_fwm_table[idx]);
> - }
> -
> - smp_wmb(); /* Do we really need it now ? */
> -
> ret = nf_register_sockopt(&ip_vs_sockopts);
> if (ret) {
> pr_err("cannot register sockopt.\n");
> @@ -3776,28 +3765,47 @@ int __init ip_vs_control_init(void)
> pr_err("cannot register Generic Netlink interface.\n");
> goto err_genl;
> }
> -
> - ret = register_netdevice_notifier(&ip_vs_dst_notifier);
> - if (ret < 0)
> - goto err_notf;
> -
> - LeaveFunction(2);
> return 0;
>
> -err_notf:
> - ip_vs_genl_unregister();
> err_genl:
> nf_unregister_sockopt(&ip_vs_sockopts);
> err_sock:
> return ret;
> }
>
> +void ip_vs_unregister_nl_ioctl(void)
> +{
> + ip_vs_genl_unregister();
> + nf_unregister_sockopt(&ip_vs_sockopts);
> +}
> +
> +int __init ip_vs_control_init(void)
> +{
> + int idx;
> + int ret;
> +
> + EnterFunction(2);
> +
> + /* Initialize svc_table, ip_vs_svc_fwm_table, rs_table */
> + for (idx = 0; idx < IP_VS_SVC_TAB_SIZE; idx++) {
> + INIT_LIST_HEAD(&ip_vs_svc_table[idx]);
> + INIT_LIST_HEAD(&ip_vs_svc_fwm_table[idx]);
> + }
> +
> + smp_wmb(); /* Do we really need it now ? */
> +
> + ret = register_netdevice_notifier(&ip_vs_dst_notifier);
> + if (ret < 0)
> + return ret;
> +
> + LeaveFunction(2);
> + return 0;
> +}
> +
>
> void ip_vs_control_cleanup(void)
> {
> EnterFunction(2);
> unregister_netdevice_notifier(&ip_vs_dst_notifier);
> - ip_vs_genl_unregister();
> - nf_unregister_sockopt(&ip_vs_sockopts);
> LeaveFunction(2);
> }
> --
> 1.7.2.3
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [RFC] allow skb->head to point/alias to first skb frag
From: Eric Dumazet @ 2012-04-26 8:10 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: David Miller, rick.jones2, Netdev, therbert, ncardwell, maze,
Yuchung Cheng
In-Reply-To: <1335257803.5205.133.camel@edumazet-glaptop>
On Tue, 2012-04-24 at 10:56 +0200, Eric Dumazet wrote:
> Really I have many doubts about GRO today.
Particularly if a NIC driver provides linear skbs :
Resulting gro skb is a list of skbs, no memory savings, and many cache
line misses when copying to userland.
Maybe we could have a new kind of skb head allocation/setup, pointing to
a frag of 2048 bytes instead of a kmalloc() blob.
Right now, a fragged skb used 3 blocks of memory :
1) struct sk_buff
2) a bloc of 512 or 1024 or 2048 bytes of memory (skb->head)
3) a frag of 2048 (or PAGE_SIZE/2 or PAGE_SIZE)
While a linear skb has :
1) struct sk_buff
2) a bloc of 512 or 1024 or 2048 bytes of memory (skb->head) from
kmalloc()
Idea would have :
1) struct sk_buff
2) skb->head points to frag (aliasing, no memory allocation)
3) frag of 2048 (or PAGE_SIZE/2 or PAGE_SIZE)
Or the reverse (no frag so that skb is considered as linea), but special
code to 'allow' this skb head be considered as a frag when needed
(splice() code, or GRO merge, or TCP coalescing)
That would make GRO (and TCP coalescing) much more efficient, since the
resulting aggregated skb would be :
1) struct sk_buff
2) skb->head points to 1st frag (aliasing, no memory allocation)
3) array of [1..16] frags
^ permalink raw reply
* Re: [v2 PATCH 1/1] ipvs: kernel oops - do_ip_vs_get_ctl
From: Jesper Dangaard Brouer @ 2012-04-26 8:10 UTC (permalink / raw)
To: Hans Schillstrom
Cc: horms, ja, wensong, rohara, lvs-devel, netdev, netfilter-devel,
hans
In-Reply-To: <1335419264-1225-1-git-send-email-hans.schillstrom@ericsson.com>
On Thu, 2012-04-26 at 07:47 +0200, Hans Schillstrom wrote:
> Change order of init so netns init is ready
> when register ioctl and netlink.
>
> Ver2
> Whitespace fixes and __init added.
>
> Reported-by: "Ryan O'Hara" <rohara@redhat.com>
> Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
Looks good, interdiff says you fixed up things, and I have tested it
against the net tree, good work :-)
Is this a stable tree candidate?
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [net-next 1/4 (V3)] net: ethtool: add the EEE support
From: Giuseppe CAVALLARO @ 2012-04-26 7:48 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, rayagond, davem
In-Reply-To: <1334849401.2426.73.camel@bwh-desktop.uk.solarflarecom.com>
Hello Ben
On 4/19/2012 5:30 PM, Ben Hutchings wrote:
[snip]
>> I'm changing the code for getting/setting the EEE capability and trying
>> to follow your suggestions.
>>
>> The "get" will show the following things; this is a bit different of the
>> points "a" "b" and "c" we had discussed. Maybe, this could also be a
>> more complete (*) .
>> The ethtool (see output below as example) could report the phy
>> (supported/advertised/lp_advertised) and mac eee capabilities separately.
>
> Sounds reasonable.
>
>> The "set" will be useful for some eth devices (like the stmmac) that can
>> stop/enable internally the eee capability (at mac level).
>
> I don't know much about EEE, but shouldn't the driver take care of
> configuring the MAC for this whenever the PHY is set to advertise EEE
> capability?
Yes indeed this can be done at driver level. So could I definitely
remove it from ethtool? What do you suggest?
In case of the stmmac I could add a specific driver option via sys to
enable/disable the eee and set timer.
>> [snip]
>>
>> Current message level: 0x0000003f (63)
>> drv probe link timer ifdown ifup
>> Link detected: yes
>> Energy-Efficient Ethernet: -------------------------
>> MAC supports: yes |-> related to MAC side |
>> phy supports modes: ... |-> from MMD 3.20 |
>> phy advertising modes: ... |-> from MMD 7.60 |
>> LP advertising modes: ... |-> from MMD 7.61 |
>> --------------------------
>> (*)
>> PS. The "..." above means that we can actually dump: 100BASE-TX EEE etc
>> for each advertising modes and also for phy support (reg 3.20).
>
> Yes, that's the sort of information I would expect to see (but try to be
> consistent with the wording used for AN).:
e.g. SUPPORTED_100baseT_EEE ... ADVERTISED_<...>
> The EEE advertising mask presumably should be changeable similarly to
> the AN advertising mask ('ethtool -s <devname> eeeadv <mask>'). But I
> don't know how the two advertising masks interact. Is one supposed to
> be a subset of the other? Currently ethtool automatically changes the
> AN advertising mask in response to a speed/duplex change; should it also
> try to change the EEE advertising mask?
I've just verified the IEEE (Table 45–150a—EEE advertisement register
(Register 7.60) bit definitions) and sorry for my delay in reply but I
was in trouble because looking at the registers for the phy (I am using)
the reg 7.60 was in RO and I couldn't understand how to set the mask.
I confirm that the Adv reg from the std is R/W and the mask as you
suggest could be set according to the speed.
The EEE should work on duplex mode only.
I wonder so if if the final patch I should have no new option for the
ethtool command and EEE info are directly passed from the kernel like
speed and duplex when call get_settings.
Peppe
>
> Ben.
>
^ 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