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 31329C001DD for ; Thu, 13 Jul 2023 14:33:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230475AbjGMOdM (ORCPT ); Thu, 13 Jul 2023 10:33:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230346AbjGMOdL (ORCPT ); Thu, 13 Jul 2023 10:33:11 -0400 Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com [IPv6:2607:f8b0:4864:20::549]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C376926B8 for ; Thu, 13 Jul 2023 07:33:07 -0700 (PDT) Received: by mail-pg1-x549.google.com with SMTP id 41be03b00d2f7-53b9eb7bda0so410481a12.0 for ; Thu, 13 Jul 2023 07:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689258787; x=1691850787; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=fr2vYa/Ch6xYV487nmzxcm8iM/FlpnkWVHQ5jynQTbg=; b=jacaK9M2p8ae07DYtf3WTwW4sJ88AeR0PMoTM/K8Zom80G9CNsRED8/7OkNACpL4FI vSrK+poAQrpW9b9XXAEX3N+/eJqGG0fl2uSilp/V2zhMmynFGmkNp19rQMAPCUIgro+L 8wZFnIyWuBTpd6inSk0jhwWPq/qOKDhiCmrdy2nICENUOLQPMx4zm5vkc1J+N+jf8F/9 NWijWeXBKP6nhRWfAZooF9dECtwpwP1B06LROVi+ZRGQWEPDlF+8FcWtS7IpVg38LWBC sabPszkfHQCdZSa4qO28HKir4zE3m+cUi5LtAFjCZb9xEKl25slyjVF3CoaXZrvttifT RnQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689258787; x=1691850787; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fr2vYa/Ch6xYV487nmzxcm8iM/FlpnkWVHQ5jynQTbg=; b=KDFb5CFjFNTnYJmpeGRBQwRDSsDDT8wKTgZDx3R2fLEzXJ+lv9p+WiDBUxr52RYDTc 95WXCDcdeXOicOaVBjwW52b9Z0yjw+WbLoLkV/mgUuBNgzO62VLzLggbhhPU66QswZm1 hUCg9LW+IDv7LNa7gMux0gz+6Tauyz33TqakzxuPoW4YtnWyaWrqOHEmD2lLRAEgjbbQ EislXtDtM2dP5LiBdmcdsLKCVcl0nSok/rzQmLm1MOlWeWXDHSLA98KbuJdiCuMTTLDi QgA5Y1kVIY61jjbPeB0PsJiLkpNVwzk7lzrEA3wX2iqPpkimmGFaQvmKMlaKFq4GKcYY zTng== X-Gm-Message-State: ABy/qLYrgHdefy8/VHaTUvM7Yk64EGRmsU8hd/dbfdM4e5xQ9qEKlCIZ MbVMByCr91gQmBauhFvY8mujiFZzpTc= X-Google-Smtp-Source: APBJJlFAAhWItEMB5PDxlVd4/XD0kDAeGPn5ZZPTnMU3ojU8FDM9Oji9AhkfLIh7rpZuc1o0H3AhYJQLwhY= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:b282:b0:1ba:1704:89d1 with SMTP id u2-20020a170902b28200b001ba170489d1mr5846plr.10.1689258786828; Thu, 13 Jul 2023 07:33:06 -0700 (PDT) Date: Thu, 13 Jul 2023 07:33:05 -0700 In-Reply-To: <20230713-vfs-eventfd-signal-v1-2-7fda6c5d212b@kernel.org> Mime-Version: 1.0 References: <20230713-vfs-eventfd-signal-v1-0-7fda6c5d212b@kernel.org> <20230713-vfs-eventfd-signal-v1-2-7fda6c5d212b@kernel.org> Message-ID: Subject: Re: [PATCH 2/2] eventfd: simplify eventfd_signal_mask() From: Sean Christopherson To: Christian Brauner Cc: linux-fsdevel@vger.kernel.org, Vitaly Kuznetsov , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, David Woodhouse , Paul Durrant , Oded Gabbay , Wu Hao , Tom Rix , Moritz Fischer , Xu Yilun , Zhenyu Wang , Zhi Wang , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Daniel Vetter , Leon Romanovsky , Jason Gunthorpe , Frederic Barrat , Andrew Donnellan , Arnd Bergmann , Greg Kroah-Hartman , Eric Farman , Matthew Rosato , Halil Pasic , Vineeth Vijayan , Peter Oberparleiter , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Tony Krowiak , Jason Herne , Harald Freudenberger , "Michael S. Tsirkin" , Jason Wang , Xuan Zhuo , Diana Craciun , Alex Williamson , Eric Auger , Fei Li , Benjamin LaHaise , Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Kirti Wankhede , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-fpga@vger.kernel.org, intel-gvt-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, linux-rdma@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-usb@vger.kernel.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, linux-aio@kvack.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Jens Axboe , Pavel Begunkov , io-uring@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Thu, Jul 13, 2023, Christian Brauner wrote: > diff --git a/fs/eventfd.c b/fs/eventfd.c > index dc9e01053235..077be5da72bd 100644 > --- a/fs/eventfd.c > +++ b/fs/eventfd.c > @@ -43,9 +43,10 @@ struct eventfd_ctx { > int id; > }; > > -__u64 eventfd_signal_mask(struct eventfd_ctx *ctx, __u64 n, __poll_t mask) > +bool eventfd_signal_mask(struct eventfd_ctx *ctx, __poll_t mask) > { > unsigned long flags; > + __u64 n = 1; > > /* > * Deadlock or stack overflow issues can happen if we recurse here > @@ -68,7 +69,7 @@ __u64 eventfd_signal_mask(struct eventfd_ctx *ctx, __u64 n, __poll_t mask) > current->in_eventfd = 0; > spin_unlock_irqrestore(&ctx->wqh.lock, flags); > > - return n; > + return n == 1; > } ... > @@ -58,13 +58,12 @@ static inline struct eventfd_ctx *eventfd_ctx_fdget(int fd) > return ERR_PTR(-ENOSYS); > } > > -static inline int eventfd_signal(struct eventfd_ctx *ctx) > +static inline bool eventfd_signal(struct eventfd_ctx *ctx) > { > return -ENOSYS; > } > > -static inline int eventfd_signal_mask(struct eventfd_ctx *ctx, __u64 n, > - unsigned mask) > +static inline bool eventfd_signal_mask(struct eventfd_ctx *ctx, unsigned mask) > { > return -ENOSYS; This will morph to "true" for what should be an error case. One option would be to have eventfd_signal_mask() return 0/-errno instead of the count, but looking at all the callers, nothing ever actually consumes the result. KVMGT morphs failure into -EFAULT if (vgpu->msi_trigger && eventfd_signal(vgpu->msi_trigger, 1) != 1) return -EFAULT; but the only caller of that user ignores the return value. if (vgpu_vreg(vgpu, i915_mmio_reg_offset(GEN8_MASTER_IRQ)) & ~GEN8_MASTER_IRQ_CONTROL) inject_virtual_interrupt(vgpu); The sample driver in samples/vfio-mdev/mtty.c uses a similar pattern: prints an error but otherwise ignores the result. So why not return nothing? That will simplify eventfd_signal_mask() a wee bit more, and eliminate that bizarre return value confusion for the ugly stubs, e.g. void eventfd_signal_mask(struct eventfd_ctx *ctx, unsigned mask) { unsigned long flags; /* * Deadlock or stack overflow issues can happen if we recurse here * through waitqueue wakeup handlers. If the caller users potentially * nested waitqueues with custom wakeup handlers, then it should * check eventfd_signal_allowed() before calling this function. If * it returns false, the eventfd_signal() call should be deferred to a * safe context. */ if (WARN_ON_ONCE(current->in_eventfd)) return; spin_lock_irqsave(&ctx->wqh.lock, flags); current->in_eventfd = 1; if (ctx->count < ULLONG_MAX) ctx->count++; if (waitqueue_active(&ctx->wqh)) wake_up_locked_poll(&ctx->wqh, EPOLLIN | mask); current->in_eventfd = 0; spin_unlock_irqrestore(&ctx->wqh.lock, flags); } You could even go further and unify the real and stub versions of eventfd_signal().