* Re: [PATCHv4 3/4] sparc64: Avoid irqsave/restore on vio.lock if in_softirq()
From: Julian Calaby @ 2014-10-21 22:42 UTC (permalink / raw)
To: Sowmini Varadhan; +Cc: David S. Miller, netdev, sparclinux
In-Reply-To: <20141021223952.GA26724@oracle.com>
Hi Sowmini,
On Wed, Oct 22, 2014 at 9:39 AM, Sowmini Varadhan
<sowmini.varadhan@oracle.com> wrote:
> On (10/22/14 09:35), Julian Calaby wrote:
>> > void vio_port_up(struct vio_driver_state *vio)
>> > {
>> > - unsigned long flags;
>> > + unsigned long flags = 0;
>>
>> Is gcc not smart enough to know that this variable isn't used before
>> it's set? (I assume it isn't used elsewhere in this function)
>
> No, it's not used elsewhere in the function, and yes, I too was
> surprised by the build warning, which is why I initialized it
> as above.
Ok, fair enough then.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCHv4 3/4] sparc64: Avoid irqsave/restore on vio.lock if in_softirq()
From: Sowmini Varadhan @ 2014-10-21 22:39 UTC (permalink / raw)
To: Julian Calaby; +Cc: David S. Miller, netdev, sparclinux
In-Reply-To: <CAGRGNgXvKJBhOE1z3=_gZkE=X94HnoAvTN6Zv5G1h8JuFfS8Ng@mail.gmail.com>
On (10/22/14 09:35), Julian Calaby wrote:
> > void vio_port_up(struct vio_driver_state *vio)
> > {
> > - unsigned long flags;
> > + unsigned long flags = 0;
>
> Is gcc not smart enough to know that this variable isn't used before
> it's set? (I assume it isn't used elsewhere in this function)
No, it's not used elsewhere in the function, and yes, I too was
surprised by the build warning, which is why I initialized it
as above.
--Sowmini
^ permalink raw reply
* Re: [PATCHv4 3/4] sparc64: Avoid irqsave/restore on vio.lock if in_softirq()
From: Julian Calaby @ 2014-10-21 22:35 UTC (permalink / raw)
To: Sowmini Varadhan; +Cc: David S. Miller, netdev, sparclinux
In-Reply-To: <20141021141647.GF15405@oracle.com>
Hi Sowmini,
On Wed, Oct 22, 2014 at 1:16 AM, Sowmini Varadhan
<sowmini.varadhan@oracle.com> wrote:
> For NAPIfied drivers , there is no need to
> synchronize by doing irqsave/restore on vio.lock in the I/O
> path.
>
> Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
> ---
> arch/sparc/kernel/viohs.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/sparc/kernel/viohs.c b/arch/sparc/kernel/viohs.c
> index 7ef081a..d731586 100644
> --- a/arch/sparc/kernel/viohs.c
> +++ b/arch/sparc/kernel/viohs.c
> @@ -747,10 +747,11 @@ EXPORT_SYMBOL(vio_ldc_free);
>
> void vio_port_up(struct vio_driver_state *vio)
> {
> - unsigned long flags;
> + unsigned long flags = 0;
Is gcc not smart enough to know that this variable isn't used before
it's set? (I assume it isn't used elsewhere in this function)
> int err, state;
>
> - spin_lock_irqsave(&vio->lock, flags);
> + if (!in_softirq())
> + spin_lock_irqsave(&vio->lock, flags);
>
> state = ldc_state(vio->lp);
>
> @@ -777,7 +778,8 @@ void vio_port_up(struct vio_driver_state *vio)
> mod_timer(&vio->timer, expires);
> }
>
> - spin_unlock_irqrestore(&vio->lock, flags);
> + if (!in_softirq())
> + spin_unlock_irqrestore(&vio->lock, flags);
> }
> EXPORT_SYMBOL(vio_port_up);
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCH] Documentation: ptp: Fix build failure on MIPS cross builds
From: Peter Foley @ 2014-10-21 22:04 UTC (permalink / raw)
To: Richard Cochran
Cc: David Daney, David Miller, markos.chandras, linux-mips, corbet,
netdev, linux-doc@vger.kernel.org, LKML
In-Reply-To: <20141021182757.GA3960@localhost.localdomain>
On Tue, Oct 21, 2014 at 2:27 PM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Tue, Oct 21, 2014 at 09:58:51AM -0700, David Daney wrote:
>> What I don't understand is why we are using hostprogs in this
>> Makefile. Isn't this a program that would run on the target, not
>> the build host?
>
> Yes.
>
> Peter, could you please fix it?
The intention of these changes was to generate more compiliation
coverage for code in Documentation/
The underlying issue is that this doesn't work for cross-compiling
because kbuild doesn't have cross-compile support for userspace code.
I submitted a patch to disable building Documentation when
cross-compiling, as the consensus in the thread that resulted in that
patch (https://lkml.org/lkml/2014/10/8/510) was that implementing
targetprogs in kbuild was not currently worth it.
I can try to take a crack at adding targetprogs support, but I'm
rather busy right now, so it may take a little while.
Thanks,
Peter
^ permalink raw reply
* Re: [PATCH 0/9] Marvell PXA168 libphy handling and Berlin Ethernet
From: Florian Fainelli @ 2014-10-21 22:03 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: David S. Miller, Antoine Ténart, Eric Miao, Haojian Zhuang,
linux-arm-kernel, netdev, devicetree, linux-kernel
In-Reply-To: <1413881627-21639-1-git-send-email-sebastian.hesselbarth@gmail.com>
Hi Sebastian,
On 10/21/2014 01:53 AM, Sebastian Hesselbarth wrote:
> This patch series deals with a removing a IP feature that can be found
> on all currently supported Marvell Ethernet IP (pxa168_eth, mv643xx_eth,
> mvneta). The MAC IP allows to automatically perform PHY auto-negotiation
> without software interaction.
>
> However, this feature (a) fundamentally clashes with the way libphy works
> and (b) is unable to deal with quirky PHYs that require special treatment.
> In this series, pxa168_eth driver is rewritten to completely disable that
> feature and properly deal with libphy provided PHYs.
>
> This is the real patch set after an RFT sent earlier. Unfortunately, there
> was no testing from MMP/gplug but there was for BG2Q. However, it still
> would be great to get a Tested-by on gplug. Also, this patch set is now
> rebased on v3.18-rc1. As usual, a branch on top of v3.18-rc1 can be found at
>
> git://git.infradead.org/users/hesselba/linux-berlin.git devel/bg2-bg2cd-eth-v1
>
> Patches 1-5 should go through David's net tree, I'll pick up the DT patches
> 6-9.
>
> Compared to the RFT, there have been some changes:
> - added phy-connection-type property to BG2Q PHY DT node
> - bail out from pxa168_eth_adjust_link when there is no change in
> PHY parameters. Also, add a call to phy_print_status.
>
> Patch 1 adds support for Marvell 88E3016 FastEthernet PHY that is also
> integrated in Marvell Berlin BG2/BG2CD SoCs.
>
> Patch 2 allows to pass phy_interface_t on pxa168_eth platform_data that
> is only used by mach-mmp/gplug. From the board setup, I guessed gplug's
> PHY is connected via RMII. The patch still isn't even compile tested.
>
> Patches 3-5 prepare proper libphy handling and finally remove all in-driver
> PHY mangling related to the feature explained above.
>
> Patches 6-9 add corresponding ethernet DT nodes to BG2, BG2CD, add a
> phy-connection-type property to BG2Q and enable ethernet on BG2-based Sony
> NSZ-GS7. I have tested all this on GS7 successfully with ip=dhcp on 100M FD.
Besides the misplacement of the 'phy-connection-type' as reported by
Sergei, this looks good to me:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks!
>
> Antoine Ténart (1):
> ARM: berlin: Add phy-connection-type to BG2Q PHY
>
> Sebastian Hesselbarth (8):
> phy: marvell: Add support for 88E3016 FastEthernet PHY
> net: pxa168_eth: Provide phy_interface mode on platform_data
> net: pxa168_eth: Prepare proper libphy handling
> net: pxa168_eth: Remove HW auto-negotiaion
> net: pxa168_eth: Remove in-driver PHY mangling
> ARM: berlin: Add BG2 ethernet DT nodes
> ARM: berlin: Add BG2CD ethernet DT nodes
> ARM: berlin: Enable ethernet on Sony NSZ-GS7
>
> arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts | 2 +
> arch/arm/boot/dts/berlin2.dtsi | 36 +++++
> arch/arm/boot/dts/berlin2cd.dtsi | 36 +++++
> arch/arm/boot/dts/berlin2q.dtsi | 1 +
> arch/arm/mach-mmp/gplugd.c | 2 +
> drivers/net/ethernet/marvell/pxa168_eth.c | 248 ++++++++++++-----------------
> drivers/net/phy/marvell.c | 46 ++++++
> include/linux/marvell_phy.h | 1 +
> include/linux/pxa168_eth.h | 1 +
> 9 files changed, 225 insertions(+), 148 deletions(-)
>
> ---
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: "Antoine Ténart" <antoine.tenart@free-electrons.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Eric Miao <eric.y.miao@gmail.com>
> Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: netdev@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
>
^ permalink raw reply
* Re: [PATCH] net: typhoon: Remove redundant casts
From: David Dillow @ 2014-10-21 21:29 UTC (permalink / raw)
To: Rasmus Villemoes; +Cc: netdev, linux-kernel
In-Reply-To: <1413903103-3047-1-git-send-email-linux@rasmusvillemoes.dk>
On Tue, 2014-10-21 at 16:51 +0200, Rasmus Villemoes wrote:
> Both image_data and typhoon_fw->data are const u8*, so the cast to u8*
> is unnecessary and confusing.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Acked-by: David Dillow <dave@thedillows.org>
^ permalink raw reply
* RE: [PATCH net 1/1] hyperv: Fix a bug in netvsc_send()
From: Haiyang Zhang @ 2014-10-21 21:25 UTC (permalink / raw)
To: Sitsofe Wheeler, Long Li
Cc: David Miller, olaf@aepfle.de, netdev@vger.kernel.org,
jasowang@redhat.com, linux-kernel@vger.kernel.org,
apw@canonical.com, devel@linuxdriverproject.org
In-Reply-To: <CALjAwxj1jHUugt+vtJL7duXfTpdoxmCrwTzRmNHGgOdj+Ju3Aw@mail.gmail.com>
> -----Original Message-----
> From: Sitsofe Wheeler [mailto:sitsofe@gmail.com]
> Sent: Tuesday, October 21, 2014 5:16 PM
> To: Long Li
> Cc: David Miller; olaf@aepfle.de; netdev@vger.kernel.org;
> jasowang@redhat.com; linux-kernel@vger.kernel.org; apw@canonical.com;
> devel@linuxdriverproject.org; Haiyang Zhang
> Subject: Re: [PATCH net 1/1] hyperv: Fix a bug in netvsc_send()
>
> On 21 October 2014 18:13, Long Li <longli@microsoft.com> wrote:
> > Thanks Sitsofe. This should have been fixed by this patch:
> > http://git.kernel.org/cgit/linux/kernel/git/next/linux-
> next.git/commit/?id=f88e67149f97d73c704d6fe6f492edde97463025
> >
> > Can you give it a try?
>
> Ah this one went mainline a few days ago so I've already been trying
> it. Yes it resolves my problem (that system is no longer oopsing on
> startup). I'd have added my Tested-by but it's already been committed
> :-)
Thank you for the test!
- Haiyang
^ permalink raw reply
* Re: [PATCH net 1/1] hyperv: Fix a bug in netvsc_send()
From: Sitsofe Wheeler @ 2014-10-21 21:16 UTC (permalink / raw)
To: Long Li
Cc: David Miller, olaf@aepfle.de, netdev@vger.kernel.org,
jasowang@redhat.com, linux-kernel@vger.kernel.org,
apw@canonical.com, devel@linuxdriverproject.org, Haiyang Zhang
In-Reply-To: <1413911624662.86334@microsoft.com>
On 21 October 2014 18:13, Long Li <longli@microsoft.com> wrote:
> Thanks Sitsofe. This should have been fixed by this patch:
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=f88e67149f97d73c704d6fe6f492edde97463025
>
> Can you give it a try?
Ah this one went mainline a few days ago so I've already been trying
it. Yes it resolves my problem (that system is no longer oopsing on
startup). I'd have added my Tested-by but it's already been committed
:-)
What helped you narrow it down?
--
Sitsofe | http://sucs.org/~sits/
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Kevin Fenzi @ 2014-10-21 21:12 UTC (permalink / raw)
To: netdev, linux-kernel
In-Reply-To: <20141020145359.565fe5e6@voldemort.scrye.com>
[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]
On Mon, 20 Oct 2014 14:53:59 -0600
Kevin Fenzi <kevin@scrye.com> wrote:
> On Mon, 20 Oct 2014 16:43:26 -0400
> Dave Jones <davej@redhat.com> wrote:
>
> > I've seen similar soft lockup traces from the sys_unshare path when
> > running my fuzz tester. It seems that if you create enough network
> > namespaces, it can take a huge amount of time for them to be
> > iterated. (Running trinity with '-c unshare' you can see the slow
> > down happen. In some cases, it takes so long that the watchdog
> > process kills it -- though the SIGKILL won't get delivered until
> > the unshare() completes)
> >
> > Any idea what this machine had been doing prior to this that may
> > have involved creating lots of namespaces ?
>
> That was right after boot. ;)
>
> This is my main rawhide running laptop.
>
> A 'ip netns list' shows nothing.
Some more information:
The problem started between:
v3.17-7872-g5ff0b9e1a1da and v3.17-8307-gf1d0d14120a8
(I can try and do a bisect, but have to head out on a trip tomorrow)
In all the kernels with the problem, there is a kworker process in D.
sysrq-t says:
Showing all locks held in the system:
Oct 21 15:06:31 voldemort.scrye.com kernel: 4 locks held by kworker/u16:0/6:
Oct 21 15:06:31 voldemort.scrye.com kernel: #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810ccbff>] process_one_work+0x17f/0x850
Oct 21 15:06:31 voldemort.scrye.com kernel: #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810ccbff>] process_one_work+0x17f/0x850
Oct 21 15:06:31 voldemort.scrye.com kernel: #2: (net_mutex){+.+.+.}, at: [<ffffffff817069fc>] cleanup_net+0x8c/0x1f0
Oct 21 15:06:31 voldemort.scrye.com kernel: #3:
(rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a395>]
_rcu_barrier+0x35/0x200
On first running any of the systemd units that use PrivateNetwork, then
run ok, but they are also set to timeout after a minute. On sucessive
runs they hang in D also.
kevin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/5] stmmac: pci: use managed resources
From: Sergei Shtylyov @ 2014-10-21 20:55 UTC (permalink / raw)
To: Andy Shevchenko, Giuseppe Cavallaro, netdev, Kweh Hock Leong,
David S. Miller, Vince Bridgers
In-Reply-To: <1413909333-16380-3-git-send-email-andriy.shevchenko@linux.intel.com>
Hello.
On 10/21/2014 08:35 PM, Andy Shevchenko wrote:
> Migrate pci driver to managed resources to reduce boilerplate error handling
> code.
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 46 +++++-------------------
> 1 file changed, 8 insertions(+), 38 deletions(-)
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> index 5459a4e..f8d4ce2 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> @@ -65,45 +65,29 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
> const struct pci_device_id *id)
> {
> int ret = 0;
> - void __iomem *addr = NULL;
> struct stmmac_priv *priv = NULL;
> - int i;
> + int pci_bar = 0;
I don't see this variable changing anywhere...
> /* Enable pci device */
> - ret = pci_enable_device(pdev);
> + ret = pcim_enable_device(pdev);
> if (ret) {
> pr_err("%s : ERROR: failed to enable %s device\n", __func__,
> pci_name(pdev));
> return ret;
> }
> - if (pci_request_regions(pdev, STMMAC_RESOURCE_NAME)) {
> - pr_err("%s: ERROR: failed to get PCI region\n", __func__);
> - ret = -ENODEV;
> - goto err_out_req_reg_failed;
> - }
> + ret = pcim_iomap_regions(pdev, BIT(pci_bar), pci_name(pdev));
> + if (ret)
> + return ret;
>
> - /* Get the base address of device */
> - for (i = 0; i <= 5; i++) {
> - if (pci_resource_len(pdev, i) == 0)
> - continue;
> - addr = pci_iomap(pdev, i, 0);
> - if (addr == NULL) {
> - pr_err("%s: ERROR: cannot map register memory aborting",
> - __func__);
> - ret = -EIO;
> - goto err_out_map_failed;
> - }
> - break;
> - }
It's not an equivalent change: the old code mapped a first existing BAR,
you always map BAR0. Are you sure that's what you meant? If so, wouldn't hurt
to describe this in the changelog...
WBR, Sergei
^ permalink raw reply
* [PATCH] netlink: don't copy over empty attribute data
From: Sasha Levin @ 2014-10-21 20:51 UTC (permalink / raw)
To: davem; +Cc: a.ryabinin, pablo, mschmidt, akpm, linux-kernel, netdev,
Sasha Levin
netlink uses empty data to seperate different levels. However, we still
try to copy that data from a NULL ptr using memcpy, which is an undefined
behaviour.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
---
lib/nlattr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/nlattr.c b/lib/nlattr.c
index 9c3e85f..6512b43 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -430,7 +430,8 @@ void __nla_put(struct sk_buff *skb, int attrtype, int attrlen,
struct nlattr *nla;
nla = __nla_reserve(skb, attrtype, attrlen);
- memcpy(nla_data(nla), data, attrlen);
+ if (data)
+ memcpy(nla_data(nla), data, attrlen);
}
EXPORT_SYMBOL(__nla_put);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/5] stmmac: pci: use managed resources
From: Andy Shevchenko @ 2014-10-21 16:35 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev, Kweh Hock Leong, David S. Miller,
Vince Bridgers
Cc: Andy Shevchenko
In-Reply-To: <1413909333-16380-1-git-send-email-andriy.shevchenko@linux.intel.com>
Migrate pci driver to managed resources to reduce boilerplate error handling
code.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 46 +++++-------------------
1 file changed, 8 insertions(+), 38 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 5459a4e..f8d4ce2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -65,45 +65,29 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
int ret = 0;
- void __iomem *addr = NULL;
struct stmmac_priv *priv = NULL;
- int i;
+ int pci_bar = 0;
/* Enable pci device */
- ret = pci_enable_device(pdev);
+ ret = pcim_enable_device(pdev);
if (ret) {
pr_err("%s : ERROR: failed to enable %s device\n", __func__,
pci_name(pdev));
return ret;
}
- if (pci_request_regions(pdev, STMMAC_RESOURCE_NAME)) {
- pr_err("%s: ERROR: failed to get PCI region\n", __func__);
- ret = -ENODEV;
- goto err_out_req_reg_failed;
- }
+ ret = pcim_iomap_regions(pdev, BIT(pci_bar), pci_name(pdev));
+ if (ret)
+ return ret;
- /* Get the base address of device */
- for (i = 0; i <= 5; i++) {
- if (pci_resource_len(pdev, i) == 0)
- continue;
- addr = pci_iomap(pdev, i, 0);
- if (addr == NULL) {
- pr_err("%s: ERROR: cannot map register memory aborting",
- __func__);
- ret = -EIO;
- goto err_out_map_failed;
- }
- break;
- }
pci_set_master(pdev);
stmmac_default_data();
- priv = stmmac_dvr_probe(&(pdev->dev), &plat_dat, addr);
+ priv = stmmac_dvr_probe(&pdev->dev, &plat_dat,
+ pcim_iomap_table(pdev)[pci_bar]);
if (IS_ERR(priv)) {
pr_err("%s: main driver probe failed", __func__);
- ret = PTR_ERR(priv);
- goto err_out;
+ return PTR_ERR(priv);
}
priv->dev->irq = pdev->irq;
priv->wol_irq = pdev->irq;
@@ -113,15 +97,6 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
pr_debug("STMMAC platform driver registration completed");
return 0;
-
-err_out:
- pci_clear_master(pdev);
-err_out_map_failed:
- pci_release_regions(pdev);
-err_out_req_reg_failed:
- pci_disable_device(pdev);
-
- return ret;
}
/**
@@ -134,13 +109,8 @@ err_out_req_reg_failed:
static void stmmac_pci_remove(struct pci_dev *pdev)
{
struct net_device *ndev = pci_get_drvdata(pdev);
- struct stmmac_priv *priv = netdev_priv(ndev);
stmmac_dvr_remove(ndev);
-
- pci_iounmap(pdev, priv->ioaddr);
- pci_release_regions(pdev);
- pci_disable_device(pdev);
}
#ifdef CONFIG_PM_SLEEP
--
2.1.1
^ permalink raw reply related
* [PATCH 5/5] stmmac: pci: remove FSF address
From: Andy Shevchenko @ 2014-10-21 16:35 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev, Kweh Hock Leong, David S. Miller,
Vince Bridgers
Cc: Andy Shevchenko
In-Reply-To: <1413909333-16380-1-git-send-email-andriy.shevchenko@linux.intel.com>
The FSF address is subject to change, thus remove it from the file.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 22cb5ff..95eb195 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -12,10 +12,6 @@
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
more details.
- You should have received a copy of the GNU General Public License along with
- this program; if not, write to the Free Software Foundation, Inc.,
- 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
-
The full GNU General Public License is included in this distribution in
the file called "COPYING".
--
2.1.1
^ permalink raw reply related
* Re: [PATCH 1/1 net-next] mac80211: remove unnecessary null test before debugfs_remove
From: Fabian Frederick @ 2014-10-21 20:05 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, netdev, linux-kernel, David S. Miller,
John W. Linville
In-Reply-To: <1413918366.1998.10.camel@jlt4.sipsolutions.net>
> On 21 October 2014 at 21:06 Johannes Berg <johannes@sipsolutions.net> wrote:
>
>
> On Tue, 2014-10-21 at 18:20 +0200, Fabian Frederick wrote:
> > Fix checkpatch warnings:
> >
> > WARNING: debugfs_remove(NULL) is safe this check is probably not
> >required
>
> I'll apply this; however, I think that checkpatch is a just tool, and
> the commit message should reflect why you're changing the code.
> Presumably you're not doing it to make the tool happy, but to address an
> issue that the tool pointed out, so I think in most cases the commit
> message should state the former, not the latter.
>
> Note that in this particular case the NULL check check could be there to
> avoid a memory write (which can be significant depending on the context)
> so blindly doing what the tool suggested wouldn't always be a good idea.
>
> johannes
>
Thanks Johannes,
Maybe you can replace commit message with:
"
This patch removes NULL check before debugfs_remove.
That function already does that check and is
only called during key management so we can add some memory writes.
"
I can also resubmit patch if necessary.
Regards,
Fabian
^ permalink raw reply
* [PATCH] netlink: Re-add locking to netlink_lookup() and seq walker
From: Thomas Graf @ 2014-10-21 20:05 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, David S. Miller, Eric Dumazet
The synchronize_rcu() in netlink_release() introduces unacceptable
latency. Reintroduce minimal lookup so we can drop the
synchronize_rcu() until socket destruction has been RCUfied.
Cc: David S. Miller <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Reported-by: Steinar H. Gunderson <sgunderson@bigfoot.com>
Reported-and-tested-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
net/netlink/af_netlink.c | 37 +++++++++++++++++++++++++------------
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 7a186e7..f1de72d 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -96,6 +96,14 @@ static DECLARE_WAIT_QUEUE_HEAD(nl_table_wait);
static int netlink_dump(struct sock *sk);
static void netlink_skb_destructor(struct sk_buff *skb);
+/* nl_table locking explained:
+ * Lookup and traversal are protected with nl_sk_hash_lock or nl_table_lock
+ * combined with an RCU read-side lock. Insertion and removal are protected
+ * with nl_sk_hash_lock while using RCU list modification primitives and may
+ * run in parallel to nl_table_lock protected lookups. Destruction of the
+ * Netlink socket may only occur *after* nl_table_lock has been acquired
+ * either during or after the socket has been removed from the list.
+ */
DEFINE_RWLOCK(nl_table_lock);
EXPORT_SYMBOL_GPL(nl_table_lock);
static atomic_t nl_table_users = ATOMIC_INIT(0);
@@ -109,10 +117,10 @@ EXPORT_SYMBOL_GPL(nl_sk_hash_lock);
static int lockdep_nl_sk_hash_is_held(void)
{
#ifdef CONFIG_LOCKDEP
- return (debug_locks) ? lockdep_is_held(&nl_sk_hash_lock) : 1;
-#else
- return 1;
+ if (debug_locks)
+ return lockdep_is_held(&nl_sk_hash_lock) || lockdep_is_held(&nl_table_lock);
#endif
+ return 1;
}
static ATOMIC_NOTIFIER_HEAD(netlink_chain);
@@ -1028,11 +1036,13 @@ static struct sock *netlink_lookup(struct net *net, int protocol, u32 portid)
struct netlink_table *table = &nl_table[protocol];
struct sock *sk;
+ read_lock(&nl_table_lock);
rcu_read_lock();
sk = __netlink_lookup(table, portid, net);
if (sk)
sock_hold(sk);
rcu_read_unlock();
+ read_unlock(&nl_table_lock);
return sk;
}
@@ -1257,9 +1267,6 @@ static int netlink_release(struct socket *sock)
}
netlink_table_ungrab();
- /* Wait for readers to complete */
- synchronize_net();
-
kfree(nlk->groups);
nlk->groups = NULL;
@@ -1281,6 +1288,7 @@ static int netlink_autobind(struct socket *sock)
retry:
cond_resched();
+ netlink_table_grab();
rcu_read_lock();
if (__netlink_lookup(table, portid, net)) {
/* Bind collision, search negative portid values. */
@@ -1288,9 +1296,11 @@ retry:
if (rover > -4097)
rover = -4097;
rcu_read_unlock();
+ netlink_table_ungrab();
goto retry;
}
rcu_read_unlock();
+ netlink_table_ungrab();
err = netlink_insert(sk, net, portid);
if (err == -EADDRINUSE)
@@ -2921,14 +2931,16 @@ static struct sock *netlink_seq_socket_idx(struct seq_file *seq, loff_t pos)
}
static void *netlink_seq_start(struct seq_file *seq, loff_t *pos)
- __acquires(RCU)
+ __acquires(nl_table_lock) __acquires(RCU)
{
+ read_lock(&nl_table_lock);
rcu_read_lock();
return *pos ? netlink_seq_socket_idx(seq, *pos - 1) : SEQ_START_TOKEN;
}
static void *netlink_seq_next(struct seq_file *seq, void *v, loff_t *pos)
{
+ struct rhashtable *ht;
struct netlink_sock *nlk;
struct nl_seq_iter *iter;
struct net *net;
@@ -2943,19 +2955,19 @@ static void *netlink_seq_next(struct seq_file *seq, void *v, loff_t *pos)
iter = seq->private;
nlk = v;
- rht_for_each_entry_rcu(nlk, nlk->node.next, node)
+ i = iter->link;
+ ht = &nl_table[i].hash;
+ rht_for_each_entry(nlk, nlk->node.next, ht, node)
if (net_eq(sock_net((struct sock *)nlk), net))
return nlk;
- i = iter->link;
j = iter->hash_idx + 1;
do {
- struct rhashtable *ht = &nl_table[i].hash;
const struct bucket_table *tbl = rht_dereference_rcu(ht->tbl, ht);
for (; j < tbl->size; j++) {
- rht_for_each_entry_rcu(nlk, tbl->buckets[j], node) {
+ rht_for_each_entry(nlk, tbl->buckets[j], ht, node) {
if (net_eq(sock_net((struct sock *)nlk), net)) {
iter->link = i;
iter->hash_idx = j;
@@ -2971,9 +2983,10 @@ static void *netlink_seq_next(struct seq_file *seq, void *v, loff_t *pos)
}
static void netlink_seq_stop(struct seq_file *seq, void *v)
- __releases(RCU)
+ __releases(RCU) __releases(nl_table_lock)
{
rcu_read_unlock();
+ read_unlock(&nl_table_lock);
}
--
1.9.3
^ permalink raw reply related
* You are receiving this donation newsletter from the PR officer to Margaret Loughrey.
From: Loughrey, Empowerment, Project @ 2014-10-21 19:54 UTC (permalink / raw)
She is a renowned winner of the 27million pound jackpot.You are been informed that three(3) e-mail addresses including yours was recently selected by Google at the request of Margaret Loughrey to receive a $450,000.00USD donation each in the ongoing 2014 Email Donation Project.. Send Name, Country, Age, and Occupation and phone number for details. See my interview
http://www.bbc.com/news/uk-northern-ireland-25178018
http://www.belfasttelegraph.co.uk/news/local-national/northern-ireland/strabanes-27m-euromillions-winner-margaret-loughrey-giving-away-millions-to-help-needy-and-town-30481234.html
Regards,
Mark Worton,
Margaret Loughrey Foudation.
^ permalink raw reply
* Re: [PATCH stable v3.2 v3.4] ipv4: disable bh while doing route gc
From: Marcelo Ricardo Leitner @ 2014-10-21 19:51 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, stable, netdev, hannes
In-Reply-To: <1413919971.31953.39.camel@decadent.org.uk>
On 21-10-2014 17:32, Ben Hutchings wrote:
> On Tue, 2014-10-21 at 17:08 -0200, Marcelo Ricardo Leitner wrote:
>> On 20-10-2014 01:09, Ben Hutchings wrote:
>>> On Mon, 2014-10-13 at 13:51 -0400, David Miller wrote:
>>>> From: Marcelo Ricardo Leitner <mleitner@redhat.com>
>>>> Date: Mon, 13 Oct 2014 14:03:30 -0300
>>>>
>>>>> Further tests revealed that after moving the garbage collector to a work
>>>>> queue and protecting it with a spinlock may leave the system prone to
>>>>> soft lockups if bottom half gets very busy.
>>>>>
>>>>> It was reproced with a set of firewall rules that REJECTed packets. If
>>>>> the NIC bottom half handler ends up running on the same CPU that is
>>>>> running the garbage collector on a very large cache, the garbage
>>>>> collector will not be able to do its job due to the amount of work
>>>>> needed for handling the REJECTs and also won't reschedule.
>>>>>
>>>>> The fix is to disable bottom half during the garbage collecting, as it
>>>>> already was in the first place (most calls to it came from softirqs).
>>>>>
>>>>> Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
>>>>> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>>>>> Acked-by: David S. Miller <davem@davemloft.net>
>>>>> Cc: stable@vger.kernel.org
>>>>
>>>> -stable folks, please integrate this directly, thanks!
>>>
>>> I've appplied this and the previous two patches mentioned ('ipv4: move
>>> route garbage collector to work queue' and 'ipv4: avoid parallel route
>>> cache gc executions'). But I didn't get the other two from you. The
>>> last batch of networking fixes I received and applied was dated
>>> 2014-08-07, and the next one I've seen is dated 2014-10-11 and has
>>> nothing for 3.2 or 3.4. Did I miss one between these?
>>
>> Sorry to ask Ben but, where did you apply them? I'm not seeing the commits on
>> linux-stable.git and couldn't find their summaries anywhere else.
>
> They're in a patch queue that I've just pushed to:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-3.2.y-queue.git
Cool, thanks!
Marcelo
^ permalink raw reply
* Re: [RFC PATCH v2 net-next] net: ipv6: Add a sysctl to make optimistic addresses useful candidates
From: Hannes Frederic Sowa @ 2014-10-21 19:45 UTC (permalink / raw)
To: Erik Kline; +Cc: netdev, ben, lorenzo
In-Reply-To: <1413864306-20055-1-git-send-email-ek@google.com>
Hi,
On Di, 2014-10-21 at 13:05 +0900, Erik Kline wrote:
> Add a sysctl that causes an interface's optimistic addresses
> to be considered equivalent to other non-deprecated addresses
> for source address selection purposes. Preferred addresses
> will still take precedence over optimistic addresses, subject
> to other ranking in the source address selection algorithm.
>
> This is useful where different interfaces are connected to
> different networks from different ISPs (e.g., a cell network
> and a home wifi network).
>
> The current behaviour complies with RFC 3484/6724, and it
> makes sense if the host has only one interface, or has
> multiple interfaces on the same network (same or cooperating
> administrative domain(s), but not in the multiple distinct
> networks case.
>
> For example, if a mobile device has an IPv6 address on an LTE
> network and then connects to IPv6-enabled wifi, while the wifi
> IPv6 address is undergoing DAD, IPv6 connections will try use
> the wifi default route with the LTE IPv6 address, and will get
> stuck until they time out.
>
> Also, because optimistic addresses can actually be used, issue
> an RTM_NEWADDR as soon as DAD starts. If DAD fails an separate
> RTM_DELADDR will be sent.
>
> Also: add an entry in ip-sysctl.txt for optimistic_dad.
>
> Signed-off-by: Erik Kline <ek@google.com>
> ---
> Documentation/networking/ip-sysctl.txt | 13 ++++++++++++
> include/linux/ipv6.h | 1 +
> include/uapi/linux/ipv6.h | 1 +
> net/ipv6/addrconf.c | 36 ++++++++++++++++++++++++++++++++--
> 4 files changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
> index 0307e28..e03cf49 100644
> --- a/Documentation/networking/ip-sysctl.txt
> +++ b/Documentation/networking/ip-sysctl.txt
> @@ -1452,6 +1452,19 @@ suppress_frag_ndisc - INTEGER
> 1 - (default) discard fragmented neighbor discovery packets
> 0 - allow fragmented neighbor discovery packets
>
> +optimistic_dad - BOOLEAN
> + Whether to perform Optimistic Duplicate Address Detection (RFC 4429).
> + 0: disabled (default)
> + 1: enabled
> +
> +use_optimistic - BOOLEAN
> + If enabled, do not classify optimistic addresses as deprecated during
> + source address selection. Preferred addresses will still be chosen
> + before optimistic addresses, subject to other ranking in the source
> + address selection algorithm.
> + 0: disabled (default)
> + 1: enabled
> +
> icmp/*:
> ratelimit - INTEGER
> Limit the maximal rates for sending ICMPv6 packets.
> diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
> index ff56053..7121a2e 100644
> --- a/include/linux/ipv6.h
> +++ b/include/linux/ipv6.h
> @@ -42,6 +42,7 @@ struct ipv6_devconf {
> __s32 accept_ra_from_local;
> #ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> __s32 optimistic_dad;
> + __s32 use_optimistic;
> #endif
> #ifdef CONFIG_IPV6_MROUTE
> __s32 mc_forwarding;
> diff --git a/include/uapi/linux/ipv6.h b/include/uapi/linux/ipv6.h
> index efa2666..e863d08 100644
> --- a/include/uapi/linux/ipv6.h
> +++ b/include/uapi/linux/ipv6.h
> @@ -164,6 +164,7 @@ enum {
> DEVCONF_MLDV2_UNSOLICITED_REPORT_INTERVAL,
> DEVCONF_SUPPRESS_FRAG_NDISC,
> DEVCONF_ACCEPT_RA_FROM_LOCAL,
> + DEVCONF_USE_OPTIMISTIC,
> DEVCONF_MAX
> };
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 725c763..c2fddb7 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -1169,6 +1169,9 @@ enum {
> IPV6_SADDR_RULE_LABEL,
> IPV6_SADDR_RULE_PRIVACY,
> IPV6_SADDR_RULE_ORCHID,
> +#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> + IPV6_SADDR_RULE_NOT_OPTIMISTIC,
> +#endif
> IPV6_SADDR_RULE_PREFIX,
> IPV6_SADDR_RULE_MAX
> };
> @@ -1257,10 +1260,17 @@ static int ipv6_get_saddr_eval(struct net *net,
> score->scopedist = ret;
> break;
> case IPV6_SADDR_RULE_PREFERRED:
> + {
> /* Rule 3: Avoid deprecated and optimistic addresses */
> + u8 avoid = IFA_F_DEPRECATED;
> +#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> + if (!score->ifa->idev->cnf.use_optimistic)
> + avoid |= IFA_F_OPTIMISTIC;
> +#endif
> ret = ipv6_saddr_preferred(score->addr_type) ||
> - !(score->ifa->flags & (IFA_F_DEPRECATED|IFA_F_OPTIMISTIC));
> + !(score->ifa->flags & avoid);
> break;
> + }
> #ifdef CONFIG_IPV6_MIP6
> case IPV6_SADDR_RULE_HOA:
> {
> @@ -1299,6 +1309,14 @@ static int ipv6_get_saddr_eval(struct net *net,
> ret = !(ipv6_addr_orchid(&score->ifa->addr) ^
> ipv6_addr_orchid(dst->addr));
> break;
> +#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> + case IPV6_SADDR_RULE_NOT_OPTIMISTIC:
> + /* Optimistic addresses still have lower precedence than other
> + * preferred addresses.
> + */
> + ret = !(score->ifa->flags & IFA_F_OPTIMISTIC);
> + break;
> +#endif
I wonder a bit why this rule is not directly ordered after
IPV6_SADDR_RULE_PREFERRED? This would e.g. matter for privacy addresses.
> case IPV6_SADDR_RULE_PREFIX:
> /* Rule 8: Use longest matching prefix */
> ret = ipv6_addr_diff(&score->ifa->addr, dst->addr);
> @@ -3222,8 +3240,13 @@ static void addrconf_dad_begin(struct inet6_ifaddr *ifp)
> * Optimistic nodes can start receiving
> * Frames right away
> */
> - if (ifp->flags & IFA_F_OPTIMISTIC)
> + if (ifp->flags & IFA_F_OPTIMISTIC) {
> ip6_ins_rt(ifp->rt);
> + /* Because optimistic nodes can receive frames, notify
> + * listeners. If DAD fails, RTM_DELADDR is sent.
> + */
> + ipv6_ifa_notify(RTM_NEWADDR, ifp);
> + }
I wonder if we can now delete the ipv6_ifa_notify(RTM_NEWADDR, ifp) in
addrconf_dad_completed.
> addrconf_dad_kick(ifp);
> out:
> @@ -4330,6 +4353,7 @@ static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
> array[DEVCONF_ACCEPT_SOURCE_ROUTE] = cnf->accept_source_route;
> #ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> array[DEVCONF_OPTIMISTIC_DAD] = cnf->optimistic_dad;
> + array[DEVCONF_USE_OPTIMISTIC] = cnf->use_optimistic;
> #endif
> #ifdef CONFIG_IPV6_MROUTE
> array[DEVCONF_MC_FORWARDING] = cnf->mc_forwarding;
> @@ -5155,6 +5179,14 @@ static struct addrconf_sysctl_table
> .proc_handler = proc_dointvec,
>
> },
> + {
> + .procname = "use_optimistic",
> + .data = &ipv6_devconf.use_optimistic,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec,
> +
> + },
> #endif
> #ifdef CONFIG_IPV6_MROUTE
> {
Otherwise looks good.
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH stable v3.2 v3.4] ipv4: disable bh while doing route gc
From: Ben Hutchings @ 2014-10-21 19:32 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: David Miller, stable, netdev, hannes
In-Reply-To: <5446AF2A.1030508@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]
On Tue, 2014-10-21 at 17:08 -0200, Marcelo Ricardo Leitner wrote:
> On 20-10-2014 01:09, Ben Hutchings wrote:
> > On Mon, 2014-10-13 at 13:51 -0400, David Miller wrote:
> >> From: Marcelo Ricardo Leitner <mleitner@redhat.com>
> >> Date: Mon, 13 Oct 2014 14:03:30 -0300
> >>
> >>> Further tests revealed that after moving the garbage collector to a work
> >>> queue and protecting it with a spinlock may leave the system prone to
> >>> soft lockups if bottom half gets very busy.
> >>>
> >>> It was reproced with a set of firewall rules that REJECTed packets. If
> >>> the NIC bottom half handler ends up running on the same CPU that is
> >>> running the garbage collector on a very large cache, the garbage
> >>> collector will not be able to do its job due to the amount of work
> >>> needed for handling the REJECTs and also won't reschedule.
> >>>
> >>> The fix is to disable bottom half during the garbage collecting, as it
> >>> already was in the first place (most calls to it came from softirqs).
> >>>
> >>> Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
> >>> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> >>> Acked-by: David S. Miller <davem@davemloft.net>
> >>> Cc: stable@vger.kernel.org
> >>
> >> -stable folks, please integrate this directly, thanks!
> >
> > I've appplied this and the previous two patches mentioned ('ipv4: move
> > route garbage collector to work queue' and 'ipv4: avoid parallel route
> > cache gc executions'). But I didn't get the other two from you. The
> > last batch of networking fixes I received and applied was dated
> > 2014-08-07, and the next one I've seen is dated 2014-10-11 and has
> > nothing for 3.2 or 3.4. Did I miss one between these?
>
> Sorry to ask Ben but, where did you apply them? I'm not seeing the commits on
> linux-stable.git and couldn't find their summaries anywhere else.
They're in a patch queue that I've just pushed to:
git://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-3.2.y-queue.git
Ben.
--
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH net] tipc: fix lockdep warning when intra-node messages are delivered
From: David Miller @ 2014-10-21 19:30 UTC (permalink / raw)
To: ying.xue; +Cc: jon.maloy, erik.hugne, netdev, tipc-discussion
In-Reply-To: <1413787595-14700-1-git-send-email-ying.xue@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Mon, 20 Oct 2014 14:46:35 +0800
> When running tipcTC&tipcTS test suite, below lockdep unsafe locking
> scenario is reported:
...
> When intra-node messages are delivered from one process to another
> process, tipc_link_xmit() doesn't disable BH before it directly calls
> tipc_sk_rcv() on process context to forward messages to destination
> socket. Meanwhile, if messages delivered by remote node arrive at the
> node and their destinations are also the same socket, tipc_sk_rcv()
> running on process context might be preempted by tipc_sk_rcv() running
> BH context. As a result, the latter cannot obtain the socket lock as
> the lock was obtained by the former, however, the former has no chance
> to be run as the latter is owning the CPU now, so headlock happens. To
> avoid it, BH should be always disabled in tipc_sk_rcv().
>
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] tipc: fix a potential deadlock
From: David Miller @ 2014-10-21 19:30 UTC (permalink / raw)
To: ying.xue; +Cc: jon.maloy, erik.hugne, netdev, tipc-discussion
In-Reply-To: <1413787465-14600-1-git-send-email-ying.xue@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Mon, 20 Oct 2014 14:44:25 +0800
> Locking dependency detected below possible unsafe locking scenario:
>
> CPU0 CPU1
> T0: tipc_named_rcv() tipc_rcv()
> T1: [grab nametble write lock]* [grab node lock]*
> T2: tipc_update_nametbl() tipc_node_link_up()
> T3: tipc_nodesub_subscribe() tipc_nametbl_publish()
> T4: [grab node lock]* [grab nametble write lock]*
>
> The opposite order of holding nametbl write lock and node lock on
> above two different paths may result in a deadlock. If we move the
> the updating of the name table after link state named out of node
> lock, the reverse order of holding locks will be eliminated, and
> as a result, the deadlock risk.
>
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 0/2] enic: Bug fixes
From: David Miller @ 2014-10-21 19:25 UTC (permalink / raw)
To: _govind; +Cc: netdev, ssujith, benve
In-Reply-To: <1413708628-25690-1-git-send-email-_govind@gmx.com>
From: Govindarajulu Varadarajan <_govind@gmx.com>
Date: Sun, 19 Oct 2014 14:20:26 +0530
> This series fixes the following problem.
??? This is a rather content free patch series header description
if you ask me.
> Please apply this to net.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH stable v3.2 v3.4] ipv4: disable bh while doing route gc
From: Marcelo Ricardo Leitner @ 2014-10-21 19:08 UTC (permalink / raw)
To: Ben Hutchings, David Miller; +Cc: stable, netdev, hannes
In-Reply-To: <1413774581.31953.12.camel@decadent.org.uk>
On 20-10-2014 01:09, Ben Hutchings wrote:
> On Mon, 2014-10-13 at 13:51 -0400, David Miller wrote:
>> From: Marcelo Ricardo Leitner <mleitner@redhat.com>
>> Date: Mon, 13 Oct 2014 14:03:30 -0300
>>
>>> Further tests revealed that after moving the garbage collector to a work
>>> queue and protecting it with a spinlock may leave the system prone to
>>> soft lockups if bottom half gets very busy.
>>>
>>> It was reproced with a set of firewall rules that REJECTed packets. If
>>> the NIC bottom half handler ends up running on the same CPU that is
>>> running the garbage collector on a very large cache, the garbage
>>> collector will not be able to do its job due to the amount of work
>>> needed for handling the REJECTs and also won't reschedule.
>>>
>>> The fix is to disable bottom half during the garbage collecting, as it
>>> already was in the first place (most calls to it came from softirqs).
>>>
>>> Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
>>> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>>> Acked-by: David S. Miller <davem@davemloft.net>
>>> Cc: stable@vger.kernel.org
>>
>> -stable folks, please integrate this directly, thanks!
>
> I've appplied this and the previous two patches mentioned ('ipv4: move
> route garbage collector to work queue' and 'ipv4: avoid parallel route
> cache gc executions'). But I didn't get the other two from you. The
> last batch of networking fixes I received and applied was dated
> 2014-08-07, and the next one I've seen is dated 2014-10-11 and has
> nothing for 3.2 or 3.4. Did I miss one between these?
Sorry to ask Ben but, where did you apply them? I'm not seeing the commits on
linux-stable.git and couldn't find their summaries anywhere else.
Thanks,
Marcelo
^ permalink raw reply
* Re: [PATCH 1/1 net-next] mac80211: remove unnecessary null test before debugfs_remove
From: Johannes Berg @ 2014-10-21 19:06 UTC (permalink / raw)
To: Fabian Frederick
Cc: linux-kernel, John W. Linville, David S. Miller, linux-wireless,
netdev
In-Reply-To: <1413908412-5177-1-git-send-email-fabf@skynet.be>
On Tue, 2014-10-21 at 18:20 +0200, Fabian Frederick wrote:
> Fix checkpatch warnings:
>
> WARNING: debugfs_remove(NULL) is safe this check is probably not required
I'll apply this; however, I think that checkpatch is a just tool, and
the commit message should reflect why you're changing the code.
Presumably you're not doing it to make the tool happy, but to address an
issue that the tool pointed out, so I think in most cases the commit
message should state the former, not the latter.
Note that in this particular case the NULL check check could be there to
avoid a memory write (which can be significant depending on the context)
so blindly doing what the tool suggested wouldn't always be a good idea.
johannes
^ permalink raw reply
* [PATCH 3/5] stmmac: pci: convert to use dev_* macros
From: Andy Shevchenko @ 2014-10-21 16:35 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev, Kweh Hock Leong, David S. Miller,
Vince Bridgers
Cc: Andy Shevchenko
In-Reply-To: <1413909333-16380-1-git-send-email-andriy.shevchenko@linux.intel.com>
Instead of pr_* macros let's use dev_* macros which provide device name.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index f8d4ce2..c16f74b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -71,8 +71,8 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
/* Enable pci device */
ret = pcim_enable_device(pdev);
if (ret) {
- pr_err("%s : ERROR: failed to enable %s device\n", __func__,
- pci_name(pdev));
+ dev_err(&pdev->dev, "%s: ERROR: failed to enable device\n",
+ __func__);
return ret;
}
ret = pcim_iomap_regions(pdev, BIT(pci_bar), pci_name(pdev));
@@ -86,7 +86,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
priv = stmmac_dvr_probe(&pdev->dev, &plat_dat,
pcim_iomap_table(pdev)[pci_bar]);
if (IS_ERR(priv)) {
- pr_err("%s: main driver probe failed", __func__);
+ dev_err(&pdev->dev, "%s: main driver probe failed\n", __func__);
return PTR_ERR(priv);
}
priv->dev->irq = pdev->irq;
@@ -94,7 +94,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
pci_set_drvdata(pdev, priv->dev);
- pr_debug("STMMAC platform driver registration completed");
+ dev_dbg(&pdev->dev, "STMMAC PCI driver registration completed\n");
return 0;
}
--
2.1.1
^ permalink raw reply related
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