search for: mispairings

...t; > To this larger audience and last week without reply: > > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel at perches.com/ > > > > Are there _any_ fastpath uses of kfree or vfree? > > > > Many patches have been posted recently to fix mispairings > > of specific types of alloc and free functions. > > I've prepared a coccinelle script to highlight these mispairings in a function > a couple of days ago: https://lkml.org/lkml/2020/6/5/953 > I've listed all the fixes in the commit message. > > Not so many misp...

...d as a separate patch later on after this one is merged. To this larger audience and last week without reply: https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel at perches.com/ Are there _any_ fastpath uses of kfree or vfree? Many patches have been posted recently to fix mispairings of specific types of alloc and free functions. To eliminate these mispairings at a runtime cost of four comparisons, should the kfree/vfree/kvfree/kfree_const functions be consolidated into a single kfree? Something like the below: void kfree(const void *addr) { if (is_kernel_rodata((u...

v4: - Break out the memzero_explicit() change as suggested by Dan Carpenter so that it can be backported to stable. - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for now as there can be a bit more discussion on what is best. It will be introduced as a separate patch later on after this one is merged. This patchset makes a global rename of the kzfree()

v4: - Break out the memzero_explicit() change as suggested by Dan Carpenter so that it can be backported to stable. - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for now as there can be a bit more discussion on what is best. It will be introduced as a separate patch later on after this one is merged. This patchset makes a global rename of the kzfree()