The first few lines of vn_pollrecord() are: if (vp->v_pollinfo == NULL) v_addpollinfo(vp); mtx_lock(&vp->v_pollinfo->vpi_lock); v_addpollinfo() leaves vp->v_pollinfo NULL if the malloc attempt fails. vfs_kqfilter() checks for failure, but this function does not. If allocation were to fail then the mtx_lock() call would result in a null pointer dereference panic. Fix: vn_pollrecord() should ensure v_addpollinfo() succeeds in allocating the pollinfo lists. However vn_pollrecord() uses its return value to convey the original event mask so there does not appear to be a method to return an error value (ENOMEM, etc.) in the current implementation. How-To-Repeat: Problem was found by code inspection.
Hi. failure of uma_zalloc() would cause null pointer dereference in v_addpollinfo() anyway (due to mtx_init() call). From commit message for rev 1.142 of sys/vm/uma_core.c: Remove uma_zalloc_arg() hack, which coerced M_WAITOK to M_NOWAIT when allocations were made using improper flags in interrupt context. Replace with a simple WITNESS warning call. This restores the invariant that M_WAITOK allocations will always succeed or die horribly trying, which is relied on by many UMA consumers. So it's ok to rely on M_WAITOK (which v_addpollinfo() does) and additional null check in vfs_kqfilter() can be removed as being meaningles. Thanks, -- Mateusz Guzik
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped