seduction
 Language:
Welcome, Guest. Please login or register.
Did you miss your activation email?
2020/02/29, 14:41:12


Help

Author [EN] [PL] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: scary bug - patch in stable-queue of G.K-H  (Read 3140 times)

0 Members and 1 Guest are viewing this topic.

Offline ralul

  • User
  • Posts: 1.809
scary bug - patch in stable-queue of G.K-H
« on: 2013/02/01, 14:59:47 »
This is a little scary to my (non-programer) eyes, found today in the stable-queue of G.K-H:
Code: [Select]
...
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
:(
experiencing siduction runs better than my gentoo makes me know I know nothing