]>
Commit | Line | Data |
---|---|---|
eb240234 GKH |
1 | From 605b0487f0bc1ae9963bf52ece0f5c8055186f81 Mon Sep 17 00:00:00 2001 |
2 | From: Andreas Gruenbacher <agruenba@redhat.com> | |
3 | Date: Wed, 6 Mar 2019 15:41:57 +0100 | |
4 | Subject: gfs2: Fix missed wakeups in find_insert_glock | |
5 | ||
6 | From: Andreas Gruenbacher <agruenba@redhat.com> | |
7 | ||
8 | commit 605b0487f0bc1ae9963bf52ece0f5c8055186f81 upstream. | |
9 | ||
10 | Mark Syms has reported seeing tasks that are stuck waiting in | |
11 | find_insert_glock. It turns out that struct lm_lockname contains four padding | |
12 | bytes on 64-bit architectures that function glock_waitqueue doesn't skip when | |
13 | hashing the glock name. As a result, we can end up waking up the wrong | |
14 | waitqueue, and the waiting tasks may be stuck forever. | |
15 | ||
16 | Fix that by using ht_parms.key_len instead of sizeof(struct lm_lockname) for | |
17 | the key length. | |
18 | ||
19 | Reported-by: Mark Syms <mark.syms@citrix.com> | |
20 | Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> | |
21 | Signed-off-by: Bob Peterson <rpeterso@redhat.com> | |
22 | Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | |
23 | ||
24 | --- | |
25 | fs/gfs2/glock.c | 2 +- | |
26 | 1 file changed, 1 insertion(+), 1 deletion(-) | |
27 | ||
28 | --- a/fs/gfs2/glock.c | |
29 | +++ b/fs/gfs2/glock.c | |
30 | @@ -107,7 +107,7 @@ static int glock_wake_function(wait_queu | |
31 | ||
32 | static wait_queue_head_t *glock_waitqueue(struct lm_lockname *name) | |
33 | { | |
34 | - u32 hash = jhash2((u32 *)name, sizeof(*name) / 4, 0); | |
35 | + u32 hash = jhash2((u32 *)name, ht_parms.key_len / 4, 0); | |
36 | ||
37 | return glock_wait_table + hash_32(hash, GLOCK_WAIT_TABLE_BITS); | |
38 | } |