* Re: [PATCH rdma-next 0/3] Dump and fill MKEY
From: Jason Gunthorpe @ 2018-07-04 17:47 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Guy Levi,
Yishai Hadas, Yonatan Cohen, Saeed Mahameed, linux-netdev
In-Reply-To: <20180619054724.32677-1-leon@kernel.org>
On Tue, Jun 19, 2018 at 08:47:21AM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> MLX5 IB HCA offers the memory key, dump_fill_mkey to increase
> performance, when used in a send or receive operations.
>
> It is used to force local HCA operations to skip the PCI bus access,
> while keeping track of the processed length in the ibv_sge handling.
>
> In this three patch series, we expose various bits in our HW
> spec file (mlx5_ifc.h), move unneeded for mlx5_core FW command and
> export such memory key to user space thought our mlx5-abi header file.
>
> Thanks
This looks fine, can you send a pull request off the mlx5 branch
please?
Thanks,
Jason
^ permalink raw reply
* Re: [PATCHv2 net-next 2/2] selftests: add a selftest for directed broadcast forwarding
From: Xin Long @ 2018-07-04 17:56 UTC (permalink / raw)
To: David Ahern; +Cc: network dev, davem, Davide Caratti, Ido Schimmel
In-Reply-To: <5e5f7edf-1313-cfef-9005-b05ec9051b25@gmail.com>
On Wed, Jul 4, 2018 at 3:23 AM, David Ahern <dsahern@gmail.com> wrote:
> On 7/3/18 5:36 AM, Xin Long wrote:
>> On Mon, Jul 2, 2018 at 11:12 PM, David Ahern <dsahern@gmail.com> wrote:
>>> On 7/2/18 12:30 AM, Xin Long wrote:
>>>> +ping_ipv4()
>>>> +{
>>>> + sysctl_set net.ipv4.icmp_echo_ignore_broadcasts 0
>>>> + bc_forwarding_disable
>>>> + ping_test $h1 198.51.100.255
>>>> +
>>>> + iptables -A INPUT -i vrf-r1 -p icmp -j DROP
>>>> + bc_forwarding_restore
>>>> + bc_forwarding_enable
>>>> + ping_test $h1 198.51.100.255
>>>> +
>>>> + bc_forwarding_restore
>>>> + iptables -D INPUT -i vrf-r1 -p icmp -j DROP
>>>> + sysctl_restore net.ipv4.icmp_echo_ignore_broadcasts
>>>> +}
>>>
>>> Both tests fail for me:
>>> TEST: ping [FAIL]
>>> TEST: ping [FAIL]
>> I think 'ip vrf exec ...' is not working in your env, while
>> the testing is using "ip vrf exec vrf-h1 ping ..."
>>
>> You can test it by:
>> # ip link add dev vrf-test type vrf table 1111
>> # ip vrf exec vrf-test ls
>
> well, that's embarrassing. yes, I updated ip and forgot to apply the bpf
> workaround to define the syscall number (not defined in jessie).
>
>>
>>>
>>> Why the need for the iptables rule?
>> This iptables rule is to block the echo_request packet going to
>> route's local_in.
>> When bc_forwarding is NOT doing forwarding well but the packet
>> goes to the route's local_in, it will fail.
>>
>> Without this rule, the 2nd ping will always succeed, we can't tell the
>> echo_reply is from route or h2.
>>
>> Or you have a better way to test this?
>
> your commands are not a proper test. The test should succeed and fail
> based on the routing lookup, not iptables rules.
A proper test can be done easily with netns, as vrf can't isolate much.
I don't want to bother forwarding/ directory with netns, so I will probably
just drop this selftest, and let the feature patch go first.
What do you think?
>
>>
>>>
>>> And, PAUSE_ON_FAIL is not working to take a look at why tests are
>>> failing. e.g.,
>>>
>>> PAUSE_ON_FAIL=yes ./router_broadcast.sh
>>>
>>> just continues on. Might be something with the infrastructure scripts.
>> Yes, in ./router_broadcast.sh, it loads lib.sh where it loads forwarding.config
>> where it has "PAUSE_ON_FAIL=no", which would override your
>> "PAUSE_ON_FAIL=yes".
>>
>
> ack. bit by that as well.
^ permalink raw reply
* Re: [PATCH net-next 08/10] r8169: remove rtl8169_set_speed_xmii
From: Heiner Kallweit @ 2018-07-04 18:13 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Miller, Florian Fainelli, Realtek linux nic maintainers,
netdev@vger.kernel.org
In-Reply-To: <20180704144617.GF12405@lunn.ch>
On 04.07.2018 16:46, Andrew Lunn wrote:
> On Mon, Jul 02, 2018 at 11:54:54PM +0200, Heiner Kallweit wrote:
>> On 02.07.2018 23:21, Andrew Lunn wrote:
>>>> - auto_nego |= ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM;
>>>
>>> This bit you probably want to keep. The PHY never says it support
>>> Pause. The MAC needs to enable pause if the MAC supports pause.
>>>
>> Actually I assumed that phylib would do this for me. But:
>> In phy_probe() first phydev->supported is copied to
>> phydev->advertising, and only after this both pause flags are added
>> to phydev->supported. Therefore I think they are not advertised.
>> Is this intentional? It sounds a little weird to me to add the
>> pause flags to the supported features per default, but not
>> advertise them.
>
> phylib has no idea if the MAC supports Pause. So it should not enable
> it by default. The MAC needs to enable it. And a lot of MAC drivers
> get this wrong...
>
>> Except e.g. we call by chance phy_set_max_speed(), which copies
>> phydev->supported to phydev->advertising after having adjusted
>> the supported speeds.
>
> As you correctly pointed out, phy_set_max_speed() is masking out too
> much.
>
>> If this is not a bug, then where would be the right place to add
>> the pause flags to phydev->advertising?
>
> Before you call phy_start().
>
Thanks for the clarification. I think beginning of next week I can
provide a v2 of the patch series.
Heiner
> Andrew
>
^ permalink raw reply
* [PATCH net-next] net: ipv4: fix drop handling in ip_list_rcv() and ip_list_rcv_finish()
From: Edward Cree @ 2018-07-04 18:23 UTC (permalink / raw)
To: davem; +Cc: netdev
Since callees (ip_rcv_core() and ip_rcv_finish_core()) might free or steal
the skb, we can't use the list_cut_before() method; we can't even do a
list_del(&skb->list) in the drop case, because skb might have already been
freed and reused.
So instead, take each skb off the source list before processing, and add it
to the sublist afterwards if it wasn't freed or stolen.
Fixes: 5fa12739a53d net: ipv4: listify ip_rcv_finish
Fixes: 17266ee93984 net: ipv4: listified version of ip_rcv
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
net/ipv4/ip_input.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 24b9b0210aeb..14ba628b2761 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -540,24 +540,27 @@ static void ip_list_rcv_finish(struct net *net, struct sock *sk,
struct sk_buff *skb, *next;
struct list_head sublist;
+ INIT_LIST_HEAD(&sublist);
list_for_each_entry_safe(skb, next, head, list) {
struct dst_entry *dst;
+ list_del(&skb->list);
if (ip_rcv_finish_core(net, sk, skb) == NET_RX_DROP)
continue;
dst = skb_dst(skb);
if (curr_dst != dst) {
/* dispatch old sublist */
- list_cut_before(&sublist, head, &skb->list);
if (!list_empty(&sublist))
ip_sublist_rcv_finish(&sublist);
/* start new sublist */
+ INIT_LIST_HEAD(&sublist);
curr_dst = dst;
}
+ list_add_tail(&skb->list, &sublist);
}
/* dispatch final sublist */
- ip_sublist_rcv_finish(head);
+ ip_sublist_rcv_finish(&sublist);
}
static void ip_sublist_rcv(struct list_head *head, struct net_device *dev,
@@ -577,24 +580,27 @@ void ip_list_rcv(struct list_head *head, struct packet_type *pt,
struct sk_buff *skb, *next;
struct list_head sublist;
+ INIT_LIST_HEAD(&sublist);
list_for_each_entry_safe(skb, next, head, list) {
struct net_device *dev = skb->dev;
struct net *net = dev_net(dev);
+ list_del(&skb->list);
skb = ip_rcv_core(skb, net);
if (skb == NULL)
continue;
if (curr_dev != dev || curr_net != net) {
/* dispatch old sublist */
- list_cut_before(&sublist, head, &skb->list);
if (!list_empty(&sublist))
- ip_sublist_rcv(&sublist, dev, net);
+ ip_sublist_rcv(&sublist, curr_dev, curr_net);
/* start new sublist */
+ INIT_LIST_HEAD(&sublist);
curr_dev = dev;
curr_net = net;
}
+ list_add_tail(&skb->list, &sublist);
}
/* dispatch final sublist */
- ip_sublist_rcv(head, curr_dev, curr_net);
+ ip_sublist_rcv(&sublist, curr_dev, curr_net);
}
^ permalink raw reply related
* Re: [RFC net-next 00/15] net: A socket API for LoRa
From: Stefan Schmidt @ 2018-07-04 18:26 UTC (permalink / raw)
To: Andreas Färber, netdev
Cc: Michal Kubeček, Konstantin Böhm, contact, Ken Yu,
Michael Röder, Rob Herring, lora, Alexander Graf,
Jan Jongboom, Janus Piwek, Jon Ortego, Jian-Hong Pan, devicetree,
Jiri Pirko, Marcel Holtmann, Mark Brown, Dollar Chen, Brian Ray,
linux-arm-kernel, lora, Matthias Brugger, Ben Whitten,
linux-kernel, linux-spi
In-Reply-To: <20180701110804.32415-1-afaerber@suse.de>
Hello.
On 01.07.2018 13:07, Andreas Färber wrote:
>
> This patchset, updated from 2017 and extended, is implementing kernel drivers
> for various LoRa chipsets and modules.
I am very happy to see that we now have three people (you, Jian-Hong and
Ben) working towards a lora subsystem for protocol stack and drivers.
Will allocate some time to look over this and provide some review and
feedback how we handled things in the ieee802154 and 6lowpan subsystems.
We are also having a IoT protocols workshop during NetDev Conf next week
in Montreal (short notice if you are not already planning to attend). If
you (or Ben) has soem topics wanted to bring up their please let me know
by pm. Jian-Hong will be there presenting on his lora work and I would
love to get more input from you and Ben on your views on this.
https://netdevconf.org/0x12/session.html?workshop-on-iot-related-mac-layers-header-compression-and-routing-protocols
regards
Stefan Schmidt
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv2 net-next 2/2] selftests: add a selftest for directed broadcast forwarding
From: David Ahern @ 2018-07-04 18:31 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem, Davide Caratti, Ido Schimmel
In-Reply-To: <CADvbK_c6pdnHuKd_aDG3REWvGRx5AtGH2YO90tyRvcWesBDzPw@mail.gmail.com>
On 7/4/18 11:56 AM, Xin Long wrote:
> A proper test can be done easily with netns, as vrf can't isolate much.
> I don't want to bother forwarding/ directory with netns, so I will probably
> just drop this selftest, and let the feature patch go first.
>
> What do you think?
>
I think I would like to see a proper test case for this.
If it does not fit the model that Ido and others are using under the
forwarding directory, then how about one in tools/testing/selftests/net
then.
^ permalink raw reply
* [PATCH net-next 1/5 v2] net: gemini: Look up L3 maxlen from table
From: Linus Walleij @ 2018-07-04 18:33 UTC (permalink / raw)
To: netdev, David S . Miller, Michał Mirosław
Cc: Janos Laube, Paulius Zaleckas, linux-arm-kernel, Hans Ulli Kroll,
Florian Fainelli, Linus Walleij
The code to calculate the hardware register enumerator
for the maximum L3 length isn't entirely simple to read.
Use the existing defines and rewrite the function into a
table look-up.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- No changes, just resending with the rest.
---
drivers/net/ethernet/cortina/gemini.c | 61 ++++++++++++++++++++-------
1 file changed, 46 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c
index 6d7404f66f84..8fc31723f700 100644
--- a/drivers/net/ethernet/cortina/gemini.c
+++ b/drivers/net/ethernet/cortina/gemini.c
@@ -401,26 +401,57 @@ static int gmac_setup_phy(struct net_device *netdev)
return 0;
}
-static int gmac_pick_rx_max_len(int max_l3_len)
-{
- /* index = CONFIG_MAXLEN_XXX values */
- static const int max_len[8] = {
- 1536, 1518, 1522, 1542,
- 9212, 10236, 1518, 1518
- };
- int i, n = 5;
+/* The maximum frame length is not logically enumerated in the
+ * hardware, so we do a table lookup to find the applicable max
+ * frame length.
+ */
+struct gmac_max_framelen {
+ unsigned int max_l3_len;
+ u8 val;
+};
- max_l3_len += ETH_HLEN + VLAN_HLEN;
+static const struct gmac_max_framelen gmac_maxlens[] = {
+ {
+ .max_l3_len = 1518,
+ .val = CONFIG0_MAXLEN_1518,
+ },
+ {
+ .max_l3_len = 1522,
+ .val = CONFIG0_MAXLEN_1522,
+ },
+ {
+ .max_l3_len = 1536,
+ .val = CONFIG0_MAXLEN_1536,
+ },
+ {
+ .max_l3_len = 1542,
+ .val = CONFIG0_MAXLEN_1542,
+ },
+ {
+ .max_l3_len = 9212,
+ .val = CONFIG0_MAXLEN_9k,
+ },
+ {
+ .max_l3_len = 10236,
+ .val = CONFIG0_MAXLEN_10k,
+ },
+};
+
+static int gmac_pick_rx_max_len(unsigned int max_l3_len)
+{
+ const struct gmac_max_framelen *maxlen;
+ int maxtot;
+ int i;
- if (max_l3_len > max_len[n])
- return -1;
+ maxtot = max_l3_len + ETH_HLEN + VLAN_HLEN;
- for (i = 0; i < 5; i++) {
- if (max_len[i] >= max_l3_len && max_len[i] < max_len[n])
- n = i;
+ for (i = 0; i < ARRAY_SIZE(gmac_maxlens); i++) {
+ maxlen = &gmac_maxlens[i];
+ if (maxtot <= maxlen->max_l3_len)
+ return maxlen->val;
}
- return n;
+ return -1;
}
static int gmac_init(struct net_device *netdev)
--
2.17.1
^ permalink raw reply related
* Re: [PATCHv2 net-next 2/2] selftests: add a selftest for directed broadcast forwarding
From: David Ahern @ 2018-07-04 18:36 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem, Davide Caratti, Ido Schimmel
In-Reply-To: <CADvbK_c6pdnHuKd_aDG3REWvGRx5AtGH2YO90tyRvcWesBDzPw@mail.gmail.com>
On 7/4/18 11:56 AM, Xin Long wrote:
>> your commands are not a proper test. The test should succeed and fail
>> based on the routing lookup, not iptables rules.
> A proper test can be done easily with netns, as vrf can't isolate much.
> I don't want to bother forwarding/ directory with netns, so I will probably
> just drop this selftest, and let the feature patch go first.
>
BTW, VRF isolates at the routing layer and this is a routing change. We
need to understand why it does not work with VRF. Perhaps another tweak
is needed for VRF.
^ permalink raw reply
* [PATCH net-next 2/5 v2] net: gemini: Improve connection prints
From: Linus Walleij @ 2018-07-04 18:33 UTC (permalink / raw)
To: netdev, David S . Miller, Michał Mirosław
Cc: Janos Laube, Paulius Zaleckas, linux-arm-kernel, Hans Ulli Kroll,
Florian Fainelli, Linus Walleij
In-Reply-To: <20180704183324.10605-1-linus.walleij@linaro.org>
Switch over to using a module parameter and debug prints
that can be controlled by this or ethtool like everyone
else. Depromote all other prints to debug messages.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Use a module parameter and the message levels like all
other drivers and stop trying to be special.
---
drivers/net/ethernet/cortina/gemini.c | 44 +++++++++++++++------------
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c
index 8fc31723f700..f219208d2351 100644
--- a/drivers/net/ethernet/cortina/gemini.c
+++ b/drivers/net/ethernet/cortina/gemini.c
@@ -46,6 +46,11 @@
#define DRV_NAME "gmac-gemini"
#define DRV_VERSION "1.0"
+#define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV|NETIF_MSG_PROBE|NETIF_MSG_LINK)
+static int debug = -1;
+module_param(debug, int, 0);
+MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
+
#define HSIZE_8 0x00
#define HSIZE_16 0x01
#define HSIZE_32 0x02
@@ -300,23 +305,26 @@ static void gmac_speed_set(struct net_device *netdev)
status.bits.speed = GMAC_SPEED_1000;
if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
status.bits.mii_rmii = GMAC_PHY_RGMII_1000;
- netdev_info(netdev, "connect to RGMII @ 1Gbit\n");
+ netdev_dbg(netdev, "connect %s to RGMII @ 1Gbit\n",
+ phydev_name(phydev));
break;
case 100:
status.bits.speed = GMAC_SPEED_100;
if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
status.bits.mii_rmii = GMAC_PHY_RGMII_100_10;
- netdev_info(netdev, "connect to RGMII @ 100 Mbit\n");
+ netdev_dbg(netdev, "connect %s to RGMII @ 100 Mbit\n",
+ phydev_name(phydev));
break;
case 10:
status.bits.speed = GMAC_SPEED_10;
if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
status.bits.mii_rmii = GMAC_PHY_RGMII_100_10;
- netdev_info(netdev, "connect to RGMII @ 10 Mbit\n");
+ netdev_dbg(netdev, "connect %s to RGMII @ 10 Mbit\n",
+ phydev_name(phydev));
break;
default:
- netdev_warn(netdev, "Not supported PHY speed (%d)\n",
- phydev->speed);
+ netdev_warn(netdev, "Unsupported PHY speed (%d) on %s\n",
+ phydev->speed, phydev_name(phydev));
}
if (phydev->duplex == DUPLEX_FULL) {
@@ -363,11 +371,8 @@ static int gmac_setup_phy(struct net_device *netdev)
return -ENODEV;
netdev->phydev = phy;
- netdev_info(netdev, "connected to PHY \"%s\"\n",
- phydev_name(phy));
- phy_attached_print(phy, "phy_id=0x%.8lx, phy_mode=%s\n",
- (unsigned long)phy->phy_id,
- phy_modes(phy->interface));
+ netdev_dbg(netdev, "connected to PHY \"%s\"\n",
+ phydev_name(phy));
phy->supported &= PHY_GBIT_FEATURES;
phy->supported |= SUPPORTED_Asym_Pause | SUPPORTED_Pause;
@@ -376,19 +381,19 @@ static int gmac_setup_phy(struct net_device *netdev)
/* set PHY interface type */
switch (phy->interface) {
case PHY_INTERFACE_MODE_MII:
- netdev_info(netdev, "set GMAC0 to GMII mode, GMAC1 disabled\n");
+ netdev_dbg(netdev,
+ "MII: set GMAC0 to GMII mode, GMAC1 disabled\n");
status.bits.mii_rmii = GMAC_PHY_MII;
- netdev_info(netdev, "connect to MII\n");
break;
case PHY_INTERFACE_MODE_GMII:
- netdev_info(netdev, "set GMAC0 to GMII mode, GMAC1 disabled\n");
+ netdev_dbg(netdev,
+ "GMII: set GMAC0 to GMII mode, GMAC1 disabled\n");
status.bits.mii_rmii = GMAC_PHY_GMII;
- netdev_info(netdev, "connect to GMII\n");
break;
case PHY_INTERFACE_MODE_RGMII:
- dev_info(dev, "set GMAC0 and GMAC1 to MII/RGMII mode\n");
+ netdev_dbg(netdev,
+ "RGMII: set GMAC0 and GMAC1 to MII/RGMII mode\n");
status.bits.mii_rmii = GMAC_PHY_RGMII_100_10;
- netdev_info(netdev, "connect to RGMII\n");
break;
default:
netdev_err(netdev, "Unsupported MII interface\n");
@@ -1307,8 +1312,8 @@ static void gmac_enable_irq(struct net_device *netdev, int enable)
unsigned long flags;
u32 val, mask;
- netdev_info(netdev, "%s device %d %s\n", __func__,
- netdev->dev_id, enable ? "enable" : "disable");
+ netdev_dbg(netdev, "%s device %d %s\n", __func__,
+ netdev->dev_id, enable ? "enable" : "disable");
spin_lock_irqsave(&geth->irq_lock, flags);
mask = GMAC0_IRQ0_2 << (netdev->dev_id * 2);
@@ -1813,7 +1818,7 @@ static int gmac_open(struct net_device *netdev)
HRTIMER_MODE_REL);
port->rx_coalesce_timer.function = &gmac_coalesce_delay_expired;
- netdev_info(netdev, "opened\n");
+ netdev_dbg(netdev, "opened\n");
return 0;
@@ -2385,6 +2390,7 @@ static int gemini_ethernet_port_probe(struct platform_device *pdev)
port->id = id;
port->geth = geth;
port->dev = dev;
+ port->msg_enable = netif_msg_init(debug, DEFAULT_MSG_ENABLE);
/* DMA memory */
dmares = platform_get_resource(pdev, IORESOURCE_MEM, 0);
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 3/5 v2] net: gemini: Allow multiple ports to instantiate
From: Linus Walleij @ 2018-07-04 18:33 UTC (permalink / raw)
To: netdev, David S . Miller, Michał Mirosław
Cc: Janos Laube, Paulius Zaleckas, linux-arm-kernel, Hans Ulli Kroll,
Florian Fainelli, Linus Walleij
In-Reply-To: <20180704183324.10605-1-linus.walleij@linaro.org>
The code was not tested with two ports actually in use at
the same time. (I blame this on lack of actual hardware using
that feature.) Now after locating a system using both ports,
add necessary fix to make both ports come up.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- No changes, just resending with the rest.
---
drivers/net/ethernet/cortina/gemini.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c
index f219208d2351..6b5aa5704c4f 100644
--- a/drivers/net/ethernet/cortina/gemini.c
+++ b/drivers/net/ethernet/cortina/gemini.c
@@ -1789,7 +1789,10 @@ static int gmac_open(struct net_device *netdev)
phy_start(netdev->phydev);
err = geth_resize_freeq(port);
- if (err) {
+ /* It's fine if it's just busy, the other port has set up
+ * the freeq in that case.
+ */
+ if (err && (err != -EBUSY)) {
netdev_err(netdev, "could not resize freeq\n");
goto err_stop_phy;
}
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 4/5 v2] net: gemini: Move main init to port
From: Linus Walleij @ 2018-07-04 18:33 UTC (permalink / raw)
To: netdev, David S . Miller, Michał Mirosław
Cc: Janos Laube, Paulius Zaleckas, linux-arm-kernel, Hans Ulli Kroll,
Florian Fainelli, Linus Walleij
In-Reply-To: <20180704183324.10605-1-linus.walleij@linaro.org>
The initialization sequence for the ethernet, setting up
interrupt routing and such things, need to be done after
both the ports are clocked and reset. Before this the
config will not "take". Move the initialization to the
port probe function and keep track of init status in
the state.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- No changes, just resending with the rest.
---
drivers/net/ethernet/cortina/gemini.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c
index 6b5aa5704c4f..4e341570047f 100644
--- a/drivers/net/ethernet/cortina/gemini.c
+++ b/drivers/net/ethernet/cortina/gemini.c
@@ -151,6 +151,7 @@ struct gemini_ethernet {
void __iomem *base;
struct gemini_ethernet_port *port0;
struct gemini_ethernet_port *port1;
+ bool initialized;
spinlock_t irq_lock; /* Locks IRQ-related registers */
unsigned int freeq_order;
@@ -2303,6 +2304,14 @@ static void gemini_port_remove(struct gemini_ethernet_port *port)
static void gemini_ethernet_init(struct gemini_ethernet *geth)
{
+ /* Only do this once both ports are online */
+ if (geth->initialized)
+ return;
+ if (geth->port0 && geth->port1)
+ geth->initialized = true;
+ else
+ return;
+
writel(0, geth->base + GLOBAL_INTERRUPT_ENABLE_0_REG);
writel(0, geth->base + GLOBAL_INTERRUPT_ENABLE_1_REG);
writel(0, geth->base + GLOBAL_INTERRUPT_ENABLE_2_REG);
@@ -2450,6 +2459,10 @@ static int gemini_ethernet_port_probe(struct platform_device *pdev)
geth->port0 = port;
else
geth->port1 = port;
+
+ /* This will just be done once both ports are up and reset */
+ gemini_ethernet_init(geth);
+
platform_set_drvdata(pdev, port);
/* Set up and register the netdev */
@@ -2567,7 +2580,6 @@ static int gemini_ethernet_probe(struct platform_device *pdev)
spin_lock_init(&geth->irq_lock);
spin_lock_init(&geth->freeq_lock);
- gemini_ethernet_init(geth);
/* The children will use this */
platform_set_drvdata(pdev, geth);
@@ -2580,8 +2592,8 @@ static int gemini_ethernet_remove(struct platform_device *pdev)
{
struct gemini_ethernet *geth = platform_get_drvdata(pdev);
- gemini_ethernet_init(geth);
geth_cleanup_freeq(geth);
+ geth->initialized = false;
return 0;
}
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 5/5 v2] net: gemini: Indicate that we can handle jumboframes
From: Linus Walleij @ 2018-07-04 18:33 UTC (permalink / raw)
To: netdev, David S . Miller, Michał Mirosław
Cc: Janos Laube, Paulius Zaleckas, linux-arm-kernel, Hans Ulli Kroll,
Florian Fainelli, Linus Walleij
In-Reply-To: <20180704183324.10605-1-linus.walleij@linaro.org>
The hardware supposedly handles frames up to 10236 bytes and
implements .ndo_change_mtu() so accept 10236 minus the ethernet
header for a VLAN tagged frame on the netdevices. Use
ETH_MIN_MTU as minimum MTU.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Change the min MTU from 256 (vendor code) to ETH_MIN_MTU
which makes more sense.
---
drivers/net/ethernet/cortina/gemini.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c
index 4e341570047f..af38f9869734 100644
--- a/drivers/net/ethernet/cortina/gemini.c
+++ b/drivers/net/ethernet/cortina/gemini.c
@@ -2476,6 +2476,11 @@ static int gemini_ethernet_port_probe(struct platform_device *pdev)
netdev->hw_features = GMAC_OFFLOAD_FEATURES;
netdev->features |= GMAC_OFFLOAD_FEATURES | NETIF_F_GRO;
+ /* We can handle jumbo frames up to 10236 bytes so, let's accept
+ * payloads of 10236 bytes minus VLAN and ethernet header
+ */
+ netdev->min_mtu = ETH_MIN_MTU;
+ netdev->max_mtu = 10236 - VLAN_ETH_HLEN;
port->freeq_refill = 0;
netif_napi_add(netdev, &port->napi, gmac_napi_poll,
--
2.17.1
^ permalink raw reply related
* Re: [PATCH rdma-next 0/3] Dump and fill MKEY
From: Leon Romanovsky @ 2018-07-04 18:54 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Guy Levi, Yishai Hadas,
Yonatan Cohen, Saeed Mahameed, linux-netdev
In-Reply-To: <20180704174739.GA9317@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 970 bytes --]
On Wed, Jul 04, 2018 at 11:47:39AM -0600, Jason Gunthorpe wrote:
> On Tue, Jun 19, 2018 at 08:47:21AM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > MLX5 IB HCA offers the memory key, dump_fill_mkey to increase
> > performance, when used in a send or receive operations.
> >
> > It is used to force local HCA operations to skip the PCI bus access,
> > while keeping track of the processed length in the ibv_sge handling.
> >
> > In this three patch series, we expose various bits in our HW
> > spec file (mlx5_ifc.h), move unneeded for mlx5_core FW command and
> > export such memory key to user space thought our mlx5-abi header file.
> >
> > Thanks
>
> This looks fine, can you send a pull request off the mlx5 branch
> please?
Updated mlx5-next with first two commits,
b183ee27f5fb net/mlx5: Add hardware definitions for dump_fill_mkey
4d4fb5dc988a net/mlx5: Limit scope of dump_fill_mkey function
Thanks
>
> Thanks,
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH rdma-next 3/3] IB/mlx5: Expose dump and fill memory key
From: Jason Gunthorpe @ 2018-07-04 19:09 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Guy Levi,
Yishai Hadas, Yonatan Cohen, Saeed Mahameed, linux-netdev
In-Reply-To: <20180619054724.32677-4-leon@kernel.org>
On Tue, Jun 19, 2018 at 08:47:24AM +0300, Leon Romanovsky wrote:
> From: Yonatan Cohen <yonatanc@mellanox.com>
>
> MLX5 IB HCA offers the memory key, dump_fill_mkey to boost
> performance, when used in a send or receive operations.
>
> It is used to force local HCA operations to skip the PCI bus access,
> while keeping track of the processed length in the ibv_sge handling.
>
> Meaning, instead of a PCI write access the HCA leaves the target
> memory untouched, and skips filling that packet section. Similar
> behavior is done upon send, the HCA skips data in memory relevant
> to this key and saves PCI bus access.
>
> This functionality saves PCI read/write operations.
>
> Signed-off-by: Yonatan Cohen <yonatanc@mellanox.com>
> Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
> Reviewed-by: Guy Levi <guyle@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> drivers/infiniband/hw/mlx5/main.c | 16 +++++++++++++++-
> include/uapi/rdma/mlx5-abi.h | 3 ++-
> 2 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
> index c29c7c838980..97113957398d 100644
> +++ b/drivers/infiniband/hw/mlx5/main.c
> @@ -1634,6 +1634,7 @@ static struct ib_ucontext *mlx5_ib_alloc_ucontext(struct ib_device *ibdev,
> int err;
> size_t min_req_v2 = offsetof(struct mlx5_ib_alloc_ucontext_req_v2,
> max_cqe_version);
> + u32 dump_fill_mkey;
> bool lib_uar_4k;
>
> if (!dev->ib_active)
> @@ -1743,8 +1744,12 @@ static struct ib_ucontext *mlx5_ib_alloc_ucontext(struct ib_device *ibdev,
> }
>
> err = mlx5_ib_devx_create(dev, context);
> + }
> +
> + if (MLX5_CAP_GEN(dev->mdev, dump_fill_mkey)) {
> + err = mlx5_cmd_dump_fill_mkey(dev->mdev, &dump_fill_mkey);
> if (err)
> - goto out_td;
> + goto out_mdev;
> }
Dropping the if (err) after mlx5_ib_devx_create is a rebasing error,
right?
Jason
^ permalink raw reply
* [PATCH net-next] r8169: fix runtime suspend
From: Heiner Kallweit @ 2018-07-04 19:11 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller; +Cc: netdev@vger.kernel.org
When runtime-suspending we configure WoL w/o touching saved_wolopts.
If saved_wolopts == 0 we would power down the PHY in this case what's
wrong. Therefore we have to check the actual chip WoL settings here.
Fixes: 433f9d0ddcc6 ("r8169: improve saved_wolopts handling")
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index f80ac894..d598fdf0 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1534,12 +1534,6 @@ static void rtl8169_check_link_status(struct net_device *dev,
#define WAKE_ANY (WAKE_PHY | WAKE_MAGIC | WAKE_UCAST | WAKE_BCAST | WAKE_MCAST)
-/* Currently we only enable WoL if explicitly told by userspace to circumvent
- * issues on certain platforms, see commit bde135a672bf ("r8169: only enable
- * PCI wakeups when WOL is active"). Let's keep __rtl8169_get_wol() for the
- * case that we want to respect BIOS settings again.
- */
-#if 0
static u32 __rtl8169_get_wol(struct rtl8169_private *tp)
{
u8 options;
@@ -1574,7 +1568,6 @@ static u32 __rtl8169_get_wol(struct rtl8169_private *tp)
return wolopts;
}
-#endif
static void rtl8169_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
{
@@ -4470,7 +4463,7 @@ static void rtl_wol_suspend_quirk(struct rtl8169_private *tp)
static bool rtl_wol_pll_power_down(struct rtl8169_private *tp)
{
- if (!netif_running(tp->dev) || !tp->saved_wolopts)
+ if (!netif_running(tp->dev) || !__rtl8169_get_wol(tp))
return false;
rtl_speed_down(tp);
--
2.18.0
^ permalink raw reply related
* Re: general protection fault in kernel_sock_shutdown
From: Eric Biggers @ 2018-07-04 19:19 UTC (permalink / raw)
To: syzbot; +Cc: davem, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <001a11458fb4c130d50565e41374@google.com>
On Fri, Feb 23, 2018 at 08:59:01AM -0800, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> af3e79d29555b97dd096e2f8e36a0f50213808a8 (Tue Feb 20 18:05:02 2018 +0000)
> Merge tag 'leds_for-4.16-rc3' of
> git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
>
> So far this crash happened 15 times on
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/master,
> net-next.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6111d5bfd5605f7520cb@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> audit: type=1400 audit(1519334784.255:7): avc: denied { map } for
> pid=4107 comm="syzkaller141165" path="/root/syzkaller141165324" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 4107 Comm: syzkaller141165 Not tainted 4.16.0-rc2+ #324
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:kernel_sock_shutdown+0x29/0x70 net/socket.c:3250
> RSP: 0018:ffff8801c905fcc8 EFLAGS: 00010206
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff846006f4
> RDX: 0000000000000005 RSI: 0000000000000002 RDI: 0000000000000028
> RBP: ffff8801c905fce0 R08: 0000000000000000 R09: 1ffff1003920bf15
> R10: ffff8801c905f870 R11: 0000000000000001 R12: ffff8801c90267d2
> R13: 0000000000000002 R14: 0000000000000000 R15: ffff8801c905fd58
> FS: 00000000006e6880(0000) GS:ffff8801db200000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fc70e02f000 CR3: 00000001ca694005 CR4: 00000000001606f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> smc_shutdown+0x3ed/0x540 net/smc/af_smc.c:1268
> SYSC_shutdown net/socket.c:1901 [inline]
> SyS_shutdown+0x137/0x290 net/socket.c:1892
> do_syscall_64+0x280/0x940 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x43fcb9
> RSP: 002b:00007ffde8479798 EFLAGS: 00000217 ORIG_RAX: 0000000000000030
> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fcb9
> RDX: 000000000043fcb9 RSI: 0000000000000002 RDI: 0000000000000003
> RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
> R10: 00000000004002c8 R11: 0000000000000217 R12: 00000000004015e0
> R13: 0000000000401670 R14: 0000000000000000 R15: 0000000000000000
> Code: 66 90 55 48 89 e5 41 55 41 54 53 48 89 fb 41 89 f5 e8 dc 04 11 fd 48
> 8d 7b 28 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75
> 32 4c 8b 63 28 48 b8 00 00 00 00 00 fc ff df 49
> RIP: kernel_sock_shutdown+0x29/0x70 net/socket.c:3250 RSP: ffff8801c905fcc8
> ---[ end trace 187d9b346b4a5aff ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
This was fixed by commit 1255fcb2a655f0:
#syz fix: net/smc: fix shutdown in state SMC_LISTEN
This also had been reported here: https://bugzilla.kernel.org/show_bug.cgi?id=199429
- Eric
^ permalink raw reply
* Re: [PATCH rdma-next 3/3] IB/mlx5: Expose dump and fill memory key
From: Leon Romanovsky @ 2018-07-04 19:20 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Guy Levi, Yishai Hadas,
Yonatan Cohen, Saeed Mahameed, linux-netdev
In-Reply-To: <20180704190937.GA15732@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 2660 bytes --]
On Wed, Jul 04, 2018 at 01:09:37PM -0600, Jason Gunthorpe wrote:
> On Tue, Jun 19, 2018 at 08:47:24AM +0300, Leon Romanovsky wrote:
> > From: Yonatan Cohen <yonatanc@mellanox.com>
> >
> > MLX5 IB HCA offers the memory key, dump_fill_mkey to boost
> > performance, when used in a send or receive operations.
> >
> > It is used to force local HCA operations to skip the PCI bus access,
> > while keeping track of the processed length in the ibv_sge handling.
> >
> > Meaning, instead of a PCI write access the HCA leaves the target
> > memory untouched, and skips filling that packet section. Similar
> > behavior is done upon send, the HCA skips data in memory relevant
> > to this key and saves PCI bus access.
> >
> > This functionality saves PCI read/write operations.
> >
> > Signed-off-by: Yonatan Cohen <yonatanc@mellanox.com>
> > Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
> > Reviewed-by: Guy Levi <guyle@mellanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > drivers/infiniband/hw/mlx5/main.c | 16 +++++++++++++++-
> > include/uapi/rdma/mlx5-abi.h | 3 ++-
> > 2 files changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
> > index c29c7c838980..97113957398d 100644
> > +++ b/drivers/infiniband/hw/mlx5/main.c
> > @@ -1634,6 +1634,7 @@ static struct ib_ucontext *mlx5_ib_alloc_ucontext(struct ib_device *ibdev,
> > int err;
> > size_t min_req_v2 = offsetof(struct mlx5_ib_alloc_ucontext_req_v2,
> > max_cqe_version);
> > + u32 dump_fill_mkey;
> > bool lib_uar_4k;
> >
> > if (!dev->ib_active)
> > @@ -1743,8 +1744,12 @@ static struct ib_ucontext *mlx5_ib_alloc_ucontext(struct ib_device *ibdev,
> > }
> >
> > err = mlx5_ib_devx_create(dev, context);
> > + }
> > +
> > + if (MLX5_CAP_GEN(dev->mdev, dump_fill_mkey)) {
> > + err = mlx5_cmd_dump_fill_mkey(dev->mdev, &dump_fill_mkey);
> > if (err)
> > - goto out_td;
> > + goto out_mdev;
> > }
>
> Dropping the if (err) after mlx5_ib_devx_create is a rebasing error,
> right?
Sorry, you are right, the fixup is pretty straightforward.
diff --git a/drivers/infiniband/hw/mlx5/main.c
b/drivers/infiniband/hw/mlx5/main.c
index 2bbafee6976c..71f3e9677622 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -1739,6 +1739,8 @@ static struct ib_ucontext
*mlx5_ib_alloc_ucontext(struct ib_device *ibdev,
}
err = mlx5_ib_devx_create(dev, context);
if (err)
+ goto out_td;
}
if (MLX5_CAP_GEN(dev->mdev, dump_fill_mkey)) {
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply related
* Re: [PATCH rdma-next 0/3] Dump and fill MKEY
From: Jason Gunthorpe @ 2018-07-04 19:29 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, RDMA mailing list, Guy Levi, Yishai Hadas,
Yonatan Cohen, Saeed Mahameed, linux-netdev
In-Reply-To: <20180704185459.GQ3014@mtr-leonro.mtl.com>
On Wed, Jul 04, 2018 at 09:54:59PM +0300, Leon Romanovsky wrote:
> On Wed, Jul 04, 2018 at 11:47:39AM -0600, Jason Gunthorpe wrote:
> > On Tue, Jun 19, 2018 at 08:47:21AM +0300, Leon Romanovsky wrote:
> > > From: Leon Romanovsky <leonro@mellanox.com>
> > >
> > > MLX5 IB HCA offers the memory key, dump_fill_mkey to increase
> > > performance, when used in a send or receive operations.
> > >
> > > It is used to force local HCA operations to skip the PCI bus access,
> > > while keeping track of the processed length in the ibv_sge handling.
> > >
> > > In this three patch series, we expose various bits in our HW
> > > spec file (mlx5_ifc.h), move unneeded for mlx5_core FW command and
> > > export such memory key to user space thought our mlx5-abi header file.
> > >
> > > Thanks
> >
> > This looks fine, can you send a pull request off the mlx5 branch
> > please?
>
> Updated mlx5-next with first two commits,
> b183ee27f5fb net/mlx5: Add hardware definitions for dump_fill_mkey
> 4d4fb5dc988a net/mlx5: Limit scope of dump_fill_mkey function
Okay, applied to for-next, with the missing 'if (err)' fixed.
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH] net: dsa: bcm_sf2: remove redundant variable off
From: Florian Fainelli @ 2018-07-04 19:55 UTC (permalink / raw)
To: Andrew Lunn, Colin King
Cc: Vivien Didelot, David S . Miller, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20180704142520.GD12405@lunn.ch>
On July 4, 2018 4:25:20 PM GMT+02:00, Andrew Lunn <andrew@lunn.ch> wrote:
>Hi Florian
>
>I this a bug? It seems to be a result of moving to
>b53_disable_port() in f86ad77faf.
>
>Before you would handle the CPU port differently than a normal
>port. After this change, there is no difference?
This looks like a big indeed, I will check that next week.
--
Florian
^ permalink raw reply
* Re: [PATCH net] net: phy: fix flag masking in __set_phy_supported
From: Florian Fainelli @ 2018-07-04 19:58 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <c0ca1da0-2b55-19c0-708a-ccab9a97ec5c@gmail.com>
On July 3, 2018 10:34:54 PM GMT+02:00, Heiner Kallweit <hkallweit1@gmail.com> wrote:
>Currently also the pause flags are removed from phydev->supported
>because
>they're not included in PHY_DEFAULT_FEATURES. I don't think this is
>intended, especially when considering that this function can be called
>via phy_set_max_speed() anywhere in a driver. Change the masking to
>mask
>out only the values we're going to change. In addition remove the
>misleading comment, job of this small function is just to adjust the
>supported and advertised speeds.
>
>Fixes: f3a6bd393c2c ("phylib: Add phy_set_max_speed helper")
>Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: WARNING in smc_unhash_sk
From: Eric Biggers @ 2018-07-04 20:01 UTC (permalink / raw)
To: Ursula Braun, linux-s390
Cc: syzbot, davem, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <001a114fa99028d2a10565e33df4@google.com>
Hi Ursula,
On Fri, Feb 23, 2018 at 07:59:01AM -0800, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> af3e79d29555b97dd096e2f8e36a0f50213808a8 (Tue Feb 20 18:05:02 2018 +0000)
> Merge tag 'leds_for-4.16-rc3' of
> git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
>
> So far this crash happened 27 times on
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/master,
> net-next, upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+3a0748c8f2f210c0ef9b@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> WARNING: CPU: 1 PID: 9921 at ./include/net/sock.h:638 sk_del_node_init
> include/net/sock.h:638 [inline]
> WARNING: CPU: 1 PID: 9921 at ./include/net/sock.h:638
> smc_unhash_sk+0x335/0x450 net/smc/af_smc.c:90
> Kernel panic - not syncing: panic_on_warn set ...
This is still happening and it can be easily reproduced with:
#include <sys/socket.h>
int main()
{
char buf[64] = { 0 };
struct iovec iov = { .iov_base = buf, .iov_len = sizeof(buf) };
struct msghdr msg = { .msg_iov = &iov, .msg_iovlen = 1 };
int fd;
fd = socket(AF_SMC, SOCK_STREAM, 0);
sendmsg(fd, &msg, MSG_FASTOPEN);
}
It seems the following sock_put() in smc_release() is done without any previous
sock_hold(), causing a use-after-free:
if (smc->use_fallback) {
sock_put(sk); /* passive closing */
sk->sk_state = SMC_CLOSED;
sk->sk_state_change(sk);
}
This is the output on latest Linus tree (commit fc36def997cfd6cb):
WARNING: CPU: 2 PID: 216 at include/net/sock.h:644 smc_unhash_sk+0x74/0x80 net/smc/af_smc.c:89
CPU: 2 PID: 216 Comm: syz_smc_unhash Not tainted 4.18.0-rc3-00113-gfc36def997cfd #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
RIP: 0010:smc_unhash_sk+0x74/0x80 net/smc/af_smc.c:89
Code: 8d bb 80 00 00 00 e8 9b 4a bc ff 48 8b 73 28 ba ff ff ff ff 48 8b 7b 30 e8 d9 a6 d4 ff 4c 89 e7 e8 e1 5b 02 00 5b 41 5c 5d c3 <0f> 0b eb d1 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 57 49 89 cf 41
RSP: 0018:ffffc900007cfd58 EFLAGS: 00010246
RAX: 0000000000000001 RBX: ffff8800792df7c0 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8270dda0 RDI: ffffffff81e92da0
RBP: ffffc900007cfd68 R08: ffffffff8270dda0 R09: 0000000000000001
R10: ffff88007933cbb8 R11: 0000000000000002 R12: ffffffff81e92da0
R13: 0000000000000000 R14: ffff8800792dfb20 R15: ffff8800792df840
FS: 00007ff24690e740(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ff245fe3eb0 CR3: 0000000001e0f000 CR4: 00000000003406e0
Call Trace:
smc_release+0x10a/0x1c0 net/smc/af_smc.c:162
__sock_release+0x31/0x80 net/socket.c:599
sock_close+0x10/0x20 net/socket.c:1150
__fput+0xb4/0x1f0 fs/file_table.c:209
____fput+0x9/0x10 fs/file_table.c:243
task_work_run+0x86/0xc0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x27a/0xa30 kernel/exit.c:865
do_group_exit+0x3c/0xc0 kernel/exit.c:968
__do_sys_exit_group kernel/exit.c:979 [inline]
__se_sys_exit_group kernel/exit.c:977 [inline]
__x64_sys_exit_group+0x13/0x20 kernel/exit.c:977
do_syscall_64+0x4a/0x180 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7ff245fe3ee8
Code: Bad RIP value.
RSP: 002b:00007ffcd2bdcae8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff245fe3ee8
RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
RBP: 00007ff2462cd6d8 R08: 00000000000000e7 R09: ffffffffffffff80
R10: 00007ff2464da100 R11: 0000000000000246 R12: 00007ff2462cd6d8
R13: 00007ff2462d2be0 R14: 0000000000000000 R15: 0000000000000000
irq event stamp: 1821
hardirqs last enabled at (1819): [<ffffffff81053a5a>] __local_bh_enable_ip+0x7a/0xd0 kernel/softirq.c:190
hardirqs last disabled at (1821): [<ffffffff81800f23>] error_entry+0x73/0xc0 arch/x86/entry/entry_64.S:1262
softirqs last enabled at (1818): [<ffffffff8144f8ad>] spin_unlock_bh include/linux/spinlock.h:355 [inline]
softirqs last enabled at (1818): [<ffffffff8144f8ad>] release_sock+0x7d/0xb0 net/core/sock.c:2862
softirqs last disabled at (1820): [<ffffffff81706e0d>] smc_unhash_sk+0x1d/0x80 net/smc/af_smc.c:85
---[ end trace f41d8ae31daf1115 ]---
------------[ cut here ]------------
refcount_t: decrement hit 0; leaking memory.
WARNING: CPU: 2 PID: 216 at lib/refcount.c:228 refcount_dec+0x33/0x40 lib/refcount.c:228
CPU: 2 PID: 216 Comm: syz_smc_unhash Tainted: G W 4.18.0-rc3-00113-gfc36def997cfd #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
RIP: 0010:refcount_dec+0x33/0x40 lib/refcount.c:228
Code: 48 89 e5 e8 6f ff ff ff 84 c0 75 02 5d c3 80 3d 85 94 bc 00 00 75 f5 48 c7 c7 40 43 d8 81 c6 05 75 94 bc 00 01 e8 d3 3f d8 ff <0f> 0b 5d c3 66 0f 1f 84 00 00 00 00 00 55 b8 01 00 00 00 31 d2 48
RSP: 0018:ffffc900007cfd48 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff8800792df7c0 RCX: 0000000000000006
RDX: 0000000000000007 RSI: ffff88007933cbe0 RDI: ffff88007fd15410
RBP: ffffc900007cfd48 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff81e92da0
R13: 0000000000000000 R14: ffff8800792dfb20 R15: ffff8800792df840
FS: 00007ff24690e740(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ff245fe3ebe CR3: 0000000001e0f000 CR4: 00000000003406e0
Call Trace:
__sock_put include/net/sock.h:635 [inline]
sk_del_node_init include/net/sock.h:645 [inline]
smc_unhash_sk+0x55/0x80 net/smc/af_smc.c:86
smc_release+0x10a/0x1c0 net/smc/af_smc.c:162
__sock_release+0x31/0x80 net/socket.c:599
sock_close+0x10/0x20 net/socket.c:1150
__fput+0xb4/0x1f0 fs/file_table.c:209
____fput+0x9/0x10 fs/file_table.c:243
task_work_run+0x86/0xc0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x27a/0xa30 kernel/exit.c:865
do_group_exit+0x3c/0xc0 kernel/exit.c:968
__do_sys_exit_group kernel/exit.c:979 [inline]
__se_sys_exit_group kernel/exit.c:977 [inline]
__x64_sys_exit_group+0x13/0x20 kernel/exit.c:977
do_syscall_64+0x4a/0x180 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7ff245fe3ee8
Code: Bad RIP value.
RSP: 002b:00007ffcd2bdcae8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff245fe3ee8
RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
RBP: 00007ff2462cd6d8 R08: 00000000000000e7 R09: ffffffffffffff80
R10: 00007ff2464da100 R11: 0000000000000246 R12: 00007ff2462cd6d8
R13: 00007ff2462d2be0 R14: 0000000000000000 R15: 0000000000000000
irq event stamp: 1841
hardirqs last enabled at (1840): [<ffffffff810a4297>] console_unlock+0x407/0x520 kernel/printk/printk.c:2422
hardirqs last disabled at (1841): [<ffffffff81800f23>] error_entry+0x73/0xc0 arch/x86/entry/entry_64.S:1262
softirqs last enabled at (1818): [<ffffffff8144f8ad>] spin_unlock_bh include/linux/spinlock.h:355 [inline]
softirqs last enabled at (1818): [<ffffffff8144f8ad>] release_sock+0x7d/0xb0 net/core/sock.c:2862
softirqs last disabled at (1820): [<ffffffff81706e0d>] smc_unhash_sk+0x1d/0x80 net/smc/af_smc.c:85
---[ end trace f41d8ae31daf1116 ]---
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 2 PID: 216 at lib/refcount.c:187 refcount_sub_and_test+0x4c/0x60 lib/refcount.c:187
CPU: 2 PID: 216 Comm: syz_smc_unhash Tainted: G W 4.18.0-rc3-00113-gfc36def997cfd #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
RIP: 0010:refcount_sub_and_test+0x4c/0x60 lib/refcount.c:187
Code: 5d 0f 94 c0 c3 83 f8 ff 75 df 31 c0 5d c3 80 3d ed 94 bc 00 00 75 f3 48 c7 c7 18 43 d8 81 c6 05 dd 94 bc 00 01 e8 3a 40 d8 ff <0f> 0b 31 c0 eb dc 31 c0 c3 90 66 2e 0f 1f 84 00 00 00 00 00 55 48
RSP: 0018:ffffc900007cfd58 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff8800792df7c0 RCX: 0000000000000006
RDX: 0000000000000007 RSI: ffff88007933cbb8 RDI: ffff88007fd15410
RBP: ffffc900007cfd58 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff88007cf16b80
R13: 0000000000000000 R14: ffff8800792dfb20 R15: ffff8800792df840
FS: 00007ff24690e740(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ff245fe3ebe CR3: 0000000001e0f000 CR4: 00000000003406e0
Call Trace:
refcount_dec_and_test+0x11/0x20 lib/refcount.c:212
sock_put include/net/sock.h:1666 [inline]
smc_release+0x112/0x1c0 net/smc/af_smc.c:163
__sock_release+0x31/0x80 net/socket.c:599
sock_close+0x10/0x20 net/socket.c:1150
__fput+0xb4/0x1f0 fs/file_table.c:209
____fput+0x9/0x10 fs/file_table.c:243
task_work_run+0x86/0xc0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x27a/0xa30 kernel/exit.c:865
do_group_exit+0x3c/0xc0 kernel/exit.c:968
__do_sys_exit_group kernel/exit.c:979 [inline]
__se_sys_exit_group kernel/exit.c:977 [inline]
__x64_sys_exit_group+0x13/0x20 kernel/exit.c:977
do_syscall_64+0x4a/0x180 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7ff245fe3ee8
Code: Bad RIP value.
RSP: 002b:00007ffcd2bdcae8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff245fe3ee8
RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
RBP: 00007ff2462cd6d8 R08: 00000000000000e7 R09: ffffffffffffff80
R10: 00007ff2464da100 R11: 0000000000000246 R12: 00007ff2462cd6d8
R13: 00007ff2462d2be0 R14: 0000000000000000 R15: 0000000000000000
irq event stamp: 1880
hardirqs last enabled at (1879): [<ffffffff810a4297>] console_unlock+0x407/0x520 kernel/printk/printk.c:2422
hardirqs last disabled at (1880): [<ffffffff81800f23>] error_entry+0x73/0xc0 arch/x86/entry/entry_64.S:1262
softirqs last enabled at (1862): [<ffffffff81a001b2>] __do_softirq+0x1b2/0x23f kernel/softirq.c:314
softirqs last disabled at (1847): [<ffffffff81800caa>] do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
---[ end trace f41d8ae31daf1117 ]---
^ permalink raw reply
* Re: [PATCH net-next 6/8] virtio: introduce packed ring defines
From: Maxime Coquelin @ 2018-07-04 20:15 UTC (permalink / raw)
To: Jason Wang, mst, kvm, virtualization, netdev, linux-kernel
Cc: wexu, tiwei.bie, jfreimann
In-Reply-To: <1530596284-4101-7-git-send-email-jasowang@redhat.com>
On 07/03/2018 07:38 AM, Jason Wang wrote:
> diff --git a/include/uapi/linux/virtio_ring.h b/include/uapi/linux/virtio_ring.h
> index 6d5d5fa..71c7a46 100644
> --- a/include/uapi/linux/virtio_ring.h
> +++ b/include/uapi/linux/virtio_ring.h
> @@ -43,6 +43,8 @@
> #define VRING_DESC_F_WRITE 2
> /* This means the buffer contains a list of buffer descriptors. */
> #define VRING_DESC_F_INDIRECT 4
> +#define VRING_DESC_F_AVAIL 7
> +#define VRING_DESC_F_USED 15
For consistency, you may want to make VRING_DESC_F_AVAIL and
VRING_DESC_F_USED to represent the bit mask and not the bit position,
as done for VRING_DESC_F_WRITE and VRING_DESC_F_INDIRECT.
Regards,
Maxime
^ permalink raw reply
* Re: BUG: corrupted list in tipc_nametbl_unsubscribe
From: Eric Biggers @ 2018-07-04 20:30 UTC (permalink / raw)
To: syzbot
Cc: davem, jon.maloy, linux-kernel, netdev, syzkaller-bugs,
tipc-discussion, ying.xue
In-Reply-To: <001a114535f203560405670110f5@google.com>
On Fri, Mar 09, 2018 at 12:59:04PM -0800, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on net-next commit
> fd372a7a9e5e9d8011a0222d10edd3523abcd3b1 (Thu Mar 8 19:43:48 2018 +0000)
> Merge tag 'mlx5-updates-2018-02-28-2' of
> git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux
>
> So far this crash happened 2 times on net-next.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+f25098149f0536920141@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> R13: ffffffffffffffff R14: 0000000000000000 R15: 0000000000000000
> Name sequence creation failed, no memory
> Failed to create subscription for {1020,0,4294967295}
> list_del corruption. prev->next should be 00000000f6eff561, but was
> (null)
> ------------[ cut here ]------------
> kernel BUG at lib/list_debug.c:53!
> invalid opcode: 0000 [#1] SMP KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 4187 Comm: syzkaller951783 Not tainted 4.16.0-rc4+ #258
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:__list_del_entry_valid+0xef/0x150 lib/list_debug.c:51
> RSP: 0018:ffff8801b7ed6ec8 EFLAGS: 00010282
> RAX: 0000000000000054 RBX: ffffffff879ffd20 RCX: 0000000000000000
> RDX: 0000000000000054 RSI: 1ffff10036fdad8e RDI: ffffed0036fdadcd
> RBP: ffff8801b7ed6ee0 R08: 1ffff10036fdad25 R09: 0000000000000000
> R10: ffff8801b7ed6da8 R11: 0000000000000000 R12: ffffffffffffffff
> R13: ffff8801b7ed7080 R14: ffff8801b7f6d998 R15: ffff8801d59c6c00
> FS: 0000000000000000(0000) GS:ffff8801db200000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f3357e55000 CR3: 0000000006e22001 CR4: 00000000001606f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> __list_del_entry include/linux/list.h:117 [inline]
> list_del_init include/linux/list.h:159 [inline]
> tipc_nametbl_unsubscribe+0x337/0x990 net/tipc/name_table.c:855
> tipc_sub_unsubscribe+0x6d/0x2e0 net/tipc/subscr.c:164
> tipc_conn_delete_sub+0x324/0x4a0 net/tipc/topsrv.c:245
> tipc_topsrv_kern_unsubscr+0x21d/0x350 net/tipc/topsrv.c:598
> tipc_group_delete+0x2c0/0x3d0 net/tipc/group.c:231
> tipc_sk_leave+0x10b/0x200 net/tipc/socket.c:2794
> tipc_release+0x154/0xff0 net/tipc/socket.c:577
> sock_release+0x8d/0x1e0 net/socket.c:594
> sock_close+0x16/0x20 net/socket.c:1149
> __fput+0x327/0x7e0 fs/file_table.c:209
> ____fput+0x15/0x20 fs/file_table.c:243
> task_work_run+0x199/0x270 kernel/task_work.c:113
> exit_task_work include/linux/task_work.h:22 [inline]
> do_exit+0x9bb/0x1ad0 kernel/exit.c:865
> do_group_exit+0x149/0x400 kernel/exit.c:968
> SYSC_exit_group kernel/exit.c:979 [inline]
> SyS_exit_group+0x1d/0x20 kernel/exit.c:977
> do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x43f0c8
> RSP: 002b:00007ffd4b6bf148 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000000000043f0c8
> RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
> RBP: 00000000004bf1a8 R08: 00000000000000e7 R09: ffffffffffffffd0
> R10: 0000000020265000 R11: 0000000000000246 R12: 0000000000000001
> R13: 00000000006d1180 R14: 0000000000000000 R15: 0000000000000000
> Code: 4c 89 e2 48 c7 c7 c0 7c 40 86 e8 75 f6 fb fe 0f 0b 48 c7 c7 20 7d 40
> 86 e8 67 f6 fb fe 0f 0b 48 c7 c7 80 7d 40 86 e8 59 f6 fb fe <0f> 0b 48 c7 c7
> e0 7d 40 86 e8 4b f6 fb fe 0f 0b 48 89 df 48 89
> RIP: __list_del_entry_valid+0xef/0x150 lib/list_debug.c:51 RSP:
> ffff8801b7ed6ec8
> ---[ end trace 1d4e489a074c9174 ]---
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
This was fixed by commit c3317f4db831b75 (thanks Jon!):
#syz fix: tipc: fix unbalanced reference counter
- Eric
^ permalink raw reply
* Re: [PATCH net-next 5/5 v2] net: gemini: Indicate that we can handle jumboframes
From: Andrew Lunn @ 2018-07-04 20:35 UTC (permalink / raw)
To: Linus Walleij
Cc: netdev, David S . Miller, Michał Mirosław,
Florian Fainelli, Paulius Zaleckas, Hans Ulli Kroll, Janos Laube,
linux-arm-kernel
In-Reply-To: <20180704183324.10605-5-linus.walleij@linaro.org>
On Wed, Jul 04, 2018 at 08:33:24PM +0200, Linus Walleij wrote:
> The hardware supposedly handles frames up to 10236 bytes and
> implements .ndo_change_mtu() so accept 10236 minus the ethernet
> header for a VLAN tagged frame on the netdevices. Use
> ETH_MIN_MTU as minimum MTU.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Hi Linus
Did you try with an MTU of 68? Maybe the vendor picked 256 because of
a hardware limit?
Otherwise the change looks good.
Andrew
^ permalink raw reply
* Re: [PATCHv2 net-next 2/2] selftests: add a selftest for directed broadcast forwarding
From: Ido Schimmel @ 2018-07-04 20:39 UTC (permalink / raw)
To: Xin Long; +Cc: David Ahern, network dev, davem, Davide Caratti
In-Reply-To: <CADvbK_c6pdnHuKd_aDG3REWvGRx5AtGH2YO90tyRvcWesBDzPw@mail.gmail.com>
On Thu, Jul 05, 2018 at 01:56:23AM +0800, Xin Long wrote:
> On Wed, Jul 4, 2018 at 3:23 AM, David Ahern <dsahern@gmail.com> wrote:
> > your commands are not a proper test. The test should succeed and fail
> > based on the routing lookup, not iptables rules.
> A proper test can be done easily with netns, as vrf can't isolate much.
> I don't want to bother forwarding/ directory with netns, so I will probably
> just drop this selftest, and let the feature patch go first.
>
> What do you think?
You can add a tc rule on the ingress of h2 and make sure that in the
first case ping succeeds and the tc rule wasn't hit. In the second case
ping should also succeed, but the tc rule should be hit. This is similar
to your original netns test.
You can look at tc_flower.sh for reference and in particular at
tc_check_packets().
^ 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