Acked-By: Ian Munsie imun...@au1.ibm.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
From: Ian Munsie imun...@au1.ibm.com
An issue was introduced with cxl: Unmap MMIO regions when detaching a
context (b123429e6a9e8d03aacf888d23262835f0081448) where closing a
context normally could also unmap the problem state area of other
contexts currently using the AFU.
It was also discovered
.
Signed-off-by: Ryan Grimm gr...@linux.vnet.ibm.com
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
drivers/misc/cxl/pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index 2ccd0a9..f801c28 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers
Excerpts from Ian Munsie's message of 2014-12-08 19:18:01 +1100:
From: Ian Munsie imun...@au1.ibm.com
If we need to force detach a context (e.g. due to EEH or simply force
unbinding the driver) we should prevent the userspace contexts from
being able to access the Problem State Area MMIO
From: Ian Munsie imun...@au1.ibm.com
We had a known sleep while atomic bug if a CXL device was forcefully
unbound while it was in use. This could occur as a result of EEH, or
manually induced with something like this while the device was in use:
echo :01:00.0 /sys/bus/pci/drivers/cxl-pci
From: Ian Munsie imun...@au1.ibm.com
In the event that something goes wrong in the hardware and it is unable
to complete a process element comment we would end up polling forever,
effectively making the associated process unkillable.
This patch adds a timeout to the process element command code
From: Ian Munsie imun...@au1.ibm.com
If a context is being detached and we get a translation fault for it
there is little point getting it's mm and handling the fault, so just
respond with an address error and return earlier.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
drivers/misc/cxl
From: Ian Munsie imun...@au1.ibm.com
Upon inspection of the implementation specific registers, it was
discovered that the high bit of the implementation specific RXCTL
register was enabled, which enables the DEADB00F debug feature.
The debug feature causes MMIO reads to a disabled AFU to respond
From: Ian Munsie imun...@au1.ibm.com
When we deactivate the AFU directed mode we free the scheduled process
area, but did not clear the register in the hardware that has a pointer
to it.
This should be fine since we will have already cleared out every context
and we won't do anything that would
From: Ian Munsie imun...@au1.ibm.com
In this particular error path we have already allocated the AFU
interrupts, but have not yet set the status to STARTED. The detach
context code will only attempt to release the interrupts if the context
is in state STARTED, so in this case the interrupts would
From: Ian Munsie imun...@au1.ibm.com
If we need to force detach a context (e.g. due to EEH or simply force
unbinding the driver) we should prevent the userspace contexts from
being able to access the Problem State Area MMIO region further, which
they may have mapped with mmap().
This patch
This patch will definitely need to go to stable - we've run into issues
a couple of times when something has gone wrong on an AFU and ended up
taking down the whole system as a result of this bug.
Cheers,
-Ian
___
Linuxppc-dev mailing list
This one needs to go to stable - I've hit it a couple of times while
testing bad AFUs and it results in an unkillable process.
Cheers,
-Ian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
This one would be nice to go to stable, but I'm not sure if it's
critical enough to justify it since it only reduces the number of
available interrupts (and therefore, contexts) that can be used by the
card (so, maybe you can only run 507 contexts simultaneously instead of
509)...
Cheers,
-Ian
This one would be nice to go to stable, but I'm not sure it really meets
the rules. It could be a problem for userspace error paths checking the
result of MMIO reads, but only if the AFU has actually been unexpectedly
disabled somehow yet the PSL is still responding...
I don't think this is a
This one should go to stable - this was the first bug uncovered after
fixing the sleep while atomic and force unbinding the driver.
Cheers,
-Ian
Excerpts from Ian Munsie's message of 2014-12-08 19:18:01 +1100:
From: Ian Munsie imun...@au1.ibm.com
If we need to force detach a context (e.g
From: Ian Munsie imun...@au1.ibm.com
If an AFU has a hardware bug that causes it to acknowledge a context
terminate or remove while that context has outstanding transactions, it
is possible for the kernel to receive an interrupt for that context
after we have removed it from the context list
Excerpts from Michael Ellerman's message of 2014-10-27 17:41:00 +1100:
On Mon, 2014-27-10 at 04:24:35 UTC, Ian Munsie wrote:
From: Ian Munsie imun...@au1.ibm.com
In certain circumstances the PSL can send an interrupt for a segment
Define PSL before using it please.
ok
The CXL driver
Excerpts from Aneesh Kumar K.V's message of 2014-10-28 01:38:41 +1100:
I guess you are missing too many fixes in one patch.
1) One cleanup
2) Fix for masking ea correctly
3) And fix for not erroring out when a slb is already in the slb cache.
ok, I'll split it up
+/* This finds a free
From: Ian Munsie imun...@au1.ibm.com
This patch simplifies the process of finding a free segment table entry
by disabling the secondary hash. This reduces the number of possible
entries in the segment table for a given address from 16 to 8.
Due to the large segment sizes we use it is extremely
From: Ian Munsie imun...@au1.ibm.com
In certain circumstances the PSL (Power Service Layer, which provides
translation services for CXL hardware) can send an interrupt for a
segment miss that the kernel has already handled. This can happen if
multiple translations for the same segment are queued
In certain circumstances the PSL (Power Service Layer, which provides
translation services for CXL hardware) can send an interrupt for a segment miss
that the kernel has already handled. This can happen if multiple translations
for the same segment are queued in the PSL before the kernel has
From: Ian Munsie imun...@au1.ibm.com
This patch makes copro_calculate_slb mask the ESID by the correct mask
for 1T vs 256M segments.
This has no effect by itself as the extra bits were ignored, but it
makes debugging the segment table entries easier and means that we can
directly compare
From: Ian Munsie imun...@au1.ibm.com
This moves the segment table hash calculation from cxl_load_segment into
find_free_sste since that is the only place it is actually used.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
drivers/misc/cxl/fault.c | 34 ++
1
From: Ian Munsie imun...@au1.ibm.com
In certain circumstances the PSL can send an interrupt for a segment
miss that the kernel has already handled. This can happen if multiple
translations for the same segment are queued in the PSL before the
kernel has restarted the first translation.
The CXL
Excerpts from Michael Neuling's message of 2014-10-08 19:55:02 +1100:
+static ssize_t afu_read(struct file *file, char __user *buf, size_t count,
+loff_t *off)
...
+for (;;) {
+prepare_to_wait(ctx-wq, wait, TASK_INTERRUPTIBLE);
+if (ctx_event_pending(ctx))
+
correctly.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
drivers/misc/cxl/file.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/misc/cxl/file.c b/drivers/misc/cxl/file.c
index 847b7e6..378b099 100644
--- a/drivers/misc/cxl/file.c
+++ b/drivers
From: Ian Munsie imun...@au1.ibm.com
If afu_read() returned due to a signal or the AFU file descriptor being
opened non-blocking it would not call finish_wait() before returning,
which could lead to a crash later when something else wakes up the wait
queue.
This patch restructures the wait logic
Hey Michael,
Excerpts from Michael Ellerman's message of 2014-10-02 16:02:37 +1000:
+/* ioctls */
+struct cxl_ioctl_start_work {
+__u64 wed;
+__u64 amr;
+__u64 reserved1;
+__u32 reserved2;
+__s16 num_interrupts; /* -1 = use value from afu descriptor */
+
Hi Cody,
I just tried building this with gcc 4.5, which failed with the following
warning (treated as an error):
cc1: warnings being treated as errors
arch/powerpc/perf/hv-24x7.c: In function 'single_24x7_request':
arch/powerpc/perf/hv-24x7.c:346:1: error: the frame size of 8192 bytes is
larger
From: Ian Munsie imun...@au1.ibm.com
If a doorbell IPI comes in while a thread is in nap power saving, the
doorbell interrupt won't be replayed by the hardware since it is edge
sensitive. Currently we are not replaying these interrupts in software,
which can cause threads to miss IPIs that come
Excerpts from Michael Ellerman's message of 2013-03-22 15:18:03 +1100:
On Wed, Mar 20, 2013 at 06:42:12PM +1100, Ian Munsie wrote:
From: Ian Munsie imun...@au1.ibm.com
This patch adds a new line to /proc/interrupts to account for the
doorbell interrupts that each hardware thread has
From: Ian Munsie imun...@au1.ibm.com
This patch adds a new line to /proc/interrupts to account for the
doorbell interrupts that each hardware thread has received. The total
interrupt count in /proc/stat will now also include doorbells.
# cat /proc/interrupts
CPU0 CPU1
From: Ian Munsie imun...@au1.ibm.com
This patch adds a new line to /proc/interrupts to account for the
doorbell interrupts that each hardware thread has received. The total
interrupt count in /proc/stat will now also include doorbells.
# cat /proc/interrupts
CPU0 CPU1
From: Ian Munsie imun...@au1.ibm.com
This patch adds support for enabling and context switching the Target
Address Register in Power8. The TAR is a new special purpose register
that can be used for computed branches with the bctar[l] (branch
conditional to TAR) instruction in the same manner
From: Ian Munsie imun...@au1.ibm.com
This patch adds support for enabling and context switching the Target
Address Register in Power8. The TAR is a new special purpose register
that can be used for computed branches with the bctar[l] (branch
conditional to TAR) instruction in the same manner
From: Ian Munsie imun...@au1.ibm.com
For PR KVM we allow userspace to map 0xc000. Because
transitioning from userspace to the guest kernel may use the relocated
exception vectors we have to disable relocation on exceptions whenever
PR KVM is active as we cannot trust that address
From: Ian Munsie imun...@au1.ibm.com
There are a few key differences between doorbells on server compared
with embedded that we care about on Linux, namely:
- We have a new msgsndp instruction for directed privileged doorbells.
msgsnd is used for directed hypervisor doorbells.
- The tag we use
From: Ian Munsie imun...@au1.ibm.com
Directed Privileged Doorbell Interrupts come in at 0xa00 (or
0xc0004a00 if relocation on exception is enabled), so add
exception vectors at these locations.
If doorbell support is not compiled in we handle it as an
unknown_exception.
Signed-off
This patch series adds support for using directed doorbell interrupts for IPIs
between threads within a core, which is supported by POWER8.
This should avoid the overhead of using XICS to deliver an IPI within a core,
though delivering IPIs between threads of different cores must still use XICS
From: Ian Munsie imun...@au1.ibm.com
On book3s we have two msgsnd instructions with differing privilege
levels. This patch selects the appropriate instruction to use whenever
we send a doorbell interrupt.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
Tested-by: Michael Neuling mi...@neuling.org
From: Ian Munsie imun...@au1.ibm.com
This patch actually hooks up doorbell interrupts on POWER8:
- Select the PPC_DOORBELL Kconfig option from PPC_PSERIES
- Add the doorbell CPU feature bit to POWER8
- We define a new pSeries_cause_ipi_mux() function that issues a
doorbell interrupt
From: Ian Munsie imun...@au1.ibm.com
Directed Hypervisor Doorbell Interrupts come in at 0xe80 (or
0xc0004e80 if relocation on exceptions is enabled), so add
exception vectors at these locations.
If doorbell support is not compiled in we handle it as an
unknown_exception.
Signed-off
From: Ian Munsie imun...@au1.ibm.com
This patch adds the logic to properly handle doorbells that come in when
interrupts have been soft disabled and to replay them when interrupts
are re-enabled:
- masked_##_H##interrupt is modified to leave interrupts enabled when a
doorbell has come in since
From: Ian Munsie imun...@au1.ibm.com
Move the rule to build doorbell support out of the Makefile and into a
new Kconfig boolean that platforms can select.
We will add doorbell support to pseries as well in the next patch.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
Tested-by: Michael Neuling
From: Ian Munsie imun...@au1.ibm.com
On PowerPC we use _GLOBAL throughout the assembly to define symbols, but
currently these symbols are missing from the tags generated with
ARCH=powerpc make tags. This patch modifies the tags.sh script to
recognise _GLOBAL(.*) so that these symbols
Excerpts from Steven Rostedt's message of Thu Feb 03 01:04:44 +1100 2011:
I'll answer your question here.
+#define arch_syscall_match_sym_name(sym, name) !strcmp(sym + 3, name + 3)
Instead, you could have:
#ifndef ARCH_HAS_SYSCALL_MATCH_SYM_NAME
static inline
Hi All,
This is a partial version of my 'ftrace syscalls, PowerPC: Various fixes,
Compat Syscall support and PowerPC implementation'. This is updated from
yesterday with arch_syscall_addr changed to a static inline function from
Steven's suggestion.
This subset implements the raw syscall
From: Ian Munsie imun...@au1.ibm.com
FTRACE_SYSCALLS would create events for each and every system call, even
if it had failed to map the system call's name with it's number. This
resulted in a number of events being created that would not behave as
expected.
This could happen, for example
From: Ian Munsie imun...@au1.ibm.com
With the ftrace events now checking if the syscall_nr is valid upon
initialisation it should no longer be possible to register or unregister
a syscall event without a valid syscall_nr since they should not be
created. This adds a WARN_ON_ONCE in the register
From: Ian Munsie imun...@au1.ibm.com
Some architectures use non-trivial system call tables and will not work
with the generic arch_syscall_addr code. For example, PowerPC64 uses a
table of twin long longs.
This patch makes the generic arch_syscall_addr weak to allow
architectures with non
From: Ian Munsie imun...@au1.ibm.com
Some architectures have unusual symbol names and the generic code to
match the symbol name with the function name for the syscall metadata
will fail. For example, symbols on PPC64 start with a period and the
generic code will fail to match them.
This patch
From: Ian Munsie imun...@au.ibm.com
This patch implements the raw syscall tracepoints on PowerPC and exports
them for ftrace syscalls to use.
To minimise reworking existing code, I slightly re-ordered the thread
info flags such that the new TIF_SYSCALL_TRACEPOINT bit would still fit
within
From: Ian Munsie imun...@au1.ibm.com
Many system calls are unimplemented and mapped to sys_ni_syscall, but at
boot ftrace would still search through every syscall metadata entry for
a match which wouldn't be there.
This patch adds causes the search to terminate early if the system call
git send-email just failed to save or send this message, so retyping...
Hi All,
This is a partial version of my 'ftrace syscalls, PowerPC: Various fixes,
Compat Syscall support and PowerPC implementation'.
I finally found some time this week to go back and work on this patchset, but
now I've
From: Ian Munsie imun...@au1.ibm.com
With the ftrace events now checking if the syscall_nr is valid upon
initialisation it should no longer be possible to register or unregister
a syscall event without a valid syscall_nr since they should not be
created. This adds a WARN_ON_ONCE in the register
From: Ian Munsie imun...@au1.ibm.com
Some architectures use non-trivial system call tables and will not work
with the generic arch_syscall_addr code. For example, PowerPC64 uses a
table of twin long longs.
This patch makes the generic arch_syscall_addr weak to allow
architectures with non
From: Ian Munsie imun...@au1.ibm.com
Some architectures have unusual symbol names and the generic code to
match the symbol name with the function name for the syscall metadata
will fail. For example, symbols on PPC64 start with a period and the
generic code will fail to match them.
This patch
From: Ian Munsie imun...@au1.ibm.com
Many system calls are unimplemented and mapped to sys_ni_syscall, but at
boot ftrace would still search through every syscall metadata entry for
a match which wouldn't be there.
This patch adds causes the search to terminate early if the system call
From: Ian Munsie imun...@au.ibm.com
This patch implements the raw syscall tracepoints on PowerPC and exports
them for ftrace syscalls to use.
To minimise reworking existing code, I slightly re-ordered the thread
info flags such that the new TIF_SYSCALL_TRACEPOINT bit would still fit
within
From: Ian Munsie imun...@au1.ibm.com
FTRACE_SYSCALLS would create events for each and every system call, even
if it had failed to map the system call's name with it's number. This
resulted in a number of events being created that would not behave as
expected.
This could happen, for example
From: Ian Munsie imun...@au.ibm.com
This patch implements the raw syscall tracepoints on PowerPC and exports
them for ftrace syscalls to use.
To minimise reworking existing code, I slightly re-ordered the thread
info flags such that the new TIF_SYSCALL_TRACEPOINT bit would still fit
within
Oops, It seems that I missed LKML in the to address of the cover email
for this set. Guess I shouldn't send a patch set just as the fire alarm
goes off. Resending:
Hi all,
This is a partial version of my 'ftrace syscalls, PowerPC: Various fixes,
Compat Syscall support and PowerPC
Hi Josh,
Excerpts from Josh Boyer's message of Fri Oct 01 21:36:35 +1000 2010:
Aside from my general uh, why? stance, I'm very very hesitant to
integrate anything in the kernel that doesn'.t have released patches
on the toolchain side.
As I said the kernel can be built today with an unpatched
Excerpts from Josh Boyer's message of Fri Oct 01 21:27:37 +1000 2010:
From: Ian Munsie imun...@au1.ibm.com
I haven't tested booting a little endian kernel on any of these targets,
but they all claim to be 44x so my little endian trampoline should work
on all of them, so wire it up
From: Ian Munsie imun...@au1.ibm.com
Since the boot wrapper must be built by a big endian 32bit toolchain
regardless of what the rest of the kernel is using introduce a new
parameter to specify that toolchain - CROSSBE_COMPILE.
We already have CROSS32_COMPILE which is already used for the boot
Some PowerPC processors can be run in either big or little endian modes, some
others can map selected pages of memory as little endian, which allows the same
thing. Until now we have only supported the default big endian mode in Linux.
This patch set introduces little endian support for the 44x
From: Ian Munsie imun...@au1.ibm.com
This patch adds support to the PowerPC zImage wrapper (which always runs
in big endian mode) to detect if the zImage is little endian and parse
it's ELF header to enable it's successful extraction.
It also provides some infrastructure for executing a little
From: Ian Munsie imun...@au1.ibm.com
With the little endian PowerPC Linux port, the CPU could be in either
mode. Rather than byte swapping and mapping the little endian bitmap
operations ourselves on the assumption that we are big endian, map them
to the generic macros that will automatically
From: Ian Munsie imun...@au1.ibm.com
The endianness on the 44x CPUs is controlled by the E bit in the TLB
entries. If the kernel has been compiled for little endian this patch
sets this E bit wherever they are set - in the PTE base flags, the early
debugging, and TLB pinning.
It defines some
From: Ian Munsie imun...@au1.ibm.com
This patch will have powerpc include the appropriate generic endianness
header depending on what the compiler reports.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
arch/powerpc/include/asm/byteorder.h |4
1 files changed, 4 insertions(+), 0
From: Ian Munsie imun...@au1.ibm.com
On the 44x we use 64bit page table entries, but the CPU is only 32bit.
When a PTE is loaded during a TLB miss each half is loaded into
different registers, so we need to reverse the offsets if the CPU is
running in little endian mode.
Signed-off-by: Ian
From: Ian Munsie imun...@au1.ibm.com
On PowerPC the device tree is always big endian, but the CPU could be
either, so add be32_to_cpu where appropriate and change the types of
device tree data to __be32 etc to allow sparse to locate endian issues.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
From: Ian Munsie imun...@au1.ibm.com
The speed and clock of the serial ports is retrieved from the device
tree in both the PowerPC legacy serial code and the Open Firmware serial
driver, therefore they need to handle the fact that the device tree is
always big endian, while the CPU may
From: Ian Munsie imun...@au1.ibm.com
The Device Control Register accesses parse the device tree and therefore
need to handle the possible differences of endianness between the CPU
and device tree.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
arch/powerpc/sysdev/dcr.c| 18
From: Ian Munsie imun...@au1.ibm.com
This patch reverses the order of the high and low bits in the alignment
handler on little endian, which should be enough to fix any alignment
exceptions.
Please note that this patch is largely untested.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
arch
From: Ian Munsie imun...@au1.ibm.com
This patch adds the appropriate conversions to correct the endianness
issues in the MTD driver whenever it accesses the device tree (which is
always big endian).
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
drivers/mtd/maps/physmap_of.c | 14
From: Ian Munsie imun...@au1.ibm.com
This patch fixes all the device tree and ring buffer accesses in the IBM
newemac driver.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
drivers/net/ibm_newemac/core.c | 68
drivers/net/ibm_newemac/mal.c |6
From: Ian Munsie imun...@au1.ibm.com
The vmlinux linker script sets the jiffies variable to the low word of
the jiffies_64 variable. This patch corrects which word is used on
little endian.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
arch/powerpc/kernel/vmlinux.lds.S |4
1 files
Excerpts from Geert Uytterhoeven's message of Fri Oct 01 17:13:19 +1000 2010:
Shouldn't the help text added by [PATCH 01/18]:
be updated here as well?
Yep, you're right. Thanks for pointing that out, I'll fix it for the next
revision.
Cheers,
-Ian
not run into this issue either because they don't have to deal with
the 32bit compat versions of the syscalls or just don't wire up that
particular compat syscall directly.
Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
kernel/sys_ni.c |1
From: Ian Munsie imun...@au1.ibm.com
This patch wires up the various socket system calls on PowerPC so that
userspace can call them directly, rather than by going through the
multiplexed socketcall system call.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
arch/powerpc/include/asm/systbl.h
Excerpts from Ian Munsie's message of Thu Aug 26 14:50:28 +1000 2010:
This patch wires up the various socket system calls on PowerPC so that
userspace can call them directly, rather than by going through the
multiplexed socketcall system call.
I should have mentioned that the base is ppc/next
Excerpts from Jason Baron's message of Thu Jun 24 04:03:54 +1000 2010:
overall this patch is a major improvement! My question though is
about the naming of the compat syscalls in the context of events. I
believe this patch differeniates compat syscall event names as:
sys32_enter_sname, and
Excerpts from Steven Rostedt's message of Thu Jun 24 01:02:19 +1000 2010:
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 34e3580..82246ce 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -431,6 +431,14 @@ void
This patch series implements ftrace syscall tracing on PowerPC. All PPC 32bit,
64bit and 32bit compat syscalls are supported along with all the missing
generic compat syscalls.
This patch series includes Jason Baron's Compat Syscall Support v3 patches
rebased atop the current tip tree as patches
From: Ian Munsie imun...@au1.ibm.com
FTRACE_SYSCALLS would create events for each and every system call, even
if it had failed to map the system call's name with it's number. This
resulted in a number of events being created that would not behave as
expected.
This could happen, for example
From: Ian Munsie imun...@au1.ibm.com
Some architectures use non-trivial system call tables and will not work
with the generic arch_syscall_addr code. For example, PowerPC64 uses a
table of twin long longs.
This patch makes the generic arch_syscall_addr weak to allow
architectures with non
From: Ian Munsie imun...@au1.ibm.com
Some architectures have unusual symbol names and the generic code to
match the symbol name with the function name for the syscall metadata
will fail. For example, symbols on PPC64 start with a period and the
generic code will fail to match them.
This patch
From: Ian Munsie imun...@au.ibm.com
This patch implements the raw syscall tracepoints on PowerPC and exports
them for ftrace syscalls to use.
To minimise reworking existing code, I slightly re-ordered the thread
info flags such that the new TIF_SYSCALL_TRACEPOINT bit would still fit
within
From: Jason Baron jba...@redhat.com
Add 'NR_syscalls_compat' global for x86. Also, make 'ia32_sys_call_table' into a
global.
Signed-off-by: Jason Baron jba...@redhat.com
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
arch/x86/ia32/ia32entry.S |3 +++
arch/x86/include/asm/compat.h
From: Jason Baron jba...@redhat.com
Add arch_compat_syscall_addr(int nr) for x86_64. This is in preparation for
adding
compat syscall support to the event tracer.
Signed-off-by: Jason Baron jba...@redhat.com
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
arch/x86/include/asm/syscall.h
From: Heiko Carstens heiko.carst...@de.ibm.com
add generic is_compat_task()
Signed-off-by: Jason Baron jba...@redhat.com
Signed-off-by: Heiko Carstens heiko.carst...@de.ibm.com
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
arch/s390/include/asm/compat.h |7 ---
arch/s390/kernel
to remove the bitmap data structures completely.
Signed-off-by: Jason Baron jba...@redhat.com
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
include/linux/syscalls.h |8 +++
include/trace/syscall.h |4 +++
kernel/trace/trace_syscalls.c | 42
...@redhat.com
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
include/linux/ftrace_event.h |3 +++
kernel/trace/trace_events.c |3 ---
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 0af31cd..54b020b 100644
From: Jason Baron jba...@redhat.com
Make use of the new ARCH_COMPAT_SYSCALL_DEFINE#N() macros to tie the compat
syscalls into the event tracer.
Signed-off-by: Jason Baron jba...@redhat.com
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
arch/x86/ia32/sys_ia32.c | 102
arguments and whether or not we are enabled.
Signed-off-by: Jason Baron jba...@redhat.com
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
include/linux/compat.h|2 +
include/trace/syscall.h |4 ++
kernel/trace/trace.h |2 +
kernel/trace/trace_syscalls.c | 86
From: Jason Baron jba...@redhat.com
convert the fs/compat.c file to use the COMPAT_SYSCALL_DEFINE#N() macros to tie
them into the generic compat layer.
Signed-off-by: Jason Baron jba...@redhat.com
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
fs/compat.c | 147
From: Jason Baron jba...@redhat.com
convert kernel/compat.c to use the new COMPAT_SYSCALL_DEFINE#N macro. Thus,
tying these syscalls into the syscall event layer.
Signed-off-by: Jason Baron jba...@redhat.com
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
kernel/compat.c | 106
From: Jason Baron jba...@redhat.com
make tags.sh recognize the new syscall macros:
COMPAT_SYSCALL_DEFINE#N()
ARCH_COMPAT_SYSCALL_DEFINE#N()
Signed-off-by: Jason Baron jba...@redhat.com
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
scripts/tags.sh |8 ++--
1 files changed, 6
301 - 400 of 448 matches
Mail list logo
