[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140511192105.766789727@linuxfoundation.org>
Date: Sun, 11 May 2014 21:21:22 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-kernel@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
stable@...r.kernel.org, "J. Bruce Fields" <bfields@...ldses.org>,
Terry Barnaby <terry1@...m.ltd.uk>,
Jeff Layton <jlayton@...hat.com>,
"J. Bruce Fields" <bfields@...hat.com>
Subject: [PATCH 3.4 14/22] locks: allow __break_lease to sleep even when break_time is 0
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Layton <jlayton@...hat.com>
commit 4991a628a789dc5954e98e79476d9808812292ec upstream.
A fl->fl_break_time of 0 has a special meaning to the lease break code
that basically means "never break the lease". knfsd uses this to ensure
that leases don't disappear out from under it.
Unfortunately, the code in __break_lease can end up passing this value
to wait_event_interruptible as a timeout, which prevents it from going
to sleep at all. This causes __break_lease to spin in a tight loop and
causes soft lockups.
Fix this by ensuring that we pass a minimum value of 1 as a timeout
instead.
Cc: J. Bruce Fields <bfields@...ldses.org>
Reported-by: Terry Barnaby <terry1@...m.ltd.uk>
Signed-off-by: Jeff Layton <jlayton@...hat.com>
Signed-off-by: J. Bruce Fields <bfields@...hat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
---
fs/locks.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1253,11 +1253,10 @@ int __break_lease(struct inode *inode, u
restart:
break_time = flock->fl_break_time;
- if (break_time != 0) {
+ if (break_time != 0)
break_time -= jiffies;
- if (break_time == 0)
- break_time++;
- }
+ if (break_time == 0)
+ break_time++;
locks_insert_block(flock, new_fl);
unlock_flocks();
error = wait_event_interruptible_timeout(new_fl->fl_wait,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists