Re: [RFC PATCH v3 0/3] Enable virtio_net to act as a backup for a passthru device
Tue, Feb 27, 2018 at 02:18:12AM CET, m...@redhat.com wrote: >On Mon, Feb 26, 2018 at 05:02:18PM -0800, Stephen Hemminger wrote: >> On Mon, 26 Feb 2018 08:19:24 +0100 >> Jiri Pirko wrote: >> >> > Sat, Feb 24, 2018 at 12:59:04AM CET, step...@networkplumber.org wrote: >> > >On Thu, 22 Feb 2018 13:30:12 -0800 >> > >Alexander Duyck wrote: >> > > >> > >> > Again, I undertand your motivation. Yet I don't like your solution. >> > >> > But if the decision is made to do this in-driver bonding. I would like >> > >> > to see it baing done some generic way: >> > >> > 1) share the same "in-driver bonding core" code with netvsc >> > >> >put to net/core. >> > >> > 2) the "in-driver bonding core" will strictly limit the functionality, >> > >> >like active-backup mode only, one vf, one backup, vf netdev type >> > >> >check (so noone could enslave a tap or anything else) >> > >> > If user would need something more, he should employ team/bond. >> > > >> > >Sharing would be good, but netvsc world would really like to only have >> > >one visible network device. >> > >> > Why do you mind? All would be the same, there would be just another >> > netdevice unused by the vm user (same as the vf netdev). >> > >> >> I mind because our requirement is no changes to userspace. >> No special udev rules, no bonding script, no setup. > >Agreed. It is mostly fine from this point of view, except that you need >to know to skip the slaves. Maybe we could look at some kind of >trick e.g. pretending link is down for slaves? :O Another hack. Please, don't. > >> Things like cloudinit running on current distro's expect to see a single >> eth0. The VF device show up can also be an issue because distro's have >> stupid rules like Network Manager trying to start DHCP on every interface. >> We deal with that now by doing stuff like udev rules to get it to stop >> but that is still causing user errors. So that means that with an extra netdev for "virtio_net bypass" you will face exactly the same problems. Should not be an issue for you then. > >So the ideal of a single net device isn't achieved by netvsc. > >Since you have scripts to skip the PT device, can't they >hind the PV slave too? How do they identify the device to skip? > >I agree it would be nice to have a way to hide the extra netdev >from userspace. "A hidden netdevice", hmm. I believe that instead of doing hacks like this, we should fix userspace to treat particular netdevices correctly. > >The benefit of the separation is that each slave device can >be configured with e.g. its own native ethtool commands for >optimum performance. > >-- >MST
Re: [PATCH] DT: net: renesas,ravb: document R8A77980 bindings
On Mon, Feb 26, 2018 at 03:10:51PM -0500, David Miller wrote: > From: Simon Horman > Date: Mon, 26 Feb 2018 11:58:24 +0100 > > > On Sat, Feb 24, 2018 at 09:53:17PM -0500, David Miller wrote: > >> From: Sergei Shtylyov > >> Date: Sat, 24 Feb 2018 21:01:15 +0300 > >> > >> > On 02/01/2018 11:13 PM, Sergei Shtylyov wrote: > >> > > >> >> Renesas R-Car V3H (R8A77980) SoC has the R-Car gen3 compatible EtherAVB > >> >> device, so document the SoC specific bindings. > >> >> > >> >> Signed-off-by: Sergei Shtylyov > >> >> > >> >> --- > >> >> The patch is against DaveM's 'net-next.git' repo but I wouldn't mind if > >> >> it's > >> >> applied to 'net.git' instead. :-) > >> > > >> >David, I see this patch was marked as "not applicable" in patchwork. > >> > Why, because > >> > it was posted during the merge window? > >> > >> No because I thought the relevant architecture tree would take a mere > >> DT update. > > > > Hi Dave, > > > > I am happy to take these kinds of changes for the ravb and sh_eth drivers > > if that is your preference. I am also just as happy for you to take them, > > which I think has been the case for similar changes in the past. > > No, it's not a problem. Applied to 'net', thanks. Great, thanks.
Re: [PATCH 0/8] R-Car M3-N: Enable EtherAVB device node
Hi Geert,
On Mon, Feb 26, 2018 at 07:28:47PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi
> wrote:
> > as discussed with you Sergei and Geert, in order to enable EtherAVB for
> > R8A77965 we first wanted to make the phy-mode "rgmii-txid" a board specific
> > property for all other SoCs.
>
> Thanks for your series!
>
> > This series adds the phy-mode property to salvator-common.dtsi and reset
> > the
> > one for R8A77965/R8A7796/R8A77995 to "rgmii".
>
> I forgot that r8a7795.dtsi and r8a7796.dtsi are used for the ULCB boards, too.
> So to avoid regressions, you need to make a similar change to ulcb.dtsi like
> you
> made for salvator-common.dtsi.
>
> In addition, r8a77995.dtsi is only used for the Draak board.
> So you have to update r8a7795-draak.dtsi first, too.
Of course! I forgot about ULCB (and had a patch for Draak I lost while
rebasing :/ )
>
> > Then, in order to enable EtherAVB for R-Car M3-N, iommu nodes had to be
> > added
> > as they are referenced by the "avb" device node (CC the iommu list for the
> > series for that reason).
>
> I don't think we need the iommu properties and nodes at this early stage.
> Ethernet works fine without them. Simon, do you agree?
I'll wait for Simon reply and then resend, possibly without iommu and
ULCB and Draak patches!
Thanks
j
>
> P.S. scripts/dtc/dtx_diff is a great tool to compare DTBs before and after
> your
> changes. It would have revealed the changes for ULCB and Draak.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [PATCH 0/8] R-Car M3-N: Enable EtherAVB device node
On Tue, Feb 27, 2018 at 09:28:38AM +0100, jacopo mondi wrote: > Hi Geert, > > On Mon, Feb 26, 2018 at 07:28:47PM +0100, Geert Uytterhoeven wrote: > > Hi Jacopo, > > > > On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi > > wrote: > > > as discussed with you Sergei and Geert, in order to enable EtherAVB for > > > R8A77965 we first wanted to make the phy-mode "rgmii-txid" a board > > > specific > > > property for all other SoCs. > > > > Thanks for your series! > > > > > This series adds the phy-mode property to salvator-common.dtsi and reset > > > the > > > one for R8A77965/R8A7796/R8A77995 to "rgmii". > > > > I forgot that r8a7795.dtsi and r8a7796.dtsi are used for the ULCB boards, > > too. > > So to avoid regressions, you need to make a similar change to ulcb.dtsi > > like you > > made for salvator-common.dtsi. > > > > In addition, r8a77995.dtsi is only used for the Draak board. > > So you have to update r8a7795-draak.dtsi first, too. > > Of course! I forgot about ULCB (and had a patch for Draak I lost while > rebasing :/ ) > > > > > Then, in order to enable EtherAVB for R-Car M3-N, iommu nodes had to be > > > added > > > as they are referenced by the "avb" device node (CC the iommu list for the > > > series for that reason). > > > > I don't think we need the iommu properties and nodes at this early stage. > > Ethernet works fine without them. Simon, do you agree? > > I'll wait for Simon reply and then resend, possibly without iommu and > ULCB and Draak patches! I don't feel strongly about this but I don't think iommu is a strict dependency of enabling Ethernet and I think its good not to include extra dependencies - if it was me I'd try to get Ethernet accepted then follow-up on iommu.
Re: [RFC PATCH v3 0/3] Enable virtio_net to act as a backup for a passthru device
Tue, Feb 20, 2018 at 05:04:29PM CET, alexander.du...@gmail.com wrote: >On Tue, Feb 20, 2018 at 2:42 AM, Jiri Pirko wrote: >> Fri, Feb 16, 2018 at 07:11:19PM CET, sridhar.samudr...@intel.com wrote: >>>Patch 1 introduces a new feature bit VIRTIO_NET_F_BACKUP that can be >>>used by hypervisor to indicate that virtio_net interface should act as >>>a backup for another device with the same MAC address. >>> >>>Ppatch 2 is in response to the community request for a 3 netdev >>>solution. However, it creates some issues we'll get into in a moment. >>>It extends virtio_net to use alternate datapath when available and >>>registered. When BACKUP feature is enabled, virtio_net driver creates >>>an additional 'bypass' netdev that acts as a master device and controls >>>2 slave devices. The original virtio_net netdev is registered as >>>'backup' netdev and a passthru/vf device with the same MAC gets >>>registered as 'active' netdev. Both 'bypass' and 'backup' netdevs are >>>associated with the same 'pci' device. The user accesses the network >>>interface via 'bypass' netdev. The 'bypass' netdev chooses 'active' netdev >>>as default for transmits when it is available with link up and running. >> >> Sorry, but this is ridiculous. You are apparently re-implemeting part >> of bonding driver as a part of NIC driver. Bond and team drivers >> are mature solutions, well tested, broadly used, with lots of issues >> resolved in the past. What you try to introduce is a weird shortcut >> that already has couple of issues as you mentioned and will certanly >> have many more. Also, I'm pretty sure that in future, someone comes up >> with ideas like multiple VFs, LACP and similar bonding things. > >The problem with the bond and team drivers is they are too large and >have too many interfaces available for configuration so as a result >they can really screw this interface up. > >Essentially this is meant to be a bond that is more-or-less managed by >the host, not the guest. We want the host to be able to configure it >and have it automatically kick in on the guest. For now we want to >avoid adding too much complexity as this is meant to be just the first >step. Trying to go in and implement the whole solution right from the >start based on existing drivers is going to be a massive time sink and >will likely never get completed due to the fact that there is always >going to be some other thing that will interfere. > >My personal hope is that we can look at doing a virtio-bond sort of >device that will handle all this as well as providing a communication >channel, but that is much further down the road. For now we only have >a single bit so the goal for now is trying to keep this as simple as >possible. I have another usecase that would require the solution to be different then what you suggest. Consider following scenario: - baremetal has 2 sr-iov nics - there is a vm, has 1 VF from each nics: vf0, vf1. No virtio_net - baremetal would like to somehow tell the VM to bond vf0 and vf1 together and how this bonding should be configured, according to how the VF representors are configured on the baremetal (LACP for example) The baremetal could decide to remove any VF during the VM runtime, it can add another VF there. For migration, it can add virtio_net. The VM should be inctructed to bond all interfaces together according to how baremetal decided - as it knows better. For this we need a separate communication channel from baremetal to VM (perhaps something re-usable already exists), we need something to listen to the events coming from this channel (kernel/userspace) and to react accordingly (create bond/team, enslave, etc). Now the question is: is it possible to merge the demands you have and the generic needs I described into a single solution? From what I see, that would be quite hard/impossible. So at the end, I think that we have to end-up with 2 solutions: 1) virtio_net, netvsc in-driver bonding - very limited, stupid, 0config solution that works for all (no matter what OS you use in VM) 2) team/bond solution with assistance of preferably userspace daemon getting info from baremetal. This is not 0config, but minimal config - user just have to define this "magic bonding" should be on. This covers all possible usecases, including multiple VFs, RDMA, etc. Thoughts?
Re: [PATCH] test_bpf: add a schedule point
On 02/27/2018 01:12 AM, Eric Dumazet wrote: > On Mon, 2018-02-26 at 21:11 +0100, Daniel Borkmann wrote: >> On 02/26/2018 07:52 PM, Eric Dumazet wrote: >>> From: Eric Dumazet >>> >>> test_bpf() is taking 1.6 seconds nowadays, it is time >>> to add a schedule point in it. >>> >>> Signed-off-by: Eric Dumazet >> >> Applied to bpf tree, thanks Eric! > > Thanks Daniel > > Note that some BPF programs are quite expensive > > [ 173.447471] test_bpf: #264 BPF_MAXINSNS: Call heavy transformations > jited:1 19248 18548 PASS > jited:1 12519 PASS > [ 173.509228] test_bpf: #269 BPF_MAXINSNS: ld_abs+get_processor_id jited:1 > 20896 PASS > > So we can still consume ~200 ms per test, without cond_resched() > > Maybe reducing MAX_TESTRUNS from 1 to 1000 would be the next step ? Yeah, that's totally fine with me, please feel free to send a patch. Another step on todo is to reduce the test cases from test_bpf and move them into the test_verifier's run-time testing where applicable. Would be nice if at some point we can get rid of test_bpf and have everything consolidated within test_verifier.
Re: [PATCH RFC 1/2] virtio: introduce packed ring defines
On Fri, Feb 23, 2018 at 07:18:00PM +0800, Tiwei Bie wrote:
Signed-off-by: Tiwei Bie
---
include/uapi/linux/virtio_config.h | 18 +-
include/uapi/linux/virtio_ring.h | 68 ++
2 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/virtio_config.h
b/include/uapi/linux/virtio_config.h
index 308e2096291f..e3d077ef5207 100644
--- a/include/uapi/linux/virtio_config.h
+++ b/include/uapi/linux/virtio_config.h
@@ -49,7 +49,7 @@
* transport being used (eg. virtio_ring), the rest are per-device feature
* bits. */
#define VIRTIO_TRANSPORT_F_START28
-#define VIRTIO_TRANSPORT_F_END 34
+#define VIRTIO_TRANSPORT_F_END 37
#ifndef VIRTIO_CONFIG_NO_LEGACY
/* Do we get callbacks when the ring is completely used, even if we've
@@ -71,4 +71,20 @@
* this is for compatibility with legacy systems.
*/
#define VIRTIO_F_IOMMU_PLATFORM 33
+
+/* This feature indicates support for the packed virtqueue layout. */
+#define VIRTIO_F_RING_PACKED 34
Spec says VIRTIO_F_PACKED_RING not RING_PACKED
+
+/*
+ * This feature indicates that all buffers are used by the device
+ * in the same order in which they have been made available.
+ */
+#define VIRTIO_F_IN_ORDER 35
+
+/*
+ * This feature indicates that drivers pass extra data (besides
+ * identifying the Virtqueue) in their device notifications.
+ */
+#define VIRTIO_F_NOTIFICATION_DATA 36
+
#endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */
diff --git a/include/uapi/linux/virtio_ring.h b/include/uapi/linux/virtio_ring.h
index 6d5d5faa989b..77b1d4aeef72 100644
--- a/include/uapi/linux/virtio_ring.h
+++ b/include/uapi/linux/virtio_ring.h
@@ -44,6 +44,9 @@
/* This means the buffer contains a list of buffer descriptors. */
#define VRING_DESC_F_INDIRECT 4
+#define VRING_DESC_F_AVAIL(b) ((b) << 7)
+#define VRING_DESC_F_USED(b) ((b) << 15)
+
/* The Host uses this in used->flags to advise the Guest: don't kick me when
* you add a buffer. It's unreliable, so it's simply an optimization. Guest
* will still kick if it's out of buffers. */
@@ -104,6 +107,36 @@ struct vring {
struct vring_used *used;
};
+struct vring_packed_desc_event {
+ /* Descriptor Event Offset */
+ __virtio16 desc_event_off : 15,
+ /* Descriptor Event Wrap Counter */
+ desc_event_wrap : 1;
+ /* Descriptor Event Flags */
+ __virtio16 desc_event_flags : 2;
+};
Where would the virtqueue number go in driver notifications?
regards,
Jens
Re: [PATCH net-next 0/5] Modernize bitbanged GPIO MDIO
On Sun, Feb 25, 2018 at 8:08 PM, Andrew Lunn wrote: > On Sun, Feb 25, 2018 at 01:51:27PM +0100, Linus Walleij wrote: >> This kills off the platform data support from the bitbanged >> GPIO-based MDIO driver and moves it over to using GPIO >> descriptors exclusively. > > Hi Linus > > I like where this ends up. I wounder about the path it takes to get > there. There seems to be quite a lot of code which gets moved around > and then in the end deleted. Maybe changing the order of the patches > would help. Converting to devm_gpiod_get_index() first would remove > all the active_low flags. Then remove all the unused reset callback, > irq, etc? It's mainly a matter of which order we want bisects to end up... I was thinking to order the patches from least-likely to cause regressions to most-likely to cause regressions so that it is later possible to revert the more likely regression cause without getting into conflict with the rest. Yours, Linus Walleij
Re: [PATCH RFC 2/2] vhost: packed ring support
On Wed, Feb 14, 2018 at 10:37:09AM +0800, Jason Wang wrote:
[...]
> +static void set_desc_used(struct vhost_virtqueue *vq,
> + struct vring_desc_packed *desc, bool wrap_counter)
> +{
> + __virtio16 flags = desc->flags;
> +
> + if (wrap_counter) {
> + desc->flags |= cpu_to_vhost16(vq, DESC_AVAIL);
> + desc->flags |= cpu_to_vhost16(vq, DESC_USED);
> + } else {
> + desc->flags &= ~cpu_to_vhost16(vq, DESC_AVAIL);
> + desc->flags &= ~cpu_to_vhost16(vq, DESC_USED);
> + }
> +
> + desc->flags = flags;
The `desc->flags` is restored after the change.
> +}
> +
> +static int vhost_get_vq_desc_packed(struct vhost_virtqueue *vq,
> + struct iovec iov[], unsigned int iov_size,
> + unsigned int *out_num, unsigned int *in_num,
> + struct vhost_log *log,
> + unsigned int *log_num)
> +{
> + struct vring_desc_packed desc;
> + int ret, access, i;
> + u16 avail_idx = vq->last_avail_idx;
> +
> + /* When we start there are none of either input nor output. */
> + *out_num = *in_num = 0;
> + if (unlikely(log))
> + *log_num = 0;
> +
> + do {
> + unsigned int iov_count = *in_num + *out_num;
> +
> + i = vq->last_avail_idx & (vq->num - 1);
The queue size may not be a power of 2 in packed ring.
Best regards,
Tiwei Bie
[PATCH net-next] net: mvpp2: Add hardware offloading for VLAN filtering
Marvell PPv2 controller allows for generic packet filtering. This commit
adds entries to implement VLAN filtering. The approach taken is :
- Filter entries that would match on the presence of the VLAN tag
(existing VLAN detection, DSA / EDSA detection) will set the next
lookup ID to be for the VID.
- For each VLAN existing on a given port, we add an entry that matches
this specific VID. If the incoming packet matches the VID entry, it is
set for the next lookup in the chain (LU_L2).
- A Guard entry is added for each port, that will match if the incoming
packet didn't match any of the above VID entries. This entry tags the
packet to be dropped.
Due to this design, and the fact that the total 256 filter entries are
also used for other purposes, we have a limit of 10 VLANs per port. To
accommodate the case where we would need more VLANS on one port, this
patch implements the ndo_set_features to allow for disabling of VLAN
filtering using ethtool.
The default config has VLAN filtering disabled.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2.c | 414 ---
1 file changed, 380 insertions(+), 34 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
index 5a1668cdb461..6f8b81055b85 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -65,6 +65,10 @@
#define MVPP2_RXQ_PACKET_OFFSET_MASK 0x7000
#define MVPP2_RXQ_DISABLE_MASK BIT(31)
+/* Top Registers */
+#define MVPP2_MH_REG(port) (0x5040 + 4 * (port))
+#define MVPP2_DSA_EXTENDED BIT(5)
+
/* Parser Registers */
#define MVPP2_PRS_INIT_LOOKUP_REG 0x1000
#define MVPP2_PRS_PORT_LU_MAX 0xf
@@ -473,6 +477,7 @@
#define MVPP2_ETH_TYPE_LEN 2
#define MVPP2_PPPOE_HDR_SIZE 8
#define MVPP2_VLAN_TAG_LEN 4
+#define MVPP2_VLAN_TAG_EDSA_LEN8
/* Lbtd 802.3 type */
#define MVPP2_IP_LBDT_TYPE 0xfffa
@@ -609,35 +614,64 @@ enum mvpp2_tag_type {
#define MVPP2_PRS_TCAM_LU_BYTE 20
#define MVPP2_PRS_TCAM_EN_OFFS(offs) ((offs) + 2)
#define MVPP2_PRS_TCAM_INV_WORD5
+
+#define MVPP2_PRS_VID_TCAM_BYTE 2
+
+/* There is a TCAM range reserved for VLAN filtering entries, range size is 33
+ * 10 VLAN ID filter entries per port
+ * 1 default VLAN filter entry per port
+ * It is assumed that there are 3 ports for filter, not including loopback port
+ */
+#define MVPP2_PRS_VLAN_FILT_MAX11
+#define MVPP2_PRS_VLAN_FILT_RANGE_SIZE 33
+
+#define MVPP2_PRS_VLAN_FILT_MAX_ENTRY (MVPP2_PRS_VLAN_FILT_MAX - 2)
+#define MVPP2_PRS_VLAN_FILT_DFLT_ENTRY (MVPP2_PRS_VLAN_FILT_MAX - 1)
+
/* Tcam entries ID */
#define MVPP2_PE_DROP_ALL 0
#define MVPP2_PE_FIRST_FREE_TID1
-#define MVPP2_PE_LAST_FREE_TID (MVPP2_PRS_TCAM_SRAM_SIZE - 31)
+
+/* VLAN filtering range */
+#define MVPP2_PE_VID_FILT_RANGE_END (MVPP2_PRS_TCAM_SRAM_SIZE - 31)
+#define MVPP2_PE_VID_FILT_RANGE_START (MVPP2_PE_VID_FILT_RANGE_END - \
+MVPP2_PRS_VLAN_FILT_RANGE_SIZE + 1)
+#define MVPP2_PE_LAST_FREE_TID (MVPP2_PE_VID_FILT_RANGE_START - 1)
#define MVPP2_PE_IP6_EXT_PROTO_UN (MVPP2_PRS_TCAM_SRAM_SIZE - 30)
#define MVPP2_PE_MAC_MC_IP6(MVPP2_PRS_TCAM_SRAM_SIZE - 29)
#define MVPP2_PE_IP6_ADDR_UN (MVPP2_PRS_TCAM_SRAM_SIZE - 28)
#define MVPP2_PE_IP4_ADDR_UN (MVPP2_PRS_TCAM_SRAM_SIZE - 27)
#define MVPP2_PE_LAST_DEFAULT_FLOW (MVPP2_PRS_TCAM_SRAM_SIZE - 26)
-#define MVPP2_PE_FIRST_DEFAULT_FLOW(MVPP2_PRS_TCAM_SRAM_SIZE - 19)
-#define MVPP2_PE_EDSA_TAGGED (MVPP2_PRS_TCAM_SRAM_SIZE - 18)
-#define MVPP2_PE_EDSA_UNTAGGED (MVPP2_PRS_TCAM_SRAM_SIZE - 17)
-#define MVPP2_PE_DSA_TAGGED(MVPP2_PRS_TCAM_SRAM_SIZE - 16)
-#define MVPP2_PE_DSA_UNTAGGED (MVPP2_PRS_TCAM_SRAM_SIZE - 15)
-#define MVPP2_PE_ETYPE_EDSA_TAGGED (MVPP2_PRS_TCAM_SRAM_SIZE - 14)
-#define MVPP2_PE_ETYPE_EDSA_UNTAGGED (MVPP2_PRS_TCAM_SRAM_SIZE - 13)
-#define MVPP2_PE_ETYPE_DSA_TAGGED (MVPP2_PRS_TCAM_SRAM_SIZE - 12)
-#define MVPP2_PE_ETYPE_DSA_UNTAGGED(MVPP2_PRS_TCAM_SRAM_SIZE - 11)
-#define MVPP2_PE_MH_DEFAULT(MVPP2_PRS_TCAM_SRAM_SIZE - 10)
-#define MVPP2_PE_DSA_DEFAULT (MVPP2_PRS_TCAM_SRAM_SIZE - 9)
-#define MVPP2_PE_IP6_PROTO_UN (MVPP2_PRS_TCAM_SRAM_SIZE - 8)
-#define MVPP2_PE_IP4_PROTO_UN (MVPP2_PRS_TCAM_SRAM_SIZE - 7)
-#define MVPP2_PE_ETH_TYPE_UN (MVPP2_PRS_TCAM_SRAM_SIZE - 6)
+#define MVPP2_PE_FIRST_DEFAULT_FLOW(MVPP2_PRS_TCAM_SRAM_SIZE - 21)
+#define MVPP2_PE_EDSA_TAGGED (MVPP2_PRS_TCAM_SRAM_SIZE - 20)
+#define MVPP2_PE_EDSA_UNTAGGED (MVPP2_PRS_TCAM_SRAM_SIZE - 19)
+#define MVPP2_PE_DSA_TAGGED(MVPP2_PRS_
Re: [PATCH RFC 1/2] virtio: introduce packed ring defines
On Tue, Feb 27, 2018 at 09:54:58AM +0100, Jens Freimann wrote: On Fri, Feb 23, 2018 at 07:18:00PM +0800, Tiwei Bie wrote: Signed-off-by: Tiwei Bie --- include/uapi/linux/virtio_config.h | 18 +- include/uapi/linux/virtio_ring.h | 68 ++ 2 files changed, 85 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/virtio_config.h b/include/uapi/linux/virtio_config.h index 308e2096291f..e3d077ef5207 100644 --- a/include/uapi/linux/virtio_config.h +++ b/include/uapi/linux/virtio_config.h @@ -49,7 +49,7 @@ * transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 37 #ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've @@ -71,4 +71,20 @@ * this is for compatibility with legacy systems. */ #define VIRTIO_F_IOMMU_PLATFORM 33 + +/* This feature indicates support for the packed virtqueue layout. */ +#define VIRTIO_F_RING_PACKED 34 Spec says VIRTIO_F_PACKED_RING not RING_PACKED Ignore this. Seems to have changed. regards, Jens
RE: [PATCH RFC 1/2] virtio: introduce packed ring defines
From: Tiwei Bie
> Sent: 23 February 2018 11:18
...
> +struct vring_packed_desc_event {
> + /* Descriptor Event Offset */
> + __virtio16 desc_event_off : 15,
> + /* Descriptor Event Wrap Counter */
> +desc_event_wrap : 1;
> + /* Descriptor Event Flags */
> + __virtio16 desc_event_flags : 2;
> +};
This looks like you are assuming that a bit-field has a defined
layout and can be used to map a 'hardware' structure.
The don't, don't use them like that.
David
Re: [net-next v3 0/2] eBPF seccomp filters
On 02/27/2018 01:01 AM, Sargun Dhillon wrote: > On Mon, Feb 26, 2018 at 3:04 PM, Alexei Starovoitov > wrote: >> On Mon, Feb 26, 2018 at 07:26:54AM +, Sargun Dhillon wrote: >>> This patchset enables seccomp filters to be written in eBPF. Although, this >>> patchset doesn't introduce much of the functionality enabled by eBPF, it >>> lays >>> the ground work for it. Currently, you have to disable CHECKPOINT_RESTORE >>> support in order to utilize eBPF seccomp filters, as eBPF filters cannot be >>> retrieved via the ptrace GET_FILTER API. >> >> this was discussed multiple times in the past. >> In eBPF land it's practically impossible to do checkpoint/restore >> of the whole bpf program/map graph. >> >>> Any user can load a bpf seccomp filter program, and it can be pinned and >>> reused without requiring access to the bpf syscalls. A user only requires >>> the traditional permissions of either being cap_sys_admin, or have >>> no_new_privs set in order to install their rule. >>> >>> The primary reason for not adding maps support in this patchset is >>> to avoid introducing new complexities around PR_SET_NO_NEW_PRIVS. >>> If we have a map that the BPF program can read, it can potentially >>> "change" privileges after running. It seems like doing writes only >>> is safe, because it can be pure, and side effect free, and therefore >>> not negatively effect PR_SET_NO_NEW_PRIVS. Nonetheless, if we come >>> to an agreement, this can be in a follow-up patchset. >> >> readonly maps already exist. See BPF_F_RDONLY. >> Is that not enough? >> > With BPF_F_RDONLY, is there a mechanism to populate a prog_array, and > then mark it rd_only? This would still need to be extended for this purpose. Right now this is either set on map creation (e.g. such that only prog itself can update the entries) or obj_get. So you'd need a mechanism that sets flags into rdonly mode where once set it cannot be undone anymore for the remaining lifetime of the map. >>> A benchmark of this patchset is as follows for a very standard eBPF filter: >>> >>> Given this test program: >>> for (i = 10; i < ; i++) syscall(__NR_getpid); >>> >>> If I implement an eBPF filter with PROG_ARRAYs with a program per syscall, >>> and tail call, the numbers are such: >>> ebpf JIT 12.3% slower than native >>> ebpf no JIT 13.6% slower than native >>> seccomp JIT 17.6% slower than native >>> seccomp no JIT 37% slower than native >> >> the perf gains are misleading, since patches don't enable bpf_tail_call. >> >> The main statement I want to hear from seccomp maintainers before >> proceeding any further on this that enabling eBPF in seccomp won't lead >> to seccomp folks arguing against changes in bpf core (like verifier) >> just because it's used by seccomp. >> It must be spelled out in the commit log with explicit Ack. Fully agree.
Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw
I've problem when using OpenWrt/LEDE on a home router with Broadcom's FullMAC WiFi chipset. First of all OpenWrt/LEDE uses bridge interface for LAN network with: 1) IFLA_BRPORT_MCAST_TO_UCAST 2) Clients isolation in hostapd 3) Hairpin mode enabled For more details please see Linus's patch description: https://patchwork.kernel.org/patch/9530669/ and maybe hairpin mode patch: https://lwn.net/Articles/347344/ Short version: in that setup packets received from a bridged wireless interface can be handled back to it for transmission. Now, Broadcom's firmware for their FullMAC chipsets in AP mode supports an obsoleted 802.11f AKA IAPP standard. It's a roaming standard that was replaced by 802.11r. Whenever a new station associates, firmware generates a packet like: ff ff ff ff ff ff ec 10 7b 5f ?? ?? 00 06 00 01 af 81 01 00 (just masked 2 bytes of my MAC) For mode details you can see discussion in my brcmfmac patch thread: https://patchwork.kernel.org/patch/10191451/ The problem is that bridge (in setup as above) handles such a packet back to the device. That makes Broadcom's FullMAC firmware believe that a given station just connected to another AP in a network (which doesn't even exist). As a result firmware immediately disassociates that station. It's simply impossible to connect to the router. Every association is followed by immediate disassociation. Can you see any solution for this problem? Is that an option to stop multicast-to-unicast from touching 802.11f packets? Some other ideas? Obviously I can't modify Broadcom's firmware and drop that obsoleted standard. -- Rafał
Re: Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw
Sending with a fixed linux-wireless ML address. Please kindly send your replies using linux-wireless@ On 02/27/2018 11:08 AM, Rafał Miłecki wrote: I've problem when using OpenWrt/LEDE on a home router with Broadcom's FullMAC WiFi chipset. First of all OpenWrt/LEDE uses bridge interface for LAN network with: 1) IFLA_BRPORT_MCAST_TO_UCAST 2) Clients isolation in hostapd 3) Hairpin mode enabled For more details please see Linus's patch description: https://patchwork.kernel.org/patch/9530669/ and maybe hairpin mode patch: https://lwn.net/Articles/347344/ Short version: in that setup packets received from a bridged wireless interface can be handled back to it for transmission. Now, Broadcom's firmware for their FullMAC chipsets in AP mode supports an obsoleted 802.11f AKA IAPP standard. It's a roaming standard that was replaced by 802.11r. Whenever a new station associates, firmware generates a packet like: ff ff ff ff ff ff ec 10 7b 5f ?? ?? 00 06 00 01 af 81 01 00 (just masked 2 bytes of my MAC) For mode details you can see discussion in my brcmfmac patch thread: https://patchwork.kernel.org/patch/10191451/ The problem is that bridge (in setup as above) handles such a packet back to the device. That makes Broadcom's FullMAC firmware believe that a given station just connected to another AP in a network (which doesn't even exist). As a result firmware immediately disassociates that station. It's simply impossible to connect to the router. Every association is followed by immediate disassociation. Can you see any solution for this problem? Is that an option to stop multicast-to-unicast from touching 802.11f packets? Some other ideas? Obviously I can't modify Broadcom's firmware and drop that obsoleted standard.
Re: [PATCH iproute2] Fix compilation with kernel headers < 3.4
On Mon, Feb 26, 2018 at 09:46:41PM +0200, Serhey Popovych wrote: > Since commit 596b1c94aa38e21b7a8c8562e8b61ccb744255d2, iproute2 uses types > __kernel_long_t and __kernel_ulong_t but does not provide internal > definitions for it. > > This means that compilation using kernel headers that are older than 3.4 > (where these types were added) will fail. This situation may be uncommon for > native compilation, but not uncommon for cross compilation where the > toolchains may be a bit older. > > Provide the necessary types internally if not provided by the kernel > headers to fix compilation in such cases. > > Co-Developed-by: Serhii Popovych > Signed-off-by: Thomas De Schampheleire > Signed-off-by: Serhey Popovych > --- > include/linux/sysinfo.h | 14 ++ > misc/ss.c | 10 ++ > 2 files changed, 24 insertions(+) > create mode 100644 include/linux/sysinfo.h > > diff --git a/include/linux/sysinfo.h b/include/linux/sysinfo.h > new file mode 100644 > index 000..766de8d > --- /dev/null > +++ b/include/linux/sysinfo.h > @@ -0,0 +1,14 @@ > +#ifndef _SYSINFO_COMPAT_H > +#define _SYSINFO_COMPAT_H > + > +/* In case the kernel header asm/posix_types.h is too old (< 3.4) to provide > + * __kernel_long_t, provide it here > + */ > +#ifndef __kernel_long_t > +typedef long __kernel_long_t; > +typedef unsigned long__kernel_ulong_t; > +#endif > + > +#include_next > + > +#endif /* _SYSINFO_COMPAT_H */ Actually, I now wonder: instead of applying this trick with #include_next on sysinfo.h, why not do it on linux/types.h ? That would be more correct and more robust for the future, no? /Thomas
Re: [PATCH 0/2] mv88e6xxx: Poll when no interrupt defined
Hi Andrew, On jeu., févr. 22 2018, Andrew Lunn wrote: > Not all boards using the mv88e6xxx switches have the interrupt output > connected to a GPIO. On these boards phylib has to poll the PHYs, > rather than use interrupts. Have the driver poll the interrupt status > register, which is more efficient than having phylib do it. And it > enables other switch interrupts to be services. > > The Armada 370RD is such a board without a interrupt GPIO. Now that > interrupts work, wire up the PHYs to make use if them. > > Gregory: Are you O.K. for the second patch to go through netdev? Why do you need that the second patch to go through netdev. Is there any dependency between the 2 patches? If it is the case does it means that an new kernel won't work with an old device tree? Gregory > > Andrew Lunn (2): > net: dsa: mv88e6xxx: Poll when no interrupt defined > arm: mvebu: 370-rd: Enable PHY interrupt handling > > arch/arm/boot/dts/armada-370-rd.dts | 32 > drivers/net/dsa/mv88e6xxx/chip.c| 146 > +--- > drivers/net/dsa/mv88e6xxx/chip.h| 3 + > 3 files changed, 138 insertions(+), 43 deletions(-) > > -- > 2.15.1 > -- Gregory Clement, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering http://bootlin.com
[PATCH v2 09/10] arm64: dts: renesas: r8a77970: Set EtherAVB phy mode to "rgmii"
Set the "phy-mode" property of EtherAVB device to "rgmii" and let board files override it if the installed PHY layer provides delays for the RX/TX channels. Signed-off-by: Jacopo Mondi --- arch/arm64/boot/dts/renesas/r8a77970.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi b/arch/arm64/boot/dts/renesas/r8a77970.dtsi index de84df3..955fded 100644 --- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi @@ -607,7 +607,7 @@ clocks = <&cpg CPG_MOD 812>; power-domains = <&sysc R8A77970_PD_ALWAYS_ON>; resets = <&cpg 812>; - phy-mode = "rgmii-id"; + phy-mode = "rgmii"; iommus = <&ipmmu_rt 3>; #address-cells = <1>; #size-cells = <0>; -- 2.7.4
[PATCH v2 10/10] arm64: dts: renesas: r8a77965: Add EtherAVB device node
Populate the ethernet@e680 device node to enable Ethernet interface
for R-Car M3-N (R8A77965) SoC.
Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
---
v1 -> v2:
- Replace ALWAYS_ON power area identifier with numeric constant
v2 -> v3:
- Send as part of a dedicated series reworking "rgmii" properties in all
mainline Renesas boards/SoC
- Add iommu dependencies
v3 -> v4:
- Remove iommu dependencies
---
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 43 ---
1 file changed, 40 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 8c9648a..1f25934 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -522,11 +522,48 @@
};
avb: ethernet@e680 {
+ compatible = "renesas,etheravb-r8a77965",
+"renesas,etheravb-rcar-gen3";
+ reg = <0 0xe680 0 0x800>, <0 0xe6a0 0 0x1>;
+ interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+ interrupt-names = "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14", "ch15",
+ "ch16", "ch17", "ch18", "ch19",
+ "ch20", "ch21", "ch22", "ch23",
+ "ch24";
+ clocks = <&cpg CPG_MOD 812>;
+ power-domains = <&sysc 32>;
+ resets = <&cpg 812>;
+ phy-mode = "rgmii";
#address-cells = <1>;
#size-cells = <0>;
-
- reg = <0 0xe680 0 0x800>, <0 0xe6a0 0 0x1>;
- /* placeholder */
+ status = "disabled";
};
csi20: csi2@fea8 {
--
2.7.4
[PATCH v2 07/10] arm64: dts: renesas: r8a7795: Set EtherAVB phy mode to "rgmii"
Set the "phy-mode" property of EtherAVB device to "rgmii" and let board files override it if the installed PHY layer provides delays for the RX/TX channels. Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index 1f32340..87327eb 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi @@ -873,7 +873,7 @@ clocks = <&cpg CPG_MOD 812>; power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; resets = <&cpg 812>; - phy-mode = "rgmii-txid"; + phy-mode = "rgmii"; iommus = <&ipmmu_ds0 16>; #address-cells = <1>; #size-cells = <0>; -- 2.7.4
Re: [PATCH net-next 20/28] net: Convert cfg802154_pernet_ops
Hello.
On 02/26/2018 02:02 PM, Kirill Tkhai wrote:
> These pernet_operations have only exit method, which
> moves devices from cfg802154_rdev_list to init_net.
> This may occur in any time from nl802154_wpan_phy_netns(),
> so we are nice with rtnl_lock() synchronization.
>
> Signed-off-by: Kirill Tkhai
> ---
> net/ieee802154/core.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/ieee802154/core.c b/net/ieee802154/core.c
> index cb7176cd4cd6..9104943c15ba 100644
> --- a/net/ieee802154/core.c
> +++ b/net/ieee802154/core.c
> @@ -345,6 +345,7 @@ static void __net_exit cfg802154_pernet_exit(struct net
> *net)
>
> static struct pernet_operations cfg802154_pernet_ops = {
> .exit = cfg802154_pernet_exit,
> + .async = true,
> };
>
> static int __init wpan_phy_class_init(void)
>
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
[PATCH v2 08/10] arm64: dts: renesas: r8a77995: Set EtherAVB phy mode to "rgmii"
Set the "phy-mode" property of EtherAVB device to "rgmii" and let board files override it if the installed PHY layer provides delays for the RX/TX channels. Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven --- arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi b/arch/arm64/boot/dts/renesas/r8a77995.dtsi index cd3c6a3..fc48677 100644 --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi @@ -512,7 +512,7 @@ clocks = <&cpg CPG_MOD 812>; power-domains = <&sysc R8A77995_PD_ALWAYS_ON>; resets = <&cpg 812>; - phy-mode = "rgmii-txid"; + phy-mode = "rgmii"; iommus = <&ipmmu_ds0 16>; #address-cells = <1>; #size-cells = <0>; -- 2.7.4
[PATCH v2 06/10] arm64: dts: renesas: r8a7796: Set EtherAVB phy mode to "rgmii"
Set the "phy-mode" property of EtherAVB device to "rgmii" and let board files override it if the installed PHY layer provides delays for the RX/TX channels. Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven --- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi index 6075511..a99b0b2 100644 --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi @@ -974,7 +974,7 @@ clocks = <&cpg CPG_MOD 812>; power-domains = <&sysc R8A7796_PD_ALWAYS_ON>; resets = <&cpg 812>; - phy-mode = "rgmii-txid"; + phy-mode = "rgmii"; iommus = <&ipmmu_ds0 16>; #address-cells = <1>; #size-cells = <0>; -- 2.7.4
[PATCH v2 05/10] arm64: dts: renesas: v3msk: Override EtherAVB phy-mode
As the PHY interface installed on the V3MSK board provides TX and RX
channels delays, make the "phy-mode" property a board-specific one,
meant to override the one specified in the SoC DTSI.
Follow up patches will reset the r8a77970 SoC DTSI to use "rgmii"
mode and let the board file override that.
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
b/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
index 8624ca8..bb554ee 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
@@ -34,6 +34,7 @@
&avb {
renesas,no-ether-link;
phy-handle = <&phy0>;
+ phy-mode = "rgmii-id";
status = "okay";
phy0: ethernet-phy@0 {
--
2.7.4
[PATCH v2 04/10] arm64: dts: renesas: eagle: Override EtherAVB phy-mode
As the PHY interface installed on the Eagle board provides TX and RX
channels delays, make the "phy-mode" property a board-specific one,
meant to override the one specified in the SoC DTSI.
Follow up patches will reset the r8a77970 SoC DTSI to use "rgmii" mode
and let the board file override that.
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index 359e835..3c5f598 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -36,6 +36,7 @@
&avb {
renesas,no-ether-link;
phy-handle = <&phy0>;
+ phy-mode = "rgmii-id";
status = "okay";
phy0: ethernet-phy@0 {
--
2.7.4
[PATCH v2 03/10] arm64: dts: renesas: draak: Override EtherAVB phy-mode
As the PHY interface installed on the Draak board, provides TX
channel delay, make the "phy-mode" property a board-specific one, meant
to override the one specified in the SoC DTSI.
Follow up patches will reset the r8a77995 SoC DTSI to use "rgmii" mode
and let the board file override that.
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index af07da2..af18a09 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -108,6 +108,7 @@
pinctrl-names = "default";
renesas,no-ether-link;
phy-handle = <&phy0>;
+ phy-mode = "rgmii-txid";
status = "okay";
phy0: ethernet-phy@0 {
--
2.7.4
[PATCH v2 01/10] arm64: dts: renesas: salvator-common: Override EtherAVB phy-mode
As the PHY interface installed on the Salvator-X[S] board, provides TX
channel delay, make the "phy-mode" property a board-specific one, meant
to override the one specified in the SoC DTSI.
Follow up patches will reset the r8a7795/96/965 SoC DTSI to use "rgmii"
mode and let the board files override that.
Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
---
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index 8e8ec30..c725f9b 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -279,6 +279,7 @@
pinctrl-0 = <&avb_pins>;
pinctrl-names = "default";
phy-handle = <&phy0>;
+ phy-mode = "rgmii-txid";
status = "okay";
phy0: ethernet-phy@0 {
--
2.7.4
[PATCH v2 02/10] arm64: dts: renesas: ulcb: Override EtherAVB phy-mode
As the PHY interface installed on the ULCB board provides TX
channel delay, make the "phy-mode" property a board-specific one, meant
to override the one specified in the SoC DTSI.
Follow up patches will reset the r8a7795/96 SoC DTSI to use "rgmii" mode\
and let the board files override that.
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/ulcb.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/renesas/ulcb.dtsi
b/arch/arm64/boot/dts/renesas/ulcb.dtsi
index 3e7a6b9..6f81484 100644
--- a/arch/arm64/boot/dts/renesas/ulcb.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi
@@ -146,6 +146,7 @@
pinctrl-0 = <&avb_pins>;
pinctrl-names = "default";
phy-handle = <&phy0>;
+ phy-mode = "rgmii-txid";
status = "okay";
phy0: ethernet-phy@0 {
--
2.7.4
[PATCH v2 00/10] R-Car M3-N: Enable EtherAVB device node
Hi Simon, Geert,
in this second iteration I have dropped iommu dependencies for EtherAVB
and have changed "phy-mode" for all mainlines Gen-3 boards, this time including
ULCB, Draak, Eagle and V3MSK.
The series add phy-mode as a board property to the following board files:
- salvator-common.dtsi
- ulcb.dtsi
- r8a77995-draak.dts
- r8a77970-eagle.dts
- r8a77970-v3msk.dts
And reset the EtherAVB phy-mode to "rgmii" in the following SoC DTSI:
- r8a7795.dtsi
- r8a7796.dtsi
- r8a77995.dtsi
- r8a77970.dtsi
And finally, I added EtherAVB device node for M3-N on top.
I have verified with scripts/dtc/dtx_diff that the only difference compared to
the previous version for all DTS files is the newly introduced EtherAVB node for
r8a77965 Salvator-X board.
--
$ for i in `ls dts-new/*.dtb`; do
dt=`basename $i`;
echo $dt;
./scripts/dtc/dtx_diff dts-old/$dt dts-new/$dt;
done
$ r8a7795-es1-h3ulcb.dtb
r8a7795-es1-h3ulcb-kf.dtb
r8a7795-es1-salvator-x.dtb
r8a7795-h3ulcb.dtb
r8a7795-h3ulcb-kf.dtb
r8a7795-salvator-x.dtb
r8a7795-salvator-xs.dtb
r8a77965-salvator-x.dtb
--- dts-old/r8a77965-salvator-x.dtb
+++ dts-new/r8a77965-salvator-x.dtb
@@ -413,10 +413,17 @@
ethernet@e680 {
#address-cells = <0x1>;
#size-cells = <0x0>;
+ clocks = <0x6 0x1 0x32c>;
+ compatible = "renesas,etheravb-r8a77965",
"renesas,etheravb-rcar-gen3";
+ interrupt-names = "ch0", "ch1", "ch2", "ch3", "ch4",
"ch5", "ch6", "ch7", "ch8", "ch9", "ch10", "ch11", "ch12", "ch13", "ch14",
"ch15", "ch16", "ch17", "ch18", "ch19", "ch20", "ch21", "ch22", "ch23", "ch24";
+ interrupts = <0x0 0x27 0x4 0x0 0x28 0x4 0x0 0x29 0x4
0x0 0x2a 0x4 0x0 0x2b 0x4 0x0 0x2c 0x4 0x0 0x2d 0x4 0x0 0x2e 0x4 0x0 0x2f 0x4
0x0 0x30 0x4 0x0 0x31 0x4 0x0 0x32 0x4 0x0 0x33 0x4 0x0 0x34 0x4 0x0 0x35 0x4
0x0 0x36 0x4 0x0 0x37 0x4 0x0 0x38 0x4 0x0 0x39 0x4 0x0 0x3a 0x4 0x0 0x3b 0x4
0x0 0x3c 0x4 0x0 0x3d 0x4 0x0 0x3e 0x4 0x0 0x3f 0x4>;
phy-handle = <0x12>;
+ phy-mode = "rgmii-txid";
pinctrl-0 = <0x11>;
pinctrl-names = "default";
+ power-domains = <0x1 0x20>;
reg = <0x0 0xe680 0x0 0x800 0x0 0xe6a0 0x0
0x1>;
+ resets = <0x6 0x32c>;
status = "okay";
ethernet-phy@0 {
r8a7796-m3ulcb.dtb
r8a7796-m3ulcb-kf.dtb
r8a7796-salvator-x.dtb
r8a7796-salvator-xs.dtb
r8a77970-eagle.dtb
r8a77970-v3msk.dtb
r8a77995-draak.dtb
--
As per the previous version, this is based on what Simon already picked in his
development branch.
Branch for testing available at:
git://jmondi.org/linux m3-n/renesas-drivers-2018-02-13-v4.16-rc1/v2-simon
Thanks
j
v1 -> v2:
- Change rgmii mode in ULCB, Draak, Eagle and V3MSK
- Reset rgmii mode for r8a77970
- Drop iommu dependencies and associated patches
Jacopo Mondi (10):
arm64: dts: renesas: salvator-common: Override EtherAVB phy-mode
arm64: dts: renesas: ulcb: Override EtherAVB phy-mode
arm64: dts: renesas: draak: Override EtherAVB phy-mode
arm64: dts: renesas: eagle: Override EtherAVB phy-mode
arm64: dts: renesas: v3msk: Override EtherAVB phy-mode
arm64: dts: renesas: r8a7796: Set EtherAVB phy mode to "rgmii"
arm64: dts: renesas: r8a7795: Set EtherAVB phy mode to "rgmii"
arm64: dts: renesas: r8a77995: Set EtherAVB phy mode to "rgmii"
arm64: dts: renesas: r8a77970: Set EtherAVB phy mode to "rgmii"
arm64: dts: renesas: r8a77965: Add EtherAVB device node
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a77965.dtsi| 43 ++--
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 1 +
arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts | 1 +
arch/arm64/boot/dts/renesas/r8a77970.dtsi| 2 +-
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 1 +
arch/arm64/boot/dts/renesas/r8a77995.dtsi| 2 +-
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 +
arch/arm64/boot/dts/renesas/ulcb.dtsi| 1 +
10 files changed, 49 insertions(+), 7 deletions(-)
--
2.7.4
Re: inconsistent lock state with usbnet/asix usb ethernet and xhci
Am Dienstag, den 27.02.2018, 08:26 +0100 schrieb Marek Szyprowski:
Hi,
> I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel
> warning ("inconsistent lock state") on Chromebook2 Peach-PIT board. No
Is that 32 bit?
> special activity is needed to reproduce this issue, it happens almost
> on every boot. ASIX USB ethernet is connected to XHCI USB host controller
> on that board. Is it a known issue? Frankly I have no idea where to look
No, it is not known.
> to fix it. The same adapter connected to EHCI ports on other boards based
> on the same SoC works fine without any warnings.
Odd.
> And the log with mentioned warning:
>
> [ 17.768040]
> [ 17.772239] WARNING: inconsistent lock state
> [ 17.776511] 4.16.0-rc3-next-20180227-7-g876c53a7493c #453 Not tainted
> [ 17.783329]
> [ 17.787580] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> [ 17.793607] swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
> [ 17.798751] (&syncp->seq#5){?.-.}, at: [<9b22e5f0>]
> asix_rx_fixup_internal+0x188/0x288
Looks like this triggers (in usbnet):
u64_stats_update_begin(&stats64->syncp);
stats64->rx_packets++;
stats64->rx_bytes += skb->len;
u64_stats_update_end(&stats64->syncp);
That I considered to be called under lock.
Could you comment this out for testing?
Regards
Oliver
RE: [net-next 1/7] i40e: link_down_on_close private flag support
>> From: Mariusz Stachura >> >> This patch introduces new ethtool private flag used for forcing true >> link state. Function i40e_force_link_state that implements this >> functionality was added, it sets phy_type = 0 in order to work-around >> firmware's LESM. False positive error messages were suppressed. >> >> The ndo_open() should not succeed if there were issues with forcing >> link state to be UP. >> >> Added I40E_PHY_TYPES_BITMASK define with all phy types OR-ed together >> in one bitmask. Added after phy type definition, so it will be hard >> to forget to include new phy types to the bitmask. >> >> CC: Jakub Kicinski >> Signed-off-by: Mariusz Stachura >> Signed-off-by: Mitch Williams >> Tested-by: Andrew Bowers >> Signed-off-by: Jeff Kirsher > > Thanks, from functional perspective this looks reasonable AFAICT. > > We may want to have a conversation about priv flags like this at later time, > since I guess more NICs won't bring the link down when netdev is closed > today.. Although it maybe a larger endeavour, perhaps it would be cool to > communicate to the user the reason why MAC/PHY is on in some standard way.. > NC-SI and multi-host comes to mind. > Yep, the main reason for not bringing the link down is NPAR and SRIOV functionality. Link is up by default, so I think it was assumed that there is no reason to inform the user about it. The operator can use private flag to force it down, assuming she/he knows it will disrupt any undergoing traffic. I get your idea, nonetheless it was designed to use slightly different approach. >> @@ -7524,6 +7596,9 @@ int i40e_open(struct net_device *netdev) >> >> netif_carrier_off(netdev); >> >> +if (i40e_force_link_state(pf, true)) >> +return -EAGAIN; > > There are some minor style issues with the rest of the patch, but here you > may want to (a) propagate the actual error value; > The actual error value is printed inside the i40e_force_link_state() function [with KERN_ERR severity], here I wanted to let the user know the generic information that the resource is temporarily unavailable. >> err = i40e_vsi_open(vsi); >> if (err) >> return err; > > (b) undo the link state if vsi_open() fails. > > Maybe that's a bit of a nitpick... > I think it is, in my humble opinion there is no need to force link back down if something went wrong during further setup. Of course I'm always open for discussion :) Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN. Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
Re: ppp/pppoe, still panic 4.15.3 in ppp_push
On 2018-02-23 12:07, Guillaume Nault wrote: On Fri, Feb 23, 2018 at 11:41:43AM +0200, Denys Fedoryshchenko wrote: On 2018-02-23 11:38, Guillaume Nault wrote: > On Thu, Feb 22, 2018 at 08:51:19PM +0200, Denys Fedoryshchenko wrote: > > I'm using accel-ppp that has unit-cache option, i guess for > > "reusing" ppp > > interfaces (because creating a lot of interfaces on BRAS with 8k > > users quite > > expensive). > > Maybe it is somehow related and can be that scenario causing this bug? > > > Indeed, it'd be interesting to know if unit-cache is part of the > equation (if it's workable for you to disable it). Already did that and testing, unfortunately i had to disable KASAN and full refcount, as performance hit is too heavy for me. I will try to enable KASAN alone tomorrow. Don't hesitate to post the result even if you can't afford enabling KASAN. Till now 4 days and no reboots.
Re: inconsistent lock state with usbnet/asix usb ethernet and xhci
Hi Oliver,
On 2018-02-27 11:37, Oliver Neukum wrote:
Am Dienstag, den 27.02.2018, 08:26 +0100 schrieb Marek Szyprowski:
I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel
warning ("inconsistent lock state") on Chromebook2 Peach-PIT board. No
Is that 32 bit?
Yes. ARM 32bit. Exynos5420 SoC (4 x CortexA15 + 4 x CortexA7 big.LITTLE
CPUs).
special activity is needed to reproduce this issue, it happens almost
on every boot. ASIX USB ethernet is connected to XHCI USB host controller
on that board. Is it a known issue? Frankly I have no idea where to look
No, it is not known.
to fix it. The same adapter connected to EHCI ports on other boards based
on the same SoC works fine without any warnings.
Odd.
And the log with mentioned warning:
[ 17.768040]
[ 17.772239] WARNING: inconsistent lock state
[ 17.776511] 4.16.0-rc3-next-20180227-7-g876c53a7493c #453 Not tainted
[ 17.783329]
[ 17.787580] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[ 17.793607] swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 17.798751] (&syncp->seq#5){?.-.}, at: [<9b22e5f0>]
asix_rx_fixup_internal+0x188/0x288
Looks like this triggers (in usbnet):
u64_stats_update_begin(&stats64->syncp);
stats64->rx_packets++;
stats64->rx_bytes += skb->len;
u64_stats_update_end(&stats64->syncp);
That I considered to be called under lock.
Could you comment this out for testing?
Yes, commenting this out indeed hides the deplock warning.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
[PATCH net 0/3] net: fix IFLA_MTU ignored on NEWLINK for some ip and ipv6 tunnels
The fix for ip_gre follows the way other ip tunnels do: not to set mtu in ndo_init, as ip_tunnel_newlink will take care of it properly. The fix for ip6_tunnel and sit follows the way ipv6 tunenls do: to set mtu again according to IFLA_MTU after, as all bind_dev are called in ndo_init where it can't get the tb[IFLA_MTU]. Xin Long (3): ip_gre: fix IFLA_MTU ignored on NEWLINK ip6_tunnel: fix IFLA_MTU ignored on NEWLINK sit: fix IFLA_MTU ignored on NEWLINK net/ipv4/ip_gre.c | 5 - net/ipv6/ip6_tunnel.c | 12 net/ipv6/sit.c| 7 +++ 3 files changed, 15 insertions(+), 9 deletions(-) -- 2.1.0
[PATCH net 2/3] ip6_tunnel: fix IFLA_MTU ignored on NEWLINK
Commit 128bb975dc3c ("ip6_gre: init dev->mtu and dev->hard_header_len
correctly") fixed IFLA_MTU ignored on NEWLINK for ip6_gre. The same
mtu fix is also needed for ip6_tunnel.
Note that dev->hard_header_len setting for ip6_tunnel works fine,
no need to fix it.
Reported-by: Jianlin Shi
Signed-off-by: Xin Long
---
net/ipv6/ip6_tunnel.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 4b15fe9..6e0f21e 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1982,14 +1982,14 @@ static int ip6_tnl_newlink(struct net *src_net, struct
net_device *dev,
{
struct net *net = dev_net(dev);
struct ip6_tnl_net *ip6n = net_generic(net, ip6_tnl_net_id);
- struct ip6_tnl *nt, *t;
struct ip_tunnel_encap ipencap;
+ struct ip6_tnl *nt, *t;
+ int err;
nt = netdev_priv(dev);
if (ip6_tnl_netlink_encap_parms(data, &ipencap)) {
- int err = ip6_tnl_encap_setup(nt, &ipencap);
-
+ err = ip6_tnl_encap_setup(nt, &ipencap);
if (err < 0)
return err;
}
@@ -2005,7 +2005,11 @@ static int ip6_tnl_newlink(struct net *src_net, struct
net_device *dev,
return -EEXIST;
}
- return ip6_tnl_create2(dev);
+ err = ip6_tnl_create2(dev);
+ if (!err && tb[IFLA_MTU])
+ ip6_tnl_change_mtu(dev, nla_get_u32(tb[IFLA_MTU]));
+
+ return err;
}
static int ip6_tnl_changelink(struct net_device *dev, struct nlattr *tb[],
--
2.1.0
[PATCH net 1/3] ip_gre: fix IFLA_MTU ignored on NEWLINK
It's safe to remove the setting of dev's needed_headroom and mtu in
__gre_tunnel_init, as discussed in [1], ip_tunnel_newlink can do it
properly.
Now Eric noticed that it could cover the mtu value set in do_setlink
when creating a ip_gre dev. It makes IFLA_MTU param not take effect.
So this patch is to remove them to make IFLA_MTU work, as in other
ipv4 tunnels.
[1]: https://patchwork.ozlabs.org/patch/823504/
Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
Reported-by: Eric Garver
Signed-off-by: Xin Long
---
net/ipv4/ip_gre.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 45d97e9..0901de4 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -970,9 +970,6 @@ static void __gre_tunnel_init(struct net_device *dev)
t_hlen = tunnel->hlen + sizeof(struct iphdr);
- dev->needed_headroom= LL_MAX_HEADER + t_hlen + 4;
- dev->mtu= ETH_DATA_LEN - t_hlen - 4;
-
dev->features |= GRE_FEATURES;
dev->hw_features|= GRE_FEATURES;
@@ -1290,8 +1287,6 @@ static int erspan_tunnel_init(struct net_device *dev)
erspan_hdr_len(tunnel->erspan_ver);
t_hlen = tunnel->hlen + sizeof(struct iphdr);
- dev->needed_headroom = LL_MAX_HEADER + t_hlen + 4;
- dev->mtu = ETH_DATA_LEN - t_hlen - 4;
dev->features |= GRE_FEATURES;
dev->hw_features|= GRE_FEATURES;
dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
--
2.1.0
[PATCH net 3/3] sit: fix IFLA_MTU ignored on NEWLINK
Commit 128bb975dc3c ("ip6_gre: init dev->mtu and dev->hard_header_len
correctly") fixed IFLA_MTU ignored on NEWLINK for ip6_gre. The same
mtu fix is also needed for sit.
Note that dev->hard_header_len setting for sit works fine, no need to
fix it. sit is actually ipv4 tunnel, it can't call ip6_tnl_change_mtu
to set mtu.
Reported-by: Jianlin Shi
Signed-off-by: Xin Long
---
net/ipv6/sit.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 3a1775a..0195598 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1578,6 +1578,13 @@ static int ipip6_newlink(struct net *src_net, struct
net_device *dev,
if (err < 0)
return err;
+ if (tb[IFLA_MTU]) {
+ u32 mtu = nla_get_u32(tb[IFLA_MTU]);
+
+ if (mtu >= IPV6_MIN_MTU && mtu <= 0xFFF8 - dev->hard_header_len)
+ dev->mtu = mtu;
+ }
+
#ifdef CONFIG_IPV6_SIT_6RD
if (ipip6_netlink_6rd_parms(data, &ip6rd))
err = ipip6_tunnel_update_6rd(nt, &ip6rd);
--
2.1.0
Re: [PATCH RFC 1/2] virtio: introduce packed ring defines
On Tue, Feb 27, 2018 at 09:26:27AM +, David Laight wrote:
> From: Tiwei Bie
> > Sent: 23 February 2018 11:18
> ...
> > +struct vring_packed_desc_event {
> > + /* Descriptor Event Offset */
> > + __virtio16 desc_event_off : 15,
> > + /* Descriptor Event Wrap Counter */
> > + desc_event_wrap : 1;
> > + /* Descriptor Event Flags */
> > + __virtio16 desc_event_flags : 2;
> > +};
>
> This looks like you are assuming that a bit-field has a defined
> layout and can be used to map a 'hardware' structure.
> The don't, don't use them like that.
>
> David
>
Thanks for the comments! Above definition isn't used in
this RFC, and the corresponding parts (event suppression)
haven't been implemented yet. It's more like some pseudo
code (I should add some comments about this in the code).
I planned to change it to something like this in the next
version:
struct vring_packed_desc_event {
__virtio16 off_wrap;
__virtio16 flags; // XXX maybe not a good name for future
}; // extension. Only 2bits are used now.
But it seems that I had a misunderstanding about the spec
on this previously:
https://lists.oasis-open.org/archives/virtio-dev/201802/msg00173.html
Anyway, it will be addressed. Thank you very much! ;-)
Best regards,
Tiwei Bie
[PATCH] cdc_ether: flag the Cinterion PLS8 modem by gemalto as WWAN
The Cinterion PL8 is an LTE modem with 2 possible WWAN interfaces.
The modem is controlled via AT commands through the exposed TTYs.
AT^SWWAN write command can be used to activate or deactivate a WWAN
connection for a PDP context defined with AT+CGDCONT. UE supports
two WWAN adapter. Both WWAN adapters can be activated a the same time
Signed-off-by: Bassem Boubaker
---
drivers/net/usb/cdc_ether.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 05dca3e..65621fe 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -562,6 +562,7 @@ static const struct driver_info wwan_info = {
#define MICROSOFT_VENDOR_ID0x045e
#define UBLOX_VENDOR_ID0x1546
#define TPLINK_VENDOR_ID 0x2357
+#define GEMALTO_VENDOR_ID 0x1e2d
static const struct usb_device_id products[] = {
/* BLACKLIST !!
@@ -896,6 +897,12 @@ static const struct usb_device_id products[] = {
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&wwan_info,
}, {
+ /* Cinterion PLS8 modem by GEMALTO */
+ USB_DEVICE_AND_INTERFACE_INFO(GEMALTO_VENDOR_ID, 0x0061, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&wwan_info,
+}, {
USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ETHERNET,
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long) &cdc_info,
--
2.7.4
[patch net 1/2] mlxsw: core: Fix flex keys scratchpad offset conflict
From: Jiri Pirko
IP_TTL, IP_ECN and IP_DSCP are using the same offset within the
scratchpad as L4 ports. Fix this by shifting all up.
Fixes: 5f57e0909136 ("mlxsw: acl: Add ip ttl acl element")
Fixes: i80d0fe4710c ("mlxsw: acl: Add ip tos acl element")
Signed-off-by: Jiri Pirko
---
.../net/ethernet/mellanox/mlxsw/core_acl_flex_keys.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.h
b/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.h
index f6963b0b4a55..122506daa586 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.h
@@ -107,20 +107,20 @@ static const struct mlxsw_afk_element_info
mlxsw_afk_element_infos[] = {
MLXSW_AFK_ELEMENT_INFO_U32(VID, 0x10, 8, 12),
MLXSW_AFK_ELEMENT_INFO_U32(PCP, 0x10, 20, 3),
MLXSW_AFK_ELEMENT_INFO_U32(TCP_FLAGS, 0x10, 23, 9),
- MLXSW_AFK_ELEMENT_INFO_U32(IP_TTL_, 0x14, 0, 8),
- MLXSW_AFK_ELEMENT_INFO_U32(IP_ECN, 0x14, 9, 2),
- MLXSW_AFK_ELEMENT_INFO_U32(IP_DSCP, 0x14, 11, 6),
- MLXSW_AFK_ELEMENT_INFO_U32(SRC_IP4, 0x18, 0, 32),
- MLXSW_AFK_ELEMENT_INFO_U32(DST_IP4, 0x1C, 0, 32),
- MLXSW_AFK_ELEMENT_INFO_BUF(SRC_IP6_HI, 0x18, 8),
- MLXSW_AFK_ELEMENT_INFO_BUF(SRC_IP6_LO, 0x20, 8),
- MLXSW_AFK_ELEMENT_INFO_BUF(DST_IP6_HI, 0x28, 8),
- MLXSW_AFK_ELEMENT_INFO_BUF(DST_IP6_LO, 0x30, 8),
MLXSW_AFK_ELEMENT_INFO_U32(DST_L4_PORT, 0x14, 0, 16),
MLXSW_AFK_ELEMENT_INFO_U32(SRC_L4_PORT, 0x14, 16, 16),
+ MLXSW_AFK_ELEMENT_INFO_U32(IP_TTL_, 0x18, 0, 8),
+ MLXSW_AFK_ELEMENT_INFO_U32(IP_ECN, 0x18, 9, 2),
+ MLXSW_AFK_ELEMENT_INFO_U32(IP_DSCP, 0x18, 11, 6),
+ MLXSW_AFK_ELEMENT_INFO_U32(SRC_IP4, 0x20, 0, 32),
+ MLXSW_AFK_ELEMENT_INFO_U32(DST_IP4, 0x24, 0, 32),
+ MLXSW_AFK_ELEMENT_INFO_BUF(SRC_IP6_HI, 0x20, 8),
+ MLXSW_AFK_ELEMENT_INFO_BUF(SRC_IP6_LO, 0x28, 8),
+ MLXSW_AFK_ELEMENT_INFO_BUF(DST_IP6_HI, 0x30, 8),
+ MLXSW_AFK_ELEMENT_INFO_BUF(DST_IP6_LO, 0x38, 8),
};
-#define MLXSW_AFK_ELEMENT_STORAGE_SIZE 0x38
+#define MLXSW_AFK_ELEMENT_STORAGE_SIZE 0x40
struct mlxsw_afk_element_inst { /* element instance in actual block */
const struct mlxsw_afk_element_info *info;
--
2.14.3
[patch net 2/2] mlxsw: spectrum: Fix handling of resource_size_param
From: Jiri Pirko
Current code uses global variables, adjusts them and passes pointer down
to devlink. With every other mlxsw_core instance, the previously passed
pointer values are rewritten. Fix this by de-globalize the variables and
also memcpu size_params during devlink resource registration.
Also, introduce a convenient size_param_init helper.
Fixes: ef3116e5403e ("mlxsw: spectrum: Register KVD resources with devlink")
Signed-off-by: Jiri Pirko
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 76 +-
include/net/devlink.h | 18 +-
net/core/devlink.c | 7 ++-
3 files changed, 58 insertions(+), 43 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index 3dcc58d61506..583e04c8d8be 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -4207,13 +4207,12 @@ static struct devlink_resource_ops
mlxsw_sp_resource_kvd_hash_double_ops = {
.size_validate = mlxsw_sp_resource_kvd_hash_double_size_validate,
};
-static struct devlink_resource_size_params mlxsw_sp_kvd_size_params;
-static struct devlink_resource_size_params mlxsw_sp_linear_size_params;
-static struct devlink_resource_size_params mlxsw_sp_hash_single_size_params;
-static struct devlink_resource_size_params mlxsw_sp_hash_double_size_params;
-
static void
-mlxsw_sp_resource_size_params_prepare(struct mlxsw_core *mlxsw_core)
+mlxsw_sp_resource_size_params_prepare(struct mlxsw_core *mlxsw_core,
+ struct devlink_resource_size_params
*kvd_size_params,
+ struct devlink_resource_size_params
*linear_size_params,
+ struct devlink_resource_size_params
*hash_double_size_params,
+ struct devlink_resource_size_params
*hash_single_size_params)
{
u32 single_size_min = MLXSW_CORE_RES_GET(mlxsw_core,
KVD_SINGLE_MIN_SIZE);
@@ -4222,52 +4221,55 @@ mlxsw_sp_resource_size_params_prepare(struct mlxsw_core
*mlxsw_core)
u32 kvd_size = MLXSW_CORE_RES_GET(mlxsw_core, KVD_SIZE);
u32 linear_size_min = 0;
- /* KVD top resource */
- mlxsw_sp_kvd_size_params.size_min = kvd_size;
- mlxsw_sp_kvd_size_params.size_max = kvd_size;
- mlxsw_sp_kvd_size_params.size_granularity = MLXSW_SP_KVD_GRANULARITY;
- mlxsw_sp_kvd_size_params.unit = DEVLINK_RESOURCE_UNIT_ENTRY;
-
- /* Linear part init */
- mlxsw_sp_linear_size_params.size_min = linear_size_min;
- mlxsw_sp_linear_size_params.size_max = kvd_size - single_size_min -
- double_size_min;
- mlxsw_sp_linear_size_params.size_granularity = MLXSW_SP_KVD_GRANULARITY;
- mlxsw_sp_linear_size_params.unit = DEVLINK_RESOURCE_UNIT_ENTRY;
-
- /* Hash double part init */
- mlxsw_sp_hash_double_size_params.size_min = double_size_min;
- mlxsw_sp_hash_double_size_params.size_max = kvd_size - single_size_min -
- linear_size_min;
- mlxsw_sp_hash_double_size_params.size_granularity =
MLXSW_SP_KVD_GRANULARITY;
- mlxsw_sp_hash_double_size_params.unit = DEVLINK_RESOURCE_UNIT_ENTRY;
-
- /* Hash single part init */
- mlxsw_sp_hash_single_size_params.size_min = single_size_min;
- mlxsw_sp_hash_single_size_params.size_max = kvd_size - double_size_min -
- linear_size_min;
- mlxsw_sp_hash_single_size_params.size_granularity =
MLXSW_SP_KVD_GRANULARITY;
- mlxsw_sp_hash_single_size_params.unit = DEVLINK_RESOURCE_UNIT_ENTRY;
+ devlink_resource_size_params_init(kvd_size_params, kvd_size, kvd_size,
+ MLXSW_SP_KVD_GRANULARITY,
+ DEVLINK_RESOURCE_UNIT_ENTRY);
+ devlink_resource_size_params_init(linear_size_params, linear_size_min,
+ kvd_size - single_size_min -
+ double_size_min,
+ MLXSW_SP_KVD_GRANULARITY,
+ DEVLINK_RESOURCE_UNIT_ENTRY);
+ devlink_resource_size_params_init(hash_double_size_params,
+ double_size_min,
+ kvd_size - single_size_min -
+ linear_size_min,
+ MLXSW_SP_KVD_GRANULARITY,
+ DEVLINK_RESOURCE_UNIT_ENTRY);
+ devlink_resource_size_params_init(hash_single_size_params,
+ single_size_min,
+ kvd_size - double_size_min
[patch net 0/2] mlxsw: couple of fixes
From: Jiri Pirko Couple of unrelated fixes for mlxsw. --- Please consider the first patch for -stable. Thanks! Jiri Pirko (2): mlxsw: core: Fix flex keys scratchpad offset conflict mlxsw: spectrum: Fix handling of resource_size_param .../ethernet/mellanox/mlxsw/core_acl_flex_keys.h | 20 +++--- drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 76 +++--- include/net/devlink.h | 18 - net/core/devlink.c | 7 +- 4 files changed, 68 insertions(+), 53 deletions(-) -- 2.14.3
[PATCH net-next] sh_eth: uninline TSU register accessors
We have uninlined the sh_eth_{read|write}() functions introduced in the
commit 4a55530f38e ("net: sh_eth: modify the definitions of register").
Now remove *inline* from sh_eth_tsu_{read|write}() as well and move
these functions from the header to the driver itself. This saves 684
more bytes of object code (ARM gcc 4.8.5)...
Signed-off-by: Sergei Shtylyov
---
drivers/net/ethernet/renesas/sh_eth.c | 11 +++
drivers/net/ethernet/renesas/sh_eth.h | 11 ---
2 files changed, 11 insertions(+), 11 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -439,6 +439,17 @@ static void sh_eth_modify(struct net_dev
enum_index);
}
+static void sh_eth_tsu_write(struct sh_eth_private *mdp, u32 data,
+int enum_index)
+{
+ iowrite32(data, mdp->tsu_addr + mdp->reg_offset[enum_index]);
+}
+
+static u32 sh_eth_tsu_read(struct sh_eth_private *mdp, int enum_index)
+{
+ return ioread32(mdp->tsu_addr + mdp->reg_offset[enum_index]);
+}
+
static bool sh_eth_is_gether(struct sh_eth_private *mdp)
{
return mdp->reg_offset == sh_eth_offset_gigabit;
Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
===
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
+++ net-next/drivers/net/ethernet/renesas/sh_eth.h
@@ -568,15 +568,4 @@ static inline void *sh_eth_tsu_get_offse
return mdp->tsu_addr + mdp->reg_offset[enum_index];
}
-static inline void sh_eth_tsu_write(struct sh_eth_private *mdp, u32 data,
- int enum_index)
-{
- iowrite32(data, mdp->tsu_addr + mdp->reg_offset[enum_index]);
-}
-
-static inline u32 sh_eth_tsu_read(struct sh_eth_private *mdp, int enum_index)
-{
- return ioread32(mdp->tsu_addr + mdp->reg_offset[enum_index]);
-}
-
#endif /* #ifndef __SH_ETH_H__ */
Re: [PATCH RFC 1/2] virtio: introduce packed ring defines
On Tue, Feb 27, 2018 at 09:54:58AM +0100, Jens Freimann wrote:
> On Fri, Feb 23, 2018 at 07:18:00PM +0800, Tiwei Bie wrote:
[...]
> >
> > +struct vring_packed_desc_event {
> > + /* Descriptor Event Offset */
> > + __virtio16 desc_event_off : 15,
> > + /* Descriptor Event Wrap Counter */
> > + desc_event_wrap : 1;
> > + /* Descriptor Event Flags */
> > + __virtio16 desc_event_flags : 2;
> > +};
>
> Where would the virtqueue number go in driver notifications?
This structure is for event suppression instead of notification.
You could refer to the "Event Suppression Structure Format"
section of the spec for more details:
https://github.com/oasis-tcs/virtio-docs/blob/master/virtio-v1.1-packed-wd08.pdf
Best regards,
Tiwei Bie
[PATCH iproute2 2/3] ss: Fix build with old libc headers without AF_VSOCK
At the moment Linux Kernel 3.2 is the last supported LTS. It comes without AF_VSOCK support (added only in 3.10), therefore old libcs, such as glibc before 2.18 does not provide, cause ss(8) tool build failures like following: ss.c:294:15: error: 'AF_VSOCK' undeclared here (not in a function) ss.c:323:2: error: array index in initializer not of integer type ss.c:323:2: error: (near initialization for 'default_afs') make[1]: *** [ss.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [all] Error 2 Provide AF_VSOCK and PF_VSOCK defines for compatibility; adjust AF_MAX and PF_MAX to reflect change. Tested in Debian 7 (Wheezy) environment with glibc-2.13 and Linux Kernel 3.2. Still supported config until 31 May 2018 according to Debian LTS support page. Signed-off-by: Serhey Popovych --- include/compat/libc/bits/socket.h | 15 +++ 1 file changed, 15 insertions(+) create mode 100644 include/compat/libc/bits/socket.h diff --git a/include/compat/libc/bits/socket.h b/include/compat/libc/bits/socket.h new file mode 100644 index 000..25ef0d5 --- /dev/null +++ b/include/compat/libc/bits/socket.h @@ -0,0 +1,15 @@ +#ifndef _IP_COMPAT_BITS_SOCKET_H +#define _IP_COMPAT_BITS_SOCKET_H + +#include_next + +#ifndef AF_VSOCK +#define PF_VSOCK 40 +#define AF_VSOCK PF_VSOCK +#undef PF_MAX +#undef AF_MAX +#define PF_MAX 41 +#define AF_MAX PF_MAX +#endif /* AF_VSOCK */ + +#endif /* _IP_COMPAT_BITS_SOCKET_H */ -- 1.7.10.4
[PATCH iproute2 1/3] ip: Fix compilation with kernel headers < 3.4
Since commit 596b1c94aa38 ("iproute: build more easily on Android"),
iproute2 uses types __kernel_long_t and __kernel_ulong_t but does not
provide internal definitions for it.
This means that compilation using kernel headers that are older than 3.4
(where these types were added) will fail. This situation may be uncommon
for native compilation, but not uncommon for cross compilation where the
toolchains may be a bit older.
Provide the necessary types internally if not provided by the kernel
headers to fix compilation in such cases.
Co-Developed-by: Serhii Popovych
Signed-off-by: Thomas De Schampheleire
Signed-off-by: Serhey Popovych
---
Makefile |5 -
include/compat/kernel/linux/sysinfo.h | 14 ++
2 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 include/compat/kernel/linux/sysinfo.h
diff --git a/Makefile b/Makefile
index 32587db..c18a13f 100644
--- a/Makefile
+++ b/Makefile
@@ -54,7 +54,10 @@ CCOPTS = -O2
WFLAGS := -Wall -Wstrict-prototypes -Wmissing-prototypes
WFLAGS += -Wmissing-declarations -Wold-style-definition -Wformat=2
-CFLAGS := $(WFLAGS) $(CCOPTS) -I../include -I../include/uapi $(DEFINES)
$(CFLAGS)
+CCINCS := -I../include/compat/kernel -I../include/compat/libc
+CCINCS += -I../include -I../include/uapi
+
+CFLAGS := $(WFLAGS) $(CCOPTS) $(CCINCS) $(DEFINES) $(CFLAGS)
YACCFLAGS = -d -t -v
SUBDIRS=lib ip tc bridge misc netem genl tipc devlink rdma man
diff --git a/include/compat/kernel/linux/sysinfo.h
b/include/compat/kernel/linux/sysinfo.h
new file mode 100644
index 000..78fa6d7
--- /dev/null
+++ b/include/compat/kernel/linux/sysinfo.h
@@ -0,0 +1,14 @@
+#ifndef _IP_COMPAT_LINUX_SYSINFO_H
+#define _IP_COMPAT_LINUX_SYSINFO_H
+
+/* In case the kernel header asm/posix_types.h is too old (< 3.4) to provide
+ * __kernel_long_t, provide it here
+ */
+#ifndef __kernel_long_t
+typedef long __kernel_long_t;
+typedef unsigned long __kernel_ulong_t;
+#endif
+
+#include_next
+
+#endif /* _IP_COMPAT_LINUX_SYSINFO_H */
--
1.7.10.4
[PATCH iproute2 3/3] ip: Get rid of custom netinet/tcp.h
It seems to be copied from one of the versions of glibc to address
build issues caused by missing functionality.
Since then even with glibc-2.13 and Linux Kernel headers from 3.2
we able to build iproute2 tools (including ss) successfuly.
This effectively reverts commit 719b958bbdfd ("ss: report ecnseen")
and original one introducing this include commit 76e5d2c39201 ("add
include/netinet/tcp.h").
Any missing functionality and compatibility stuff must go to "compat"
subdirectory in include/.
Signed-off-by: Serhey Popovych
---
include/netinet/tcp.h | 231 -
1 file changed, 231 deletions(-)
delete mode 100644 include/netinet/tcp.h
diff --git a/include/netinet/tcp.h b/include/netinet/tcp.h
deleted file mode 100644
index 3f890a1..000
--- a/include/netinet/tcp.h
+++ /dev/null
@@ -1,231 +0,0 @@
-/*
- * Copyright (c) 1982, 1986, 1993
- * The Regents of the University of California. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- * 4. Neither the name of the University nor the names of its contributors
- *may be used to endorse or promote products derived from this software
- *without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- *
- * @(#)tcp.h 8.1 (Berkeley) 6/10/93
- */
-
-#ifndef _NETINET_TCP_H
-#define _NETINET_TCP_H 1
-
-#include
-
-/*
- * User-settable options (used with setsockopt).
- */
-#defineTCP_NODELAY 1 /* Don't delay send to coalesce packets
*/
-#defineTCP_MAXSEG 2 /* Set maximum segment size */
-#define TCP_CORK3 /* Control sending of partial frames */
-#define TCP_KEEPIDLE4 /* Start keeplives after this period */
-#define TCP_KEEPINTVL 5 /* Interval between keepalives */
-#define TCP_KEEPCNT 6 /* Number of keepalives before death */
-#define TCP_SYNCNT 7 /* Number of SYN retransmits */
-#define TCP_LINGER2 8 /* Life time of orphaned FIN-WAIT-2 state */
-#define TCP_DEFER_ACCEPT 9 /* Wake up listener only when data arrive */
-#define TCP_WINDOW_CLAMP 10/* Bound advertised window */
-#define TCP_INFO11 /* Information about this connection. */
-#defineTCP_QUICKACK 12 /* Bock/reenable quick ACKs. */
-#define TCP_CONGESTION 13 /* Congestion control algorithm. */
-
-#ifdef __USE_MISC
-# include
-
-# ifdef __FAVOR_BSD
-typedefu_int32_t tcp_seq;
-/*
- * TCP header.
- * Per RFC 793, September, 1981.
- */
-struct tcphdr
- {
-u_int16_t th_sport;/* source port */
-u_int16_t th_dport;/* destination port */
-tcp_seq th_seq;/* sequence number */
-tcp_seq th_ack;/* acknowledgement number */
-# if __BYTE_ORDER == __LITTLE_ENDIAN
-u_int8_t th_x2:4; /* (unused) */
-u_int8_t th_off:4; /* data offset */
-# endif
-# if __BYTE_ORDER == __BIG_ENDIAN
-u_int8_t th_off:4; /* data offset */
-u_int8_t th_x2:4; /* (unused) */
-# endif
-u_int8_t th_flags;
-# define TH_FIN 0x01
-# define TH_SYN 0x02
-# define TH_RST 0x04
-# define TH_PUSH 0x08
-# define TH_ACK 0x10
-# define TH_URG 0x20
-u_int16_t th_win; /* window */
-u_int16_t th_sum; /* checksum */
-u_int16_t th_urp; /* urgent pointer */
-};
-
-# else /* !__FAVOR_BSD */
-struct tcphdr
- {
-u_int16_t source;
-u_int16_t dest;
-u_int32_t seq;
-u_int32_t ack_seq;
-# if __BYTE_ORDER == __LITTLE_ENDIAN
-u_int16_t res1:4;
-u_int16_t doff:4;
-u_int16_t fin:1;
-u_int16_t syn:1;
-u_int16_t rst:1;
-u_int16_t psh:1;
-u_int16_t ack:1;
-u_int16_t urg:1;
[PATCH iproute2 0/3] ip: Provide compatibility bits to build with old glibc/kernel headers
Now last LTS kernel is 3.2 one might want to build recent version of iproute2 package. This is quite common in embedded world where old kernels/glibc is quite common and updating them could be problematic or even impossible. There are two problems at the moment preventing recent version of iproute2 build against old headers: 1) missing __kernel_long_t/__kernel_ulong_t 2) AF_VSOCK/PF_VSOCK defines There is also quite outdated copy of netinet/tcp.h header persent in include/ that no longer required to build ss(8) tool with even old configurations such as 3.2 and glibc-2.13 on Debian 7 (Wheezy). We probably can get rid of it. Since compatibility issues are quite common kind of problems I propose to add new directory include/compat/ to keep both kernel and libc hierarchy separately and use include_next preprocessor directive to include old headers before/after we tweak it's contents for compat. As usal reviews, comments and suggestions are welcome. Thanks, Serhii Serhey Popovych (3): ip: Fix compilation with kernel headers < 3.4 ss: Fix build with old libc headers without AF_VSOCK ip: Get rid of custom netinet/tcp.h Makefile |5 +- include/compat/kernel/linux/sysinfo.h | 14 ++ include/compat/libc/bits/socket.h | 15 +++ include/netinet/tcp.h | 231 - 4 files changed, 33 insertions(+), 232 deletions(-) create mode 100644 include/compat/kernel/linux/sysinfo.h create mode 100644 include/compat/libc/bits/socket.h delete mode 100644 include/netinet/tcp.h -- 1.7.10.4
[RFC][PATCH bpf] tools: bpftool: Fix tags for bpf-to-bpf calls
"Naveen N. Rao" wrote:
> I'm wondering if we can instead encode the bpf prog id in
> imm32. That way, we should be able to indicate the BPF
> function being called into. Daniel, is that something we
> can consider?
Since each subprog does not get a separate id, we cannot fetch
the fd and therefore the tag of a subprog. Instead we can use
the tag of the complete program as shown below.
"Daniel Borkmann" wrote:
> I think one limitation that would still need to be addressed later
> with such approach would be regarding the xlated prog dump in bpftool,
> see 'BPF calls via JIT' in 7105e828c087 ("bpf: allow for correlation
> of maps and helpers in dump"). Any ideas for this (potentially if we
> could use off + imm for calls, we'd get to 48 bits, but that seems
> still not be enough as you say)?
As an alternative, this is what I am thinking of:
Currently, for bpf-to-bpf calls, if bpf_jit_kallsyms is enabled,
bpftool looks up the name of the corresponding symbol for the
JIT-ed subprogram and shows it in the xlated dump alongside the
actual call instruction. However, the lookup is based on the
target address which is calculated using the imm field of the
instruction. So, once again, if imm is truncated, we will end
up with the wrong address. Also, the subprog aux data (which
has been proposed as a mitigation for this) is not accessible
from this tool.
We can still access the tag for the complete bpf program and use
this with the correct offset in an objdump-like notation as an
alterative for the name of the subprog that is the target of a
bpf-to-bpf call instruction.
Currently, an xlated dump looks like this:
0: (85) call pc+2#bpf_prog_5f76847930402518_F
1: (b7) r0 = 1
2: (95) exit
3: (b7) r0 = 2
4: (95) exit
With this patch, it will look like this:
0: (85) call pc+2#bpf_prog_8f85936f29a7790a+3
1: (b7) r0 = 1
2: (95) exit
3: (b7) r0 = 2
4: (95) exit
where 8f85936f29a7790a is the tag of the bpf program and 3 is
the offset to the start of the subprog from the start of the
program.
Signed-off-by: Sandipan Das
---
tools/bpf/bpftool/prog.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
index e8e2baaf93c2..93746d5d1e3c 100644
--- a/tools/bpf/bpftool/prog.c
+++ b/tools/bpf/bpftool/prog.c
@@ -415,9 +415,11 @@ struct kernel_sym {
};
struct dump_data {
+ unsigned char prog_tag[BPF_TAG_SIZE];
unsigned long address_call_base;
struct kernel_sym *sym_mapping;
__u32 sym_count;
+ unsigned int curr_line;
char scratch_buff[SYM_MAX_NAME];
};
@@ -499,16 +501,16 @@ static void print_insn(struct bpf_verifier_env *env,
const char *fmt, ...)
}
static const char *print_call_pcrel(struct dump_data *dd,
- struct kernel_sym *sym,
- unsigned long address,
const struct bpf_insn *insn)
{
- if (sym)
- snprintf(dd->scratch_buff, sizeof(dd->scratch_buff),
-"%+d#%s", insn->off, sym->name);
- else
- snprintf(dd->scratch_buff, sizeof(dd->scratch_buff),
-"%+d#0x%lx", insn->off, address);
+ snprintf(dd->scratch_buff, sizeof(dd->scratch_buff),
+"+%d#bpf_prog_%02x%02x%02x%02x%02x%02x%02x%02x+%d",
+insn->off,
+dd->prog_tag[0], dd->prog_tag[1],
+dd->prog_tag[2], dd->prog_tag[3],
+dd->prog_tag[4], dd->prog_tag[5],
+dd->prog_tag[6], dd->prog_tag[7],
+dd->curr_line + insn->off + 1);
return dd->scratch_buff;
}
@@ -534,7 +536,7 @@ static const char *print_call(void *private_data,
sym = kernel_syms_search(dd, address);
if (insn->src_reg == BPF_PSEUDO_CALL)
- return print_call_pcrel(dd, sym, address, insn);
+ return print_call_pcrel(dd, insn);
else
return print_call_helper(dd, sym, address);
}
@@ -576,6 +578,7 @@ static void dump_xlated_plain(struct dump_data *dd, void
*buf,
double_insn = insn[i].code == (BPF_LD | BPF_IMM | BPF_DW);
printf("% 4d: ", i);
+ dd->curr_line = i;
print_bpf_insn(&cbs, NULL, insn + i, true);
if (opcodes) {
@@ -628,6 +631,7 @@ static void dump_xlated_json(struct dump_data *dd, void
*buf,
jsonw_start_object(json_wtr);
jsonw_name(json_wtr, "disasm");
+ dd->curr_line = i;
print_bpf_insn(&cbs, NULL, insn + i, true);
if (opcodes) {
@@ -788,6 +792,7 @@ static int do_dump(int argc, char **argv)
disasm_print_insn(buf, *member_len, opcodes, name);
} else {
+ memcpy(dd.prog_tag, info.tag, sizeof(info.tag));
kernel_syms_lo
[PATCH v4 net] Use correct sk->sk_prot for IPv6 in TLS
The tls ulp overrides sk->prot with a new tls specific proto structs. The tls specific structs were previously based on the ipv4 specific tcp_prot sturct. As a result, attaching the tls ulp to an ipv6 tcp socket replaced some ipv6 callback with the ipv4 equivalents. This patch adds ipv6 tls proto structs and uses them when attached to ipv6 sockets. Changed since v3: - Removed the use of tcpv6_prot and the dependency on the IPv6 module. - Should fix the issue triggered by CVE-2018-5703 Changed since v2: - Dropped patch to fix IPv6_ADDRFORM setsockopt There was some disagreement about the correct way of fixinig it, and this series does not depend on it. Changes since v1: - TLS now dependes on IPv6 This fixes complication issues when TLS is built-in and IPv6 is a module. The downside should be small as it is unlikely that there are kernel TLS users who can't afford to include IPv6 in thier kernel. - tls_init now checks sk->sk_prot directly This is somewhat safer then checking indirectly through sk->sk_family Boris Pismenny (1): tls: Use correct sk->sk_prot for IPv6 net/tls/tls_main.c | 52 +--- 1 file changed, 37 insertions(+), 15 deletions(-) -- 1.8.3.1
[PATCH v4 net] tls: Use correct sk->sk_prot for IPV6
The tls ulp overrides sk->prot with a new tls specific proto structs.
The tls specific structs were previously based on the ipv4 specific
tcp_prot sturct.
As a result, attaching the tls ulp to an ipv6 tcp socket replaced
some ipv6 callback with the ipv4 equivalents.
This patch adds ipv6 tls proto structs and uses them when
attached to ipv6 sockets.
Fixes: 3c4d7559159b ('tls: kernel TLS support')
Signed-off-by: Boris Pismenny
Signed-off-by: Ilya Lesokhin
---
net/tls/tls_main.c | 52 +---
1 file changed, 37 insertions(+), 15 deletions(-)
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index e9b4b53..d824d54 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -46,16 +46,26 @@
MODULE_LICENSE("Dual BSD/GPL");
enum {
+ TLSV4,
+ TLSV6,
+ TLS_NUM_PROTS,
+};
+
+enum {
TLS_BASE_TX,
TLS_SW_TX,
TLS_NUM_CONFIG,
};
-static struct proto tls_prots[TLS_NUM_CONFIG];
+static struct proto *saved_tcpv6_prot;
+static DEFINE_MUTEX(tcpv6_prot_mutex);
+static struct proto tls_prots[TLS_NUM_PROTS][TLS_NUM_CONFIG];
static inline void update_sk_prot(struct sock *sk, struct tls_context *ctx)
{
- sk->sk_prot = &tls_prots[ctx->tx_conf];
+ int ip_ver = sk->sk_family == AF_INET6 ? TLSV6 : TLSV4;
+
+ sk->sk_prot = &tls_prots[ip_ver][ctx->tx_conf];
}
int wait_on_pending_writer(struct sock *sk, long *timeo)
@@ -453,8 +463,21 @@ static int tls_setsockopt(struct sock *sk, int level, int
optname,
return do_tls_setsockopt(sk, optname, optval, optlen);
}
+static void build_protos(struct proto *prot, struct proto *base)
+{
+ prot[TLS_BASE_TX] = *base;
+ prot[TLS_BASE_TX].setsockopt= tls_setsockopt;
+ prot[TLS_BASE_TX].getsockopt= tls_getsockopt;
+ prot[TLS_BASE_TX].close = tls_sk_proto_close;
+
+ prot[TLS_SW_TX] = prot[TLS_BASE_TX];
+ prot[TLS_SW_TX].sendmsg = tls_sw_sendmsg;
+ prot[TLS_SW_TX].sendpage= tls_sw_sendpage;
+}
+
static int tls_init(struct sock *sk)
{
+ int ip_ver = sk->sk_family == AF_INET6 ? TLSV6 : TLSV4;
struct inet_connection_sock *icsk = inet_csk(sk);
struct tls_context *ctx;
int rc = 0;
@@ -479,6 +502,17 @@ static int tls_init(struct sock *sk)
ctx->getsockopt = sk->sk_prot->getsockopt;
ctx->sk_proto_close = sk->sk_prot->close;
+ /* Build IPv6 TLS whenever the address of tcpv6_prot changes */
+ if (ip_ver == TLSV6 &&
+ unlikely(sk->sk_prot != smp_load_acquire(&saved_tcpv6_prot))) {
+ mutex_lock(&tcpv6_prot_mutex);
+ if (likely(sk->sk_prot != saved_tcpv6_prot)) {
+ build_protos(tls_prots[TLSV6], sk->sk_prot);
+ smp_store_release(&saved_tcpv6_prot, sk->sk_prot);
+ }
+ mutex_unlock(&tcpv6_prot_mutex);
+ }
+
ctx->tx_conf = TLS_BASE_TX;
update_sk_prot(sk, ctx);
out:
@@ -493,21 +527,9 @@ static int tls_init(struct sock *sk)
.init = tls_init,
};
-static void build_protos(struct proto *prot, struct proto *base)
-{
- prot[TLS_BASE_TX] = *base;
- prot[TLS_BASE_TX].setsockopt= tls_setsockopt;
- prot[TLS_BASE_TX].getsockopt= tls_getsockopt;
- prot[TLS_BASE_TX].close = tls_sk_proto_close;
-
- prot[TLS_SW_TX] = prot[TLS_BASE_TX];
- prot[TLS_SW_TX].sendmsg = tls_sw_sendmsg;
- prot[TLS_SW_TX].sendpage= tls_sw_sendpage;
-}
-
static int __init tls_register(void)
{
- build_protos(tls_prots, &tcp_prot);
+ build_protos(tls_prots[TLSV4], &tcp_prot);
tcp_register_ulp(&tcp_tls_ulp_ops);
--
1.8.3.1
Re: [PATCH iproute2] Fix compilation with kernel headers < 3.4
Thomas De Schampheleire wrote: > On Mon, Feb 26, 2018 at 09:46:41PM +0200, Serhey Popovych wrote: >> Since commit 596b1c94aa38e21b7a8c8562e8b61ccb744255d2, iproute2 uses types >> __kernel_long_t and __kernel_ulong_t but does not provide internal >> definitions for it. >> >> This means that compilation using kernel headers that are older than 3.4 >> (where these types were added) will fail. This situation may be uncommon for >> native compilation, but not uncommon for cross compilation where the >> toolchains may be a bit older. >> >> Provide the necessary types internally if not provided by the kernel >> headers to fix compilation in such cases. >> >> Co-Developed-by: Serhii Popovych >> Signed-off-by: Thomas De Schampheleire >> Signed-off-by: Serhey Popovych >> --- >> include/linux/sysinfo.h | 14 ++ >> misc/ss.c | 10 ++ >> 2 files changed, 24 insertions(+) >> create mode 100644 include/linux/sysinfo.h >> >> diff --git a/include/linux/sysinfo.h b/include/linux/sysinfo.h >> new file mode 100644 >> index 000..766de8d >> --- /dev/null >> +++ b/include/linux/sysinfo.h >> @@ -0,0 +1,14 @@ >> +#ifndef _SYSINFO_COMPAT_H >> +#define _SYSINFO_COMPAT_H >> + >> +/* In case the kernel header asm/posix_types.h is too old (< 3.4) to provide >> + * __kernel_long_t, provide it here >> + */ >> +#ifndef __kernel_long_t >> +typedef long__kernel_long_t; >> +typedef unsigned long __kernel_ulong_t; >> +#endif >> + >> +#include_next >> + >> +#endif /* _SYSINFO_COMPAT_H */ > > Actually, I now wonder: instead of applying this trick with #include_next on > sysinfo.h, why not do it on linux/types.h ? That would be more correct and > more > robust for the future, no? No. Headers in include/uapi updated automatically from newer kernel versions. If we do any hacks in iproute2 uapi directory updating headers automatically would be problematic. As for me using #include_next presents better approach. Better to provide means for compatibility and that I propose to do with series "ip: Provide compatibility bits to build with old glibc/kernel headers". > > /Thomas > signature.asc Description: OpenPGP digital signature
Re: WARNING in smc_unhash_sk
On Fri, 2018-02-23 at 07:59 -0800, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > af3e79d29555b97dd096e2f8e36a0f50213808a8 (Tue Feb 20 18:05:02 2018 +) > Merge tag 'leds_for-4.16-rc3' of > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds > > So far this crash happened 27 times on > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/master, > net-next, upstream. > C reproducer is attached. > syzkaller reproducer is attached. > Raw console output is attached. > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+3a0748c8f2f210c0e...@syzkaller.appspotmail.com > It will help syzbot understand when the bug is fixed. See footer for > details. > If you forward the report, please keep this part and the footer. > > WARNING: CPU: 1 PID: 9921 at ./include/net/sock.h:638 sk_del_node_init > include/net/sock.h:638 [inline] > WARNING: CPU: 1 PID: 9921 at ./include/net/sock.h:638 > smc_unhash_sk+0x335/0x450 net/smc/af_smc.c:90 > Kernel panic - not syncing: panic_on_warn set ... > > CPU: 1 PID: 9921 Comm: syzkaller089677 Not tainted 4.16.0-rc2+ #324 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:17 [inline] > dump_stack+0x194/0x24d lib/dump_stack.c:53 > panic+0x1e4/0x41c kernel/panic.c:183 > __warn+0x1dc/0x200 kernel/panic.c:547 > report_bug+0x211/0x2d0 lib/bug.c:184 > fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178 > fixup_bug arch/x86/kernel/traps.c:247 [inline] > do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296 > do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315 > invalid_op+0x58/0x80 arch/x86/entry/entry_64.S:957 > RIP: 0010:sk_del_node_init include/net/sock.h:638 [inline] > RIP: 0010:smc_unhash_sk+0x335/0x450 net/smc/af_smc.c:90 > RSP: 0018:8801b639f198 EFLAGS: 00010293 > RAX: 8801b684a340 RBX: 110036c73e37 RCX: 85a3f1f5 > RDX: RSI: dc00 RDI: 110036c73e3b > RBP: 8801b639f280 R08: dc00 R09: 0004 > R10: 8801b639f050 R11: 0004 R12: 8801b639f258 > R13: 87669b40 R14: 8801c08d57c0 R15: 110036c73e3b > smc_release+0x321/0x580 net/smc/af_smc.c:148 > sock_release+0x8d/0x1e0 net/socket.c:595 > sock_close+0x16/0x20 net/socket.c:1149 > __fput+0x327/0x7e0 fs/file_table.c:209 > fput+0x15/0x20 fs/file_table.c:243 > task_work_run+0x199/0x270 kernel/task_work.c:113 > exit_task_work include/linux/task_work.h:22 [inline] > do_exit+0x9bb/0x1ad0 kernel/exit.c:865 > do_group_exit+0x149/0x400 kernel/exit.c:968 > get_signal+0x73a/0x16d0 kernel/signal.c:2469 > do_signal+0x90/0x1e90 arch/x86/kernel/signal.c:809 > exit_to_usermode_loop+0x258/0x2f0 arch/x86/entry/common.c:162 > prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline] > syscall_return_slowpath arch/x86/entry/common.c:265 [inline] > do_syscall_64+0x6e5/0x940 arch/x86/entry/common.c:292 > entry_SYSCALL_64_after_hwframe+0x42/0xb7 > RIP: 0033:0x44cad9 > RSP: 002b:7fbf24687ce8 EFLAGS: 0246 ORIG_RAX: 0007 > RAX: 0001 RBX: 00700024 RCX: 0044cad9 > RDX: RSI: 0001 RDI: 2080 > RBP: 00700020 R08: R09: > R10: R11: 0246 R12: > R13: 0080ef3f R14: 7fbf246889c0 R15: 0005 > Dumping ftrace buffer: > (ftrace buffer empty) > Kernel Offset: disabled > Rebooting in 86400 seconds.. > > > --- > This bug is generated by a dumb bot. It may contain errors. > See https://goo.gl/tpsmEJ for details. > Direct all questions to syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. > If you forgot to add the Reported-by tag, once the fix for this bug is > merged > into any tree, please reply to this email with: > #syz fix: exact-commit-title > If you want to test a patch for this bug, please reply with: > #syz test: git://repo/address.git branch > and provide the patch inline or as an attachment. > To mark this as a duplicate of another syzbot report, please reply with: > #syz dup: exact-subject-of-another-report > If it's a one-off invalid bug report, please reply with: > #syz invalid > Note: if the crash happens again, it will cause creation of a new bug > report. > Note: all commands must start from beginning of the line in the email body. #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master From c258bf3ad07985eaf4e07d7667b7882cb9a2661b Mon Sep 17 00:00:00 2001 Message-Id: From: Davide Caratti Date: Tue, 27 Feb 2018 12:45:11 +0100 Subject: [PATCH net] af_smc: fix NULL pointer dereference on sock_create_kern() error path when sock_create_kern(..., a) returns an error, 'a' might
Re: [PATCH V8 2/4] sctp: Add ip option support
On Mon, Feb 26, 2018 at 05:48:48PM -0500, Paul Moore wrote: > On Sat, Feb 24, 2018 at 11:18 AM, Richard Haines > wrote: > > Add ip option support to allow LSM security modules to utilise CIPSO/IPv4 > > and CALIPSO/IPv6 services. > > > > Signed-off-by: Richard Haines > > --- > > All SCTP lksctp-tools/src/func_tests run correctly in enforcing mode. > > All "./sctp-tests run" obtained from: https://github.com/sctp/sctp-tests > > pass. > > > > V7 Changes: > > 1) Log when copy ip options fail for IPv4 and IPv6 > > 2) Correct sctp_setsockopt_maxseg() function. Note that the lksctp-tools > > func_tests do not test with struct sctp_assoc_value. Just used simple test > > and okay. > > 3) Move calculation of overheads to sctp_packet_config(). > > NOTE: Initially in sctp_packet_reset() I set packet->size and > > packet->overhead to zero (as it is a reset). This was okay for all the > > lksctp-tools function tests, however when running "sctp-tests" ndatshched > > tests it causes these to fail with an st_s.log entry of: > > sid: 3, expected: 3 > > sid: 3, expected: 3 > > unexpected sid packet !!! > > sid: 1, expected: 3 > > > > I then found sctp_packet_transmit() relies on setting > > "packet->size = packet->overhead;" to reset size to the current overhead > > after sending packets, hence the comment in sctp_packet_reset() > > > > V8 Change: > > Fix sparse warning: > > net/sctp/protocol.c:269:28: sparse: dereference of noderef expression > > highlighted in [1] for sctp_v4_ip_options_len() function. > > > > [1] https://lists.01.org/pipermail/kbuild-all/2018-February/043695.html > > > > include/net/sctp/sctp.h| 4 +++- > > include/net/sctp/structs.h | 2 ++ > > net/sctp/chunk.c | 10 +++--- > > net/sctp/ipv6.c| 45 > > ++--- > > net/sctp/output.c | 34 +- > > net/sctp/protocol.c| 43 +++ > > net/sctp/socket.c | 11 --- > > 7 files changed, 122 insertions(+), 27 deletions(-) > > Thanks Richard. > > Neil and Marcelo, I transfered your acked-by to this patch, if you've > got any objections to that please let me know. > I'm also fine with the transfer, thanks for checking! Neil
Re: [PATCH] cdc_ether: flag the Cinterion PLS8 modem by gemalto as WWAN
Bassem Boubaker writes: > +#define GEMALTO_VENDOR_ID0x1e2d This is defined as CINTERION_VENDOR_ID in drivers/usb/serial/option.c. I have no idea which defintion is most correct, but I believe the macros should be kept identical whatever you decide. Anything else is just unnecessarily confusing. IMHO the company name tracking macros have grown beyond useful a long time ago. They just make it harder to grep for the IDs without adding any useful information whatsoever. And because you have cases like this where the same number end up having different names, they sometimes hide information which a plain number would have revealed. Bjørn
Re: [PATCH] cdc_ether: flag the Cinterion PLS8 modem by gemalto as WWAN
Am Dienstag, den 27.02.2018, 13:29 +0100 schrieb Bjørn Mork : > Bassem Boubaker writes: > > > > > +#define GEMALTO_VENDOR_ID 0x1e2d > > This is defined as CINTERION_VENDOR_ID in drivers/usb/serial/option.c. > > I have no idea which defintion is most correct, but I believe the macros > should be kept identical whatever you decide. Anything else is just > unnecessarily confusing. > > IMHO the company name tracking macros have grown beyond useful a long > time ago. They just make it harder to grep for the IDs without adding > any useful information whatsoever. And because you have cases like this > where the same number end up having different names, they sometimes hide > information which a plain number would have revealed. Hi, I concur. Could you redo the patch and just use a plain number? Regards Oliver
[PATCH] cdc_ether: flag the Cinterion PLS8 modem by gemalto as WWAN
The Cinterion PL8 is an LTE modem with 2 possible WWAN interfaces.
The modem is controlled via AT commands through the exposed TTYs.
AT^SWWAN write command can be used to activate or deactivate a WWAN
connection for a PDP context defined with AT+CGDCONT. UE supports
two WWAN adapter. Both WWAN adapters can be activated a the same time
Signed-off-by: Bassem Boubaker
---
drivers/net/usb/cdc_ether.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 05dca3e..fff4b13 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -896,6 +896,12 @@ static const struct usb_device_id products[] = {
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&wwan_info,
}, {
+ /* Cinterion PLS8 modem by GEMALTO */
+ USB_DEVICE_AND_INTERFACE_INFO(0x1e2d, 0x0061, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&wwan_info,
+}, {
USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ETHERNET,
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long) &cdc_info,
--
2.7.4
[PATCH 0/6]GSO_BY_FRAGS correctness improvements
As requested [1], I went through and had a look at users of gso_size to
see if there were things that need to be fixed to consider
GSO_BY_FRAGS, and I have tried to improve our helper functions to deal
with this case.
I found a few, and this fixes all but one of them. The one thing that
remains is qdisc_pkt_len_init which is discussed at [2] - it's caught
up in the GSO_DODGY mess. I don't have any expertise in GSO_DODGY, and
it looks like a good clean fix will involve unpicking the whole
validation mess, so I have left it for now.
Patch 1 renames skb_gso_validate_mtu to skb_gso_validate_network_len.
This is follow-up to my earlier patch 2b16f048729b ("net: create
skb_gso_validate_mac_len()"), and just makes everything a bit clearer.
Patches 2 and 3 replace the final users of skb_gso_network_seglen() -
which doesn't consider GSO_BY_FRAGS - with
skb_gso_validate_network_len(), which does. This allows me to make the
skb_gso_*_seglen functions private in patch 4 - now future users won't
accidentally do the wrong comparison.
Lastly, there are 3 eBPF opcodes that change the gso_size of an SKB
and don't consider GSO_BY_FRAGS. To address this, patch 5 adds a
couple of helpers for changing gso_size that throw a WARN if you use
them on a GSO_BY_FRAGS packet. To return a useful error to eBPF, patch
6 goes further and prevents any change of gso_size for SCTP GSO skbs.
Regards,
Daniel
[1] https://patchwork.ozlabs.org/comment/1852414/
[2] https://www.spinics.net/lists/netdev/msg482397.html
PS: This is all in the core networking stack. For a driver to be
affected by this it would need to support NETIF_F_GSO_SCTP /
NETIF_F_GSO_SOFTWARE and then either use gso_size or not be a purely
virtual device. (Many drivers look at gso_size, but do not support
SCTP segmentation, so the core network will segment an SCTP gso before
it hits them.) Based on that, the only driver that may be affected is
sunvnet, but I have no way of testing it, so I haven't looked at it.
Daniel Axtens (6):
net: rename skb_gso_validate_mtu -> skb_gso_validate_network_len
net: sched: tbf: handle GSO_BY_FRAGS case in enqueue
net: xfrm: use skb_gso_validate_network_len() to check gso sizes
net: make skb_gso_*_seglen functions private
net: add and use helpers when adjusting gso_size
net: filter: refuse to change gso_size of SCTP packets
Documentation/networking/segmentation-offloads.txt | 11 -
include/linux/skbuff.h | 51 --
net/core/filter.c | 24 --
net/core/skbuff.c | 48 +---
net/ipv4/ip_forward.c | 2 +-
net/ipv4/ip_output.c | 2 +-
net/ipv4/netfilter/nf_flow_table_ipv4.c| 2 +-
net/ipv4/xfrm4_output.c| 3 +-
net/ipv6/ip6_output.c | 2 +-
net/ipv6/netfilter/nf_flow_table_ipv6.c| 2 +-
net/ipv6/xfrm6_output.c| 2 +-
net/mpls/af_mpls.c | 2 +-
net/sched/sch_tbf.c| 3 +-
net/xfrm/xfrm_device.c | 2 +-
14 files changed, 99 insertions(+), 57 deletions(-)
--
2.14.1
[PATCH 1/6] net: rename skb_gso_validate_mtu -> skb_gso_validate_network_len
If you take a GSO skb, and split it into packets, will the network
length (L3 headers + L4 headers + payload) of those packets be small
enough to fit within a given MTU?
skb_gso_validate_mtu gives you the answer to that question. However,
we recently added to add a way to validate the MAC length of a split GSO
skb (L2+L3+L4+payload), and the names get confusing, so rename
skb_gso_validate_mtu to skb_gso_validate_network_len
Signed-off-by: Daniel Axtens
---
include/linux/skbuff.h | 2 +-
net/core/skbuff.c | 11 ++-
net/ipv4/ip_forward.c | 2 +-
net/ipv4/ip_output.c| 2 +-
net/ipv4/netfilter/nf_flow_table_ipv4.c | 2 +-
net/ipv6/ip6_output.c | 2 +-
net/ipv6/netfilter/nf_flow_table_ipv6.c | 2 +-
net/mpls/af_mpls.c | 2 +-
net/xfrm/xfrm_device.c | 2 +-
9 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 9bc1750ca3d3..eeb76bb7730a 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3289,7 +3289,7 @@ void skb_split(struct sk_buff *skb, struct sk_buff *skb1,
const u32 len);
int skb_shift(struct sk_buff *tgt, struct sk_buff *skb, int shiftlen);
void skb_scrub_packet(struct sk_buff *skb, bool xnet);
unsigned int skb_gso_transport_seglen(const struct sk_buff *skb);
-bool skb_gso_validate_mtu(const struct sk_buff *skb, unsigned int mtu);
+bool skb_gso_validate_network_len(const struct sk_buff *skb, unsigned int mtu);
bool skb_gso_validate_mac_len(const struct sk_buff *skb, unsigned int len);
struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features);
struct sk_buff *skb_vlan_untag(struct sk_buff *skb);
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 96d36b81a3a5..0c0c1d6f28ef 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4957,19 +4957,20 @@ static inline bool skb_gso_size_check(const struct
sk_buff *skb,
}
/**
- * skb_gso_validate_mtu - Return in case such skb fits a given MTU
+ * skb_gso_validate_network_len - Will a split GSO skb fit into a given MTU?
*
* @skb: GSO skb
* @mtu: MTU to validate against
*
- * skb_gso_validate_mtu validates if a given skb will fit a wanted MTU
- * once split.
+ * skb_gso_validate_network_len validates if a given skb will fit a
+ * wanted MTU once split. It considers L3 headers, L4 headers, and the
+ * payload.
*/
-bool skb_gso_validate_mtu(const struct sk_buff *skb, unsigned int mtu)
+bool skb_gso_validate_network_len(const struct sk_buff *skb, unsigned int mtu)
{
return skb_gso_size_check(skb, skb_gso_network_seglen(skb), mtu);
}
-EXPORT_SYMBOL_GPL(skb_gso_validate_mtu);
+EXPORT_SYMBOL_GPL(skb_gso_validate_network_len);
/**
* skb_gso_validate_mac_len - Will a split GSO skb fit in a given length?
diff --git a/net/ipv4/ip_forward.c b/net/ipv4/ip_forward.c
index 2dd21c3281a1..b54b948b0596 100644
--- a/net/ipv4/ip_forward.c
+++ b/net/ipv4/ip_forward.c
@@ -55,7 +55,7 @@ static bool ip_exceeds_mtu(const struct sk_buff *skb,
unsigned int mtu)
if (skb->ignore_df)
return false;
- if (skb_is_gso(skb) && skb_gso_validate_mtu(skb, mtu))
+ if (skb_is_gso(skb) && skb_gso_validate_network_len(skb, mtu))
return false;
return true;
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index e8e675be60ec..66340ab750e6 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -248,7 +248,7 @@ static int ip_finish_output_gso(struct net *net, struct
sock *sk,
/* common case: seglen is <= mtu
*/
- if (skb_gso_validate_mtu(skb, mtu))
+ if (skb_gso_validate_network_len(skb, mtu))
return ip_finish_output2(net, sk, skb);
/* Slowpath - GSO segment length exceeds the egress MTU.
diff --git a/net/ipv4/netfilter/nf_flow_table_ipv4.c
b/net/ipv4/netfilter/nf_flow_table_ipv4.c
index 25d2975da156..2447077d163d 100644
--- a/net/ipv4/netfilter/nf_flow_table_ipv4.c
+++ b/net/ipv4/netfilter/nf_flow_table_ipv4.c
@@ -185,7 +185,7 @@ static bool __nf_flow_exceeds_mtu(const struct sk_buff
*skb, unsigned int mtu)
if ((ip_hdr(skb)->frag_off & htons(IP_DF)) == 0)
return false;
- if (skb_is_gso(skb) && skb_gso_validate_mtu(skb, mtu))
+ if (skb_is_gso(skb) && skb_gso_validate_network_len(skb, mtu))
return false;
return true;
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 997c7f19ad62..a8a919520090 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -412,7 +412,7 @@ static bool ip6_pkt_too_big(const struct sk_buff *skb,
unsigned int mtu)
if (skb->ignore_df)
return false;
- if (skb_is_gso(skb) && skb_gso_validate_mtu(skb, mtu))
+ if (skb_is_gso(skb) && skb_gso_validate_network_len(skb, mtu))
return false;
return true;
diff --git a/
[PATCH 2/6] net: sched: tbf: handle GSO_BY_FRAGS case in enqueue
tbf_enqueue() checks the size of a packet before enqueuing it.
However, the GSO size check does not consider the GSO_BY_FRAGS
case, and so will drop GSO SCTP packets, causing a massive drop
in throughput.
Use skb_gso_validate_mac_len() instead, as it does consider that
case.
Signed-off-by: Daniel Axtens
---
net/sched/sch_tbf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c
index 229172d509cc..03225a8df973 100644
--- a/net/sched/sch_tbf.c
+++ b/net/sched/sch_tbf.c
@@ -188,7 +188,8 @@ static int tbf_enqueue(struct sk_buff *skb, struct Qdisc
*sch,
int ret;
if (qdisc_pkt_len(skb) > q->max_size) {
- if (skb_is_gso(skb) && skb_gso_mac_seglen(skb) <= q->max_size)
+ if (skb_is_gso(skb) &&
+ skb_gso_validate_mac_len(skb, q->max_size))
return tbf_segment(skb, sch, to_free);
return qdisc_drop(skb, sch, to_free);
}
--
2.14.1
[PATCH 5/6] net: add and use helpers when adjusting gso_size
An audit of users of gso_size reveals that an eBPF tc action on a
veth pair can be passed an SCTP GSO skb, which has gso_size of
GSO_BY_FRAGS.
If that action calls bpf_skb_change_proto(), bpf_skb_net_grow()
or bpf_skb_net_shrink(), the gso_size will be unconditionally
incremented or decremented to some nonsense value.
Add helpers that WARN if attempting to change a gso_size of a
GSO_BY_FRAGS skb (and leave the value unchanged).
Signed-off-by: Daniel Axtens
---
Documentation/networking/segmentation-offloads.txt | 11 +--
include/linux/skbuff.h | 16
net/core/filter.c | 8
3 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/Documentation/networking/segmentation-offloads.txt
b/Documentation/networking/segmentation-offloads.txt
index d47480b61ac6..23a8dd91a9ec 100644
--- a/Documentation/networking/segmentation-offloads.txt
+++ b/Documentation/networking/segmentation-offloads.txt
@@ -153,8 +153,15 @@ To signal this, gso_size is set to the special value
GSO_BY_FRAGS.
Therefore, any code in the core networking stack must be aware of the
possibility that gso_size will be GSO_BY_FRAGS and handle that case
-appropriately. (For size checks, the skb_gso_validate_*_len family of
-helpers do this automatically.)
+appropriately.
+
+There are a couple of helpers to make this easier:
+
+ - For size checks, the skb_gso_validate_*_len family of helpers correctly
+ considers GSO_BY_FRAGS.
+
+ - For manipulating packets, skb_increase_gso_size and skb_decrease_gso_size
+ will check for GSO_BY_FRAGS and WARN if asked to manipulate these skbs.
This also affects drivers with the NETIF_F_FRAGLIST & NETIF_F_GSO_SCTP bits
set. Note also that NETIF_F_GSO_SCTP is included in NETIF_F_GSO_SOFTWARE.
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index d8340e6e8814..157a91864e16 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -4047,6 +4047,22 @@ static inline void skb_gso_reset(struct sk_buff *skb)
skb_shinfo(skb)->gso_type = 0;
}
+static inline void skb_increase_gso_size(struct sk_buff *skb, u16 increment)
+{
+ if (WARN_ON_ONCE(skb_shinfo(skb)->gso_size == GSO_BY_FRAGS))
+ return;
+
+ skb_shinfo(skb)->gso_size += increment;
+}
+
+static inline void skb_decrease_gso_size(struct sk_buff *skb, u16 decrement)
+{
+ if (WARN_ON_ONCE(skb_shinfo(skb)->gso_size == GSO_BY_FRAGS))
+ return;
+
+ skb_shinfo(skb)->gso_size -= decrement;
+}
+
void __skb_warn_lro_forwarding(const struct sk_buff *skb);
static inline bool skb_warn_if_lro(const struct sk_buff *skb)
diff --git a/net/core/filter.c b/net/core/filter.c
index 0c121adbdbaa..d9684d8a3ac7 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2105,7 +2105,7 @@ static int bpf_skb_proto_4_to_6(struct sk_buff *skb)
}
/* Due to IPv6 header, MSS needs to be downgraded. */
- skb_shinfo(skb)->gso_size -= len_diff;
+ skb_decrease_gso_size(skb, len_diff);
/* Header must be checked, and gso_segs recomputed. */
skb_shinfo(skb)->gso_type |= SKB_GSO_DODGY;
skb_shinfo(skb)->gso_segs = 0;
@@ -2141,7 +2141,7 @@ static int bpf_skb_proto_6_to_4(struct sk_buff *skb)
}
/* Due to IPv4 header, MSS can be upgraded. */
- skb_shinfo(skb)->gso_size += len_diff;
+ skb_increase_gso_size(skb, len_diff);
/* Header must be checked, and gso_segs recomputed. */
skb_shinfo(skb)->gso_type |= SKB_GSO_DODGY;
skb_shinfo(skb)->gso_segs = 0;
@@ -2253,7 +2253,7 @@ static int bpf_skb_net_grow(struct sk_buff *skb, u32
len_diff)
if (skb_is_gso(skb)) {
/* Due to header grow, MSS needs to be downgraded. */
- skb_shinfo(skb)->gso_size -= len_diff;
+ skb_decrease_gso_size(skb, len_diff);
/* Header must be checked, and gso_segs recomputed. */
skb_shinfo(skb)->gso_type |= SKB_GSO_DODGY;
skb_shinfo(skb)->gso_segs = 0;
@@ -2277,7 +2277,7 @@ static int bpf_skb_net_shrink(struct sk_buff *skb, u32
len_diff)
if (skb_is_gso(skb)) {
/* Due to header shrink, MSS can be upgraded. */
- skb_shinfo(skb)->gso_size += len_diff;
+ skb_increase_gso_size(skb, len_diff);
/* Header must be checked, and gso_segs recomputed. */
skb_shinfo(skb)->gso_type |= SKB_GSO_DODGY;
skb_shinfo(skb)->gso_segs = 0;
--
2.14.1
[PATCH 4/6] net: make skb_gso_*_seglen functions private
They're very hard to use properly as they do not consider the
GSO_BY_FRAGS case. Code should use skb_gso_validate_network_len
and skb_gso_validate_mac_len as they do consider this case.
Make the seglen functions static inline, which stops people
using them, and also means the validate functions don't have
to make any out of line calls.
Signed-off-by: Daniel Axtens
---
include/linux/skbuff.h | 33 -
net/core/skbuff.c | 37 +++--
2 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index eeb76bb7730a..d8340e6e8814 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3288,7 +3288,6 @@ int skb_zerocopy(struct sk_buff *to, struct sk_buff *from,
void skb_split(struct sk_buff *skb, struct sk_buff *skb1, const u32 len);
int skb_shift(struct sk_buff *tgt, struct sk_buff *skb, int shiftlen);
void skb_scrub_packet(struct sk_buff *skb, bool xnet);
-unsigned int skb_gso_transport_seglen(const struct sk_buff *skb);
bool skb_gso_validate_network_len(const struct sk_buff *skb, unsigned int mtu);
bool skb_gso_validate_mac_len(const struct sk_buff *skb, unsigned int len);
struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features);
@@ -4107,38 +4106,6 @@ static inline bool skb_head_is_locked(const struct
sk_buff *skb)
return !skb->head_frag || skb_cloned(skb);
}
-/**
- * skb_gso_network_seglen - Return length of individual segments of a gso
packet
- *
- * @skb: GSO skb
- *
- * skb_gso_network_seglen is used to determine the real size of the
- * individual segments, including Layer3 (IP, IPv6) and L4 headers (TCP/UDP).
- *
- * The MAC/L2 header is not accounted for.
- */
-static inline unsigned int skb_gso_network_seglen(const struct sk_buff *skb)
-{
- unsigned int hdr_len = skb_transport_header(skb) -
- skb_network_header(skb);
- return hdr_len + skb_gso_transport_seglen(skb);
-}
-
-/**
- * skb_gso_mac_seglen - Return length of individual segments of a gso packet
- *
- * @skb: GSO skb
- *
- * skb_gso_mac_seglen is used to determine the real size of the
- * individual segments, including MAC/L2, Layer3 (IP, IPv6) and L4
- * headers (TCP/UDP).
- */
-static inline unsigned int skb_gso_mac_seglen(const struct sk_buff *skb)
-{
- unsigned int hdr_len = skb_transport_header(skb) - skb_mac_header(skb);
- return hdr_len + skb_gso_transport_seglen(skb);
-}
-
/* Local Checksum Offload.
* Compute outer checksum based on the assumption that the
* inner checksum will be offloaded later.
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 0c0c1d6f28ef..a664a3ae507e 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4893,7 +4893,7 @@ EXPORT_SYMBOL_GPL(skb_scrub_packet);
*
* The MAC/L2 or network (IP, IPv6) headers are not accounted for.
*/
-unsigned int skb_gso_transport_seglen(const struct sk_buff *skb)
+static inline unsigned int skb_gso_transport_seglen(const struct sk_buff *skb)
{
const struct skb_shared_info *shinfo = skb_shinfo(skb);
unsigned int thlen = 0;
@@ -4915,7 +4915,40 @@ unsigned int skb_gso_transport_seglen(const struct
sk_buff *skb)
*/
return thlen + shinfo->gso_size;
}
-EXPORT_SYMBOL_GPL(skb_gso_transport_seglen);
+
+/**
+ * skb_gso_network_seglen - Return length of individual segments of a gso
packet
+ *
+ * @skb: GSO skb
+ *
+ * skb_gso_network_seglen is used to determine the real size of the
+ * individual segments, including Layer3 (IP, IPv6) and L4 headers (TCP/UDP).
+ *
+ * The MAC/L2 header is not accounted for.
+ */
+static inline unsigned int skb_gso_network_seglen(const struct sk_buff *skb)
+{
+ unsigned int hdr_len = skb_transport_header(skb) -
+ skb_network_header(skb);
+
+ return hdr_len + skb_gso_transport_seglen(skb);
+}
+
+/**
+ * skb_gso_mac_seglen - Return length of individual segments of a gso packet
+ *
+ * @skb: GSO skb
+ *
+ * skb_gso_mac_seglen is used to determine the real size of the
+ * individual segments, including MAC/L2, Layer3 (IP, IPv6) and L4
+ * headers (TCP/UDP).
+ */
+static inline unsigned int skb_gso_mac_seglen(const struct sk_buff *skb)
+{
+ unsigned int hdr_len = skb_transport_header(skb) - skb_mac_header(skb);
+
+ return hdr_len + skb_gso_transport_seglen(skb);
+}
/**
* skb_gso_size_check - check the skb size, considering GSO_BY_FRAGS
--
2.14.1
[PATCH 3/6] net: xfrm: use skb_gso_validate_network_len() to check gso sizes
Replace skb_gso_network_seglen() with
skb_gso_validate_network_len(), as it considers the GSO_BY_FRAGS
case.
Signed-off-by: Daniel Axtens
---
net/ipv4/xfrm4_output.c | 3 ++-
net/ipv6/xfrm6_output.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c
index 94b8702603bc..be980c195fc5 100644
--- a/net/ipv4/xfrm4_output.c
+++ b/net/ipv4/xfrm4_output.c
@@ -30,7 +30,8 @@ static int xfrm4_tunnel_check_size(struct sk_buff *skb)
mtu = dst_mtu(skb_dst(skb));
if ((!skb_is_gso(skb) && skb->len > mtu) ||
- (skb_is_gso(skb) && skb_gso_network_seglen(skb) >
ip_skb_dst_mtu(skb->sk, skb))) {
+ (skb_is_gso(skb) &&
+!skb_gso_validate_network_len(skb, ip_skb_dst_mtu(skb->sk, skb
{
skb->protocol = htons(ETH_P_IP);
if (skb->sk)
diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c
index 8ae87d4ec5ff..5959ce9620eb 100644
--- a/net/ipv6/xfrm6_output.c
+++ b/net/ipv6/xfrm6_output.c
@@ -82,7 +82,7 @@ static int xfrm6_tunnel_check_size(struct sk_buff *skb)
if ((!skb_is_gso(skb) && skb->len > mtu) ||
(skb_is_gso(skb) &&
-skb_gso_network_seglen(skb) > ip6_skb_dst_mtu(skb))) {
+!skb_gso_validate_network_len(skb, ip6_skb_dst_mtu(skb {
skb->dev = dst->dev;
skb->protocol = htons(ETH_P_IPV6);
--
2.14.1
[PATCH 6/6] net: filter: refuse to change gso_size of SCTP packets
An eBPF tc action on a veth pair can be passed an SCTP GSO skb, which
has gso_size of GSO_BY_FRAGS.
If that action calls bpf_skb_change_proto(), bpf_skb_net_grow()
or bpf_skb_net_shrink(), the code will unconditionally attempt to
increment or decrement the gso_size to some nonsense value.
It's not clear how this could be done correctly, so simply refuse
to operate on SCTP GSO skbs.
Cc: Marcelo Ricardo Leitner
Signed-off-by: Daniel Axtens
---
Marcelo - I am not an SCTP expert by any means, so if this code should
be doing something else, please let me know.
---
net/core/filter.c | 16
1 file changed, 16 insertions(+)
diff --git a/net/core/filter.c b/net/core/filter.c
index d9684d8a3ac7..f189c988962e 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2096,6 +2096,10 @@ static int bpf_skb_proto_4_to_6(struct sk_buff *skb)
return ret;
if (skb_is_gso(skb)) {
+ /* SCTP uses GSO_BY_FRAGS, cannot adjust */
+ if (unlikely(skb_shinfo(skb)->gso_type & SKB_GSO_SCTP))
+ return -ENOTSUPP;
+
/* SKB_GSO_TCPV4 needs to be changed into
* SKB_GSO_TCPV6.
*/
@@ -2132,6 +2136,10 @@ static int bpf_skb_proto_6_to_4(struct sk_buff *skb)
return ret;
if (skb_is_gso(skb)) {
+ /* SCTP uses GSO_BY_FRAGS, cannot adjust */
+ if (unlikely(skb_shinfo(skb)->gso_type & SKB_GSO_SCTP))
+ return -ENOTSUPP;
+
/* SKB_GSO_TCPV6 needs to be changed into
* SKB_GSO_TCPV4.
*/
@@ -2252,6 +2260,10 @@ static int bpf_skb_net_grow(struct sk_buff *skb, u32
len_diff)
return ret;
if (skb_is_gso(skb)) {
+ /* SCTP uses GSO_BY_FRAGS, cannot adjust */
+ if (unlikely(skb_shinfo(skb)->gso_type & SKB_GSO_SCTP))
+ return -ENOTSUPP;
+
/* Due to header grow, MSS needs to be downgraded. */
skb_decrease_gso_size(skb, len_diff);
/* Header must be checked, and gso_segs recomputed. */
@@ -2276,6 +2288,10 @@ static int bpf_skb_net_shrink(struct sk_buff *skb, u32
len_diff)
return ret;
if (skb_is_gso(skb)) {
+ /* SCTP uses GSO_BY_FRAGS, cannot adjust */
+ if (unlikely(skb_shinfo(skb)->gso_type & SKB_GSO_SCTP))
+ return -ENOTSUPP;
+
/* Due to header shrink, MSS can be upgraded. */
skb_increase_gso_size(skb, len_diff);
/* Header must be checked, and gso_segs recomputed. */
--
2.14.1
Re: [PATCH] cdc_ether: flag the Cinterion PLS8 modem by gemalto as WWAN
Am Dienstag, den 27.02.2018, 14:04 +0100 schrieb Bassem Boubaker: > The Cinterion PL8 is an LTE modem with 2 possible WWAN interfaces. > > The modem is controlled via AT commands through the exposed TTYs. > > AT^SWWAN write command can be used to activate or deactivate a WWAN > connection for a PDP context defined with AT+CGDCONT. UE supports > two WWAN adapter. Both WWAN adapters can be activated a the same time > > Signed-off-by: Bassem Boubaker Acked-by: Oliver Neukum
[PATCH net] af_smc: fix NULL pointer dereference on sock_create_kern() error path
when sock_create_kern(..., a) returns an error, 'a' might not be a valid
pointer, so it shouldn't be dereferenced to read a->sk->sk_sndbuf and
and a->sk->sk_rcvbuf; not doing that caused the following crash:
general protection fault: [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 4254 Comm: syzkaller919713 Not tainted 4.16.0-rc1+ #18
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:smc_create+0x14e/0x300 net/smc/af_smc.c:1410
RSP: 0018:8801b06afbc8 EFLAGS: 00010202
RAX: dc00 RBX: 8801b63457c0 RCX: 85a3e746
RDX: 0004 RSI: RDI: 0020
RBP: 8801b06afbf0 R08: 07c0 R09:
R10: R11: R12:
R13: 8801b6345c08 R14: ffe9 R15: 8695ced0
FS: 01afb880() GS:8801db20()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 2040 CR3: 0001b0721004 CR4: 001606f0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
__sock_create+0x4d4/0x850 net/socket.c:1285
sock_create net/socket.c:1325 [inline]
SYSC_socketpair net/socket.c:1409 [inline]
SyS_socketpair+0x1c0/0x6f0 net/socket.c:1366
do_syscall_64+0x282/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x26/0x9b
RIP: 0033:0x4404b9
RSP: 002b:7fff44ab6908 EFLAGS: 0246 ORIG_RAX: 0035
RAX: ffda RBX: RCX: 004404b9
RDX: RSI: 0001 RDI: 002b
RBP: 7fff44ab6910 R08: 0002 R09: 7fff44003031
R10: 2040 R11: 0246 R12:
R13: 0006 R14: R15:
Code: 48 c1 ea 03 80 3c 02 00 0f 85 b3 01 00 00 4c 8b a3 48 04 00 00 48
b8
00 00 00 00 00 fc ff df 49 8d 7c 24 20 48 89 fa 48 c1 ea 03 <80> 3c 02
00
0f 85 82 01 00 00 4d 8b 7c 24 20 48 b8 00 00 00 00
RIP: smc_create+0x14e/0x300 net/smc/af_smc.c:1410 RSP: 8801b06afbc8
Fixes: cd6851f30386 smc: remote memory buffers (RMBs)
Reported-and-tested-by: syzbot+aa0227369be2dcc26...@syzkaller.appspotmail.com
Signed-off-by: Davide Caratti
---
net/smc/af_smc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index da1a5cdefd13..8cc97834d4f6 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -1406,8 +1406,10 @@ static int smc_create(struct net *net, struct socket
*sock, int protocol,
smc->use_fallback = false; /* assume rdma capability first */
rc = sock_create_kern(net, PF_INET, SOCK_STREAM,
IPPROTO_TCP, &smc->clcsock);
- if (rc)
+ if (rc) {
sk_common_release(sk);
+ goto out;
+ }
smc->sk.sk_sndbuf = max(smc->clcsock->sk->sk_sndbuf, SMC_BUF_MIN_SIZE);
smc->sk.sk_rcvbuf = max(smc->clcsock->sk->sk_rcvbuf, SMC_BUF_MIN_SIZE);
--
2.14.3
Re: [v2,1/6] wl1251: Update wl->nvs_len after wl->nvs is valid
Pali Rohár wrote: > If kmemdup fails, then wl->nvs_len will contain invalid non-zero size. > > Signed-off-by: Pali Rohár > Acked-by: Pavel Machek 4 patches applied to wireless-drivers-next.git, thanks. f63b4c971f5f wl1251: Update wl->nvs_len after wl->nvs is valid 562da3a39cb7 wl1251: Generate random MAC address only if driver does not have valid 4f507d588d08 wl1251: Parse and use MAC address from supplied NVS data 3142467fc15b wl1251: Set generated MAC address back to NVS data -- https://patchwork.kernel.org/patch/10052101/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[patch net-next 04/15] ip_tunnel: Rename & publish init_tunnel_flow
From: Petr Machata
Initializing struct flowi4 is useful for drivers that need to emulate
routing decisions made by a tunnel interface. Publish the
function (appropriately renamed) so that the drivers in question don't
need to cut'n'paste it around.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Signed-off-by: Jiri Pirko
---
include/net/ip_tunnels.h | 16
net/ipv4/ip_tunnel.c | 40
2 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h
index 1f16773cfd76..cbe5addb9293 100644
--- a/include/net/ip_tunnels.h
+++ b/include/net/ip_tunnels.h
@@ -254,6 +254,22 @@ static inline __be32 tunnel_id_to_key32(__be64 tun_id)
#ifdef CONFIG_INET
+static inline void ip_tunnel_init_flow(struct flowi4 *fl4,
+ int proto,
+ __be32 daddr, __be32 saddr,
+ __be32 key, __u8 tos, int oif,
+ __u32 mark)
+{
+ memset(fl4, 0, sizeof(*fl4));
+ fl4->flowi4_oif = oif;
+ fl4->daddr = daddr;
+ fl4->saddr = saddr;
+ fl4->flowi4_tos = tos;
+ fl4->flowi4_proto = proto;
+ fl4->fl4_gre_key = key;
+ fl4->flowi4_mark = mark;
+}
+
int ip_tunnel_init(struct net_device *dev);
void ip_tunnel_uninit(struct net_device *dev);
void ip_tunnel_dellink(struct net_device *dev, struct list_head *head);
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index d786a8441bce..b2117d89bc83 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -290,22 +290,6 @@ static struct net_device *__ip_tunnel_create(struct net
*net,
return ERR_PTR(err);
}
-static inline void init_tunnel_flow(struct flowi4 *fl4,
- int proto,
- __be32 daddr, __be32 saddr,
- __be32 key, __u8 tos, int oif,
- __u32 mark)
-{
- memset(fl4, 0, sizeof(*fl4));
- fl4->flowi4_oif = oif;
- fl4->daddr = daddr;
- fl4->saddr = saddr;
- fl4->flowi4_tos = tos;
- fl4->flowi4_proto = proto;
- fl4->fl4_gre_key = key;
- fl4->flowi4_mark = mark;
-}
-
static int ip_tunnel_bind_dev(struct net_device *dev)
{
struct net_device *tdev = NULL;
@@ -322,10 +306,10 @@ static int ip_tunnel_bind_dev(struct net_device *dev)
struct flowi4 fl4;
struct rtable *rt;
- init_tunnel_flow(&fl4, iph->protocol, iph->daddr,
-iph->saddr, tunnel->parms.o_key,
-RT_TOS(iph->tos), tunnel->parms.link,
-tunnel->fwmark);
+ ip_tunnel_init_flow(&fl4, iph->protocol, iph->daddr,
+ iph->saddr, tunnel->parms.o_key,
+ RT_TOS(iph->tos), tunnel->parms.link,
+ tunnel->fwmark);
rt = ip_route_output_key(tunnel->net, &fl4);
if (!IS_ERR(rt)) {
@@ -581,8 +565,8 @@ void ip_md_tunnel_xmit(struct sk_buff *skb, struct
net_device *dev, u8 proto)
else if (skb->protocol == htons(ETH_P_IPV6))
tos = ipv6_get_dsfield((const struct ipv6hdr
*)inner_iph);
}
- init_tunnel_flow(&fl4, proto, key->u.ipv4.dst, key->u.ipv4.src, 0,
-RT_TOS(tos), tunnel->parms.link, tunnel->fwmark);
+ ip_tunnel_init_flow(&fl4, proto, key->u.ipv4.dst, key->u.ipv4.src, 0,
+ RT_TOS(tos), tunnel->parms.link, tunnel->fwmark);
if (tunnel->encap.type != TUNNEL_ENCAP_NONE)
goto tx_error;
rt = ip_route_output_key(tunnel->net, &fl4);
@@ -711,14 +695,14 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct
net_device *dev,
}
if (tunnel->fwmark) {
- init_tunnel_flow(&fl4, protocol, dst, tnl_params->saddr,
-tunnel->parms.o_key, RT_TOS(tos),
tunnel->parms.link,
-tunnel->fwmark);
+ ip_tunnel_init_flow(&fl4, protocol, dst, tnl_params->saddr,
+ tunnel->parms.o_key, RT_TOS(tos),
+ tunnel->parms.link, tunnel->fwmark);
}
else {
- init_tunnel_flow(&fl4, protocol, dst, tnl_params->saddr,
-tunnel->parms.o_key, RT_TOS(tos),
tunnel->parms.link,
-skb->mark);
+ ip_tunnel_init_flow(&fl4, protocol, dst, tnl_params->saddr,
+ tunnel->parms.o_key, RT_TOS(tos),
+ tunnel->parms.link, skb->mark);
}
if (ip_tunnel_encap(skb, tunnel, &protocol, &fl4) < 0)
--
2.14.3
[patch net-next 01/15] mlxsw: spectrum_ipip: Extract mlxsw_sp_l3addr_is_zero
From: Petr Machata
Extract the logic for determining whether a given IPv4/IPv6 address is
all-zeroes from mlxsw_sp_ipip_tunnel_complete to a separate function.
Make that function public within the module.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Signed-off-by: Jiri Pirko
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.c | 16 +++-
drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.h | 6 --
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.c
index a1c4b1e63f8d..03788182 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.c
@@ -1,7 +1,7 @@
/*
* drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.c
- * Copyright (c) 2017 Mellanox Technologies. All rights reserved.
- * Copyright (c) 2017 Petr Machata
+ * Copyright (c) 2017-2018 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2017-2018 Petr Machata
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -122,6 +122,13 @@ mlxsw_sp_ipip_netdev_daddr(enum mlxsw_sp_l3proto proto,
return (union mlxsw_sp_l3addr) {0};
}
+bool mlxsw_sp_l3addr_is_zero(union mlxsw_sp_l3addr addr)
+{
+ union mlxsw_sp_l3addr naddr = {0};
+
+ return !memcmp(&addr, &naddr, sizeof(naddr));
+}
+
static int
mlxsw_sp_ipip_nexthop_update_gre4(struct mlxsw_sp *mlxsw_sp, u32 adj_index,
struct mlxsw_sp_ipip_entry *ipip_entry)
@@ -215,15 +222,14 @@ static bool mlxsw_sp_ipip_tunnel_complete(enum
mlxsw_sp_l3proto proto,
{
union mlxsw_sp_l3addr saddr = mlxsw_sp_ipip_netdev_saddr(proto, ol_dev);
union mlxsw_sp_l3addr daddr = mlxsw_sp_ipip_netdev_daddr(proto, ol_dev);
- union mlxsw_sp_l3addr naddr = {0};
/* Tunnels with unset local or remote address are valid in Linux and
* used for lightweight tunnels (LWT) and Non-Broadcast Multi-Access
* (NBMA) tunnels. In principle these can be offloaded, but the driver
* currently doesn't support this. So punt.
*/
- return memcmp(&saddr, &naddr, sizeof(naddr)) &&
- memcmp(&daddr, &naddr, sizeof(naddr));
+ return !mlxsw_sp_l3addr_is_zero(saddr) &&
+ !mlxsw_sp_l3addr_is_zero(daddr);
}
static bool mlxsw_sp_ipip_can_offload_gre4(const struct mlxsw_sp *mlxsw_sp,
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.h
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.h
index a4ff5737eccc..888f19000209 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.h
@@ -1,7 +1,7 @@
/*
* drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.h
- * Copyright (c) 2017 Mellanox Technologies. All rights reserved.
- * Copyright (c) 2017 Petr Machata
+ * Copyright (c) 2017-2018 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2017-2018 Petr Machata
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -46,6 +46,8 @@ union mlxsw_sp_l3addr
mlxsw_sp_ipip_netdev_saddr(enum mlxsw_sp_l3proto proto,
const struct net_device *ol_dev);
+bool mlxsw_sp_l3addr_is_zero(union mlxsw_sp_l3addr addr);
+
enum mlxsw_sp_ipip_type {
MLXSW_SP_IPIP_TYPE_GRE4,
MLXSW_SP_IPIP_TYPE_MAX,
--
2.14.3
[patch net-next 06/15] mlxsw: reg: Extend mlxsw_reg_mpat_pack()
From: Petr Machata
To support encapsulated SPAN, extend mlxsw_reg_mpat_pack() with a field
to set the SPAN type.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Signed-off-by: Jiri Pirko
---
drivers/net/ethernet/mellanox/mlxsw/reg.h | 4 +++-
drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c | 6 --
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/reg.h
b/drivers/net/ethernet/mellanox/mlxsw/reg.h
index 2aaccbac3ed1..cb5f77f09f8e 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/reg.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/reg.h
@@ -6868,7 +6868,8 @@ MLXSW_ITEM32(reg, mpat, eth_rspan_sip4, 0x5C, 0, 32);
MLXSW_ITEM_BUF(reg, mpat, eth_rspan_sip6, 0x50, 16);
static inline void mlxsw_reg_mpat_pack(char *payload, u8 pa_id,
- u16 system_port, bool e)
+ u16 system_port, bool e,
+ enum mlxsw_reg_mpat_span_type span_type)
{
MLXSW_REG_ZERO(mpat, payload);
mlxsw_reg_mpat_pa_id_set(payload, pa_id);
@@ -6876,6 +6877,7 @@ static inline void mlxsw_reg_mpat_pack(char *payload, u8
pa_id,
mlxsw_reg_mpat_e_set(payload, e);
mlxsw_reg_mpat_qos_set(payload, 1);
mlxsw_reg_mpat_be_set(payload, 1);
+ mlxsw_reg_mpat_span_type_set(payload, span_type);
}
static inline void mlxsw_reg_mpat_eth_rspan_pack(char *payload, u16 vid)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
index c3bec37d71ed..1433d4890b88 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
@@ -93,7 +93,8 @@ mlxsw_sp_span_entry_create(struct mlxsw_sp_port *port)
return NULL;
/* create a new port analayzer entry for local_port */
- mlxsw_reg_mpat_pack(mpat_pl, index, local_port, true);
+ mlxsw_reg_mpat_pack(mpat_pl, index, local_port, true,
+ MLXSW_REG_MPAT_SPAN_TYPE_LOCAL_ETH);
err = mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(mpat), mpat_pl);
if (err)
return NULL;
@@ -111,7 +112,8 @@ static void mlxsw_sp_span_entry_destroy(struct mlxsw_sp
*mlxsw_sp,
char mpat_pl[MLXSW_REG_MPAT_LEN];
int pa_id = span_entry->id;
- mlxsw_reg_mpat_pack(mpat_pl, pa_id, local_port, false);
+ mlxsw_reg_mpat_pack(mpat_pl, pa_id, local_port, false,
+ MLXSW_REG_MPAT_SPAN_TYPE_LOCAL_ETH);
mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(mpat), mpat_pl);
}
--
2.14.3
[patch net-next 09/15] mlxsw: spectrum_span: Extract mlxsw_sp_span_entry_{de,}configure()
From: Petr Machata
Configuring the hardware for encapsulated SPAN involves more code than
the simple mirroring case. Extract the related code to a separate
function to separate it from the rest of SPAN entry creation. Extract
deconfigure as well for symmetry, even though disablement is the same
regardless of SPAN type.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Signed-off-by: Jiri Pirko
---
.../net/ethernet/mellanox/mlxsw/spectrum_span.c| 43 +++---
1 file changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
index 5c87e6dfc5a1..442771908600 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
@@ -73,15 +73,40 @@ void mlxsw_sp_span_fini(struct mlxsw_sp *mlxsw_sp)
kfree(mlxsw_sp->span.entries);
}
+static int
+mlxsw_sp_span_entry_configure(struct mlxsw_sp *mlxsw_sp,
+ struct mlxsw_sp_span_entry *span_entry,
+ u8 local_port)
+{
+ char mpat_pl[MLXSW_REG_MPAT_LEN];
+ int pa_id = span_entry->id;
+
+ /* Create a new port analayzer entry for local_port. */
+ mlxsw_reg_mpat_pack(mpat_pl, pa_id, local_port, true,
+ MLXSW_REG_MPAT_SPAN_TYPE_LOCAL_ETH);
+ return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(mpat), mpat_pl);
+}
+
+static void
+mlxsw_sp_span_entry_deconfigure(struct mlxsw_sp *mlxsw_sp,
+ struct mlxsw_sp_span_entry *span_entry)
+{
+ u8 local_port = span_entry->local_port;
+ char mpat_pl[MLXSW_REG_MPAT_LEN];
+ int pa_id = span_entry->id;
+
+ mlxsw_reg_mpat_pack(mpat_pl, pa_id, local_port, false,
+ MLXSW_REG_MPAT_SPAN_TYPE_LOCAL_ETH);
+ mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(mpat), mpat_pl);
+}
+
static struct mlxsw_sp_span_entry *
mlxsw_sp_span_entry_create(struct mlxsw_sp_port *port)
{
struct mlxsw_sp_span_entry *span_entry = NULL;
struct mlxsw_sp *mlxsw_sp = port->mlxsw_sp;
- char mpat_pl[MLXSW_REG_MPAT_LEN];
u8 local_port = port->local_port;
int i;
- int err;
/* find a free entry to use */
for (i = 0; i < mlxsw_sp->span.entries_count; i++) {
@@ -93,11 +118,7 @@ mlxsw_sp_span_entry_create(struct mlxsw_sp_port *port)
if (!span_entry)
return NULL;
- /* create a new port analayzer entry for local_port */
- mlxsw_reg_mpat_pack(mpat_pl, span_entry->id, local_port, true,
- MLXSW_REG_MPAT_SPAN_TYPE_LOCAL_ETH);
- err = mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(mpat), mpat_pl);
- if (err)
+ if (mlxsw_sp_span_entry_configure(mlxsw_sp, span_entry, local_port))
return NULL;
span_entry->ref_count = 1;
@@ -108,13 +129,7 @@ mlxsw_sp_span_entry_create(struct mlxsw_sp_port *port)
static void mlxsw_sp_span_entry_destroy(struct mlxsw_sp *mlxsw_sp,
struct mlxsw_sp_span_entry *span_entry)
{
- u8 local_port = span_entry->local_port;
- char mpat_pl[MLXSW_REG_MPAT_LEN];
- int pa_id = span_entry->id;
-
- mlxsw_reg_mpat_pack(mpat_pl, pa_id, local_port, false,
- MLXSW_REG_MPAT_SPAN_TYPE_LOCAL_ETH);
- mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(mpat), mpat_pl);
+ mlxsw_sp_span_entry_deconfigure(mlxsw_sp, span_entry);
}
struct mlxsw_sp_span_entry *
--
2.14.3
[patch net-next 11/15] mlxsw: spectrum_span: Generalize SPAN support
From: Petr Machata
To support mirroring to different device types, the functions that
partake in configuring the port analyzer need to be extended to admit
non-trivial SPAN types.
Create a structure where all details of SPAN configuration are kept,
struct mlxsw_sp_span_parms. Also create struct mlxsw_sp_span_entry_ops
to keep per-SPAN-type operations.
Instantiate the latter once for MLXSW_REG_MPAT_SPAN_TYPE_LOCAL_ETH, and
once for a suite of NOP callbacks used for invalidated SPAN entry. Put
the formet as a sole member of a new array mlxsw_sp_span_entry_types,
where all known SPAN types are kept. Introduce a new function,
mlxsw_sp_span_entry_ops(), to look up the right ops suite given a
netdevice.
Change mlxsw_sp_span_mirror_add() to use both parms and ops structures.
Change mlxsw_sp_span_entry_get() and mlxsw_sp_span_entry_create() to
take these as arguments. Modify mlxsw_sp_span_entry_configure() and
mlxsw_sp_span_entry_deconfigure() to dispatch to ops.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Signed-off-by: Jiri Pirko
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 5 -
drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c | 3 -
.../net/ethernet/mellanox/mlxsw/spectrum_span.c| 155 +
.../net/ethernet/mellanox/mlxsw/spectrum_span.h| 17 +++
4 files changed, 147 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index 86991db3478c..b070cad8dba7 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -1266,11 +1266,6 @@ mlxsw_sp_port_add_cls_matchall_mirror(struct
mlxsw_sp_port *mlxsw_sp_port,
return -EINVAL;
}
- if (!mlxsw_sp_port_dev_check(to_dev)) {
- netdev_err(mlxsw_sp_port->dev, "Cannot mirror to a non-spectrum
port");
- return -EOPNOTSUPP;
- }
-
mirror->ingress = ingress;
span_type = ingress ? MLXSW_SP_SPAN_INGRESS : MLXSW_SP_SPAN_EGRESS;
return mlxsw_sp_span_mirror_add(mlxsw_sp_port, to_dev, span_type,
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c
index 50f5eacdfa24..9d7197b9abb1 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c
@@ -581,9 +581,6 @@ int mlxsw_sp_acl_rulei_act_mirror(struct mlxsw_sp *mlxsw_sp,
binding = list_first_entry(&block->binding_list,
struct mlxsw_sp_acl_block_binding, list);
in_port = binding->mlxsw_sp_port;
- if (!mlxsw_sp_port_dev_check(out_dev))
- return -EINVAL;
-
out_port = netdev_priv(out_dev);
if (out_port->mlxsw_sp != mlxsw_sp)
return -EINVAL;
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
index 9819cdcf9e5c..c0e0e9af2da7 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
@@ -74,40 +74,120 @@ void mlxsw_sp_span_fini(struct mlxsw_sp *mlxsw_sp)
}
static int
-mlxsw_sp_span_entry_configure(struct mlxsw_sp *mlxsw_sp,
- struct mlxsw_sp_span_entry *span_entry,
- u8 local_port)
+mlxsw_sp_span_entry_phys_parms(const struct net_device *to_dev,
+ struct mlxsw_sp_span_parms *sparmsp)
+{
+ sparmsp->dest_port = netdev_priv(to_dev);
+ return 0;
+}
+
+static int
+mlxsw_sp_span_entry_phys_configure(struct mlxsw_sp_span_entry *span_entry,
+ struct mlxsw_sp_span_parms sparms)
{
+ struct mlxsw_sp_port *dest_port = sparms.dest_port;
+ struct mlxsw_sp *mlxsw_sp = dest_port->mlxsw_sp;
+ u8 local_port = dest_port->local_port;
char mpat_pl[MLXSW_REG_MPAT_LEN];
int pa_id = span_entry->id;
/* Create a new port analayzer entry for local_port. */
mlxsw_reg_mpat_pack(mpat_pl, pa_id, local_port, true,
MLXSW_REG_MPAT_SPAN_TYPE_LOCAL_ETH);
+
return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(mpat), mpat_pl);
}
static void
-mlxsw_sp_span_entry_deconfigure(struct mlxsw_sp *mlxsw_sp,
- struct mlxsw_sp_span_entry *span_entry)
+mlxsw_sp_span_entry_deconfigure_common(struct mlxsw_sp_span_entry *span_entry,
+ enum mlxsw_reg_mpat_span_type span_type)
{
- struct mlxsw_sp_port *to_port = netdev_priv(span_entry->to_dev);
- u8 local_port = to_port->local_port;
+ struct mlxsw_sp_port *dest_port = span_entry->parms.dest_port;
+ struct mlxsw_sp *mlxsw_sp = dest_port->mlxsw_sp;
+ u8 local_port = dest_port->local_port;
char mpat_pl[MLXSW_REG_MPAT_LEN];
int pa_id = span_entry->id;
- mlxsw_reg_m
[patch net-next 15/15] mlxsw: spectrum_span: Support mirror to ip6gretap
From: Petr Machata
Similarly to mirror-to-gretap, this enables mirroring to IPv6 gretap
netdevice.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Signed-off-by: Jiri Pirko
---
drivers/net/ethernet/mellanox/mlxsw/Kconfig| 2 +
.../net/ethernet/mellanox/mlxsw/spectrum_span.c| 101 +
2 files changed, 103 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/Kconfig
b/drivers/net/ethernet/mellanox/mlxsw/Kconfig
index 830c3e28505e..93d97b4676eb 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlxsw/Kconfig
@@ -80,6 +80,8 @@ config MLXSW_SPECTRUM
select MLXFW
depends on NET_IPGRE
depends on !(MLXSW_CORE=y && NET_IPGRE=m)
+ depends on IPV6_GRE
+ depends on !(MLXSW_CORE=y && IPV6_GRE=m)
default m
---help---
This driver supports Mellanox Technologies Spectrum Ethernet
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
index d5fda4f13c31..f537e1de11d9 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
@@ -35,6 +35,8 @@
#include
#include
#include
+#include
+#include
#include "spectrum.h"
#include "spectrum_span.h"
@@ -290,10 +292,109 @@ static const struct mlxsw_sp_span_entry_ops
mlxsw_sp_span_entry_ops_gretap4 = {
.deconfigure = mlxsw_sp_span_entry_gretap4_deconfigure,
};
+static struct net_device *
+mlxsw_sp_span_gretap6_route(const struct net_device *to_dev,
+ struct in6_addr *saddrp,
+ struct in6_addr *daddrp)
+{
+ struct ip6_tnl *t = netdev_priv(to_dev);
+ struct flowi6 fl6 = t->fl.u.ip6;
+ struct net_device *dev = NULL;
+ struct dst_entry *dst;
+ struct rt6_info *rt6;
+
+ /* We assume "dev" stays valid after dst is released. */
+ ASSERT_RTNL();
+
+ fl6.flowi6_mark = t->parms.fwmark;
+ if (!ip6_tnl_xmit_ctl(t, &fl6.saddr, &fl6.daddr))
+ return NULL;
+
+ dst = ip6_route_output(t->net, NULL, &fl6);
+ if (!dst || dst->error)
+ goto out;
+
+ rt6 = container_of(dst, struct rt6_info, dst);
+
+ dev = dst->dev;
+ *saddrp = fl6.saddr;
+ *daddrp = rt6->rt6i_gateway;
+
+out:
+ dst_release(dst);
+ return dev;
+}
+
+static int
+mlxsw_sp_span_entry_gretap6_parms(const struct net_device *to_dev,
+ struct mlxsw_sp_span_parms *sparmsp)
+{
+ struct __ip6_tnl_parm tparm = mlxsw_sp_ipip_netdev_parms6(to_dev);
+ bool inherit_tos = tparm.flags & IP6_TNL_F_USE_ORIG_TCLASS;
+ union mlxsw_sp_l3addr saddr = { .addr6 = tparm.laddr };
+ union mlxsw_sp_l3addr daddr = { .addr6 = tparm.raddr };
+ bool inherit_ttl = !tparm.hop_limit;
+ union mlxsw_sp_l3addr gw = daddr;
+ struct net_device *l3edev;
+
+ if (!(to_dev->flags & IFF_UP) ||
+ /* Reject tunnels with GRE keys, checksums, etc. */
+ tparm.i_flags || tparm.o_flags ||
+ /* Require a fixed TTL and a TOS copied from the mirrored packet. */
+ inherit_ttl || !inherit_tos ||
+ /* A destination address may not be "any". */
+ mlxsw_sp_l3addr_is_zero(daddr))
+ return mlxsw_sp_span_entry_unoffloadable(sparmsp);
+
+ l3edev = mlxsw_sp_span_gretap6_route(to_dev, &saddr.addr6, &gw.addr6);
+ return mlxsw_sp_span_entry_tunnel_parms_common(l3edev, saddr, daddr, gw,
+ tparm.hop_limit,
+ &nd_tbl, sparmsp);
+}
+
+static int
+mlxsw_sp_span_entry_gretap6_configure(struct mlxsw_sp_span_entry *span_entry,
+ struct mlxsw_sp_span_parms sparms)
+{
+ struct mlxsw_sp_port *dest_port = sparms.dest_port;
+ struct mlxsw_sp *mlxsw_sp = dest_port->mlxsw_sp;
+ u8 local_port = dest_port->local_port;
+ char mpat_pl[MLXSW_REG_MPAT_LEN];
+ int pa_id = span_entry->id;
+
+ /* Create a new port analayzer entry for local_port. */
+ mlxsw_reg_mpat_pack(mpat_pl, pa_id, local_port, true,
+ MLXSW_REG_MPAT_SPAN_TYPE_REMOTE_ETH_L3);
+ mlxsw_reg_mpat_eth_rspan_l2_pack(mpat_pl,
+ MLXSW_REG_MPAT_ETH_RSPAN_VERSION_NO_HEADER,
+ sparms.dmac, false);
+ mlxsw_reg_mpat_eth_rspan_l3_ipv6_pack(mpat_pl, sparms.ttl, sparms.smac,
+ sparms.saddr.addr6,
+ sparms.daddr.addr6);
+
+ return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(mpat), mpat_pl);
+}
+
+static void
+mlxsw_sp_span_entry_gretap6_deconfigure(struct mlxsw_sp_span_entry *span_entry)
+{
+ mlxsw_sp_span_entry_deconfigure_common(span_entry,
+
[patch net-next 13/15] mlxsw: Move a mirroring check to mlxsw_sp_span_entry_create
From: Petr Machata
The check for whether a mirror port (which is a mlxsw front panel port)
belongs to the same mlxsw instance as the mirrored port, is currently
only done in spectrum_acl, even though it's applicable for the matchall
case as well. Thus move it to mlxsw_sp_span_entry_create().
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Signed-off-by: Jiri Pirko
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c | 4
drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c | 6 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c
index 9d7197b9abb1..21ed27ae51e3 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c
@@ -572,7 +572,6 @@ int mlxsw_sp_acl_rulei_act_mirror(struct mlxsw_sp *mlxsw_sp,
struct net_device *out_dev)
{
struct mlxsw_sp_acl_block_binding *binding;
- struct mlxsw_sp_port *out_port;
struct mlxsw_sp_port *in_port;
if (!list_is_singular(&block->binding_list))
@@ -581,9 +580,6 @@ int mlxsw_sp_acl_rulei_act_mirror(struct mlxsw_sp *mlxsw_sp,
binding = list_first_entry(&block->binding_list,
struct mlxsw_sp_acl_block_binding, list);
in_port = binding->mlxsw_sp_port;
- out_port = netdev_priv(out_dev);
- if (out_port->mlxsw_sp != mlxsw_sp)
- return -EINVAL;
return mlxsw_afa_block_append_mirror(rulei->act_block,
in_port->local_port,
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
index 71102f156a97..57df57c7a405 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
@@ -164,7 +164,11 @@ mlxsw_sp_span_entry_configure(struct mlxsw_sp *mlxsw_sp,
struct mlxsw_sp_span_parms sparms)
{
if (sparms.dest_port) {
- if (span_entry->ops->configure(span_entry, sparms)) {
+ if (sparms.dest_port->mlxsw_sp != mlxsw_sp) {
+ netdev_err(span_entry->to_dev, "Cannot mirror to %s,
which belongs to a different mlxsw instance",
+ sparms.dest_port->dev->name);
+ sparms.dest_port = NULL;
+ } else if (span_entry->ops->configure(span_entry, sparms)) {
netdev_err(span_entry->to_dev, "Failed to offload
mirror to %s",
sparms.dest_port->dev->name);
sparms.dest_port = NULL;
--
2.14.3
[patch net-next 03/15] net: GRE: Add is_gretap_dev, is_ip6gretap_dev
From: Petr Machata
Determining whether a device is a GRE device is easily done by
inspecting struct net_device.type. However, for the tap variants, the
type is just ARPHRD_ETHER.
Therefore introduce two predicate functions that use netdev_ops to tell
the tap devices.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Signed-off-by: Jiri Pirko
---
include/net/gre.h | 3 +++
net/ipv4/ip_gre.c | 6 ++
net/ipv6/ip6_gre.c | 6 ++
3 files changed, 15 insertions(+)
diff --git a/include/net/gre.h b/include/net/gre.h
index f90585decbce..797142eee9cd 100644
--- a/include/net/gre.h
+++ b/include/net/gre.h
@@ -37,6 +37,9 @@ struct net_device *gretap_fb_dev_create(struct net *net,
const char *name,
int gre_parse_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
bool *csum_err, __be16 proto, int nhs);
+bool is_gretap_dev(const struct net_device *dev);
+bool is_ip6gretap_dev(const struct net_device *dev);
+
static inline int gre_calc_hlen(__be16 o_flags)
{
int addend = 4;
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 45d97e9b2759..8050be9f6b51 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1322,6 +1322,12 @@ static void ipgre_tap_setup(struct net_device *dev)
ip_tunnel_setup(dev, gre_tap_net_id);
}
+bool is_gretap_dev(const struct net_device *dev)
+{
+ return dev->netdev_ops == &gre_tap_netdev_ops;
+}
+EXPORT_SYMBOL_GPL(is_gretap_dev);
+
static int ipgre_newlink(struct net *src_net, struct net_device *dev,
struct nlattr *tb[], struct nlattr *data[],
struct netlink_ext_ack *extack)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 3c353125546d..0bdd74d4e9c9 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -1784,6 +1784,12 @@ static void ip6gre_tap_setup(struct net_device *dev)
netif_keep_dst(dev);
}
+bool is_ip6gretap_dev(const struct net_device *dev)
+{
+ return dev->netdev_ops == &ip6gre_tap_netdev_ops;
+}
+EXPORT_SYMBOL_GPL(is_ip6gretap_dev);
+
static bool ip6gre_netlink_encap_parms(struct nlattr *data[],
struct ip_tunnel_encap *ipencap)
{
--
2.14.3
[patch net-next 08/15] mlxsw: spectrum_span: Initialize span_entry.id eagerly
From: Petr Machata
It is known statically ahead of time which SPAN entry will have which
ID. Just initialize it eagerly in mlxsw_sp_span_init(), don't wait until
the entry is actually created. This simplifies some code in
mlxsw_sp_span_entry_create()
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Signed-off-by: Jiri Pirko
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
index 9e596b064582..5c87e6dfc5a1 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
@@ -51,8 +51,12 @@ int mlxsw_sp_span_init(struct mlxsw_sp *mlxsw_sp)
if (!mlxsw_sp->span.entries)
return -ENOMEM;
- for (i = 0; i < mlxsw_sp->span.entries_count; i++)
- INIT_LIST_HEAD(&mlxsw_sp->span.entries[i].bound_ports_list);
+ for (i = 0; i < mlxsw_sp->span.entries_count; i++) {
+ struct mlxsw_sp_span_entry *curr = &mlxsw_sp->span.entries[i];
+
+ INIT_LIST_HEAD(&curr->bound_ports_list);
+ curr->id = i;
+ }
return 0;
}
@@ -72,34 +76,30 @@ void mlxsw_sp_span_fini(struct mlxsw_sp *mlxsw_sp)
static struct mlxsw_sp_span_entry *
mlxsw_sp_span_entry_create(struct mlxsw_sp_port *port)
{
+ struct mlxsw_sp_span_entry *span_entry = NULL;
struct mlxsw_sp *mlxsw_sp = port->mlxsw_sp;
- struct mlxsw_sp_span_entry *span_entry;
char mpat_pl[MLXSW_REG_MPAT_LEN];
u8 local_port = port->local_port;
- int index;
int i;
int err;
/* find a free entry to use */
- index = -1;
for (i = 0; i < mlxsw_sp->span.entries_count; i++) {
if (!mlxsw_sp->span.entries[i].ref_count) {
- index = i;
span_entry = &mlxsw_sp->span.entries[i];
break;
}
}
- if (index < 0)
+ if (!span_entry)
return NULL;
/* create a new port analayzer entry for local_port */
- mlxsw_reg_mpat_pack(mpat_pl, index, local_port, true,
+ mlxsw_reg_mpat_pack(mpat_pl, span_entry->id, local_port, true,
MLXSW_REG_MPAT_SPAN_TYPE_LOCAL_ETH);
err = mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(mpat), mpat_pl);
if (err)
return NULL;
- span_entry->id = index;
span_entry->ref_count = 1;
span_entry->local_port = local_port;
return span_entry;
--
2.14.3
[patch net-next 14/15] mlxsw: spectrum_span: Support mirror to gretap
From: Petr Machata
When a user requests mirror from a mlxsw physical port (possibly based
on an ACL match) to a gretap netdevice, the driver needs to resolve the
request to a particular physical port that the mirrored packets will
egress through, and a suite of configuration keys (importantly, IP and
MAC addresses). That means calling into routing and neighbor kernel code
to simulate the decisions made by the system for packets passing through
a gretap netdevice.
Add a new instance of mlxsw_sp_span_entry_ops to support this.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Signed-off-by: Jiri Pirko
---
drivers/net/ethernet/mellanox/mlxsw/Kconfig| 2 +
.../net/ethernet/mellanox/mlxsw/spectrum_span.c| 167 -
.../net/ethernet/mellanox/mlxsw/spectrum_span.h| 8 +
3 files changed, 175 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/Kconfig
b/drivers/net/ethernet/mellanox/mlxsw/Kconfig
index d56eea310509..830c3e28505e 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlxsw/Kconfig
@@ -78,6 +78,8 @@ config MLXSW_SPECTRUM
depends on IPV6 || IPV6=n
select PARMAN
select MLXFW
+ depends on NET_IPGRE
+ depends on !(MLXSW_CORE=y && NET_IPGRE=m)
default m
---help---
This driver supports Mellanox Technologies Spectrum Ethernet
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
index 57df57c7a405..d5fda4f13c31 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
@@ -1,6 +1,7 @@
/*
* drivers/net/ethernet/mellanox/mlxsw/mlxsw_span.c
* Copyright (c) 2018 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2018 Petr Machata
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -32,9 +33,12 @@
*/
#include
+#include
+#include
#include "spectrum.h"
#include "spectrum_span.h"
+#include "spectrum_ipip.h"
int mlxsw_sp_span_init(struct mlxsw_sp *mlxsw_sp)
{
@@ -127,17 +131,176 @@ struct mlxsw_sp_span_entry_ops
mlxsw_sp_span_entry_ops_phys = {
.deconfigure = mlxsw_sp_span_entry_phys_deconfigure,
};
+static struct net_device *
+mlxsw_sp_span_gretap4_route(const struct net_device *to_dev,
+ __be32 *saddrp, __be32 *daddrp)
+{
+ struct ip_tunnel *tun = netdev_priv(to_dev);
+ struct net_device *dev = NULL;
+ struct ip_tunnel_parm parms;
+ struct rtable *rt = NULL;
+ struct flowi4 fl4;
+
+ /* We assume "dev" stays valid after rt is put. */
+ ASSERT_RTNL();
+
+ parms = mlxsw_sp_ipip_netdev_parms4(to_dev);
+ ip_tunnel_init_flow(&fl4, parms.iph.protocol, *daddrp, *saddrp,
+ 0, 0, parms.link, tun->fwmark);
+
+ rt = ip_route_output_key(tun->net, &fl4);
+ if (IS_ERR(rt))
+ return NULL;
+
+ if (rt->rt_type != RTN_UNICAST)
+ goto out;
+
+ dev = rt->dst.dev;
+ *saddrp = fl4.saddr;
+ *daddrp = rt->rt_gateway;
+
+out:
+ ip_rt_put(rt);
+ return dev;
+}
+
+static int mlxsw_sp_span_dmac(struct neigh_table *tbl,
+ const void *pkey,
+ struct net_device *l3edev,
+ unsigned char dmac[ETH_ALEN])
+{
+ struct neighbour *neigh = neigh_lookup(tbl, pkey, l3edev);
+ int err = 0;
+
+ if (!neigh) {
+ neigh = neigh_create(tbl, pkey, l3edev);
+ if (IS_ERR(neigh))
+ return PTR_ERR(neigh);
+ }
+
+ neigh_event_send(neigh, NULL);
+
+ read_lock_bh(&neigh->lock);
+ if ((neigh->nud_state & NUD_VALID) && !neigh->dead)
+ memcpy(dmac, neigh->ha, ETH_ALEN);
+ else
+ err = -ENOENT;
+ read_unlock_bh(&neigh->lock);
+
+ neigh_release(neigh);
+ return err;
+}
+
+static int
+mlxsw_sp_span_entry_unoffloadable(struct mlxsw_sp_span_parms *sparmsp)
+{
+ sparmsp->dest_port = NULL;
+ return 0;
+}
+
+static int
+mlxsw_sp_span_entry_tunnel_parms_common(struct net_device *l3edev,
+ union mlxsw_sp_l3addr saddr,
+ union mlxsw_sp_l3addr daddr,
+ union mlxsw_sp_l3addr gw,
+ __u8 ttl,
+ struct neigh_table *tbl,
+ struct mlxsw_sp_span_parms *sparmsp)
+{
+ unsigned char dmac[ETH_ALEN];
+
+ if (mlxsw_sp_l3addr_is_zero(gw))
+ gw = daddr;
+
+ if (!l3edev || !mlxsw_sp_port_dev_check(l3edev) ||
+ mlxsw_sp_span_dmac(tbl, &gw, l3edev, dmac))
+ re
[patch net-next 02/15] mlxsw: spectrum_ipip: Support decoding IPv6 tunnel addresses
From: Petr Machata
To support mirroring to ip6gretap, the SPAN module needs to be able to
decode IPv6 addresses specified at that tunnel.
Extend mlxsw_sp_ipip_netdev_saddr() and mlxsw_sp_ipip_netdev_daddr() to
support IPv6 addresses. To that end, add and publish a support function
mlxsw_sp_ipip_netdev_parms6().
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Signed-off-by: Jiri Pirko
---
.../net/ethernet/mellanox/mlxsw/spectrum_ipip.c| 29 --
.../net/ethernet/mellanox/mlxsw/spectrum_ipip.h| 2 ++
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.c
index 03788182..98d896c14b87 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.c
@@ -33,6 +33,7 @@
*/
#include
+#include
#include "spectrum_ipip.h"
@@ -44,6 +45,14 @@ mlxsw_sp_ipip_netdev_parms4(const struct net_device *ol_dev)
return tun->parms;
}
+struct __ip6_tnl_parm
+mlxsw_sp_ipip_netdev_parms6(const struct net_device *ol_dev)
+{
+ struct ip6_tnl *tun = netdev_priv(ol_dev);
+
+ return tun->parms;
+}
+
static bool mlxsw_sp_ipip_parms4_has_ikey(struct ip_tunnel_parm parms)
{
return !!(parms.i_flags & TUNNEL_KEY);
@@ -72,24 +81,38 @@ mlxsw_sp_ipip_parms4_saddr(struct ip_tunnel_parm parms)
return (union mlxsw_sp_l3addr) { .addr4 = parms.iph.saddr };
}
+static union mlxsw_sp_l3addr
+mlxsw_sp_ipip_parms6_saddr(struct __ip6_tnl_parm parms)
+{
+ return (union mlxsw_sp_l3addr) { .addr6 = parms.laddr };
+}
+
static union mlxsw_sp_l3addr
mlxsw_sp_ipip_parms4_daddr(struct ip_tunnel_parm parms)
{
return (union mlxsw_sp_l3addr) { .addr4 = parms.iph.daddr };
}
+static union mlxsw_sp_l3addr
+mlxsw_sp_ipip_parms6_daddr(struct __ip6_tnl_parm parms)
+{
+ return (union mlxsw_sp_l3addr) { .addr6 = parms.raddr };
+}
+
union mlxsw_sp_l3addr
mlxsw_sp_ipip_netdev_saddr(enum mlxsw_sp_l3proto proto,
const struct net_device *ol_dev)
{
struct ip_tunnel_parm parms4;
+ struct __ip6_tnl_parm parms6;
switch (proto) {
case MLXSW_SP_L3_PROTO_IPV4:
parms4 = mlxsw_sp_ipip_netdev_parms4(ol_dev);
return mlxsw_sp_ipip_parms4_saddr(parms4);
case MLXSW_SP_L3_PROTO_IPV6:
- break;
+ parms6 = mlxsw_sp_ipip_netdev_parms6(ol_dev);
+ return mlxsw_sp_ipip_parms6_saddr(parms6);
}
WARN_ON(1);
@@ -109,13 +132,15 @@ mlxsw_sp_ipip_netdev_daddr(enum mlxsw_sp_l3proto proto,
const struct net_device *ol_dev)
{
struct ip_tunnel_parm parms4;
+ struct __ip6_tnl_parm parms6;
switch (proto) {
case MLXSW_SP_L3_PROTO_IPV4:
parms4 = mlxsw_sp_ipip_netdev_parms4(ol_dev);
return mlxsw_sp_ipip_parms4_daddr(parms4);
case MLXSW_SP_L3_PROTO_IPV6:
- break;
+ parms6 = mlxsw_sp_ipip_netdev_parms6(ol_dev);
+ return mlxsw_sp_ipip_parms6_daddr(parms6);
}
WARN_ON(1);
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.h
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.h
index 888f19000209..6909d867bb59 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.h
@@ -41,6 +41,8 @@
struct ip_tunnel_parm
mlxsw_sp_ipip_netdev_parms4(const struct net_device *ol_dev);
+struct __ip6_tnl_parm
+mlxsw_sp_ipip_netdev_parms6(const struct net_device *ol_dev);
union mlxsw_sp_l3addr
mlxsw_sp_ipip_netdev_saddr(enum mlxsw_sp_l3proto proto,
--
2.14.3
[patch net-next 12/15] mlxsw: Handle config changes pertinent to SPAN
From: Petr Machata
For some netdevices, for which mlxsw offloads mirroring, may have a
complex relationship between the declared intent and low-level
device configuration.
Trying to accurately track which changes might influence offloading
decisions is finicky and error-prone. Instead, this patch introduces a
function mlxsw_sp_span_entry_respin, which re-queries the configuration
anew and, if different, removes the existing offloads and installs new
ones.
Call this function strategically at event handlers that might influence
the mirroring configuration.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Signed-off-by: Jiri Pirko
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 29 +-
.../net/ethernet/mellanox/mlxsw/spectrum_router.c | 7 ++
.../net/ethernet/mellanox/mlxsw/spectrum_span.c| 24 ++
.../net/ethernet/mellanox/mlxsw/spectrum_span.h| 1 +
4 files changed, 49 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index b070cad8dba7..8d2d140d7910 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -1,6 +1,6 @@
/*
* drivers/net/ethernet/mellanox/mlxsw/spectrum.c
- * Copyright (c) 2015-2017 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2015-2018 Mellanox Technologies. All rights reserved.
* Copyright (c) 2015-2017 Jiri Pirko
* Copyright (c) 2015 Ido Schimmel
* Copyright (c) 2015 Elad Raz
@@ -3667,14 +3667,24 @@ static int mlxsw_sp_init(struct mlxsw_core *mlxsw_core,
goto err_afa_init;
}
+ err = mlxsw_sp_span_init(mlxsw_sp);
+ if (err) {
+ dev_err(mlxsw_sp->bus_info->dev, "Failed to init span
system\n");
+ goto err_span_init;
+ }
+
+ /* Initialize router after SPAN is initialized, so that the FIB and
+* neighbor event handlers can issue SPAN respin.
+*/
err = mlxsw_sp_router_init(mlxsw_sp);
if (err) {
dev_err(mlxsw_sp->bus_info->dev, "Failed to initialize
router\n");
goto err_router_init;
}
- /* Initialize netdevice notifier after router is initialized, so that
-* the event handler can use router structures.
+ /* Initialize netdevice notifier after router and SPAN is initialized,
+* so that the event handler can use router structures and call SPAN
+* respin.
*/
mlxsw_sp->netdevice_nb.notifier_call = mlxsw_sp_netdevice_event;
err = register_netdevice_notifier(&mlxsw_sp->netdevice_nb);
@@ -3683,12 +3693,6 @@ static int mlxsw_sp_init(struct mlxsw_core *mlxsw_core,
goto err_netdev_notifier;
}
- err = mlxsw_sp_span_init(mlxsw_sp);
- if (err) {
- dev_err(mlxsw_sp->bus_info->dev, "Failed to init span
system\n");
- goto err_span_init;
- }
-
err = mlxsw_sp_acl_init(mlxsw_sp);
if (err) {
dev_err(mlxsw_sp->bus_info->dev, "Failed to initialize ACL\n");
@@ -3714,12 +3718,12 @@ static int mlxsw_sp_init(struct mlxsw_core *mlxsw_core,
err_dpipe_init:
mlxsw_sp_acl_fini(mlxsw_sp);
err_acl_init:
- mlxsw_sp_span_fini(mlxsw_sp);
-err_span_init:
unregister_netdevice_notifier(&mlxsw_sp->netdevice_nb);
err_netdev_notifier:
mlxsw_sp_router_fini(mlxsw_sp);
err_router_init:
+ mlxsw_sp_span_fini(mlxsw_sp);
+err_span_init:
mlxsw_sp_afa_fini(mlxsw_sp);
err_afa_init:
mlxsw_sp_counter_pool_fini(mlxsw_sp);
@@ -3745,9 +3749,9 @@ static void mlxsw_sp_fini(struct mlxsw_core *mlxsw_core)
mlxsw_sp_ports_remove(mlxsw_sp);
mlxsw_sp_dpipe_fini(mlxsw_sp);
mlxsw_sp_acl_fini(mlxsw_sp);
- mlxsw_sp_span_fini(mlxsw_sp);
unregister_netdevice_notifier(&mlxsw_sp->netdevice_nb);
mlxsw_sp_router_fini(mlxsw_sp);
+ mlxsw_sp_span_fini(mlxsw_sp);
mlxsw_sp_afa_fini(mlxsw_sp);
mlxsw_sp_counter_pool_fini(mlxsw_sp);
mlxsw_sp_switchdev_fini(mlxsw_sp);
@@ -4641,6 +4645,7 @@ static int mlxsw_sp_netdevice_event(struct notifier_block
*nb,
if (span_entry)
mlxsw_sp_span_entry_invalidate(mlxsw_sp, span_entry);
}
+ mlxsw_sp_span_respin(mlxsw_sp);
if (mlxsw_sp_netdev_is_ipip_ol(mlxsw_sp, dev))
err = mlxsw_sp_netdevice_ipip_ol_event(mlxsw_sp, dev,
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 05146970c19c..69f16c605b9d 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -70,6 +70,7 @@
#include "spectrum_mr.h"
#include "spectrum_mr_tcam.h"
#include "spectrum_router.h"
+#include "spectrum_span.h"
struct mlxsw_sp_fib;
struct mlxsw_sp_vr;
[patch net-next 07/15] mlxsw: span: Remove span_entry by span_id
From: Petr Machata
Instead of removing span_entry by the port number, allow removing by
SPAN id. That simplifies some code right here, and for mirroring to soft
netdevices, avoids problems with netdevice pointer invalidation and
reuse.
Rename mlxsw_sp_span_entry_find() to mlxsw_sp_span_entry_find_by_port()
and keep it--follow-up patches will make use of it.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Signed-off-by: Jiri Pirko
---
.../mellanox/mlxsw/core_acl_flex_actions.c | 6 ++---
.../mellanox/mlxsw/core_acl_flex_actions.h | 2 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 5 ++--
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 2 +-
.../mellanox/mlxsw/spectrum_acl_flex_actions.c | 27
.../net/ethernet/mellanox/mlxsw/spectrum_span.c| 29 --
.../net/ethernet/mellanox/mlxsw/spectrum_span.h| 7 +++---
7 files changed, 37 insertions(+), 41 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.c
b/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.c
index b698fb481b2e..d1c2d85f396d 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.c
@@ -1,6 +1,6 @@
/*
* drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.c
- * Copyright (c) 2017 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2017, 2018 Mellanox Technologies. All rights reserved.
* Copyright (c) 2017 Jiri Pirko
*
* Redistribution and use in source and binary forms, with or without
@@ -838,7 +838,6 @@ struct mlxsw_afa_mirror {
struct mlxsw_afa_resource resource;
int span_id;
u8 local_in_port;
- u8 local_out_port;
bool ingress;
};
@@ -848,7 +847,7 @@ mlxsw_afa_mirror_destroy(struct mlxsw_afa_block *block,
{
block->afa->ops->mirror_del(block->afa->ops_priv,
mirror->local_in_port,
- mirror->local_out_port,
+ mirror->span_id,
mirror->ingress);
kfree(mirror);
}
@@ -882,7 +881,6 @@ mlxsw_afa_mirror_create(struct mlxsw_afa_block *block,
goto err_mirror_add;
mirror->ingress = ingress;
- mirror->local_out_port = local_out_port;
mirror->local_in_port = local_in_port;
mirror->resource.destructor = mlxsw_afa_mirror_destructor;
mlxsw_afa_resource_add(block, &mirror->resource);
diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.h
b/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.h
index 43132293475c..4e991ca6dce5 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.h
@@ -50,7 +50,7 @@ struct mlxsw_afa_ops {
void (*counter_index_put)(void *priv, unsigned int counter_index);
int (*mirror_add)(void *priv, u8 locol_in_port, u8 local_out_port,
bool ingress, int *p_span_id);
- void (*mirror_del)(void *priv, u8 locol_in_port, u8 local_out_port,
+ void (*mirror_del)(void *priv, u8 local_in_port, int span_id,
bool ingress);
};
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index bfde93910f82..10bb4891ec31 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -1273,11 +1273,10 @@ mlxsw_sp_port_add_cls_matchall_mirror(struct
mlxsw_sp_port *mlxsw_sp_port,
}
to_port = netdev_priv(to_dev);
- mirror->to_local_port = to_port->local_port;
mirror->ingress = ingress;
span_type = ingress ? MLXSW_SP_SPAN_INGRESS : MLXSW_SP_SPAN_EGRESS;
return mlxsw_sp_span_mirror_add(mlxsw_sp_port, to_port, span_type,
- true);
+ true, &mirror->span_id);
}
static void
@@ -1288,7 +1287,7 @@ mlxsw_sp_port_del_cls_matchall_mirror(struct
mlxsw_sp_port *mlxsw_sp_port,
span_type = mirror->ingress ?
MLXSW_SP_SPAN_INGRESS : MLXSW_SP_SPAN_EGRESS;
- mlxsw_sp_span_mirror_del(mlxsw_sp_port, mirror->to_local_port,
+ mlxsw_sp_span_mirror_del(mlxsw_sp_port, mirror->span_id,
span_type, true);
}
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
index 675e03a892ed..2673310f92da 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
@@ -124,7 +124,7 @@ enum mlxsw_sp_port_mall_action_type {
};
struct mlxsw_sp_port_mall_mirror_tc_entry {
- u8 to_local_port;
+ int span_id;
bool ingress;
};
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_flex_ac
[patch net-next 10/15] mlxsw: spectrum: Keep mirror netdev in mlxsw_sp_span_entry
From: Petr Machata
Currently the only mirror action supported by mlxsw is mirror to another
mlxsw physical port. Correspondingly, span_entry, which tracks each
mlxsw mirror in the system, currently holds a u8 number of the
destination port.
To extend this system to mirror to gretap and ip6gretap netdevices, have
struct mlxsw_sp_span_entry actually hold the destination netdevice
itself.
This change then trickles down in obvious manner to SPAN module API and
mirror-related interfaces in struct mlxsw_afa_ops.
To prevent use of invalid pointer, NETDEV_UNREGISTER needs to be hooked
and the corresponding SPAN entry invalidated.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Signed-off-by: Jiri Pirko
---
.../mellanox/mlxsw/core_acl_flex_actions.c | 13
.../mellanox/mlxsw/core_acl_flex_actions.h | 7 ++--
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 11 --
drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c | 2 +-
.../mellanox/mlxsw/spectrum_acl_flex_actions.c | 8 ++---
.../net/ethernet/mellanox/mlxsw/spectrum_span.c| 39 ++
.../net/ethernet/mellanox/mlxsw/spectrum_span.h| 10 --
7 files changed, 56 insertions(+), 34 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.c
b/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.c
index d1c2d85f396d..ba338428ffd1 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.c
@@ -863,9 +863,8 @@ mlxsw_afa_mirror_destructor(struct mlxsw_afa_block *block,
}
static struct mlxsw_afa_mirror *
-mlxsw_afa_mirror_create(struct mlxsw_afa_block *block,
- u8 local_in_port, u8 local_out_port,
- bool ingress)
+mlxsw_afa_mirror_create(struct mlxsw_afa_block *block, u8 local_in_port,
+ const struct net_device *out_dev, bool ingress)
{
struct mlxsw_afa_mirror *mirror;
int err;
@@ -875,7 +874,7 @@ mlxsw_afa_mirror_create(struct mlxsw_afa_block *block,
return ERR_PTR(-ENOMEM);
err = block->afa->ops->mirror_add(block->afa->ops_priv,
- local_in_port, local_out_port,
+ local_in_port, out_dev,
ingress, &mirror->span_id);
if (err)
goto err_mirror_add;
@@ -907,13 +906,13 @@ mlxsw_afa_block_append_allocated_mirror(struct
mlxsw_afa_block *block,
}
int
-mlxsw_afa_block_append_mirror(struct mlxsw_afa_block *block,
- u8 local_in_port, u8 local_out_port, bool ingress)
+mlxsw_afa_block_append_mirror(struct mlxsw_afa_block *block, u8 local_in_port,
+ const struct net_device *out_dev, bool ingress)
{
struct mlxsw_afa_mirror *mirror;
int err;
- mirror = mlxsw_afa_mirror_create(block, local_in_port, local_out_port,
+ mirror = mlxsw_afa_mirror_create(block, local_in_port, out_dev,
ingress);
if (IS_ERR(mirror))
return PTR_ERR(mirror);
diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.h
b/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.h
index 4e991ca6dce5..6dd601703c99 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.h
@@ -36,6 +36,7 @@
#define _MLXSW_CORE_ACL_FLEX_ACTIONS_H
#include
+#include
struct mlxsw_afa;
struct mlxsw_afa_block;
@@ -48,7 +49,8 @@ struct mlxsw_afa_ops {
void (*kvdl_fwd_entry_del)(void *priv, u32 kvdl_index);
int (*counter_index_get)(void *priv, unsigned int *p_counter_index);
void (*counter_index_put)(void *priv, unsigned int counter_index);
- int (*mirror_add)(void *priv, u8 locol_in_port, u8 local_out_port,
+ int (*mirror_add)(void *priv, u8 local_in_port,
+ const struct net_device *out_dev,
bool ingress, int *p_span_id);
void (*mirror_del)(void *priv, u8 local_in_port, int span_id,
bool ingress);
@@ -70,7 +72,8 @@ int mlxsw_afa_block_append_trap(struct mlxsw_afa_block
*block, u16 trap_id);
int mlxsw_afa_block_append_trap_and_forward(struct mlxsw_afa_block *block,
u16 trap_id);
int mlxsw_afa_block_append_mirror(struct mlxsw_afa_block *block,
- u8 local_in_port, u8 local_out_port,
+ u8 local_in_port,
+ const struct net_device *out_dev,
bool ingress);
int mlxsw_afa_block_append_fwd(struct mlxsw_afa_block *block,
u8 local_port, bool in_port);
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
b/drivers/net/ether
[patch net-next 05/15] mlxsw: reg: Add SPAN encapsulation to MPAT register
From: Petr Machata
MPAT Register is used to query and configure the Switch Port Analyzer
Table. To configure Port Analyzer to encapsulate mirrored packets,
additional fields need to be specified for the MPAT register.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Signed-off-by: Jiri Pirko
---
drivers/net/ethernet/mellanox/mlxsw/reg.h | 141 +-
1 file changed, 139 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/reg.h
b/drivers/net/ethernet/mellanox/mlxsw/reg.h
index 0e08be41c8e0..2aaccbac3ed1 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/reg.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/reg.h
@@ -1,11 +1,11 @@
/*
* drivers/net/ethernet/mellanox/mlxsw/reg.h
- * Copyright (c) 2015-2017 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2015-2018 Mellanox Technologies. All rights reserved.
* Copyright (c) 2015-2016 Ido Schimmel
* Copyright (c) 2015 Elad Raz
* Copyright (c) 2015-2017 Jiri Pirko
* Copyright (c) 2016 Yotam Gigi
- * Copyright (c) 2017 Petr Machata
+ * Copyright (c) 2017-2018 Petr Machata
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -6772,6 +6772,101 @@ MLXSW_ITEM32(reg, mpat, qos, 0x04, 26, 1);
*/
MLXSW_ITEM32(reg, mpat, be, 0x04, 25, 1);
+enum mlxsw_reg_mpat_span_type {
+ /* Local SPAN Ethernet.
+* The original packet is not encapsulated.
+*/
+ MLXSW_REG_MPAT_SPAN_TYPE_LOCAL_ETH = 0x0,
+
+ /* Encapsulated Remote SPAN Ethernet L3 GRE.
+* The packet is encapsulated with GRE header.
+*/
+ MLXSW_REG_MPAT_SPAN_TYPE_REMOTE_ETH_L3 = 0x3,
+};
+
+/* reg_mpat_span_type
+ * SPAN type.
+ * Access: RW
+ */
+MLXSW_ITEM32(reg, mpat, span_type, 0x04, 0, 4);
+
+/* Remote SPAN - Ethernet VLAN
+ * - - - - - - - - - - - - - -
+ */
+
+/* reg_mpat_eth_rspan_vid
+ * Encapsulation header VLAN ID.
+ * Access: RW
+ */
+MLXSW_ITEM32(reg, mpat, eth_rspan_vid, 0x18, 0, 12);
+
+/* Encapsulated Remote SPAN - Ethernet L2
+ * - - - - - - - - - - - - - - - - - - -
+ */
+
+enum mlxsw_reg_mpat_eth_rspan_version {
+ MLXSW_REG_MPAT_ETH_RSPAN_VERSION_NO_HEADER = 15,
+};
+
+/* reg_mpat_eth_rspan_version
+ * RSPAN mirror header version.
+ * Access: RW
+ */
+MLXSW_ITEM32(reg, mpat, eth_rspan_version, 0x10, 18, 4);
+
+/* reg_mpat_eth_rspan_mac
+ * Destination MAC address.
+ * Access: RW
+ */
+MLXSW_ITEM_BUF(reg, mpat, eth_rspan_mac, 0x12, 6);
+
+/* reg_mpat_eth_rspan_tp
+ * Tag Packet. Indicates whether the mirroring header should be VLAN tagged.
+ * Access: RW
+ */
+MLXSW_ITEM32(reg, mpat, eth_rspan_tp, 0x18, 16, 1);
+
+/* Encapsulated Remote SPAN - Ethernet L3
+ * - - - - - - - - - - - - - - - - - - -
+ */
+
+enum mlxsw_reg_mpat_eth_rspan_protocol {
+ MLXSW_REG_MPAT_ETH_RSPAN_PROTOCOL_IPV4,
+ MLXSW_REG_MPAT_ETH_RSPAN_PROTOCOL_IPV6,
+};
+
+/* reg_mpat_eth_rspan_protocol
+ * SPAN encapsulation protocol.
+ * Access: RW
+ */
+MLXSW_ITEM32(reg, mpat, eth_rspan_protocol, 0x18, 24, 4);
+
+/* reg_mpat_eth_rspan_ttl
+ * Encapsulation header Time-to-Live/HopLimit.
+ * Access: RW
+ */
+MLXSW_ITEM32(reg, mpat, eth_rspan_ttl, 0x1C, 4, 8);
+
+/* reg_mpat_eth_rspan_smac
+ * Source MAC address
+ * Access: RW
+ */
+MLXSW_ITEM_BUF(reg, mpat, eth_rspan_smac, 0x22, 6);
+
+/* reg_mpat_eth_rspan_dip*
+ * Destination IP address. The IP version is configured by protocol.
+ * Access: RW
+ */
+MLXSW_ITEM32(reg, mpat, eth_rspan_dip4, 0x4C, 0, 32);
+MLXSW_ITEM_BUF(reg, mpat, eth_rspan_dip6, 0x40, 16);
+
+/* reg_mpat_eth_rspan_sip*
+ * Source IP address. The IP version is configured by protocol.
+ * Access: RW
+ */
+MLXSW_ITEM32(reg, mpat, eth_rspan_sip4, 0x5C, 0, 32);
+MLXSW_ITEM_BUF(reg, mpat, eth_rspan_sip6, 0x50, 16);
+
static inline void mlxsw_reg_mpat_pack(char *payload, u8 pa_id,
u16 system_port, bool e)
{
@@ -6783,6 +6878,48 @@ static inline void mlxsw_reg_mpat_pack(char *payload, u8
pa_id,
mlxsw_reg_mpat_be_set(payload, 1);
}
+static inline void mlxsw_reg_mpat_eth_rspan_pack(char *payload, u16 vid)
+{
+ mlxsw_reg_mpat_eth_rspan_vid_set(payload, vid);
+}
+
+static inline void
+mlxsw_reg_mpat_eth_rspan_l2_pack(char *payload,
+enum mlxsw_reg_mpat_eth_rspan_version version,
+const char *mac,
+bool tp)
+{
+ mlxsw_reg_mpat_eth_rspan_version_set(payload, version);
+ mlxsw_reg_mpat_eth_rspan_mac_memcpy_to(payload, mac);
+ mlxsw_reg_mpat_eth_rspan_tp_set(payload, tp);
+}
+
+static inline void
+mlxsw_reg_mpat_eth_rspan_l3_ipv4_pack(char *payload, u8 ttl,
+ const char *smac,
+ u32 sip, u32 dip)
+{
+ mlxsw_reg_mpat_eth_rspan_ttl_set(payload, ttl);
+ mlxsw_reg_mpat_eth_rspan_smac_memcpy_to(payload, smac);
+ mlxsw_reg_mp
[patch net-next 00/15] mlxsw: Offloading encapsulated SPAN
From: Jiri Pirko
Petr says:
This patch series introduces support for mirroring with GRE
encapsulation. It offloads tc action mirred mirror from a mlxsw port to
either a gretap or an ip6gretap netdevice.
Spectrum hardware needs to know all the details of the requested
encapsulation: source and destination MAC and IP addresses, details of
VLAN tagging, etc. The only variables are the encapsulated packet
itself, and TOS field, which may be inherited. To that end, mlxsw driver
resolves the route that encapsulated packets would take, queries the
corresponding neighbor, and with that configuration in hand, configures
the mirroring in the hardware.
The driver also hooks into event handlers for netdevice changes, FIB and
neighbor events, and reconsiders the configuration on each such change.
When the new configuration differs from the currently-offloaded one, the
existing offload is removed and replaced with a new one.
It is possible to mirror to {ip6,}gretap from a matchall rule as well as
from a flower match.
** Note that with this patch set, mlxsw build depends on NET_IPGRE and
IPV6_GRE.
Current limitations:
- There has to be a route that directs packets to an mlxsw port. We
intend to extend the logic to support other netdevice types in the
future, but the eventual egress netdevice will have to be an mlxsw
port in any case.
- Offload reconfiguration due to changes in netdevice configuration
creates a window of time where packets are not mirrored. Under some
circumstances this can be prevented by configuring an unused port
analyzer and migrating mirrors over to that. However that's currently
not implemented.
- Remote address of a tunnel device needs to be set, there may not be a
GRE key, checksumming or sequence numbers, and TTL needs to be fixed
(non-inherit). These are hard requirements imposed by the underlying
hardware.
- TOS of a tunnel device needs to be "inherit". The hardware supports a
fixed TOS, but that's currently not implemented.
The series start with two patches, #1 and #2, that publish one function
and add support for querying IPv6 tunnel parameters.
In patches #3 and #4, we introduce helpers to GRE and tunneling code
that we will use later in the patchset from the SPAN code.
Patches #5 and #6 introduce support for encapsulated SPAN in reg.h.
The following seven patches, #7-#13, then prepare the SPAN codebase for
introduction of mirroring to netdevices that don't correspond to front
panel ports.
Then #14 and #15 pull all this together to implement mirroring to
{ip6,}gretap netdevices.
Petr Machata (15):
mlxsw: spectrum_ipip: Extract mlxsw_sp_l3addr_is_zero
mlxsw: spectrum_ipip: Support decoding IPv6 tunnel addresses
net: GRE: Add is_gretap_dev, is_ip6gretap_dev
ip_tunnel: Rename & publish init_tunnel_flow
mlxsw: reg: Add SPAN encapsulation to MPAT register
mlxsw: reg: Extend mlxsw_reg_mpat_pack()
mlxsw: span: Remove span_entry by span_id
mlxsw: spectrum_span: Initialize span_entry.id eagerly
mlxsw: spectrum_span: Extract mlxsw_sp_span_entry_{de,}configure()
mlxsw: spectrum: Keep mirror netdev in mlxsw_sp_span_entry
mlxsw: spectrum_span: Generalize SPAN support
mlxsw: Handle config changes pertinent to SPAN
mlxsw: Move a mirroring check to mlxsw_sp_span_entry_create
mlxsw: spectrum_span: Support mirror to gretap
mlxsw: spectrum_span: Support mirror to ip6gretap
drivers/net/ethernet/mellanox/mlxsw/Kconfig| 4 +
.../mellanox/mlxsw/core_acl_flex_actions.c | 19 +-
.../mellanox/mlxsw/core_acl_flex_actions.h | 9 +-
drivers/net/ethernet/mellanox/mlxsw/reg.h | 145 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 50 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 2 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c | 9 +-
.../mellanox/mlxsw/spectrum_acl_flex_actions.c | 33 +-
.../net/ethernet/mellanox/mlxsw/spectrum_ipip.c| 45 +-
.../net/ethernet/mellanox/mlxsw/spectrum_ipip.h| 8 +-
.../net/ethernet/mellanox/mlxsw/spectrum_router.c | 7 +
.../net/ethernet/mellanox/mlxsw/spectrum_span.c| 522 +++--
.../net/ethernet/mellanox/mlxsw/spectrum_span.h| 41 +-
include/net/gre.h | 3 +
include/net/ip_tunnels.h | 16 +
net/ipv4/ip_gre.c | 6 +
net/ipv4/ip_tunnel.c | 40 +-
net/ipv6/ip6_gre.c | 6 +
18 files changed, 808 insertions(+), 157 deletions(-)
--
2.14.3
Re: [PATCH net-next 0/5] Modernize bitbanged GPIO MDIO
On 02/25/2018 04:51 AM, Linus Walleij wrote: > This kills off the platform data support from the bitbanged > GPIO-based MDIO driver and moves it over to using GPIO > descriptors exclusively. > > We are certainly not going to merge any more platforms into > the kernel using platform data, and nothing is using it at the > moment. The only concern would be out-of-tree platforms, and > those are not the concern of the kernel community. They need > to move to use device tree (or ACPI etc) like everyone else. Please refrain from making statements like those because there are perfectly valid use cases for never seeing ACPI or Device Tree for a given platform, yes there will be push back, and yes, if DT or ACPI is possible, it should be used but I can guarantee you there are platforms out there that won't be converted to DT (e.g: tons of MIPS-based router, x86 add-on modules etc.). Nack on patches 1 and 3, because I am slowly resuming work on an x86 platform driver that uses the mdio-gpio driver with platform data, and DT is not an option there, and I would rather not have to revert your changes. > > This was tested on the bit-banged GPIO MDIO on the D-Link > DNS-313 and works fine for me. > > Linus Walleij (5): > net: mdio-gpio: Localize platform data > net: mdio-gpio: Allocate state in probe() > net: mdio-gpio: Remove non-DT probe path > net: mdio-gpio: Merge platform data into state > net: mdio-gpio: Move to gpiod API > > MAINTAINERS | 1 - > drivers/net/phy/Kconfig | 2 +- > drivers/net/phy/mdio-gpio.c | 151 > ++-- > include/linux/platform_data/mdio-gpio.h | 33 --- > 4 files changed, 47 insertions(+), 140 deletions(-) > delete mode 100644 include/linux/platform_data/mdio-gpio.h > -- Florian
Re: inconsistent lock state with usbnet/asix usb ethernet and xhci
On Tue, 2018-02-27 at 08:26 +0100, Marek Szyprowski wrote:
> Hi
>
> I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel
> warning ("inconsistent lock state") on Chromebook2 Peach-PIT board. No
> special activity is needed to reproduce this issue, it happens almost
> on every boot. ASIX USB ethernet is connected to XHCI USB host controller
> on that board. Is it a known issue? Frankly I have no idea where to look
> to fix it. The same adapter connected to EHCI ports on other boards based
> on the same SoC works fine without any warnings.
>
> Here are some more information from that board:
> # lsusb
> Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 005 Device 002: ID 0b95:772b ASIX Electronics Corp. AX88772B
> Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 001 Device 002: ID 2232:1056 Silicon Motion
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> # lsusb -t
> /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
> /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
> |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=asix, 480M
> /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
> /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
> |__ Port 1: Dev 2, If 0, Class=Video, Driver=, 480M
> |__ Port 1: Dev 2, If 1, Class=Video, Driver=, 480M
>
>
> And the log with mentioned warning:
>
> [ 17.768040] ====
> [ 17.772239] WARNING: inconsistent lock state
> [ 17.776511] 4.16.0-rc3-next-20180227-7-g876c53a7493c #453 Not tainted
> [ 17.783329]
> [ 17.787580] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> [ 17.793607] swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
> [ 17.798751] (&syncp->seq#5){?.-.}, at: [<9b22e5f0>]
> asix_rx_fixup_internal+0x188/0x288
> [ 17.806790] {IN-HARDIRQ-W} state was registered at:
> [ 17.811677] tx_complete+0x100/0x208
> [ 17.815319] __usb_hcd_giveback_urb+0x60/0xf0
> [ 17.819770] xhci_giveback_urb_in_irq+0xa8/0x240
> [ 17.824469] xhci_td_cleanup+0xf4/0x16c
> [ 17.828367] xhci_irq+0xe74/0x2240
> [ 17.831827] usb_hcd_irq+0x24/0x38
> [ 17.835343] __handle_irq_event_percpu+0x98/0x510
> [ 17.840111] handle_irq_event_percpu+0x1c/0x58
> [ 17.844623] handle_irq_event+0x38/0x5c
> [ 17.848519] handle_fasteoi_irq+0xa4/0x138
> [ 17.852681] generic_handle_irq+0x18/0x28
> [ 17.856760] __handle_domain_irq+0x6c/0xe4
> [ 17.860941] gic_handle_irq+0x54/0xa0
> [ 17.864666] __irq_svc+0x70/0xb0
> [ 17.867964] arch_cpu_idle+0x20/0x3c
> [ 17.871578] arch_cpu_idle+0x20/0x3c
> [ 17.875190] do_idle+0x144/0x218
> [ 17.878468] cpu_startup_entry+0x18/0x1c
> [ 17.882454] start_kernel+0x394/0x400
> [ 17.886177] irq event stamp: 161912
> [ 17.889616] hardirqs last enabled at (161912): [<7bedfacf>]
> __netdev_alloc_skb+0xcc/0x140
> [ 17.897893] hardirqs last disabled at (161911): []
> __netdev_alloc_skb+0x94/0x140
> [ 17.904903] exynos5-hsi2c 12ca.i2c: tx timeout
> [ 17.906116] softirqs last enabled at (161904): [<387102ff>]
> irq_enter+0x78/0x80
> [ 17.906123] softirqs last disabled at (161905): []
> irq_exit+0x134/0x158
> [ 17.925722].
> [ 17.925722] other info that might help us debug this:
> [ 17.933435] Possible unsafe locking scenario:
> [ 17.933435].
> [ 17.940331] CPU0
> [ 17.942488]
> [ 17.944894] lock(&syncp->seq#5);
> [ 17.948274]
> [ 17.950847] lock(&syncp->seq#5);
> [ 17.954386].
> [ 17.954386] *** DEADLOCK ***
> [ 17.954386].
> [ 17.962422] no locks held by swapper/0/0.
> [ 17.966011].
> [ 17.966011] stack backtrace:
> [ 17.971333] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 4.16.0-rc3-next-20180227-7-g876c53a7493c #453
> [ 17.980312] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [ 17.986380] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [ 17.994128] [] (show_stack) from []
> (dump_stack+0x90/0xc8)
> [ 18.001339] [] (dump_stack) from []
> (print_usage_bug+0x25c/0x2cc)
> [ 18.009161] [] (print_usage_bug) from []
> (mark_lock+0x290/0x698)
> [ 18.014952] exynos5-h
Re: [PATCH 0/2] mv88e6xxx: Poll when no interrupt defined
On Tue, Feb 27, 2018 at 11:24:02AM +0100, Gregory CLEMENT wrote: > Hi Andrew, > > On jeu., févr. 22 2018, Andrew Lunn wrote: > > > Not all boards using the mv88e6xxx switches have the interrupt output > > connected to a GPIO. On these boards phylib has to poll the PHYs, > > rather than use interrupts. Have the driver poll the interrupt status > > register, which is more efficient than having phylib do it. And it > > enables other switch interrupts to be services. > > > > The Armada 370RD is such a board without a interrupt GPIO. Now that > > interrupts work, wire up the PHYs to make use if them. > > > > Gregory: Are you O.K. for the second patch to go through netdev? > > Why do you need that the second patch to go through netdev. Is there any > dependency between the 2 patches? > > If it is the case does it means that an new kernel won't work with an > old device tree? Hi Gregory There is a runtime dependency between the two. A new device tree blob will not run on an old kernel. So if you take the second patch alone via mvebu, the PHYs will stop working, no link up reported. But an old blob will run on a new kernel. Backwards compatibility is maintained. Andrew
Re: phy: micrel.c: Support ksz9031 energy-detect power-down mode
CC netdev 2018-02-27 13:12 GMT+03:00 Maxim Uvarov : > It migth be reason to reconsider of unconditionally enable power-down mode. > v1 of patch and code here: > https://lkml.org/lkml/2016/10/3/199 > > I see that 9031 just lock ups with start from -40C just after > swtiching to power save mode. And any soft reset do not work. Chip is > not visible on mdio bus completely and only physycal power cycle > restores operation. Temperature is acceptable for specifcication. > > I think it's better to not touch defaults in mainline linux-kernel. Or > at least make all new features optional. > > -- > Best regards, > Maxim Uvarov
Re: [PATCH net-next] ipv6: allow userspace to add IFA_F_OPTIMISTIC addresses
2018-02-26, 12:11:27 -0500, David Miller wrote: > From: Sabrina Dubroca > Date: Mon, 26 Feb 2018 17:56:19 +0100 > > > 2018-02-26, 10:57:11 -0500, David Miller wrote: > >> Userland is now repsonsible for implementing correct behavior when it > >> takes over this task, and therefore the kernel has no say in the > >> matter of proper ipv6 neighbor discovery and addrconf behavior. > > > > As an aside, that's also the case whenever userland uses packet > > sockets. > > When you use packet sockets, all bets are off and it is clearly the > case that the user gets to keep the broken pieces when things go > wrong. Ok, I see your point. > That's completely different to this case, which is a bonfide explicit > allowance for userspace to take over these fundamental protocol tasks > from the kernel. This is not letting userspace take over. On the contrary, it allows userspace to take advantage of the kernel's DAD, without suffering the delay. The alternative, without optimistic DAD, would be to completely disable DAD done by the kernel. This follows RFC 4429, which explicitly allows optimistic DAD for addresses generated by (among other mechanisms) DHCPv6. -- Sabrina
[PATCH net-next 0/4] mlx4_en misc for 4.17
Hi Dave, This patchset contains misc enhancements from the team to the mlx4 Eth driver. Patch 1 by Eran adds physical layer counters. Patch 2 by Eran cleans-up a redundant warn print. Patch 3 combines the checks of two end cases into a single if statement. Patch 4 takes common code structures out of the #ifdef, following your comment on a previous patch. Series generated against net-next commit: f74290fdb363 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net Thanks, Tariq. Eran Ben Elisha (2): net/mlx4_en: Add physical RX/TX bytes/packets counters net/mlx4_en: Remove unnecessary warn print in reset config Tariq Toukan (2): net/mlx4_en: Combine checks of end-cases in RX completion function net/mlx4_en: RX csum, pre-define enabled protocols for IP status masking drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 14 + drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 8 +++--- drivers/net/ethernet/mellanox/mlx4/en_port.c| 38 - drivers/net/ethernet/mellanox/mlx4/en_rx.c | 18 ++-- drivers/net/ethernet/mellanox/mlx4/mlx4_en.h| 1 + drivers/net/ethernet/mellanox/mlx4/mlx4_stats.h | 10 ++- 6 files changed, 61 insertions(+), 28 deletions(-) -- 1.8.3.1
[PATCH net-next 2/4] net/mlx4_en: Remove unnecessary warn print in reset config
From: Eran Ben Elisha
In mlx4_en_reset_config, there was a redundant warn print that was left
from previous versions of this function. No warn is needed anymore.
This warn can be confusing when RX-FCS is changed:
Turn OFF RX-FCS:
mlx4_en: eth1: Changing device configuration rx filter(0) rx vlan(1)
Turn ON RX-FCS:
mlx4_en: eth1: Changing device configuration rx filter(0) rx vlan(1)
Signed-off-by: Eran Ben Elisha
Signed-off-by: Tariq Toukan
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index b62d2c3f976a..e0adac4a9a19 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -3634,10 +3634,6 @@ int mlx4_en_reset_config(struct net_device *dev,
mlx4_en_stop_port(dev, 1);
}
- en_warn(priv, "Changing device configuration rx filter(%x) rx
vlan(%x)\n",
- ts_config.rx_filter,
- !!(features & NETIF_F_HW_VLAN_CTAG_RX));
-
mlx4_en_safe_replace_resources(priv, tmp);
if (DEV_FEATURE_CHANGED(dev, features, NETIF_F_HW_VLAN_CTAG_RX)) {
--
1.8.3.1
[PATCH net-next 4/4] net/mlx4_en: RX csum, pre-define enabled protocols for IP status masking
Pre-define a mask for IP status of a completion, that tests the
MLX4_CQE_STATUS_IPV6 only in case CONFIG_IPV6 is enabled.
Use it for IP status testing upon completion, instead of separating
the datapath into two flows.
This takes common code structures (such as closing parenthesis)
back to their original place, and makes code more readable.
Signed-off-by: Tariq Toukan
Suggested-by: David S. Miller
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 1e8f21b7fed8..c2c6bd7578fd 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -649,6 +649,12 @@ static int check_csum(struct mlx4_cqe *cqe, struct sk_buff
*skb, void *va,
return get_fixed_ipv4_csum(hw_checksum, skb, hdr);
}
+#if IS_ENABLED(CONFIG_IPV6)
+#define MLX4_CQE_STATUS_IP_ANY (MLX4_CQE_STATUS_IPV4 | MLX4_CQE_STATUS_IPV6)
+#else
+#define MLX4_CQE_STATUS_IP_ANY (MLX4_CQE_STATUS_IPV4)
+#endif
+
int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int
budget)
{
struct mlx4_en_priv *priv = netdev_priv(dev);
@@ -835,12 +841,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct
mlx4_en_cq *cq, int bud
ring->csum_ok++;
} else {
if (!(priv->flags &
MLX4_EN_FLAG_RX_CSUM_NON_TCP_UDP &&
- (cqe->status &
cpu_to_be16(MLX4_CQE_STATUS_IPV4 |
-#if IS_ENABLED(CONFIG_IPV6)
-
MLX4_CQE_STATUS_IPV6
-#else
-0
-#endif
+ (cqe->status &
cpu_to_be16(MLX4_CQE_STATUS_IP_ANY
goto csum_none;
if (check_csum(cqe, skb, va, dev->features))
goto csum_none;
--
1.8.3.1
[PATCH net-next 3/4] net/mlx4_en: Combine checks of end-cases in RX completion function
Combine two end-cases in the same if statement with a single return value. Signed-off-by: Tariq Toukan --- drivers/net/ethernet/mellanox/mlx4/en_rx.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c index b4d144e67514..1e8f21b7fed8 100644 --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c @@ -662,12 +662,9 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud int polled = 0; int index; - if (unlikely(!priv->port_up)) + if (unlikely(!priv->port_up || budget <= 0)) return 0; - if (unlikely(budget <= 0)) - return polled; - ring = priv->rx_ring[cq_ring]; /* Protect accesses to: ring->xdp_prog, priv->mac_hash list */ -- 1.8.3.1
[PATCH net-next 1/4] net/mlx4_en: Add physical RX/TX bytes/packets counters
From: Eran Ben Elisha
Add physical RX/TX packets/bytes counters into ethtool output to monitor
all traffic that was received and transmitted on the port. These
counters are available only for none Virtual Function.
Signed-off-by: Eran Ben Elisha
Signed-off-by: Tariq Toukan
---
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 14 +
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 4 +++
drivers/net/ethernet/mellanox/mlx4/en_port.c| 38 -
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h| 1 +
drivers/net/ethernet/mellanox/mlx4/mlx4_stats.h | 10 ++-
5 files changed, 53 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index ebc1f566a4d9..9a7a2f05ab35 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -199,6 +199,10 @@ static int mlx4_en_moderation_update(struct mlx4_en_priv
*priv)
"rx_xdp_drop",
"rx_xdp_tx",
"rx_xdp_tx_full",
+
+ /* phy statistics */
+ "rx_packets_phy", "rx_bytes_phy",
+ "tx_packets_phy", "tx_bytes_phy",
};
static const char mlx4_en_test_names[][ETH_GSTRING_LEN]= {
@@ -411,6 +415,10 @@ static void mlx4_en_get_ethtool_stats(struct net_device
*dev,
if (bitmap_iterator_test(&it))
data[index++] = ((unsigned long *)&priv->xdp_stats)[i];
+ for (i = 0; i < NUM_PHY_STATS; i++, bitmap_iterator_inc(&it))
+ if (bitmap_iterator_test(&it))
+ data[index++] = ((unsigned long *)&priv->phy_stats)[i];
+
for (i = 0; i < priv->tx_ring_num[TX]; i++) {
data[index++] = priv->tx_ring[TX][i]->packets;
data[index++] = priv->tx_ring[TX][i]->bytes;
@@ -490,6 +498,12 @@ static void mlx4_en_get_strings(struct net_device *dev,
strcpy(data + (index++) * ETH_GSTRING_LEN,
main_strings[strings]);
+ for (i = 0; i < NUM_PHY_STATS; i++, strings++,
+bitmap_iterator_inc(&it))
+ if (bitmap_iterator_test(&it))
+ strcpy(data + (index++) * ETH_GSTRING_LEN,
+ main_strings[strings]);
+
for (i = 0; i < priv->tx_ring_num[TX]; i++) {
sprintf(data + (index++) * ETH_GSTRING_LEN,
"tx%d_packets", i);
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 8fc51bc29003..b62d2c3f976a 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -3256,6 +3256,10 @@ void mlx4_en_set_stats_bitmap(struct mlx4_dev *dev,
bitmap_set(stats_bitmap->bitmap, last_i, NUM_XDP_STATS);
last_i += NUM_XDP_STATS;
+
+ if (!mlx4_is_slave(dev))
+ bitmap_set(stats_bitmap->bitmap, last_i, NUM_PHY_STATS);
+ last_i += NUM_PHY_STATS;
}
int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_port.c
b/drivers/net/ethernet/mellanox/mlx4/en_port.c
index 1fa4849a6f56..0158b88bea5b 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_port.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_port.c
@@ -275,19 +275,31 @@ int mlx4_en_DUMP_ETH_STATS(struct mlx4_en_dev *mdev, u8
port, u8 reset)
priv->port_stats.xmit_more +=
READ_ONCE(ring->xmit_more);
}
- if (mlx4_is_master(mdev->dev)) {
- stats->rx_packets = en_stats_adder(&mlx4_en_stats->RTOT_prio_0,
- &mlx4_en_stats->RTOT_prio_1,
- NUM_PRIORITIES);
- stats->tx_packets = en_stats_adder(&mlx4_en_stats->TTOT_prio_0,
- &mlx4_en_stats->TTOT_prio_1,
- NUM_PRIORITIES);
- stats->rx_bytes = en_stats_adder(&mlx4_en_stats->ROCT_prio_0,
-&mlx4_en_stats->ROCT_prio_1,
-NUM_PRIORITIES);
- stats->tx_bytes = en_stats_adder(&mlx4_en_stats->TOCT_prio_0,
-&mlx4_en_stats->TOCT_prio_1,
-NUM_PRIORITIES);
+ if (!mlx4_is_slave(mdev->dev)) {
+ struct mlx4_en_phy_stats *p_stats = &priv->phy_stats;
+
+ p_stats->rx_packets_phy =
+ en_stats_adder(&mlx4_en_stats->RTOT_prio_0,
+ &mlx4_en_stats->RTOT_prio_1,
+ NUM_PRIORITIES);
+ p_stats->tx_packets_phy =
+ en_stats_adder(&mlx4_e
HOW ARE YOU
Dear Good day, I sent this mail praying for it to reach you in good health, since I myself are in a very critical health condition in which I sleep every night without knowing if I may be alive to see the next day. I am a widow suffering from long time illness. I have some fundsI inherited from my late husband, my Doctor told me recently that I would not last due to the illness. Having known my condition, I decided to donate this fund to a good person that will utilize it the way i am going to instruct herein. I need you claim this money and use it for Charity works, for orphanages, widows and also build schools for less privilege . I accept this decision because I do not have any child who will inherit this money after I die. Please I want your sincerely and urgent reply to know if you will be able to execute this project please reply to jry...@yahoo.com for more details Thank you, Mrs Grace
Re: [PATCH net] af_smc: fix NULL pointer dereference on sock_create_kern() error path
On 02/27/2018 02:49 PM, Davide Caratti wrote:
> when sock_create_kern(..., a) returns an error, 'a' might not be a valid
> pointer, so it shouldn't be dereferenced to read a->sk->sk_sndbuf and
> and a->sk->sk_rcvbuf; not doing that caused the following crash:
>
> general protection fault: [#1] SMP KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 4254 Comm: syzkaller919713 Not tainted 4.16.0-rc1+ #18
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:smc_create+0x14e/0x300 net/smc/af_smc.c:1410
> RSP: 0018:8801b06afbc8 EFLAGS: 00010202
> RAX: dc00 RBX: 8801b63457c0 RCX: 85a3e746
> RDX: 0004 RSI: RDI: 0020
> RBP: 8801b06afbf0 R08: 07c0 R09:
> R10: R11: R12:
> R13: 8801b6345c08 R14: ffe9 R15: 8695ced0
> FS: 01afb880() GS:8801db20()
> knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 2040 CR3: 0001b0721004 CR4: 001606f0
> DR0: DR1: DR2:
> DR3: DR6: fffe0ff0 DR7: 0400
> Call Trace:
> __sock_create+0x4d4/0x850 net/socket.c:1285
> sock_create net/socket.c:1325 [inline]
> SYSC_socketpair net/socket.c:1409 [inline]
> SyS_socketpair+0x1c0/0x6f0 net/socket.c:1366
> do_syscall_64+0x282/0x940 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x26/0x9b
> RIP: 0033:0x4404b9
> RSP: 002b:7fff44ab6908 EFLAGS: 0246 ORIG_RAX: 0035
> RAX: ffda RBX: RCX: 004404b9
> RDX: RSI: 0001 RDI: 002b
> RBP: 7fff44ab6910 R08: 0002 R09: 7fff44003031
> R10: 2040 R11: 0246 R12:
> R13: 0006 R14: R15:
> Code: 48 c1 ea 03 80 3c 02 00 0f 85 b3 01 00 00 4c 8b a3 48 04 00 00 48
> b8
> 00 00 00 00 00 fc ff df 49 8d 7c 24 20 48 89 fa 48 c1 ea 03 <80> 3c 02
> 00
> 0f 85 82 01 00 00 4d 8b 7c 24 20 48 b8 00 00 00 00
> RIP: smc_create+0x14e/0x300 net/smc/af_smc.c:1410 RSP: 8801b06afbc8
>
> Fixes: cd6851f30386 smc: remote memory buffers (RMBs)
> Reported-and-tested-by: syzbot+aa0227369be2dcc26...@syzkaller.appspotmail.com
> Signed-off-by: Davide Caratti
> ---
> net/smc/af_smc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index da1a5cdefd13..8cc97834d4f6 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -1406,8 +1406,10 @@ static int smc_create(struct net *net, struct socket
> *sock, int protocol,
> smc->use_fallback = false; /* assume rdma capability first */
> rc = sock_create_kern(net, PF_INET, SOCK_STREAM,
> IPPROTO_TCP, &smc->clcsock);
> - if (rc)
> + if (rc) {
> sk_common_release(sk);
> + goto out;
> + }
> smc->sk.sk_sndbuf = max(smc->clcsock->sk->sk_sndbuf, SMC_BUF_MIN_SIZE);
> smc->sk.sk_rcvbuf = max(smc->clcsock->sk->sk_rcvbuf, SMC_BUF_MIN_SIZE);
>
Thanks Davide, I add your patch to our local repository; it will be part of my
next patch set
to be sent to Dave Miller.
Regards, Ursula
Re: inconsistent lock state with usbnet/asix usb ethernet and xhci
Hi Eric,
On 2018-02-27 15:07, Eric Dumazet wrote:
On Tue, 2018-02-27 at 08:26 +0100, Marek Szyprowski wrote:
I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel
warning ("inconsistent lock state") on Chromebook2 Peach-PIT board. No
special activity is needed to reproduce this issue, it happens almost
on every boot. ASIX USB ethernet is connected to XHCI USB host controller
on that board. Is it a known issue? Frankly I have no idea where to look
to fix it. The same adapter connected to EHCI ports on other boards based
on the same SoC works fine without any warnings.
Here are some more information from that board:
# lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 002: ID 0b95:772b ASIX Electronics Corp. AX88772B
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 2232:1056 Silicon Motion
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
# lsusb -t
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=asix, 480M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Video, Driver=, 480M
|__ Port 1: Dev 2, If 1, Class=Video, Driver=, 480M
And the log with mentioned warning:
[ 17.768040]
[ 17.772239] WARNING: inconsistent lock state
[ 17.776511] 4.16.0-rc3-next-20180227-7-g876c53a7493c #453 Not tainted
[ 17.783329]
[ 17.787580] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[ 17.793607] swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 17.798751] (&syncp->seq#5){?.-.}, at: [<9b22e5f0>]
asix_rx_fixup_internal+0x188/0x288
[ 17.806790] {IN-HARDIRQ-W} state was registered at:
[ 17.811677] tx_complete+0x100/0x208
[ 17.815319] __usb_hcd_giveback_urb+0x60/0xf0
[ 17.819770] xhci_giveback_urb_in_irq+0xa8/0x240
[ 17.824469] xhci_td_cleanup+0xf4/0x16c
[ 17.828367] xhci_irq+0xe74/0x2240
[ 17.831827] usb_hcd_irq+0x24/0x38
[ 17.835343] __handle_irq_event_percpu+0x98/0x510
[ 17.840111] handle_irq_event_percpu+0x1c/0x58
[ 17.844623] handle_irq_event+0x38/0x5c
[ 17.848519] handle_fasteoi_irq+0xa4/0x138
[ 17.852681] generic_handle_irq+0x18/0x28
[ 17.856760] __handle_domain_irq+0x6c/0xe4
[ 17.860941] gic_handle_irq+0x54/0xa0
[ 17.864666] __irq_svc+0x70/0xb0
[ 17.867964] arch_cpu_idle+0x20/0x3c
[ 17.871578] arch_cpu_idle+0x20/0x3c
[ 17.875190] do_idle+0x144/0x218
[ 17.878468] cpu_startup_entry+0x18/0x1c
[ 17.882454] start_kernel+0x394/0x400
[ 17.886177] irq event stamp: 161912
[ 17.889616] hardirqs last enabled at (161912): [<7bedfacf>]
__netdev_alloc_skb+0xcc/0x140
[ 17.897893] hardirqs last disabled at (161911): []
__netdev_alloc_skb+0x94/0x140
[ 17.904903] exynos5-hsi2c 12ca.i2c: tx timeout
[ 17.906116] softirqs last enabled at (161904): [<387102ff>]
irq_enter+0x78/0x80
[ 17.906123] softirqs last disabled at (161905): []
irq_exit+0x134/0x158
[ 17.925722].
[ 17.925722] other info that might help us debug this:
[ 17.933435] Possible unsafe locking scenario:
[ 17.933435].
[ 17.940331] CPU0
[ 17.942488]
[ 17.944894] lock(&syncp->seq#5);
[ 17.948274]
[ 17.950847] lock(&syncp->seq#5);
[ 17.954386].
[ 17.954386] *** DEADLOCK ***
[ 17.954386].
[ 17.962422] no locks held by swapper/0/0.
[ 17.966011].
[ 17.966011] stack backtrace:
[ 17.971333] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.16.0-rc3-next-20180227-7-g876c53a7493c #453
[ 17.980312] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 17.986380] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 17.994128] [] (show_stack) from []
(dump_stack+0x90/0xc8)
[ 18.001339] [] (dump_stack) from []
(print_usage_bug+0x25c/0x2cc)
[ 18.009161] [] (print_usage_bug) from []
(mark_lock+0x290/0x698)
[ 18.014952] exynos5-hsi2c 12ca.i2c: tx timeout
[ 18.016899] [] (mark_lock) from []
(__lock_acquire+0x454/0x1850)
[ 18.029449] [] (__lock_acquire) from []
(lock_acquire+0xc8/0x2b8)
[ 18.037272] [] (lock_acquire) from []
(usbnet_skb_return+0x7c/0x1a0)
[ 18.045356] [] (usbnet_skb_return) from []
(asix_rx_fixup_internal+0x188/0x288)
[ 18.054420] [] (asix_rx_fixup_internal) from []
(usbnet_bh+0xf8/0x2e4)
[ 18.062694] [] (usbnet_bh) from []
(tasklet_action+0x8c/0x13c)
Re: brcm80211: remove duplicated bit-wise or of IEEE80211_CHAN_NO_IR
Colin Ian King wrote: > From: Colin Ian King > > Bit pattern IEEE80211_CHAN_NO_IR is being bit-wise or'd twice; > remove the redundant 2nd IEEE80211_CHAN_NO_IR > > Signed-off-by: Colin Ian King The prefix should be "brcmsmac:", I'll fix that. -- https://patchwork.kernel.org/patch/10237695/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [RFC][PATCH bpf] tools: bpftool: Fix tags for bpf-to-bpf calls
On 02/27/2018 01:13 PM, Sandipan Das wrote:
> "Naveen N. Rao" wrote:
>> I'm wondering if we can instead encode the bpf prog id in
>> imm32. That way, we should be able to indicate the BPF
>> function being called into. Daniel, is that something we
>> can consider?
>
> Since each subprog does not get a separate id, we cannot fetch
> the fd and therefore the tag of a subprog. Instead we can use
> the tag of the complete program as shown below.
>
> "Daniel Borkmann" wrote:
>> I think one limitation that would still need to be addressed later
>> with such approach would be regarding the xlated prog dump in bpftool,
>> see 'BPF calls via JIT' in 7105e828c087 ("bpf: allow for correlation
>> of maps and helpers in dump"). Any ideas for this (potentially if we
>> could use off + imm for calls, we'd get to 48 bits, but that seems
>> still not be enough as you say)?
>
> As an alternative, this is what I am thinking of:
>
> Currently, for bpf-to-bpf calls, if bpf_jit_kallsyms is enabled,
> bpftool looks up the name of the corresponding symbol for the
> JIT-ed subprogram and shows it in the xlated dump alongside the
> actual call instruction. However, the lookup is based on the
> target address which is calculated using the imm field of the
> instruction. So, once again, if imm is truncated, we will end
> up with the wrong address. Also, the subprog aux data (which
> has been proposed as a mitigation for this) is not accessible
> from this tool.
>
> We can still access the tag for the complete bpf program and use
> this with the correct offset in an objdump-like notation as an
> alterative for the name of the subprog that is the target of a
> bpf-to-bpf call instruction.
>
> Currently, an xlated dump looks like this:
>0: (85) call pc+2#bpf_prog_5f76847930402518_F
>1: (b7) r0 = 1
>2: (95) exit
>3: (b7) r0 = 2
>4: (95) exit
>
> With this patch, it will look like this:
>0: (85) call pc+2#bpf_prog_8f85936f29a7790a+3
(Note the +2 is the insn->off already.)
>1: (b7) r0 = 1
>2: (95) exit
>3: (b7) r0 = 2
>4: (95) exit
>
> where 8f85936f29a7790a is the tag of the bpf program and 3 is
> the offset to the start of the subprog from the start of the
> program.
The problem with this approach would be that right now the name is
something like bpf_prog_5f76847930402518_F where the subprog tag is
just a placeholder so in future, this may well adapt to e.g. the actual
function name from the elf file. Note that when kallsyms is enabled
then a name like bpf_prog_5f76847930402518_F will also appear in stack
traces, perf records, etc, so for correlation/debugging it would really
help to have them the same everywhere.
Worst case if there's nothing better, potentially what one could do in
bpf_prog_get_info_by_fd() is to dump an array of full addresses and
have the imm part as the index pointing to one of them, just unfortunate
that it's likely only needed in ppc64.
Re: [net-next v3 0/2] eBPF seccomp filters
On 02/26/2018 11:38 PM, Kees Cook wrote: On Mon, Feb 26, 2018 at 8:19 PM, Andy Lutomirski wrote: 3. Straight-up bugs. Those are exactly as problematic as verifier bugs in any other unprivileged eBPF program type, right? I don't see why seccomp is special here. My concern is more about unintended design mistakes or other feature creep with side-effects, especially when it comes to privileges and synchronization. Getting no-new-privs done correctly, for example, took some careful thought and discussion, and I'm shy from how painful TSYNC was on the process locking side, and eBPF has had some rather ugly flaws in the past (and recently: it was nice to be able to say for Spectre that seccomp filters couldn't be constructed to make attacks but eBPF could). Adding the complexity needs to be worth the gain. I'm on board for doing it, I just want to be careful. :) Another option might be to remove c/eBPF from the equation all together. c/eBPF allows flexibility and that almost always comes at the cost of additional security risk. Seccomp is for enhanced security yes? How about a new seccomp mode that passes in something like a bit vector or hashmap for "simple" white/black list checks validated by kernel code, versus user provided interpreted code? Of course this removes a fair number of things you can currently do or would be able to do with eBPF. Of course, restated from a security point of view, this removes a fair number of things an _attacker_ can do. Presumably the performance improvement would also be significant. Is this an idea worth prototyping? -chrish
Re: phy: micrel.c: Support ksz9031 energy-detect power-down mode
On Tue, Feb 27, 2018 at 05:09:45PM +0300, Maxim Uvarov wrote: > CC netdev > > 2018-02-27 13:12 GMT+03:00 Maxim Uvarov : > > It migth be reason to reconsider of unconditionally enable power-down mode. > > v1 of patch and code here: > > https://lkml.org/lkml/2016/10/3/199 > > > > I see that 9031 just lock ups with start from -40C just after > > swtiching to power save mode. And any soft reset do not work. Chip is > > not visible on mdio bus completely and only physycal power cycle > > restores operation. Temperature is acceptable for specifcication. Hi Maxim If it disappears, it makes me think it has lost its clock, the PLL has lost lock. How are you clocking the PHY? Do you have a crystal, or a 25MHz clock? Have you checked the clock inputs are within spec at -40C? Andrew
