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

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

From: Matthew Wilcox <willy@infradead.org>
Date: 2020-06-17 11:08:45
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, linuxppc-dev, lkml, netdev, target-devel, virtualization

On Wed, Jun 17, 2020 at 09:12:12AM +0200, Michal Hocko wrote:
On Tue 16-06-20 17:37:11, Matthew Wilcox wrote:
quoted
Not just performance critical, but correctness critical.  Since kvfree()
may allocate from the vmalloc allocator, I really think that kvfree()
should assert that it's !in_atomic().  Otherwise we can get into trouble
if we end up calling vfree() and have to take the mutex.
FWIW __vfree already checks for atomic context and put the work into a
deferred context. So this should be safe. It should be used as a last
resort, though.
Actually, it only checks for in_interrupt().  If you call vfree() under
a spinlock, you're in trouble.  in_atomic() only knows if we hold a
spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic()
in __vfree().  So we need the warning in order that preempt people can
tell those without that there is a bug here.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help