* [PATCH net-next 01/12] net: hns3: Fix ets validate issue
From: Salil Mehta @ 2018-09-21 15:41 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Jian Shen
In-Reply-To: <20180921154148.26756-1-salil.mehta@huawei.com>
From: Jian Shen <shenjian15@huawei.com>
There is a defect in hclge_ets_validate(). If each member of tc_tsa is
not IEEE_8021QAZ_TSA_ETS, the variable total_ets_bw won't be updated.
In this case, the check for value of total_ets_bw will fail. This patch
fixes it by checking total_ets_bw only after it has been updated.
Fixes: cacde272dd00 ("net: hns3: Add hclge_dcb module for the support of DCB feature")
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
index f08ebb7..92f1938 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
@@ -73,6 +73,7 @@ static int hclge_ieee_getets(struct hnae3_handle *h, struct ieee_ets *ets)
static int hclge_ets_validate(struct hclge_dev *hdev, struct ieee_ets *ets,
u8 *tc, bool *changed)
{
+ bool has_ets_tc = false;
u32 total_ets_bw = 0;
u8 max_tc = 0;
u8 i;
@@ -100,13 +101,14 @@ static int hclge_ets_validate(struct hclge_dev *hdev, struct ieee_ets *ets,
*changed = true;
total_ets_bw += ets->tc_tx_bw[i];
- break;
+ has_ets_tc = true;
+ break;
default:
return -EINVAL;
}
}
- if (total_ets_bw != BW_PERCENT)
+ if (has_ets_tc && total_ets_bw != BW_PERCENT)
return -EINVAL;
*tc = max_tc + 1;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 00/12] Bug fixes, snall modifications & cleanup for HNS3 driver
From: Salil Mehta @ 2018-09-21 15:41 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm
This patch presents some bug fixes, small modifications and cleanups
to the HNS3 VF and PF driver.
Fuyun Liang (1):
net: hns3: Fix speed/duplex information loss problem when executing
ethtool ethx cmd of VF
Jian Shen (9):
net: hns3: Fix ets validate issue
net: hns3: Unify the type convert for desc.data
net: hns3: Adjust prefix of tx/rx statistic names
net: hns3: Fix tqp array traversal condition for vf
net: hns3: Unify the prefix of vf functions
net: hns3: Add handle for default case
net: hns3: Add nic state check before calling netif_tx_wake_queue
net: hns3: Add unlikely for dma_mapping_error check
net: hns3: Remove print messages for error packet
Peng Li (2):
net: hns3: Add get_media_type ops support for VF
net: hns3: Remove redundant hclge_get_port_type()
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 13 ++--
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 83 +++++++++++++---------
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 6 +-
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 36 +++-------
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 6 +-
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 8 +--
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 72 +++++++++++--------
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 1 +
9 files changed, 120 insertions(+), 107 deletions(-)
--
2.7.4
^ permalink raw reply
* [Regression] openvswitch: Add eventmask support to CT action.
From: Joseph Salisbury @ 2018-09-21 9:37 UTC (permalink / raw)
To: Jarno Rajahalme
Cc: gvrose8192, joe, davem, pshelar, netdev, dev,
linux-kernel@vger.kernel.org, james.page, christian.ehrhardt,
1736390
Hi Jarno,
A kernel bug report was opened against Ubuntu [0]. This bug is a
regression introduced in v4.12-rc1. The latest mainline kernel was
tested and still exhibits the bug. The following commit was identified
as the cause of the regression:
120645513f55 ("openvswitch: Add eventmask support to CT action.")
I was hoping to get your feedback, since you are the patch author. Do
you think gathering any additional data will help diagnose this issue?
Thanks,
Joe
http://pad.lv/1736390
^ permalink raw reply
* Re: [PATCH net] ixgbe: check return value of napi_complete_done()
From: Alexei Starovoitov @ 2018-09-21 15:14 UTC (permalink / raw)
To: Eric Dumazet, Song Liu
Cc: Jeff Kirsher, netdev, intel-wired-lan@lists.osuosl.org,
Kernel Team, stable@vger.kernel.org, Alexei Starovoitov
In-Reply-To: <e6afa0d0-ba22-8205-076c-6a259a9f1b52@gmail.com>
On 9/21/18 7:59 AM, Eric Dumazet wrote:
>
>
> On 09/21/2018 07:55 AM, Alexei Starovoitov wrote:
>
>>
>> should we remove ndo_poll_controller then?
>> My understanding that the patch helps by not letting
>> drivers do napi_schedule() for all queues into this_cpu, right?
>> But most of the drivers do exactly that in their ndo_poll_controller
>> implementations. Means most of the drivers will experience
>> this nasty behavior.
>>
>
> Some legacy drivers do not use NAPI yet, but provide ndo_poll_controller()
>
> I believe users caring about system behavior with multi queue NIC are
> all using NAPI enabled drivers, so this should be fine.
I'm not following.
All modern napi enabled drivers need to _remove_ ndo_poll_controller
from the driver. This is a lot of churn.
Isn't it cleaner (less error prone) to introduce new ndo
for legacy drivers without napi?
^ permalink raw reply
* stmmac: Race in coalesce timer and NAPI
From: Jose Abreu @ 2018-09-21 9:19 UTC (permalink / raw)
To: netdev@vger.kernel.org, Joao Pinto
Hello,
I'm getting a race in stmmac coalesce timer and the
napi_schedule() interrupt and I'm asking for advice. Currently,
we are scheduling NAPI in coalesce timer but this leads to
stmmac_tx_clean() deadlock because this function tries to acquire
queue lock.
I find that this is not expected because only one instance of
NAPI should run at same time so I was wondering if it is possible
that xmit() callback is causing the deadlock ?
BTW, this is solved by:
- Directly call stmmac_tx_clean() in timer function AND
- Use netif_tx_trylock() in stmmac_tx_clean(). Then, if queue
is already locked we re-arm coalesce timer or reschedule NAPI.
This is easily reproducible in an ARM board with 8 core running
at 100MHz each.
Thanks and Best Regards,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: rework SIOCGSTAMP ioctl handling
From: Stefan Schmidt @ 2018-09-21 9:14 UTC (permalink / raw)
To: Arnd Bergmann, netdev, David S . Miller
Cc: linux-arch, y2038, Eric Dumazet, Willem de Bruijn, linux-kernel,
linux-hams, linux-bluetooth, linux-can, dccp, linux-wpan,
linux-sctp, linux-x25
In-Reply-To: <20180829130308.3504560-1-arnd@arndb.de>
Hello Arnd.
On 8/29/18 2:59 PM, Arnd Bergmann wrote:
> The SIOCGSTAMP/SIOCGSTAMPNS ioctl commands are implemented by many
> socket protocol handlers, and all of those end up calling the same
> sock_get_timestamp()/sock_get_timestampns() helper functions, which
> results in a lot of duplicate code.
>
> With the introduction of 64-bit time_t on 32-bit architectures, this
> gets worse, as we then need four different ioctl commands in each
> socket protocol implementation.
>
> To simplify that, let's add a new .gettstamp() operation in
> struct proto_ops, and move ioctl implementation into the common
> sock_ioctl()/compat_sock_ioctl_trans() functions that these all go
> through.
>
> We can reuse the sock_get_timestamp() implementation, but generalize
> it so it can deal with both native and compat mode, as well as
> timeval and timespec structures.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> include/linux/net.h | 2 ++
> include/net/compat.h | 3 --
> include/net/sock.h | 4 +--
> net/appletalk/ddp.c | 7 +----
> net/atm/ioctl.c | 16 -----------
> net/atm/pvc.c | 1 +
> net/atm/svc.c | 1 +
> net/ax25/af_ax25.c | 9 +-----
> net/bluetooth/af_bluetooth.c | 8 ------
> net/bluetooth/l2cap_sock.c | 1 +
> net/bluetooth/rfcomm/sock.c | 1 +
> net/bluetooth/sco.c | 1 +
> net/can/af_can.c | 6 ----
> net/can/bcm.c | 1 +
> net/can/raw.c | 1 +
> net/compat.c | 54 ------------------------------------
> net/core/sock.c | 38 +++++++++++--------------
> net/dccp/ipv4.c | 1 +
> net/dccp/ipv6.c | 1 +
> net/ieee802154/socket.c | 6 ++--
> net/ipv4/af_inet.c | 9 ++----
> net/ipv6/af_inet6.c | 8 ++----
> net/ipv6/raw.c | 1 +
> net/l2tp/l2tp_ip.c | 1 +
> net/l2tp/l2tp_ip6.c | 1 +
> net/netrom/af_netrom.c | 14 +---------
> net/packet/af_packet.c | 7 ++---
> net/qrtr/qrtr.c | 4 +--
> net/rose/af_rose.c | 7 +----
> net/sctp/ipv6.c | 1 +
> net/sctp/protocol.c | 1 +
> net/socket.c | 48 ++++++++++----------------------
> net/x25/af_x25.c | 27 +-----------------
> 33 files changed, 63 insertions(+), 228 deletions(-)
For the net/ieee802154/socket. part I am fine with this change.
Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>
regards
Stefan Schmidt
^ permalink raw reply
* Re: [PATCH net] ixgbe: check return value of napi_complete_done()
From: Eric Dumazet @ 2018-09-21 14:59 UTC (permalink / raw)
To: Alexei Starovoitov, Eric Dumazet, Song Liu
Cc: Jeff Kirsher, netdev, intel-wired-lan@lists.osuosl.org,
Kernel Team, stable@vger.kernel.org, Alexei Starovoitov
In-Reply-To: <71fd1305-17ad-2bdc-c123-9bc0ab37b0a4@fb.com>
On 09/21/2018 07:55 AM, Alexei Starovoitov wrote:
>
> should we remove ndo_poll_controller then?
> My understanding that the patch helps by not letting
> drivers do napi_schedule() for all queues into this_cpu, right?
> But most of the drivers do exactly that in their ndo_poll_controller
> implementations. Means most of the drivers will experience
> this nasty behavior.
>
Some legacy drivers do not use NAPI yet, but provide ndo_poll_controller()
I believe users caring about system behavior with multi queue NIC are
all using NAPI enabled drivers, so this should be fine.
^ permalink raw reply
* Re: [PATCH net] ixgbe: check return value of napi_complete_done()
From: Alexei Starovoitov @ 2018-09-21 14:55 UTC (permalink / raw)
To: Eric Dumazet, Song Liu
Cc: Jeff Kirsher, netdev, intel-wired-lan@lists.osuosl.org,
Kernel Team, stable@vger.kernel.org, Alexei Starovoitov
In-Reply-To: <74672b30-1627-efcd-383f-adda6cdf486f@gmail.com>
On 9/21/18 6:33 AM, Eric Dumazet wrote:
>
>
> On 09/21/2018 12:17 AM, Song Liu wrote:
>>
>>
>>> On Sep 20, 2018, at 4:49 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>>
>>>
>>>
>>> On 09/20/2018 04:43 PM, Song Liu wrote:
>>>>
>>>
>>>> I tried to totally skip ndo_poll_controller() here. It did avoid hitting
>>>> the issue. However, netpoll will drop (fail to send) more packets.
>>>>
>>>
>>> Why is it failing ?
>>>
>>> If you are under high memory pressure, then maybe if you absolutely want memory to send
>>> netpoll packets, you want to grab all NAPI contexts as a way to prevent other cpus
>>> from feeding incoming packets to the host and add more memory pressure ;)
>>>
>>
>> I did the test with Eric's latest patch (and disable ndo_poll_controller
>> in driver). The result didn't show significant increase in drop packets.
>> I guess packet drops in my earlier test was caused by some other changes
>> I mixed there.
>>
>> So I think this patch does fix the issue. Thanks Eric!
>
> Great, this is awesome.
>
> I will prepare a patch series for net tree.
>
> The core infrastructure is just better at being able to drain TX completions
> without risking stealing the NAPI context forever.
should we remove ndo_poll_controller then?
My understanding that the patch helps by not letting
drivers do napi_schedule() for all queues into this_cpu, right?
But most of the drivers do exactly that in their ndo_poll_controller
implementations. Means most of the drivers will experience
this nasty behavior.
^ permalink raw reply
* Re: [PATCH v3 net-next 07/12] net: ethernet: Add helper to remove a supported link mode
From: Simon Horman @ 2018-09-21 8:17 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Miller, netdev, Florian Fainelli, Sergei Shtylyov,
linux-renesas-soc
In-Reply-To: <20180920125106.GA13632@lunn.ch>
On Thu, Sep 20, 2018 at 02:51:06PM +0200, Andrew Lunn wrote:
> > eth0: no link
> > registers for MII PHY 0:
> > 1140 7949 0022 1622 0981 c1e1 000d 0000
>
> Hi Simon
>
> The ID registers 0022 1622 indicate this is a Micrel KSZ9031.
> Are you using the micrel PHY driver?
Yes, when the Link is successfully negotiated I see:
Micrel KSZ9031 Gigabit PHY e6800000.ethernet-ffffffff:00: attached PHY driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=e6800000.ethernet-ffffffff:00, irq=204)
> > I note a difference in the 3rd line of hex output: 7002 vs 6002
> > but I am unsure if that is relevant.
>
> Register 20, or 0x14. The datasheet says "Reserved" and there is no
> description given :-(
>
> I will decode the other registers and see if i can find anything.
Thanks, very much appreciated.
I believe your patch to disable Asym_Pause solves the immediate
problem I have observed.
^ permalink raw reply
* Re: [PATCH nf-next] netfilter: ctnetlink: must check mark attributes vs NULL
From: Pablo Neira Ayuso @ 2018-09-21 8:14 UTC (permalink / raw)
To: Florian Westphal
Cc: netfilter-devel, syzbot+e45eda8eda6e93a03959, syzkaller-bugs,
netdev, kristian.evensen
In-Reply-To: <20180920215306.10018-1-fw@strlen.de>
On Thu, Sep 20, 2018 at 11:53:06PM +0200, Florian Westphal wrote:
> else we will oops (null deref) when the attributes aren't present.
>
> Also add back the EOPNOTSUPP in case MARK filtering is requested but
> kernel doesn't support it.
Applied, thanks Florian.
^ permalink raw reply
* Re: [PATCH v3 net-next 07/12] net: ethernet: Add helper to remove a supported link mode
From: Simon Horman @ 2018-09-21 8:13 UTC (permalink / raw)
To: Andrew Lunn; +Cc: David Miller, netdev, Florian Fainelli
In-Reply-To: <20180920132530.GB13632@lunn.ch>
On Thu, Sep 20, 2018 at 03:25:30PM +0200, Andrew Lunn wrote:
> > 1. net-next: cf7d97e1e54d ("net: mdio: remove duplicated include from mdio_bus.c")
> >
> > # mii-tool -vv eth0
> > Using SIOCGMIIPHY=0x8947
> > eth0: no link
> > registers for MII PHY 0:
> > 1140 7949 0022 1622 0d81 c1e1 000f 0000
> > 0000 0300 0000 0000 0000 0000 0000 3000
> > 0000 0000 0000 0078 7002 0000 0000 0200
> > 0000 0000 0000 0528 0000 0000 0000 0000
> > product info: vendor 00:08:85, model 34 rev 2
> > basic mode: autonegotiation enabled
> > basic status: no link
> > capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > advertising: 100baseTx-FD 100baseTx-HD flow-control
> > link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> >
> > 2. net-next with this patch reverted
> >
> > # mii-tool -vv eth0
> > Using SIOCGMIIPHY=0x8947
> > eth0: negotiated 100baseTx-FD, link ok
> > registers for MII PHY 0:
> > 1140 796d 0022 1622 0181 c1e1 000f 0000
>
> Hi Simon
>
> Word 5 is what we are advertising. Bits 10 and 11 are Pause and Asym
> Pause. In the good case here, neither are set. In this bad case above,
> both bits are set.
>
> The patch i asked you to try only cleared the Pause bit, not the
> Asymmetric Pause bit. mii-tool only saying 'flow-control' did not
> help.
>
> Word 6 is what the partner is advertising. c1e1 indicates the partner
> does not support flow control, both bits are 0. I don't see why this
> is preventing auto-net though. But in the bad case, the status
> register indicates auto-neg has not completed.
>
> Anyway, please can you try this patch, which also removes Aysm Pause.
Thanks Andrew,
it seems that removing Aysm Pause does the trick.
* net-next [5678cb3c96ee ("net-next: mscc: remove unused ocelot_dev_gmii.h")]
+ Your patch to disable Pause and Asym_Pause (and 10baseT)
=> Success!
# ip link set up dev eth0; sleep 10; mii-tool -vv eth0
[ 13.418522] Micrel KSZ9031 Gigabit PHY e6800000.ethernet-ffffffff:00: attached PHY driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=e6800000.ethernet-ffffffff:00, irq=204)
[ 16.399410] ravb e6800000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Using SIOCGMIIPHY=0x8947
eth0: negotiated 100baseTx-FD, link ok
registers for MII PHY 0:
1140 796d 0022 1622 0181 c1e1 000f 0000
0000 0300 3800 0000 0000 0000 0000 3000
0000 0000 0000 0c7e 54fe 0000 0000 0200
0000 0000 0000 0500 0000 0000 0000 0000
product info: vendor 00:08:85, model 34 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD
link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
* net-next [5678cb3c96ee ("net-next: mscc: remove unused ocelot_dev_gmii.h")]
+ Your patch modified to only disable Asym_Pause (and 10baseT)
=> Success!
# ip link set up dev eth0; sleep 10; mii-tool -vv eth0
[ 86.414460] Micrel KSZ9031 Gigabit PHY e6800000.ethernet-ffffffff:00: attached PHY driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=e6800000.ethernet-ffffffff:00, irq=204)
[ 89.414651] ravb e6800000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Using SIOCGMIIPHY=0x8947
eth0: negotiated 100baseTx-FD, link ok
registers for MII PHY 0:
1140 796d 0022 1622 0581 c1e1 000f 0000
0000 0300 3800 0000 0000 0000 0000 3000
0000 0000 0000 087e 44fe 0000 0000 0200
0000 0000 0000 0500 0000 0000 0000 0000
product info: vendor 00:08:85, model 34 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD flow-control
link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
* net-next [5678cb3c96ee ("net-next: mscc: remove unused ocelot_dev_gmii.h")]
+ Your patch modified to only disable Pause (and 10baseT)
=> Fail (same test and result as yesterday)
# ip link set up dev eth0; sleep 10; mii-tool -vv eth0
[ 52.518742] Micrel KSZ9031 Gigabit PHY e6800000.ethernet-ffffffff:00: attached PHY driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=e6800000.ethernet-ffffffff:00, irq=204)
Using SIOCGMIIPHY=0x8947
eth0: no link
registers for MII PHY 0:
1140 7949 0022 1622 0981 c1e1 000f 0000
0000 0300 0000 0000 0000 0000 0000 3000
0000 0000 0000 0878 7002 0000 0000 0200
0000 0000 0000 0528 0000 0000 0000 0000
product info: vendor 00:08:85, model 34 rev 2
basic mode: autonegotiation enabled
basic status: no link
capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>
> Thanks
> Andrew
>
> >From 00a061304af51831ca1dc86bf6ce23d01f724229 Mon Sep 17 00:00:00 2001
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Tue, 18 Sep 2018 18:12:54 -0500
> Subject: [PATCH] ravb: Disable Pause Advertisement
>
> The previous commit to ravb had the side effect of making the PHY
> advertise Pause. This previously did not happen, and it appears the
> MAC does not support Pause. By default, phydev->supported has Pause
> enabled, but phydev->advertising does not. Rather than rely on this,
> be explicit, and remove the Pause link mode.
>
> Reported-by: Simon Horman <horms@verge.net.au>
> Fixes: 41124fa64d4b ("net: ethernet: Add helper to remove a supported link mode")
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> drivers/net/ethernet/renesas/ravb_main.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index fb2a1125780d..b0f2612ad226 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -1073,9 +1073,11 @@ static int ravb_phy_init(struct net_device *ndev)
> netdev_info(ndev, "limited PHY to 100Mbit/s\n");
> }
>
> - /* 10BASE is not supported */
> + /* 10BASE, Pause and Asym Pause is not supported */
> phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_10baseT_Half_BIT);
> phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_10baseT_Full_BIT);
> + phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_Pause_BIT);
> + phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_Asym_Pause_BIT);
>
> phy_attached_info(phydev);
>
> --
> 2.19.0.rc1
>
^ permalink raw reply
* [PATCH net] devlink: double free in devlink_resource_fill()
From: Dan Carpenter @ 2018-09-21 8:07 UTC (permalink / raw)
To: Jiri Pirko; +Cc: David S. Miller, netdev, kernel-janitors
Smatch reports that devlink_dpipe_send_and_alloc_skb() frees the skb
on error so this is a double free. We fixed a bunch of these bugs in
commit 7fe4d6dcbcb4 ("devlink: Remove redundant free on error path") but
we accidentally overlooked this one.
Fixes: d9f9b9a4d05f ("devlink: Add support for resource abstraction")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 65fc366a78a4..8c0ed225e280 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -2592,7 +2592,7 @@ static int devlink_resource_fill(struct genl_info *info,
if (!nlh) {
err = devlink_dpipe_send_and_alloc_skb(&skb, info);
if (err)
- goto err_skb_send_alloc;
+ return err;
goto send_done;
}
return genlmsg_reply(skb, info);
@@ -2600,7 +2600,6 @@ static int devlink_resource_fill(struct genl_info *info,
nla_put_failure:
err = -EMSGSIZE;
err_resource_put:
-err_skb_send_alloc:
nlmsg_free(skb);
return err;
}
^ permalink raw reply related
* Re: [PATCH net] sctp: update dst pmtu with the correct daddr
From: Xin Long @ 2018-09-21 7:55 UTC (permalink / raw)
To: davem; +Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, Neil Horman
In-Reply-To: <20180920.113113.1168948449098131783.davem@davemloft.net>
On Fri, Sep 21, 2018 at 2:31 AM David Miller <davem@davemloft.net> wrote:
>
> From: Xin Long <lucien.xin@gmail.com>
> Date: Thu, 20 Sep 2018 17:27:28 +0800
>
> > When processing pmtu update from an icmp packet, it calls .update_pmtu
> > with sk instead of skb in sctp_transport_update_pmtu.
> >
> > However for sctp, the daddr in the transport might be different from
> > inet_sock->inet_daddr or sk->sk_v6_daddr, which is used to update or
> > create the route cache. The incorrect daddr will cause a different
> > route cache created for the path.
> >
> > So before calling .update_pmtu, inet_sock->inet_daddr/sk->sk_v6_daddr
> > should be updated with the daddr in the transport, and update it back
> > after it's done.
> >
> > The issue has existed since route exceptions introduction.
> >
> > Fixes: 4895c771c7f0 ("ipv4: Add FIB nexthop exceptions.")
> > Reported-by: ian.periam@dialogic.com
> > Signed-off-by: Xin Long <lucien.xin@gmail.com>
>
> Applied and queued up for -stable.
>
> Although are you sure it's OK to temporarily change the sockets address
> like this? What if an asynchronous context looks at the socket state
> and sees the temporarily set address?
It's under the protection of the sock lock, I think any other places that
want to access the address also need to acquire this sock lock first.
^ permalink raw reply
* Re: [PATCH net] VSOCK: check sk state before receive
From: Jorgen S. Hansen @ 2018-09-21 7:48 UTC (permalink / raw)
To: Hangbin Liu; +Cc: Stefan Hajnoczi, netdev@vger.kernel.org, David S. Miller
In-Reply-To: <20180613014402.GU8958@leo.usersys.redhat.com>
Hi Hangbin,
I finaly got to the bottom of this - the issue was indeed in the VMCI driver. The patch is posted here:
https://lkml.org/lkml/2018/9/21/326
I used your reproduce.log to test the fix. Thanks for discovering this issue.
Thanks,
Jørgen
________________________________________
From: Hangbin Liu <liuhangbin@gmail.com>
Sent: Wednesday, June 13, 2018 3:44 AM
To: Jorgen S. Hansen
Cc: Stefan Hajnoczi; netdev@vger.kernel.org; David S. Miller
Subject: Re: [PATCH net] VSOCK: check sk state before receive
On Mon, Jun 04, 2018 at 04:02:39PM +0000, Jorgen S. Hansen wrote:
>
> > On May 30, 2018, at 11:17 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> >
> > On Sun, May 27, 2018 at 11:29:45PM +0800, Hangbin Liu wrote:
> >> Hmm...Although I won't reproduce this bug with my reproducer after
> >> apply my patch. I could still get a similiar issue with syzkaller sock vnet test.
> >>
> >> It looks this patch is not complete. Here is the KASAN call trace with my patch.
> >> I can also reproduce it without my patch.
> >
> > Seems like a race between vmci_datagram_destroy_handle() and the
> > delayed callback, vmci_transport_recv_dgram_cb().
> >
> > I don't know the VMCI transport well so I'll leave this to Jorgen.
>
> Yes, it looks like we are calling the delayed callback after we return from vmci_datagram_destroy_handle(). I’ll take a closer look at the VMCI side here - the refcounting of VMCI datagram endpoints should guard against this, since the delayed callback does a get on the datagram resource, so this could a VMCI driver issue, and not a problem in the VMCI transport for AF_VSOCK.
Hi Jorgen,
Thanks for helping look at this. I'm happy to run test for you patch.
Thanks
Hangbin
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH v2 1/4] i40e: clean zero-copy XDP Tx ring on shutdown/reset
From: Björn Töpel @ 2018-09-21 7:35 UTC (permalink / raw)
To: Jeff Kirsher, intel-wired-lan
Cc: Netdev, Björn Töpel, Magnus Karlsson, Karlsson, Magnus,
Jakub Kicinski, Daniel Borkmann, ast
In-Reply-To: <20180907081848.5438-2-bjorn.topel@gmail.com>
Jeff,
Den fre 7 sep. 2018 kl 10:29 skrev Björn Töpel <bjorn.topel@gmail.com>:
>
> From: Björn Töpel <bjorn.topel@intel.com>
>
> When the zero-copy enabled XDP Tx ring is torn down, due to
> configuration changes, outstandning frames on the hardware descriptor
> ring are queued on the completion ring.
>
> The completion ring has a back-pressure mechanism that will guarantee
> that there is sufficient space on the ring.
>
> Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_txrx.c | 17 +++++++----
> .../ethernet/intel/i40e/i40e_txrx_common.h | 2 ++
> drivers/net/ethernet/intel/i40e/i40e_xsk.c | 30 +++++++++++++++++++
> 3 files changed, 43 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> index 37bd4e50ccde..7f85d4ba8b54 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> @@ -636,13 +636,18 @@ void i40e_clean_tx_ring(struct i40e_ring *tx_ring)
> unsigned long bi_size;
> u16 i;
>
> - /* ring already cleared, nothing to do */
> - if (!tx_ring->tx_bi)
> - return;
> + if (ring_is_xdp(tx_ring) && tx_ring->xsk_umem) {
> + i40e_xsk_clean_tx_ring(tx_ring);
> + } else {
> + /* ring already cleared, nothing to do */
> + if (!tx_ring->tx_bi)
> + return;
>
> - /* Free all the Tx ring sk_buffs */
> - for (i = 0; i < tx_ring->count; i++)
> - i40e_unmap_and_free_tx_resource(tx_ring, &tx_ring->tx_bi[i]);
> + /* Free all the Tx ring sk_buffs */
> + for (i = 0; i < tx_ring->count; i++)
> + i40e_unmap_and_free_tx_resource(tx_ring,
> + &tx_ring->tx_bi[i]);
> + }
>
> bi_size = sizeof(struct i40e_tx_buffer) * tx_ring->count;
> memset(tx_ring->tx_bi, 0, bi_size);
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx_common.h b/drivers/net/ethernet/intel/i40e/i40e_txrx_common.h
> index b5afd479a9c5..29c68b29d36f 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_txrx_common.h
> +++ b/drivers/net/ethernet/intel/i40e/i40e_txrx_common.h
> @@ -87,4 +87,6 @@ static inline void i40e_arm_wb(struct i40e_ring *tx_ring,
> }
> }
>
> +void i40e_xsk_clean_tx_ring(struct i40e_ring *tx_ring);
> +
> #endif /* I40E_TXRX_COMMON_ */
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_xsk.c b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> index 2ebfc78bbd09..99116277c4d2 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> @@ -830,3 +830,33 @@ int i40e_xsk_async_xmit(struct net_device *dev, u32 queue_id)
>
> return 0;
> }
> +
> +/**
> + * i40e_xsk_clean_xdp_ring - Clean the XDP Tx ring on shutdown
> + * @xdp_ring: XDP Tx ring
> + **/
> +void i40e_xsk_clean_tx_ring(struct i40e_ring *tx_ring)
> +{
> + u16 ntc = tx_ring->next_to_clean, ntu = tx_ring->next_to_use;
> + struct xdp_umem *umem = tx_ring->xsk_umem;
> + struct i40e_tx_buffer *tx_bi;
> + u32 xsk_frames = 0;
> +
> + while (ntc != ntu) {
> + tx_bi = &tx_ring->tx_bi[ntc];
> +
> + if (tx_bi->xdpf)
> + i40e_clean_xdp_tx_buffer(tx_ring, tx_bi);
> + else
> + xsk_frames++;
> +
> + tx_bi->xdpf = NULL;
> +
> + ntc++;
> + if (ntc > tx_ring->count)
This is an off-by-one error, and should be:
if (ntc == tx_ring->count)
Can you fix it up, or should I respin the patch?
Thanks!
Björn
> + ntc = 0;
> + }
> +
> + if (xsk_frames)
> + xsk_umem_complete_tx(umem, xsk_frames);
> +}
> --
> 2.17.1
>
> _______________________________________________
> Intel-wired-lan mailing list
> Intel-wired-lan@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
^ permalink raw reply
* [PATCH] ISDN: Should use request_mem_region instead of request_region
From: zhong jiang @ 2018-09-21 12:40 UTC (permalink / raw)
To: davem, isdn; +Cc: arvind.yadav.cs, netdev, linux-kernel
In this case, Obviously, we should use request_mem_region to handle.
hence just replace the function.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/isdn/hisax/isurf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/isdn/hisax/isurf.c b/drivers/isdn/hisax/isurf.c
index 53e299b..ebf49f0 100644
--- a/drivers/isdn/hisax/isurf.c
+++ b/drivers/isdn/hisax/isurf.c
@@ -263,7 +263,7 @@ int setup_isurf(struct IsdnCard *card)
cs->hw.isurf.reset);
return (0);
}
- if (!request_region(cs->hw.isurf.phymem, ISURF_IOMEM_SIZE, "isurf iomem")) {
+ if (!request_mem_region(cs->hw.isurf.phymem, ISURF_IOMEM_SIZE, "isurf iomem")) {
printk(KERN_WARNING "HiSax: Siemens I-Surf memory region "
"%lx-%lx already in use\n",
cs->hw.isurf.phymem,
--
1.7.12.4
^ permalink raw reply related
* Re: [PATCH] net: macb: Clean 64b dma addresses if they are not detected
From: Nicolas Ferre @ 2018-09-21 12:38 UTC (permalink / raw)
To: Michal Simek, Edgar E. Iglesias
Cc: linux-kernel, monstr, Edgar E. Iglesias, David S. Miller, netdev,
u-boot, Joe Hershberger
In-Reply-To: <7e641346-dd4c-4e2a-637f-1b666f13485c@xilinx.com>
Michal,
On 20/09/2018 at 08:23, Michal Simek wrote:
> On 19.9.2018 20:08, Edgar E. Iglesias wrote:
>> On Wed, Sep 19, 2018 at 06:08:18PM +0200, Michal Simek wrote:
>>> Clear ADDR64 dma bit in DMACFG register in case that HW_DMA_CAP_64B
>>> is not detected on 64bit system.
>>> The issue was observed when bootloader(u-boot) does not check macb
>>> feature at DCFG6 register (DAW64_OFFSET) and enabling 64bit dma support
>>> by default. Then macb driver is reading DMACFG register back and only
>>> adding 64bit dma configuration but not cleaning it out.
>>>
>>> This is also align with other features which are also cleared if they are not
>>> present.
>>
>> Hi Michal,
>>
>>>
>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>>> ---
>>>
>>> drivers/net/ethernet/cadence/macb_main.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
>>> index 16e4ef7d7185..79707dff3f13 100644
>>> --- a/drivers/net/ethernet/cadence/macb_main.c
>>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>>> @@ -2163,6 +2163,8 @@ static void macb_configure_dma(struct macb *bp)
>>> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>>> if (bp->hw_dma_cap & HW_DMA_CAP_64B)
>>> dmacfg |= GEM_BIT(ADDR64);
>>> + else
>>> + dmacfg &= ~GEM_BIT(ADDR64);
>>> #endif
>>
>> I think you might want to do this clearing outside of the #ifdef.
>> If CONFIG_ARCH_DMA_ADDR_T_64BIT is not defined, we'd want to make
>> sure the ADDR64 is cleared. E.g something like:
>>
>> dmacfg &= ~GEM_BIT(ADDR64);
>> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>> if (bp->hw_dma_cap & HW_DMA_CAP_64B)
>> dmacfg |= GEM_BIT(ADDR64);
>> #endif
>>
>>
>> Same thing for the USE_HWSTAMP/PTP flags below.
>
> Origin patch, which introduce this read with mask,
> macfg = gem_readl(bp, DMACFG) & ~GEM_BF(RXBS, -1L);
> was done in 2011 and from that time this function was extended a little
> bit. I am even not quite sure if make sense to read this reg and apply
> setting on the top of it.
>
> Nicolas: Isn't it better simply compose that reg from scratch?
I have several arguments against composing this register from scratch:
1/ the reset value of this register is non-null for both of our
platforms and it could be meaningful to keep some of these values.
2/ one bitfield could use different values between Zynq and AT91: RXBMS
(1kB to 8kB for Zynq and 512 to 4KB for AT91), with same encoding.
3/ and well, this is the type of register with multiple bits that are
marked as "reserved" and that experience tells that they might be
connected to something...
So, I'm all for correcting the code like what Edgar suggests.
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array
From: Janusz Krzysztofik @ 2018-09-21 11:26 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Linus Walleij, Jonathan Corbet, Miguel Ojeda Sandonis,
Peter Korsgaard, Peter Rosin, Ulf Hansson, Andrew Lunn,
Florian Fainelli, David S. Miller, Dominik Brodowski,
Greg Kroah-Hartman, Kishon Vijay Abraham I, Lars-Peter Clausen,
Michael Hennerich, Jonathan Cameron, Hartmut Knaack,
Peter Meerwald-Stadler, Jiri Slaby, Willy Tarreau
In-Reply-To: <CAGfqbt7xJxGbq3oOJp9S0Sg7Z9=T6Dy52MDNWSDdsU==kPt1KQ@mail.gmail.com>
Hi Marek,
2018-09-21 12:51 GMT+02:00, Janusz Krzysztofik <jmkrzyszt@gmail.com>:
> Hi Marek,
>
> 2018-09-21 10:18 GMT+02:00, Marek Szyprowski <m.szyprowski@samsung.com>:
>> Hi Janusz,
>>
>> On 2018-09-20 18:21, Janusz Krzysztofik wrote:
>>> On Thursday, September 20, 2018 5:48:22 PM CEST Janusz Krzysztofik
>>> wrote:
>>>> On Thursday, September 20, 2018 12:11:48 PM CEST Marek Szyprowski
>>>> wrote:
>>>>> On 2018-09-02 14:01, Janusz Krzysztofik wrote:
>>>>>> Certain GPIO descriptor arrays returned by gpio_get_array() may
>>>>>> contain
>>>>>> information on direct mapping of array members to pins of a single
>>>>>> GPIO
>>>>>> chip in hardware order. In such cases, bitmaps of values can be
>>>>>> passed
>>>>>> directly from/to the chip's .get/set_multiple() callbacks without
>>>>>> wasting time on iterations.
>>>>>>
>>>>>> Add respective code to gpiod_get/set_array_bitmap_complex()
>>>>>> functions.
>>>>>> Pins not applicable for fast path are processed as before, skipping
>>>>>> over the 'fast' ones.
>>>>>>
>>>>>> Cc: Jonathan Corbet <corbet@lwn.net>
>>>>>> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>>>>> I've just noticed that this patch landed in today's linux-next. Sadly
>>>>> it
>>>>> breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
>>>>> device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
>>>>>
>>>>> Booting hangs after detecting MMC cards. Reverting this patch fixes
>>>>> the
>>>>> boot. I will try later to add some debugs and investigate it further
>>>>> what
>>>>> really happens when booting hangs.
>>>> Hi Marek,
>>>>
>>>> Thanks for reporting. Could you please try the following fix?
>>> Hi again,
>>>
>>> I realized the patch was not correct, j, not i, should be updated in
>>> second
>>> hunk. Please try the following one.
>>>
>>> Thanks,
>>> Janusz
>>>
>>> >From a919c504850f6cb40e8e81267a3a37537f7c4fd4 Mon Sep 17 00:00:00 2001
>>> From: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>>> Date: Thu, 20 Sep 2018 17:37:21 +0200
>>> Subject: [PATCH] gpiolib: Fix bitmap index not updated
>>> While skipping fast path bits, bitmap index is not updated with next
>>> found zero bit position. Fix it.
>>>
>>> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>>
>> This one also doesn't help. A quick compare of logs with this version and
>> a working system shows, that with your patch (and fix) there are no calls
>> to
>> gpx0-2 pin (which are a part of mmc pwrseq), what causes mmc failure. If
>> you need any more information (what kind of logs will help?), let me
>> know.
One more question. You said before that booting hanged after detecting MMC
cards. Without the fix, I could imagine it keeps iterating with index not
updated and simply never returns from gpiod_get/set_array_bitmap_complex().
Is the behaviour you observe the same with the fix applied?
Thanks,
Janusz
> There is a debug message on array_info content available at the end of
> gpiod_get_array(), could you please activate it and post the message so
> we can understand better what is going on?
>
> On the other hand, I've had a look your device-tree configuration and
> it looks like that specific setup won't benefit from the fast bitmap path.
> You have pin 2 at position 0 and pin 1 at position 1 of the array.
> Hence, the fast bitmap path covers only pin 1, and pin 2 is processed
> by the old path with apparently buggy code for skipping over fast pins.
>
> As a temporary workaround, you could try to revert the order of pins in
> your dts file (pin 1 at position 0, pin 2 at 1) and the mmc pwrseq code
> should work for you again by taking the original old path, not skipping
> over fast pins. Results of such check may also help us to better
> understand and resolve the issue.
>
> Thanks,
> Janusz
>
>>
>>> ---
>>> drivers/gpio/gpiolib.c | 7 ++++---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
>>> index a53d17745d21..369bdd358fcc 100644
>>> --- a/drivers/gpio/gpiolib.c
>>> +++ b/drivers/gpio/gpiolib.c
>>> @@ -2880,7 +2880,7 @@ int gpiod_get_array_value_complex(bool raw, bool
>>> can_sleep,
>>> __set_bit(hwgpio, mask);
>>>
>>> if (array_info)
>>> - find_next_zero_bit(array_info->get_mask,
>>> + i = find_next_zero_bit(array_info->get_mask,
>>> array_size, i);
>>> else
>>> i++;
>>> @@ -2905,7 +2905,8 @@ int gpiod_get_array_value_complex(bool raw, bool
>>> can_sleep,
>>> trace_gpio_value(desc_to_gpio(desc), 1, value);
>>>
>>> if (array_info)
>>> - find_next_zero_bit(array_info->get_mask, i, j);
>>> + j = find_next_zero_bit(array_info->get_mask, i,
>>> + j);
>>> else
>>> j++;
>>> }
>>> @@ -3192,7 +3193,7 @@ int gpiod_set_array_value_complex(bool raw, bool
>>> can_sleep,
>>> }
>>>
>>> if (array_info)
>>> - find_next_zero_bit(array_info->set_mask,
>>> + i = find_next_zero_bit(array_info->set_mask,
>>> array_size, i);
>>> else
>>> i++;
>>
>> Best regards
>> --
>> Marek Szyprowski, PhD
>> Samsung R&D Institute Poland
>>
>>
>
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: mvebu: add "marvell,prestera" to PP nodes
From: Gregory CLEMENT @ 2018-09-21 11:08 UTC (permalink / raw)
To: Chris Packham
Cc: robh+dt, jason, davem, andrew, sebastian.hesselbarth, devicetree,
linux-arm-kernel, linux-kernel, netdev, Mark Rutland
In-Reply-To: <20180907005926.27134-3-chris.packham@alliedtelesis.co.nz>
Hi Chris,
On ven., sept. 07 2018, Chris Packham <chris.packham@alliedtelesis.co.nz> wrote:
> The compatible string "marvell,prestera" allows drivers to have code
> common to any prestera variant.
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Applied on mvebu/dt
Thanks,
Gregory
> ---
> arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 2 +-
> arch/arm/boot/dts/armada-xp-98dx3336.dtsi | 2 +-
> arch/arm/boot/dts/armada-xp-98dx4251.dtsi | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
> index 8d708cc22495..2185ea58abfe 100644
> --- a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
> +++ b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
> @@ -243,7 +243,7 @@
> ranges = <0 MBUS_ID(0x03, 0x00) 0 0x100000>;
>
> pp0: packet-processor@0 {
> - compatible = "marvell,prestera-98dx3236";
> + compatible = "marvell,prestera-98dx3236", "marvell,prestera";
> reg = <0 0x4000000>;
> interrupts = <33>, <34>, <35>;
> dfx = <&dfx>;
> diff --git a/arch/arm/boot/dts/armada-xp-98dx3336.dtsi b/arch/arm/boot/dts/armada-xp-98dx3336.dtsi
> index 2f5fc67dd6dc..1d9d8a8ea60c 100644
> --- a/arch/arm/boot/dts/armada-xp-98dx3336.dtsi
> +++ b/arch/arm/boot/dts/armada-xp-98dx3336.dtsi
> @@ -35,5 +35,5 @@
> };
>
> &pp0 {
> - compatible = "marvell,prestera-98dx3336";
> + compatible = "marvell,prestera-98dx3336", "marvell,prestera";
> };
> diff --git a/arch/arm/boot/dts/armada-xp-98dx4251.dtsi b/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
> index 7a9e8839880b..48ffdc72bfc7 100644
> --- a/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
> +++ b/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
> @@ -49,6 +49,6 @@
> };
>
> &pp0 {
> - compatible = "marvell,prestera-98dx4251";
> + compatible = "marvell,prestera-98dx4251", "marvell,prestera";
> interrupts = <33>, <34>, <35>, <36>;
> };
> --
> 2.18.0
>
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: marvell,prestera: Add common compatible string
From: Gregory CLEMENT @ 2018-09-21 11:07 UTC (permalink / raw)
To: Chris Packham
Cc: robh+dt, jason, davem, andrew, sebastian.hesselbarth, devicetree,
linux-arm-kernel, linux-kernel, netdev, Mark Rutland
In-Reply-To: <20180907005926.27134-2-chris.packham@alliedtelesis.co.nz>
Hi Chris,
On ven., sept. 07 2018, Chris Packham <chris.packham@alliedtelesis.co.nz> wrote:
> Add "marvell,prestera" as a compatible string so that drivers can be
> written to account for any prestera variant without needing to
> specialise to the more specific values.
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Applied on mvebu/soc with Rob reviewed-by tag
Thanks,
Gregory
> ---
> Documentation/devicetree/bindings/net/marvell,prestera.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/marvell,prestera.txt b/Documentation/devicetree/bindings/net/marvell,prestera.txt
> index c329608fa887..83370ebf5b89 100644
> --- a/Documentation/devicetree/bindings/net/marvell,prestera.txt
> +++ b/Documentation/devicetree/bindings/net/marvell,prestera.txt
> @@ -2,7 +2,7 @@ Marvell Prestera Switch Chip bindings
> -------------------------------------
>
> Required properties:
> -- compatible: one of the following
> +- compatible: must be "marvell,prestera" and one of the following
> "marvell,prestera-98dx3236",
> "marvell,prestera-98dx3336",
> "marvell,prestera-98dx4251",
> @@ -21,7 +21,7 @@ switch {
> ranges = <0 MBUS_ID(0x03, 0x00) 0 0x100000>;
>
> packet-processor@0 {
> - compatible = "marvell,prestera-98dx3236";
> + compatible = "marvell,prestera-98dx3236", "marvell,prestera";
> reg = <0 0x4000000>;
> interrupts = <33>, <34>, <35>;
> dfx = <&dfx>;
> --
> 2.18.0
>
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
^ permalink raw reply
* Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array
From: Janusz Krzysztofik @ 2018-09-21 10:51 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Andrew Lunn, Ulf Hansson, linux-doc, linux-iio, Linus Walleij,
Dominik Brodowski, Peter Rosin, netdev, linux-i2c,
Peter Meerwald-Stadler, devel, Florian Fainelli, Jonathan Corbet,
Krzysztof Kozlowski, Kishon Vijay Abraham I, Tony Lindgren,
Lukas Wunner, Geert Uytterhoeven, linux-serial, Jiri Slaby,
Michael Hennerich, Uwe Kleine-König, linux-gpio,
Russell King
In-Reply-To: <20180921081806eucas1p182d4646e8510b5f0356214af7edba11e~WXF8Ptw4M0970709707eucas1p1p@eucas1p1.samsung.com>
Hi Marek,
2018-09-21 10:18 GMT+02:00, Marek Szyprowski <m.szyprowski@samsung.com>:
> Hi Janusz,
>
> On 2018-09-20 18:21, Janusz Krzysztofik wrote:
>> On Thursday, September 20, 2018 5:48:22 PM CEST Janusz Krzysztofik wrote:
>>> On Thursday, September 20, 2018 12:11:48 PM CEST Marek Szyprowski wrote:
>>>> On 2018-09-02 14:01, Janusz Krzysztofik wrote:
>>>>> Certain GPIO descriptor arrays returned by gpio_get_array() may
>>>>> contain
>>>>> information on direct mapping of array members to pins of a single
>>>>> GPIO
>>>>> chip in hardware order. In such cases, bitmaps of values can be
>>>>> passed
>>>>> directly from/to the chip's .get/set_multiple() callbacks without
>>>>> wasting time on iterations.
>>>>>
>>>>> Add respective code to gpiod_get/set_array_bitmap_complex() functions.
>>>>> Pins not applicable for fast path are processed as before, skipping
>>>>> over the 'fast' ones.
>>>>>
>>>>> Cc: Jonathan Corbet <corbet@lwn.net>
>>>>> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>>>> I've just noticed that this patch landed in today's linux-next. Sadly
>>>> it
>>>> breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
>>>> device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
>>>>
>>>> Booting hangs after detecting MMC cards. Reverting this patch fixes the
>>>> boot. I will try later to add some debugs and investigate it further
>>>> what
>>>> really happens when booting hangs.
>>> Hi Marek,
>>>
>>> Thanks for reporting. Could you please try the following fix?
>> Hi again,
>>
>> I realized the patch was not correct, j, not i, should be updated in
>> second
>> hunk. Please try the following one.
>>
>> Thanks,
>> Janusz
>>
>> >From a919c504850f6cb40e8e81267a3a37537f7c4fd4 Mon Sep 17 00:00:00 2001
>> From: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>> Date: Thu, 20 Sep 2018 17:37:21 +0200
>> Subject: [PATCH] gpiolib: Fix bitmap index not updated
>> While skipping fast path bits, bitmap index is not updated with next
>> found zero bit position. Fix it.
>>
>> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>
> This one also doesn't help. A quick compare of logs with this version and
> a working system shows, that with your patch (and fix) there are no calls
> to
> gpx0-2 pin (which are a part of mmc pwrseq), what causes mmc failure. If
> you need any more information (what kind of logs will help?), let me know.
There is a debug message on array_info content available at the end of
gpiod_get_array(), could you please activate it and post the message so
we can understand better what is going on?
On the other hand, I've had a look your device-tree configuration and
it looks like that specific setup won't benefit from the fast bitmap path.
You have pin 2 at position 0 and pin 1 at position 1 of the array.
Hence, the fast bitmap path covers only pin 1, and pin 2 is processed
by the old path with apparently buggy code for skipping over fast pins.
As a temporary workaround, you could try to revert the order of pins in
your dts file (pin 1 at position 0, pin 2 at 1) and the mmc pwrseq code
should work for you again by taking the original old path, not skipping
over fast pins. Results of such check may also help us to better
understand and resolve the issue.
Thanks,
Janusz
>
>> ---
>> drivers/gpio/gpiolib.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
>> index a53d17745d21..369bdd358fcc 100644
>> --- a/drivers/gpio/gpiolib.c
>> +++ b/drivers/gpio/gpiolib.c
>> @@ -2880,7 +2880,7 @@ int gpiod_get_array_value_complex(bool raw, bool
>> can_sleep,
>> __set_bit(hwgpio, mask);
>>
>> if (array_info)
>> - find_next_zero_bit(array_info->get_mask,
>> + i = find_next_zero_bit(array_info->get_mask,
>> array_size, i);
>> else
>> i++;
>> @@ -2905,7 +2905,8 @@ int gpiod_get_array_value_complex(bool raw, bool
>> can_sleep,
>> trace_gpio_value(desc_to_gpio(desc), 1, value);
>>
>> if (array_info)
>> - find_next_zero_bit(array_info->get_mask, i, j);
>> + j = find_next_zero_bit(array_info->get_mask, i,
>> + j);
>> else
>> j++;
>> }
>> @@ -3192,7 +3193,7 @@ int gpiod_set_array_value_complex(bool raw, bool
>> can_sleep,
>> }
>>
>> if (array_info)
>> - find_next_zero_bit(array_info->set_mask,
>> + i = find_next_zero_bit(array_info->set_mask,
>> array_size, i);
>> else
>> i++;
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
>
^ permalink raw reply
* [PATCH 0/2] net: if_arp: use define instead of hard-coded value
From: Håkon Bugge @ 2018-09-21 10:39 UTC (permalink / raw)
To: David S . Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI
Cc: linux-kernel, netdev
Struct arpreq contains the name of the device. All other places in the
kernel, the define IFNAMSIZ is used to designate its size. But in
if_arp.h, a literal constant is used.
As it could be good reasons to use constants instead of the defines in
include files under uapi, it seems to be OK to use the define here,
without opening a can of worms in user-land.
This because if_arp.h includes netdevice.h, which also uses
IFNAMSIZ. For the distros I have checked, this also holds true for the
use-land side.
The series also fixes some incorrect indents.
Håkon Bugge (2):
net: if_arp: Fix incorrect indents
net: if_arp: use define instead of hard-coded value
include/uapi/linux/if_arp.h | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
--
2.14.3
^ permalink raw reply
* Re: [PATCH net-next v5 02/20] zinc: introduce minimal cryptography library
From: Jason A. Donenfeld @ 2018-09-21 4:32 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Andy Lutomirski, Andrew Lunn, Arnd Bergmann, Eric Biggers, LKML,
Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Jean-Philippe Aumasson
In-Reply-To: <CAKv+Gu-sciHeWVij8hWGF78HV_CLddMv7Xdf1GRSY+6B2yt48A@mail.gmail.com>
Hi Ard,
On Fri, Sep 21, 2018 at 6:30 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> Did any of the fuzzing/testing you mention in the cover letter occur
> on the kernel versions of these algorithms?
Yes, of course.
Jason
^ permalink raw reply
* Re: [PATCH net-next v5 02/20] zinc: introduce minimal cryptography library
From: Ard Biesheuvel @ 2018-09-21 4:30 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Andy Lutomirski, Andrew Lunn, Arnd Bergmann, Eric Biggers, LKML,
Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Jean-Philippe Aumasson
In-Reply-To: <CAHmME9rF=FfOf-_EOB-BeT-BM=B9Q9YzFAoUimaPiM2RKb5sGA@mail.gmail.com>
On 20 September 2018 at 21:15, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Hi Andy,
>
> On Fri, Sep 21, 2018 at 5:23 AM Andy Lutomirski <luto@amacapital.net> wrote:
>> At the risk on suggesting something awful: on x86_64, since we turn preemption off for simd, it wouldn’t be *completely* insane to do the crypto on the irq stack. It would look like:
>>
>> kernel_fpu_call(func, arg);
>>
>> And this helper would disable preemption, enable FPU, switch to the irq stack, call func(arg), disable FPU, enable preemption, and return. And we can have large IRQ stacks.
>>
>> I refuse to touch this with a ten-foot pole until the lazy FPU restore patches land.
>
> Haha. That's fun, and maybe we'll do that at some point, but I have
> some other reasons too for being on a workqueue now.
>
Kernel mode crypto is callable from any context, and SIMD can be used
in softirq context on arm64 (and on x86, even from hardirq context
IIRC if the interrupt is taken from userland), in which case we'd
already be on the irq stack.
>>
>> All that being said, why are these frames so large? It sounds like something may be spilling that ought not to.
>
> They're not. Well, they're not anymore. I had a silly thing before
> like "u8 buffer[1 << 12]" in some debugging code, which is what
> prompted the ccflag-y addition. I cleaned up the mistakes like that
> and frames are now reasonable everywhere. Non-issue.
>
Did any of the fuzzing/testing you mention in the cover letter occur
on the kernel versions of these algorithms?
^ permalink raw reply
* Re: [PATCH net-next 0/5] vrf: allow simultaneous service instances in default and other VRFs
From: David Ahern @ 2018-09-21 4:28 UTC (permalink / raw)
To: Mike Manning, netdev, David Miller
In-Reply-To: <20180920085848.17721-1-mmanning@vyatta.att-mail.com>
On 9/20/18 1:58 AM, Mike Manning wrote:
> Services currently have to be VRF-aware if they are using an unbound
> socket. One cannot have multiple service instances running in the
> default and other VRFs for services that are not VRF-aware and listen
> on an unbound socket. This is because there is no way of isolating
> packets received in the default VRF from those arriving in other VRFs.
>
> This series provides this isolation subject to the existing kernel
> parameter net.ipv4.tcp_l3mdev_accept not being set, given that this is
> documented as allowing a single service instance to work across all
> VRF domains. The functionality applies to UDP & TCP services, for IPv4
> and IPv6, in particular adding VRF table handling for IPv6 multicast.
>
> Example of running ssh instances in default and blue VRF:
>
> $ /usr/sbin/sshd -D
> $ ip vrf exec vrf-blue /usr/sbin/sshd
> $ ss -ta | egrep 'State|ssh'
> State Recv-Q Send-Q Local Address:Port Peer Address:Port
> LISTEN 0 128 0.0.0.0%vrf-blue:ssh 0.0.0.0:*
> LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:*
> ESTAB 0 0 192.168.122.220:ssh 192.168.122.1:50282
> LISTEN 0 128 [::]%vrf-blue:ssh [::]:*
> LISTEN 0 128 [::]:ssh [::]:*
> ESTAB 0 0 [3000::2]%vrf-blue:ssh [3000::9]:45896
> ESTAB 0 0 [2000::2]:ssh [2000::9]:46398
>
Hi Dave:
I need some time to review and more importantly test this patch set
before it is committed. I am traveling tomorrow afternoon through Sunday
evening, so I need a few days into next week to get to this.
Thanks,
David
^ 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