Skip to content

Commit 0e2837d

Browse files
authored
Merge pull request ceph#58099 from athanatos/sjust/wip-66461-obc-with-lock
crimson: fix ObjectContext::_with_lock to only unlock if lock is taken Reviewed-by: Yingxin Cheng <[email protected]> Reviewed-by: Matan Breizman <[email protected]>
2 parents 92f79ec + 9e0c518 commit 0e2837d

File tree

1 file changed

+19
-7
lines changed

1 file changed

+19
-7
lines changed

src/crimson/osd/object_context.h

Lines changed: 19 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -137,22 +137,34 @@ class ObjectContext : public ceph::common::intrusive_lru_base<
137137
private:
138138
template <typename Lock, typename Func>
139139
auto _with_lock(Lock& lock, Func&& func) {
140-
Ref obc = this;
141140
auto maybe_fut = lock.lock();
142141
return seastar::futurize_invoke([
143142
maybe_fut=std::move(maybe_fut),
144-
func=std::forward<Func>(func)]() mutable {
143+
func=std::forward<Func>(func),
144+
obc=Ref(this),
145+
&lock]() mutable {
145146
if (maybe_fut) {
146147
return std::move(*maybe_fut
147-
).then([func=std::forward<Func>(func)]() mutable {
148-
return seastar::futurize_invoke(func);
148+
).then([func=std::forward<Func>(func), obc, &lock]() mutable {
149+
return seastar::futurize_invoke(
150+
func
151+
).finally([&lock, obc] {
152+
/* We chain the finally block here because it's possible for
153+
* *maybe_fut from lock.lock() above to fail due to a call to
154+
* ObjectContext::interrupt, which calls tri_mutex::abort.
155+
* In the event of such an error, the lock isn't actually taken
156+
* and calling unlock() would be incorrect. */
157+
lock.unlock();
158+
});
149159
});
150160
} else {
151161
// atomically calling func upon locking
152-
return seastar::futurize_invoke(func);
162+
return seastar::futurize_invoke(
163+
func
164+
).finally([&lock, obc] {
165+
lock.unlock();
166+
});
153167
}
154-
}).finally([&lock, obc] {
155-
lock.unlock();
156168
});
157169
}
158170

0 commit comments

Comments
 (0)