This is a little scary to my (non-programer) eyes, found today in the stable-queue of G.K-H:
...
commit cce89f4f6911286500cf7be0363f46c9b0a12ce0('Move kmem_cache
refcounting to common code') moves some refcount manipulation
code to common code. Unfortunately, it also
removed refcount assignment for
kmalloc_caches. So, kmalloc_caches's refcount
is initially 0. This makes erroneous situation.
Paul Hargrove report that when he create a 8-byte
kmem_cache and destory it, he encounter below
message. 'Objects remaining in kmalloc-8 on kmem_cache_close()'
8-byte kmem_cache merge with 8-byte kmalloc cache
and refcount is increased by one. So,
resulting refcount is 1. When destroy it, it
hit refcount = 0, then kmem_cache_close() is
executed and error message is printed.
This patch assign initial refcount 1
to kmalloc_caches, so fix this
erroneous situation.
Reported-by: Paul Hargrove <phhargrove@lbl.gov>
...
<gregkh@linuxfoundation.org>
---
mm/slub.c | 1 +
1 file changed, 1 insertion(+)
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3279,6 +3279,7 @@ static struct kmem_cache *__init create_
if (kmem_cache_open(s, flags))
goto panic;
+ s->refcount = 1;
list_add(&s->list, &slab_caches);
return s;
As everyone is using slub but not slab these days: Does this mean important data had a refcount of null and thus could be reused despite the fact it was used?
I also use the linux-3.7 kernel having this error - and I really wonder why I didn't have any crashes yet.
G.K-H has his bad opinion of Linus stable releases:
I read in the openSUSE dev-mailing list some months ago, G.K-H wanted his sparse openSUSE-Tumbleweed release to be used as a testing bed for the Linus kernel beta-quality "stable" releases.
Above patch obviously shows a badass bug:
This is why - to my humble opinion - we should release a siduction linux kernel not before .6 stable-queue release. That before kernels should be called at most experimental
