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 491E0C00528 for ; Fri, 14 Jul 2023 07:05:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BAF226B00AE; Fri, 14 Jul 2023 03:05:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B41228E000B; Fri, 14 Jul 2023 03:05:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 98A736B00AE; Fri, 14 Jul 2023 03:05:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 8856B6B00B0 for ; Fri, 14 Jul 2023 03:05:44 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 27DED8015B for ; Fri, 14 Jul 2023 07:05:44 +0000 (UTC) X-FDA: 81009332208.12.DD20EF6 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf24.hostedemail.com (Postfix) with ESMTP id CDB0818000B; Fri, 14 Jul 2023 07:05:40 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ukDx1eRh; spf=pass (imf24.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689318341; a=rsa-sha256; cv=none; b=tshWLhMmnk5mhp/3/2q4ubGrvxr2VzTSaBtU/GtjOuC3WS4x4nrvFha+WvI1hqdD/JxQTZ fcMRszaWafwM27lO5Dr6wCmw0ZMsBFc8mG7eJShnbRpU/km5hqHS8jsZDBl9zISaon2gW3 LVwF2C393Bi30z5gwD95TjeBIayTcFs= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ukDx1eRh; spf=pass (imf24.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689318341; 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: in-reply-to:in-reply-to:references:dkim-signature; bh=VJuaKwcyW0mQQUmJJUp2oBpfum1MY5ZFuCO9cqVTLwI=; b=Ef4/q8FJGwmpzDOw+LS9v2SmwsRImfn/QPsCAP42eXaH5nE9JwHp39DR3KjyvSsffwztom h/JDZUydpgpZvavYpEGhh0FuISXTn8HMgE5knp/k8Wu+DOf7oCiKnIxnRNYNGuKd15bSNq W9yX8XU+ooBZ36QDGbHrci9cFoboS5s= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BA2B261BD1; Fri, 14 Jul 2023 07:05:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72352C433C8; Fri, 14 Jul 2023 07:05:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689318339; bh=jyWvUrZcUvjNBBSZOzXCNGPPxcxV/q9OYHwe4H3B3Lw=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=ukDx1eRh8ZivXqHNYBn5Q0ezu7jPxA8DBkgLn6Yr4ieEasOnILafdrjyXNGEm446B vdoY8r4oSZIdNajc3UECepRL8sXl8WF1aY3nsBTYeT1jETstZ0f8AhW7bTRQc/52Qq P+stCjuut9rZUb/FtZq2RC8GkYNcmH18gWUjcC/YVZwiCNSkJoOeVjb4/L8KcmM6xP IeKh3hfbNuWYqjO1NcV70XYwdDRmrE9otI0QO8uXvZ2x+z2rjsCQR5r+pIi8kHOFqH yUig3DyDnWCSEK1kxr9YLeu9ZSrBGXd6ZPFhVoSKNhVLjgUv6X+4bGRfk/gzLXxZ3w K4WbhoY8kPy2A== Date: Fri, 14 Jul 2023 09:05:21 +0200 From: Christian Brauner To: 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 , jaz@semihalf.com Subject: Re: [PATCH 0/2] eventfd: simplify signal helpers Message-ID: <20230714-gauner-unsolidarisch-fc51f96c61e8@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230630155936.3015595-1-jaz@semihalf.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: CDB0818000B X-Stat-Signature: da8stwrfpr17797naaockfmepu7dkuhe X-Rspam-User: X-HE-Tag: 1689318340-512459 X-HE-Meta: U2FsdGVkX1+mudj3IQoEv01rcwl2e8xSWs2Ja4DO+43HiERbmzBxgMiFSDVLw7RSUqSF4IzkLEwP6v6e3FqjVSGBKPhLp9nrj1vvAOPPbogZ9hjQgtk6M7ohukXCu7cNYGWSYRWAjYLr6CIPmwUfC6MQrISr8hZ6tKRakNiCtHoOGY9jZcIT6s98g2m64KYXkSEjCySzSgza3beePoNVgmEMsveN8DyZnqa8bKv3qaVzyU2DMjq3kdandcg+bp+ultZIyxCMQrHOoxViYIQofCnZ9O9/GJoPOTnJAvXs21+6+p3f+Lx/q5IHUtdUG1aic5nKTmkcTlpSiBRpGSOsOSAfYek0ihNRiqt2dBZJbhDTbLyDaUzbIk8nuMW82dqQeHfTDMcqEECkme4bD20W9UujgeYdpyPN/OG7jVyoiR/etRKZy4bkjsYqEgAekx+41nldjEzuX0OTkNvWkLpF2uNE0p6qdSuW67d09ONhqwGVdAo31yC5NxRYoJMlbuMd9dh+yCwwXzubyl9OHFUsAg3rwaYoc/FwOQn18FD0uL92sOmIWgha2S4V3wJIojFhBxaCFKzwTHe2HHDmbGT8x6yenqbDHZ3PEmEOqYksStatuqtrvBA4OogDxjJp7QlIUPCI8kfAX/IGOfvAdMT5MIMc+aoNCd08RZDPX6iYCZsztnVmO+A5H3CVppdV3XbXfJyROUANBZyxuSOhehXOGFvq8mnvkVXFlO4M3Uke1vulKNz/6YDADYNYkLHW1N8ZpKI7VDrcX95McwOhf60ytnBpbaWtTSoDlnPA//oCWkouw2FGcp57l/UNUnfAL0mj9M5yG5U5M4wuFdvIdpejgo7K/PXT9fSGbdx9ZHxIg2i8YVOWGXxhmA9KF1BiJzCeACSEx2Kj1lxIKUvc/kSLyw/5+uFhYDLvnq5dx00fX9patzOv/HdWnHOT5d1a5PjJO2otu8e8t+hV4yxMylK GJ+JNi0j xdeqGgvUY2YgoGvTSswxUOsfqatDAMMyQnCadOTlie6k/NbwpoUS4WO4SYuK1k9+RMYs+3299t9YcVXIwu/pyvoYRJpTrctO23/hH+hDAlm2g9/MMIXFk8BU9E7DMJJjD/sT/6jsGKvirWl87HMwxp1G0cnP3DTHOMvKLAS/QLEZeO3dm2Kw0m67c3M8fXjP/4cebmlnSMgTOWJ2qADEVFIj0hXKrqDreICOBHeqVbBw0aOYlEw9smm9Ws1ik42PgQgV5Yj3gDJZmgZFtlzpBzgKILOVSbhmWW77PJMVoPirRRX4n2TW3DKOrgw4Z36R9TDdED1q+yeseYXBwM4xlYsurwNu7zydH5kaIGEVT5pee/c/GDsmFVlovszqI1HtuJ916mOCzyFm88+sspJOpowZnA+n3hv7kDONOv9UgqFYW2Pe0JR82X4Cg0mt6J7iHxMkgEr6xZJAbWJFJ+CZk159A3IX1IojCEVcN 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: 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() helpers > > 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-jaz@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 possible > 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.