panic in bpobj_space(): null pointer dereference
The issue fixed by this patch is a race condition in the deadlist code.
A thread executing an administrative command that uses
`dsl_deadlist_space_range()` holds the lock of the whole `deadlist_t` to
protect the access of all its entries that the deadlist contains in an
Sync threads trying to insert a new entry in the deadlist
(through `dsl_deadlist_insert()` -> `dle_enqueue()`) do not hold the
deadlist lock at that moment. If the `dle_bpobj` is the empty bpobj (our
sentinel value), we close and reopen it. Between these two operations,
it is possible for the `dsl_deadlist_space_range()` thread to dereference
that bpobj which is `NULL` during that window.
Threads should hold the a deadlist's `dl_lock` when they manipulate its
internal data so scenarios like the one above are avoided. In addition,
threads should also hold the bpobj lock whenever they are allocating the
subobj list of a bpobj, and not just when they actually insert the subobj
to the list. This way we can avoid potential memory leaks.
Updated by Electric Monk about 6 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
git commit a3905a45920de250d181b66ac0b6b71bd200d9ef
commit a3905a45920de250d181b66ac0b6b71bd200d9ef Author: Serapheim Dimitropoulos <email@example.com> Date: 2017-03-08T19:23:17.000Z 7869 panic in bpobj_space(): null pointer dereference Reviewed by: Matt Ahrens <firstname.lastname@example.org> Reviewed by: Dan Kimmel <email@example.com> Reviewed by: Steve Gonczi <firstname.lastname@example.org> Reviewed by: John Kennedy <email@example.com> Reviewed by: George Melikov <firstname.lastname@example.org> Reviewed by: Brian Behlendorf <email@example.com> Approved by: Dan McDonald <firstname.lastname@example.org>