Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH 00/14] Modify action API for implementing lockless actions
From: Davide Caratti @ 2018-05-16 18:10 UTC (permalink / raw)
  To: Roman Mashak, Vlad Buslov
  Cc: Jamal Hadi Salim, Linux Kernel Network Developers, David Miller,
	Cong Wang, Jiri Pirko, pablo, kadlec, fw, ast, Daniel Borkmann,
	Eric Dumazet, kliteyn
In-Reply-To: <85efib33kr.fsf@mojatatu.com>

On Wed, 2018-05-16 at 13:36 -0400, Roman Mashak wrote:
> Vlad Buslov <vladbu@mellanox.com> writes:
> 
> > On Wed 16 May 2018 at 14:38, Roman Mashak <mrv@mojatatu.com> wrote:
> > > On Wed, May 16, 2018 at 2:43 AM, Vlad Buslov <vladbu@mellanox.com> wrote:
> > > > > > > > I'm trying to run tdc, but keep getting following error even on clean
> > > > > > > > branch without my patches:
> > > > > > > 
> > > > > > > Vlad, not sure if you saw my email:
> > > > > > > Apply Roman's patch and try again
> > > > > > > 
> > > > > > > https://marc.info/?l=linux-netdev&m=152639369112020&w=2
> > > > > > > 
> > > > > > > cheers,
> > > > > > > jamal
> > > > > > 
> > > > > > With patch applied I get following error:
> > > > > > 
> > > > > > Test 7d50: Add skbmod action to set destination mac
> > > > > > exit: 255 0
> > > > > > dst MAC address <11:22:33:44:55:66>
> > > > > > RTNETLINK answers: No such file or directory
> > > > > > We have an error talking to the kernel
> > > > > > 
> > > > > 
> > > > > You may actually have broken something with your patches in this case.
> > > > 
> > > > Results is for net-next without my patches.
> > > 
> > > Do you have skbmod compiled in kernel or as a module?
> > 
> > Thanks, already figured out that default config has some actions
> > disabled.
> > Have more errors now. Everything related to ife:
> > 
> > Test 7682: Create valid ife encode action with mark and pass control
> > exit: 255 0
> > IFE type 0xED3E
> > RTNETLINK answers: No such file or directory
> > We have an error talking to the kernel
> > 
> > Test ef47: Create valid ife encode action with mark and pipe control
> > exit: 255 0
> > IFE type 0xED3E
> > RTNETLINK answers: No space left on device
> > We have an error talking to the kernel
> > 
> > Test df43: Create valid ife encode action with mark and continue control
> > exit: 255 0
> > IFE type 0xED3E
> > RTNETLINK answers: No space left on device
> > We have an error talking to the kernel
> > 
> > Test e4cf: Create valid ife encode action with mark and drop control
> > exit: 255 0
> > IFE type 0xED3E
> > RTNETLINK answers: No space left on device
> > We have an error talking to the kernel
> > 
> > Test ccba: Create valid ife encode action with mark and reclassify control
> > exit: 255 0
> > IFE type 0xED3E
> > RTNETLINK answers: No space left on device
> > We have an error talking to the kernel
> > 
> > Test a1cf: Create valid ife encode action with mark and jump control
> > exit: 255 0
> > IFE type 0xED3E
> > RTNETLINK answers: No space left on device
> > We have an error talking to the kernel
> > 
> > ...
> > 
> > 
> 
> Please make sure you have these in your kernel config:
> 
> CONFIG_NET_ACT_IFE=y
> CONFIG_NET_IFE_SKBMARK=m
> CONFIG_NET_IFE_SKBPRIO=m
> CONFIG_NET_IFE_SKBTCINDEX=m
> 
> For tdc to run all the tests, it is assumed that all the supported tc
> actions/filters are enabled and compiled.
hello,

looking at ife.json, it seems that we have at least 4 typos in
'teardown'. 

It does

$TC actions flush action skbedit

in place of 

$TC actions flush action ife

On my fedora28 (with fedora28 kernel), fixing them made test 7682 return
'ok' (and all others in ife category, except ee94, 7ee0 and 0a7d).

regards,
-- 
davide

^ permalink raw reply

* Re: [PATCH net v2 0/3] net: dsa: bcm_sf2: CFP fixes
From: David Miller @ 2018-05-16 18:12 UTC (permalink / raw)
  To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, linux-kernel, opendmb
In-Reply-To: <20180515230125.25886-1-f.fainelli@gmail.com>

From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 15 May 2018 16:01:22 -0700

> This patch series fixes a number of usability issues with the SF2 Compact Field
> Processor code:
> 
> - we would not be properly bound checking the location when we let the kernel
>   automatically place rules with RX_CLS_LOC_ANY
> 
> - when using IPv6 rules and user space specifies a location identifier we
>   would be off by one in what the chain ID (within the Broadcom tag) indicates
> 
> - it would be possible to delete one of the two slices of an IPv6 while leaving
>   the other one programming leading to various problems

Series applied, thanks.

Queue up for -stable?

^ permalink raw reply

* Re: [Intel-wired-lan] [RFC PATCH bpf-next 00/12] AF_XDP, zero-copy support
From: Jeff Kirsher @ 2018-05-16 18:14 UTC (permalink / raw)
  To: Alexei Starovoitov, Björn Töpel
  Cc: willemdebruijn.kernel, daniel, ast, netdev, qi.z.zhang, mst,
	michael.lundkvist, intel-wired-lan, brouer, Björn Töpel,
	magnus.karlsson, magnus.karlsson
In-Reply-To: <20180516170427.7jq74odw62myg55x@ast-mbp>

[-- Attachment #1: Type: text/plain, Size: 3398 bytes --]

On Wed, 2018-05-16 at 10:04 -0700, Alexei Starovoitov wrote:
> On Tue, May 15, 2018 at 09:06:03PM +0200, Björn Töpel wrote:
> > 
> > Alexei had two concerns in conjunction with adding ZC support to
> > AF_XDP: show that the user interface holds and can deliver good
> > performance for ZC and that the driver interfaces for ZC are good.
> > We
> > think that this patch set shows that we have addressed the first
> > issue: performance is good and there is no change to the uapi. But
> > please take a look at the code and see if you like the ZC
> > interfaces
> > that was the second concern.
> 
> Looks like we're not on the same page with definition of 'uapi'.
> Here you're saying that patches demonstrate performance without
> a change to uapi, whereas patch 1 does remove rebind support
> which _is_ a change to uapi.
> That was exactly my concern with the previous set.
> 
> The other restrictions that are introduced in this patch set
> are actually ok:
> - like in patch 12: 'no redirect to an AF_XDP enabled XDP Tx ring'
>   this is fine, since this restriction can be lifted later without
>   breaking uapi
> - patch 11: 'No passing to the stack via XDP_PASS'
>   also fine, since can be addressed later.
> 
> > To do for this RFC to become a patch set:
> > 
> > * Implement dynamic creation and deletion of queues in the i40e
> > driver
> 
> can be deferred, no?
> 
> > * Properly splitting up the i40e changes
> 
> Imo patch 11 and 12 are reasonable in terms of size
> and reviewable as-is. I don't think they have to be split.
> Would be nice though.
>  
> > * Have the Intel NIC team review the i40e changes from at least an
> >   architecture point of view
> 
> As Alexander pointed out in patch 11, if you split it into
> separate file the changes to i40e core become pretty small and
> I think Intel folks (Jeff, Alexander, ...) will be ok if we merge
> this set via bpf-next tree asap and clean up, refactor, share
> more code with i40e core later.

I am fine with the i40e changes in this series go through the BPF tree,
since majority of the series is BPF changes.  We just need to address
Alex's comments on patch 11 & 12.

I only have 1-2 patches currently in my queue against i40e and they are
not affected by the changes in this series, so Dave should not have any
merge issues when pulling.

> > * Implement a more fair scheduling policy for multiple XSKs that
> > share
> >   an umem for TX. This can be combined with a batching API for
> >   xsk_umem_consume_tx.
> 
> can be deferred too?
> 
> I think the first 10 patches in this set is a hard dependency on i40e
> patches, so the whole thing have to reviewed and landed together.
> May be the first 5 patches can be applied already.
> 
> Anyway at this point I still think that removing AF_XDP and bpf
> xskmap
> from uapi is necessary before the merge window, unless this patch set
> (including i40e changes can land right now).
> Also I'd like to see another NIC vendor demonstrating RFC for ZC as
> well.
> The allocator api looks good and I don't anticipate issues, but still
> I think it's necessary to make sure that we're not adding i40e-only
> feature.
> 
> _______________________________________________
> Intel-wired-lan mailing list
> Intel-wired-lan@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply

* Re: [PATCH net-next v2] net: ethernet: ti: cpsw-phy-sel: check bus_find_device() ret value
From: David Miller @ 2018-05-16 18:13 UTC (permalink / raw)
  To: grygorii.strashko; +Cc: netdev, nsekhar, linux-kernel, linux-omap
In-Reply-To: <20180515233725.11882-1-grygorii.strashko@ti.com>

From: Grygorii Strashko <grygorii.strashko@ti.com>
Date: Tue, 15 May 2018 18:37:25 -0500

> This fixes klockworks warnings: Pointer 'dev' returned from call to
> function 'bus_find_device' at line 179 may be NULL and will be dereferenced
> at line 181.
> 
>     cpsw-phy-sel.c:179: 'dev' is assigned the return value from function 'bus_find_device'.
>     bus.c:342: 'bus_find_device' explicitly returns a NULL value.
>     cpsw-phy-sel.c:181: 'dev' is dereferenced by passing argument 1 to function 'dev_get_drvdata'.
>     device.h:1024: 'dev' is passed to function 'dev_get_drvdata'.
>     device.h:1026: 'dev' is explicitly dereferenced.
> 
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> [nsekhar@ti.com: add an error message, fix return path]
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> ---
> v2: use %pOF

Applied, thank you.

^ permalink raw reply

* Re: [PATCH net-next 0/3] net: Allow more drivers with COMPILE_TEST
From: David Miller @ 2018-05-16 18:15 UTC (permalink / raw)
  To: f.fainelli; +Cc: netdev, andrew, linux-kernel
In-Reply-To: <20180515234825.11240-1-f.fainelli@gmail.com>

From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 15 May 2018 16:48:22 -0700

> This patch series includes more drivers to be build tested with COMPILE_TEST
> enabled. This helps cover some of the issues I just ran into with missing
> a driver *sigh*.

Thank you for doing this.

Series applied.

^ permalink raw reply

* Re: [PATCH net v2 0/3] net: dsa: bcm_sf2: CFP fixes
From: Florian Fainelli @ 2018-05-16 18:15 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, andrew, vivien.didelot, linux-kernel, opendmb
In-Reply-To: <20180516.141218.827550466386531999.davem@davemloft.net>

On 05/16/2018 11:12 AM, David Miller wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Tue, 15 May 2018 16:01:22 -0700
> 
>> This patch series fixes a number of usability issues with the SF2 Compact Field
>> Processor code:
>>
>> - we would not be properly bound checking the location when we let the kernel
>>   automatically place rules with RX_CLS_LOC_ANY
>>
>> - when using IPv6 rules and user space specifies a location identifier we
>>   would be off by one in what the chain ID (within the Broadcom tag) indicates
>>
>> - it would be possible to delete one of the two slices of an IPv6 while leaving
>>   the other one programming leading to various problems
> 
> Series applied, thanks.
> 
> Queue up for -stable?

Yes please!
-- 
Florian

^ permalink raw reply

* Re: [PATCH net-next 0/3] net: Allow more drivers with COMPILE_TEST
From: David Miller @ 2018-05-16 18:17 UTC (permalink / raw)
  To: f.fainelli; +Cc: netdev, andrew, linux-kernel
In-Reply-To: <20180516.141514.1102545495330180859.davem@davemloft.net>

From: David Miller <davem@davemloft.net>
Date: Wed, 16 May 2018 14:15:14 -0400 (EDT)

> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Tue, 15 May 2018 16:48:22 -0700
> 
>> This patch series includes more drivers to be build tested with COMPILE_TEST
>> enabled. This helps cover some of the issues I just ran into with missing
>> a driver *sigh*.
> 
> Thank you for doing this.
> 
> Series applied.

Actually, I have to revert.

The FEC driver cannot be built tested without the appropriate platform
specific register set defines and x86-64 for example won't provide that.

drivers/net/ethernet/freescale/fec_main.c: In function ‘fec_restart’:
drivers/net/ethernet/freescale/fec_main.c:959:26: error: ‘FEC_RACC’ undeclared (first use in this function); did you mean ‘FEC_RXIC0’?
   val = readl(fep->hwp + FEC_RACC);
                          ^~~~~~~~
                          FEC_RXIC0
drivers/net/ethernet/freescale/fec_main.c:959:26: note: each undeclared identifier is reported only once for each function it appears in
drivers/net/ethernet/freescale/fec_main.c:968:38: error: ‘FEC_FTRL’ undeclared (first use in this function); did you mean ‘FEC_ECNTRL’?
   writel(PKT_MAXBUF_SIZE, fep->hwp + FEC_FTRL);
                                      ^~~~~~~~
                                      FEC_ECNTRL
 ...

^ permalink raw reply

* Re: [PATCH net v2 0/3] net: dsa: bcm_sf2: CFP fixes
From: David Miller @ 2018-05-16 18:18 UTC (permalink / raw)
  To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, linux-kernel, opendmb
In-Reply-To: <e88ff455-2072-c885-e64b-0f2bf91420a4@gmail.com>

From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 16 May 2018 11:15:37 -0700

> On 05/16/2018 11:12 AM, David Miller wrote:
>> Queue up for -stable?
> 
> Yes please!

Done.

^ permalink raw reply

* Re: [PATCH net-next 0/3] net: Allow more drivers with COMPILE_TEST
From: Florian Fainelli @ 2018-05-16 18:18 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, andrew, linux-kernel
In-Reply-To: <20180516.141738.494765267490482500.davem@davemloft.net>

On 05/16/2018 11:17 AM, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Wed, 16 May 2018 14:15:14 -0400 (EDT)
> 
>> From: Florian Fainelli <f.fainelli@gmail.com>
>> Date: Tue, 15 May 2018 16:48:22 -0700
>>
>>> This patch series includes more drivers to be build tested with COMPILE_TEST
>>> enabled. This helps cover some of the issues I just ran into with missing
>>> a driver *sigh*.
>>
>> Thank you for doing this.
>>
>> Series applied.
> 
> Actually, I have to revert.
> 
> The FEC driver cannot be built tested without the appropriate platform
> specific register set defines and x86-64 for example won't provide that.

Ah, yes, it built okay for ARM 32-bit, let me fix that.

> 
> drivers/net/ethernet/freescale/fec_main.c: In function ‘fec_restart’:
> drivers/net/ethernet/freescale/fec_main.c:959:26: error: ‘FEC_RACC’ undeclared (first use in this function); did you mean ‘FEC_RXIC0’?
>    val = readl(fep->hwp + FEC_RACC);
>                           ^~~~~~~~
>                           FEC_RXIC0
> drivers/net/ethernet/freescale/fec_main.c:959:26: note: each undeclared identifier is reported only once for each function it appears in
> drivers/net/ethernet/freescale/fec_main.c:968:38: error: ‘FEC_FTRL’ undeclared (first use in this function); did you mean ‘FEC_ECNTRL’?
>    writel(PKT_MAXBUF_SIZE, fep->hwp + FEC_FTRL);
>                                       ^~~~~~~~
>                                       FEC_ECNTRL
>  ...
> 


-- 
Florian

^ permalink raw reply

* [PATCH net] net/ipv4: Initialize proto and ports in flow struct
From: David Ahern @ 2018-05-16 18:18 UTC (permalink / raw)
  To: netdev; +Cc: roopa, David Ahern

Updating the FIB tracepoint for the recent change to allow rules using
the protocol and ports exposed a few places where the entries in the flow
struct are not initialized.

For __fib_validate_source add the call to fib4_rules_early_flow_dissect
since it is invoked for the input path. For netfilter, add the memset on
the flow struct to avoid future problems like this.

Fixes: bfff4862653b ("net: fib_rules: support for match on ip_proto, sport and dport")
Signed-off-by: David Ahern <dsahern@gmail.com>
---
 net/ipv4/fib_frontend.c           | 10 +++++++---
 net/ipv4/netfilter/ipt_rpfilter.c |  2 +-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index f05afaf3235c..58696b829065 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -326,10 +326,11 @@ static int __fib_validate_source(struct sk_buff *skb, __be32 src, __be32 dst,
 				 u8 tos, int oif, struct net_device *dev,
 				 int rpf, struct in_device *idev, u32 *itag)
 {
+	struct net *net = dev_net(dev);
+	struct flow_keys flkeys;
 	int ret, no_addr;
 	struct fib_result res;
 	struct flowi4 fl4;
-	struct net *net = dev_net(dev);
 	bool dev_match;
 
 	fl4.flowi4_oif = 0;
@@ -347,8 +348,11 @@ static int __fib_validate_source(struct sk_buff *skb, __be32 src, __be32 dst,
 	no_addr = idev->ifa_list == NULL;
 
 	fl4.flowi4_mark = IN_DEV_SRC_VMARK(idev) ? skb->mark : 0;
-
-	trace_fib_validate_source(dev, &fl4);
+	if (!fib4_rules_early_flow_dissect(net, skb, &fl4, &flkeys)) {
+		fl4.flowi4_proto = 0;
+		fl4.fl4_sport = 0;
+		fl4.fl4_dport = 0;
+	}
 
 	if (fib_lookup(net, &fl4, &res, 0))
 		goto last_resort;
diff --git a/net/ipv4/netfilter/ipt_rpfilter.c b/net/ipv4/netfilter/ipt_rpfilter.c
index fd01f13c896a..12843c9ef142 100644
--- a/net/ipv4/netfilter/ipt_rpfilter.c
+++ b/net/ipv4/netfilter/ipt_rpfilter.c
@@ -89,10 +89,10 @@ static bool rpfilter_mt(const struct sk_buff *skb, struct xt_action_param *par)
 			return true ^ invert;
 	}
 
+	memset(&flow, 0, sizeof(flow));
 	flow.flowi4_iif = LOOPBACK_IFINDEX;
 	flow.daddr = iph->saddr;
 	flow.saddr = rpfilter_get_saddr(iph->daddr);
-	flow.flowi4_oif = 0;
 	flow.flowi4_mark = info->flags & XT_RPFILTER_VALID_MARK ? skb->mark : 0;
 	flow.flowi4_tos = RT_TOS(iph->tos);
 	flow.flowi4_scope = RT_SCOPE_UNIVERSE;
-- 
2.11.0

^ permalink raw reply related

* Re: [PATCH net-next v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node
From: David Miller @ 2018-05-16 18:21 UTC (permalink / raw)
  To: f.fainelli
  Cc: netdev, andrew, vivien.didelot, nicolas.ferre, fugang.duan,
	sergei.shtylyov, peppe.cavallaro, alexandre.torgue, joabreu,
	grygorii.strashko, woojung.huh, UNGLinuxDriver, robh+dt,
	frowand.list, antoine.tenart, Tobias.Jordan, rmk+kernel,
	geert+renesas, thomas.petazzoni, niklas.soderlund+renesas,
	horms+renesas, muvarov, nsekhar, linux-kernel, linux-renesas-soc,
	linux-omap, linux-usb, devicetree
In-Reply-To: <20180515235619.27773-1-f.fainelli@gmail.com>

From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 15 May 2018 16:56:17 -0700

> This patch series updates of_mdiobus_register() such that when the device_node
> argument is NULL, it calls mdiobus_register() directly. This is consistent with
> the behavior of of_mdiobus_register() when CONFIG_OF=n.
> 
> I only converted the most obvious drivers, there are others that have a much
> less obvious behavior and specifically attempt to deal with CONFIG_ACPI.
> 
> Changes in v2:
> 
> - fixed build error in davincin_mdio.c (Grygorii)
> - reworked first patch a bit: commit message, subject and removed useless
>   code comment

Based upon Andrew's response to Geert's feedback, I'm applying this series.

Thanks.

^ permalink raw reply

* Re: [PATCH net-next v2 0/3] net: qualcomm: rmnet: Updates 2018-05-14
From: David Miller @ 2018-05-16 18:23 UTC (permalink / raw)
  To: subashab; +Cc: netdev, fengguang.wu
In-Reply-To: <1526431922-4132-1-git-send-email-subashab@codeaurora.org>

From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date: Tue, 15 May 2018 18:51:59 -0600

> Patch 1 adds tx_drops counter to more places.
> Patch 2 adds ethtool private stats support to make it easy to debug
> the checksum offload path.
> Patch 3 is a cleanup in command packet processing path.
> 
> v1->v2: Fix the incorrect if / else statement in
> rmnet_map_checksum_downlink_packet() and define rmnet_ethtool_ops
> as static as mentioned by kbuild test robot.

Series applied, thank you.

^ permalink raw reply

* [BUG] net: stmmac: dwmac-sun8i broken in linux-next
From: Corentin Labbe @ 2018-05-16 18:32 UTC (permalink / raw)
  To: Jose.Abreu-HKixBCOQz3hWk0Htik3J/w, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
	alexandre.torgue-qxv4g6HH51o, peppe.cavallaro-qxv4g6HH51o
  Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw

Hello

The dwmac-sun8i driver is broken in next-20180515, symptom are no RX and TX errors as shown by ifconfig:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.204  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 96:75:ff:0d:f6:d8  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 4956 (4.8 KiB)
        TX errors 118  dropped 0 overruns 0  carrier 0  collisions 0

Reverting the following commit made the driver working:
4dbbe8dde8485b89bce8bbbe7564337fd7eed69f ("net: stmmac: Add support for U32 TC filter using Flexible RX Parser")
5f0456b43140af9413397cc11d03d18b9f2fc2fc ("net: stmmac: Implement logic to automatically select HW Interface")

Note that reverting only 4dbbe8dde8485b89bce8bbbe7564337fd7eed69f lead to crash:
[   31.385110] Backtrace: 
[   31.387576] [<c0510cd4>] (stmmac_open) from [<c062cf48>] (__dev_open+0xe4/0x180)
[   31.394972]  r10:ed447d04 r9:edc5d010 r8:ef02002c r7:c08670a4 r6:00000000 r5:c0c08488
[   31.402793]  r4:ef020000
[   31.405335] [<c062ce64>] (__dev_open) from [<c062d374>] (__dev_change_flags+0x190/0x1e8)
[   31.413421]  r8:00001002 r7:c0c08488 r6:00001003 r5:00000001 r4:ef020000
[   31.420122] [<c062d1e4>] (__dev_change_flags) from [<c062d3ec>] (dev_change_flags+0x20/0x50)
[   31.428555]  r9:edc5d010 r8:ed447c18 r7:ef020134 r6:00000000 r5:00001002 r4:ef020000
[   31.436300] [<c062d3cc>] (dev_change_flags) from [<c0646ef0>] (do_setlink+0x28c/0xbdc)
[   31.444213]  r9:edc5d010 r8:ed447c18 r7:00000000 r6:c0c08488 r5:ed447b50 r4:ef020000
[   31.451955] [<c0646c64>] (do_setlink) from [<c0648064>] (rtnl_newlink+0x54c/0x7a8)
[   31.459522]  r10:ed447d04 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:00000000
[   31.467343]  r4:ef020000
[   31.469885] [<c0647b18>] (rtnl_newlink) from [<c06449f8>] (rtnetlink_rcv_msg+0x38c/0x544)
[   31.478058]  r10:ed447d04 r9:00000000 r8:ee242840 r7:00000000 r6:edc5d000 r5:c0c08488
[   31.485879]  r4:00000000
[   31.488422] [<c064466c>] (rtnetlink_rcv_msg) from [<c066e458>] (netlink_rcv_skb+0xc0/0x118)
[   31.496768]  r10:c0c08488 r9:00000000 r8:00000020 r7:edc5d000 r6:c064466c r5:c0c08488
[   31.504589]  r4:ee242840
[   31.507129] [<c066e398>] (netlink_rcv_skb) from [<c0644668>] (rtnetlink_rcv+0x18/0x1c)
[   31.515042]  r8:ed447d60 r7:ee242840 r6:00000020 r5:ee37d800 r4:ee5fac00
[   31.521742] [<c0644650>] (rtnetlink_rcv) from [<c066db98>] (netlink_unicast+0x190/0x1fc)
[   31.529829] [<c066da08>] (netlink_unicast) from [<c066e098>] (netlink_sendmsg+0x3cc/0x410)
[   31.538089]  r10:00000000 r9:00000020 r8:014000c0 r7:ee242840 r6:ee37d800 r5:c0c08488
[   31.545910]  r4:ed447f44
[   31.548452] [<c066dccc>] (netlink_sendmsg) from [<c0604460>] (sock_sendmsg+0x1c/0x2c)
[   31.556279]  r10:00000000 r9:ed447edc r8:00000000 r7:eefce640 r6:00000000 r5:c0c08488
[   31.564100]  r4:ed447f44
[   31.566640] [<c0604444>] (sock_sendmsg) from [<c0604d9c>] (___sys_sendmsg+0x250/0x264)
[   31.574555] [<c0604b4c>] (___sys_sendmsg) from [<c0605e98>] (__sys_sendmsg+0x58/0x94)
[   31.582382]  r10:00000000 r9:ed446000 r8:c01011c4 r7:eefce640 r6:00000000 r5:bec25150
[   31.590203]  r4:c0c08488
[   31.592743] [<c0605e40>] (__sys_sendmsg) from [<c0605ee8>] (sys_sendmsg+0x14/0x18)
[   31.600307]  r7:00000128 r6:bec2d17c r5:bec25144 r4:00093ee0
[   31.605969] [<c0605ed4>] (sys_sendmsg) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
[   31.613704] Exception stack(0xed447fa8 to 0xed447ff0)
[   31.618756] 7fa0:                   00093ee0 bec25144 00000003 bec25150 00000000 85ce0000
[   31.626929] 7fc0: 00093ee0 bec25144 bec2d17c 00000128 000942a8 5afc783a 00094000 bec25150
[   31.635099] 7fe0: 00000000 bec250f0 0000012c b6e10b5c
[   31.640152] Code: e59a261c e59a013c e50b306c e592300c (e593300c) 
[   31.646632] ---[ end trace 407964b7deb937bf ]---

For the moment, I stil didnt find the issue.
What to we do now ? do you want that I send revert patchs ?

Regards

^ permalink raw reply

* Re: [PATCH net-next v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node
From: Geert Uytterhoeven @ 2018-05-16 18:32 UTC (permalink / raw)
  To: David Miller
  Cc: Florian Fainelli, netdev, Andrew Lunn, Vivien Didelot,
	Nicolas Ferre, Fugang Duan, Sergei Shtylyov, Giuseppe Cavallaro,
	Alexandre Torgue, Jose Abreu, Grygorii Strashko, Woojung Huh,
	Microchip Linux Driver Support, Rob Herring, Frank Rowand,
	Antoine Ténart, Tobias Jordan
In-Reply-To: <20180516.142102.1650229402143291732.davem@davemloft.net>

Hi David,

On Wed, May 16, 2018 at 8:21 PM, David Miller <davem@davemloft.net> wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Tue, 15 May 2018 16:56:17 -0700
>
>> This patch series updates of_mdiobus_register() such that when the device_node
>> argument is NULL, it calls mdiobus_register() directly. This is consistent with
>> the behavior of of_mdiobus_register() when CONFIG_OF=n.
>>
>> I only converted the most obvious drivers, there are others that have a much
>> less obvious behavior and specifically attempt to deal with CONFIG_ACPI.
>>
>> Changes in v2:
>>
>> - fixed build error in davincin_mdio.c (Grygorii)
>> - reworked first patch a bit: commit message, subject and removed useless
>>   code comment
>
> Based upon Andrew's response to Geert's feedback, I'm applying this series.

Thanks, his feedback made perfect sense.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* Re: [PATCH] net: qcom/emac: Encapsulate sgmii ops under one structure
From: David Miller @ 2018-05-16 18:33 UTC (permalink / raw)
  To: hpuranik; +Cc: netdev, linux-kernel, timur
In-Reply-To: <1526433053-16308-1-git-send-email-hpuranik@codeaurora.org>

From: Hemanth Puranik <hpuranik@codeaurora.org>
Date: Wed, 16 May 2018 06:40:53 +0530

> This patch introduces ops structure for sgmii, This by ensures that
> we do not need dummy functions in case of emulation platforms.
> 
> Signed-off-by: Hemanth Puranik <hpuranik@codeaurora.org>

Applied to net-next.

^ permalink raw reply

* Re: [PATCH net-next v11 1/7] sched: Add Common Applications Kept Enhanced (cake) qdisc
From: Toke Høiland-Jørgensen @ 2018-05-16 18:34 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, cake
In-Reply-To: <20180516.140203.2185491961233997679.davem@davemloft.net>

David Miller <davem@davemloft.net> writes:

> From: Toke Høiland-Jørgensen <toke@toke.dk>
> Date: Tue, 15 May 2018 17:12:44 +0200
>
>> +typedef u64 cobalt_time_t;
>> +typedef s64 cobalt_tdiff_t;
>  ...
>> +static cobalt_time_t cobalt_get_time(void)
>> +{
>> +	return ktime_get_ns();
>> +}
>> +
>> +static u32 cobalt_time_to_us(cobalt_time_t val)
>> +{
>> +	do_div(val, NSEC_PER_USEC);
>> +	return (u32)val;
>> +}
>
> If fundamentally you are working with ktime_t values, please use that type
> and the associated helpers.
>
> This is a valid argument that using custom typedefs provide documentation
> and an aid to understanding, but I think it doesn't serve that purpose
> very well here.
>
> So please just use ktime_t throughout instead of this cobalt_time_t
> and cobalt_tdiff_t.  And then use helpers like ktime_to_us() which
> properly optimize for 64-bit vs. 32-bit hosts.

Can do :)

-Toke

^ permalink raw reply

* Re: [PATCH net-next v3 1/3] ipv4: support sport, dport and ip_proto in RTM_GETROUTE
From: David Miller @ 2018-05-16 18:37 UTC (permalink / raw)
  To: roopa; +Cc: netdev, dsa, nikolay, idosch
In-Reply-To: <1526442908-13183-2-git-send-email-roopa@cumulusnetworks.com>

From: Roopa Prabhu <roopa@cumulusnetworks.com>
Date: Tue, 15 May 2018 20:55:06 -0700

> +static int inet_rtm_getroute_reply(struct sk_buff *in_skb, struct nlmsghdr *nlh,
> +				   __be32 dst, __be32 src, struct flowi4 *fl4,
> +				   struct rtable *rt, struct fib_result *res)
> +{
> +	struct net *net = sock_net(in_skb->sk);
> +	struct rtmsg *rtm = nlmsg_data(nlh);
> +	u32 table_id = RT_TABLE_MAIN;
> +	struct sk_buff *skb;
> +	int err = 0;
> +
> +	skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
> +	if (!skb)
> +		return -ENOMEM;

If the caller can use GFP_KERNEL, so can this allocation.

^ permalink raw reply

* Re: [PATCH] net: 8390: ne: Fix accidentally removed RBTX4927 support
From: David Miller @ 2018-05-16 18:40 UTC (permalink / raw)
  To: geert; +Cc: arnd, linux, anemo, netdev, linux-mips, linux-kernel
In-Reply-To: <1526462281-20772-1-git-send-email-geert@linux-m68k.org>

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Wed, 16 May 2018 11:18:01 +0200

> The configuration settings for RBTX4927 were accidentally removed,
> leading to a silently broken network interface.
> 
> Re-add the missing settings to fix this.
> 
> Fixes: 8eb97ff5a4ec941d ("net: 8390: remove m32r specific bits")
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> Bisected between v4.9-rc2 (doh) and v4.17-rc5.
> 
> Note to myself: I should do more boot testing on RBTX4927.
> Fortunately I caught it before it ends up in a point release ;-)

Better to go on a wild bisect ride than not be able to find the
bug at all :-)

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net] net/sched: fix refcnt leak in the error path of tcf_vlan_init()
From: David Miller @ 2018-05-16 18:42 UTC (permalink / raw)
  To: dcaratti; +Cc: netdev, jiri, jhs, mrv
In-Reply-To: <b2e7cfab172461a824959d683d8c868fe04119a3.1526467698.git.dcaratti@redhat.com>

From: Davide Caratti <dcaratti@redhat.com>
Date: Wed, 16 May 2018 12:54:29 +0200

> Similarly to what was done with commit a52956dfc503 ("net sched actions:
> fix refcnt leak in skbmod"), fix the error path of tcf_vlan_init() to avoid
> refcnt leaks when wrong value of TCA_VLAN_PUSH_VLAN_PROTOCOL is given.
> 
> Fixes: 5026c9b1bafc ("net sched: vlan action fix late binding")
> CC: Roman Mashak <mrv@mojatatu.com>
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>

Applied and queued up for -stable, thanks.

^ permalink raw reply

* Re: [PATCH net-next] net: stmmac: Remove useless test before clk_disable_unprepare
From: David Miller @ 2018-05-16 18:44 UTC (permalink / raw)
  To: yuehaibing; +Cc: peppe.cavallaro, netdev, linux-kernel, alexandre.torgue
In-Reply-To: <20180516105919.25436-1-yuehaibing@huawei.com>

From: YueHaibing <yuehaibing@huawei.com>
Date: Wed, 16 May 2018 18:59:19 +0800

> clk_disable_unprepare() already checks that the clock pointer is valid.
> No need to test it before calling it.
> 
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next] net: ethoc: Remove useless test before clk_disable_unprepare
From: David Miller @ 2018-05-16 18:47 UTC (permalink / raw)
  To: yuehaibing; +Cc: tklauser, netdev, linux-kernel
In-Reply-To: <20180516111822.26440-1-yuehaibing@huawei.com>

From: YueHaibing <yuehaibing@huawei.com>
Date: Wed, 16 May 2018 19:18:22 +0800

> clk_disable_unprepare() already checks that the clock pointer is valid.
> No need to test it before calling it.
> 
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>

Applied.

^ permalink raw reply

* Re: [PATCH net] net/ipv4: Initialize proto and ports in flow struct
From: David Ahern @ 2018-05-16 18:48 UTC (permalink / raw)
  To: netdev; +Cc: roopa
In-Reply-To: <20180516181834.31915-1-dsahern@gmail.com>

On 5/16/18 12:18 PM, David Ahern wrote:

> @@ -347,8 +348,11 @@ static int __fib_validate_source(struct sk_buff *skb, __be32 src, __be32 dst,
>  	no_addr = idev->ifa_list == NULL;
>  
>  	fl4.flowi4_mark = IN_DEV_SRC_VMARK(idev) ? skb->mark : 0;
> -
> -	trace_fib_validate_source(dev, &fl4);

Looks like I sent the net-next version; did not mean to remove that
tracepoint in net. Will send v2


> +	if (!fib4_rules_early_flow_dissect(net, skb, &fl4, &flkeys)) {
> +		fl4.flowi4_proto = 0;
> +		fl4.fl4_sport = 0;
> +		fl4.fl4_dport = 0;
> +	}
>  
>  	if (fib_lookup(net, &fl4, &res, 0))
>  		goto last_resort;

^ permalink raw reply

* Re: [PATCH net 0/3] qed: LL2 fixes
From: David Miller @ 2018-05-16 18:50 UTC (permalink / raw)
  To: Michal.Kalderon; +Cc: netdev, chad.dupuis, Ariel.Elior
In-Reply-To: <20180516114440.5048-1-Michal.Kalderon@cavium.com>

From: Michal Kalderon <Michal.Kalderon@cavium.com>
Date: Wed, 16 May 2018 14:44:37 +0300

> This series fixes some issues in ll2 related to synchronization
> and resource freeing
> 
> Signed-off-by: Ariel Elior <Ariel.Elior@cavium.com>
> Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>

Series applied and queued up for -stable, thank you.

^ permalink raw reply

* [PATCH net-next v2 1/3] net: ethernet: ti: Allow most drivers with COMPILE_TEST
From: Florian Fainelli @ 2018-05-16 18:52 UTC (permalink / raw)
  To: netdev
  Cc: fugang.duan, Florian Fainelli, David S. Miller, Andrew Lunn,
	open list
In-Reply-To: <20180516185258.20508-1-f.fainelli@gmail.com>

Most of the TI drivers build just fine with COMPILE_TEST, cpmac (AR7) is
the exception because it uses a header file from
arch/mips/include/asm/mach-ar7/ar7.h.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 drivers/net/ethernet/ti/Kconfig | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index 48a541eb0af2..1f8626999ac6 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -18,7 +18,7 @@ if NET_VENDOR_TI
 
 config TI_DAVINCI_EMAC
 	tristate "TI DaVinci EMAC Support"
-	depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 )
+	depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 ) || COMPILE_TEST
 	select TI_DAVINCI_MDIO
 	select TI_DAVINCI_CPDMA
 	select PHYLIB
@@ -30,7 +30,7 @@ config TI_DAVINCI_EMAC
 
 config TI_DAVINCI_MDIO
 	tristate "TI DaVinci MDIO Support"
-	depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE
+	depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE || COMPILE_TEST
 	select PHYLIB
 	---help---
 	  This driver supports TI's DaVinci MDIO module.
@@ -40,7 +40,7 @@ config TI_DAVINCI_MDIO
 
 config TI_DAVINCI_CPDMA
 	tristate "TI DaVinci CPDMA Support"
-	depends on ARCH_DAVINCI || ARCH_OMAP2PLUS
+	depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || COMPILE_TEST
 	---help---
 	  This driver supports TI's DaVinci CPDMA dma engine.
 
@@ -60,7 +60,7 @@ config TI_CPSW_ALE
 
 config TI_CPSW
 	tristate "TI CPSW Switch Support"
-	depends on ARCH_DAVINCI || ARCH_OMAP2PLUS
+	depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || COMPILE_TEST
 	select TI_DAVINCI_CPDMA
 	select TI_DAVINCI_MDIO
 	select TI_CPSW_PHY_SEL
@@ -75,7 +75,7 @@ config TI_CPSW
 
 config TI_CPTS
 	bool "TI Common Platform Time Sync (CPTS) Support"
-	depends on TI_CPSW || TI_KEYSTONE_NETCP
+	depends on TI_CPSW || TI_KEYSTONE_NETCP || COMPILE_TEST
 	depends on POSIX_TIMERS
 	---help---
 	  This driver supports the Common Platform Time Sync unit of
@@ -95,8 +95,8 @@ config TI_KEYSTONE_NETCP
 	tristate "TI Keystone NETCP Core Support"
 	select TI_CPSW_ALE
 	select TI_DAVINCI_MDIO
-	depends on OF
-	depends on KEYSTONE_NAVIGATOR_DMA && KEYSTONE_NAVIGATOR_QMSS
+	depends on OF && KEYSTONE_NAVIGATOR_DMA && KEYSTONE_NAVIGATOR_QMSS || \
+		   COMPILE_TEST
 	---help---
 	  This driver supports TI's Keystone NETCP Core.
 
-- 
2.14.1

^ permalink raw reply related

* [PATCH net-next v2 2/3] net: ethernet: freescale: Allow FEC with COMPILE_TEST
From: Florian Fainelli @ 2018-05-16 18:52 UTC (permalink / raw)
  To: netdev
  Cc: fugang.duan, Florian Fainelli, David S. Miller, Andrew Lunn,
	open list
In-Reply-To: <20180516185258.20508-1-f.fainelli@gmail.com>

The Freescale FEC driver builds fine with COMPILE_TEST, so make that
possible.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 drivers/net/ethernet/freescale/Kconfig    | 2 +-
 drivers/net/ethernet/freescale/fec.h      | 2 +-
 drivers/net/ethernet/freescale/fec_main.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index 6e490fd2345d..a580a3dcbe59 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -22,7 +22,7 @@ if NET_VENDOR_FREESCALE
 config FEC
 	tristate "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
 	depends on (M523x || M527x || M5272 || M528x || M520x || M532x || \
-		   ARCH_MXC || SOC_IMX28)
+		   ARCH_MXC || SOC_IMX28 || COMPILE_TEST)
 	default ARCH_MXC || SOC_IMX28 if ARM
 	select PHYLIB
 	imply PTP_1588_CLOCK
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index e7381f8ef89d..4778b663653e 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -21,7 +21,7 @@
 
 #if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || \
     defined(CONFIG_M520x) || defined(CONFIG_M532x) || defined(CONFIG_ARM) || \
-    defined(CONFIG_ARM64)
+    defined(CONFIG_ARM64) || defined(CONFIG_COMPILE_TEST)
 /*
  *	Just figures, Motorola would have to change the offsets for
  *	registers in the same peripheral device on different models
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index d4604bc8eb5b..91e334b5a836 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2111,7 +2111,7 @@ static int fec_enet_get_regs_len(struct net_device *ndev)
 /* List of registers that can be safety be read to dump them with ethtool */
 #if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || \
 	defined(CONFIG_M520x) || defined(CONFIG_M532x) || defined(CONFIG_ARM) || \
-	defined(CONFIG_ARM64)
+	defined(CONFIG_ARM64) || defined(CONFIG_COMPILE_TEST)
 static u32 fec_enet_register_offset[] = {
 	FEC_IEVENT, FEC_IMASK, FEC_R_DES_ACTIVE_0, FEC_X_DES_ACTIVE_0,
 	FEC_ECNTRL, FEC_MII_DATA, FEC_MII_SPEED, FEC_MIB_CTRLSTAT, FEC_R_CNTRL,
-- 
2.14.1

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox