* [PATCH net 4/5] tcp: call tcp_drop() from tcp_data_queue_ofo()
From: Eric Dumazet @ 2018-07-23 16:28 UTC (permalink / raw)
To: David S . Miller, Juha-Matti Tilli, Yuchung Cheng,
Soheil Hassas Yeganeh
Cc: netdev, Eric Dumazet, Eric Dumazet
In-Reply-To: <20180723162821.11556-1-edumazet@google.com>
In order to be able to give better diagnostics and detect
malicious traffic, we need to have better sk->sk_drops tracking.
Fixes: 9f5afeae5152 ("tcp: use an RB tree for ooo receive queue")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
---
net/ipv4/tcp_input.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 78068b902e7bca6e60cbe562f1554fc33b43c872..b062a76922384f6199563af7cf30a30c5baa7601 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4510,7 +4510,7 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
/* All the bits are present. Drop. */
NET_INC_STATS(sock_net(sk),
LINUX_MIB_TCPOFOMERGE);
- __kfree_skb(skb);
+ tcp_drop(sk, skb);
skb = NULL;
tcp_dsack_set(sk, seq, end_seq);
goto add_sack;
@@ -4529,7 +4529,7 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
TCP_SKB_CB(skb1)->end_seq);
NET_INC_STATS(sock_net(sk),
LINUX_MIB_TCPOFOMERGE);
- __kfree_skb(skb1);
+ tcp_drop(sk, skb1);
goto merge_right;
}
} else if (tcp_try_coalesce(sk, skb1,
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply related
* [PATCH net 3/5] tcp: detect malicious patterns in tcp_collapse_ofo_queue()
From: Eric Dumazet @ 2018-07-23 16:28 UTC (permalink / raw)
To: David S . Miller, Juha-Matti Tilli, Yuchung Cheng,
Soheil Hassas Yeganeh
Cc: netdev, Eric Dumazet, Eric Dumazet
In-Reply-To: <20180723162821.11556-1-edumazet@google.com>
In case an attacker feeds tiny packets completely out of order,
tcp_collapse_ofo_queue() might scan the whole rb-tree, performing
expensive copies, but not changing socket memory usage at all.
1) Do not attempt to collapse tiny skbs.
2) Add logic to exit early when too many tiny skbs are detected.
We prefer not doing aggressive collapsing (which copies packets)
for pathological flows, and revert to tcp_prune_ofo_queue() which
will be less expensive.
In the future, we might add the possibility of terminating flows
that are proven to be malicious.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
---
net/ipv4/tcp_input.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 53289911362a2dea6b1e9d9ce630b29eed87ebb9..78068b902e7bca6e60cbe562f1554fc33b43c872 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4902,6 +4902,7 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
static void tcp_collapse_ofo_queue(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
+ u32 range_truesize, sum_tiny = 0;
struct sk_buff *skb, *head;
u32 start, end;
@@ -4913,6 +4914,7 @@ static void tcp_collapse_ofo_queue(struct sock *sk)
}
start = TCP_SKB_CB(skb)->seq;
end = TCP_SKB_CB(skb)->end_seq;
+ range_truesize = skb->truesize;
for (head = skb;;) {
skb = skb_rb_next(skb);
@@ -4923,11 +4925,20 @@ static void tcp_collapse_ofo_queue(struct sock *sk)
if (!skb ||
after(TCP_SKB_CB(skb)->seq, end) ||
before(TCP_SKB_CB(skb)->end_seq, start)) {
- tcp_collapse(sk, NULL, &tp->out_of_order_queue,
- head, skb, start, end);
+ /* Do not attempt collapsing tiny skbs */
+ if (range_truesize != head->truesize ||
+ end - start >= SKB_WITH_OVERHEAD(SK_MEM_QUANTUM)) {
+ tcp_collapse(sk, NULL, &tp->out_of_order_queue,
+ head, skb, start, end);
+ } else {
+ sum_tiny += range_truesize;
+ if (sum_tiny > sk->sk_rcvbuf >> 3)
+ return;
+ }
goto new_range;
}
+ range_truesize += skb->truesize;
if (unlikely(before(TCP_SKB_CB(skb)->seq, start)))
start = TCP_SKB_CB(skb)->seq;
if (after(TCP_SKB_CB(skb)->end_seq, end))
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply related
* [PATCH net 2/5] tcp: avoid collapses in tcp_prune_queue() if possible
From: Eric Dumazet @ 2018-07-23 16:28 UTC (permalink / raw)
To: David S . Miller, Juha-Matti Tilli, Yuchung Cheng,
Soheil Hassas Yeganeh
Cc: netdev, Eric Dumazet, Eric Dumazet
In-Reply-To: <20180723162821.11556-1-edumazet@google.com>
Right after a TCP flow is created, receiving tiny out of order
packets allways hit the condition :
if (atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf)
tcp_clamp_window(sk);
tcp_clamp_window() increases sk_rcvbuf to match sk_rmem_alloc
(guarded by tcp_rmem[2])
Calling tcp_collapse_ofo_queue() in this case is not useful,
and offers a O(N^2) surface attack to malicious peers.
Better not attempt anything before full queue capacity is reached,
forcing attacker to spend lots of resource and allow us to more
easily detect the abuse.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
---
net/ipv4/tcp_input.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 64e45b279431886a50c8097593b9dbc9e5d75cc1..53289911362a2dea6b1e9d9ce630b29eed87ebb9 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5004,6 +5004,9 @@ static int tcp_prune_queue(struct sock *sk)
else if (tcp_under_memory_pressure(sk))
tp->rcv_ssthresh = min(tp->rcv_ssthresh, 4U * tp->advmss);
+ if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf)
+ return 0;
+
tcp_collapse_ofo_queue(sk);
if (!skb_queue_empty(&sk->sk_receive_queue))
tcp_collapse(sk, &sk->sk_receive_queue, NULL,
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply related
* [PATCH net 1/5] tcp: free batches of packets in tcp_prune_ofo_queue()
From: Eric Dumazet @ 2018-07-23 16:28 UTC (permalink / raw)
To: David S . Miller, Juha-Matti Tilli, Yuchung Cheng,
Soheil Hassas Yeganeh
Cc: netdev, Eric Dumazet, Eric Dumazet
In-Reply-To: <20180723162821.11556-1-edumazet@google.com>
Juha-Matti Tilli reported that malicious peers could inject tiny
packets in out_of_order_queue, forcing very expensive calls
to tcp_collapse_ofo_queue() and tcp_prune_ofo_queue() for
every incoming packet. out_of_order_queue rb-tree can contain
thousands of nodes, iterating over all of them is not nice.
Before linux-4.9, we would have pruned all packets in ofo_queue
in one go, every XXXX packets. XXXX depends on sk_rcvbuf and skbs
truesize, but is about 7000 packets with tcp_rmem[2] default of 6 MB.
Since we plan to increase tcp_rmem[2] in the future to cope with
modern BDP, can not revert to the old behavior, without great pain.
Strategy taken in this patch is to purge ~12.5 % of the queue capacity.
Fixes: 36a6503fedda ("tcp: refine tcp_prune_ofo_queue() to not drop all packets")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Juha-Matti Tilli <juha-matti.tilli@iki.fi>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
---
net/ipv4/tcp_input.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 6bade06aaf72afea474ec83677d63b23e531ab68..64e45b279431886a50c8097593b9dbc9e5d75cc1 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4942,6 +4942,7 @@ static void tcp_collapse_ofo_queue(struct sock *sk)
* 2) not add too big latencies if thousands of packets sit there.
* (But if application shrinks SO_RCVBUF, we could still end up
* freeing whole queue here)
+ * 3) Drop at least 12.5 % of sk_rcvbuf to avoid malicious attacks.
*
* Return true if queue has shrunk.
*/
@@ -4949,20 +4950,26 @@ static bool tcp_prune_ofo_queue(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
struct rb_node *node, *prev;
+ int goal;
if (RB_EMPTY_ROOT(&tp->out_of_order_queue))
return false;
NET_INC_STATS(sock_net(sk), LINUX_MIB_OFOPRUNED);
+ goal = sk->sk_rcvbuf >> 3;
node = &tp->ooo_last_skb->rbnode;
do {
prev = rb_prev(node);
rb_erase(node, &tp->out_of_order_queue);
+ goal -= rb_to_skb(node)->truesize;
tcp_drop(sk, rb_to_skb(node));
- sk_mem_reclaim(sk);
- if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf &&
- !tcp_under_memory_pressure(sk))
- break;
+ if (!prev || goal <= 0) {
+ sk_mem_reclaim(sk);
+ if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf &&
+ !tcp_under_memory_pressure(sk))
+ break;
+ goal = sk->sk_rcvbuf >> 3;
+ }
node = prev;
} while (node);
tp->ooo_last_skb = rb_to_skb(prev);
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply related
* [PATCH net 0/5] tcp: more robust ooo handling
From: Eric Dumazet @ 2018-07-23 16:28 UTC (permalink / raw)
To: David S . Miller, Juha-Matti Tilli, Yuchung Cheng,
Soheil Hassas Yeganeh
Cc: netdev, Eric Dumazet, Eric Dumazet
Juha-Matti Tilli reported that malicious peers could inject tiny
packets in out_of_order_queue, forcing very expensive calls
to tcp_collapse_ofo_queue() and tcp_prune_ofo_queue() for
every incoming packet.
With tcp_rmem[2] default of 6MB, the ooo queue could
contain ~7000 nodes.
This patch series makes sure we cut cpu cycles enough to
render the attack not critical.
We might in the future go further, like disconnecting
or black-holing proven malicious flows.
Eric Dumazet (5):
tcp: free batches of packets in tcp_prune_ofo_queue()
tcp: avoid collapses in tcp_prune_queue() if possible
tcp: detect malicious patterns in tcp_collapse_ofo_queue()
tcp: call tcp_drop() from tcp_data_queue_ofo()
tcp: add tcp_ooo_try_coalesce() helper
net/ipv4/tcp_input.c | 62 +++++++++++++++++++++++++++++++++++---------
1 file changed, 50 insertions(+), 12 deletions(-)
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply
* possible deadlock in mnt_want_write
From: syzbot @ 2018-07-23 17:30 UTC (permalink / raw)
To: linux-fsdevel, linux-kernel, syzkaller-bugs, viro
Hello,
syzbot found the following crash on:
HEAD commit: 45ae4df92207 Merge tag 'armsoc-fixes' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10e7eee0400000
kernel config: https://syzkaller.appspot.com/x/.config?x=c0bdc4175608181c
dashboard link: https://syzkaller.appspot.com/bug?extid=ae82084b07d0297e566b
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+ae82084b07d0297e566b@syzkaller.appspotmail.com
device bridge_slave_0 left promiscuous mode
bridge0: port 1(bridge_slave_0) entered disabled state
IPVS: set_ctl: invalid protocol: 255 0.0.0.0:20004
======================================================
WARNING: possible circular locking dependency detected
4.18.0-rc5+ #159 Not tainted
------------------------------------------------------
syz-executor7/24660 is trying to acquire lock:
000000007bd46ec8 (sb_writers#15){.+.+}, at: sb_start_write
include/linux/fs.h:1554 [inline]
000000007bd46ec8 (sb_writers#15){.+.+}, at: mnt_want_write+0x3f/0xc0
fs/namespace.c:386
but task is already holding lock:
00000000a4a13f7a (&fi->mutex){+.+.}, at: fuse_lock_inode+0xaf/0xe0
fs/fuse/inode.c:363
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&fi->mutex){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:757 [inline]
__mutex_lock+0x176/0x1820 kernel/locking/mutex.c:894
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:909
fuse_lock_inode+0xaf/0xe0 fs/fuse/inode.c:363
fuse_lookup+0x8f/0x4c0 fs/fuse/dir.c:359
__lookup_hash+0x12e/0x190 fs/namei.c:1505
filename_create+0x1e5/0x5b0 fs/namei.c:3646
user_path_create fs/namei.c:3703 [inline]
do_mkdirat+0xda/0x310 fs/namei.c:3842
__do_sys_mkdirat fs/namei.c:3861 [inline]
__se_sys_mkdirat fs/namei.c:3859 [inline]
__x64_sys_mkdirat+0x76/0xb0 fs/namei.c:3859
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #1 (&type->i_mutex_dir_key#5/1){+.+.}:
down_write_nested+0x93/0x130 kernel/locking/rwsem.c:192
inode_lock_nested include/linux/fs.h:750 [inline]
filename_create+0x1b2/0x5b0 fs/namei.c:3645
user_path_create fs/namei.c:3703 [inline]
do_mkdirat+0xda/0x310 fs/namei.c:3842
__do_sys_mkdirat fs/namei.c:3861 [inline]
__se_sys_mkdirat fs/namei.c:3859 [inline]
__x64_sys_mkdirat+0x76/0xb0 fs/namei.c:3859
nla_parse: 14 callbacks suppressed
netlink: 3 bytes leftover after parsing attributes in process
`syz-executor1'.
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 (sb_writers#15){.+.+}:
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
[inline]
percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
__sb_start_write+0x1e9/0x300 fs/super.c:1403
sb_start_write include/linux/fs.h:1554 [inline]
mnt_want_write+0x3f/0xc0 fs/namespace.c:386
path_removexattr+0xf0/0x210 fs/xattr.c:703
__do_sys_removexattr fs/xattr.c:719 [inline]
__se_sys_removexattr fs/xattr.c:716 [inline]
__x64_sys_removexattr+0x59/0x80 fs/xattr.c:716
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
other info that might help us debug this:
Chain exists of:
sb_writers#15 --> &type->i_mutex_dir_key#5/1 --> &fi->mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&fi->mutex);
lock(&type->i_mutex_dir_key#5/1);
lock(&fi->mutex);
lock(sb_writers#15);
*** DEADLOCK ***
1 lock held by syz-executor7/24660:
#0: 00000000a4a13f7a (&fi->mutex){+.+.}, at: fuse_lock_inode+0xaf/0xe0
fs/fuse/inode.c:363
stack backtrace:
CPU: 1 PID: 24660 Comm: syz-executor7 Not tainted 4.18.0-rc5+ #159
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_circular_bug.isra.36.cold.57+0x1bd/0x27d
kernel/locking/lockdep.c:1227
check_prev_add kernel/locking/lockdep.c:1867 [inline]
check_prevs_add kernel/locking/lockdep.c:1980 [inline]
validate_chain kernel/locking/lockdep.c:2421 [inline]
__lock_acquire+0x3449/0x5020 kernel/locking/lockdep.c:3435
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36 [inline]
percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
__sb_start_write+0x1e9/0x300 fs/super.c:1403
sb_start_write include/linux/fs.h:1554 [inline]
mnt_want_write+0x3f/0xc0 fs/namespace.c:386
path_removexattr+0xf0/0x210 fs/xattr.c:703
__do_sys_removexattr fs/xattr.c:719 [inline]
__se_sys_removexattr fs/xattr.c:716 [inline]
__x64_sys_removexattr+0x59/0x80 fs/xattr.c:716
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x455ab9
Code: 1d ba fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fee4a211c68 EFLAGS: 00000246 ORIG_RAX: 00000000000000c5
RAX: ffffffffffffffda RBX: 00007fee4a2126d4 RCX: 0000000000455ab9
RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000020000040
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000004bbc1c R14: 00000000004d0f48 R15: 0000000000000000
team0 (unregistering): Port device team_slave_1 removed
team0 (unregistering): Port device team_slave_0 removed
bond0 (unregistering): Releasing backup interface bond_slave_1
bond0 (unregistering): Releasing backup interface bond_slave_0
bond0 (unregistering): Released all slaves
netlink: 3 bytes leftover after parsing attributes in process
`syz-executor4'.
netlink: 3 bytes leftover after parsing attributes in process
`syz-executor3'.
netlink: 3 bytes leftover after parsing attributes in process
`syz-executor1'.
netlink: 3 bytes leftover after parsing attributes in process
`syz-executor2'.
netlink: 3 bytes leftover after parsing attributes in process
`syz-executor4'.
netlink: 3 bytes leftover after parsing attributes in process
`syz-executor2'.
netlink: 3 bytes leftover after parsing attributes in process
`syz-executor1'.
netlink: 3 bytes leftover after parsing attributes in process
`syz-executor4'.
netlink: 3 bytes leftover after parsing attributes in process
`syz-executor2'.
nla_parse: 16 callbacks suppressed
netlink: 3 bytes leftover after parsing attributes in process
`syz-executor4'.
netlink: 3 bytes leftover after parsing attributes in process
`syz-executor4'.
netlink: 3 bytes leftover after parsing attributes in process
`syz-executor4'.
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* KASAN: use-after-free Read in rds_cong_queue_updates (2)
From: syzbot @ 2018-07-23 17:30 UTC (permalink / raw)
To: davem, linux-kernel, linux-rdma, netdev, rds-devel,
santosh.shilimkar, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: fcf4793e278e tls: check RCV_SHUTDOWN in tls_wait_data
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=1738cb2c400000
kernel config: https://syzkaller.appspot.com/x/.config?x=c0bdc4175608181c
dashboard link: https://syzkaller.appspot.com/bug?extid=470ae97a39f16146af45
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+470ae97a39f16146af45@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in atomic_read
include/asm-generic/atomic-instrumented.h:21 [inline]
BUG: KASAN: use-after-free in refcount_read include/linux/refcount.h:42
[inline]
BUG: KASAN: use-after-free in check_net include/net/net_namespace.h:237
[inline]
BUG: KASAN: use-after-free in rds_destroy_pending net/rds/rds.h:902 [inline]
BUG: KASAN: use-after-free in rds_cong_queue_updates+0x25d/0x5b0
net/rds/cong.c:226
Read of size 4 at addr ffff88019f180144 by task kworker/u4:1/23
CPU: 1 PID: 23 Comm: kworker/u4:1 Not tainted 4.18.0-rc5+ #18
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: krdsd rds_send_worker
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
refcount_read include/linux/refcount.h:42 [inline]
check_net include/net/net_namespace.h:237 [inline]
rds_destroy_pending net/rds/rds.h:902 [inline]
rds_cong_queue_updates+0x25d/0x5b0 net/rds/cong.c:226
rds_recv_rcvbuf_delta.part.3+0x332/0x3e0 net/rds/recv.c:123
rds_recv_rcvbuf_delta net/rds/recv.c:382 [inline]
rds_recv_incoming+0x85a/0x1320 net/rds/recv.c:382
rds_loop_xmit+0x16a/0x340 net/rds/loop.c:95
rds_send_xmit+0x1343/0x29c0 net/rds/send.c:355
rds_send_worker+0x153/0x300 net/rds/threads.c:199
process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
kthread+0x345/0x410 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
Allocated by task 4564:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554
kmem_cache_zalloc include/linux/slab.h:697 [inline]
net_alloc net/core/net_namespace.c:383 [inline]
copy_net_ns+0x15b/0x4d0 net/core/net_namespace.c:423
create_new_namespaces+0x6ad/0x900 kernel/nsproxy.c:107
unshare_nsproxy_namespaces+0xc3/0x1f0 kernel/nsproxy.c:206
ksys_unshare+0x723/0xfb0 kernel/fork.c:2419
__do_sys_unshare kernel/fork.c:2487 [inline]
__se_sys_unshare kernel/fork.c:2485 [inline]
__x64_sys_unshare+0x31/0x40 kernel/fork.c:2485
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 23:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kmem_cache_free+0x86/0x2d0 mm/slab.c:3756
net_free net/core/net_namespace.c:399 [inline]
net_drop_ns.part.14+0x129/0x150 net/core/net_namespace.c:406
net_drop_ns net/core/net_namespace.c:405 [inline]
cleanup_net+0x6bb/0xb50 net/core/net_namespace.c:541
process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
kthread+0x345/0x410 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
The buggy address belongs to the object at ffff88019f180140
which belongs to the cache net_namespace of size 8704
The buggy address is located 4 bytes inside of
8704-byte region [ffff88019f180140, ffff88019f182340)
The buggy address belongs to the page:
page:ffffea00067c6000 count:1 mapcount:0 mapping:ffff8801d9be9e40 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea00067d5a08 ffffea00067b3a08 ffff8801d9be9e40
raw: 0000000000000000 ffff88019f180140 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88019f180000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88019f180080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff88019f180100: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff88019f180180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88019f180200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* master - lvconvert: improve text about splitmirrors
From: David Teigland @ 2018-07-23 17:29 UTC (permalink / raw)
To: lvm-devel
Gitweb: https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=778ce8d80830a60d258b419720be3e45a7ee9f0b
Commit: 778ce8d80830a60d258b419720be3e45a7ee9f0b
Parent: 8a66c81b9beb87f2f381e7e2aa76e4e54fd19934
Author: David Teigland <teigland@redhat.com>
AuthorDate: Mon Jul 23 12:28:48 2018 -0500
Committer: David Teigland <teigland@redhat.com>
CommitterDate: Mon Jul 23 12:28:48 2018 -0500
lvconvert: improve text about splitmirrors
in messages and man page.
---
lib/metadata/raid_manip.c | 4 ++--
tools/args.h | 14 +++++++++-----
tools/command-lines.in | 2 +-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/lib/metadata/raid_manip.c b/lib/metadata/raid_manip.c
index 92e01a2..931b411 100644
--- a/lib/metadata/raid_manip.c
+++ b/lib/metadata/raid_manip.c
@@ -3553,7 +3553,7 @@ int lv_raid_merge(struct logical_volume *image_lv)
struct volume_group *vg = image_lv->vg;
if (image_lv->status & LVM_WRITE) {
- log_error("%s is not read-only - refusing to merge.",
+ log_error("%s cannot be merged because --trackchanges was not used.",
display_lvname(image_lv));
return 0;
}
@@ -3562,7 +3562,7 @@ int lv_raid_merge(struct logical_volume *image_lv)
return_0;
if (!(p = strstr(lv_name, "_rimage_"))) {
- log_error("Unable to merge non-mirror image %s.",
+ log_error("Unable to merge non-raid image %s.",
display_lvname(image_lv));
return 0;
}
diff --git a/tools/args.h b/tools/args.h
index 9e83b12..adca84b 100644
--- a/tools/args.h
+++ b/tools/args.h
@@ -618,7 +618,9 @@ arg(splitcache_ARG, '\0', "splitcache", 0, 0, 0,
arg(splitmirrors_ARG, '\0', "splitmirrors", number_VAL, 0, 0,
"Splits the specified number of images from a raid1 or mirror LV\n"
"and uses them to create a new LV. If --trackchanges is also specified,\n"
- "changes to the raid1 LV are tracked while the split LV remains detached.\n")
+ "changes to the raid1 LV are tracked while the split LV remains detached.\n"
+ "If --name is specified, then the images are permanently split from the\n"
+ "original LV and changes are not tracked.\n")
arg(splitsnapshot_ARG, '\0', "splitsnapshot", 0, 0, 0,
"Separates a COW snapshot from its origin LV. The LV that is split off\n"
@@ -697,10 +699,12 @@ arg(thinpool_ARG, '\0', "thinpool", lv_VAL, 0, 0,
arg(trackchanges_ARG, '\0', "trackchanges", 0, 0, 0,
"Can be used with --splitmirrors on a raid1 LV. This causes\n"
"changes to the original raid1 LV to be tracked while the split images\n"
- "remain detached. This allows the read-only detached image(s) to be\n"
- "merged efficiently back into the raid1 LV later. Only the regions with\n"
- "changed data are resynchronized during merge. (This option only applies\n"
- "when using the raid1 LV type.)\n")
+ "remain detached. This is a temporary state that allows the read-only\n"
+ "detached image to be merged efficiently back into the raid1 LV later.\n"
+ "Only the regions with changed data are resynchronized during merge.\n"
+ "While a raid1 LV is tracking changes, operations on it are limited to\n"
+ "merging the split image (see --mergemirrors) or permanently splitting\n"
+ "the image (see --splitmirrors with --name.\n")
/* TODO: hide this? */
arg(trustcache_ARG, '\0', "trustcache", 0, 0, 0,
diff --git a/tools/command-lines.in b/tools/command-lines.in
index d6cd04e..1511098 100644
--- a/tools/command-lines.in
+++ b/tools/command-lines.in
@@ -408,7 +408,7 @@ lvconvert --splitmirrors Number --trackchanges LV_raid1_cache
OO: OO_LVCONVERT
OP: PV ...
ID: lvconvert_split_mirror_images
-DESC: Split images from a raid1 LV and track changes to origin.
+DESC: Split images from a raid1 LV and track changes to origin for later merge.
RULE: all not lv_is_locked lv_is_pvmove
lvconvert --mergemirrors LV_linear_raid|VG|Tag ...
^ permalink raw reply related
* Re: [PATCH net] ip: hash fragments consistently
From: Eric Dumazet @ 2018-07-23 16:26 UTC (permalink / raw)
To: Paolo Abeni, netdev; +Cc: David S. Miller, Tom Herbert
In-Reply-To: <9b22fd3a35416b3145f1245466167b001925ce1a.1532357173.git.pabeni@redhat.com>
On 07/23/2018 07:50 AM, Paolo Abeni wrote:
> The skb hash for locally generated ip[v6] fragments belonging
> to the same datagram can vary in several circumstances:
> * for connected UDP[v6] sockets, the first fragment get its hash
> via set_owner_w()/skb_set_hash_from_sk()
> * for unconnected IPv6 UDPv6 sockets, the first fragment can get
> its hash via ip6_make_flowlabel()/skb_get_hash_flowi6(), if
> auto_flowlabel is enabled
>
> For the following frags the hash is usually computed via
> skb_get_hash().
> The above can cause OoO for unconnected IPv6 UDPv6 socket: in that
> scenario the egress tx queue can be selected on a per packet basis
> via the skb hash.
> It may also fool flow-oriented schedulers to place fragments belonging
> to the same datagram in different flows.
>
It also fools bond_xmit_hash(), packets of the same datagram can be sent on
two bonding slaves instead of one, meaning adding pressure on the defrag unit
in receiver.
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [RESEND] Spectre-v2 (IBPB/IBRS) and SSBD fixes for 4.4.y
From: Srivatsa S. Bhat @ 2018-07-23 17:27 UTC (permalink / raw)
To: Greg KH
Cc: Dave Hansen, Wanpeng Li, ak, linux-tip-commits, Piotr Luc,
Mel Gorman, arjan.van.de.ven, xen-devel, Alexander Sergeyev,
Brian Gerst, Andy Lutomirski, MickaëlSalaün,
Thomas Gleixner, Joe Konno, Laura Abbott, Will Drewry,
Jiri Kosina, linux-kernel, Jia Zhang, Andrew Morton, torvalds,
dwmw, karahmed, dave.hansen, linux, Bo Gan
In-Reply-To: <20180723112624.GA29710@kroah.com>
On 7/23/18 4:26 AM, Greg KH wrote:
> On Sat, Jul 14, 2018 at 02:25:43AM -0700, Srivatsa S. Bhat wrote:
>> Hi Greg,
>>
>> This patch series is a backport of the Spectre-v2 fixes (IBPB/IBRS)
>> and patches for the Speculative Store Bypass vulnerability to 4.4.y
>> (they apply cleanly on top of 4.4.140).
>>
>> I used 4.9.y as my reference when backporting to 4.4.y (as I thought
>> that would minimize the amount of fixing up necessary). Unfortunately
>> I had to skip the KVM fixes for these vulnerabilities, as the KVM
>> codebase is drastically different in 4.4 as compared to 4.9. (I tried
>> my best to backport them initially, but wasn't confident that they
>> were correct, so I decided to drop them from this series).
>>
>> You'll notice that the initial few patches in this series include
>> cleanups etc., that are non-critical to IBPB/IBRS/SSBD. Most of these
>> patches are aimed at getting the cpufeature.h vs cpufeatures.h split
>> into 4.4, since a lot of the subsequent patches update these headers.
>> On my first attempt to backport these patches to 4.4.y, I had actually
>> tried to do all the updates on the cpufeature.h file itself, but it
>> started getting very cumbersome, so I resorted to backporting the
>> cpufeature.h vs cpufeatures.h split and their dependencies as well. I
>> think apart from these initial patches, the rest of the patchset
>> doesn't have all that much noise.
>>
>> This patchset has been tested on both Intel and AMD machines (Intel
>> Xeon CPU E5-2660 v4 and AMD EPYC 7281 16-Core Processor, respectively)
>> with updated microcode. All the patch backports have been
>> independently reviewed by Matt Helsley, Alexey Makhalov and Bo Gan.
>>
>> I would appreciate if you could kindly consider these patches for
>> review and inclusion in a future 4.4.y release.
>
> Given no one has complained about these yet, I've queued them all up,
> including the 2 extra ones you sent afterward.
>
Great! Thank you very much!
> Let's see what breaks :)
>
Hehe :)
Regards,
Srivatsa
VMware Photon OS
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [RESEND] Spectre-v2 (IBPB/IBRS) and SSBD fixes for 4.4.y
From: Srivatsa S. Bhat @ 2018-07-23 17:27 UTC (permalink / raw)
To: Greg KH
Cc: stable, Denys Vlasenko, Bo Gan, Konrad Rzeszutek Wilk,
Borislav Petkov, Thomas Gleixner, Ricardo Neri, Tom Lendacky, ak,
linux-tip-commits, Jia Zhang, Josh Poimboeuf, xen-devel,
Krčmář, Peter Zijlstra, Andy Lutomirski,
Arnaldo Carvalho de Melo, Sherry Hurwitz, Kees Cook, linux-kernel,
Shuah Khan, Oleg Nesterov, torvalds, dwmw, karahmed,
Borislav Petkov, dave.hansen, linux, Quentin Casasnovas,
Joerg Roedel, Alexander Shishkin, Kyle Huey, Will Drewry,
Andrey Ryabinin, H. Peter Anvin, Brian Gerst,
Kristen Carlson Accardi, Thomas Garnier, Andrew Morton, Joe Konno,
kvm, Piotr Luc, boris.ostrovsky, Jan Beulich, arjan,
Alexander Kuleshov, Juergen Gross, Ross Zwisler, Jörg Otte,
tim.c.chen, Alexander Sergeyev, Josh Triplett, gnomes, Tony Luck,
Laura Abbott, dave.hansen, Ingo Molnar, Mike Galbraith,
Rik van Riel, Kirill A. Shutemov, Alexey Makhalov, Dave Hansen,
ashok.raj, Mel Gorman, MickaëlSalaün, Fenghua Yu,
Matt Helsley (VMware), Vince Weaver, Prarit Bhargava, rostedt,
Dan Williams, Jim Mattson, Dave Young, linux-edac, Jon Masters,
Jiri Kosina, Andy Lutomirski, Paolo Bonzini, Arnd Bergmann,
linux-mm, Jiri Olsa, arjan.van.de.ven, sironi,
Frederic Weisbecker, Kyle Huey, Alexander Popov, Andy Shevchenko,
Nadav Amit, Yazen Ghannam, Wanpeng Li, Stephane Eranian,
David Woodhouse, srivatsab
In-Reply-To: <20180723112624.GA29710@kroah.com>
On 7/23/18 4:26 AM, Greg KH wrote:
> On Sat, Jul 14, 2018 at 02:25:43AM -0700, Srivatsa S. Bhat wrote:
>> Hi Greg,
>>
>> This patch series is a backport of the Spectre-v2 fixes (IBPB/IBRS)
>> and patches for the Speculative Store Bypass vulnerability to 4.4.y
>> (they apply cleanly on top of 4.4.140).
>>
>> I used 4.9.y as my reference when backporting to 4.4.y (as I thought
>> that would minimize the amount of fixing up necessary). Unfortunately
>> I had to skip the KVM fixes for these vulnerabilities, as the KVM
>> codebase is drastically different in 4.4 as compared to 4.9. (I tried
>> my best to backport them initially, but wasn't confident that they
>> were correct, so I decided to drop them from this series).
>>
>> You'll notice that the initial few patches in this series include
>> cleanups etc., that are non-critical to IBPB/IBRS/SSBD. Most of these
>> patches are aimed at getting the cpufeature.h vs cpufeatures.h split
>> into 4.4, since a lot of the subsequent patches update these headers.
>> On my first attempt to backport these patches to 4.4.y, I had actually
>> tried to do all the updates on the cpufeature.h file itself, but it
>> started getting very cumbersome, so I resorted to backporting the
>> cpufeature.h vs cpufeatures.h split and their dependencies as well. I
>> think apart from these initial patches, the rest of the patchset
>> doesn't have all that much noise.
>>
>> This patchset has been tested on both Intel and AMD machines (Intel
>> Xeon CPU E5-2660 v4 and AMD EPYC 7281 16-Core Processor, respectively)
>> with updated microcode. All the patch backports have been
>> independently reviewed by Matt Helsley, Alexey Makhalov and Bo Gan.
>>
>> I would appreciate if you could kindly consider these patches for
>> review and inclusion in a future 4.4.y release.
>
> Given no one has complained about these yet, I've queued them all up,
> including the 2 extra ones you sent afterward.
>
Great! Thank you very much!
> Let's see what breaks :)
>
Hehe :)
Regards,
Srivatsa
VMware Photon OS
^ permalink raw reply
* pull-request: wireless-drivers-next 2018-07-23
From: Kalle Valo @ 2018-07-23 17:27 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
this first pull request for 4.19 got delayed as I was on vacation for
two weeks. I was supposed to send this before my vacation but didn't
manage to do it due to other urgent stuff, but I'll try to catch up with
everything this week so that we get everything ready on time for 4.19.
More info in the signed tag below and please let me know if there are
any problems.
Kalle
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2018-07-23
for you to fetch changes up to 4a07ed51cae18765c76d9aede5b9830d42db1546:
mt76x2: debugfs: add sw pulse statistics to dfs debugfs (2018-07-04 18:16:01 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.19
The first set of patches for 4.19. Only smaller features and bug
fixes, not really anything major. Also included are changes to
include/linux/bitfield.h, we agreed with Johannes that it makes sense
to apply them via wireless-drivers-next.
Major changes:
ath10k
* support channel 173
* fix spectral scan for QCA9984 and QCA9888 chipsets
ath6kl
* add support for Dell Wireless 1537
ti wlcore
* add support for runtime PM
* enable runtime PM autosuspend support
qtnfmac
* support changing MAC address
* enable source MAC address randomization support
libertas
* fix suspend and resume for SDIO cards
mt76
* add software DFS radar pattern detector for mt76x2 based devices
----------------------------------------------------------------
Andrey Shevchenko (1):
qtnfmac: enable source MAC address randomization support
Arnd Bergmann (2):
zd1211rw: stop using deprecated get_seconds()
ipw2x00: track time using boottime
Ben Greear (1):
ath10k: support use of channel 173
Brian Norris (6):
ath10k: use crash_dump enum instead of magic numbers
ath10k: snoc: use module_platform_driver() macro
ath10k: snoc: use correct bus-specific pointer in RX retry
ath10k: snoc: stop including pci.h
ath10k: snoc: drop unused WCN3990_CE_ATTR_FLAGS
ath10k: snoc: sort include files
Colin Ian King (3):
ath10k: fix memory leak of tpc_stats
ath9k: debug: fix spelling mistake "WATHDOG" -> "WATCHDOG"
brcmsmac: make function wlc_phy_workarounds_nphy_rev1 static
Dan Carpenter (1):
rndis_wlan: potential buffer overflow in rndis_wlan_auth_indication()
Daniel Mack (1):
libertas: fix suspend and resume for SDIO connected cards
Eyal Reizer (1):
wlcore: Use generic runtime pm calls for wowlan elp configuration
Felix Fietkau (9):
mt76: fix beacon timer drift
mt76: fix threshold for gain adjustment
mt76: fix swapped values for RXO-18 in gain control
mt76: adjust AGC control register 26 based on gain for VHT80
mt76: clear false CCA counters after changing gain settings
mt76: fix variable gain adjustment range
mt76: add a debugfs file to dump agc calibration information
mt76: track ewma rssi for gain adjustment per station
mt76: improve gain adjustment in noisy environments
Govind Singh (1):
ath10k: handle resource init failure case
Gustavo A. R. Silva (5):
ath10k: htt_tx: mark expected switch fall-throughs
ath5k: mark expected switch fall-through
ath6kl: mark expected switch fall-throughs
ath9k: mark expected switch fall-throughs
wlcore: Fix memory leak in wlcore_cmd_wait_for_event_or_timeout
Guy Chronister (1):
ath6kl: add support for Dell Wireless 1537
Igor Mitsyanko (1):
qtnfmac: implement net_device_ops callback to set MAC address
Johannes Berg (3):
bitfield: fix *_encode_bits()
bitfield: add u8 helpers
bitfield: add tests
Kalle Valo (1):
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Karthikeyan Periyasamy (1):
ath10k: fix spectral scan for QCA9984 and QCA9888 chipsets
Lorenzo Bianconi (5):
mt76x2: fix mrr idx/count estimation in mt76x2_mac_fill_tx_status()
mt76: introduce mt76_{incr,decr} utility routines
mt76x2: dfs: add sw event ring buffer
mt76x2: dfs: add sw pattern detector
mt76x2: debugfs: add sw pulse statistics to dfs debugfs
Niklas Cassel (1):
ath10k: do not mix spaces and tabs in Kconfig
Omer Efrat (1):
wireless-drivers: use BIT_ULL for NL80211_STA_INFO_ attribute types
Rafał Miłecki (5):
brcmfmac: detect firmware support for monitor interface
brcmfmac: detect firmware support for radiotap monitor frames
brcmfmac: handle msgbuf packets marked with monitor mode flag
brcmfmac: define more bits for the flags of struct brcmf_sta_info_le
brcmfmac: update STA info struct to the v5
Sebastian Andrzej Siewior (3):
libertas_tf: use irqsave() in USB's complete callback
libertas: use irqsave() in USB's complete callback
zd1211rw: use irqsave() in USB's complete callback
Stefan Agner (1):
brcmsmac: fix wrap around in conversion from constant to s16
Surabhi Vishnoi (1):
ath10k: skip data calibration for non-bmi target
Tony Lindgren (7):
wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()
wlcore: Make sure PM calls are paired
wlcore: Add support for runtime PM
wlcore: Fix misplaced PM call for scan_complete_work()
wlcore: Fix timout errors after recovery
wlcore: Make sure firmware is initialized in wl1271_op_add_interface()
wlcore: Enable runtime PM autosuspend support
Varsha Rao (2):
brcmsmac: Remove unnecessary parentheses
net: ipw2x00: Replace NULL comparison with !priv
Wei Yongjun (1):
ath10k: make some functions static
Xinming Hu (1):
mwifiex: uap: do not chok ethernet header in bridge path
YueHaibing (4):
ath10k: fix incorrect size of dma_free_coherent in ath10k_ce_alloc_src_ring_64
ath10k: use dma_zalloc_coherent instead of allocator/memset
atmel: use memdup_user to simplify the code
atmel: using strlcpy() to avoid possible buffer overflows
drivers/net/wireless/ath/ath10k/Kconfig | 24 +-
drivers/net/wireless/ath/ath10k/ce.c | 2 +-
drivers/net/wireless/ath/ath10k/ce.h | 42 ++
drivers/net/wireless/ath/ath10k/core.c | 19 +-
drivers/net/wireless/ath/ath10k/core.h | 3 +-
drivers/net/wireless/ath/ath10k/debug.c | 21 +-
drivers/net/wireless/ath/ath10k/htt_tx.c | 4 +-
drivers/net/wireless/ath/ath10k/hw.h | 3 +
drivers/net/wireless/ath/ath10k/mac.c | 7 +-
drivers/net/wireless/ath/ath10k/pci.h | 42 --
drivers/net/wireless/ath/ath10k/snoc.c | 47 +-
drivers/net/wireless/ath/ath10k/snoc.h | 1 -
drivers/net/wireless/ath/ath10k/spectral.c | 2 +-
drivers/net/wireless/ath/ath10k/wmi.c | 14 +-
drivers/net/wireless/ath/ath5k/pcu.c | 1 +
drivers/net/wireless/ath/ath6kl/cfg80211.c | 17 +-
drivers/net/wireless/ath/ath6kl/sdio.c | 1 +
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 2 +
drivers/net/wireless/ath/ath9k/ar9002_phy.c | 1 +
drivers/net/wireless/ath/ath9k/debug.c | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 1 +
drivers/net/wireless/ath/wil6210/cfg80211.c | 18 +-
drivers/net/wireless/atmel/atmel.c | 14 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 40 +-
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 25 +
.../wireless/broadcom/brcm80211/brcmfmac/core.h | 2 +
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 2 +
.../wireless/broadcom/brcm80211/brcmfmac/feature.h | 6 +-
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 43 +-
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 18 +
.../broadcom/brcm80211/brcmsmac/phy/phy_cmn.c | 2 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c | 2 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_qmath.c | 2 +-
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 18 +-
drivers/net/wireless/intel/ipw2x00/ipw2100.h | 12 +-
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 6 +-
drivers/net/wireless/intel/ipw2x00/ipw2200.h | 6 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 6 +-
drivers/net/wireless/marvell/libertas/cfg.c | 12 +-
drivers/net/wireless/marvell/libertas/dev.h | 1 +
drivers/net/wireless/marvell/libertas/if_sdio.c | 30 +-
drivers/net/wireless/marvell/libertas/if_usb.c | 7 +-
drivers/net/wireless/marvell/libertas_tf/if_usb.c | 8 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 14 +-
drivers/net/wireless/marvell/mwifiex/uap_txrx.c | 52 +-
drivers/net/wireless/mediatek/mt76/mt76.h | 12 +
drivers/net/wireless/mediatek/mt76/mt76x2.h | 16 +-
.../net/wireless/mediatek/mt76/mt76x2_debugfs.c | 22 +
drivers/net/wireless/mediatek/mt76/mt76x2_dfs.c | 377 ++++++++++++++-
drivers/net/wireless/mediatek/mt76/mt76x2_dfs.h | 64 +++
drivers/net/wireless/mediatek/mt76/mt76x2_mac.c | 39 +-
drivers/net/wireless/mediatek/mt76/mt76x2_main.c | 7 +-
drivers/net/wireless/mediatek/mt76/mt76x2_phy.c | 107 ++++-
drivers/net/wireless/mediatek/mt76/mt76x2_tx.c | 33 ++
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 3 +
drivers/net/wireless/quantenna/qtnfmac/commands.c | 57 ++-
drivers/net/wireless/quantenna/qtnfmac/core.c | 25 +
drivers/net/wireless/quantenna/qtnfmac/qlink.h | 20 +
drivers/net/wireless/rndis_wlan.c | 6 +-
drivers/net/wireless/ti/wl18xx/debugfs.c | 29 +-
drivers/net/wireless/ti/wlcore/acx.c | 1 -
drivers/net/wireless/ti/wlcore/cmd.c | 10 +
drivers/net/wireless/ti/wlcore/debugfs.c | 90 ++--
drivers/net/wireless/ti/wlcore/main.c | 528 ++++++++++++++-------
drivers/net/wireless/ti/wlcore/ps.c | 146 ------
drivers/net/wireless/ti/wlcore/ps.h | 3 -
drivers/net/wireless/ti/wlcore/scan.c | 13 +-
drivers/net/wireless/ti/wlcore/sysfs.c | 13 +-
drivers/net/wireless/ti/wlcore/testmode.c | 20 +-
drivers/net/wireless/ti/wlcore/tx.c | 10 +-
drivers/net/wireless/ti/wlcore/vendor_cmd.c | 30 +-
drivers/net/wireless/ti/wlcore/wlcore.h | 1 -
drivers/net/wireless/ti/wlcore/wlcore_i.h | 1 -
drivers/net/wireless/zydas/zd1211rw/zd_chip.c | 2 +-
drivers/net/wireless/zydas/zd1211rw/zd_usb.c | 21 +-
include/linux/bitfield.h | 7 +-
lib/Kconfig.debug | 7 +
lib/Makefile | 1 +
lib/test_bitfield.c | 168 +++++++
79 files changed, 1787 insertions(+), 704 deletions(-)
create mode 100644 lib/test_bitfield.c
^ permalink raw reply
* Re: [PATCH 05/11] touchscreen: elants: Use octal permissions
From: Joe Perches @ 2018-07-23 17:25 UTC (permalink / raw)
To: Dmitry Torokhov, Greg Kroah-Hartman
Cc: dev-harsh1998, trivial, Simon Budig, Andi Shyti, Luca Ceresoli,
Guenter Roeck, linux-input, linux-kernel
In-Reply-To: <20180723171831.GC100814@dtor-ws>
On Mon, 2018-07-23 at 10:18 -0700, Dmitry Torokhov wrote:
> On Mon, Jul 23, 2018 at 03:32:00PM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Jul 23, 2018 at 06:49:20PM +0530, dev-harsh1998 wrote:
> > > WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
> > > +static DEVICE_ATTR(iap_mode, S_IRUGO, show_iap_mode, NULL);
> > >
> > > WARNING: Symbolic permissions 'S_IWUSR' are not preferred. Consider using octal permissions '0200'.
> > > +static DEVICE_ATTR(update_fw, S_IWUSR, NULL, write_update_fw)
> > >
> > > WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
> > > + .dattr = __ATTR(_field, S_IRUGO, \
> > >
> > > Signed-off-by: Harshit Jain <harshitjain6751@gmail.com>
> >
> > This name doesn't match up with the From: line above :(
> >
> > Please fix up and try again.
>
> dtor@dtor-ws:~/kernel/linux-next$ git grep S_IRU | wc -l
> 7605
>
> We either need to run a tree-wide script or leave this alone. FWIW I am
> perfectly fine with either octals or symbolic names so I do not see
> benefit of doing conversion for code that is not known to be broken.
About half of those are in one subsystem (drivers/hwmon)
$ git grep -w S_IRUGO | cut -f1,2 -d'/' | \
sort | uniq -c | sort -rn | head -10 | cat -n
1 3846 drivers/hwmon
2 748 drivers/scsi
3 215 drivers/infiniband
4 168 drivers/usb
5 109 drivers/media
6 106 drivers/input
7 102 drivers/platform
8 101 drivers/misc
9 101 drivers/gpu
10 91 drivers/edac
The generic reason is octal is readable and S_<FOO> is unintelligible.
https://lkml.org/lkml/2016/8/2/1945
^ permalink raw reply
* Re: [PATCHv5 10/19] x86/mm: Implement page_keyid() using page_ext
From: Alison Schofield @ 2018-07-23 17:22 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Dave Hansen, Kirill A. Shutemov, Ingo Molnar, x86,
Thomas Gleixner, H. Peter Anvin, Tom Lendacky, Kai Huang,
Jacob Pan, linux-kernel, linux-mm
In-Reply-To: <20180723094517.7sxt62p3h75htppw@kshutemo-mobl1>
On Mon, Jul 23, 2018 at 12:45:17PM +0300, Kirill A. Shutemov wrote:
> On Wed, Jul 18, 2018 at 04:38:02PM -0700, Dave Hansen wrote:
> > On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
> > > Store KeyID in bits 31:16 of extended page flags. These bits are unused.
> >
> > I'd love a two sentence remind of what page_ext is and why you chose to
> > use it. Yes, you need this. No, not everybody that you want to review
> > this patch set knows what it is or why you chose it.
>
> Okay.
>
> > > page_keyid() returns zero until page_ext is ready.
> >
> > Is there any implication of this? Or does it not matter because we
> > don't run userspace until after page_ext initialization is done?
>
> It matters in sense that we shouldn't reference page_ext before it's
> initialized otherwise we will get garbage and crash.
>
> > > page_ext initializer enables static branch to indicate that
> >
> > "enables a static branch"
> >
> > > page_keyid() can use page_ext. The same static branch will gate MKTME
> > > readiness in general.
> >
> > Can you elaborate on this a bit? It would also be a nice place to hint
> > to the folks working hard on the APIs to ensure she checks this.
>
> Okay.
At API init time we can check if (MKTME_ENABLED && mktme_nr_keyids > 0)
Sounds like this is another dependency we need to check and 'wait' on?
It happens after MKTME_ENABLED is set? Let me know.
>
> > > We don't yet set KeyID for the page. It will come in the following
> > > patch that implements prep_encrypted_page(). All pages have KeyID-0 for
> > > now.
> >
> > It also wouldn't hurt to mention why you don't use an X86_FEATURE_* for
> > this rather than an explicit static branch. I'm sure the x86
> > maintainers will be curious.
>
> Sure.
>
> --
> Kirill A. Shutemov
^ permalink raw reply
* Re: [GIT PULL] Renesas ARM Based SoC Defconfig Updates for v4.19
From: Olof Johansson @ 2018-07-23 16:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, ARM-SoC Maintainers, Linux-Renesas, Kevin Hilman,
Arnd Bergmann, Linux ARM, Magnus Damm
In-Reply-To: <CAMuHMdVbyUa5PtQf4LZQDv-=aqToahX5Eb4TEDvsJniYm-trNQ@mail.gmail.com>
On Mon, Jul 23, 2018 at 2:11 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Olof,
>
> On Sun, Jul 22, 2018 at 12:27 AM Olof Johansson <olof@lixom.net> wrote:
>> On Fri, Jul 20, 2018 at 02:03:54PM +0200, Simon Horman wrote:
>> > Please consider these Renesas ARM based SoC defconfig updates for v4.19.
>
>> > * Set CONFIG_LOCALVERSION to shmobile_defconfig
>> >
>> > This follows what appears to be common practice in defconfigs
>> > and allows easier management of the kernel flavour at run-time.
>>
>> I replied to the multi-versions of defconfig for this patch -- it's not a good
>> way to solve the problem of detecting config at runtime. Please drop this
>> patch. See:
>>
>> https://lore.kernel.org/lkml/CAOesGMgkU6yBRpAsED2fPyuAo9Tc=YprndGdkmBVrc+0783VwQ@mail.gmail.com/
>
> One more comment to the rescue: it does complicate regression testing,
> as the test software running on the DUT has no easy way to distinguish
> between e.g. shmobile_defconfig and multi_v7_defconfig (and whatever
> other board-specific configs I use for testing).
> Yes, I can have these as local patches in my tree (of course I already have ;-),
> but when bisecting, I have to remember to (un)apply them in every step.
Hi,
It looks like scripts/setlocalversion will look for files named
localversion* in the directory you build in, git won't touch the file
so you don't have to re-apply it every time.
I do see the usefulness for bisect and so on, but there's such a high
chance that people will start changing configs without changing
localversion that the value of it will diminish immediately for
downstream trees. Also, the "local" in localversion sort of indicates
that it shouldn't be set in a central place. :)
-Olof
^ permalink raw reply
* Re: [PATCH/RFT 0/7] rsnd: add support for r8a77965
From: Simon Horman @ 2018-07-23 16:21 UTC (permalink / raw)
To: Yoshihiro Kaneko; +Cc: linux-renesas-soc, Magnus Damm, linux-arm-kernel
In-Reply-To: <1531856883-19645-1-git-send-email-ykaneko0929@gmail.com>
On Wed, Jul 18, 2018 at 04:47:56AM +0900, Yoshihiro Kaneko wrote:
> This series adds sound support for r8a77965 (R-Car M3-N).
> This series is based on the devel branch of Simon Horman's renesas tree.
>
> Hiroyuki Yokoyama (1):
> ASoC: rsnd: Document R-Car M3-N support
>
> Takeshi Kihara (6):
> arm64: dts: renesas: r8a77965: Add Audio-DMAC device nodes
> arm64: dts: renesas: r8a77965: Add Sound device node and SSI support
> arm64: dts: renesas: r8a77965: Add Sound SRC support
> arm64: dts: renesas: r8a77965: Add Sound DVC device nodes
> arm64: dts: renesas: r8a77965: Add Sound CTU support
> arm64: dts: renesas: r8a77965: Add Sound MIX support
>
> .../devicetree/bindings/sound/renesas,rsnd.txt | 1 +
> arch/arm64/boot/dts/renesas/r8a77965.dtsi | 245 ++++++++++++++++++++-
Thanks Kaneko-san,
in general this series looks good, however, I would like to ask you to
squash all the dts patches (the patches by Kihara-san) into a single patch.
For many years now we have split patches up as this series does.
And no doubt that is why BPS team chose to split up the patches
that you have based this patchset on. However, we were recently
asked by the Olof Johansson to squash patches together to make
the high-level intent of patches clearer to him in his position
of ARM-SoC co-maintainer.
So while what you have done is correct, it is now the "old way".
Please squash the patches together as this is the "new way".
Thanks!
^ permalink raw reply
* [Qemu-devel] [PULL for-3.0 1/1] tcg/i386: Mark xmm registers call-clobbered
From: Richard Henderson @ 2018-07-23 17:23 UTC (permalink / raw)
To: qemu-devel; +Cc: peter.maydell, qemu-stable
In-Reply-To: <20180723172311.11316-1-richard.henderson@linaro.org>
When host vector registers and operations were introduced, I failed
to mark the registers call clobbered as required by the ABI.
Fixes: 770c2fc7bb7
Cc: qemu-stable@nongnu.org
Reported-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---
tcg/i386/tcg-target.inc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tcg/i386/tcg-target.inc.c b/tcg/i386/tcg-target.inc.c
index e87b0d445e..a91e4f1313 100644
--- a/tcg/i386/tcg-target.inc.c
+++ b/tcg/i386/tcg-target.inc.c
@@ -3532,7 +3532,7 @@ static void tcg_target_init(TCGContext *s)
tcg_target_available_regs[TCG_TYPE_V256] = ALL_VECTOR_REGS;
}
- tcg_target_call_clobber_regs = 0;
+ tcg_target_call_clobber_regs = ALL_VECTOR_REGS;
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_EAX);
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_EDX);
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_ECX);
--
2.17.1
^ permalink raw reply related
* [Qemu-devel] [PULL for-3.0 0/1] tcg-next patches
From: Richard Henderson @ 2018-07-23 17:23 UTC (permalink / raw)
To: qemu-devel; +Cc: peter.maydell
One more tcg/i386 patch for 3.0, fixing a testcase
reported over the weekend.
r~
The following changes since commit e596be90393389405c96a5c9534c4c4e2e0b5675:
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20180723' into staging (2018-07-23 16:15:24 +0100)
are available in the Git repository at:
https://github.com/rth7680/qemu.git tags/pull-tcg-20180723
for you to fetch changes up to 672189cd586ea38a2c1d8ab91eb1f9dcff5ceb05:
tcg/i386: Mark xmm registers call-clobbered (2018-07-23 09:21:14 -0700)
----------------------------------------------------------------
Mark xmm registers call-clobbered.
----------------------------------------------------------------
Richard Henderson (1):
tcg/i386: Mark xmm registers call-clobbered
tcg/i386/tcg-target.inc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* Re: [meta-oe][PATCH] perl: native modules will not trigger build perl for target.
From: Andre McCurdy @ 2018-07-23 17:23 UTC (permalink / raw)
To: Krzysztof Taborski; +Cc: OE Core mailing list
In-Reply-To: <CAFmD+WEeyHwEQs825up0Q=yF4n3gvQU-eav3RZdJ9nt5NLECwQ@mail.gmail.com>
On Mon, Jul 23, 2018 at 5:57 AM, Krzysztof Taborski
<taborskikrzysztof@gmail.com> wrote:
> Change was already merged:
> http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-devtools?id=7dd9772eca6df52db09b65537fdf689f1aa3fd8f
>
> Is your request still valid?
Yes, although the change was merged, it's not clear that it was correct.
Native recipes aren't split into packages, so there are no -native
versions of the perl modules. If you have a recipe which depends on
"perl-module-XXX-native" it's likely a bug in that recipe - not in
perl-native.
What recipe did you find which depends on a -native version of a perl module?
> 2018-07-09 21:40 GMT+02:00 Andre McCurdy <armccurdy@gmail.com>:
>>
>> On Wed, May 9, 2018 at 7:16 AM, taborskikrzysztof
>> <taborskikrzysztof@gmail.com> wrote:
>> > Can I request review?
>> > -------- Oryginalna wiadomość --------
>> > Od: Krzysztof Taborski <taborskikrzysztof@gmail.com>
>> > Data: 08.05.2018 18:46 (GMT+01:00)
>> > Do: openembedded-core@lists.openembedded.org
>> > DW: Krzysztof Taborski <taborskikrzysztof@gmail.com>
>> > Temat: [meta-oe][PATCH] perl: native modules will not trigger build perl
>> > for
>> > target.
>> >
>> > Currently building perl-native modules triggers
>> > build perl for target due to PACKAGES_DYNAMIC regex.
>> >
>> > This commit will cause, that perl native modules will
>> > trigger perl-native build.
>>
>> Can you give an example of how to reproduce the problem?
>>
>> > Signed-off-by: Krzysztof Taborski <taborskikrzysztof@gmail.com>
>> > ---
>> > meta/recipes-devtools/perl/perl-native_5.24.1.bb | 2 ++
>> > meta/recipes-devtools/perl/perl_5.24.1.bb | 2 +-
>> > 2 files changed, 3 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/meta/recipes-devtools/perl/perl-native_5.24.1.bb
>> > b/meta/recipes-devtools/perl/perl-native_5.24.1.bb
>> > index a9ab17d16c..71f45890b0 100644
>> > --- a/meta/recipes-devtools/perl/perl-native_5.24.1.bb
>> > +++ b/meta/recipes-devtools/perl/perl-native_5.24.1.bb
>> > @@ -135,3 +135,5 @@ EOF
>> >
>> > # Fix the path in sstate
>> > SSTATE_SCAN_FILES += "*.pm *.pod *.h *.pl *.sh"
>> > +PACKAGES_DYNAMIC_class-native += "^perl-module-.*native$"
>>
>> This usage of += with an over-ride is not correct.
>>
>> However, regardless of that, was this change actually needed?
>>
>> If you know of a -native recipe which depends on a
>> perl-module-XXX-native package then it's probably a bug in the -native
>> recipe. Having perl-native pretend to provide perl-module packages
>> probably isn't the right solution.
>>
>> > diff --git a/meta/recipes-devtools/perl/perl_5.24.1.bb
>> > b/meta/recipes-devtools/perl/perl_5.24.1.bb
>> > index 53a426289a..4c6a71082f 100644
>> > --- a/meta/recipes-devtools/perl/perl_5.24.1.bb
>> > +++ b/meta/recipes-devtools/perl/perl_5.24.1.bb
>> > @@ -339,7 +339,7 @@ python split_perl_packages () {
>> > d.setVar(d.expand("RRECOMMENDS_${PN}-modules"), ' '.join(packages))
>> > }
>> >
>> > -PACKAGES_DYNAMIC += "^perl-module-.*"
>> > +PACKAGES_DYNAMIC += "^perl-module-.*(?<!\-native)$"
>> > PACKAGES_DYNAMIC_class-nativesdk += "^nativesdk-perl-module-.*"
>>
>> This usage of += with an over-ride is not correct.
>>
>> > RPROVIDES_perl-lib = "perl-lib"
>> > --
>> > 2.13.6
>> >
>> >
>> > --
>> > _______________________________________________
>> > Openembedded-core mailing list
>> > Openembedded-core@lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> >
>
>
>
>
> --
> Pozdrawiam,
> Krzysiek Taborski
^ permalink raw reply
* Re: [PATCH] firmware: vpd: Fix section enabled flag on vpd_section_destroy
From: Dmitry Torokhov @ 2018-07-23 17:23 UTC (permalink / raw)
To: Guenter Roeck
Cc: Anton Vasilyev, Greg Kroah-Hartman, Samuel Holland, Pan Bian,
linux-kernel, ldv-project
In-Reply-To: <20180723171336.GA15900@roeck-us.net>
On Mon, Jul 23, 2018 at 10:13:36AM -0700, Guenter Roeck wrote:
> On Mon, Jul 23, 2018 at 07:48:57PM +0300, Anton Vasilyev wrote:
> > static struct ro_vpd and rw_vpd are initialized by vpd_sections_init()
> > in vpd_probe() based on header's ro and rw sizes.
> > In vpd_remove() vpd_section_destroy() performs deinitialization based
> > on enabled flag, which is set to true by vpd_sections_init().
> > This leads to call of vpd_section_destroy() on already destroyed section
> > for probe-release-probe-release sequence if first probe performs
> > ro_vpd initialization and second probe does not initialize it.
> >
>
> I am not sure if the situation described can be seen in the first place.
> The second probe would only not perform ro_vpd initialization if it fails
> prior to that, ie if it fails to allocate memory or if there is a
> consistency problem. In that case the remove function would not be called.
>
> However, there is a problem in the code: A partially failed probe will
> leave the system in inconsistent state. Example: ro section initializes,
> rw section fails to initialize. The probe will fail, but the ro section
> will not be destroyed, its sysfs attributes still exist, and its memory
> is still mapped. It would make more sense to fix _that_ problem.
> Essentially, vpd_sections_init() should clean up after itself after it
> fails to initialize a section.
>
> Note that I am not convinced that the "enabled" flag is needed in the first
> place. It is only relevant if vpd_section_destroy() is called, which only
> happens from the remove function. The remove function is only called if the
> probe function succeeded. In that case it is always set for both sections.
The problem will happen if coreboot memory changes between 2 probes so
that header.ro_size is not 0 on the first pass and is 0 on the second
pass. Not quite likely to ever happen in real life, but resetting a flag
is pretty cheap to not do it.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 08/12] sched/core: uclamp: extend cpu's cgroup controller
From: Patrick Bellasi @ 2018-07-23 17:22 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-kernel, linux-pm, Ingo Molnar, Peter Zijlstra,
Rafael J . Wysocki, Viresh Kumar, Vincent Guittot, Paul Turner,
Dietmar Eggemann, Morten Rasmussen, Juri Lelli, Todd Kjos,
Joel Fernandes, Steve Muckle, Suren Baghdasaryan
In-Reply-To: <20180723153040.GG1934745@devbig577.frc2.facebook.com>
On 23-Jul 08:30, Tejun Heo wrote:
> Hello,
Hi Tejun!
> On Mon, Jul 16, 2018 at 09:29:02AM +0100, Patrick Bellasi wrote:
> > The cgroup's CPU controller allows to assign a specified (maximum)
> > bandwidth to the tasks of a group. However this bandwidth is defined and
> > enforced only on a temporal base, without considering the actual
> > frequency a CPU is running on. Thus, the amount of computation completed
> > by a task within an allocated bandwidth can be very different depending
> > on the actual frequency the CPU is running that task.
> > The amount of computation can be affected also by the specific CPU a
> > task is running on, especially when running on asymmetric capacity
> > systems like Arm's big.LITTLE.
>
> One basic problem I have with this patchset is that what's being
> described is way more generic than what actually got implemented.
> What's described is computation bandwidth control but what's
> implemented is just frequency clamping.
What I meant to describe is that we already have a computation
bandwidth control mechanism which is working quite fine for the
scheduling classes it applies to, i.e. CFS and RT.
For these classes we are usually happy with just a _best effort_
allocation of the bandwidth: nothing enforced in strict terms. Indeed,
there is not (at least not in kernel space) a tracking of the actual
available and allocated bandwidth. If we need strict enforcement, we
already have DL with its CBS servers.
However, the "best effort" bandwidth control we have for CFS and RT
can be further improved if, instead of just looking at time spent on
CPUs, we provide some more hints to the scheduler to know at which
min/max "MIPS" we want to consume the (best effort) time we have been
allocated on a CPU.
Such a simple extension is still quite useful to satisfy many use-case
we have, mainly on mobile systems, like the ones I've described in the
"Newcomer's Short Abstract (Updated)"
section of the cover letter:
https://lore.kernel.org/lkml/20180716082906.6061-1-patrick.bellasi@arm.com/T/#u
> So, there are fundamental discrepancies between
> description+interface vs. what it actually does.
Perhaps then I should just change the description to make it less
generic...
> I really don't think that's something we can fix up later.
... since, really, I don't think we can get to the point to extend
later this interface to provide the strict bandwidth enforcement you
are thinking about.
This would not be a fixup, but something really close to
re-implementing what we already have with the DL class.
> > These attributes:
> >
> > a) are available only for non-root nodes, both on default and legacy
> > hierarchies
> > b) do not enforce any constraints and/or dependency between the parent
> > and its child nodes, thus relying on the delegation model and
> > permission settings defined by the system management software
>
> cgroup does host attributes which only concern the cgroup itself and
> thus don't need any hierarchical behaviors on their own, but what's
> being implemented does control resource allocation,
I'm not completely sure to get your point here.
Maybe it all depends on what we mean by "control resource allocation".
AFAIU, currently both the CFS and RT bandwidth controllers allow you
to define how much CPU time a group of tasks can use. It does that by
looking just within the group: there is no enforced/required relation
between the bandwidth assigned to a group and the bandwidth assigned
to its parent, siblings and/or children.
The resource control allocation is eventually enforced "indirectly" by
means of the fact that, based on tasks priorities and cgroup shares,
the scheduler will prefer to pick and run "more frequently" and
"longer" certain tasks instead of others.
Thus I would say that the resource allocation control is already
performed by the combined action of:
A) priorities / shares to favor certain tasks over others
B) period & bandwidth to further bias the scheduler in _not_ selecting
tasks which already executed for the configured amount of time.
> and what you're describing inherently breaks the delegation model.
What I describe here is just an additional hint to the scheduler which
enrich the above described model. Provided A and B are already
satisfied, when a task gets a chance to run it will be executed at a
min/max configured frequency. That's really all... there is not
additional impact on "resources allocation".
I don't see why you say that this breaks the delegation model?
Maybe an example can help to better explain what you mean?
Best,
Patrick
--
#include <best/regards.h>
Patrick Bellasi
^ permalink raw reply
* Have you read my previous message
From: Lisa Jaster @ 2018-07-23 16:20 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: Type: text/html, Size: 26 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 23/40] target/mips: Implement emulation of nanoMIPS LLWP/SCWP pair
From: Aleksandar Markovic @ 2018-07-23 17:21 UTC (permalink / raw)
To: Richard Henderson, Stefan Markovic, qemu-devel@nongnu.org
Cc: laurent@vivier.eu, riku.voipio@iki.fi,
philippe.mathieu.daude@gmail.com, aurelien@aurel32.net,
Stefan Markovic, Petar Jovanovic, Paul Burton
In-Reply-To: <b2be38da-84b6-904c-a826-1c86fed7e03c@linaro.org>
> From: Richard Henderson <richard.henderson@linaro.org>
> Sent: Saturday, July 21, 2018 8:15 PM
> On 07/19/2018 05:54 AM, Stefan Markovic wrote:
> > From: Yongbok Kim <yongbok.kim@mips.com>
> >
> > Implement nanoMIPS LLWP and SCWP instruction pair.
> >
> > Signed-off-by: Yongbok Kim <yongbok.kim@mips.com>
> > Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
> > Signed-off-by: Stefan Markovic <smarkovic@wavecomp.com>
> > ---
> > linux-user/mips/cpu_loop.c | 25 ++++++++---
> > target/mips/cpu.h | 2 +
> > target/mips/helper.h | 2 +
> > target/mips/op_helper.c | 35 +++++++++++++++
> > target/mips/translate.c | 107 +++++++++++++++++++++++++++++++++++++++++++++
> > 5 files changed, 166 insertions(+), 5 deletions(-)
>
> Hmm. Well, it's ok as far as it goes, but I'd really really like to see
> target/mips to be updated to use actual atomic operations. Otherwise
> mips*-linux-user will never be reliable and mips*-softmmu cannot run SMP in
> multi-threaded mode.
>
> While converting the rest of target/mips to atomic operations is perhaps out of
> scope for this patch set, there's really no reason not to do these two
> instructions correctly from the start. It'll save the trouble of rewriting
> them from scratch later.
>
> Please see target/arm/translate.c, gen_load_exclusive and gen_store_exclusive,
> for the size == 3 case. That is arm32 doing a 64-bit "paired" atomic
> operation, just like you are attempting here.
>
> Note that single-copy atomic semantics apply in both cases, so LLWP must
> perform one 64-bit load, not two 32-bit loads. The store in SCWP must happen
> with a 64-bit atomic cmpxchg operation.
>
>
> r~
Hi, Richard.
The improved version of this patch, that addresses the concerns you mentioned, may be included in the next version of this series, which is scheduled to be sent in next few days.
The reason we are a little sluggish with response to your reviews is that we are still completing functionality (mostly linux-user-related). However, we'll focus on the interaction with reviewers as soon as we are out of that phase.
Regards,
Aleksandar
^ permalink raw reply
* [PATCH] drm/i915: Skip repeated calls to i915_gem_set_wedged()
From: Chris Wilson @ 2018-07-23 17:21 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20180723145335.24579-1-chris@chris-wilson.co.uk>
If we already wedged, i915_gem_set_wedged() becomes a complicated no-op.
v2: Make sure the double set-wedged is synchronous, a parallel call
should not return before the driver is indeed wedged.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107343
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_gem.c | 26 ++++++++++++++++++++++----
drivers/gpu/drm/i915/i915_gpu_error.h | 3 ++-
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8b52cb768a67..99c91c7ad46c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3298,12 +3298,24 @@ static void nop_complete_submit_request(struct i915_request *request)
spin_unlock_irqrestore(&request->engine->timeline.lock, flags);
}
+static void wait_for_wedged(struct drm_i915_private *i915)
+{
+ struct i915_gpu_error *error = &i915->gpu_error;
+ DEFINE_WAIT_BIT(wq_entry, &error->flags, I915_WEDGED);
+
+ __wait_on_bit(&error->reset_queue,
+ &wq_entry, bit_wait, TASK_UNINTERRUPTIBLE);
+}
+
void i915_gem_set_wedged(struct drm_i915_private *i915)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
- GEM_TRACE("start\n");
+ if (test_and_set_bit(I915_WEDGE_IN_PROGRESS, &i915->gpu_error.flags)) {
+ wait_for_wedged(i915);
+ return;
+ }
if (GEM_SHOW_DEBUG()) {
struct drm_printer p = drm_debug_printer(__func__);
@@ -3312,8 +3324,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
intel_engine_dump(engine, &p, "%s\n", engine->name);
}
- set_bit(I915_WEDGED, &i915->gpu_error.flags);
- smp_mb__after_atomic();
+ GEM_TRACE("start\n");
/*
* First, stop submission to hw, but do not yet complete requests by
@@ -3372,6 +3383,9 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
i915_gem_reset_finish_engine(engine);
}
+ smp_mb__before_atomic();
+ set_bit(I915_WEDGED, &i915->gpu_error.flags);
+
GEM_TRACE("end\n");
wake_up_all(&i915->gpu_error.reset_queue);
@@ -3379,10 +3393,14 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
bool i915_gem_unset_wedged(struct drm_i915_private *i915)
{
+ struct i915_gpu_error *error = &i915->gpu_error;
struct i915_timeline *tl;
lockdep_assert_held(&i915->drm.struct_mutex);
- if (!test_bit(I915_WEDGED, &i915->gpu_error.flags))
+
+ while (test_and_clear_bit(I915_WEDGE_IN_PROGRESS, &error->flags))
+ wait_for_wedged(i915);
+ if (!test_bit(I915_WEDGE_IN_PROGRESS, &error->flags))
return true;
GEM_TRACE("start\n");
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h b/drivers/gpu/drm/i915/i915_gpu_error.h
index f893a4e8b783..1a78a8f330f2 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -267,8 +267,9 @@ struct i915_gpu_error {
#define I915_RESET_BACKOFF 0
#define I915_RESET_HANDOFF 1
#define I915_RESET_MODESET 2
+#define I915_RESET_ENGINE 3
#define I915_WEDGED (BITS_PER_LONG - 1)
-#define I915_RESET_ENGINE (I915_WEDGED - I915_NUM_ENGINES)
+#define I915_WEDGE_IN_PROGRESS (I915_WEDGED - 1)
/** Number of times an engine has been reset */
u32 reset_engine_count[I915_NUM_ENGINES];
--
2.18.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [PATCH v1 0/2] mm/kdump: exclude reserved pages in dumps
From: David Hildenbrand @ 2018-07-23 17:20 UTC (permalink / raw)
To: Michal Hocko, Vlastimil Babka
Cc: linux-mm, linux-kernel, Andrew Morton, Baoquan He, Dave Young,
Greg Kroah-Hartman, Hari Bathini, Huang Ying, Kirill A. Shutemov,
Marc-André Lureau, Matthew Wilcox, Miles Chen,
Pavel Tatashin, Petr Tesarik
In-Reply-To: <20180723123043.GD31229@dhcp22.suse.cz>
On 23.07.2018 14:30, Michal Hocko wrote:
> On Mon 23-07-18 13:45:18, Vlastimil Babka wrote:
>> On 07/20/2018 02:34 PM, David Hildenbrand wrote:
>>> Dumping tools (like makedumpfile) right now don't exclude reserved pages.
>>> So reserved pages might be access by dump tools although nobody except
>>> the owner should touch them.
>>
>> Are you sure about that? Or maybe I understand wrong. Maybe it changed
>> recently, but IIRC pages that are backing memmap (struct pages) are also
>> PG_reserved. And you definitely do want those in the dump.
>
> You are right. reserve_bootmem_region will make all early bootmem
> allocations (including those backing memmaps) PageReserved. I have asked
> several times but I haven't seen a satisfactory answer yet. Why do we
> even care for kdump about those. If they are reserved the nobody should
> really look at those specific struct pages and manipulate them. Kdump
> tools are using a kernel interface to read the content. If the specific
> content is backed by a non-existing memory then they should simply not
> return anything.
>
"new kernel" provides an interface to read memory from "old kernel".
The new kernel has no idea about
- which memory was added/online in the old kernel
- where struct pages of the old kernel are and what their content is
- which memory is save to touch and which not
Dump tools figure all that out by interpreting the VMCORE. They e.g.
identify "struct pages" and see if they should be dumped. The "new
kernel" only allows to read that memory. It cannot hinder to crash the
system (e.g. if a dump tool would try to read a hwpoison page).
So how should the "new kernel" know if a page can be touched or not?
The *only* way would be to have an interface to the hypervisor where we
"sense" if a memory location is safe to touch. I remember that xen or
hyper-v does that - they fake a zero page in that case, after querying
the hypervisor. But this does not sound like a clean approach to me,
especially es we need yet another hypervisor interface to sense for
memory provided via "some" device.
If we can find a way to just tag pages as "don't touch", it would be the
easiest and cleanest solution in my opinion.
--
Thanks,
David / dhildenb
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.