linux-kernel - [RFC] mm,tracing: improve current situation

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1396561440.4661.33.camel@buesod1.americas.hpqcorp.net>
Date:	Thu, 03 Apr 2014 14:44:00 -0700
From:	Davidlohr Bueso <davidlohr@...com>
To:	linux-mm@...ck.org
Cc:	linux-kernel@...r.kernel.org, Dave Jones <davej@...hat.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: [RFC] mm,tracing: improve current situation

Hi All,

During LSFMM Dave Jones discussed the current situation around
testing/trinity in the mm. One of the conclusions was that basically we
lack tools to gather the necessary information to make debugging a less
painful process, making it pretty much a black box for a lot of cases.

One of the suggested ways to do so was to improve our tracing. Currently
we have events for kmem, vmscan and oom (which really just traces the
tunable updates) -- In addition Dave Hansen also also been trying to add
tracing for TLB range flushing, hopefully that can make it in some time
soon. However, this lacks the more general data that governs all of the
core VM, such as vmas and of course the mm_struct.

To this end, I've started adding events to trace the vma lifecycle,
including: creating, removing, splitting, merging, copying and
adjusting. Currently it only prints out the start and end virtual
addresses, such as:

bash-3661   [000]  ....  222.964847: split_vma: [8a8000-9a6000] => new: [9a6000-9b6000]

Now, on a more general scenario, I basically would like to know, 1) is
this actually useful... I'm hoping that, if in fact something like this
gets merged, it won't just sit there. 2) What other general data would
be useful for debugging purposes? I'm happy to collect feedback and send
out something we can all benefit from.

Thanks,
Davidlohr

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/