* 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
* [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 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
* 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: [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 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: [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] 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: [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 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 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] 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: [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 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: [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: [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: [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: [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: [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 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 4/7] net/fsl_pq_mdio: various small fixes
From: David Miller @ 2012-08-30 17:30 UTC (permalink / raw)
To: timur; +Cc: afleming, netdev
In-Reply-To: <1346263683-3664-4-git-send-email-timur@freescale.com>
From: Timur Tabi <timur@freescale.com>
Date: Wed, 29 Aug 2012 13:08:00 -0500
> 1) Replace printk with dev_err
>
> 2) Fix some whitespace mistakes
>
> 3) Rename "ofdev" to "pdev", since it's a platform_device now
>
> 4) Fix an inadvertent compound statement by replacing commas with semicolons
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 5/7] net/fsl_pq_mdio: streamline probing of MDIO nodes
From: David Miller @ 2012-08-30 17:31 UTC (permalink / raw)
To: timur; +Cc: afleming, netdev
In-Reply-To: <1346263683-3664-5-git-send-email-timur@freescale.com>
From: Timur Tabi <timur@freescale.com>
Date: Wed, 29 Aug 2012 13:08:01 -0500
> Make the device tree probe function more data-driven, so that it no longer
> searches the 'compatible' property more than once. The of_device_id[] array
> allows for per-entry private data, so we use that to store details about each
> type of node that the driver supports. This removes the need to check the
> 'compatible' property inside the probe function.
>
> The driver supports four types on MDIO devices:
>
> 1) Gianfar MDIO nodes that only map the MII registers
> 2) Gianfar MDIO nodes that map the full MDIO register set
> 3) eTSEC2 MDIO nodes (which map the full MDIO register set)
> 4) QE MDIO nodes (which map only the MII registers)
>
> Gianfar, eTSEC2, and QE have different mappings for the TBIPA register, which
> is needed to initialize the TBI PHY. In addition, the QE needs a special
> hack because of the way the device tree is ordered.
>
> All of this information is encapsulated in the fsl_pq_mdio_data structure,
> so when an MDIO node is probed, per-device data and functions are used
> to determine how to initialize the device.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 6/7] net/fsl-pq-mdio: coalesce multiple memory allocations into one
From: David Miller @ 2012-08-30 17:31 UTC (permalink / raw)
To: timur; +Cc: afleming, netdev
In-Reply-To: <1346263683-3664-6-git-send-email-timur@freescale.com>
From: Timur Tabi <timur@freescale.com>
Date: Wed, 29 Aug 2012 13:08:02 -0500
> Take advantage of the new mdiobus_alloc_size() function to combine three
> different memory allocations into one. This also simplies the error
> handling.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 7/7] [v2] net/fsl_pq_mdio: add support for the Fman 1G MDIO controller
From: David Miller @ 2012-08-30 17:31 UTC (permalink / raw)
To: timur; +Cc: afleming, netdev
In-Reply-To: <1346263683-3664-7-git-send-email-timur@freescale.com>
From: Timur Tabi <timur@freescale.com>
Date: Wed, 29 Aug 2012 13:08:03 -0500
> The MDIO controller on the Frame Manager (Fman) is compatible with the
> QE and Gianfar MDIO controllers, but we don't care about the TBI because
> the Ethernet drivers (FMD) take care of programming it.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Applied to net-next.
^ permalink raw reply
* Re: route.c:645 suspicious rcu_dereference_check()
From: David Miller @ 2012-08-30 17:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: proski, netdev
In-Reply-To: <1346193187.3571.21.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 28 Aug 2012 15:33:07 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> [PATCH] ipv4: must use rcu protection while calling fib_lookup
>
> Following lockdep splat was reported by Pavel Roskin :
...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Pavel Roskin <proski@gnu.org>
Applied, thanks.
It looks like the redirect handlers might have the same problem?
^ 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