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 3B3E2C04A6A for ; Mon, 17 Jul 2023 08:29:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230318AbjGQI3w (ORCPT ); Mon, 17 Jul 2023 04:29:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231350AbjGQI3u (ORCPT ); Mon, 17 Jul 2023 04:29:50 -0400 Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8DDB18B for ; Mon, 17 Jul 2023 01:29:46 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id e9e14a558f8ab-345ff33d286so22420885ab.3 for ; Mon, 17 Jul 2023 01:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf.com; s=google; t=1689582586; x=1692174586; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KrEcIar0BkfpmBL+8BCmNKqe2TUSK3LL+WBdNYsOjsM=; b=e52IJgo7nORao0Gl4I5dRpwwbrYRCXZTSuwaC/thRVodGrQS/Ih+iZx/Zsqn89WU3w pQgXUWQS+Vk59/Fh6rrIEqzCQJkEny2i0gy7zEPOvxwj9yUxhnNvrizRbt8YsZpplHpx RjVLFZyrzR9wafddakUgpMo5lLKlNumHP6uiacp/wGVyLbBbCgrHIUP/7snpf7XV2sof jlaeLm95LpwgAuzcjO7UCvT+e3bh2UJ0I6TbCUpKBOZvGLRTw6wJXY5zbY52dacz1/1P iPPOvh8ArwyYCroEOLn3Y8OJKVgd78PUACDF8tTPiPB+Om3hyy+66x8dhT2yU/74h83y v2JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689582586; x=1692174586; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KrEcIar0BkfpmBL+8BCmNKqe2TUSK3LL+WBdNYsOjsM=; b=H6SWtXrUPYRoLrVnk4apta0ejYZXygH5biYbuzZNM63m6XSWS9pkExtnM53hojlaS3 bjYuj0SmbQw3o/jXCsSAczfbZ5x25MTTllnxGmsgXXrqTcQwm8rV2e0OHg4EsmErGCsM C2itC+NN6c9uTo4GgH5OXEletCqN9yF+gE4l6//zhktpNq7S/c878YXICJ1ZAnfvQg/q qs+rq4mYQaLMGG7qXsqdGcMc6ZpEYOaMOCyxRlGWD797iDJIU9oxfdq9N0IsuAHCnDD4 TR2WBKkbhs3ceCnbXq4jY0QehkuvJzJQqoKn+dbcFUWp2VpKk4lU5dMWn0FiesV1vdtp Hu8Q== X-Gm-Message-State: ABy/qLZDwr1hvHeN5Y6QOvEW6w8vBGqlevczGfVRvHys5WyJWyt4Kb5R zKydsMT+eU15K3X8Luja7dJ+AEjT2EqL/+cTjFWPTQ== X-Google-Smtp-Source: APBJJlGE7jn73weZAb7Q+GH4ouydfCd9ILtA9ynYfWdyB1I4k5TGE6qNhhrOJBaOwSkah9YrBoRDKcKZ9t95G975sJc= X-Received: by 2002:a92:d4d2:0:b0:345:d470:baa6 with SMTP id o18-20020a92d4d2000000b00345d470baa6mr9664500ilm.29.1689582586220; Mon, 17 Jul 2023 01:29:46 -0700 (PDT) MIME-Version: 1.0 References: <20230630155936.3015595-1-jaz@semihalf.com> <20230714-gauner-unsolidarisch-fc51f96c61e8@brauner> In-Reply-To: <20230714-gauner-unsolidarisch-fc51f96c61e8@brauner> From: Grzegorz Jaszczyk Date: Mon, 17 Jul 2023 10:29:34 +0200 Message-ID: Subject: Re: [PATCH 0/2] eventfd: simplify signal helpers To: Christian Brauner , Alex Williamson Cc: linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, linux-usb@vger.kernel.org, Matthew Rosato , Paul Durrant , Tom Rix , Jason Wang , dri-devel@lists.freedesktop.org, Michal Hocko , linux-mm@kvack.org, Kirti Wankhede , Paolo Bonzini , Jens Axboe , Vineeth Vijayan , Diana Craciun , Alexander Gordeev , Xuan Zhuo , Shakeel Butt , Vasily Gorbik , Leon Romanovsky , Harald Freudenberger , Fei Li , x86@kernel.org, Roman Gushchin , Halil Pasic , Jason Gunthorpe , Ingo Molnar , intel-gfx@lists.freedesktop.org, Christian Borntraeger , linux-fpga@vger.kernel.org, Zhi Wang , Wu Hao , Jason Herne , Eric Farman , Dave Hansen , Andrew Donnellan , Arnd Bergmann , linux-s390@vger.kernel.org, Heiko Carstens , Johannes Weiner , linuxppc-dev@lists.ozlabs.org, Eric Auger , Borislav Petkov , kvm@vger.kernel.org, Rodrigo Vivi , cgroups@vger.kernel.org, Thomas Gleixner , virtualization@lists.linux-foundation.org, intel-gvt-dev@lists.freedesktop.org, io-uring@vger.kernel.org, netdev@vger.kernel.org, Tony Krowiak , Tvrtko Ursulin , Pavel Begunkov , Sean Christopherson , Oded Gabbay , Muchun Song , Peter Oberparleiter , linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, Benjamin LaHaise , "Michael S. Tsirkin" , Sven Schnelle , Greg Kroah-Hartman , Frederic Barrat , Moritz Fischer , Vitaly Kuznetsov , David Woodhouse , Xu Yilun , Dominik Behr , Marcin Wojtas Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org pt., 14 lip 2023 o 09:05 Christian Brauner napisa=C5= =82(a): > > On Thu, Jul 13, 2023 at 11:10:54AM -0600, Alex Williamson wrote: > > On Thu, 13 Jul 2023 12:05:36 +0200 > > Christian Brauner wrote: > > > > > Hey everyone, > > > > > > This simplifies the eventfd_signal() and eventfd_signal_mask() helper= s > > > by removing the count argument which is effectively unused. > > > > We have a patch under review which does in fact make use of the > > signaling value: > > > > https://lore.kernel.org/all/20230630155936.3015595-1-jaz@semihalf.com/ > > Huh, thanks for the link. > > Quoting from > https://patchwork.kernel.org/project/kvm/patch/20230307220553.631069-1-ja= z@semihalf.com/#25266856 > > > Reading an eventfd returns an 8-byte value, we generally only use it > > as a counter, but it's been discussed previously and IIRC, it's possibl= e > > to use that value as a notification value. > > So the goal is to pipe a specific value through eventfd? But it is > explicitly a counter. The whole thing is written around a counter and > each write and signal adds to the counter. > > The consequences are pretty well described in the cover letter of > v6 https://lore.kernel.org/all/20230630155936.3015595-1-jaz@semihalf.com/ > > > Since the eventfd counter is used as ACPI notification value > > placeholder, the eventfd signaling needs to be serialized in order to > > not end up with notification values being coalesced. Therefore ACPI > > notification values are buffered and signalized one by one, when the > > previous notification value has been consumed. > > But isn't this a good indication that you really don't want an eventfd > but something that's explicitly designed to associate specific data with > a notification? Using eventfd in that manner requires serialization, > buffering, and enforces ordering. > > I have no skin in the game aside from having to drop this conversion > which I'm fine to do if there are actually users for this btu really, > that looks a lot like abusing an api that really wasn't designed for > this. https://patchwork.kernel.org/project/kvm/patch/20230307220553.631069-1-jaz@= semihalf.com/ was posted at the beginig of March and one of the main things we've discussed was the mechanism for propagating acpi notification value. We've endup with eventfd as the best mechanism and have actually been using it from v2. I really do not want to waste this effort, I think we are quite advanced with v6 now. Additionally we didn't actually modify any part of eventfd support that was in place, we only used it in a specific (and discussed beforehand) way.