Natty SRU: eCryptfs: Handle failed metadata read in lookup
The following changes since commit 2fbb6e80e5b7e9e31a1a81d96c5a39a5a2cc070d:
Keng-Yu Lin (1):
UBUNTU: SAUCE: Input: ALPS - Enable Intellimouse mode for Lenovo Zhaoyang E47
Natty SRU: eCryptfs: Handle failed metadata read in lookup
On 20.07.2011 02:01, Tim Gardner wrote:
> The following changes since commit 2fbb6e80e5b7e9e31a1a81d96c5a39a5a2cc070d:
> Keng-Yu Lin (1):
> UBUNTU: SAUCE: Input: ALPS - Enable Intellimouse mode for Lenovo Zhaoyang E47
>
> are available in the git repository at:
>
> git://kernel.ubuntu.com/rtg/ubuntu-natty.git ecryptfs-lp509180
>
> Tim Gardner (1):
> eCryptfs: Handle failed metadata read in lookup
>
> fs/ecryptfs/crypto.c | 21 +++++++++++++++++++++
> fs/ecryptfs/ecryptfs_kernel.h | 2 ++
> fs/ecryptfs/file.c | 3 ++-
> fs/ecryptfs/inode.c | 18 +++---------------
> 4 files changed, 28 insertions(+), 16 deletions(-)
>
> From 9a2275b475ca346baba6445b2b737c61d9564afd Mon Sep 17 00:00:00 2001
> From: Tim Gardner <tim.gardner@canonical.com>
> Date: Fri, 15 Jul 2011 10:49:42 -0600
> Subject: [PATCH] eCryptfs: Handle failed metadata read in lookup
>
> When failing to read the lower file's crypto metadata during a lookup,
> eCryptfs must continue on without throwing an error. For example, there
> may be a plaintext file in the lower mount point that the user wants to
> delete through the eCryptfs mount.
>
> If an error is encountered while reading the metadata in lookup(), the
> eCryptfs inode's size could be incorrect. We must be sure to reread the
> plaintext inode size from the metadata when performing an open() or
> setattr(). The metadata is already being read in those paths, so this
> adds minimal performance overhead.
>
> This patch introduces a flag which will track whether or not the
> plaintext inode size has been read so that an incorrect i_size can be
> fixed in the open() or setattr() paths.
>
> https://bugs.launchpad.net/bugs/509180
>
> Cc: <stable@kernel.org>
> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
07-20-2011, 05:29 PM
Leann Ogasawara
Natty SRU: eCryptfs: Handle failed metadata read in lookup
On Tue, 2011-07-19 at 18:01 -0600, Tim Gardner wrote:
> The following changes since commit 2fbb6e80e5b7e9e31a1a81d96c5a39a5a2cc070d:
> Keng-Yu Lin (1):
> UBUNTU: SAUCE: Input: ALPS - Enable Intellimouse mode for Lenovo Zhaoyang E47
>
> are available in the git repository at:
>
> git://kernel.ubuntu.com/rtg/ubuntu-natty.git ecryptfs-lp509180
>
> Tim Gardner (1):
> eCryptfs: Handle failed metadata read in lookup
>
> fs/ecryptfs/crypto.c | 21 +++++++++++++++++++++
> fs/ecryptfs/ecryptfs_kernel.h | 2 ++
> fs/ecryptfs/file.c | 3 ++-
> fs/ecryptfs/inode.c | 18 +++---------------
> 4 files changed, 28 insertions(+), 16 deletions(-)
>
> From 9a2275b475ca346baba6445b2b737c61d9564afd Mon Sep 17 00:00:00 2001
> From: Tim Gardner <tim.gardner@canonical.com>
> Date: Fri, 15 Jul 2011 10:49:42 -0600
> Subject: [PATCH] eCryptfs: Handle failed metadata read in lookup
>
> When failing to read the lower file's crypto metadata during a lookup,
> eCryptfs must continue on without throwing an error. For example, there
> may be a plaintext file in the lower mount point that the user wants to
> delete through the eCryptfs mount.
>
> If an error is encountered while reading the metadata in lookup(), the
> eCryptfs inode's size could be incorrect. We must be sure to reread the
> plaintext inode size from the metadata when performing an open() or
> setattr(). The metadata is already being read in those paths, so this
> adds minimal performance overhead.
>
> This patch introduces a flag which will track whether or not the
> plaintext inode size has been read so that an incorrect i_size can be
> fixed in the open() or setattr() paths.
>
> https://bugs.launchpad.net/bugs/509180
>
> Cc: <stable@kernel.org>
> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
>
> (backported from 3aeb86ea4cd15f728147a3bd5469a205ada8c767)
> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>