Thread (28 messages) 28 messages, 11 authors, 2020-06-17

Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()

From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: 2020-06-16 19:47:11
Also in: keyrings, linux-amlogic, linux-bluetooth, linux-btrfs, linux-cifs, linux-crypto, linux-fscrypt, linux-integrity, linux-mediatek, linux-mm, linux-nfs, linux-pm, linux-s390, linux-scsi, linux-sctp, linux-security-module, linux-wireless, linuxppc-dev, lkml, target-devel, virtualization

On Tue, Jun 16, 2020 at 12:54 PM Joe Perches [off-list ref] wrote:
On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
quoted
 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.
To this larger audience and last week without reply:
https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/ (local)

Are there _any_ fastpath uses of kfree or vfree?
The networking stack has various places where there will be a quick
kmalloc followed by a kfree for an incoming or outgoing packet. One
place that comes to mind would be esp_alloc_tmp, which does a quick
allocation of some temporary kmalloc memory, processes some packet
things inside of that, and then frees it, sometimes in the same
function, and sometimes later in an async callback. I don't know how
"fastpath" you consider this, but usually packet processing is
something people want to do with minimal overhead, considering how
fast NICs are these days.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help