This changes kcmp_epoll_target to use the new exec_update_mutex
instead of cred_guard_mutex.
This should be safe, as the credentials are only used for reading,
and furthermore ->mm and ->sighand are updated on execve,
but only under the new exec_update_mutex.
Signed-off-by: Bernd Edlinger <bernd.edlinger(a)hotmail.de>
---
kernel/kcmp.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/kcmp.c b/kernel/kcmp.c
index a0e3d7a..b3ff928 100644
--- a/kernel/kcmp.c
+++ b/kernel/kcmp.c
@@ -173,8 +173,8 @@ static int kcmp_epoll_target(struct task_struct *task1,
/*
* One should have enough rights to inspect task details.
*/
- ret = kcmp_lock(&task1->signal->cred_guard_mutex,
- &task2->signal->cred_guard_mutex);
+ ret = kcmp_lock(&task1->signal->exec_update_mutex,
+ &task2->signal->exec_update_mutex);
if (ret)
goto err;
if (!ptrace_may_access(task1, PTRACE_MODE_READ_REALCREDS) ||
@@ -229,8 +229,8 @@ static int kcmp_epoll_target(struct task_struct *task1,
}
err_unlock:
- kcmp_unlock(&task1->signal->cred_guard_mutex,
- &task2->signal->cred_guard_mutex);
+ kcmp_unlock(&task1->signal->exec_update_mutex,
+ &task2->signal->exec_update_mutex);
err:
put_task_struct(task1);
put_task_struct(task2);
--
1.9.1
This changes __pidfd_fget to use the new exec_update_mutex
instead of cred_guard_mutex.
This should be safe, as the credentials do not change
before exec_update_mutex is locked. Therefore whatever
file access is possible with holding the cred_guard_mutex
here is also possbile with the exec_update_mutex.
Signed-off-by: Bernd Edlinger <bernd.edlinger(a)hotmail.de>
---
kernel/pid.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/pid.c b/kernel/pid.c
index 0f4ecb5..04821f4 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -584,7 +584,7 @@ static struct file *__pidfd_fget(struct task_struct *task, int fd)
struct file *file;
int ret;
- ret = mutex_lock_killable(&task->signal->cred_guard_mutex);
+ ret = mutex_lock_killable(&task->signal->exec_update_mutex);
if (ret)
return ERR_PTR(ret);
@@ -593,7 +593,7 @@ static struct file *__pidfd_fget(struct task_struct *task, int fd)
else
file = ERR_PTR(-EPERM);
- mutex_unlock(&task->signal->cred_guard_mutex);
+ mutex_unlock(&task->signal->exec_update_mutex);
return file ?: ERR_PTR(-EBADF);
}
--
1.9.1
Hi,
Tools like sar and iostat are reporting abnormally high %util with 4.19.y
running in VM (the disk is almost idle):
$ sar -dp
Linux 4.19.107-1.x86_64 03/25/20 _x86_64_ (6 CPU)
00:00:00 DEV tps ... %util
00:10:00 vda 0.55 ... 98.07
...
10:00:00 vda 0.44 ... 99.74
Average: vda 0.48 ... 98.98
The numbers look reasonable for the partition:
# iostat -x -p ALL 1 1
Linux 4.19.107-1.x86_64 03/25/20 _x86_64_ (6 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
10.51 0.00 8.58 0.05 0.11 80.75
Device r/s ... %util
vda 0.02 ... 98.25
vda1 0.01 ... 0.09
Lots of io_ticks in /proc/diskstats:
# cat /proc/uptime
45787.03 229321.29
# grep vda /proc/diskstats
253 0 vda 760 0 38498 731 28165 43212 1462928 157514 0 44690263
44812032 0 0 0 0
253 1 vda1 350 0 19074 293 26169 43212 1462912 154931 0 41560 150998
0 0 0 0
Other people are apparently seeing this too with 4.19:
https://kudzia.eu/b/2019/09/iostat-x-1-reporting-100-utilization-of-nearly-…
I also see this only in 4.19.y and bisected to this (based on the Fixes
tag, this should have been taken to 4.14 too...):
commit 6131837b1de66116459ef4413e26fdbc70d066dc
Author: Omar Sandoval <osandov(a)fb.com>
Date: Thu Apr 26 00:21:58 2018 -0700
blk-mq: count allocated but not started requests in iostats inflight
In the legacy block case, we increment the counter right after we
allocate the request, not when the driver handles it. In both the legacy
and blk-mq cases, part_inc_in_flight() is called from
blk_account_io_start() right after we've allocated the request. blk-mq
only considers requests started requests as inflight, but this is
inconsistent with the legacy definition and the intention in the code.
This removes the started condition and instead counts all allocated
requests.
Fixes: f299b7c7a9de ("blk-mq: provide internal in-flight variant")
Signed-off-by: Omar Sandoval <osandov(a)fb.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
diff --git a/block/blk-mq.c b/block/blk-mq.c
index c3621453ad87..5450cbc61f8d 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -95,18 +95,15 @@ static void blk_mq_check_inflight(struct blk_mq_hw_ctx
*hctx,
{
struct mq_inflight *mi = priv;
- if (blk_mq_rq_state(rq) == MQ_RQ_IN_FLIGHT) {
- /*
- * index[0] counts the specific partition that was asked
- * for. index[1] counts the ones that are active on the
- * whole device, so increment that if mi->part is indeed
- * a partition, and not a whole device.
- */
- if (rq->part == mi->part)
- mi->inflight[0]++;
- if (mi->part->partno)
- mi->inflight[1]++;
- }
+ /*
+ * index[0] counts the specific partition that was asked for.
index[1]
+ * counts the ones that are active on the whole device, so
increment
+ * that if mi->part is indeed a partition, and not a whole device.
+ */
+ if (rq->part == mi->part)
+ mi->inflight[0]++;
+ if (mi->part->partno)
+ mi->inflight[1]++;
}
void blk_mq_in_flight(struct request_queue *q, struct hd_struct *part,
If I get it right, when the disk is idle, and some request is allocated,
part_round_stats() with this commit will now add all ticks between
previous I/O and current time (now - part->stamp) to io_ticks.
Before the commit, part_round_stats() would only update part->stamp when
called after request allocation.
Any thoughts how to best fix this in 4.19?
I see the io_ticks accounting has been reworked in 5.0, do we need to
backport those to 4.19, or any ill effects if this commit is reverted in
4.19?
-Tommi
Hi
[This is an automated email]
The bot has tested the following trees: v5.5.11, v5.4.27, v4.19.112, v4.14.174, v4.9.217, v4.4.217.
v5.5.11: Build OK!
v5.4.27: Build OK!
v4.19.112: Failed to apply! Possible dependencies:
1863d77f15da ("SUNRPC: Replace the cache_detail->hash_lock with a regular spinlock")
v4.14.174: Failed to apply! Possible dependencies:
1863d77f15da ("SUNRPC: Replace the cache_detail->hash_lock with a regular spinlock")
v4.9.217: Failed to apply! Possible dependencies:
1863d77f15da ("SUNRPC: Replace the cache_detail->hash_lock with a regular spinlock")
2b477c00f3bd ("svcrpc: free contexts immediately on PROC_DESTROY")
471a930ad7d1 ("SUNRPC: Drop all entries from cache_detail when cache_purge()")
v4.4.217: Failed to apply! Possible dependencies:
1863d77f15da ("SUNRPC: Replace the cache_detail->hash_lock with a regular spinlock")
2b477c00f3bd ("svcrpc: free contexts immediately on PROC_DESTROY")
471a930ad7d1 ("SUNRPC: Drop all entries from cache_detail when cache_purge()")
d8d29138b17c ("sunrpc: remove 'inuse' flag from struct cache_detail.")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha