Received: by 2002:a05:7412:d008:b0:f9:6acb:47ec with SMTP id bd8csp268186rdb; Tue, 19 Dec 2023 16:42:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IFfgC9jSsol1FvoyUjBupqZ3mmBLRNe2MLh6R8qaAWF/kibedES4z0La9RIFZiZRUmW/iHV X-Received: by 2002:a05:6a20:548a:b0:17a:4871:63fd with SMTP id i10-20020a056a20548a00b0017a487163fdmr2259203pzk.0.1703032937599; Tue, 19 Dec 2023 16:42:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703032937; cv=none; d=google.com; s=arc-20160816; b=lBOMReZflZqbv+uC7VGzWOQJ4LtAvH9lyhVQlLu5xJ5Gqq1S/lxc5eCvlJ4X5R7dvT 8a1Sf4sFxSPOK4U5cndI3Ols3FvF44/C50VPa5NNXwwoKxTEaR24TQY/iepY0Nkoy8JP +N9gyttlrAvYYSXeXLNlA+6+R5V9WVPNeFXNvC577Xstd26XiDAijPr5n6uRrlTc8QqO mZpMZtXhag593M2fGfbqOfEeyzMke2Yy4VY/EcvQoPp8K2VPkyTVDxBIXza0ANtNXLUi ApGk/HpVg1Xt+TmHXzEd0Ur4n/v8HinrCd4NsqrIgMXEUGWJ2Sme/86wCf60kGP4rFuO MGcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=UrQBapL+nIn/dkB+R2v7IjM8W/+uNBfn7v6MtlUgLXo=; fh=8EYg68P4jfy0pyYWKje2HQIX/5yyw/s49tysdNtVA3I=; b=VtvsxglIuQsquezTYlmD3gwY+Hi5aypoxEb5TFYVr4bUmQhUPXI3mft23i6jelULfE D8nM3YAqaIah1eycl/WAZCvw7oiRGxj+N5V1g/hazuc8HhmJEoH6EYW0VFI1FrUuONwm 8uDWSwWyQJxtx8QZKnPstFx0+I/zrhayly9srw8JlZGMDcEZ6erYSrKe4TWh7SAOSNgN A1Bdcs+37RK4m/7WWesmQT6juenCB5mWLLzXBr1sURiSEvk7+YKkIPvaNKobVBN7bAz2 uxE5nne/I2dSjArHZigfPMtoFRvSAVQ5qZq0nA/kp9UM7+B2bY0Z1dFzY24u/2i68ugo nxqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b="KwwG/8Lx"; spf=pass (google.com: domain of linux-kernel+bounces-6197-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-6197-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id s185-20020a6377c2000000b005cd811e2ffesi6799491pgc.18.2023.12.19.16.42.17 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Dec 2023 16:42:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-6197-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b="KwwG/8Lx"; spf=pass (google.com: domain of linux-kernel+bounces-6197-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-6197-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 60DD328578C for ; Wed, 20 Dec 2023 00:39:21 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 812091D6AB; Wed, 20 Dec 2023 00:35:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="KwwG/8Lx" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9DAEE4423 for ; Wed, 20 Dec 2023 00:35:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD4EFC433C8; Wed, 20 Dec 2023 00:35:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1703032555; bh=XT/zovLOBmnZeQxmRj3HaYlA/gd3BKurq41D6Jrq9F0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KwwG/8LxoJGLo4BvzZqmImMTjb4Z3lchHZ236e2JuYFSqqOfWFtmsVmNRDA/qJsJf uZaHFRRVEnwi15A6O1YGdAnMw8Wf96XsHf5K2lUKrbZ1F8ZF+XjIZfOVDjsVPJ50Nc qa839JAIktgKGz8+DT5p838ZhgJ2duX74ItMm46A= Date: Tue, 19 Dec 2023 16:35:54 -0800 From: Andrew Morton To: Ahelenia =?UTF-8?B?WmllbWlhxYRza2E=?= Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , Andrew Morton , Li kunyu , Zhao Lei , "Mike Rapoport (IBM)" , Suren Baghdasaryan , Zhang Zhengming , linux-kernel@vger.kernel.org Subject: Re: [PATCH] kernel: relay: remove relay_file_splice_read =?UTF-8?B?4oCS?= dead code, doesn't work Message-Id: <20231219163554.a65b8d9e918aeb28e21b5c21@linux-foundation.org> In-Reply-To: References: X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Tue, 19 Dec 2023 23:24:14 +0100 Ahelenia ZiemiaƄska wrote: > Documentation/filesystems/relay.rst says to use > return debugfs_create_file(filename, mode, parent, buf, > &relay_file_operations); > and this is the only way relay_file_operations is used. > > Thus: debugfs_create_file(&relay_file_operations) > -> __debugfs_create_file(&debugfs_full_proxy_file_operations, > &relay_file_operations) > -> dentry{inode: {i_fop: &debugfs_full_proxy_file_operations}, > d_fsdata: &relay_file_operations > | DEBUGFS_FSDATA_IS_REAL_FOPS_BIT} > > debugfs_full_proxy_file_operations.open is full_proxy_open, which > extracts the &relay_file_operations from the dentry, and allocates > via __full_proxy_fops_init() new fops, with trivial wrappers around > release, llseek, read, write, poll, and unlocked_ioctl, then replaces > the fops on the opened file therewith. > > Naturally, all thusly-created debugfs files have .splice_read = NULL. > This was introduced in > commit 49d200deaa680501f19a247b1fffb29301e51d2b ("debugfs: prevent > access to removed files' private data") from 2016-03-22. > > AFAICT, relay_file_operations is the only struct file_operations > used for debugfs which defines a .splice_read callback. > Hooking it up with > > diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c > > index 5063434be0fc..952fcf5b2afa 100644 > > --- a/fs/debugfs/file.c > > +++ b/fs/debugfs/file.c > > @@ -328,6 +328,11 @@ FULL_PROXY_FUNC(write, ssize_t, filp, > > loff_t *ppos), > > ARGS(filp, buf, size, ppos)); > > > > +FULL_PROXY_FUNC(splice_read, long, in, > > + PROTO(struct file *in, loff_t *ppos, struct pipe_inode_info *pipe, > > + size_t len, unsigned int flags), > > + ARGS(in, ppos, pipe, len, flags)); > > + > > FULL_PROXY_FUNC(unlocked_ioctl, long, filp, > > PROTO(struct file *filp, unsigned int cmd, unsigned long arg), > > ARGS(filp, cmd, arg)); > > @@ -382,6 +387,8 @@ static void __full_proxy_fops_init(struct file_operations *proxy_fops, > > proxy_fops->write = full_proxy_write; > > if (real_fops->poll) > > proxy_fops->poll = full_proxy_poll; > > + if (real_fops->splice_read) > > + proxy_fops->splice_read = full_proxy_splice_read; > > if (real_fops->unlocked_ioctl) > > proxy_fops->unlocked_ioctl = full_proxy_unlocked_ioctl; > > } > shows it just doesn't work, and splicing always instantly returns empty > (subsequent reads actually return the contents). > > No-one noticed it became dead code in 2016, who knows if it worked back > then. Clearly no-one cares; just delete it. > All checks out for me. How on earth did you notice this? > --- a/kernel/relay.c > +++ b/kernel/relay.c > @@ -1073,167 +1073,6 @@ static ssize_t relay_file_read(struct file *filp, > return written; > } > > -static void relay_consume_bytes(struct rchan_buf *rbuf, int bytes_consumed) And all this goop wasn't even inside #ifdef DEBUF_FS.