Closed emaste closed 8 months ago
The panic is from
#define hash_add_rcu(ht, node, key) do { \
struct lkpi_hash_head *__head = &(ht)[hash_min(key, HASH_BITS(ht))]; \
__hash_node_type_assert(node); \
KASSERT(((struct lkpi_hash_entry *)(node))->entry.cle_prev == NULL, \
("node is already on list or was not zeroed")); \
CK_LIST_INSERT_HEAD(&__head->head, \
(struct lkpi_hash_entry *)(node), entry); \
} while (0)
which has been there since f9e90c24737f9
Panic does not occur with https://github.com/emaste/drm-kmod/commit/b6ecd6f88afe3ae026c940290c65163ce21f1d44 applied. I assume this code has just not been run w/ INVARIANTS previously.
Mhm weird, is kmalloc supposed to bzero in linux ?
So having looked at the Linux code it seems that they don't check this, also hash_add seems to use hlist and not the hash rcu ones that we do use.
Linux has kzalloc
for a zeroed allocation, kmalloc
does not. I suspect that the KASSERT in _hash_addrcu is not valid and should be removed (or, we decide it's actually a valuable check, and we have to modify callers to zero the whole allocation or at least the cle_prev
)
Describe the bug
panic: node is already on list or was not zeroed
immediately upon bootFreeBSD version FreeBSD 15.0-CURRENT wipbsd-n267714-217416d818df GENERIC amd64 (This is my WIP branch with a number of changes but should not be related; this is the same kernel as in #280 which worked until
sysctl -a
)PCI Info
DRM KMOD version From git, 1af4c68be62c22429de556c5aa6e0c8bde584f0c
To Reproduce
kldload i915kms
Screenshots N/A
Additional context Note this is GENERIC with INVARIANTS