* Re: [PATCH 3/7] net/fsl_pq_mdio: merge some functions together
From: David Miller @ 2012-08-30 17:30 UTC (permalink / raw)
To: timur; +Cc: afleming, netdev
In-Reply-To: <1346263683-3664-3-git-send-email-timur@freescale.com>
From: Timur Tabi <timur@freescale.com>
Date: Wed, 29 Aug 2012 13:07:59 -0500
> A few small functions were called only by other functions in the same
> file, so merge them together. One function, for example, was calculating
> the device address even though the caller was doing the same thing.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 2/7] net/fsl_pq_mdio: trim #include statements
From: David Miller @ 2012-08-30 17:30 UTC (permalink / raw)
To: timur; +Cc: afleming, netdev
In-Reply-To: <1346263683-3664-2-git-send-email-timur@freescale.com>
From: Timur Tabi <timur@freescale.com>
Date: Wed, 29 Aug 2012 13:07:58 -0500
> Remove several unnecessary #include statements.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 1/7] net/freescale: do not export any functions from fsl_pq_mdio.c
From: David Miller @ 2012-08-30 17:30 UTC (permalink / raw)
To: timur; +Cc: afleming, netdev
In-Reply-To: <1346263683-3664-1-git-send-email-timur@freescale.com>
From: Timur Tabi <timur@freescale.com>
Date: Wed, 29 Aug 2012 13:07:57 -0500
> None of the functions in fsl_pq_mdio.c are used by any other source file,
> so there's no point in exporting them. Merge the header file into the
> source file, make all the functions static, remove any EXPORT_SYMBOL
> statements, and delete any #include "fsl_pq_mdio.h" statements.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Applied to net-next.
^ permalink raw reply
* Re: [RFC] Move in6_dev_hold under CONFIG_IPV6_PRIVACY
From: Eric Dumazet @ 2012-08-30 17:28 UTC (permalink / raw)
To: David Marchand; +Cc: netdev
In-Reply-To: <503F9A30.6030100@pace.com>
On Thu, 2012-08-30 at 18:52 +0200, David Marchand wrote:
> Mmm, ok.
> But if CONFIG_IPV6_PRIVACY is not selected, then I can't find where the associated in6_dev_put is done for this in6_dev_hold.
> Besides, __ipv6_regen_rndid is a "CONFIG_IPV6_PRIVACY-only" stuff.
>
Okay.
Look at addrconf_ifdown(), line 2850
in6_dev_put(idev);
Will finally remove the last reference
With your patch, I guess there will be a reference problem, and possibly
call in6_dev_finish_destroy() too soon.
You are mistaken, because the reference taken in PRIVACY is at line 421,
right before calling ipv6_regen_rndid()
Look at following commit to have an idea of the underlying problem
http://git.kernel.org/?p=linux/kernel/git/davem/net.git;a=commit;h=144d56e91044181ec0ef67aeca91e9a8b5718348
^ permalink raw reply
* Re: [net-next PATCH 0/5] be2net fixes
From: David Miller @ 2012-08-30 17:27 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <68712d56-8bf1-48bf-9408-4a5081ea17ee@exht1.ad.emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Wed, 29 Aug 2012 12:07:39 +0530
> Pls apply.
>
> Sathya Perla (2):
> be2net: create RSS rings even in multi-channel configs
> be2net: fixup malloc/free of adapter->pmac_id
>
> Vasundhara Volam (3):
> be2net: fix max VFs reported by HW
> be2net: fix FW default for VF tx-rate
> be2net: modify log msg for lack of privilege error
All applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH 0/2]: ieee802154 drivers location
From: David Miller @ 2012-08-30 17:24 UTC (permalink / raw)
To: alex.bluesman.smirnov; +Cc: netdev, dbaryshkov
In-Reply-To: <1345993811-13803-1-git-send-email-alex.bluesman.smirnov@gmail.com>
From: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
Date: Sun, 26 Aug 2012 19:10:09 +0400
> Please review these two patches:
>
> 1. I want to keep 'ieee802154' drivers with other networking code in
> 'drivers/net' folder instead of current location in drivers root.
> I don't exactly know this historical reason, but lets keep networking
> code together.
> 2. Minor cosmetic improvement in at86rf230 driver
Both applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH 0/5] dev_<level> and dynamic_debug cleanups
From: David Miller @ 2012-08-30 17:16 UTC (permalink / raw)
To: joe; +Cc: akpm, netdev, gregkh, jbaron, jim.cromie, kay, linux-kernel
In-Reply-To: <cover.1345978012.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 26 Aug 2012 04:25:25 -0700
> The recent commit to fix dynamic_debug was a bit unclean.
> Neaten the style for dynamic_debug.
> Reduce the stack use of message logging that uses netdev_printk
> Add utility functions dev_printk_emit and dev_vprintk_emit for /dev/kmsg.
I think these should go through the generic device tree, feel free to
add my:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [net PATCH 1/1] bnx2x: fix 57840_MF pci id
From: David Miller @ 2012-08-30 17:13 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, eilong, mchan
In-Reply-To: <1345977345-3721-1-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Sun, 26 Aug 2012 13:35:45 +0300
> Commit c3def943c7117d42caaed3478731ea7c3c87190e have added support for
> new pci ids of the 57840 board, while failing to change the obsolete value
> in 'pci_ids.h'.
> This patch does so, allowing the probe of such devices.
>
> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] netlink: add minlen validation for the new signed types
From: David Miller @ 2012-08-30 17:12 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <1345970877-4408-1-git-send-email-ja@ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Sun, 26 Aug 2012 11:47:57 +0300
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
Applied to net-next, thanks Julian.
^ permalink raw reply
* Re: [PATCH 2/2] drivers/net/ethernet/tundra/tsi108_eth.c: delete double assignment
From: David Miller @ 2012-08-30 17:09 UTC (permalink / raw)
To: Julia.Lawall; +Cc: netdev, kernel-janitors, linux-kernel
In-Reply-To: <1345969115-12977-2-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Sun, 26 Aug 2012 10:18:35 +0200
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Delete successive assignments to the same location.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied to net-next, thanks Julia.
^ permalink raw reply
* Re: [PATCH net-next v1 0/3] forcedeth: fix device lock-up for dual-port NICs
From: David Miller @ 2012-08-30 17:05 UTC (permalink / raw)
To: decot; +Cc: aabdulla, netdev, linux-kernel, edumazet, joe
In-Reply-To: <cover.1345864542.git.decot@googlers.com>
From: David Decotigny <decot@googlers.com>
Date: Fri, 24 Aug 2012 20:22:50 -0700
> On a dual port MCP55 10de:0373 (rev a3) NIC with both ports connected,
> we identified a configuration that does freeze the whole NIC: having
> autoneg & TX pause turned on while one port is physically connected
> but interface is down (eg. eth1) eventually causes the whole NIC to
> freeze (eth1 and... eth0). This triggers TX timeouts on the UP
> interface and, more generally, an unreachable network.
>
> In order to avoid the bug, all we have to do is make sure not to
> configure TX pause on the hardware while NIC is down. This is what the
> 2nd patch of the series does (details included).
>
> And, in case the NIC is in a bad state at reboot (should not happen
> anymore thanks to patch above), third patch basically always makes
> sure to fix the NIC when module is loaded.
>
> I could only test this with a MCP55 10de:0373 (rev a3) PCI device on a
> x86_64 host.
All applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] [v3] netdev/phy: add MDIO bus multiplexer driven by a memory-mapped device
From: David Miller @ 2012-08-30 16:55 UTC (permalink / raw)
To: timur; +Cc: afleming, swarren, ddaney.cavm, devicetree-discuss, netdev
In-Reply-To: <1345835453-8611-1-git-send-email-timur@freescale.com>
From: Timur Tabi <timur@freescale.com>
Date: Fri, 24 Aug 2012 14:10:53 -0500
> Add support for an MDIO bus multiplexer controlled by a simple memory-mapped
> device, like an FPGA. The device must be memory-mapped and contain only
> 8-bit registers (which keeps things simple).
>
> Tested on a Freescale P5020DS board which uses the "PIXIS" FPGA attached
> to the localbus.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH 1/1] net: ipv4: ipmr_expire_timer causes crash when removing net namespace
From: David Miller @ 2012-08-30 16:52 UTC (permalink / raw)
To: fruggeri; +Cc: netdev
In-Reply-To: <CA+HUmGhEaTD7QgYyfhDB22K1=Oj3RvDi2Ny217-YFXV03HJzqg@mail.gmail.com>
From: Francesco Ruggeri <fruggeri@aristanetworks.com>
Date: Fri, 24 Aug 2012 10:38:35 -0700
> When tearing down a net namespace, ipv4 mr_table structures are freed
> without first deactivating their timers. This can result in a crash in
> run_timer_softirq.
> This patch mimics the corresponding behaviour in ipv6.
> Locking and synchronization seem to be adequate.
> We are about to kfree mrt, so existing code should already make sure that
> no other references to mrt are pending or can be created by incoming traffic.
> The functions invoked here do not cause new references to mrt or other
> race conditions to be created.
> Invoking del_timer_sync guarantees that ipmr_expire_timer is inactive.
> Both ipmr_expire_process (whose completion we may have to wait in
> del_timer_sync) and mroute_clean_tables internally use mfc_unres_lock
> or other synchronizations when needed, and they both only modify mrt.
>
> Tested in Linux 3.4.8.
>
> Signed-off-by: Francesco Ruggeri <fruggeri@aristanetworks.com>
Applied, and queued up for -stable, thanks.
I think we have another problem. mroute_clean_tables() skips MRT_STATIC
cache entries, and does not purge them.
I can't see anything that will ever free those static entries up at all.
^ permalink raw reply
* Re: [RFC] Move in6_dev_hold under CONFIG_IPV6_PRIVACY
From: David Marchand @ 2012-08-30 16:52 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1346340321.2586.24.camel@edumazet-glaptop>
On 30/08/2012 17:25, Eric Dumazet wrote:
> Your patch was mangled by your email client, and its always safer to
> test a patch...
Sorry about that, I am not used to sending patch (tried again, I hope it is fine this time ...).
I did try my patch in my setup, and did not notice any problem at the moment.
I sent this patch as a rfc, mainly because I want to know if my analysis is correct (and if not, understand why).
> Dont trust the comment, its a bit misleading.
>
> Comment intent was to say :
>
> /* One reference from device. We must do this before
> * we eventually invoke __ipv6_regen_rndid().
> */
>
Mmm, ok.
But if CONFIG_IPV6_PRIVACY is not selected, then I can't find where the associated in6_dev_put is done for this in6_dev_hold.
Besides, __ipv6_regen_rndid is a "CONFIG_IPV6_PRIVACY-only" stuff.
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 6bc85f7..263fcf3 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -393,11 +393,6 @@ static struct inet6_dev *ipv6_add_dev(struct net_device *dev)
return NULL;
}
- /* One reference from device. We must do this before
- * we invoke __ipv6_regen_rndid().
- */
- in6_dev_hold(ndev);
-
if (dev->flags & (IFF_NOARP | IFF_LOOPBACK))
ndev->cnf.accept_dad = -1;
@@ -410,6 +405,12 @@ static struct inet6_dev *ipv6_add_dev(struct net_device *dev)
#ifdef CONFIG_IPV6_PRIVACY
INIT_LIST_HEAD(&ndev->tempaddr_list);
+
+ /* One reference from device. We must do this before
+ * we invoke ipv6_regen_rndid().
+ */
+ in6_dev_hold(ndev);
+
setup_timer(&ndev->regen_timer, ipv6_regen_rndid, (unsigned long)ndev);
if ((dev->flags&IFF_LOOPBACK) ||
dev->type == ARPHRD_TUNNEL ||
--
David Marchand
This message has been scanned for viruses by BlackSpider MailControl. - www.blackspider.com
^ permalink raw reply related
* Re: [PATCH 1/1] tcp: Wrong timeout for SYN segments
From: David Miller @ 2012-08-30 16:45 UTC (permalink / raw)
To: eric.dumazet; +Cc: hkjerry.chu, alex, netdev, linux-kernel
In-Reply-To: <1346332350.2586.10.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 30 Aug 2012 06:12:30 -0700
> On Wed, 2012-08-29 at 10:25 -0700, H.K. Jerry Chu wrote:
>
>> But it probably matter slightly more for TCP Fast Open (the server
>> side patch has
>> been completed and will be posted soon, after I finish breaking it up
>> into smaller
>> pieces for ease of review purpose), when a full socket will be created with data
>> passed to the app upon a valid SYN+data. Dropping a fully functioning socket
>> won't be the same as dropping a request_sock unknown to the app and letting
>> the other side retransmitting SYN (w/o data this time).
>>
>> >
>> > Sure, RFC numbers are what they are, but in practice, I doubt someone
>> > will really miss the extra SYNACK sent after ~32 seconds, since it would
>> > matter only for the last SYN attempted.
>>
>> I'd slightly prefer 1 extra retry plus longer wait time just to make
>> TCP Fast Open
>> a little more robust (even though the app protocol is required to be
>> idempotent).
>> But this is not a showstopper.
>
> Thats very good points indeed, thanks.
>
> Maybe we can increase SYNACK max retrans only if the FastOpen SYN cookie
> was validated.
>
> This way, we increase reliability without amplifying the effect of wild
> SYN packets.
Can we come to a final conclusion on this last point and arrive at a final
patch?
Thanks.
^ permalink raw reply
* Re: [net] e1000e: DoS while TSO enabled caused by link partner with small MSS
From: David Miller @ 2012-08-30 16:40 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: bruce.w.allan, netdev, gospo, sassmann, bhutchings, stable
In-Reply-To: <1345876691-22254-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 24 Aug 2012 23:38:11 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> With a low enough MSS on the link partner and TSO enabled locally, the
> networking stack can periodically send a very large (e.g. 64KB) TCP
> message for which the driver will attempt to use more Tx descriptors than
> are available by default in the Tx ring. This is due to a workaround in
> the code that imposes a limit of only 4 MSS-sized segments per descriptor
> which appears to be a carry-over from the older e1000 driver and may be
> applicable only to some older PCI or PCIx parts which are not supported in
> e1000e. When the driver gets a message that is too large to fit across the
> configured number of Tx descriptors, it stops the upper stack from queueing
> any more and gets stuck in this state. After a timeout, the upper stack
> assumes the adapter is hung and calls the driver to reset it.
>
> Remove the unnecessary limitation of using up to only 4 MSS-sized segments
> per Tx descriptor, and put in a hard failure test to catch when attempting
> to check for message sizes larger than would fit in the whole Tx ring.
> Refactor the remaining logic that limits the size of data per Tx descriptor
> from a seemingly arbitrary 8KB to a limit based on the dynamic size of the
> Tx packet buffer as described in the hardware specification.
>
> Also, fix the logic in the check for space in the Tx ring for the next
> largest possible packet after the current one has been successfully queued
> for transmit, and use the appropriate defines for default ring sizes in
> e1000_probe instead of magic values.
>
> This issue goes back to the introduction of e1000e in 2.6.24 when it was
> split off from e1000.
>
> Reported-by: Ben Hutchings <bhutchings@solarflare.com>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Cc: Stable <stable@vger.kernel.org> [2.6.24+]
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 3.6.0-rc3 2/2] of/mdio-gpio: Simplify the way device tree support is implemented.
From: David Miller @ 2012-08-30 16:38 UTC (permalink / raw)
To: srinivas.kandagatla; +Cc: netdev, laurentp, devicetree-discuss, grant.likely
In-Reply-To: <1345809557-27727-1-git-send-email-srinivas.kandagatla@st.com>
From: Srinivas KANDAGATLA <srinivas.kandagatla@st.com>
Date: Fri, 24 Aug 2012 12:59:17 +0100
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> This patch cleans up the way device tree support is added in mdio-gpio
> driver. I found lot of code duplication which is not necessary.
> Also strangely a new platform driver was also introduced for device tree
> support. All this forced me to do this cleanup patch.
> After this patch, the driver probe checks the of_node pointer to get the
> data from device tree.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 3.6.0-rc3 1/2] of/mdio: Add dummy functions in of_mdio.h.
From: David Miller @ 2012-08-30 16:38 UTC (permalink / raw)
To: srinivas.kandagatla; +Cc: netdev, laurentp, devicetree-discuss, grant.likely
In-Reply-To: <1345809539-27684-1-git-send-email-srinivas.kandagatla@st.com>
From: Srinivas KANDAGATLA <srinivas.kandagatla@st.com>
Date: Fri, 24 Aug 2012 12:58:59 +0100
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> This patch adds dummy functions in of_mdio.h, so that driver need not
> ifdef there code with CONFIG_OF.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Applied to net-next.
^ permalink raw reply
* [PATCH] net: ethernet: fix kernel OOPS when remove davinci_mdio module
From: Bin Liu @ 2012-08-30 16:37 UTC (permalink / raw)
To: mugunthanvnm, vaibhav.bedia, netdev, linux-kernel; +Cc: b-liu
davinci mdio device is not unregistered from mdiobus when removing
the module, which causes BUG_ON() when free the device from mdiobus.
Calling mdiobus_unregister() before mdiobus_free() fixes the issue.
Signed-off-by: Bin Liu <b-liu@ti.com>
---
drivers/net/ethernet/ti/davinci_mdio.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index 0c2fcdd..7de19a5 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -391,8 +391,10 @@ static int __devexit davinci_mdio_remove(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct davinci_mdio_data *data = dev_get_drvdata(dev);
- if (data->bus)
+ if (data->bus) {
+ mdiobus_unregister(data->bus);
mdiobus_free(data->bus);
+ }
if (data->clk)
clk_put(data->clk);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH net-next] netpoll: provide an IP ident in UDP frames
From: David Miller @ 2012-08-30 16:32 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1345808846.29722.133.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 24 Aug 2012 13:47:26 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Let's fill IP header ident field with a meaningful value,
> it might help some setups.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 1/1] l2tp: avoid to use synchronize_rcu in tunnel free function
From: David Miller @ 2012-08-30 16:31 UTC (permalink / raw)
To: xeb; +Cc: netdev, kleptog, jchapman
In-Reply-To: <1430615.YYms4uRCh4@dima>
From: Kozlov Dmitry <xeb@mail.ru>
Date: Fri, 24 Aug 2012 15:07:38 +0400
> Avoid to use synchronize_rcu in l2tp_tunnel_free because context may be
> atomic.
>
> Signed-off-by: Dmitry Kozlov <xeb@mail.ru>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] netvm: check for page == NULL when propogating the skb->pfmemalloc flag
From: David Miller @ 2012-08-30 16:24 UTC (permalink / raw)
To: konrad.wilk
Cc: Ian.Campbell, mgorman, linux-mm, linux-kernel, netdev, xen-devel,
konrad, akpm
In-Reply-To: <20120823141740.GA30305@phenom.dumpdata.com>
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 23 Aug 2012 10:17:40 -0400
> On Wed, Aug 22, 2012 at 11:26:47AM +0100, Ian Campbell wrote:
>> On Wed, 2012-08-08 at 23:50 +0100, David Miller wrote:
>> > Just use something like a call to __pskb_pull_tail(skb, len) and all
>> > that other crap around that area can simply be deleted.
>>
>> I think you mean something like this, which works for me, although I've
>> only lightly tested it.
>>
>
> I've tested it heavily and works great.
>
> Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> and I took a look at it too and:
>
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Applied, thanks everyone.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net-next v2] net: dev: fix the incorrect hold of net namespace's lo device
From: David Miller @ 2012-08-30 16:22 UTC (permalink / raw)
To: gaofeng; +Cc: netdev, eric.dumazet, ebiederm
In-Reply-To: <1345772215-30379-1-git-send-email-gaofeng@cn.fujitsu.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Fri, 24 Aug 2012 09:36:55 +0800
> When moving a net device from one net namespace to another
> net namespace,dev_change_net_namespace calls NETDEV_DOWN
> event,so the original net namespace's dst entries which
> beloned to this net device will be put into dst_garbage
> list.
>
> then dev_change_net_namespace will set this net device's
> net to the new net namespace.
>
> If we unregister this net device's driver, this will trigger
> the NETDEV_UNREGISTER_FINAL event, dst_ifdown will be called,
> and get this net device's dst entries from dst_garbage list,
> put these entries' dev to the new net namespace's lo device.
>
> It's not what we want,actually we need these dst entries hold
> the original net namespace's lo device,this incorrect device
> holding will trigger emg message like below.
> unregister_netdevice: waiting for lo to become free. Usage count = 1
>
> so we should call NETDEV_UNREGISTER_FINAL event in
> dev_change_net_namespace too,in order to make sure dst entries
> already in the dst_garbage list, we need rcu_barrier before we
> call NETDEV_UNREGISTER_FINAL event.
>
> With help form Eric Dumazet.
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH RFC 1/2] tcp: add generic netlink support for tcp_metrics
From: David Miller @ 2012-08-30 16:20 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <1345734105-28328-2-git-send-email-ja@ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Thu, 23 Aug 2012 18:01:44 +0300
> Add support for genl "tcp_metrics". No locking
> is changed, only that now we can unlink and delete
> entries after grace period. We implement get/del for
> single entry and dump to support show/flush filtering
> in user space.
>
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
I like it.
Please address Eric Dumazet's feedback and resubmit, thanks!
^ permalink raw reply
* Re: [PATCH] rtnl_wilddump_request: fix alignment issue for embedded platforms
From: Lutz Jaenicke @ 2012-08-30 16:09 UTC (permalink / raw)
To: David Laight; +Cc: netdev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B6FC9@saturn3.aculab.com>
On Thu, Aug 30, 2012 at 04:51:49PM +0100, David Laight wrote:
> > + /* attribute has to be NLMSG aligned */
> > + struct rtattr ext_req
> __attribute__((aligned(NLMSG_ALIGNTO)));
>
> Would it be better to apply the attribute to the definition
> of 'struct rtattr' itself ?
'struct rtattr' is defined in a kernel header and I am not really sure
what kind of side effects it would have.
The problem I intend to solve with my page is rather caused by the use case:
The request is sent as a single structure, the processing is however
performed step by step: first the nlmsg is parsed, then the pointer
is moved on to the parsing of the content. This pointer is hoever not
oriented at the structure element but by using size information which
is then adjust by NLMSG_ALIGN() etc. Consequently one should actually
use the same method in sending (generate the header first, then addattr_()
which enforces protocol conform alignment). This is the way all other
instances in iproute2 generate their messages btw.
I hence consider my proposed patch to be the least intrusive solution.
Best regards,
Lutz
--
Dr.-Ing. Lutz Jänicke
CTO
Innominate Security Technologies AG /protecting industrial networks/
tel: +49.30.921028-200
fax: +49.30.921028-020
Rudower Chaussee 13
D-12489 Berlin, Germany
www.innominate.com
Register Court: AG Charlottenburg, HR B 81603
Management Board: Dirk Seewald
Chairman of the Supervisory Board: Christoph Leifer
^ 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