* Re: sctp: kernel memory overwrite attempt detected in sctp_getsockopt_assoc_stats
From: Kees Cook @ 2017-01-17 17:19 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: David Laight, Neil Horman, Vladislav Yasevich, David Miller,
linux-sctp@vger.kernel.org, netdev, LKML, syzkaller, Rik van Riel
In-Reply-To: <CACT4Y+bK3nvWoGJcZs5k1Lr3Rbn7ZxBCvNscs9Ty=7ZJEF37kQ@mail.gmail.com>
On Mon, Jan 16, 2017 at 6:56 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Mon, Jan 16, 2017 at 3:50 PM, David Laight <David.Laight@aculab.com> wrote:
>> From: Dmitry Vyukov
>>> Sent: 16 January 2017 14:04
>>> >> >> I've enabled CONFIG_HARDENED_USERCOPY_PAGESPAN on syzkaller fuzzer and
>> ...
>>> >> The code also takes into account compound pages. As far as I
>>> >> understand the intention of the check is to effectively find
>>> >> out-of-bounds copies (e.g. goes beyond the current heap allocation). I
>>> >> would expect that stacks are allocated as compound pages and don't
>>> >> trigger this check. I don't see it is firing in other similar places.
>>> >>
>>> > Honestly, I'm not overly familiar with stack page allocation, at least not so
>>> > far as compound vs. single page allocation is concerned. I suppose the question
>>> > your really asking here is: Have you found a case in which the syscall fuzzer
>>> > has forced the allocation of an insecure non-compound page on the stack, or is
>>> > this a false positive warning. I can't provide the answer to that.
>>>
>>> Yes. I added Kees, author of CONFIG_HARDENED_USERCOPY_PAGESPAN, to To line.
>>> Kees, is this a false positive?
>>
>> I'd guess that the kernel stack is (somehow) allocated page by page
>> rather than by a single multi-page allocate.
>> Or maybe vmalloc() isn't setting the required flag??
>
>
> Just in case, I don't have CONFIG_VMAP_STACK selected.
> If it is a generic issue, then CONFIG_HARDENED_USERCOPY_PAGESPAN looks
> considerably broken as there are tons of copies onto stack. I don't
> see what's special in this particular case.
There have been so many false positives on this option, even though it
is known not to be quite right, that I'll probably just remove it
entirely. It clearly needs much more work before it'll be useful, so
there's no reason to leave it in the kernel to confuse people. :)
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
* Re: [PATCH] net: ethernet: stmmac: add ARP management
From: Florian Fainelli @ 2017-01-17 17:17 UTC (permalink / raw)
To: Christophe Roullier, Alexandre Torgue, Giuseppe Cavallaro, netdev,
linux-kernel
In-Reply-To: <1484672200-7755-1-git-send-email-christophe.roullier@st.com>
On 01/17/2017 08:56 AM, Christophe Roullier wrote:
> DWC_ether_qos supports the Address Recognition
> Protocol (ARP) Offload for IPv4 packets. This feature
> allows the processing of the IPv4 ARP request packet
> in the receive path and generating corresponding ARP
> response packet in the transmit path. DWC_ether_qos
> generates the ARP reply packets for appropriate ARP
> request packets.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 4daa8a3..92a0db9 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -306,6 +306,7 @@ struct plat_stmmacenet_data *
> plat->has_gmac = 0;
> plat->pmt = 1;
> plat->tso_en = of_property_read_bool(np, "snps,tso");
> + plat->arp_en = of_property_read_bool(np, "snps,arp");
You introduce a new property that needs to be documented in the Device
Tree binding document for stmmac.
--
Florian
^ permalink raw reply
* [PATCH net 1/3] net: ethtool: Initialize buffer when querying device channel settings
From: Tariq Toukan @ 2017-01-17 17:19 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Tariq Toukan, John W. Linville
In-Reply-To: <1484673559-21687-1-git-send-email-tariqt@mellanox.com>
From: Eran Ben Elisha <eranbe@mellanox.com>
Ethtool channels respond struct was uninitialized when querying device
channel boundaries settings. As a result, unreported fields by the driver
hold garbage. This may cause sending unsupported params to driver.
Fixes: 8bf368620486 ('ethtool: ensure channel counts are within bounds ...')
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
CC: John W. Linville <linville@tuxdriver.com>
---
net/core/ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index e23766c7e3ba..236a21e3c878 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1712,7 +1712,7 @@ static noinline_for_stack int ethtool_get_channels(struct net_device *dev,
static noinline_for_stack int ethtool_set_channels(struct net_device *dev,
void __user *useraddr)
{
- struct ethtool_channels channels, max;
+ struct ethtool_channels channels, max = { .cmd = ETHTOOL_GCHANNELS };
u32 max_rx_in_use = 0;
if (!dev->ethtool_ops->set_channels || !dev->ethtool_ops->get_channels)
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 0/3] ethtool fix
From: Tariq Toukan @ 2017-01-17 17:19 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Tariq Toukan
Hi Dave,
This patchset from Eran contains a fix to ethtool set_channels, where the call
to get_channels with an uninitialized parameter might result in garbage fields.
It also contains two followup changes in our mlx4/mlx5 Eth drivers.
Series generated against net commit:
0faa9cb5b383 net sched actions: fix refcnt when GETing of action after bind
Thanks,
Tariq.
Eran Ben Elisha (3):
net: ethtool: Initialize buffer when querying device channel settings
net/mlx4_en: Remove unnecessary checks when setting num channels
net/mlx5e: Remove unnecessary checks when setting num channels
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 7 +------
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 10 ----------
net/core/ethtool.c | 2 +-
3 files changed, 2 insertions(+), 17 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH] net: ethernet: stmmac: add ARP management
From: Andrew Lunn @ 2017-01-17 17:25 UTC (permalink / raw)
To: Christophe Roullier
Cc: Alexandre Torgue, Giuseppe Cavallaro, netdev, linux-kernel
In-Reply-To: <1484672200-7755-1-git-send-email-christophe.roullier@st.com>
On Tue, Jan 17, 2017 at 05:56:40PM +0100, Christophe Roullier wrote:
> DWC_ether_qos supports the Address Recognition
Resolution not Recognition?
> Protocol (ARP) Offload for IPv4 packets. This feature
> allows the processing of the IPv4 ARP request packet
> in the receive path and generating corresponding ARP
> response packet in the transmit path. DWC_ether_qos
> generates the ARP reply packets for appropriate ARP
> request packets.
What about when .ndo_set_mac_address is called?
Andrew
^ permalink raw reply
* Re: [PATCH net] lwtunnel: fix autoload of lwt modules
From: Robert Shearman @ 2017-01-17 17:26 UTC (permalink / raw)
To: David Ahern, netdev, roopa
In-Reply-To: <8b621810-f7b3-05bb-413b-29389125c6ea@cumulusnetworks.com>
On 17/01/17 17:07, David Ahern wrote:
> On 1/17/17 3:04 AM, Robert Shearman wrote:
>> Is it safe to release the rtnl lock here? E.g. neither fib_get_nhs nor fib_create_info take a reference on the device and further up inet_rtm_newroute has a pointer to the struct fib_table without taking a reference.
>
> fib tables can not be deleted so that reference is safe.
Looks like we can free a table on unmerging. Admittedly this is the
local table so is unlikely to be one that lwtunnels are used on, but
does it not need to be safe against races anyway?
> You are right about the dev reference in the IPv4 path but the thing is build_state does not need the device reference.
>
> Roopa: do you recall why dev is passed to build_state? Nothing about the encap should require a device reference and none of the current encaps use it.
>
>>
>> Unfortunately, I think more invasive changes are required to solve this. I'm happy to work on solving this.
>
> I have a patch that removes passing dev to build_state. Walking the remainder of the code I do not see any more references that would be affected by dropping rtnl here on the add path. Still looking at the delete path.
>
Ok, I'll continue looking too and let you know if there's anything else
that pops up.
Having said that, even if we eliminate all the unreferenced objects in
the current code, what are the chances that we'll be able to keep it
this way going forward? Perhaps it would be safer to retry the insert
operation from as close to the start as possible?
Thanks,
Rob
^ permalink raw reply
* [PATCH net 2/3] net/mlx4_en: Remove unnecessary checks when setting num channels
From: Tariq Toukan @ 2017-01-17 17:19 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Tariq Toukan
In-Reply-To: <1484673559-21687-1-git-send-email-tariqt@mellanox.com>
From: Eran Ben Elisha <eranbe@mellanox.com>
Boundaries checks for the number of RX, TX, other and combined channels
should be checked by the caller and not in the driver.
In addition, remove wrong memset on get channels as it overrides the cmd
field in the requester struct.
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index d9c9f86a30df..d5a9372ed84d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -1732,8 +1732,6 @@ static void mlx4_en_get_channels(struct net_device *dev,
{
struct mlx4_en_priv *priv = netdev_priv(dev);
- memset(channel, 0, sizeof(*channel));
-
channel->max_rx = MAX_RX_RINGS;
channel->max_tx = MLX4_EN_MAX_TX_RING_P_UP;
@@ -1752,10 +1750,7 @@ static int mlx4_en_set_channels(struct net_device *dev,
int xdp_count;
int err = 0;
- if (channel->other_count || channel->combined_count ||
- channel->tx_count > MLX4_EN_MAX_TX_RING_P_UP ||
- channel->rx_count > MAX_RX_RINGS ||
- !channel->tx_count || !channel->rx_count)
+ if (!channel->tx_count || !channel->rx_count)
return -EINVAL;
tmp = kzalloc(sizeof(*tmp), GFP_KERNEL);
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 3/3] net/mlx5e: Remove unnecessary checks when setting num channels
From: Tariq Toukan @ 2017-01-17 17:19 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Tariq Toukan
In-Reply-To: <1484673559-21687-1-git-send-email-tariqt@mellanox.com>
From: Eran Ben Elisha <eranbe@mellanox.com>
Boundaries checks for the number of RX and TX should be checked by the
caller and not in the driver.
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
index 33a399a8b5d5..b1b9eb6ee135 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
@@ -554,16 +554,6 @@ static int mlx5e_set_channels(struct net_device *dev,
__func__);
return -EINVAL;
}
- if (ch->rx_count || ch->tx_count) {
- netdev_info(dev, "%s: separate rx/tx count not supported\n",
- __func__);
- return -EINVAL;
- }
- if (count > ncv) {
- netdev_info(dev, "%s: count (%d) > max (%d)\n",
- __func__, count, ncv);
- return -EINVAL;
- }
if (priv->params.num_channels == count)
return 0;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next v4 1/2] net sched actions: Add support for user cookies
From: Jiri Pirko @ 2017-01-17 17:05 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Jamal Hadi Salim, davem, netdev, jiri, paulb, john.fastabend,
simon.horman, mrv, hadarh, ogerlitz, roid, xiyou.wangcong
In-Reply-To: <587E4D16.8030708@iogearbox.net>
Tue, Jan 17, 2017 at 05:57:58PM CET, daniel@iogearbox.net wrote:
>On 01/17/2017 05:50 PM, Jamal Hadi Salim wrote:
>> On 17-01-17 09:16 AM, Daniel Borkmann wrote:
>> > On 01/17/2017 12:11 PM, Jamal Hadi Salim wrote:
>> > > From: Jamal Hadi Salim <jhs@mojatatu.com>
>> > >
>> > > Introduce optional 128-bit action cookie.
>> > > Like all other cookie schemes in the networking world (eg in protocols
>> > > like http or existing kernel fib protocol field, etc) the idea is to save
>> > > user state that when retrieved serves as a correlator. The kernel
>> > > _should not_ intepret it. The user can store whatever they wish in the
>> > > 128 bits.
>> > [...]
>> >
>> > Since it looks like you need a v5 anyway, few comments below.
>> >
>> > > include/net/act_api.h | 1 +
>> > > include/net/pkt_cls.h | 8 ++++++++
>> > > include/uapi/linux/pkt_cls.h | 3 +++
>> > > net/sched/act_api.c | 25 +++++++++++++++++++++++++
>> > > 4 files changed, 37 insertions(+)
>> > >
>> > > diff --git a/include/net/act_api.h b/include/net/act_api.h
>> > > index 1d71644..0692458 100644
>> > > --- a/include/net/act_api.h
>> > > +++ b/include/net/act_api.h
>> > > @@ -41,6 +41,7 @@ struct tc_action {
>> > > struct rcu_head tcfa_rcu;
>> > > struct gnet_stats_basic_cpu __percpu *cpu_bstats;
>> > > struct gnet_stats_queue __percpu *cpu_qstats;
>> > > + struct tc_cookie *act_ck;
>> >
>> > Since we know anyway that this is part of struct tc_action, can't
>> > you just give this some real/readable name like ...
>> >
>> > struct tc_cookie cookie;
>>
>> Grep-ability.
>> I was worried about when the classifier adds its cookie it
>> would need to use something like cls_cookie etc.
>
>Given this cookie is just used for correlation in user space anyway
>and not processed any further by the kernel, I think we can well
>handle these very few spots, so would be better if the code is more
>maintainable instead.
I agree with Daniel. His naming change suggestions make sense.
In fact, Jamal, now I know why there are names like this all over TC :)
^ permalink raw reply
* [net, 1/6] net: korina: don't use overflow and underflow interrupts
From: Roman Yeryomin @ 2017-01-17 17:32 UTC (permalink / raw)
To: netdev
When such interrupts occur there is not much we can do.
Dropping the whole ring doesn't help and only produces high packet loss.
If we just ignore the interrupt the mac will drop one or few packets instead of the whole ring.
Also this will lower the irq handling load, which is good.
Signed-off-by: Roman Yeryomin <roman@advem.lv>
---
drivers/net/ethernet/korina.c | 83 +------------------------------------------
1 file changed, 1 insertion(+), 82 deletions(-)
diff --git a/drivers/net/ethernet/korina.c b/drivers/net/ethernet/korina.c
index 8037426..9bc375d 100644
--- a/drivers/net/ethernet/korina.c
+++ b/drivers/net/ethernet/korina.c
@@ -122,8 +122,6 @@ struct korina_private {
int rx_irq;
int tx_irq;
- int ovr_irq;
- int und_irq;
spinlock_t lock; /* NIC xmit lock */
@@ -890,8 +888,6 @@ static void korina_restart_task(struct work_struct *work)
*/
disable_irq(lp->rx_irq);
disable_irq(lp->tx_irq);
- disable_irq(lp->ovr_irq);
- disable_irq(lp->und_irq);
writel(readl(&lp->tx_dma_regs->dmasm) |
DMA_STAT_FINI | DMA_STAT_ERR,
@@ -910,40 +906,10 @@ static void korina_restart_task(struct work_struct *work)
}
korina_multicast_list(dev);
- enable_irq(lp->und_irq);
- enable_irq(lp->ovr_irq);
enable_irq(lp->tx_irq);
enable_irq(lp->rx_irq);
}
-static void korina_clear_and_restart(struct net_device *dev, u32 value)
-{
- struct korina_private *lp = netdev_priv(dev);
-
- netif_stop_queue(dev);
- writel(value, &lp->eth_regs->ethintfc);
- schedule_work(&lp->restart_task);
-}
-
-/* Ethernet Tx Underflow interrupt */
-static irqreturn_t korina_und_interrupt(int irq, void *dev_id)
-{
- struct net_device *dev = dev_id;
- struct korina_private *lp = netdev_priv(dev);
- unsigned int und;
-
- spin_lock(&lp->lock);
-
- und = readl(&lp->eth_regs->ethintfc);
-
- if (und & ETH_INT_FC_UND)
- korina_clear_and_restart(dev, und & ~ETH_INT_FC_UND);
-
- spin_unlock(&lp->lock);
-
- return IRQ_HANDLED;
-}
-
static void korina_tx_timeout(struct net_device *dev)
{
struct korina_private *lp = netdev_priv(dev);
@@ -951,25 +917,6 @@ static void korina_tx_timeout(struct net_device *dev)
schedule_work(&lp->restart_task);
}
-/* Ethernet Rx Overflow interrupt */
-static irqreturn_t
-korina_ovr_interrupt(int irq, void *dev_id)
-{
- struct net_device *dev = dev_id;
- struct korina_private *lp = netdev_priv(dev);
- unsigned int ovr;
-
- spin_lock(&lp->lock);
- ovr = readl(&lp->eth_regs->ethintfc);
-
- if (ovr & ETH_INT_FC_OVR)
- korina_clear_and_restart(dev, ovr & ~ETH_INT_FC_OVR);
-
- spin_unlock(&lp->lock);
-
- return IRQ_HANDLED;
-}
-
#ifdef CONFIG_NET_POLL_CONTROLLER
static void korina_poll_controller(struct net_device *dev)
{
@@ -992,8 +939,7 @@ static int korina_open(struct net_device *dev)
}
/* Install the interrupt handler
- * that handles the Done Finished
- * Ovr and Und Events */
+ * that handles the Done Finished */
ret = request_irq(lp->rx_irq, korina_rx_dma_interrupt,
0, "Korina ethernet Rx", dev);
if (ret < 0) {
@@ -1009,31 +955,10 @@ static int korina_open(struct net_device *dev)
goto err_free_rx_irq;
}
- /* Install handler for overrun error. */
- ret = request_irq(lp->ovr_irq, korina_ovr_interrupt,
- 0, "Ethernet Overflow", dev);
- if (ret < 0) {
- printk(KERN_ERR "%s: unable to get OVR IRQ %d\n",
- dev->name, lp->ovr_irq);
- goto err_free_tx_irq;
- }
-
- /* Install handler for underflow error. */
- ret = request_irq(lp->und_irq, korina_und_interrupt,
- 0, "Ethernet Underflow", dev);
- if (ret < 0) {
- printk(KERN_ERR "%s: unable to get UND IRQ %d\n",
- dev->name, lp->und_irq);
- goto err_free_ovr_irq;
- }
mod_timer(&lp->media_check_timer, jiffies + 1);
out:
return ret;
-err_free_ovr_irq:
- free_irq(lp->ovr_irq, dev);
-err_free_tx_irq:
- free_irq(lp->tx_irq, dev);
err_free_rx_irq:
free_irq(lp->rx_irq, dev);
err_release:
@@ -1051,8 +976,6 @@ static int korina_close(struct net_device *dev)
/* Disable interrupts */
disable_irq(lp->rx_irq);
disable_irq(lp->tx_irq);
- disable_irq(lp->ovr_irq);
- disable_irq(lp->und_irq);
korina_abort_tx(dev);
tmp = readl(&lp->tx_dma_regs->dmasm);
@@ -1072,8 +995,6 @@ static int korina_close(struct net_device *dev)
free_irq(lp->rx_irq, dev);
free_irq(lp->tx_irq, dev);
- free_irq(lp->ovr_irq, dev);
- free_irq(lp->und_irq, dev);
return 0;
}
@@ -1112,8 +1033,6 @@ static int korina_probe(struct platform_device *pdev)
lp->rx_irq = platform_get_irq_byname(pdev, "korina_rx");
lp->tx_irq = platform_get_irq_byname(pdev, "korina_tx");
- lp->ovr_irq = platform_get_irq_byname(pdev, "korina_ovr");
- lp->und_irq = platform_get_irq_byname(pdev, "korina_und");
r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "korina_regs");
dev->base_addr = r->start;
--
2.7.4
^ permalink raw reply related
* [net, 2/6] net: korina: define NAPI_WEIGHT
From: Roman Yeryomin @ 2017-01-17 17:32 UTC (permalink / raw)
To: netdev
Signed-off-by: Roman Yeryomin <roman@advem.lv>
---
drivers/net/ethernet/korina.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/korina.c b/drivers/net/ethernet/korina.c
index 9bc375d..45bd617 100644
--- a/drivers/net/ethernet/korina.c
+++ b/drivers/net/ethernet/korina.c
@@ -77,6 +77,8 @@
#define MII_CLOCK 1250000 /* no more than 2.5MHz */
+#define NAPI_WEIGHT 64
+
/* the following must be powers of two */
#define KORINA_NUM_RDS 64 /* number of receive descriptors */
#define KORINA_NUM_TDS 64 /* number of transmit descriptors */
@@ -1080,7 +1082,7 @@ static int korina_probe(struct platform_device *pdev)
dev->netdev_ops = &korina_netdev_ops;
dev->ethtool_ops = &netdev_ethtool_ops;
dev->watchdog_timeo = TX_TIMEOUT;
- netif_napi_add(dev, &lp->napi, korina_poll, 64);
+ netif_napi_add(dev, &lp->napi, korina_poll, NAPI_WEIGHT);
lp->phy_addr = (((lp->rx_irq == 0x2c? 1:0) << 8) | 0x05);
lp->mii_if.dev = dev;
--
2.7.4
^ permalink raw reply related
* [net, 4/6] net: korina: whitespace styling cleanup
From: Roman Yeryomin @ 2017-01-17 17:32 UTC (permalink / raw)
To: netdev
Signed-off-by: Roman Yeryomin <roman@advem.lv>
---
drivers/net/ethernet/korina.c | 54 +++++++++++++++++++++++--------------------
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/korina.c b/drivers/net/ethernet/korina.c
index 02f2364..afa440c 100644
--- a/drivers/net/ethernet/korina.c
+++ b/drivers/net/ethernet/korina.c
@@ -64,9 +64,9 @@
#include <asm/mach-rc32434/eth.h>
#include <asm/mach-rc32434/dma_v.h>
-#define DRV_NAME "korina"
-#define DRV_VERSION "0.10"
-#define DRV_RELDATE "04Mar2008"
+#define DRV_NAME "korina"
+#define DRV_VERSION "0.10"
+#define DRV_RELDATE "04Mar2008"
#define STATION_ADDRESS_HIGH(dev) (((dev)->dev_addr[0] << 8) | \
((dev)->dev_addr[1]))
@@ -75,7 +75,7 @@
((dev)->dev_addr[4] << 8) | \
((dev)->dev_addr[5]))
-#define MII_CLOCK 1250000 /* no more than 2.5MHz */
+#define MII_CLOCK 1250000 /* no more than 2.5MHz */
#define NAPI_WEIGHT 64
@@ -94,10 +94,14 @@
#define TX_TIMEOUT (6000 * HZ / 1000)
-enum chain_status { desc_filled, desc_empty };
-#define IS_DMA_FINISHED(X) (((X) & (DMA_DESC_FINI)) != 0)
-#define IS_DMA_DONE(X) (((X) & (DMA_DESC_DONE)) != 0)
-#define RCVPKT_LENGTH(X) (((X) & ETH_RX_LEN) >> ETH_RX_LEN_BIT)
+enum chain_status {
+ desc_filled,
+ desc_empty
+};
+
+#define IS_DMA_FINISHED(X) (((X) & (DMA_DESC_FINI)) != 0)
+#define IS_DMA_DONE(X) (((X) & (DMA_DESC_DONE)) != 0)
+#define RCVPKT_LENGTH(X) (((X) & ETH_RX_LEN) >> ETH_RX_LEN_BIT)
/* Information that need to be kept for each board. */
struct korina_private {
@@ -125,7 +129,7 @@ struct korina_private {
int rx_irq;
int tx_irq;
- spinlock_t lock; /* NIC xmit lock */
+ spinlock_t lock; /* NIC xmit lock */
int dma_halt_cnt;
int dma_run_cnt;
@@ -148,17 +152,17 @@ static inline void korina_start_dma(struct dma_reg *ch, u32 dma_addr)
static inline void korina_abort_dma(struct net_device *dev,
struct dma_reg *ch)
{
- if (readl(&ch->dmac) & DMA_CHAN_RUN_BIT) {
- writel(0x10, &ch->dmac);
+ if (readl(&ch->dmac) & DMA_CHAN_RUN_BIT) {
+ writel(0x10, &ch->dmac);
- while (!(readl(&ch->dmas) & DMA_STAT_HALT))
- netif_trans_update(dev);
+ while (!(readl(&ch->dmas) & DMA_STAT_HALT))
+ netif_trans_update(dev);
- writel(0, &ch->dmas);
- }
+ writel(0, &ch->dmas);
+ }
- writel(0, &ch->dmadptr);
- writel(0, &ch->dmandptr);
+ writel(0, &ch->dmadptr);
+ writel(0, &ch->dmandptr);
}
static inline void korina_chain_dma(struct dma_reg *ch, u32 dma_addr)
@@ -686,7 +690,7 @@ static int korina_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
/* ethtool helpers */
static void netdev_get_drvinfo(struct net_device *dev,
- struct ethtool_drvinfo *info)
+ struct ethtool_drvinfo *info)
{
struct korina_private *lp = netdev_priv(dev);
@@ -728,10 +732,10 @@ static u32 netdev_get_link(struct net_device *dev)
}
static const struct ethtool_ops netdev_ethtool_ops = {
- .get_drvinfo = netdev_get_drvinfo,
- .get_settings = netdev_get_settings,
- .set_settings = netdev_set_settings,
- .get_link = netdev_get_link,
+ .get_drvinfo = netdev_get_drvinfo,
+ .get_settings = netdev_get_settings,
+ .set_settings = netdev_set_settings,
+ .get_link = netdev_get_link,
};
static int korina_alloc_ring(struct net_device *dev)
@@ -863,7 +867,7 @@ static int korina_init(struct net_device *dev)
/* Management Clock Prescaler Divisor
* Clock independent setting */
writel(((idt_cpu_freq) / MII_CLOCK + 1) & ~1,
- &lp->eth_regs->ethmcp);
+ &lp->eth_regs->ethmcp);
/* don't transmit until fifo contains 48b */
writel(48, &lp->eth_regs->ethfifott);
@@ -946,14 +950,14 @@ static int korina_open(struct net_device *dev)
0, "Korina ethernet Rx", dev);
if (ret < 0) {
printk(KERN_ERR "%s: unable to get Rx DMA IRQ %d\n",
- dev->name, lp->rx_irq);
+ dev->name, lp->rx_irq);
goto err_release;
}
ret = request_irq(lp->tx_irq, korina_tx_dma_interrupt,
0, "Korina ethernet Tx", dev);
if (ret < 0) {
printk(KERN_ERR "%s: unable to get Tx DMA IRQ %d\n",
- dev->name, lp->tx_irq);
+ dev->name, lp->tx_irq);
goto err_free_rx_irq;
}
--
2.7.4
^ permalink raw reply related
* Kernel 4.6.7-rt14 kernel workqueue lockup - rtnl deadlock plus syscall endless loop
From: Elad Nachman @ 2017-01-17 17:39 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi,
I am experiencing sporadic work queue lockups on kernel 4.6.7-rt14 (mach-socfpga).
Using a HW debugger I got the following information:
A process containing a network namespace is terminating itself (SIGKILL), which causes cleanup_net() to be scheduled to kworker/u4:2 to clean up the network namespace running on the process.
Kworker/u4:2 got preempted (plus there are a lot of other work queue items, like vmstat_shepherd, wakeup_dirtytime_writeback, phy_state_machine, neigh_periodic_work, check_lifetime plus another one by a LKM) while holding the rtnl lock.
A processing running waitpid() on the terminated process starts a new process, which forks busybox to run sysctl -w net.ipv6.conf.all.forwarding = 1 .
This in turn starts making a write syscall, calling in turn vfs_write, proc_sys_call_handler, addrconf_sysctl_forward, and finally addrconf_fixup_forwarding().
addrconf_fixup_forwarding() runs the following code:
if (!rtnl_trylock())
return restart_syscall();
This fails and restart_syscall() does the following:
set_tsk_thread_flag(current, TIF_SIGPENDING);
return -ERESTARTNOINTR;
Now the system call goes back to ret_fast_syscall (arch/arm/kernel/entry-common.S)
Testing the flags in the task_struct (which contain TIF_SIGPENDING) the code branches to fast_work_pending, then falls through to slow_work_pending, which
Calls do_work_pending(), and in turn calls do_signal(), get_signal(), dequeuer_signal(), which find no signals, and clears the TIF_SIGPENDING bit when recalc_sigpending() is called, then returns zero.
This causes do_signal() to examine r0 and return 1 (-ERESTARTNOINTR), which is propogated to the assembly code by do_work_pending().
Having r0 equal zero causes a branch to local_restart, which restarts the very same write system call in an endless loop.
No scheduling is possible, so the cleanup_net() cannot finish and release rtnl, which in turn causes the endless restarting of the write system call.
I have sent this to linux-arm-kernel and got a response from Russel King saying that (relating to addrconf_fixup_forwarding, net/ipv6/addrconf.c ):
"
I think the problem is that:
if (!rtnl_trylock())
return restart_syscall();
which, if it didn't do a trylock, it would put this thread to sleep
and allow other threads to run (potentially allowing the holder of
the lock to release it.)
What's more odd about this is that it's very unusual and strange for
a kernel function to invoke the restart mechanism because a lock is
being held - the point of the restart mechanism is to allow userspace
signal handlers to run, so it should only be used when there's a
signal pending. I think this is a hack in the IPv6 code to work
around some other issue.
"
Any reason we cannot change the above two lines to rtnl_lock() ?
Thanks,
Elad.
IMPORTANT - This email and any attachments is intended for the above named addressee(s), and may contain information which is confidential or privileged. If you are not the intended recipient, please inform the sender immediately and delete this email: you should not copy or use this e-mail for any purpose nor disclose its contents to any person.
^ permalink raw reply
* [net, 5/6] net: korina: update authors
From: Roman Yeryomin @ 2017-01-17 17:33 UTC (permalink / raw)
To: netdev
Signed-off-by: Roman Yeryomin <roman@advem.lv>
---
drivers/net/ethernet/korina.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/korina.c b/drivers/net/ethernet/korina.c
index afa440c..83c994f 100644
--- a/drivers/net/ethernet/korina.c
+++ b/drivers/net/ethernet/korina.c
@@ -4,6 +4,7 @@
* Copyright 2004 IDT Inc. (rischelp@idt.com)
* Copyright 2006 Felix Fietkau <nbd@openwrt.org>
* Copyright 2008 Florian Fainelli <florian@openwrt.org>
+ * Copyright 2017 Roman Yeryomin <roman@advem.lv>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -1150,5 +1151,6 @@ module_platform_driver(korina_driver);
MODULE_AUTHOR("Philip Rischel <rischelp@idt.com>");
MODULE_AUTHOR("Felix Fietkau <nbd@openwrt.org>");
MODULE_AUTHOR("Florian Fainelli <florian@openwrt.org>");
+MODULE_AUTHOR("Roman Yeryomin <roman@advem.lv>");
MODULE_DESCRIPTION("IDT RC32434 (Korina) Ethernet driver");
MODULE_LICENSE("GPL");
--
2.7.4
^ permalink raw reply related
* Re: [net, 2/6] net: korina: define NAPI_WEIGHT
From: David Miller @ 2017-01-17 17:40 UTC (permalink / raw)
To: leroi.lists; +Cc: netdev
In-Reply-To: <1484674342-22304-1-git-send-email-roman@advem.lv>
From: Roman Yeryomin <leroi.lists@gmail.com>
Date: Tue, 17 Jan 2017 19:32:22 +0200
> @@ -77,6 +77,8 @@
>
> #define MII_CLOCK 1250000 /* no more than 2.5MHz */
>
> +#define NAPI_WEIGHT 64
> +
> /* the following must be powers of two */
> #define KORINA_NUM_RDS 64 /* number of receive descriptors */
> #define KORINA_NUM_TDS 64 /* number of transmit descriptors */
> @@ -1080,7 +1082,7 @@ static int korina_probe(struct platform_device *pdev)
> dev->netdev_ops = &korina_netdev_ops;
> dev->ethtool_ops = &netdev_ethtool_ops;
> dev->watchdog_timeo = TX_TIMEOUT;
> - netif_napi_add(dev, &lp->napi, korina_poll, 64);
> + netif_napi_add(dev, &lp->napi, korina_poll, NAPI_WEIGHT);
Please use NAPI_POLL_WEIGHT from linux/netdevice.h
^ permalink raw reply
* [net, 3/6] net: korina: increase tx/rx ring sizes
From: Roman Yeryomin @ 2017-01-17 17:32 UTC (permalink / raw)
To: netdev
Having larger ring sizes almost eliminates rx fifo overflow, thus improving performance.
This patch reduces rx overflow occurence by approximately 1000 times (from ~25k down to ~25 times per 3M frames)
Signed-off-by: Roman Yeryomin <roman@advem.lv>
---
drivers/net/ethernet/korina.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/korina.c b/drivers/net/ethernet/korina.c
index 45bd617..02f2364 100644
--- a/drivers/net/ethernet/korina.c
+++ b/drivers/net/ethernet/korina.c
@@ -80,8 +80,8 @@
#define NAPI_WEIGHT 64
/* the following must be powers of two */
-#define KORINA_NUM_RDS 64 /* number of receive descriptors */
-#define KORINA_NUM_TDS 64 /* number of transmit descriptors */
+#define KORINA_NUM_RDS 256 /* number of receive descriptors */
+#define KORINA_NUM_TDS 256 /* number of transmit descriptors */
/* KORINA_RBSIZE is the hardware's default maximum receive
* frame size in bytes. Having this hardcoded means that there
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] net: ethernet: stmmac: add ARP management
From: Florian Fainelli @ 2017-01-17 17:41 UTC (permalink / raw)
To: Andrew Lunn, Christophe Roullier
Cc: Alexandre Torgue, Giuseppe Cavallaro, netdev, linux-kernel
In-Reply-To: <20170117172541.GC9470@lunn.ch>
On 01/17/2017 09:25 AM, Andrew Lunn wrote:
> On Tue, Jan 17, 2017 at 05:56:40PM +0100, Christophe Roullier wrote:
>> DWC_ether_qos supports the Address Recognition
>
> Resolution not Recognition?
>
>> Protocol (ARP) Offload for IPv4 packets. This feature
>> allows the processing of the IPv4 ARP request packet
>> in the receive path and generating corresponding ARP
>> response packet in the transmit path. DWC_ether_qos
>> generates the ARP reply packets for appropriate ARP
>> request packets.
>
> What about when .ndo_set_mac_address is called?
Was wondering about the same thing, but presumably, if there is correct
programming of the MAC address into the appropriate MAC address
registers, one could expect the hardware to latch that value while
generating the ARP replies?
While it sounds like this feature may be useful under heavy ARP spoofing
workloads, in practice, ARP packets are both small and infrequent, so
this sounds like micro optimization.
--
Florian
^ permalink raw reply
* [net, 6/6] net: korina: version bump
From: Roman Yeryomin @ 2017-01-17 17:33 UTC (permalink / raw)
To: netdev
Signed-off-by: Roman Yeryomin <roman@advem.lv>
---
drivers/net/ethernet/korina.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/korina.c b/drivers/net/ethernet/korina.c
index 83c994f..c8fed01 100644
--- a/drivers/net/ethernet/korina.c
+++ b/drivers/net/ethernet/korina.c
@@ -66,8 +66,8 @@
#include <asm/mach-rc32434/dma_v.h>
#define DRV_NAME "korina"
-#define DRV_VERSION "0.10"
-#define DRV_RELDATE "04Mar2008"
+#define DRV_VERSION "0.20"
+#define DRV_RELDATE "15Jan2017"
#define STATION_ADDRESS_HIGH(dev) (((dev)->dev_addr[0] << 8) | \
((dev)->dev_addr[1]))
--
2.7.4
^ permalink raw reply related
* Re: Kernel 4.6.7-rt14 kernel workqueue lockup - rtnl deadlock plus syscall endless loop
From: David Miller @ 2017-01-17 17:57 UTC (permalink / raw)
To: EladN; +Cc: netdev
In-Reply-To: <AM5PR0701MB187338B2418A19E1B4B55C98A07C0@AM5PR0701MB1873.eurprd07.prod.outlook.com>
From: Elad Nachman <EladN@gilat.com>
Date: Tue, 17 Jan 2017 17:39:03 +0000
> What's more odd about this is that it's very unusual and strange for
> a kernel function to invoke the restart mechanism because a lock is
> being held - the point of the restart mechanism is to allow userspace
> signal handlers to run, so it should only be used when there's a
> signal pending. I think this is a hack in the IPv6 code to work
> around some other issue.
It's not unusal at all, if you actually grep for this under net/ you will
see that it is in fact a common code pattern.
It prevents deadlocks because the sysfs and other nodes that we are
operating with can be unregistered by other threads of control holding
the RTNL mutex. If we don't break out, we won't release our reference
and therefore the RTNL mutex holding entity cannot make forward
progress.
This behavior is therefore very much intentional.
^ permalink raw reply
* Re: [net, 3/6] net: korina: increase tx/rx ring sizes
From: David Miller @ 2017-01-17 17:58 UTC (permalink / raw)
To: leroi.lists; +Cc: netdev
In-Reply-To: <1484674356-22363-1-git-send-email-roman@advem.lv>
From: Roman Yeryomin <leroi.lists@gmail.com>
Date: Tue, 17 Jan 2017 19:32:36 +0200
> Having larger ring sizes almost eliminates rx fifo overflow, thus improving performance.
> This patch reduces rx overflow occurence by approximately 1000 times (from ~25k down to ~25 times per 3M frames)
Those numbers don't mean much without full context.
What kind of system, what kind of traffic, and over what kind of link?
^ permalink raw reply
* Re: Kernel 4.6.7-rt14 kernel workqueue lockup - rtnl deadlock plus syscall endless loop
From: Stephen Hemminger @ 2017-01-17 17:53 UTC (permalink / raw)
To: Elad Nachman; +Cc: netdev@vger.kernel.org
In-Reply-To: <AM5PR0701MB187338B2418A19E1B4B55C98A07C0@AM5PR0701MB1873.eurprd07.prod.outlook.com>
On Tue, 17 Jan 2017 17:39:03 +0000
Elad Nachman <EladN@gilat.com> wrote:
> Hi,
>
> I am experiencing sporadic work queue lockups on kernel 4.6.7-rt14 (mach-socfpga).
>
> Using a HW debugger I got the following information:
>
> A process containing a network namespace is terminating itself (SIGKILL), which causes cleanup_net() to be scheduled to kworker/u4:2 to clean up the network namespace running on the process.
>
> Kworker/u4:2 got preempted (plus there are a lot of other work queue items, like vmstat_shepherd, wakeup_dirtytime_writeback, phy_state_machine, neigh_periodic_work, check_lifetime plus another one by a LKM) while holding the rtnl lock.
>
> A processing running waitpid() on the terminated process starts a new process, which forks busybox to run sysctl -w net.ipv6.conf.all.forwarding = 1 .
> This in turn starts making a write syscall, calling in turn vfs_write, proc_sys_call_handler, addrconf_sysctl_forward, and finally addrconf_fixup_forwarding().
>
> addrconf_fixup_forwarding() runs the following code:
>
> if (!rtnl_trylock())
> return restart_syscall();
>
> This fails and restart_syscall() does the following:
>
> set_tsk_thread_flag(current, TIF_SIGPENDING);
> return -ERESTARTNOINTR;
>
> Now the system call goes back to ret_fast_syscall (arch/arm/kernel/entry-common.S)
> Testing the flags in the task_struct (which contain TIF_SIGPENDING) the code branches to fast_work_pending, then falls through to slow_work_pending, which
> Calls do_work_pending(), and in turn calls do_signal(), get_signal(), dequeuer_signal(), which find no signals, and clears the TIF_SIGPENDING bit when recalc_sigpending() is called, then returns zero.
>
> This causes do_signal() to examine r0 and return 1 (-ERESTARTNOINTR), which is propogated to the assembly code by do_work_pending().
> Having r0 equal zero causes a branch to local_restart, which restarts the very same write system call in an endless loop.
> No scheduling is possible, so the cleanup_net() cannot finish and release rtnl, which in turn causes the endless restarting of the write system call.
>
> I have sent this to linux-arm-kernel and got a response from Russel King saying that (relating to addrconf_fixup_forwarding, net/ipv6/addrconf.c ):
>
> "
> I think the problem is that:
>
> if (!rtnl_trylock())
> return restart_syscall();
>
>
>
> which, if it didn't do a trylock, it would put this thread to sleep
> and allow other threads to run (potentially allowing the holder of
> the lock to release it.)
>
> What's more odd about this is that it's very unusual and strange for
> a kernel function to invoke the restart mechanism because a lock is
> being held - the point of the restart mechanism is to allow userspace
> signal handlers to run, so it should only be used when there's a
> signal pending. I think this is a hack in the IPv6 code to work
> around some other issue.
The trylock was added intentionally to handle a different deadlock.
Going back to a blocking lock would cause that problem.
There was a deadlock between device unregistration and sysfs access.
Unregistration wants to remove sysfs entry while holding RTNL.
Sysfs access graps sysfs file entry lock then acquires RTNL.
The patch back in 2.6.30 followed by multiple revisions was to
restart the sysfs write syscall.
^ permalink raw reply
* Re: [PATCH net] lwtunnel: fix autoload of lwt modules
From: David Ahern @ 2017-01-17 18:04 UTC (permalink / raw)
To: Robert Shearman, netdev, roopa
In-Reply-To: <0e226af4-cb62-9b20-f8a2-191b0aaffb11@brocade.com>
On 1/17/17 10:26 AM, Robert Shearman wrote:
> Ok, I'll continue looking too and let you know if there's anything else that pops up.
>
> Having said that, even if we eliminate all the unreferenced objects in the current code, what are the chances that we'll be able to keep it this way going forward? Perhaps it would be safer to retry the insert operation from as close to the start as possible?
handling restart for all code paths seems a bit risky for 4.10. Perhaps then the best course for 4.10 and older stable releases is to remove the autoload code from lwtunnel. It can be re-added once the recovery path is handled.
^ permalink raw reply
* [PATCH] virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on xmit
From: Rolf Neugebauer @ 2017-01-17 18:13 UTC (permalink / raw)
To: netdev; +Cc: mst, davem, jasowang, rppt, Rolf Neugebauer
This patch part reverts fd2a0437dc33 and e858fae2b0b8 which introduced a
subtle change in how the virtio_net flags are derived from the SKBs
ip_summed field.
With the above commits, the flags are set to VIRTIO_NET_HDR_F_DATA_VALID
when ip_summed == CHECKSUM_UNNECESSARY, thus treating it differently to
ip_summed == CHECKSUM_NONE, which should be the same.
Further, the virtio spec 1.0 / CS04 explicitly says that
VIRTIO_NET_HDR_F_DATA_VALID must not be set by the driver.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
---
include/linux/virtio_net.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 66204007d7ac..56436472ccc7 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -91,8 +91,6 @@ static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
skb_checksum_start_offset(skb));
hdr->csum_offset = __cpu_to_virtio16(little_endian,
skb->csum_offset);
- } else if (skb->ip_summed == CHECKSUM_UNNECESSARY) {
- hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
} /* else everything is zero */
return 0;
--
2.11.0
^ permalink raw reply related
* RE: Kernel 4.6.7-rt14 kernel workqueue lockup - rtnl deadlock plus syscall endless loop
From: Elad Nachman @ 2017-01-17 18:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20170117.125748.122599514616047216.davem@davemloft.net>
Any thought about limiting the amount of busy polling?
Say if more than X polls are done within a jiffy, then at least for preemptable kernels you can sleep for a jiffy inside the syscall to yield the CPU for a while?
Thanks,
Elad.
-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: יום ג 17 ינואר 2017 19:58
To: Elad Nachman <EladN@gilat.com>
Cc: netdev@vger.kernel.org
Subject: Re: Kernel 4.6.7-rt14 kernel workqueue lockup - rtnl deadlock plus syscall endless loop
From: Elad Nachman <EladN@gilat.com>
Date: Tue, 17 Jan 2017 17:39:03 +0000
> What's more odd about this is that it's very unusual and strange for a
> kernel function to invoke the restart mechanism because a lock is
> being held - the point of the restart mechanism is to allow userspace
> signal handlers to run, so it should only be used when there's a
> signal pending. I think this is a hack in the IPv6 code to work around
> some other issue.
It's not unusal at all, if you actually grep for this under net/ you will see that it is in fact a common code pattern.
It prevents deadlocks because the sysfs and other nodes that we are operating with can be unregistered by other threads of control holding the RTNL mutex. If we don't break out, we won't release our reference and therefore the RTNL mutex holding entity cannot make forward progress.
This behavior is therefore very much intentional.
IMPORTANT - This email and any attachments is intended for the above named addressee(s), and may contain information which is confidential or privileged. If you are not the intended recipient, please inform the sender immediately and delete this email: you should not copy or use this e-mail for any purpose nor disclose its contents to any person.
^ permalink raw reply
* Re: [PATCH] bpf: Fix test_lru_sanity5() in test_lru_map.c
From: Alexei Starovoitov @ 2017-01-17 18:16 UTC (permalink / raw)
To: Daniel Borkmann, Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, Kernel Team
In-Reply-To: <587DDED4.5060706@iogearbox.net>
On 1/17/17 1:07 AM, Daniel Borkmann wrote:
> On 01/17/2017 07:17 AM, Martin KaFai Lau wrote:
>> test_lru_sanity5() fails when the number of online cpus
>> is fewer than the number of possible cpus. It can be
>> reproduced with qemu by using cmd args "--smp cpus=2,maxcpus=8".
>>
>> The problem is the loop in test_lru_sanity5() is testing
>> 'i' which is incorrect.
>>
>> This patch:
>> 1. Make sched_next_online() always return -1 if it cannot
>> find a next cpu to schedule the process.
>> 2. In test_lru_sanity5(), the parent process does
>> sched_setaffinity() first (through sched_next_online())
>> and the forked process will inherit it according to
>> the 'man sched_setaffinity'.
>>
>> Fixes: 5db58faf989f ("bpf: Add tests for the LRU bpf_htab")
>> Reported-by: Daniel Borkmann <daniel@iogearbox.net>
>> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
>
> Looks good, thanks for fixing!
>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
>
> (Patch is against -net tree.)
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ 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