* [RFC PATCH net-next] bpf: fix potential percpu map overcopy to user.
From: William Tu @ 2016-10-16 16:41 UTC (permalink / raw)
To: netdev
When running bpf_map_lookup on percpu elements, the bytes copied to
userspace depends on num_possible_cpus() * value_size, which could
potentially be larger than memory allocated from user, which depends
on sysconf(_SC_NPROCESSORS_CONF) to get the current cpu num. As a
result, the inconsistency might corrupt the user's stack.
The fact that sysconf(_SC_NPROCESSORS_CONF) != num_possible_cpu()
happens when cpu hotadd is enabled. For example, in Fusion when
setting vcpu.hotadd = "TRUE" or in KVM, setting
./qemu-system-x86_64 -smp 2, maxcpus=4 ...
the num_possible_cpu() will be 4 and sysconf() will be 2[1].
Currently the any percpu map lookup suffers this issue, try
samples/bpf/test_maps.c or tracex3.c.
Th RFC patch adds additional 'size' param from userspace so that
kernel knows the maximum memory it should copy to the user.
[1] https://www.mail-archive.com/netdev@vger.kernel.org/msg121183.html
Signed-off-by: William Tu <u9012063@gmail.com>
---
include/uapi/linux/bpf.h | 5 ++++-
kernel/bpf/syscall.c | 5 +++--
samples/bpf/fds_example.c | 2 +-
samples/bpf/libbpf.c | 3 ++-
samples/bpf/libbpf.h | 2 +-
samples/bpf/test_maps.c | 30 +++++++++++++++---------------
tools/include/uapi/linux/bpf.h | 5 ++++-
7 files changed, 30 insertions(+), 22 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index f09c70b..fa0c40b 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -123,7 +123,10 @@ union bpf_attr {
__aligned_u64 value;
__aligned_u64 next_key;
};
- __u64 flags;
+ union {
+ __u64 flags;
+ __u32 size; /* number of bytes allocated in userspace */
+ };
};
struct { /* anonymous struct used by BPF_PROG_LOAD command */
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 228f962..be211ea 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -264,13 +264,14 @@ int __weak bpf_stackmap_copy(struct bpf_map *map, void *key, void *value)
}
/* last field in 'union bpf_attr' used by this command */
-#define BPF_MAP_LOOKUP_ELEM_LAST_FIELD value
+#define BPF_MAP_LOOKUP_ELEM_LAST_FIELD size
static int map_lookup_elem(union bpf_attr *attr)
{
void __user *ukey = u64_to_ptr(attr->key);
void __user *uvalue = u64_to_ptr(attr->value);
int ufd = attr->map_fd;
+ u32 usize = attr->size;
struct bpf_map *map;
void *key, *value, *ptr;
u32 value_size;
@@ -324,7 +325,7 @@ static int map_lookup_elem(union bpf_attr *attr)
goto free_value;
err = -EFAULT;
- if (copy_to_user(uvalue, value, value_size) != 0)
+ if (copy_to_user(uvalue, value, min_t(u32, usize, value_size)) != 0)
goto free_value;
err = 0;
diff --git a/samples/bpf/fds_example.c b/samples/bpf/fds_example.c
index 625e797..5b833d8 100644
--- a/samples/bpf/fds_example.c
+++ b/samples/bpf/fds_example.c
@@ -88,7 +88,7 @@ static int bpf_do_map(const char *file, uint32_t flags, uint32_t key,
ret, strerror(errno));
assert(ret == 0);
} else if (flags & BPF_F_KEY) {
- ret = bpf_lookup_elem(fd, &key, &value);
+ ret = bpf_lookup_elem(fd, &key, &value, sizeof(value));
printf("bpf: fd:%d l->(%u):%u ret:(%d,%s)\n", fd, key, value,
ret, strerror(errno));
assert(ret == 0);
diff --git a/samples/bpf/libbpf.c b/samples/bpf/libbpf.c
index 9969e35..9f0a1c3 100644
--- a/samples/bpf/libbpf.c
+++ b/samples/bpf/libbpf.c
@@ -44,12 +44,13 @@ int bpf_update_elem(int fd, void *key, void *value, unsigned long long flags)
return syscall(__NR_bpf, BPF_MAP_UPDATE_ELEM, &attr, sizeof(attr));
}
-int bpf_lookup_elem(int fd, void *key, void *value)
+int bpf_lookup_elem(int fd, void *key, void *value, int size)
{
union bpf_attr attr = {
.map_fd = fd,
.key = ptr_to_u64(key),
.value = ptr_to_u64(value),
+ .size = size,
};
return syscall(__NR_bpf, BPF_MAP_LOOKUP_ELEM, &attr, sizeof(attr));
diff --git a/samples/bpf/libbpf.h b/samples/bpf/libbpf.h
index ac6edb6..b911185 100644
--- a/samples/bpf/libbpf.h
+++ b/samples/bpf/libbpf.h
@@ -7,7 +7,7 @@ struct bpf_insn;
int bpf_create_map(enum bpf_map_type map_type, int key_size, int value_size,
int max_entries, int map_flags);
int bpf_update_elem(int fd, void *key, void *value, unsigned long long flags);
-int bpf_lookup_elem(int fd, void *key, void *value);
+int bpf_lookup_elem(int fd, void *key, void *value, int size);
int bpf_delete_elem(int fd, void *key);
int bpf_get_next_key(int fd, void *key, void *next_key);
diff --git a/samples/bpf/test_maps.c b/samples/bpf/test_maps.c
index cce2b59..a6a8fbe 100644
--- a/samples/bpf/test_maps.c
+++ b/samples/bpf/test_maps.c
@@ -47,11 +47,11 @@ static void test_hashmap_sanity(int i, void *data)
assert(bpf_update_elem(map_fd, &key, &value, -1) == -1 && errno == EINVAL);
/* check that key=1 can be found */
- assert(bpf_lookup_elem(map_fd, &key, &value) == 0 && value == 1234);
+ assert(bpf_lookup_elem(map_fd, &key, &value, sizeof(value)) == 0 && value == 1234);
key = 2;
/* check that key=2 is not found */
- assert(bpf_lookup_elem(map_fd, &key, &value) == -1 && errno == ENOENT);
+ assert(bpf_lookup_elem(map_fd, &key, &value, sizeof(value)) == -1 && errno == ENOENT);
/* BPF_EXIST means: update existing element */
assert(bpf_update_elem(map_fd, &key, &value, BPF_EXIST) == -1 &&
@@ -139,11 +139,11 @@ static void test_percpu_hashmap_sanity(int task, void *data)
* was run from a different cpu.
*/
value[0] = 1;
- assert(bpf_lookup_elem(map_fd, &key, value) == 0 && value[0] == 100);
+ assert(bpf_lookup_elem(map_fd, &key, value, sizeof(value)) == 0 && value[0] == 100);
key = 2;
/* check that key=2 is not found */
- assert(bpf_lookup_elem(map_fd, &key, value) == -1 && errno == ENOENT);
+ assert(bpf_lookup_elem(map_fd, &key, value, sizeof(value)) == -1 && errno == ENOENT);
/* BPF_EXIST means: update existing element */
assert(bpf_update_elem(map_fd, &key, value, BPF_EXIST) == -1 &&
@@ -170,7 +170,7 @@ static void test_percpu_hashmap_sanity(int task, void *data)
assert((expected_key_mask & next_key) == next_key);
expected_key_mask &= ~next_key;
- assert(bpf_lookup_elem(map_fd, &next_key, value) == 0);
+ assert(bpf_lookup_elem(map_fd, &next_key, value, sizeof(value)) == 0);
for (i = 0; i < nr_cpus; i++)
assert(value[i] == i + 100);
@@ -218,11 +218,11 @@ static void test_arraymap_sanity(int i, void *data)
errno == EEXIST);
/* check that key=1 can be found */
- assert(bpf_lookup_elem(map_fd, &key, &value) == 0 && value == 1234);
+ assert(bpf_lookup_elem(map_fd, &key, &value, sizeof(value)) == 0 && value == 1234);
key = 0;
/* check that key=0 is also found and zero initialized */
- assert(bpf_lookup_elem(map_fd, &key, &value) == 0 && value == 0);
+ assert(bpf_lookup_elem(map_fd, &key, &value, sizeof(value)) == 0 && value == 0);
/* key=0 and key=1 were inserted, check that key=2 cannot be inserted
@@ -233,7 +233,7 @@ static void test_arraymap_sanity(int i, void *data)
errno == E2BIG);
/* check that key = 2 doesn't exist */
- assert(bpf_lookup_elem(map_fd, &key, &value) == -1 && errno == ENOENT);
+ assert(bpf_lookup_elem(map_fd, &key, &value, sizeof(value)) == -1 && errno == ENOENT);
/* iterate over two elements */
assert(bpf_get_next_key(map_fd, &key, &next_key) == 0 &&
@@ -274,7 +274,7 @@ static void test_percpu_arraymap_many_keys(void)
for (key = 0; key < nr_keys; key++) {
for (i = 0; i < nr_cpus; i++)
values[i] = 0;
- assert(bpf_lookup_elem(map_fd, &key, values) == 0);
+ assert(bpf_lookup_elem(map_fd, &key, values, sizeof(values)) == 0);
for (i = 0; i < nr_cpus; i++)
assert(values[i] == i + 10);
}
@@ -307,11 +307,11 @@ static void test_percpu_arraymap_sanity(int i, void *data)
errno == EEXIST);
/* check that key=1 can be found */
- assert(bpf_lookup_elem(map_fd, &key, values) == 0 && values[0] == 100);
+ assert(bpf_lookup_elem(map_fd, &key, values, sizeof(values)) == 0 && values[0] == 100);
key = 0;
/* check that key=0 is also found and zero initialized */
- assert(bpf_lookup_elem(map_fd, &key, values) == 0 &&
+ assert(bpf_lookup_elem(map_fd, &key, values, sizeof(values)) == 0 &&
values[0] == 0 && values[nr_cpus - 1] == 0);
@@ -321,7 +321,7 @@ static void test_percpu_arraymap_sanity(int i, void *data)
errno == E2BIG);
/* check that key = 2 doesn't exist */
- assert(bpf_lookup_elem(map_fd, &key, values) == -1 && errno == ENOENT);
+ assert(bpf_lookup_elem(map_fd, &key, values, sizeof(values)) == -1 && errno == ENOENT);
/* iterate over two elements */
assert(bpf_get_next_key(map_fd, &key, &next_key) == 0 &&
@@ -371,9 +371,9 @@ static void test_map_large(void)
assert(bpf_get_next_key(map_fd, &key, &key) == -1 && errno == ENOENT);
key.c = 0;
- assert(bpf_lookup_elem(map_fd, &key, &value) == 0 && value == 0);
+ assert(bpf_lookup_elem(map_fd, &key, &value, sizeof(value)) == 0 && value == 0);
key.a = 1;
- assert(bpf_lookup_elem(map_fd, &key, &value) == -1 && errno == ENOENT);
+ assert(bpf_lookup_elem(map_fd, &key, &value, sizeof(value)) == -1 && errno == ENOENT);
close(map_fd);
}
@@ -466,7 +466,7 @@ static void test_map_parallel(void)
/* another check for all elements */
for (i = 0; i < MAP_SIZE; i++) {
key = MAP_SIZE - i - 1;
- assert(bpf_lookup_elem(map_fd, &key, &value) == 0 &&
+ assert(bpf_lookup_elem(map_fd, &key, &value, sizeof(value)) == 0 &&
value == key);
}
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 9e5fc16..719fa25 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -122,7 +122,10 @@ union bpf_attr {
__aligned_u64 value;
__aligned_u64 next_key;
};
- __u64 flags;
+ union {
+ __u64 flags;
+ __u32 size; /* number of bytes allocated in userspace */
+ };
};
struct { /* anonymous struct used by BPF_PROG_LOAD command */
--
2.5.0
^ permalink raw reply related
* net/l2tp:BUG: KASAN: use-after-free in l2tp_ip6_close
From: Baozeng Ding @ 2016-10-16 15:07 UTC (permalink / raw)
To: netdev
Hello,
While running syzkaller fuzzer I have got the following use-after-free
bug in l2tp_ip6_close. The kernel version is 4.8.0+ (on Oct 7 commit d1f5323370fceaed43a7ee38f4c7bfc7e70f28d0).
BUG: KASAN: use-after-free in l2tp_ip6_close+0x22e/0x290 at addr ffff8800081b0ed8
Write of size 8 by task syz-executor/10987
CPU: 0 PID: 10987 Comm: syz-executor Not tainted 4.8.0+ #39
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
ffff880031d97838 ffffffff829f835b ffff88001b5a1640 ffff8800081b0ec0
ffff8800081b15a0 ffff8800081b6d20 ffff880031d97860 ffffffff8174d3cc
ffff880031d978f0 ffff8800081b0e80 ffff88001b5a1640 ffff880031d978e0
Call Trace:
[<ffffffff829f835b>] dump_stack+0xb3/0x118 lib/dump_stack.c:15
[<ffffffff8174d3cc>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156
[< inline >] print_address_description mm/kasan/report.c:194
[<ffffffff8174d666>] kasan_report_error+0x1f6/0x4d0 mm/kasan/report.c:283
[< inline >] kasan_report mm/kasan/report.c:303
[<ffffffff8174db7e>] __asan_report_store8_noabort+0x3e/0x40 mm/kasan/report.c:329
[< inline >] __write_once_size ./include/linux/compiler.h:249
[< inline >] __hlist_del ./include/linux/list.h:622
[< inline >] hlist_del_init ./include/linux/list.h:637
[<ffffffff8579047e>] l2tp_ip6_close+0x22e/0x290 net/l2tp/l2tp_ip6.c:239
[<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415
[<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
[<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570
[<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017
[<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208
[<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244
[<ffffffff813774f9>] task_work_run+0xf9/0x170
[<ffffffff81324aae>] do_exit+0x85e/0x2a00
[<ffffffff81326dc8>] do_group_exit+0x108/0x330
[<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307
[<ffffffff811b49af>] do_signal+0x7f/0x18f0
[<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156
[< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
[<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259
[<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6
Object at ffff8800081b0ec0, in cache L2TP/IPv6 size: 1448
Allocated:
PID = 10987
[ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20
[ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0
[ 1116.897025] [<ffffffff8174c9ad>] kasan_kmalloc+0xad/0xe0
[ 1116.897025] [<ffffffff8174cee2>] kasan_slab_alloc+0x12/0x20
[ 1116.897025] [< inline >] slab_post_alloc_hook mm/slab.h:417
[ 1116.897025] [< inline >] slab_alloc_node mm/slub.c:2708
[ 1116.897025] [< inline >] slab_alloc mm/slub.c:2716
[ 1116.897025] [<ffffffff817476a8>] kmem_cache_alloc+0xc8/0x2b0 mm/slub.c:2721
[ 1116.897025] [<ffffffff84c4f6a9>] sk_prot_alloc+0x69/0x2b0 net/core/sock.c:1326
[ 1116.897025] [<ffffffff84c58ac8>] sk_alloc+0x38/0xae0 net/core/sock.c:1388
[ 1116.897025] [<ffffffff851ddf67>] inet6_create+0x2d7/0x1000 net/ipv6/af_inet6.c:182
[ 1116.897025] [<ffffffff84c4af7b>] __sock_create+0x37b/0x640 net/socket.c:1153
[ 1116.897025] [< inline >] sock_create net/socket.c:1193
[ 1116.897025] [< inline >] SYSC_socket net/socket.c:1223
[ 1116.897025] [<ffffffff84c4b46f>] SyS_socket+0xef/0x1b0 net/socket.c:1203
[ 1116.897025] [<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6
Freed:
PID = 10987
[ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20
[ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0
[ 1116.897025] [<ffffffff8174cf61>] kasan_slab_free+0x71/0xb0
[ 1116.897025] [< inline >] slab_free_hook mm/slub.c:1352
[ 1116.897025] [< inline >] slab_free_freelist_hook mm/slub.c:1374
[ 1116.897025] [< inline >] slab_free mm/slub.c:2951
[ 1116.897025] [<ffffffff81748b28>] kmem_cache_free+0xc8/0x330 mm/slub.c:2973
[ 1116.897025] [< inline >] sk_prot_free net/core/sock.c:1369
[ 1116.897025] [<ffffffff84c541eb>] __sk_destruct+0x32b/0x4f0 net/core/sock.c:1444
[ 1116.897025] [<ffffffff84c5aca4>] sk_destruct+0x44/0x80 net/core/sock.c:1452
[ 1116.897025] [<ffffffff84c5ad33>] __sk_free+0x53/0x220 net/core/sock.c:1460
[ 1116.897025] [<ffffffff84c5af23>] sk_free+0x23/0x30 net/core/sock.c:1471
[ 1116.897025] [<ffffffff84c5cb6c>] sk_common_release+0x28c/0x3e0 ./include/net/sock.h:1589
[ 1116.897025] [<ffffffff8579044e>] l2tp_ip6_close+0x1fe/0x290 net/l2tp/l2tp_ip6.c:243
[ 1116.897025] [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415
[ 1116.897025] [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
[ 1116.897025] [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570
[ 1116.897025] [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017
[ 1116.897025] [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208
[ 1116.897025] [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244
[ 1116.897025] [<ffffffff813774f9>] task_work_run+0xf9/0x170
[ 1116.897025] [<ffffffff81324aae>] do_exit+0x85e/0x2a00
[ 1116.897025] [<ffffffff81326dc8>] do_group_exit+0x108/0x330
[ 1116.897025] [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307
[ 1116.897025] [<ffffffff811b49af>] do_signal+0x7f/0x18f0
[ 1116.897025] [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156
[ 1116.897025] [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
[ 1116.897025] [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259
[ 1116.897025] [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6
Memory state around the buggy address:
ffff8800081b0d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8800081b0e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff8800081b0e80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff8800081b0f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8800081b0f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Best Regards,
Baozeng Ding
^ permalink raw reply
* Re: [RFC v2 0/2] proc connector: get namespace events
From: Eric W. Biederman @ 2016-10-16 14:57 UTC (permalink / raw)
To: Alban Crequy
Cc: Iago Lopez Galeiras, Aaron Campbell,
netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Jiri Benc,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jesper Derehag, Alban Crequy,
Tejun Heo, Evgeniy Polyakov, Dimitri John Ledkov
In-Reply-To: <1476534370-4027-1-git-send-email-alban-lYLaGTFnO9sWenYVfaLwtA@public.gmane.org>
Alban Crequy <alban.crequy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> This is v2 of the patch set to add namespace events in the proc
> connector.
So while not totally wrong the way you report namespaces makes me
grumpy. You are not including the device node of the filesystem
those inodes are on. The inode number is meaningless if you don't
specify which filesystem the inode is from.
I absolutely do not want to have to implement a namespace for namespaces
someday just because people have been sloppy like this.
So please correct this to at least report the full information on
namespaces.
Thank you,
Eric
^ permalink raw reply
* BUG: KASAN: use-after-free in udp_lib_rehash
From: Baozeng Ding @ 2016-10-16 13:54 UTC (permalink / raw)
To: netdev
Hello all,
While running syzkaller fuzzer I have got the following use-after-free
bug in udp_lib_rehash. The kernel version is 4.8.0+ (on Oct 7 commit d1f5323370fceaed43a7ee38f4c7bfc7e70f28d0). Unfortunately I failed to find a reproducer for it.
BUG: KASAN: use-after-free in udp_lib_rehash+0x634/0x640 at addr ffff88002f3fe1e0
Write of size 8 by task syz-executor/11156
CPU: 3 PID: 11156 Comm: syz-executor Not tainted 4.8.0+ #39
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
ffff88001acb7b58 ffffffff829f835b ffff880034acd900 ffff88002f3fe1c0
ffff88002f3fe8d0 ffffc90000230810 ffff88001acb7b80 ffffffff8174d3cc
ffff88001acb7c10 ffff88002f3fe180 ffff880034acd900 ffff88001acb7c00
Call Trace:
[<ffffffff829f835b>] dump_stack+0xb3/0x118 lib/dump_stack.c:15
[<ffffffff8174d3cc>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156
[< inline >] print_address_description mm/kasan/report.c:194
[<ffffffff8174d666>] kasan_report_error+0x1f6/0x4d0 mm/kasan/report.c:283
[< inline >] kasan_report mm/kasan/report.c:303
[<ffffffff8174db7e>] __asan_report_store8_noabort+0x3e/0x40 mm/kasan/report.c:329
[< inline >] hlist_add_head_rcu ./include/linux/rculist.h:487
[<ffffffff85083384>] udp_lib_rehash+0x634/0x640 net/ipv4/udp.c:1429
[<ffffffff8525d502>] udp_v6_rehash+0x72/0xa0 net/ipv6/udp.c:115
[<ffffffff852a69d6>] ip6_datagram_connect+0x786/0xc40
[<ffffffff850b3162>] inet_dgram_connect+0x112/0x1f0 net/ipv4/af_inet.c:530
[<ffffffff84c4959e>] SYSC_connect+0x23e/0x2e0 net/socket.c:1533
[<ffffffff84c4bd14>] SyS_connect+0x24/0x30 net/socket.c:1514
[<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6
Object at ffff88002f3fe1c0, in cache UDPv6 size: 1496
Allocated:
PID = 11149
[ 1921.980207] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20
[ 1921.980207] [<ffffffff8174c736>] save_stack+0x46/0xd0
[ 1921.980207] [<ffffffff8174c9ad>] kasan_kmalloc+0xad/0xe0
[ 1921.980207] [<ffffffff8174cee2>] kasan_slab_alloc+0x12/0x20
[ 1921.980207] [< inline >] slab_post_alloc_hook mm/slab.h:417
[ 1921.980207] [< inline >] slab_alloc_node mm/slub.c:2708
[ 1921.980207] [< inline >] slab_alloc mm/slub.c:2716
[ 1921.980207] [<ffffffff817476a8>] kmem_cache_alloc+0xc8/0x2b0 mm/slub.c:2721
[ 1921.980207] [<ffffffff84c4f6a9>] sk_prot_alloc+0x69/0x2b0 net/core/sock.c:1326
[ 1921.980207] [<ffffffff84c58ac8>] sk_alloc+0x38/0xae0 net/core/sock.c:1388
[ 1921.980207] [<ffffffff851ddf67>] inet6_create+0x2d7/0x1000 net/ipv6/af_inet6.c:182
[ 1921.980207] [<ffffffff84c4af7b>] __sock_create+0x37b/0x640 net/socket.c:1153
[ 1921.980207] [< inline >] sock_create net/socket.c:1193
[ 1921.980207] [< inline >] SYSC_socket net/socket.c:1223
[ 1921.980207] [<ffffffff84c4b46f>] SyS_socket+0xef/0x1b0 net/socket.c:1203
[ 1921.980207] [<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6
Freed:
PID = 11157
[ 1921.980207] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20
[ 1921.980207] [<ffffffff8174c736>] save_stack+0x46/0xd0
[ 1921.980207] [<ffffffff8174cf61>] kasan_slab_free+0x71/0xb0
[ 1921.980207] [< inline >] slab_free_hook mm/slub.c:1352
[ 1921.980207] [< inline >] slab_free_freelist_hook mm/slub.c:1374
[ 1921.980207] [< inline >] slab_free mm/slub.c:2951
[ 1921.980207] [<ffffffff81748b28>] kmem_cache_free+0xc8/0x330 mm/slub.c:2973
[ 1921.980207] [< inline >] sk_prot_free net/core/sock.c:1369
[ 1921.980207] [<ffffffff84c541eb>] __sk_destruct+0x32b/0x4f0 net/core/sock.c:1444
[ 1921.980207] [<ffffffff84c5aca4>] sk_destruct+0x44/0x80 net/core/sock.c:1452
[ 1921.980207] [<ffffffff84c5ad33>] __sk_free+0x53/0x220 net/core/sock.c:1460
[ 1921.980207] [<ffffffff84c5af23>] sk_free+0x23/0x30 net/core/sock.c:1471
[ 1921.980207] [<ffffffff84c5cb6c>] sk_common_release+0x28c/0x3e0 ./include/net/sock.h:1589
[ 1921.980207] [<ffffffff852569e5>] udp_lib_close+0x15/0x20 ./include/net/udp.h:203
[ 1921.980207] [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415
[ 1921.980207] [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
[ 1921.980207] [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570
[ 1921.980207] [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017
[ 1921.980207] [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208
[ 1921.980207] [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244
[ 1921.980207] [<ffffffff813774f9>] task_work_run+0xf9/0x170
[ 1921.980207] [<ffffffff81324aae>] do_exit+0x85e/0x2a00
[ 1921.980207] [<ffffffff81326dc8>] do_group_exit+0x108/0x330
[ 1921.980207] [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307
[ 1921.980207] [<ffffffff811b49af>] do_signal+0x7f/0x18f0
[ 1921.980207] [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156
[ 1921.980207] [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
[ 1921.980207] [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259
[ 1921.980207] [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6
Memory state around the buggy address:
ffff88002f3fe080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88002f3fe100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88002f3fe180: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff88002f3fe200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88002f3fe280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
Thansk && Best Regards,
Baozeng Ding
^ permalink raw reply
* BUG: KASAN: use-after-free in udp_lib_get_port
From: Baozeng Ding @ 2016-10-16 13:46 UTC (permalink / raw)
To: network dev
Hello all,
While running syzkaller fuzzer I have got the following use-after-free
bug in udp_lib_get_port. The kernel version is 4.8.0+ (on Oct 7 commit d1f5323370fceaed43a7ee38f4c7bfc7e70f28d0). Unfortunately I failed to find a reproducer for it.
BUG: KASAN: use-after-free in udp_lib_get_port+0x1573/0x1860 at addr ffff88000804cb60
Write of size 8 by task syz-executor/31190
CPU: 0 PID: 31190 Comm: syz-executor Not tainted 4.8.0+ #39
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
ffff880015ac7a48 ffffffff829f835b ffff880032b531c0 ffff88000804cb40
ffff88000804d250 ffff880017415a4a ffff880015ac7a70 ffffffff8174d3cc
ffff880015ac7b00 ffff88000804cb00 ffff880032b531c0 ffff880015ac7af0
Call Trace:
[<ffffffff829f835b>] dump_stack+0xb3/0x118 lib/dump_stack.c:15
[<ffffffff8174d3cc>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156
[< inline >] print_address_description mm/kasan/report.c:194
[<ffffffff8174d666>] kasan_report_error+0x1f6/0x4d0 mm/kasan/report.c:283
[< inline >] kasan_report mm/kasan/report.c:303
[<ffffffff8174db7e>] __asan_report_store8_noabort+0x3e/0x40 mm/kasan/report.c:329
[< inline >] hlist_add_head_rcu ./include/linux/rculist.h:487
[<ffffffff850866e3>] udp_lib_get_port+0x1573/0x1860 net/ipv4/udp.c:345
[<ffffffff8525cc27>] udp_v6_get_port+0xa7/0xd0 net/ipv6/udp.c:106
[<ffffffff851df52c>] inet6_bind+0x89c/0xfb0 net/ipv6/af_inet6.c:384
[<ffffffff84c492fa>] SYSC_bind+0x1ea/0x250 net/socket.c:1367
[<ffffffff84c4ba34>] SyS_bind+0x24/0x30 net/socket.c:1353
[<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6
Object at ffff88000804cb40, in cache UDPv6 size: 1496
Allocated:
PID = 30789
[ 378.305168] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20
[ 378.305168] [<ffffffff8174c736>] save_stack+0x46/0xd0
[ 378.305168] [<ffffffff8174c9ad>] kasan_kmalloc+0xad/0xe0
[ 378.305168] [<ffffffff8174cee2>] kasan_slab_alloc+0x12/0x20
[ 378.305168] [< inline >] slab_post_alloc_hook mm/slab.h:417
[ 378.305168] [< inline >] slab_alloc_node mm/slub.c:2708
[ 378.305168] [< inline >] slab_alloc mm/slub.c:2716
[ 378.305168] [<ffffffff817476a8>] kmem_cache_alloc+0xc8/0x2b0 mm/slub.c:2721
[ 378.305168] [<ffffffff84c4f6a9>] sk_prot_alloc+0x69/0x2b0 net/core/sock.c:1326
[ 378.305168] [<ffffffff84c58ac8>] sk_alloc+0x38/0xae0 net/core/sock.c:1388
[ 378.305168] [<ffffffff851ddf67>] inet6_create+0x2d7/0x1000 net/ipv6/af_inet6.c:182
[ 378.305168] [<ffffffff84c4af7b>] __sock_create+0x37b/0x640 net/socket.c:1153
[ 378.305168] [< inline >] sock_create net/socket.c:1193
[ 378.305168] [< inline >] SYSC_socket net/socket.c:1223
[ 378.305168] [<ffffffff84c4b46f>] SyS_socket+0xef/0x1b0 net/socket.c:1203
[ 378.305168] [<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6
Freed:
PID = 30789
[ 378.305168] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20
[ 378.305168] [<ffffffff8174c736>] save_stack+0x46/0xd0
[ 378.305168] [<ffffffff8174cf61>] kasan_slab_free+0x71/0xb0
[ 378.305168] [< inline >] slab_free_hook mm/slub.c:1352
[ 378.305168] [< inline >] slab_free_freelist_hook mm/slub.c:1374
[ 378.305168] [< inline >] slab_free mm/slub.c:2951
[ 378.305168] [<ffffffff81748b28>] kmem_cache_free+0xc8/0x330 mm/slub.c:2973
[ 378.305168] [< inline >] sk_prot_free net/core/sock.c:1369
[ 378.305168] [<ffffffff84c541eb>] __sk_destruct+0x32b/0x4f0 net/core/sock.c:1444
[ 378.305168] [<ffffffff84c5aca4>] sk_destruct+0x44/0x80 net/core/sock.c:1452
[ 378.305168] [<ffffffff84c5ad33>] __sk_free+0x53/0x220 net/core/sock.c:1460
[ 378.305168] [<ffffffff84c5af23>] sk_free+0x23/0x30 net/core/sock.c:1471
[ 378.305168] [<ffffffff84c5cb6c>] sk_common_release+0x28c/0x3e0 ./include/net/sock.h:1589
[ 378.305168] [<ffffffff852569e5>] udp_lib_close+0x15/0x20 ./include/net/udp.h:203
[ 378.305168] [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415
[ 378.305168] [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
[ 378.305168] [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570
[ 378.305168] [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017
[ 378.305168] [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208
[ 378.305168] [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244
[ 378.305168] [<ffffffff813774f9>] task_work_run+0xf9/0x170
[ 378.305168] [<ffffffff81324aae>] do_exit+0x85e/0x2a00
[ 378.305168] [<ffffffff81326dc8>] do_group_exit+0x108/0x330
[ 378.376437] [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307
[ 378.376437] [<ffffffff811b49af>] do_signal+0x7f/0x18f0
[ 378.376437] [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156
[ 378.376437] [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
[ 378.376437] [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259
[ 378.376437] [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6
Memory state around the buggy address:
ffff88000804ca00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88000804ca80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88000804cb00: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff88000804cb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88000804cc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Thanks && Best Regards,
Baozeng Ding
^ permalink raw reply
* net/ipv6: potential deadlock in do_ipv6_setsockopt
From: Baozeng Ding @ 2016-10-16 13:34 UTC (permalink / raw)
To: netdev
Hello,
While running syzkaller fuzzer I have got the following deadlock
report. The kernel version is 4.8.0+ (on Oct 7 commit d1f5323370fceaed43a7ee38f4c7bfc7e70f28d0). Unfortunately I failed to find a reproducer for it.
===============================================================================
[ INFO: possible circular locking dependency detected ]
4.8.0+ #39 Not tainted
-------------------------------------------------------
syz-executor/21301 is trying to acquire lock:
([ 165.136033] rtnl_mutex
[<ffffffff84ce81d7>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
but task is already holding lock:
([ 165.136033] sk_lock-AF_INET6
[<ffffffff85245db1>] do_ipv6_setsockopt.isra.7+0x1f1/0x2960
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
:
[ 165.136033] [<ffffffff81427398>] lock_acquire+0x1a8/0x380 kernel/locking/lockdep.c:3746
[ 165.136033] [<ffffffff84c54c0b>] lock_sock_nested+0xcb/0x120 net/core/sock.c:2493
[ 165.136033] [<ffffffff85245e28>] do_ipv6_setsockopt.isra.7+0x268/0x2960
[ 165.136033] [<ffffffff852485bb>] ipv6_setsockopt+0x9b/0x140
[ 165.136033] [<ffffffff8525a6c5>] udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1344
[ 165.136033] [<ffffffff84c4ed85>] sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2688
[ 165.136033] [< inline >] SYSC_setsockopt net/socket.c:1742
[ 165.136033] [<ffffffff84c4bff8>] SyS_setsockopt+0x158/0x240 net/socket.c:1721
[ 165.136033] [<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6
:
[ 165.136033] [< inline >] check_prev_add kernel/locking/lockdep.c:1829
[ 165.136033] [< inline >] check_prevs_add kernel/locking/lockdep.c:1939
[ 165.136033] [< inline >] validate_chain kernel/locking/lockdep.c:2266
[ 165.136033] [<ffffffff81424d19>] __lock_acquire+0x35a9/0x4bc0 kernel/locking/lockdep.c:3335
[ 165.136033] [<ffffffff81427398>] lock_acquire+0x1a8/0x380 kernel/locking/lockdep.c:3746
[ 165.136033] [< inline >] __mutex_lock_common kernel/locking/mutex.c:521
[ 165.136033] [<ffffffff85e44721>] mutex_lock_nested+0xb1/0x860 kernel/locking/mutex.c:621
[ 165.136033] [<ffffffff84ce81d7>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
[ 165.136033] [<ffffffff8528116e>] ipv6_sock_mc_close+0xfe/0x350 net/ipv6/mcast.c:288
[ 165.136033] [<ffffffff85247ebc>] do_ipv6_setsockopt.isra.7+0x22fc/0x2960
[ 165.136033] [<ffffffff852485bb>] ipv6_setsockopt+0x9b/0x140
[ 165.136033] [<ffffffff8525a6c5>] udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1344
[ 165.136033] [<ffffffff84c4ed85>] sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2688
[ 165.136033] [< inline >] SYSC_setsockopt net/socket.c:1742
[ 165.136033] [<ffffffff84c4bff8>] SyS_setsockopt+0x158/0x240 net/socket.c:1721
[ 165.136033] [<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock([ 165.136033] sk_lock-AF_INET6
);
lock([ 165.136033] rtnl_mutex
);
lock([ 165.136033] sk_lock-AF_INET6
);
lock([ 165.136033] rtnl_mutex
);
*** DEADLOCK ***
1 lock held by syz-executor/21301:
#0: [ 165.136033] (
stack backtrace:
CPU: 1 PID: 21301 Comm: syz-executor Not tainted 4.8.0+ #39
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
ffff880017217580 ffffffff829f835b ffffffff88d65790 ffffffff88d65790
ffffffff88dc6b70 ffff880016f41fd8 ffff8800172175d0 ffffffff8141df18
ffff880016f41ffa dffffc0000000000 000000008764c180 ffff880016f41fd8
Call Trace:
[<ffffffff829f835b>] dump_stack+0xb3/0x118 lib/dump_stack.c:15
[<ffffffff8141df18>] print_circular_bug+0x288/0x340 kernel/locking/lockdep.c:1202
[< inline >] check_prev_add kernel/locking/lockdep.c:1829
[< inline >] check_prevs_add kernel/locking/lockdep.c:1939
[< inline >] validate_chain kernel/locking/lockdep.c:2266
[<ffffffff81424d19>] __lock_acquire+0x35a9/0x4bc0 kernel/locking/lockdep.c:3335
[<ffffffff81427398>] lock_acquire+0x1a8/0x380 kernel/locking/lockdep.c:3746
[< inline >] __mutex_lock_common kernel/locking/mutex.c:521
[<ffffffff85e44721>] mutex_lock_nested+0xb1/0x860 kernel/locking/mutex.c:621
[<ffffffff84ce81d7>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
[<ffffffff8528116e>] ipv6_sock_mc_close+0xfe/0x350 net/ipv6/mcast.c:288
[<ffffffff85247ebc>] do_ipv6_setsockopt.isra.7+0x22fc/0x2960
[<ffffffff852485bb>] ipv6_setsockopt+0x9b/0x140
[<ffffffff8525a6c5>] udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1344
[<ffffffff84c4ed85>] sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2688
[< inline >] SYSC_setsockopt net/socket.c:1742
[<ffffffff84c4bff8>] SyS_setsockopt+0x158/0x240 net/socket.c:1721
[<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6
Thanks && Best Regards,
Baozeng Ding
^ permalink raw reply
* Re: [patch net-next RFC 4/6] Introduce sample tc action
From: Or Gerlitz @ 2016-10-16 10:27 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linux Netdev List, David Miller, Yotam Gigi, Ido Schimmel,
Elad Raz, Nogah Frankel, Or Gerlitz, Jamal Hadi Salim,
geert+renesas, Stephen Hemminger, Cong Wang, Guenter Roeck
In-Reply-To: <1476276069-5315-5-git-send-email-jiri@resnulli.us>
On Wed, Oct 12, 2016 at 3:41 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> From: Yotam Gigi <yotam.gi@gmail.com>
>
> This action allow the user to sample traffic matched by tc classifier.
> The sampling consists of choosing packets randomly, truncating them,
> adding some informative metadata regarding the interface and the original
> packet size and mark them with specific mark, to allow further tc rules to
> match and process. The marked sample packets are then injected into the
> device ingress qdisc using netif_receive_skb.
>
> The packets metadata is packed using the ife encapsulation protocol, and
> the outer packet's ethernet dest, source and eth_type, along with the
> rate, mark and the optional truncation size can be configured from
> userspace.
>
> Example:
> To sample ingress traffic from interface eth1, and redirect the sampled
> the sampled packets to interface dummy0, one may use the commands:
>
> tc qdisc add dev eth1 handle ffff: ingress
>
> tc filter add dev eth1 parent ffff: \
> matchall action sample rate 12 mark 17
>
> tc filter add parent ffff: dev eth1 protocol all \
> u32 match mark 172 0xff
> action mirred egress redirect dev dummy0
>
> Where the first command adds an ingress qdisc and the second starts
> sampling every 12'th packet on dev eth0 and marks the sampled packets with
> 17. The command third catches the sampled packets, which are marked with
> 17, and redirects them to dev dummy0.
eth0 --> eth1
command third --> third command
don't we need a re-classify directive for the u32 filter to apply
after the marking done by the matchall rule + sample action
or is that implicit?
> diff --git a/include/net/tc_act/tc_sample.h b/include/net/tc_act/tc_sample.h
> new file mode 100644
> index 0000000..a2b445a
> --- /dev/null
> +++ b/include/net/tc_act/tc_sample.h
> @@ -0,0 +1,88 @@
> +#ifndef __NET_TC_SAMPLE_H
> +#define __NET_TC_SAMPLE_H
> +
> +#include <net/act_api.h>
> +#include <linux/tc_act/tc_sample.h>
> +
> +struct tcf_sample {
> + struct tc_action common;
> + u32 rate;
> + u32 mark;
> + bool truncate;
> + u32 trunc_size;
> + u32 packet_counter;
> + u8 eth_dst[ETH_ALEN];
> + u8 eth_src[ETH_ALEN];
> + u16 eth_type;
> + bool eth_type_set;
> + struct list_head tcfm_list;
> +};
> +++ b/include/uapi/linux/tc_act/tc_sample.h
> @@ -0,0 +1,31 @@
> +#ifndef __LINUX_TC_SAMPLE_H
> +#define __LINUX_TC_SAMPLE_H
> +
> +#include <linux/types.h>
> +#include <linux/pkt_cls.h>
> +#include <linux/if_ether.h>
> +
> +#define TCA_ACT_SAMPLE 26
> +
> +struct tc_sample {
> + tc_gen;
> + __u32 rate; /* sample rate */
> + __u32 mark; /* mark to put on the sampled packets */
> + bool truncate; /* whether to truncate the packets */
> + __u32 trunc_size; /* truncation size */
> + __u8 eth_dst[ETH_ALEN]; /* encapsulated mac destination */
> + __u8 eth_src[ETH_ALEN]; /* encapsulated mac source */
> + bool eth_type_set; /* whether to overrid ethtype */
> + __u16 eth_type; /* encapsulated mac ethtype */
> +};
overrid --> override
what do you mean by override here, to encapsulate?
consider using 0 as special value, e.g no truncation and no encapsulation
best if you just define the netlink attributes (document on the RHS
the type, see the uapi
for the new tunnel key action) and let the tc action in-kernel code to
decode them directly
into the non UAPI structure. This way you are extendable and also
avoid having two
structs which is sort of confusing.
> +
> +enum {
> + TCA_SAMPLE_UNSPEC,
> + TCA_SAMPLE_TM,
> + TCA_SAMPLE_PARMS,
> + TCA_SAMPLE_PAD,
> + __TCA_SAMPLE_MAX
> +};
> +#define TCA_SAMPLE_MAX (__TCA_SAMPLE_MAX - 1)
> +
> +#endif
> +static bool dev_ok_push(struct net_device *dev)
> +{
> + switch (dev->type) {
> + case ARPHRD_TUNNEL:
> + case ARPHRD_TUNNEL6:
> + case ARPHRD_SIT:
> + case ARPHRD_IPGRE:
> + case ARPHRD_VOID:
> + case ARPHRD_NONE:
> + return false;
> + default:
> + return true;
> + }
> +}
> +
> +static int tcf_sample(struct sk_buff *skb, const struct tc_action *a,
> + struct tcf_result *res)
> +{
> + struct tcf_sample *s = to_sample(a);
> + struct sample_packet_metadata metadata;
> + static struct ethhdr *ethhdr;
> + struct sk_buff *skb2;
> + int retval;
> + u32 at;
> +
> + tcf_lastuse_update(&s->tcf_tm);
> + bstats_cpu_update(this_cpu_ptr(s->common.cpu_bstats), skb);
> +
> + rcu_read_lock();
> + retval = READ_ONCE(s->tcf_action);
> +
> + if (++s->packet_counter % s->rate == 0) {
> + skb2 = skb_copy(skb, GFP_ATOMIC);
> + if (!skb2)
> + goto out;
> +
> + if (s->truncate)
> + skb_trim(skb2, s->trunc_size);
> +
> + at = G_TC_AT(skb->tc_verd);
> + skb2->mac_len = skb->mac_len;
> +
> + /* on ingress, the mac header gets poped, so push it back */
> + if (!(at & AT_EGRESS) && dev_ok_push(skb->dev))
> + skb_push(skb2, skb2->mac_len);
> +
what's the exact role of the !(at & AT_EGRESS) check?
and if !dev_ok_push(.) - are we just fine to continue here without
that push? maybe
worth documenting that corner a bit
> + metadata.ifindex = skb->dev->ifindex;
> + metadata.orig_size = skb->len + skb->dev->hard_header_len;
> + metadata.sample_size = skb2->len;
> + ethhdr = sample_packet_pack(skb2, (void *)&metadata);
> + if (!ethhdr)
> + goto out;
> +
> + if (!is_zero_ether_addr(s->eth_src))
> + ether_addr_copy(ethhdr->h_source, s->eth_src);
> + if (!is_zero_ether_addr(s->eth_dst))
> + ether_addr_copy(ethhdr->h_dest, s->eth_dst);
> + if (s->eth_type_set)
> + ethhdr->h_proto = htons(s->eth_type);
> +
> + skb2->mark = s->mark;
> + netif_receive_skb(skb2);
> +
> + /* mirror is always swallowed */
> + skb2->tc_verd = SET_TC_FROM(skb2->tc_verd, at);
> + }
> +out:
> + rcu_read_unlock();
> +
> + return retval;
> +}
^ permalink raw reply
* Re: [PATCH v2 1/3] net: smc91x: isolate u16 writes alignment workaround
From: Robert Jarzmik @ 2016-10-16 10:05 UTC (permalink / raw)
To: robert.jarzmik
Cc: David S. Miller, Rob Herring, Mark Rutland, Nicolas Pitre,
Russell King - ARM Linux, Arnd Bergmann, netdev, devicetree,
linux-kernel
In-Reply-To: <1476559670-25056-2-git-send-email-robert.jarzmik@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> diff --git a/drivers/net/ethernet/smsc/smc91x.h b/drivers/net/ethernet/smsc/smc91x.h
> index ea8465467469..dff165ed106d 100644
> --- a/drivers/net/ethernet/smsc/smc91x.h
> +++ b/drivers/net/ethernet/smsc/smc91x.h
And there is also the specific case of ARCH=MN10300, where I didn't see :
#include <unit/smc91111.h>
In which SMC_outw() is also defined ... sic.
So this is also to be fixed, thanks to kbuild test robot.
--
Robert
^ permalink raw reply
* Re: [PATCH v3] net: Require exact match for TCP socket lookups if dif is l3mdev
From: David Miller @ 2016-10-15 23:32 UTC (permalink / raw)
To: dsa; +Cc: netdev, eric.dumazet
In-Reply-To: <48ba7600-0624-9684-e609-b7a315e03483@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Sat, 15 Oct 2016 17:07:53 -0600
> I believe at netconf someone mentioned it would be a great day when
> something is done for IPv6 first and IPv4 was a follow on. Here you
> go. :-)
:-)
> I can rename the existing one to skb_l3mdev_slave_6 and make the new
> one skb_l3mdev_slave_4.
That works. So does names with "ipv4_" and "ipv6_" prefixes which at
least to me seems more canonical. But maybe I'm just weird like that.
^ permalink raw reply
* Re: [PATCH 0/2] net: Fix compiler warnings
From: tndave @ 2016-10-15 23:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, chris.hyser, linux-kernel
In-Reply-To: <20161015.174850.1523283727470633263.davem@davemloft.net>
On 10/15/2016 02:48 PM, David Miller wrote:
> From: Tushar Dave <tushar.n.dave@oracle.com>
> Date: Fri, 14 Oct 2016 17:06:04 -0700
>
>> Recently, ATU (iommu) changes are submitted to linux-sparc that
>> enables 64bit DMA on SPARC. However, this change also makes
>> 'incompatible pointer type' compiler warnings inevitable on sunqe
>> and sunbmac driver.
>>
>> The two patches in series fix compiler warnings.
>
> Only the sparc tree has this build problem, so these patches
> really ought to be submitted for and applied there.
Okay. I will send these to sparclinux then.
Thanks.
-Tushar
>
> Thanks.
>
^ permalink raw reply
* Re: [PATCH v3] net: Require exact match for TCP socket lookups if dif is l3mdev
From: David Ahern @ 2016-10-15 23:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, eric.dumazet
In-Reply-To: <20161015.174654.72392403309705041.davem@davemloft.net>
On 10/15/16 3:46 PM, David Miller wrote:
> From: David Ahern <dsa@cumulusnetworks.com>
> Date: Fri, 14 Oct 2016 12:29:19 -0700
>
>> +/* can not be used in TCP layer after tcp_v6_fill_cb */
>> +static inline bool inet6_exact_dif_match(struct net *net, struct sk_buff *skb)
>> +{
>> +#if defined(CONFIG_NET_L3_MASTER_DEV)
>> + if (!net->ipv4.sysctl_tcp_l3mdev_accept &&
>> + skb_l3mdev_slave(IP6CB(skb)->flags))
>> + return true;
>> +#endif
>> + return false;
>> +}
> ...
>> +static inline bool skb_l3mdev_slave4(u16 flags)
>> +{
>> + return !!(flags & IPSKB_L3SLAVE);
>> +}
>
> I think this makes the code confusing.
>
> Actually it has been from the beginning, because we have a generically
> named "skb_l3mdev_slave()" helper which strictly operates on ipv6
> state.
>
> Please do something with the naming of these two helpers,
> skb_l3mdev_slave() and skb_l3mdev_slave4(), so that it is clear that
> they are ipv6 and ipv4 specific helpers, respectively.
>
I believe at netconf someone mentioned it would be a great day when something is done for IPv6 first and IPv4 was a follow on. Here you go. :-)
I can rename the existing one to skb_l3mdev_slave_6 and make the new one skb_l3mdev_slave_4.
^ permalink raw reply
* Re: [PATCH] ipvlan: constify l3mdev_ops structure
From: David Miller @ 2016-10-15 21:50 UTC (permalink / raw)
To: Julia.Lawall; +Cc: netdev, kernel-janitors, linux-kernel
In-Reply-To: <1476546030-14324-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Sat, 15 Oct 2016 17:40:30 +0200
> This l3mdev_ops structure is only stored in the l3mdev_ops field of a
> net_device structure. This field is declared const, so the l3mdev_ops
> structure can be declared as const also. Additionally drop the
> __read_mostly annotation.
>
> The semantic patch that adds const is as follows:
> (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/2] net: Fix compiler warnings
From: David Miller @ 2016-10-15 21:48 UTC (permalink / raw)
To: tushar.n.dave; +Cc: netdev, chris.hyser, linux-kernel
In-Reply-To: <1476489966-9128-1-git-send-email-tushar.n.dave@oracle.com>
From: Tushar Dave <tushar.n.dave@oracle.com>
Date: Fri, 14 Oct 2016 17:06:04 -0700
> Recently, ATU (iommu) changes are submitted to linux-sparc that
> enables 64bit DMA on SPARC. However, this change also makes
> 'incompatible pointer type' compiler warnings inevitable on sunqe
> and sunbmac driver.
>
> The two patches in series fix compiler warnings.
Only the sparc tree has this build problem, so these patches
really ought to be submitted for and applied there.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] vmxnet3: avoid assumption about invalid dma_pa in vmxnet3_set_mc()
From: David Miller @ 2016-10-15 21:48 UTC (permalink / raw)
To: khoroshilov; +Cc: skhare, pv-drivers, netdev, linux-kernel, ldv-project
In-Reply-To: <1476478880-22607-1-git-send-email-khoroshilov@ispras.ru>
From: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date: Sat, 15 Oct 2016 00:01:20 +0300
> vmxnet3_set_mc() checks new_table_pa returned by dma_map_single()
> with dma_mapping_error(), but even there it assumes zero is invalid pa
> (it assumes dma_mapping_error(...,0) returns true if new_table is NULL).
>
> The patch adds an explicit variable to track status of new_table_pa.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> v2: use "bool" and "true"/"false" for boolean variables.
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Applied.
^ permalink raw reply
* Re: [PATCH v3] net: Require exact match for TCP socket lookups if dif is l3mdev
From: David Miller @ 2016-10-15 21:46 UTC (permalink / raw)
To: dsa; +Cc: netdev, eric.dumazet
In-Reply-To: <1476473359-15422-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Fri, 14 Oct 2016 12:29:19 -0700
> +/* can not be used in TCP layer after tcp_v6_fill_cb */
> +static inline bool inet6_exact_dif_match(struct net *net, struct sk_buff *skb)
> +{
> +#if defined(CONFIG_NET_L3_MASTER_DEV)
> + if (!net->ipv4.sysctl_tcp_l3mdev_accept &&
> + skb_l3mdev_slave(IP6CB(skb)->flags))
> + return true;
> +#endif
> + return false;
> +}
...
> +static inline bool skb_l3mdev_slave4(u16 flags)
> +{
> + return !!(flags & IPSKB_L3SLAVE);
> +}
I think this makes the code confusing.
Actually it has been from the beginning, because we have a generically
named "skb_l3mdev_slave()" helper which strictly operates on ipv6
state.
Please do something with the naming of these two helpers,
skb_l3mdev_slave() and skb_l3mdev_slave4(), so that it is clear that
they are ipv6 and ipv4 specific helpers, respectively.
^ permalink raw reply
* Re: [patch] stmmac: fix an error code in stmmac_ptp_register()
From: David Miller @ 2016-10-15 21:35 UTC (permalink / raw)
To: dan.carpenter; +Cc: peppe.cavallaro, alexandre.torgue, netdev, kernel-janitors
In-Reply-To: <20161014192417.GC21917@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Fri, 14 Oct 2016 22:26:11 +0300
> PTR_ERR(NULL) is success. We have to preserve the error code earlier.
>
> Fixes: 7086605a6ab5 ("stmmac: fix error check when init ptp")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Good catch, applied.
^ permalink raw reply
* Re: [PATCH] net: qcom/emac: disable interrupts before calling phy_disconnect
From: David Miller @ 2016-10-15 21:35 UTC (permalink / raw)
To: timur; +Cc: netdev
In-Reply-To: <1476472475-12104-1-git-send-email-timur@codeaurora.org>
From: Timur Tabi <timur@codeaurora.org>
Date: Fri, 14 Oct 2016 14:14:35 -0500
> There is a race condition that can occur if EMAC interrupts are
> enabled when phy_disconnect() is called. phy_disconnect() sets
> adjust_link to NULL. When an interrupt occurs, the ISR might
> call phy_mac_interrupt(), which wakes up the workqueue function
> phy_state_machine(). This function might reference adjust_link,
> thereby causing a null pointer exception.
>
> Signed-off-by: Timur Tabi <timur@codeaurora.org>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/2] ila: Cache a route in ILA lwt structure
From: David Miller @ 2016-10-15 21:34 UTC (permalink / raw)
To: tom; +Cc: netdev, roopa, kernel-team
In-Reply-To: <20161014182537.1713757-1-tom@herbertland.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 14 Oct 2016 11:25:35 -0700
> Add a dst_cache to ila_lwt structure. This holds a cached route for the
> translated address. In ila_output we now perform a route lookup after
> translation and if possible (destination in original route is full 128
> bits) we set the dst_cache. Subsequent calls to ila_output can then use
> the cache to avoid the route lookup.
...
Series applied, thanks Tom.
^ permalink raw reply
* [PATCH RFC] ixgbe: ixgbe_atr() must check if network header is available in headlen
From: Sowmini Varadhan @ 2016-10-15 21:31 UTC (permalink / raw)
To: alexander.h.duyck, netdev; +Cc: sowmini.varadhan
For some Tx paths (e.g., tpacket_snd()), ixgbe_atr may be
passed down an sk_buff that has the network and transport
header in the paged data, so it needs to make sure these
headers are available in the headlen bytes to calculate the
l4_proto.
This patch bails out if the headlen is "too short", and does
not attempt to call skb_header_pointer() to get the needed
bytes: the assumption is that the caller should set things
up properly if the l4_proto based tx steering is desired.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index a244d9a..0868de1 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7632,6 +7632,7 @@ static void ixgbe_atr(struct ixgbe_ring *ring,
struct sk_buff *skb;
__be16 vlan_id;
int l4_proto;
+ int min_hdr_size = 0;
/* if ring doesn't have a interrupt vector, cannot perform ATR */
if (!q_vector)
@@ -7650,6 +7651,14 @@ static void ixgbe_atr(struct ixgbe_ring *ring,
/* snag network header to get L4 type and address */
skb = first->skb;
+ if (first->protocol == htons(ETH_P_IP))
+ min_hdr_size = sizeof(struct iphdr) +
+ sizeof(struct tcphdr);
+ else if (first->protocol == htons(ETH_P_IPV6))
+ min_hdr_size = sizeof(struct ipv6hdr) +
+ sizeof(struct tcphdr);
+ if (min_hdr_size && skb_headlen(skb) < ETH_HLEN + min_hdr_size)
+ return;
hdr.network = skb_network_header(skb);
if (skb->encapsulation &&
first->protocol == htons(ETH_P_IP) &&
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v2] r8169: set coherent DMA mask as well as streaming DMA mask
From: David Miller @ 2016-10-15 21:31 UTC (permalink / raw)
To: ard.biesheuvel; +Cc: David.Laight, romieu, nic_swsd, netdev, linux-kernel
In-Reply-To: <EEC99DAD-50A1-4E45-8707-E5A4E6851D22@linaro.org>
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Fri, 14 Oct 2016 14:48:51 +0100
>
>> On 14 Oct 2016, at 14:42, David Laight <David.Laight@ACULAB.COM> wrote:
>>
>> From: Of Ard Biesheuvel
>>> Sent: 14 October 2016 14:41
>>> PCI devices that are 64-bit DMA capable should set the coherent
>>> DMA mask as well as the streaming DMA mask. On some architectures,
>>> these are managed separately, and so the coherent DMA mask will be
>>> left at its default value of 32 if it is not set explicitly. This
>>> results in errors such as
>>>
>>> r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
>>> hwdev DMA mask = 0x00000000ffffffff, dev_addr = 0x00000080fbfff000
>>> swiotlb: coherent allocation failed for device 0000:02:00.0 size=4096
>>> CPU: 0 PID: 1062 Comm: systemd-udevd Not tainted 4.8.0+ #35
>>> Hardware name: AMD Seattle/Seattle, BIOS 10:53:24 Oct 13 2016
>>>
>>> on systems without memory that is 32-bit addressable by PCI devices.
>>>
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> ---
>>> v2: dropped the hunk that sets the coherent DMA mask to DMA_BIT_MASK(32),
>>> which is unnecessary given that it is the default
>>>
>>> drivers/net/ethernet/realtek/r8169.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
>>> index e55638c7505a..bf000d819a21 100644
>>> --- a/drivers/net/ethernet/realtek/r8169.c
>>> +++ b/drivers/net/ethernet/realtek/r8169.c
>>> @@ -8273,7 +8273,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> if ((sizeof(dma_addr_t) > 4) &&
>>> (use_dac == 1 || (use_dac == -1 && pci_is_pcie(pdev) &&
>>> tp->mac_version >= RTL_GIGA_MAC_VER_18)) &&
>>> - !pci_set_dma_mask(pdev, DMA_BIT_MASK(64))) {
>>> + !pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) &&
>>> + !pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64))) {
>>
>> Isn't there a dma_set_mask_and_coherent() function ?
>>
>
> Not of the pci_xxx variety afaik
You can often use the "dev_*" variants intechangably with the pci_*()
ones.
In fact you'll find that for several architectures pci_*() is
implemented via calls to dev_*().
^ permalink raw reply
* Re: [PATCH v2] r8169: set coherent DMA mask as well as streaming DMA mask
From: David Miller @ 2016-10-15 21:29 UTC (permalink / raw)
To: ard.biesheuvel; +Cc: romieu, nic_swsd, netdev, linux-kernel
In-Reply-To: <1476452433-20518-1-git-send-email-ard.biesheuvel@linaro.org>
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Fri, 14 Oct 2016 14:40:33 +0100
> PCI devices that are 64-bit DMA capable should set the coherent
> DMA mask as well as the streaming DMA mask. On some architectures,
> these are managed separately, and so the coherent DMA mask will be
> left at its default value of 32 if it is not set explicitly. This
> results in errors such as
>
> r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> hwdev DMA mask = 0x00000000ffffffff, dev_addr = 0x00000080fbfff000
> swiotlb: coherent allocation failed for device 0000:02:00.0 size=4096
> CPU: 0 PID: 1062 Comm: systemd-udevd Not tainted 4.8.0+ #35
> Hardware name: AMD Seattle/Seattle, BIOS 10:53:24 Oct 13 2016
>
> on systems without memory that is 32-bit addressable by PCI devices.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Applied.
^ permalink raw reply
* linux-next: manual merge of the net tree with Linus' tree
From: Stephen Rothwell @ 2016-10-15 21:13 UTC (permalink / raw)
To: David Miller, Networking
Cc: linux-next, linux-kernel, Ram Amrani, Doug Ledford, Yuval Mintz
Hi all,
Today's linux-next merge of the net tree got a conflict in:
drivers/net/ethernet/qlogic/Kconfig
between commit:
2e0cbc4dd077 ("qedr: Add RoCE driver framework")
from Linus' tree and commit:
0189efb8f4f8 ("qed*: Fix Kconfig dependencies with INFINIBAND_QEDR")
from the net tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
I also added this merge fix patch:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Sun, 16 Oct 2016 08:09:42 +1100
Subject: [PATCH] qed*: merge fix for CONFIG_INFINIBAND_QEDR Kconfig move
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/infiniband/hw/qedr/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/infiniband/hw/qedr/Kconfig b/drivers/infiniband/hw/qedr/Kconfig
index 7c06d85568d4..6c9f3923e838 100644
--- a/drivers/infiniband/hw/qedr/Kconfig
+++ b/drivers/infiniband/hw/qedr/Kconfig
@@ -2,6 +2,7 @@ config INFINIBAND_QEDR
tristate "QLogic RoCE driver"
depends on 64BIT && QEDE
select QED_LL2
+ select QED_RDMA
---help---
This driver provides low-level InfiniBand over Ethernet
support for QLogic QED host channel adapters (HCAs).
--
2.8.1
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/qlogic/Kconfig
index 1e8339a67f6e,77567727528a..000000000000
--- a/drivers/net/ethernet/qlogic/Kconfig
+++ b/drivers/net/ethernet/qlogic/Kconfig
@@@ -107,4 -107,19 +107,7 @@@ config QED
---help---
This enables the support for ...
+ config QED_RDMA
+ bool
+
-config INFINIBAND_QEDR
- tristate "QLogic qede RoCE sources [debug]"
- depends on QEDE && 64BIT
- select QED_LL2
- select QED_RDMA
- default n
- ---help---
- This provides a temporary node that allows the compilation
- and logical testing of the InfiniBand over Ethernet support
- for QLogic QED. This would be replaced by the 'real' option
- once the QEDR driver is added [+relocated].
-
endif # NET_VENDOR_QLOGIC
^ permalink raw reply related
* Re: [PATCH v2 1/3] net: smc91x: isolate u16 writes alignment workaround
From: Robert Jarzmik @ 2016-10-15 21:11 UTC (permalink / raw)
To: David S. Miller
Cc: Rob Herring, Mark Rutland, Nicolas Pitre,
Russell King - ARM Linux, Arnd Bergmann,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476559670-25056-2-git-send-email-robert.jarzmik-GANU6spQydw@public.gmane.org>
Sorry David, I just noticed you weren't in the "To:" of this serie, but I won't
forget you for the v3 I need to release anyway
(https://lkml.org/lkml/2016/10/15/104).
Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org> writes:
> + lp->half_word_align4 =
> + machine_is_mainstone() || machine_is_stargate2() ||
> + machine_is_pxa_idp();
Bah this one is not good enough.
First, machine_is_*() is not defined if CONFIG_ARM=n, and this part is not under
a #ifdef CONFIG_ARM.
Moreover, I think it is a good occasion to go further, and :
- enhance smc91x_platdata and add a pxa_u16_align4 boolean
- transform this statement into :
lp->half_word_align4 = lp->cfg.pxa_u16_align4
This will remove the machine_*() calls from the smc91x driver, which looks a
good move, doesn't it ?
Cheers.
--
Robert
--
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 2/2] rds: Remove duplicate prefix from rds_conn_path_error use
From: Santosh Shilimkar @ 2016-10-15 19:38 UTC (permalink / raw)
To: Joe Perches
Cc: David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <832b0d2c1b31c10db7692f65f1ba77e779db15e1.1476557523.git.joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
On 10/15/2016 11:53 AM, Joe Perches wrote:
> rds_conn_path_error already prefixes "RDS:" to the output.
>
> Signed-off-by: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
> ---
Acked-by: Santosh Shilimkar <santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
--
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
* Re: [PATCH 1/2] rds: Remove unused rds_conn_error
From: Santosh Shilimkar @ 2016-10-15 19:38 UTC (permalink / raw)
To: Joe Perches
Cc: David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <01fddf3af8f7757d0e79e4f25d7eb8b246e3d695.1476557523.git.joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
On 10/15/2016 11:53 AM, Joe Perches wrote:
> This macro's last use was removed in commit d769ef81d5b59
> ("RDS: Update rds_conn_shutdown to work with rds_conn_path")
> so make the macro and the __rds_conn_error function definition
> and declaration disappear.
>
> Signed-off-by: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
> ---
Had same patch along with few more in the queue but
didn't find time of late to get it on the list.
Thanks for both patches.
Acked-by: Santosh Shilimkar <santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
--
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
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