linux-kernel - Re: [PATCH 15/28] ktap: add built-in functions and library (runtime/lib

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGdX0WH0NVqL37Qe43WE1Lfxc5VR_7C4oA-Z0VkaKSdZazd7tQ@mail.gmail.com>
Date:	Wed, 2 Apr 2014 09:44:06 +0800
From:	Jovi Zhangwei <jovi.zhangwei@...il.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Ingo Molnar <mingo@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Geoff Levand <geoff@...radead.org>
Subject: Re: [PATCH 15/28] ktap: add built-in functions and library (runtime/lib_*.c)

On Mon, Mar 31, 2014 at 9:13 PM, Andi Kleen <andi@...stfloor.org> wrote:
> On Mon, Mar 31, 2014 at 10:01:04AM +0800, Jovi Zhangwei wrote:
>> On Sun, Mar 30, 2014 at 8:58 AM, Andi Kleen <andi@...stfloor.org> wrote:
>> >> Maybe in future, after ktap support "include" or "require" to
>> >> import user defined library in userspace.
>> >
>> > Can't you just have some hardcoded standard script for now that is
>> > always appeneded and provides these functions?
>> >
>> Maybe it's fine to hardcoded just for now.
>>
>> Since we are agreed on review userspace part in another schedule,
>> so I will remove this ansi library from kernel part in next version.
>>
>> Thanks for this suggestion.
>
> Please do the following for the next version:
>
> - Don't repost with all the TODOs regarding changing other
> kernel parts. Just fix them.
>
Sure.

> - As others pointed out elsewhere it's too big and full featured right
> now. Please find ways to define a useful "core ktap" for now with less
> features. This could be dropping library parts or dropping some of the
> probe types or some parts of the language. These can then be later phased
> in over time. For the library it may make sense to add some module
> interface and keep parts of it external for now?
>
I will remove some library and raw tracing interface(designed for benchmark)

> - Please run as much test content as you have with all the kernel debug
> options to automatically find bugs. I would at least two runs one with
> lockdep/lock debugging/preempt debugging/slab/page debugging etc.
> and another with kmemleak (that is exclusive with some other options)
> Some of these checks may have false positives, but the messages
> should be all analyzed at least, and false positives commented.
>
ktap runs fine in lockdep/lock debugging/preempt debugging, but not
try to run in slab/page debugging and kmemleak. I will do that.

> - Do similar with the static compile time checks: checkpatch,
> sparse, coccinelle. There will be likely a lot more false positives
> here, so it may not be feasible to check all, but should at least
> eyeball the output to see if there are some obvious problems.
> For sparse it would be also good to annotate the user ioctl
> parts with __user and carefully look at the warnings there,
> as that is a common problem area.
>
Sure.

I will send out new version once we make agreement on ktap
upstream which discussing in another thread.

Thanks for these comments.

Jovi
--
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/