This is a note to let you know that I've just added the patch titled
io_uring: no need to call xa_destroy() on empty xarray
to the 5.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
io_uring-no-need-to-call-xa_destroy-on-empty-xarray.patch
and it can be found in the queue-5.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From foo@baz Thu Oct 29 01:16:54 PM CET 2020
From: Jens Axboe <axboe@xxxxxxxxx>
Date: Thu, 8 Oct 2020 07:46:52 -0600
Subject: io_uring: no need to call xa_destroy() on empty xarray
From: Jens Axboe <axboe@xxxxxxxxx>
commit ca6484cd308a671811bf39f3119e81966eb476e3 upstream.
The kernel test robot reports this lockdep issue:
[child1:659] mbind (274) returned ENOSYS, marking as inactive.
[child1:659] mq_timedsend (279) returned ENOSYS, marking as inactive.
[main] 10175 iterations. [F:7781 S:2344 HI:2397]
[ 24.610601]
[ 24.610743] ================================
[ 24.611083] WARNING: inconsistent lock state
[ 24.611437] 5.9.0-rc7-00017-g0f2122045b9462 #5 Not tainted
[ 24.611861] --------------------------------
[ 24.612193] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 24.612660] ksoftirqd/0/7 [HC0[0]:SC1[3]:HE0:SE0] takes:
[ 24.613086] f00ed998 (&xa->xa_lock#4){+.?.}-{2:2}, at: xa_destroy+0x43/0xc1
[ 24.613642] {SOFTIRQ-ON-W} state was registered at:
[ 24.614024] lock_acquire+0x20c/0x29b
[ 24.614341] _raw_spin_lock+0x21/0x30
[ 24.614636] io_uring_add_task_file+0xe8/0x13a
[ 24.614987] io_uring_create+0x535/0x6bd
[ 24.615297] io_uring_setup+0x11d/0x136
[ 24.615606] __ia32_sys_io_uring_setup+0xd/0xf
[ 24.615977] do_int80_syscall_32+0x53/0x6c
[ 24.616306] restore_all_switch_stack+0x0/0xb1
[ 24.616677] irq event stamp: 939881
[ 24.616968] hardirqs last enabled at (939880): [<8105592d>] __local_bh_enable_ip+0x13c/0x145
[ 24.617642] hardirqs last disabled at (939881): [<81b6ace3>] _raw_spin_lock_irqsave+0x1b/0x4e
[ 24.618321] softirqs last enabled at (939738): [<81b6c7c8>] __do_softirq+0x3f0/0x45a
[ 24.618924] softirqs last disabled at (939743): [<81055741>] run_ksoftirqd+0x35/0x61
[ 24.619521]
[ 24.619521] other info that might help us debug this:
[ 24.620028] Possible unsafe locking scenario:
[ 24.620028]
[ 24.620492] CPU0
[ 24.620685] ----
[ 24.620894] lock(&xa->xa_lock#4);
[ 24.621168] <Interrupt>
[ 24.621381] lock(&xa->xa_lock#4);
[ 24.621695]
[ 24.621695] *** DEADLOCK ***
[ 24.621695]
[ 24.622154] 1 lock held by ksoftirqd/0/7:
[ 24.622468] #0: 823bfb94 (rcu_callback){....}-{0:0}, at: rcu_process_callbacks+0xc0/0x155
[ 24.623106]
[ 24.623106] stack backtrace:
[ 24.623454] CPU: 0 PID: 7 Comm: ksoftirqd/0 Not tainted 5.9.0-rc7-00017-g0f2122045b9462 #5
[ 24.624090] Call Trace:
[ 24.624284] ? show_stack+0x40/0x46
[ 24.624551] dump_stack+0x1b/0x1d
[ 24.624809] print_usage_bug+0x17a/0x185
[ 24.625142] mark_lock+0x11d/0x1db
[ 24.625474] ? print_shortest_lock_dependencies+0x121/0x121
[ 24.625905] __lock_acquire+0x41e/0x7bf
[ 24.626206] lock_acquire+0x20c/0x29b
[ 24.626517] ? xa_destroy+0x43/0xc1
[ 24.626810] ? lock_acquire+0x20c/0x29b
[ 24.627110] _raw_spin_lock_irqsave+0x3e/0x4e
[ 24.627450] ? xa_destroy+0x43/0xc1
[ 24.627725] xa_destroy+0x43/0xc1
[ 24.627989] __io_uring_free+0x57/0x71
[ 24.628286] ? get_pid+0x22/0x22
[ 24.628544] __put_task_struct+0xf2/0x163
[ 24.628865] put_task_struct+0x1f/0x2a
[ 24.629161] delayed_put_task_struct+0xe2/0xe9
[ 24.629509] rcu_process_callbacks+0x128/0x155
[ 24.629860] __do_softirq+0x1a3/0x45a
[ 24.630151] run_ksoftirqd+0x35/0x61
[ 24.630443] smpboot_thread_fn+0x304/0x31a
[ 24.630763] kthread+0x124/0x139
[ 24.631016] ? sort_range+0x18/0x18
[ 24.631290] ? kthread_create_worker_on_cpu+0x17/0x17
[ 24.631682] ret_from_fork+0x1c/0x28
which is complaining about xa_destroy() grabbing the xa lock in an
IRQ disabling fashion, whereas the io_uring uses cases aren't interrupt
safe. This is really an xarray issue, since it should not assume the
lock type. But for our use case, since we know the xarray is empty at
this point, there's no need to actually call xa_destroy(). So just get
rid of it.
Fixes: 0f2122045b94 ("io_uring: don't rely on weak ->files references")
Reported-by: kernel test robot <lkp@xxxxxxxxx>
Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
fs/io_uring.c | 1 -
1 file changed, 1 deletion(-)
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -7136,7 +7136,6 @@ void __io_uring_free(struct task_struct
struct io_uring_task *tctx = tsk->io_uring;
WARN_ON_ONCE(!xa_empty(&tctx->xa));
- xa_destroy(&tctx->xa);
kfree(tctx);
tsk->io_uring = NULL;
}
Patches currently in stable-queue which might be from axboe@xxxxxxxxx are
queue-5.8/io_uring-convert-advanced-xarray-uses-to-the-normal-api.patch
queue-5.8/io_uring-don-t-run-task-work-on-an-exiting-task.patch
queue-5.8/io_uring-reference-nsproxy-for-file-table-commands.patch
queue-5.8/io_uring-stash-ctx-task-reference-for-sqpoll.patch
queue-5.8/io_uring-return-cancelation-status-from-poll-timeout-files-handlers.patch
queue-5.8/io_uring-fix-xarray-usage-in-io_uring_add_task_file.patch
queue-5.8/io_uring-fix-use-of-xarray-in-__io_uring_files_cancel.patch
queue-5.8/io-wq-fix-use-after-free-in-io_wq_worker_running.patch
queue-5.8/io_uring-don-t-rely-on-weak-files-references.patch
queue-5.8/io_uring-allow-timeout-poll-files-killing-to-take-task-into-account.patch
queue-5.8/io_uring-move-dropping-of-files-into-separate-helper.patch
queue-5.8/io_uring-unconditionally-grab-req-task.patch
queue-5.8/io_uring-enable-task-files-specific-overflow-flushing.patch
queue-5.8/io_wq-make-io_wqe-lock-a-raw_spinlock_t.patch
queue-5.8/io_uring-no-need-to-call-xa_destroy-on-empty-xarray.patch
