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 X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AAD49C433DB for ; Fri, 12 Feb 2021 16:00:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5894E64DEA for ; Fri, 12 Feb 2021 16:00:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232166AbhBLQAG (ORCPT ); Fri, 12 Feb 2021 11:00:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57312 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230515AbhBLP76 (ORCPT ); Fri, 12 Feb 2021 10:59:58 -0500 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F36C4C061574 for ; Fri, 12 Feb 2021 07:59:16 -0800 (PST) Received: by mail-ej1-x62b.google.com with SMTP id hs11so45886ejc.1 for ; Fri, 12 Feb 2021 07:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=golang-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yQtB9DQQCYhoE2PX3zsTi2OoG8c7N9zifSGdBLGMpRU=; b=P7JvmqoKUlPwbYY/W3Md5u/d01RJCmNBOeYtTfXs92AEtiC9YivrE84PxDu0n+N02L gesWb+j292sMEUyr5ctTX5IGac4iVjlcVnN1ahRKq+VLmA8ErVq0ZCc2X3iuuM8+PUl+ kI9fmuOff8qeVPLhxpbERC4MS93gj6B14V9PPWVDb2mURmuVn/88ZJwtBY9JSumVykwp DfkJVPgDssLVgvQ1HWTx2+QB29osXG+n0k1GvvSr2NAOUgDCWuTTObGzMsAuDWzKs5Bs xFEZIHl1U8MALR5uadD1YE5rAHF1RwOin0ANNZg5VWf/iL5ORbrUXH5akj1tuMWcDwbP rMqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yQtB9DQQCYhoE2PX3zsTi2OoG8c7N9zifSGdBLGMpRU=; b=BmJK0oMSUzg2X+NYazlmNlT/xCUH9oPAp/qkj38M4Rz2fv0SkQltYeXH/uNxZazOY1 1AuohuFWgLKceF2liEBb+l35MxxrjyIxQvT12K4JI6YsaPKYnwN30th+cLcjd3uQzIf4 puoqoY8qX3z0CTSCTVeL4vU5XAJDJJqZuvc/5hXCfujGisJDg00Nrtgdd1nU0tJS0bBn bv/ivu6umFIroHonnrqA5+y8hyQZWxoBKQvLF6iigXieTJLz9up5OiC6GtXNaBMSF94L 2vFbIIO/LEZRhNksSfZlp7hTcN7bWrWWvOS1oupz0+gTjgMkKpsQIKLjUH4XDOfnYnUc wc6Q== X-Gm-Message-State: AOAM531YOgnQ4OmZc+6pkrQgzXUMT66JPD9V5/EZd/kLEHv/IQTeYyOn At5Ak8FYuz6M27JJ55PB/Nl5b7yMDkR2hgPPLoN3eA== X-Google-Smtp-Source: ABdhPJxkERY/oPSU3XzhUsb2aRy7fBSqogheSCk2JXtUPt7fSrF/htK7vOhSmdS90JsKYB559clwRp7ujO8ykCKC/D8= X-Received: by 2002:a17:906:8555:: with SMTP id h21mr3585156ejy.403.1613145555571; Fri, 12 Feb 2021 07:59:15 -0800 (PST) MIME-Version: 1.0 References: <20210212044405.4120619-1-drinkcat@chromium.org> <20210212124354.1.I7084a6235fbcc522b674a6b1db64e4aff8170485@changeid> In-Reply-To: From: Ian Lance Taylor Date: Fri, 12 Feb 2021 07:59:04 -0800 Message-ID: Subject: Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated To: Greg KH Cc: Nicolas Boichat , "Darrick J . Wong" , Alexander Viro , Luis Lozano , Dave Chinner , linux-fsdevel@vger.kernel.org, lkml Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 12, 2021 at 7:45 AM Greg KH wrote: > > On Fri, Feb 12, 2021 at 07:33:57AM -0800, Ian Lance Taylor wrote: > > On Fri, Feb 12, 2021 at 12:38 AM Greg KH wrote: > > > > > > Why are people trying to use copy_file_range on simple /proc and /sys > > > files in the first place? They can not seek (well most can not), so > > > that feels like a "oh look, a new syscall, let's use it everywhere!" > > > problem that userspace should not do. > > > > This may have been covered elsewhere, but it's not that people are > > saying "let's use copy_file_range on files in /proc." It's that the > > Go language standard library provides an interface to operating system > > files. When Go code uses the standard library function io.Copy to > > copy the contents of one open file to another open file, then on Linux > > kernels 5.3 and greater the Go standard library will use the > > copy_file_range system call. That seems to be exactly what > > copy_file_range is intended for. Unfortunately it appears that when > > people writing Go code open a file in /proc and use io.Copy the > > contents to another open file, copy_file_range does nothing and > > reports success. There isn't anything on the copy_file_range man page > > explaining this limitation, and there isn't any documented way to know > > that the Go standard library should not use copy_file_range on certain > > files. > > But, is this a bug in the kernel in that the syscall being made is not > working properly, or a bug in that Go decided to do this for all types > of files not knowing that some types of files can not handle this? > > If the kernel has always worked this way, I would say that Go is doing > the wrong thing here. If the kernel used to work properly, and then > changed, then it's a regression on the kernel side. > > So which is it? I don't work on the kernel, so I can't tell you which it is. You will have to decide. >From my perspective, as a kernel user rather than a kernel developer, a system call that silently fails for certain files and that provides no way to determine either 1) ahead of time that the system call will fail, or 2) after the call that the system call did fail, is a useless system call. I can never use that system call, because I don't know whether or not it will work. So as a kernel user I would say that you should fix the system call to report failure, or document some way to know whether the system call will fail, or you should remove the system call. But I'm not a kernel developer, I don't have all the information, and it's obviously your call. I'll note that to the best of my knowledge this failure started happening with the 5.3 kernel, as before 5.3 the problematic calls would report a failure (EXDEV). Since 5.3 isn't all that old I personally wouldn't say that the kernel "has always worked this way." But I may be mistaken about this. > > So ideally the kernel will report EOPNOTSUPP or EINVAL when using > > copy_file_range on a file in /proc or some other file system that > > fails (and, minor side note, the copy_file_range man page should > > document that it can return EOPNOTSUPP or EINVAL in some cases, which > > does already happen on at least some kernel versions using at least > > some file systems). > > Documentation is good, but what the kernel does is the true "definition" > of what is going right or wrong here. Sure. The documentation comment was just a side note. I hope that we can all agree that accurate man pages are better than inaccurate ones. Ian