Re: [PATCH v3 0/2] refactor code and mark expected switch fall-throughs

[David Ranch]

Hello David,

Thanks for the reply.  I completely admit that there aren't many changes 
going into this section of code.  Unfortunately, we've had some nasty 
breaks that took quite a long while to get fixed.


Can you point me in the direction of this kbuild test robot (URLs, etc) 
so I can better understand if it makes sense to add tests there?  For 
example, do you know if it's "changed based" so only certain tests will 
run if given files are updated?


--David
KI6ZHD


On 10/28/2017 06:45 PM, David Miller wrote:

From: David Ranch 
Date: Sat, 28 Oct 2017 10:53:24 -0700


Does anyone else have thoughts on this topic?


I think you are making a mountain out of a mole hill.

If you care so much about this, set things up so that entities such as
the kbuild test robot run whatever tests you think are necessary.

Otherwise, continually test the stack yourself and report any
regressions here as fast as you can.

If soemone can't be bothered to verify or test someone's change in 2
or 3 days, except in extreme circumstances, I absolutely refuse to
burdon the submitter and let their patches rot in the queue.

That's unacceptable.

That's the proper way to deal with this, without unreasonably
burdoning people who just want to keep the code across the tree modern
and more up to date.

Thank you.

Re: [PATCH net-next 1/1] net sched qdisc: pass netlink message flags in event notification

[Roman Mashak]

Cong Wang  writes:

> On Thu, Oct 26, 2017 at 2:40 PM, Roman Mashak  wrote:
>> Userland client should be able to read an event, and reflect it back to
>> the kernel, therefore it needs to extract complete set of netlink flags.
>>
>> For example, this will allow "tc monitor" to distinguish Add and Replace
>> qdisc operations.
>>
>> Signed-off-by: Roman Mashak 
>> ---
>>  net/sched/sch_api.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
>> index a9ac912..e3e29be 100644
>> --- a/net/sched/sch_api.c
>> +++ b/net/sched/sch_api.c
>> @@ -859,7 +859,7 @@ static int qdisc_notify(struct net *net, struct sk_buff 
>> *oskb,
>> }
>> if (new && !tc_qdisc_dump_ignore(new, false)) {
>> if (tc_fill_qdisc(skb, new, clid, portid, n->nlmsg_seq,
>> - old ? NLM_F_REPLACE : 0, RTM_NEWQDISC) < 0)
>> + n->nlmsg_flags, RTM_NEWQDISC) < 0)
>
>
> Don't you want to change the other tc_fill_qdisc() in the same function
> too? ;)

The other tc_fill_qdisc generates RTM_DELQDISC event, in that case
netlink flags for user don't matter.

Re: [PATCH net-next] ipv6: prevent user from adding cached routes

[David Miller]

From: Wei Wang 
Date: Fri, 27 Oct 2017 17:30:12 -0700

> From: Wei Wang 
> 
> Cached routes should only be created by the system when receiving pmtu
> discovery or ip redirect msg. Users should not be allowed to create
> cached routes.
> 
> Furthermore, after the patch series to move cached routes into exception
> table, user added cached routes will trigger the following warning in
> fib6_add():
 ...
> So we fix this by failing the attemp to add cached routes from userspace
> with returning EINVAL error.
> 
> Fixes: 2b760fcf5cfb ("ipv6: hook up exception table to store dst cache")
> Signed-off-by: Wei Wang 
> Signed-off-by: Eric Dumazet 

Applied, thank you.

Re: [PATCH net-next] samples/bpf: adjust rlimit RLIMIT_MEMLOCK for xdp1

[David Miller]

From: Tushar Dave 
Date: Fri, 27 Oct 2017 16:12:30 -0700

> Default rlimit RLIMIT_MEMLOCK is 64KB, causes bpf map failure.
> e.g.
> [root@lab bpf]#./xdp1 -N $( failed to create a map: 1 Operation not permitted
> 
> Fix it.
> 
> Signed-off-by: Tushar Dave 

Applied.

Re: [PATCH net-next] samples/bpf: adjust rlimit RLIMIT_MEMLOCK for xdp_redirect_map

[David Miller]

From: Tushar Dave 
Date: Fri, 27 Oct 2017 17:28:22 -0700

> Default rlimit RLIMIT_MEMLOCK is 64KB, causes bpf map failure.
> e.g.
> [root@labbpf]# ./xdp_redirect_map $(> $( failed to create a map: 1 Operation not permitted
> 
> The failure is 100% when multiple xdp programs are running. Fix it.
> 
> Signed-off-by: Tushar Dave 

Applied.

Re: [PATCH net-next] net: dsa: b53: Export b53_configure_vlan()

[David Miller]

From: Florian Fainelli 
Date: Fri, 27 Oct 2017 15:56:01 -0700

> bcm_sf2 and b53 replicate the same operations: clear all VLANs and set
> their ports to the default VLAN tag (1 for these devices) so export the
> b53 function doing just that.
> 
> Signed-off-by: Florian Fainelli 

Applied.

Re: [PATCH net-next] liquidio: get rid of false alarm "Unknown cmd 27" in dmesg

[David Miller]

From: Felix Manlunas 
Date: Fri, 27 Oct 2017 14:37:03 -0700

> Creating a macvtap interface with the liquidio VF driver as lower device
> causes this alarming message to show up in dmesg:
> 
> liquidio_link_ctrl_cmd_completion Unknown cmd 27
> 
> That's actually a false alarm because cmd 27 is the value of the macro
> OCTNET_CMD_SET_UC_LIST which is known.  It's a control command sent from
> host to NIC firmware to set the unicast MAC address list of the macvtap
> lower device.
> 
> Make the false alarm go away by adding a case for OCTNET_CMD_SET_UC_LIST
> in liquidio_link_ctrl_cmd_completion().
> 
> Signed-off-by: Felix Manlunas 
> Signed-off-by: Raghu Vatsavayi 

Applied.

Re: [PATCH net-next] hv_netvsc: Set tx_table to equal weight after subchannels open

[David Miller]

From: Haiyang Zhang 
Date: Fri, 27 Oct 2017 12:36:38 -0700

> From: Haiyang Zhang 
> 
> In some cases, like internal vSwitch, the host doesn't provide
> send indirection table updates. This patch sets the table to be
> equal weight after subchannels are all open. Otherwise, all workload
> will be on one TX channel.
> 
> As tested, this patch has largely increased the throughput over
> internal vSwitch.
> 
> Signed-off-by: Haiyang Zhang 

Applied to net-next, thanks.

Re: [PATCH net] sctp: reset owner sk for data chunks on out queues when migrating a sock

[David Miller]

From: Xin Long 
Date: Sat, 28 Oct 2017 02:13:29 +0800

> Now when migrating sock to another one in sctp_sock_migrate(), it only
> resets owner sk for the data in receive queues, not the chunks on out
> queues.
> 
> It would cause that data chunks length on the sock is not consistent
> with sk sk_wmem_alloc. When closing the sock or freeing these chunks,
> the old sk would never be freed, and the new sock may crash due to
> the overflow sk_wmem_alloc.
> 
> syzbot found this issue with this series:
> 
>   r0 = socket$inet_sctp()
>   sendto$inet(r0)
>   listen(r0)
>   accept4(r0)
>   close(r0)
> 
> Although listen() should have returned error when one TCP-style socket
> is in connecting (I may fix this one in another patch), it could also
> be reproduced by peeling off an assoc.
> 
> This issue is there since very beginning.
> 
> This patch is to reset owner sk for the chunks on out queues so that
> sk sk_wmem_alloc has correct value after accept one sock or peeloff
> an assoc to one sock.
> 
> Note that when resetting owner sk for chunks on outqueue, it has to
> sctp_clear_owner_w/skb_orphan chunks before changing assoc->base.sk
> first and then sctp_set_owner_w them after changing assoc->base.sk,
> due to that sctp_wfree and it's callees are using assoc->base.sk.
> 
> Reported-by: Dmitry Vyukov 
> Signed-off-by: Xin Long 

Applied and queued up for -stable, thank you.

Re: [PATCH] ppp: allow usage in namespaces

[David Miller]

From: Matteo Croce 
Date: Fri, 27 Oct 2017 20:08:23 +0200

> Check for CAP_NET_ADMIN with ns_capable() instead of capable()
> to allow usage of ppp in user namespace other than the init one.
> 
> Signed-off-by: Matteo Croce 

Ok, applied to net-next.

Re: [net-next v2 0/6][pull request] 1GbE Intel Wired LAN Driver Updates 2017-10-27

[David Miller]

From: Jeff Kirsher 
Date: Fri, 27 Oct 2017 09:57:00 -0700

> This patchset is a proposal of how the Traffic Control subsystem can
> be used to offload the configuration of the Credit Based Shaper
> (defined in the IEEE 802.1Q-2014 Section 8.6.8.2) into supported
> network devices.
 ...

Pulled, thanks Jeff!

Re: [net PATCH 0/2] sockmap fixes

[David Miller]

From: John Fastabend 
Date: Fri, 27 Oct 2017 09:45:16 -0700

> Last two fixes (as far as I know) for sockmap code this round.
> 
> First, we are using the qdisc cb structure when making the data end
> calculation. This is really just wrong so, store it with the other
> metadata in the correct tcp_skb_cb sturct to avoid breaking things.
> 
> Next, with recent work to attach multiple programs to a cgroup a
> specific enumeration of return codes was agreed upon. However,
> I wrote the sk_skb program types before seeing this work and used
> a different convention. Patch 2 in the series aligns the return
> codes to avoid breaking with this infrastructure and also aligns
> with other programming conventions to avoid being the odd duck out
> forcing programs to remember SK_SKB programs are different. Pusing
> to net because its a user visible change. With this SK_SKB program
> return codes are the same as other cgroup program types.

Series applied, thanks a lot John.

Re: [PATCH net 0/4] l2tp: register sessions atomically

[David Miller]

From: Guillaume Nault 
Date: Fri, 27 Oct 2017 16:51:48 +0200

> Currently l2tp_session_create() allocates a session, partially
> initialises it and finally registers it. It therefore exposes sessions
> that aren't fully initialised to the rest of the system, because
> pseudo-wire specific initialisation can only happen after
> l2tp_session_create() returns.
> This leads to several crashes when these sessions are used or deleted.
> 
> This series starts by splitting session registration out of
> l2tp_session_create() (patch #1). Thus allowing pseudo-wires code to
> terminate the initialisation phase before registration.
> 
> Then patch #2 fixes the eth pseudo-wire code. This requires protecting
> the session's netdevice pointer with RCU, because it still needs to be
> updated concurrently after the session got registered.
> 
> Remaining patches take care of ppp pseudo-wires. RCU protection is
> needed there too, for the same reasons. This time it's the pppol2tp
> socket pointer that gets protected. For clarity, and since the
> conversion requires more modifications, introducing RCU is done in
> its own patch (#3). Then patch #4 only has to take care of fixing
> sessions initialisation and registration (and adapting part of the
> deletion process).

Series applied, thank you.

Re: net-next Compile error

[David Miller]

From: Egil Hjelmeland 
Date: Fri, 27 Oct 2017 15:50:25 +0200

> Starting with net-next commit 60e2a7780793bae0debc275a9ccd57f7da0cf195
> "tcp: TCP experimental option for SMC", I can not cross compile the
> kernel.

Thanks for the report, I've committed the following fix for this:


[PATCH] tcp: Remove "linux/unaligned/access_ok.h" include.

This causes build failures:

In file included from net/ipv4/tcp_input.c:79:0:
./include/linux/unaligned/access_ok.h:7:28: error: redefinition of
'get_unaligned_le16'
In file included from ./include/asm-generic/unaligned.h:17:0,
 from ./arch/arm/include/generated/asm/unaligned.h:1,
 from net/ipv4/tcp_input.c:76:
./include/linux/unaligned/le_struct.h:6:19: note: previous definition
of 'get_unaligned_le16' was here
In file included from net/ipv4/tcp_input.c:79:0:
./include/linux/unaligned/access_ok.h:12:28: error: redefinition of
'get_unaligned_le32'

Plain "asm/access_ok.h", which is already included, is
sufficient.

Fixes: 60e2a7780793 ("tcp: TCP experimental option for SMC")
Reported-by: Egil Hjelmeland 
Signed-off-by: David S. Miller 
---
 net/ipv4/tcp_input.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 21c358c0cf2e..b62a7d1707ae 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -76,7 +76,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 int sysctl_tcp_max_orphans __read_mostly = NR_FILE;
-- 
2.13.6

Re: [PATCH net-next] cxgb3: Check and handle the dma mapping errors

[David Miller]

From: Ganesh Goudar 
Date: Fri, 27 Oct 2017 18:08:21 +0530

> From: Arjun Vynipadath 
> 
> This patch adds checks at approprate places whether *dma_map*() call has
> succeeded or not.
> 
> Original Work by: Santosh Rastapur 
> Signed-off-by: Arjun Vynipadath 
> Signed-off-by: Ganesh Goudar 

Applied.

Re: [PATCH] r8169: Add support for interrupt coalesce tuning (ethtool -C)

[David Miller]

Applied to net-next, thank you.

Re: [PATCH net-next v6 0/2] bridge: make setlink/dellink notifications more accurate

[David Miller]

From: Nikolay Aleksandrov 
Date: Fri, 27 Oct 2017 13:19:35 +0300

> Before this set the bridge would generate a notification on vlan add or del
> even if they didn't actually do any changes, which confuses listeners and
> is generally not preferred. We could also lose notifications on actual
> changes if one adds a range of vlans and there's an error in the middle.
> The problem with just breaking and returning an error is that we could
> break existing user-space scripts which rely on the vlan delete to clear
> all existing entries in the specified range and ignore the non-existing
> errors (typically used to clear the current vlan config).
> So in order to make the notifications more accurate while keeping backwards
> compatibility we add a boolean that tracks if anything actually changed
> during the config calls.
> 
> The vlan add is more difficult to fix because it always returns 0 even if
> nothing changed, but we cannot use a specific error because the drivers
> can return anything and we may mask it, also we'd need to update all places
> that directly return the add result, thus to signal that a vlan was created
> or updated and in order not to break overlapping vlan range add we pass
> down the new boolean that tracks changes to the add functions to check
> if anything was actually updated.
> 
> v6: moved "changed" in else branch in br|nbp_vlan_add, thanks to
> Toshiaki Makita and retested everything again
> v5: fix br_vlan_add return (v1 leftover) spotted by Toshiaki Makita
> v4: set changed always to false in the non-vlan config case and retested
> v3: rebased to latest net-next and fixed non-vlan config functions reported
> by kbuild test bot
> v2: pass changed down to vlan add instead of masking errors

Series applied, thank you.

[PATCH net-next] net: dpaa: remove init which already done in per-cpu allocation

[yuan linyu]

From: yuan linyu 

Signed-off-by: yuan linyu 
---
 drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c 
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index a8d0be8..1ccc316 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2814,10 +2814,6 @@ static int dpaa_eth_probe(struct platform_device *pdev)
err = -ENOMEM;
goto free_dpaa_fqs;
}
-   for_each_possible_cpu(i) {
-   percpu_priv = per_cpu_ptr(priv->percpu_priv, i);
-   memset(percpu_priv, 0, sizeof(*percpu_priv));
-   }
 
priv->num_tc = 1;
netif_set_real_num_tx_queues(net_dev, priv->num_tc * DPAA_TC_TXQ_NUM);
-- 
2.7.4

Re: [PATCH v7 net-next 00/13] gtp: Additional feature support - Part I

[David Miller]

From: Tom Herbert 
Date: Sat, 28 Oct 2017 11:37:51 -0700

> Customers are using IPv6!

Customers aren't using GTP with ipv6 the way you have implemented it.

Please stop weasel-wording the situation to frame it in a way that
purely benefits you and your objectives.

Also, just because "nobody has done the work", doesn't mean it's OK to
do the work improperly and then force that implementation upon people.

Harald is right, calling something GTP/ipv6 sets a certain expectation
with people who actually use GTP with ipv6 and have a deployment.  No
matter if you mark it EXPERIMENTAL or whatever, the effect is the
same.

Therefore, I fully agree with Harald.

Re: [PATCH v3 0/2] refactor code and mark expected switch fall-throughs

[David Miller]

From: David Ranch 
Date: Sat, 28 Oct 2017 10:53:24 -0700

> Does anyone else have thoughts on this topic?

I think you are making a mountain out of a mole hill.

If you care so much about this, set things up so that entities such as
the kbuild test robot run whatever tests you think are necessary.

Otherwise, continually test the stack yourself and report any
regressions here as fast as you can.

If soemone can't be bothered to verify or test someone's change in 2
or 3 days, except in extreme circumstances, I absolutely refuse to
burdon the submitter and let their patches rot in the queue.

That's unacceptable.

That's the proper way to deal with this, without unreasonably
burdoning people who just want to keep the code across the tree modern
and more up to date.

Thank you.

Re: Linux 4.14-rc6 bisected regression tun devices not working anymore in openvpn

[David Miller]

From: Cong Wang 
Date: Sat, 28 Oct 2017 10:37:27 -0700

> On Sat, Oct 28, 2017 at 7:57 AM, Sander Eikelenboom
>  wrote:
>> The offending commit is:
>> 0ad646c81b2182f7fa67ec0c8c825e0ee165696d
>> "tun: call dev_get_valid_name() before register_netdevice()"
>>
>> Reverting this commit fixes the issue for me, it's unfortunate that the 
>> commit it self seems to fix an other issue.
> 
> It should be fixed by:
> 
> commit 5c25f65fd1e42685f7ccd80e0621829c105785d9
> Author: Julien Gomes 
> Date:   Wed Oct 25 11:50:50 2017 -0700
> 
> tun: allow positive return values on dev_get_valid_name() call

I made sure to queue this up for -stable since the offending commit is queued up
there as well.

[PATCH net-next] selftests/bpf: remove useless bpf_trace_printk

[Alexei Starovoitov]

sockmap test is using two programs that use bpf_trace_printk()
which prints into trace_pipe, but nothing is reading it.
Remove it.

Fixes: 6f6d33f3b3d0 ("bpf: selftests add sockmap tests")
Signed-off-by: Alexei Starovoitov 
---
 tools/testing/selftests/bpf/sockmap_parse_prog.c   | 3 ---
 tools/testing/selftests/bpf/sockmap_verdict_prog.c | 2 --
 2 files changed, 5 deletions(-)

diff --git a/tools/testing/selftests/bpf/sockmap_parse_prog.c 
b/tools/testing/selftests/bpf/sockmap_parse_prog.c
index fae3b96c3aa4..a1dec2b6d9c5 100644
--- a/tools/testing/selftests/bpf/sockmap_parse_prog.c
+++ b/tools/testing/selftests/bpf/sockmap_parse_prog.c
@@ -29,9 +29,6 @@ int bpf_prog1(struct __sk_buff *skb)
 * fields.
 */
d[7] = 1;
-
-   bpf_printk("parse: data[0] = (%u): local_port %i remote %i\n",
-  d[0], lport, bpf_ntohl(rport));
return skb->len;
 }
 
diff --git a/tools/testing/selftests/bpf/sockmap_verdict_prog.c 
b/tools/testing/selftests/bpf/sockmap_verdict_prog.c
index 2cd2d552938b..d7bea972cb21 100644
--- a/tools/testing/selftests/bpf/sockmap_verdict_prog.c
+++ b/tools/testing/selftests/bpf/sockmap_verdict_prog.c
@@ -58,8 +58,6 @@ int bpf_prog2(struct __sk_buff *skb)
d[6] = 0xe;
d[7] = 0xf;
 
-   bpf_printk("verdict: data[0] = redir(%u:%u)\n", map, sk);
-
if (!map)
return bpf_sk_redirect_map(skb, _map_rx, sk, 0);
return bpf_sk_redirect_map(skb, _map_tx, sk, 0);
-- 
2.9.5

Re: [PATCH net-next 2/2] chcr: Add support for Inline IPSec

[kbuild test robot]

Hi Atul,

Thank you for the patch! Yet we hit a small issue.
[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Atul-Gupta/cxgb4-Add-support-for-Inline-IPSec-Tx/20171029-060344
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   In file included from drivers/crypto/chelsio/chcr_core.h:41:0,
from drivers/crypto/chelsio/chcr_ipsec.c:64:
   drivers/crypto/chelsio/chcr_ipsec.c: In function 'chcr_ipsec_xmit':
>> drivers/net/ethernet/chelsio/cxgb4/cxgb4.h:1678:13: error: inlining failed 
>> in call to always_inline 'cxgb4_reclaim_completed_tx': function body not 
>> available
inline void cxgb4_reclaim_completed_tx(struct adapter *adap,
^~
   drivers/crypto/chelsio/chcr_ipsec.c:597:2: note: called from here
 cxgb4_reclaim_completed_tx(adap, >q, true);
 ^
   In file included from drivers/crypto/chelsio/chcr_core.h:41:0,
from drivers/crypto/chelsio/chcr_ipsec.c:64:
>> drivers/net/ethernet/chelsio/cxgb4/cxgb4.h:1678:13: error: inlining failed 
>> in call to always_inline 'cxgb4_reclaim_completed_tx': function body not 
>> available
inline void cxgb4_reclaim_completed_tx(struct adapter *adap,
^~
   drivers/crypto/chelsio/chcr_ipsec.c:597:2: note: called from here
 cxgb4_reclaim_completed_tx(adap, >q, true);
 ^
   In file included from drivers/crypto/chelsio/chcr_core.h:41:0,
from drivers/crypto/chelsio/chcr_ipsec.c:64:
>> drivers/net/ethernet/chelsio/cxgb4/cxgb4.h:1687:13: error: inlining failed 
>> in call to always_inline 'cxgb4_ring_tx_db': function body not available
inline void cxgb4_ring_tx_db(struct adapter *adap, struct sge_txq *q, int 
n);
^~~~
   drivers/crypto/chelsio/chcr_ipsec.c:657:2: note: called from here
 cxgb4_ring_tx_db(adap, >q, ndesc);
 ^~~~
   In file included from drivers/crypto/chelsio/chcr_core.h:41:0,
from drivers/crypto/chelsio/chcr_ipsec.c:64:
>> drivers/net/ethernet/chelsio/cxgb4/cxgb4.h:1687:13: error: inlining failed 
>> in call to always_inline 'cxgb4_ring_tx_db': function body not available
inline void cxgb4_ring_tx_db(struct adapter *adap, struct sge_txq *q, int 
n);
^~~~
   drivers/crypto/chelsio/chcr_ipsec.c:657:2: note: called from here
 cxgb4_ring_tx_db(adap, >q, ndesc);
 ^~~~

vim +/cxgb4_reclaim_completed_tx +1678 
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h

f2b7e78db drivers/net/ethernet/chelsio/cxgb4/cxgb4.h Vipul Pandya 
2012-12-10  1562  
625ba2c2e drivers/net/cxgb4/cxgb4.h  Dimitris Michailidis 
2010-04-01  1563  void t4_wol_magic_enable(struct adapter *adap, unsigned int 
port,
625ba2c2e drivers/net/cxgb4/cxgb4.h  Dimitris Michailidis 
2010-04-01  1564   const u8 *addr);
625ba2c2e drivers/net/cxgb4/cxgb4.h  Dimitris Michailidis 
2010-04-01  1565  int t4_wol_pat_enable(struct adapter *adap, unsigned int 
port, unsigned int map,
625ba2c2e drivers/net/cxgb4/cxgb4.h  Dimitris Michailidis 
2010-04-01  1566u64 mask0, u64 mask1, unsigned int crc, 
bool enable);
625ba2c2e drivers/net/cxgb4/cxgb4.h  Dimitris Michailidis 
2010-04-01  1567  
625ba2c2e drivers/net/cxgb4/cxgb4.h  Dimitris Michailidis 
2010-04-01  1568  int t4_fw_hello(struct adapter *adap, unsigned int mbox, 
unsigned int evt_mbox,
625ba2c2e drivers/net/cxgb4/cxgb4.h  Dimitris Michailidis 
2010-04-01  1569  enum dev_master master, enum dev_state *state);
625ba2c2e drivers/net/cxgb4/cxgb4.h  Dimitris Michailidis 
2010-04-01  1570  int t4_fw_bye(struct adapter *adap, unsigned int mbox);
625ba2c2e drivers/net/cxgb4/cxgb4.h  Dimitris Michailidis 
2010-04-01  1571  int t4_early_init(struct adapter *adap, unsigned int mbox);
625ba2c2e drivers/net/cxgb4/cxgb4.h  Dimitris Michailidis 
2010-04-01  1572  int t4_fw_reset(struct adapter *adap, unsigned int mbox, int 
reset);
636f9d371 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h Vipul Pandya 
2012-09-26  1573  int t4_fixup_host_params(struct adapter *adap, unsigned int 
page_size,
636f9d371 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h Vipul Pandya 
2012-09-26  1574unsigned int cache_line_size);
636f9d371 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h Vipul Pandya 

Re: [PATCH net-next 2/2] net sched act_vlan: VLAN action rewrite to use RCU lock/unlock and update

[kbuild test robot]

Hi Manish,

Thank you for the patch! Yet we hit a small issue.
[auto build test WARNING on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Manish-Kurup/net-sched-act_vlan-Change-stats-update-to-use-per-core-stats/20171029-053449
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)


vim +70 drivers/net/ethernet/netronome/nfp/flower/action.c

1a1e586f Pieter Jansen van Vuuren 2017-06-29  55  
1a1e586f Pieter Jansen van Vuuren 2017-06-29  56  static void
1a1e586f Pieter Jansen van Vuuren 2017-06-29  57  nfp_fl_push_vlan(struct 
nfp_fl_push_vlan *push_vlan,
1a1e586f Pieter Jansen van Vuuren 2017-06-29  58 const struct 
tc_action *action)
1a1e586f Pieter Jansen van Vuuren 2017-06-29  59  {
1a1e586f Pieter Jansen van Vuuren 2017-06-29  60size_t act_size = 
sizeof(struct nfp_fl_push_vlan);
1a1e586f Pieter Jansen van Vuuren 2017-06-29  61struct tcf_vlan *vlan = 
to_vlan(action);
1a1e586f Pieter Jansen van Vuuren 2017-06-29  62u16 tmp_push_vlan_tci;
1a1e586f Pieter Jansen van Vuuren 2017-06-29  63  
62d3f60b Pieter Jansen van Vuuren 2017-10-20  64push_vlan->head.jump_id 
= NFP_FL_ACTION_OPCODE_PUSH_VLAN;
62d3f60b Pieter Jansen van Vuuren 2017-10-20  65push_vlan->head.len_lw 
= act_size >> NFP_FL_LW_SIZ;
1a1e586f Pieter Jansen van Vuuren 2017-06-29  66push_vlan->reserved = 0;
1a1e586f Pieter Jansen van Vuuren 2017-06-29  67push_vlan->vlan_tpid = 
tcf_vlan_push_proto(action);
1a1e586f Pieter Jansen van Vuuren 2017-06-29  68  
1a1e586f Pieter Jansen van Vuuren 2017-06-29  69tmp_push_vlan_tci =
1a1e586f Pieter Jansen van Vuuren 2017-06-29 @70
FIELD_PREP(NFP_FL_PUSH_VLAN_PRIO, vlan->tcfv_push_prio) |
1a1e586f Pieter Jansen van Vuuren 2017-06-29  71
FIELD_PREP(NFP_FL_PUSH_VLAN_VID, vlan->tcfv_push_vid) |
1a1e586f Pieter Jansen van Vuuren 2017-06-29  72
NFP_FL_PUSH_VLAN_CFI;
1a1e586f Pieter Jansen van Vuuren 2017-06-29  73push_vlan->vlan_tci = 
cpu_to_be16(tmp_push_vlan_tci);
1a1e586f Pieter Jansen van Vuuren 2017-06-29  74  }
1a1e586f Pieter Jansen van Vuuren 2017-06-29  75  

:: The code at line 70 was first introduced by commit
:: 1a1e586f54bfe54a0ba7ea0ac9b8c7b1d3e655f6 nfp: add basic action 
capabilities to flower offloads

:: TO: Pieter Jansen van Vuuren 
:: CC: David S. Miller 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH net-next 1/2] cxgb4: Add support for Inline IPSec Tx

[kbuild test robot]

Hi Atul,

Thank you for the patch! Yet we hit a small issue.
[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Atul-Gupta/cxgb4-Add-support-for-Inline-IPSec-Tx/20171029-060344
config: x86_64-kexec (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/net//ethernet/chelsio/cxgb4/sge.c: In function 't4_eth_xmit':
>> drivers/net//ethernet/chelsio/cxgb4/sge.c:1198:6: error: implicit 
>> declaration of function 'xfrm_offload' 
>> [-Werror=implicit-function-declaration]
 if (xfrm_offload(skb) && !ssi->gso_size)
 ^~~~
   cc1: some warnings being treated as errors

vim +/xfrm_offload +1198 drivers/net//ethernet/chelsio/cxgb4/sge.c

  1177  
  1178  /*
  1179   * The chip min packet length is 10 octets but play safe and 
reject
  1180   * anything shorter than an Ethernet header.
  1181   */
  1182  if (unlikely(skb->len < ETH_HLEN)) {
  1183  out_free:   dev_kfree_skb_any(skb);
  1184  return NETDEV_TX_OK;
  1185  }
  1186  
  1187  /* Discard the packet if the length is greater than mtu */
  1188  max_pkt_len = ETH_HLEN + dev->mtu;
  1189  if (skb_vlan_tagged(skb))
  1190  max_pkt_len += VLAN_HLEN;
  1191  if (!skb_shinfo(skb)->gso_size && (unlikely(skb->len > 
max_pkt_len)))
  1192  goto out_free;
  1193  
  1194  pi = netdev_priv(dev);
  1195  adap = pi->adapter;
  1196  ssi = skb_shinfo(skb);
  1197  
> 1198  if (xfrm_offload(skb) && !ssi->gso_size)
  1199  return adap->uld[CXGB4_ULD_CRYPTO].tx_handler(skb, dev);
  1200  
  1201  qidx = skb_get_queue_mapping(skb);
  1202  if (ptp_enabled) {
  1203  spin_lock(>ptp_lock);
  1204  if (!(adap->ptp_tx_skb)) {
  1205  skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
  1206  adap->ptp_tx_skb = skb_get(skb);
  1207  } else {
  1208  spin_unlock(>ptp_lock);
  1209  goto out_free;
  1210  }
  1211  q = >sge.ptptxq;
  1212  } else {
  1213  q = >sge.ethtxq[qidx + pi->first_qset];
  1214  }
  1215  skb_tx_timestamp(skb);
  1216  
  1217  cxgb4_reclaim_completed_tx(adap, >q, true);
  1218  cntrl = TXPKT_L4CSUM_DIS_F | TXPKT_IPCSUM_DIS_F;
  1219  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH net-next 2/2] net sched act_vlan: VLAN action rewrite to use RCU lock/unlock and update

[kbuild test robot]

Hi Manish,

Thank you for the patch! Yet we hit a small issue.
[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Manish-Kurup/net-sched-act_vlan-Change-stats-update-to-use-per-core-stats/20171029-053449
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   In file included from include/asm-generic/bug.h:4:0,
from arch/ia64/include/asm/bug.h:12,
from include/linux/bug.h:4,
from include/linux/bitfield.h:18,
from drivers/net/ethernet/netronome/nfp/flower/action.c:34:
   drivers/net/ethernet/netronome/nfp/flower/action.c: In function 
'nfp_fl_push_vlan':
>> drivers/net/ethernet/netronome/nfp/flower/action.c:70:41: error: 'struct 
>> tcf_vlan' has no member named 'tcfv_push_prio'
  FIELD_PREP(NFP_FL_PUSH_VLAN_PRIO, vlan->tcfv_push_prio) |
^
   include/linux/compiler.h:553:19: note: in definition of macro 
'__compiletime_assert'
  bool __cond = !(condition);\
  ^
   include/linux/compiler.h:576:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^~~
   include/linux/build_bug.h:46:37: note: in expansion of macro 
'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
   include/linux/bitfield.h:56:3: note: in expansion of macro 'BUILD_BUG_ON_MSG'
  BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?  \
  ^~~~
   include/linux/bitfield.h:88:3: note: in expansion of macro '__BF_FIELD_CHECK'
  __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: "); \
  ^~~~
   drivers/net/ethernet/netronome/nfp/flower/action.c:70:3: note: in expansion 
of macro 'FIELD_PREP'
  FIELD_PREP(NFP_FL_PUSH_VLAN_PRIO, vlan->tcfv_push_prio) |
  ^~
>> drivers/net/ethernet/netronome/nfp/flower/action.c:70:41: error: 'struct 
>> tcf_vlan' has no member named 'tcfv_push_prio'
  FIELD_PREP(NFP_FL_PUSH_VLAN_PRIO, vlan->tcfv_push_prio) |
^
   include/linux/compiler.h:553:19: note: in definition of macro 
'__compiletime_assert'
  bool __cond = !(condition);\
  ^
   include/linux/compiler.h:576:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^~~
   include/linux/build_bug.h:46:37: note: in expansion of macro 
'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
   include/linux/bitfield.h:56:3: note: in expansion of macro 'BUILD_BUG_ON_MSG'
  BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?  \
  ^~~~
   include/linux/bitfield.h:88:3: note: in expansion of macro '__BF_FIELD_CHECK'
  __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: "); \
  ^~~~
   drivers/net/ethernet/netronome/nfp/flower/action.c:70:3: note: in expansion 
of macro 'FIELD_PREP'
  FIELD_PREP(NFP_FL_PUSH_VLAN_PRIO, vlan->tcfv_push_prio) |
  ^~
   In file included from 
drivers/net/ethernet/netronome/nfp/flower/action.c:34:0:
>> drivers/net/ethernet/netronome/nfp/flower/action.c:70:41: error: 'struct 
>> tcf_vlan' has no member named 'tcfv_push_prio'
  FIELD_PREP(NFP_FL_PUSH_VLAN_PRIO, vlan->tcfv_push_prio) |
^
   include/linux/bitfield.h:89:20: note: in definition of macro 'FIELD_PREP'
  ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask); \
   ^~~~
   In file included from include/asm-generic/bug.h:4:0,
from arch/ia64/include/asm/bug.h:12,
from include/linux/bug.h:4,
from include/linux/bitfield.h:18,
from drivers/net/ethernet/netronome/nfp/flower/action.c:34:
>> drivers/net/ethernet/netronome/nfp/flower/action.c:71:40: error: 'struct 
>> tcf_vlan' has no member named 'tcfv_push_vid'
  FIELD_PREP(NFP_FL_PUSH_VLAN_VID, vlan->tcfv_push_vid) |
   ^
   include/linux/compiler.h:553:19: note: in definition of macro 
'__compiletime_assert'
  bool __cond = !(condition);\
  ^
   include/linux/compiler.h:576:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^~~
   

Re: [PATCH V2 net] tuntap: properly align skb->head before building skb

[Wei Wei]

With this patch, the crash can’t be reproduced with the syz-repro and crash 
log0/log1.

The auto-generated reproducers are here: 
https://github.com/dotweiba/skb_clone_atomic_inc_bug

Thanks,
Wei
> On 28 Oct 2017, at 6:06 AM, David Miller  wrote:
> 
> From: Jason Wang 
> Date: Fri, 27 Oct 2017 11:05:44 +0800
> 
>> An unaligned alloc_frag->offset caused by previous allocation will
>> result an unaligned skb->head. This will lead unaligned
>> skb_shared_info and then unaligned dataref which requires to be
>> aligned for accessing on some architecture. Fix this by aligning
>> alloc_frag->offset before the frag refilling.
>> 
>> Fixes: 0bbd7dad34f8 ("tun: make tun_build_skb() thread safe")
>> Cc: Eric Dumazet 
>> Cc: Willem de Bruijn 
>> Cc: Wei Wei 
>> Cc: Dmitry Vyukov 
>> Cc: Mark Rutland 
>> Reported-by: Wei Wei 
>> Signed-off-by: Jason Wang 
> 
> Applied and queued up for -stable, thanks Jason.

Re: [PATCH] phylink: Use common error handling code in phylink_create()

[Russell King - ARM Linux]

On Sat, Oct 28, 2017 at 10:00:33PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 28 Oct 2017 21:48:31 +0200
> 
> * Add a jump target so that a bit of exception handling can be better
>   reused at the end of this function.
> 
> * Adjust three condition checks.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Russell King 

Thanks.

> ---
>  drivers/net/phy/phylink.c | 22 ++
>  1 file changed, 10 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index bcb4755bcd95..67b19c13f405 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -533,26 +533,24 @@ struct phylink *phylink_create(struct net_device *ndev, 
> struct device_node *np,
>   phylink_validate(pl, pl->supported, >link_config);
>  
>   ret = phylink_parse_mode(pl, np);
> - if (ret < 0) {
> - kfree(pl);
> - return ERR_PTR(ret);
> - }
> + if (ret)
> + goto free_link;
>  
>   if (pl->link_an_mode == MLO_AN_FIXED) {
>   ret = phylink_parse_fixedlink(pl, np);
> - if (ret < 0) {
> - kfree(pl);
> - return ERR_PTR(ret);
> - }
> + if (ret)
> + goto free_link;
>   }
>  
>   ret = phylink_register_sfp(pl, np);
> - if (ret < 0) {
> - kfree(pl);
> - return ERR_PTR(ret);
> - }
> + if (ret)
> + goto free_link;
>  
>   return pl;
> +
> +free_link:
> + kfree(pl);
> + return ERR_PTR(ret);
>  }
>  EXPORT_SYMBOL_GPL(phylink_create);
>  
> -- 
> 2.14.3
> 

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH] phylink: Use common error handling code in phylink_create()

[Florian Fainelli]

On 10/28/2017 01:00 PM, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 28 Oct 2017 21:48:31 +0200
> 
> * Add a jump target so that a bit of exception handling can be better
>   reused at the end of this function.
> 
> * Adjust three condition checks.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Reviewed-by: Florian Fainelli 
-- 
Florian

[PATCH] lan78xx: Use common error handling code in lan78xx_phy_init()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 28 Oct 2017 22:42:52 +0200

* Add a jump target so that a specific error message is stored only once
  at the end of this function implementation.

* Replace two calls of the function "netdev_err" by goto statements.

* Adjust two condition checks.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/net/usb/lan78xx.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 0161f77641fa..ff07e20621e3 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2030,17 +2030,15 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
/* external PHY fixup for KSZ9031RNX */
ret = phy_register_fixup_for_uid(PHY_KSZ9031RNX, 0xfff0,
 ksz9031rnx_fixup);
-   if (ret < 0) {
-   netdev_err(dev->net, "fail to register fixup\n");
-   return ret;
-   }
+   if (ret)
+   goto report_fixup_failure;
+
/* external PHY fixup for LAN8835 */
ret = phy_register_fixup_for_uid(PHY_LAN8835, 0xfff0,
 lan8835_fixup);
-   if (ret < 0) {
-   netdev_err(dev->net, "fail to register fixup\n");
-   return ret;
-   }
+   if (ret)
+   goto report_fixup_failure;
+
/* add more external PHY fixup here if needed */
 
phydev->is_internal = false;
@@ -2093,6 +2091,10 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
phy_unregister_fixup_for_uid(PHY_LAN8835, 0xfff0);
 
return ret;
+
+report_fixup_failure:
+   netdev_err(dev->net, "fail to register fixup\n");
+   return ret;
 }
 
 static int lan78xx_set_rx_max_frame_length(struct lan78xx_net *dev, int size)
-- 
2.14.3

Re: [PATCH] ipv6: exthdrs: use swap macro in ipv6_dest_hao

[Gustavo A. R. Silva]

Quoting David Miller :


From: "Gustavo A. R. Silva" 
Date: Thu, 26 Oct 2017 23:10:35 -0500


make use of the swap macro and remove unnecessary variable tmp_addr.
This makes the code easier to read and maintain.

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 


Applied to net-next, thanks.


Glad to help.

Thanks
--
Gustavo A. R. Silva

[PATCH] net: dccp: ccids: lib: packet_history: use swap macro in tfrc_rx_hist_swap

[Gustavo A. R. Silva]

Make use of the swap macro and remove unnecessary variable tmp.
This makes the code easier to read and maintain.

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 net/dccp/ccids/lib/packet_history.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/net/dccp/ccids/lib/packet_history.c 
b/net/dccp/ccids/lib/packet_history.c
index 08df7a3..876e185 100644
--- a/net/dccp/ccids/lib/packet_history.c
+++ b/net/dccp/ccids/lib/packet_history.c
@@ -149,10 +149,8 @@ static void tfrc_rx_hist_swap(struct tfrc_rx_hist *h, 
const u8 a, const u8 b)
 {
const u8 idx_a = tfrc_rx_hist_index(h, a),
 idx_b = tfrc_rx_hist_index(h, b);
-   struct tfrc_rx_hist_entry *tmp = h->ring[idx_a];
 
-   h->ring[idx_a] = h->ring[idx_b];
-   h->ring[idx_b] = tmp;
+   swap(h->ring[idx_a], h->ring[idx_b]);
 }
 
 /*
-- 
2.7.4

[PATCH] net: decnet: dn_nsp_out: use swap macro in dn_mk_ack_header

[Gustavo A. R. Silva]

Make use of the swap macro and remove unnecessary variable tmp.
This makes the code easier to read and maintain.

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 net/decnet/dn_nsp_out.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/net/decnet/dn_nsp_out.c b/net/decnet/dn_nsp_out.c
index e50a4ad..56a52a0 100644
--- a/net/decnet/dn_nsp_out.c
+++ b/net/decnet/dn_nsp_out.c
@@ -313,11 +313,8 @@ static __le16 *dn_mk_ack_header(struct sock *sk, struct 
sk_buff *skb, unsigned c
ackcrs |= 0x8000;
 
/* If this is an "other data/ack" message, swap acknum and ackcrs */
-   if (other) {
-   unsigned short tmp = acknum;
-   acknum = ackcrs;
-   ackcrs = tmp;
-   }
+   if (other)
+   swap(acknum, ackcrs);
 
/* Set "cross subchannel" bit in ackcrs */
ackcrs |= 0x2000;
-- 
2.7.4

[PATCH] netfilter: ipset: ip_set_bitmap_port: use swap macro in bitmap_port_create

[Gustavo A. R. Silva]

Make use of the swap macro and remove unnecessary variable tmp.
This makes the code easier to read and maintain.

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 net/netfilter/ipset/ip_set_bitmap_port.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/net/netfilter/ipset/ip_set_bitmap_port.c 
b/net/netfilter/ipset/ip_set_bitmap_port.c
index 7f9bbd7..b561ca8 100644
--- a/net/netfilter/ipset/ip_set_bitmap_port.c
+++ b/net/netfilter/ipset/ip_set_bitmap_port.c
@@ -238,12 +238,8 @@ bitmap_port_create(struct net *net, struct ip_set *set, 
struct nlattr *tb[],
 
first_port = ip_set_get_h16(tb[IPSET_ATTR_PORT]);
last_port = ip_set_get_h16(tb[IPSET_ATTR_PORT_TO]);
-   if (first_port > last_port) {
-   u16 tmp = first_port;
-
-   first_port = last_port;
-   last_port = tmp;
-   }
+   if (first_port > last_port)
+   swap(first_port, last_port);
 
elements = last_port - first_port + 1;
set->dsize = ip_set_elem_len(set, tb, 0, 0);
-- 
2.7.4

[PATCH] netfilter: ipset: ip_set_bitmap_ip: use swap macro in bitmap_ip_create

[Gustavo A. R. Silva]

Make use of the swap macro and remove unnecessary variable tmp.
This makes the code easier to read and maintain.

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 net/netfilter/ipset/ip_set_bitmap_ip.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/net/netfilter/ipset/ip_set_bitmap_ip.c 
b/net/netfilter/ipset/ip_set_bitmap_ip.c
index d8975a0..488d6d0 100644
--- a/net/netfilter/ipset/ip_set_bitmap_ip.c
+++ b/net/netfilter/ipset/ip_set_bitmap_ip.c
@@ -263,12 +263,8 @@ bitmap_ip_create(struct net *net, struct ip_set *set, 
struct nlattr *tb[],
ret = ip_set_get_hostipaddr4(tb[IPSET_ATTR_IP_TO], _ip);
if (ret)
return ret;
-   if (first_ip > last_ip) {
-   u32 tmp = first_ip;
-
-   first_ip = last_ip;
-   last_ip = tmp;
-   }
+   if (first_ip > last_ip)
+   swap(first_ip, last_ip);
} else if (tb[IPSET_ATTR_CIDR]) {
u8 cidr = nla_get_u8(tb[IPSET_ATTR_CIDR]);
 
-- 
2.7.4

[PATCH] netfilter: ipset: ip_set_bitmap_ipmac: use swap macro in bitmap_ipmac_create

[Gustavo A. R. Silva]

Make use of the swap macro and remove unnecessary variable tmp.
This makes the code easier to read and maintain.

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 net/netfilter/ipset/ip_set_bitmap_ipmac.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/net/netfilter/ipset/ip_set_bitmap_ipmac.c 
b/net/netfilter/ipset/ip_set_bitmap_ipmac.c
index 4c279fb..c00b6a2 100644
--- a/net/netfilter/ipset/ip_set_bitmap_ipmac.c
+++ b/net/netfilter/ipset/ip_set_bitmap_ipmac.c
@@ -337,12 +337,8 @@ bitmap_ipmac_create(struct net *net, struct ip_set *set, 
struct nlattr *tb[],
ret = ip_set_get_hostipaddr4(tb[IPSET_ATTR_IP_TO], _ip);
if (ret)
return ret;
-   if (first_ip > last_ip) {
-   u32 tmp = first_ip;
-
-   first_ip = last_ip;
-   last_ip = tmp;
-   }
+   if (first_ip > last_ip)
+   swap(first_ip, last_ip);
} else if (tb[IPSET_ATTR_CIDR]) {
u8 cidr = nla_get_u8(tb[IPSET_ATTR_CIDR]);
 
-- 
2.7.4

Re: can: Use common error handling code in vxcan_newlink()

[SF Markus Elfring]

>> Are you interested in related adjustments for a bigger code base?
> 
> No. Definitely not.

You might have noticed that I am proposing similar changes already
for other software modules.   ;-)


> If you aim for the the deletion of “ < 0” for all rtnl_configure_link() users
> you would need to do this consistently.

How do you see the software situation around a function
like “register_netdevice”?

Regards,
Markus

[PATCH] net: decnet: dn_nsp_in: use swap macro in dn_nsp_rx_packet

[Gustavo A. R. Silva]

Make use of the swap macro and remove unnecessary variable tmp.
This makes the code easier to read and maintain.

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 net/decnet/dn_nsp_in.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/net/decnet/dn_nsp_in.c b/net/decnet/dn_nsp_in.c
index 7ac086d..1b212064 100644
--- a/net/decnet/dn_nsp_in.c
+++ b/net/decnet/dn_nsp_in.c
@@ -776,12 +776,8 @@ static int dn_nsp_rx_packet(struct net *net, struct sock 
*sk2,
 * Swap src & dst and look up in the normal way.
 */
if (unlikely(cb->rt_flags & DN_RT_F_RTS)) {
-   __le16 tmp = cb->dst_port;
-   cb->dst_port = cb->src_port;
-   cb->src_port = tmp;
-   tmp = cb->dst;
-   cb->dst = cb->src;
-   cb->src = tmp;
+   swap(cb->dst_port, cb->src_port);
+   swap(cb->dst, cb->src);
}
 
/*
-- 
2.7.4

Re: can: Use common error handling code in vxcan_newlink()

[Oliver Hartkopp]

On 10/28/2017 08:33 PM, SF Markus Elfring wrote:

So if you would like to change the if-statement:


It will need a small adjustment for the shown transformation.

I was also unsure if the proposal will work in a single update step.



1. Send a patch for vxcan.c to improve the error handling flow


I am going to send a second approach for this update variant.


Ok.




2. Send a separate patch for all rtnl_configure_link() callers to unify the 
result check

Step 2 is optional ... and prepare yourself for more feedback ;-)


I am curious on how software development aspects will evolve around
desired error predicates.
Which scope did you have in mind?


Oh, I don't have any scope in mind.

I just wanted to make clear that I don't want to have a different kind 
of result handling in vxcan.c and veth.c


So if you suggest to simplify the error flow that would be ok for me.

If you want to change the semantic of the result check - this has to 
done consistently at all rtnl_configure_link() caller sites. And not 
only in vxcan.c


That's what I have in mind.

Regards,
Oliver

Re: [PATCH v7 net-next 00/13] gtp: Additional feature support - Part I

[Tom Herbert]

On Sat, Oct 28, 2017 at 9:47 AM, Harald Welte  wrote:
> Hi Tom,
>
> On Sat, Oct 28, 2017 at 09:16:01AM -0700, Tom Herbert wrote:
>> Here is what the Kconfig for the EXPERIMENTAL option says:
>>
>> "This is an experimental implementation that allows encapsulating IPv6
>> over GTP and using GTP over IPv6 for testing and development purposes.
>> This is not a standards conformant implementation for IPv6 and GTP.
>> More work is needed to reach that level."
>>
>> I don't see any ambiguity here about it not being standards complete.
>> Nor is there any ambiguity about the its purpose to enable further
>> development and the fact that more work is needed.
>
> As stated repeatedly: I have no issue with an *incomplete* implementation,
> but I have a problem with an *incompatible* one that takes left turns
> where the spec takes right turns.
>
> An *incomplete* implementation could still interoperate with other
> implementations but is e.g. missing some optional bits.  It can later
> extended with those missing bits and wills stay compatible to users of
> the incomplete as well as to any later complete implementation.
>
> An *incompatible* implementation is what I have issues with.
>
>> This a foundation for an IPv6 datapath and is sufficient to do
>> benchmarking and performance to determine the prospects of replacing
>> proprietary HW with commodity servers running Linux kernel.
>
> I completely agree with that.
>
>> This is a forward step to get IPv6 into GTP, and frankly the _only_ code that
>> has been proposed. There is no reason why someone can't build upon
>> this to make a first rate conformant implementation.
>
> I also agree with this.  However, I don't think it makes sense to have it in
> the kernel given it implements something that's actually not GTP as per
> the relevant specs.  No matter how many disclaimers you put at it,
> people will still assume it's GTP if it's called GTP.  And if it's only
> useful for benchmarking the poential of a later proper IPv6
> implementation, I don't think it should go in.
>
>> In any case, I've invested as much time in this as I can for now. I'll
>> leave it up to DaveM to decide if we wants to take all, none, or some
>> subset of these patches.
>
> Thanks.  As indicated, I'm planning some testing later this weekend on
> the non-IPv6 patches, and am happy to add my Acked-by and/or re-submit
> those to Dave after that.
>
> For sure, the kernel networking maintainer can merge any patches,
> including the proposed IPv6 patches as-is, and I will accept that.  But
> my vote as the original author and co-maintainer of the kernel GTP code
> goes politely and respectfully against that - as I have made quite clear
> by now.
>
It's been more than a year since the GTP patches went in and I asked
about a IPv6 support-- we haven't heard a peep since then until I
posted these patches. IMO, no IPv6 support for something that could
support it is a _major_ bug-- we are well past the where it's
acceptable to put support in for IPv4 because the "customer uses it"
and "we'll get around to IPv6 later". Customers are using IPv6!
Failure to support it is doing nothing more than holding the protocol
back as well as the kernel, In mobile this especially true, IPv6 is
going to eclipse IPv4. We need GTP kernel to support IPv6!

So, if you don't like these patches and don't think it's the right
direction, that's fine, but as maintainer then please tell us the plan
and timeline to get IPv6 supported in GTP.

Tom


> Thanks + Regards,
> Harald
>
> --
> - Harald Welte    http://laforge.gnumonks.org/
> 
> "Privacy in residential applications is a desirable marketing option."
>   (ETSI EN 300 175-7 Ch. A6)

Re: can: Use common error handling code in vxcan_newlink()

[SF Markus Elfring]

> So if you would like to change the if-statement:

It will need a small adjustment for the shown transformation.

I was also unsure if the proposal will work in a single update step.


> 1. Send a patch for vxcan.c to improve the error handling flow

I am going to send a second approach for this update variant.


> 2. Send a separate patch for all rtnl_configure_link() callers to unify the 
> result check
> 
> Step 2 is optional ... and prepare yourself for more feedback ;-)

I am curious on how software development aspects will evolve around
desired error predicates.
Which scope did you have in mind?

Regards,
Markus

[PATCH] netcp_core: Use common error handling code in netcp_create_interface()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 28 Oct 2017 20:11:02 +0200

Add a jump target so that a specific error code assignment is stored
only once at the end of this function implementation.
Replace five assignments by goto statements.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/net/ethernet/ti/netcp_core.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/ti/netcp_core.c 
b/drivers/net/ethernet/ti/netcp_core.c
index 437d36289786..8fb17df6daa8 100644
--- a/drivers/net/ethernet/ti/netcp_core.c
+++ b/drivers/net/ethernet/ti/netcp_core.c
@@ -2009,8 +2009,7 @@ static int netcp_create_interface(struct netcp_device 
*netcp_device,
if (efuse_mac) {
if (of_address_to_resource(node, NETCP_EFUSE_REG_INDEX, )) {
dev_err(dev, "could not find efuse-mac reg resource\n");
-   ret = -ENODEV;
-   goto quit;
+   goto failure_indication;
}
size = resource_size();
 
@@ -2049,8 +2048,7 @@ static int netcp_create_interface(struct netcp_device 
*netcp_device,
  >dma_chan_name);
if (ret < 0) {
dev_err(dev, "missing \"rx-channel\" parameter\n");
-   ret = -ENODEV;
-   goto quit;
+   goto failure_indication;
}
 
ret = of_property_read_u32(node_interface, "rx-queue",
@@ -2071,8 +2069,7 @@ static int netcp_create_interface(struct netcp_device 
*netcp_device,
ret = of_property_read_u32_array(node_interface, "rx-pool", temp, 2);
if (ret < 0) {
dev_err(dev, "missing \"rx-pool\" parameter\n");
-   ret = -ENODEV;
-   goto quit;
+   goto failure_indication;
}
netcp->rx_pool_size = temp[0];
netcp->rx_pool_region_id = temp[1];
@@ -2080,8 +2077,7 @@ static int netcp_create_interface(struct netcp_device 
*netcp_device,
ret = of_property_read_u32_array(node_interface, "tx-pool", temp, 2);
if (ret < 0) {
dev_err(dev, "missing \"tx-pool\" parameter\n");
-   ret = -ENODEV;
-   goto quit;
+   goto failure_indication;
}
netcp->tx_pool_size = temp[0];
netcp->tx_pool_region_id = temp[1];
@@ -2089,8 +2085,7 @@ static int netcp_create_interface(struct netcp_device 
*netcp_device,
if (netcp->tx_pool_size < MAX_SKB_FRAGS) {
dev_err(dev, "tx-pool size too small, must be atleast(%ld)\n",
MAX_SKB_FRAGS);
-   ret = -ENODEV;
-   goto quit;
+   goto failure_indication;
}
 
ret = of_property_read_u32(node_interface, "tx-completion-queue",
@@ -2113,6 +2108,8 @@ static int netcp_create_interface(struct netcp_device 
*netcp_device,
list_add_tail(>interface_list, _device->interface_head);
return 0;
 
+failure_indication:
+   ret = -ENODEV;
 quit:
free_netdev(ndev);
return ret;
-- 
2.14.3

Re: [PATCH v3 0/2] refactor code and mark expected switch fall-throughs

[David Ranch]

Hello Gustavo,

Thanks for the reply.  I do appreciate the work but we've had other 
people contribute to keep things up to date but previous minor patches 
broke parts of the AX.25 stack in strange ways.  The fixes weren't hard 
to repair or backout but due to the timing, various Linux distros based 
their releases on the broken kernel code and it's taken a LONG time to
get things healthy for them.  We need be able provide a test harness to 
developers to unit test / regression test their proposed code ideally 
AHEAD of the commit but at least after the commit.


I'm still failing to find any Linux groups that offer some sort of 
automated build & test environment (Travis, Jenkins, etc) tracking 
various kernel branches, etc.  It's gotta be out there (many of them in 
fact) but I'm struggling to find them.


For example, here is an excellent article about what *Intel* is doing 
for their graphics drivers but I need something that the general 
community can leverage for say various protocol stacks (TCP/IP, AX.25, 
whatever):


   https://lwn.net/Articles/735468/

From that article, it seems that maybe this could be a good place to start:

   https://01.org/lkp
   https://github.com/intel/lkp-tests

Looks like a good start but is that what the majority of the Linux 
kernel folk use today?  Is it the right group for non-scaled out unit 
testing that I seek?  I also think this email-centric approach might be 
an overly broad approach with WAY too much noise for various development 
areas.


Does anyone else have thoughts on this topic?

--David
KI6ZHD


On 10/27/2017 12:48 PM, Gustavo A. R. Silva wrote:

Hi David,

Quoting David Ranch :


Hello Gustavo,

I appreciate you working on keeping up the kernel and maintaining some
of the older feature areas like AX.25, Netrom, etc.  Other than
auditing your code changes, can you tell me what you're changing? I've
been attempting to find who / where does regression tests for the
Linus kernel to potentially ADD test suites for this area.  In the
recent past, we have seen a lot of toxicity creep into the kernel
because no one is testing their changes and backing out this toxic
code out of released Linux distributions takes a VERY long time.



Here you can see the patch I'm proposing to refactor some code:
https://patchwork.kernel.org/patch/10029119/

It does not add any new functionality. It's just a small function that
helps to modularize and reduce the size of the code in the nr_add_node()
function.

The function I'm proposing (re_sort_routes) re-sort the routes in
quality order. It takes as arguments a pointer to the nr_node structure
which contains the routes within and the indexes of the routes to re-sort.

This function also replaces a "manual" swap of the routes with a call to
the swap macro.

Thanks
--
Gustavo A. R. Silva


I'm willing to try and help here but I really would like to follow
some team's guidelines of how they would like tests to be created,
supported, etc.  Be it in VMs, containers, specific automation
languages, etc.

--David
KI6ZHD




On 10/26/2017 10:50 PM, Gustavo A. R. Silva wrote:

The aim of this patchset is firstly to refactor code in nr_route.c in
order to make it
easier to read and maintain and, secondly, to mark some expected
switch fall-throughs
in preparation to enabling -Wimplicit-fallthrough.

I have to mention that I did not implement any unit test.
If someone has any suggestions on how I could test this piece of code
it'd be greatly appreciated.

Thanks

Changes in v2:
 - Make use of the swap macro and remove inline keyword as suggested by
   Walter Harms and Kevin Dawson.

Changes in v3:
 - Update subject for both patches.
 - Add this cover letter as suggested by David Miller.

Gustavo A. R. Silva (2):
  net: netrom: nr_route: refactor code in nr_add_node
  net: netrom: nr_route: mark expected switch fall-throughs

 net/netrom/nr_route.c | 62
---
 1 file changed, 19 insertions(+), 43 deletions(-)

[PATCH iproute2/net-next]tc: B.W limits can now be specified in %

[Nishanth Devarajan]

This patch adapts the tc command line interface to allow bandwidth limits
to be specified as a percentage of the interface's capacity.

For this purpose, we move int read_prop() from ip/iptuntap.c to
lib/utils.c to make it accessible to tc.

Additionally, adding this functionality requires passing the specified
device string to each class/qdisc which changes the prototype for a
couple of functions: the .parse_qopt and .parse_copt interfaces. The
device string is a required parameter for tc-qdisc and tc-class, and when
not specified, the kernel return ENODEV. In this patch, if the user tries
to specify a bandwidth percentage without naming the device, we return an
error from userspace.

Signed-off-by: Nishanth Devarajan 
---
 include/utils.h |  1 +
 ip/iptuntap.c   | 32 
 lib/utils.c | 32 
 man/man8/tc.8   |  4 +++-
 tc/q_atm.c  |  2 +-
 tc/q_cbq.c  | 25 -
 tc/q_choke.c|  9 +++--
 tc/q_clsact.c   |  2 +-
 tc/q_codel.c|  2 +-
 tc/q_drr.c  |  4 ++--
 tc/q_dsmark.c   |  4 ++--
 tc/q_fifo.c |  2 +-
 tc/q_fq.c   | 16 +---
 tc/q_fq_codel.c |  2 +-
 tc/q_gred.c |  9 +++--
 tc/q_hfsc.c | 45 ++---
 tc/q_hhf.c  |  2 +-
 tc/q_htb.c  | 18 ++
 tc/q_ingress.c  |  2 +-
 tc/q_mqprio.c   |  2 +-
 tc/q_multiq.c   |  2 +-
 tc/q_netem.c|  9 +++--
 tc/q_pie.c  |  2 +-
 tc/q_prio.c |  2 +-
 tc/q_qfq.c  |  4 ++--
 tc/q_red.c  |  9 +++--
 tc/q_rr.c   |  2 +-
 tc/q_sfb.c  |  2 +-
 tc/q_sfq.c  |  2 +-
 tc/q_tbf.c  | 16 +---
 tc/tc.c |  2 +-
 tc/tc_class.c   |  2 +-
 tc/tc_qdisc.c   |  2 +-
 tc/tc_util.c| 54 ++
 tc/tc_util.h|  8 ++--
 35 files changed, 237 insertions(+), 96 deletions(-)

diff --git a/include/utils.h b/include/utils.h
index 3d91c50..63fea7c 100644
--- a/include/utils.h
+++ b/include/utils.h
@@ -87,6 +87,7 @@ int get_prefix(inet_prefix *dst, char *arg, int family);
 int mask2bits(__u32 netmask);
 int get_addr_ila(__u64 *val, const char *arg);
 
+int read_prop(char *dev, char *prop, long *value);
 int get_hex(char c);
 int get_integer(int *val, const char *arg, int base);
 int get_unsigned(unsigned *val, const char *arg, int base);
diff --git a/ip/iptuntap.c b/ip/iptuntap.c
index b46e452..09f2be2 100644
--- a/ip/iptuntap.c
+++ b/ip/iptuntap.c
@@ -223,38 +223,6 @@ static int do_del(int argc, char **argv)
return tap_del_ioctl();
 }
 
-static int read_prop(char *dev, char *prop, long *value)
-{
-   char fname[IFNAMSIZ+25], buf[80], *endp;
-   ssize_t len;
-   int fd;
-   long result;
-
-   sprintf(fname, "/sys/class/net/%s/%s", dev, prop);
-   fd = open(fname, O_RDONLY);
-   if (fd < 0) {
-   if (strcmp(prop, "tun_flags"))
-   fprintf(stderr, "open %s: %s\n", fname,
-   strerror(errno));
-   return -1;
-   }
-   len = read(fd, buf, sizeof(buf)-1);
-   close(fd);
-   if (len < 0) {
-   fprintf(stderr, "read %s: %s", fname, strerror(errno));
-   return -1;
-   }
-
-   buf[len] = 0;
-   result = strtol(buf, , 0);
-   if (*endp != '\n') {
-   fprintf(stderr, "Failed to parse %s\n", fname);
-   return -1;
-   }
-   *value = result;
-   return 0;
-}
-
 static void print_flags(long flags)
 {
if (flags & IFF_TUN)
diff --git a/lib/utils.c b/lib/utils.c
index ac155bf..444c978 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -39,6 +39,38 @@
 
 int timestamp_short;
 
+int read_prop(char *dev, char *prop, long *value)
+{
+   char fname[41], buf[80], *endp;
+   ssize_t len;
+   int fd;
+   long result;
+
+   sprintf(fname, "/sys/class/net/%s/%s", dev, prop);
+   fd = open(fname, O_RDONLY);
+   if (fd < 0) {
+   if (strcmp(prop, "tun_flags"))
+   fprintf(stderr, "open %s: %s\n", fname,
+   strerror(errno));
+   return -1;
+   }
+   len = read(fd, buf, sizeof(buf)-1);
+   close(fd);
+   if (len < 0) {
+   fprintf(stderr, "read %s: %s", fname, strerror(errno));
+   return -1;
+   }
+
+   buf[len] = 0;
+   result = strtol(buf, , 0);
+   if (*endp != '\n') {
+   fprintf(stderr, "Failed to parse %s\n", fname);
+   return -1;
+   }
+   *value = result;
+   return 0;
+}
+
 int get_hex(char c)
 {
if (c >= 'A' && c <= 'F')
diff --git a/man/man8/tc.8 b/man/man8/tc.8
index f96911a..22f699b 100644
--- a/man/man8/tc.8
+++ b/man/man8/tc.8
@@ -443,7 +443,9 @@ see the man pages for individual qdiscs.
 RATES
 Bandwidths or rates.
 These parameters accept a floating point number, possibly followed by
-a 

Re: [PATCH] can: Use common error handling code in vxcan_newlink()

[Oliver Hartkopp]

On 10/28/2017 10:23 AM, SF Markus Elfring wrote:

@@ -227,10 +227,8 @@ static int vxcan_newlink(struct net *net, struct 
net_device *dev,
   netif_carrier_off(peer);
     err = rtnl_configure_link(peer, ifmp);
-    if (err < 0) {
-    unregister_netdevice(peer);
-    return err;
-    }
+    if (err)
+    goto unregister_network_device;


You are changing semantic in the if-statement here.


I got an other software development opinion for this implementation detail.

http://elixir.free-electrons.com/linux/v4.14-rc6/source/net/core/rtnetlink.c#L2393
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/net/core/rtnetlink.c?id=36ef71cae353f88fd6e095e2aaa3e5953af1685d#n2513

The success predicate for the function “rtnl_configure_link” is that
the return value is zero. I would prefer to treat other values as
an error code then.


Me not.

In rtnl_configure_link() the check is

if (err < 0)
return err;

And other calling sites as in linux/drivers/net/veth.c are checking for

(err < 0)

too.

All checks done at the calling sites should be consistent.

So if you would like to change the if-statement:

1. Send a patch for vxcan.c to improve the error handling flow
2. Send a separate patch for all rtnl_configure_link() callers to unify 
the result check


Step 2 is optional ... and prepare yourself for more feedback ;-)

Regards,
Oliver

Re: Linux 4.14-rc6 bisected regression tun devices not working anymore in openvpn

[Cong Wang]

On Sat, Oct 28, 2017 at 7:57 AM, Sander Eikelenboom
 wrote:
> L.S.,
>
> While testing a linux 4.14-rc6 kernel i noticed OpenVPN didn't function 
> anymore.
> My openvpn config uses tun devices and is pretty standard.
> The openvpn version is current Debian stable: openvpn 2.4.0-6+deb9u2
>
> From the openvpn logging:
> Sat Oct 28 16:03:34 2017 us=175829 TUN/TAP device  opened
> Sat Oct 28 16:03:34 2017 us=183027 Note: Cannot set tx queue length on : 
> No such device (errno=19)
> Sat Oct 28 16:03:34 2017 us=183055 do_ifconfig, 
> tt->did_ifconfig_ipv6_setup=0
> Sat Oct 28 16:03:34 2017 us=183071 /sbin/ip link set dev  up mtu 1500
> Cannot find device ""
> Sat Oct 28 16:03:34 2017 us=200445 Linux ip link set failed: external 
> program exited with error status: 1
> Sat Oct 28 16:03:34 2017 us=200482 Exiting due to fatal error
> Sat Oct 28 16:38:17 2017 us=923381 TCP/UDP: Closing socket
> Sat Oct 28 16:38:17 2017 us=925986 Closing TUN/TAP interface
>
>
> The offending commit is:
> 0ad646c81b2182f7fa67ec0c8c825e0ee165696d
> "tun: call dev_get_valid_name() before register_netdevice()"
>
> Reverting this commit fixes the issue for me, it's unfortunate that the 
> commit it self seems to fix an other issue.

It should be fixed by:

commit 5c25f65fd1e42685f7ccd80e0621829c105785d9
Author: Julien Gomes 
Date:   Wed Oct 25 11:50:50 2017 -0700

tun: allow positive return values on dev_get_valid_name() call

If the name argument of dev_get_valid_name() contains "%d", it will try
to assign it a unit number in __dev__alloc_name() and return either the
unit number (>= 0) or an error code (< 0).
Considering positive values as error values prevent tun device creations
relying this mechanism, therefor we should only consider negative values
as errors here.

Signed-off-by: Julien Gomes 
Acked-by: Cong Wang 
Signed-off-by: David S. Miller 


Sorry for the trouble.

Thanks.

Re: [PATCH net-next] ipv6: prevent user from adding cached routes

[Martin KaFai Lau]

On Fri, Oct 27, 2017 at 05:30:12PM -0700, Wei Wang wrote:
> So we fix this by failing the attemp to add cached routes from userspace
> with returning EINVAL error.
Acked-by: Martin KaFai Lau 

[PATCH] ravb: Use common error handling code in ravb_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 28 Oct 2017 19:10:08 +0200

Add a jump target so that a bit of exception handling can be better reused
at the end of this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/net/ethernet/renesas/ravb_main.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index a8822a756e08..62dbdf7de6cd 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2069,10 +2069,9 @@ static int ravb_probe(struct platform_device *pdev)
irq = platform_get_irq_byname(pdev, "ch22");
else
irq = platform_get_irq(pdev, 0);
-   if (irq < 0) {
-   error = irq;
-   goto out_release;
-   }
+   if (irq < 0)
+   goto failure_indication;
+
ndev->irq = irq;
 
SET_NETDEV_DEV(ndev, >dev);
@@ -2101,25 +2100,22 @@ static int ravb_probe(struct platform_device *pdev)
 
if (chip_id == RCAR_GEN3) {
irq = platform_get_irq_byname(pdev, "ch24");
-   if (irq < 0) {
-   error = irq;
-   goto out_release;
-   }
+   if (irq < 0)
+   goto failure_indication;
+
priv->emac_irq = irq;
for (i = 0; i < NUM_RX_QUEUE; i++) {
irq = platform_get_irq_byname(pdev, ravb_rx_irqs[i]);
-   if (irq < 0) {
-   error = irq;
-   goto out_release;
-   }
+   if (irq < 0)
+   goto failure_indication;
+
priv->rx_irqs[i] = irq;
}
for (i = 0; i < NUM_TX_QUEUE; i++) {
irq = platform_get_irq_byname(pdev, ravb_tx_irqs[i]);
-   if (irq < 0) {
-   error = irq;
-   goto out_release;
-   }
+   if (irq < 0)
+   goto failure_indication;
+
priv->tx_irqs[i] = irq;
}
}
@@ -2226,6 +,10 @@ static int ravb_probe(struct platform_device *pdev)
pm_runtime_put(>dev);
pm_runtime_disable(>dev);
return error;
+
+failure_indication:
+   error = irq;
+   goto out_release;
 }
 
 static int ravb_remove(struct platform_device *pdev)
-- 
2.14.3

Re: [patch net-next v2 00/20] net: sched: convert cls ndo_setup_tc offload calls to per-block callbacks

[Jakub Kicinski]

On Sat, 28 Oct 2017 10:43:51 +0200, Jiri Pirko wrote:
> Sat, Oct 28, 2017 at 09:53:21AM CEST, kubak...@wp.pl wrote:
> >On Sat, 28 Oct 2017 09:20:31 +0200, Jiri Pirko wrote:  
> >> Sat, Oct 28, 2017 at 02:52:00AM CEST, kubak...@wp.pl wrote:  
> >> >On Fri, 27 Oct 2017 09:27:30 +0200, Jiri Pirko wrote:
> >> >> Yes, it is the same.
> >> >
> >> >FWIW I also see what Amritha and Alex are describing here, for cls_bpf
> >> >there are no DESTROYs coming on rmmod or qdisc del.  There is a DESTROY
> >> >if I manually remove the filter (or if an ADD with skip_sw fails).
> >> 
> >> Is this different to the original behaviour? Just for cls_bpf?  
> >
> >For cls_bpf the callbacks used to be 100% symmetrical, i.e. destroy
> >would always be guaranteed if add succeeded (regardless of state of
> >skip_* flags).  
> 
> Hmm. It still should be symmetrical. Looking at following path:
> cls_bpf_destroy->
>__cls_bpf_delete->
>   cls_bpf_stop_offload->
>  cls_bpf_offload_cmd(tp, prog, TC_CLSBPF_DESTROY)
> 
> I don't see how any tp could be missed. Could you please check this
> callpath is utilized during your action (rmmod or qdisc del)?

The same path seems to be utilized but the unbind comes before the
filters are destroyed.

Re: [PATCH] nfp: Improve unlocking of a mutex in area_cache_get()

[Jakub Kicinski]

On Sat, 28 Oct 2017 17:18:56 +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 28 Oct 2017 17:12:10 +0200
> 
> Add a jump target so that a call of the function "mutex_unlock" is stored
> only once at the end of this function implementation.
> Replace four calls by goto statements.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Jakub Kicinski 

Re: [PATCH v7 net-next 00/13] gtp: Additional feature support - Part I

[Harald Welte]

Hi Tom,

On Sat, Oct 28, 2017 at 09:16:01AM -0700, Tom Herbert wrote:
> Here is what the Kconfig for the EXPERIMENTAL option says:
> 
> "This is an experimental implementation that allows encapsulating IPv6
> over GTP and using GTP over IPv6 for testing and development purposes.
> This is not a standards conformant implementation for IPv6 and GTP.
> More work is needed to reach that level."
> 
> I don't see any ambiguity here about it not being standards complete.
> Nor is there any ambiguity about the its purpose to enable further
> development and the fact that more work is needed.

As stated repeatedly: I have no issue with an *incomplete* implementation,
but I have a problem with an *incompatible* one that takes left turns
where the spec takes right turns.

An *incomplete* implementation could still interoperate with other
implementations but is e.g. missing some optional bits.  It can later
extended with those missing bits and wills stay compatible to users of
the incomplete as well as to any later complete implementation.

An *incompatible* implementation is what I have issues with.

> This a foundation for an IPv6 datapath and is sufficient to do
> benchmarking and performance to determine the prospects of replacing
> proprietary HW with commodity servers running Linux kernel. 

I completely agree with that.

> This is a forward step to get IPv6 into GTP, and frankly the _only_ code that
> has been proposed. There is no reason why someone can't build upon
> this to make a first rate conformant implementation.

I also agree with this.  However, I don't think it makes sense to have it in
the kernel given it implements something that's actually not GTP as per
the relevant specs.  No matter how many disclaimers you put at it,
people will still assume it's GTP if it's called GTP.  And if it's only
useful for benchmarking the poential of a later proper IPv6
implementation, I don't think it should go in.

> In any case, I've invested as much time in this as I can for now. I'll
> leave it up to DaveM to decide if we wants to take all, none, or some
> subset of these patches.

Thanks.  As indicated, I'm planning some testing later this weekend on
the non-IPv6 patches, and am happy to add my Acked-by and/or re-submit
those to Dave after that.

For sure, the kernel networking maintainer can merge any patches,
including the proposed IPv6 patches as-is, and I will accept that.  But
my vote as the original author and co-maintainer of the kernel GTP code
goes politely and respectfully against that - as I have made quite clear
by now.

Thanks + Regards,
Harald

-- 
- Harald Welte    http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

[PATCH] forcedeth: Use common error handling code in two functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 28 Oct 2017 18:15:44 +0200

Add a jump target so that a bit of exception handling can be better reused
at the end of these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/net/ethernet/nvidia/forcedeth.c | 42 -
 1 file changed, 20 insertions(+), 22 deletions(-)

diff --git a/drivers/net/ethernet/nvidia/forcedeth.c 
b/drivers/net/ethernet/nvidia/forcedeth.c
index a235e8881af9..08dc2e8e5878 100644
--- a/drivers/net/ethernet/nvidia/forcedeth.c
+++ b/drivers/net/ethernet/nvidia/forcedeth.c
@@ -2827,10 +2827,8 @@ static int nv_rx_process(struct net_device *dev, int 
limit)
if (unlikely(flags & NV_RX_ERROR)) {
if ((flags & NV_RX_ERROR_MASK) == 
NV_RX_ERROR4) {
len = nv_getlen(dev, skb->data, 
len);
-   if (len < 0) {
-   dev_kfree_skb(skb);
-   goto next_pkt;
-   }
+   if (len < 0)
+   goto next_free_skb;
}
/* framing errors are soft errors */
else if ((flags & NV_RX_ERROR_MASK) == 
NV_RX_FRAMINGERR) {
@@ -2844,13 +2842,12 @@ static int nv_rx_process(struct net_device *dev, int 
limit)

np->stat_rx_missed_errors++;

u64_stats_update_end(>swstats_rx_syncp);
}
-   dev_kfree_skb(skb);
-   goto next_pkt;
+
+   goto next_free_skb;
}
}
} else {
-   dev_kfree_skb(skb);
-   goto next_pkt;
+   goto next_free_skb;
}
} else {
if (likely(flags & NV_RX2_DESCRIPTORVALID)) {
@@ -2858,10 +2855,8 @@ static int nv_rx_process(struct net_device *dev, int 
limit)
if (unlikely(flags & NV_RX2_ERROR)) {
if ((flags & NV_RX2_ERROR_MASK) == 
NV_RX2_ERROR4) {
len = nv_getlen(dev, skb->data, 
len);
-   if (len < 0) {
-   dev_kfree_skb(skb);
-   goto next_pkt;
-   }
+   if (len < 0)
+   goto next_free_skb;
}
/* framing errors are soft errors */
else if ((flags & NV_RX2_ERROR_MASK) == 
NV_RX2_FRAMINGERR) {
@@ -2870,16 +2865,14 @@ static int nv_rx_process(struct net_device *dev, int 
limit)
}
/* the rest are hard errors */
else {
-   dev_kfree_skb(skb);
-   goto next_pkt;
+   goto next_free_skb;
}
}
if (((flags & NV_RX2_CHECKSUMMASK) == 
NV_RX2_CHECKSUM_IP_TCP) || /*ip and tcp */
((flags & NV_RX2_CHECKSUMMASK) == 
NV_RX2_CHECKSUM_IP_UDP))   /*ip and udp */
skb->ip_summed = CHECKSUM_UNNECESSARY;
} else {
-   dev_kfree_skb(skb);
-   goto next_pkt;
+   goto next_free_skb;
}
}
/* got a valid packet - forward it to the network core */
@@ -2900,6 +2893,10 @@ static int nv_rx_process(struct net_device *dev, int 
limit)
}
 
return rx_work;
+
+next_free_skb:
+   dev_kfree_skb(skb);
+   goto next_pkt;
 }
 
 static int nv_rx_process_optimized(struct net_device *dev, int limit)
@@ -2932,10 +2929,8 @@ static int nv_rx_process_optimized(struct net_device 
*dev, int limit)
if 

Re: [PATCH v7 net-next 00/13] gtp: Additional feature support - Part I

[Tom Herbert]

On Sat, Oct 28, 2017 at 1:09 AM, Harald Welte  wrote:
> Hi Tom,
>
> my apologies for only getting back to reviews now, after return from
> holidays I was too overloaded with plenty of other tasks.
>
> On Fri, Oct 27, 2017 at 05:09:24PM -0700, Tom Herbert wrote:
>>   - Experimental IPv6 support
>
> As far as I can tell, my previous comments/concerns regarding an IPv6
> support that is in clear violation of how it is specified is not
> acceptable to me, sorry.
>
> The question is - as illustrated quite verbosely before - not one
> of missing certain bits, but it is simply *different* from what
> the protocol specification says.
>
> This makes absolutely no sense to me.  All it will do, is it will raise
> the impression that IPv6 is supported in a spec-compliant way.
> Furthermore, it will mean that once somebody does convert this into
> proper IPv6 support later, they will break the existing use cases of
> the non-compliant implementation that you're adding in this patch
> series.
>
Harald,

Here is what the Kconfig for the EXPERIMENTAL option says:

"This is an experimental implementation that allows encapsulating IPv6
over GTP and using GTP over IPv6 for testing and development purposes.
This is not a standards conformant implementation for IPv6 and GTP.
More work is needed to reach that level."

I don't see any ambiguity here about it not being standards complete.
Nor is there any ambiguity about the its purpose to enable further
development and the fact that more work is needed.

This a foundation for an IPv6 datapath and is sufficient to do
benchmarking and performance to determine the prospects of replacing
proprietary HW with commodity servers running Linux kernel. This is a
forward step to get IPv6 into GTP, and frankly the _only_ code that
has been proposed. There is no reason why someone can't build upon
this to make a first rate conformant implementation.

In any case, I've invested as much time in this as I can for now. I'll
leave it up to DaveM to decide if we wants to take all, none, or some
subset of these patches.

Tom

[PATCH] net: phy: leds: Add support for "link" trigger

[Maciej S. Szmigiero]

Currently, we create a LED trigger for any link speed known to a PHY.
These triggers only fire when their exact link speed had been negotiated
(they aren't cumulative, that is, they don't fire for "their or any higher"
link speed).

What we are missing, however, is a trigger which will fire on any link
speed known to the PHY. Such trigger can then be used for implementing a
poor man's substitute of the "link" LED on boards that lack it.
Let's add it.

Signed-off-by: Maciej S. Szmigiero 
---
 drivers/net/phy/Kconfig|  7 +--
 drivers/net/phy/phy_led_triggers.c | 19 ---
 2 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index cd931cf9dcc2..3bcc2107ad77 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -191,11 +191,14 @@ config LED_TRIGGER_PHY
  Adds support for a set of LED trigger events per-PHY.  Link
  state change will trigger the events, for consumption by an
  LED class driver.  There are triggers for each link speed currently
- supported by the phy, and are of the form:
+ supported by the PHY and also a one common "link" trigger as a
+ logical-or of all the link speed ones.
+ All these triggers are named according to the following pattern:
  ::
 
  Where speed is in the form:
-   Mbps or Gbps
+   Mbps OR Gbps OR link
+   for any speed known to the PHY.
 
 
 comment "MII PHY device drivers"
diff --git a/drivers/net/phy/phy_led_triggers.c 
b/drivers/net/phy/phy_led_triggers.c
index 94ca42e630bb..5b6f1876f514 100644
--- a/drivers/net/phy/phy_led_triggers.c
+++ b/drivers/net/phy/phy_led_triggers.c
@@ -20,7 +20,8 @@ static struct phy_led_trigger 
*phy_speed_to_led_trigger(struct phy_device *phy,
 {
unsigned int i;
 
-   for (i = 0; i < phy->phy_num_led_triggers; i++) {
+   /* the first (i = 0) trigger is for "any" speed */
+   for (i = 1; i < phy->phy_num_led_triggers; i++) {
if (phy->phy_led_triggers[i].speed == speed)
return >phy_led_triggers[i];
}
@@ -46,6 +47,10 @@ void phy_led_trigger_change_speed(struct phy_device *phy)
}
 
if (plt != phy->last_triggered) {
+   if (!phy->last_triggered)
+   led_trigger_event(>phy_led_triggers[0].trigger,
+ LED_FULL);
+
led_trigger_event(>last_triggered->trigger, LED_OFF);
led_trigger_event(>trigger, LED_FULL);
phy->last_triggered = plt;
@@ -56,6 +61,8 @@ void phy_led_trigger_change_speed(struct phy_device *phy)
if (phy->last_triggered) {
led_trigger_event(>last_triggered->trigger,
  LED_OFF);
+   led_trigger_event(>phy_led_triggers[0].trigger,
+ LED_OFF);
phy->last_triggered = NULL;
}
 }
@@ -69,7 +76,9 @@ static int phy_led_trigger_register(struct phy_device *phy,
 
plt->speed = speed;
 
-   if (speed < SPEED_1000)
+   if (speed == SPEED_UNKNOWN)
+   snprintf(name_suffix, sizeof(name_suffix), "link");
+   else if (speed < SPEED_1000)
snprintf(name_suffix, sizeof(name_suffix), "%dMbps", speed);
else if (speed == SPEED_2500)
snprintf(name_suffix, sizeof(name_suffix), "2.5Gbps");
@@ -99,6 +108,9 @@ int phy_led_triggers_register(struct phy_device *phy)
if (!phy->phy_num_led_triggers)
return 0;
 
+   /* include "any" speed */
+   phy->phy_num_led_triggers++;
+
phy->phy_led_triggers = devm_kzalloc(>mdio.dev,
sizeof(struct phy_led_trigger) *
   phy->phy_num_led_triggers,
@@ -110,7 +122,8 @@ int phy_led_triggers_register(struct phy_device *phy)
 
for (i = 0; i < phy->phy_num_led_triggers; i++) {
err = phy_led_trigger_register(phy, >phy_led_triggers[i],
-  speeds[i]);
+  i == 0 ? SPEED_UNKNOWN :
+   speeds[i - 1]);
if (err)
goto out_unreg;
}

[PATCH] nfp: Improve unlocking of a mutex in area_cache_get()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 28 Oct 2017 17:12:10 +0200

Add a jump target so that a call of the function "mutex_unlock" is stored
only once at the end of this function implementation.
Replace four calls by goto statements.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 .../ethernet/netronome/nfp/nfpcore/nfp_cppcore.c   | 28 ++
 1 file changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c 
b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c
index 04dd5758ecf5..e864793b7ca0 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c
@@ -822,10 +822,8 @@ area_cache_get(struct nfp_cpp *cpp, u32 id,
 
mutex_lock(>area_cache_mutex);
 
-   if (list_empty(>area_cache_list)) {
-   mutex_unlock(>area_cache_mutex);
-   return NULL;
-   }
+   if (list_empty(>area_cache_list))
+   goto unlock;
 
addr += *offset;
 
@@ -843,10 +841,8 @@ area_cache_get(struct nfp_cpp *cpp, u32 id,
 
/* Can we fit in the cache entry? */
if (round_down(addr + length - 1, cache->size) !=
-   round_down(addr, cache->size)) {
-   mutex_unlock(>area_cache_mutex);
-   return NULL;
-   }
+   round_down(addr, cache->size))
+   goto unlock;
 
/* If id != 0, we will need to release it */
if (cache->id) {
@@ -863,23 +859,23 @@ area_cache_get(struct nfp_cpp *cpp, u32 id,
if (cpp->op->area_init) {
err = cpp->op->area_init(cache->area,
 id, cache->addr, cache->size);
-   if (err < 0) {
-   mutex_unlock(>area_cache_mutex);
-   return NULL;
-   }
+   if (err < 0)
+   goto unlock;
}
 
/* Attempt to acquire */
err = nfp_cpp_area_acquire(cache->area);
-   if (err < 0) {
-   mutex_unlock(>area_cache_mutex);
-   return NULL;
-   }
+   if (err < 0)
+   goto unlock;
 
 exit:
/* Adjust offset */
*offset = addr - cache->addr;
return cache;
+
+unlock:
+   mutex_unlock(>area_cache_mutex);
+   return NULL;
 }
 
 static void
-- 
2.14.3

Linux 4.14-rc6 bisected regression tun devices not working anymore in openvpn

[Sander Eikelenboom]

L.S.,

While testing a linux 4.14-rc6 kernel i noticed OpenVPN didn't function 
anymore. 
My openvpn config uses tun devices and is pretty standard.
The openvpn version is current Debian stable: openvpn 2.4.0-6+deb9u2

>From the openvpn logging:
Sat Oct 28 16:03:34 2017 us=175829 TUN/TAP device  opened
Sat Oct 28 16:03:34 2017 us=183027 Note: Cannot set tx queue length on : No 
such device (errno=19)
Sat Oct 28 16:03:34 2017 us=183055 do_ifconfig, 
tt->did_ifconfig_ipv6_setup=0
Sat Oct 28 16:03:34 2017 us=183071 /sbin/ip link set dev  up mtu 1500
Cannot find device ""
Sat Oct 28 16:03:34 2017 us=200445 Linux ip link set failed: external 
program exited with error status: 1
Sat Oct 28 16:03:34 2017 us=200482 Exiting due to fatal error
Sat Oct 28 16:38:17 2017 us=923381 TCP/UDP: Closing socket
Sat Oct 28 16:38:17 2017 us=925986 Closing TUN/TAP interface


The offending commit is: 
0ad646c81b2182f7fa67ec0c8c825e0ee165696d
"tun: call dev_get_valid_name() before register_netdevice()" 

Reverting this commit fixes the issue for me, it's unfortunate that the commit 
it self seems to fix an other issue.

--
Sander

[PATCH] net: atheros: atl1: Use common error handling code in atl1_xmit_frame()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 28 Oct 2017 16:22:30 +0200

Add a jump target so that a bit of exception handling can be better reused
at the end of this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/net/ethernet/atheros/atlx/atl1.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c 
b/drivers/net/ethernet/atheros/atlx/atl1.c
index 83d2db2abb45..030dac9c06aa 100644
--- a/drivers/net/ethernet/atheros/atlx/atl1.c
+++ b/drivers/net/ethernet/atheros/atlx/atl1.c
@@ -2424,17 +2424,13 @@ static netdev_tx_t atl1_xmit_frame(struct sk_buff *skb,
}
 
tso = atl1_tso(adapter, skb, ptpd);
-   if (tso < 0) {
-   dev_kfree_skb_any(skb);
-   return NETDEV_TX_OK;
-   }
+   if (tso < 0)
+   goto free_skb;
 
if (!tso) {
ret_val = atl1_tx_csum(adapter, skb, ptpd);
-   if (ret_val < 0) {
-   dev_kfree_skb_any(skb);
-   return NETDEV_TX_OK;
-   }
+   if (ret_val < 0)
+   goto free_skb;
}
 
atl1_tx_map(adapter, skb, ptpd);
@@ -2442,6 +2438,10 @@ static netdev_tx_t atl1_xmit_frame(struct sk_buff *skb,
atl1_update_mailbox(adapter);
mmiowb();
return NETDEV_TX_OK;
+
+free_skb:
+   dev_kfree_skb_any(skb);
+   return NETDEV_TX_OK;
 }
 
 static int atl1_rings_clean(struct napi_struct *napi, int budget)
-- 
2.14.3

Re: [PATCH v2 net-next 3/3] mlxsw: spectrum_router: Return extack message on abort due to fib rules

[Ido Schimmel]

On Fri, Oct 27, 2017 at 05:37:14PM -0700, David Ahern wrote:
> Adding a FIB rule on a spectrum platform silently aborts FIB offload:
> $ ip ru add pref 99 from all to 192.168.1.1 table 10
> $ dmesg -c
> [  623.144736] mlxsw_spectrum :03:00.0: FIB abort triggered. Note 
> that FIB entries are no longer being offloaded to this device.
> 
> This patch reworks FIB rule handling to return a message to the user:
> $ ip ru add pref 99 from all to 8.8.8.8 table 11
> Error: spectrum: FIB rules not supported. Aborting offload.
> 
> spectrum currently only checks whether the fib rule is a default rule or
> an l3mdev rule, both of which it knows how to handle. Any other it aborts
> FIB offload. Move the processing to check the rule type inline with the
> user request. If the rule is an unsupported one, then a work queue entry
> is used to abort the offload. Change the rule delete handling to just
> return since it does nothing at the moment.
> 
> Signed-off-by: David Ahern 

Reviewed-by: Ido Schimmel 

I'll follow-up with a patch to notify about IPv6 source-specific routes
that also trigger abort.

Another possible use case for this, is something Petr is working on. We
currently assume IP-in-IP tunnel parameters don't change after creation,
but Petr has a patchset that adds support for NETDEV_CHANGE events in
mlxsw.

It's possible that after parameters are changed, we can no longer
offload the tunnel (for example, because user enabled sequence
counters). With this infrastructure, we can let the user know about it.

Thanks!

Re: [PATCH v2 net-next 2/3] net: Add extack to fib_notifier_info

[Ido Schimmel]

On Fri, Oct 27, 2017 at 05:37:13PM -0700, David Ahern wrote:
> Add extack to fib_notifier_info and plumb through stack to
> call_fib_rule_notifiers, call_fib_entry_notifiers and
> call_fib6_entry_notifiers. This allows notifer handlers to
> return messages to user.
> 
> Signed-off-by: David Ahern 

Reviewed-by: Ido Schimmel 

Re: [PATCH v2] xdp: Sample xdp program implementing ip forward

[Christina Jacob]

On Wed, Oct 11, 2017 at 3:07 AM, David Daney  wrote:
> On 10/10/2017 10:19 AM, Stephen Hemminger wrote:
>>
>> On Tue, 10 Oct 2017 12:58:52 +0530
>> Christina Jacob  wrote:
>>
>>> +/* Get the mac address of the interface given interface name */
>>> +static long *getmac(char *iface)
>>> +{
>>> +   int fd;
>>> +   struct ifreq ifr;
>>> +   long *mac = NULL;
>>> +
>>> +   fd = socket(AF_INET, SOCK_DGRAM, 0);
>>> +   ifr.ifr_addr.sa_family = AF_INET;
>>> +   strncpy(ifr.ifr_name, iface, IFNAMSIZ - 1);
>>> +   ioctl(fd, SIOCGIFHWADDR, );
>>> +   mac = (long *)ifr.ifr_hwaddr.sa_data;
>>> +   close(fd);
>>> +   return mac;
>>
>>
>> Always check return value of ioctl.
>> You are assuming sizeof(long) > 6 bytes.
>> Also the byte order.
>
>
>
> Also:
>
> Returning the address of a local variable (ifr.ifr_hwaddr.sa_data), and then
> dereferencing it outside of the function is not correct.
>
> The casting of the char sa_data[] to a long * may cause alignment faults on
> some architectures.  The may also be endinaness issues depending on how the
> data are manipulated if you pack all those chars into a long.
>
> If we think that a MAC address is char[6], then it may be best to define the
> data structures as such and manipulate it as an array instead of trying to
> pack it into a long.

How do I feed the MAC address to xdp.data ? Is it ok to do a manual
leftshift + biwise and  for the purpose?

>
> Keep working on this though, this program will surely be useful.
>
> David Daney

[PATCH net-next 1/1] forcedeth: replace pci_alloc_consistent with dma_alloc_coherent

[Zhu Yanjun]

The functions pci_alloc_consistent is obsolete. So it is replaced
with dma_alloc_coherent

Signed-off-by: Zhu Yanjun 
---
 drivers/net/ethernet/nvidia/forcedeth.c | 61 ++---
 1 file changed, 41 insertions(+), 20 deletions(-)

diff --git a/drivers/net/ethernet/nvidia/forcedeth.c 
b/drivers/net/ethernet/nvidia/forcedeth.c
index 88128ce..31a9438 100644
--- a/drivers/net/ethernet/nvidia/forcedeth.c
+++ b/drivers/net/ethernet/nvidia/forcedeth.c
@@ -1024,12 +1024,18 @@ static void free_rings(struct net_device *dev)
 
if (!nv_optimized(np)) {
if (np->rx_ring.orig)
-   pci_free_consistent(np->pci_dev, sizeof(struct 
ring_desc) * (np->rx_ring_size + np->tx_ring_size),
-   np->rx_ring.orig, np->ring_addr);
+   dma_free_coherent(>pci_dev->dev,
+ sizeof(struct ring_desc) *
+ (np->rx_ring_size +
+ np->tx_ring_size),
+ np->rx_ring.orig, np->ring_addr);
} else {
if (np->rx_ring.ex)
-   pci_free_consistent(np->pci_dev, sizeof(struct 
ring_desc_ex) * (np->rx_ring_size + np->tx_ring_size),
-   np->rx_ring.ex, np->ring_addr);
+   dma_free_coherent(>pci_dev->dev,
+ sizeof(struct ring_desc_ex) *
+ (np->rx_ring_size +
+ np->tx_ring_size),
+ np->rx_ring.ex, np->ring_addr);
}
kfree(np->rx_skb);
kfree(np->tx_skb);
@@ -4596,13 +4602,17 @@ static int nv_set_ringparam(struct net_device *dev, 
struct ethtool_ringparam* ri
 
/* allocate new rings */
if (!nv_optimized(np)) {
-   rxtx_ring = pci_alloc_consistent(np->pci_dev,
-   sizeof(struct ring_desc) * 
(ring->rx_pending + ring->tx_pending),
-   _addr);
+   rxtx_ring = dma_alloc_coherent(>pci_dev->dev,
+  sizeof(struct ring_desc) *
+  (ring->rx_pending +
+  ring->tx_pending),
+  _addr, GFP_ATOMIC);
} else {
-   rxtx_ring = pci_alloc_consistent(np->pci_dev,
-   sizeof(struct ring_desc_ex) * 
(ring->rx_pending + ring->tx_pending),
-   _addr);
+   rxtx_ring = dma_alloc_coherent(>pci_dev->dev,
+  sizeof(struct ring_desc_ex) *
+  (ring->rx_pending +
+  ring->tx_pending),
+  _addr, GFP_ATOMIC);
}
rx_skbuff = kmalloc(sizeof(struct nv_skb_map) * ring->rx_pending, 
GFP_KERNEL);
tx_skbuff = kmalloc(sizeof(struct nv_skb_map) * ring->tx_pending, 
GFP_KERNEL);
@@ -4610,12 +4620,18 @@ static int nv_set_ringparam(struct net_device *dev, 
struct ethtool_ringparam* ri
/* fall back to old rings */
if (!nv_optimized(np)) {
if (rxtx_ring)
-   pci_free_consistent(np->pci_dev, sizeof(struct 
ring_desc) * (ring->rx_pending + ring->tx_pending),
-   rxtx_ring, ring_addr);
+   dma_free_coherent(>pci_dev->dev,
+ sizeof(struct ring_desc) *
+ (ring->rx_pending +
+ ring->tx_pending),
+ rxtx_ring, ring_addr);
} else {
if (rxtx_ring)
-   pci_free_consistent(np->pci_dev, sizeof(struct 
ring_desc_ex) * (ring->rx_pending + ring->tx_pending),
-   rxtx_ring, ring_addr);
+   dma_free_coherent(>pci_dev->dev,
+ sizeof(struct ring_desc_ex) *
+ (ring->rx_pending +
+ ring->tx_pending),
+ rxtx_ring, ring_addr);
}
 
kfree(rx_skbuff);
@@ -5740,16 +5756,21 @@ static int nv_probe(struct pci_dev *pci_dev, const 
struct pci_device_id *id)
np->tx_ring_size = TX_RING_DEFAULT;
 
if (!nv_optimized(np)) {
-   

[PATCH net-next] ip_vti: remove the useless err_count check in vti_xmit

[Xin Long]

Unlike ipip and gre, ip_vti never uses err_count in vti4_err,
so no need to check err_count in vti_xmit, it's value always 0.

Signed-off-by: Xin Long 
---
 net/ipv4/ip_vti.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index 58465c0..949f432 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -198,15 +198,6 @@ static netdev_tx_t vti_xmit(struct sk_buff *skb, struct 
net_device *dev,
goto tx_error;
}
 
-   if (tunnel->err_count > 0) {
-   if (time_before(jiffies,
-   tunnel->err_time + IPTUNNEL_ERR_TIMEO)) {
-   tunnel->err_count--;
-   dst_link_failure(skb);
-   } else
-   tunnel->err_count = 0;
-   }
-
mtu = dst_mtu(dst);
if (skb->len > mtu) {
skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL, skb, mtu);
-- 
2.1.0

[PATCH net 3/4] sctp: fix a type cast warnings that causes a_rwnd gets the wrong value

[Xin Long]

These warnings were found by running 'make C=2 M=net/sctp/'.

Commit d4d6fb5787a6 ("sctp: Try not to change a_rwnd when faking a
SACK from SHUTDOWN.") expected to use the peers old rwnd and add
our flight size to the a_rwnd. But with the wrong Endian, it may
not work as well as expected.

So fix it by converting to the right value.

Fixes: d4d6fb5787a6 ("sctp: Try not to change a_rwnd when faking a SACK from 
SHUTDOWN.")
Reported-by: Eric Dumazet 
Signed-off-by: Xin Long 
---
 net/sctp/sm_sideeffect.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index e6a2974..8f2762b 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -1680,8 +1680,8 @@ static int sctp_cmd_interpreter(enum sctp_event 
event_type,
case SCTP_CMD_PROCESS_CTSN:
/* Dummy up a SACK for processing. */
sackh.cum_tsn_ack = cmd->obj.be32;
-   sackh.a_rwnd = asoc->peer.rwnd +
-   asoc->outqueue.outstanding_bytes;
+   sackh.a_rwnd = htonl(asoc->peer.rwnd +
+asoc->outqueue.outstanding_bytes);
sackh.num_gap_ack_blocks = 0;
sackh.num_dup_tsns = 0;
chunk->subh.sack_hdr = 
-- 
2.1.0

[PATCH net 0/4] sctp: a bunch of fixes for some sparse warnings

[Xin Long]

As Eric noticed, when running 'make C=2 M=net/sctp/', a plenty of
warnings or errors checked by sparse appear. They are all problems
about Endian and type cast.

Most of them are just warnings by which no issues could be caused
while some might be bugs.

This patchset fixes them with four patches basically according to
how they are introduced.

Xin Long (4):
  sctp: fix some type cast warnings introduced by stream reconf
  sctp: fix some type cast warnings introduced by transport rhashtable
  sctp: fix a type cast warnings that causes a_rwnd gets the wrong value
  sctp: fix some type cast warnings introduced since very beginning

 include/linux/sctp.h| 34 +-
 include/net/sctp/sm.h   |  2 +-
 include/net/sctp/ulpevent.h |  2 +-
 include/uapi/linux/sctp.h   |  2 +-
 net/sctp/input.c| 22 +++---
 net/sctp/ipv6.c |  2 +-
 net/sctp/sm_make_chunk.c|  9 +
 net/sctp/sm_sideeffect.c|  8 
 net/sctp/stream.c   | 26 +-
 net/sctp/ulpevent.c |  2 +-
 10 files changed, 59 insertions(+), 50 deletions(-)

-- 
2.1.0

[PATCH net 2/4] sctp: fix some type cast warnings introduced by transport rhashtable

[Xin Long]

These warnings were found by running 'make C=2 M=net/sctp/'.

They are introduced by not aware of Endian for the port when
coding transport rhashtable patches.

Fixes: 7fda702f9315 ("sctp: use new rhlist interface on sctp transport 
rhashtable")
Reported-by: Eric Dumazet 
Signed-off-by: Xin Long 
---
 net/sctp/input.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/net/sctp/input.c b/net/sctp/input.c
index 34f10e7..621b5ca 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -794,7 +794,7 @@ static struct sctp_endpoint 
*__sctp_rcv_lookup_endpoint(struct net *net,
 struct sctp_hash_cmp_arg {
const union sctp_addr   *paddr;
const struct net*net;
-   u16 lport;
+   __be16  lport;
 };
 
 static inline int sctp_hash_cmp(struct rhashtable_compare_arg *arg,
@@ -820,37 +820,37 @@ static inline int sctp_hash_cmp(struct 
rhashtable_compare_arg *arg,
return err;
 }
 
-static inline u32 sctp_hash_obj(const void *data, u32 len, u32 seed)
+static inline __u32 sctp_hash_obj(const void *data, u32 len, u32 seed)
 {
const struct sctp_transport *t = data;
const union sctp_addr *paddr = >ipaddr;
const struct net *net = sock_net(t->asoc->base.sk);
-   u16 lport = htons(t->asoc->base.bind_addr.port);
-   u32 addr;
+   __be16 lport = htons(t->asoc->base.bind_addr.port);
+   __u32 addr;
 
if (paddr->sa.sa_family == AF_INET6)
addr = jhash(>v6.sin6_addr, 16, seed);
else
-   addr = paddr->v4.sin_addr.s_addr;
+   addr = (__force __u32)paddr->v4.sin_addr.s_addr;
 
-   return  jhash_3words(addr, ((__u32)paddr->v4.sin_port) << 16 |
+   return  jhash_3words(addr, ((__force __u32)paddr->v4.sin_port) << 16 |
 (__force __u32)lport, net_hash_mix(net), seed);
 }
 
-static inline u32 sctp_hash_key(const void *data, u32 len, u32 seed)
+static inline __u32 sctp_hash_key(const void *data, u32 len, u32 seed)
 {
const struct sctp_hash_cmp_arg *x = data;
const union sctp_addr *paddr = x->paddr;
const struct net *net = x->net;
-   u16 lport = x->lport;
-   u32 addr;
+   __be16 lport = x->lport;
+   __u32 addr;
 
if (paddr->sa.sa_family == AF_INET6)
addr = jhash(>v6.sin6_addr, 16, seed);
else
-   addr = paddr->v4.sin_addr.s_addr;
+   addr = (__force __u32)paddr->v4.sin_addr.s_addr;
 
-   return  jhash_3words(addr, ((__u32)paddr->v4.sin_port) << 16 |
+   return  jhash_3words(addr, ((__force __u32)paddr->v4.sin_port) << 16 |
 (__force __u32)lport, net_hash_mix(net), seed);
 }
 
-- 
2.1.0

[PATCH net 1/4] sctp: fix some type cast warnings introduced by stream reconf

[Xin Long]

These warnings were found by running 'make C=2 M=net/sctp/'.

They are introduced by not aware of Endian when coding stream
reconf patches.

Since commit c0d8bab6ae51 ("sctp: add get and set sockopt for
reconf_enable") enabled stream reconf feature for users, the
Fixes tag below would use it.

Fixes: c0d8bab6ae51 ("sctp: add get and set sockopt for reconf_enable")
Reported-by: Eric Dumazet 
Signed-off-by: Xin Long 
---
 include/linux/sctp.h| 32 
 include/net/sctp/sm.h   |  2 +-
 include/net/sctp/ulpevent.h |  2 +-
 net/sctp/sm_make_chunk.c|  5 +++--
 net/sctp/stream.c   | 26 +-
 net/sctp/ulpevent.c |  2 +-
 6 files changed, 39 insertions(+), 30 deletions(-)

diff --git a/include/linux/sctp.h b/include/linux/sctp.h
index 82b171e..09d7412 100644
--- a/include/linux/sctp.h
+++ b/include/linux/sctp.h
@@ -716,28 +716,28 @@ struct sctp_reconf_chunk {
 
 struct sctp_strreset_outreq {
struct sctp_paramhdr param_hdr;
-   __u32 request_seq;
-   __u32 response_seq;
-   __u32 send_reset_at_tsn;
-   __u16 list_of_streams[0];
+   __be32 request_seq;
+   __be32 response_seq;
+   __be32 send_reset_at_tsn;
+   __be16 list_of_streams[0];
 };
 
 struct sctp_strreset_inreq {
struct sctp_paramhdr param_hdr;
-   __u32 request_seq;
-   __u16 list_of_streams[0];
+   __be32 request_seq;
+   __be16 list_of_streams[0];
 };
 
 struct sctp_strreset_tsnreq {
struct sctp_paramhdr param_hdr;
-   __u32 request_seq;
+   __be32 request_seq;
 };
 
 struct sctp_strreset_addstrm {
struct sctp_paramhdr param_hdr;
-   __u32 request_seq;
-   __u16 number_of_streams;
-   __u16 reserved;
+   __be32 request_seq;
+   __be16 number_of_streams;
+   __be16 reserved;
 };
 
 enum {
@@ -752,16 +752,16 @@ enum {
 
 struct sctp_strreset_resp {
struct sctp_paramhdr param_hdr;
-   __u32 response_seq;
-   __u32 result;
+   __be32 response_seq;
+   __be32 result;
 };
 
 struct sctp_strreset_resptsn {
struct sctp_paramhdr param_hdr;
-   __u32 response_seq;
-   __u32 result;
-   __u32 senders_next_tsn;
-   __u32 receivers_next_tsn;
+   __be32 response_seq;
+   __be32 result;
+   __be32 senders_next_tsn;
+   __be32 receivers_next_tsn;
 };
 
 #endif /* __LINUX_SCTP_H__ */
diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
index 2db3d3a..88233cf 100644
--- a/include/net/sctp/sm.h
+++ b/include/net/sctp/sm.h
@@ -261,7 +261,7 @@ struct sctp_chunk *sctp_make_fwdtsn(const struct 
sctp_association *asoc,
struct sctp_fwdtsn_skip *skiplist);
 struct sctp_chunk *sctp_make_auth(const struct sctp_association *asoc);
 struct sctp_chunk *sctp_make_strreset_req(const struct sctp_association *asoc,
- __u16 stream_num, __u16 *stream_list,
+ __u16 stream_num, __be16 *stream_list,
  bool out, bool in);
 struct sctp_chunk *sctp_make_strreset_tsnreq(
const struct sctp_association *asoc);
diff --git a/include/net/sctp/ulpevent.h b/include/net/sctp/ulpevent.h
index b8c86ec..231dc42 100644
--- a/include/net/sctp/ulpevent.h
+++ b/include/net/sctp/ulpevent.h
@@ -130,7 +130,7 @@ struct sctp_ulpevent *sctp_ulpevent_make_sender_dry_event(
 
 struct sctp_ulpevent *sctp_ulpevent_make_stream_reset_event(
const struct sctp_association *asoc, __u16 flags,
-   __u16 stream_num, __u16 *stream_list, gfp_t gfp);
+   __u16 stream_num, __be16 *stream_list, gfp_t gfp);
 
 struct sctp_ulpevent *sctp_ulpevent_make_assoc_reset_event(
const struct sctp_association *asoc, __u16 flags,
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index ca8f196..57c5504 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3591,7 +3591,7 @@ static struct sctp_chunk *sctp_make_reconf(const struct 
sctp_association *asoc,
  */
 struct sctp_chunk *sctp_make_strreset_req(
const struct sctp_association *asoc,
-   __u16 stream_num, __u16 *stream_list,
+   __u16 stream_num, __be16 *stream_list,
bool out, bool in)
 {
struct sctp_strreset_outreq outreq;
@@ -3788,7 +3788,8 @@ bool sctp_verify_reconf(const struct sctp_association 
*asoc,
 {
struct sctp_reconf_chunk *hdr;
union sctp_params param;
-   __u16 last = 0, cnt = 0;
+   __be16 last = 0;
+   __u16 cnt = 0;
 
hdr = (struct sctp_reconf_chunk *)chunk->chunk_hdr;
sctp_walk_params(param, hdr, params) {
diff --git a/net/sctp/stream.c b/net/sctp/stream.c
index 63ea155..fa8371f 100644
--- a/net/sctp/stream.c
+++ 

[PATCH net 4/4] sctp: fix some type cast warnings introduced since very beginning

[Xin Long]

These warnings were found by running 'make C=2 M=net/sctp/'.
They are there since very beginning.

Note after this patch, there still one warning left in
sctp_outq_flush():
  sctp_chunk_fail(chunk, SCTP_ERROR_INV_STRM)

Since it has been moved to sctp_stream_outq_migrate on net-next,
to avoid the extra job when merging net-next to net, I will post
the fix for it after the merging is done.

Reported-by: Eric Dumazet 
Signed-off-by: Xin Long 
---
 include/linux/sctp.h  | 2 +-
 include/uapi/linux/sctp.h | 2 +-
 net/sctp/ipv6.c   | 2 +-
 net/sctp/sm_make_chunk.c  | 4 ++--
 net/sctp/sm_sideeffect.c  | 4 ++--
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/linux/sctp.h b/include/linux/sctp.h
index 09d7412..da803df 100644
--- a/include/linux/sctp.h
+++ b/include/linux/sctp.h
@@ -231,7 +231,7 @@ struct sctp_datahdr {
__be32 tsn;
__be16 stream;
__be16 ssn;
-   __be32 ppid;
+   __u32 ppid;
__u8  payload[0];
 };
 
diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
index 6217ff8..84fc291 100644
--- a/include/uapi/linux/sctp.h
+++ b/include/uapi/linux/sctp.h
@@ -376,7 +376,7 @@ struct sctp_remote_error {
__u16 sre_type;
__u16 sre_flags;
__u32 sre_length;
-   __u16 sre_error;
+   __be16 sre_error;
sctp_assoc_t sre_assoc_id;
__u8 sre_data[0];
 };
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index 7fe9e1d1..a6dfa86 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -738,7 +738,7 @@ static int sctp_v6_skb_iif(const struct sk_buff *skb)
 /* Was this packet marked by Explicit Congestion Notification? */
 static int sctp_v6_is_ce(const struct sk_buff *skb)
 {
-   return *((__u32 *)(ipv6_hdr(skb))) & htonl(1 << 20);
+   return *((__u32 *)(ipv6_hdr(skb))) & (__force __u32)htonl(1 << 20);
 }
 
 /* Dump the v6 addr to the seq file. */
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 57c5504..514465b 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -2854,7 +2854,7 @@ struct sctp_chunk *sctp_make_asconf_update_ip(struct 
sctp_association *asoc,
addr_param_len = af->to_addr_param(addr, _param);
param.param_hdr.type = flags;
param.param_hdr.length = htons(paramlen + addr_param_len);
-   param.crr_id = i;
+   param.crr_id = htonl(i);
 
sctp_addto_chunk(retval, paramlen, );
sctp_addto_chunk(retval, addr_param_len, _param);
@@ -2867,7 +2867,7 @@ struct sctp_chunk *sctp_make_asconf_update_ip(struct 
sctp_association *asoc,
addr_param_len = af->to_addr_param(addr, _param);
param.param_hdr.type = SCTP_PARAM_DEL_IP;
param.param_hdr.length = htons(paramlen + addr_param_len);
-   param.crr_id = i;
+   param.crr_id = htonl(i);
 
sctp_addto_chunk(retval, paramlen, );
sctp_addto_chunk(retval, addr_param_len, _param);
diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index 8f2762b..e2d9a4b 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -1607,12 +1607,12 @@ static int sctp_cmd_interpreter(enum sctp_event 
event_type,
break;
 
case SCTP_CMD_INIT_FAILED:
-   sctp_cmd_init_failed(commands, asoc, cmd->obj.err);
+   sctp_cmd_init_failed(commands, asoc, cmd->obj.u32);
break;
 
case SCTP_CMD_ASSOC_FAILED:
sctp_cmd_assoc_failed(commands, asoc, event_type,
- subtype, chunk, cmd->obj.err);
+ subtype, chunk, cmd->obj.u32);
break;
 
case SCTP_CMD_INIT_COUNTER_INC:
-- 
2.1.0

Re: [PATCH 0/4] TI Bluetooth serdev support

[Adam Ford]

On Fri, Oct 27, 2017 at 5:55 AM, Adam Ford  wrote:
> On Tue, May 9, 2017 at 9:14 AM, Rob Herring  wrote:
>> On Mon, May 8, 2017 at 11:48 PM, Baruch Siach  wrote:
>>> Hi Rob,
>>>
>>> On Mon, May 08, 2017 at 04:12:16PM -0500, Rob Herring wrote:
 On Fri, May 5, 2017 at 9:51 AM, Adam Ford  wrote:
 > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel  
 > wrote:
 >> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
 >>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring  wrote:
 >>> > This series adds serdev support to the HCI LL protocol used on TI BT
 >>> > modules and enables support on HiKey board with with the WL1835 
 >>> > module.
 >>> > With this the custom TI UIM daemon and btattach are no longer needed.
 >>>
 >>> Without UIM daemon, what instruction do you use to load the BT 
 >>> firmware?
 >>>
 >>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
 >>> might have some insight.
 >>>
 >>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 300 flow  Just
 >>> returns a timeout.
 >>>
 >>> I modified my i.MX6 device tree per the binding documentation and
 >>> setup the regulators and enable GPIO pins.
 >>
 >> If you configured everything correctly no userspace interaction is
 >> required. The driver should request the firmware automatically once
 >> you power up the bluetooth device.
 >>
 >> Apart from DT changes make sure, that the following options are
 >> enabled and check dmesg for any hints.
 >>
 >> CONFIG_SERIAL_DEV_BUS
 >> CONFIG_SERIAL_DEV_CTRL_TTYPORT
 >> CONFIG_BT_HCIUART
 >> CONFIG_BT_HCIUART_LL
 >
 > I have enabled those flags, and I have updated my device tree.
 > I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
 > getting a lot of timeout errors.  I tested this against the original
 > implemention I had in pdata-quirks.c using the ti-st driver, uim & and
 > the btwilink driver.
 >
 > I pulled in some of the newer patches to enable the wl1283-st, but I
 > am obviously missing something.
 >
 > I   58.717651] Bluetooth: hci0: Reading TI version information failed
 > (-110)
 > [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
 > [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
 > [   68.957641] Bluetooth: hci0: Reading TI version information failed
 > (-110)
 > [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
 > [   69.132171] Bluetooth: Unknown HCI packet type 06
 > [   69.138244] Bluetooth: Unknown HCI packet type 0c
 > [   69.143249] Bluetooth: Unknown HCI packet type 40
 > [   69.148498] Bluetooth: Unknown HCI packet type 20
 > [   69.153533] Bluetooth: Data length is too large
 > [   69.158569] Bluetooth: Unknown HCI packet type a0
 > [   69.163574] Bluetooth: Unknown HCI packet type 00
 > [   69.168731] Bluetooth: Unknown HCI packet type 00
 > [   69.173736] Bluetooth: Unknown HCI packet type 34
 > [   69.178924] Bluetooth: Unknown HCI packet type 91
 > [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
 > [   79.197662] Bluetooth: hci0: Reading TI version information failed 
 > (-110)

 There's a bug in serdev_device_write(), so if you have that function
 you need either the fix I sent or the patch to make
 serdev_device_writebuf atomic again. Both are on the linux-serial
 list, but not in any tree yet.
>>>
>>> You refer to the patches below, right?
>>>
>>>   [PATCH] tty: serdev: fix serdev_device_write return value,
>>>   http://www.spinics.net/lists/linux-serial/msg26117.html
>>>
>>>   [PATCH] serdev: Restore serdev_device_write_buf for atomic context,
>>>   http://www.spinics.net/lists/linux-serial/msg26113.html
>>
>> Yes, either one will fix the issue.
>
> I am finally getting back to testing these on my DM3730 board, since
> it appears most of the patches appear upstream.  I am having trouble
> remembering how to load this.
>
> # modprobe hci_uart
> [   31.639892] Bluetooth: Core ver 2.22
> [   31.643890] NET: Registered protocol family 31
> [   31.648559] Bluetooth: HCI device and connection manager initialized
> [   31.655975] Bluetooth: HCI socket layer initialized
> [   31.661315] Bluetooth: L2CAP socket layer initialized
> [   31.667175] Bluetooth: SCO socket layer initialized
> [   31.700408] Bluetooth: HCI UART driver ver 2.3
> [   31.705108] Bluetooth: HCI UART protocol H4 registered
> [   31.710632] Bluetooth: HCI UART protocol BCSP registered
> [   31.716217] Bluetooth: HCI UART protocol Three-wire (H5) registered
> #
>
> Unfortunately, any attempt to access the HCI device (ie hciconfig up
> hci0) fail.
>
> I have those configs enabled:
> CONFIG_SERIAL_DEV_BUS
> CONFIG_SERIAL_DEV_CTRL_TTYPORT
> 

Re: [PATCH net-next 0/9] net: dsa: define port types

[Egil Hjelmeland]

Den 27. okt. 2017 21:37, skrev Andrew Lunn:

On Fri, Oct 27, 2017 at 02:56:51PM +0200, Egil Hjelmeland wrote:

The DSA code currently has 3 bitmaps in the dsa_switch structure:
cpu_port_mask, dsa_port_mask and enabled_port_mask.



Hi Vivien

First I must apologize to everybody for not replying in-thread. Problem
is that I was not subscribed to netdev. But now I am, so I promise it
will not happen again :-)

So to the point. I think DSA need to keep track of multicast
memberships. As it is now, dsa_switch_mdb_add() include
the CPU/DSA port(s) in the multicast. But  multicast is never
removed from the CPU/DSA port(s).


Hi Egil

You should take a look at my patches from a few weeks back. I hope to
make another version next week. These deal with multicast on the CPU
port, or better said, the host wanting to receive a multicast group.

   Andrew



Hi Andrew

I suppose you refer to https://www.spinics.net/lists/netdev/msg453848.html.
That will be great to have for my employer.

Regarding the offload_fwd_mark discussion: I did some experiments
yesterday afternoon on the lan9303 driver.

- Driver add the STP address to the ALR(fdb) pointing to CPU port
- In tag_lan9303.c rcv() set offload_fwd_mark if destination is
  not STP address.

In addition; I found out that my fresh lan9303_xmit_use_arl() is wrong:
Multicast and broadcasts must not be sent via the ALR.

 - use ALR on transmit if bridged and destination is unicast.

Then it looks as if the system is doing the right thing, both for
incomming and outgoing packets. Including STP BPDUs both when
STP is enabled and not.

I will have to test more though when back at office next week.

Egil

Re: [PATCH] netfilter/ipvs: clear ipvs_property flag when SKB net namespace changed

[Julian Anastasov]

Hello,

On Thu, 26 Oct 2017, Ye Yin wrote:

> When run ipvs in two different network namespace at the same host, and one
> ipvs transport network traffic to the other network namespace ipvs.
> 'ipvs_property' flag will make the second ipvs take no effect. So we should
> clear 'ipvs_property' when SKB network namespace changed.
> 
> Signed-off-by: Ye Yin 
> Signed-off-by: Wei Zhou 

Patch looks good to me. ipvs_property was added long ago
but skb_scrub_packet() is more recent (3.11), so:

Fixes: 621e84d6f373 ("dev: introduce skb_scrub_packet()")
Signed-off-by: Julian Anastasov 

I guess, DaveM can apply it directly as a bugfix
to the net tree.

> ---
>  include/linux/skbuff.h | 7 +++
>  net/core/skbuff.c  | 1 +
>  2 files changed, 8 insertions(+)
> 
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 72299ef..d448a48 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -3770,6 +3770,13 @@ static inline void nf_reset_trace(struct sk_buff *skb)
>  #endif
>  }
>  
> +static inline void ipvs_reset(struct sk_buff *skb)
> +{
> +#if IS_ENABLED(CONFIG_IP_VS)
> + skb->ipvs_property = 0;
> +#endif
> +}
> +
>  /* Note: This doesn't put any conntrack and bridge info in dst. */
>  static inline void __nf_copy(struct sk_buff *dst, const struct sk_buff *src,
>bool copy)
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 2465607..e140ba4 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -4864,6 +4864,7 @@ void skb_scrub_packet(struct sk_buff *skb, bool xnet)
>   if (!xnet)
>   return;
>  
> + ipvs_reset(skb);
>   skb_orphan(skb);
>   skb->mark = 0;
>  }
> -- 
> 1.7.12.4

Regards

--
Julian Anastasov 

Re: [PATCH net-next] tcp: remove unnecessary include

[David Miller]

From: Alexei Starovoitov 
Date: Fri, 27 Oct 2017 10:01:39 -0700

> two extra #include are not necessary in tcp.h
> Remove them.
> 
> Fixes: 40304b2a1567 ("bpf: BPF support for sock_ops")
> Signed-off-by: Alexei Starovoitov 

Applied, thank you.

Re: [PATCH net-next 00/12] tcp: move 12 sysctls to namespaces

[David Miller]

From: Eric Dumazet 
Date: Fri, 27 Oct 2017 07:47:20 -0700

> Ideally all TCP sysctls should be per netns.
> This patch series takes care of 12 sysctls.

Series applied, thanks Eric.

> Remains the ones that need discussion :
> 
> sysctl_tcp_mem, sysctl_tcp_rmem, sysctl_tcp_wmem, and sysctl_tcp_max_orphans

Yeah those will be tricky.

Re: [PATCH] drivers/net: smsc: Convert timers to use timer_setup()

[David Miller]

From: Kees Cook 
Date: Thu, 26 Oct 2017 22:55:42 -0700

> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> 
> Cc: "David S. Miller" 
> Cc: "yuval.sh...@oracle.com" 
> Cc: Eric Dumazet 
> Cc: Philippe Reynes 
> Cc: Allen Pais 
> Cc: Tobias Klauser 
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook 

Applied.

Re: [PATCH] drivers/net: korina: Convert timers to use timer_setup()

[David Miller]

From: Kees Cook 
Date: Thu, 26 Oct 2017 22:55:13 -0700

> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> 
> Cc: "David S. Miller" 
> Cc: Roman Yeryomin 
> Cc: Florian Fainelli 
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook 

Applied.

Re: [PATCH] tap: reference to KVA of an unloaded module causes kernel panic

[David Miller]

From: Girish Moodalbail 
Date: Fri, 27 Oct 2017 00:00:16 -0700

> The commit 9a393b5d5988 ("tap: tap as an independent module") created a
> separate tap module that implements tap functionality and exports
> interfaces that will be used by macvtap and ipvtap modules to create
> create respective tap devices.
> 
> However, that patch introduced a regression wherein the modules macvtap
> and ipvtap can be removed (through modprobe -r) while there are
> applications using the respective /dev/tapX devices. These applications
> cause kernel to hold reference to /dev/tapX through 'struct cdev
> macvtap_cdev' and 'struct cdev ipvtap_dev' defined in macvtap and ipvtap
> modules respectively. So,  when the application is later closed the
> kernel panics because we are referencing KVA that is present in the
> unloaded modules.
> 
> --8<--- Example --8<--
> $ sudo ip li add name mv0 link enp7s0 type macvtap
> $ sudo ip li show mv0 |grep mv0| awk -e '{print $1 $2}'
>   14:mv0@enp7s0:
> $ cat /dev/tap14 &
> $ lsmod |egrep -i 'tap|vlan'
> macvtap16384  0
> macvlan24576  1 macvtap
> tap24576  3 macvtap
> $ sudo modprobe -r macvtap
> $ fg
> cat /dev/tap14
> ^C
> 
> <...system panics...>
> BUG: unable to handle kernel paging request at a038c500
> IP: cdev_put+0xf/0x30
> --8<-8<--
> 
> The fix is to set cdev.owner to the module that creates the tap device
> (either macvtap or ipvtap). With this set, the operations (in
> fs/char_dev.c) on char device holds and releases the module through
> cdev_get() and cdev_put() and will not allow the module to unload
> prematurely.
> 
> Fixes: 9a393b5d5988ea4e (tap: tap as an independent module)
> Signed-off-by: Girish Moodalbail 

Applied and queued up for -stable.

Re: [PATCH] drivers/net: natsemi: Convert timers to use timer_setup()

[David Miller]

From: Kees Cook 
Date: Thu, 26 Oct 2017 22:55:27 -0700

> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> 
> Cc: "David S. Miller" 
> Cc: Allen Pais 
> Cc: Eric Dumazet 
> Cc: Philippe Reynes 
> Cc: Wei Yongjun 
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook 

Applied.

Re: [PATCH] drivers/net: mellanox: Convert timers to use timer_setup()

[David Miller]

From: Kees Cook 
Date: Thu, 26 Oct 2017 22:55:20 -0700

> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> 
> Cc: Saeed Mahameed 
> Cc: Matan Barak 
> Cc: Leon Romanovsky 
> Cc: netdev@vger.kernel.org
> Cc: linux-r...@vger.kernel.org
> Signed-off-by: Kees Cook 

Applied.

Re: [PATCH] drivers/net: packetengines: Convert timers to use timer_setup()

[David Miller]

From: Kees Cook 
Date: Thu, 26 Oct 2017 22:55:34 -0700

> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> 
> Cc: "David S. Miller" 
> Cc: Allen Pais 
> Cc: yuan linyu 
> Cc: Philippe Reynes 
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook 

Applied.

Re: [PATCH] drivers/net: fealnx: Convert timers to use timer_setup()

[David Miller]

From: Kees Cook 
Date: Thu, 26 Oct 2017 22:55:07 -0700

> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> 
> Cc: "David S. Miller" 
> Cc: "yuval.sh...@oracle.com" 
> Cc: Allen Pais 
> Cc: Stephen Hemminger 
> Cc: Philippe Reynes 
> Cc: Johannes Berg 
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook 

Applied.

Re: [PATCH] drivers/net: dlink: Convert timers to use timer_setup()

[David Miller]

From: Kees Cook 
Date: Thu, 26 Oct 2017 22:54:59 -0700

> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> 
> Cc: Denis Kirjanov 
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook 

Applied.

Re: [PATCH] drivers/net: chelsio/cxgb*: Convert timers to use timer_setup()

[David Miller]

From: Kees Cook 
Date: Thu, 26 Oct 2017 22:54:53 -0700

> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> 
> Cc: Santosh Raspatur 
> Cc: Ganesh Goudar 
> Cc: Casey Leedom 
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook 

Applied.

Re: [PATCH] drivers/net: chelsio/cxgb*: Convert timers to use timer_setup()

[David Miller]

From: Kees Cook 
Date: Thu, 26 Oct 2017 22:54:53 -0700

> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> 
> Cc: Santosh Raspatur 
> Cc: Ganesh Goudar 
> Cc: Casey Leedom 
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook 

Applied.

Re: [PATCH] drivers/net: appletalk/cops: Convert timers to use timer_setup()

[David Miller]

From: Kees Cook 
Date: Thu, 26 Oct 2017 22:54:45 -0700

> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> 
> Cc: Allen Pais 
> Cc: "David S. Miller" 
> Cc: David Howells 
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook 

Applied.

Re: [PATCH] drivers/net: 8390: Convert timers to use timer_setup()

[David Miller]

From: Kees Cook 
Date: Thu, 26 Oct 2017 22:54:25 -0700

> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> 
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook 

Applied.

Re: [PATCH] drivers/net: amd: Convert timers to use timer_setup()

[David Miller]

From: Kees Cook 
Date: Thu, 26 Oct 2017 22:54:38 -0700

> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> 
> Cc: Tom Lendacky 
> Cc: "David S. Miller" 
> Cc: Allen Pais 
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook 

Applied.

Re: [PATCH net] tcp: refresh tp timestamp before tcp_mtu_probe()

[David Miller]

From: Eric Dumazet 
Date: Thu, 26 Oct 2017 21:21:40 -0700

> From: Eric Dumazet 
> 
> In the unlikely event tcp_mtu_probe() is sending a packet, we
> want tp->tcp_mstamp being as accurate as possible. 
> 
> This means we need to call tcp_mstamp_refresh() a bit earlier in
> tcp_write_xmit().
> 
> Fixes: 385e20706fac ("tcp: use tp->tcp_mstamp in output path")
> Signed-off-by: Eric Dumazet 

Applied and queued up for -stable.

Re: [PATCH] ipv6: exthdrs: use swap macro in ipv6_dest_hao

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Thu, 26 Oct 2017 23:10:35 -0500

> make use of the swap macro and remove unnecessary variable tmp_addr.
> This makes the code easier to read and maintain.
> 
> This code was detected with the help of Coccinelle.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied to net-next, thanks.

Re: [PATCH V2 net] tuntap: properly align skb->head before building skb

[David Miller]

From: Jason Wang 
Date: Fri, 27 Oct 2017 11:05:44 +0800

> An unaligned alloc_frag->offset caused by previous allocation will
> result an unaligned skb->head. This will lead unaligned
> skb_shared_info and then unaligned dataref which requires to be
> aligned for accessing on some architecture. Fix this by aligning
> alloc_frag->offset before the frag refilling.
> 
> Fixes: 0bbd7dad34f8 ("tun: make tun_build_skb() thread safe")
> Cc: Eric Dumazet 
> Cc: Willem de Bruijn 
> Cc: Wei Wei 
> Cc: Dmitry Vyukov 
> Cc: Mark Rutland 
> Reported-by: Wei Wei 
> Signed-off-by: Jason Wang 

Applied and queued up for -stable, thanks Jason.

Re: [PATCH net-next] stmmac: copy unicast mac address to MAC registers

[David Miller]

From: Bhadram Varka 
Date: Fri, 27 Oct 2017 08:22:02 +0530

> Currently stmmac driver not copying the valid ethernet
> MAC address to MAC registers. This patch takes care
> of updating the MAC register with MAC address.
> 
> Signed-off-by: Bhadram Varka 

Applied, thank you.

Re: [PATCH net-next] nfp: inform the VF driver needs to be restarted after changing the MAC

[David Miller]

From: Jakub Kicinski 
Date: Thu, 26 Oct 2017 17:35:38 -0700

> From: Pablo Cascón 
> 
> Add message to inform the VF MAC was changed and the need to restart
> the VF driver for the changes to be effective.
> 
> Signed-off-by: Pablo Cascón 
> Signed-off-by: Jakub Kicinski 

Applied, thanks!

Re: [PATCH net-next] net: dsa: move fixed link registration helpers

[David Miller]

From: Vivien Didelot 
Date: Thu, 26 Oct 2017 10:50:07 -0400

> The new bindings (dsa2.c) and the old bindings (legacy.c) share two
> helpers dsa_cpu_dsa_setup and dsa_cpu_dsa_destroy, used to register or
> deregister a fixed PHY if a given port has a corresponding device node.
> 
> Unclutter the code by moving them into two new port.c helpers,
> dsa_port_fixed_link_register_of and dsa_port_fixed_link_(un)register_of.
> 
> Signed-off-by: Vivien Didelot 

Applied, thanks Vivien.

Re: [PATCH net-next] liquidio: fix kernel panic in VF driver

[David Miller]

From: Felix Manlunas 
Date: Thu, 26 Oct 2017 16:46:36 -0700

> Doing ifconfig down on VF driver in the middle of receiving line rate
> traffic causes a kernel panic:
 ...
> Reason is:  in the function assigned to net_device_ops->ndo_stop, the steps
> for bringing down the interface are done in the wrong order.  The step that
> notifies the NIC firmware to stop forwarding packets to host is done too
> late.  Fix it by moving that step to the beginning.
> 
> Signed-off-by: Felix Manlunas 
> Signed-off-by: Raghu Vatsavayi 

Applied, thanks.

Re: [PATCH net-next] bnxt_en: Fix randconfig build errors.

[David Miller]

From: Michael Chan 
Date: Sat, 28 Oct 2017 01:56:10 -0400

> Fix undefined symbols when CONFIG_VLAN_8021Q or CONFIG_INET is not set.
> 
> Fixes: 8c95f773b4a3 ("bnxt_en: add support for Flower based vxlan encap/decap 
> offload")
> Reported-by: Jakub Kicinski 
> Signed-off-by: Michael Chan 

Applied, thanks Michael.

Re: [RFC PATCH v10 0/7] PCI: rockchip: Move PCIe WAKE# handling into pci core

[Rafael J. Wysocki]

On Friday, October 27, 2017 9:26:05 AM CEST Jeffy Chen wrote:
> 
> Currently we are handling wake irq in mrvl wifi driver. Move it into
> pci core.
> 
> Tested on my chromebook bob(with cros 4.4 kernel and mrvl wifi).
> 
> 
> Changes in v10:
> Use device_set_wakeup_capable() instead of device_set_wakeup_enable(),
> since dedicated wakeirq will be lost in device_set_wakeup_enable(false).
> 
> Changes in v9:
> Add section for PCI devices and rewrite the commit message.
> Rewrite the commit message.
> Fix check error in .cleanup().
> Move dedicated wakeirq setup to setup() callback and use
> device_set_wakeup_enable() to enable/disable.
> 
> Changes in v8:
> Add optional "pci", and rewrite commit message.
> Rewrite the commit message.
> Add pci-of.c and use platform_pm_ops to handle the PCIe WAKE# signal.
> 
> Changes in v7:
> Move PCIE_WAKE handling into pci core.
> 
> Changes in v6:
> Fix device_init_wake error handling, and add some comments.
> 
> Changes in v5:
> Move to pci.txt
> Use "wakeup" instead of "wake"
> Rebase.
> 
> Changes in v3:
> Fix error handling.
> 
> Changes in v2:
> Use dev_pm_set_dedicated_wake_irq.
> 
> Jeffy Chen (7):
>   dt-bindings: PCI: Add definition of PCIe WAKE# irq and PCI irq
>   of/irq: Adjust of_pci_irq parsing for multiple interrupts
>   mwifiex: Disable wakeup irq handling for pcie
>   arm64: dts: rockchip: Move PCIe WAKE# irq to pcie driver for Gru
>   PCI: Make pci_platform_pm_ops's callbacks optional
>   PCI / PM: Move acpi wakeup code to pci core
>   PCI / PM: Add support for the PCIe WAKE# signal for OF

Overall, I don't quite like the direction this is going into, but I need to
have a deeper look.  Which may take some time, so please bear with me.

Thanks,
Rafael

Re: [patch net-next v2 00/20] net: sched: convert cls ndo_setup_tc offload calls to per-block callbacks

[Jiri Pirko]

Sat, Oct 28, 2017 at 09:53:21AM CEST, kubak...@wp.pl wrote:
>On Sat, 28 Oct 2017 09:20:31 +0200, Jiri Pirko wrote:
>> Sat, Oct 28, 2017 at 02:52:00AM CEST, kubak...@wp.pl wrote:
>> >On Fri, 27 Oct 2017 09:27:30 +0200, Jiri Pirko wrote:  
>> >> Yes, it is the same.  
>> >
>> >FWIW I also see what Amritha and Alex are describing here, for cls_bpf
>> >there are no DESTROYs coming on rmmod or qdisc del.  There is a DESTROY
>> >if I manually remove the filter (or if an ADD with skip_sw fails).  
>> 
>> Is this different to the original behaviour? Just for cls_bpf?
>
>For cls_bpf the callbacks used to be 100% symmetrical, i.e. destroy
>would always be guaranteed if add succeeded (regardless of state of
>skip_* flags).

Hmm. It still should be symmetrical. Looking at following path:
cls_bpf_destroy->
   __cls_bpf_delete->
  cls_bpf_stop_offload->
 cls_bpf_offload_cmd(tp, prog, TC_CLSBPF_DESTROY)

I don't see how any tp could be missed. Could you please check this
callpath is utilized during your action (rmmod or qdisc del)?


>
>I haven't checked cls_flower on the nfp because it implodes on add
>already...  I hear the fix is simple so I can check, if that helps.
>Although from quick code inspection it seems fl_hw_destroy_filter()
>was always invoked before fl_destroy_filter(), so it looks like since
>flower doesn't track which filters were offloaded successfully it may
>send destroy events for filter drivers don't hold, but destroy should
>always be guaranteed there too.

You are right, that is following path:
fl_delete->
   fl_hw_destroy_filter

I will check it.

Re: [PATCH] can: Use common error handling code in vxcan_newlink()

[SF Markus Elfring]

>> @@ -227,10 +227,8 @@ static int vxcan_newlink(struct net *net, struct 
>> net_device *dev,
>>   netif_carrier_off(peer);
>>     err = rtnl_configure_link(peer, ifmp);
>> -    if (err < 0) {
>> -    unregister_netdevice(peer);
>> -    return err;
>> -    }
>> +    if (err)
>> +    goto unregister_network_device;
> 
> You are changing semantic in the if-statement here.

I got an other software development opinion for this implementation detail.

http://elixir.free-electrons.com/linux/v4.14-rc6/source/net/core/rtnetlink.c#L2393
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/net/core/rtnetlink.c?id=36ef71cae353f88fd6e095e2aaa3e5953af1685d#n2513

The success predicate for the function “rtnl_configure_link” is that
the return value is zero. I would prefer to treat other values as
an error code then.


> I would be fine with the patch

Thanks for a bit of change acceptance.


> if you revert that if-statement as I would like to stay on the behavior
> from veth.c in veth_newlink().

Will another bit of clarification be useful around the usage of error 
predicates?

Regards,
Markus

Re: [PATCH v7 net-next 00/13] gtp: Additional feature support - Part I

[Harald Welte]

Hi Tom,

my apologies for only getting back to reviews now, after return from
holidays I was too overloaded with plenty of other tasks.

On Fri, Oct 27, 2017 at 05:09:24PM -0700, Tom Herbert wrote:
>   - Experimental IPv6 support

As far as I can tell, my previous comments/concerns regarding an IPv6
support that is in clear violation of how it is specified is not
acceptable to me, sorry.

The question is - as illustrated quite verbosely before - not one
of missing certain bits, but it is simply *different* from what
the protocol specification says.

This makes absolutely no sense to me.  All it will do, is it will raise
the impression that IPv6 is supported in a spec-compliant way.
Furthermore, it will mean that once somebody does convert this into
proper IPv6 support later, they will break the existing use cases of
the non-compliant implementation that you're adding in this patch
series.

To me, I simply don't understand how that makes any sense. There are no
known users of GTP outside of 3GPP networks, and particularly none of a
different GTP flavour than the one specified in 3GPP.  If there are, I
would want to hear of it.  And if there really are, I would strongly
recommend them to use some other tunneling protocol, one that's more
reasonable for normal use cases and with better protocol-level security.

I wouldn't mind merging *incomplete* IPv6 support.  However, I do mind
merging *incompatible* or *incompliant* IPv6 support.

>   - Configurable networking interfaces so that GTP kernel can be
> used and tested without needing GSN network emulation (i.e. no user
> space daemon needed).
>   - Addition of a dst_cache in the GTP structure and other cleanup

No issues with this from my side.  I plan on setting up a test system
with your patches over the weekend and give it some more testing from
the use cases I know to avoid regressions.

>   - Common functions to get a route fo for an IP tunnel
>   - Fix VXLAN gro cells initialization

Also no issues from my side, but that's for core networking folks to
decide.

> For IPv6 support, the mobile subscriber needs to allow IPv6 addresses,
> and the remote endpoint can be IPv6.

You are raising the impression - again - that this implementation will
work with any mobile subscriber.  I would bet at lot on the fact that
the current IPv6 implementation will in fact *not* work with any
existing equipment/devices out there.

> Tested:
> 
> Configured the matrix of IPv4/IPv6 mobile subscriber, 

Please indicate how that testing was done, see my comment above.

Regards,
Harald
-- 
- Harald Welte    http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Re: [patch net-next v2 00/20] net: sched: convert cls ndo_setup_tc offload calls to per-block callbacks

[Jakub Kicinski]

On Sat, 28 Oct 2017 09:20:31 +0200, Jiri Pirko wrote:
> Sat, Oct 28, 2017 at 02:52:00AM CEST, kubak...@wp.pl wrote:
> >On Fri, 27 Oct 2017 09:27:30 +0200, Jiri Pirko wrote:  
> >> Yes, it is the same.  
> >
> >FWIW I also see what Amritha and Alex are describing here, for cls_bpf
> >there are no DESTROYs coming on rmmod or qdisc del.  There is a DESTROY
> >if I manually remove the filter (or if an ADD with skip_sw fails).  
> 
> Is this different to the original behaviour? Just for cls_bpf?

For cls_bpf the callbacks used to be 100% symmetrical, i.e. destroy
would always be guaranteed if add succeeded (regardless of state of
skip_* flags).

I haven't checked cls_flower on the nfp because it implodes on add
already...  I hear the fix is simple so I can check, if that helps.
Although from quick code inspection it seems fl_hw_destroy_filter()
was always invoked before fl_destroy_filter(), so it looks like since
flower doesn't track which filters were offloaded successfully it may
send destroy events for filter drivers don't hold, but destroy should
always be guaranteed there too.

Re: [patch net-next v2 00/20] net: sched: convert cls ndo_setup_tc offload calls to per-block callbacks

[Jiri Pirko]

Sat, Oct 28, 2017 at 02:52:00AM CEST, kubak...@wp.pl wrote:
>On Fri, 27 Oct 2017 09:27:30 +0200, Jiri Pirko wrote:
>> >>> 2.   Deleting the ingress qdisc fails to remove filters added in
>> >>> HW. Filters in SW gets deleted.
>> >>>
>> >>> We haven’t exactly root-caused this, the changes being extensive, but
>> >>> our guess is again something wrong with the offload check or similar
>> >>> while unregistering the block callback (tcf_block_cb_unregister) and
>> >>> further to the classifier (CLS_U32/CLS_FLOWER etc.) with the
>> >>> DESTROY/REMOVE command.  
>> >> 
>> >> Hmm. How does this worked previously. I mean, do you see change of
>> >> behaviour? I'm asking because I don't see how rules added only to HW
>> >> could be removed, driver should care of it. Or are you talking about
>> >> rules added to both SW and HW?  
>> >
>> >These are rules added to both SW and HW. Previously all cls_* had
>> >ndo_setup_tc calls based on the offload capability.
>> >
>> >commit 8d26d5636d "net: sched: avoid ndo_setup_tc calls for
>> >TC_SETUP_CLS*" removed this bit to work with the new block callback. Is
>> >there something similar in the block callback flow while acting on the
>> >tcf_proto destroy call initiated when the qdisc is cleared?  
>> 
>> Yes, it is the same.
>
>FWIW I also see what Amritha and Alex are describing here, for cls_bpf
>there are no DESTROYs coming on rmmod or qdisc del.  There is a DESTROY
>if I manually remove the filter (or if an ADD with skip_sw fails).

Is this different to the original behaviour? Just for cls_bpf?

Re: [PATCH net-next v4 02/10] devlink: Adding SR-IOV enablement perm config param

[Jiri Pirko]

Fri, Oct 27, 2017 at 11:30:06PM CEST, steven.l...@broadcom.com wrote:
>On Fri, Oct 27, 2017 at 5:06 PM, Jiri Pirko  wrote:
>> Fri, Oct 27, 2017 at 10:54:06PM CEST, steven.l...@broadcom.com wrote:
>>>Adding DEVLINK_PERM_CONFIG_SRIOV_ENABLED permanent config
>>>parameter.  Value is permanent, so becomes the new default
>>
>> Avoid the double space.
>
>Ok.
>
>>
>>
>>>value for this device.
>>>
>>>  DEVLINK_PERM_CONFIG_DISABLE = Disable SR-IOV
>>>  DEVLINK_PERM_CONFIG_ENABLE  = Enable SR-IOV
>>>
>>>Signed-off-by: Steve Lin 
>>>Acked-by: Andy Gospodarek 
>>>---
>>> include/uapi/linux/devlink.h | 14 +-
>>> net/core/devlink.c   |  1 +
>>> 2 files changed, 14 insertions(+), 1 deletion(-)
>>>
>>>diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
>>>index b3a0b2a..9a41f6e 100644
>>>--- a/include/uapi/linux/devlink.h
>>>+++ b/include/uapi/linux/devlink.h
>>>@@ -256,8 +256,20 @@ enum devlink_dpipe_header_id {
>>>   DEVLINK_DPIPE_HEADER_IPV6,
>>> };
>>>
>>>-/* Permanent config parameters */
>>>+enum devlink_perm_config_enabled {
>>>+  DEVLINK_PERM_CONFIG_DISABLE,
>>>+  DEVLINK_PERM_CONFIG_ENABLE,
>>>+};
>>>+
>>>+/* Permanent config parameters:
>>>+ * DEVLINK_PERM_CONFIG_SRIOV_ENABLED: Configures whether SR-IOV PCI 
>>>capability
>>>+ * provided by device.
>>
>> I don't understand the sentense :/
>
>It means that this parameter controls whether the device advertises
>SR-IOV PCI capability -- perhaps I should say "advertised" rather than
>"provided"?  Ok, will do that...

I'm missing "is" most probably.

>
>>
>>
>>>+ *   DEVLINK_PERM_CONFIG_DISABLE = disable SR-IOV
>>>+ *   DEVLINK_PERM_CONFIG_ENABLE  = enable SR-IOV
>>
>> These comments should be at the enum values, not here.
>
>Ok.
>
>>
>>
>>>+ */
>>> enum devlink_perm_config_param {
>>>+  DEVLINK_PERM_CONFIG_SRIOV_ENABLED,
>>>+
>>>   __DEVLINK_PERM_CONFIG_MAX,
>>>   DEVLINK_PERM_CONFIG_MAX = __DEVLINK_PERM_CONFIG_MAX - 1
>>> };
>>>diff --git a/net/core/devlink.c b/net/core/devlink.c
>>>index a7fa7cc..395c93c 100644
>>>--- a/net/core/devlink.c
>>>+++ b/net/core/devlink.c
>>>@@ -1569,6 +1569,7 @@ static int devlink_nl_cmd_eswitch_set_doit(struct 
>>>sk_buff *skb,
>>> static const struct nla_policy devlink_nl_policy[DEVLINK_ATTR_MAX + 1];
>>>
>>> static const u8 devlink_perm_cfg_param_types[DEVLINK_PERM_CONFIG_MAX + 1] = 
>>> {
>>>+  [DEVLINK_PERM_CONFIG_SRIOV_ENABLED] = NLA_U8,
>>> };
>>>
>>> static int devlink_nl_single_param_get(struct sk_buff *msg,
>>>--
>>>2.7.4
>>>