Received: by 10.223.164.202 with SMTP id h10csp1382167wrb; Wed, 15 Nov 2017 19:16:04 -0800 (PST) X-Google-Smtp-Source: AGs4zMayMByk9u0wR1uA7J5/yCvIbRBn/Yu6OA7fxSFLwNsfmXk/rpN/U2EVvgGIRdcLj0A67iXC X-Received: by 10.84.148.134 with SMTP id k6mr256683pla.406.1510802163973; Wed, 15 Nov 2017 19:16:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510802163; cv=none; d=google.com; s=arc-20160816; b=UY4nkReLUIuN5tgDSmTzC5suWxJMfepVGa1UskXijBzFUncYWuPKx0VM8P0tazYLL/ rITb20UJBkmgpYKvWEcU9nXP7OPBhz9fDn3WWM2YvVvgkuk5lwIfk1arOutYkBbRI67p FkQB9xCxRQV2uiz7KIbLDLkfiwimcfH3WDZqMlB1j5OZX3PmyeuhqCIwYCcf1EBH2mwS 46G3nsezMkp1wZKaqvpuBsyfIg3ZfiQScm4pfvL4yILogKt6lPjl/ixSr9R/vbgd+U/h w/1V47s7tLxM9RJnE7WHhaNYGWjH04qrwmEZUOQfJ3d54NcJL4dq5hCLH00ZP7+VGhUi SN8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=XMEmhYblA5Al3CZqM9I+er5QnaP78OvsQmvsJBerzgo=; b=OJPquz06ko9aCmNZNcILL62nbGS+UXkPPyCXRBcmc89HoNdJ2XL12y6ailNX5PS+Po L5m1AV+YVRVfDuAxJHzin+4zyK/zTEjzzdmgc/SLmOySl5pkA+pB82pTiTg8NcAVu/k8 AYwd7veU1u8K7vUqRIUtt0Pdfy+sLdTy8XvinMAkrDMGquc/NsW5g6i4/buHET1hHTjX +qVLKq0raKiaEy+tFG9pIes9n0WosYk9LhT+2Vsj55Lrtio2bv0vU3V6lBcTHQ8Ssd5P GiQPJeroeFxR60VoSYtFHqfVaFPDip6gfHwIftWJWApndwLAc85NaTSAT8Q3yGhsMST9 VxEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rrqsUbLF; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f3si109048pld.213.2017.11.15.19.15.50; Wed, 15 Nov 2017 19:16:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rrqsUbLF; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758737AbdKPA6M (ORCPT + 89 others); Wed, 15 Nov 2017 19:58:12 -0500 Received: from mail-ua0-f182.google.com ([209.85.217.182]:47782 "EHLO mail-ua0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758343AbdKPA6F (ORCPT ); Wed, 15 Nov 2017 19:58:05 -0500 Received: by mail-ua0-f182.google.com with SMTP id s28so11541122uag.4; Wed, 15 Nov 2017 16:58:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XMEmhYblA5Al3CZqM9I+er5QnaP78OvsQmvsJBerzgo=; b=rrqsUbLF9vQZUjY4fGqcqw9RvSJFUJB9IqfPRtmU5aMCWS+hAnLKQUYB51ol/KA8fy yW187O2uSIEdKXLM9qoD7OEEllXOpu1/JD6XTBEtG/XHnyad1bGyNZBNLT0KBbvWYjC+ Rgw7CIXFgOZA1YgVcyL6aXXeGltan4B9GJ6Z5HTwTjpazbbEAFs6QWaBSourwXbk72d9 DQjHwm9B26pUmxOm/orjs0lASCtd85KPd2zex7E5ULTa8GJp1BtdfdY7artbySA8ytLZ tcIHn4jY7TIQkjGYBpsxZXpHEkW88QT6kG/4tPK+upUFhyfL5vEWLHwGkTWBLjBSKgSU IkNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XMEmhYblA5Al3CZqM9I+er5QnaP78OvsQmvsJBerzgo=; b=ANe3N9ECFaxo8WOhBpm5AUaFFcBbKA+yCbefBQrX5WuS9tGl/i1aQB9be1WKHdacrR d+afRnInqmfzN5H3KIDkVEIlRJTrxjuMmvsQ8dqAs9LGYhDjy8VYd+5i0PGUqikL7KQ9 +uWgYtoVpQgRrR3t3KMv6zJgk4EZMWImphKHi03OFta0ME49FFLsIAJ/Ha9cMZ6fh7/A +jlxGqhXGxbiDc4HOQp5cwAZZi2cyaVNsaSb5zadNryf7T509FdaIegCJxJIua9KjpLp ryHlrFTpAhr1VOfuewIE+eZU1LhrjtsAyVdyMkWKqlwwvB76dp+VInfiHrWvEWZrtz+n lXcQ== X-Gm-Message-State: AJaThX5g8qMVDfGLAkeoFxa4dmosSOqpT0qytdFaxMAxoVkRKPBVUhfi UY6E/O+OhE8F+pWtL2aRa7OhcXgImARfEhf573c= X-Received: by 10.159.60.98 with SMTP id w34mr15661982uah.27.1510793884387; Wed, 15 Nov 2017 16:58:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.80.253 with HTTP; Wed, 15 Nov 2017 16:58:03 -0800 (PST) In-Reply-To: <20170426180215.42572-1-apronin@chromium.org> References: <20170418233649.78805-1-apronin@chromium.org> <20170426180215.42572-1-apronin@chromium.org> From: Dmitry Torokhov Date: Wed, 15 Nov 2017 16:58:03 -0800 Message-ID: Subject: Re: [PATCH v2] ecryptfs: sync before truncating lower inode To: Andrey Pronin Cc: Tyler Hicks , ecryptfs@vger.kernel.org, lkml , Gwendal Grignou , Dmitry Torokhov Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 26, 2017 at 11:02 AM, Andrey Pronin wrote: > If the updated ecryptfs header data is not written to disk before > the lower file is truncated, a crash may leave the filesystem > in the state when the lower file truncation is journaled, while > the changes to the ecryptfs header are lost (if the underlying > filesystem is ext4 in data=ordered mode, for example). As a result, > upon remounting and repairing the file may have a pre-truncation > length and garbage data after the post-truncation end. > > To reproduce, make a snapshot of the underlying ext4 filesystem > mounted with data=ordered while asynchronously truncating to zero a > group of files in ecryptfs mounted on top. Mount ecryptfs for the > snapshot and check the contents of the group of files that was > being truncated. The following script reproduces it in almost 100% > of runs: > > cd /tmp > mkdir -p ./loop > dd if=/dev/zero of=./file.img bs=1M count=10 > PW=secret > > LOOPDEV=`losetup --find --show ./file.img` > mkfs -t ext4 $LOOPDEV > mount -t ext4 -o rw,nodev,relatime,seclabel,commit=600,data=ordered\ > $LOOPDEV ./loop > mkdir -p ./loop/vault ./loop/mount > mount -t ecryptfs -o rw,relatime,seclabel,ecryptfs_cipher=aes,\ > ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_passthrough=no,\ > ecryptfs_enable_filename_crypto=no,passphrase_passwd="$PW",no_sig_cache\ > ./loop/vault ./loop/mount > for i in `seq 1 100`; do echo $i > ./loop/mount/test.$i; done > sync > for i in `seq 100 -1 1`; do truncate -s 0 ./loop/mount/test.$i; done & > sleep 0.1; sync; cp ./file.img ./file.snap; sleep 1 > umount ./loop/mount > umount ./loop > losetup -d $LOOPDEV > > LOOPDEV=`losetup --find --show ./file.snap` > mount -t ext4 -o rw,nodev,relatime,seclabel,commit=600,data=ordered\ > $LOOPDEV ./loop > mount -t ecryptfs -o rw,relatime,seclabel,ecryptfs_cipher=aes,\ > ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_passthrough=no,\ > ecryptfs_enable_filename_crypto=no,passphrase_passwd="$PW",no_sig_cache\ > ./loop/vault ./loop/mount > for i in `seq 1 100`; do > if [ `stat -c %s ./loop/mount/test.$i` != 0 ] && > [ `cat ./loop/mount/test.$i` != $i ]; then > echo -n "!!! garbage at $i: "; cat ./loop/mount/test.$i; echo > fi > done > umount ./loop/mount > umount ./loop > losetup -d $LOOPDEV > > Signed-off-by: Andrey Pronin > --- > > Changes since v1: > - Switched to datasync=1 for ecryptfs_fsync_lower() in truncate_upper()\ It looks like this patch got lost... Can we get it in? Thanks! > > fs/ecryptfs/ecryptfs_kernel.h | 1 + > fs/ecryptfs/inode.c | 6 ++++++ > fs/ecryptfs/read_write.c | 22 ++++++++++++++++++++++ > 3 files changed, 29 insertions(+) > > diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h > index f622a733f7ad..567698421270 100644 > --- a/fs/ecryptfs/ecryptfs_kernel.h > +++ b/fs/ecryptfs/ecryptfs_kernel.h > @@ -689,6 +689,7 @@ int ecryptfs_read_lower_page_segment(struct page *page_for_ecryptfs, > pgoff_t page_index, > size_t offset_in_page, size_t size, > struct inode *ecryptfs_inode); > +int ecryptfs_fsync_lower(struct inode *ecryptfs_inode, int datasync); > struct page *ecryptfs_get_locked_page(struct inode *inode, loff_t index); > int ecryptfs_parse_packet_length(unsigned char *data, size_t *size, > size_t *length_size); > diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c > index 5eab400e2590..a96988ba6928 100644 > --- a/fs/ecryptfs/inode.c > +++ b/fs/ecryptfs/inode.c > @@ -827,6 +827,12 @@ static int truncate_upper(struct dentry *dentry, struct iattr *ia, > "rc = [%d]\n", rc); > goto out; > } > + rc = ecryptfs_fsync_lower(inode, 1); > + if (rc) { > + printk(KERN_WARNING "Problem with ecryptfs_fsync_lower," > + "continue without syncing; " > + "rc = [%d]\n", rc); > + } > /* We are reducing the size of the ecryptfs file, and need to > * know if we need to reduce the size of the lower file. */ > lower_size_before_truncate = > diff --git a/fs/ecryptfs/read_write.c b/fs/ecryptfs/read_write.c > index 09fe622274e4..ba2dd6263875 100644 > --- a/fs/ecryptfs/read_write.c > +++ b/fs/ecryptfs/read_write.c > @@ -271,3 +271,25 @@ int ecryptfs_read_lower_page_segment(struct page *page_for_ecryptfs, > flush_dcache_page(page_for_ecryptfs); > return rc; > } > + > +/** > + * ecryptfs_fsync_lower > + * @ecryptfs_inode: The eCryptfs inode > + * @datasync: Only perform a fdatasync operation > + * > + * Write back data and metadata for the lower file to disk. If @datasync is > + * set only metadata needed to access modified file data is written. > + * > + * Returns 0 on success; less than zero on error > + */ > +int ecryptfs_fsync_lower(struct inode *ecryptfs_inode, int datasync) > +{ > + struct file *lower_file; > + > + lower_file = ecryptfs_inode_to_private(ecryptfs_inode)->lower_file; > + if (!lower_file) > + return -EIO; > + if (!lower_file->f_op->fsync) > + return 0; > + return vfs_fsync(lower_file, datasync); > +} > -- > 2.13.0.rc0.306.g87b477812d-goog > -- Dmitry From 1584369327997410496@xxx Sat Nov 18 02:32:15 +0000 2017 X-GM-THRID: 1584369327997410496 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread