Fix ASSERT in dmu_free_long_object_raw()

[tcaputi]

This small patch fixes an issue where dmu_free_long_object_raw()
calls dnode_hold() after freeing the dnode a line above.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the ZFS on Linux code style requirements.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• All commit messages are properly formatted and contain Signed-off-by.
• Change has been approved by a ZFS on Linux member.

[behlendorf]

Rather than make this a fatal VERIFY0 why don't we cleanly handle an error here since we can. How about:

        err = dmu_tx_assign(tx, TXG_WAIT);
        if (err == 0) {
                if (raw)
                        err = dmu_object_dirty_raw(os, object, tx);
                if (err == 0)
                        err = dmu_object_free(os, object, tx);

                dmu_tx_commit(tx);
        } else {
                dmu_tx_abort(tx);
        }

[tcaputi]

I could, but dmu_object_dirty_raw() will always succeed, since it will only fail if dnode_hold() fails, and we already know at this point in the code that it will work. Do you still want me to change it?

[behlendorf]

I don't see anything in the code which guarantees that. We do take a hold and release it a few lines up in dmu_free_long_range() but by the time we get to dmu_object_dirty_raw() and dmu_object_free we're not holding any lock or reference which would prevent it from being freed. An error here is unlikely, but entirely possible.

Incidentally, the same logic applies to the dmu_object_free() call which only takes a hold and does handle the error. So yes, I think it's important we make that change.

[lundman]

Problem fixed on OSX, and passes tests. Thanks.