On Mon, May 08, 2023 at 10:13:27PM +0100, Matthew Wilcox wrote: > > > > I was looking at this just a few weeks ago, and I couldn't find any > > actual *documentation* that it was safe to call vfree(NIILL) or > > kvfree(NULL). The problem is there are a lot of architecture-specific > > functions, and unlike with kfree() there is no top-level "if (ptr == > > NULL) return;" in the top-level vfree() and kvfree(). > > There doesn't need to be in kvfree(). is_vmalloc_addr() returns 'false' > for NULL, so it calls kfree(), which as you note has an explicit check > for ZERO_OR_NULL_PTR(). is_vmalloc_addr() also returns false for the > ZERO pointer, fwiw. > > I agree that this should be explicitly documented as allowed, since it's > not reasonable to expect users to dig through these functions to verify > that such a change is safe. I seem to recall at one point looking at kvfree_rcu (at least the one argument variant), and I *thought* it would unconditionally allocate memory so it could be put on a linked list to be freed after an RCU grace period had elapsed. But I tried tracing through the huge numbers of cpp macros and other layers of #ifdef's and other abstractions, and in my conference-induced sleep depreviation, it caused my head to spin, and I gave up trying to trace it down so I had 100% confidence. So if someone could document *all* of the k[v]free_* variants whether it is safe/optimal to pass NULL to them, that would be great, thanks. - Ted
