On Sat, 18 Apr 2026 11:08:42 +0530 Yash Suthar <[email protected]> wrote:
> Hello Steven, > Thank you for taking a look and really sorry. > > I did use ai assistance for commit message, but I reviewed, modified > and tested(with syzbot locally) the code myself. I should have > disclosed really sorry. > > One thing I want to know (or I am still missing something): > sched_cmdline_ref is incremented before tracing_sched_register() and > register fails, but sched_cmdline_ref stays at 1 and on disable > tracepoint_remove_func() sees NULL and return error (as syzbot > reported and reproduce also locally). > your suggestion WARN_ONCE correctly flags the upstream failure, but > the secondary WARN at tracepoint.c:358 will still fire on the next > disable, since the refcount desync isn't addressed. Was that > intentional ? Yes. This is why I'm not too thrilled about syzbot injecting kmalloc failures. These injections are for one page or less, in which case the system is in pretty much a failed state anyway. I don't care about warnings being triggering due to kmalloc failures. I'll fix UAF or NULL pointer dereferences, but warnings? No! If you fail to alloc a single page, expect a lot of warnings to happen. That is intentional. syzbot should not flag an error for a warning that was triggered due to a single page memory failure, unless that memory was allocated by in atomic or something where it can't do reclaim. -- Steve
