This is a note to let you know that I've just added the patch titled
udf: Release preallocation on last writeable close
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
udf-release-preallocation-on-last-writeable-close.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From b07ef35244424cbeda9844198607c7077099c82c Mon Sep 17 00:00:00 2001
From: Jan Kara <[email protected]>
Date: Wed, 28 Jan 2015 08:38:20 +0100
Subject: udf: Release preallocation on last writeable close
From: Jan Kara <[email protected]>
commit b07ef35244424cbeda9844198607c7077099c82c upstream.
Commit 6fb1ca92a640 "udf: Fix race between write(2) and close(2)"
changed the condition when preallocation is released. The idea was that
we don't want to release the preallocation for an inode on close when
there are other writeable file descriptors for the inode. However the
condition was written in the opposite way so we released preallocation
only if there were other writeable file descriptors. Fix the problem by
changing the condition properly.
Fixes: 6fb1ca92a6409a9d5b0696447cd4997bc9aaf5a2
Reported-by: Fabian Frederick <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/udf/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/udf/file.c
+++ b/fs/udf/file.c
@@ -224,7 +224,7 @@ out:
static int udf_release_file(struct inode *inode, struct file *filp)
{
if (filp->f_mode & FMODE_WRITE &&
- atomic_read(&inode->i_writecount) > 1) {
+ atomic_read(&inode->i_writecount) == 1) {
/*
* Grab i_mutex to avoid races with writes changing i_size
* while we are running.
Patches currently in stable-queue which might be from [email protected] are
queue-3.18/udf-release-preallocation-on-last-writeable-close.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
