K 10 svn:author V 3 avg K 8 svn:date V 27 2017-05-24T21:45:52.262536Z K 7 svn:log V 1734 MFC r316913: 7869 panic in bpobj_space(): null pointer dereference illumos/illumos-gate@a3905a45920de250d181b66ac0b6b71bd200d9ef https://github.com/illumos/illumos-gate/commit/a3905a45920de250d181b66ac0b6b71bd200d9ef https://www.illumos.org/issues/7869 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 avl tree. 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. Reviewed by: Matt Ahrens Reviewed by: Dan Kimmel Reviewed by: Steve Gonczi Reviewed by: John Kennedy Reviewed by: George Melikov Reviewed by: Brian Behlendorf Approved by: Dan McDonald Author: Serapheim Dimitropoulos MFC after: 2 weeks END