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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141104235505.GA31748@redhat.com>
Date:	Wed, 5 Nov 2014 00:55:05 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Pedro Alves <palves@...hat.com>,
	Denys Vlasenko <dvlasenk@...hat.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Evan Teran <eteran@...m.rit.edu>,
	Jan Kratochvil <jan.kratochvil@...hat.com>,
	Roland McGrath <roland@...k.frob.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] ptrace/x86: fix the TIF_FORCED_TF logic in
	handle_signal()

On 11/03, Pedro Alves wrote:
>
> Thanks a lot Oleg.

thanks for the detailed report ;)

> Question - shouldn't ptrace tests be put in
> tools/testing/selftests/ptrace/ in the kernel tree nowadays?

Oh, I do not know. Personally I am not sure that selftests/ptrace/
makes sense and I did not even know (or forgot) we already have it.
To me it would be better to move the single peeksiginfo.c to ptrace
testsuite and remove this dir.

That said, I certainly won't argue if you or Jan will maintain
selftests/ptrace and send the patches with the new test-cases ;)

The only problem is that every new test-case should be justified
somehow. For example, should we add the test-case from this changelog
into selftests/ptrace/ ? Honestly, I do not know. This bug is minor,
and probably we do not want a test-case for every bug we fix. So I'd
leave this to you, you know how ptrace is actually _used_ and what is
important for gdb.

The same for other tests in ptrace testsuite. Some of them are really
"random", in any case (I think) we should not blindly put them all into
selftests/ptrace. Not to mention the coding style which should be fixed.

And I know that gdb has a lot of internal tests, and gdb developers
run them (and ptrace tests) to check the new kernels... Who else do
you think will use selftests/ptrace?

But again, if you/Jan want to add something into selftests - please
send a patch. I will even try to review it but only in a sense that
I will try to convince myself that I understand _what_ this test does,
not _why_ we need this test-case. You certainly understand "why" much
better.

Add Denys, perhaps he also has some tests for strace.

Oleg.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ