* [PATCH net-next 0/2] net: phy: improve PM handling of PHY/MDIO
From: Heiner Kallweit @ 2018-06-02 20:33 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
Current implementation of MDIO bus PM ops doesn't actually implement
bus-specific PM ops but just calls PM ops defined on a device level
what doesn't seem to be fully in line with the core PM model.
When looking e.g. at __device_suspend() the PM core looks for PM ops
of a device in a specific order:
1. device PM domain
2. device type
3. device class
4. device bus
I think it has good reason that there's no PM ops on device level.
The situation can be improved by modeling PHY's as device type of
a MDIO device. If for some other type of MDIO device PM ops are
needed, it could be modeled as struct device_type as well.
Heiner Kallweit (2):
net: phy: add struct device_type representation of a PHY
net: phy: remove PM ops from MDIO bus
drivers/net/phy/mdio_bus.c | 48 ------------------
drivers/net/phy/phy_device.c | 96 +++++++++++++++++++-----------------
include/linux/mdio.h | 1 -
3 files changed, 50 insertions(+), 95 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH net v2] ipv6: omit traffic class when calculating flow hash
From: David Ahern @ 2018-06-02 20:33 UTC (permalink / raw)
To: Michal Kubecek, David S. Miller
Cc: netdev, linux-kernel, Nicolas Dichtel, Tom Herbert, Ido Schimmel
In-Reply-To: <20180602080528.54B27A0C48@unicorn.suse.cz>
On 6/2/18 1:40 AM, Michal Kubecek wrote:
> Some of the code paths calculating flow hash for IPv6 use flowlabel member
> of struct flowi6 which, despite its name, encodes both flow label and
> traffic class. If traffic class changes within a TCP connection (as e.g.
> ssh does), ECMP route can switch between path. It's also incosistent with
> other code paths where ip6_flowlabel() (returning only flow label) is used
> to feed the key.
>
> Use only flow label everywhere, including one place where hash key is set
> using ip6_flowinfo().
>
> Fixes: 51ebd3181572 ("ipv6: add support of equal cost multipath (ECMP)")
> Fixes: f70ea018da06 ("net: Add functions to get skb->hash based on flow structures")
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
> ---
> v2: introduce and use an inline helper as suggested by David Ahern
>
> include/net/ipv6.h | 5 +++++
> net/core/flow_dissector.c | 2 +-
> net/ipv6/route.c | 4 ++--
> 3 files changed, 8 insertions(+), 3 deletions(-)
>
Acked-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] net: phy: improve PHY suspend/resume
From: Heiner Kallweit @ 2018-06-02 20:27 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <20180601001043.GA2303@lunn.ch>
On 01.06.2018 02:10, Andrew Lunn wrote:
>> Configuring the different WoL options isn't handled by writing to
>> the PHY registers but by writing to chip / MAC registers.
>> Therefore phy_suspend() isn't able to figure out whether WoL is
>> enabled or not. Only the parent has the full picture.
>
> Hi Heiner
>
> I think you need to look at your different runtime PM domains. If i
> understand the code right, you runtime suspend if there is no
> link. But for this to work correctly, your PHY needs to keep working.
> You also cannot assume all accesses to the PHY go via the MAC. Some
> calls will go direct to the PHY, and they can trigger MDIO bus
> accesses. So i think you need two runtime PM domains. MAC and MDIO
> bus. Maybe just the pll? An MDIO bus is a device, so it can have its
> on PM callbacks. It is not clear what you need to resume in order to
> make MDIO work.
>
Thanks for your comments!
The actual problem is quite small: I get an error at MDIO suspend,
the PHY however is suspended later by the driver's suspend callback
anyway. Because the problem is small I'm somewhat reluctant to
consider bigger changes like introducing different PM domains.
Primary reason for the error is that the network chip is in PCI D3hot
at that moment. In addition to that for some of the chips supported by
the driver also MDIO-relevant PLL's might be disabled.
By the way:
When checking PM handling for PHY/MDIO I stumbled across something
that can be improved IMO, I'll send a patch for your review.
> It might also help if you do the phy_connect in .ndo_open and
> disconnect in .ndo_stop. This is a common pattern in drivers. But some
> also do it is probe and remove.
>
Thanks for the hint. I will move phy_connect_direct accordingly.
> Andrew
>
Heiner
^ permalink raw reply
* Proposal
From: Miss Victoria Mehmet @ 2018-06-02 19:40 UTC (permalink / raw)
--
Hello
I have been trying to contact you. Did you get my business proposal?
Best Regards,
Miss.Victoria Mehmet
^ permalink raw reply
* [PATCH 3/3] sh_eth: use DIV_ROUND_UP() in sh_eth_soft_swap()
From: Sergei Shtylyov @ 2018-06-02 19:40 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc
In-Reply-To: <9027499a-0e19-7721-a17f-26e86885da3f@cogentembedded.com>
When initializing 'maxp' in sh_eth_soft_swap(), the buffer length needs
to be rounded up -- that's just asking for DIV_ROUND_UP()!
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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
@@ -464,7 +464,7 @@ static void sh_eth_soft_swap(char *src,
{
#ifdef __LITTLE_ENDIAN
u32 *p = (u32 *)src;
- u32 *maxp = p + ((len + sizeof(u32) - 1) / sizeof(u32));
+ u32 *maxp = p + DIV_ROUND_UP(len, sizeof(u32));
for (; p < maxp; p++)
*p = swab32(*p);
^ permalink raw reply
* [PATCH 2/3] sh_eth: uninline sh_eth_soft_swap()
From: Sergei Shtylyov @ 2018-06-02 19:38 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc
In-Reply-To: <9027499a-0e19-7721-a17f-26e86885da3f@cogentembedded.com>
sh_eth_tsu_soft_swap() is called twice by the driver, remove *inline* and
move that function from the header to the driver itself to let gcc decide
whether to expand it inline or not...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 11 +++++++++++
drivers/net/ethernet/renesas/sh_eth.h | 12 ------------
2 files changed, 11 insertions(+), 12 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
@@ -460,6 +460,17 @@ static u32 sh_eth_tsu_read(struct sh_eth
return ioread32(mdp->tsu_addr + offset);
}
+static void sh_eth_soft_swap(char *src, int len)
+{
+#ifdef __LITTLE_ENDIAN
+ u32 *p = (u32 *)src;
+ u32 *maxp = p + ((len + sizeof(u32) - 1) / sizeof(u32));
+
+ for (; p < maxp; p++)
+ *p = swab32(*p);
+#endif
+}
+
static void sh_eth_select_mii(struct net_device *ndev)
{
struct sh_eth_private *mdp = netdev_priv(ndev);
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
@@ -560,18 +560,6 @@ struct sh_eth_private {
unsigned wol_enabled:1;
};
-static inline void sh_eth_soft_swap(char *src, int len)
-{
-#ifdef __LITTLE_ENDIAN
- u32 *p = (u32 *)src;
- u32 *maxp;
- maxp = p + ((len + sizeof(u32) - 1) / sizeof(u32));
-
- for (; p < maxp; p++)
- *p = swab32(*p);
-#endif
-}
-
static inline void *sh_eth_tsu_get_offset(struct sh_eth_private *mdp,
int enum_index)
{
^ permalink raw reply
* [PATCH 1/3] sh_eth: make sh_eth_soft_swap() work on ARM
From: Sergei Shtylyov @ 2018-06-02 19:37 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc
In-Reply-To: <9027499a-0e19-7721-a17f-26e86885da3f@cogentembedded.com>
Browsing thru the driver disassembly, I noticed that ARM gcc generated
no code whatsoever for sh_eth_soft_swap() while building a little-endian
kernel -- apparently __LITTLE_ENDIAN__ was not being #define'd, however
it got implicitly #define'd when building with the SH gcc (I could only
find the explicit #define __LITTLE_ENDIAN that was #include'd when building
a little-endian kernel). Luckily, the Ether controller only doing big-
endian DMA is encountered on the early SH771x SoCs only and all ARM SoCs
implement EDMR.DE and thus set 'sh_eth_cpu_data::hw_swap'. But anyway, we
need to fix the #ifdef inside sh_eth_soft_swap() to something that would
work on all architectures...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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
@@ -562,7 +562,7 @@ struct sh_eth_private {
static inline void sh_eth_soft_swap(char *src, int len)
{
-#ifdef __LITTLE_ENDIAN__
+#ifdef __LITTLE_ENDIAN
u32 *p = (u32 *)src;
u32 *maxp;
maxp = p + ((len + sizeof(u32) - 1) / sizeof(u32));
^ permalink raw reply
* [PATCH 0/3] sh_eth: fix & clean up sh_eth_soft_swap()
From: Sergei Shtylyov @ 2018-06-02 19:32 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc
Hello!
Here's a set of 3 patches against DaveM's 'net-next.git' repo. First one fixes an
old buffer endiannes issue (luckily, the ARM SoCs are smart enough to not actually
care) plus couple clean ups around sh_eth_soft_swap()...
[1/1] sh_eth: make sh_eth_soft_swap() work on ARM
[2/3] sh_eth: uninline sh_eth_soft_swap()
[3/3] sh_eth: use DIV_ROUND_UP() in sh_eth_soft_swap()
MBR, Sergei
^ permalink raw reply
* Re: [PATCH bpf-next 1/2] bpf: btf: Check array t->size
From: Alexei Starovoitov @ 2018-06-02 18:31 UTC (permalink / raw)
To: Martin KaFai Lau; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20180602160651.3960897-1-kafai@fb.com>
On Sat, Jun 02, 2018 at 09:06:50AM -0700, Martin KaFai Lau wrote:
> This patch ensures array's t->size is 0.
>
> The array size is decided by its individual elem's size and the
> number of elements. Hence, t->size is not used and
> it must be 0.
>
> A test case is added to test_btf.c
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Both applied.
Please provide cover letter with short description next time
when sending series.
Thanks
^ permalink raw reply
* [PATCH net-next 2/2] mlxsw: spectrum_span: Suppress VLAN on BRIDGE_VLAN_INFO_UNTAGGED
From: Ido Schimmel @ 2018-06-02 18:09 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, petrm, mlxsw, Ido Schimmel
In-Reply-To: <20180602180935.24544-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
When offloading mirroring to gretap or ip6gretap netdevices, an 802.1q
bridge is one of the soft devices permissible in the underlay when
resolving the packet path. After the packet path is resolved to a
particular bridge egress device, flags on packet VLAN determine whether
the egressed packet should be tagged.
The current logic however only ever sets the VLAN tag, never suppresses
it. Thus if there's a VLAN netdevice above the bridge that determines
the packet VLAN, that VLAN is never unset, and mirroring is configured
with VLAN tagging.
Fix by setting the packet VLAN on both branches: set to zero (for unset)
when BRIDGE_VLAN_INFO_UNTAGGED, copy the resolved VLAN (e.g. from bridge
PVID) otherwise.
Fixes: 946a11e7408e ("mlxsw: spectrum_span: Allow bridge for gretap mirror")
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
index da3f7f527360..3d187d88cc7c 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
@@ -191,7 +191,9 @@ mlxsw_sp_span_entry_bridge_8021q(const struct net_device *br_dev,
if (br_vlan_get_info(edev, vid, &vinfo))
return NULL;
- if (!(vinfo.flags & BRIDGE_VLAN_INFO_UNTAGGED))
+ if (vinfo.flags & BRIDGE_VLAN_INFO_UNTAGGED)
+ *p_vid = 0;
+ else
*p_vid = vid;
return edev;
}
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 1/2] mlxsw: spectrum_switchdev: Postpone respin on object deletion
From: Ido Schimmel @ 2018-06-02 18:09 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, petrm, mlxsw, Ido Schimmel
In-Reply-To: <20180602180935.24544-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
VLAN deletion notifications are emitted before the relevant change is
projected to bridge configuration. Thus, like with VLAN addition,
schedule SPAN respin for later.
Fixes: c520bc698647 ("mlxsw: Respin SPAN on switchdev events")
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index 8a15ac49cb5a..e97652c40d13 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -1856,7 +1856,7 @@ static int mlxsw_sp_port_obj_del(struct net_device *dev,
break;
}
- mlxsw_sp_span_respin(mlxsw_sp_port->mlxsw_sp);
+ mlxsw_sp_span_respin_schedule(mlxsw_sp_port->mlxsw_sp);
return err;
}
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 0/2] mlxsw: Fixes in offloading of mirror-to-gretap
From: Ido Schimmel @ 2018-06-02 18:09 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, petrm, mlxsw, Ido Schimmel
Petr says:
These two patches fix issues in offloading of mirror-to-gretap when
bridge is present in the underlay.
In patch #1, reconsideration of SPAN configuration is not done right at
the point that SWITCHDEV_OBJ_ID_PORT_VLAN deletion notification is
distributed, but is postponed, because the notifications are actually
distributed before the relevant change is implemented in the bridge.
In patch #2, a problem in configuring VLAN tagging in situations when a
VLAN device is on top of an 802.1Q bridge whose egress port is marked as
"egress untagged". In that case, mlxsw would neglect to suppress the
tagging implicitly assumed after the VLAN device was seen.
Petr Machata (2):
mlxsw: spectrum_switchdev: Postpone respin on object deletion
mlxsw: spectrum_span: Suppress VLAN on BRIDGE_VLAN_INFO_UNTAGGED
drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c | 4 +++-
drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
--
2.14.3
^ permalink raw reply
* Dear Talented
From: Lisa Clement @ 2018-06-02 17:11 UTC (permalink / raw)
To: Recipients
Dear Talented,
I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a
Film Corporation Located in the United State, is Soliciting for the
Right to use Your Photo/Face and Personality as One of the Semi -Major
Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The Story
of Spies in Disguise (Spies in Disguise 2019) The Movie is Currently Filming (In Production) Please Note That There Will Be No Auditions, Traveling or Any Special / Professional Acting Skills, Since the Production of This Movie Will Be Done with our State of Art Computer -Generating Imagery Equipment. We Are Prepared to Pay the Total Sum of $620,000.00 USD. For More Information/Understanding, Please Write us on the E-Mail Below. CONTACT EMAIL: bluesky.filmstudio@usa.com
All Reply to: bluesky.filmstudio@usa.com
Note: Only the Response send to this mail will be Given a Prior Consideration.
Talent Scout
Lisa Clement
^ permalink raw reply
* Re: ANNOUNCE: Enhanced IP v1.4
From: Willy Tarreau @ 2018-06-02 17:02 UTC (permalink / raw)
To: Sam Patton; +Cc: netdev
In-Reply-To: <330e58f3-61d3-6abc-4f7c-1726e0ce852d@enhancedip.org>
On Sat, Jun 02, 2018 at 12:17:12PM -0400, Sam Patton wrote:
> As far as application examples, check out this simple netcat-like
> program I use for testing:
>
> https://github.com/EnIP/enhancedip/blob/master/userspace/netcat/netcat.c
>
> Lines 61-67 show how to connect directly via an EnIP address. The
> netcat-like application uses
>
> a header file called eip.h.
OK so basically we need to use a new address structure (which makes sense),
however I'm not sure I understand how the system is supposed to know it has
to use EnIP instead of IPv4 if the sin_family remains the same :
...
memset(&serv_addr, 0, sizeof(struct sockaddr_ein));
serv_addr.sin_family= AF_INET;
serv_addr.sin_port = htons(portno);
serv_addr.sin_addr1=inet_addr(argv[1]);
serv_addr.sin_addr2=inet_addr(argv[2]);
if (connect(sockfd,(struct sockaddr *) &serv_addr,sizeof(serv_addr)) < 0)
error("ERROR connecting");
...
Does it solely rely on the 3rd argument to connect() to know that it
may read sin_addr2 ? If so, that sounds a bit fragile to me because I
*think* (but could be wrong) that right now any size at least as large
as sockaddr_in work for IPv4 (typically I think if you pass a struct
sockaddr_storage with its size it should work). So there would be a
risk of breaking applications if this is the case.
I suspect that using a different family would make things more robust
and more friendly to applications. But that's just a first opinion,
you have worked longer than me on this.
> You can look at it here:
>
> https://github.com/EnIP/enhancedip/blob/master/userspace/include/eip.h
Thank you. There's a problem with your #pragma pack there, it will
propagate to all struct declared after this file is included and
will force all subsequent structs to be packed. It would be preferable
to use __attribute__((packed)) on the struct or to use pragma pack()
safely (I've just seen it supports push/pop options).
> EnIP makes use of IPv6 AAAA records for DNS lookup. We simply put
> 2001:0101 (which is an IPv6 experimental prefix) and
>
> then we put the 64-bit EnIP address into the next 8 bytes of the
> address. The remaining bytes are set to zero.
Does this require a significant amount of changes to the libc ?
> In the kernel, if you want to see how we convert the IPv6 DNS lookup
> into something connect() can manage,
>
> check out the add_enhanced_ip() routine found here:
>
> https://github.com/EnIP/enhancedip/blob/master/kernel/4.9.28/socket.c
Hmmm so both IPv4 and IPv6 addresses are supported and used together.
So that just makes me think that if in the end you need a little bit
of IPv6 to handle this, why not instead define a new way to map IPv6 to
Enhanced IPv4 ? I mean, you'd exclusively use AF_INET6 in applications,
within a dedicated address range, allowing you to naturally use all of
the IPv6 ecosystem in place in userland, but use IPv4 over the wire.
This way applications would possibly require even less modififications,
if any at all because they'd accept/connect/send/receive data for IPv6
address families that they all deal with nowadays, but this would rely
on an omni-present IPv4 infrastructure.
> The reason we had to do changes for openssh and not other applications
> (that use DNS) is openssh has a check to
>
> see if the socket is using IP options. If the socket does, sshd drops
> the connection. I had to work around that to get openssh working
OK. They possibly do this to avoid source-routing.
> with EnIP. The result: if you want to connect the netcat-like program
> with IP addresses you'll end up doing something like the
>
> example above. If you're using DNS (getaddrinfo) to connect(), it
> should just work (except for sshd as noted).
>
> Here's the draft experimental RFC:
> https://tools.ietf.org/html/draft-chimiak-enhanced-ipv4-03
Yep I've found it on the site.
> I'll also note that I am doing this code part time as a hobby for a long
> time so I appreciate your help and support. It would be really
>
> great if the kernel community decided to pick this up, but if it's not a
> reality please let me know soonest so I can move on to a
>
> different hobby. :)
I *personally* think there is some value in what you're experimenting
with, and doing it as a hobby can leave you with the time needed to
collect pros and cons from various people. I'm just thinking that in
order to get some adoption, you need to be extremely careful not to
break any of the IPv4 applications developed in the last 38 years,
and by this, AF_INET+sizeof() scares me a little bit.
Regards,
Willy
^ permalink raw reply
* Re: [PATCH 4/4] cpsw: add switchdev support
From: Ilias Apalodimas @ 2018-06-02 16:52 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, netdev, grygorii.strashko, ivan.khoronzhuk, nsekhar,
jiri, ivecera, francois.ozog, yogeshs, spatton
In-Reply-To: <A6381ECC-4C7C-4CCB-88B0-9FC77FE18F66@gmail.com>
On Sat, Jun 02, 2018 at 09:10:08AM -0700, Florian Fainelli wrote:
> On June 2, 2018 3:34:32 AM MST, Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote:
> >Hi Florian,
> >
> >Thanks for taking time to look into this
> >
> >On Fri, Jun 01, 2018 at 02:48:48PM -0700, Florian Fainelli wrote:
> >>
> >>
> >> On 05/24/2018 09:56 PM, Ilias Apalodimas wrote:
> >> > On Thu, May 24, 2018 at 06:39:04PM +0200, Andrew Lunn wrote:
> >> >> On Thu, May 24, 2018 at 04:32:34PM +0300, Ilias Apalodimas wrote:
> >> >>> On Thu, May 24, 2018 at 03:12:29PM +0200, Andrew Lunn wrote:
> >> >>>> Device tree is supposed to describe the hardware. Using that
> >hardware
> >> >>>> in different ways is not something you should describe in DT.
> >> >>>>
> >> >>> The new switchdev mode is applied with a .config option in the
> >kernel. What you
> >> >>> see is pre-existing code, so i am not sure if i should change it
> >in this
> >> >>> patchset.
> >> >>
> >> >> If you break the code up into a library and two drivers, it
> >becomes a
> >> >> moot point.
> >> > Agree
> >> >
> >> >>
> >> >> But what i don't like here is that the device tree says to do dual
> >> >> mac. But you ignore that and do sometime else. I would prefer that
> >if
> >> >> DT says dual mac, and switchdev is compiled in, the probe fails
> >with
> >> >> EINVAL. Rather than ignore something, make it clear it is invalid.
> >> > The switch has 3 modes of operation as is.
> >> > 1. switch mode, to enable that you don't need to add anything on
> >> > the DTS and linux registers a single netdev interface.
> >> > 2. dual mac mode, this is when you need to add dual_emac; on the
> >DTS.
> >> > 3. switchdev mode which is controlled by a .config option, since as
> >you
> >> > pointed out DTS was not made for controlling config options.
> >> >
> >> > I agree that this is far from beautiful. If the driver remains as
> >in though,
> >> > i'd prefer either keeping what's there or making "switchdev" a DTS
> >option,
> >> > following the pre-existing erroneous usage rather than making the
> >device
> >> > unusable. If we end up returning some error and refuse to
> >initialize, users
> >> > that remote upgrade their equipment, without taking a good look at
> >changelog,
> >> > will loose access to their devices with no means of remotely fixing
> >that.
> >>
> >> It seems to me that the mistake here is seeing multiple modes of
> >> operations for the cpsw. There are not actually many, there is one
> >> usage, and then there is what you can and cannot offload.
> >CPSW has in fact 2 modes of operation, different FIFO usage/lookup
> >entry(it's
> >called ALE in the current driver) by-pass(which is used in dual emac
> >for
> >example) and other features. Again Grygorii is better suited to answer
> >the
> >exact differences.
> >> The basic
> >> premise with switchdev and DSA (which uses switchdev) is that each
> >> user-facing port of your switch needs to work as if it were a normal
> >> Ethernet NIC, that is what you call dual-MAC I believe. Then, when
> >you
> >> create a bridge and you enslave those ports into the bridge, you need
> >to
> >> have forwarding done in hardware between these two ports when the
> >> SMAC/DMAC are not for the host/CPU/management interface and you must
> >> simultaneously still have the host have the ability to send/receive
> >> traffic through the bridge device.
> >Yes dual emac does that. But dual emac configures the port facing VLAN
> >to the
> >CPU port as well. So dual emac splits and uses 2 interfaces. VLAN 1 is
> >configured on port1 + CPU port and VLAN 2 is confired on port 2 + CPU
> >port
> >That's exactly what the current RFC does as well, with the addition of
> >registering a sw0p0 (i'll explain why later on this mail)
> >A little more detail on the issue we are having. On my description
> >sw0p0 -> CPU port, sw0p1 -> port 1 sw0p2 -> port 2. sw0p1/sw0p2 are the
> >ports
> >that have PHYs attached.
> >
> >When we start in the new switchdev mode all interfaces are added to
> >VLAN 0
> >so CPU port + port1 + port2 are all in the same VLAN group. In that
> >case sw0p1
> >and sw0p2 are working as you describe. So those 2 interfaces can
> >send/receive
> >traffic normally which matches the switchdev case.
> >
> >When we add them on a bridge(let's say br0), VLAN1(or any default
> >bridge VLAN)
> >is now configured on sw0p1 and sw0p2 but *not* on the CPU port.
> >From this point on the whole fuunctionality just collapses. The switch
> >will
> >work and offload traffic between sw0p1/sw0p2 but the bridge won't be
> >able to
> >get an ip address (since VLAN1 is not a member of the CPU port and the
> >packet
> >gets dropped).
> >IGMPv2/V3 messages will never reach the br_multicast.c code to trigger
> >switchdev and configure the MDBs on the ports. i am prety sure there
> >are other
> >fail scenarios which i haven't discovered already, but those 2 are the
> >most
> >basic ones. If we add VLAN1 on the CPU port, everything works as
> >intended of
> >course.
> >
> >That's the reason we registered sw0p0 as the CPU port. It can't do any
> >"real"
> >traffic, but you can configure the CPU port independantly and not be
> >forced to
> >do an OR on every VLAN add/delete grouping the CPU port with your port
> >command.
> >The TL;DR version of this is that the switch is working exactly as
> >switchdev is
> >expecting offloading traffic to the hardware when possible as long as
> >the CPU
> >port is member of the proper VLANs
> >
> >Petr's patch solves this for us
> >(9c86ce2c1ae337fc10568a12aea812ed03de8319).
> >We can now do "bridge vlan add dev br0 vid 100 pvid untagged self" and
> >decide
> >when to add the CPU port or not.
> >
> >There are still a couple of cases that are not covered though, if we
> >don't
> >register the CPU port. We cant decide when to forward multicast
> >traffic on the CPU port if a join hasn't been sent from br0.
> >So let's say you got 2 hosts doing multicast and for whatever reason
> >the host
> >wants to see that traffic.
> >With the CPU port present you can do a
> >"bridge mdb add dev br0 port sw0p0 grp 239.1.1.1 permanent" which will
> >offload
> >the traffic to the CPU port and thus the host. If this goes away we are
> >forced
> >to send a join.
>
> Thanks for the detailed explanation. Somehow I was under the impression that cpsw had the ability, through specific DMA descriptor bits to direct traffic towards one external port or another and conversely, have that information from the HW when receiving packets.
That's one mode of operation when by-passing the ALE if my understanding of
the hardware is correct. You can choose not to do that. I am still earning all
the details of the ahrdware myself. On Rx though you still need the CPU to
participate to receive the packet(and yes the descriptor indicates the port)
> What you describe is exactly the same problem we have in DSA when the switch advertises DSA_TAG_PROTO_NONE where only VLAN tags could help differentiate traffic from external ports. At some point there was a discuss of making DSA_TAG_PROTO_NONE automatically create one VLAN per port but this is a good source for other problems...
I am pretty sure i am not the first one to encounter this kind of problems
>
> Looking forward to your follow-up patch series!
Will do!
>
> --
> Florian
Thanks
Ilias
^ permalink raw reply
* Re: [PATCH net] packet: fix reserve calculation
From: Lennert Buytenhek @ 2018-06-02 16:35 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: netdev, davem, Willem de Bruijn
In-Reply-To: <20180524221030.158150-1-willemdebruijn.kernel@gmail.com>
On Thu, May 24, 2018 at 06:10:30PM -0400, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> Commit b84bbaf7a6c8 ("packet: in packet_snd start writing at link
> layer allocation") ensures that packet_snd always starts writing
> the link layer header in reserved headroom allocated for this
> purpose.
>
> This is needed because packets may be shorter than hard_header_len,
> in which case the space up to hard_header_len may be zeroed. But
> that necessary padding is not accounted for in skb->len.
>
> The fix, however, is buggy. It calls skb_push, which grows skb->len
> when moving skb->data back. But in this case packet length should not
> change.
>
> Instead, call skb_reserve, which moves both skb->data and skb->tail
> back, without changing length.
>
> Fixes: b84bbaf7a6c8 ("packet: in packet_snd start writing at link layer allocation")
> Reported-by: Tariq Toukan <tariqt@mellanox.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
After upgrading my router from 4.16.11 to 4.16.12, it is failing to
obtain a DHCP lease from my ISP, as it started sending out DHCP queries
with 14 bytes of junk at the end (which is presumably causing RX csum
failures on the DHCP server end):
13:08:39.292667 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx, length 300, xid 0xxxxxxxxx, Flags [none] (0x0000)
[...]
- 0x0150: 0000 0000 0000
+ 0x0150: 0000 0000 0000 e802 0000 0000 0000 e802
+ 0x0160: 0000 0000
This seems to be caused by (the -stable backport of) b84bbaf7a6c8
("packet: in packet_snd start writing at link layer allocation") and
appears to have been fixed by this patch, as applying this patch to
4.16.12 makes DHCP work for me again.
Tested-by: Lennert Buytenhek <buytenh@wantstofly.org>
> ---
> net/packet/af_packet.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index e9422fe45179..acb7b86574cd 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -2911,7 +2911,7 @@ static int packet_snd(struct socket *sock, struct msghdr *msg, size_t len)
> if (unlikely(offset < 0))
> goto out_free;
> } else if (reserve) {
> - skb_push(skb, reserve);
> + skb_reserve(skb, -reserve);
> }
>
> /* Returns -EFAULT on error */
> --
> 2.17.0.921.gf22659ad46-goog
^ permalink raw reply
* Re: ANNOUNCE: Enhanced IP v1.4
From: Sam Patton @ 2018-06-02 16:17 UTC (permalink / raw)
To: Willy Tarreau; +Cc: netdev
In-Reply-To: <20180602055717.GB17899@1wt.eu>
Hello Willy, netdev,
Thank you for your reply and advice. I couldn't agree more with you
about containers and the exciting prospects there,
as well as the ADSL scenario you mention.
As far as application examples, check out this simple netcat-like
program I use for testing:
https://github.com/EnIP/enhancedip/blob/master/userspace/netcat/netcat.c
Lines 61-67 show how to connect directly via an EnIP address. The
netcat-like application uses
a header file called eip.h. You can look at it here:
https://github.com/EnIP/enhancedip/blob/master/userspace/include/eip.h
EnIP makes use of IPv6 AAAA records for DNS lookup. We simply put
2001:0101 (which is an IPv6 experimental prefix) and
then we put the 64-bit EnIP address into the next 8 bytes of the
address. The remaining bytes are set to zero.
In the kernel, if you want to see how we convert the IPv6 DNS lookup
into something connect() can manage,
check out the add_enhanced_ip() routine found here:
https://github.com/EnIP/enhancedip/blob/master/kernel/4.9.28/socket.c
The reason we had to do changes for openssh and not other applications
(that use DNS) is openssh has a check to
see if the socket is using IP options. If the socket does, sshd drops
the connection. I had to work around that to get openssh working
with EnIP. The result: if you want to connect the netcat-like program
with IP addresses you'll end up doing something like the
example above. If you're using DNS (getaddrinfo) to connect(), it
should just work (except for sshd as noted).
Here's the draft experimental RFC:
https://tools.ietf.org/html/draft-chimiak-enhanced-ipv4-03
I'll also note that I am doing this code part time as a hobby for a long
time so I appreciate your help and support. It would be really
great if the kernel community decided to pick this up, but if it's not a
reality please let me know soonest so I can move on to a
different hobby. :)
Thank you.
Sam Patton
On 6/2/18 1:57 AM, Willy Tarreau wrote:
> Hello Sam,
>
> On Fri, Jun 01, 2018 at 09:48:28PM -0400, Sam Patton wrote:
>> Hello!
>>
>> If you do not know what Enhanced IP is, read this post on netdev first:
>>
>> https://www.spinics.net/lists/netdev/msg327242.html
>>
>>
>> The Enhanced IP project presents:
>>
>> Enhanced IP v1.4
>>
>> The Enhanced IP (EnIP) code has been updated. It now builds with OpenWRT barrier breaker (for 148 different devices). We've been testing with the Western Digital N600 and N750 wireless home routers.
> (...) First note, please think about breaking your lines if you want your
> mails to be read by the widest audience, as for some of us here, reading
> lines wider than a terminal is really annoying, and often not considered
> worth spending time on them considering there are so many easier ones
> left to read.
>
>> Interested in seeing Enhanced IP in the Linux kernel, read on. Not
>> interested in seeing Enhanced IP in the Linux kernel read on.
> (...)
>
> So I personally find the concept quite interesting. It reminds me of the
> previous IPv5/IPv7/IPv8 initiatives, which in my opinion were a bit hopeless.
> Here the fact that you decide to consider the IPv4 address as a network opens
> new perspectives. For containerized environments it could be considered that
> each server, with one IPv4, can host 2^32 guests and that NAT is not needed
> anymore for example. It could also open the possibility that enthousiasts
> can more easily host some services at home behind their ADSL line without
> having to run on strange ports.
>
> However I think your approach is not the most efficient to encourage adoption.
> It's important to understand that there will be little incentive for people
> to patch their kernels to run some code if they don't have the applications
> on top of it. The kernel is not the end goal for most users, the kernel is
> just the lower layer needed to run applications on top. I looked at your site
> and the github repo, and all I could find was a pre-patched openssh, no simple
> explanation of what to change in an application.
>
> What you need to do first is to *explain* how to modify userland applications
> to support En-IP, provide an echo server and show the parts which have to be
> changed. Write a simple client and do the same. Provide your changes to
> existing programs as patches, not as pre-patched code. This way anyone can
> use your patches on top of other versions, and can use these patches to
> understand what has to be modified in their applications.
>
> Once applications are easy to patch, the incentive to install patched kernels
> everywhere will be higher. For many enthousiasts, knowing that they only have
> to modify the ADSL router to automatically make their internal IoT stuff
> accessible from outside indeed becomes appealing.
>
> Then you'll need to provide patches for well known applications like curl,
> wget, DNS servers (bind...), then browsers.
>
> In my case I could be interested in adding support for En-ip into haproxy,
> and only once I don't see any showstopped in doing this, I'd be willing to
> patch my kernel to support it.
>
> Last advice, provide links to your drafts in future e-mails, they are not
> easy to find on your site, we have to navigate through various pages to
> finally find them.
>
> Regards,
> Willy
^ permalink raw reply
* Re: [PATCH 4/4] cpsw: add switchdev support
From: Florian Fainelli @ 2018-06-02 16:10 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Andrew Lunn, netdev, grygorii.strashko, ivan.khoronzhuk, nsekhar,
jiri, ivecera, francois.ozog, yogeshs, spatton
In-Reply-To: <20180602103432.GA948@apalos>
On June 2, 2018 3:34:32 AM MST, Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote:
>Hi Florian,
>
>Thanks for taking time to look into this
>
>On Fri, Jun 01, 2018 at 02:48:48PM -0700, Florian Fainelli wrote:
>>
>>
>> On 05/24/2018 09:56 PM, Ilias Apalodimas wrote:
>> > On Thu, May 24, 2018 at 06:39:04PM +0200, Andrew Lunn wrote:
>> >> On Thu, May 24, 2018 at 04:32:34PM +0300, Ilias Apalodimas wrote:
>> >>> On Thu, May 24, 2018 at 03:12:29PM +0200, Andrew Lunn wrote:
>> >>>> Device tree is supposed to describe the hardware. Using that
>hardware
>> >>>> in different ways is not something you should describe in DT.
>> >>>>
>> >>> The new switchdev mode is applied with a .config option in the
>kernel. What you
>> >>> see is pre-existing code, so i am not sure if i should change it
>in this
>> >>> patchset.
>> >>
>> >> If you break the code up into a library and two drivers, it
>becomes a
>> >> moot point.
>> > Agree
>> >
>> >>
>> >> But what i don't like here is that the device tree says to do dual
>> >> mac. But you ignore that and do sometime else. I would prefer that
>if
>> >> DT says dual mac, and switchdev is compiled in, the probe fails
>with
>> >> EINVAL. Rather than ignore something, make it clear it is invalid.
>> > The switch has 3 modes of operation as is.
>> > 1. switch mode, to enable that you don't need to add anything on
>> > the DTS and linux registers a single netdev interface.
>> > 2. dual mac mode, this is when you need to add dual_emac; on the
>DTS.
>> > 3. switchdev mode which is controlled by a .config option, since as
>you
>> > pointed out DTS was not made for controlling config options.
>> >
>> > I agree that this is far from beautiful. If the driver remains as
>in though,
>> > i'd prefer either keeping what's there or making "switchdev" a DTS
>option,
>> > following the pre-existing erroneous usage rather than making the
>device
>> > unusable. If we end up returning some error and refuse to
>initialize, users
>> > that remote upgrade their equipment, without taking a good look at
>changelog,
>> > will loose access to their devices with no means of remotely fixing
>that.
>>
>> It seems to me that the mistake here is seeing multiple modes of
>> operations for the cpsw. There are not actually many, there is one
>> usage, and then there is what you can and cannot offload.
>CPSW has in fact 2 modes of operation, different FIFO usage/lookup
>entry(it's
>called ALE in the current driver) by-pass(which is used in dual emac
>for
>example) and other features. Again Grygorii is better suited to answer
>the
>exact differences.
>> The basic
>> premise with switchdev and DSA (which uses switchdev) is that each
>> user-facing port of your switch needs to work as if it were a normal
>> Ethernet NIC, that is what you call dual-MAC I believe. Then, when
>you
>> create a bridge and you enslave those ports into the bridge, you need
>to
>> have forwarding done in hardware between these two ports when the
>> SMAC/DMAC are not for the host/CPU/management interface and you must
>> simultaneously still have the host have the ability to send/receive
>> traffic through the bridge device.
>Yes dual emac does that. But dual emac configures the port facing VLAN
>to the
>CPU port as well. So dual emac splits and uses 2 interfaces. VLAN 1 is
>configured on port1 + CPU port and VLAN 2 is confired on port 2 + CPU
>port
>That's exactly what the current RFC does as well, with the addition of
>registering a sw0p0 (i'll explain why later on this mail)
>A little more detail on the issue we are having. On my description
>sw0p0 -> CPU port, sw0p1 -> port 1 sw0p2 -> port 2. sw0p1/sw0p2 are the
>ports
>that have PHYs attached.
>
>When we start in the new switchdev mode all interfaces are added to
>VLAN 0
>so CPU port + port1 + port2 are all in the same VLAN group. In that
>case sw0p1
>and sw0p2 are working as you describe. So those 2 interfaces can
>send/receive
>traffic normally which matches the switchdev case.
>
>When we add them on a bridge(let's say br0), VLAN1(or any default
>bridge VLAN)
>is now configured on sw0p1 and sw0p2 but *not* on the CPU port.
>From this point on the whole fuunctionality just collapses. The switch
>will
>work and offload traffic between sw0p1/sw0p2 but the bridge won't be
>able to
>get an ip address (since VLAN1 is not a member of the CPU port and the
>packet
>gets dropped).
>IGMPv2/V3 messages will never reach the br_multicast.c code to trigger
>switchdev and configure the MDBs on the ports. i am prety sure there
>are other
>fail scenarios which i haven't discovered already, but those 2 are the
>most
>basic ones. If we add VLAN1 on the CPU port, everything works as
>intended of
>course.
>
>That's the reason we registered sw0p0 as the CPU port. It can't do any
>"real"
>traffic, but you can configure the CPU port independantly and not be
>forced to
>do an OR on every VLAN add/delete grouping the CPU port with your port
>command.
>The TL;DR version of this is that the switch is working exactly as
>switchdev is
>expecting offloading traffic to the hardware when possible as long as
>the CPU
>port is member of the proper VLANs
>
>Petr's patch solves this for us
>(9c86ce2c1ae337fc10568a12aea812ed03de8319).
>We can now do "bridge vlan add dev br0 vid 100 pvid untagged self" and
>decide
>when to add the CPU port or not.
>
>There are still a couple of cases that are not covered though, if we
>don't
>register the CPU port. We cant decide when to forward multicast
>traffic on the CPU port if a join hasn't been sent from br0.
>So let's say you got 2 hosts doing multicast and for whatever reason
>the host
>wants to see that traffic.
>With the CPU port present you can do a
>"bridge mdb add dev br0 port sw0p0 grp 239.1.1.1 permanent" which will
>offload
>the traffic to the CPU port and thus the host. If this goes away we are
>forced
>to send a join.
Thanks for the detailed explanation. Somehow I was under the impression that cpsw had the ability, through specific DMA descriptor bits to direct traffic towards one external port or another and conversely, have that information from the HW when receiving packets. What you describe is exactly the same problem we have in DSA when the switch advertises DSA_TAG_PROTO_NONE where only VLAN tags could help differentiate traffic from external ports. At some point there was a discuss of making DSA_TAG_PROTO_NONE automatically create one VLAN per port but this is a good source for other problems...
Looking forward to your follow-up patch series!
--
Florian
^ permalink raw reply
* [PATCH bpf-next 2/2] bpf: btf: Ensure t->type == 0 for BTF_KIND_FWD
From: Martin KaFai Lau @ 2018-06-02 16:06 UTC (permalink / raw)
To: netdev; +Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20180602160651.3960897-1-kafai@fb.com>
The t->type in BTF_KIND_FWD is not used. It must be 0.
This patch ensures that and also adds a test case in test_btf.c
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
---
kernel/bpf/btf.c | 21 ++++++++++++++++++++-
tools/testing/selftests/bpf/test_btf.c | 22 ++++++++++++++++++++++
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 84ad532f2854..8653ab004c73 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -1286,8 +1286,27 @@ static struct btf_kind_operations ptr_ops = {
.seq_show = btf_ptr_seq_show,
};
+static s32 btf_fwd_check_meta(struct btf_verifier_env *env,
+ const struct btf_type *t,
+ u32 meta_left)
+{
+ if (btf_type_vlen(t)) {
+ btf_verifier_log_type(env, t, "vlen != 0");
+ return -EINVAL;
+ }
+
+ if (t->type) {
+ btf_verifier_log_type(env, t, "type != 0");
+ return -EINVAL;
+ }
+
+ btf_verifier_log_type(env, t, NULL);
+
+ return 0;
+}
+
static struct btf_kind_operations fwd_ops = {
- .check_meta = btf_ref_type_check_meta,
+ .check_meta = btf_fwd_check_meta,
.resolve = btf_df_resolve,
.check_member = btf_df_check_member,
.log_details = btf_ref_type_log,
diff --git a/tools/testing/selftests/bpf/test_btf.c b/tools/testing/selftests/bpf/test_btf.c
index fd8246e84149..3619f3023088 100644
--- a/tools/testing/selftests/bpf/test_btf.c
+++ b/tools/testing/selftests/bpf/test_btf.c
@@ -1242,6 +1242,28 @@ static struct btf_raw_test raw_tests[] = {
.err_str = "Invalid btf_info",
},
+{
+ .descr = "fwd test. t->type != 0\"",
+ .raw_types = {
+ /* int */ /* [1] */
+ BTF_TYPE_INT_ENC(0, BTF_INT_SIGNED, 0, 32, 4),
+ /* fwd type */ /* [2] */
+ BTF_TYPE_ENC(0, BTF_INFO_ENC(BTF_KIND_FWD, 0, 0), 1),
+ BTF_END_RAW,
+ },
+ .str_sec = "",
+ .str_sec_size = sizeof(""),
+ .map_type = BPF_MAP_TYPE_ARRAY,
+ .map_name = "fwd_test_map",
+ .key_size = sizeof(int),
+ .value_size = sizeof(int),
+ .key_type_id = 1,
+ .value_type_id = 1,
+ .max_entries = 4,
+ .btf_load_err = true,
+ .err_str = "type != 0",
+},
+
}; /* struct btf_raw_test raw_tests[] */
static const char *get_next_str(const char *start, const char *end)
--
2.9.5
^ permalink raw reply related
* [PATCH bpf-next 1/2] bpf: btf: Check array t->size
From: Martin KaFai Lau @ 2018-06-02 16:06 UTC (permalink / raw)
To: netdev; +Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team
This patch ensures array's t->size is 0.
The array size is decided by its individual elem's size and the
number of elements. Hence, t->size is not used and
it must be 0.
A test case is added to test_btf.c
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
---
kernel/bpf/btf.c | 5 +++++
tools/testing/selftests/bpf/test_btf.c | 23 +++++++++++++++++++++++
2 files changed, 28 insertions(+)
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 3d20aa1f4b54..84ad532f2854 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -1342,6 +1342,11 @@ static s32 btf_array_check_meta(struct btf_verifier_env *env,
return -EINVAL;
}
+ if (t->size) {
+ btf_verifier_log_type(env, t, "size != 0");
+ return -EINVAL;
+ }
+
/* Array elem type and index type cannot be in type void,
* so !array->type and !array->index_type are not allowed.
*/
diff --git a/tools/testing/selftests/bpf/test_btf.c b/tools/testing/selftests/bpf/test_btf.c
index 35064df688c1..fd8246e84149 100644
--- a/tools/testing/selftests/bpf/test_btf.c
+++ b/tools/testing/selftests/bpf/test_btf.c
@@ -1179,6 +1179,29 @@ static struct btf_raw_test raw_tests[] = {
},
{
+ .descr = "array test. t->size != 0\"",
+ .raw_types = {
+ /* int */ /* [1] */
+ BTF_TYPE_INT_ENC(0, BTF_INT_SIGNED, 0, 32, 4),
+ /* int[16] */ /* [2] */
+ BTF_TYPE_ENC(0, BTF_INFO_ENC(BTF_KIND_ARRAY, 0, 0), 1),
+ BTF_ARRAY_ENC(1, 1, 16),
+ BTF_END_RAW,
+ },
+ .str_sec = "",
+ .str_sec_size = sizeof(""),
+ .map_type = BPF_MAP_TYPE_ARRAY,
+ .map_name = "array_test_map",
+ .key_size = sizeof(int),
+ .value_size = sizeof(int),
+ .key_type_id = 1,
+ .value_type_id = 1,
+ .max_entries = 4,
+ .btf_load_err = true,
+ .err_str = "size != 0",
+},
+
+{
.descr = "int test. invalid int_data",
.raw_types = {
BTF_TYPE_ENC(0, BTF_INFO_ENC(BTF_KIND_INT, 0, 0), 4),
--
2.9.5
^ permalink raw reply related
* Re: [PATCH 10/18] rhashtable: remove rhashtable_walk_peek()
From: Herbert Xu @ 2018-06-02 15:48 UTC (permalink / raw)
To: NeilBrown; +Cc: Thomas Graf, netdev, linux-kernel, Tom Herbert
In-Reply-To: <152782824964.30340.6329146982899668633.stgit@noble>
On Fri, Jun 01, 2018 at 02:44:09PM +1000, NeilBrown wrote:
> This function has a somewhat confused behavior that is not properly
> described by the documentation.
> Sometimes is returns the previous object, sometimes it returns the
> next one.
> Sometimes it changes the iterator, sometimes it doesn't.
>
> This function is not currently used and is not worth keeping, so
> remove it.
>
> A future patch will introduce a new function with a
> simpler interface which can meet the same need that
> this was added for.
>
> Signed-off-by: NeilBrown <neilb@suse.com>
Please keep Tom Herbert in the loop. IIRC he had an issue with
this patch.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/4] RFC CPSW switchdev mode
From: Andrew Lunn @ 2018-06-02 14:08 UTC (permalink / raw)
To: Grygorii Strashko
Cc: Ilias Apalodimas, netdev, ivan.khoronzhuk, nsekhar, jiri, ivecera,
francois.ozog, yogeshs, spatton
In-Reply-To: <4277c55c-bea2-1061-35e9-62d1d0f60d28@ti.com>
On Fri, Jun 01, 2018 at 04:29:08PM -0500, Grygorii Strashko wrote:
> Hi Ilias,
> Second, Thanks a lot for your great work. I'm still testing it with different
> use cases and trying to consolidate my reply for all questions.
>
> All, thanks for your comments.
Hi Grygorii
Something i've said to Ilias already. I would recommend you don't try
to cover all your uses cases with the first version. Keep it simple
and clean, don't do anything controversial and get it merged. Then add
more features one by one. We can then discuss any odd ball features
while being able to look at the complete system, driver, switchdev and
the network stack.
Andrew
^ permalink raw reply
* Donation!!!
From: Mr Mikhail Fridman @ 2018-06-02 11:52 UTC (permalink / raw)
To: Recipients
Charitable Donation for you, Respond for further directives.
Mr. Mikhail Fridman
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH V2 mlx5-next 0/2] Mellanox, mlx5 new device events
From: David Miller @ 2018-06-02 13:07 UTC (permalink / raw)
To: saeedm; +Cc: jgg, netdev, linux-rdma, leonro
In-Reply-To: <a6385f91ca1611184391b1949f26f531ae812911.camel@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Sat, 2 Jun 2018 00:17:37 +0000
> On Fri, 2018-06-01 at 17:13 -0700, saeedm@mellanox.com wrote:
>> Hey Dave, this series was meant to go to mlx5-next tree as stated in
>> the cover letter and patches titles "[PATCH V2 mlx5-next 0/2]".
>>
>> It is ok you applied those patches to net-next this time, but for
>> next
>> time I would like to apply them myself to mlx5-next and send a clean
>> pull request later to both rdma and net trees.
>
> Sorry please ignore, I just saw that this was sorted out .. :).
> Thanks A lot !
>
>> Is there a way for me to mark them as delegated in patchwork ?
>> I see that i have "update Properties" option in patchwork but i don't
>> know how to use it or whether I am allowed to do anything with it.
>
> It would be great if we can mark such patches in patchwork though..
I really don't like it when others adjust patchwork state on me.
Florian Fainelli did it for a brief time for some of his own patches
and it caused a lot of confusion for me, so I asked him to stop.
Let's just make sure that the Subject line says mlx5-next or whatever
instead of net-next and I'll be mindful in such situations.
Thanks.
^ permalink raw reply
* Re: [PATCH 00/20] Netfilter/IPVS updates for net-next
From: David Miller @ 2018-06-02 13:04 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20180602002259.4024-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Sat, 2 Jun 2018 02:22:39 +0200
> The following patchset contains Netfilter/IPVS updates for your net-next
> tree, the most relevant things in this batch are:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Pulled, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox