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=-11.6 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 710F5C433DF for ; Fri, 7 Aug 2020 01:00:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 37C0D2073E for ; Fri, 7 Aug 2020 01:00:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="fihtTYWe" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726011AbgHGBAr (ORCPT ); Thu, 6 Aug 2020 21:00:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34364 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725999AbgHGBAr (ORCPT ); Thu, 6 Aug 2020 21:00:47 -0400 Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37F70C061574 for ; Thu, 6 Aug 2020 18:00:46 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id i10so395014ljn.2 for ; Thu, 06 Aug 2020 18:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xlcgFJhNZ9/EKyqtVIg6l5Auc33voPfKTHPm9n79Xgk=; b=fihtTYWeRFsLnAPo2/8HSap1JRXc4kLy/SfcatMKPQuC0IoNiUp5d6luSQiGfssT9Y UYHIfEBhVtpKVXLFx5pfQVccJmmj9zcHF/V+sfsblEVWo+9ABOA3o3BcaKUxgJCKG9Nt NrFoF5yO2PGxmtcnauERIEreq4dU8qFvzf7JapTQR8za0v+XN1nJgucXL0ccee85+jqn mN+ewBveywZi/tThhKBtOHqncs2xZSwjlb5yOyTjSk3VOfBQRuVCvO74zAqZMHm91HNv zIQqVzakRHuS+LhlqB7E6XmLdZ4Id2mQJ+CKAjONNzsn6qhzIyTv0uCal6ZLXbxFsjtZ 1XNw== 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=xlcgFJhNZ9/EKyqtVIg6l5Auc33voPfKTHPm9n79Xgk=; b=gGJOj3jdt8gG/2nIjf7TbpjAAtZKePffIYgF8Mo7SR8cFc3InX7/nHaOWkBYF3/K/Y wqejje0HnQFUkfefEX++/BSU36fDRKF898TZx/39OAlXl6jYpttgSA4yFHDyNW7Q3qL+ oPecP//r0O10YQV2hoNNN4EoUJWWHstRfFr+OkJU63ro7zY+n5tc6pxqNwjyzTc6Fl4M 302RUT+BspDz/cfJsR622g4sVib0BsEcEBQKwXL+9A+ejIwDF7YYPcz/18tn5Rk2WSaY IOLXxq/mzk20JD+QjHKzYYvtbEeE/8nnT28yQerdMtGaRUqPiJ7Zx2iagerDJPGxCUJJ SETQ== X-Gm-Message-State: AOAM533uCTtopDjjSWfPLIJhyKQ7GNrluyWKmnemxhDzaB0ah8pdI77+ nHmh/jId8UW55vVu8g2gLQ35yeLeTA6q0F0FlHrLlA== X-Google-Smtp-Source: ABdhPJwF5seTjCe9i6h+1E/7y2WF0Sd5O/M/y4oJesMCaNYzE8srsZ8G4BZ6TsimXOZMA6EZfXkbGS/YqDqPrDPBC44= X-Received: by 2002:a2e:302:: with SMTP id 2mr4614295ljd.156.1596762044328; Thu, 06 Aug 2020 18:00:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jann Horn Date: Fri, 7 Aug 2020 03:00:17 +0200 Message-ID: Subject: Re: [PATCH] io_uring: use TWA_SIGNAL for task_work related to eventfd To: Jens Axboe Cc: io-uring 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 Fri, Aug 7, 2020 at 1:57 AM Jens Axboe wrote: > An earlier commit: > > b7db41c9e03b ("io_uring: fix regression with always ignoring signals in io_cqring_wait()") > > ensured that we didn't get stuck waiting for eventfd reads when it's > registered with the io_uring ring for event notification, but that didn't > cover the general case of waiting on eventfd and having that dependency > between io_uring and eventfd. > > Ensure that we use signaled notification for anything related to eventfd. [...] > @@ -1720,7 +1720,7 @@ static int io_req_task_work_add(struct io_kiocb *req, struct callback_head *cb) > */ > if (ctx->flags & IORING_SETUP_SQPOLL) > notify = 0; > - else if (ctx->cq_ev_fd) > + else if (ctx->cq_ev_fd || (req->file && eventfd_file(req->file))) > notify = TWA_SIGNAL; Is the idea here that you want "polling an eventfd" to have different UAPI semantics compared to e.g. "polling a pipe"? Or is there something in-kernel that makes eventfds special?