* Re: pull-request: bpf-next 2018-10-21
From: David Miller @ 2018-10-22 4:12 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <20181021192426.22776-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Sun, 21 Oct 2018 21:24:26 +0200
> The following pull-request contains BPF updates for your *net-next* tree.
>
> The main changes are:
...
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
Pulled, thanks Daniel.
^ permalink raw reply
* RE: [PATCH v2 1/2] dt-bindings: net: add MDIO bus multiplexer driven by a regmap device
From: Pankaj Bansal @ 2018-10-22 4:22 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn; +Cc: netdev@vger.kernel.org
In-Reply-To: <HE1PR0402MB33233F0E876E2091DFD9C9D0F1F80@HE1PR0402MB3323.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Pankaj Bansal
> Sent: Thursday, October 18, 2018 10:00 AM
> To: Florian Fainelli <f.fainelli@gmail.com>; Andrew Lunn <andrew@lunn.ch>
> Cc: netdev@vger.kernel.org
> Subject: RE: [PATCH v2 1/2] dt-bindings: net: add MDIO bus multiplexer driven by
> a regmap device
>
> Hi Florian
>
> > -----Original Message-----
> > From: Florian Fainelli [mailto:f.fainelli@gmail.com]
> > Sent: Sunday, October 7, 2018 11:32 PM
> > To: Pankaj Bansal <pankaj.bansal@nxp.com>; Andrew Lunn
> > <andrew@lunn.ch>
> > Cc: netdev@vger.kernel.org
> > Subject: Re: [PATCH v2 1/2] dt-bindings: net: add MDIO bus multiplexer
> > driven by a regmap device
> >
> >
> >
> > On 10/07/18 11:24, Pankaj Bansal wrote:
> > > Add support for an MDIO bus multiplexer controlled by a regmap
> > > device, like an FPGA.
> > >
> > > Tested on a NXP LX2160AQDS board which uses the "QIXIS" FPGA
> > > attached to the i2c bus.
> > >
> > > Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
> > > ---
> > >
> > > Notes:
> > > V2:
> > > - Fixed formatting error caused by using space instead of tab
> > > - Add newline between property list and subnode
> > > - Add newline between two subnodes
> > >
> > > .../bindings/net/mdio-mux-regmap.txt | 95 ++++++++++++++++++
> > > 1 file changed, 95 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/net/mdio-mux-regmap.txt
> > > b/Documentation/devicetree/bindings/net/mdio-mux-regmap.txt
> > > new file mode 100644
> > > index 000000000000..88ebac26c1c5
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/net/mdio-mux-regmap.txt
> > > @@ -0,0 +1,95 @@
> > > +Properties for an MDIO bus multiplexer controlled by a regmap
> > > +
> > > +This is a special case of a MDIO bus multiplexer. A regmap device,
> > > +like an FPGA, is used to control which child bus is connected. The
> > > +mdio-mux node must be a child of the device that is controlled by a
> regmap.
> > > +The driver currently only supports devices with upto 32-bit registers.
> >
> > I would omit any sort of details about Linux constructs designed to
> > support specific needs (e.g: regmap) as well as putting driver
> > limitations into a binding document because it really ought to be restricted to
> describing hardware.
> >
>
> Actually the platform driver mdio-mux-regmap.c, is generalization of mdio-mux-
> mmioreg.c As such, it doesn't describe any new hardware, so no new properties
> are described by it.
> The only new property is compatible field.
> I don't know how to describe this driver otherwise. Can you please help?
I further thought about it. mdio-mux-regmap.c is not meant to control a specific device.
It is meant to control some registers of parent device. Therefore, IMO this should not be a
Platform driver and there should not be any "compatible" property to which this driver is associated.
Rather this driver should expose the APIs, which should be called by parent devices' driver.
What is your thought on this ?
>
> > > +
> > > +Required properties in addition to the generic multiplexer properties:
> > > +
> > > +- compatible : string, must contain "mdio-mux-regmap"
> > > +
> > > +- reg : integer, contains the offset of the register that controls the bus
> > > + multiplexer. it can be 32 bit number.
> >
> > Technically it could be any "reg" property size, the only requirement
> > is that it must be of the appropriate size with respect to what the
> > parent node of this "mdio-mux-regmap" node has, determined by #address-
> cells/#size-cells width.
>
> We are reading only single cell of this property using "of_propert_read_u32".
> That is why I put the size in this.
>
> >
> > > +
> > > +- mux-mask : integer, contains an 32 bit mask that specifies which
> > > + bits in the register control the actual bus multiplexer. The
> > > + 'reg' property of each child mdio-mux node must be constrained by
> > > + this mask.
> >
> > Same thing here.
>
> We are reading only single cell of this property using "of_propert_read_u32".
> That is why I put the size in this.
>
> >
> > Since this is a MDIO mux, I would invite you to specify what the
> > correct #address-cells/#size-cells values should be (1, and 0
> > respectively as your example correctly shows).
> >
>
> I will mention #address-cells/#size-cells values
>
> > > +
> > > +Example:
> > > +
> > > +The FPGA node defines a i2c connected FPGA with a register space of
> > > +0x30
> > bytes.
> > > +For the "EMI2" MDIO bus, register 0x54 (BRDCFG4) controls the mux
> > > +on that
> > bus.
> > > +A bitmask of 0x07 means that bits 0, 1 and 2 (bit 0 is lsb) are the
> > > +bits on
> > > +BRDCFG4 that control the actual mux.
> > > +
> > > +i2c@2000000 {
> > > + compatible = "fsl,vf610-i2c";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + reg = <0x0 0x2000000 0x0 0x10000>;
> > > + interrupts = <0 34 0x4>; // Level high type
> > > + clock-names = "i2c";
> > > + clocks = <&clockgen 4 7>;
> > > + fsl-scl-gpio = <&gpio2 15 0>;
> > > + status = "okay";
> > > +
> > > + /* The FPGA node */
> > > + fpga@66 {
> > > + compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c";
> > > + reg = <0x66>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + mdio1_mux@54 {
> > > + compatible = "mdio-mux-regmap", "mdio-mux";
> > > + mdio-parent-bus = <&emdio2>; /* MDIO bus */
> > > + reg = <0x54>; /* BRDCFG4 */
> > > + mux-mask = <0x07>; /* EMI2_MDIO */
> > > + #address-cells=<1>;
> > > + #size-cells = <0>;
> > > +
> > > + mdio1_ioslot1@0 { // Slot 1
> > > + reg = <0x00>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + phy1@1 {
> > > + reg = <1>;
> > > + compatible = "ethernet-phy-
> > id0210.7441";
> > > + };
> > > +
> > > + phy1@0 {
> > > + reg = <0>;
> > > + compatible = "ethernet-phy-
> > id0210.7441";
> > > + };
> > > + };
> > > +
> > > + mdio1_ioslot2@1 { // Slot 2
> > > + reg = <0x01>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + };
> > > +
> > > + mdio1_ioslot3@2 { // Slot 3
> > > + reg = <0x02>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + };
> > > + };
> > > + };
> > > +};
> > > +
> > > + /* The parent MDIO bus. */
> > > + emdio2: mdio@0x8B97000 {
> > > + compatible = "fsl,fman-memac-mdio";
> > > + reg = <0x0 0x8B97000 0x0 0x1000>;
> > > + device_type = "mdio";
> > > + little-endian;
> > > +
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > >
> >
> > --
> > Florian
^ permalink raw reply
* Re: [rtnetlink] Potential bug in Linux (rt)netlink code
From: Henning Rogge @ 2018-10-22 5:22 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
In-Reply-To: <cae45e94-72f5-3aac-8c91-8e71facc3482@fkie.fraunhofer.de>
Does anyone else have an idea how to debug this problem?
Henning Rogge
Am 15.10.2018 um 07:25 schrieb Henning Rogge:
> Am 12.10.2018 um 20:51 schrieb Stephen Hemminger:
>> On Fri, 12 Oct 2018 09:30:40 +0200
>> Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:
>>
>>> Hi,
>>>
>>> I am working on a self-written routing agent
>>> (https://github.com/OLSR/OONF) and am stuck on a problem with netlink
>>> that I cannot explain with an userspace error.
>>>
>>> I am using a netlink socket for setting routes
>>> (RTM_NEWROUTE/RTM_DELROUTE), querying the kernel for the current routes
>>> in the database (via a RTM_GETROUTE dump) and for getting multicast
>>> messages for ongoing routing changes.
>>>
>>> After a few netlink messages I get to the point where the kernel just
>>> does not responst to a RTM_NEWROUTE. No error, no answer, despite the
>>> NLM_F_ACK flag set)... but sometime when (during shutdown of the routing
>>> agent) the program sends another route command (most times a
>>> RTM_DELROUTE) I get a single netlink packet with a "successful" response
>>> for both the "missing" RTM_NEWROUTE and one for the new RTM DELROUTE
>>> sequence number.
>>>
>>> I am testing two routing agents, each of them in a systemd-nspawn based
>>> container connected over a bridge on the host system on a current Debian
>>> Testing (kernel 4.18.0-1-amd64).
>>>
>>> I am directly using the netlink sockets, without any other userspace
>>> library in between.
>>>
>>> I have checked the hexdumps of a couple of netlink messages (including
>>> the ones just before the bug happens) by hand and they seem to be okay.
>>>
>>> When I tried to add a "netlink listener" socket for futher debugging (ip
>>> link add nlmon0 type nlmon) the problem vanished until I removed the
>>> listener socket again.
>>>
>>> Any ideas how to debug this problem? Unfortunately I have no short
>>> example program to trigger the bug... I have rarely seen the problem for
>>> years (once every couple of months), but until a few days ago I never
>>> managed to reproduce it.
>>>
>>> Henning Rogge
>>
>> Are you reading the responses to your requests? If you don't read
>> the response, the socket will get flow blocked.
>
> Yes, I do...
>
> all netlink sockets the program uses are constantly watched for traffic
> coming from the kernel (with an epoll()-based event loop, no edge-trigger).
>
> I even have a rate limitation towards the kernel, only sending a
> "pagesize" full of netlink data towards the kernel, then waiting for the
> reply before sending more (I had the blocking problem a few years ago
> when experimenting with LOTS of routes).
>
> Henning Rogge
Henning Rogge
--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Zanderstrasse 5, 53177 Bonn, Germany
Telefon +49 228 50212-469
mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
^ permalink raw reply
* Re: [PATCH] net/mlx5: allocate enough space in
From: Dan Carpenter @ 2018-10-22 5:23 UTC (permalink / raw)
To: Or Gerlitz
Cc: Saeed Mahameed, Paul Blakey, kernel-janitors, Linux Netdev List,
Leon Romanovsky
In-Reply-To: <CAJ3xEMjZ8WQu2cj_QgU9RoZvUZu7X2Szh6-Si6KZU-qMBFqwHQ@mail.gmail.com>
On Sun, Oct 21, 2018 at 01:56:26PM +0300, Or Gerlitz wrote:
> I will re-post your patch, this time to netdev since the original
> commit is there
> and so should be the fix, thanks for reporting/fixing!
I didn't realize it had been posted to netdev already so I deliberately
left that off the CC. If Dave hasn't applied the original (he probably
has now because he is so quick) then it's fine by me if you fold them
together.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] net/mlx5: allocate enough space in
From: Or Gerlitz @ 2018-10-22 6:18 UTC (permalink / raw)
To: Dan Carpenter
Cc: Saeed Mahameed, Paul Blakey, kernel-janitors, Linux Netdev List,
Leon Romanovsky
In-Reply-To: <20181022052336.fr4kvd7idba5d2om@mwanda>
On Mon, Oct 22, 2018 at 8:23 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
> On Sun, Oct 21, 2018 at 01:56:26PM +0300, Or Gerlitz wrote:
> > I will re-post your patch, this time to netdev since the original
> > commit is there
> > and so should be the fix, thanks for reporting/fixing!
>
> I didn't realize it had been posted to netdev already so I deliberately
> left that off the CC. If Dave hasn't applied the original (he probably
you didn't post it to netdev, I don't see how he could have got it
> has now because he is so quick) then it's fine by me if you fold them
> together.
>
> regards,
> dan carpenter
>
^ permalink raw reply
* Re: [PATCH 0/2] Mark expected switch fall-throughs and fix missing break
From: Jes Sorensen @ 2018-10-22 14:36 UTC (permalink / raw)
To: Gustavo A. R. Silva, linux-kernel
Cc: Kalle Valo, linux-wireless, David S. Miller, netdev
In-Reply-To: <cover.1540208577.git.gustavo@embeddedor.com>
On 10/22/18 7:49 AM, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, this patchset aims
> to mark multiple switch cases where we are expecting to fall through.
>
> Also, the second patch in this series fixes a missing break in switch.
Enabling that sounds like a great way to inflict pain and suffering.
Not a big deal to put that in the code, the second patch looks fine though.
Jes
^ permalink raw reply
* Re: [PATCH] net/mlx5: Allocate enough space for the FDB sub-namespaces
From: Or Gerlitz @ 2018-10-22 6:19 UTC (permalink / raw)
To: Or Gerlitz; +Cc: David Miller, Saeed Mahameed, Linux Netdev List, Dan Carpenter
In-Reply-To: <1540119949-1748-1-git-send-email-ogerlitz@mellanox.com>
On Sun, Oct 21, 2018 at 2:47 PM Or Gerlitz <ogerlitz@mellanox.com> wrote:
>
> From: Dan Carpenter <dan.carpenter@oracle.com>
>
> FDB_MAX_CHAIN is three. We wanted to allocate enough memory to hold four
> structs but there are missing parentheses so we only allocate enough
> memory for three structs and the first byte of the fourth one.
>
> Fixes: 328edb499f99 ("net/mlx5: Split FDB fast path prio to multiple namespaces")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Dave, I forgot to mark it as net-next, so here I am saying that..
> ---
> drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> index 67ba4c9..9d73eb9 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> @@ -2470,7 +2470,7 @@ static int init_fdb_root_ns(struct mlx5_flow_steering *steering)
> return -ENOMEM;
>
> steering->fdb_sub_ns = kzalloc(sizeof(steering->fdb_sub_ns) *
> - FDB_MAX_CHAIN + 1, GFP_KERNEL);
> + (FDB_MAX_CHAIN + 1), GFP_KERNEL);
> if (!steering->fdb_sub_ns)
> return -ENOMEM;
>
> --
> 2.3.7
>
^ permalink raw reply
* Re: [PATCH] net/mlx5: allocate enough space in
From: Dan Carpenter @ 2018-10-22 6:41 UTC (permalink / raw)
To: Or Gerlitz
Cc: Saeed Mahameed, Paul Blakey, kernel-janitors, Linux Netdev List,
Leon Romanovsky
In-Reply-To: <CAJ3xEMj5NPo-BJ2t_xno+R5O6R0_i3CU0Dig3_Wakop0xLa8CQ@mail.gmail.com>
On Mon, Oct 22, 2018 at 09:18:43AM +0300, Or Gerlitz wrote:
> On Mon, Oct 22, 2018 at 8:23 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> >
> > On Sun, Oct 21, 2018 at 01:56:26PM +0300, Or Gerlitz wrote:
> > > I will re-post your patch, this time to netdev since the original
> > > commit is there
> > > and so should be the fix, thanks for reporting/fixing!
> >
> > I didn't realize it had been posted to netdev already so I deliberately
> > left that off the CC. If Dave hasn't applied the original (he probably
>
> you didn't post it to netdev, I don't see how he could have got it
>
I meant commit 328edb499f99 ("net/mlx5: Split FDB fast path prio to
multiple namespaces"). It turns out that Dave has applied that, but I
was expecting to see his S-o-B on it.
It's hard for me to know which tree patches are applied to.
Also I see that I screwed up the subject. Thanks for fixing that.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] bpf: btf: Fix a missing-check bug
From: Martin Lau @ 2018-10-22 15:40 UTC (permalink / raw)
To: Wenwen Wang
Cc: Kangjie Lu, Alexei Starovoitov, Daniel Borkmann,
open list:BPF (Safe dynamic programs and tools),
open list:BPF (Safe dynamic programs and tools)
In-Reply-To: <1539988191-13973-1-git-send-email-wang6495@umn.edu>
On Fri, Oct 19, 2018 at 05:29:51PM -0500, Wenwen Wang wrote:
> In btf_parse(), the header of the user-space btf data 'btf_data' is firstly
> parsed and verified through btf_parse_hdr(). In btf_parse_hdr(), the header
> is copied from user-space 'btf_data' to kernel-space 'btf->hdr' and then
> verified. If no error happens during the verification process, the whole
> data of 'btf_data', including the header, is then copied to 'data' in
> btf_parse(). It is obvious that the header is copied twice here. More
> importantly, no check is enforced after the second copy to make sure the
> headers obtained in these two copies are same. Given that 'btf_data'
> resides in the user space, a malicious user can race to modify the header
> between these two copies. By doing so, the user can inject inconsistent
> data, which can cause undefined behavior of the kernel and introduce
> potential security risk.
>
> To avoid the above issue, this patch rewrites the header after the second
> copy, using 'btf->hdr', which is obtained in the first copy.
Acked-by: Martin KaFai Lau <kafai@fb.com>
^ permalink raw reply
* Re: [PATCH] bpf: btf: Fix a missing-check bug
From: Y Song @ 2018-10-22 15:57 UTC (permalink / raw)
To: wang6495; +Cc: kjlu, Alexei Starovoitov, Daniel Borkmann, netdev, LKML
In-Reply-To: <1539988191-13973-1-git-send-email-wang6495@umn.edu>
On Fri, Oct 19, 2018 at 3:30 PM Wenwen Wang <wang6495@umn.edu> wrote:
>
> In btf_parse(), the header of the user-space btf data 'btf_data' is firstly
> parsed and verified through btf_parse_hdr(). In btf_parse_hdr(), the header
> is copied from user-space 'btf_data' to kernel-space 'btf->hdr' and then
> verified. If no error happens during the verification process, the whole
> data of 'btf_data', including the header, is then copied to 'data' in
> btf_parse(). It is obvious that the header is copied twice here. More
> importantly, no check is enforced after the second copy to make sure the
> headers obtained in these two copies are same. Given that 'btf_data'
> resides in the user space, a malicious user can race to modify the header
> between these two copies. By doing so, the user can inject inconsistent
> data, which can cause undefined behavior of the kernel and introduce
> potential security risk.
>
> To avoid the above issue, this patch rewrites the header after the second
> copy, using 'btf->hdr', which is obtained in the first copy.
>
> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
> ---
> kernel/bpf/btf.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 138f030..2a85f91 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -2202,6 +2202,9 @@ static struct btf *btf_parse(void __user *btf_data, u32 btf_data_size,
> goto errout;
> }
>
> + memcpy(data, &btf->hdr,
> + min_t(u32, btf->hdr.hdr_len, sizeof(btf->hdr)));
Could you restructure the code to memcpy the header followed by copying
the rest of btf_data with copy_from_user? This way, each byte is only
copied once.
Could you add some comments right before memcpy so later people will know
why we implement this way?
> +
> err = btf_parse_str_sec(env);
> if (err)
> goto errout;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] rtlwifi: btcoex: remove set but not used variable 'ppsc'
From: YueHaibing @ 2018-10-22 7:51 UTC (permalink / raw)
To: Ping-Ke Shih, Kalle Valo, Larry Finger, Colin Ian King,
Nathan Chancellor
Cc: YueHaibing, linux-wireless, netdev, kernel-janitors
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c: In function 'halbtc_leave_lps':
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:295:21: warning:
variable 'ppsc' set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c: In function 'halbtc_enter_lps':
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:318:21: warning:
variable 'ppsc' set but not used [-Wunused-but-set-variable]
It never used since introduction in
commit aa45a673b291 ("rtlwifi: btcoexist: Add new mini driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 6fbf884..d748aab 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -292,11 +292,9 @@ bool halbtc_send_bt_mp_operation(struct btc_coexist *btcoexist, u8 op_code,
static void halbtc_leave_lps(struct btc_coexist *btcoexist)
{
struct rtl_priv *rtlpriv;
- struct rtl_ps_ctl *ppsc;
bool ap_enable = false;
rtlpriv = btcoexist->adapter;
- ppsc = rtl_psc(rtlpriv);
btcoexist->btc_get(btcoexist, BTC_GET_BL_WIFI_AP_MODE_ENABLE,
&ap_enable);
@@ -315,11 +313,9 @@ static void halbtc_leave_lps(struct btc_coexist *btcoexist)
static void halbtc_enter_lps(struct btc_coexist *btcoexist)
{
struct rtl_priv *rtlpriv;
- struct rtl_ps_ctl *ppsc;
bool ap_enable = false;
rtlpriv = btcoexist->adapter;
- ppsc = rtl_psc(rtlpriv);
btcoexist->btc_get(btcoexist, BTC_GET_BL_WIFI_AP_MODE_ENABLE,
&ap_enable);
^ permalink raw reply related
* [PATCHv3 iproute2-next] ip/geneve: fix ttl inherit behavior
From: Hangbin Liu @ 2018-10-22 7:46 UTC (permalink / raw)
To: netdev
Cc: Stephen Hemminger, David Ahern, Phil Sutter, Michal Kubecek,
Hangbin Liu
In-Reply-To: <1539846110-11607-1-git-send-email-liuhangbin@gmail.com>
Currently when we add geneve with "ttl inherit", we only set ttl to 0, which
is actually use whatever default value instead of inherit the inner protocol's
ttl value.
To make a difference with ttl inherit and ttl == 0, we add an attribute
IFLA_GENEVE_TTL_INHERIT in kernel commit 52d0d404d39dd ("geneve: add ttl
inherit support"). Now let's use "ttl inherit" to inherit the inner
protocol's ttl, and use "ttl auto" to means "use whatever default value",
the same behavior with ttl == 0.
v2:
1) remove IFLA_GENEVE_TTL_INHERIT defination in if_link.h as it's already
updated.
2) Still use addattr8() so we can enable/disable ttl inherit, as Michal
suggested.
v3: Update man page
Reported-by: Jianlin Shi <jishi@redhat.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
ip/iplink_geneve.c | 20 +++++++++++++-------
man/man8/ip-link.8.in | 4 +++-
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/ip/iplink_geneve.c b/ip/iplink_geneve.c
index 26e70ff..c417842 100644
--- a/ip/iplink_geneve.c
+++ b/ip/iplink_geneve.c
@@ -34,7 +34,7 @@ static void print_explain(FILE *f)
"Where: VNI := 0-16777215\n"
" ADDR := IP_ADDRESS\n"
" TOS := { NUMBER | inherit }\n"
- " TTL := { 1..255 | inherit }\n"
+ " TTL := { 1..255 | auto | inherit }\n"
" LABEL := 0-1048575\n"
);
}
@@ -94,7 +94,9 @@ static int geneve_parse_opt(struct link_util *lu, int argc, char **argv,
NEXT_ARG();
check_duparg(&attrs, IFLA_GENEVE_TTL, "ttl", *argv);
- if (strcmp(*argv, "inherit") != 0) {
+ if (strcmp(*argv, "inherit") == 0) {
+ addattr8(n, 1024, IFLA_GENEVE_TTL_INHERIT, 1);
+ } else if (strcmp(*argv, "auto") != 0) {
if (get_unsigned(&uval, *argv, 0))
invarg("invalid TTL", *argv);
if (uval > 255)
@@ -265,12 +267,16 @@ static void geneve_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
}
}
- if (tb[IFLA_GENEVE_TTL])
- ttl = rta_getattr_u8(tb[IFLA_GENEVE_TTL]);
- if (is_json_context() || ttl)
- print_uint(PRINT_ANY, "ttl", "ttl %u ", ttl);
- else
+ if (tb[IFLA_GENEVE_TTL_INHERIT] &&
+ rta_getattr_u8(tb[IFLA_GENEVE_TTL_INHERIT])) {
print_string(PRINT_FP, NULL, "ttl %s ", "inherit");
+ } else if (tb[IFLA_GENEVE_TTL]) {
+ ttl = rta_getattr_u8(tb[IFLA_GENEVE_TTL]);
+ if (is_json_context() || ttl)
+ print_uint(PRINT_ANY, "ttl", "ttl %u ", ttl);
+ else
+ print_string(PRINT_FP, NULL, "ttl %s ", "auto");
+ }
if (tb[IFLA_GENEVE_TOS])
tos = rta_getattr_u8(tb[IFLA_GENEVE_TOS]);
diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
index ecbbd4f..4489162 100644
--- a/man/man8/ip-link.8.in
+++ b/man/man8/ip-link.8.in
@@ -1190,7 +1190,9 @@ the following additional arguments are supported:
.sp
.BI ttl " TTL"
-- specifies the TTL value to use in outgoing packets.
+- specifies the TTL value to use in outgoing packets. "0" or "auto" means
+use whatever default value, "inherit" means inherit the inner protocol's
+ttl. Default option is "0".
.sp
.BI tos " TOS"
--
2.5.5
^ permalink raw reply related
* Re: CRC errors between mvneta and macb
From: Willy Tarreau @ 2018-10-22 16:34 UTC (permalink / raw)
To: Richard Genoud
Cc: linux-kernel, Thomas Petazzoni, Antoine Tenart, Gregory CLEMENT,
Yelena Krivosheev, Maxime Chevallier, Nicolas Ferre, netdev
In-Reply-To: <31385a3b-2196-94d0-7f4f-52e37ee07a28@sorico.fr>
On Mon, Oct 22, 2018 at 05:15:21PM +0200, Richard Genoud wrote:
> After analyzing the ethernet frame on the Davicom PHY's output (pin
> TX+), I find out that the FCS errors occurs when the ethernet preamble
> is longer than 56bits. (something like 58 or 60 bits)
>
> To say this in another way, instead of having 28 times 1-0 followed by
> the SFD (10101011), I see 29 or 30 times 1-0 followed by the SFD.
> (sometimes 29, sometimes 30)
>
>
> Should a longer preamble be considered as an FCS error ? It seems a
> little harsh since the point of the preamble is to synchronize the frame.
That indeed seems a bit strange considering that you're not supposed to
know what is before the preamble so it would very well contain random
noise looking a lot like alteranted bits.
> I don't know what the 802.3 standard says about that.
Just found it :-)
https://www.trincoll.edu/Academics/MajorsAndMinors/Engineering/Documents/IEEE%20Standard%20for%20Ethernet.pdf
Page 132, #7.2.3.2 :
The DTE is required to supply at least 56 bits of preamble in
order to satisfy system requirements. System components consume
preamble bits in order to perform their functions. The number
of preamble bits sourced ensures an adequate number of bits are
provided to each system component to correctly implement its
function.
So that totally makes sense since the purpose is to enable signal
detection at the hardware leve, hence the problem definitely is on
the receiver in your case.
Willy
^ permalink raw reply
* Re: [PATCH 1/1] net: dsa: legacy: simplify getting .driver_data
From: Florian Fainelli @ 2018-10-22 17:01 UTC (permalink / raw)
To: Wolfram Sang, linux-kernel
Cc: linux-renesas-soc, Andrew Lunn, Vivien Didelot, David S. Miller,
netdev
In-Reply-To: <20181021200105.2414-2-wsa+renesas@sang-engineering.com>
On 10/21/18 1:01 PM, Wolfram Sang wrote:
> We should get 'driver_data' from 'struct device' directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH 2/9] net: dsa: qca8k: simplify getting .driver_data
From: Florian Fainelli @ 2018-10-22 17:01 UTC (permalink / raw)
To: Wolfram Sang, linux-kernel
Cc: linux-renesas-soc, Andrew Lunn, Vivien Didelot, David S. Miller,
netdev
In-Reply-To: <20181021200021.1693-3-wsa+renesas@sang-engineering.com>
On 10/21/18 1:00 PM, Wolfram Sang wrote:
> We should get 'driver_data' from 'struct device' directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH 9/9] net: phy: mdio-mux-bcm-iproc: simplify getting .driver_data
From: Florian Fainelli @ 2018-10-22 17:02 UTC (permalink / raw)
To: Wolfram Sang, linux-kernel
Cc: linux-renesas-soc, Andrew Lunn, David S. Miller, Ray Jui,
Scott Branden, Jon Mason, bcm-kernel-feedback-list, netdev,
linux-arm-kernel
In-Reply-To: <20181021200021.1693-10-wsa+renesas@sang-engineering.com>
On 10/21/18 1:00 PM, Wolfram Sang wrote:
> We should get 'driver_data' from 'struct device' directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH 0/9] net: simplify getting .driver_data
From: Florian Fainelli @ 2018-10-22 17:05 UTC (permalink / raw)
To: Wolfram Sang, linux-kernel
Cc: linux-renesas-soc, linux-omap, linux-arm-kernel, netdev
In-Reply-To: <20181021200021.1693-1-wsa+renesas@sang-engineering.com>
On 10/21/18 1:00 PM, Wolfram Sang wrote:
> I got tired of fixing this in Renesas drivers manually, so I took the big
> hammer. Remove this cumbersome code pattern which got copy-pasted too much
> already:
>
> - struct platform_device *pdev = to_platform_device(dev);
> - struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
> + struct ep93xx_keypad *keypad = dev_get_drvdata(dev);
>
> A branch, tested by buildbot, can be found here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git coccinelle/get_drvdata
>
> I have been asked if it couldn't be done for dev_set_drvdata as well. I checked
> it and did not find one occasion where it could be simplified like this. Not
> much of a surprise because driver_data is usually set in probe() functions
> which access struct platform_device in many other ways.
>
> I am open for other comments, suggestions, too, of course.
Would it make sense to annotate platform_get_drvdata() with __deprecated
or something like that to prevent further uses by driver authors?
Do you mind submitting the cocci-script to the maintainers of the
coccinelle scripts that way it can be included and run by automated
tools? Thanks!
>
> Here is the cocci-script I created:
>
> @@
> struct device* d;
> identifier pdev;
> expression *ptr;
> @@
> (
> - struct platform_device *pdev = to_platform_device(d);
> |
> - struct platform_device *pdev;
> ...
> - pdev = to_platform_device(d);
> )
> <... when != pdev
> - &pdev->dev
> + d
> ...>
>
> ptr =
> - platform_get_drvdata(pdev)
> + dev_get_drvdata(d)
>
> <... when != pdev
> - &pdev->dev
> + d
> ...>
>
> Kind regards,
>
> Wolfram
>
>
> Wolfram Sang (9):
> net: dsa: bcm_sf2: simplify getting .driver_data
> net: dsa: qca8k: simplify getting .driver_data
> net: ethernet: cadence: macb_main: simplify getting .driver_data
> net: ethernet: davicom: dm9000: simplify getting .driver_data
> net: ethernet: smsc: smc91x: simplify getting .driver_data
> net: ethernet: ti: cpsw: simplify getting .driver_data
> net: ethernet: ti: davinci_emac: simplify getting .driver_data
> net: ethernet: wiznet: w5300: simplify getting .driver_data
> net: phy: mdio-mux-bcm-iproc: simplify getting .driver_data
>
> drivers/net/dsa/bcm_sf2.c | 6 ++----
> drivers/net/dsa/qca8k.c | 6 ++----
> drivers/net/ethernet/cadence/macb_main.c | 6 ++----
> drivers/net/ethernet/davicom/dm9000.c | 6 ++----
> drivers/net/ethernet/smsc/smc91x.c | 3 +--
> drivers/net/ethernet/ti/cpsw.c | 6 ++----
> drivers/net/ethernet/ti/davinci_emac.c | 6 ++----
> drivers/net/ethernet/wiznet/w5300.c | 6 ++----
> drivers/net/phy/mdio-mux-bcm-iproc.c | 6 ++----
> 9 files changed, 17 insertions(+), 34 deletions(-)
>
--
Florian
^ permalink raw reply
* [PATCH 1/2] arm64: dts: stratix10: Support for Ethernet Jumbo frame
From: thor.thayer @ 2018-10-22 17:29 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue, joabreu, davem, dinguyen,
robh+dt, mark.rutland
Cc: devicetree, netdev, linux-kernel, Thor Thayer
From: Thor Thayer <thor.thayer@linux.intel.com>
Properly specify the RX and TX FIFO size which is important
for Jumbo frames.
Update the max-frame-size to support Jumbo frames.
Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
---
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 6 ++++++
arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
index d033da401c26..8a2641c742ae 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -137,6 +137,8 @@
reset-names = "stmmaceth", "stmmaceth-ocp";
clocks = <&clkmgr STRATIX10_EMAC0_CLK>;
clock-names = "stmmaceth";
+ tx-fifo-depth = <16384>;
+ rx-fifo-depth = <16384>;
status = "disabled";
};
@@ -150,6 +152,8 @@
reset-names = "stmmaceth", "stmmaceth-ocp";
clocks = <&clkmgr STRATIX10_EMAC1_CLK>;
clock-names = "stmmaceth";
+ tx-fifo-depth = <16384>;
+ rx-fifo-depth = <16384>;
status = "disabled";
};
@@ -163,6 +167,8 @@
reset-names = "stmmaceth", "stmmaceth-ocp";
clocks = <&clkmgr STRATIX10_EMAC2_CLK>;
clock-names = "stmmaceth";
+ tx-fifo-depth = <16384>;
+ rx-fifo-depth = <16384>;
status = "disabled";
};
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts b/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
index 6edc4fa9fd42..7c661753bfaf 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
@@ -76,7 +76,7 @@
phy-mode = "rgmii";
phy-handle = <&phy0>;
- max-frame-size = <3800>;
+ max-frame-size = <9000>;
mdio0 {
#address-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] net: stmmac: Set OWN bit for jumbo frames
From: thor.thayer @ 2018-10-22 17:29 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue, joabreu, davem, dinguyen,
robh+dt, mark.rutland
Cc: devicetree, netdev, linux-kernel, Thor Thayer
In-Reply-To: <1540229352-26010-1-git-send-email-thor.thayer@linux.intel.com>
From: Thor Thayer <thor.thayer@linux.intel.com>
Ping with Jumbo packet does not reply and get a watchdog timeout
[ 46.059616] ------------[ cut here ]------------
[ 46.064268] NETDEV WATCHDOG: eth0 (socfpga-dwmac): transmit queue 0 timed out
[ 46.071471] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:461 dev_watchdog+0x2cc/0x2d8
[ 46.079708] Modules linked in:
[ 46.082761] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.18.0-00115-gc262be665854-dirty #264
[ 46.091082] Hardware name: SoCFPGA Stratix 10 SoCDK (DT)
[ 46.096377] pstate: 20000005 (nzCv daif -PAN -UAO)
[ 46.101152] pc : dev_watchdog+0x2cc/0x2d8
[ 46.105149] lr : dev_watchdog+0x2cc/0x2d8
[ 46.109144] sp : ffff00000800bd80
[ 46.112447] x29: ffff00000800bd80 x28: ffff80007a9b4940
[ 46.117744] x27: 00000000ffffffff x26: ffff80007aa183b0
[ 46.123040] x25: 0000000000000001 x24: 0000000000000140
[ 46.128336] x23: ffff80007aa1839c x22: ffff80007aa17fb0
[ 46.133632] x21: ffff80007aa18000 x20: ffff0000091a7000
[ 46.138927] x19: 0000000000000000 x18: ffffffffffffffff
[ 46.144223] x17: 0000000000000000 x16: 0000000000000000
[ 46.149519] x15: ffff0000091a96c8 x14: 07740775076f0720
[ 46.154814] x13: 07640765076d0769 x12: 0774072007300720
[ 46.160110] x11: 0765077507650775 x10: 0771072007740769
[ 46.165406] x9 : 076d0773076e0761 x8 : 077207740720073a
[ 46.170702] x7 : 072907630761076d x6 : ffff80007ff9a0c0
[ 46.175997] x5 : ffff80007ff9a0c0 x4 : 0000000000000002
[ 46.181293] x3 : 0000000000000000 x2 : ffff0000091ac180
[ 46.186589] x1 : e6a742ebe628e800 x0 : 0000000000000000
[ 46.191885] Call trace:
[ 46.194326] dev_watchdog+0x2cc/0x2d8
[ 46.197980] call_timer_fn+0x20/0x78
[ 46.201544] expire_timers+0xa4/0xb0
[ 46.205108] run_timer_softirq+0xe4/0x198
[ 46.209107] __do_softirq+0x114/0x210
[ 46.212760] irq_exit+0xd0/0xd8
[ 46.215895] __handle_domain_irq+0x60/0xb0
[ 46.219977] gic_handle_irq+0x58/0xa8
[ 46.223628] el1_irq+0xb0/0x128
[ 46.226761] arch_cpu_idle+0x10/0x18
[ 46.230326] do_idle+0x1d4/0x288
[ 46.233544] cpu_startup_entry+0x24/0x28
[ 46.237457] secondary_start_kernel+0x17c/0x1c0
[ 46.241971] ---[ end trace 57048cd1372cd828 ]---
Inspection of queue showed Jumbo packets were not sent out.
The ring Jumbo packet function needs to set the OWN bit so
the packet is sent.
Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/ring_mode.c b/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
index a7ffc73fffe8..c5fd9483bd96 100644
--- a/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
+++ b/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
@@ -91,7 +91,7 @@ static int jumbo_frm(void *p, struct sk_buff *skb, int csum)
tx_q->tx_skbuff_dma[entry].is_jumbo = true;
desc->des3 = cpu_to_le32(des2 + BUF_SIZE_4KiB);
stmmac_prepare_tx_desc(priv, desc, 1, nopaged_len, csum,
- STMMAC_RING_MODE, 0, true, skb->len);
+ STMMAC_RING_MODE, 1, true, skb->len);
}
tx_q->cur_tx = entry;
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH v2 00/10] udp: implement GRO support
From: Paolo Abeni @ 2018-10-22 9:41 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: Network Development, Willem de Bruijn, steffen.klassert
In-Reply-To: <CAF=yD-Jt_Tx-gsCy0ygxm8Wgx_6bxbbi3+4NgjULqQ9gK-xang@mail.gmail.com>
Hi all,
On Sun, 2018-10-21 at 16:05 -0400, Willem de Bruijn wrote:
> On Fri, Oct 19, 2018 at 10:30 AM Paolo Abeni <pabeni@redhat.com> wrote:
> >
> > This series implements GRO support for UDP sockets, as the RX counterpart
> > of commit bec1f6f69736 ("udp: generate gso with UDP_SEGMENT").
> > The core functionality is implemented by the second patch, introducing a new
> > sockopt to enable UDP_GRO, while patch 3 implements support for passing the
> > segment size to the user space via a new cmsg.
> > UDP GRO performs a socket lookup for each ingress packets and aggregate datagram
> > directed to UDP GRO enabled sockets with constant l4 tuple.
> >
> > UDP GRO packets can land on non GRO-enabled sockets, e.g. due to iptables NAT
> > rules, and that could potentially confuse existing applications.
>
> Good catch.
>
> > The solution adopted here is to de-segment the GRO packet before enqueuing
> > as needed. Since we must cope with packet reinsertion after de-segmentation,
> > the relevant code is factored-out in ipv4 and ipv6 specific helpers and exposed
> > to UDP usage.
> >
> > While the current code can probably be improved, this safeguard ,implemented in
> > the patches 4-7, allows future enachements to enable UDP GSO offload on more
> > virtual devices eventually even on forwarded packets.
> >
> > The last 4 for patches implement some performance and functional self-tests,
> > re-using the existing udpgso infrastructure. The problematic scenario described
> > above is explicitly tested.
>
> This looks awesome! Impressive testing, too.
>
> A few comments in the individual patches, mostly minor.
Thank you for the in-depth review! (in the WE ;)
I'll try to address the comments on each patch individually.
In the end I rushed a bit this RFC, because the misdirection issue (and
the tentative fix) bothered me more than a bit: I wanted to check I was
not completely out-of-track.
Cheers,
Paolo
^ permalink raw reply
* Re: [PATCH] mm: convert totalram_pages, totalhigh_pages and managed_pages to atomic.
From: Michal Hocko @ 2018-10-22 18:11 UTC (permalink / raw)
To: Arun KS
Cc: Mike Snitzer, Benjamin Herrenschmidt, Kemi Wang,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, J. Bruce Fields,
linux-sctp-u79uwXL29TY76Z2rM5mHXA, Paul Mackerras, Pavel Machek,
Christoph Lameter, K. Y. Srinivasan, Sumit Semwal,
David (ChunMing) Zhou, Petr Tesarik, Michael Ellerman,
ceph-devel-u79uwXL29TY76Z2rM5mHXA, James E.J. Bottomley,
kasan-dev-/JYPxA39Uh5TLH3MbocFFw, Marcos Paulo de Souza,
Steven J. Hill, David Rientjes, Anthony Yznaga, Daniel Vacek,
Roman Gushchin, Len Brown <len.b
In-Reply-To: <1540229092-25207-1-git-send-email-arunks-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Mon 22-10-18 22:53:22, Arun KS wrote:
> Remove managed_page_count_lock spinlock and instead use atomic
> variables.
I assume this has been auto-generated. If yes, it would be better to
mention the script so that people can review it and regenerate for
comparision. Such a large change is hard to review manually.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH bpf-next] selftests/bpf: enable (uncomment) all tests in test_libbpf.sh
From: Quentin Monnet @ 2018-10-22 10:00 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Alexei Starovoitov, Daniel Borkmann, netdev, oss-drivers
In-Reply-To: <20181021230438.10481e7f@redhat.com>
2018-10-21 23:04 UTC+0200 ~ Jesper Dangaard Brouer <brouer@redhat.com>
> On Sun, 21 Oct 2018 16:37:08 +0100
> Quentin Monnet <quentin.monnet@netronome.com> wrote:
>
>> 2018-10-21 11:57 UTC+0200 ~ Jesper Dangaard Brouer <brouer@redhat.com>
>>> On Sat, 20 Oct 2018 23:00:24 +0100
>>> Quentin Monnet <quentin.monnet@netronome.com> wrote:
>>>
>>
>> [...]
>>
>>>> --- a/tools/testing/selftests/bpf/test_libbpf.sh
>>>> +++ b/tools/testing/selftests/bpf/test_libbpf.sh
>>>> @@ -33,17 +33,11 @@ trap exit_handler 0 2 3 6 9
>>>>
>>>> libbpf_open_file test_l4lb.o
>>>>
>>>> -# TODO: fix libbpf to load noinline functions
>>>> -# [warning] libbpf: incorrect bpf_call opcode
>>>> -#libbpf_open_file test_l4lb_noinline.o
>>>> +libbpf_open_file test_l4lb_noinline.o
>>>>
>>>> -# TODO: fix test_xdp_meta.c to load with libbpf
>>>> -# [warning] libbpf: test_xdp_meta.o doesn't provide kernel version
>>>> -#libbpf_open_file test_xdp_meta.o
>>>> +libbpf_open_file test_xdp_meta.o
>>>>
>>>> -# TODO: fix libbpf to handle .eh_frame
>>>> -# [warning] libbpf: relocation failed: no section(10)
>>>> -#libbpf_open_file ../../../../samples/bpf/tracex3_kern.o
>>>> +libbpf_open_file ../../../../samples/bpf/tracex3_kern.o
>>>
>>> I don't like the ../../../../samples/bpf/ reference (even-through I
>>> added this TODO), as the kselftests AFAIK support installing the
>>> selftests and then this tests will fail.
>>> Maybe we can find another example kern.o file?
>>> (which isn't compiled with -target bpf)
>>
>> Hi Jesper, yeah maybe making the test rely on something from samples/bpf
>> instead of just the selftests/bpf directory is not a good idea. But
>> there is no program compiled without the "-target-bpf" in that
>> directory. What we could do is explicitly compile one without the flag
>> in the Makefile, as in the patch below, but I am not sure that doing so
>> is acceptable?
>
> I think it makes sense to have a test program compiled without the
> "-target-bpf", as that will happen for users. And I guess we can add
> some more specific test that are related to "-target-bpf".
Alright, I can repost my second version that takes a test out of the
default target for building BPF programs, after the merge window.
>> Or should tests for libbpf have a directory of their own,
>> with another Makefile?
>
> Hmm, I'm not sure about that idea.
>
> I did plan by naming the test "libbpf_open_file", what we add more
> libbpf_ prefixed tests to the test_libbpf.sh script, which should
> cover more aspects of the _base_ libbpf functionality.
>
>> Another question regarding the test with test_xdp_meta.o: does the fix I
>> suggested (setting a version in the .C file) makes sense, or did you
>> leave this test for testing someday that libbpf would be able to open
>> even programs that do not set a version (in which case this is still not
>> the case if program type is not provided, and in fact my fix ruins
>> everything? :s).
>
> Well, yes. I was hinting if we should relax the version requirement
> for e.g. XDP BPF progs.
This is already the case. What happens for this test is that we never
tell libbpf that this program is XDP, we just ask it to open the ELF
file and the whole time libbpf treats it as a program of type
BPF_PROG_TYPE_UNSPEC. So we can fix the BPF source (by adding a version)
or we can fix test_libbpf_open.c (to tell libbpf this is XDP), but I
don't believe there is anything to add to libbpf in that regard. I think
we could simply remove the test on test_xdp_meta.o from test_libbpf.h,
actually. What is you opinion?
Thanks,
Quentin
^ permalink raw reply
* Re: CRC errors between mvneta and macb
From: Andrew Lunn @ 2018-10-22 18:19 UTC (permalink / raw)
To: Richard Genoud
Cc: Willy Tarreau, linux-kernel, Thomas Petazzoni, Antoine Tenart,
Gregory CLEMENT, Yelena Krivosheev, Maxime Chevallier,
Nicolas Ferre, netdev
In-Reply-To: <31385a3b-2196-94d0-7f4f-52e37ee07a28@sorico.fr>
> I dug more on the subject, and I think I found what Marvell's PHY/MAC
> doesn't like.
Hi Richard
What PHY is being used?
> After analyzing the ethernet frame on the Davicom PHY's output (pin
> TX+), I find out that the FCS errors occurs when the ethernet preamble
> is longer than 56bits. (something like 58 or 60 bits)
Some Marvell PHYs have a register bit which might be of interest: Page
2, register 16, bit 6.
0 = Pad odd nibble preambles in copper receive packets.
1 = Pass as is and do not pad odd nibble preambles in
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net: ethernet: ti: cpsw: unsync mcast entries while switch promisc mode
From: Grygorii Strashko @ 2018-10-22 18:26 UTC (permalink / raw)
To: Ivan Khoronzhuk, davem; +Cc: linux-omap, netdev, linux-kernel
In-Reply-To: <20181019202541.10278-1-ivan.khoronzhuk@linaro.org>
On 10/19/18 3:25 PM, Ivan Khoronzhuk wrote:
> After flushing all mcast entries from the table, the ones contained in
> mc list of ndev are not restored when promisc mode is toggled off,
> because they are considered as synched with ALE, thus, in order to
> restore them after promisc mode - reset syncing info. This fix
> touches only switch mode devices, including single port boards
> like Beagle Bone.
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> ---
So, this is follow up fix for
176b23 net: ethernet: ti: cpsw: fix lost of mcast packets while rx_mode update
because I can't reproduce it otherwise.
Could you update description and re-send pls.?
>
> Based on net-nex/master
> and is logical continuation of the
> https://lore.kernel.org/patchwork/patch/1001633/
>
> drivers/net/ethernet/ti/cpsw.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index 226be2a56c1f..f7753b240ced 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -640,6 +640,7 @@ static void cpsw_set_promiscious(struct net_device *ndev, bool enable)
>
> /* Clear all mcast from ALE */
> cpsw_ale_flush_multicast(ale, ALE_ALL_PORTS, -1);
> + __dev_mc_unsync(ndev, NULL);
>
> /* Flood All Unicast Packets to Host port */
> cpsw_ale_control_set(ale, 0, ALE_P0_UNI_FLOOD, 1);
>
--
regards,
-grygorii
^ permalink raw reply
* Re: [RFC PATCH v2 02/10] udp: implement GRO for plain UDP sockets.
From: Paolo Abeni @ 2018-10-22 10:13 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: Network Development, Willem de Bruijn, steffen.klassert
In-Reply-To: <CAF=yD-Jr4_x6KrNQugEtOuVfA5c_jtvJEhCizmyAJM0OLR-g_g@mail.gmail.com>
On Sun, 2018-10-21 at 16:06 -0400, Willem de Bruijn wrote:
> On Fri, Oct 19, 2018 at 10:30 AM Paolo Abeni <pabeni@redhat.com> wrote:
> >
> > This is the RX counterpart of commit bec1f6f69736 ("udp: generate gso
> > with UDP_SEGMENT"). When UDP_GRO is enabled, such socket is also
> > eligible for GRO in the rx path: UDP segments directed to such socket
> > are assembled into a larger GSO_UDP_L4 packet.
> >
> > The core UDP GRO support is enabled with setsockopt(UDP_GRO).
> >
> > Initial benchmark numbers:
> >
> > Before:
> > udp rx: 1079 MB/s 769065 calls/s
> >
> > After:
> > udp rx: 1466 MB/s 24877 calls/s
> >
> >
> > This change introduces a side effect in respect to UDP tunnels:
> > after a UDP tunnel creation, now the kernel performs a lookup per ingress
> > UDP packet, while before such lookup happened only if the ingress packet
> > carried a valid internal header csum.
> >
> > v1 -> v2:
> > - use a new option to enable UDP GRO
> > - use static keys to protect the UDP GRO socket lookup
> >
> > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > ---
> > include/linux/udp.h | 3 +-
> > include/uapi/linux/udp.h | 1 +
> > net/ipv4/udp.c | 7 +++
> > net/ipv4/udp_offload.c | 109 +++++++++++++++++++++++++++++++--------
> > net/ipv6/udp_offload.c | 6 +--
> > 5 files changed, 98 insertions(+), 28 deletions(-)
> >
> > diff --git a/include/linux/udp.h b/include/linux/udp.h
> > index a4dafff407fb..f613b329852e 100644
> > --- a/include/linux/udp.h
> > +++ b/include/linux/udp.h
> > @@ -50,11 +50,12 @@ struct udp_sock {
> > __u8 encap_type; /* Is this an Encapsulation socket? */
> > unsigned char no_check6_tx:1,/* Send zero UDP6 checksums on TX? */
> > no_check6_rx:1,/* Allow zero UDP6 checksums on RX? */
> > - encap_enabled:1; /* This socket enabled encap
> > + encap_enabled:1, /* This socket enabled encap
> > * processing; UDP tunnels and
> > * different encapsulation layer set
> > * this
> > */
> > + gro_enabled:1; /* Can accept GRO packets */
> >
> > /*
> > * Following member retains the information to create a UDP header
> > * when the socket is uncorked.
> > diff --git a/include/uapi/linux/udp.h b/include/uapi/linux/udp.h
> > index 09502de447f5..30baccb6c9c4 100644
> > --- a/include/uapi/linux/udp.h
> > +++ b/include/uapi/linux/udp.h
> > @@ -33,6 +33,7 @@ struct udphdr {
> > #define UDP_NO_CHECK6_TX 101 /* Disable sending checksum for UDP6X */
> > #define UDP_NO_CHECK6_RX 102 /* Disable accpeting checksum for UDP6 */
> > #define UDP_SEGMENT 103 /* Set GSO segmentation size */
> > +#define UDP_GRO 104 /* This socket can receive UDP GRO packets */
> >
> > /* UDP encapsulation types */
> > #define UDP_ENCAP_ESPINUDP_NON_IKE 1 /* draft-ietf-ipsec-nat-t-ike-00/01 */
> > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> > index 9fcb5374e166..3c277378814f 100644
> > --- a/net/ipv4/udp.c
> > +++ b/net/ipv4/udp.c
> > @@ -115,6 +115,7 @@
> > #include "udp_impl.h"
> > #include <net/sock_reuseport.h>
> > #include <net/addrconf.h>
> > +#include <net/udp_tunnel.h>
> >
> > struct udp_table udp_table __read_mostly;
> > EXPORT_SYMBOL(udp_table);
> > @@ -2459,6 +2460,12 @@ int udp_lib_setsockopt(struct sock *sk, int level, int optname,
> > up->gso_size = val;
> > break;
> >
> > + case UDP_GRO:
> > + if (valbool)
> > + udp_tunnel_encap_enable(sk->sk_socket);
> > + up->gro_enabled = valbool;
>
> The socket lock is not held here, so multiple updates to
> up->gro_enabled and the up->encap_enabled and the static branch can
> race. Syzkaller is adept at generating those.
Good catch. I was fooled by the current existing code. I think there
are potentially similar issues for UDP_ENCAP, UDPLITE_SEND_CSCOV, ...
Since the rx path don't take it anymore and we don't risk starving, I
think we should could/always acquire the socket lock on setsockopt,
wdyt?
> > +#define UDO_GRO_CNT_MAX 64
> > +static struct sk_buff *udp_gro_receive_segment(struct list_head *head,
> > + struct sk_buff *skb)
> > +{
> > + struct udphdr *uh = udp_hdr(skb);
> > + struct sk_buff *pp = NULL;
> > + struct udphdr *uh2;
> > + struct sk_buff *p;
> > +
> > + /* requires non zero csum, for simmetry with GSO */
>
> symmetry
Thanks ;)
Paolo
^ 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