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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04CB1EB64DC for ; Mon, 17 Jul 2023 08:29:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 366EE6B0074; Mon, 17 Jul 2023 04:29:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 317296B0075; Mon, 17 Jul 2023 04:29:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 206118D0001; Mon, 17 Jul 2023 04:29:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 0F42D6B0074 for ; Mon, 17 Jul 2023 04:29:49 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id CF3B81A042B for ; Mon, 17 Jul 2023 08:29:48 +0000 (UTC) X-FDA: 81020430456.29.3FCE07F Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) by imf07.hostedemail.com (Postfix) with ESMTP id 0D83040013 for ; Mon, 17 Jul 2023 08:29:46 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=semihalf.com header.s=google header.b=e52IJgo7; spf=pass (imf07.hostedemail.com: domain of jaz@semihalf.com designates 209.85.166.169 as permitted sender) smtp.mailfrom=jaz@semihalf.com; dmarc=pass (policy=quarantine) header.from=semihalf.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689582587; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KrEcIar0BkfpmBL+8BCmNKqe2TUSK3LL+WBdNYsOjsM=; b=TyY64/uIU5C+aHPu60REvZBDk6+Oo8Vg2FmkJfhDd5gKXcDWZ+8D0xnTp/G2lbY5aEQ56o Jp5tbHew0zuRNxcyesM+IfldZEWQ6iajKohA+7oGm1KUMg0b5c/6oPvfqajQPm/Q7mlwdr eq0AkoENVSVbrl7EJQW8zUtqfpsHGkk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689582587; a=rsa-sha256; cv=none; b=pSPcxIRcAbASR0NKcwgtNT1SvpRdFJVNNFHPdpSCztq3Xk6tfbFWmekecuYFw9LlxtMzLn /AEmZvQYIGE+rHtw0yJdpGGVTzHjwbuflOaE5ioVQthCfiZ4NR6hNEhxPBjF00jnBVVgel 0dyE1IjUm8gE4oNwKOpBQoef2Ssl4Zk= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=semihalf.com header.s=google header.b=e52IJgo7; spf=pass (imf07.hostedemail.com: domain of jaz@semihalf.com designates 209.85.166.169 as permitted sender) smtp.mailfrom=jaz@semihalf.com; dmarc=pass (policy=quarantine) header.from=semihalf.com Received: by mail-il1-f169.google.com with SMTP id e9e14a558f8ab-3457a3ada84so22440695ab.1 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=aa6WhdUWoXi3zNnO2qxFwqJbhc2G1AYEEzBWhFW3nXSlj7Yu+EPM5ReMKh4gIjUzYV hbEXf9Z/i6/BGexmWyyn7wdqjdLWzlNazTaUJRFxLFep/3S6qwodrrxb6MVu6Amty1OG F5+YH7n8HBvo6Tu0hfUZyZ78QErZchzO6AHyZhm8oBldpG9oSCzFYLrT5q/mBz5S8B+t BDdXIflgwAzKw83ZfmG8qu8IL9TmG22GteSF1udJeNbg1ehaO6XJ0av2b5d62X/nQM+q Y8oFp3aFB+PXy2Uqw8xUI/T2sjt2Dya0YJCM4MxTpaFB8rTcGbqw72/RZXnhoMG8Jo1v b+/g== X-Gm-Message-State: ABy/qLZzDwqnTH97clX1gvk5LKY+W8sUSt6Tv8SdiJxFeYugjgFR0SBq 5o9B3e0KHBkJnmgwo1mGvbM3B3qyHwqOMtSRpr4mwA== 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 X-Rspamd-Queue-Id: 0D83040013 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: xsthz31zxdg5o194888n7jt9iidc5mkj X-HE-Tag: 1689582586-823136 X-HE-Meta: U2FsdGVkX1+Espqe0XtuoWmxolfC/O4azW0Mp27y8MrHtnaXJ7li99HiEBCDQc/QcgM6z9PXuVY+e7ghMUqYyenZT7Mh53yWbNEULFW3db/VH1Cy7y8y6DHaCW7nhXxwperFtR5qWw92JVPh6k3mmbLHfmdXEuDtznsGa82S2Q+tLHuW6HI43wYK2yu9+DOcnQRNXvcS+HcWgOKs/z1SUpk6sDJBj7WklQxOfpRnnmccNqtcG7lek8WSwi7Xn2VWPkAV7aX8L4+L5jrtluk5W8Hif4jhRm3OaabIbf9xC7x0vrZ6CjFI1cOnWueVF7vkW7UcMgnsFkFxIiKmbJY6/BqGm+zD0gBFJuVExenbK4T9XayHptcbn2eXE5VX6qzcUAByNdI1Ufc5wdKVJdKme5gvsiDzkCVSR6V/JI7yUN+Y6vQpqEucyUBScbDBUZDFgbwuTPLKOk1ZDqVComGq+7dU71jpC4ixmO5qgHen09Uwyka2JfuwxyoSPqkEO1Qv7ilH7Y0oqM28x1TtC++zezNWlGhhs9Vn8w2EHnl4efnTTuOirduFj8Q/F5j08YaOVek1ccDMHoHTmsK0bsksbDrxWNRB2K/xEfruTVgq3whbajOwvXHG/6AOHu1TOKwCTyppVjIhcwoPtmistyLyUcQvkuZnHWew6jYvv++ITsshcFiKvbzh9Z4ecmyCSiz/roZvci3UquyuaOe2ulbEBOyo9fkZcm6pSybvZPZX/ND8r58DVDe6YaO6DI5+QBhZO6wncRrEm5xTrZY/3mdTF6Sv5ADRrT+taK8ExZAmmWuXomg0fSqenYbX2H7/4KUO4lTFzhtlIkUzQoX9qUrLbW8kfjTD09/r8tuuHy3Zxm66eToAYMfcBNMQycZssPsNWrI28X6KMzo151MaTnfI2kBqPcXhff+yjPqbYfVgLptwE9nHE7mBfakbfX3ySthMnVPpgOGV0bj8TtMJFLH 9ZhU48OH lcEL6WD94iJYdpsv0RKl7MZOhRl2ybVACVNs2tv4xAdjzxugtjiRotS6tB/fjL4dGSdMZ52gjS7rl7Wu6ctyU4BWgr2kCtQoLjTJeh9CwHPrq6IYNRZmDBzpEQ9NAeAbmcbxtfxM6UxXsKEMc9eY71E+/WMzS8It+097gWtzaseokk1dd+x0JqcvUTbAl89gXMwXq8NWgerZIP5muG6vf51bZ4Qx8bdsSod4krnpWOCDtPwflQnenR8S6YiLKzBAU5eLsS7VZ9YiEXv/FkUZWNRMv6mLrqL4d5y8noWwQFE2eGKFQ36Cos4vPn77KD+ZJYvnyNdX6QHc9Uz1Sml8T7mlPYyGX/iekjDEbwjMqeE+2UeQNYVHiJs1LMuByjB0dyh3TQDVY+8BFTocgXXRrILL3bn859ifgDkVsZwE2MzEHqGA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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.