From patchwork Wed Oct 17 22:44:15 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Darrick Wong X-Patchwork-Id: 985580 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-cifs-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=oracle.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=oracle.com header.i=@oracle.com header.b="2ilMuWAE"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 42b6gG0Ldbz9sBj for ; Thu, 18 Oct 2018 09:44:26 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727205AbeJRGmO (ORCPT ); Thu, 18 Oct 2018 02:42:14 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:54406 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727175AbeJRGmO (ORCPT ); Thu, 18 Oct 2018 02:42:14 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9HMi3C0189411; Wed, 17 Oct 2018 22:44:20 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : from : to : cc : date : message-id : mime-version : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=zQALILQr9U+7OIPR4EjpK3HtCxxS0f5CSoa6TXZMX6o=; b=2ilMuWAEXORm+LsZmmU6BlLwNLeTrOtsYWF7J8+HqIcMwQ2dE+dQ6OFknzDLNJpMQyHL xFNeeXUG59cB+RNE00JW8nWIe3aqeC7KwTSXre/WZVCgNDOYPcLkave7qp/zccQGg7Ac 38M0Zuzy431OmDlA818onA8k0kHgjSguECi6JUhh6tVxC/U8hVnmCq3ShW0COxTo5jXx X21xV8z1xSSjCT4DtrPKBTAvELQcmp4o9WICWB6/in3RxZSaOJDCWvTCsmYO5lybL9N3 +UpuIcFKBVyaSf+B8TrZX6hcaqbtRMCVNnxATdAd467Ys9+5W78YFZQT5n41emABwP8I RQ== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2n39brhnxp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 17 Oct 2018 22:44:19 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w9HMiINZ005171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 17 Oct 2018 22:44:18 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9HMiH6d028180; Wed, 17 Oct 2018 22:44:17 GMT Received: from localhost (/10.159.132.177) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Oct 2018 15:44:17 -0700 Subject: [PATCH v6 00/29] fs: fixes for serious clone/dedupe problems From: "Darrick J. Wong" To: david@fromorbit.com, darrick.wong@oracle.com Cc: sandeen@redhat.com, linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, ocfs2-devel@oss.oracle.com Date: Wed, 17 Oct 2018 15:44:15 -0700 Message-ID: <153981625504.5568.2708520119290577378.stgit@magnolia> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9049 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=910 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810170188 Sender: linux-cifs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-cifs@vger.kernel.org Hi all, Dave, Eric, and I have been chasing a stale data exposure bug in the XFS reflink implementation, and tracked it down to reflink forgetting to do some of the file-extending activities that must happen for regular writes. We then started auditing the clone, dedupe, and copyfile code and realized that from a file contents perspective, clonerange isn't any different from a regular file write. Unfortunately, we also noticed that *unlike* a regular write, clonerange skips a ton of overflow checks, such as validating the ranges against s_maxbytes, MAX_NON_LFS, and RLIMIT_FSIZE. We also observed that cloning into a file did not strip security privileges (suid, capabilities) like a regular write would. I also noticed that xfs and ocfs2 need to dump the page cache before remapping blocks, not after. In fixing the range checking problems I also realized that both dedupe and copyfile tell userspace how much of the requested operation was acted upon. Since the range validation can shorten a clone request (or we can ENOSPC midway through), we might as well plumb the short operation reporting back through the VFS indirection code to userspace. I added a few more cleanups to the xfs code per reviewer suggestions. So, here's the whole giant pile of patches[1] that fix all the problems. This branch is against current upstream (4.19-rc8). The patch "generic: test reflink side effects" recently sent to fstests exercises the fixes in this series. Tests are in [2]. --D [1] https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=djwong-devel [2] https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/log/?h=djwong-devel