Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1336836ybl; Fri, 13 Dec 2019 13:34:15 -0800 (PST) X-Google-Smtp-Source: APXvYqwfU+vTse8IBnHuuzoVKpnvIqRwFS3tHhKQXyfWplkbiPXs8SFvBjvtUdHa0BFfRCc0AfnO X-Received: by 2002:a05:6830:22e3:: with SMTP id t3mr16154277otc.193.1576272855000; Fri, 13 Dec 2019 13:34:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576272854; cv=none; d=google.com; s=arc-20160816; b=tcl3JTpio1wczv/mm3ymuMDFyyqq4yuNat0nOH6vK70RNiaEg8JQiCx12w+NR6kXBx w/f5yPuNSfyqdeQF5G+KI4t6ey8gyPIOn5cAMgG+BM2m9k5cyiTX4Pu4IkOjfHtuKApg +Ywqzfb8SnklhaKqy4jef0oYRRp6FZHqWO/PofQpVhrkeKjH9K8vYx5xHKBL62WnDqR0 VgUbs6ZptldcnD8G/1/knkmAFO3Sk+JhAOkXpcp8ergrsI1bZCmzh/rljSqEzSJsavyX Tlk3WKILinCYBaxG7n7Zsc+hhVMr5WJ2vPyB6aAGwFIpPqWDzL0sMLeSpF2WLzlT1Xtq sc3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:dkim-signature; bh=VMUpcAkZBc/3hcg5ji+Dj7UkVJADZCSszth3iskQpEM=; b=WfcBZFOJ2gWC0fGdTO6zUs3qA1Ub4LD6A4Xgyrg7MSf8cxN1cE4qQwep+HJ7PfeOGv rdGfCRSOldx+25j3YOcLFUj+Iy1lOuMn9LVByyhGbxkes2ESjmqwpmPdQATCJ98DAO6P NR3ckt167YBYip6F360U7WZYY77wZ/XIByOJ5ootBahgV1NpJcXKyGVSz8//JegMQznC x9oBwUwXTKagZLyrXKF1hvGixADIM8dPRNQ9grH0lZvb4lsO49SD7v6iJjKsqo8BDf22 AtvwmFBpco7TPtgU3tAdiypgWEHrXsJDj2TFQQjNDVQRCe7lmCib5TcQFYmi5dWcCchW NtXw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="o3Z/izHZ"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y198si6060746oia.163.2019.12.13.13.34.03; Fri, 13 Dec 2019 13:34:14 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="o3Z/izHZ"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726704AbfLMVc4 (ORCPT + 99 others); Fri, 13 Dec 2019 16:32:56 -0500 Received: from mail-wm1-f65.google.com ([209.85.128.65]:38094 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725554AbfLMVcz (ORCPT ); Fri, 13 Dec 2019 16:32:55 -0500 Received: by mail-wm1-f65.google.com with SMTP id u2so245358wmc.3; Fri, 13 Dec 2019 13:32:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=VMUpcAkZBc/3hcg5ji+Dj7UkVJADZCSszth3iskQpEM=; b=o3Z/izHZCjNfFVfVm8doXR0ARkwNOzoCeEuKPdB3PNRW8Gen+2qZI5SYK57ReaREdw pac8ijJNfQIqM+NqMezzwStedtpVQHP1omiKLqFVHD599TR4/elJaEJo8IHSauT+EyIa I4hwrBg+MHwLZ35+TTYc00Q6dAq0J/YEZZNvuU6DjVK0YTcW5ZgiyhbXF6aSaqVpZNFD JXJWZgIpWJLct8jmuR2YRjD8E7oCuZngYIQ9DT+12xaLfd6/Y3kRYbRl/qRaXDNlWzST AKu+NWp6DkDzWFXFj0ppawhad/fXahVRSboZaKZY8x59aNg8bHi1RVxGkz8wEgNK+pdr +k2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VMUpcAkZBc/3hcg5ji+Dj7UkVJADZCSszth3iskQpEM=; b=WmytR/7YOfBGZ+CT8hjnVZH0yRLGC2ogw0ttzuOeK5IH+YZBXKuHrC+Ik2ERvTsYib MQt4KOX+XYqf2+QjzKPPKVOm5wXEzDlTHxRbXJaLBZu9sVGd092xig2gHtgjlhuVy9dN uCe/mkWfRwyYw+Lw5hCUXEdOQl3u2VqUS71eo7B1Qs7onlVsKn/xB/IwB7QgnmYIWWGG HoK24upqqyB7mc5/IdEsM7mzLd9/r1zLbxUDDqCOmzIAxSQld6O0rYbcExeyAxQ5hmC0 5oSKh2IzPjIsEZ/cK+6b2eyg4Baa9URtCMfvlJZe6JHJoEZyNRAW98KBj2NANfh0MBJC 3hxw== X-Gm-Message-State: APjAAAV9qwW5zvLrkQF+wRoBSyHCIvXWALMUDdi8kNs7uwHiPYSR7mgR 84DVzi7XGaom12mn83tntm3Pgja8 X-Received: by 2002:a1c:7205:: with SMTP id n5mr16222550wmc.9.1576272772712; Fri, 13 Dec 2019 13:32:52 -0800 (PST) Received: from [192.168.43.233] ([109.126.143.152]) by smtp.gmail.com with ESMTPSA id k8sm11595537wrl.3.2019.12.13.13.32.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Dec 2019 13:32:52 -0800 (PST) Subject: Re: [PATCH 1/1] io_uring: don't wait when under-submitting To: Jens Axboe , io-uring@vger.kernel.org, linux-kernel@vger.kernel.org References: <5caa38be87f069eb4cc921d58ee1a98ff5d53978.1576223348.git.asml.silence@gmail.com> <21ca72b0-c35d-96b7-399f-d4034d976c27@kernel.dk> <9fbb03f4-6444-04a6-4cfb-ee4b3aa0bcd1@kernel.dk> From: Pavel Begunkov Message-ID: <47a5641b-af81-0edf-1d71-4e3063ce8517@gmail.com> Date: Sat, 14 Dec 2019 00:32:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <9fbb03f4-6444-04a6-4cfb-ee4b3aa0bcd1@kernel.dk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/12/2019 21:32, Jens Axboe wrote: > On 12/13/19 11:22 AM, Jens Axboe wrote: >> On 12/13/19 12:51 AM, Pavel Begunkov wrote: >>> There is no reliable way to submit and wait in a single syscall, as >>> io_submit_sqes() may under-consume sqes (in case of an early error). >>> Then it will wait for not-yet-submitted requests, deadlocking the user >>> in most cases. >> >> Why not just cap the wait_nr? If someone does to_submit = 8, wait_nr = 8, >> and we only submit 4, just wait for 4? Ala: >> Is it worth entangling the code? I don't expect anyone trying to recover, maybe except full reset/restart. So, failing ASAP seemed to me as the right thing to do. It may also mean nothing to the user if e.g. submit(1), submit(1), ..., submit_and_wait(1, n) Anyway, this shouldn't even happen in a not buggy code, so I'm fine with any version as long as it doesn't lock up. I'll resend if you still prefer to cap it. >> diff --git a/fs/io_uring.c b/fs/io_uring.c >> index 81219a631a6d..4a76ccbb7856 100644 >> --- a/fs/io_uring.c >> +++ b/fs/io_uring.c >> @@ -5272,6 +5272,10 @@ SYSCALL_DEFINE6(io_uring_enter, unsigned int, fd, u32, to_submit, >> submitted = io_submit_sqes(ctx, to_submit, f.file, fd, >> &cur_mm, false); >> mutex_unlock(&ctx->uring_lock); >> + if (submitted <= 0) >> + goto done; >> + if (submitted != to_submit && min_complete > submitted) >> + min_complete = submitted; >> } >> if (flags & IORING_ENTER_GETEVENTS) { >> unsigned nr_events = 0; >> @@ -5284,7 +5288,7 @@ SYSCALL_DEFINE6(io_uring_enter, unsigned int, fd, u32, to_submit, >> ret = io_cqring_wait(ctx, min_complete, sig, sigsz); >> } >> } >> - >> +done: >> percpu_ref_put(&ctx->refs); >> out_fput: >> fdput(f); >> > > This is probably a bit cleaner, since it only adjusts if we're going to > wait. > > > diff --git a/fs/io_uring.c b/fs/io_uring.c > index 81219a631a6d..e262549a2601 100644 > --- a/fs/io_uring.c > +++ b/fs/io_uring.c > @@ -5272,11 +5272,15 @@ SYSCALL_DEFINE6(io_uring_enter, unsigned int, fd, u32, to_submit, > submitted = io_submit_sqes(ctx, to_submit, f.file, fd, > &cur_mm, false); > mutex_unlock(&ctx->uring_lock); > + if (submitted <= 0) > + goto done; > } > if (flags & IORING_ENTER_GETEVENTS) { > unsigned nr_events = 0; > > min_complete = min(min_complete, ctx->cq_entries); > + if (submitted != to_submit && min_complete > submitted) > + min_complete = submitted; > > if (ctx->flags & IORING_SETUP_IOPOLL) { > ret = io_iopoll_check(ctx, &nr_events, min_complete); > @@ -5284,7 +5288,7 @@ SYSCALL_DEFINE6(io_uring_enter, unsigned int, fd, u32, to_submit, > ret = io_cqring_wait(ctx, min_complete, sig, sigsz); > } > } > - > +done: > percpu_ref_put(&ctx->refs); > out_fput: > fdput(f); > -- Pavel Begunkov