* [iproute PATCH 2/3] testsuite: Prepare for ss tests
From: Phil Sutter @ 2018-08-14 12:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Samuel Mannehed
In-Reply-To: <20180814121808.24774-1-phil@nwl.cc>
This merges the shared bits from ts_tc() and ts_ip() into a common
function for being wrapped by the first ones and adds a third ts_ss()
for testing ss commands.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
testsuite/Makefile | 2 +-
testsuite/lib/generic.sh | 37 ++++++++++++++-----------------------
2 files changed, 15 insertions(+), 24 deletions(-)
diff --git a/testsuite/Makefile b/testsuite/Makefile
index 2a54e5c845e65..8fcbc557ff9a7 100644
--- a/testsuite/Makefile
+++ b/testsuite/Makefile
@@ -65,7 +65,7 @@ endif
TMP_ERR=`mktemp /tmp/tc_testsuite.XXXXXX`; \
TMP_OUT=`mktemp /tmp/tc_testsuite.XXXXXX`; \
STD_ERR="$$TMP_ERR" STD_OUT="$$TMP_OUT" \
- TC="$$i/tc/tc" IP="$$i/ip/ip" DEV="$(DEV)" IPVER="$@" SNAME="$$i" \
+ TC="$$i/tc/tc" IP="$$i/ip/ip" SS=$$i/misc/ss DEV="$(DEV)" IPVER="$@" SNAME="$$i" \
ERRF="$(RESULTS_DIR)/$@.$$o.err" $(KENV) $(PREFIX) tests/$@ > $(RESULTS_DIR)/$@.$$o.out; \
if [ "$$?" = "127" ]; then \
echo "SKIPPED"; \
diff --git a/testsuite/lib/generic.sh b/testsuite/lib/generic.sh
index 8cef20fa1b280..f92260fc40cf3 100644
--- a/testsuite/lib/generic.sh
+++ b/testsuite/lib/generic.sh
@@ -26,16 +26,17 @@ ts_skip()
exit 127
}
-ts_tc()
+__ts_cmd()
{
+ CMD=$1; shift
SCRIPT=$1; shift
DESC=$1; shift
- $TC $@ 2> $STD_ERR > $STD_OUT
+ $CMD $@ 2> $STD_ERR > $STD_OUT
if [ -s $STD_ERR ]; then
ts_err "${SCRIPT}: ${DESC} failed:"
- ts_err "command: $TC $@"
+ ts_err "command: $CMD $@"
ts_err "stderr output:"
ts_err_cat $STD_ERR
if [ -s $STD_OUT ]; then
@@ -50,29 +51,19 @@ ts_tc()
fi
}
-ts_ip()
+ts_tc()
{
- SCRIPT=$1; shift
- DESC=$1; shift
+ __ts_cmd "$TC" "$@"
+}
- $IP $@ 2> $STD_ERR > $STD_OUT
- RET=$?
+ts_ip()
+{
+ __ts_cmd "$IP" "$@"
+}
- if [ -s $STD_ERR ] || [ "$RET" != "0" ]; then
- ts_err "${SCRIPT}: ${DESC} failed:"
- ts_err "command: $IP $@"
- ts_err "stderr output:"
- ts_err_cat $STD_ERR
- if [ -s $STD_OUT ]; then
- ts_err "stdout output:"
- ts_err_cat $STD_OUT
- fi
- elif [ -s $STD_OUT ]; then
- echo "${SCRIPT}: ${DESC} succeeded with output:"
- cat $STD_OUT
- else
- echo "${SCRIPT}: ${DESC} succeeded"
- fi
+ts_ss()
+{
+ __ts_cmd "$SS" "$@"
}
ts_qdisc_available()
--
2.18.0
^ permalink raw reply related
* Re: [PATCH bpf] Revert "xdp: add NULL pointer check in __xdp_return()"
From: Björn Töpel @ 2018-08-14 12:02 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Daniel Borkmann, Alexei Starovoitov, Netdev, Taehee Yoo,
Jesper Dangaard Brouer, Björn Töpel, Karlsson, Magnus,
Magnus Karlsson, kafai
In-Reply-To: <20180810092625.1ad1cce4@cakuba.netronome.com>
Den fre 10 aug. 2018 kl 18:26 skrev Jakub Kicinski
<jakub.kicinski@netronome.com>:
>
> On Fri, 10 Aug 2018 17:16:45 +0200, Björn Töpel wrote:
> > Den fre 10 aug. 2018 kl 16:10 skrev Daniel Borkmann <daniel@iogearbox.net>:
> > >
> > > On 08/10/2018 11:28 AM, Björn Töpel wrote:
> > > > From: Björn Töpel <bjorn.topel@intel.com>
> > > >
> > > > This reverts commit 36e0f12bbfd3016f495904b35e41c5711707509f.
> > > >
> > > > The reverted commit adds a WARN to check against NULL entries in the
> > > > mem_id_ht rhashtable. Any kernel path implementing the XDP (generic or
> > > > driver) fast path is required to make a paired
> > > > xdp_rxq_info_reg/xdp_rxq_info_unreg call for proper function. In
> > > > addition, a driver using a different allocation scheme than the
> > > > default MEM_TYPE_PAGE_SHARED is required to additionally call
> > > > xdp_rxq_info_reg_mem_model.
> > > >
> > > > For MEM_TYPE_ZERO_COPY, an xdp_rxq_info_reg_mem_model call ensures
> > > > that the mem_id_ht rhashtable has a properly inserted allocator id. If
> > > > not, this would be a driver bug. A NULL pointer kernel OOPS is
> > > > preferred to the WARN.
> > > >
> > > > Suggested-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > > > Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
> > >
> > > Given the last bpf pr went out yesterday night, I've applied this to
> > > bpf-next (worst case we can just route it via stable), thanks!
> >
> > Ah, right! Thanks!
> >
> > bpf-next is OK. (Since this path is currently not used yet by any driver... :-()
>
> Wasn't this dead code, anyway? The frame return path is for redirects,
> and one can't convert_to_xdp_frame presently?
Indeed, dead it is. Hmm, I'll remove it as part of the i40e zc submission.
Björn
^ permalink raw reply
* Re: [Query]: DSA Understanding
From: Lad, Prabhakar @ 2018-08-14 11:49 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Andrew Lunn, netdev
In-Reply-To: <4ab52cf7-e340-ff0b-4352-f18dcb9e0e6b@gmail.com>
Hi Florian,
On Mon, Aug 13, 2018 at 7:57 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 08/13/2018 08:58 AM, Lad, Prabhakar wrote:
> > Hi Andrew/Florain,
> >
> > On Mon, Aug 13, 2018 at 2:38 PM Andrew Lunn <andrew@lunn.ch> wrote:
> >>
> >>>> I agree, this should be padding packets correctly, can you still
> >>>> instrument cpsw to make sure that what comes to its ndo_start_xmit() is
> >>>> ETH_ZLEN + tag_len or more?
> >>>>
> >>> Yes I can confirm the skb->len is always >= 62 (ETH_ZLEN + 2)
> >>
> >> Which switch are you using?
> >>
> >> Marvell switches use either 4 or 8 bytes of tag. Broadcom has 4, KSZ
> >> has 1 for packets going to the switch, lan9303 has 4, mtd uses 4, qca
> >> has 2.
> >>
> > I am using the KSZ switch. for Ingress it has 1 byte and for Egress it
> > has 2 bytes.
> > I came across patch [1] and padded 2 more bytes in ksz_xmit() and I was
> > successfully able to ping from lan4 to PC. Thank you very much for
> > your guidance/support.
> >
> > Now I have stumbled into a different issue:
> >
> > Case 1 Works:
> > =================
> > lan0 = 192.168.0.1
> > PC1 = 192.168.0.10
> > For the above ping works from both directions.
> >
> > CASE 2 Doesn’t Work:
> > =========================
> > lan0 = 192.168.0.1
> > PC1 = 192.168.0.10
> > lan4 = 192.168.0.4
> > PC2 = 192.168.0.11
> >
> > Ping from lan0 to PC1 and PC1 to lan0 works
> > But ping from PC2 to lan4 and lan4 to PC2 fails.
> >
> > CASE 3 Works:
> > =========================
> > lan0 = 192.168.0.1
> > PC1 = 192.168.0.10
> > lan4 = 192.168.4.4
> > PC2 = 192.168.4.11
> >
> > With the above setup ping works.
> >
> > [Query] Why does ping fail in case 2. Any thoughts what I am missing here ?
> > or is it the expected behaviour ?
>
> For case 2, what I suspect is happening is that the machine that has
> lan1/lan4, because you have put lan1/lan4 in the same subnet, does not
> know how to respond to PC2 because it is unable to select an appropriate
> output interface. In such cases, you might have to add an explicit /32
> route that forces telling the kernel that PC2 is accessible via lan2.
>
That did the trick thank you, following is my setup
lan0 = 192.168.0.1
PC1 = 192.168.0.10
lan4 = 192.168.0.4
PC2 = 192.168.0.11
route add 192.168.0.11 gw 192.168.0.4
route add 192.168.0.10 gw 192.168.0.1
And now ping works either ways. Is this setup for adding the route a valid way
to do it ? Or is there some standard way I need to follow which I am missing.
> Andrew, do you see an other explanation for that?
>
> >
> > [1] https://lore.kernel.org/patchwork/patch/851457/
>
> This patch works, but I think it is still working by "accident" in that
> if you have both VLAN tags + KSZ tag, you would likely still be too
> short by a few bytes.
>
too take care of this now I making sure the skb->len is padded to VLAN_ETH_ZLEN
in tag_ksz.c ksz_xmit() function.
Cheers,
--Prabhakar Lad
^ permalink raw reply
* Re: [RFC PATCH net-next V2 0/6] XDP rx handler
From: David Ahern @ 2018-08-14 14:03 UTC (permalink / raw)
To: Jason Wang, Jesper Dangaard Brouer
Cc: Alexei Starovoitov, netdev, linux-kernel, ast, daniel, mst
In-Reply-To: <03ab3b18-9b13-8169-7e68-ada307694bc1@redhat.com>
On 8/14/18 7:20 AM, Jason Wang wrote:
>
>
> On 2018年08月14日 18:17, Jesper Dangaard Brouer wrote:
>> On Tue, 14 Aug 2018 15:59:01 +0800
>> Jason Wang <jasowang@redhat.com> wrote:
>>
>>> On 2018年08月14日 08:32, Alexei Starovoitov wrote:
>>>> On Mon, Aug 13, 2018 at 11:17:24AM +0800, Jason Wang wrote:
>>>>> Hi:
>>>>>
>>>>> This series tries to implement XDP support for rx hanlder. This would
>>>>> be useful for doing native XDP on stacked device like macvlan, bridge
>>>>> or even bond.
>>>>>
>>>>> The idea is simple, let stacked device register a XDP rx handler. And
>>>>> when driver return XDP_PASS, it will call a new helper xdp_do_pass()
>>>>> which will try to pass XDP buff to XDP rx handler directly. XDP rx
>>>>> handler may then decide how to proceed, it could consume the buff, ask
>>>>> driver to drop the packet or ask the driver to fallback to normal skb
>>>>> path.
>>>>>
>>>>> A sample XDP rx handler was implemented for macvlan. And virtio-net
>>>>> (mergeable buffer case) was converted to call xdp_do_pass() as an
>>>>> example. For ease comparision, generic XDP support for rx handler was
>>>>> also implemented.
>>>>>
>>>>> Compared to skb mode XDP on macvlan, native XDP on macvlan (XDP_DROP)
>>>>> shows about 83% improvement.
>>>> I'm missing the motiviation for this.
>>>> It seems performance of such solution is ~1M packet per second.
>>> Notice it was measured by virtio-net which is kind of slow.
>>>
>>>> What would be a real life use case for such feature ?
>>> I had another run on top of 10G mlx4 and macvlan:
>>>
>>> XDP_DROP on mlx4: 14.0Mpps
>>> XDP_DROP on macvlan: 10.05Mpps
>>>
>>> Perf shows macvlan_hash_lookup() and indirect call to
>>> macvlan_handle_xdp() are the reasons for the number drop. I think the
>>> numbers are acceptable. And we could try more optimizations on top.
>>>
>>> So here's real life use case is trying to have an fast XDP path for rx
>>> handler based device:
>>>
>>> - For containers, we can run XDP for macvlan (~70% of wire speed). This
>>> allows a container specific policy.
>>> - For VM, we can implement macvtap XDP rx handler on top. This allow us
>>> to forward packet to VM without building skb in the setup of macvtap.
>>> - The idea could be used by other rx handler based device like bridge,
>>> we may have a XDP fast forwarding path for bridge.
>>>
>>>> Another concern is that XDP users expect to get line rate performance
>>>> and native XDP delivers it. 'generic XDP' is a fallback only
>>>> mechanism to operate on NICs that don't have native XDP yet.
>>> So I can replace generic XDP TX routine with a native one for macvlan.
>> If you simply implement ndo_xdp_xmit() for macvlan, and instead use
>> XDP_REDIRECT, then we are basically done.
>
> As I replied in another thread this probably not true. Its
> ndo_xdp_xmit() just need to call under layer device's ndo_xdp_xmit()
> except for the case of bridge mode.
>
>>
>>
>>>> Toshiaki's veth XDP work fits XDP philosophy and allows
>>>> high speed networking to be done inside containers after veth.
>>>> It's trying to get to line rate inside container.
>>> This is one of the goal of this series as well. I agree veth XDP work
>>> looks pretty fine, but it only work for a specific setup I believe since
>>> it depends on XDP_REDIRECT which is supported by few drivers (and
>>> there's no VF driver support).
>> The XDP_REDIRECT (RX-side) is trivial to add to drivers. It is a bad
>> argument that only a few drivers implement this. Especially since all
>> drivers also need to be extended with your proposed xdp_do_pass() call.
>>
>> (rant) The thing that is delaying XDP_REDIRECT adaption in drivers, is
>> that it is harder to implement the TX-side, as the ndo_xdp_xmit() call
>> have to allocate HW TX-queue resources. If we disconnect RX and TX
>> side of redirect, then we can implement RX-side in an afternoon.
>
> That's exactly the point, ndo_xdp_xmit() may requires per CPU TX queues
> which breaks assumptions of some drivers. And since we don't disconnect
> RX and TX, it looks to me the partial implementation is even worse?
> Consider a user can redirect from mlx4 to ixgbe but not ixgbe to mlx4.
>
>>
>>
>>> And in order to make it work for a end
>>> user, the XDP program still need logic like hash(map) lookup to
>>> determine the destination veth.
>> That _is_ the general idea behind XDP and eBPF, that we need to add logic
>> that determine the destination. The kernel provides the basic
>> mechanisms for moving/redirecting packets fast, and someone else
>> builds an orchestration tool like Cilium, that adds the needed logic.
>
> Yes, so my reply is for the concern about performance. I meant anyway
> the hash lookup will make it not hit the wire speed.
>
>>
>> Did you notice that we (Ahern) added bpf_fib_lookup a FIB route lookup
>> accessible from XDP.
>
> Yes.
>
>>
>> For macvlan, I imagine that we could add a BPF helper that allows you
>> to lookup/call macvlan_hash_lookup().
>
> That's true but we still need a method to feed macvlan with XDP buff.
> I'm not sure if this could be treated as another kind of redirection,
> but ndo_xdp_xmit() could not be used for this case for sure. Compared to
> redirection, XDP rx handler has its own advantages:
>
> 1) Use the exist API and userspace to setup the network topology instead
> of inventing new tools and its own specific API. This means user can
> just setup macvlan (macvtap, bridge or other) as usual and simply attach
> XDP programs to both macvlan and its under layer device.
> 2) Ease the processing of complex logic, XDP can not do cloning or
> reference counting. We can differ those cases and let normal networking
> stack to deal with such packets seamlessly. I believe this is one of the
> advantage of XDP. This makes us to focus on the fast path and greatly
> simplify the codes.
>
> Like ndo_xdp_xmit(), XDP rx handler is used to feed RX handler with XDP
> buff. It's just another basic mechanism. Policy is still done by XDP
> program itself.
>
I have been looking into handling stacked devices via lookup helper
functions. The idea is that a program only needs to be installed on the
root netdev (ie., the one representing the physical port), and it can
use helpers to create an efficient pipeline to decide what to do with
the packet in the presence of stacked devices.
For example, anyone doing pure L3 could do:
{port, vlan} --> [ find l2dev ] --> [ find l3dev ] ...
--> [ l3 forward lookup ] --> [ header rewrite ] --> XDP_REDIRECT
port is the netdev associated with the ingress_ifindex in the xdp_md
context, vlan is the vlan in the packet or the assigned PVID if
relevant. From there l2dev could be a bond or bridge device for example,
and l3dev is the one with a network address (vlan netdev, bond netdev, etc).
I have L3 forwarding working for vlan devices and bonds. I had not
considered macvlans specifically yet, but it should be straightforward
to add.
^ permalink raw reply
* Re: PROBLEM: Using BPF_PROG_TEST_RUN with data_out != NULL is unsafe
From: Lorenz Bauer @ 2018-08-14 10:59 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: ast, netdev, linux-kernel
In-Reply-To: <c3907b6a-a7cd-0fda-27fd-9357cf63cfec@iogearbox.net>
Sorry for the late reply.
On 4 April 2018 at 11:01, Daniel Borkmann <daniel@iogearbox.net> wrote:
> In case you point data_in and data_out to the same address, then the total buffer size therefore has to be
> attr.test.data_size_in + 256 in order to not overrun anything while not being
> aware of the BPF test program. The XDP_PACKET_HEADROOM is exposed to user space
> in linux/bpf.h.
Would it be possible to extend the API of BPF_PROG_TEST_RUN to allow
user space to specify the
length of the output buffer? The kernel could then either clamp
output, or return an error.
The current API seems fundamentally hard to use, and unsafe. It leads
to kludges like [1] in a library
I'm maintaining.
1: https://github.com/newtools/ebpf/blob/f4398602ca2a37b99a1f29df9a7e8adcc57be680/prog.go#L200-L204
--
Lorenz Bauer | Systems Engineer
25 Lavington St., London SE1 0NZ
www.cloudflare.com
^ permalink raw reply
* Re: [PATCH net 2/2] net/mlx5e: Cleanup of dcbnl related fields
From: Håkon Bugge @ 2018-08-14 10:52 UTC (permalink / raw)
To: Yuval Shaia; +Cc: Saeed Mahameed, David S. Miller, netdev, Huy Nguyen
In-Reply-To: <20180814090151.GA3787@lap1>
> On 14 Aug 2018, at 11:01, Yuval Shaia <yuval.shaia@oracle.com> wrote:
>
> On Wed, Aug 08, 2018 at 03:48:08PM -0700, Saeed Mahameed wrote:
>> From: Huy Nguyen <huyn@mellanox.com>
>>
>> Remove unused netdev_registered_init/remove in en.h
>> Return ENOSUPPORT if the check MLX5_DSCP_SUPPORTED fails.
>
> s/ENOSUPPORT/EOPNOTSUPP
> (noted by Haakon)
Sure did,
>
>> Remove extra white space
and I also said that this has nothing to with the commit (no matter how tempting it can be) ;-)
Thxs, Håkon
>>
>> Fixes: 2a5e7a1344f4 ("net/mlx5e: Add dcbnl dscp to priority support")
>> Signed-off-by: Huy Nguyen <huyn@mellanox.com>
>> Cc: Yuval Shaia <yuval.shaia@oracle.com>
>> Reviewed-by: Parav Pandit <parav@mellanox.com>
>> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
>> ---
>> drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 --
>> .../ethernet/mellanox/mlx5/core/en_dcbnl.c | 30 +++++++------------
>> 2 files changed, 11 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
>> index eb9eb7aa953a..405236cf0b04 100644
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
>> @@ -858,8 +858,6 @@ struct mlx5e_profile {
>> mlx5e_fp_handle_rx_cqe handle_rx_cqe;
>> mlx5e_fp_handle_rx_cqe handle_rx_cqe_mpwqe;
>> } rx_handlers;
>> - void (*netdev_registered_init)(struct mlx5e_priv *priv);
>> - void (*netdev_registered_remove)(struct mlx5e_priv *priv);
>> int max_tc;
>> };
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
>> index e33afa8d2417..722998d68564 100644
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
>> @@ -443,16 +443,12 @@ static int mlx5e_dcbnl_ieee_setapp(struct net_device *dev, struct dcb_app *app)
>> bool is_new;
>> int err;
>>
>> - if (app->selector != IEEE_8021QAZ_APP_SEL_DSCP)
>> - return -EINVAL;
>> -
>> - if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager))
>> - return -EINVAL;
>> -
>> - if (!MLX5_DSCP_SUPPORTED(priv->mdev))
>> - return -EINVAL;
>> + if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager) ||
>> + !MLX5_DSCP_SUPPORTED(priv->mdev))
>> + return -EOPNOTSUPP;
>>
>> - if (app->protocol >= MLX5E_MAX_DSCP)
>> + if ((app->selector != IEEE_8021QAZ_APP_SEL_DSCP) ||
>> + (app->protocol >= MLX5E_MAX_DSCP))
>> return -EINVAL;
>>
>> /* Save the old entry info */
>> @@ -500,16 +496,12 @@ static int mlx5e_dcbnl_ieee_delapp(struct net_device *dev, struct dcb_app *app)
>> struct mlx5e_priv *priv = netdev_priv(dev);
>> int err;
>>
>> - if (app->selector != IEEE_8021QAZ_APP_SEL_DSCP)
>> - return -EINVAL;
>> -
>> - if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager))
>> - return -EINVAL;
>> -
>> - if (!MLX5_DSCP_SUPPORTED(priv->mdev))
>> - return -EINVAL;
>> + if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager) ||
>> + !MLX5_DSCP_SUPPORTED(priv->mdev))
>> + return -EOPNOTSUPP;
>>
>> - if (app->protocol >= MLX5E_MAX_DSCP)
>> + if ((app->selector != IEEE_8021QAZ_APP_SEL_DSCP) ||
>> + (app->protocol >= MLX5E_MAX_DSCP))
>> return -EINVAL;
>>
>> /* Skip if no dscp app entry */
>> @@ -1146,7 +1138,7 @@ static int mlx5e_set_trust_state(struct mlx5e_priv *priv, u8 trust_state)
>> {
>> int err;
>>
>> - err = mlx5_set_trust_state(priv->mdev, trust_state);
>> + err = mlx5_set_trust_state(priv->mdev, trust_state);
>> if (err)
>> return err;
>> priv->dcbx_dp.trust_state = trust_state;
>> --
>> 2.17.0
>>
^ permalink raw reply
* [PATCH net] cxgb4: Add new T5 PCI device ids 0x50af and 0x50b0
From: Ganesh Goudar @ 2018-08-14 10:51 UTC (permalink / raw)
To: netdev, davem; +Cc: dt, Ganesh Goudar
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h b/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
index e3adf43..60df66f 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
@@ -189,6 +189,8 @@ CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN
CH_PCI_ID_TABLE_FENTRY(0x50ac), /* Custom T540-BT */
CH_PCI_ID_TABLE_FENTRY(0x50ad), /* Custom T520-CR */
CH_PCI_ID_TABLE_FENTRY(0x50ae), /* Custom T540-XL-SO */
+ CH_PCI_ID_TABLE_FENTRY(0x50af), /* Custom T580-KR-SO */
+ CH_PCI_ID_TABLE_FENTRY(0x50b0), /* Custom T520-CR-LOM */
/* T6 adapters:
*/
--
2.1.0
^ permalink raw reply related
* Re: linux-next: build warning after merge of the net-next tree
From: Guenter Roeck @ 2018-08-14 13:28 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Stephen Rothwell, David Miller, Networking,
Linux-Next Mailing List, Linux Kernel Mailing List, Andrew Lunn
In-Reply-To: <CAK7LNAQgdqpi60eH-Sfnr+U9DKpwCL=wPdhJA6=hpv3cicVotw@mail.gmail.com>
On 08/14/2018 12:05 AM, Masahiro Yamada wrote:
> 2018-07-20 8:19 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
>> 2018-07-20 7:35 GMT+09:00 Guenter Roeck <linux@roeck-us.net>:
>>> On Fri, Jul 20, 2018 at 08:09:06AM +1000, Stephen Rothwell wrote:
>>>> Hi Guenter,
>>>>
>>>> On Thu, 19 Jul 2018 06:49:01 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>
>>>>> On 07/18/2018 10:29 PM, Stephen Rothwell wrote:
>>>>>>
>>>>>> On Wed, 18 Jul 2018 20:52:56 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>>>
>>>>>>> On 07/18/2018 07:04 PM, Stephen Rothwell wrote:
>>>>>>>>
>>>>>>>> After merging the net-next tree, today's linux-next build (x86_64
>>>>>>>> allmodconfig) produced this warning:
>>>>>>>>
>>>>>>>> *
>>>>>>>> * Restart config...
>>>>>>>> *
>>>>>>>> ....
>>>>>>>>
>>>>>>>> This is output by my "make allmodconfig" and only started after merging
>>>>>>>> the net-next tree today. It has continued for further merges/builds.
>>>>>>>>
>>>>>>>> I suspect commit
>>>>>>>>
>>>>>>>> 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
>>>>>>>>
>>>>>>>> which added an "imply" clause.
>>>>>>>>
>>>>>>> I thought "imply" was better than "depends on HWMON || HWMON=n", but maybe
>>>>>>> not. Is that a caveat when using "imply", and does it mean that "imply"
>>>>>>> should better not be used ?
>>>>>>
>>>>>> I don't know, sorry. It was just my best guess from what I could see
>>>>>> had changed.
>>>>>>
>>>>>> I wonder if it makes a difference that I am doing my "make
>>>>>> allmodconfig" on top of a previous "make allmodconfig" and some symbols
>>>>>> are marked as "NEW" (though they are not symbols related to the changes
>>>>>> that happened during the net-next tree merge)?
>>>>>>
>>>>>
>>>>> I tried to reproduce the problem, but I don't see the message.
>>>>>
>>>>> What I do see, though, is that "make allmodconfig" on a clean tree,
>>>>> followed by "make menuconfig", results in configuration changes.
>>>>> Specifically,
>>>>>
>>>>> > CONFIG_ARC_EMAC_CORE=m
>>>>> > CONFIG_ARC_EMAC=m
>>>>> > CONFIG_EMAC_ROCKCHIP=m
>>>>>
>>>>> is removed by menuconfig, and a large number of "# ... is not set"
>>>>> configuration lines are added. Weird and bad, since several of the
>>>>> disabled configurations _should_ be enabled by "make allmodconfig",
>>>>> and a large number of hwmon drivers are affected. Bisect does point
>>>>> to "net: phy: sfp: Add HWMON support for module sensors", meaning
>>>>> "imply hwmon" does have severe side effects and can not be used.
>>>>>
>>>>> I'll try to find a fix.
>>>>
>>>> OK, my mistake, the "make allmodconfig" works, the following "make"
>>>> causes the config restart. (I am actually doing cross builds and using
>>>> an external object directory, in case that matters.)
>>>>
>>>> I removed the "imply HWMON" line added by the above commit and the
>>>> problem went away. Also, using "depends on HWMON || HWMON=n" instead
>>>> of the imply fixes it.
>>>
>>> Yes, replacing imply with the dependency is what I did in the fixup patch.
>>> Sorry, I should have copied you: https://patchwork.kernel.org/patch/10534925/
>>>
>>> It is a bit different - imply was supposed to enforce HWMON={y,n} if SFP=y,
>>> and the depends line enforces SFP={n,m} if HWMON=m. I have no idea why
>>> imply doesn't work, but I think I'll stay away from it in the future.
>>>
>>> Guenter
>>
>>
>> Hmm, this could be a Kconfig bug.
>>
>> I will take a look.
>
>
> Today, I took a look at it.
>
> The cause of the problem was the circular dependency.
>
> Somehow, 'imply' is not checked in the circular dependency.
>
> So, I wrote patches to report this.
> https://patchwork.kernel.org/patch/10565061/
> https://patchwork.kernel.org/patch/10565063/
>
>
> If you apply those two patches on top of commit
> 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
> It is reported in allmodconfig stage, like this:
>
>
> masahiro@grover:~/ref/linux-next$ make allmodconfig
> HOSTCC scripts/kconfig/conf.o
> YACC scripts/kconfig/zconf.tab.c
> HOSTCC scripts/kconfig/zconf.tab.o
> HOSTLD scripts/kconfig/conf
> scripts/kconfig/conf --allmodconfig Kconfig
> drivers/of/Kconfig:68:error: recursive dependency detected!
> drivers/of/Kconfig:68: symbol OF_IRQ depends on IRQ_DOMAIN
> kernel/irq/Kconfig:63: symbol IRQ_DOMAIN is selected by REGMAP
> drivers/base/regmap/Kconfig:6: symbol REGMAP is selected by SENSORS_ASPEED
> drivers/hwmon/Kconfig:352: symbol SENSORS_ASPEED depends on HWMON
> drivers/hwmon/Kconfig:5: symbol HWMON is implied by SFP
> drivers/net/phy/Kconfig:214: symbol SFP depends on PHYLIB
> drivers/net/phy/Kconfig:181: symbol PHYLIB is selected by ARC_EMAC_CORE
> drivers/net/ethernet/arc/Kconfig:18: symbol ARC_EMAC_CORE is selected
> by ARC_EMAC
> drivers/net/ethernet/arc/Kconfig:24: symbol ARC_EMAC depends on OF_IRQ
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
>
Interesting; I thought that "implied" does not really select the symbol.
That means 'imply' just doesn't work for HWMON, and we'll have to stick
with the old "depends on HWMON || HWMON=n".
Thanks,
Guenter
^ permalink raw reply
* Re: [RFC PATCH net-next V2 6/6] virtio-net: support XDP rx handler
From: Jason Wang @ 2018-08-14 13:01 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: netdev, linux-kernel, ast, daniel, mst
In-Reply-To: <20180814112222.42177a24@redhat.com>
On 2018年08月14日 17:22, Jesper Dangaard Brouer wrote:
> On Mon, 13 Aug 2018 11:17:30 +0800
> Jason Wang<jasowang@redhat.com> wrote:
>
>> This patch tries to add the support of XDP rx handler to
>> virtio-net. This is straight-forward, just call xdp_do_pass() and
>> behave depends on its return value.
>>
>> Test was done by using XDP_DROP (xdp1) for macvlan on top of
>> virtio-net. PPS of SKB mode was ~1.2Mpps while PPS of native XDP mode
>> was ~2.2Mpps. About 83% improvement was measured.
> I'm not convinced...
>
> Why are you not using XDP_REDIRECT, which is already implemented in
> receive_mergeable (which you modify below).
>
> The macvlan driver just need to implement ndo_xdp_xmit(), and then you
> can redirect (with XDP prog from physical driver into the guest). It
> should be much faster...
>
>
Macvlan is different from macvtap. For host RX, macvtap deliver the
packet to a pointer ring which could be accessed through a socket but
macvlan deliver the packet to the normal networking stack. As an example
of XDP rx handler, this series just try to make native XDP works for
macvlan, macvtap path will still go for skb (but it's not hard to add it
on top).
Consider the case of fast forwarding between host and guest. For TAP,
XDP_REDIRECT works perfectly since from the host point of view, host RX
is guest TX and host guest RX is host TX. But for macvtap which is based
on macvlan, transmitting packet to macvtap/macvlan means transmitting
packets to under layer device which is either a physical NIC or another
macvlan device. That's why we can't use XDP_REDIRECT with ndo_xdp_xmit().
Thanks
^ permalink raw reply
* Re: [PATCH 07/10] dt-bindings: phy: add DT binding for Microsemi Ocelot SerDes muxing
From: Alexandre Belloni @ 2018-08-14 12:45 UTC (permalink / raw)
To: Rob Herring
Cc: Quentin Schulz, Florian Fainelli, ralf, paul.burton, jhogan,
mark.rutland, davem, kishon, andrew, linux-mips, devicetree,
linux-kernel, netdev, allan.nielsen, thomas.petazzoni
In-Reply-To: <20180813223748.GA20086@rob-hp-laptop>
On 13/08/2018 16:37:48-0600, Rob Herring wrote:
> > I'm fine with a define for the second value (which is basically the enum
> > serdes_type I've defined at the beginning of the serdes driver) but I
> > don't see the point of defining the index of the SerDes. What would it
> > look like?
> >
> > enum serdes_type {
> > SERDES1G = 1,
> > SERDES6G = 6,
> > }
> >
> > #define SERDES1G_0 0
> > #define SERDES1G_1 1
> > #define SERDES1G_2 2
> > #define SERDES6G_0 0
> > #define SERDES6G_1 1
> >
> > Then, e.g.:
> >
> > &port5 {
> > phys = <&serdes 5 SERDES1G SERDES1G_0>
> > };
> >
> > If you want a define for the pair (serdes_type, serdes_index), I don't
> > see how I could re-use it on the driver side but it makes more sense on the
> > DeviceTree side:
> >
> > #define SERDES1G_0 1 0
> > #define SERDES1G_1 1 1
> > #define SERDES1G_2 1 2
> > #define SERDES6G_0 6 0
> > #define SERDES6G_1 6 1
>
> I prefer #defines which are a single number. Otherwise if you read a dts
> file when #phy-cells is 3, it will look like an error in that you have
> what looks like 2 cells.
>
Maybe we should not have the type in DT and simply have an index. The
driver will now what the serdes type is anyway and the defines would be:
#define SERDES1G_0 0
#define SERDES1G_1 1
#define SERDES1G_2 2
#define SERDES6G_0 3
#define SERDES6G_1 4
The main drawback is that this requires one include file per soc.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next 02/10] dt-bindings: net: ocelot: remove hsio from the list of register address spaces
From: Alexandre Belloni @ 2018-08-14 12:41 UTC (permalink / raw)
To: Quentin Schulz
Cc: Rob Herring, ralf, paul.burton, jhogan, mark.rutland, davem,
kishon, andrew, f.fainelli, linux-mips, devicetree, linux-kernel,
netdev, allan.nielsen, thomas.petazzoni
In-Reply-To: <20180814064953.vboz2gryq4jff34n@qschulz>
On 14/08/2018 08:49:53+0200, Quentin Schulz wrote:
> Understood but it's an intermediate patch. Later (patch 8), the SerDes
> muxing "controller" is added as a child to this node. There most likely
> will be some others in the future (temperature sensor for example).
>
> Furthermore, there's already a simple-mfd without children in this file:
> https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/mips/mscc.txt#L19
>
> How should we handle this case?
>
There were child nodes in previous version of the binding. You can
remove simple-mfd now. The useful registers that are not used by any
drivers are gpr and chipid.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH] dt-bindings: net: ravb: Add support for r8a774a1 SoC
From: Fabrizio Castro @ 2018-08-14 12:33 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: Fabrizio Castro, Sergei Shtylyov, David S. Miller,
Geert Uytterhoeven, Simon Horman, Biju Das, Yoshihiro Shimoda,
netdev, linux-renesas-soc, devicetree, linux-kernel, Simon Horman,
Chris Paterson
Document RZ/G2M (R8A774A1) SoC bindings.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
Documentation/devicetree/bindings/net/renesas,ravb.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt
index 19740d0..da249b7 100644
--- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
+++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
@@ -16,6 +16,7 @@ Required properties:
- "renesas,etheravb-rcar-gen2" as a fallback for the above
R-Car Gen2 and RZ/G1 devices.
+ - "renesas,etheravb-r8a774a1" for the R8A774A1 SoC.
- "renesas,etheravb-r8a7795" for the R8A7795 SoC.
- "renesas,etheravb-r8a7796" for the R8A7796 SoC.
- "renesas,etheravb-r8a77965" for the R8A77965 SoC.
@@ -24,7 +25,7 @@ Required properties:
- "renesas,etheravb-r8a77990" for the R8A77990 SoC.
- "renesas,etheravb-r8a77995" for the R8A77995 SoC.
- "renesas,etheravb-rcar-gen3" as a fallback for the above
- R-Car Gen3 devices.
+ R-Car Gen3 and RZ/G2 devices.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first followed by
--
2.7.4
^ permalink raw reply related
* [PATCH net] cls_matchall: fix tcf_unbind_filter missing
From: Hangbin Liu @ 2018-08-14 9:28 UTC (permalink / raw)
To: netdev; +Cc: David Miller, WANG Cong, Yotam Gigi, Jiri Pirko, Hangbin Liu
Fix tcf_unbind_filter missing in cls_matchall as this will trigger
WARN_ON() in cbq_destroy_class().
Fixes: fd62d9f5c575f ("net/sched: matchall: Fix configuration race")
Reported-by: Li Shuang <shuali@redhat.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/sched/cls_matchall.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/sched/cls_matchall.c b/net/sched/cls_matchall.c
index 47b207e..7ad65da 100644
--- a/net/sched/cls_matchall.c
+++ b/net/sched/cls_matchall.c
@@ -111,6 +111,8 @@ static void mall_destroy(struct tcf_proto *tp, struct netlink_ext_ack *extack)
if (!head)
return;
+ tcf_unbind_filter(tp, &head->res);
+
if (!tc_skip_hw(head->flags))
mall_destroy_hw_filter(tp, head, (unsigned long) head, extack);
--
2.5.5
^ permalink raw reply related
* Re: [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
From: Camille Bordignon @ 2018-08-14 9:14 UTC (permalink / raw)
To: Neftin, Sasha; +Cc: Alexander Duyck, Netdev, intel-wired-lan, David S. Miller
In-Reply-To: <c1e2cf13-6bcc-498d-03ea-7c3792d675cb@intel.com>
Le mercredi 08 août 2018 à 18:00:28 (+0300), Neftin, Sasha a écrit :
> On 8/8/2018 17:24, Neftin, Sasha wrote:
> > On 8/7/2018 09:42, Camille Bordignon wrote:
> > > Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit :
> > > > On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
> > > > <camille.bordignon@easymile.com> wrote:
> > > > > Hello,
> > > > >
> > > > > Recently we experienced some issues with intel NIC (I219-LM
> > > > > and I219-V).
> > > > > It seems that after a wire reconnection, auto-negotation "fails" and
> > > > > link speed drips to 10 Mbps.
> > > > >
> > > > > From kernel logs:
> > > > > [17616.346150] e1000e: enp0s31f6 NIC Link is Down
> > > > > [17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full
> > > > > Duplex, Flow Control: None
> > > > > [17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed:
> > > > > disabling TSO
> > > > >
> > > > >
> > > > > $ethtool enp0s31f6
> > > > > Settings for enp0s31f6:
> > > > > Supported ports: [ TP ]
> > > > > Supported link modes: 10baseT/Half 10baseT/Full
> > > > > 100baseT/Half 100baseT/Full
> > > > > 1000baseT/Full
> > > > > Supported pause frame use: No
> > > > > Supports auto-negotiation: Yes
> > > > > Supported FEC modes: Not reported
> > > > > Advertised link modes: 10baseT/Half 10baseT/Full
> > > > > 100baseT/Half 100baseT/Full
> > > > > 1000baseT/Full
> > > > > Advertised pause frame use: No
> > > > > Advertised auto-negotiation: Yes
> > > > > Advertised FEC modes: Not reported
> > > > > Speed: 10Mb/s
> > > > > Duplex: Full
> > > > > Port: Twisted Pair
> > > > > PHYAD: 1
> > > > > Transceiver: internal
> > > > > Auto-negotiation: on
> > > > > MDI-X: on (auto)
> > > > > Supports Wake-on: pumbg
> > > > > Wake-on: g
> > > > > Current message level: 0x00000007 (7)
> > > > > drv probe link
> > > > > Link detected: yes
> > > > >
> > > > >
> > > > > Notice that if disconnection last less than about 5 seconds,
> > > > > nothing wrong happens.
> > > > > And if after last failure, disconnection / connection occurs again and
> > > > > last less than 5 seconds, link speed is back to 1000 Mbps.
> > > > >
> > > > > [18075.350678] e1000e: enp0s31f6 NIC Link is Down
> > > > > [18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps
> > > > > Full Duplex, Flow Control: None
> > > > >
> > > > > The following patch seems to fix this issue.
> > > > > However I don't clearly understand why.
> > > > >
> > > > > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > b/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > index 3ba0c90e7055..763c013960f1 100644
> > > > > --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > @@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct
> > > > > e1000_adapter *adapter)
> > > > > case e1000_media_type_copper:
> > > > > if (hw->mac.get_link_status) {
> > > > > ret_val = hw->mac.ops.check_for_link(hw);
> > > > > - link_active = !hw->mac.get_link_status;
> > > > > + link_active = false;
> > > > > } else {
> > > > > link_active = true;
> > > > > }
> > > > >
> > > > > Maybe this is related to watchdog task.
> > > > >
> > > > > I've found out this fix by comparing with last commit that works fine :
> > > > > commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
> > > > > However I don't know if this information is relevant.
> > > > >
> > > > > Thank you.
> > > > > Camille Bordignon
> > > >
> > > > What kernel were you testing this on? I know there have been a number
> > > > of changes over the past few months in this area and it would be
> > > > useful to know exactly what code base you started out with and what
> > > > the latest version of the kernel is you have tested.
> > > >
> > > > Looking over the code change the net effect of it should be to add a 2
> > > > second delay from the time the link has changed until you actually
> > > > check the speed/duplex configuration. It is possible we could be
> > > > seeing some sort of timing issue and adding the 2 second delay after
> > > > the link event is enough time for things to stabilize and detect the
> > > > link at 1000 instead of 10/100.
> > > >
> > > > - Alex
> > >
> > > We've found out this issue using Fedora 27 (4.17.11-100.fc27.x86_64).
> > >
> > > Then I've tested wth a more recent version of the driver v4.18-rc7 but
> > > behavior looks the same.
> > >
> > > Thanks for you reply.
> > >
> > > Camille Bordignon
> > > _______________________________________________
> > > Intel-wired-lan mailing list
> > > Intel-wired-lan@osuosl.org
> > > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> > >
> > I've agree with Alex. Let's try add 2s delay after a link event. Please,
> > let us know if it will solve your problem.
> > Also, I would like recommend try work with different link partner and
> > see if you see same problem.
> > _______________________________________________
> > Intel-wired-lan mailing list
> > Intel-wired-lan@osuosl.org
> > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> Camille,
> My apologies, I wrong understand Alex. Please, do not try add delay. Please,
> check if you see same problem with different link partners.
> Thanks,
> Sasha
I tried to reproduce the issue with differents devices.
On computer side :
- HP ZBook 14u G5 (Intel NIC I219-V)
- Dell Tower 3620 (Intel NIC I219-LM)
On network side :
- TP-LINK TL-SG108E
- Advantech EKI-2728I
- Freebox v6 (https://en.wikipedia.org/wiki/Freebox)
It always happens with any configuration.
Thanks.
Camille Bordignon
^ permalink raw reply
* [PATCH net-next] net: dsa: mv88e6xxx: missing unlock on error path
From: Dan Carpenter @ 2018-08-14 9:09 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Vivien Didelot, Florian Fainelli, netdev, kernel-janitors
We added a new error path, but we need to drop the lock before we return.
Fixes: 2d2e1dd29962 ("net: dsa: mv88e6xxx: Cache the port cmode")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 17752316ab10..8da3d39e3218 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2408,7 +2408,7 @@ static int mv88e6xxx_setup(struct dsa_switch *ds)
if (chip->info->ops->port_get_cmode) {
err = chip->info->ops->port_get_cmode(chip, i, &cmode);
if (err)
- return err;
+ goto unlock;
chip->ports[i].cmode = cmode;
}
^ permalink raw reply related
* [PATCH net-next] net: dsa: mv88e6xxx: bitwise vs logical bug
From: Dan Carpenter @ 2018-08-14 9:06 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vivien Didelot, Florian Fainelli, David S. Miller, netdev,
kernel-janitors
We are trying to test if these flags are set but there are some && vs &
typos.
Fixes: efd1ba6af93f ("net: dsa: mv88e6xxx: Add SERDES phydev_mac_change up for 6390")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c b/drivers/net/dsa/mv88e6xxx/serdes.c
index f007d109b385..e82983975754 100644
--- a/drivers/net/dsa/mv88e6xxx/serdes.c
+++ b/drivers/net/dsa/mv88e6xxx/serdes.c
@@ -502,8 +502,8 @@ static irqreturn_t mv88e6390_serdes_thread_fn(int irq, void *dev_id)
err = mv88e6390_serdes_irq_status_sgmii(chip, lane, &status);
if (err)
goto out;
- if (status && (MV88E6390_SGMII_INT_LINK_DOWN ||
- MV88E6390_SGMII_INT_LINK_UP)) {
+ if (status & (MV88E6390_SGMII_INT_LINK_DOWN |
+ MV88E6390_SGMII_INT_LINK_UP)) {
ret = IRQ_HANDLED;
mv88e6390_serdes_irq_link_sgmii(chip, port->port, lane);
}
^ permalink raw reply related
* Re: [PATCH net 2/2] net/mlx5e: Cleanup of dcbnl related fields
From: Yuval Shaia @ 2018-08-14 9:01 UTC (permalink / raw)
To: Saeed Mahameed, Haakon Bugge
Cc: David S. Miller, netdev, Huy Nguyen, yuval.shaia
In-Reply-To: <20180808224808.12600-3-saeedm@mellanox.com>
On Wed, Aug 08, 2018 at 03:48:08PM -0700, Saeed Mahameed wrote:
> From: Huy Nguyen <huyn@mellanox.com>
>
> Remove unused netdev_registered_init/remove in en.h
> Return ENOSUPPORT if the check MLX5_DSCP_SUPPORTED fails.
s/ENOSUPPORT/EOPNOTSUPP
(noted by Haakon)
> Remove extra white space
>
> Fixes: 2a5e7a1344f4 ("net/mlx5e: Add dcbnl dscp to priority support")
> Signed-off-by: Huy Nguyen <huyn@mellanox.com>
> Cc: Yuval Shaia <yuval.shaia@oracle.com>
> Reviewed-by: Parav Pandit <parav@mellanox.com>
> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 --
> .../ethernet/mellanox/mlx5/core/en_dcbnl.c | 30 +++++++------------
> 2 files changed, 11 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
> index eb9eb7aa953a..405236cf0b04 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
> @@ -858,8 +858,6 @@ struct mlx5e_profile {
> mlx5e_fp_handle_rx_cqe handle_rx_cqe;
> mlx5e_fp_handle_rx_cqe handle_rx_cqe_mpwqe;
> } rx_handlers;
> - void (*netdev_registered_init)(struct mlx5e_priv *priv);
> - void (*netdev_registered_remove)(struct mlx5e_priv *priv);
> int max_tc;
> };
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
> index e33afa8d2417..722998d68564 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
> @@ -443,16 +443,12 @@ static int mlx5e_dcbnl_ieee_setapp(struct net_device *dev, struct dcb_app *app)
> bool is_new;
> int err;
>
> - if (app->selector != IEEE_8021QAZ_APP_SEL_DSCP)
> - return -EINVAL;
> -
> - if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager))
> - return -EINVAL;
> -
> - if (!MLX5_DSCP_SUPPORTED(priv->mdev))
> - return -EINVAL;
> + if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager) ||
> + !MLX5_DSCP_SUPPORTED(priv->mdev))
> + return -EOPNOTSUPP;
>
> - if (app->protocol >= MLX5E_MAX_DSCP)
> + if ((app->selector != IEEE_8021QAZ_APP_SEL_DSCP) ||
> + (app->protocol >= MLX5E_MAX_DSCP))
> return -EINVAL;
>
> /* Save the old entry info */
> @@ -500,16 +496,12 @@ static int mlx5e_dcbnl_ieee_delapp(struct net_device *dev, struct dcb_app *app)
> struct mlx5e_priv *priv = netdev_priv(dev);
> int err;
>
> - if (app->selector != IEEE_8021QAZ_APP_SEL_DSCP)
> - return -EINVAL;
> -
> - if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager))
> - return -EINVAL;
> -
> - if (!MLX5_DSCP_SUPPORTED(priv->mdev))
> - return -EINVAL;
> + if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager) ||
> + !MLX5_DSCP_SUPPORTED(priv->mdev))
> + return -EOPNOTSUPP;
>
> - if (app->protocol >= MLX5E_MAX_DSCP)
> + if ((app->selector != IEEE_8021QAZ_APP_SEL_DSCP) ||
> + (app->protocol >= MLX5E_MAX_DSCP))
> return -EINVAL;
>
> /* Skip if no dscp app entry */
> @@ -1146,7 +1138,7 @@ static int mlx5e_set_trust_state(struct mlx5e_priv *priv, u8 trust_state)
> {
> int err;
>
> - err = mlx5_set_trust_state(priv->mdev, trust_state);
> + err = mlx5_set_trust_state(priv->mdev, trust_state);
> if (err)
> return err;
> priv->dcbx_dp.trust_state = trust_state;
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH net-next][RFC] net/tls: Add support for async decryption of tls records
From: Vakul Garg @ 2018-08-14 14:17 UTC (permalink / raw)
To: netdev; +Cc: borisp, aviadye, davejwatson, davem, Vakul Garg
Incoming TLS records which are directly decrypted into user space
application buffer i.e. records which are decrypted in zero-copy mode
are submitted for async decryption. When the decryption cryptoapi
returns -EINPROGRESS, the next tls record is parsed and then submitted
for decryption. The references to records which has been sent for async
decryption are dropped. This happens in a loop for all the records that
can be decrypted in zero-copy mode. For records for which decryption is
not possible in zero-copy mode, asynchronous decryption is not used and
we wait for decryption crypto api to complete.
For crypto requests executing in async fashion, the memory for
aead_request, sglists and skb etc is freed from the decryption
completion handler. The decryption completion handler wakesup the
sleeping user context. This happens when the user context is done
enqueueing all the crypto requests and is waiting for all the async
operations to finish. Since the splice() operation does not use
zero-copy decryption, async remains disabled for splice().
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
include/net/tls.h | 6 +++
net/tls/tls_sw.c | 134 +++++++++++++++++++++++++++++++++++++++++++++++++-----
2 files changed, 129 insertions(+), 11 deletions(-)
diff --git a/include/net/tls.h b/include/net/tls.h
index d5c683e8bb22..cd0a65bd92f9 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -124,6 +124,12 @@ struct tls_sw_context_rx {
struct sk_buff *recv_pkt;
u8 control;
bool decrypted;
+ atomic_t decrypt_pending;
+ bool async_notify;
+};
+
+struct decrypt_req_ctx {
+ struct sock *sk;
};
struct tls_record_info {
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 52fbe727d7c1..e2f0df18b6cf 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -43,12 +43,50 @@
#define MAX_IV_SIZE TLS_CIPHER_AES_GCM_128_IV_SIZE
+static void tls_decrypt_done(struct crypto_async_request *req, int err)
+{
+ struct aead_request *aead_req = (struct aead_request *)req;
+ struct decrypt_req_ctx *req_ctx =
+ (struct decrypt_req_ctx *)(aead_req + 1);
+
+ struct scatterlist *sgout = aead_req->dst;
+
+ struct tls_context *tls_ctx = tls_get_ctx(req_ctx->sk);
+ struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
+ int pending = atomic_dec_return(&ctx->decrypt_pending);
+ struct scatterlist *sg;
+ unsigned int pages;
+
+ /* Propagate if there was an err */
+ if (err) {
+ ctx->async_wait.err = err;
+ tls_err_abort(req_ctx->sk, err);
+ }
+
+ /* Release the skb, pages and memory allocated for crypto req */
+ kfree_skb(req->data);
+
+ /* Skip the first S/G entry as it points to AAD */
+ for_each_sg(sg_next(sgout), sg, UINT_MAX, pages) {
+ if (!sg)
+ break;
+ put_page(sg_page(sg));
+ }
+
+ kfree(aead_req);
+
+ if (!pending && READ_ONCE(ctx->async_notify))
+ complete(&ctx->async_wait.completion);
+}
+
static int tls_do_decryption(struct sock *sk,
+ struct sk_buff *skb,
struct scatterlist *sgin,
struct scatterlist *sgout,
char *iv_recv,
size_t data_len,
- struct aead_request *aead_req)
+ struct aead_request *aead_req,
+ bool async)
{
struct tls_context *tls_ctx = tls_get_ctx(sk);
struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
@@ -59,10 +97,34 @@ static int tls_do_decryption(struct sock *sk,
aead_request_set_crypt(aead_req, sgin, sgout,
data_len + tls_ctx->rx.tag_size,
(u8 *)iv_recv);
- aead_request_set_callback(aead_req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- crypto_req_done, &ctx->async_wait);
- ret = crypto_wait_req(crypto_aead_decrypt(aead_req), &ctx->async_wait);
+ if (async) {
+ struct decrypt_req_ctx *req_ctx;
+
+ req_ctx = (struct decrypt_req_ctx *)(aead_req + 1);
+ req_ctx->sk = sk;
+
+ aead_request_set_callback(aead_req,
+ CRYPTO_TFM_REQ_MAY_BACKLOG,
+ tls_decrypt_done, skb);
+ atomic_inc(&ctx->decrypt_pending);
+ } else {
+ aead_request_set_callback(aead_req,
+ CRYPTO_TFM_REQ_MAY_BACKLOG,
+ crypto_req_done, &ctx->async_wait);
+ }
+
+ ret = crypto_aead_decrypt(aead_req);
+ if (ret == -EINPROGRESS) {
+ if (async)
+ return ret;
+
+ ret = crypto_wait_req(ret, &ctx->async_wait);
+ }
+
+ if (async)
+ atomic_dec(&ctx->decrypt_pending);
+
return ret;
}
@@ -763,7 +825,10 @@ static int decrypt_internal(struct sock *sk, struct sk_buff *skb,
}
/* Prepare and submit AEAD request */
- err = tls_do_decryption(sk, sgin, sgout, iv, data_len, aead_req);
+ err = tls_do_decryption(sk, skb, sgin, sgout, iv,
+ data_len, aead_req, *zc);
+ if (err == -EINPROGRESS)
+ return err;
/* Release the pages in case iov was mapped to pages */
for (; pages > 0; pages--)
@@ -788,8 +853,12 @@ static int decrypt_skb_update(struct sock *sk, struct sk_buff *skb,
#endif
if (!ctx->decrypted) {
err = decrypt_internal(sk, skb, dest, NULL, chunk, zc);
- if (err < 0)
+ if (err < 0) {
+ if (err == -EINPROGRESS)
+ tls_advance_record_sn(sk, &tls_ctx->rx);
+
return err;
+ }
} else {
*zc = false;
}
@@ -851,6 +920,7 @@ int tls_sw_recvmsg(struct sock *sk,
int target, err = 0;
long timeo;
bool is_kvec = msg->msg_iter.type & ITER_KVEC;
+ int num_async = 0;
flags |= nonblock;
@@ -862,7 +932,10 @@ int tls_sw_recvmsg(struct sock *sk,
target = sock_rcvlowat(sk, flags & MSG_WAITALL, len);
timeo = sock_rcvtimeo(sk, flags & MSG_DONTWAIT);
do {
+ int full_len;
+ int offset;
bool zc = false;
+ bool async = false;
int chunk = 0;
skb = tls_wait_data(sk, flags, timeo, &err);
@@ -870,6 +943,9 @@ int tls_sw_recvmsg(struct sock *sk,
goto recv_end;
rxm = strp_msg(skb);
+ full_len = rxm->full_len;
+ offset = rxm->offset;
+
if (!cmsg) {
int cerr;
@@ -888,7 +964,7 @@ int tls_sw_recvmsg(struct sock *sk,
}
if (!ctx->decrypted) {
- int to_copy = rxm->full_len - tls_ctx->rx.overhead_size;
+ int to_copy = full_len - tls_ctx->rx.overhead_size;
if (!is_kvec && to_copy <= len &&
likely(!(flags & MSG_PEEK)))
@@ -896,42 +972,76 @@ int tls_sw_recvmsg(struct sock *sk,
err = decrypt_skb_update(sk, skb, &msg->msg_iter,
&chunk, &zc);
- if (err < 0) {
+ if (err < 0 && err != -EINPROGRESS) {
tls_err_abort(sk, EBADMSG);
goto recv_end;
}
+
+ if (err == -EINPROGRESS) {
+ async = true;
+ num_async++;
+ goto pick_next_record;
+ }
+
ctx->decrypted = true;
}
if (!zc) {
- chunk = min_t(unsigned int, rxm->full_len, len);
- err = skb_copy_datagram_msg(skb, rxm->offset, msg,
+ chunk = min_t(unsigned int, full_len, len);
+
+ err = skb_copy_datagram_msg(skb, offset, msg,
chunk);
if (err < 0)
goto recv_end;
}
+pick_next_record:
copied += chunk;
len -= chunk;
if (likely(!(flags & MSG_PEEK))) {
u8 control = ctx->control;
- if (tls_sw_advance_skb(sk, skb, chunk)) {
+ if (async) {
+ /* Finished with current record, pick up next */
+ ctx->recv_pkt = NULL;
+ __strp_unpause(&ctx->strp);
+ goto mark_eor_chk_ctrl;
+ } else if (tls_sw_advance_skb(sk, skb, chunk)) {
/* Return full control message to
* userspace before trying to parse
* another message type
*/
+mark_eor_chk_ctrl:
msg->msg_flags |= MSG_EOR;
if (control != TLS_RECORD_TYPE_DATA)
goto recv_end;
+ } else {
+ break;
}
}
+
/* If we have a new message from strparser, continue now. */
if (copied >= target && !ctx->recv_pkt)
break;
} while (len);
recv_end:
+ if (num_async) {
+ /* Wait for all previously submitted records to be decrypted */
+ smp_store_mb(ctx->async_notify, true);
+ if (atomic_read(&ctx->decrypt_pending)) {
+ err = crypto_wait_req(-EINPROGRESS, &ctx->async_wait);
+ if (err) {
+ /* one of async decrypt failed */
+ tls_err_abort(sk, err);
+ copied = 0;
+ }
+ } else {
+ reinit_completion(&ctx->async_wait.completion);
+ }
+ WRITE_ONCE(ctx->async_notify, false);
+ }
+
release_sock(sk);
return copied ? : err;
}
@@ -1271,6 +1381,8 @@ int tls_set_sw_offload(struct sock *sk, struct tls_context *ctx, int tx)
goto free_aead;
if (sw_ctx_rx) {
+ (*aead)->reqsize = sizeof(struct decrypt_req_ctx);
+
/* Set up strparser */
memset(&cb, 0, sizeof(cb));
cb.rcv_msg = tls_queue;
--
2.13.6
^ permalink raw reply related
* [PATCH] 9p/xen: fix check for xenbus_read error in front_probe
From: Dominique Martinet @ 2018-08-14 8:40 UTC (permalink / raw)
To: v9fs-developer
Cc: Dominique Martinet, netdev, Stefano Stabellini,
Eric Van Hensbergen, Latchesar Ionkov
From: Dominique Martinet <dominique.martinet@cea.fr>
If the xen bus exists but does not expose the proper interface, it is
possible to get a non-zero length but still some error, leading to
strcmp failing trying to load invalid memory addresses e.g.
fffffffffffffffe.
There is then no need to check length when there is no error, as the
xenbus driver guarantees that the string is nul-terminated.
Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Latchesar Ionkov <lucho@ionkov.net>
---
This is a trivial bug I stumbled on when setting up xen with p9fs and
running the VM in pvm: it had enough in the bus to trigger the probe
but then there was no version and it tried to return ENOENT but len
was set to the lower-level message size.
net/9p/trans_xen.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 1a5b38892eb4..f76beadddfc3 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -391,9 +391,9 @@ static int xen_9pfs_front_probe(struct xenbus_device *dev,
unsigned int max_rings, max_ring_order, len = 0;
versions = xenbus_read(XBT_NIL, dev->otherend, "versions", &len);
- if (!len)
- return -EINVAL;
+ if (IS_ERR(versions))
+ return PTR_ERR(versions);
if (strcmp(versions, "1")) {
kfree(versions);
return -EINVAL;
}
--
2.17.1
^ permalink raw reply related
* Re: [RFC PATCH net-next V2 0/6] XDP rx handler
From: Jesper Dangaard Brouer @ 2018-08-14 10:17 UTC (permalink / raw)
To: Jason Wang; +Cc: Alexei Starovoitov, netdev, linux-kernel, ast, daniel, mst
In-Reply-To: <5de3d14f-f21a-c806-51f4-b5efd7d809b7@redhat.com>
On Tue, 14 Aug 2018 15:59:01 +0800
Jason Wang <jasowang@redhat.com> wrote:
> On 2018年08月14日 08:32, Alexei Starovoitov wrote:
> > On Mon, Aug 13, 2018 at 11:17:24AM +0800, Jason Wang wrote:
> >> Hi:
> >>
> >> This series tries to implement XDP support for rx hanlder. This would
> >> be useful for doing native XDP on stacked device like macvlan, bridge
> >> or even bond.
> >>
> >> The idea is simple, let stacked device register a XDP rx handler. And
> >> when driver return XDP_PASS, it will call a new helper xdp_do_pass()
> >> which will try to pass XDP buff to XDP rx handler directly. XDP rx
> >> handler may then decide how to proceed, it could consume the buff, ask
> >> driver to drop the packet or ask the driver to fallback to normal skb
> >> path.
> >>
> >> A sample XDP rx handler was implemented for macvlan. And virtio-net
> >> (mergeable buffer case) was converted to call xdp_do_pass() as an
> >> example. For ease comparision, generic XDP support for rx handler was
> >> also implemented.
> >>
> >> Compared to skb mode XDP on macvlan, native XDP on macvlan (XDP_DROP)
> >> shows about 83% improvement.
> > I'm missing the motiviation for this.
> > It seems performance of such solution is ~1M packet per second.
>
> Notice it was measured by virtio-net which is kind of slow.
>
> > What would be a real life use case for such feature ?
>
> I had another run on top of 10G mlx4 and macvlan:
>
> XDP_DROP on mlx4: 14.0Mpps
> XDP_DROP on macvlan: 10.05Mpps
>
> Perf shows macvlan_hash_lookup() and indirect call to
> macvlan_handle_xdp() are the reasons for the number drop. I think the
> numbers are acceptable. And we could try more optimizations on top.
>
> So here's real life use case is trying to have an fast XDP path for rx
> handler based device:
>
> - For containers, we can run XDP for macvlan (~70% of wire speed). This
> allows a container specific policy.
> - For VM, we can implement macvtap XDP rx handler on top. This allow us
> to forward packet to VM without building skb in the setup of macvtap.
> - The idea could be used by other rx handler based device like bridge,
> we may have a XDP fast forwarding path for bridge.
>
> >
> > Another concern is that XDP users expect to get line rate performance
> > and native XDP delivers it. 'generic XDP' is a fallback only
> > mechanism to operate on NICs that don't have native XDP yet.
>
> So I can replace generic XDP TX routine with a native one for macvlan.
If you simply implement ndo_xdp_xmit() for macvlan, and instead use
XDP_REDIRECT, then we are basically done.
> > Toshiaki's veth XDP work fits XDP philosophy and allows
> > high speed networking to be done inside containers after veth.
> > It's trying to get to line rate inside container.
>
> This is one of the goal of this series as well. I agree veth XDP work
> looks pretty fine, but it only work for a specific setup I believe since
> it depends on XDP_REDIRECT which is supported by few drivers (and
> there's no VF driver support).
The XDP_REDIRECT (RX-side) is trivial to add to drivers. It is a bad
argument that only a few drivers implement this. Especially since all
drivers also need to be extended with your proposed xdp_do_pass() call.
(rant) The thing that is delaying XDP_REDIRECT adaption in drivers, is
that it is harder to implement the TX-side, as the ndo_xdp_xmit() call
have to allocate HW TX-queue resources. If we disconnect RX and TX
side of redirect, then we can implement RX-side in an afternoon.
> And in order to make it work for a end
> user, the XDP program still need logic like hash(map) lookup to
> determine the destination veth.
That _is_ the general idea behind XDP and eBPF, that we need to add logic
that determine the destination. The kernel provides the basic
mechanisms for moving/redirecting packets fast, and someone else
builds an orchestration tool like Cilium, that adds the needed logic.
Did you notice that we (Ahern) added bpf_fib_lookup a FIB route lookup
accessible from XDP.
For macvlan, I imagine that we could add a BPF helper that allows you
to lookup/call macvlan_hash_lookup().
> > This XDP rx handler stuff is destined to stay at 1Mpps speeds forever
> > and the users will get confused with forever slow modes of XDP.
> >
> > Please explain the problem you're trying to solve.
> > "look, here I can to XDP on top of macvlan" is not an explanation of the problem.
> >
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: serdev: How to attach serdev devices to USB based tty devices?
From: Oliver Neukum @ 2018-08-14 7:23 UTC (permalink / raw)
To: Andreas Färber, Rob Herring, linux-serial@vger.kernel.org,
linux-usb
Cc: Jian-Hong Pan, Xue Liu, Ben Whitten, Linux-MIPS,
linux-arm-kernel@lists.infradead.org, Stefan Rehm,
LoRa_Community_Support@semtech.com, Alexander Graf, devicetree,
netdev@vger.kernel.org
In-Reply-To: <3639955d-5990-1c82-7158-ac07b33c41f2@suse.de>
On Di, 2018-08-14 at 04:28 +0200, Andreas Färber wrote:
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.
If you really must do this you can benignly fail probe(). Thus you
can compare strings within your probe() method.
This sucks because you need to make sure your drivers are always
loaded in a certain order and you really rely on undocumented
properties, but it can be done.
Regards
Oliver
^ permalink raw reply
* Re: TJA1100 100Base-T1 PHY features via ethtool?
From: Michael Grzeschik @ 2018-08-14 7:13 UTC (permalink / raw)
To: Florian Fainelli; +Cc: davem, netdev, kernel
In-Reply-To: <d7ce5ce0-665e-2b27-72e3-24656999b7c7@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2467 bytes --]
On Mon, Aug 13, 2018 at 12:53:35PM -0700, Florian Fainelli wrote:
> On 08/13/2018 12:35 PM, Michael Grzeschik wrote:
> > Hi David,
> >
> > I use a special 100Base-T1 phy (NXP TJA1100 [1]) that has some features
> > like:
> >
> > - enabling/disabling test modes
> > - fault detection
> > - switching managed/autonomous mode
> > - signal quality indication
> > - ...
> >
> > I already implemented the support of the features with the
> > ethtool --get/set-phy-tunables features by adding ethtool_phy_tunables:
> >
> > ETHTOOL_PHY_TEST_MODE
> > ETHTOOL_PHY_FAULT_DETECTION
> > ETHTOOL_PHY_MANAGED_MODE
> > ETHTOOL_PHY_SIGNAL_QUALITY
> >
> > Before posting my series I wanted to ensure that this is the preferred
> > interface for those options.
>
> The tunable interface is there, but is very limited. A few months ago, I
> had started proposing an interface to support PHY test modes [1] (the
> standard IEEE 802.3 defined ones) but a lot of it should now be migrated
> to the work that Michal is doing on the conversion of ethtool to netlink
> [2].
>
> [1]: https://lkml.org/lkml/2018/4/27/1172
> [2]: https://www.spinics.net/lists/netdev/msg516233.html
The ethtool userspace tool is somehow odd to program on,
so switching to netlink is definitively a great idea!
> >
> > I found a series from 2016 [2] that implements the userspace part for
> > the loopback feature of some phys, that did not get mainline so far
> > which makes me wonder if ethtool is still the way to go.
>
> ethtool is being converted to netlink, and that will be a much more
> flexible interface to work with since it is basically easily extensible
> (unlike the current ethtool + ioctl approach).
Yes, netlink sounds absolutely more useful here.
> Back when the patches were proposed, we just had mild disagreement on
> the loopback terminology being used, and then nothing happened.
Right, thanks for clarification!
>
> >
> > [1] https://www.nxp.com/docs/en/data-sheet/TJA1100.pdf
> > [2] https://www.spinics.net/lists/netdev/msg406614.html
> >
> > Thanks,
> > Michael
> >
>
>
> --
> Florian
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands
From: Dan Carpenter @ 2018-08-14 9:54 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: security, kdeus, Samuel Ortiz, David S. Miller, Allen Pais,
Kees Cook, linux-wireless, netdev, linux-kernel
In-Reply-To: <20180813223910.26276-1-surenb@google.com>
Thanks. This is great. I'm so glad these are finally getting fixed.
Do we need to fix nfc_hci_msg_rx_work() and nfc_hci_recv_from_llc() as
well? In nfc_hci_recv_from_llc() we allow pipe to be NFC_HCI_FRAGMENT
(0x7f) so that's one element beyond the end of the array and the
NFC_HCI_HCP_RESPONSE isn't checked.
Also nci_hci_msg_rx_work() and nci_hci_data_received_cb() use
NCI_HCP_MSG_GET_PIPE() so those could be off by one.
regards,
dan carpenter
^ permalink raw reply
* WARNING: suspicious RCU usage in bpf_prog_array_copy_core
From: syzbot @ 2018-08-14 9:40 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 4110b42356f3 Add linux-next specific files for 20180810
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=109bac02400000
kernel config: https://syzkaller.appspot.com/x/.config?x=1d80606e3795a4f5
dashboard link: https://syzkaller.appspot.com/bug?extid=6e72317008eef84a216b
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=157ef48a400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12e16cf8400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+6e72317008eef84a216b@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
=============================
WARNING: suspicious RCU usage
4.18.0-rc8-next-20180810+ #36 Not tainted
-----------------------------
kernel/bpf/core.c:1582 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syz-executor287/4449:
#0: 00000000d8131c0c (&ctx->mutex){+.+.}, at:
perf_event_ctx_lock_nested+0x375/0x600 kernel/events/core.c:1276
#1: 000000006c916250 (bpf_event_mutex){+.+.}, at:
perf_event_query_prog_array+0x1c6/0x380 kernel/trace/bpf_trace.c:1062
stack backtrace:
CPU: 1 PID: 4449 Comm: syz-executor287 Not tainted
4.18.0-rc8-next-20180810+ #36
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
lockdep_rcu_suspicious+0x14a/0x153 kernel/locking/lockdep.c:4562
bpf_prog_array_copy_core+0x2d9/0x360 kernel/bpf/core.c:1582
bpf_prog_array_copy_info+0x9a/0x110 kernel/bpf/core.c:1720
perf_event_query_prog_array+0x22e/0x380 kernel/trace/bpf_trace.c:1063
_perf_ioctl+0x986/0x1600 kernel/events/core.c:5079
perf_ioctl+0x59/0x80 kernel/events/core.c:5110
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:501 [inline]
do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
__do_sys_ioctl fs/ioctl.c:709 [inline]
__se_sys_ioctl fs/ioctl.c:707 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x440409
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fffc5fc1488 EFLAGS: 00000217 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440409
RDX: 0000000020000180 RSI: 00000000c008240a RDI: 0000000000000003
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000217 R12: 0000000000401c90
R13: 0000000000401d20 R14: 0000000000000000
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [RFC PATCH net-next V2 6/6] virtio-net: support XDP rx handler
From: Jesper Dangaard Brouer @ 2018-08-14 9:22 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, linux-kernel, ast, daniel, mst
In-Reply-To: <1534130250-5302-7-git-send-email-jasowang@redhat.com>
On Mon, 13 Aug 2018 11:17:30 +0800
Jason Wang <jasowang@redhat.com> wrote:
> This patch tries to add the support of XDP rx handler to
> virtio-net. This is straight-forward, just call xdp_do_pass() and
> behave depends on its return value.
>
> Test was done by using XDP_DROP (xdp1) for macvlan on top of
> virtio-net. PPS of SKB mode was ~1.2Mpps while PPS of native XDP mode
> was ~2.2Mpps. About 83% improvement was measured.
I'm not convinced...
Why are you not using XDP_REDIRECT, which is already implemented in
receive_mergeable (which you modify below).
The macvlan driver just need to implement ndo_xdp_xmit(), and then you
can redirect (with XDP prog from physical driver into the guest). It
should be much faster...
> Notes: for RFC, only mergeable buffer case was implemented.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/net/virtio_net.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 62311dd..1e22ad9 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -777,6 +777,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> rcu_read_lock();
> xdp_prog = rcu_dereference(rq->xdp_prog);
> if (xdp_prog) {
> + rx_xdp_handler_result_t ret;
> struct xdp_frame *xdpf;
> struct page *xdp_page;
> struct xdp_buff xdp;
> @@ -825,6 +826,15 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
>
> switch (act) {
> case XDP_PASS:
> + ret = xdp_do_pass(&xdp);
> + if (ret == RX_XDP_HANDLER_DROP)
> + goto drop;
> + if (ret != RX_XDP_HANDLER_FALLBACK) {
> + if (unlikely(xdp_page != page))
> + put_page(page);
> + rcu_read_unlock();
> + goto xdp_xmit;
> + }
> /* recalculate offset to account for any header
> * adjustments. Note other cases do not build an
> * skb and avoid using offset
> @@ -881,6 +891,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> case XDP_ABORTED:
> trace_xdp_exception(vi->dev, xdp_prog, act);
> /* fall through */
> +drop:
> case XDP_DROP:
> if (unlikely(xdp_page != page))
> __free_pages(xdp_page, 0);
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ 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