Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1053658pxk; Mon, 31 Aug 2020 08:34:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwGxk6fqdaoNE7I+CRiGk1U0EU3QRdZkcipo4xflJvmzwK55hTYuK52OdlOi79fIG9bqSVG X-Received: by 2002:a17:906:474f:: with SMTP id j15mr1536769ejs.329.1598888048498; Mon, 31 Aug 2020 08:34:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598888048; cv=none; d=google.com; s=arc-20160816; b=HPRqqxQg+fV6fx2mr9pTBX3eShpqdoyS0kS5S7V+t0GimETU71XJIkhbJ9bG2YKBBt GoO+ktcy/Q/4dMjMUMpchj6/cMIIqI8YEf5IGLVTWNqhBqtgHip3ggwZbZO6qkcdYeZ4 lp7krthXHpKGIepI2rWZwQ7JpfI3diJdO9U/i5g+yCWegOqztWn5otygBUe0wz+533G6 5q9gpUBe5YlcUEslH0IUB6asFsPJOkju/SeziA5DbJRAeGtoAV93DnWolOwvnnN7bSVu sS3LWpsAmaGTK3hJFoEjasccDi7e17gDi0oWWre2LgmOjthXZWQNppAYtovYWmwzXZZ+ nt3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:content-disposition :mime-version:message-id:subject:cc:to:from:date; bh=/+V9+6gAChO8JJ0SPxKOmrxft++7FLXfFWWiKClH4D8=; b=afc6UPP5oBQfUpe0uZECgs4x0yJpNdSSSCcemyjCkeGIdqU4hU3o8sP1/ybmb9Y6sn nGv1wtSpo37zP5ZQ3p6Yfra9fHnRrke4hJg9e7Rr2QnHSvjsGr8IDGl6AJqekMM68EmN 6aCDFLcK7RidCn37F8w9GsSr9T2x9SRaxdJq3HnrLbaesI6+Tvb/MLTOelZ3EVIjCWEP ya8Zf6Q5LrT9ulB1gPqH1uWZvTw/iWO7nLHBfgEDXRO6oOJcl7gmCTahJN6erBqOGuR7 gIBsWOWeiaCO14EHS9nNyI/p2pPSPMIuI/V5SPI11bbZ03LHq7ivRfGBM1w/mDhJ92wK YprA== 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 c9si5369122edw.148.2020.08.31.08.33.44; Mon, 31 Aug 2020 08:34:08 -0700 (PDT) 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 S1729171AbgHaPch (ORCPT + 99 others); Mon, 31 Aug 2020 11:32:37 -0400 Received: from brightrain.aerifal.cx ([216.12.86.13]:48526 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729085AbgHaPcM (ORCPT ); Mon, 31 Aug 2020 11:32:12 -0400 Date: Mon, 31 Aug 2020 11:32:08 -0400 From: Rich Felker To: Jann Horn Cc: linux-fsdevel , kernel list , Linux API , Alexander Viro , Pavel Begunkov Subject: [PATCH v2] vfs: add RWF_NOAPPEND flag for pwritev2 Message-ID: <20200831153207.GO3265@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The pwrite function, originally defined by POSIX (thus the "p"), is defined to ignore O_APPEND and write at the offset passed as its argument. However, historically Linux honored O_APPEND if set and ignored the offset. This cannot be changed due to stability policy, but is documented in the man page as a bug. Now that there's a pwritev2 syscall providing a superset of the pwrite functionality that has a flags argument, the conforming behavior can be offered to userspace via a new flag. Since pwritev2 checks flag validity (in kiocb_set_rw_flags) and reports unknown ones with EOPNOTSUPP, callers will not get wrong behavior on old kernels that don't support the new flag; the error is reported and the caller can decide how to handle it. Signed-off-by: Rich Felker --- Changes in v2: I've added a check to ensure that RWF_NOAPPEND does not override O_APPEND for S_APPEND (chattr +a) inodes, and fixed conflicts with 1752f0adea98ef85, which optimized kiocb_set_rw_flags to work with a local copy of flags. Unfortunately the same optimization does not work for RWF_NOAPPEND since it needs to remove flags from the original set at function entry. If desired, I could further change this so that kiocb_flags is initialized to ki->ki_flags, with assignment-back in place of |= at the end of the function. This would allow the same local variable pattern in the RWF_NOAPPEND code path, which might be more elegant, but I'm not sure if the emitted code would improve or get worse. include/linux/fs.h | 7 +++++++ include/uapi/linux/fs.h | 5 ++++- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/include/linux/fs.h b/include/linux/fs.h index 7519ae003a08..924e17ac8e7e 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -3321,6 +3321,8 @@ static inline int kiocb_set_rw_flags(struct kiocb *ki, rwf_t flags) return 0; if (unlikely(flags & ~RWF_SUPPORTED)) return -EOPNOTSUPP; + if (unlikely((flags & RWF_APPEND) && (flags & RWF_NOAPPEND))) + return -EINVAL; if (flags & RWF_NOWAIT) { if (!(ki->ki_filp->f_mode & FMODE_NOWAIT)) @@ -3335,6 +3337,11 @@ static inline int kiocb_set_rw_flags(struct kiocb *ki, rwf_t flags) kiocb_flags |= (IOCB_DSYNC | IOCB_SYNC); if (flags & RWF_APPEND) kiocb_flags |= IOCB_APPEND; + if ((flags & RWF_NOAPPEND) && (ki->ki_flags & IOCB_APPEND)) { + if (IS_APPEND(file_inode(ki->ki_filp))) + return -EPERM; + ki->ki_flags &= ~IOCB_APPEND; + } ki->ki_flags |= kiocb_flags; return 0; diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h index f44eb0a04afd..d5e54e0742cf 100644 --- a/include/uapi/linux/fs.h +++ b/include/uapi/linux/fs.h @@ -300,8 +300,11 @@ typedef int __bitwise __kernel_rwf_t; /* per-IO O_APPEND */ #define RWF_APPEND ((__force __kernel_rwf_t)0x00000010) +/* per-IO negation of O_APPEND */ +#define RWF_NOAPPEND ((__force __kernel_rwf_t)0x00000020) + /* mask of flags supported by the kernel */ #define RWF_SUPPORTED (RWF_HIPRI | RWF_DSYNC | RWF_SYNC | RWF_NOWAIT |\ - RWF_APPEND) + RWF_APPEND | RWF_NOAPPEND) #endif /* _UAPI_LINUX_FS_H */ -- 2.21.0