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]
Date:	Thu, 4 Oct 2012 00:48:09 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Chris Zankel <chris@...kel.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] xtensa patchset for 3.7

On Wed, Oct 03, 2012 at 03:23:56PM -0700, Chris Zankel wrote:
> Hi Linus,
> 
> Please pull the changes for the Xtensa architecture for v3.7.
> 
> Thanks,
> -Chris

	BTW, could you do an xtensa counterpart of the stuff in
git.kernel.org/pub/scm/linux/kernel/git/viro/signal#experimental-kernel_thread?
Basically,
	* switch kernel_thread() away from "syscall in kernel" model;
select GENERIC_KERNEL_THREAD in Kconfig and have copy_thread() check
p->flags & PF_KTHREAD instead of user_mode(regs).  If it's true, set the
child up so that it would wake up not in ret_from_fork() but in
ret_from_kernel_thread(), the latter being
	schedule_tail(last);
	fn(arg);
	sys_exit(0);
where fn and arg would be picked from something set by copy_thread() - either
pt_regs or callee-saved registers if your switch_to() deals with those (in
the latter case you'll obviously have then already in place by the time your
newborn kernel thread wakes up).  Have the same value for kernel stack pointer
regardless of user_mode.  Use 'usp' for fn, 'unused' for arg and expect regs
to be NULL.  Kill kernel_thread() in entry.S.
	* add ret_from_kernel_execve() that would simply set sp to value
normal for common_exception_return (i.e. what you used to set it when
going into ret_from_kernel_thread()/ret_from_fork()) and branch to said
common_exception_return().  Define __ARCH_WANT_KERNEL_EXECVE in unistd.h
and kill kernel_execve() in entry.S.  ret_from_kernel_execve() will get as
its argument task_pt_regs(current), which often spares us some calculations.
	* define __ARCH_WANT_SYS_EXECVE in unistd.h, kill xtensa_execve();
just use sys_execve instead.
	* as an optimization, define current_pt_regs() as
(struct pt_regs *)((unsigned long)current_thread_info() +
 KERNEL_STACK_SIZE - (XCHAL_NUM_AREGS-16)*4) - 1).  I.e. an equivalent of
task_pt_regs(current) without useless work - task_stack_page(current) is
expanded to task_stack_page(current_thread_info()->task), which is
equal to current_thread_info()...

That would probably allow more glue removal - no more syscalls from the
kernel, for one thing.  For another, xtensa_clone() won't need to locate
struct pt_regs * - current_pt_regs() would work just as well and be faster
anyway.  The same goes for xtensa_rt_sigreturn() and xtensa_sigaltstack()...
--
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