Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp30275pxb; Wed, 18 Nov 2020 15:37:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJyolBbJ+x9szEdV6w8/Acr39mnsuVDemthfodXeMOz2A9f+wXk/xFtRgmkydhzQzij/ahuT X-Received: by 2002:aa7:cb58:: with SMTP id w24mr28316020edt.35.1605742663429; Wed, 18 Nov 2020 15:37:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605742663; cv=none; d=google.com; s=arc-20160816; b=XwA095+mRMwbJ1EEorTJ+5JrnwwfuDKfcUesJI1Qq9GCBZ/DYiZxzoMJAaFXAJMUHT vXCRx0EcwhDNqlwjmN3xv9AAKKDZU6pszFMG0+PXavB9I1iUQZwdkTv81nBfnllE4mPk 7DbWsc0Wz7WBftV5bKm5ZMkarHuRtT/tMq0sadPsmktEgygekyOk98DU/Ep/CtYLOVzy /fI7CVCPPWn/BMBBnHp1muXv6cQ2ZaCnNDnMt7E3GLZ5wLpj7vSBdTzbNBQB+L1rfxBX xq1eYkQPO6OxuRpiMjn6ZPumdXMX8yzvfT7LR5M6bE1Tnnf6+eqIoW/381wtWGiCktYA Injg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=EDJKTOz2YTofu4TWmvghbysExy+0ElmwHNFJlmmbQoU=; b=OTsKZc4r8zqjfIDPXqIqp6Y8m44Ko1a1zqvLw+Gu6pXlJucGZtZlZlkOEgNcsZw5pD kDtSlj4k8u0rzOPNQYVddfAFYZTHB1vJqk/P5XQi8RAod7AQ0CeK8PG+jHoIjK+qVQ+d 2BLr2nGBsnLC9bMSE75CF6prepAL8Q5i9ZapXdErMuDD6Ca/Xs9ntcBefRg7VxU6Pvo/ Z99+iPHmHt3jWcSsLjzhin7BCRIuRJa1MnAa+WRdCXRbb1koaMvbpCB+w64y0EVF7jIF 7asNrPo2cPQwz0nGO6L+O+e/oYzwrb/zRoR0G16ICgroHr4Z7Vci09ZfNgXIyZMTElpt KKoQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id df6si16517217edb.508.2020.11.18.15.37.20; Wed, 18 Nov 2020 15:37:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726756AbgKRXfC (ORCPT + 99 others); Wed, 18 Nov 2020 18:35:02 -0500 Received: from mx2.suse.de ([195.135.220.15]:58696 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726098AbgKRXfC (ORCPT ); Wed, 18 Nov 2020 18:35:02 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 4A6D8AF7E; Wed, 18 Nov 2020 23:35:00 +0000 (UTC) Received: by lion.mk-sys.cz (Postfix, from userid 1000) id 073F0603F9; Thu, 19 Nov 2020 00:35:00 +0100 (CET) Date: Thu, 19 Nov 2020 00:34:59 +0100 From: Michal Kubecek To: Jens Axboe Cc: Christoph Hellwig , Alexander Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] eventfd: convert to ->write_iter() Message-ID: <20201118233459.d2p5gh7boguzcybg@lion.mk-sys.cz> References: <8a4f07e6ec47b681a32c6df5d463857e67bfc965.1605690824.git.mkubecek@suse.cz> <20201118151806.GA25804@infradead.org> <20201118195936.p33qlcjc7gp2zezz@lion.mk-sys.cz> <4e4d222c-ed8b-a40d-0cdc-cf152573645c@kernel.dk> <20201118231835.u6hqivoayq5ej4vg@lion.mk-sys.cz> <7323253d-003a-456c-166c-d85a614c8bf6@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7323253d-003a-456c-166c-d85a614c8bf6@kernel.dk> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 18, 2020 at 04:25:37PM -0700, Jens Axboe wrote: > On 11/18/20 4:18 PM, Michal Kubecek wrote: > > On Wed, Nov 18, 2020 at 02:27:08PM -0700, Jens Axboe wrote: > >> On 11/18/20 12:59 PM, Michal Kubecek wrote: > >>> On Wed, Nov 18, 2020 at 03:18:06PM +0000, Christoph Hellwig wrote: > >>>> On Wed, Nov 18, 2020 at 10:19:17AM +0100, Michal Kubecek wrote: > >>>>> While eventfd ->read() callback was replaced by ->read_iter() recently, > >>>>> it still provides ->write() for writes. Since commit 4d03e3cc5982 ("fs: > >>>>> don't allow kernel reads and writes without iter ops"), this prevents > >>>>> kernel_write() to be used for eventfd and with set_fs() removal, > >>>>> ->write() cannot be easily called directly with a kernel buffer. > >>>>> > >>>>> According to eventfd(2), eventfd descriptors are supposed to be (also) > >>>>> used by kernel to notify userspace applications of events which now > >>>>> requires ->write_iter() op to be available (and ->write() not to be). > >>>>> Therefore convert eventfd_write() to ->write_iter() semantics. This > >>>>> patch also cleans up the code in a similar way as commit 12aceb89b0bc > >>>>> ("eventfd: convert to f_op->read_iter()") did in read_iter(). > >>>> > >>>> A far as I can tell we don't have an in-tree user that writes to an > >>>> eventfd. We can merge something like this once there is a user. > >>> > >>> As far as I can say, we don't have an in-tree user that reads from > >>> sysctl. But you not only did not object to commit 4bd6a7353ee1 ("sysctl: > >>> Convert to iter interfaces") which adds ->read_iter() for sysctl, that > >>> commit even bears your Signed-off-by. There may be other examples like > >>> that. > >> > >> A better justification for this patch is that users like io_uring can > >> potentially write non-blocking to the file if ->write_iter() is > >> supported. > > > > So you think the patch could be accepted with a modified commit message? > > (As long as there are no technical issues, of course.) I did not really > > expect there would be so much focus on a justification for a patch which > > (1) converts f_ops to a more advanced (and apparently preferred) > > interface and (2) makes eventfd f_ops more consistent. > > > > For the record, my original motivation for this patch was indeed an out > > of tree module (not mine) using kernel write to eventfd. But that module > > can be patched to use eventfd_signal() instead and it will have to be > > patched anyway unless eventfd allows kernel_write() in 5.10 (which > > doesn't seem likely). So if improving the code is not considered > > sufficient to justify the patch, I can live with that easily. > > My point is that improving eventfd writes from io_uring is a win with > this patch, whereas enabling kernel_write() makes people more nervous, > and justifiably so as your stated use case is some out of tree module. > > So yeah, I'd focus on the former and not the latter, as it is actually > something I'd personally like to see... OK, I'll send v2 with a different reasoning in commit message. Michal Kubecek