* Re: [PATCH] af_unix: fix garbage collect vs. MSG_PEEK
From: Miklos Szeredi @ 2016-12-19 11:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, lkml, Hannes Frederic Sowa, Nikolay Borisov
In-Reply-To: <20161003.215103.2267442887041931968.davem@davemloft.net>
On Tue, Oct 4, 2016 at 3:51 AM, David Miller <davem@davemloft.net> wrote:
> From: Miklos Szeredi <mszeredi@redhat.com>
> Date: Thu, 29 Sep 2016 14:09:14 +0200
>
>> @@ -1550,6 +1550,17 @@ static int unix_attach_fds(struct scm_cookie *scm, struct sk_buff *skb)
>> return max_level;
>> }
>>
>> +static void unix_peek_fds(struct scm_cookie *scm, struct sk_buff *skb)
>> +{
>> + scm->fp = scm_fp_dup(UNIXCB(skb).fp);
>> + /*
>> + * During garbage collection it is assumed that in-flight sockets don't
>> + * get a new external reference. So we need to wait until current run
>> + * finishes.
>> + */
>> + unix_gc_barrier();
>> +}
> ...
>> @@ -266,6 +266,11 @@ void wait_for_unix_gc(void)
>> wait_event(unix_gc_wait, gc_in_progress == false);
>> }
>>
>> +void unix_gc_barrier(void)
>> +{
>> + spin_unlock_wait(&unix_gc_lock);
>> +}
>
> Can you explain why wait_for_unix_gc() isn't appropriate? I'm a little
> bit uncomfortable with a spinlock wait like this, and would rather see
> something like the existing helper used.
Missed this mail, sorry for the late reply...
AFAICS wait_for_unix_gc() lacks a barrier that the spin lock provides.
The ordering needs to be strictly:
A: duplicate file pointers
B: garbage collect
Also wait_for_unix_gc() is an overkill since the complete garbage
collect (including purging the trash) will take longer than the
collection stage, which we need to have ordering with. This probably
doesn't matter much in practice.
Thanks,
Miklos
^ permalink raw reply
* Re: Synopsys Ethernet QoS
From: Joao Pinto @ 2016-12-19 11:01 UTC (permalink / raw)
To: Pavel Machek, Joao Pinto
Cc: Niklas Cassel, Giuseppe CAVALLARO, Florian Fainelli,
Andy Shevchenko, David Miller, larper, rabinv, netdev,
CARLOS.PALMINHA, Jie.Deng1, Stephen Warren
In-Reply-To: <3c70d3c0-d312-054f-6e8c-54035c63573e@synopsys.com>
Às 10:55 AM de 12/19/2016, Joao Pinto escreveu:
>
> Hi Pavel,
>
> Às 5:38 PM de 12/17/2016, Pavel Machek escreveu:
>> Hi!
>>
>>>>> So if there is a long time before handling interrupts,
>>>>> I guess that it makes sense that one stream could
>>>>> get an advantage in the net scheduler.
>>>>>
>>>>> If I find the time, and if no one beats me to it, I will try to replace
>>>>> the normal timers with HR timers + a smaller default timeout.
>>>>>
>>>>
>>>> Can you try something like this? Highres timers will be needed, too,
>>>> but this fixes the logic problem.
>>>>
>>>> You'll need to apply it twice as code is copy&pasted.
>>>>
>>>> Best regards,
>>>> Pavel
>>>>
>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>>
>>>> */
>>>> priv->tx_count_frames += nfrags + 1;
>>>> if (likely(priv->tx_coal_frames > priv->tx_count_frames)) {
>>>> - mod_timer(&priv->txtimer,
>>>> - STMMAC_COAL_TIMER(priv->tx_coal_timer));
>>>> + if (priv->tx_count_frames == nfrags + 1)
>>>> + mod_timer(&priv->txtimer,
>>>> + STMMAC_COAL_TIMER(priv->tx_coal_timer));
>>>> } else {
>>>> priv->tx_count_frames = 0;
>>>> priv->hw->desc->set_tx_ic(desc);
>>>>
>>>>
>>>
>>> I know that this is completely of topic, but I am facing a dificulty with
>>> stmmac. I have interrupts, mac well configured rx packets being received
>>> successfully, but TX is not working, resulting in Tx errors = Total TX packets.
>>> I have made a lot of debug and my conclusions is that by some reason when using
>>> stmmac after starting tx dma, the hw state machine enters a deadend state
>>> resulting in those errors. Anyone faced this trouble?
>>
>> SMP or UP system? AFAICT the driver gets the memory barriers wrong. It
>> does not fail completely for me, but still fails rather quickly.
>
> I was able to put my setup receiving and transmiting packets. The problem is
> that because my hw controller supports multi-queues, I had to enable the TX
> queue 0 in order for it to work.
>
> Now I am facing a new problem. My DUT with stmmac does not answer to ARP
> messages. When I execute a "ping" the other machine in the nework executes a ARP
> message asking "who is the owner of IP XXXX" which my DUT does not reply. I used
> wireshark and the ARP messages are reaching the DUT machine, but for some reason
> it does not reply. Did you ever face this problem when using stmmac?
>
> When using my internal driver, it works perfectly, so some detail in the stmmac
> I suppose.
>
> Tahnks.
Forgot to say that I am using a PC with SMP and a PCI link to the controller.
Thanks.
>
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index 3e40578..641b03d 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -2121,11 +2205,11 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
>> if (mss_desc)
>> priv->hw->desc->set_tx_owner(mss_desc);
>>
>> - /* The own bit must be the latest setting done when prepare the
>> + /* The own bit must be the latest setting done when preparing the
>> * descriptor and then barrier is needed to make sure that
>> * all is coherent before granting the DMA engine.
>> */
>> - smp_wmb();
>> + wmb();
>>
>> if (netif_msg_pktdata(priv)) {
>> pr_info("%s: curr=%d dirty=%d f=%d, e=%d, f_p=%p, nfrags %d\n",
>> @@ -2336,9 +2401,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
>>
>> /* The own bit must be the latest setting done when prepare the
>> * descriptor and then barrier is needed to make sure that
>> - * all is coherent before granting the DMA engine.
>> + * all is coherent before granting access to the DMA engine.
>> */
>> - smp_wmb();
>> + wmb();
>> }
>>
>> netdev_sent_queue(dev, skb->len);
>>
>> Plus I'd suggest... at least (hand-edited). Driver should really be
>> modified to use readl() when accessing memory that changes.
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index 3e40578..641b03d 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -1309,6 +1323,8 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
>> status = priv->hw->desc->tx_status(&priv->dev->stats,
>> &priv->xstats, p,
>> priv->ioaddr);
>> + rmb();
>> +
>> /* Check if the descriptor is owned by the DMA */
>> if (unlikely(status & tx_dma_own))
>> break;
>>
>> Pavel
>>
>
^ permalink raw reply
* Re: Synopsys Ethernet QoS
From: Joao Pinto @ 2016-12-19 10:55 UTC (permalink / raw)
To: Pavel Machek, Joao Pinto
Cc: Niklas Cassel, Giuseppe CAVALLARO, Florian Fainelli,
Andy Shevchenko, David Miller, larper, rabinv, netdev,
CARLOS.PALMINHA, Jie.Deng1, Stephen Warren
In-Reply-To: <20161217173824.GB20231@amd>
Hi Pavel,
Às 5:38 PM de 12/17/2016, Pavel Machek escreveu:
> Hi!
>
>>>> So if there is a long time before handling interrupts,
>>>> I guess that it makes sense that one stream could
>>>> get an advantage in the net scheduler.
>>>>
>>>> If I find the time, and if no one beats me to it, I will try to replace
>>>> the normal timers with HR timers + a smaller default timeout.
>>>>
>>>
>>> Can you try something like this? Highres timers will be needed, too,
>>> but this fixes the logic problem.
>>>
>>> You'll need to apply it twice as code is copy&pasted.
>>>
>>> Best regards,
>>> Pavel
>>>
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>
>>> */
>>> priv->tx_count_frames += nfrags + 1;
>>> if (likely(priv->tx_coal_frames > priv->tx_count_frames)) {
>>> - mod_timer(&priv->txtimer,
>>> - STMMAC_COAL_TIMER(priv->tx_coal_timer));
>>> + if (priv->tx_count_frames == nfrags + 1)
>>> + mod_timer(&priv->txtimer,
>>> + STMMAC_COAL_TIMER(priv->tx_coal_timer));
>>> } else {
>>> priv->tx_count_frames = 0;
>>> priv->hw->desc->set_tx_ic(desc);
>>>
>>>
>>
>> I know that this is completely of topic, but I am facing a dificulty with
>> stmmac. I have interrupts, mac well configured rx packets being received
>> successfully, but TX is not working, resulting in Tx errors = Total TX packets.
>> I have made a lot of debug and my conclusions is that by some reason when using
>> stmmac after starting tx dma, the hw state machine enters a deadend state
>> resulting in those errors. Anyone faced this trouble?
>
> SMP or UP system? AFAICT the driver gets the memory barriers wrong. It
> does not fail completely for me, but still fails rather quickly.
I was able to put my setup receiving and transmiting packets. The problem is
that because my hw controller supports multi-queues, I had to enable the TX
queue 0 in order for it to work.
Now I am facing a new problem. My DUT with stmmac does not answer to ARP
messages. When I execute a "ping" the other machine in the nework executes a ARP
message asking "who is the owner of IP XXXX" which my DUT does not reply. I used
wireshark and the ARP messages are reaching the DUT machine, but for some reason
it does not reply. Did you ever face this problem when using stmmac?
When using my internal driver, it works perfectly, so some detail in the stmmac
I suppose.
Tahnks.
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 3e40578..641b03d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2121,11 +2205,11 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
> if (mss_desc)
> priv->hw->desc->set_tx_owner(mss_desc);
>
> - /* The own bit must be the latest setting done when prepare the
> + /* The own bit must be the latest setting done when preparing the
> * descriptor and then barrier is needed to make sure that
> * all is coherent before granting the DMA engine.
> */
> - smp_wmb();
> + wmb();
>
> if (netif_msg_pktdata(priv)) {
> pr_info("%s: curr=%d dirty=%d f=%d, e=%d, f_p=%p, nfrags %d\n",
> @@ -2336,9 +2401,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
>
> /* The own bit must be the latest setting done when prepare the
> * descriptor and then barrier is needed to make sure that
> - * all is coherent before granting the DMA engine.
> + * all is coherent before granting access to the DMA engine.
> */
> - smp_wmb();
> + wmb();
> }
>
> netdev_sent_queue(dev, skb->len);
>
> Plus I'd suggest... at least (hand-edited). Driver should really be
> modified to use readl() when accessing memory that changes.
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 3e40578..641b03d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1309,6 +1323,8 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
> status = priv->hw->desc->tx_status(&priv->dev->stats,
> &priv->xstats, p,
> priv->ioaddr);
> + rmb();
> +
> /* Check if the descriptor is owned by the DMA */
> if (unlikely(status & tx_dma_own))
> break;
>
> Pavel
>
^ permalink raw reply
* Linux support for 802.1AS-Rev.
From: Praveen Bajantri @ 2016-12-19 10:20 UTC (permalink / raw)
To: netdev
Hello everyone,
I am new to Linux networking and had doubt related to support for
802.1AS-Rev. Please point me to appropriate forum/mailing list If this
is not a right place.
I know that Linux supports gPTP (802.1AS), As there are new clauses
added to gPTP to support new features such as one step time stamping,
I just wanted to know the Linux support for 802.1AS-Rev.
Does Linux support 802.1AS-Rev ? Is there any application which can be
used to test this feature ?
Thanks,
Praveen Bajantri
^ permalink raw reply
* Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock
From: Pavel Machek @ 2016-12-19 10:02 UTC (permalink / raw)
To: Francois Romieu
Cc: Lino Sanfilippo, bh74.an, ks.giri, vipul.pandya, peppe.cavallaro,
alexandre.torgue, davem, linux-kernel, netdev
In-Reply-To: <20161218001507.GA5343@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]
Hi!
> Lino, have you considered via-rhine.c since its "move work from irq to
> workqueue context" changes that started in
> 7ab87ff4c770eed71e3777936299292739fcd0fe [*] ?
>
> It's a shameless plug - originated in r8169.c - but it should be rather
> close to what the sxgbe and friends require. Thought / opinion ?
>
> [*] Including fixes/changes in:
> - 3a5a883a8a663b930908cae4abe5ec913b9b2fd2
> - e1efa87241272104d6a12c8b9fcdc4f62634d447
> - 810f19bcb862f8889b27e0c9d9eceac9593925dd
> - e45af497950a89459a0c4b13ffd91e1729fffef4
> - a926592f5e4e900f3fa903298c4619a131e60963
> - 559bcac35facfed49ab4f408e162971612dcfdf3
Considering the memory barriers... is something like this neccessary
in the via-rhine?
AFAICT... we need a barrier after making sure that descriptor is no
longer owned by DMA (to make sure we don't get stale data in rest of
descriptor)... and we need a barrier before giving the descriptor to
the dma, to make sure DMA engine sees the complete update....?
Thanks,
Pavel
diff --git a/drivers/net/ethernet/via/via-rhine.c b/drivers/net/ethernet/via/via-rhine.c
index ba5c542..3806e72 100644
--- a/drivers/net/ethernet/via/via-rhine.c
+++ b/drivers/net/ethernet/via/via-rhine.c
@@ -1952,6 +1952,7 @@ static void rhine_tx(struct net_device *dev)
entry, txstatus);
if (txstatus & DescOwn)
break;
+ dma_rmb();
skb = rp->tx_skbuff[entry];
if (txstatus & 0x8000) {
netif_dbg(rp, tx_done, dev,
@@ -2061,6 +2062,7 @@ static int rhine_rx(struct net_device *dev, int limit)
if (desc_status & DescOwn)
break;
+ dma_rmb();
netif_dbg(rp, rx_status, dev, "%s() status %08x\n", __func__,
desc_status);
@@ -2146,6 +2148,7 @@ static int rhine_rx(struct net_device *dev, int limit)
u64_stats_update_end(&rp->rx_stats.syncp);
}
give_descriptor_to_nic:
+ dma_wmb();
desc->rx_status = cpu_to_le32(DescOwn);
entry = (++rp->cur_rx) % RX_RING_SIZE;
}
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply related
* [PATCH net v2 5/5] fsl/fman: enable compilation on ARM64
From: Madalin Bucur @ 2016-12-19 9:22 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem, scott.wood, mpe
In-Reply-To: <1482139343-8975-1-git-send-email-madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
drivers/net/ethernet/freescale/fman/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fman/Kconfig b/drivers/net/ethernet/freescale/fman/Kconfig
index 79b7c84..dc0850b 100644
--- a/drivers/net/ethernet/freescale/fman/Kconfig
+++ b/drivers/net/ethernet/freescale/fman/Kconfig
@@ -1,6 +1,6 @@
config FSL_FMAN
tristate "FMan support"
- depends on FSL_SOC || COMPILE_TEST
+ depends on FSL_SOC || ARCH_LAYERSCAPE || COMPILE_TEST
select GENERIC_ALLOCATOR
select PHYLIB
default n
--
2.1.0
^ permalink raw reply related
* [PATCH net v2 4/5] fsl/fman: A007273 only applies to PPC SoCs
From: Madalin Bucur @ 2016-12-19 9:22 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem, scott.wood, mpe
In-Reply-To: <1482139343-8975-1-git-send-email-madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Reviewed-by: Camelia Groza <camelia.groza@nxp.com>
---
drivers/net/ethernet/freescale/fman/fman.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
index 0b7f711..003b86d 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -1890,6 +1890,7 @@ static int fman_reset(struct fman *fman)
goto _return;
} else {
+#ifdef CONFIG_PPC
struct device_node *guts_node;
struct ccsr_guts __iomem *guts_regs;
u32 devdisr2, reg;
@@ -1921,6 +1922,7 @@ static int fman_reset(struct fman *fman)
/* Enable all MACs */
iowrite32be(reg, &guts_regs->devdisr2);
+#endif
/* Perform FMan reset */
iowrite32be(FPM_RSTC_FM_RESET, &fman->fpm_regs->fm_rstc);
@@ -1932,25 +1934,31 @@ static int fman_reset(struct fman *fman)
} while (((ioread32be(&fman->fpm_regs->fm_rstc)) &
FPM_RSTC_FM_RESET) && --count);
if (count == 0) {
+#ifdef CONFIG_PPC
iounmap(guts_regs);
of_node_put(guts_node);
+#endif
err = -EBUSY;
goto _return;
}
+#ifdef CONFIG_PPC
/* Restore devdisr2 value */
iowrite32be(devdisr2, &guts_regs->devdisr2);
iounmap(guts_regs);
of_node_put(guts_node);
+#endif
goto _return;
+#ifdef CONFIG_PPC
guts_regs:
of_node_put(guts_node);
guts_node:
dev_dbg(fman->dev, "%s: Didn't perform FManV3 reset due to Errata A007273!\n",
__func__);
+#endif
}
_return:
return err;
--
2.1.0
^ permalink raw reply related
* [PATCH net v2 3/5] fsl/fman: call of_platform_populate()
From: Madalin Bucur @ 2016-12-19 9:22 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem, scott.wood, mpe
In-Reply-To: <1482139343-8975-1-git-send-email-madalin.bucur@nxp.com>
From: Igal Liberman <igal.liberman@freescale.com>
Call of_platform_populate() to probe the FMan sub-nodes.
Signed-off-by: Igal Liberman <igal.liberman@freescale.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
drivers/net/ethernet/freescale/fman/fman.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
index dafd9e1..0b7f711 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -2868,6 +2868,14 @@ static struct fman *read_dts_node(struct platform_device *of_dev)
fman->dev = &of_dev->dev;
+ /* call of_platform_populate in order to probe sub-nodes on arm64 */
+ err = of_platform_populate(fm_node, NULL, NULL, &of_dev->dev);
+ if (err) {
+ dev_err(&of_dev->dev, "%s: of_platform_populate() failed\n",
+ __func__);
+ goto fman_free;
+ }
+
return fman;
fman_node_put:
--
2.1.0
^ permalink raw reply related
* [PATCH net v2 2/5] powerpc: remove fsl,fman from of_device_ids[]
From: Madalin Bucur @ 2016-12-19 9:22 UTC (permalink / raw)
To: netdev; +Cc: scott.wood, linuxppc-dev, linux-kernel, davem
In-Reply-To: <1482139343-8975-1-git-send-email-madalin.bucur@nxp.com>
The fsl/fman drivers will use of_platform_populate() on all
supported platforms.
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
arch/powerpc/platforms/85xx/corenet_generic.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index 1179115..824b7f1 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -117,9 +117,6 @@ static const struct of_device_id of_device_ids[] = {
{
.compatible = "fsl,qe",
},
- {
- .compatible = "fsl,fman",
- },
/* The following two are for the Freescale hypervisor */
{
.name = "hypervisor",
--
2.1.0
^ permalink raw reply related
* [PATCH net v2 1/5] fsl/fman: fix 1G support for QSGMII interfaces
From: Madalin Bucur @ 2016-12-19 9:22 UTC (permalink / raw)
To: netdev; +Cc: scott.wood, linuxppc-dev, linux-kernel, davem
In-Reply-To: <1482139343-8975-1-git-send-email-madalin.bucur@nxp.com>
QSGMII ports were not advertising 1G speed.
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Reviewed-by: Camelia Groza <camelia.groza@nxp.com>
---
drivers/net/ethernet/freescale/fman/mac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/fman/mac.c b/drivers/net/ethernet/freescale/fman/mac.c
index 69ca42c..0b31f85 100644
--- a/drivers/net/ethernet/freescale/fman/mac.c
+++ b/drivers/net/ethernet/freescale/fman/mac.c
@@ -594,6 +594,7 @@ static const u16 phy2speed[] = {
[PHY_INTERFACE_MODE_RGMII_RXID] = SPEED_1000,
[PHY_INTERFACE_MODE_RGMII_TXID] = SPEED_1000,
[PHY_INTERFACE_MODE_RTBI] = SPEED_1000,
+ [PHY_INTERFACE_MODE_QSGMII] = SPEED_1000,
[PHY_INTERFACE_MODE_XGMII] = SPEED_10000
};
--
2.1.0
^ permalink raw reply related
* [PATCH net v2 0/5] fsl/fman: fixes for ARM
From: Madalin Bucur @ 2016-12-19 9:22 UTC (permalink / raw)
To: netdev; +Cc: scott.wood, linuxppc-dev, linux-kernel, davem
The patch set fixes advertised speeds for QSGMII interfaces, disables
A007273 erratum workaround on non-PowerPC platforms where it does not
apply, enables compilation on ARM64 and addresses a probing issue on
non PPC platforms.
Changes from v1: unifying probing on all supported platforms
Igal Liberman (1):
fsl/fman: call of_platform_populate()
Madalin Bucur (4):
fsl/fman: fix 1G support for QSGMII interfaces
powerpc: remove fsl,fman from of_device_ids[]
fsl/fman: A007273 only applies to PPC SoCs
fsl/fman: enable compilation on ARM64
arch/powerpc/platforms/85xx/corenet_generic.c | 3 ---
drivers/net/ethernet/freescale/fman/Kconfig | 2 +-
drivers/net/ethernet/freescale/fman/fman.c | 16 ++++++++++++++++
drivers/net/ethernet/freescale/fman/mac.c | 1 +
4 files changed, 18 insertions(+), 4 deletions(-)
--
2.1.0
^ permalink raw reply
* Re: [PATCH 5/8] linux: drop __bitwise__ everywhere
From: Luca Coelho @ 2016-12-19 9:09 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel
Cc: Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Russell King, Alasdair Kergon, Mike Snitzer, dm-devel, Shaohua Li,
Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless,
Kalle Valo, Greg Kroah-Hartman, Jiri Slaby, Lee Duncan,
Chris Leech, James E.J. Bottomley, Martin K. Petersen,
Nicholas A. Bellinger, Jason Wang, Alexander Aring,
Stefan Schmidt, David S. Miller
In-Reply-To: <1481778865-27667-6-git-send-email-mst@redhat.com>
On Thu, 2016-12-15 at 07:15 +0200, Michael S. Tsirkin wrote:
> __bitwise__ used to mean "yes, please enable sparse checks
> unconditionally", but now that we dropped __CHECK_ENDIAN__
> __bitwise is exactly the same.
> There aren't many users, replace it by __bitwise everywhere.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> arch/arm/plat-samsung/include/plat/gpio-cfg.h | 2 +-
> drivers/md/dm-cache-block-types.h | 6 +++---
> drivers/net/ethernet/sun/sunhme.h | 2 +-
> drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 4 ++--
For drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h:
Acked-by: Luca Coelho <luciano.coelho@intel.com>
--
Luca.
--
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 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags
From: Luca Coelho @ 2016-12-19 9:08 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Emmanuel Grumbach, Stanislaw Gruszka, Gustavo Padovan,
Arend van Spriel, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
Jakub Kicinski, Stefan Schmidt,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
wil6210-A+ZNKFmMK5xy9aJCnZT0Uw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chris Snook,
Wolfgang Grandegger, Jay Cliburn,
linux-wpan-u79uwXL29TY76Z2rM5mHXA, Johan Hedberg, Johannes Berg,
Intel Linux Wireless, Alexander Aring, Marcel Holtmann,
Hante Meuleman, linux-can-u79uwXL29TY76Z2rM5mHXA,
Marc Kleine-Budde, Matthias Brugger, Kall
In-Reply-To: <1481778865-27667-9-git-send-email-mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Thu, 2016-12-15 at 07:15 +0200, Michael S. Tsirkin wrote:
> That's the default now, no need for makefiles to set it.
>
> Signed-off-by: Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> drivers/bluetooth/Makefile | 2 --
> drivers/net/can/Makefile | 1 -
> drivers/net/ethernet/altera/Makefile | 1 -
> drivers/net/ethernet/atheros/alx/Makefile | 1 -
> drivers/net/ethernet/freescale/Makefile | 2 --
> drivers/net/wireless/ath/Makefile | 2 --
> drivers/net/wireless/ath/wil6210/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 1 -
> drivers/net/wireless/intel/iwlegacy/Makefile | 2 --
> drivers/net/wireless/intel/iwlwifi/Makefile | 2 +-
> drivers/net/wireless/intel/iwlwifi/dvm/Makefile | 2 +-
> drivers/net/wireless/intel/iwlwifi/mvm/Makefile | 2 +-
For the drivers/net/wireless/intel/iwlwifi/ part:
Acked-by: Luca Coelho <luciano.coelho-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
--
Luca.
^ permalink raw reply
* ovs internal_dev mtu
From: nickcooper-zhangtonghao @ 2016-12-19 8:59 UTC (permalink / raw)
To: netdev
The upstream net-next has removed the “internal_dev_change_mtu”.
It will be ok for ovs(e.g. mtu_request) ? I think that code should
be keep. Can you provide more information ？
^ permalink raw reply
* Re: "rfkill: Add rfkill-any LED trigger" causes deadlock
From: Johannes Berg @ 2016-12-19 8:56 UTC (permalink / raw)
To: Михаил Кринкин,
kernel, linux-wireless, davem, netdev
In-Reply-To: <CACpa5=_chGuU3zVcVR3nkNySwz1cGAQTs39v+BjwcDNSvOqhTw@mail.gmail.com>
Hi Mike,
Thanks for the report. I'm sorry I missed this in review - obviously we
can't call something that acquires the mutex from rfkill_set_sw_state()
which clearly states, in the documentation:
* This function can be called in any context, even from within rfkill
* callbacks.
I've reverted the change (and the follow-up fix) now.
Michał, if you want to resubmit with this fixed, please also make sure
you don't reintroduce the unused label warning and have the appropriate
#ifdef that Arnd had later added for your change.
Thanks,
johannes
^ permalink raw reply
* Re: [PATCH v2 1/4] net: hix5hd2_gmac: add generic compatible string
From: Dongpo Li @ 2016-12-19 8:14 UTC (permalink / raw)
To: Rob Herring, David Miller
Cc: Mark Rutland, Michael Turquette, Stephen Boyd, Russell King,
Zhangfei Gao, Yisen Zhuang, salil.mehta, Arnd Bergmann,
Andrew Lunn, Jiancheng Xue, benjamin.chenhao, caizhiyong, netdev,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CAL_Jsq+d5xHsxMKxbWSYy3cDXnC+HQj3=wun1zxf5PZ_BYrD-Q@mail.gmail.com>
Hi Rob and David,
On 2016/12/12 22:21, Rob Herring wrote:
> On Mon, Dec 12, 2016 at 5:16 AM, Dongpo Li <lidongpo@hisilicon.com> wrote:
>> Hi Rob,
>>
>> On 2016/12/10 6:35, Rob Herring wrote:
>>> On Mon, Dec 05, 2016 at 09:27:58PM +0800, Dongpo Li wrote:
>>>> The "hix5hd2" is SoC name, add the generic ethernet driver name.
>>>> The "hisi-gemac-v1" is the basic version and "hisi-gemac-v2" adds
>>>> the SG/TXCSUM/TSO/UFO features.
>>>>
>>>> Signed-off-by: Dongpo Li <lidongpo@hisilicon.com>
>>>> ---
>>>> .../devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt | 9 +++++++--
>>>> drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 15 +++++++++++----
>>>> 2 files changed, 18 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
>>>> index 75d398b..75920f0 100644
>>>> --- a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
>>>> +++ b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
>>>> @@ -1,7 +1,12 @@
>>>> Hisilicon hix5hd2 gmac controller
>>>>
>>>> Required properties:
>>>> -- compatible: should be "hisilicon,hix5hd2-gmac".
>>>> +- compatible: should contain one of the following SoC strings:
>>>> + * "hisilicon,hix5hd2-gemac"
>>>> + * "hisilicon,hi3798cv200-gemac"
>>>> + and one of the following version string:
>>>> + * "hisilicon,hisi-gemac-v1"
>>>> + * "hisilicon,hisi-gemac-v2"
>>>
>>> What combinations are valid? I assume both chips don't have both v1 and
>>> v2. 2 SoCs and 2 versions so far, I don't think there is much point to
>>> have the v1 and v2 compatible strings.
>>>
>> The v1 and v2 are generic MAC compatible strings, many HiSilicon SoCs may
>> use the same MAC version. For example,
>> hix5hd2, hi3716cv200 SoCs use the v1 MAC version,
>> hi3798cv200, hi3516a SoCs use the v2 MAC version,
>> and there may be more SoCs added in future.
>> So I think the generic compatible strings are okay here.
>> Should I add the hi3716cv200, hi3516a SoCs compatible here?
>
> Yes.
>
>> Do you have any good advice?
>>
>>>> - reg: specifies base physical address(s) and size of the device registers.
>>>> The first region is the MAC register base and size.
>>>> The second region is external interface control register.
>>>> @@ -20,7 +25,7 @@ Required properties:
>>>>
>>>> Example:
>>>> gmac0: ethernet@f9840000 {
>>>> - compatible = "hisilicon,hix5hd2-gmac";
>>>> + compatible = "hisilicon,hix5hd2-gemac", "hisilicon,hisi-gemac-v1";
>>>
>>> You can't just change compatible strings.
>>>
>> Okay, maybe I should name all the compatible string with the suffix "-gmac" instead of
>> "-gemac". This can keep the compatible strings with the same suffix. Is this okay?
>> Can I just add the generic compatible string without changing the SoCs compatible string?
>> Like following:
>> gmac0: ethernet@f9840000 {
>> - compatible = "hisilicon,hix5hd2-gmac";
>> + compatible = "hisilicon,hix5hd2-gmac", "hisilicon,hisi-gmac-v1";
>
> Yes, this is fine.
As the patch series have been applied to net-next branch,
in which way should I commit this compatible fix?
Should I send a new patch fixing this compatible string error with "Fixes: xxx"?
Looking forward to your reply!
Regards,
Dongpo
.
^ permalink raw reply
* Re: [RFC v2 03/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) netdev
From: Vishwanathapura, Niranjana @ 2016-12-19 6:43 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w,
ira.weiny-ral2JQCrhuEAvxtiuMwx3w, Sadanand Warrier, Sudeep Dutt,
Tanya K Jajodia, Andrzej Kacprowski
In-Reply-To: <20161216042420.GB3797-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Thu, Dec 15, 2016 at 09:24:20PM -0700, Jason Gunthorpe wrote:
>> >>+struct __hfi_vesw_info {
>> >>+ u16 fabric_id;
>> >>+ u16 vesw_id;
>> >>+
>> >>+ u8 rsvd0[6];
>> >>+ u16 def_port_mask;
>> >>+
>> >>+ u8 rsvd1[2];
>> >>+ u16 pkey;
>> >>+
>> >>+ u8 rsvd2[4];
>> >>+ u32 u_mcast_dlid;
>> >>+ u32 u_ucast_dlid[HFI_VESW_MAX_NUM_DEF_PORT];
>> >>+
>> >>+ u8 rsvd3[44];
>> >>+ u16 eth_mtu[HFI_VNIC_MAX_NUM_PCP];
>> >>+ u16 eth_mtu_non_vlan;
>> >>+ u8 rsvd4[2];
>> >>+} __packed;
>> >
>> >This goes on the network too? Also looks like it has endian problems.
>> >
>> >Ditto for all the __packed structures.
>> >
>>
>> This is in CPU format. There is a separate big endian version of
>> this
>
>Why are CPU handled structures packed and full of reserved fields?
>Don't pack them if they are not pushed out to the network..
>
>There were lots of __packed structures, any that go on the network
>need be/le annoations.
>
Well, driver treats the reserved fields to be sticky. ie., information
block returned (upon GET) to EM is not changed (from SET) except few fields
which driver is expected to modify.
Structures that go on wire are big endian __packed structures in
hfi_vnic_encap.h. Ok, I will remove the __packed attribute from CPU handled
structures here.
Niranjana
>Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 3/3] net: fec: Fix typo in error msg and comment
From: Andy Duan @ 2016-12-19 2:14 UTC (permalink / raw)
To: Peter Meerwald-Stadler, netdev@vger.kernel.org; +Cc: trivial@kernel.org
In-Reply-To: <1481894616-4517-1-git-send-email-pmeerw@pmeerw.net>
From: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Sent: Friday, December 16, 2016 9:24 PM
>To: netdev@vger.kernel.org
>Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>; Andy Duan
><fugang.duan@nxp.com>; trivial@kernel.org
>Subject: [PATCH 3/3] net: fec: Fix typo in error msg and comment
>
>Signed-off-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
>Cc: Fugang Duan <fugang.duan@nxp.com>
>Cc: trivial@kernel.org
>---
> drivers/net/ethernet/freescale/fec_main.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Acked-by: Fugang Duan <fugang.duan@nxp.com>
>diff --git a/drivers/net/ethernet/freescale/fec_main.c
>b/drivers/net/ethernet/freescale/fec_main.c
>index 38160c2..250b790 100644
>--- a/drivers/net/ethernet/freescale/fec_main.c
>+++ b/drivers/net/ethernet/freescale/fec_main.c
>@@ -2001,7 +2001,7 @@ static int fec_enet_mii_init(struct platform_device
>*pdev)
> mii_speed--;
> if (mii_speed > 63) {
> dev_err(&pdev->dev,
>- "fec clock (%lu) to fast to get right mii speed\n",
>+ "fec clock (%lu) too fast to get right mii speed\n",
> clk_get_rate(fep->clk_ipg));
> err = -EINVAL;
> goto err_out;
>@@ -2950,7 +2950,7 @@ static void set_multicast_list(struct net_device
>*ndev)
> }
>
> /* only upper 6 bits (FEC_HASH_BITS) are used
>- * which point to specific bit in he hash registers
>+ * which point to specific bit in the hash registers
> */
> hash = (crc >> (32 - FEC_HASH_BITS)) & 0x3f;
>
>--
>1.7.10.4
^ permalink raw reply
* Re: [PATCH iproute2 v2 1/3] ifstat: Add extended statistics to ifstat
From: Or Gerlitz @ 2016-12-19 4:10 UTC (permalink / raw)
To: Nogah Frankel
Cc: Linux Netdev List, Stephen Hemminger, Roopa Prabhu, Jiri Pirko,
Elad Raz, Yotam Gigi, Ido Schimmel, Or Gerlitz
In-Reply-To: <1481806845-63384-2-git-send-email-nogahf@mellanox.com>
On Thu, Dec 15, 2016 at 3:00 PM, Nogah Frankel <nogahf@mellanox.com> wrote:
> +/* Note: if one xstat name in subset of another, it should be before it in this
> + * list.
> + * Name length must be under 64 chars.
> + */
nit "in subset" --> "is subset" ?
^ permalink raw reply
* [PATCH net-next 1/1] driver: ipvlan: Define common functions to decrease duplicated codes used to add or del IP address
From: fgao @ 2016-12-19 1:24 UTC (permalink / raw)
To: davem, maheshb, edumazet, netdev, gfree.wind; +Cc: Gao Feng
From: Gao Feng <fgao@ikuai8.com>
There are some duplicated codes in ipvlan_add_addr6/4 and
ipvlan_del_addr6/4. Now define two common functions ipvlan_add_addr
and ipvlan_del_addr to decrease the duplicated codes.
It could be helful to maintain the codes.
Signed-off-by: Gao Feng <fgao@ikuai8.com>
---
It is sent again because the first email is sent during net-next closing.
drivers/net/ipvlan/ipvlan_main.c | 68 +++++++++++++++++-----------------------
1 file changed, 29 insertions(+), 39 deletions(-)
diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
index 693ec5b..5874d30 100644
--- a/drivers/net/ipvlan/ipvlan_main.c
+++ b/drivers/net/ipvlan/ipvlan_main.c
@@ -669,23 +669,22 @@ static int ipvlan_device_event(struct notifier_block *unused,
return NOTIFY_DONE;
}
-static int ipvlan_add_addr6(struct ipvl_dev *ipvlan, struct in6_addr *ip6_addr)
+static int ipvlan_add_addr(struct ipvl_dev *ipvlan, void *iaddr, bool is_v6)
{
struct ipvl_addr *addr;
- if (ipvlan_addr_busy(ipvlan->port, ip6_addr, true)) {
- netif_err(ipvlan, ifup, ipvlan->dev,
- "Failed to add IPv6=%pI6c addr for %s intf\n",
- ip6_addr, ipvlan->dev->name);
- return -EINVAL;
- }
addr = kzalloc(sizeof(struct ipvl_addr), GFP_ATOMIC);
if (!addr)
return -ENOMEM;
addr->master = ipvlan;
- memcpy(&addr->ip6addr, ip6_addr, sizeof(struct in6_addr));
- addr->atype = IPVL_IPV6;
+ if (is_v6) {
+ memcpy(&addr->ip6addr, iaddr, sizeof(struct in6_addr));
+ addr->atype = IPVL_IPV6;
+ } else {
+ memcpy(&addr->ip4addr, iaddr, sizeof(struct in_addr));
+ addr->atype = IPVL_IPV4;
+ }
list_add_tail(&addr->anode, &ipvlan->addrs);
/* If the interface is not up, the address will be added to the hash
@@ -697,11 +696,11 @@ static int ipvlan_add_addr6(struct ipvl_dev *ipvlan, struct in6_addr *ip6_addr)
return 0;
}
-static void ipvlan_del_addr6(struct ipvl_dev *ipvlan, struct in6_addr *ip6_addr)
+static void ipvlan_del_addr(struct ipvl_dev *ipvlan, void *iaddr, bool is_v6)
{
struct ipvl_addr *addr;
- addr = ipvlan_find_addr(ipvlan, ip6_addr, true);
+ addr = ipvlan_find_addr(ipvlan, iaddr, is_v6);
if (!addr)
return;
@@ -712,6 +711,23 @@ static void ipvlan_del_addr6(struct ipvl_dev *ipvlan, struct in6_addr *ip6_addr)
return;
}
+static int ipvlan_add_addr6(struct ipvl_dev *ipvlan, struct in6_addr *ip6_addr)
+{
+ if (ipvlan_addr_busy(ipvlan->port, ip6_addr, true)) {
+ netif_err(ipvlan, ifup, ipvlan->dev,
+ "Failed to add IPv6=%pI6c addr for %s intf\n",
+ ip6_addr, ipvlan->dev->name);
+ return -EINVAL;
+ }
+
+ return ipvlan_add_addr(ipvlan, ip6_addr, true);
+}
+
+static void ipvlan_del_addr6(struct ipvl_dev *ipvlan, struct in6_addr *ip6_addr)
+{
+ return ipvlan_del_addr(ipvlan, ip6_addr, true);
+}
+
static int ipvlan_addr6_event(struct notifier_block *unused,
unsigned long event, void *ptr)
{
@@ -745,45 +761,19 @@ static int ipvlan_addr6_event(struct notifier_block *unused,
static int ipvlan_add_addr4(struct ipvl_dev *ipvlan, struct in_addr *ip4_addr)
{
- struct ipvl_addr *addr;
-
if (ipvlan_addr_busy(ipvlan->port, ip4_addr, false)) {
netif_err(ipvlan, ifup, ipvlan->dev,
"Failed to add IPv4=%pI4 on %s intf.\n",
ip4_addr, ipvlan->dev->name);
return -EINVAL;
}
- addr = kzalloc(sizeof(struct ipvl_addr), GFP_KERNEL);
- if (!addr)
- return -ENOMEM;
-
- addr->master = ipvlan;
- memcpy(&addr->ip4addr, ip4_addr, sizeof(struct in_addr));
- addr->atype = IPVL_IPV4;
- list_add_tail(&addr->anode, &ipvlan->addrs);
-
- /* If the interface is not up, the address will be added to the hash
- * list by ipvlan_open.
- */
- if (netif_running(ipvlan->dev))
- ipvlan_ht_addr_add(ipvlan, addr);
- return 0;
+ return ipvlan_add_addr(ipvlan, ip4_addr, false);
}
static void ipvlan_del_addr4(struct ipvl_dev *ipvlan, struct in_addr *ip4_addr)
{
- struct ipvl_addr *addr;
-
- addr = ipvlan_find_addr(ipvlan, ip4_addr, false);
- if (!addr)
- return;
-
- ipvlan_ht_addr_del(addr);
- list_del(&addr->anode);
- kfree_rcu(addr, rcu);
-
- return;
+ return ipvlan_del_addr(ipvlan, ip4_addr, false);
}
static int ipvlan_addr4_event(struct notifier_block *unused,
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 1/1] driver: ipvlan: Remove unnecessary ipvlan NULL check in ipvlan_count_rx
From: fgao @ 2016-12-19 1:24 UTC (permalink / raw)
To: davem, maheshb, edumazet, netdev, gfree.wind; +Cc: Gao Feng
From: Gao Feng <fgao@ikuai8.com>
There are three functions which would invoke the ipvlan_count_rx. They
are ipvlan_process_multicast, ipvlan_rcv_frame, and ipvlan_nf_input.
The former two functions already use the ipvlan directly before
ipvlan_count_rx, and ipvlan_nf_input gets the ipvlan from
ipvl_addr->master, it is not possible to be NULL too.
So the ipvlan pointer check is unnecessary in ipvlan_count_rx.
Signed-off-by: Gao Feng <fgao@ikuai8.com>
---
drivers/net/ipvlan/ipvlan_core.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ipvlan/ipvlan_core.c b/drivers/net/ipvlan/ipvlan_core.c
index b4e9907..082f9f1 100644
--- a/drivers/net/ipvlan/ipvlan_core.c
+++ b/drivers/net/ipvlan/ipvlan_core.c
@@ -19,9 +19,6 @@ void ipvlan_init_secret(void)
static void ipvlan_count_rx(const struct ipvl_dev *ipvlan,
unsigned int len, bool success, bool mcast)
{
- if (!ipvlan)
- return;
-
if (likely(success)) {
struct ipvl_pcpu_stats *pcptr;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net] netfilter: check duplicate config when initializing in ipt_CLUSTERIP
From: Marcelo Ricardo Leitner @ 2016-12-19 1:02 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, netfilter-devel, davem
In-Reply-To: <9b3e1f76b5670d33727e63b6e166ae416b0d65af.1481776300.git.lucien.xin@gmail.com>
On Thu, Dec 15, 2016 at 12:31:40PM +0800, Xin Long wrote:
> Now when adding an ipt_CLUSTERIP rule, it only checks duplicate config in
> clusterip_config_find_get(). But after that, there may be still another
> thread to insert a config with the same ip, then it leaves proc_create_data
> to do duplicate check.
>
> It's more reasonable to check duplicate config by ipt_CLUSTERIP itself,
> instead of checking it by proc fs duplicate file check. Before, when proc
> fs allowed duplicate name files in a directory, It could even crash kernel
> because of use-after-free.
>
> This patch is to check duplicate config under the protection of clusterip
> net lock when initializing a new config.
>
> Note that it also moves proc file node creation after adding new config, as
> proc_create_data may sleep, it couldn't be called under the clusterip_net
> lock. clusterip_config_find_get returns NULL if c->pde is null to make sure
> it can't be used until the proc file node creation is done.
>
> Suggested-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> net/ipv4/netfilter/ipt_CLUSTERIP.c | 26 +++++++++++++++++++-------
> 1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/net/ipv4/netfilter/ipt_CLUSTERIP.c b/net/ipv4/netfilter/ipt_CLUSTERIP.c
> index 21db00d..0e71cac 100644
> --- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
> +++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
> @@ -144,7 +144,7 @@ clusterip_config_find_get(struct net *net, __be32 clusterip, int entry)
> rcu_read_lock_bh();
> c = __clusterip_config_find(net, clusterip);
> if (c) {
> - if (unlikely(!atomic_inc_not_zero(&c->refcount)))
> + if (!c->pde || unlikely(!atomic_inc_not_zero(&c->refcount)))
> c = NULL;
> else if (entry)
> atomic_inc(&c->entries);
> @@ -166,10 +166,11 @@ clusterip_config_init_nodelist(struct clusterip_config *c,
>
> static struct clusterip_config *
> clusterip_config_init(const struct ipt_clusterip_tgt_info *i, __be32 ip,
> - struct net_device *dev)
> + struct net_device *dev)
> {
> + struct net *net = dev_net(dev);
> struct clusterip_config *c;
> - struct clusterip_net *cn = net_generic(dev_net(dev), clusterip_net_id);
> + struct clusterip_net *cn = net_generic(net, clusterip_net_id);
>
> c = kzalloc(sizeof(*c), GFP_ATOMIC);
> if (!c)
> @@ -185,6 +186,17 @@ clusterip_config_init(const struct ipt_clusterip_tgt_info *i, __be32 ip,
> atomic_set(&c->refcount, 1);
> atomic_set(&c->entries, 1);
>
> + spin_lock_bh(&cn->lock);
> + if (__clusterip_config_find(net, ip)) {
> + spin_unlock_bh(&cn->lock);
> + kfree(c);
> +
> + return NULL;
> + }
> +
> + list_add_rcu(&c->list, &cn->configs);
> + spin_unlock_bh(&cn->lock);
> +
> #ifdef CONFIG_PROC_FS
> {
> char buffer[16];
> @@ -195,16 +207,16 @@ clusterip_config_init(const struct ipt_clusterip_tgt_info *i, __be32 ip,
> cn->procdir,
> &clusterip_proc_fops, c);
> if (!c->pde) {
> + spin_lock_bh(&cn->lock);
> + list_del_rcu(&c->list);
> + spin_unlock_bh(&cn->lock);
> kfree(c);
> +
> return NULL;
> }
> }
> #endif
>
> - spin_lock_bh(&cn->lock);
> - list_add_rcu(&c->list, &cn->configs);
> - spin_unlock_bh(&cn->lock);
> -
> return c;
> }
>
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* RE: [PATCH iproute2 v2 1/3] ifstat: Add extended statistics to ifstat
From: Nogah Frankel @ 2016-12-18 14:22 UTC (permalink / raw)
To: Rami Rosen
Cc: Stephen Hemminger, netdev@vger.kernel.org,
roopa@cumulusnetworks.com, Jiri Pirko, Elad Raz, Yotam Gigi,
Ido Schimmel, Or Gerlitz
In-Reply-To: <CAKoUArk5oSseSGDdZ_TEGLbG-jabdArUmz3pZ7kdoZKiNpqPrQ@mail.gmail.com>
> -----Original Message-----
> From: Rami Rosen [mailto:roszenrami@gmail.com]
> Sent: Friday, December 16, 2016 5:21 PM
> To: Nogah Frankel <nogahf@mellanox.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>; netdev@vger.kernel.org;
> roopa@cumulusnetworks.com; Jiri Pirko <jiri@mellanox.com>; Elad Raz
> <eladr@mellanox.com>; Yotam Gigi <yotamg@mellanox.com>; Ido Schimmel
> <idosch@mellanox.com>; Or Gerlitz <ogerlitz@mellanox.com>
> Subject: Re: [PATCH iproute2 v2 1/3] ifstat: Add extended statistics to ifstat
>
> Hi,
>
> >Thanks, I'll fix it.
> Another minor nit, on this occasion:
>
> bool is_extanded should be: bool is_extended
>
> Regards,
> Rami Rosen
Thank you, I will fix it.
Nogah
^ permalink raw reply
* [PATCH] at86rf230: Allow slow GPIO pins for "rstn"
From: Andrey Smirnov @ 2016-12-18 23:25 UTC (permalink / raw)
To: linux-wpan
Cc: Andrey Smirnov, Alexander Aring, netdev, linux-kernel,
Chris Healy
Driver code never touches "rstn" signal in atomic context, so there's
no need to implicitly put such restriction on it by using gpio_set_value
to manipulate it. Replace gpio_set_value to gpio_set_value_cansleep to
fix that.
As a an example of where such restriction might be inconvenient,
consider a hardware design where "rstn" is connected to a pin of I2C/SPI
GPIO expander chip.
Cc: Chris Healy <cphealy@gmail.com>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
drivers/net/ieee802154/at86rf230.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c
index 9f10da6..7700690 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
@@ -1710,9 +1710,9 @@ static int at86rf230_probe(struct spi_device *spi)
/* Reset */
if (gpio_is_valid(rstn)) {
udelay(1);
- gpio_set_value(rstn, 0);
+ gpio_set_value_cansleep(rstn, 0);
udelay(1);
- gpio_set_value(rstn, 1);
+ gpio_set_value_cansleep(rstn, 1);
usleep_range(120, 240);
}
--
2.5.5
^ permalink raw reply related
* Re: regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section
From: Gabriel C @ 2016-12-18 23:11 UTC (permalink / raw)
To: paulmck, Valo, Kalle
Cc: Tobias Klausmann, lkml, ath9k-devel,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
netdev@vger.kernel.org, nbd@nbd.name
In-Reply-To: <20161218201410.GS3924@linux.vnet.ibm.com>
On 18.12.2016 21:14, Paul E. McKenney wrote:
> On Sun, Dec 18, 2016 at 07:57:42PM +0000, Valo, Kalle wrote:
>> Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> writes:
>>
>>> A patch for this is already floating on the ML for a while now latest:
>>> (ath9k: do not return early to fix rcu unlocking)
>>
>> It's here:
>>
>> https://patchwork.kernel.org/patch/9472709/
>
> Feel free to add:
>
> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
This patch fixes the bug for me.
You can add my Tested-by if you wish.
Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com>
Regards,
Gabriel
^ 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