lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 7 Dec 2020 18:02:53 +0900 From: Joonsoo Kim <js1304@...il.com> To: paulmck@...nel.org Cc: rcu@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-team@...com, mingo@...nel.org, jiangshanlai@...il.com, akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com, josh@...htriplett.org, tglx@...utronix.de, peterz@...radead.org, rostedt@...dmis.org, dhowells@...hat.com, edumazet@...gle.com, fweisbec@...il.com, oleg@...hat.com, joel@...lfernandes.org, Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>, David Rientjes <rientjes@...gle.com>, linux-mm@...ck.org Subject: Re: [PATCH sl-b 1/6] mm: Add kmem_last_alloc() to return last allocation for memory block Hello, Paul. On Fri, Dec 04, 2020 at 04:40:52PM -0800, paulmck@...nel.org wrote: > From: "Paul E. McKenney" <paulmck@...nel.org> > > There are kernel facilities such as per-CPU reference counts that give > error messages in generic handlers or callbacks, whose messages are > unenlightening. In the case of per-CPU reference-count underflow, this > is not a problem when creating a new use of this facility because in that > case the bug is almost certainly in the code implementing that new use. > However, trouble arises when deploying across many systems, which might > exercise corner cases that were not seen during development and testing. > Here, it would be really nice to get some kind of hint as to which of > several uses the underflow was caused by. > > This commit therefore exposes a new kmem_last_alloc() function that > takes a pointer to dynamically allocated memory and returns the return > address of the call that allocated it. This pointer can reference the > middle of the block as well as the beginning of the block, as needed > by things like RCU callback functions and timer handlers that might not > know where the beginning of the memory block is. These functions and > handlers can use the return value from kmem_last_alloc() to give the > kernel hacker a better hint as to where the problem might lie. I agree with exposing allocation caller information to the other subsystem to help the debugging. Some suggestions... 1. It's better to separate a slab object check (validity check) and retrieving the allocation caller. Someone else would want to check only a validity. And, it doesn't depend on the debug configuration so it's not good to bind it to the debug function. kmem_cache_valid_(obj|ptr) kmalloc_valid_(obj|ptr) 2. rename kmem_last_alloc to ... int kmem_cache_debug_alloc_caller(cache, obj, &ret_addr) int kmalloc_debug_alloc_caller(obj, &ret_addr) or debug_kmem_cache_alloc_caller() I think that function name need to include the keyword 'debug' to show itself as a debugging facility (enabled at the debugging). And, return errno and get caller address by pointer argument. 3. If concrete error message is needed, please introduce more functions. void *kmalloc_debug_error(errno) Thanks.
Powered by blists - more mailing lists