From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1CEDEC2BA83 for ; Wed, 12 Feb 2020 14:23:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E18C1206D7 for ; Wed, 12 Feb 2020 14:23:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=scylladb-com.20150623.gappssmtp.com header.i=@scylladb-com.20150623.gappssmtp.com header.b="tRLJ6QK6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727980AbgBLOXU (ORCPT ); Wed, 12 Feb 2020 09:23:20 -0500 Received: from mail-lf1-f46.google.com ([209.85.167.46]:34591 "EHLO mail-lf1-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727781AbgBLOXU (ORCPT ); Wed, 12 Feb 2020 09:23:20 -0500 Received: by mail-lf1-f46.google.com with SMTP id l18so1756435lfc.1 for ; Wed, 12 Feb 2020 06:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scylladb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/zOpDpLrMd2NLa3wJlzierP2BVjcQfDv/FVJNprJMAQ=; b=tRLJ6QK6NzTNSqEGS7urdpu+ttkmkA68mx40tr1P3poE3kmCb/lAvCqqSYqMsyFa07 xD3Lrrwg9nhHGeEa+FdBvprZNDWh2RjjGeKq1sDa9Shy2uJ5xYZZJ3Bs1jrvXBYvRspm EF1IwKYOgOCUP00RjO54yyuicmVH9oJGlYqvQKkzncn9Di8lo5M3A7YLuaFEjnQyQEhv e1CyheSff7D2K/Fxic+dyUIk83zbSyUwCmTIJKD8QsJg84IsXIxirhum5FOQVDH6rgBK nkr0Q/fc9QFXeCKukxj2WNv9iaFWsMWdM41f8KGZ1IoHiXLPmv7z0fid0tWphCBWvcfU CJoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/zOpDpLrMd2NLa3wJlzierP2BVjcQfDv/FVJNprJMAQ=; b=WoGbX33qnIhXTPXb+rYfeK/vM8cy27GLjm40zeSm7qDaT0iJ9MCP+VGNHP5rGZP37a oLnxuCeFHfjyXLwX+s8yztr57TfLFZc2q2vPepAE+nSvLwlVi0VGqkonCUnCpX4WZbwg lm+UTrADT2E+mjBOnIRKHeQb6QOCH+pduyIS3BHtzpiBXb3xLft5Z+Xm6fpQd9ZZ1w6C 2WjUcx8Gu0l8awBAD333MDPL58E/+o4vI8/eoezxnT6qcvkfwJqok99Aq0Q99fZrq1gw /B5IXwtEI6qQXBOzH79/H74KgZGSGA6BXVRF7IPiinp+HszrNbpr4mdOqGc7sMZBBK8W YVtQ== X-Gm-Message-State: APjAAAXLWkxN8LwpB7//5tpmLofrDlmJPQs6XEkSvGGYX77YOzu7VAqV EcyeRH9lDSKs0oxyb7Vc3pprfNxTg1KUkmjxE2JnqA== X-Google-Smtp-Source: APXvYqzLo8lPB8O2odMHYobGPnyXGoiH7bS5UAd3tZc0vMxbwOHEX/j2fnZw8hPEO5MFZvRVT3K8GOan30AzuqZEUjs= X-Received: by 2002:a19:c014:: with SMTP id q20mr6900790lff.208.1581517398275; Wed, 12 Feb 2020 06:23:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Glauber Costa Date: Wed, 12 Feb 2020 09:23:06 -0500 Message-ID: Subject: Re: how is register_(buffer|file) supposed to work? To: Jens Axboe Cc: io-uring@vger.kernel.org, Avi Kivity Content-Type: text/plain; charset="UTF-8" Sender: io-uring-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Wed, Feb 12, 2020 at 9:20 AM Jens Axboe wrote: > > On 2/11/20 9:12 PM, Glauber Costa wrote: > > Hi, > > > > I am trying to experiment with the interface for registering files and buffers. > > > > (almost) Every time I call io_uring_register with those opcodes, my > > application hangs. > > > > It's easy to see the reason. I am blocking here: > > > > mutex_unlock(&ctx->uring_lock); > > ret = wait_for_completion_interruptible(&ctx->completions[0]); > > mutex_lock(&ctx->uring_lock); > > > > Am I right in my understanding that this is waiting for everything > > that was submitted to complete? Some things in my ring may never > > complete: for instance one may be polling for file descriptors that > > may never really become ready. > > > > This sounds a bit too restrictive to me. Is this really the intended > > use of the interface? > > For files, this was added in the current merge window: > Ok, so this is what I was missing: > commit 05f3fb3c5397524feae2e73ee8e150a9090a7da2 > Author: Jens Axboe > Date: Mon Dec 9 11:22:50 2019 -0700 > > io_uring: avoid ring quiesce for fixed file set unregister and update > > which allows you to call IORING_REGISTER_FILES_UPDATE without having to > quiesce the ring. File sets can be sparse, you can register with an fd > of -1 and then later use FILES_UPDATE (or IORING_OP_FILES_UPDATE) to > replace it with a real entry. You can also replace a real entry with a > new one, or switch it to sparse again. ^^^ this I thought I've seen EBADF errors when registering -1, but maybe it wasn't -1, it was just really an invalid fd. For memory I guess I could register early on and draw from a poll. That's a bit inconvenient as ideally that poll would grow and shrink dynamically, but it works I'll give it a try