linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Chris Metcalf <cmetcalf@tilera.com>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
Date: Sat, 20 Oct 2012 16:34:01 +0100	[thread overview]
Message-ID: <20121020153401.GT2616@ZenIV.linux.org.uk> (raw)
In-Reply-To: <5082A1F1.3080303@tilera.com>

On Sat, Oct 20, 2012 at 09:06:57AM -0400, Chris Metcalf wrote:
> First, the compat_sys_execve() declaration provided in
> arch/tile/include/asm/compat.h isn't right, so I deleted that (you had only
> deleted the PTREGS_SYSCALL trampoline declaration, _compat_sys_execve).
> 
> However, then arch/tile/kernel/compat.c failed to build, because
> <linux/compat.h> is included before <asm/unistd.h>, and <asm/unistd.h>
> provides __ARCH_WANT_SYS_EXECVE, and so we end up with no declaration at
> all for compat_sys_execve.  For most platforms this is no big deal, but on
> tile we use the __SYSCALL #define to provide the actual syscall table, and
> for that to work we need a declaration in scope for each syscall at the
> time we create the table.
> 
> The best solution seems likely to be to copy the other place in
> <linux/compat.h> where we need to do something configurable (that is,
> CONFIG_ARCH_WANT_OLD_COMPAT_IPC), and just convert __ARCH_WANT_SYS_EXECVE
> to be a Kconfig option.

Frankly, I hope to get rid of the damn thing completely.  By now we have
at least some variant of execve conversions for just about everything;
I certainly hope that by the beginning of the next cycle we'll have it
defined on everything.  And put unconditional declarations in syscalls.h
and compat.h

Actually, we can make the declaration in linux/compat.h unconditional
right now.  The only obstacle is the situation on arm64; there the mainline
has C variant of that sucker (with struct pt_regs * in arguments) in
arch/arm64/kernel/sys_compat.c.  So we could ask Linus to pull
git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 execve
and then do the following in one patch:
	introduce current_pt_regs() on tile (from your commit)
	get rid of pt_regs * argument in tile compat_sys_execve(), making it
use current_pt_regs(); kill its wrapper
	kill the declarations of compat_sys_execve()/_compat_sys_execve()
in tile asm/compat.h
	make declaration in linux/compat.h unconditional
Note that this does *not* depend on kernel_thread/kernel_execve patch -
kernel_execve() is never going to hit compat_sys_execve(), since it's
only called from kernel threads and those are not going to be 32bit.
After that we can do kernel_thread/kernel_execve commit and
sys_execve() conversion with nothing outside of arch/tile touched.

Comments?  If Catalin feels that arm64 series needs more testing, we could
reorder it a bit - all we really need there is getting rid of pt_regs argument
in compat_sys_execve() and just as on tile, that isn't tied into kernel_execve
and kernel_thread issues.

FWIW, it's my fault - I assumed that it would be easier to sort the compat
side of things out on per-arch basis.  Should've consolidated *that* first
(unlike sys_execve(), that doesn't have any prereqs), followed by the
infrastructure for kernel_thread/kernel_execve/sys_execve series, followed
by the per-architecture conversions.  Too late for that now, of course,
and fortunately the mess is fairly small.

  reply	other threads:[~2012-10-20 15:34 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-16 22:35 new execve/kernel_thread design Al Viro
2012-10-17  5:32 ` Max Filippov
2012-10-17  5:43   ` Al Viro
2012-10-17 14:07 ` Jonas Bonn
2012-10-17 14:27   ` Michal Simek
2012-10-17 16:07     ` Al Viro
2012-10-17 16:19       ` Al Viro
2012-11-15 16:41         ` Michal Simek
2012-11-15 21:55           ` Al Viro
2012-11-16  7:59             ` Michal Simek
2012-11-18  5:45               ` sigaltstack fun (was Re: new execve/kernel_thread design) Al Viro
2012-11-18 18:45                 ` Linus Torvalds
2012-11-18 19:03                   ` sigaltstack fun David Miller
2012-11-18 19:59                     ` Al Viro
2012-11-18 20:48                       ` David Miller
2012-11-19  4:55                         ` Greg KH
2012-11-18 21:02                       ` Al Viro
2012-11-18 21:18                         ` David Miller
2012-11-19  1:10                           ` Al Viro
2012-11-19  1:30                             ` David Miller
2012-11-19  2:35                               ` Al Viro
2012-11-19  3:27                                 ` David Miller
2012-11-26  5:10                                   ` Al Viro
2012-11-26  5:15                                     ` Al Viro
2012-12-04  3:03                                       ` David Miller
2012-12-04  2:58                                     ` David Miller
2012-11-21  1:53                   ` sigaltstack fun (was Re: new execve/kernel_thread design) Al Viro
2012-10-19 15:49 ` new execve/kernel_thread design Al Viro
2012-10-19 17:16   ` Luck, Tony
2012-10-19 17:30     ` Al Viro
2012-10-19 18:01       ` Tony Luck
2012-10-19 18:33         ` Al Viro
2012-10-19 20:25 ` [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE Chris Metcalf
2012-10-19 21:35   ` Al Viro
2012-10-20 13:06     ` Chris Metcalf
2012-10-20 15:34       ` Al Viro [this message]
2012-10-20 17:16         ` Al Viro
2012-10-23 17:30           ` Chris Metcalf
2012-10-23 18:41             ` Al Viro
2012-10-23 19:22               ` Chris Metcalf
2012-10-23 20:36                 ` Al Viro
2012-10-25 13:31                   ` Chris Metcalf
2012-10-25 14:25                     ` Al Viro
2012-10-23 20:47               ` Thomas Gleixner
2012-10-23 20:51                 ` Jeff King
2012-10-23 21:09                   ` Catalin Marinas
2012-10-23 21:22                     ` Jeff King
2012-10-24 11:18                       ` Catalin Marinas
2012-10-23 21:25                   ` Thomas Gleixner
2012-10-23 21:47                     ` Jeff King
2012-10-23 22:06                       ` Marc Gauthier
2012-10-23 22:23                         ` Jeff King
2012-10-24  6:02                           ` Johannes Sixt
2012-10-24  1:02                     ` Linus Torvalds
2012-10-24  1:56                       ` Al Viro
2012-10-24  2:14                         ` Linus Torvalds
2012-10-24  6:02                       ` Ingo Molnar
2012-10-23 17:30           ` [PATCH] arch/tile: eliminate pt_regs trampolines for syscalls Chris Metcalf
2012-10-22 14:23         ` [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE Catalin Marinas
2012-10-19 20:25 ` Chris Metcalf
2012-10-25 16:54 ` new execve/kernel_thread design Richard Kuo
2012-10-26 18:31 ` [update] " Al Viro
2012-10-27  3:32   ` Al Viro
2012-10-29  7:53   ` Martin Schwidefsky
2012-10-29 13:25     ` Al Viro
2012-10-29 14:38       ` Martin Schwidefsky
2012-10-29 14:57         ` Al Viro
2012-12-07 22:23   ` Al Viro
2012-12-08  2:40     ` Chris Metcalf
2012-12-13  1:54     ` Hirokazu Takata

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121020153401.GT2616@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=catalin.marinas@arm.com \
    --cc=cmetcalf@tilera.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).