linux-toradex.git/arch/um, branch tegra

um: Fix kmalloc argument order in um/vdso/vma.c

2011-11-11T17:43:36+00:00

commit 0d65ede0a605d6252acc5c8a9c536c4cd0211f3c upstream.

kmalloc size is 1st arg, not second.

Signed-off-by: Dave Jones 
Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman

um: fix ubd cow size

2011-11-11T17:43:35+00:00

commit 8535639810e578960233ad39def3ac2157b0c3ec upstream.

ubd_file_size() cannot use ubd_dev->cow.file because at this time
ubd_dev->cow.file is not initialized.
Therefore, ubd_file_size() will always report a wrong disk size when
COW files are used.
Reading from /dev/ubd* would crash the kernel.

We have to read the correct disk size from the COW file's backing
file.

Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman

um: fix strrchr() problems

2011-09-15T01:09:37+00:00

richard@nod.at:
Fixes:
  /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/libc.a(strrchr.o): In function `rindex':
  (.text+0x0): multiple definition of `strrchr'

If both STATIC_LINK and UML_NET_VDE are set to "y" libc's strrchr may
clash with the kernel implementation.

This workaround comes originally from Jeff Dike:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494995#35

Signed-off-by: Al Viro 
Signed-off-by: Richard Weinberger 
Cc: Jeff Dike 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

um: clean arch_ptrace() up a bit

2011-09-15T01:09:37+00:00

1) take subarch-specific stuff to subarch_ptrace()
2) PTRACE_{PEEK,POKE}{TEXT,DATA} is handled by ptrace_request() just fine...

Signed-off-by: Al Viro 
Signed-off-by: Richard Weinberger 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

um: PTRACE_[GS]ETFPXREGS had been wired on the wrong subarch

2011-09-15T01:09:37+00:00

It's 32bit-only, not 64bit-only...  And while we are at it, it's
set_fpxregs(), not set_fpregs()...

Signed-off-by: Al Viro 
Signed-off-by: Richard Weinberger 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

um: fix free_winch() mess

2011-09-15T01:09:37+00:00

while not doing free_irq() from irq handler is commendable, kfree() on the
data passed to said handler before free_irq() is Not Good(tm).  Freeing
the stack it's being run on is also not nice...  Solution: delay actually
freeing stuff.

Signed-off-by: Al Viro 
Signed-off-by: Richard Weinberger 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

um: winch_interrupt() can happen inside of free_winch()

2011-09-15T01:09:37+00:00

...  so set winch->fd to -1 before doing free_irq(), to avoid having
winch_interrupt() come from/during the latter and attempt to do
reactivate_fd() on something that's already gone.

Signed-off-by: Al Viro 
Signed-off-by: Richard Weinberger 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

um: fix oopsable race in line_close()

2011-09-15T01:09:37+00:00

tty->count is decremented only after ->close() had been called and
several tasks can hit it in parallel.  As the result, using tty->count
to check if you are the last one is broken.  We end up leaving line->tty
not reset to NULL and the next IRQ on that sucker will blow up trying to
dereference pointers from kfree'd struct tty.

Fix is obvious: we need to use a counter of our own.

Signed-off-by: Al Viro 
Signed-off-by: Richard Weinberger 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

um: Save FPU registers between task switches

2011-09-15T01:09:37+00:00

Some time ago Jeff prepared 42daba316557 ("uml: stop saving process FP
state") for UML to stop saving the process FP state between task
switches.  The assumption was that since with SKAS0 every guest process
runs inside a host process context the host OS will take care of keeping
the proper FP state.

Unfortunately this is not true for multi-threaded applications, where
all guest threads share a single host process context yet all may use
the FPU on their own.  Although I haven't verified it I suspect things
to be even worse in SKAS3 mode where all guest processes run inside a
single host process.

The patch reintroduces the saving and restoring of the FP context
between task switches.

[richard@nod.at: Ingo posted this patch in 2009, sadly it was never applied
and got lost. Now in 2011 the problem was reported by Gunnar.]

Signed-off-by: Ingo van Lil 
Signed-off-by: Richard Weinberger 
Reported-by: 
Tested-by: 
Cc: Stanislav Meduna 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

um: drivers/xterm.c: fix a file descriptor leak

2011-09-15T01:09:37+00:00

I could use out_close1, but that seems to be the code path to close the fd
returned by os_create_unix_socket, and using it to close the fd returned
by mkstemp might lead to some confusion, so I don't do it.

Signed-off-by: Jonathan Neuschäfer 
Signed-off-by: Richard Weinberger 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds