summaryrefslogtreecommitdiffstats
path: root/kernel/gcov/fs.c
diff options
context:
space:
mode:
authorTyler Hicks <tyhicks@linux.vnet.ibm.com>2011-03-15 14:54:00 -0500
committerTyler Hicks <tyhicks@linux.vnet.ibm.com>2011-04-25 18:45:06 -0500
commit3aeb86ea4cd15f728147a3bd5469a205ada8c767 (patch)
tree6219c664f7938fa8e5e8a2efa93aab7bcc38c12f /kernel/gcov/fs.c
parent332ab16f830f59e7621ae8eb2c353dc135a316f6 (diff)
downloadlinux-stable-3aeb86ea4cd15f728147a3bd5469a205ada8c767.tar.gz
linux-stable-3aeb86ea4cd15f728147a3bd5469a205ada8c767.tar.bz2
linux-stable-3aeb86ea4cd15f728147a3bd5469a205ada8c767.zip
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>
Diffstat (limited to 'kernel/gcov/fs.c')
0 files changed, 0 insertions, 0 deletions