c991591342
Normally wakeups() are performed for completed softupdates work items in workitem_free() before the underlying memory is free()'d. complete_jseg() was clearing the "wakeup needed" flag in work items to defer the wakeup until the end of each loop iteration. However, this resulted in the item being free'd before it's address was used with wakeup(). As a result, another part of the kernel could allocate this memory from malloc() and use it as a wait channel for a different "event" with a different lock. This triggered an assertion failure when the lock passed to sleepq_add() did not match the existing lock associated with the sleep queue. Fix this by removing the code to defer the wakeup in complete_jseg() allowing the wakeup to occur slightly earlier in workitem_free() before free() is called. The main reason I can think of for deferring a wakeup() would be to avoid waking up a waiter while holding a lock that the waiter would need. However, no locks are dropped in between the wakeup() in workitem_free() and the end of the loop in complete_jseg() as far as I can tell. In general I think it is not safe to do a wakeup() after free() as one cannot control how other parts of the kernel that might reuse the address for a different wait channel will handle spurious wakeups. Reported by: pho Reviewed by: kib MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D12494 |
||
|---|---|---|
| .. | ||
| ffs_alloc.c | ||
| ffs_balloc.c | ||
| ffs_extern.h | ||
| ffs_inode.c | ||
| ffs_rawread.c | ||
| ffs_snapshot.c | ||
| ffs_softdep.c | ||
| ffs_subr.c | ||
| ffs_suspend.c | ||
| ffs_tables.c | ||
| ffs_vfsops.c | ||
| ffs_vnops.c | ||
| fs.h | ||
| softdep.h | ||