user/sven/linux.git/lib/debugobjects.c, branch v4.14.53

debugobjects: Make kmemleak ignore debug objects

2017-08-14T14:51:01Z

The allocated debug objects are either on the free list or in the hashed bucket lists. So they won't get lost. However if both debug objects and kmemleak are enabled and kmemleak scanning is done while some of the debug objects are transitioning from one list to the others, false negative reporting of memory leaks may happen for those objects. For example, [38687.275678] kmemleak: 12 new suspected memory leaks (see /sys/kernel/debug/kmemleak) unreferenced object 0xffff92e98aabeb68 (size 40): comm "ksmtuned", pid 4344, jiffies 4298403600 (age 906.430s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 d0 bc db 92 e9 92 ff ff ................ 01 00 00 00 00 00 00 00 38 36 8a 61 e9 92 ff ff ........86.a.... backtrace: [] kmemleak_alloc+0x4a/0xa0 [] kmem_cache_alloc+0xe9/0x320 [] __debug_object_init+0x3e6/0x400 [] debug_object_activate+0x131/0x210 [] __call_rcu+0x3f/0x400 [] call_rcu_sched+0x1d/0x20 [] put_object+0x2c/0x40 [] __delete_object+0x3c/0x50 [] delete_object_full+0x1d/0x20 [] kmemleak_free+0x32/0x80 [] kmem_cache_free+0x77/0x350 [] unlink_anon_vmas+0x82/0x1e0 [] free_pgtables+0xa1/0x110 [] exit_mmap+0xc1/0x170 [] mmput+0x80/0x150 [] do_exit+0x2a9/0xd20 The references in the debug objects may also hide a real memory leak. As there is no point in having kmemleak to track debug object allocations, kmemleak checking is now disabled for debug objects. Signed-off-by: Waiman Long Signed-off-by: Thomas Gleixner Cc: Andrew Morton Link: http://lkml.kernel.org/r/1502718733-8527-1-git-send-email-longman@redhat.com

sched/headers: Prepare for new header dependencies before moving code to

2017-03-02T07:42:36Z

We are going to split out of , which will have to be picked up from other headers and a couple of .c files. Create a trivial placeholder file that just maps to to make this patch obviously correct and bisectable. Include the new header in the files that are going to need it. Acked-by: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar

debugobjects: Improve variable naming

2017-02-10T08:53:04Z

As suggested by Ingo, the debug_objects_alloc counter is now renamed to debug_objects_allocated with minor twist in comment and debug output. Signed-off-by: Waiman Long Cc: Andrew Morton Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1486503630-1501-1-git-send-email-longman@redhat.com Signed-off-by: Ingo Molnar

debugobjects: Reduce contention on the global pool_lock

2017-02-05T16:09:32Z

On a large SMP system with many CPUs, the global pool_lock may become a performance bottleneck as all the CPUs that need to allocate or free debug objects have to take the lock. That can sometimes cause soft lockups like: NMI watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [rcuos/1:21] ... RIP: 0010:[] [] _raw_spin_unlock_irqrestore+0x3b/0x60 ... Call Trace: [] free_object+0x81/0xb0 [] debug_check_no_obj_freed+0x193/0x220 [] ? trace_hardirqs_on_caller+0xf9/0x1c0 [] ? file_free_rcu+0x36/0x60 [] kmem_cache_free+0xd2/0x380 [] ? fput+0x90/0x90 [] file_free_rcu+0x36/0x60 [] rcu_nocb_kthread+0x1b3/0x550 [] ? rcu_nocb_kthread+0x101/0x550 [] ? sync_exp_work_done.constprop.63+0x50/0x50 [] kthread+0x101/0x120 [] ? trace_hardirqs_on_caller+0xf9/0x1c0 [] ret_from_fork+0x22/0x50 To reduce the amount of contention on the pool_lock, the actual kmem_cache_free() of the debug objects will be delayed if the pool_lock is busy. This will temporarily increase the amount of free objects available at the free pool when the system is busy. As a result, the number of kmem_cache allocation and freeing is reduced. To further reduce the lock operations free debug objects in batches of four. Signed-off-by: Waiman Long Cc: Christian Borntraeger Cc: "Du Changbin" Cc: Andrew Morton Cc: Jan Stancek Link: http://lkml.kernel.org/r/1483647425-4135-4-git-send-email-longman@redhat.com Signed-off-by: Thomas Gleixner

debugobjects: Scale thresholds with # of CPUs

2017-02-04T08:01:55Z

On a large SMP systems with hundreds of CPUs, the current thresholds for allocating and freeing debug objects (256 and 1024 respectively) may not work well. This can cause a lot of needless calls to kmem_aloc() and kmem_free() on those systems. To alleviate this thrashing problem, the object freeing threshold is now increased to "1024 + # of CPUs * 32". Whereas the object allocation threshold is increased to "256 + # of CPUs * 4". That should make the debug objects subsystem scale better with the number of CPUs available in the system. Signed-off-by: Waiman Long Cc: Christian Borntraeger Cc: "Du Changbin" Cc: Andrew Morton Cc: Jan Stancek Link: http://lkml.kernel.org/r/1483647425-4135-3-git-send-email-longman@redhat.com Signed-off-by: Thomas Gleixner

debugobjects: Track number of kmem_cache_alloc/kmem_cache_free done

2017-02-04T08:01:54Z

New debugfs stat counters are added to track the numbers of kmem_cache_alloc() and kmem_cache_free() function calls to get a sense of how the internal debug objects cache management is performing. Signed-off-by: Waiman Long Cc: Christian Borntraeger Cc: "Du Changbin" Cc: Andrew Morton Cc: Jan Stancek Link: http://lkml.kernel.org/r/1483647425-4135-2-git-send-email-longman@redhat.com Signed-off-by: Thomas Gleixner

Merge branch 'for-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq

2016-12-13T20:59:57Z

Pull workqueue updates from Tejun Heo: "Mostly patches to initialize workqueue subsystem earlier and get rid of keventd_up(). The patches were headed for the last merge cycle but got delayed due to a bug found late minute, which is fixed now. Also, to help debugging, destroy_workqueue() is more chatty now on a sanity check failure." * 'for-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: move wq_numa_init() to workqueue_init() workqueue: remove keventd_up() debugobj, workqueue: remove keventd_up() usage slab, workqueue: remove keventd_up() usage power, workqueue: remove keventd_up() usage tty, workqueue: remove keventd_up() usage mce, workqueue: remove keventd_up() usage workqueue: make workqueue available early during boot workqueue: dump workqueue state on sanity check failures in destroy_workqueue()

lib/debugobjects: export for use in modules

2016-12-01T00:32:52Z

Drivers, or other modules, that use a mixture of objects (especially objects embedded within other objects) would like to take advantage of the debugobjects facilities to help catch misuse. Currently, the debugobjects interface is only available to builtin drivers and requires a set of EXPORT_SYMBOL_GPL for use by modules. I am using the debugobjects in i915.ko to try and catch some invalid operations on embedded objects. The problem currently only presents itself across module unload so forcing i915 to be builtin is not an option. Link: http://lkml.kernel.org/r/20161122143039.6433-1-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson Cc: "Du, Changbin" Cc: Thomas Gleixner Cc: Christian Borntraeger Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

debugobj, workqueue: remove keventd_up() usage

2016-09-17T17:18:21Z

Now that workqueue can handle work item queueing from very early during boot, there is no need to gate schedule_work() while !keventd_up(). Remove it. Signed-off-by: Tejun Heo Acked-by: Thomas Gleixner Cc: Andrew Morton

debugobjects: insulate non-fixup logic related to static obj from fixup callbacks

2016-05-20T02:12:14Z

When activating a static object we need make sure that the object is tracked in the object tracker. If it is a non-static object then the activation is illegal. In previous implementation, each subsystem need take care of this in their fixup callbacks. Actually we can put it into debugobjects core. Thus we can save duplicated code, and have *pure* fixup callbacks. To achieve this, a new callback "is_static_object" is introduced to let the type specific code decide whether a object is static or not. If yes, we take it into object tracker, otherwise give warning and invoke fixup callback. This change has paassed debugobjects selftest, and I also do some test with all debugobjects supports enabled. At last, I have a concern about the fixups that can it change the object which is in incorrect state on fixup? Because the 'addr' may not point to any valid object if a non-static object is not tracked. Then Change such object can overwrite someone's memory and cause unexpected behaviour. For example, the timer_fixup_activate bind timer to function stub_timer. Link: http://lkml.kernel.org/r/1462576157-14539-1-git-send-email-changbin.du@intel.com [changbin.du@intel.com: improve code comments where invoke the new is_static_object callback] Link: http://lkml.kernel.org/r/1462777431-8171-1-git-send-email-changbin.du@intel.com Signed-off-by: Du, Changbin Cc: Jonathan Corbet Cc: Josh Triplett Cc: Steven Rostedt Cc: Thomas Gleixner Cc: Tejun Heo Cc: Christian Borntraeger Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds