RE: [PATCH] net: intel: e1000: use new api ethtool_{get|set}_link_ksettings
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Philippe Reynes
> Sent: Saturday, January 21, 2017 7:06 AM
> To: Kirsher, Jeffrey T ; da...@davemloft.net
> Cc: intel-wired-...@lists.osuosl.org; netdev@vger.kernel.org; linux-
> ker...@vger.kernel.org; Philippe Reynes
> Subject: [PATCH] net: intel: e1000: use new api
> ethtool_{get|set}_link_ksettings
>
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
>
> Signed-off-by: Philippe Reynes
> ---
> drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 93 +++-
> --
> 1 files changed, 46 insertions(+), 47 deletions(-)
Tested-by: Aaron Brown
Re: [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY
On Fri, Feb 24, 2017 at 6:03 PM, Alexei Starovoitov
wrote:
> On Wed, Feb 22, 2017 at 11:38:49AM -0500, Willem de Bruijn wrote:
>>
>> * Limitations / Known Issues
>>
>> - PF_INET6 is not yet supported.
>
> we struggled so far to make it work in our setups which are ipv6 only.
> Looking at patches it seems the code should just work.
> What particularly is missing ?
>
> Great stuff. Looking forward to net-next reopening :)
Thanks for taking the feature for a spin!
The udp and raw paths require separate ipv6 patches. TCP should indeed
just work. I just ran a slightly modified snd_zerocopy_lo with good
results as well as a hacked netperf to another host.
I should have had ipv6 from the start, of course. Will add it before
resubmitting when net-next opens. For now, quick hack to
snd_zerocopy_lo.c:
diff --git a/tools/testing/selftests/net/snd_zerocopy_lo.c
b/tools/testing/selftests/net/snd_zerocopy_lo.c
index 309b016a4fd5..38a165e2af64 100644
--- a/tools/testing/selftests/net/snd_zerocopy_lo.c
+++ b/tools/testing/selftests/net/snd_zerocopy_lo.c
@@ -453,7 +453,7 @@ static int do_setup_rx(int domain, int type, int protocol)
static void do_setup_and_run(int domain, int type, int protocol)
{
- struct sockaddr_in addr;
+ struct sockaddr_in6 addr;
socklen_t alen;
int fdr, fdt, ret;
@@ -468,8 +468,8 @@ static void do_setup_and_run(int domain, int type,
int protocol)
if (domain != PF_PACKET) {
memset(&addr, 0, sizeof(addr));
- addr.sin_family = AF_INET;
- addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
+ addr.sin6_family = AF_INET6;
+ addr.sin6_addr = in6addr_loopback;
alen = sizeof(addr);
if (bind(fdr, (void *) &addr, sizeof(addr)))
@@ -589,7 +589,7 @@ int main(int argc, char **argv)
if (cfg_test_raw_hdrincl)
do_setup_and_run(PF_INET, SOCK_RAW, IPPROTO_RAW);
if (cfg_test_tcp)
- do_setup_and_run(PF_INET, SOCK_STREAM, 0);
+ do_setup_and_run(PF_INET6, SOCK_STREAM, 0);
Loopback zerocopy is disabled in RFCv2, so to use snd_zerocopy_lo to verify the
feature requires this hack in skb_orphan_frags_rx:
static inline int skb_orphan_frags_rx(struct sk_buff *skb, gfp_t gfp_mask)
{
- if (likely(!skb_zcopy(skb)))
- return 0;
- return skb_copy_ubufs(skb, gfp_mask);
+ return skb_orphan_frags(skb, gfp_mask);
}
With this change, I see
$ ./snd_zerocopy_lo_ipv6 -t
test socket(10, 1, 0)
cpu: 23
rx=106364 (6637 MB) tx=106364 txc=0
rx=209736 (13088 MB) tx=209736 txc=0
rx=314524 (19627 MB) tx=314524 txc=0
rx=419424 (26174 MB) tx=419424 txc=0
OK. All tests passed
$ ./snd_zerocopy_lo_ipv6 -t -z
test socket(10, 1, 0)
cpu: 23
rx=239792 (14964 MB) tx=239792 txc=239786
rx=477376 (29790 MB) tx=477376 txc=477370
rx=715016 (44620 MB) tx=715016 txc=715010
rx=952820 (59460 MB) tx=952820 txc=952814
OK. All tests passed
In comparison, the same without the change
$ ./snd_zerocopy_lo_ipv6 -t
test socket(10, 1, 0)
cpu: 23
rx=109908 (6858 MB) tx=109908 txc=0
rx=217100 (13548 MB) tx=217100 txc=0
rx=326584 (20380 MB) tx=326584 txc=0
rx=429568 (26807 MB) tx=429568 txc=0
OK. All tests passed
$ ./snd_zerocopy_lo_ipv6 -t -z
test socket(10, 1, 0)
cpu: 23
rx=87636 (5468 MB) tx=87636 txc=87630
rx=174328 (10878 MB) tx=174328 txc=174322
rx=260360 (16247 MB) tx=260360 txc=260354
rx=346512 (21623 MB) tx=346512 txc=346506
Here the sk_buff hits the deep copy in skb_copy_ubufs called from
__netif_receive_skb_core, which actually degrades performance versus
copying as part of the sendmsg() syscall.
The netperf change is to add MSG_ZEROCOPY to send() in send_tcp_stream
and also adding a recvmsg(send_socket, &msg, MSG_ERRQUEUE) to the same
function, preferably called only once every N iterations. This does
not take any additional explicit references on the send_ring element
while data is in flight, so is really a hack, but ring contents should
be static throughout the test. I did not modify the omni tests, so
this requires building with --no-omni.
Re: [PATCH] iproute2: tc: introduce build dependency on libnetlink
On Fri, 24 Feb 2017 18:28:54 +0100 (CET) Jiri Kosina wrote: > From: Jiri Kosina > > Rebuilding libnetlink doesn't trigger rebuild of tc, which is wrong > (especially so for builds where libnetlink.a gets statically linked into > tc). Fix that by introducing an explicit dependency. > > Signed-off-by: Jiri Kosina Makes sense, Applied
Re: [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY
On Wed, Feb 22, 2017 at 11:38:49AM -0500, Willem de Bruijn wrote: > > * Limitations / Known Issues > > - PF_INET6 is not yet supported. we struggled so far to make it work in our setups which are ipv6 only. Looking at patches it seems the code should just work. What particularly is missing ? Great stuff. Looking forward to net-next reopening :)
Re: [PATCH] bridge: Add support for IEEE 802.11 Proxy ARP for IPv6
Hi Jouni, [auto build test ERROR on net-next/master] [also build test ERROR on next-20170224] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jouni-Malinen/bridge-Add-support-for-IEEE-802-11-Proxy-ARP-for-IPv6/20170225-024548 config: x86_64-rhel (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 >>): >> ERROR: "icmpv6_flow_init" [net/bridge/bridge.ko] undefined! >> ERROR: "icmp6_dst_alloc" [net/bridge/bridge.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH net 1/1] net sched actions: do not overwrite status of action creation.
nla_memdup_cookie was overwriting err value, declared at function
scope and earlier initialized with result of ->init(). At success
nla_memdup_cookie() returns 0, and thus module refcnt decremented,
although the action was installed.
$ sudo tc actions add action pass index 1 cookie 1234
$ sudo tc actions ls action gact
action order 0: gact action pass
random type none pass val 0
index 1 ref 1 bind 0
$
$ lsmod
Module Size Used by
act_gact 16384 0
...
$
$ sudo rmmod act_gact
[ 52.310283] [ cut here ]
[ 52.312551] WARNING: CPU: 1 PID: 455 at kernel/module.c:1113
module_put+0x99/0xa0
[ 52.316278] Modules linked in: act_gact(-) crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel psmouse pcbc evbug aesni_intel aes_x86_64 crypto_simd
serio_raw glue_helper pcspkr cryptd
[ 52.322285] CPU: 1 PID: 455 Comm: rmmod Not tainted 4.10.0+ #11
[ 52.324261] Call Trace:
[ 52.325132] dump_stack+0x63/0x87
[ 52.326236] __warn+0xd1/0xf0
[ 52.326260] warn_slowpath_null+0x1d/0x20
[ 52.326260] module_put+0x99/0xa0
[ 52.326260] tcf_hashinfo_destroy+0x7f/0x90
[ 52.326260] gact_exit_net+0x27/0x40 [act_gact]
[ 52.326260] ops_exit_list.isra.6+0x38/0x60
[ 52.326260] unregister_pernet_operations+0x90/0xe0
[ 52.326260] unregister_pernet_subsys+0x21/0x30
[ 52.326260] tcf_unregister_action+0x68/0xa0
[ 52.326260] gact_cleanup_module+0x17/0xa0f [act_gact]
[ 52.326260] SyS_delete_module+0x1ba/0x220
[ 52.326260] entry_SYSCALL_64_fastpath+0x1e/0xad
[ 52.326260] RIP: 0033:0x7f527ffae367
[ 52.326260] RSP: 002b:7ffeb402a598 EFLAGS: 0202 ORIG_RAX:
00b0
[ 52.326260] RAX: ffda RBX: 559b069912a0 RCX: 7f527ffae367
[ 52.326260] RDX: 000a RSI: 0800 RDI: 559b06991308
[ 52.326260] RBP: 0003 R08: 7f5280264420 R09: 7ffeb4029511
[ 52.326260] R10: 087b R11: 0202 R12: 7ffeb4029580
[ 52.326260] R13: R14: R15: 559b069912a0
[ 52.354856] ---[ end trace 90d89401542b0db6 ]---
$
With the fix:
$ sudo modprobe act_gact
$ lsmod
Module Size Used by
act_gact 16384 0
...
$ sudo tc actions add action pass index 1 cookie 1234
$ sudo tc actions ls action gact
action order 0: gact action pass
random type none pass val 0
index 1 ref 1 bind 0
$
$ lsmod
Module Size Used by
act_gact 16384 1
...
$ sudo rmmod act_gact
rmmod: ERROR: Module act_gact is in use
$
$ sudo /home/mrv/bin/tc actions del action gact index 1
$ sudo rmmod act_gact
$ lsmod
Module Size Used by
$
Fixes: 1045ba77a ("net sched actions: Add support for user cookies")
Signed-off-by: Roman Mashak
Signed-off-by: Jamal Hadi Salim
---
net/sched/act_api.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index f219ff3..e59cb09 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -613,8 +613,8 @@ struct tc_action *tcf_action_init_1(struct net *net, struct
nlattr *nla,
goto err_mod;
}
- err = nla_memdup_cookie(a, tb);
- if (err < 0) {
+ if (nla_memdup_cookie(a, tb) < 0) {
+ err = -ENOMEM;
tcf_hash_release(a, bind);
goto err_mod;
}
--
1.9.1
[4.10+] sctp lockdep trace
[ 244.251557] ===
[ 244.263321] [ ERR: suspicious RCU usage. ]
[ 244.274982] 4.10.0-think+ #7 Not tainted
[ 244.286511] ---
[ 244.298008] ./include/linux/rhashtable.h:602 suspicious
rcu_dereference_check() usage!
[ 244.309665]
other info that might help us debug this:
[ 244.344629]
rcu_scheduler_active = 2, debug_locks = 1
[ 244.367839] 1 lock held by trinity-c30/1781:
[ 244.379481] #0:
[ 244.390848] (
[ 244.402372] sk_lock-AF_INET
[ 244.413825] ){+.+.+.}
[ 244.425231] , at: [] sctp_sendmsg+0x330/0xfe0 [sctp]
[ 244.436774]
stack backtrace:
[ 244.459620] CPU: 3 PID: 1781 Comm: trinity-c30 Not tainted 4.10.0-think+ #7
[ 244.482790] Call Trace:
[ 244.494201] dump_stack+0x68/0x93
[ 244.505598] lockdep_rcu_suspicious+0xce/0xf0
[ 244.516924] sctp_hash_transport+0x406/0x7e0 [sctp]
[ 244.528137] ? sctp_endpoint_bh_rcv+0x171/0x290 [sctp]
[ 244.539243] sctp_assoc_add_peer+0x290/0x3c0 [sctp]
[ 244.550291] sctp_sendmsg+0x8f7/0xfe0 [sctp]
[ 244.561258] ? rw_copy_check_uvector+0x8e/0x190
[ 244.572308] ? import_iovec+0x3a/0xe0
[ 244.583232] inet_sendmsg+0x49/0x1e0
[ 244.594150] ___sys_sendmsg+0x2d4/0x300
[ 244.605002] ? debug_smp_processor_id+0x17/0x20
[ 244.615844] ? debug_smp_processor_id+0x17/0x20
[ 244.626533] ? get_lock_stats+0x19/0x50
[ 244.637141] __sys_sendmsg+0x54/0x90
[ 244.647817] SyS_sendmsg+0x12/0x20
[ 244.658400] do_syscall_64+0x66/0x1d0
[ 244.668990] entry_SYSCALL64_slow_path+0x25/0x25
[ 244.679582] RIP: 0033:0x7fe095fcb0f9
[ 244.690079] RSP: 002b:7ffc5601b1d8 EFLAGS: 0246
[ 244.700704] ORIG_RAX: 002e
[ 244.711248] RAX: ffda RBX: 002e RCX: 7fe095fcb0f9
[ 244.721818] RDX: 0080 RSI: 5592de12ddc0 RDI: 012d
[ 244.732282] RBP: 7fe0965c8000 R08: c000 R09: 00dc
[ 244.742576] R10: 000302120088 R11: 0246 R12: 0002
[ 244.752804] R13: 7fe0965c8048 R14: 7fe0966a1ad8 R15: 7fe0965c8000
[ 244.775549] ===
[ 244.785875] [ ERR: suspicious RCU usage. ]
[ 244.796951] 4.10.0-think+ #7 Not tainted
[ 244.807185] ---
[ 244.819213] ./include/linux/rhashtable.h:605 suspicious
rcu_dereference_check() usage!
[ 244.829420]
other info that might help us debug this:
[ 244.859963]
rcu_scheduler_active = 2, debug_locks = 1
[ 244.879766] 1 lock held by trinity-c30/1781:
[ 244.889953] #0:
[ 244.90] (
[ 244.909854] sk_lock-AF_INET
[ 244.919645] ){+.+.+.}
[ 244.929238] , at: [] sctp_sendmsg+0x330/0xfe0 [sctp]
[ 244.939167]
stack backtrace:
[ 244.958506] CPU: 3 PID: 1781 Comm: trinity-c30 Not tainted 4.10.0-think+ #7
[ 244.978102] Call Trace:
[ 244.987735] dump_stack+0x68/0x93
[ 244.997112] lockdep_rcu_suspicious+0xce/0xf0
[ 245.006588] sctp_hash_transport+0x4ca/0x7e0 [sctp]
[ 245.016264] ? sctp_endpoint_bh_rcv+0x171/0x290 [sctp]
[ 245.025797] sctp_assoc_add_peer+0x290/0x3c0 [sctp]
[ 245.035380] sctp_sendmsg+0x8f7/0xfe0 [sctp]
[ 245.044883] ? rw_copy_check_uvector+0x8e/0x190
[ 245.054464] ? import_iovec+0x3a/0xe0
[ 245.064016] inet_sendmsg+0x49/0x1e0
[ 245.073516] ___sys_sendmsg+0x2d4/0x300
[ 245.082967] ? debug_smp_processor_id+0x17/0x20
[ 245.092448] ? debug_smp_processor_id+0x17/0x20
[ 245.101850] ? get_lock_stats+0x19/0x50
[ 245.70] __sys_sendmsg+0x54/0x90
[ 245.120451] SyS_sendmsg+0x12/0x20
[ 245.129649] do_syscall_64+0x66/0x1d0
[ 245.138783] entry_SYSCALL64_slow_path+0x25/0x25
[ 245.147678] RIP: 0033:0x7fe095fcb0f9
[ 245.156588] RSP: 002b:7ffc5601b1d8 EFLAGS: 0246
[ 245.165503] ORIG_RAX: 002e
[ 245.174601] RAX: ffda RBX: 002e RCX: 7fe095fcb0f9
[ 245.183861] RDX: 0080 RSI: 5592de12ddc0 RDI: 012d
[ 245.193038] RBP: 7fe0965c8000 R08: c000 R09: 00dc
[ 245.202214] R10: 000302120088 R11: 0246 R12: 0002
[ 245.211261] R13: 7fe0965c8048 R14: 7fe0966a1ad8 R15: 7fe0965c8000
[ 245.308216] ===
[ 245.317295] [ ERR: suspicious RCU usage. ]
[ 245.327876] 4.10.0-think+ #7 Not tainted
[ 245.337065] ---
[ 245.345840] ./include/linux/rhashtable.h:616 suspicious
rcu_dereference_check() usage!
[ 245.356501]
other info that might help us debug this:
[ 245.382185]
rcu_scheduler_active = 2, debug_locks = 1
[ 245.399415] 1 lock held by trinity-c30/1781:
[ 245.408138] #0:
[ 245.416594] (
[ 245.424928] sk_lock-AF_INET
[ 245.433279] ){+.+.+.}
[ 245.441889] , at: [] sctp_sendmsg+0x330/0xfe0 [sctp]
[ 245.450167]
stack backtrace:
[ 245.466352] CPU: 3 PID: 1781 Comm: trinity-c30 Not tainted 4.10.0-think+ #7
[ 245.482894
Re: [PATCH net 1/1] net sched actions: decrement module reference count after table flush.
Cong Wang writes: > On Fri, Feb 24, 2017 at 8:00 AM, Roman Mashak wrote: >> When tc actions are loaded as a module and no actions have been installed, >> flushing them would result in actions removed from the memory, but modules >> reference count not being decremented, so that the modules would not be >> unloaded. [...] > Fixes commit f97017cdefefdb6a0e19266024b0c6f9fd411eeb ? Yes, exactly. > Acked-by: Cong Wang -- Roman Mashak
[PATCH net] rxrpc: Kernel calls get stuck in recvmsg
Calls made through the in-kernel interface can end up getting stuck because
of a missed variable update in a loop in rxrpc_recvmsg_data(). The problem
is like this:
(1) A new packet comes in and doesn't cause a notification to be given to
the client as there's still another packet in the ring - the
assumption being that if the client will keep drawing off data until
the ring is empty.
(2) The client is in rxrpc_recvmsg_data(), inside the big while loop that
iterates through the packets. This copies the window pointers into
variables rather than using the information in the call struct
because:
(a) MSG_PEEK might be in effect;
(b) we need a barrier after reading call->rx_top to pair with the
barrier in the softirq routine that loads the buffer.
(3) The reading of call->rx_top is done outside of the loop, and top is
never updated whilst we're in the loop. This means that even through
there's a new packet available, we don't see it and may return -EFAULT
to the caller - who will happily return to the scheduler and await the
next notification.
(4) No further notifications are forthcoming until there's an abort as the
ring isn't empty.
The fix is to move the read of call->rx_top inside the loop - but it needs
to be done before the condition is checked.
Reported-by: Marc Dionne
Signed-off-by: David Howells
Tested-by: Marc Dionne
---
net/rxrpc/recvmsg.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/rxrpc/recvmsg.c b/net/rxrpc/recvmsg.c
index c29362d50a92..f3a688e10843 100644
--- a/net/rxrpc/recvmsg.c
+++ b/net/rxrpc/recvmsg.c
@@ -320,8 +320,10 @@ static int rxrpc_recvmsg_data(struct socket *sock, struct
rxrpc_call *call,
/* Barriers against rxrpc_input_data(). */
hard_ack = call->rx_hard_ack;
- top = smp_load_acquire(&call->rx_top);
- for (seq = hard_ack + 1; before_eq(seq, top); seq++) {
+ seq = hard_ack + 1;
+ while (top = smp_load_acquire(&call->rx_top),
+ before_eq(seq, top)
+ ) {
ix = seq & RXRPC_RXTX_BUFF_MASK;
skb = call->rxtx_buffer[ix];
if (!skb) {
@@ -394,6 +396,8 @@ static int rxrpc_recvmsg_data(struct socket *sock, struct
rxrpc_call *call,
ret = 1;
goto out;
}
+
+ seq++;
}
out:
Re: [PATCH] drivers: net: xgene: Simplify xgene_enet_setup_mss() to kill warning
On Fri, Feb 24, 2017 at 2:30 AM, Geert Uytterhoeven
wrote:
> With gcc-4.1.2 and -Os:
>
> drivers/net/ethernet/apm/xgene/xgene_enet_main.c: In function
> ‘xgene_enet_start_xmit’:
> drivers/net/ethernet/apm/xgene/xgene_enet_main.c:297: warning:
> ‘mss_index’ may be used uninitialized in this function
>
> Using a separate variable to track success may confuse the compiler.
> Preinitialize mss_index with -EBUSY and check for negative error values
> instead to kill the warning.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Compile-tested only.
>
> drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 13 +++--
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> index d0d0d12b531fc683..e536301acfdec9fd 100644
> --- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> @@ -293,36 +293,29 @@ static int xgene_enet_tx_completion(struct
> xgene_enet_desc_ring *cp_ring,
> static int xgene_enet_setup_mss(struct net_device *ndev, u32 mss)
> {
> struct xgene_enet_pdata *pdata = netdev_priv(ndev);
> - bool mss_index_found = false;
> - int mss_index;
> + int mss_index = -EBUSY;
> int i;
>
> spin_lock(&pdata->mss_lock);
>
> /* Reuse the slot if MSS matches */
> - for (i = 0; !mss_index_found && i < NUM_MSS_REG; i++) {
> + for (i = 0; mss_index < 0 && i < NUM_MSS_REG; i++) {
> if (pdata->mss[i] == mss) {
> pdata->mss_refcnt[i]++;
> mss_index = i;
> - mss_index_found = true;
> }
> }
>
> /* Overwrite the slot with ref_count = 0 */
> - for (i = 0; !mss_index_found && i < NUM_MSS_REG; i++) {
> + for (i = 0; mss_index < 0 && i < NUM_MSS_REG; i++) {
> if (!pdata->mss_refcnt[i]) {
> pdata->mss_refcnt[i]++;
> pdata->mac_ops->set_mss(pdata, mss, i);
> pdata->mss[i] = mss;
> mss_index = i;
> - mss_index_found = true;
> }
> }
>
> - /* No slots with ref_count = 0 available, return busy */
> - if (!mss_index_found)
> - mss_index = -EBUSY;
> -
> spin_unlock(&pdata->mss_lock);
>
> return mss_index;
> --
> 2.7.4
>
Thanks.
Acked-by: Iyappan Subramanian
Re: [PATCH] bridge: Add support for IEEE 802.11 Proxy ARP for IPv6
The concept is fine. Please add some comments to the code about what is happening and why. The proposed patch is too sparse and has no comments. > + skb = alloc_skb(hlen + sizeof(struct ipv6hdr) + sizeof(*msg) + > + ndisc_opt_addr_space(dev, > + NDISC_NEIGHBOUR_ADVERTISEMENT) + > + tlen, GFP_ATOMIC); > + if (!skb) > + return; Why not netdev_alloc_skb which takes care of padding and setting skb->dev? Rather than doing copy/paste of the code to generate a ND message, it would be better to have one function in IPv6 code that handles that. That would keep from having to fix code in two places in the future. Is there some way to extend ndisc_send_na?
[PATCH net 0/2] VXLAN/geneve RCU fixes
Hi! VXLAN and GENEVE need to take RCU lock explicitly because TX path only has the _bh() flavour of RCU locked. Making the reconfiguration path wait for both normal and _bh() RCU would be bigger hassle so just acquire the lock, as suggested by Pravin: https://www.mail-archive.com/netdev@vger.kernel.org/msg155583.html Jakub Kicinski (2): vxlan: lock RCU on TX path geneve: lock RCU on TX path drivers/net/geneve.c | 2 ++ drivers/net/vxlan.c | 8 ++-- 2 files changed, 8 insertions(+), 2 deletions(-) -- 2.11.0
[PATCH net 1/2] vxlan: lock RCU on TX path
There is no guarantees that callers of the TX path will hold
the RCU lock. Grab it explicitly.
Fixes: c6fcc4fc5f8b ("vxlan: avoid using stale vxlan socket.")
Signed-off-by: Jakub Kicinski
---
drivers/net/vxlan.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 4e27c5b09600..e53ee696c962 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2108,6 +2108,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct
net_device *dev,
src_port = udp_flow_src_port(dev_net(dev), skb, vxlan->cfg.port_min,
vxlan->cfg.port_max, true);
+ rcu_read_lock();
if (dst->sa.sa_family == AF_INET) {
struct vxlan_sock *sock4 = rcu_dereference(vxlan->vn4_sock);
struct rtable *rt;
@@ -2130,7 +2131,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct
net_device *dev,
dst_port, vni, &rt->dst,
rt->rt_flags);
if (err)
- return;
+ goto out_unlock;
} else if (info->key.tun_flags & TUNNEL_DONT_FRAGMENT) {
df = htons(IP_DF);
}
@@ -2169,7 +2170,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct
net_device *dev,
dst_port, vni, ndst,
rt6i_flags);
if (err)
- return;
+ goto out_unlock;
}
tos = ip_tunnel_ecn_encap(tos, old_iph, skb);
@@ -2186,6 +2187,8 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct
net_device *dev,
label, src_port, dst_port, !udp_sum);
#endif
}
+out_unlock:
+ rcu_read_unlock();
return;
drop:
@@ -2194,6 +2197,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct
net_device *dev,
return;
tx_error:
+ rcu_read_unlock();
if (err == -ELOOP)
dev->stats.collisions++;
else if (err == -ENETUNREACH)
--
2.11.0
[PATCH net 2/2] geneve: lock RCU on TX path
There is no guarantees that callers of the TX path will hold
the RCU lock. Grab it explicitly.
Fixes: fceb9c3e3825 ("geneve: avoid using stale geneve socket.")
Signed-off-by: Jakub Kicinski
---
drivers/net/geneve.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 45301cb98bc1..7074b40ebd7f 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -881,12 +881,14 @@ static netdev_tx_t geneve_xmit(struct sk_buff *skb,
struct net_device *dev)
info = &geneve->info;
}
+ rcu_read_lock();
#if IS_ENABLED(CONFIG_IPV6)
if (info->mode & IP_TUNNEL_INFO_IPV6)
err = geneve6_xmit_skb(skb, dev, geneve, info);
else
#endif
err = geneve_xmit_skb(skb, dev, geneve, info);
+ rcu_read_unlock();
if (likely(!err))
return NETDEV_TX_OK;
--
2.11.0
Re: VXLAN RCU error
On Fri, 24 Feb 2017 11:30:05 -0800, Cong Wang wrote: > On Thu, Feb 23, 2017 at 12:20 AM, Jakub Kicinski wrote: > > > > Ugh. Looks like this may not work even if it makes the splat go away. > > synchronize_net() doesn't seem to wait for the _bh() flavor of RCU, so > > we need to add syncronize_rcu_bh() call before freeing the socket or do > > a normal rcu_read_lock()/unlock() on the fast path. Any RCU experts > > want to comment? :) > > But rcu_read_lock_bh() is enforced by upper layer, __dev_queue_xmit(), > I am afraid you can't change it. > > Does changing these kfree() to kfree_rcu() work too since there is no > kfree_rcu_bh()? If I read the code correctly the VXLAN/GENEVE does standard RCU dereferencing (i.e. non-_bh()) but as you point out __dev_queue_xmit() takes rcu_read_lock_bh() and not rcu_read_lock() so we either have to make VXLAN code take the correct lock itself or make VXLAN reconfiguration code do synchronize_rcu_bh() as well as synchronize_net() (most likely with synchronize_rcu_mult() but then we will have to open code expediting under rtnl...) I was waiting for some internal reviews but let me just post the code I have now implementing the first option.
Re: VXLAN RCU error
On Thu, Feb 23, 2017 at 12:20 AM, Jakub Kicinski wrote: > > Ugh. Looks like this may not work even if it makes the splat go away. > synchronize_net() doesn't seem to wait for the _bh() flavor of RCU, so > we need to add syncronize_rcu_bh() call before freeing the socket or do > a normal rcu_read_lock()/unlock() on the fast path. Any RCU experts > want to comment? :) But rcu_read_lock_bh() is enforced by upper layer, __dev_queue_xmit(), I am afraid you can't change it. Does changing these kfree() to kfree_rcu() work too since there is no kfree_rcu_bh()?
Re: [PATCH] drivers: net: xgene: Simplify xgene_enet_setup_mss() to kill warning
From: Geert Uytterhoeven Date: Fri, 24 Feb 2017 11:30:03 +0100 > With gcc-4.1.2 and -Os: > > drivers/net/ethernet/apm/xgene/xgene_enet_main.c: In function > ‘xgene_enet_start_xmit’: > drivers/net/ethernet/apm/xgene/xgene_enet_main.c:297: warning: > ‘mss_index’ may be used uninitialized in this function > > Using a separate variable to track success may confuse the compiler. > Preinitialize mss_index with -EBUSY and check for negative error values > instead to kill the warning. > > Signed-off-by: Geert Uytterhoeven Applied, thank you.
Re: [PATCH 1/1] rds: fix memory leak error
From: Santosh Shilimkar Date: Fri, 24 Feb 2017 08:49:19 -0800 > On 2/24/2017 1:28 AM, Zhu Yanjun wrote: >> When the function register_netdevice_notifier fails, the memory >> allocated by kmem_cache_create should be freed by the function >> kmem_cache_destroy. >> >> Cc: Joe Jin >> Cc: Junxiao Bi >> Signed-off-by: Zhu Yanjun >> --- > Minor nit with subject. > s/rds/RDS: TCP: Please, I definitely prefer people use all lowercase letters for the susbsystem prefix in the subject line.
Re: [PATCH 1/1] rds: fix memory leak error
On 2/24/17 11:12 AM, David Miller wrote: From: Santosh Shilimkar Date: Fri, 24 Feb 2017 08:49:19 -0800 On 2/24/2017 1:28 AM, Zhu Yanjun wrote: When the function register_netdevice_notifier fails, the memory allocated by kmem_cache_create should be freed by the function kmem_cache_destroy. Cc: Joe Jin Cc: Junxiao Bi Signed-off-by: Zhu Yanjun --- Minor nit with subject. s/rds/RDS: TCP: Please, I definitely prefer people use all lowercase letters for the susbsystem prefix in the subject line. Note for the future. Thanks Dave !! Regards, Santosh
Re: [PATCH 1/1] rds: fix memory leak error
From: Zhu Yanjun Date: Fri, 24 Feb 2017 04:28:01 -0500 > When the function register_netdevice_notifier fails, the memory > allocated by kmem_cache_create should be freed by the function > kmem_cache_destroy. > > Cc: Joe Jin > Cc: Junxiao Bi > Signed-off-by: Zhu Yanjun Applied, thank you.
Re: [PATCH net v2] vxlan: don't allow overwrite of config src addr
From: Brian Russell
Date: Fri, 24 Feb 2017 17:47:11 +
> When using IPv6 transport and a default dst, a pointer to the configured
> source address is passed into the route lookup. If no source address is
> configured, then the value is overwritten.
>
> IPv6 route lookup ignores egress ifindex match if the source address is set,
> so if egress ifindex match is desired, the source address must be passed
> as any. The overwrite breaks this for subsequent lookups.
>
> Avoid this by copying the configured address to an existing stack variable
> and pass a pointer to that instead.
>
> Fixes: 272d96a5ab10 ("net: vxlan: lwt: Use source ip address during route
> lookup.")
>
> Signed-off-by: Brian Russell
> Acked-by: Jiri Benc
Applied and queued up for -stable, thanks.
[PATCH] iproute2: tc: introduce build dependency on libnetlink
From: Jiri Kosina Rebuilding libnetlink doesn't trigger rebuild of tc, which is wrong (especially so for builds where libnetlink.a gets statically linked into tc). Fix that by introducing an explicit dependency. Signed-off-by: Jiri Kosina --- tc/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tc/Makefile b/tc/Makefile index 6dd984f0..3f7fc939 100644 --- a/tc/Makefile +++ b/tc/Makefile @@ -127,7 +127,7 @@ MODDESTDIR := $(DESTDIR)$(LIBDIR)/tc all: tc $(TCSO) -tc: $(TCOBJ) libtc.a +tc: $(TCOBJ) $(LIBNETLINK) libtc.a $(QUIET_LINK)$(CC) $^ $(LDFLAGS) $(LDLIBS) -o $@ libtc.a: $(TCLIB) -- Jiri Kosina SUSE Labs
[PATCH] bridge: Add support for IEEE 802.11 Proxy ARP for IPv6
This is an IPv6 extension of commit 958501163ddd ("bridge: Add support
for IEEE 802.11 Proxy ARP"). The IEEE 802.11 Proxy ARP feature is
defined in IEEE Std 802.11-2012, 10.23.13. It allows the AP devices to
keep track of the hardware-address-to-IP-address mapping of the mobile
devices within the WLAN network.
The AP will learn this mapping via observing NS/NA frames (this part is
implemented in user space, e.g., in hostapd). When a request for such
information is made (i.e., Neighbor Solicitation), the AP will respond
on behalf of the associated mobile device. In the process of doing so,
the AP will drop the multicast request frame that was intended to go out
to the wireless medium.
To meet the Hotspot 2.0 requirement of using the target devices MAC
address as the sender's MAC address in the NA frame (when AP replies on
behalf of an associated station), the full link layer header needs to be
built with a custom function instead of going through the existing
ndisc.c implementation.
Signed-off-by: Jouni Malinen
---
net/bridge/br_multicast.c | 268 ++
1 file changed, 268 insertions(+)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index b760f26..7a375a7 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#endif
@@ -1815,6 +1816,272 @@ static int br_multicast_ipv4_rcv(struct net_bridge *br,
}
#if IS_ENABLED(CONFIG_IPV6)
+static int br_ndisc_send_na_finish(struct net *net, struct sock *sk,
+ struct sk_buff *skb)
+{
+ return dev_queue_xmit(skb);
+}
+
+void br_ndisc_send_na(struct net_device *dev,
+ const struct in6_addr *daddr,
+ const struct in6_addr *solicited_addr,
+ const u8 *target_lladdr, bool solicited,
+ bool override, const u8 *dest_hw)
+{
+ struct sk_buff *skb;
+ struct nd_msg *msg;
+ int hlen = LL_RESERVED_SPACE(dev);
+ int tlen = dev->needed_tailroom;
+ struct dst_entry *dst;
+ struct net *net = dev_net(dev);
+ struct sock *sk = net->ipv6.ndisc_sk;
+ struct inet6_dev *idev;
+ int err;
+ struct ipv6hdr *hdr;
+ struct icmp6hdr *icmp6h;
+ u8 type;
+ const struct in6_addr *saddr = solicited_addr;
+ int pad, data_len, space;
+ u8 *opt;
+
+ skb = alloc_skb(hlen + sizeof(struct ipv6hdr) + sizeof(*msg) +
+ ndisc_opt_addr_space(dev,
+NDISC_NEIGHBOUR_ADVERTISEMENT) +
+ tlen, GFP_ATOMIC);
+ if (!skb)
+ return;
+
+ skb->protocol = htons(ETH_P_IPV6);
+ skb->dev = dev;
+
+ skb_reserve(skb, hlen + sizeof(struct ipv6hdr));
+ skb_reset_transport_header(skb);
+
+ /* Manually assign socket ownership as we avoid calling
+* sock_alloc_send_pskb() to bypass wmem buffer limits
+*/
+ skb_set_owner_w(skb, sk);
+
+ msg = (struct nd_msg *)skb_put(skb, sizeof(*msg));
+ *msg = (struct nd_msg) {
+ .icmph = {
+ .icmp6_type = NDISC_NEIGHBOUR_ADVERTISEMENT,
+ .icmp6_router = false,
+ .icmp6_solicited = solicited,
+ .icmp6_override = override,
+ },
+ .target = *solicited_addr,
+ };
+
+ /* We are replying on behalf of other entity. Let that entity's
+* address be the target ll addr and src_addr.
+*/
+ pad = ndisc_addr_option_pad(skb->dev->type);
+ data_len = skb->dev->addr_len;
+ space = ndisc_opt_addr_space(skb->dev, NDISC_NEIGHBOUR_ADVERTISEMENT);
+ opt = skb_put(skb, space);
+
+ opt[0] = ND_OPT_TARGET_LL_ADDR;
+ opt[1] = space >> 3;
+
+ memset(opt + 2, 0, pad);
+ opt += pad;
+ space -= pad;
+
+ memcpy(opt + 2, target_lladdr, dev->addr_len);
+ data_len += 2;
+ opt += data_len;
+ space -= data_len;
+ if (space > 0)
+ memset(opt, 0, space);
+
+ dst = skb_dst(skb);
+ icmp6h = icmp6_hdr(skb);
+
+ type = icmp6h->icmp6_type;
+
+ if (!dst) {
+ struct flowi6 fl6;
+
+ icmpv6_flow_init(sk, &fl6, type, saddr, daddr,
+skb->dev->ifindex);
+ dst = icmp6_dst_alloc(skb->dev, &fl6);
+ if (IS_ERR(dst))
+ goto out;
+
+ skb_dst_set(skb, dst);
+ }
+
+ icmp6h->icmp6_cksum = csum_ipv6_magic(saddr, daddr, skb->len,
+ IPPROTO_ICMPV6,
+ csum_partial(icmp6h,
+ skb->len, 0));
+
+ skb_push(skb, sizeof(*hdr));
+ skb_reset_network_header(skb);
+ hdr
Re: [PATCH 1/1] color: use "light" colors for dark background
On Fri, 24 Feb 2017 11:13:12 +0100 Petr Vorel wrote: > COLORFGBG environment variable is used to detect dark background. > > Idea and a bit of code is borrowed from Vim, thanks. > > Signed-off-by: Petr Vorel > --- > Colors are nice, but the ones chosen aren't suitable for dark background. > COLORFGBG environment variable is used in some libraries and software (e.g. > ncurses, Vim). COLORFGBG is set by various terminal emulators (e.g. konsole, > rxvt and rxvt-unicode). > > Chosen colors are questionable. Best solution would be also allow user to > redefine colors, like ls does with LS_COLORS or grep with GREP_COLORS. But > that > is maybe overkill. This really needs to be standardized with some convention. So that ls, grep, git all behave the same and done by some standard library. The current method is hack that keeps on growing.
Re: [PATCH RFC] net/socket: use per af lockdep classes for sk queues
On Fri, Feb 24, 2017 at 5:29 AM, Paolo Abeni wrote: > Currently the sock queue's spin locks get their lockdep > classes by the default init_spin_lock() initializer: > all socket families get - usually, see below - a single > class for rx, another specific class for tx, etc. > This can lead to false positive lockdep splat, as > reported by Andrey. > Moreover there are two separate initialization points > for the sock queues, one in sk_clone_lock() and one > in sock_init_data(), so that e.g. the rx queue lock > can get one of two possible, different classes, depending > on the socket being cloned or not. > This change tries to address the above, setting explicitly > a per address family lockdep class for each queue's > spinlock. Also, move the duplicated initialization code to a > single location. > > Suggested-by: Cong Wang > Signed-off-by: Paolo Abeni Looks good. Thanks for working on it!
[PATCH net v2] vxlan: don't allow overwrite of config src addr
When using IPv6 transport and a default dst, a pointer to the configured
source address is passed into the route lookup. If no source address is
configured, then the value is overwritten.
IPv6 route lookup ignores egress ifindex match if the source address is set,
so if egress ifindex match is desired, the source address must be passed
as any. The overwrite breaks this for subsequent lookups.
Avoid this by copying the configured address to an existing stack variable
and pass a pointer to that instead.
Fixes: 272d96a5ab10 ("net: vxlan: lwt: Use source ip address during route
lookup.")
Signed-off-by: Brian Russell
Acked-by: Jiri Benc
---
drivers/net/vxlan.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 556953f..2e05129 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2035,7 +2035,6 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct
net_device *dev,
const struct iphdr *old_iph = ip_hdr(skb);
union vxlan_addr *dst;
union vxlan_addr remote_ip, local_ip;
- union vxlan_addr *src;
struct vxlan_metadata _md;
struct vxlan_metadata *md = &_md;
__be16 src_port = 0, dst_port;
@@ -2062,7 +2061,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct
net_device *dev,
dst_port = rdst->remote_port ? rdst->remote_port :
vxlan->cfg.dst_port;
vni = (rdst->remote_vni) ? : default_vni;
- src = &vxlan->cfg.saddr;
+ local_ip = vxlan->cfg.saddr;
dst_cache = &rdst->dst_cache;
md->gbp = skb->mark;
ttl = vxlan->cfg.ttl;
@@ -2095,7 +2094,6 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct
net_device *dev,
dst = &remote_ip;
dst_port = info->key.tp_dst ? : vxlan->cfg.dst_port;
vni = tunnel_id_to_key32(info->key.tun_id);
- src = &local_ip;
dst_cache = &info->dst_cache;
if (info->options_len)
md = ip_tunnel_info_opts(info);
@@ -2115,7 +2113,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct
net_device *dev,
rt = vxlan_get_route(vxlan, dev, sock4, skb,
rdst ? rdst->remote_ifindex : 0, tos,
dst->sin.sin_addr.s_addr,
-&src->sin.sin_addr.s_addr,
+&local_ip.sin.sin_addr.s_addr,
dst_port, src_port,
dst_cache, info);
if (IS_ERR(rt)) {
@@ -2142,7 +2140,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct
net_device *dev,
if (err < 0)
goto tx_error;
- udp_tunnel_xmit_skb(rt, sock4->sock->sk, skb,
src->sin.sin_addr.s_addr,
+ udp_tunnel_xmit_skb(rt, sock4->sock->sk, skb,
local_ip.sin.sin_addr.s_addr,
dst->sin.sin_addr.s_addr, tos, ttl, df,
src_port, dst_port, xnet, !udp_sum);
#if IS_ENABLED(CONFIG_IPV6)
@@ -2152,7 +2150,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct
net_device *dev,
ndst = vxlan6_get_route(vxlan, dev, sock6, skb,
rdst ? rdst->remote_ifindex : 0, tos,
label, &dst->sin6.sin6_addr,
- &src->sin6.sin6_addr,
+ &local_ip.sin6.sin6_addr,
dst_port, src_port,
dst_cache, info);
if (IS_ERR(ndst)) {
@@ -2180,7 +2178,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct
net_device *dev,
goto tx_error;
udp_tunnel6_xmit_skb(ndst, sock6->sock->sk, skb, dev,
-&src->sin6.sin6_addr,
+&local_ip.sin6.sin6_addr,
&dst->sin6.sin6_addr, tos, ttl,
label, src_port, dst_port, !udp_sum);
#endif
--
2.1.4
[PATCH net-next] tools: hv: Add clean up function for Ubuntu config
This patch adds a function to clean up duplicate config info
on Ubuntu.
Signed-off-by: Haiyang Zhang
---
tools/hv/bondvf.sh | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/tools/hv/bondvf.sh b/tools/hv/bondvf.sh
index 4aa5369..d85968c 100755
--- a/tools/hv/bondvf.sh
+++ b/tools/hv/bondvf.sh
@@ -101,9 +101,25 @@ function create_bond_cfg_redhat {
echo BONDING_OPTS=\"mode=active-backup miimon=100 primary=$2\" >>$fn
}
+function del_eth_cfg_ubuntu {
+ local fn=$cfgdir/interfaces
+ local tmpfl=$(mktemp)
+
+ local nic_start='^[ \t]*(auto|iface|mapping|allow-.*)[ \t]+'$1
+ local nic_end='^[ \t]*(auto|iface|mapping|allow-.*|source)'
+
+ awk "/$nic_end/{x=0} x{next} /$nic_start/{x=1;next} 1" $fn >$tmpfl
+
+ cp $tmpfl $fn
+
+ rm $tmpfl
+}
+
function create_eth_cfg_ubuntu {
local fn=$cfgdir/interfaces
+ del_eth_cfg_ubuntu $1
+
echo $'\n'auto $1 >>$fn
echo iface $1 inet manual >>$fn
echo bond-master $2 >>$fn
@@ -119,6 +135,8 @@ function create_eth_cfg_pri_ubuntu {
function create_bond_cfg_ubuntu {
local fn=$cfgdir/interfaces
+ del_eth_cfg_ubuntu $1
+
echo $'\n'auto $1 >>$fn
echo iface $1 inet dhcp >>$fn
echo bond-mode active-backup >>$fn
--
1.7.1
Re: [PATCH net 1/1] net sched actions: decrement module reference count after table flush.
On Fri, Feb 24, 2017 at 8:00 AM, Roman Mashak wrote: > When tc actions are loaded as a module and no actions have been installed, > flushing them would result in actions removed from the memory, but modules > reference count not being decremented, so that the modules would not be > unloaded. > > Following is example with GACT action: > > % sudo modprobe act_gact > % lsmod > Module Size Used by > act_gact 16384 0 > % > % sudo tc actions ls action gact > % > % sudo tc actions flush action gact > % lsmod > Module Size Used by > act_gact 16384 1 > % sudo tc actions flush action gact > % lsmod > Module Size Used by > act_gact 16384 2 > % sudo rmmod act_gact > rmmod: ERROR: Module act_gact is in use > > > After the fix: > % lsmod > Module Size Used by > act_gact 16384 0 > % > % sudo tc actions add action pass index 1 > % sudo tc actions add action pass index 2 > % sudo tc actions add action pass index 3 > % lsmod > Module Size Used by > act_gact 16384 3 > % > % sudo tc actions flush action gact > % lsmod > Module Size Used by > act_gact 16384 0 > % > % sudo tc actions flush action gact > % lsmod > Module Size Used by > act_gact 16384 0 > % sudo rmmod act_gact > % lsmod > Module Size Used by > % > > Signed-off-by: Roman Mashak > Signed-off-by: Jamal Hadi Salim Fixes commit f97017cdefefdb6a0e19266024b0c6f9fd411eeb ? Acked-by: Cong Wang
Re: [PATCH RFC] net/socket: use per af lockdep classes for sk queues
On Fri, 2017-02-24 at 14:29 +0100, Paolo Abeni wrote: > Currently the sock queue's spin locks get their lockdep > classes by the default init_spin_lock() initializer: > all socket families get - usually, see below - a single > class for rx, another specific class for tx, etc. > This can lead to false positive lockdep splat, as > reported by Andrey. > Moreover there are two separate initialization points > for the sock queues, one in sk_clone_lock() and one > in sock_init_data(), so that e.g. the rx queue lock > can get one of two possible, different classes, depending > on the socket being cloned or not. > This change tries to address the above, setting explicitly > a per address family lockdep class for each queue's > spinlock. Also, move the duplicated initialization code to a > single location. > > Suggested-by: Cong Wang > Signed-off-by: Paolo Abeni > --- I have not tested the patch, but it looks pretty reasonable to me, thanks !
Re: [PATCH 1/1] rds: fix memory leak error
On 02/24/2017 04:28 AM, Zhu Yanjun wrote: When the function register_netdevice_notifier fails, the memory allocated by kmem_cache_create should be freed by the function kmem_cache_destroy. Cc: Joe Jin Cc: Junxiao Bi Signed-off-by: Zhu Yanjun Acked-by: Sowmini Varadhan
Re: [PATCH net] net: phy: Fix LED mode in DT single property.
On Thu, Feb 23, 2017 at 11:59 PM, Raju Lakkaraju
wrote:
> From: Raju Lakkaraju
>
> Fix the LED mode DT parameters combine to a single property
> and change the vendor prefix i.e. mscc.
>
> Signed-off-by: Raju Lakkaraju
> ---
> .../devicetree/bindings/net/mscc-phy-vsc8531.txt | 20 -
> drivers/net/phy/mscc.c | 50
> +-
> 2 files changed, 38 insertions(+), 32 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> index 0eedabe..2253de5 100644
> --- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> +++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> @@ -6,12 +6,12 @@ Required properties:
> Documentation/devicetree/bindings/net/phy.txt
>
> Optional properties:
> -- vsc8531,vddmac : The vddmac in mV. Allowed values is listed
> +- mscc,vddmac : The vddmac in mV. Allowed values is listed
It would be nice if these were fixed too for consistency, but you
can't just change them unless you know there's no users already and
supporting both doesn't seem worth it here.
> in the first row of Table 1 (below).
> This property is only used in combination
> with the 'edge-slowdown' property.
> Default value is 3300.
> -- vsc8531,edge-slowdown: % the edge should be slowed down relative to
> +- mscc,edge-slowdown : % the edge should be slowed down relative to
> the fastest possible edge time.
> Edge rate sets the drive strength of the MAC
> interface output signals. Changing the
> @@ -27,14 +27,11 @@ Optional properties:
> 'vddmac'.
> Default value is 0%.
> Ref: Table:1 - Edge rate change (below).
> -- vsc8531,led-0-mode : LED mode. Specify how the LED[0] should behave.
> +- mscc,led-mode: LED mode. Specify how the LED[0] and LED[1]
> should behave.
Need to be explicit that the length is 2 cells.
> Allowed values are define in
> "include/dt-bindings/net/mscc-phy-vsc8531.h".
> - Default value is VSC8531_LINK_1000_ACTIVITY (1).
> -- vsc8531,led-1-mode : LED mode. Specify how the LED[1] should behave.
> - Allowed values are define in
> - "include/dt-bindings/net/mscc-phy-vsc8531.h".
> - Default value is VSC8531_LINK_100_ACTIVITY (2).
> + Default LED[0] value is VSC8531_LINK_1000_ACTIVITY
> (1).
> + Default LED[1] value is VSC8531_LINK_100_ACTIVITY
> (2).
>
> Table: 1 - Edge rate change
> |
> @@ -66,8 +63,7 @@ Example:
>
> vsc8531_0: ethernet-phy@0 {
> compatible = "ethernet-phy-id0007.0570";
> -vsc8531,vddmac = <3300>;
> -vsc8531,edge-slowdown = <7>;
> -vsc8531,led-0-mode = ;
> -vsc8531,led-1-mode = ;
> +mscc,vddmac= /bits/ 16 <3300>;
> +mscc,edge-slowdown = /bits/ 8 <7>;
> +mscc,led-mode = ;
> };
> diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
> index 650c266..3e7e9d9 100644
> --- a/drivers/net/phy/mscc.c
> +++ b/drivers/net/phy/mscc.c
> @@ -385,11 +385,11 @@ static int vsc85xx_edge_rate_magic_get(struct
> phy_device *phydev)
> if (!of_node)
> return -ENODEV;
>
> - rc = of_property_read_u16(of_node, "vsc8531,vddmac", &vdd);
> + rc = of_property_read_u16(of_node, "mscc,vddmac", &vdd);
> if (rc != 0)
> vdd = MSCC_VDDMAC_3300;
>
> - rc = of_property_read_u8(of_node, "vsc8531,edge-slowdown", &sd);
> + rc = of_property_read_u8(of_node, "mscc,edge-slowdown", &sd);
> if (rc != 0)
> sd = 0;
>
> @@ -403,25 +403,43 @@ static int vsc85xx_edge_rate_magic_get(struct
> phy_device *phydev)
> }
>
> static int vsc85xx_dt_led_mode_get(struct phy_device *phydev,
> - char *led,
> - u8 default_mode)
> + char *led)
> {
> struct device *dev = &phydev->mdio.dev;
> struct device_node *of_node = dev->of_node;
> - u8 led_mode;
> - int err;
> + struct vsc8531_private *vsc8531 = phydev->priv;
> + u8 led_0_mode = VSC8531_LINK_1000_ACTIVITY;
> + u8 led_1_mode = VSC8531_LINK_100_ACTIVITY;
> + const __be32 *paddr_end;
> + const __be32 *paddr;
> + int len;
>
> if (!of_node)
> return -ENODEV;
>
> - led_mode = de
Re: iproute2: hide devices starting with period by default
On Thu, Feb 23, 2017 at 11:50:28AM -0800, stephen hemminger wrote:
> Some use cases create Linux networking devices which are not intended for use
> by normal networking. This is an enhancement to ip command to hide network
> devices starting with period (like files in normal directory). Interfaces
> whose
> name start with "." are not shown by default, and the -a (or -all) flag must
> be used to show these devices.
>
> Example:
> $ ip -brief link show
> lo UNKNOWN00:00:00:00:00:00
> eth0 UP 00:25:90:86:b3:6b
>
> eth1 DOWN 00:25:90:86:b3:6a
>
> $ ip -all -brief link show
> lo UNKNOWN00:00:00:00:00:00
> eth0 UP 00:25:90:86:b3:6b
>
> eth1 DOWN 00:25:90:86:b3:6a
>
> .eth2DOWN 00:1b:21:a0:e7:06
I've run across a time when there was a perceived need for this with an
out of tree driver that created a netdev that was never used. I was
never a big fan of the attempt to hide it. It seemed like the better
answer would be to try and fix the driver that is creating and
registering this unnecessary netdev so it no longer appears and that was
what we did.
As an admin I'd be pretty frustrated if I somehow had a network issue
that I could not properly debug due to a hidden network interface. If
there was an extra flag that was needed to a tool like iproute2 to show
the hidden device, soon admin's hands would just type 'ip -all link
show' each time to get the full picture.
If the concensus is that we DO want to hide devices I've seen David
Ahern's set and it is much more complete than this. It is probably the
better approach to not leave too many loose ends.
> Signed-off-by: Stephen Hemminger
> ---
> include/utils.h | 1 +
> ip/ip.c | 5 -
> ip/ipaddress.c | 31 ---
> man/man8/ip.8 | 5 +
> 4 files changed, 34 insertions(+), 8 deletions(-)
>
> diff --git a/include/utils.h b/include/utils.h
> index 22369e0b4e03..50712d27f112 100644
> --- a/include/utils.h
> +++ b/include/utils.h
> @@ -16,6 +16,7 @@ extern int human_readable;
> extern int use_iec;
> extern int show_stats;
> extern int show_details;
> +extern int show_all;
> extern int show_raw;
> extern int resolve_hosts;
> extern int oneline;
> diff --git a/ip/ip.c b/ip/ip.c
> index 07050b07592a..ed637b065b58 100644
> --- a/ip/ip.c
> +++ b/ip/ip.c
> @@ -30,6 +30,7 @@ int human_readable;
> int use_iec;
> int show_stats;
> int show_details;
> +int show_all;
> int resolve_hosts;
> int oneline;
> int brief;
> @@ -54,7 +55,7 @@ static void usage(void)
> " netns | l2tp | fou | macsec | tcp_metrics | token |
> netconf | ila |\n"
> " vrf }\n"
> " OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve]
> |\n"
> -"-h[uman-readable] | -iec |\n"
> +"-h[uman-readable] | -iec | -all |\n"
> "-f[amily] { inet | inet6 | ipx | dnet | mpls | bridge |
> link } |\n"
> "-4 | -6 | -I | -D | -B | -0 |\n"
> "-l[oops] { maximum-addr-flush-attempts } | -br[ief] |\n"
> @@ -231,6 +232,8 @@ int main(int argc, char **argv)
> ++show_stats;
> } else if (matches(opt, "-details") == 0) {
> ++show_details;
> + } else if (matches(opt, "-all") == 0) {
> + ++show_all;
> } else if (matches(opt, "-resolve") == 0) {
> ++resolve_hosts;
> } else if (matches(opt, "-oneline") == 0) {
> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
> index 400ebb4de563..029aae100549 100644
> --- a/ip/ipaddress.c
> +++ b/ip/ipaddress.c
> @@ -660,6 +660,7 @@ int print_linkinfo_brief(const struct sockaddr_nl *who,
> struct ifinfomsg *ifi = NLMSG_DATA(n);
> struct rtattr *tb[IFLA_MAX+1];
> int len = n->nlmsg_len;
> + const char *ifname;
> char *name;
> char buf[32] = { 0, };
> unsigned int m_flag = 0;
> @@ -677,14 +678,22 @@ int print_linkinfo_brief(const struct sockaddr_nl *who,
> return -1;
>
> parse_rtattr(tb, IFLA_MAX, IFLA_RTA(ifi), len);
> - if (tb[IFLA_IFNAME] == NULL)
> - fprintf(stderr, "BUG: device with ifindex %d has nil ifname\n",
> ifi->ifi_index);
> + if (tb[IFLA_IFNAME])
> + ifname = rta_getattr_str(tb[IFLA_IFNAME]);
> + else {
> + fprintf(stderr, "BUG: device with ifindex %d has nil ifname\n",
> + ifi->ifi_index);
> + ifname = "";
> + }
>
> if (filter.label &&
> (!filter.family || filter.family == AF_PACKET) &&
> fnmatch(filter.label, RTA_DATA(tb[IFLA_IFNAME]), 0))
> return -1;
>
> + if (!filter.ifindex && *ifname == '.' && !show_all)
> + return 0;
> +
> if (tb[IFLA_GROUP]) {
>
Re: [PATCH 1/1] color: use "light" colors for dark background
On Fri, 24 Feb 2017 11:22:13 -0500 (EST) David Miller wrote: > From: Johannes Berg > Date: Fri, 24 Feb 2017 17:11:42 +0100 > > > > >> > Chosen colors are questionable. Best solution would be also allow > >> user to > >> > redefine colors, like ls does with LS_COLORS or grep with > >> GREP_COLORS. But that > >> > is maybe overkill. > >> > >> I think you may have posted this to the wrong mailing list. > > > > Actually, it seems to just be missing the "iproute" (or so) prefix? > > Ok that makes more sense :) Yes. Iproute2 has had color support for a while. The CC list has the original developer
Re: [PATCH 1/1] rds: fix memory leak error
On 2/24/2017 1:28 AM, Zhu Yanjun wrote: When the function register_netdevice_notifier fails, the memory allocated by kmem_cache_create should be freed by the function kmem_cache_destroy. Cc: Joe Jin Cc: Junxiao Bi Signed-off-by: Zhu Yanjun --- Minor nit with subject. s/rds/RDS: TCP: patch looks fine to me. Acked:by: Santosh Shilimkar
Basic test setup for testing of Kernel GTP-U
Hi all, [intentionally breaking the thread here] On Thu, Feb 23, 2017 at 05:46:57PM +0100, Harald Welte wrote: > I'll try to cook up some instructions extending > https://osmocom.org/projects/openggsn/wiki/OpenGGSN to cover also > sgsnemu for a basic use case of establishing one single tunnel. That's > of course like a manual "HOWTO" and not yet anything that can be tested > automatically. I've documented the instructions at https://osmocom.org/projects/linux-kernel-gtp-u/wiki/Basic_Testing Please let me know any updates/corrections/questions if you try to reproduce this. The above instructions were working for me yesterday. Please find an ASCII export of this below (much less readable than the wiki). Regards, Harald h1. Basic Testing This page documents some basic testing setup for the Kenrel GTP-U code. It follows the below rationale: * focus on testing the kernel GTP-U module without too much external dependencies * test GTP-U interoperability of the kernel with at least one other implementation, not just kernel-to-kernel (which currently is not supported in the kernel, as it only implements the GGSN/P-GW role) * limit testing to SGSN/S-GW and GGSN/P-GW, without a real cellular network (which is possible e.g. using [[OsmoSGSN:]] and [[OsmoPCU:]]) h2. Building / Installing dependencies In order to follow below test instructions, you will need * A Linux kernel including the GTP-U driver (@drivers/net/gtp.c@) either compiled-in or as kernel module * [[libgtpnl]] - the userspace library providing an API around the kernel GTP-U netlink interface * [[OpenGGSN:]] - a minimal C-language implementation of a 3GPP GGSN, also contains a SGSN-side emulator called [[OpenGGSN:sgsnemu]] ** make sure you use Version 0.93 or later ** make sure you compile it with @--enable-gtp-linux@ enable during the @./configure@ step You can find some instructions on how to build [[OpenGGSN:]] with support for [[libgtpnl]] and kernel GTP-U at this wiki page: [[OpenGGSN:Kernel_GTP]] h2. Test setup description We will run the GGSN natively on the host, and put the emulated SGSN inside a separate network namespace. The two namespaces are interconnected by a virtual ethernet device using the transfer network 172.31.1.0/24 The GGSN is configured to provide a pool of IP addresses from the 192.168.71.0/24 range. Each PDP context will be allocated one dynamic address from that pool h2. Test instructions h3. create the network namespace for the SGSN ip netns add sgsn h3. add veth to be used between SGSN and GGSN ip link add veth0 type veth peer name veth1 h3. remote (SGSN) side of veth device ip link set veth1 netns sgsn ip netns exec sgsn ip addr add 172.31.1.2/24 dev veth1 ip netns exec sgsn ip link set veth1 up h3. local (GGSN) side of veth device ip addr add 172.31.1.1/24 dev veth0 ip link set veth0 up h3. execute the GGSN on the host ggsn -g -c ./ggsn.conf.test (use the file attached to this wiki page) The @-g@ option is responsible for activating kernel-GTP support. If you cannot get the example described in this document to work, try the pure GTP-U userspace implementation by removing @-g@ from the above command line. If it works then, there's something related to Kernel GTP-U that breaks the setup. h3. execute the emulated SGSN inside the sgsn namespace ip netns exec sgsn sgsnemu -d -r 172.31.1.1 -l 172.31.1.2 --defaultroute --createif h3. verify the existnace of the GTP tunnel ggsn:~# gtp-tunnel list version 1 tei 1/1 ms_addr 192.168.71.2 sgsn_addr 172.31.1.2 h3. further testing in the @sgsn@ namespace, there's now a default-route that points into the GTP tunnel. You can use this to ping any network address that's reachable to the GGSN host. If that host is connected to the internet, you can e.g. run a ping command from within the namespace using ip netns exec sgsn ping -c 10 8.8.8.8 which will send some IP packets to 8.8.8.8 via the tun0 device (created by [[OpenGGSN:sgsnemu]]). It will be encapsulated by the userspace GTP-U implementation of sgsnemu, sent via the veth device to the host, where it ends up inthe GTP-U kernel module, decapsulating the package and passing in on to the gtp0 device there. Anything beyond that point depends on your local routing configuration. == Building OpenGGSN == h1. OpenGGSN and Linux Kernel accelerated GTP-U OpenGGSN has support to use the Linux kernel GTP-U code to accelerate the data/user plane while still implementing the control plane (GTP-C) in userspace in OpenGGSN. For more information about the Linux kernel GTP-U code, please see [[linux-kernel-gtp-u:]] h2. Building OpenGGSN with kernel which has GTP-U support At the time of writing (2017-01-09) of this wiki, below listed distributions have support of GTP kernels : * Debian 4.9.1-1~exp1 - Debian's latest experimental build * Ubuntu 16.10 kernel 4.8 * OpenSUSE Tumbleweed (stable) 4.8 (.12) * Fedora 25 kernel 4.8 Following two Debian kernels
Re: [PATCH] vti6: return GRE_KEY for vti6
From: David Forster Date: Fri, 24 Feb 2017 14:20:32 + > Align vti6 with vti by returning GRE_KEY flag. This enables iproute2 > to display tunnel keys on "ip -6 tunnel show" > > Signed-off-by: David Forster Applied, thanks.
Re: [PATCH 1/1] color: use "light" colors for dark background
From: Johannes Berg Date: Fri, 24 Feb 2017 17:11:42 +0100 > >> > Chosen colors are questionable. Best solution would be also allow >> user to >> > redefine colors, like ls does with LS_COLORS or grep with >> GREP_COLORS. But that >> > is maybe overkill. >> >> I think you may have posted this to the wrong mailing list. > > Actually, it seems to just be missing the "iproute" (or so) prefix? Ok that makes more sense :)
Re: [PATCH net v2] vxlan: correctly validate VXLAN ID against VXLAN_N_VID
From: Matthias Schiffer
Date: Thu, 23 Feb 2017 17:19:41 +0100
> The incorrect check caused an off-by-one error: the maximum VID 0xff
> was unusable.
>
> Fixes: d342894c5d2f ("vxlan: virtual extensible lan")
> Signed-off-by: Matthias Schiffer
Applied and queued up for -stable, thanks.
Re: [PATCH net] rxrpc: Fix an assertion in rxrpc_read()
From: David Howells Date: Fri, 24 Feb 2017 12:33:09 + > From: Marc Dionne > > In the rxrpc_read() function, which allows a user to read the contents of a > key, we miscalculate the expected length of an encoded rxkad token by not > taking into account the key length. However, the data is stored later > anyway with an ENCODE_DATA() call - and an assertion failure then ensues > when the lengths are checked at the end. > > Fix this by including the key length in the token size estimation. > > The following assertion is produced: ... > Signed-off-by: Marc Dionne > Signed-off-by: David Howells Applied.
Re: [PATCH net] net/mlx4_en: fix overflow in mlx4_en_init_timestamp()
From: Eric Dumazet
Date: Thu, 23 Feb 2017 15:22:43 -0800
> From: Eric Dumazet
>
> The cited commit makes a great job of finding optimal shift/multiplier
> values assuming a 10 seconds wrap around, but forgot to change the
> overflow_period computation.
>
> It overflows in cyclecounter_cyc2ns(), and the final result is 804 ms,
> which is silly.
>
> Lets simply use 5 seconds, no need to recompute this, given how it is
> supposed to work.
>
> Later, we will use a timer instead of a work queue, since the new RX
> allocation schem will no longer need mlx4_en_recover_from_oom() and the
> service_task firing every 250 ms.
>
> Fixes: 31c128b66e5b ("net/mlx4_en: Choose time-stamping shift value according
> to HW frequency")
> Signed-off-by: Eric Dumazet
Tariq please review.
Re: [PATCH net] net: phy: Add missing driver check in phy_aneg_done()
From: Florian Fainelli
Date: Thu, 23 Feb 2017 14:22:19 -0800
> Dan's static checker caught a potential code path in phy_state_machine() where
> we were not checking phydev->drv which is in phy_aneg_done().
>
> Reported-by: Dan Carpenter
> Fixes: 25149ef9d25c ("net: phy: Check phydev->drv")
> Signed-off-by: Florian Fainelli
Applied.
Re: [PATCH] net: stmmac: unify registers dumps methods
From: Corentin Labbe Date: Thu, 23 Feb 2017 14:12:25 +0100 > The stmmac driver have two methods for registers dumps: via ethtool and > at init (if NETIF_MSG_HW is enabled). > > It is better to keep only one method, ethtool, since the other was ugly. > > This patch convert all dump_regs() function from "printing regs" to > "fill the reg_space used by ethtool". > > Signed-off-by: Corentin Labbe > Acked-by: Giuseppe Cavallaro Applied.
Re: [PATCH net 1/1] tipc: move premature initilalization of stack variables
From: Jon Maloy Date: Thu, 23 Feb 2017 11:10:31 -0500 > In the function tipc_rcv() we initialize a couple of stack variables > from the message header before that same header has been validated. > In rare cases when the arriving header is non-linar, the validation > function itself may linearize the buffer by calling skb_may_pull(), > while the wrongly initialized stack fields are not updated accordingly. > > We fix this in this commit. > > Reported-by: Matthew Wong > Signed-off-by: Jon Maloy Applied.
Re: [PATCH] RDS: IB: fix ifnullfree.cocci warnings
From: kbuild test robot Date: Thu, 23 Feb 2017 20:47:01 +0800 > net/rds/ib.c:115:2-7: WARNING: NULL check before freeing functions like > kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not > needed. Maybe consider reorganizing relevant code to avoid passing NULL > values. > > NULL check before some freeing functions is not needed. > > Based on checkpatch warning > "kfree(NULL) is safe this check is probably not required" > and kfreeaddr.cocci by Julia Lawall. > > Generated by: scripts/coccinelle/free/ifnullfree.cocci > > Signed-off-by: Fengguang Wu Applied.
Re: [PATCH 1/1] color: use "light" colors for dark background
> > Chosen colors are questionable. Best solution would be also allow > user to > > redefine colors, like ls does with LS_COLORS or grep with > GREP_COLORS. But that > > is maybe overkill. > > I think you may have posted this to the wrong mailing list. Actually, it seems to just be missing the "iproute" (or so) prefix? johannes
Re: [PATCH net] sctp: deny peeloff operation on asocs with threads sleeping on it
From: Marcelo Ricardo Leitner
Date: Thu, 23 Feb 2017 09:31:18 -0300
> commit 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
> attempted to avoid a BUG_ON call when the association being used for a
> sendmsg() is blocked waiting for more sndbuf and another thread did a
> peeloff operation on such asoc, moving it to another socket.
>
> As Ben Hutchings noticed, then in such case it would return without
> locking back the socket and would cause two unlocks in a row.
>
> Further analysis also revealed that it could allow a double free if the
> application managed to peeloff the asoc that is created during the
> sendmsg call, because then sctp_sendmsg() would try to free the asoc
> that was created only for that call.
>
> This patch takes another approach. It will deny the peeloff operation
> if there is a thread sleeping on the asoc, so this situation doesn't
> exist anymore. This avoids the issues described above and also honors
> the syscalls that are already being handled (it can be multiple sendmsg
> calls).
>
> Joint work with Xin Long.
>
> Fixes: 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
> Cc: Alexander Popov
> Cc: Ben Hutchings
> Signed-off-by: Marcelo Ricardo Leitner
> Signed-off-by: Xin Long
> ---
> Hi, please consider this one for -stable too. Thanks
Applied and queued up for -stable, thanks.
[PATCH net 1/1] net sched actions: decrement module reference count after table flush.
When tc actions are loaded as a module and no actions have been installed, flushing them would result in actions removed from the memory, but modules reference count not being decremented, so that the modules would not be unloaded. Following is example with GACT action: % sudo modprobe act_gact % lsmod Module Size Used by act_gact 16384 0 % % sudo tc actions ls action gact % % sudo tc actions flush action gact % lsmod Module Size Used by act_gact 16384 1 % sudo tc actions flush action gact % lsmod Module Size Used by act_gact 16384 2 % sudo rmmod act_gact rmmod: ERROR: Module act_gact is in use After the fix: % lsmod Module Size Used by act_gact 16384 0 % % sudo tc actions add action pass index 1 % sudo tc actions add action pass index 2 % sudo tc actions add action pass index 3 % lsmod Module Size Used by act_gact 16384 3 % % sudo tc actions flush action gact % lsmod Module Size Used by act_gact 16384 0 % % sudo tc actions flush action gact % lsmod Module Size Used by act_gact 16384 0 % sudo rmmod act_gact % lsmod Module Size Used by % Signed-off-by: Roman Mashak Signed-off-by: Jamal Hadi Salim --- net/sched/act_api.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/net/sched/act_api.c b/net/sched/act_api.c index f219ff3..dfe64f8 100644 --- a/net/sched/act_api.c +++ b/net/sched/act_api.c @@ -859,10 +859,8 @@ static int tca_action_flush(struct net *net, struct nlattr *nla, goto out_module_put; err = ops->walk(net, skb, &dcb, RTM_DELACTION, ops); - if (err < 0) + if (err <= 0) goto out_module_put; - if (err == 0) - goto noflush_out; nla_nest_end(skb, nest); @@ -879,7 +877,6 @@ static int tca_action_flush(struct net *net, struct nlattr *nla, out_module_put: module_put(ops->owner); err_out: -noflush_out: kfree_skb(skb); return err; } -- 1.9.1
Re: [PATCH] iproute2: hide devices starting with period by default
On 2/23/17 8:12 PM, David Miller wrote: > This really need to be a fundamental facility, so that it transparently > works for NetworkManager, router daemons, everything. Not just iproute2 > and "ls". I'll rebase my patch and send out as RFC.
Re: [PATCH] iproute2: hide devices starting with period by default
On Thu, Feb 23, 2017 at 05:31:14PM -0800, Stephen Hemminger wrote: > On Thu, 23 Feb 2017 18:07:07 -0700 > David Ahern wrote: > > > On 2/23/17 5:30 PM, Stephen Hemminger wrote: > > > On Thu, 23 Feb 2017 16:39:52 -0700 > > > David Ahern wrote: > > > > > >> On 2/23/17 12:50 PM, Stephen Hemminger wrote: > > >>> Some use cases create Linux networking devices which are not intended > > >>> for use > > >>> by normal networking. This is an enhancement to ip command to hide > > >>> network > > >>> devices starting with period (like files in normal directory). > > >>> Interfaces whose > > >>> name start with "." are not shown by default, and the -a (or -all) flag > > >>> must > > >>> be used to show these devices. > > >> > > >> Agree that some devices need to be hidden by default -- not just from > > >> users but also other processes. > > >> > > >> This solution is very narrow, only affecting iproute2 users. Any other > > >> programs that use netlink or /proc files will continue to see those > > >> devices. > > > > > > I want solution that works broadly. And this works for sysfs already. > > > > for 'ls' maybe, but not general walking of /sys. It does not hide > > devices from snmpd, from ifconfig, etc., etc. > > > > > > >> I started a patch a year ago that allows devices to marked as invisible > > >> (attribute can be toggled at any time). Invisible devices do not show up > > >> in netlink dumps, proc files or notifications. Netlink dumps can request > > >> invisible devices to be included in a link dump. While it is more > > >> intrusive, it is also more complete covering all of the paths in which > > >> the device is shows up. > > >> > > >> Also, changing the default behavior for iproute2 could break existing > > >> users that have such device names. > > > > > > I am less worried about this. The only people using . in name already > > > are probably Brocade, and they have similar thing in CLI to hide these > > > devices. > > > > > > seems like a big assumption. > > Need a solution now, not something that requires kernel and command changes. Why the haste? This doesn't seem like an urgent thing to fix and given the mixed feelings this provoked giving it a second thought might not be the worst idea, no? Cheers, Phil
Re: [PATCH 1/1] color: use "light" colors for dark background
From: Petr Vorel Date: Fri, 24 Feb 2017 11:13:12 +0100 > COLORFGBG environment variable is used to detect dark background. > > Idea and a bit of code is borrowed from Vim, thanks. > > Signed-off-by: Petr Vorel > --- > Colors are nice, but the ones chosen aren't suitable for dark background. > COLORFGBG environment variable is used in some libraries and software (e.g. > ncurses, Vim). COLORFGBG is set by various terminal emulators (e.g. konsole, > rxvt and rxvt-unicode). > > Chosen colors are questionable. Best solution would be also allow user to > redefine colors, like ls does with LS_COLORS or grep with GREP_COLORS. But > that > is maybe overkill. I think you may have posted this to the wrong mailing list.
[PATCH] vti6: return GRE_KEY for vti6
Align vti6 with vti by returning GRE_KEY flag. This enables iproute2 to display tunnel keys on "ip -6 tunnel show" Signed-off-by: David Forster --- net/ipv6/ip6_vti.c | 4 1 file changed, 4 insertions(+) diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c index c795fee..644ba59 100644 --- a/net/ipv6/ip6_vti.c +++ b/net/ipv6/ip6_vti.c @@ -693,6 +693,10 @@ vti6_parm_to_user(struct ip6_tnl_parm2 *u, const struct __ip6_tnl_parm *p) u->link = p->link; u->i_key = p->i_key; u->o_key = p->o_key; + if (u->i_key) + u->i_flags |= GRE_KEY; + if (u->o_key) + u->o_flags |= GRE_KEY; u->proto = p->proto; memcpy(u->name, p->name, sizeof(u->name)); -- 2.1.4
[PATCH] IB/rxe: increment msn only when completing a request
According to C9-147, MSN should only be incremented when the last packet of
a multi packet request has been received.
"Logically, the requester associates a sequential Send Sequence Number
(SSN) with each WQE posted to the send queue. The SSN bears a one-
to-one relationship to the MSN returned by the responder in each re-
sponse packet. Therefore, when the requester receives a response, it in-
terprets the MSN as representing the SSN of the most recent request
completed by the responder to determine which send WQE(s) can be
completed."
Fixes: 8700e3e7c485 ("Soft RoCE driver")
Signed-off-by: David Marchand
---
drivers/infiniband/sw/rxe/rxe_resp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/sw/rxe/rxe_resp.c
b/drivers/infiniband/sw/rxe/rxe_resp.c
index 5bcf073..193d95c 100644
--- a/drivers/infiniband/sw/rxe/rxe_resp.c
+++ b/drivers/infiniband/sw/rxe/rxe_resp.c
@@ -812,18 +812,18 @@ static enum resp_states execute(struct rxe_qp *qp, struct
rxe_pkt_info *pkt)
/* Unreachable */
WARN_ON(1);
- /* We successfully processed this new request. */
- qp->resp.msn++;
-
/* next expected psn, read handles this separately */
qp->resp.psn = (pkt->psn + 1) & BTH_PSN_MASK;
qp->resp.opcode = pkt->opcode;
qp->resp.status = IB_WC_SUCCESS;
- if (pkt->mask & RXE_COMP_MASK)
+ if (pkt->mask & RXE_COMP_MASK) {
+ /* We successfully processed this new request. See C9-147. */
+ qp->resp.msn++;
+
return RESPST_COMPLETE;
- else if (qp_type(qp) == IB_QPT_RC)
+ } else if (qp_type(qp) == IB_QPT_RC)
return RESPST_ACKNOWLEDGE;
else
return RESPST_CLEANUP;
--
2.7.4
Re: [PATCH v5 6/6] 6lowpan: Fix IID format for Bluetooth
Hello.
On 02/24/2017 01:14 PM, Luiz Augusto von Dentz wrote:
From: Luiz Augusto von Dentz
Accourding to RFC 7668 U/L bit shall not be used:
https://wiki.tools.ietf.org/html/rfc7668#section-3.2.2 [Page 10]:
In the figure, letter 'b' represents a bit from the
Bluetooth device address, copied as is without any changes on any
bit. This means that no bit in the IID indicates whether the
underlying Bluetooth device address is public or random.
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+++++
|||1110||
+++++
Because of this the code cannot figure out the address type from the IP
address anymore thus it makes no sense to use peer_lookup_ba as it needs
the peer address type.
Signed-off-by: Luiz Augusto von Dentz
---
include/net/6lowpan.h | 4 ---
net/bluetooth/6lowpan.c | 79 -
2 files changed, 12 insertions(+), 71 deletions(-)
diff --git a/include/net/6lowpan.h b/include/net/6lowpan.h
index c5792cb..a713780 100644
--- a/include/net/6lowpan.h
+++ b/include/net/6lowpan.h
@@ -211,10 +211,6 @@ static inline void
lowpan_iphc_uncompress_eui48_lladdr(struct in6_addr *ipaddr,
ipaddr->s6_addr[11] = 0xFF;
ipaddr->s6_addr[12] = 0xFE;
memcpy(&ipaddr->s6_addr[13], lladdr + 3, 3);
- /* second bit-flip (Universe/Local)
-* is done according RFC2464
-*/
- ipaddr->s6_addr[8] ^= 0x02;
}
#ifdef DEBUG
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 0b68cfc..ec89c55 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -398,37 +398,6 @@ static int chan_recv_cb(struct l2cap_chan *chan, struct
sk_buff *skb)
return err;
}
-static u8 get_addr_type_from_eui64(u8 byte)
-{
- /* Is universal(0) or local(1) bit */
- return ((byte & 0x02) ? BDADDR_LE_RANDOM : BDADDR_LE_PUBLIC);
-}
-
-static void copy_to_bdaddr(struct in6_addr *ip6_daddr, bdaddr_t *addr)
-{
- u8 *eui64 = ip6_daddr->s6_addr + 8;
-
- addr->b[0] = eui64[7];
- addr->b[1] = eui64[6];
- addr->b[2] = eui64[5];
- addr->b[3] = eui64[2];
- addr->b[4] = eui64[1];
- addr->b[5] = eui64[0];
-}
-
-static void convert_dest_bdaddr(struct in6_addr *ip6_daddr,
- bdaddr_t *addr, u8 *addr_type)
-{
- copy_to_bdaddr(ip6_daddr, addr);
-
- /* We need to toggle the U/L bit that we got from IPv6 address
-* so that we get the proper address and type of the BD address.
-*/
- addr->b[5] ^= 0x02;
-
- *addr_type = get_addr_type_from_eui64(addr->b[5]);
-}
-
static int setup_header(struct sk_buff *skb, struct net_device *netdev,
bdaddr_t *peer_addr, u8 *peer_addr_type)
{
@@ -436,8 +405,7 @@ static int setup_header(struct sk_buff *skb, struct
net_device *netdev,
struct ipv6hdr *hdr;
struct lowpan_btle_dev *dev;
struct lowpan_peer *peer;
- bdaddr_t addr, *any = BDADDR_ANY;
- u8 *daddr = any->b;
+ u8 *daddr;
int err, status = 0;
hdr = ipv6_hdr(skb);
@@ -448,34 +416,24 @@ static int setup_header(struct sk_buff *skb, struct
net_device *netdev,
if (ipv6_addr_is_multicast(&ipv6_daddr)) {
lowpan_cb(skb)->chan = NULL;
+ daddr = NULL;
} else {
- u8 addr_type;
+ BT_DBG("dest IP %pI6c", &ipv6_daddr);
- /* Get destination BT device from skb.
-* If there is no such peer then discard the packet.
+ /* The packet might be sent to 6lowpan interface
+* because of routing (either via default route
+* or user set route) so get peer according to
+* the destination address.
*/
- convert_dest_bdaddr(&ipv6_daddr, &addr, &addr_type);
-
- BT_DBG("dest addr %pMR type %d IP %pI6c", &addr,
- addr_type, &ipv6_daddr);
-
- peer = peer_lookup_ba(dev, &addr, addr_type);
+ peer = peer_lookup_dst(dev, &ipv6_daddr, skb);
if (!peer) {
- /* The packet might be sent to 6lowpan interface
-* because of routing (either via default route
-* or user set route) so get peer according to
-* the destination address.
-*/
- peer = peer_lookup_dst(dev, &ipv6_daddr, skb);
- if (!peer) {
- BT_DBG("no such peer %pMR found", &addr);
- return -ENOENT;
- }
+
[PATCH RFC] net/socket: use per af lockdep classes for sk queues
Currently the sock queue's spin locks get their lockdep
classes by the default init_spin_lock() initializer:
all socket families get - usually, see below - a single
class for rx, another specific class for tx, etc.
This can lead to false positive lockdep splat, as
reported by Andrey.
Moreover there are two separate initialization points
for the sock queues, one in sk_clone_lock() and one
in sock_init_data(), so that e.g. the rx queue lock
can get one of two possible, different classes, depending
on the socket being cloned or not.
This change tries to address the above, setting explicitly
a per address family lockdep class for each queue's
spinlock. Also, move the duplicated initialization code to a
single location.
Suggested-by: Cong Wang
Signed-off-by: Paolo Abeni
---
Targeting the net-next tree since this a bit invasive
net/core/sock.c | 96 ++---
1 file changed, 78 insertions(+), 18 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index e7d7494..0c76524 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -258,12 +258,66 @@ static const char *const
af_family_clock_key_strings[AF_MAX+1] = {
"clock-AF_NFC" , "clock-AF_VSOCK", "clock-AF_KCM" ,
"clock-AF_QIPCRTR", "clock-AF_SMC" , "clock-AF_MAX"
};
+static const char *const af_family_rlock_key_strings[AF_MAX+1] = {
+ "rlock-AF_UNSPEC", "rlock-AF_UNIX" , "rlock-AF_INET" ,
+ "rlock-AF_AX25" , "rlock-AF_IPX" , "rlock-AF_APPLETALK",
+ "rlock-AF_NETROM", "rlock-AF_BRIDGE" , "rlock-AF_ATMPVC" ,
+ "rlock-AF_X25" , "rlock-AF_INET6", "rlock-AF_ROSE" ,
+ "rlock-AF_DECnet", "rlock-AF_NETBEUI" , "rlock-AF_SECURITY" ,
+ "rlock-AF_KEY" , "rlock-AF_NETLINK" , "rlock-AF_PACKET" ,
+ "rlock-AF_ASH" , "rlock-AF_ECONET" , "rlock-AF_ATMSVC" ,
+ "rlock-AF_RDS" , "rlock-AF_SNA" , "rlock-AF_IRDA" ,
+ "rlock-AF_PPPOX" , "rlock-AF_WANPIPE" , "rlock-AF_LLC" ,
+ "rlock-27" , "rlock-28" , "rlock-AF_CAN" ,
+ "rlock-AF_TIPC" , "rlock-AF_BLUETOOTH", "rlock-AF_IUCV" ,
+ "rlock-AF_RXRPC" , "rlock-AF_ISDN" , "rlock-AF_PHONET" ,
+ "rlock-AF_IEEE802154", "rlock-AF_CAIF" , "rlock-AF_ALG" ,
+ "rlock-AF_NFC" , "rlock-AF_VSOCK", "rlock-AF_KCM" ,
+ "rlock-AF_QIPCRTR", "rlock-AF_SMC" , "rlock-AF_MAX"
+};
+static const char *const af_family_wlock_key_strings[AF_MAX+1] = {
+ "wlock-AF_UNSPEC", "wlock-AF_UNIX" , "wlock-AF_INET" ,
+ "wlock-AF_AX25" , "wlock-AF_IPX" , "wlock-AF_APPLETALK",
+ "wlock-AF_NETROM", "wlock-AF_BRIDGE" , "wlock-AF_ATMPVC" ,
+ "wlock-AF_X25" , "wlock-AF_INET6", "wlock-AF_ROSE" ,
+ "wlock-AF_DECnet", "wlock-AF_NETBEUI" , "wlock-AF_SECURITY" ,
+ "wlock-AF_KEY" , "wlock-AF_NETLINK" , "wlock-AF_PACKET" ,
+ "wlock-AF_ASH" , "wlock-AF_ECONET" , "wlock-AF_ATMSVC" ,
+ "wlock-AF_RDS" , "wlock-AF_SNA" , "wlock-AF_IRDA" ,
+ "wlock-AF_PPPOX" , "wlock-AF_WANPIPE" , "wlock-AF_LLC" ,
+ "wlock-27" , "wlock-28" , "wlock-AF_CAN" ,
+ "wlock-AF_TIPC" , "wlock-AF_BLUETOOTH", "wlock-AF_IUCV" ,
+ "wlock-AF_RXRPC" , "wlock-AF_ISDN" , "wlock-AF_PHONET" ,
+ "wlock-AF_IEEE802154", "wlock-AF_CAIF" , "wlock-AF_ALG" ,
+ "wlock-AF_NFC" , "wlock-AF_VSOCK", "wlock-AF_KCM" ,
+ "wlock-AF_QIPCRTR", "wlock-AF_SMC" , "wlock-AF_MAX"
+};
+static const char *const af_family_elock_key_strings[AF_MAX+1] = {
+ "elock-AF_UNSPEC", "elock-AF_UNIX" , "elock-AF_INET" ,
+ "elock-AF_AX25" , "elock-AF_IPX" , "elock-AF_APPLETALK",
+ "elock-AF_NETROM", "elock-AF_BRIDGE" , "elock-AF_ATMPVC" ,
+ "elock-AF_X25" , "elock-AF_INET6", "elock-AF_ROSE" ,
+ "elock-AF_DECnet", "elock-AF_NETBEUI" , "elock-AF_SECURITY" ,
+ "elock-AF_KEY" , "elock-AF_NETLINK" , "elock-AF_PACKET" ,
+ "elock-AF_ASH" , "elock-AF_ECONET" , "elock-AF_ATMSVC" ,
+ "elock-AF_RDS" , "elock-AF_SNA" , "elock-AF_IRDA" ,
+ "elock-AF_PPPOX" , "elock-AF_WANPIPE" , "elock-AF_LLC" ,
+ "elock-27" , "elock-28" , "elock-AF_CAN" ,
+ "elock-AF_TIPC" , "elock-AF_BLUETOOTH", "elock-AF_IUCV" ,
+ "elock-AF_RXRPC" , "elock-AF_ISDN" , "elock-AF_PHONET" ,
+ "elock-AF_IEEE802154", "elock-AF_CAIF" , "elock-AF_ALG" ,
+ "elock-AF_NFC" , "elock-AF_VSOCK", "elock-AF_KCM" ,
+ "elock-AF_QIPCRTR", "elock-AF_SMC" , "elock-AF_MAX"
+};
/*
- * sk_callback_lock locking rules are per-address-family,
+ * sk_callback_lock and sk queues locking rules are per-address-family,
* so split the lock classes by using a per-AF key:
*/
static struct lock_class_key af_callback_keys[AF_MAX];
+static struct lock_class_key af_rlock_keys[AF_MAX];
+static struct lock_class_key af_wlock_keys[AF_MAX];
+static struct lock_class_key af_elock_keys[AF_MAX];
/* Take into consideration the size of the struct sk_buff overhead in the
* determination of these values, s
[PATCH net] rxrpc: Fix an assertion in rxrpc_read()
From: Marc Dionne
In the rxrpc_read() function, which allows a user to read the contents of a
key, we miscalculate the expected length of an encoded rxkad token by not
taking into account the key length. However, the data is stored later
anyway with an ENCODE_DATA() call - and an assertion failure then ensues
when the lengths are checked at the end.
Fix this by including the key length in the token size estimation.
The following assertion is produced:
Assertion failed - 384(0x180) == 380(0x17c) is false
[ cut here ]
kernel BUG at ../net/rxrpc/key.c:1221!
invalid opcode: [#1] SMP
Modules linked in:
CPU: 2 PID: 2957 Comm: keyctl Not tainted 4.10.0-fscache+ #483
Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
task: 8804013a8500 task.stack: 8804013ac000
RIP: 0010:rxrpc_read+0x10de/0x11b6
RSP: 0018:8804013afe48 EFLAGS: 00010296
RAX: 003b RBX: 0003 RCX:
RDX: 00040001 RSI: 00f6 RDI: 0300
RBP: 8804013afed8 R08: 0001 R09: 0001
R10: 8804013afd90 R11: 0002 R12: 5575f7c911b4
R13: 5575f7c911b3 R14: 0157 R15: 880408a5d640
FS: 7f8dfbc73700() GS:88041fb0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 5575f7c91008 CR3: 00040120a000 CR4: 001406e0
Call Trace:
keyctl_read_key+0xb6/0xd7
SyS_keyctl+0x83/0xe7
do_syscall_64+0x80/0x191
entry_SYSCALL64_slow_path+0x25/0x25
Signed-off-by: Marc Dionne
Signed-off-by: David Howells
---
net/rxrpc/key.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/rxrpc/key.c b/net/rxrpc/key.c
index 18c737a61d80..0a4e28477ad9 100644
--- a/net/rxrpc/key.c
+++ b/net/rxrpc/key.c
@@ -1065,7 +1065,7 @@ static long rxrpc_read(const struct key *key,
switch (token->security_index) {
case RXRPC_SECURITY_RXKAD:
- toksize += 8 * 4; /* viceid, kvno, key*2, begin,
+ toksize += 9 * 4; /* viceid, kvno, key*2 + len,
begin,
* end, primary, tktlen */
toksize += RND(token->kad->ticket_len);
break;
Re: [PATCH 3/3] mwifiex: wake system up when receives a wake irq
Hi Kalle, On 02/24/2017 07:01 PM, Kalle Valo wrote: Jeffy Chen writes: Currrently we are disabling this wake irq after receiving it. If this happens before we finish suspend and the pm event check is disabled, the system will continue suspending, and this irq would not work again. We may need to abort system suspend to avoid that. Signed-off-by: Jeffy Chen I only see patch 3 in patchwork. Where are patches 1 and 2? the other two are much like this one, but for bluetooth :) please check: https://patchwork.kernel.org/patch/9589455 New [1/3] btusb: wake system up when receives a wake irq https://patchwork.kernel.org/patch/9589453 New [2/3] btmrvl: wake system up when receives a wake irq https://patchwork.kernel.org/patch/9589457 New [3/3] mwifiex: wake system up when receives a wake irq (sorry, this is a resent mail, because the last one was rejected due to wrong format)
[PATCH v5 5/6] 6lowpan: Use netdev addr_len to determine lladdr len
From: Luiz Augusto von Dentz
This allow technologies such as Bluetooth to use its native lladdr which
is eui48 instead of eui64 which was expected by functions like
lowpan_header_decompress and lowpan_header_compress.
Signed-off-by: Luiz Augusto von Dentz
Reviewed-by: Stefan Schmidt
---
include/net/6lowpan.h | 19 +++
net/6lowpan/iphc.c | 49 ++---
net/bluetooth/6lowpan.c | 42 ++
3 files changed, 63 insertions(+), 47 deletions(-)
diff --git a/include/net/6lowpan.h b/include/net/6lowpan.h
index 5ab4c99..c5792cb 100644
--- a/include/net/6lowpan.h
+++ b/include/net/6lowpan.h
@@ -198,6 +198,25 @@ static inline void
lowpan_iphc_uncompress_eui64_lladdr(struct in6_addr *ipaddr,
ipaddr->s6_addr[8] ^= 0x02;
}
+static inline void lowpan_iphc_uncompress_eui48_lladdr(struct in6_addr *ipaddr,
+ const void *lladdr)
+{
+ /* fe:80:::XXff:feXX:
+*\_/
+* hwaddr
+*/
+ ipaddr->s6_addr[0] = 0xFE;
+ ipaddr->s6_addr[1] = 0x80;
+ memcpy(&ipaddr->s6_addr[8], lladdr, 3);
+ ipaddr->s6_addr[11] = 0xFF;
+ ipaddr->s6_addr[12] = 0xFE;
+ memcpy(&ipaddr->s6_addr[13], lladdr + 3, 3);
+ /* second bit-flip (Universe/Local)
+* is done according RFC2464
+*/
+ ipaddr->s6_addr[8] ^= 0x02;
+}
+
#ifdef DEBUG
/* print data in line */
static inline void raw_dump_inline(const char *caller, char *msg,
diff --git a/net/6lowpan/iphc.c b/net/6lowpan/iphc.c
index fb5f6fa..6b1042e 100644
--- a/net/6lowpan/iphc.c
+++ b/net/6lowpan/iphc.c
@@ -278,6 +278,23 @@ lowpan_iphc_ctx_get_by_mcast_addr(const struct net_device
*dev,
return ret;
}
+static void lowpan_iphc_uncompress_lladdr(const struct net_device *dev,
+ struct in6_addr *ipaddr,
+ const void *lladdr)
+{
+ switch (dev->addr_len) {
+ case ETH_ALEN:
+ lowpan_iphc_uncompress_eui48_lladdr(ipaddr, lladdr);
+ break;
+ case EUI64_ADDR_LEN:
+ lowpan_iphc_uncompress_eui64_lladdr(ipaddr, lladdr);
+ break;
+ default:
+ WARN_ON_ONCE(1);
+ break;
+ }
+}
+
/* Uncompress address function for source and
* destination address(non-multicast).
*
@@ -320,7 +337,7 @@ static int lowpan_iphc_uncompress_addr(struct sk_buff *skb,
lowpan_iphc_uncompress_802154_lladdr(ipaddr, lladdr);
break;
default:
- lowpan_iphc_uncompress_eui64_lladdr(ipaddr, lladdr);
+ lowpan_iphc_uncompress_lladdr(dev, ipaddr, lladdr);
break;
}
break;
@@ -381,7 +398,7 @@ static int lowpan_iphc_uncompress_ctx_addr(struct sk_buff
*skb,
lowpan_iphc_uncompress_802154_lladdr(ipaddr, lladdr);
break;
default:
- lowpan_iphc_uncompress_eui64_lladdr(ipaddr, lladdr);
+ lowpan_iphc_uncompress_lladdr(dev, ipaddr, lladdr);
break;
}
ipv6_addr_prefix_copy(ipaddr, &ctx->pfx, ctx->plen);
@@ -810,6 +827,21 @@ lowpan_iphc_compress_ctx_802154_lladdr(const struct
in6_addr *ipaddr,
return lladdr_compress;
}
+static bool lowpan_iphc_addr_equal(const struct net_device *dev,
+ const struct lowpan_iphc_ctx *ctx,
+ const struct in6_addr *ipaddr,
+ const void *lladdr)
+{
+ struct in6_addr tmp = {};
+
+ lowpan_iphc_uncompress_lladdr(dev, &tmp, lladdr);
+
+ if (ctx)
+ ipv6_addr_prefix_copy(&tmp, &ctx->pfx, ctx->plen);
+
+ return ipv6_addr_equal(&tmp, ipaddr);
+}
+
static u8 lowpan_compress_ctx_addr(u8 **hc_ptr, const struct net_device *dev,
const struct in6_addr *ipaddr,
const struct lowpan_iphc_ctx *ctx,
@@ -827,13 +859,7 @@ static u8 lowpan_compress_ctx_addr(u8 **hc_ptr, const
struct net_device *dev,
}
break;
default:
- /* check for SAM/DAM = 11 */
- memcpy(&tmp.s6_addr[8], lladdr, EUI64_ADDR_LEN);
- /* second bit-flip (Universe/Local) is done according RFC2464 */
- tmp.s6_addr[8] ^= 0x02;
- /* context information are always used */
- ipv6_addr_prefix_copy(&tmp, &ctx->pfx, ctx->plen);
- if (ipv6_addr_equal(&tmp, ipaddr)) {
+ if (lowpan_iphc_addr_equal(dev, ctx, ipaddr, lladdr)) {
dam = LOWPAN_IPHC_DAM_11;
goto out;
[PATCH v5 2/6] 6lowpan: Set MAC address length according to LOWPAN_LLTYPE
From: Patrik Flykt
Set MAC address length according to the 6LoWPAN link layer in use.
Bluetooth Low Energy uses 48 bit addressing while IEEE802.15.4 uses
64 bits.
Signed-off-by: Patrik Flykt
Reviewed-by: Stefan Schmidt
---
net/6lowpan/core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/net/6lowpan/core.c b/net/6lowpan/core.c
index 5945f7e..5f9909a 100644
--- a/net/6lowpan/core.c
+++ b/net/6lowpan/core.c
@@ -23,7 +23,16 @@ int lowpan_register_netdevice(struct net_device *dev,
{
int i, ret;
- dev->addr_len = EUI64_ADDR_LEN;
+ switch (lltype) {
+ case LOWPAN_LLTYPE_IEEE802154:
+ dev->addr_len = EUI64_ADDR_LEN;
+ break;
+
+ case LOWPAN_LLTYPE_BTLE:
+ dev->addr_len = ETH_ALEN;
+ break;
+ }
+
dev->type = ARPHRD_6LOWPAN;
dev->mtu = IPV6_MIN_MTU;
dev->priv_flags |= IFF_NO_QUEUE;
--
2.9.3
[PATCH v5 1/6] bluetooth: Set 6 byte device addresses
From: Patrik Flykt
Set BTLE MAC addresses that are 6 bytes long and not 8 bytes
that are used in other places with 6lowpan.
Signed-off-by: Patrik Flykt
Signed-off-by: Luiz Augusto von Dentz
Reviewed-by: Stefan Schmidt
---
net/bluetooth/6lowpan.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 1904a93..1456b01 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -80,6 +80,8 @@ struct lowpan_btle_dev {
struct delayed_work notify_peers;
};
+static void set_addr(u8 *eui, u8 *addr, u8 addr_type);
+
static inline struct lowpan_btle_dev *
lowpan_btle_dev(const struct net_device *netdev)
{
@@ -272,9 +274,10 @@ static int give_skb_to_upper(struct sk_buff *skb, struct
net_device *dev)
static int iphc_decompress(struct sk_buff *skb, struct net_device *netdev,
struct l2cap_chan *chan)
{
- const u8 *saddr, *daddr;
+ const u8 *saddr;
struct lowpan_btle_dev *dev;
struct lowpan_peer *peer;
+ unsigned char eui64_daddr[EUI64_ADDR_LEN];
dev = lowpan_btle_dev(netdev);
@@ -285,9 +288,9 @@ static int iphc_decompress(struct sk_buff *skb, struct
net_device *netdev,
return -EINVAL;
saddr = peer->eui64_addr;
- daddr = dev->netdev->dev_addr;
+ set_addr(&eui64_daddr[0], chan->src.b, chan->src_type);
- return lowpan_header_decompress(skb, netdev, daddr, saddr);
+ return lowpan_header_decompress(skb, netdev, &eui64_daddr, saddr);
}
static int recv_pkt(struct sk_buff *skb, struct net_device *dev,
@@ -681,13 +684,6 @@ static void set_addr(u8 *eui, u8 *addr, u8 addr_type)
BT_DBG("type %d addr %*phC", addr_type, 8, eui);
}
-static void set_dev_addr(struct net_device *netdev, bdaddr_t *addr,
-u8 addr_type)
-{
- netdev->addr_assign_type = NET_ADDR_PERM;
- set_addr(netdev->dev_addr, addr->b, addr_type);
-}
-
static void ifup(struct net_device *netdev)
{
int err;
@@ -803,7 +799,8 @@ static int setup_netdev(struct l2cap_chan *chan, struct
lowpan_btle_dev **dev)
if (!netdev)
return -ENOMEM;
- set_dev_addr(netdev, &chan->src, chan->src_type);
+ netdev->addr_assign_type = NET_ADDR_PERM;
+ baswap((void *)netdev->dev_addr, &chan->src);
netdev->netdev_ops = &netdev_ops;
SET_NETDEV_DEV(netdev, &chan->conn->hcon->hdev->dev);
--
2.9.3
[PATCH v5 0/6] Bluetooth: 6LoWPAN: Fix lladdr length
From: Luiz Augusto von Dentz These patches fixes lladdr length to be 6 bytes long and not 8 which cause neighbor advertisement to be sent with wrong lladdr including FF:FE filler bytes for eui64. Note: This does not fix some of the existing crashes which I hope to address in a different set. v2: Make all code paths that generate a link-local from lladdr use the same code. v3: Use lowpan_iphc_uncompress_eui48_lladdr to generate the remote ip address. v4: Handle comments from Stefan Schmidt. v5: Add patch to fix IID format for Bluetooth Alexander Aring (2): 6lowpan: iphc: override l2 packet information ipv6: addrconf: fix 48 bit 6lowpan autoconfiguration Luiz Augusto von Dentz (2): 6lowpan: Use netdev addr_len to determine lladdr len 6lowpan: Fix IID format for Bluetooth Patrik Flykt (2): bluetooth: Set 6 byte device addresses 6lowpan: Set MAC address length according to LOWPAN_LLTYPE include/net/6lowpan.h | 15 ++ net/6lowpan/core.c | 11 +++- net/6lowpan/iphc.c | 57 + net/bluetooth/6lowpan.c | 130 net/ipv6/addrconf.c | 17 +-- 5 files changed, 104 insertions(+), 126 deletions(-) -- 2.9.3
[PATCH v5 4/6] ipv6: addrconf: fix 48 bit 6lowpan autoconfiguration
From: Alexander Aring
This patch adds support for 48 bit 6LoWPAN address length
autoconfiguration which is the case for BTLE 6LoWPAN.
Signed-off-by: Alexander Aring
Signed-off-by: Luiz Augusto von Dentz
Reviewed-by: Stefan Schmidt
---
net/ipv6/addrconf.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 3a2025f..7756640 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2052,12 +2052,19 @@ static void addrconf_leave_anycast(struct inet6_ifaddr
*ifp)
__ipv6_dev_ac_dec(ifp->idev, &addr);
}
-static int addrconf_ifid_eui64(u8 *eui, struct net_device *dev)
+static int addrconf_ifid_6lowpan(u8 *eui, struct net_device *dev)
{
- if (dev->addr_len != EUI64_ADDR_LEN)
+ switch (dev->addr_len) {
+ case ETH_ALEN:
+ return addrconf_ifid_eui48(eui, dev);
+ case EUI64_ADDR_LEN:
+ memcpy(eui, dev->dev_addr, EUI64_ADDR_LEN);
+ eui[0] ^= 2;
+ break;
+ default:
return -1;
- memcpy(eui, dev->dev_addr, EUI64_ADDR_LEN);
- eui[0] ^= 2;
+ }
+
return 0;
}
@@ -2149,7 +2156,7 @@ static int ipv6_generate_eui64(u8 *eui, struct net_device
*dev)
case ARPHRD_TUNNEL:
return addrconf_ifid_gre(eui, dev);
case ARPHRD_6LOWPAN:
- return addrconf_ifid_eui64(eui, dev);
+ return addrconf_ifid_6lowpan(eui, dev);
case ARPHRD_IEEE1394:
return addrconf_ifid_ieee1394(eui, dev);
case ARPHRD_TUNNEL6:
--
2.9.3
[PATCH v5 3/6] 6lowpan: iphc: override l2 packet information
From: Alexander Aring
The skb->pkt_type need to be set by L2, but on 6LoWPAN there exists L2
e.g. BTLE which doesn't has multicast addressing. If it's a multicast or
not is detected by IPHC headers multicast bit. The IPv6 layer will
evaluate this pkt_type, so we force set this type while uncompressing.
Should be okay for 802.15.4 as well.
Signed-off-by: Alexander Aring
Reviewed-by: Stefan Schmidt
---
net/6lowpan/iphc.c | 8
1 file changed, 8 insertions(+)
diff --git a/net/6lowpan/iphc.c b/net/6lowpan/iphc.c
index 79f1fa2..fb5f6fa 100644
--- a/net/6lowpan/iphc.c
+++ b/net/6lowpan/iphc.c
@@ -666,6 +666,8 @@ int lowpan_header_decompress(struct sk_buff *skb, const
struct net_device *dev,
switch (iphc1 & (LOWPAN_IPHC_M | LOWPAN_IPHC_DAC)) {
case LOWPAN_IPHC_M | LOWPAN_IPHC_DAC:
+ skb->pkt_type = PACKET_BROADCAST;
+
spin_lock_bh(&lowpan_dev(dev)->ctx.lock);
ci = lowpan_iphc_ctx_get_by_id(dev, LOWPAN_IPHC_CID_DCI(cid));
if (!ci) {
@@ -681,11 +683,15 @@ int lowpan_header_decompress(struct sk_buff *skb, const
struct net_device *dev,
spin_unlock_bh(&lowpan_dev(dev)->ctx.lock);
break;
case LOWPAN_IPHC_M:
+ skb->pkt_type = PACKET_BROADCAST;
+
/* multicast */
err = lowpan_uncompress_multicast_daddr(skb, &hdr.daddr,
iphc1 &
LOWPAN_IPHC_DAM_MASK);
break;
case LOWPAN_IPHC_DAC:
+ skb->pkt_type = PACKET_HOST;
+
spin_lock_bh(&lowpan_dev(dev)->ctx.lock);
ci = lowpan_iphc_ctx_get_by_id(dev, LOWPAN_IPHC_CID_DCI(cid));
if (!ci) {
@@ -701,6 +707,8 @@ int lowpan_header_decompress(struct sk_buff *skb, const
struct net_device *dev,
spin_unlock_bh(&lowpan_dev(dev)->ctx.lock);
break;
default:
+ skb->pkt_type = PACKET_HOST;
+
err = lowpan_iphc_uncompress_addr(skb, dev, &hdr.daddr,
iphc1 & LOWPAN_IPHC_DAM_MASK,
daddr);
--
2.9.3
[PATCH v5 6/6] 6lowpan: Fix IID format for Bluetooth
From: Luiz Augusto von Dentz
Accourding to RFC 7668 U/L bit shall not be used:
https://wiki.tools.ietf.org/html/rfc7668#section-3.2.2 [Page 10]:
In the figure, letter 'b' represents a bit from the
Bluetooth device address, copied as is without any changes on any
bit. This means that no bit in the IID indicates whether the
underlying Bluetooth device address is public or random.
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+++++
|||1110||
+++++
Because of this the code cannot figure out the address type from the IP
address anymore thus it makes no sense to use peer_lookup_ba as it needs
the peer address type.
Signed-off-by: Luiz Augusto von Dentz
---
include/net/6lowpan.h | 4 ---
net/bluetooth/6lowpan.c | 79 -
2 files changed, 12 insertions(+), 71 deletions(-)
diff --git a/include/net/6lowpan.h b/include/net/6lowpan.h
index c5792cb..a713780 100644
--- a/include/net/6lowpan.h
+++ b/include/net/6lowpan.h
@@ -211,10 +211,6 @@ static inline void
lowpan_iphc_uncompress_eui48_lladdr(struct in6_addr *ipaddr,
ipaddr->s6_addr[11] = 0xFF;
ipaddr->s6_addr[12] = 0xFE;
memcpy(&ipaddr->s6_addr[13], lladdr + 3, 3);
- /* second bit-flip (Universe/Local)
-* is done according RFC2464
-*/
- ipaddr->s6_addr[8] ^= 0x02;
}
#ifdef DEBUG
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 0b68cfc..ec89c55 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -398,37 +398,6 @@ static int chan_recv_cb(struct l2cap_chan *chan, struct
sk_buff *skb)
return err;
}
-static u8 get_addr_type_from_eui64(u8 byte)
-{
- /* Is universal(0) or local(1) bit */
- return ((byte & 0x02) ? BDADDR_LE_RANDOM : BDADDR_LE_PUBLIC);
-}
-
-static void copy_to_bdaddr(struct in6_addr *ip6_daddr, bdaddr_t *addr)
-{
- u8 *eui64 = ip6_daddr->s6_addr + 8;
-
- addr->b[0] = eui64[7];
- addr->b[1] = eui64[6];
- addr->b[2] = eui64[5];
- addr->b[3] = eui64[2];
- addr->b[4] = eui64[1];
- addr->b[5] = eui64[0];
-}
-
-static void convert_dest_bdaddr(struct in6_addr *ip6_daddr,
- bdaddr_t *addr, u8 *addr_type)
-{
- copy_to_bdaddr(ip6_daddr, addr);
-
- /* We need to toggle the U/L bit that we got from IPv6 address
-* so that we get the proper address and type of the BD address.
-*/
- addr->b[5] ^= 0x02;
-
- *addr_type = get_addr_type_from_eui64(addr->b[5]);
-}
-
static int setup_header(struct sk_buff *skb, struct net_device *netdev,
bdaddr_t *peer_addr, u8 *peer_addr_type)
{
@@ -436,8 +405,7 @@ static int setup_header(struct sk_buff *skb, struct
net_device *netdev,
struct ipv6hdr *hdr;
struct lowpan_btle_dev *dev;
struct lowpan_peer *peer;
- bdaddr_t addr, *any = BDADDR_ANY;
- u8 *daddr = any->b;
+ u8 *daddr;
int err, status = 0;
hdr = ipv6_hdr(skb);
@@ -448,34 +416,24 @@ static int setup_header(struct sk_buff *skb, struct
net_device *netdev,
if (ipv6_addr_is_multicast(&ipv6_daddr)) {
lowpan_cb(skb)->chan = NULL;
+ daddr = NULL;
} else {
- u8 addr_type;
+ BT_DBG("dest IP %pI6c", &ipv6_daddr);
- /* Get destination BT device from skb.
-* If there is no such peer then discard the packet.
+ /* The packet might be sent to 6lowpan interface
+* because of routing (either via default route
+* or user set route) so get peer according to
+* the destination address.
*/
- convert_dest_bdaddr(&ipv6_daddr, &addr, &addr_type);
-
- BT_DBG("dest addr %pMR type %d IP %pI6c", &addr,
- addr_type, &ipv6_daddr);
-
- peer = peer_lookup_ba(dev, &addr, addr_type);
+ peer = peer_lookup_dst(dev, &ipv6_daddr, skb);
if (!peer) {
- /* The packet might be sent to 6lowpan interface
-* because of routing (either via default route
-* or user set route) so get peer according to
-* the destination address.
-*/
- peer = peer_lookup_dst(dev, &ipv6_daddr, skb);
- if (!peer) {
- BT_DBG("no such peer %pMR found", &addr);
- return -ENOENT;
- }
+ BT_DBG("no such peer");
+ return -ENO
Re: [PATCH net-next v3 0/4] net: mvneta: improve rx/tx performance
Hi David, Marcin, On Tue, 21 Feb 2017 11:16:02 -0500 David Miller wrote: > From: Jisheng Zhang > Date: Tue, 21 Feb 2017 12:37:40 +0800 > > > Thanks for your review. > > > > The measurement is simple: record how much time we spent in mvneta_rx_swbm() > > for receiving 1GB data, something as below: > > Please use a standard tool for measuring performance, rather than profiling > the driver and trying to derive numbers that way. Got your point. I will try to get performance with standard tool and cook a v4 once rc1 is released. Thanks, Jisheng
Hopefully
Dear friend, My name is Mr Micheal Rita, I am the Bill and Exchange (assistant) Manager of Bank of Africa Ouagadougou, Burkina Faso. In my department I discovered an abandoned sum of teen million five hundred thousand United State of American dollars (10.5MILLION USA DOLLARS) in an account that belongs to one of our foreign customer who died in airline that crashed on 4th October 2001. Since I got information about his death I have been expecting his next of kin to come over and claim his money because we can not release it unless somebody applies for it as the next of kin or relation to the deceased as indicated in our banking guidelines, but unfortunately we learnt that all his supposed next of kin or relation died alongside with him in the plane crash leaving nobody behind for the claim. It is therefore upon this discovery that I decided to make this business proposal to you and release the money to you as next of kin or relation to the deceased for safety and subsequent disbursement since nobody is coming for it and I don't want the money to go into the bank treasury as unclaimed bill. You will be entitled with 40% of the total sum while 60% will be for me after which I will visit your Country to invest my own share when the fund is successfully transferred into your account, Please I would like you to keep this transaction confidential and as a top secret as you may wish to know that I am a bank official. Yours sincerely, Mr Micheal Rita.
Re: [PATCH 3/3] mwifiex: wake system up when receives a wake irq
Jeffy Chen writes: > Currrently we are disabling this wake irq after receiving it. If this > happens before we finish suspend and the pm event check is disabled, > the system will continue suspending, and this irq would not work again. > > We may need to abort system suspend to avoid that. > > Signed-off-by: Jeffy Chen I only see patch 3 in patchwork. Where are patches 1 and 2? -- Kalle Valo
[PATCH v2 net] net: phy: Fix LED mode in DT single property.
From: Raju Lakkaraju
Fix the LED mode DT parameters combine to a single property
and change the vendor prefix i.e. mscc.
Signed-off-by: Raju Lakkaraju
---
Change set:
v0: Fix the LED mode DT parameters combine to a single property
v1: Fix the build test ERROR
v2: Add default LED mode "vsc85xx_dt_led_mode_get" function.
.../devicetree/bindings/net/mscc-phy-vsc8531.txt | 20 +++
drivers/net/phy/mscc.c | 65 --
2 files changed, 45 insertions(+), 40 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
index 0eedabe..2253de5 100644
--- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
+++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
@@ -6,12 +6,12 @@ Required properties:
Documentation/devicetree/bindings/net/phy.txt
Optional properties:
-- vsc8531,vddmac : The vddmac in mV. Allowed values is listed
+- mscc,vddmac : The vddmac in mV. Allowed values is listed
in the first row of Table 1 (below).
This property is only used in combination
with the 'edge-slowdown' property.
Default value is 3300.
-- vsc8531,edge-slowdown: % the edge should be slowed down relative to
+- mscc,edge-slowdown : % the edge should be slowed down relative to
the fastest possible edge time.
Edge rate sets the drive strength of the MAC
interface output signals. Changing the
@@ -27,14 +27,11 @@ Optional properties:
'vddmac'.
Default value is 0%.
Ref: Table:1 - Edge rate change (below).
-- vsc8531,led-0-mode : LED mode. Specify how the LED[0] should behave.
+- mscc,led-mode: LED mode. Specify how the LED[0] and LED[1]
should behave.
Allowed values are define in
"include/dt-bindings/net/mscc-phy-vsc8531.h".
- Default value is VSC8531_LINK_1000_ACTIVITY (1).
-- vsc8531,led-1-mode : LED mode. Specify how the LED[1] should behave.
- Allowed values are define in
- "include/dt-bindings/net/mscc-phy-vsc8531.h".
- Default value is VSC8531_LINK_100_ACTIVITY (2).
+ Default LED[0] value is VSC8531_LINK_1000_ACTIVITY
(1).
+ Default LED[1] value is VSC8531_LINK_100_ACTIVITY (2).
Table: 1 - Edge rate change
|
@@ -66,8 +63,7 @@ Example:
vsc8531_0: ethernet-phy@0 {
compatible = "ethernet-phy-id0007.0570";
-vsc8531,vddmac = <3300>;
-vsc8531,edge-slowdown = <7>;
-vsc8531,led-0-mode = ;
-vsc8531,led-1-mode = ;
+mscc,vddmac= /bits/ 16 <3300>;
+mscc,edge-slowdown = /bits/ 8 <7>;
+mscc,led-mode = ;
};
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index 650c266..5cd705b 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -385,11 +385,11 @@ static int vsc85xx_edge_rate_magic_get(struct phy_device
*phydev)
if (!of_node)
return -ENODEV;
- rc = of_property_read_u16(of_node, "vsc8531,vddmac", &vdd);
+ rc = of_property_read_u16(of_node, "mscc,vddmac", &vdd);
if (rc != 0)
vdd = MSCC_VDDMAC_3300;
- rc = of_property_read_u8(of_node, "vsc8531,edge-slowdown", &sd);
+ rc = of_property_read_u8(of_node, "mscc,edge-slowdown", &sd);
if (rc != 0)
sd = 0;
@@ -402,26 +402,43 @@ static int vsc85xx_edge_rate_magic_get(struct phy_device
*phydev)
return -EINVAL;
}
-static int vsc85xx_dt_led_mode_get(struct phy_device *phydev,
- char *led,
- u8 default_mode)
+static int vsc85xx_dt_led_mode_get(struct phy_device *phydev, char *led)
{
struct device *dev = &phydev->mdio.dev;
struct device_node *of_node = dev->of_node;
- u8 led_mode;
- int err;
+ struct vsc8531_private *vsc8531 = phydev->priv;
+ u8 led_0_mode = VSC8531_LINK_1000_ACTIVITY;
+ u8 led_1_mode = VSC8531_LINK_100_ACTIVITY;
+ const __be32 *paddr_end;
+ const __be32 *paddr;
+ int len;
if (!of_node)
return -ENODEV;
- led_mode = default_mode;
- err = of_property_read_u8(of_node, led, &led_mode);
- if (!err && (led_mode > 15 || led_mode == 7 || led_mode == 11)) {
- phydev_err(phydev, "DT %s invalid\n", led);
+ paddr = of_get_property(of_node, "mscc,led-mode", &le
[PATCH] drivers: net: xgene: Simplify xgene_enet_setup_mss() to kill warning
With gcc-4.1.2 and -Os:
drivers/net/ethernet/apm/xgene/xgene_enet_main.c: In function
‘xgene_enet_start_xmit’:
drivers/net/ethernet/apm/xgene/xgene_enet_main.c:297: warning: ‘mss_index’
may be used uninitialized in this function
Using a separate variable to track success may confuse the compiler.
Preinitialize mss_index with -EBUSY and check for negative error values
instead to kill the warning.
Signed-off-by: Geert Uytterhoeven
---
Compile-tested only.
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index d0d0d12b531fc683..e536301acfdec9fd 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -293,36 +293,29 @@ static int xgene_enet_tx_completion(struct
xgene_enet_desc_ring *cp_ring,
static int xgene_enet_setup_mss(struct net_device *ndev, u32 mss)
{
struct xgene_enet_pdata *pdata = netdev_priv(ndev);
- bool mss_index_found = false;
- int mss_index;
+ int mss_index = -EBUSY;
int i;
spin_lock(&pdata->mss_lock);
/* Reuse the slot if MSS matches */
- for (i = 0; !mss_index_found && i < NUM_MSS_REG; i++) {
+ for (i = 0; mss_index < 0 && i < NUM_MSS_REG; i++) {
if (pdata->mss[i] == mss) {
pdata->mss_refcnt[i]++;
mss_index = i;
- mss_index_found = true;
}
}
/* Overwrite the slot with ref_count = 0 */
- for (i = 0; !mss_index_found && i < NUM_MSS_REG; i++) {
+ for (i = 0; mss_index < 0 && i < NUM_MSS_REG; i++) {
if (!pdata->mss_refcnt[i]) {
pdata->mss_refcnt[i]++;
pdata->mac_ops->set_mss(pdata, mss, i);
pdata->mss[i] = mss;
mss_index = i;
- mss_index_found = true;
}
}
- /* No slots with ref_count = 0 available, return busy */
- if (!mss_index_found)
- mss_index = -EBUSY;
-
spin_unlock(&pdata->mss_lock);
return mss_index;
--
2.7.4
[PATCH] lib: Allow compile-testing of parman
This allows to enable and run the accompanying test (test_parman) without dependencies on other users of parman. Signed-off-by: Geert Uytterhoeven --- lib/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/Kconfig b/lib/Kconfig index fe7e8e175db8f7b4..e494065156a28d20 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -549,7 +549,7 @@ config SBITMAP bool config PARMAN - tristate + tristate "parman" if COMPILE_TEST config PRIME_NUMBERS tristate -- 2.7.4
RE: [PATCH net-next 2/2] sctp: add support for MSG_MORE
From: Xin Long > Sent: 24 February 2017 06:44 ... > > IIRC sctp_packet_can_append_data() is called for the first queued > > data chunk in order to decide whether to generate a message that > > consists only of data chunks. > > If it returns SCTP_XMIT_OK then a message is built collecting the > > rest of the queued data chunks (until the window fills). > > > > So if I send a message with MSG_MORE set (on an idle connection) > > SCTP_XMIT_DELAY is returned and a message isn't sent. > > > > I now send a second small message, this time with MSG_MORE clear. > > The message is queued, then the code looks to see if it can send anything. > > > > sctp_packet_can_append_data() is called for the first queued chunk. > > Since it has force_delay set SCTP_XMIT_DELAY is returned and no > > message is built. > > The second message isn't even looked at. > You're right. I can see the problem now. > > What I expected is it should work like: > > 1, send 3 small chunks with MSG_MORE set, the queue is: > chk3 [set] -> chk2 [set] -> chk1 [set] Strange way to write a queue! chk1 points to chk2 :-) > 2. send 1 more chunk with MSG_MORE clear, the queue is: > chk4[clear] -> chk3 [clear] -> chk2 [clear] -> chk1 [clear] I don't think processing the entire queue is a good idea. Both from execution time and the effects on the data cache. The SCTP code is horrid enough as it is. > 3. then if user send more small chunks with MSG_MORE set, > the queue is like: > chkB[set] -> chkA[set] -> chk4[clear] -> chk3 [clear] -> chk2 [clear] -> > chk1 [clear] > so that the new small chunks' flag will not affect the other chunks bundling. That isn't really necessary. The user can't expect to have absolute control over which chunks get bundled together. If the above chunks still aren't big enough to fill a frame the code might as well wait for the next chunk instead of building a packet that contains chk1 through to chkB. Remember you'll only get a queued chunk with MSG_MORE clear if data can't be sent. As soon as data can be sent, if the first chunk has MSG_MORE clear all of the queued chunks will be sent. So immediately after your (3) the application is expected to send a chunk with MSG_MORE clear - at that point all the queued chunks can be sent in a single packet. So just save the last MSG_MORE on the association as I did. David
[PATCH 1/1] color: use "light" colors for dark background
COLORFGBG environment variable is used to detect dark background.
Idea and a bit of code is borrowed from Vim, thanks.
Signed-off-by: Petr Vorel
---
Colors are nice, but the ones chosen aren't suitable for dark background.
COLORFGBG environment variable is used in some libraries and software (e.g.
ncurses, Vim). COLORFGBG is set by various terminal emulators (e.g. konsole,
rxvt and rxvt-unicode).
Chosen colors are questionable. Best solution would be also allow user to
redefine colors, like ls does with LS_COLORS or grep with GREP_COLORS. But that
is maybe overkill.
---
include/color.h | 1 +
lib/color.c | 43 ++-
2 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/include/color.h b/include/color.h
index c1c29831..43190db4 100644
--- a/include/color.h
+++ b/include/color.h
@@ -12,6 +12,7 @@ enum color_attr {
};
void enable_color(void);
+void set_background(void);
int color_fprintf(FILE *fp, enum color_attr attr, const char *fmt, ...);
enum color_attr ifa_family_color(__u8 ifa_family);
enum color_attr oper_state_color(__u8 state);
diff --git a/lib/color.c b/lib/color.c
index 95596be2..69375b26 100644
--- a/lib/color.c
+++ b/lib/color.c
@@ -1,5 +1,7 @@
#include
#include
+#include
+#include
#include
#include
#include
@@ -14,6 +16,12 @@ enum color {
C_MAGENTA,
C_CYAN,
C_WHITE,
+ C_LIGHT_RED,
+ C_LIGHT_GREEN,
+ C_LIGHT_YELLOW,
+ C_LIGHT_BLUE,
+ C_LIGHT_MAGENTA,
+ C_LIGHT_CYAN,
C_CLEAR
};
@@ -25,25 +33,58 @@ static const char * const color_codes[] = {
"\e[35m",
"\e[36m",
"\e[37m",
+ "\e[1;31m",
+ "\e[1;32m",
+ "\e[1;33m",
+ "\e[1;34m",
+ "\e[1;35m",
+ "\e[1;36m",
"\e[0m",
NULL,
};
static enum color attr_colors[] = {
+ /* light background */
C_CYAN,
C_YELLOW,
C_MAGENTA,
C_BLUE,
C_GREEN,
C_RED,
+ C_CLEAR,
+
+ /* dark background */
+ C_LIGHT_CYAN,
+ C_LIGHT_YELLOW,
+ C_LIGHT_MAGENTA,
+ C_LIGHT_BLUE,
+ C_LIGHT_GREEN,
+ C_LIGHT_RED,
C_CLEAR
};
+static int is_dark_bg;
static int color_is_enabled;
void enable_color(void)
{
color_is_enabled = 1;
+ set_background();
+}
+
+void set_background(void)
+{
+ char *p = getenv("COLORFGBG");
+
+ /*
+* COLORFGBG environment variable usually contains either two or three
+* values separated by semicolons; we want the last value in either
case.
+* If this value is 0-6 or 8, background is dark.
+*/
+ if (p && (p = (char *)strrchr(p, ';')) != NULL
+ && ((p[1] >= '0' && p[1] <= '6') || p[1] == '8')
+ && p[2] == '\0')
+ is_dark_bg = 1;
}
int color_fprintf(FILE *fp, enum color_attr attr, const char *fmt, ...)
@@ -58,7 +99,7 @@ int color_fprintf(FILE *fp, enum color_attr attr, const char
*fmt, ...)
goto end;
}
- ret += fprintf(fp, "%s", color_codes[attr_colors[attr]]);
+ ret += fprintf(fp, "%s", color_codes[attr_colors[is_dark_bg ? attr + 7
: attr]]);
ret += vfprintf(fp, fmt, args);
ret += fprintf(fp, "%s", color_codes[C_CLEAR]);
--
2.11.0
Re: [PATCH v2 net] net: phy: Fix LED mode in DT single property.
Hi Raju,
[auto build test ERROR on net/master]
url:
https://github.com/0day-ci/linux/commits/Raju-Lakkaraju/net-phy-Fix-LED-mode-in-DT-single-property/20170224-171412
config: i386-randconfig-x011-201708 (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=i386
All errors (new ones prefixed by >>):
drivers/net/phy/mscc.c: In function 'vsc85xx_dt_led_mode_get':
>> drivers/net/phy/mscc.c:452:2: error: 'vsc8531' undeclared (first use in this
>> function)
vsc8531->led_0_mode = VSC8531_LINK_1000_ACTIVITY;
^~~
drivers/net/phy/mscc.c:452:2: note: each undeclared identifier is reported
only once for each function it appears in
vim +/vsc8531 +452 drivers/net/phy/mscc.c
446 {
447 return 0;
448 }
449
450 static int vsc85xx_dt_led_mode_get(struct phy_device *phydev, char *led)
451 {
> 452 vsc8531->led_0_mode = VSC8531_LINK_1000_ACTIVITY;
453 vsc8531->led_1_mode = VSC8531_LINK_100_ACTIVITY;
454 return 0;
455 }
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v3 net-next 08/14] mlx4: use order-0 pages for RX
On Wed, 22 Feb 2017 18:06:58 -0800 Eric Dumazet wrote: > On Wed, 2017-02-22 at 17:08 -0800, Alexander Duyck wrote: > > > > > Right but you were talking about using both halves one after the > > other. If that occurs you have nothing left that you can reuse. That > > was what I was getting at. If you use up both halves you end up > > having to unmap the page. > > > > You must have misunderstood me. FYI, I also misunderstood you (Eric) to start with ;-) > Once we use both halves of a page, we _keep_ the page, we do not unmap > it. > > We save the page pointer in a ring buffer of pages. > Call it the 'quarantine' > > When we _need_ to replenish the RX desc, we take a look at the oldest > entry in the quarantine ring. > > If page count is 1 (or pagecnt_bias if needed) -> we immediately reuse > this saved page. > > If not, _then_ we unmap and release the page. > > Note that we would have received 4096 frames before looking at the page > count, so there is high chance both halves were consumed. > > To recap on x86 : > > 2048 active pages would be visible by the device, because 4096 RX desc > would contain dma addresses pointing to the 4096 halves. > > And 2048 pages would be in the reserve. I do like it, and it should work. I like it because it solves my concern, regarding being able to adjust the amount of outstanding-frames independently of the RX ring size. Do notice: driver developers have to use Alex'es new DMA API in-order to get writable-pages, else this will violate the DMA API. And XDP requires writable pages. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer
[PATCH 1/1] rds: fix memory leak error
When the function register_netdevice_notifier fails, the memory
allocated by kmem_cache_create should be freed by the function
kmem_cache_destroy.
Cc: Joe Jin
Cc: Junxiao Bi
Signed-off-by: Zhu Yanjun
---
net/rds/tcp.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/rds/tcp.c b/net/rds/tcp.c
index 57bb523..5438f67 100644
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -641,12 +641,12 @@ static int rds_tcp_init(void)
ret = register_netdevice_notifier(&rds_tcp_dev_notifier);
if (ret) {
pr_warn("could not register rds_tcp_dev_notifier\n");
- goto out;
+ goto out_slab;
}
ret = register_pernet_subsys(&rds_tcp_net_ops);
if (ret)
- goto out_slab;
+ goto out_notifier;
ret = rds_tcp_recv_init();
if (ret)
@@ -664,9 +664,10 @@ static int rds_tcp_init(void)
rds_tcp_recv_exit();
out_pernet:
unregister_pernet_subsys(&rds_tcp_net_ops);
-out_slab:
+out_notifier:
if (unregister_netdevice_notifier(&rds_tcp_dev_notifier))
pr_warn("could not unregister rds_tcp_dev_notifier\n");
+out_slab:
kmem_cache_destroy(rds_tcp_conn_slab);
out:
return ret;
--
2.7.4
[PATCH v2 net] net: phy: Fix LED mode in DT single property.
From: Raju Lakkaraju
Fix the LED mode DT parameters combine to a single property
and change the vendor prefix i.e. mscc.
Signed-off-by: Raju Lakkaraju
---
Change set:
v0: Fix the LED mode DT parameters combine to a single property
v1: Fix the build test ERROR
v2: Add default LED mode "vsc85xx_dt_led_mode_get" function.
.../devicetree/bindings/net/mscc-phy-vsc8531.txt | 20 +++
drivers/net/phy/mscc.c | 65 --
2 files changed, 45 insertions(+), 40 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
index 0eedabe..2253de5 100644
--- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
+++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
@@ -6,12 +6,12 @@ Required properties:
Documentation/devicetree/bindings/net/phy.txt
Optional properties:
-- vsc8531,vddmac : The vddmac in mV. Allowed values is listed
+- mscc,vddmac : The vddmac in mV. Allowed values is listed
in the first row of Table 1 (below).
This property is only used in combination
with the 'edge-slowdown' property.
Default value is 3300.
-- vsc8531,edge-slowdown: % the edge should be slowed down relative to
+- mscc,edge-slowdown : % the edge should be slowed down relative to
the fastest possible edge time.
Edge rate sets the drive strength of the MAC
interface output signals. Changing the
@@ -27,14 +27,11 @@ Optional properties:
'vddmac'.
Default value is 0%.
Ref: Table:1 - Edge rate change (below).
-- vsc8531,led-0-mode : LED mode. Specify how the LED[0] should behave.
+- mscc,led-mode: LED mode. Specify how the LED[0] and LED[1]
should behave.
Allowed values are define in
"include/dt-bindings/net/mscc-phy-vsc8531.h".
- Default value is VSC8531_LINK_1000_ACTIVITY (1).
-- vsc8531,led-1-mode : LED mode. Specify how the LED[1] should behave.
- Allowed values are define in
- "include/dt-bindings/net/mscc-phy-vsc8531.h".
- Default value is VSC8531_LINK_100_ACTIVITY (2).
+ Default LED[0] value is VSC8531_LINK_1000_ACTIVITY
(1).
+ Default LED[1] value is VSC8531_LINK_100_ACTIVITY (2).
Table: 1 - Edge rate change
|
@@ -66,8 +63,7 @@ Example:
vsc8531_0: ethernet-phy@0 {
compatible = "ethernet-phy-id0007.0570";
-vsc8531,vddmac = <3300>;
-vsc8531,edge-slowdown = <7>;
-vsc8531,led-0-mode = ;
-vsc8531,led-1-mode = ;
+mscc,vddmac= /bits/ 16 <3300>;
+mscc,edge-slowdown = /bits/ 8 <7>;
+mscc,led-mode = ;
};
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index 650c266..30bc9ec 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -385,11 +385,11 @@ static int vsc85xx_edge_rate_magic_get(struct phy_device
*phydev)
if (!of_node)
return -ENODEV;
- rc = of_property_read_u16(of_node, "vsc8531,vddmac", &vdd);
+ rc = of_property_read_u16(of_node, "mscc,vddmac", &vdd);
if (rc != 0)
vdd = MSCC_VDDMAC_3300;
- rc = of_property_read_u8(of_node, "vsc8531,edge-slowdown", &sd);
+ rc = of_property_read_u8(of_node, "mscc,edge-slowdown", &sd);
if (rc != 0)
sd = 0;
@@ -402,26 +402,43 @@ static int vsc85xx_edge_rate_magic_get(struct phy_device
*phydev)
return -EINVAL;
}
-static int vsc85xx_dt_led_mode_get(struct phy_device *phydev,
- char *led,
- u8 default_mode)
+static int vsc85xx_dt_led_mode_get(struct phy_device *phydev, char *led)
{
struct device *dev = &phydev->mdio.dev;
struct device_node *of_node = dev->of_node;
- u8 led_mode;
- int err;
+ struct vsc8531_private *vsc8531 = phydev->priv;
+ u8 led_0_mode = VSC8531_LINK_1000_ACTIVITY;
+ u8 led_1_mode = VSC8531_LINK_100_ACTIVITY;
+ const __be32 *paddr_end;
+ const __be32 *paddr;
+ int len;
if (!of_node)
return -ENODEV;
- led_mode = default_mode;
- err = of_property_read_u8(of_node, led, &led_mode);
- if (!err && (led_mode > 15 || led_mode == 7 || led_mode == 11)) {
- phydev_err(phydev, "DT %s invalid\n", led);
+ paddr = of_get_property(of_node, "mscc,led-mode", &le
Re: [patch net] lib: Remove string from parman config selection
Fri, Feb 24, 2017 at 08:54:04AM CET, ge...@linux-m68k.org wrote:
>Hi Jiri,
>
>On Thu, Feb 23, 2017 at 10:57 AM, Jiri Pirko wrote:
>> From: Jiri Pirko
>>
>> As reported by Geert, remove the string so the user does not see this
>> config option. The option is explicitly selected only as a dependency of
>> in-kernel users.
>>
>> Reported-by: Geert Uytterhoeven
>> Fixes: 44091d29f207 ("lib: Introduce priority array area manager")
>> Signed-off-by: Jiri Pirko
>> ---
>> lib/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lib/Kconfig b/lib/Kconfig
>> index 5d644f1..f355260 100644
>> --- a/lib/Kconfig
>> +++ b/lib/Kconfig
>> @@ -551,6 +551,6 @@ config SBITMAP
>> bool
>>
>> config PARMAN
>> - tristate "parman"
>> + tristate
>
>Upon second thought
>
>tristate "parman" if COMPILE_TEST
>
>might be better, as it allows to enable and run the accompanying test without
>dependencies.
>
>Gr{oetje,eeting}s,
>
>Geert
Geert, could you please send this as a follow-up? Thanks.
Re: [patch net] lib: Remove string from parman config selection
Hi Jiri,
On Fri, Feb 24, 2017 at 9:25 AM, Jiri Pirko wrote:
> Fri, Feb 24, 2017 at 08:54:04AM CET, ge...@linux-m68k.org wrote:
>>On Thu, Feb 23, 2017 at 10:57 AM, Jiri Pirko wrote:
>>> From: Jiri Pirko
>>>
>>> As reported by Geert, remove the string so the user does not see this
>>> config option. The option is explicitly selected only as a dependency of
>>> in-kernel users.
>>>
>>> Reported-by: Geert Uytterhoeven
>>> Fixes: 44091d29f207 ("lib: Introduce priority array area manager")
>>> Signed-off-by: Jiri Pirko
>>> ---
>>> lib/Kconfig | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/lib/Kconfig b/lib/Kconfig
>>> index 5d644f1..f355260 100644
>>> --- a/lib/Kconfig
>>> +++ b/lib/Kconfig
>>> @@ -551,6 +551,6 @@ config SBITMAP
>>> bool
>>>
>>> config PARMAN
>>> - tristate "parman"
>>> + tristate
>>
>>Upon second thought
>>
>>tristate "parman" if COMPILE_TEST
>>
>>might be better, as it allows to enable and run the accompanying test without
>>dependencies.
>
> Geert, could you please send this as a follow-up? Thanks.
Sure, will do.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH net] ipv6: check sk sk_type and protocol early in ip_mroute_set/getsockopt
Commit 5e1859fbcc3c ("ipv4: ipmr: various fixes and cleanups") fixed
the issue for ipv4 ipmr:
ip_mroute_setsockopt() & ip_mroute_getsockopt() should not
access/set raw_sk(sk)->ipmr_table before making sure the socket
is a raw socket, and protocol is IGMP
The same fix should be done for ipv6 ipmr as well.
This patch can fix the panic caused by overwriting the same offset
as ipmr_table as in raw_sk(sk) when accessing other type's socket
by ip_mroute_setsockopt().
Signed-off-by: Xin Long
---
net/ipv6/ip6mr.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index babaf3e..6ba6c90 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -1666,6 +1666,10 @@ int ip6_mroute_setsockopt(struct sock *sk, int optname,
char __user *optval, uns
struct net *net = sock_net(sk);
struct mr6_table *mrt;
+ if (sk->sk_type != SOCK_RAW ||
+ inet_sk(sk)->inet_num != IPPROTO_ICMPV6)
+ return -EOPNOTSUPP;
+
mrt = ip6mr_get_table(net, raw6_sk(sk)->ip6mr_table ? : RT6_TABLE_DFLT);
if (!mrt)
return -ENOENT;
@@ -1677,9 +1681,6 @@ int ip6_mroute_setsockopt(struct sock *sk, int optname,
char __user *optval, uns
switch (optname) {
case MRT6_INIT:
- if (sk->sk_type != SOCK_RAW ||
- inet_sk(sk)->inet_num != IPPROTO_ICMPV6)
- return -EOPNOTSUPP;
if (optlen < sizeof(int))
return -EINVAL;
@@ -1815,6 +1816,10 @@ int ip6_mroute_getsockopt(struct sock *sk, int optname,
char __user *optval,
struct net *net = sock_net(sk);
struct mr6_table *mrt;
+ if (sk->sk_type != SOCK_RAW ||
+ inet_sk(sk)->inet_num != IPPROTO_ICMPV6)
+ return -EOPNOTSUPP;
+
mrt = ip6mr_get_table(net, raw6_sk(sk)->ip6mr_table ? : RT6_TABLE_DFLT);
if (!mrt)
return -ENOENT;
--
2.1.0
