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

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

From: Waiman Long <longman@redhat.com>
Date: 2020-06-16 19:43:50
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, netdev, target-devel

On 6/16/20 2:53 PM, Joe Perches 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?
I am not sure about that, but both of them can be slow.

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((unsigned long)addr))
    		return;

    	if (is_vmalloc_addr(addr))
    		_vfree(addr);
    	else
    		_kfree(addr);
    }
is_kernel_rodata() is inlined, but is_vmalloc_addr() isn't. So the 
overhead can be a bit bigger.

Cheers,
Longman
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help