summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* arch: setup PF_IO_WORKER threads like PF_KTHREADJens Axboe2021-02-2122-22/+22
| | | | | | | | | PF_IO_WORKER are kernel threads too, but they aren't PF_KTHREAD in the sense that we don't assign ->set_child_tid with our own structure. Just ensure that every arch sets up the PF_IO_WORKER threads like kthreads in the arch implementation of copy_thread(). Signed-off-by: Jens Axboe <axboe@kernel.dk>
* io-wq: don't pass 'wqe' needlessly aroundJens Axboe2021-02-211-15/+16
| | | | | | Just grab it from the worker itself, which we're already passing in. Signed-off-by: Jens Axboe <axboe@kernel.dk>
* io_uring: tie async worker side to the task contextJens Axboe2021-02-212-50/+35
| | | | | | | Move it outside of the io_ring_ctx, and tie it to the io_uring task context. Signed-off-by: Jens Axboe <axboe@kernel.dk>
* io-wq: get rid of wq->use_refsJens Axboe2021-02-212-19/+1
| | | | | | | We don't support attach anymore, so doesn't make sense to carry the use_refs reference count. Get rid of it. Signed-off-by: Jens Axboe <axboe@kernel.dk>
* io_uring: disable io-wq attachingJens Axboe2021-02-211-33/+22
| | | | | | | | | | | | Moving towards making the io_wq per ring per task, so we can't really share it between rings. Which is fine, since we've now dropped some of that fat from it. Retain compatibility with how attaching works, so that any attempt to attach to an fd that doesn't exist, or isn't an io_uring fd, will fail like it did before. Signed-off-by: Jens Axboe <axboe@kernel.dk>
* io-wq: don't create any IO workers upfrontJens Axboe2021-02-211-12/+0
| | | | | | | | When the manager thread starts up, it creates a worker per node for the given context. Just let these get created dynamically, like we do for adding further workers. Signed-off-by: Jens Axboe <axboe@kernel.dk>
* io_uring: remove the need for relying on an io-wq fallback workerJens Axboe2021-02-213-17/+34
| | | | | | | | | We hit this case when the task is exiting, and we need somewhere to do background cleanup of requests. Instead of relying on the io-wq task manager to do this work for us, just stuff it somewhere where we can safely run it ourselves directly. Signed-off-by: Jens Axboe <axboe@kernel.dk>
* Merge branch 'for-5.12/io_uring' into io_uring-worker.v3Jens Axboe2021-02-211-342/+347
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * for-5.12/io_uring: (21 commits) io_uring: run task_work on io_uring_register() io_uring: fix leaving invalid req->flags io_uring: wait potential ->release() on resurrect io_uring: keep generic rsrc infra generic io_uring: zero ref_node after killing it io_uring: make the !CONFIG_NET helpers a bit more robust io_uring: don't hold uring_lock when calling io_run_task_work* io_uring: fail io-wq submission from a task_work io_uring: don't take uring_lock during iowq cancel io_uring: fail links more in io_submit_sqe() io_uring: don't do async setup for links' heads io_uring: do io_*_prep() early in io_submit_sqe() io_uring: split sqe-prep and async setup io_uring: don't submit link on error io_uring: move req link into submit_state io_uring: move io_init_req() into io_submit_sqe() io_uring: move io_init_req()'s definition io_uring: don't duplicate ->file check in sfr io_uring: keep io_*_prep() naming consistent io_uring: kill fictitious submit iteration index ...
| * io_uring: run task_work on io_uring_register()Pavel Begunkov2021-02-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | Do run task_work before io_uring_register(), that might make a first quiesce round much nicer. We generally do that for any syscall invocation to avoid spurious -EINTR/-ERESTARTSYS, for task_work that we generate. This patch brings io_uring_register() inline with the two other io_uring syscalls. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: fix leaving invalid req->flagsPavel Begunkov2021-02-201-1/+3
| | | | | | | | | | | | | | | | | | sqe->flags are subset of req flags, so incorrectly copied may span into in-kernel flags and wreck havoc, e.g. by setting REQ_F_INFLIGHT. Fixes: 5be9ad1e4287e ("io_uring: optimise io_init_req() flags setting") Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: wait potential ->release() on resurrectPavel Begunkov2021-02-201-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | There is a short window where percpu_refs are already turned zero, but we try to do resurrect(). Play nicer and wait for ->release() to happen in this case and proceed as everything is ok. One downside for ctx refs is that we can ignore signal_pending() on a rare occasion, but someone else should check for it later if needed. Cc: <stable@vger.kernel.org> # 5.5+ Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: keep generic rsrc infra genericPavel Begunkov2021-02-201-19/+13
| | | | | | | | | | | | | | | | | | | | io_rsrc_ref_quiesce() is a generic resource function, though now it was wired to allocate and initialise ref nodes with file-specific callbacks/etc. Keep it sane by passing in as a parameters everything we need for initialisations, otherwise it will hurt us badly one day. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: zero ref_node after killing itPavel Begunkov2021-02-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | After a rsrc/files reference node's refs are killed, it must never be used. And that's how it works, it either assigns a new node or kills the whole data table. Let's explicitly NULL it, that shouldn't be necessary, but if something would go wrong I'd rather catch a NULL dereference to using a dangling pointer. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: make the !CONFIG_NET helpers a bit more robustJens Axboe2021-02-201-50/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the prep and prep async split, we now have potentially 3 helpers that need to be defined for !CONFIG_NET. Add some helpers to do just that. Fixes the following compile error on !CONFIG_NET: fs/io_uring.c:6171:10: error: implicit declaration of function 'io_sendmsg_prep_async'; did you mean 'io_req_prep_async'? [-Werror=implicit-function-declaration] return io_sendmsg_prep_async(req); ^~~~~~~~~~~~~~~~~~~~~ io_req_prep_async Fixes: 93642ef88434 ("io_uring: split sqe-prep and async setup") Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: don't hold uring_lock when calling io_run_task_work*Hao Xu2021-02-201-17/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Abaci reported the below issue: [ 141.400455] hrtimer: interrupt took 205853 ns [ 189.869316] process 'usr/local/ilogtail/ilogtail_0.16.26' started with executable stack [ 250.188042] [ 250.188327] ============================================ [ 250.189015] WARNING: possible recursive locking detected [ 250.189732] 5.11.0-rc4 #1 Not tainted [ 250.190267] -------------------------------------------- [ 250.190917] a.out/7363 is trying to acquire lock: [ 250.191506] ffff888114dbcbe8 (&ctx->uring_lock){+.+.}-{3:3}, at: __io_req_task_submit+0x29/0xa0 [ 250.192599] [ 250.192599] but task is already holding lock: [ 250.193309] ffff888114dbfbe8 (&ctx->uring_lock){+.+.}-{3:3}, at: __x64_sys_io_uring_register+0xad/0x210 [ 250.194426] [ 250.194426] other info that might help us debug this: [ 250.195238] Possible unsafe locking scenario: [ 250.195238] [ 250.196019] CPU0 [ 250.196411] ---- [ 250.196803] lock(&ctx->uring_lock); [ 250.197420] lock(&ctx->uring_lock); [ 250.197966] [ 250.197966] *** DEADLOCK *** [ 250.197966] [ 250.198837] May be due to missing lock nesting notation [ 250.198837] [ 250.199780] 1 lock held by a.out/7363: [ 250.200373] #0: ffff888114dbfbe8 (&ctx->uring_lock){+.+.}-{3:3}, at: __x64_sys_io_uring_register+0xad/0x210 [ 250.201645] [ 250.201645] stack backtrace: [ 250.202298] CPU: 0 PID: 7363 Comm: a.out Not tainted 5.11.0-rc4 #1 [ 250.203144] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 250.203887] Call Trace: [ 250.204302] dump_stack+0xac/0xe3 [ 250.204804] __lock_acquire+0xab6/0x13a0 [ 250.205392] lock_acquire+0x2c3/0x390 [ 250.205928] ? __io_req_task_submit+0x29/0xa0 [ 250.206541] __mutex_lock+0xae/0x9f0 [ 250.207071] ? __io_req_task_submit+0x29/0xa0 [ 250.207745] ? 0xffffffffa0006083 [ 250.208248] ? __io_req_task_submit+0x29/0xa0 [ 250.208845] ? __io_req_task_submit+0x29/0xa0 [ 250.209452] ? __io_req_task_submit+0x5/0xa0 [ 250.210083] __io_req_task_submit+0x29/0xa0 [ 250.210687] io_async_task_func+0x23d/0x4c0 [ 250.211278] task_work_run+0x89/0xd0 [ 250.211884] io_run_task_work_sig+0x50/0xc0 [ 250.212464] io_sqe_files_unregister+0xb2/0x1f0 [ 250.213109] __io_uring_register+0x115a/0x1750 [ 250.213718] ? __x64_sys_io_uring_register+0xad/0x210 [ 250.214395] ? __fget_files+0x15a/0x260 [ 250.214956] __x64_sys_io_uring_register+0xbe/0x210 [ 250.215620] ? trace_hardirqs_on+0x46/0x110 [ 250.216205] do_syscall_64+0x2d/0x40 [ 250.216731] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 250.217455] RIP: 0033:0x7f0fa17e5239 [ 250.218034] Code: 01 00 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 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 3d 01 f0 ff ff 73 01 c3 48 8b 0d 27 ec 2c 00 f7 d8 64 89 01 48 [ 250.220343] RSP: 002b:00007f0fa1eeac48 EFLAGS: 00000246 ORIG_RAX: 00000000000001ab [ 250.221360] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0fa17e5239 [ 250.222272] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 0000000000000008 [ 250.223185] RBP: 00007f0fa1eeae20 R08: 0000000000000000 R09: 0000000000000000 [ 250.224091] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 250.224999] R13: 0000000000021000 R14: 0000000000000000 R15: 00007f0fa1eeb700 This is caused by calling io_run_task_work_sig() to do work under uring_lock while the caller io_sqe_files_unregister() already held uring_lock. To fix this issue, briefly drop uring_lock when calling io_run_task_work_sig(), and there are two things to concern: - hold uring_lock in io_ring_ctx_free() around io_sqe_files_unregister() this is for consistency of lock/unlock. - add new fixed rsrc ref node before dropping uring_lock it's not safe to do io_uring_enter-->percpu_ref_get() with a dying one. - check if rsrc_data->refs is dying to avoid parallel io_sqe_files_unregister Reported-by: Abaci <abaci@linux.alibaba.com> Fixes: 1ffc54220c44 ("io_uring: fix io_sqe_files_unregister() hangs") Suggested-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Hao Xu <haoxu@linux.alibaba.com> [axboe: fixes from Pavel folded in] Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: fail io-wq submission from a task_workPavel Begunkov2021-02-201-30/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | In case of failure io_wq_submit_work() needs to post an CQE and so potentially take uring_lock. The safest way to deal with it is to do that from under task_work where we can safely take the lock. Also, as io_iopoll_check() holds the lock tight and releases it reluctantly, it will play nicer in the furuter with notifying an iopolling task about new such pending failed requests. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: don't take uring_lock during iowq cancelPavel Begunkov2021-02-181-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ 97.866748] a.out/2890 is trying to acquire lock: [ 97.867829] ffff8881046763e8 (&ctx->uring_lock){+.+.}-{3:3}, at: io_wq_submit_work+0x155/0x240 [ 97.869735] [ 97.869735] but task is already holding lock: [ 97.871033] ffff88810dfe0be8 (&ctx->uring_lock){+.+.}-{3:3}, at: __x64_sys_io_uring_enter+0x3f0/0x5b0 [ 97.873074] [ 97.873074] other info that might help us debug this: [ 97.874520] Possible unsafe locking scenario: [ 97.874520] [ 97.875845] CPU0 [ 97.876440] ---- [ 97.877048] lock(&ctx->uring_lock); [ 97.877961] lock(&ctx->uring_lock); [ 97.878881] [ 97.878881] *** DEADLOCK *** [ 97.878881] [ 97.880341] May be due to missing lock nesting notation [ 97.880341] [ 97.881952] 1 lock held by a.out/2890: [ 97.882873] #0: ffff88810dfe0be8 (&ctx->uring_lock){+.+.}-{3:3}, at: __x64_sys_io_uring_enter+0x3f0/0x5b0 [ 97.885108] [ 97.885108] stack backtrace: [ 97.890457] Call Trace: [ 97.891121] dump_stack+0xac/0xe3 [ 97.891972] __lock_acquire+0xab6/0x13a0 [ 97.892940] lock_acquire+0x2c3/0x390 [ 97.894894] __mutex_lock+0xae/0x9f0 [ 97.901101] io_wq_submit_work+0x155/0x240 [ 97.902112] io_wq_cancel_cb+0x162/0x490 [ 97.904126] io_async_find_and_cancel+0x3b/0x140 [ 97.905247] io_issue_sqe+0x86d/0x13e0 [ 97.909122] __io_queue_sqe+0x10b/0x550 [ 97.913971] io_queue_sqe+0x235/0x470 [ 97.914894] io_submit_sqes+0xcce/0xf10 [ 97.917872] __x64_sys_io_uring_enter+0x3fb/0x5b0 [ 97.921424] do_syscall_64+0x2d/0x40 [ 97.922329] entry_SYSCALL_64_after_hwframe+0x44/0xa9 While holding uring_lock, e.g. from inline execution, async cancel request may attempt cancellations through io_wq_submit_work, which may try to grab a lock. Delay it to task_work, so we do it from a clean context and don't have to worry about locking. Cc: <stable@vger.kernel.org> # 5.5+ Fixes: c07e6719511e ("io_uring: hold uring_lock while completing failed polled io in io_wq_submit_work()") Reported-by: Abaci <abaci@linux.alibaba.com> Reported-by: Hao Xu <haoxu@linux.alibaba.com> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: fail links more in io_submit_sqe()Pavel Begunkov2021-02-181-13/+8
| | | | | | | | | | | | | | | | | | | | Instead of marking a link with REQ_F_FAIL_LINK on an error and delaying its failing to the caller, do it eagerly right when after getting an error in io_submit_sqe(). This renders FAIL_LINK checks in io_queue_link_head() useless and we can skip it. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: don't do async setup for links' headsPavel Begunkov2021-02-181-3/+0
| | | | | | | | | | | | | | | | | | Now, as we can do async setup without holding an SQE, we can skip doing io_req_defer_prep() for link heads, it will be tried to be executed inline and follows all the rules of the non-linked requests. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: do io_*_prep() early in io_submit_sqe()Pavel Begunkov2021-02-181-35/+24
| | | | | | | | | | | | | | | | | | | | Now as preparations are split from async setup, we can do the first one pretty early not spilling it across multiple call sites. And after it's done SQE is not needed anymore and we can save on passing it deeply into the submission stack. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: split sqe-prep and async setupPavel Begunkov2021-02-181-50/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two kinds of opcode-specific preparations we do. The first is just initialising req with what is always needed for an opcode and reading all non-generic SQE fields. And the second is copying some of the stuff like iovec preparing to punt a request to somewhere async, e.g. to io-wq or for draining. For requests that have tried an inline execution but still needing to be punted, the second prep type is done by the opcode handler itself. Currently, we don't explicitly split those preparation steps, but combining both of them into io_*_prep(), altering the behaviour by allocating ->async_data. That's pretty messy and hard to follow and also gets in the way of some optimisations. Split the steps, leave the first type as where it is now, and put the second into a new io_req_prep_async() helper. It may make us to do opcode switch twice, but it's worth it. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: don't submit link on errorPavel Begunkov2021-02-181-4/+4
| | | | | | | | | | | | | | | | | | If we get an error in io_init_req() for a request that would have been linked, we break the submission but still issue a partially composed link, that's nasty, fail it instead. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: move req link into submit_statePavel Begunkov2021-02-181-14/+14
| | | | | | | | | | | | | | | | | | | | Move struct io_submit_link into submit_state, which is a part of a submission state and so belongs to it. It saves us from explicitly passing it, and init/deinit is now nicely hidden in io_submit_state_[start,end]. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: move io_init_req() into io_submit_sqe()Pavel Begunkov2021-02-181-17/+15
| | | | | | | | | | | | | | | | Behaves identically, just move io_init_req() call into the beginning of io_submit_sqes(). That looks better unloads io_submit_sqes(). Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: move io_init_req()'s definitionPavel Begunkov2021-02-181-107/+107
| | | | | | | | | | | | | | | | | | | | A preparation patch, symbol to symbol move io_init_req() + io_check_restriction() a bit up. The submission path is pretty settled down, so don't worry about backports and move the functions instead of relying on forward declarations in the future. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: don't duplicate ->file check in sfrPavel Begunkov2021-02-181-3/+0
| | | | | | | | | | | | | | | | | | IORING_OP_SYNC_FILE_RANGE is marked as .needs_file, so the common path will take care of assigning and validating req->file, no need to duplicate it in io_sfr_prep(). Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: keep io_*_prep() naming consistentPavel Begunkov2021-02-181-4/+4
| | | | | | | | | | | | | | | | Follow io_*_prep() naming pattern, there are only fsync and sfr that don't do that. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: kill fictitious submit iteration indexPavel Begunkov2021-02-181-2/+2
| | | | | | | | | | | | | | | | | | @i and @submitted are very much coupled together, and there is no need to keep them both. Remove @i, it doesn't change generated binary but helps to keep a single source of truth. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
| * io_uring: fix read memory leakPavel Begunkov2021-02-171-4/+6
| | | | | | | | | | | | | | | | | | | | Don't forget to free iovec read inline completion and bunch of other cases that do "goto done" before setting up an async context. Fixes: 5ea5dd45844d ("io_uring: inline io_read()'s iovec freeing") Reported-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
* | Merge tag 'drm-next-2021-02-19' of git://anongit.freedesktop.org/drm/drmLinus Torvalds2021-02-211549-44262/+51351
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm updates from Dave Airlie: "A pretty normal tree, lots of refactoring across the board, ttm, i915, nouveau, and bunch of features in various drivers. docs: - lots of updated docs core: - require crtc to have unique primary plane - fourcc macro fix - PCI bar quirk for bar resizing - don't sent hotplug on error - move vm code to legacy - nuke hose only used on old oboslete alpha dma-buf: - kernel doc updates - improved lock tracking dp/hdmi: - DP-HDMI2.1 protocol converter support ttm: - bo size handling cleanup - release a pinned bo warning - cleanup lru handler - avoid using pages with drm_prime_sg_to_page_addr_arrays cma-helper: - prime/mmap fixes bridge: - add DP support gma500: - remove gma3600 support i915: - try eDP fast/narrow link again with fallback - Intel eDP backlight control - replace display register read/write macros - refactor intel_display.c - display power improvements - HPD code cleanup - Rocketlake display fixes - Power/backlight/RPM fixes - DG1 display fix - IVB/BYT clear residuals security fix again - make i915 mitigations options via parameter - HSW GT1 GPU hangs fixes - DG1 workaround hang fixes - TGL DMAR hang avoidance - Lots of GT fixes - follow on fixes for residuals clear - gen7 per-engine-reset support - HDCP2.2 + HDCP1.4 GEN12 DP MST support - TGL clear color support - backlight refactoring - VRR/Adaptive sync enabling on DP/EDP for TGL+ - async flips for all ilk+ amdgpu: - rework IH ring handling (Vega/Navi) - rework HDP handling (Vega/Navi) - swSMU updates for renoir/vangogh - Sienna Cichild overdrive support - FP16 on DCE8-11 support - GPU reset on navy flounder/vangogh - SMU profile fixes for APU - SR-IOV fixes - Vangogh SMU fixes - fan speed control fixes amdkfd: - config handling fix - buffer free fix - recursive lock warnings fix nouveau: - Turing MMU fault recovery fixes - mDP connectors reporting fix - audio locking fixes - rework engines/instances code to support new scheme tegra: - VIC newer firmware support - display/gr2d fixes for older tegra - pm reference leak fix mediatek: - SOC MT8183 support - decouple sub driver + share mtk mutex driver radeon: - PCI resource fix for some platforms ingenic: - pm support - 8-bit delta RGB panels vmwgfx: - managed driver helpers vc4: - BCM2711 DSI1 support - converted to atomic helpers - enable 10/12 bpc outputs - gem prime mmap helpers - CEC fix omap: - use degamma table - CTM support - rework DSI support imx: - stack usage fixes - drm managed support - imx-tve clock provider leak fix - rcar-du: - default mode fixes - conversion to managed API hisilicon: - use simple encoder vkms: - writeback connector support d3: - BT2020 support" * tag 'drm-next-2021-02-19' of git://anongit.freedesktop.org/drm/drm: (1459 commits) drm/amdgpu: Set reference clock to 100Mhz on Renoir (v2) drm/radeon: OLAND boards don't have VCE drm/amdkfd: Fix recursive lock warnings drm/amd/display: Add FPU wrappers to dcn21_validate_bandwidth() drm/amd/display: Fix potential integer overflow drm/amdgpu/display: remove hdcp_srm sysfs on device removal drm/amdgpu: fix CGTS_TCC_DISABLE register offset on gfx10.3 drm/i915/gt: Correct surface base address for renderclear drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling drm/nouveau/top/ga100: initial support drm/nouveau/top: add ioctrl/nvjpg drm/nouveau/privring: rename from ibus drm/nouveau/nvkm: remove nvkm_subdev.index drm/nouveau/nvkm: determine subdev id/order from layout drm/nouveau/vic: switch to instanced constructor drm/nouveau/sw: switch to instanced constructor drm/nouveau/sec2: switch to instanced constructor drm/nouveau/sec: switch to instanced constructor drm/nouveau/pm: switch to instanced constructor drm/nouveau/nvenc: switch to instanced constructor ...
| * \ Merge tag 'drm-intel-next-fixes-2021-02-18' of ↵Dave Airlie2021-02-1916-60/+115
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-intel into drm-next - Restrict DRM_I915_DEBUG to developer builds (Chris) - Fix return and error codes (Dan) - Suspend/Resume fix (Chris) - Disable atomics in L3 for gen9 (Chris) - Flush before changing register state (Chris) - Fix for GLK's HDMI (Ville) - Fix ILK+'s plane strides with Xtiling (Ville) - Correct surface base address for renderclear (Chris) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YC7uQY1kt6w0tRp+@intel.com
| | * | drm/i915/gt: Correct surface base address for renderclearChris Wilson2021-02-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The surface_state_base is an offset into the batch, so we need to pass the correct batch address for STATE_BASE_ADDRESS. Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.7+ Link: https://patchwork.freedesktop.org/patch/msgid/20210210122728.20097-1-chris@chris-wilson.co.uk (cherry picked from commit 1914911f4aa08ddc05bae71d3516419463e0c567) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
| | * | drm/i915: Disallow plane x+w>stride on ilk+ with X-tilingVille Syrjälä2021-02-173-6/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ilk+ planes get notably unhappy when the plane x+w exceeds the stride. This wasn't a problem previously because we always aligned SURF to the closest tile boundary so the x offset never got particularly large. But now with async flips we have to align to 256KiB instead and thus this becomes a real issue. On ilk/snb/ivb it looks like the accesses just wrap early to the next tile row when scanout goes past the SURF+n*stride boundary, hsw/bdw suffer more heavily and start to underrun constantly. i965/g4x appear to be immune. vlv/chv I've not yet checked. Let's borrow another trick from the skl+ code and search backwards for a better SURF offset in the hopes of getting the x offset below the limit. IIRC when I ran into a similar issue on skl years ago it was causing the hardware to fall over pretty hard as well. And let's be consistent and include i965/g4x in the check as well, just in case I just got super lucky somehow when I wasn't able to reproduce the issue. Not that it really matters since we still use 4k SURF alignment for i965/g4x anyway. Fixes: 6ede6b0616b2 ("drm/i915: Implement async flips for vlv/chv") Fixes: 4bb18054adc4 ("drm/i915: Implement async flip for ilk/snb") Fixes: 2a636e240c77 ("drm/i915: Implement async flip for ivb/hsw") Fixes: cda195f13abd ("drm/i915: Implement async flips for bdw") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209021918.16234-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit 59fb8218c8e5001f854e7d5fdb5fb135cba58102) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Rodrigo also exported some functions from intel_display.c during backport]
| | * | drm/i915: Reject 446-480MHz HDMI clock on GLKVille Syrjälä2021-02-081-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The BXT/GLK DPLL can't generate certain frequencies. We already reject the 233-240MHz range on both. But on GLK the DPLL max frequency was bumped from 300MHz to 594MHz, so now we get to also worry about the 446-480MHz range (double the original problem range). Reject any frequency within the higher problematic range as well. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3000 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210203093044.30532-1-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com> (cherry picked from commit 41751b3e5c1ac656a86f8d45a8891115281b729e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
| | * | drm/i915/gt: Flush before changing register stateChris Wilson2021-02-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Flush; invalidate; change registers; invalidate; flush. Will this finally work on every device? Or will Baytrail complain again? On the positive side, we immediately see the benefit of having hsw-gt1 in CI. Fixes: ace44e13e577 ("drm/i915/gt: Clear CACHE_MODE prior to clearing residuals") Testcase: igt/gem_render_tiled_blits # hsw-gt1 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210125220247.31701-1-chris@chris-wilson.co.uk (cherry picked from commit d30bbd62b1bfd9e0a33c3583c5a9e5d66f60cbd7) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
| | * | drm/i915: Disable atomics in L3 for gen9Chris Wilson2021-02-082-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enabling atomic operations in L3 leads to unrecoverable GPU hangs, as the machine stops responding milliseconds after receipt of the reset request [GDRT]. By disabling the cached atomics, the hang do not occur and we presume the GPU would reset normally for similar hangs. Sadly this is a shotgun approach, but since the impact is critical it is better to err on the safe side and work back from there. Reported-by: Jason Ekstrand <jason@jlekstrand.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110998 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Jason Ekstrand <jason@jlesktrand.net> Link: https://patchwork.freedesktop.org/patch/msgid/20210125220152.24070-1-chris@chris-wilson.co.uk Cc: stable@vger.kernel.org (cherry picked from commit b267c7ae0ad5b437b068f46919b17f85000154b4) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
| | * | drm/i915/gem: Move freeze/freeze_late next to suspend/suspend_lateChris Wilson2021-02-086-43/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Push the hibernate pm routines next to the suspend pm routines in gem/i915_gem_pm.c. This has the side-effect of putting the wbinvd() abusers next to each other. Reported-by: Guenter Roeck <linux@roeck-us.net> Fixes: 30d2bfd09383 ("drm/i915/gem: Almagamate clflushes on freeze") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210123145543.10533-1-chris@chris-wilson.co.uk (cherry picked from commit 6d8f02207420e76db693a00ccb44792474e297fc) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
| | * | drm/i915/gem: Fix oops in error handling codeDan Carpenter2021-02-081-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This code will Oops when it tries to i915_gem_object_free(obj) because "obj" is an error pointer. Fixes: 97d553963250 ("drm/i915/region: convert object_create into object_init") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/YA6FkPn5S4ZDUGxq@mwanda (cherry picked from commit ad8db423a30f0ac39a5483dfd726058135ff2bd2) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
| | * | drm/i915/gvt: fix uninitialized return in intel_gvt_update_reg_whitelist()Dan Carpenter2021-02-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Smatch found an uninitialized variable bug in this code: drivers/gpu/drm/i915/gvt/cmd_parser.c:3191 intel_gvt_update_reg_whitelist() error: uninitialized symbol 'ret'. The first thing that Smatch complains about is that "ret" isn't set if we don't enter the "for_each_engine(engine, &dev_priv->gt, id) {" loop. Presumably we always have at least one engine so that's a false positive. But it's definitely a bug to not set "ret" if i915_gem_object_pin_map() fails. Let's fix the bug and silence the false positive. Fixes: 493f30cd086e ("drm/i915/gvt: parse init context to update cmd accessible reg whitelist") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/YA6F3oF8mRaNQWjb@mwanda (cherry picked from commit 784f70e17e6bc423a04fb6524634a76f68ab1192) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
| | * | drm/i915: Restrict DRM_I915_DEBUG to developer buildsChris Wilson2021-02-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let's not encourage everybody to build i915's debug code, and certainly not the build robots who need to scrutinise the production build. Since CI will complain if the debug build is broken, having the other build bots focus on the builds we don't cover ourselves should improve the build coverage. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 4f86975f539d ("drm/i915: Add DEBUG_GEM to the recommended CI config") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210122091058.5145-1-chris@chris-wilson.co.uk (cherry picked from commit c442f658299d59b327a4bf21457ec8ece936f133) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
| * | | Merge tag 'amd-drm-next-5.12-2021-02-18' of ↵Dave Airlie2021-02-1986-342/+1147
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.12-2021-02-18: amdgpu: - Prefer Bhawan's unused variable fix - Fixes for high priority queues on gfx8,9 - swSMU fixes for sienna cichlid - swSMU fixes for renoir - mmhub client id fixes for arcturus - SMUIO fixes for navi family - swSMU fixes for vangogh - GPU reset cleanup - Display fixes - GFX harvesting fix for sienna cichlid - Fix reference clock on Renoir - Misc fixes and cleanups amdkfd: - Fix for unique id query - Fix recursive lock warnings radeon: - Remove confusing VCE messages on Oland Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210218221531.3870-1-alexander.deucher@amd.com
| | * | | drm/amdgpu: Set reference clock to 100Mhz on Renoir (v2)Alex Deucher2021-02-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes the rlc reference clock used for GPU timestamps. Value is 100Mhz. Confirmed with hardware team. v2: reword commit message. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1480 Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | drm/radeon: OLAND boards don't have VCEAlex Deucher2021-02-183-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Disable it on those boards. No functional change, this just removes the message about VCE failing to initialize. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=197327 Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | drm/amdkfd: Fix recursive lock warningsFelix Kuehling2021-02-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | memalloc_nofs_save/restore are no longer sufficient to prevent recursive lock warnings when holding locks that can be taken in MMU notifiers. Use memalloc_noreclaim_save/restore instead. Fixes: f920e413ff9c ("mm: track mmu notifiers in fs_reclaim_acquire/release") CC: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Philip Yang <Philip.Yang@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 5.10.x
| | * | | drm/amd/display: Add FPU wrappers to dcn21_validate_bandwidth()Jan Kokemüller2021-02-182-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dcn21_validate_bandwidth() calls functions that use floating point math. On my machine this sometimes results in simd exceptions when there are other FPU users such as KVM virtual machines running. The screen freezes completely in this case. Wrapping the function with DC_FP_START()/DC_FP_END() seems to solve the problem. This mirrors the approach used for dcn20_validate_bandwidth. Tested on a AMD Ryzen 7 PRO 4750U (Renoir). Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206987 Signed-off-by: Jan Kokemüller <jan.kokemueller@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | drm/amd/display: Fix potential integer overflowGustavo A. R. Silva2021-02-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix potential integer overflow by casting actual_calculated_clock_100hz to u64, in order to give the compiler complete information about the proper arithmetic to use. Notice that such variable is used in a context that expects an expression of type u64 (64 bits, unsigned) and the following expression is currently being evaluated using 32-bit arithmetic: actual_calculated_clock_100hz * post_divider Fixes: 7a03fdf628af ("drm/amd/display: fix 64bit division issue on 32bit OS") Addresses-Coverity-ID: 1501691 ("Unintentional integer overflow") Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | drm/amdgpu/display: remove hdcp_srm sysfs on device removalNirmoy Das2021-02-183-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes: 9037246bb2da5 ("drm/amd/display: Add sysfs interface for set/get srm") Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | drm/amdgpu: fix CGTS_TCC_DISABLE register offset on gfx10.3Marek Olšák2021-02-181-12/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes incorrect TCC harvesting info reported to userspace. The impact was a very very tiny performance degradation (unnecessary GL2 cache flushes). Signed-off-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | drm/radeon: Simplify bool comparisonJiapeng Chong2021-02-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the following coccicheck warning: ./drivers/gpu/drm/radeon/rs690.c:190:6-35: WARNING: Comparison to bool. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | drm/amd/display: Simplify bool comparisonJiapeng Chong2021-02-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the following coccicheck warning: ./drivers/gpu/drm/amd/display/dc/inc/hw/clk_mgr_internal.h:319:11-23: WARNING: Comparison to bool. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.25.1) at 2025-02-10 04:27:31 +0000