Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[Al Viro <viro@ZenIV.linux.org.uk>]

On Thu, Aug 11, 2011 at 02:13:22PM +0200, richard -rw- weinberger wrote:

> Sorry for the delay.
> Writing my theses consumes a lot of my time...
> 
> I've already started reviewing and testing your changes.
> Currently they life in my local git repo.
> But a git.kernel.org repo is on the way!
> 
> Later I'll submit all changes to akpm.

OK...  It does end up in linux-next, so...  OTOH, why not send direct pull
requests to Linus?

Speaking of more fun in there:
	* coredumps do not contain fp registers; fixable by switching to
what x86 is doing (CORE_DUMP_USE_REGSET and corresponding bits in uml-x86
ptrace.c - arch/x86/um/ptrace*.c in this tree, arch/um/sys-*/ptrace.c in
mainline)
	* more drivers/{lin,chan*}.c races ;-/  Protecting setup_one_line()
from being done on opened ones is nice, but we are really not safe until
parse_chan_pair() has been finished...  I've partial fixes, but it's not
quite trivial.
	* fixrange_init() assumes that start and end are both multiples of
PMD_SIZE, which is not true, to put it mildly.  Wraparounds are possible
there - e.g. I've seen it called with 0xfffe000/0xffff000 for 32bit UML
running on amd64 host.  Not pretty, since vaddr < end will always remain
true when called that way.  With 3-level pagetables it gets really ugly -
it's nowhere near the end of upper-level table yet, so i < PTRS_PER_PGD
also doesn't stop the sucker.  I think the right solution here is to shift
vaddr down by PMD_SHIFT and do the same to end (taking care of fencepost
errors, of course).
	* no biarch support; that one might be really painful to implement,
but if we want it on something like ppc64 or sparc64 where the userland
is routinely 32bit...  That's going to be really rough on mm-switching
variants, BTW - when kernel address space is 64bit one and userland ones
are 32bit... <shudder>

	Anyway, I'm back to pure VFS work for the next few weeks.  I'll
probably dump fixrange_init() fixes into this tree, but anything beyond
that will have to wait until I dig myself out of atomic_open work and
unionfs/overlayfs/aufs/whatnot mess...