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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68C9CC433EF for ; Fri, 6 May 2022 16:04:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1443422AbiEFQIW (ORCPT ); Fri, 6 May 2022 12:08:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39036 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1443373AbiEFQHp (ORCPT ); Fri, 6 May 2022 12:07:45 -0400 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EA0406D975 for ; Fri, 6 May 2022 09:04:00 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id iq10so7432328pjb.0 for ; Fri, 06 May 2022 09:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=0uUTR9z98utauBqj+KmjxPc4gxj1gteGLGPvj7webUo=; b=J4IvR3uUluzPVJPujF5iGP7CnGMFRxS4C+JdTXPQeYnSh3W80C91i9wOSOsN7J/kGv bkX4yeeMmFTGNs2RiGiQ7rLi5NpfOmOCdMNV59m1D1X568tUCbKlXVN6Fc7MsWjfQrHc vbCNlfjkVHr8WjXmvxtOwRxpyh6SKRcrhQy/BW+7bcTZ5Fw72tYvnAXXD4DeN8+qaeSj /iU3XP4qgOgPzLD31X97EYpS874M9TrJZR4vF8sNIGilZSCOmMYryQJ4IP1aabvQ+V7H J5E/pxWQRHLJp0OCqreWvFF7K0+tNgFlQpHpHM5D88RoTNN6ZL072kF2+f0Xrue43ues 1hrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=0uUTR9z98utauBqj+KmjxPc4gxj1gteGLGPvj7webUo=; b=ThyprhFnsKOnKg4gz9rE5DGMGmOX6xYuptOkU5OpMSf4gXHgZXzhtbgEYMdOngznQJ PhxAFge2PiDegDn2SZ/45IZVX97dv99TcEn9taz75WXFDxau/vcEp5WOOz5gBe5jcrrt 52km62S8f3D3nUjdHM4vIexpSvX7vmwgcc2rcv3VBQjrUGJsQCWPnbs4m4tOQntrIsU+ hBqHlEetVQ7Ivb8t9DozFGXkV/4ISvgELluzFVx3fu0DR9q6yGjz4+WDGVuMiN7HXJdX MoGWQQIHV4+O46QDdcZfTvlhi6hDGHEEDR/ie/2Y/yNmjqgF11o7o5VsM1mbPYZxHMS/ WnJg== X-Gm-Message-State: AOAM531eAGD5M2lh05bpP471oRgVjn6xBCQeLJyb5Y9dtwh3ZrYNWjxn W+6tbZ6VcV0e8eKsS2tHSwmPGU4zVDOBAA== X-Google-Smtp-Source: ABdhPJzaRrmoWWC0zULoNyAQrgE1JZUQBrth1vEB2/dmiHbMGv30IIErYnu0FnK0crc6nCQ0X0BZdw== X-Received: by 2002:a17:903:22c1:b0:15e:c3b2:d632 with SMTP id y1-20020a17090322c100b0015ec3b2d632mr4462885plg.0.1651853040377; Fri, 06 May 2022 09:04:00 -0700 (PDT) Received: from [192.168.4.166] (cpe-72-132-29-68.dc.res.rr.com. [72.132.29.68]) by smtp.gmail.com with ESMTPSA id 6-20020a631546000000b003c14af50628sm3419968pgv.64.2022.05.06.09.03.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 May 2022 09:03:59 -0700 (PDT) Message-ID: <05e99d9e-4c66-6d7c-604c-1e52d8d0b5b2@kernel.dk> Date: Fri, 6 May 2022 10:03:58 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v2 0/5] fast poll multishot mode Content-Language: en-US To: Pavel Begunkov , Hao Xu , io-uring@vger.kernel.org Cc: linux-kernel@vger.kernel.org References: <20220506070102.26032-1-haoxu.linux@gmail.com> <5ce3d6c7-42f9-28c3-0800-4da399adaaea@kernel.dk> <3f940dad-73ce-4ea6-dc76-f877c64dbb9a@gmail.com> From: Jens Axboe In-Reply-To: <3f940dad-73ce-4ea6-dc76-f877c64dbb9a@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/6/22 10:01 AM, Pavel Begunkov wrote: > On 5/6/22 15:18, Jens Axboe wrote: >> On 5/6/22 1:36 AM, Hao Xu wrote: >>> Hi All, >>> I actually had a question about the current poll code, from the code it >>> seems when we cancel a poll-like request, it will ignore the existing >>> events and just raise a -ECANCELED cqe though I haven't tested it. Is >>> this by design or am I missing something? >> >> That's by design, but honestly I don't think anyone considered the case >> where it's being canceled but has events already. For that case, I think >> we should follow the usual logic of only returning an error (canceled) >> if we don't have events, if we have events just return them. For >> multi-shot, obviously also terminate, but same logic there. > > Why would we care? It's inherently racy in any case and any > user not handling this is already screwed. We don't really need to care, but the normal logic is "return error if we have no result, return result otherwise". No reason this should be any different imho, it's not really a correctness thing. -- Jens Axboe