Commit 8798d07
committed
rbd: always kick acquire on "acquired" and "released" notifications
Skipping the "lock has been released" notification if the lock owner
is not what we expect based on owner_cid can lead to I/O hangs.
One example is our own notifications: because owner_cid is cleared
in rbd_unlock(), when we get our own notification it is processed as
unexpected/duplicate and maybe_kick_acquire() isn't called. If a peer
that requested the lock then doesn't go through with acquiring it,
I/O requests that came in while the lock was being quiesced would
be stalled until another I/O request is submitted and kicks acquire
from rbd_img_exclusive_lock().
This makes the comment in rbd_release_lock() actually true: prior to
this change the canceled work was being requeued in response to the
"lock has been acquired" notification from rbd_handle_acquired_lock().
Cc: stable@vger.kernel.org # 5.3+
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Tested-by: Robin Geuze <robin.geuze@nl.team.blue>1 parent 2734d6c commit 8798d07
1 file changed
Lines changed: 7 additions & 13 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
4203 | 4203 | | |
4204 | 4204 | | |
4205 | 4205 | | |
4206 | | - | |
4207 | | - | |
4208 | | - | |
4209 | | - | |
4210 | | - | |
4211 | | - | |
| 4206 | + | |
| 4207 | + | |
| 4208 | + | |
| 4209 | + | |
4212 | 4210 | | |
4213 | | - | |
4214 | | - | |
4215 | 4211 | | |
4216 | 4212 | | |
4217 | 4213 | | |
| |||
4236 | 4232 | | |
4237 | 4233 | | |
4238 | 4234 | | |
4239 | | - | |
| 4235 | + | |
4240 | 4236 | | |
4241 | 4237 | | |
4242 | | - | |
4243 | | - | |
| 4238 | + | |
| 4239 | + | |
4244 | 4240 | | |
4245 | | - | |
4246 | | - | |
4247 | 4241 | | |
4248 | 4242 | | |
4249 | 4243 | | |
| |||
0 commit comments