Nick Alcock [Mon, 3 Aug 2015 12:40:29 +0000 (13:40 +0100)]
kallsyms: make it possible to disable /proc/kallmodsyms
This allows you to build UEK without elfutils present at all, just like you
can with the upstream.
It requires a bit of fiddling about in kernel/kallsyms.c to make kallsyms
work with a NULL kallsyms_symbol_modules, and a bit of code motion to keep
the number of ifdefs down.
Verified that /proc/kallsyms has identical output (modulo only addresses,
dtrace-related symbols and, of course, the symbols ifdeffed out in this
patch) when the new CONFIG_KALLMODSYMS option is flipped.
Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Acked-by: Kris Van Hees <kris.van.hees@oracle.com>
Orabug: 21539840
dtrace: accomodate changes in the 4.1 kernel for sparc64
The handling of some system calls changed:
- The sigaltstack system call is no longer a special case using a
stub in assembler.
- New system call: execveat
This commit also fixes a problem with the support for the execveat
system call on x86_64, where not all arguments were being passed in
the entry probe for that new system call.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com> Acked-by: Nick Alcock <nick.alcock@oracle.com>
dtrace: ignore any and all PFs during NOFAULT memory acceses
Previously, memory access from DTrace probe handling could be marked
as NOFAULT (ignore faults) and/or NOPF (ignore page faults). However,
when safe memory access support is necessary, it is required that no
faults of any kind are allowed to disrupt the system.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com> Acked-by: Nick Alcock <nick.alcock@oracle.com>
Kris Van Hees [Tue, 2 Jun 2015 20:34:20 +0000 (16:34 -0400)]
dtrace: convert from sdt_instr_t to asm_instr_t 2of2
The sdt_instr_t type was introduced as a generic type name for machine
instructions to be defined as a synonym for the arch-specific type.
It was named thusly because it was only used by the SDT support code.
However, other providers will need it also (e.g. FBT) and therefore it
is more appropriate to give it a name that is not tied to a specific
provider.
Kris Van Hees [Tue, 2 Jun 2015 20:34:20 +0000 (16:34 -0400)]
dtrace: convert from sdt_instr_t to asm_instr_t 1of2
The sdt_instr_t type was introduced as a generic type name for machine
instructions to be defined as a synonym for the arch-specific type.
It was named thusly because it was only used by the SDT support code.
However, other providers will need it also (e.g. FBT) and therefore it
is more appropriate to give it a name that is not tied to a specific
provider.
Kris Van Hees [Thu, 4 Jun 2015 20:17:43 +0000 (16:17 -0400)]
dtrace: allocate space for SDT trampolines using module_alloc
The allocation of the SDT trampolines was done previously using vmalloc
which may cause the trampolines to be too far away from the code that
they provide a call to dtrace_probe() for, making it impossible to put
a jump to the trampoline in a single instruction at the probe location.
By using module_alloc on SPARC, the trampolines are allocated in the
memory region where modules live, which is by design within the jump
range.
The allocated memory is known to be of sufficient size for trampolines,
yet its actual use is not determined at the kernel level. It is simply
provided as a chunk of memory in the appropriate range.
Nick Alcock [Mon, 15 Jun 2015 16:47:42 +0000 (17:47 +0100)]
kallsyms: fix /proc/kallmodsyms to not be misled by const variables
The recent fix to bug 21172433 caused all symbols with the external DWARF
attribute which appear in only one built-in module to be considered part of that
module rather than part of the core kernel as far as /proc/kallmodsyms is
concerned. Unfortunately, this is the wrong DWARF attribute to use: it
indicates that the content is visible outside this compilation unit, which
is of course true even of the definition of anything which *can* be
declared 'extern' (since it is, of course, not declared 'static').
The right attribute to use is the declaration attribute, which is unset only
for the definition -- the module containing the translation unit in which a
variable is defined is surely the module in which that variable resides.
Orabug: 21257163 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Acked-by: Kris Van Hees <kris.van.hees@oracle.com>
Nick Alcock [Fri, 29 May 2015 20:40:20 +0000 (21:40 +0100)]
kallsyms: fix /proc/kallmodsyms to not be misled by external symbols
The population of /proc/kallmodsyms is thrown off by external symbols: not only
does it include them in /proc/kallmodsyms even if they have no corresponding
definition, because the relevant definition is not configured in (leading to a
huge number of useless symbols), but it assumes that if the symbol appears
in one built-in module, the symbol is defined there, even if it was declared
'extern'.
This can lead to lunacies such as saved_command_line appearing to come from the
openprom module and stuff like that. More generally, it can lead to symbols
apparently moving around if extern references to them are added or modules are
added to the kernel configuration, which is clearly unacceptable.
Orabug: 21172433 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Todd Vierling <todd.vierling@oracle.com>
Nick Alcock [Wed, 27 May 2015 14:54:27 +0000 (15:54 +0100)]
wait: change waitfd() to use wait4(), not waitid(); reduce invasiveness
The waitfd() syscall, introduced principally for DTrace's use, has turned out to
be somewhat problematic because of differences between waitid() and waitpid().
In particular, you can't use waitfd() usefully on ptrace()d multithreaded
processes because waitid() explicitly rejects __WNOTHREAD, so your waitfd will
be written to even when a corresponding waitpid() will return nothing. Also, of
course, waitid() isn't much use for communicating with ptrace()d children
because it throws away most of the information needed.
So rejig waitfd() to use wait4 (the guts of waitpid()) instead. This has both
positive and negative consequences.
On the positive side, the significant changes to kernel/exit.c which were
imposed to cater for the waitfd()'s info parameter can all be discarded: we are
much closer to mainline. (The diff between mainline kernel/exit.c and this
patch is 23 lines, down from 83 before it.)
The downside is that half the parameters to the waitfd() syscall are useless
now, because they are modelled on waitid(), which is no longer used (the which
and flags arguments), but we can't remove them without breaking the syscall's
one caller. The content read from the waitfd has also changed -- rather than
being an array of 'struct siginfo' it is an array of ints, waitpid() exit
statuses. This is not a problem in practice because all released versions of
dtrace only poll this descriptor: they never read from it.
Cross-compatibility, therefore:
- older dtrace, older kernel: works.
- older dtrace, newer kernel: works, because the syscall's parameters are
unchanged, waitfd() was being called with P_PID and zero flags, giving
identical behaviour; this dtrace doesn't work properly with multithreaded
tracees as it is, so we can ignore that case (it won't work worse)
- newer dtrace, older kernel: an attempted call with __WNOTHREAD will fail, so
it will retry without __WNOTHREAD, and succeed (this means that we could
introduce a new syscall, new_waitfd(), without those compatibility
arguments, if you prefer); for multithreaded tracees, the older kernel will
tell dtrace that lots of threads have changed state even when they haven't,
incurring substantial CPU-wasting spinning
- newer dtrace, newer kernel: works as intended.
Orabug: 21245371 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Todd Vierling <todd.vierling@oracle.com>
Nick Alcock [Mon, 23 Feb 2015 14:03:14 +0000 (14:03 +0000)]
dtrace: x86: Cater for new instruction size limit in instruction decoder
This adjusts to the API change in commit 6ba48ff upstream. (We use the same
technique as kprobes, allowing instructions of any size, since this PF will
always come from kernelspace and never contain a malicious instruction stream.)
Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Acked-by: Kris Van Hees <kris.van.hees@oracle.com>
Nick Alcock [Tue, 17 Mar 2015 18:46:36 +0000 (18:46 +0000)]
mm: memcontrol: adjust prototype to allow for poll_wait_fixed() changes.
The poll_wait_fixed() stuff changed the prototype of the poll_queue_proc.
memcg_event_ptable_queue_proc() needs to change correspondingly. (The
extra parameter is unused by this function.)
Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Nick Alcock [Tue, 24 Feb 2015 20:49:14 +0000 (20:49 +0000)]
dtrace: zero-initialize the fake vmlinux module's pdata space
We need to do this because we bypass normal module initialization for this
"module", so move_module() is never called for it and the memory is never zeroed
as it is for real modules.
If this is not done, we end up with a non-initialized pdata which may contain
e.g. a non-zero count of the number of registered SDT probes, even before any
had been registered. (This would have the effect of preventing the registration
of any SDT probes in the main kernel, forever.)
Orabug: 19005031 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Kris Van Hees <kris.van.hees@oracle.com>
Kris Van Hees [Wed, 28 Jan 2015 17:08:01 +0000 (12:08 -0500)]
dtrace: make it possible to call do_sigaltstack()
DTrace needs to be able to call do_sigaltstack() from its system call
stub code when we're trying to probe that system call. With the shift
to UEK4, that function was marked static.
Kris Van Hees [Mon, 26 Jan 2015 21:19:54 +0000 (16:19 -0500)]
dtrace: do not vmalloc/vfree from probe context
The dtrace_stacktrace() code was using vmalloc/vfree in cases where no
array for PCs was provided (as was the case for getting the stackdepth).
When this code gets called from probe context, we might be processing an
interrupt or trap, and it is not safe to use vmalloc/vfree in that context.
We now pass in a (pre-allocated) scratch buffer instead.
Kris Van Hees [Thu, 15 Jan 2015 09:43:43 +0000 (04:43 -0500)]
dtrace: fix dtrace_sdt.sh for UEK4
The new base kernel for UEK4 no longer defines ARCH as x86_64 or sparc64,
but rather as x86 and sparc (and 32/64 is handled on a per-arch level). So,
various conditionals in this script needed updating. This commit also gets
rid of some debugging output.
Nick Alcock [Fri, 9 Jan 2015 19:23:20 +0000 (19:23 +0000)]
ctf: speed up dwarf2ctf by avoiding ctf_update() calls
By far the slowest operation in dwarf2ctf is ctf_update(). This operation
serializes all CTF data then essentially reopens the CTF file using that data.
For large CTF files like the vmlinux and shared type repositories this is
extremely slow, yet we do it between every top-level type and variable and
sometimes even more often than that. We are doing this for three reasons:
- firstly, in case of error we want to be able to throw away the erroneous
type and any new types we may have added that it depends on but nothing
else does. libdtrace-ctf's only API for this is ctf_discard(), which
throws away all types added since the most recent ctf_update(): so we
must call ctf_update() frequently just to give a point to discard to.
- secondly, whenever a new structure is encountered we need to count the number
of members in it to tell whether it is at least as large as any
previously-encountered instance in scope in this CTF file or the shared one,
and if it is, to note that the already-existing structure should be updated
rather than creating a new one: we did this by iterating over the members in
the DWARF and in the previously-encountered instance in the CTF. That meant
the CTF type had to be lookable-up... and you can't look up newly-added types
in CTF until you've called ctf_update() on the CTF file containing those
types.
- thirdly, libdtrace-ctf internally looks up the type of structure members to
determine their size (and thus the offset of the next element).
We avoid the first requirement by using the new ctf_snapshot()/ctf_rollback()
machinery. ctf_snapshot() is radically faster than ctf_update(): it just grabs
a couple of integers, increments one, and returns them. So we can usually avoid
calling ctf_update() between every emitted type, though we do then have to call
it for all the CTF files just before we emit them. (But that happens only once
for a given file.)
We avoid the second requirement by maintaining our own count of structure and
union members in the recently-added per_module hash: this count is itself a hash
mapping a variant of CTF structure names (an "s" or "u", then a space, then the
name) to a structure containing the CTF file that contains this structure
definition, its type ID, and a count of its members. (We use this notation
because we want to know if a structure has the same C name as another structure,
even if its type ID differs because it was declared in a different place). We
can then check this structure's count to see if a structure of this name already
exists, and return its CTF ID (recorded when the structure was emitted for the
first time). The member-emission code, obviously, has to pull out this count
and increment it whenever it emits a new member (even a blacklisted one which is
otherwise ignored, since we are interested in the size of the original
structure *in the DWARF*). This data is never thrown away, because built-in
modules can come in and out of scope, interspersed with each other and with
always-built-in kernel code, as we walk through vmlinux.o.
The third requirement, alas, cannot be avoided, but we can reduce the overhead
of it somewhat. Rather than unconditionally doing a ctf_update() whenever we
insert a new type and whenever we insert a new structure tag (just in case this
structure refers to its own tag), we err on the side of optimism and try to
insert the member anyway, and *only if it fails* with a bad ID error do we do an
update. The bad ID might happen because the type of a member is not known, or
because a type that member depends upon is not known: either of these might be
in the shared type repository. Again, we err on the side of optimism and
ctf_update() the non-shared CTF file first -- it's probably much smaller and
will update faster. Then we try adding the member again, and only if *that*
fails do we ctf_update() the share repository. If insertion still fails after
that, it's a real error, and is treated as such.
This third requirement conflicts with the first a bit -- we have now called
ctf_update() after a ctf_snapshot() was carried out, which prevents us from
rolling back in case of error. So we look for an ECTF_OVERROLLBACK error from
ctf_rollback(), and if one happens, we do a ctf_discard() instead, throwing away
all the types inserted after that ctf_update(). This will leave some redundant
types around (those inserted before the ctf_update()), but now they are
ctf_update()d there's no way we can get rid of them: this is only an error case
anyway.
The net effect of this is a radical speedup of dwarf2ctf: in my testing my draft
UEK4 merge tree sees this speedup:
user 563 / sys 173 / elapsed 10:09
->
user 272 / sys 10 / elapsed 4:56
We update the documentation at the same time.
This does change the set of dependent types, but only from one buggy set to
another (a fix to that bug is next on the agenda: the bug only affects a
limited subset of modules, which is why nobody has ever noticed it before).
Nick Alcock [Fri, 9 Jan 2015 19:16:43 +0000 (19:16 +0000)]
ctf: move the module->ctf_file info into a structure.
Rather than tracking the underlying ctf_file info in a module_to_ctf_file hash
mapping module name to the CTF file directly, introduce a structure to hold the
CTF file info in.
This has absolutely no effect on the output (nor even on the in-memory data
structures, since a structure with one member looks identical to the member on
its own) but is necessary for later commits that add further per-module state.
Nick Alcock [Mon, 15 Dec 2014 19:08:01 +0000 (19:08 +0000)]
ctf: duplicate-detect dependent types properly
dwarf2ctf's duplicate-detection machinery takes care to spot and mark members of
structures reliably, but does not take quite the same care with dependent types.
Code such as that in drivers/net/wireless/brcm80211/brcmsmac/phy_shim.c:
The pointer is marked as seen, since it is at the top level, but the
structure_type, because it is inside a subroutine_type, does not. Type emission
then recurses through dependent types and crashes horribly.
The fix is to recurse through dependent types (via a type_id() callback) when
marking things as seen.
Unfortunately this slows down dwarf2ctf quite a lot: speedups are next on the
agenda.
Nick Alcock [Mon, 15 Dec 2014 14:27:12 +0000 (14:27 +0000)]
Remove BUILD_BUG_ON for epitem size code to compile.
The changes to the epitem struct to support waitfd() / poll_wait_fixed()
cause it to be larger than the limit enforced by the BUILD_BUG_ON. The
dropping of this build assertion is in line with the suggestion by Andrew
Morton in https://lkml.org/lkml/2013/3/8/467.
Nick Alcock [Fri, 12 Dec 2014 18:45:37 +0000 (18:45 +0000)]
ctf: Prohibit a bunch of debug info options we don't support.
CONFIG_DEBUG_INFO_DWARF4 and CONFIG_DEBUG_INFO_SPLIT will require significant
changes to dwarf2ctf, but will eventually be supported.
CONFIG_DEBUG_INFO_REDUCED fundamentally breaks the type deduplicator and will
never be supported.
Unfortunately this forces us to change the DEBUG_INFO select to a depends,
so you have to remember to turn CONFIG_DEBUG_INFO on or half of dtrace won't
work.
Kris Van Hees [Mon, 22 Dec 2014 21:56:13 +0000 (16:56 -0500)]
dtrace: add support for sparc64 3of3
This commit is the 3rd of 3 commits to add DTrace support to the sparc64
kernel. This particular commit covers the DTrace implementation code
changes. It provides an implementation of the DTrace core for sparc64,
SDT, and syscall tracing.
Note that the sparc64 implementation for SDT probe points utilizes a call
to a trampoline function that in turn calls dtrace_probe() rather than
using a trap-based mechanism. This requires an additional data item to be
associated with each module. In order to facilitate this in a manner that
is arch-dependent, DTrace specific data other than the list of SDT probes
has been moved to a structure that is maintained by the DTrace module code
and the module struct merely has a generic void *pdata member that can be
populated with a pointer to the actual data. This commit renames the
num_dtrace_probes member of the module struct to be sdt_probec, since that
is more consistent.
Kris Van Hees [Mon, 22 Dec 2014 21:56:13 +0000 (16:56 -0500)]
dtrace: add support for sparc64 2of3
This commit is the 2nd of 3 commits to add DTrace support to the sparc64
kernel. This particular commit covers the generic kernel code changes.
The sparc64 implementation for SDT probe points utilizes a call to a
trampoline function that in turn calls dtrace_probe() rather than using
a trap-based mechanism. This requires an additional data item to be
associated with each module. In order to facilitate this in a manner that
is arch-dependent, DTrace specific data other than the list of SDT probes
has been moved to a structure that is maintained by the DTrace module code
and the module struct merely has a generic void *pdata member that can be
populated with a pointer to the actual data.
This commit also renames the num_dtrace_probes member of the module struct
to be sdt_probec, since that is more consistent.
Kris Van Hees [Mon, 22 Dec 2014 21:56:13 +0000 (16:56 -0500)]
dtrace: add support for sparc64 1of3
This commit is the 1st of 3 commits to add DTrace support to the sparc64
kernel. This particular commit covers the sparc64-specific kernel code
changes.
- Set ARCH_SUPPORTS_DTRACE for SPARC64.
- Add DIE_PAGE_FAULT to be used in the (new) notifier call in the
do_kernel_fault() function to allow DTrace to report failed memory
accesses from probe recipes as an error rather than causing a kernel
OOPS.
- Add support for the dtrace_no_pf() functionality to ignore page faults
on request when trying to access userspace.
Kris Van Hees [Mon, 22 Dec 2014 21:54:49 +0000 (16:54 -0500)]
dtrace: restructuring for multi-arch support
1) The cpu_info member of the cpu_core structure is now architecture
dependent through the use of type cpuinfo_arch_t. Architectures must
provide a typedef for this type in asm/dtrace_cpuinfo.h.
2) Wherever an instruction address is used, the type is now sdt_instr_t,
which architectures must define in asm/dtrace_sdt.h.
3) System calls that use an assembly language stub must be defined by
architectures in asm/dtrace_syscall.h using the following syntax:
DTRACE_SYSCALL_STUB(all-caps-name, name)
E.g.
DTRACE_SYSCALL_STUB(CLONE, clone)
4) The x86 architecture uses an InvalidOpcode TRAP as probe firing
mechanism for SDT. This is machinery that is entirely architecture
specific (not just in imolementation) and the function prototypes for
those functions have been moved to asm/dtrace_util.h. The actual SDT
implementation (which aside from the core framework is always going
to be architecture specific) has been moved into the x86 specific
part of the kernel tree. The core framework has been split off into
is own dtrace_sdt_core.c.
5) The system call tracing implementation (and assembly language stubs)
are very architecture specific and have been moved into the x86
specific part of the kernel tree. The sys_call_ptr_t type has been
discontinued because dt_sys_call_t serves the same purpose already.
The syscall tracing specific part of dtrace_os.h has been split out
into its own dtrace_syscall.h.
6) Aside from any architecture-specific support functions (that are not
accessed from arch-independent code), an arch-specific dtrace_util.c
must also implement the following functions:
Adjust the CPU registers such that upon restoring of the
register set, execution commences with the instruction
AFTER the one currently referenced.
int dtrace_die_notifier(struct notifier_block *nb,
unsigned long val, void *args)
Handle faults that could cause a panic in cases of
invalid memory accesses, and very whether DTrace has
requested that they be rendered non-fatal. This may
also be used for other arch-specific things like the
InvalidOpcode TRAP on x86.
7) Since the linux/percpu.h include file occurs in different include
chains dependent on the architecture, linux/dtrace_cpu_defines.h now
includes it explicitly (as it should have done from the beginning)
because it does depend on per_cpu() and friends.
8) The use of uprobes structures in linux/dtrace_os.h was conditional on
a specific architecture (x86_64). This has been changed to now be
conditional on whether the fasttrap provider is being built. Fasttrap
itself depends on uprobes through the kconfig mechanism.
9) The DTrace facility has been a bool option in Kconfig for a while now,
although some code still refers to the possibilty CONFIG_DTRACE_MODULE
may be defined. That has been changed to always check CONFIG_DTRACE.
10) Some architectures truly need strnlen_user() to be used when there
are userspace addresses involved.
11) While on x86 we were using the dump stack facility to get stacktrace
information, this is not available on other architectures. We're now
using the save_stack_trace(). Sadly, just for x86 we need to adjust
the stack depth value by -1 because the x86 implementation adds a
totally unnecessary sentinel value to the end of the stacktrace (and
includes it in the nr_entries count).
Kris Van Hees [Mon, 22 Dec 2014 21:54:49 +0000 (16:54 -0500)]
dtrace: set ARCH_SUPPORTS_DTRACE for x86_64
Architectures should define ARCH_SUPPORTS_DTRACE if there is an
implementation of DTrace in the kernel for that arch. Provide that
config option for x86_64 (currently the only implementation).
Jamie Iles [Wed, 5 Nov 2014 12:23:59 +0000 (12:23 +0000)]
dwarf2ctf: don't use O_PATH in rel_abs_file_name().
O_PATH was introduced in v2.6.39, but fchdir() on an O_PATH opened
handle came in v3.5. When building UEK3 on a system with a kernel <
v3.5 dwarf2ctf failed with:
CTF Cannot return to original directory after relative realpath(): Bad
file descriptor
Open the directory as a normal file descriptor which is a bit uglier but
allows building on systems with older kernels.
Jamie Iles [Tue, 4 Nov 2014 13:07:58 +0000 (13:07 +0000)]
dwarf2ctf: don't leak directory fd.
We open a descriptor to the current directory in rel_abs_file_name() but
don't close it whilst we're done with resolving the path. Plug the file
descriptor leak once we have returned to that directory.
Nick Alcock [Tue, 30 Sep 2014 14:02:46 +0000 (15:02 +0100)]
ctf: handle srcdir-relative paths properly.
The dwarf2ctf tool maintains various blacklists to get around things some
modules do which are incompatible with large-scale deduplication of types or
with having one type table per module. These blacklists are in the source tree,
and unfortunately we were looking for them using a relative path, which equates
to the objdir when O= or KBUILD_OUTPUT are in use: so we got assertion failures
from dwarf2ctf and a kernel build failure when it detected that something was
wrong with its duplicate-type detection.
Worse yet, one of these blacklists, member.blacklist, contains the names of
source files. These paths relate to entities in the source tree, but they are
compared to source-file paths in object files generated by the compiler (which
are in theory objdir-relative, but which are in any case always absolute iff
KBUILD_OUTPUT is in use). If these comparisons are to be successful, we must
absolutize the relative paths in the member.blacklist against the source tree,
not against the object tree.
We don't need to extend the realpath()-result-caching infrastructure to handle
this case, because we're only absolutizing *one path* this way, and at most
it'll be a few dozen. The caching infrastructure exists to handle cases where
millions or billions of realpath()s are done. We just need to chdir() to the
source tree, realpath(), and fchdir() back. (We use the O_PATH open() flag to
do this if possible, but older glibcs such as that on OL6 do not provide O_PATH,
and it has an architecture-dependent so we cannot provide it ourselves: in that
case we fall back to O_RDONLY | O_DIRECTORY, which should always work since the
objdir really should always be readable by the current user.)
Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Tested-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Guangyu Sun <guangyu.sun@oracle.com> Acked-by: Guru Anbalagane <Guru.Anbalagane@oracle.com>
Nick Alcock [Fri, 27 Jun 2014 14:11:21 +0000 (15:11 +0100)]
kbuild/ctf: Fix out-of-tree module build when CONFIG_CTF=n.
When doing an out-of-tree build against a kernel with CONFIG_CTF=n (such as
debug kernels), linking fails because the list of object files in the
command-line given to the linker is empty.
The object files are substituted by this line in Makefile.modpost:
$(patsubst $(ctf-dir)/%,,$(filter-out FORCE,$^))
which takes the list of prerequisites for the module (which includes all its CTF
type information as well as its object files and a FORCE dummy target) and
filters out the FORCE target and all the CTF prerequisites (they are not linked
at this stage, but objcopied in immediately afterward). This works because all
the CTF files are generated under the $(ctf-dir) directory, and nothing else is
kept under there.
Unfortunately $(ctf-dir) is left empty if CONFIG_CTF=n. This is unproblematic
in normal kernel builds because all paths are relative, but if an out-of-tree
module build is being performed this strips everything out of the link line,
since out-of-tree builds usually specify all object files using absolute
pathnames, which naturally begin with a slash, and when $(ctf-dir) is empty so
does the patsubst pattern.
The solution is to provide a non-empty expansion of ctf-dir when CONFIG_CTF=n:
any value that can't appear at the start of object file names will do.
Kris Van Hees [Wed, 18 Jun 2014 12:35:58 +0000 (08:35 -0400)]
dtrace: support order-only-prerequisites for sdtstub generation
This commit ensures that order-only-prerequisites are supported in the
module build process when it comes to the generation of the sdtstub file
for SDT probes in modules. This is necessary even when there are no
probes in the actual module source code.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com> Acked-by: Chuck Anderson <chuck.anderson@oracle.com> Signed-off-by: Guangyu Sun <guangyu.sun@oracle.com>
Kris Van Hees [Thu, 15 May 2014 21:40:12 +0000 (17:40 -0400)]
dtrace: ensure that building outside src tree works
The Makefile.build and Makefile.modpost uses of dtrace_sdt.sh were
not safe for out-of-srctree building because they expected to be
able to call the scripts with a relative path. This has been
corrected. The problem was introduced with the SDT-in-modules
support.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com> Acked-by: Chuck Anderson <chuck.anderson@oracle.com> Acked-by: Jerry Snitselaar <jerry.snitselaar@oracle.com>
dtrace: ensure one can try to get user pages without locking or faulting
This commit changes the FOLL_NOFAULT flag into a FOLL_IMMED flag, to
more accurately convey its meaning, i.e. to request user pages without
waiting for any locks and without servicing any page faults as a result
of the request. This is necessary in order to request user pages from
interrupt context.
This also completes the implementation by ensuring that the PTE spinlock
is checked rather than trying to lock it (and possibly get stuck in a
deadlock spinning for it).
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com> Reviewed-by: Chuck Anderson <chuck.anderson@oracle.com> Reviewed-by: Jerry Snitselaar <jerry.snitselaar@oracle.com>
Nick Alcock [Mon, 31 Mar 2014 14:23:39 +0000 (15:23 +0100)]
mm / dtrace: Allow DTrace to entirely disable page faults.
In some very limited circumstances (largely restricted to get_user() calls, but
not entirely) DTrace needs to be able to probe userspace in irq and trap
context, in which page faults are prohibited or otherwise impossible because we
cannot guarantee that certain locks (like the mmap_sem) are not already taken by
the time DTrace is invoked.
In a similar fashion to the existing CPU_DTRACE_NOFAULT machinery, which allows
DTrace to prohibit invalid address faults, we introduce a CPU_DTRACE_NOPF value
in the per-CPU DTrace flag variable, which, when set by the DTrace module,
causes all page faults to set CPU_DTRACE_PF_TRAPPED in the flag variable: the
page fault is then ignored (and the current instruction skipped so that it is
not immediately retriggered).
Clearly, ignoring page faults in random pieces of kernel code would be very
risky: this machinery is only used in situations such as get_user() in which the
kernel code does nothing with the page other than to extract data from it and
pass it back to the DTrace module.
The impact on the core x86 fault path when CONFIG_DTRACE is set is one
unlikely() conditional and one function call: when CONFIG_DTRACE is not on the
impact is zero. (Eliminating the function call and directly testing the DTrace
per-CPU flag is possible as a future optimization, but was considered too
invasive for now.)
Orabug: 18412802 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Kris Van Hees <kris.van.hees@oracle.com> Reviewed-by: Chuck Anderson <chuck.anderson@oracle.com>
Conflicts:
arch/x86/mm/fault.c
Nick Alcock [Mon, 31 Mar 2014 14:22:56 +0000 (15:22 +0100)]
mm: allow __get_user_pages() callers to avoid triggering page faults.
Some callers of __get_userpages() would like to tentatively probe for
pages which may or may not be faulted in, in contexts in which faulting
is prohibited. __get_user_pages() can return early before the fault is
complete, but cannot avoid the fault entirely.
This change introduces FOLL_NOFAULT, which causes an early return if a
fault would occur, without triggering a fault, and indicating (if the
caller requests it) that the call would block.
Orabug: 18412802 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Kris Van Hees <kris.van.hees@oracle.com> Reviewed-by: Chuck Anderson <chuck.anderson@oracle.com>
Kris Van Hees [Fri, 14 Mar 2014 15:37:43 +0000 (11:37 -0400)]
dtrace: implement omni-present cyclics
This commit adds support for omni-present cyclics. An omni-present
cyclic is one that fires on every CPU on the system, each at the same
frequency/interval. They are implemented based on regular cyclics,
pinned to specific CPUs. The implementation is such that hotplugging
CPUs is supported, i.e. when new CPUs come online, cyclics are started
on them for every omni-present cyclic that is currently active, and
when a CPU goes offline, the cyclics associated with that CPU (at least
those that are part of an omni-present cyclic) are removed.
Kris Van Hees [Thu, 27 Feb 2014 14:40:13 +0000 (09:40 -0500)]
dtrace: avoid unreliable entries in stack() output
The original implementation of the stacktrace walker for DTrace often reported
unreliable (i.e. non-callframe) entries in the stack() output. This was most
often seen as a result of datastructures allocated on the stack in functions.
This new implementation isn't plagued by that issue anymore. It uses knowledge
of the basepointer (bp) to link callframes.
The psinfo objects created from a kmem cache (slab) to hold information
about a task's environment and arguments can leak when a task executes
two consecutive execve() calls. The implementation also made it possible
for tasks to have no psinfo (NULL) after a fork() unless an execve() was
done shortly after. This commit resolved both problems by adding a refc
to the psinfo objects (so one can be shared across task parentage
relations due to fork()), and by ensuring that upon execve() any existing
psinfo gets its refc decremented and a new psinfo object gets installed
to reflect the new execution environment.
This commit also adds the necessary initialization of a psinfo object for
tasks that do not have a mm object associated with them.
Nick Alcock [Thu, 23 Jan 2014 23:23:00 +0000 (23:23 +0000)]
ctf: spot non-struct/union/enum children of DW_TAG_structure_type
One of the jobs of the dwarf2ctf duplicate detector is to trace the members of
structures and unions in every kernel module, one by one, and recursively mark
the types of every such member as used in that module; any such types used in
more than one module are promoted to the shared type repository (and marked as
used in that in the same way). In conjunction with a variety of other rules,
this ensures that types in per-module type repositories can refer to types in
the shared type repository, but that the shared repository is self-contained:
DTrace userspace can then load any module's type repository, set its parent to
be the shared type repository, and be sure that it can fully characterize any
type in that module.
dwarf2ctf was aborting because a type was missed by the duplicate detector but
then emitted by the type generation phase. The type in question is found in
drivers/message/i2o/i2o_proc.c:
As the indentation makes clear, in GCC 4.4.x the array_type is at the top level,
where it is always spotted by the duplicate detector as a matter of course. In
fact, in GCC 4.4.x *no* types other than aggregates are ever emitted as children
of structure_types: they're all at the top level and thus trivially detected by
the walk through top-level types that the duplicate detector does as a matter of
course: so this part of the scanning phase only needs to look at the types of
structures, unions and enumerations, to handle perverse cases like
struct foo {
struct {
int womble;
} *baz;
};
in which the innermost struct's DIE (but *not* the pointer to it) is represented
as a child of the outer one's, even in GCC 4.4.x.
In GCC 4.8.x this is no longer true: the array_type DIE above is emitted as a
direct child of the structure_type here shown as [ beca], and indeed you can see
all sorts of types as children of structure_types, even basic types like 'int'
if they happen not to be used anywhere else in the translation unit. So we must
mark them all as seen.
-- or almost all. We do not bother marking types we will not later emit CTF
for, and we do not mark structure or union members themselves, because structure
members are not types and cannot be referenced by another member. (Since
members are very numerous and cannot be duplicated across kernel modules unless
their containing structure is also duplicated, not marking them as seen also
saves a great deal of memory.)
Thankfully the emission phase does not care what the parent of DIEs is except if
they are things like structures or unions which have parents in CTF too. So
arrays, basic types, and the like inside structure_type DIEs do not disturb the
actual emission of types: once we have fixed the duplicate detector, all is
well.
Orabug: 18117464 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Chuck Anderson <chuck.anderson@oracle.com>
Nick Alcock [Thu, 23 Jan 2014 23:22:21 +0000 (23:22 +0000)]
ctf: capture all DIEs with structs/enums as their ultimate supertype
dwarf2ctf has to scan all the DWARF in the kernel repeatedly while generating
its compressed type representation: it even has to scan inside functions, even
though it is only interested in file-scope types and variables, because opaque
structure, union, or enumeration references at the top level can contain
references to a definition inside a function. Repeated scanning of gigabytes of
DWARF is slow: dwarf2ctf spends most of its time doing this, not emitting types.
To make this less abominably slow, dwarf2ctf contains a filtration mechanism to
avoid scanning or emitting DIEs which will never be useful.
An iron rule of dwarf2ctf is that *all* DIEs that are emitted as types must
first be spotted by this 'duplicate detector' scanning phase, since it not only
determines which types are duplicated but also where they should go: whether
they are shared between kernel modules (and should go into the shared type
repository in ctf.ko) or are shared between translation units in a single module
or not duplicated at all, in which case they go into the module's local CTF. So
if the filtration mechanism skips types which are later emitted, dwarf2ctf can
do little but abort (in general dwarf2ctf aborts if it finds internal
consistency problems which may affect the generation of many types, but skips
types and warns if it finds problems with single types which are not likely to
affect the generation of other types).
One of these filtration functions is filter_ctf_file_scope(). This is called to
filter out DIEs representing most qualifiers and base types when they appear
inside functions, by simply checking if the parent of the DIE is
DW_TAG_compile_unit. In GCC 4.4.x, applying this to a variety of DIEs was
sufficient to filter out all DIEs inside functions that we weren't going to emit
CTF representations of.
Unfortunately GCC has since changed its debugging information representation
somewhat in a fashion which breaks this. Inside drivers/firmware/dmi-id.c we
see the example dwarf2ctf calls out when it fails:
This is a structure inside a function, but even so GCC generates some of its
type DIEs at global scope and they are emitted into the CTF. Over time, GCC is
moving more of the DIEs into subprogram scope, but not yet all of them: this is
what has broken us.
The variable 'f' is represented by the following DIEs, where A, B, C and D are
DIE offsets:
[ A] structure_type
name (strp) "mafield"
[...]
[ B] const_type
type (ref4) [ A]
[ C] pointer_type
byte_size (data1) 8
type (ref4) [ B]
In GCC 4.4.x, all of these other than the structure_type itself are at the
global scope, not the subprogram scope, so the filter never kicks in for these
DIEs and all of them are emitted successfully. Between 4.4.x and 4.8.0, the
'const_type' moved into subprogram scope, but the pointer_type did not, so we
have a pointer_type at global scope referring to a const_type at subprogram
scope -- which has been filtered out by the filtration function, so emission of
the pointer_type fails and dwarf2ctf aborts because its type graph is
incomplete, with a type pointing at a type it has no record of.
Fix this by having filter_ctf_file_scope() look at the DW_AT_type attribute of
its target DIE, chaining to its type-attributeless terminus and note whether
that terminus is a structure, union, or enumeration: all DIEs having such types
at the terminus of their type chains must not be filtered out.
Orabug: 18117464 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Chuck Anderson <chuck.anderson@oracle.com>
Nick Alcock [Thu, 23 Jan 2014 23:21:24 +0000 (23:21 +0000)]
ctf: handle structure and union offsets in form DW_FORM_data1
GCC 4.8.0 and above have started to represent structure member offsets in the
DW_AT_data_member_location attribute using DWARF forms DW_FORM_data1 and _data2
where possible: indeed, this is the common case, as most structure members are
less than 64K into the structure: and every structure contains at least one
member whose offset is represented this way.
dwarf2ctf neglected to check for DW_FORM_data1, so the build failed when it hit
the first structure in the kernel and realised that it didn't understand its
offset.
Fix trivial.
Orabug: 18117464 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Chuck Anderson <chuck.anderson@oracle.com>
Nick Alcock [Thu, 23 Jan 2014 23:20:22 +0000 (23:20 +0000)]
ctf: cater for elfutils 0.156 change in dwfl_report_elf() prototype
This version of elfutils breaks source compatibility, adding a new parameter to
dwfl_report_elf(). Compensate for this in a manner that does not break
compilation with older elfutils.
Orabug: 18117421 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Jerry Snitselaar <jerry.snitselaar@oracle.com>
Kris Van Hees [Tue, 17 Dec 2013 23:08:17 +0000 (18:08 -0500)]
dtrace: vtimestamp implementation
This commit adds DTrace vtimestamp support. It keeps track of how much
time a task has spent actually processing on a CPU. The time is set to
zero at task creation, and is updated whenever the task leaves a CPU
(gets scheduled off), and when the dtrace_probe() function is entered,
to enusre that the most recent value of consumed time is reported.
Some code got moved around for consistency of the implementation.
Kris Van Hees [Tue, 17 Dec 2013 23:06:57 +0000 (18:06 -0500)]
dtrace: implement SDT in kernel modules
Full implementation of SDT probes in kernel modules.
The dtrace_sdt.sh script has been modified to handle both the creation
of the SDT stubs and the SDT info. It's syntax has therefore changed:
dtrace_sdt.sh sdtstub <stubfile> <object-file> <object-file>*
or
dtrace_sdt.sh sdtinfo <infofile> vmlinux.o
or
dtrace_sdt.sh sdtinfo <infofile> vmlinux.o .tmp_vmlinux1
or
dtrace_sdt.sh sdtinfo <infofile> <kmod>.o kmod
The first form generates a stub file in assembler to ensure that the
(fake) functions that are called from SDT probe points will not longer
be reported as undefined symbols, and to ensure that when SDT is not
enabled, the probes become calls to a function that simply returns.
The second form creates the initial (dummy) SDT info file for the kernel
linking process, mainly to ensure that its size is known. The third
form then creates the true SDT info file for the kernel, based on the
kernel object file and the first stage linked kernel image.
The fourth and final form generates SDT info for a kernel module, based
on its initial linked object.
This commit also enables the test probes in the dt_test module.
Kris Van Hees [Tue, 22 Oct 2013 09:24:09 +0000 (05:24 -0400)]
dtrace: remove functionality of dtrace_os_exit() as deprecated
This function is in its current form no longer called from anywhere, but since
it is exported someone could (maliciously) still call it and cause a mess. We
therefore issue a warning and do not do anything else. This will be removed in
a future version.
Kris Van Hees [Tue, 22 Oct 2013 09:19:25 +0000 (05:19 -0400)]
dtrace: new cyclic implementation
The original cyclic implementation (based on hrtimer_*()) failed
because it caused handlers to be called from interrupt context, which
causes quite some interesting (bad) side effects.
The change to tasklet_hrtimer_*() as underlying implementation solved
the context issues for handlers, but resulted in runaway timers that
could call handlers in modules that are no longer loaded, causing a
crash. Cause was related to a race between timer cancellation and the
tasklet restarting the timer.
The new implementation is a two layer approach where hrtimer_*() is
used to generate handler invocations requests, scheduling a tasklet for
handler call processing as needed, and using a counter to determine how
many times the handler needs to be called (if the timer fires more than
once between two subsequent tasklet processing schedulings). The
tasklet (one per cyclic - only scheduled when there has been one or
moretimer expirations) takes care of calling the handler.
More details are embedded in comments in the code...
Allocate the psinfo structure from a slab (alike other structures related to
the task_struct), and use kmalloc() for the argv and envp members (with size
limit to avoid allocation issues).
Orabug: 17407069 Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Nick Alcock [Fri, 13 Sep 2013 15:13:13 +0000 (16:13 +0100)]
kbuild/ctf: Use shell expansion, not $(wildcard ...), for CTF section copying.
The stub module kernel/ctf/ctf.ko must contain sections for all CTF for the core
kernel, CTF shared between modules and CTF for every built-in module. This set
can vary as the kernel configuration changes: it is computed by dwarf2ctf from
objects.builtin, modules.builtin, and analysis of the debugging information in
the object files comprising the kernel build.
This means that we must dynamically construct the command line for the objcopy
which inserts these sections into the final .ko, as it is not known until
recipes are executed. This is done via the module-ctf-flags variable, which is
expanded into cmd_ld_ko_o. We chose to use the GNU Make wildcard function to
determine the set of builtin modules, but this has turned out to be problematic,
because, though it is nowhere documented, the output of this function is often
cached if the directory exists. glob lookups will rescan it as needed, but
$(wildcard) seemingly does not, and can often produce inaccurate or even empty
lists even when many files matching the wildcard have existed for some time.
This shows up as (often parallel) makes failing to insert any CTF sections into
kernel/ctf/ctf.ko, with DTrace subsequently failing because the CTF for the core
kernel and inter-module shared types was missing.
For now, work around this bug by using shell expansion instead. (This
particular part of the module-ctf-flags is only expanded once, for one module,
and only after a period of computation by dwarf2ctf lasting many minutes, so no
negative impact on build times from this shell loop is expected.)
Orabug: 17445637 Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Jamie Iles [Fri, 16 Aug 2013 16:02:25 +0000 (17:02 +0100)]
kbuild/ctf: always build vmlinux when building CTF.
Before now, a 'make modules' in a clean tree would neglect to build the built-in
objects and yield an empty objects.builtin, or no objects.builtin at all.
Correct generation of the CTF requires all the .o and .a files which go into
vmlinux, and a list of them in objects.builtin: without them, dwarf2ctf will
fail one way or the other.
While we're at it, remove all CTF-related references in the build system to
CONFIG_DTRACE and CONFIG_DT_DISABLE_CTF: CTF generation has been decoupled from
DTrace and has its own config symbol nowadays.
Orabug: 17397200 Signed-off-by: Jamie Iles <jamie.iles@oracle.com> Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Kris Van Hees [Thu, 29 Aug 2013 22:07:21 +0000 (18:07 -0400)]
dtrace: Ensure that USDT probes are carried over correctly across fork().
When a process forks, its child will have a copy of the address space of the
parent, and therefore any enabled USDT probes from the parent will also fire
for the child. In order for those probe firings to be valid, the child must
have its own pid-specific providers (created by duplicating the parent's
providers).
Kris Van Hees [Tue, 27 Aug 2013 19:49:50 +0000 (15:49 -0400)]
dtrace: fix retrieval of arg5 through arg9
Fix the retrieval of arguments passed on the stack for SDT, USDT, and direct
call probes. This commit also adds trivial support for testcases related to
this fix.
Kris Van Hees [Mon, 19 Aug 2013 18:07:13 +0000 (14:07 -0400)]
dtrace: Ensure that task_struct members are initialized correctly
Due to an initialization issue with current->predcache, it was possible for the
predicate on a probe to never be evaluated because the dtrace_probe() code was
incorrectly assuming that there was a valid predicate cache result.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Nick Alcock [Thu, 29 Aug 2013 14:15:35 +0000 (15:15 +0100)]
ctf: avoid command-line length limits by passing .o filenames via a file
Historically, dwarf2ctf took the names of all object files it was to run over on
the command line. This can lead to very long command lines, but since the kernel
now supports lines of almost unlimited length (up to RLIMIT_STACK / 4, which is
much longer than the names of all .c files in the kernel tree added together for
any reasonable stack size), this seemed safe.
It turns out not to be, because GNU Make sometimes passes command lines through
the shell even when it doesn't need to, and GNU Bash does not yet know that the
kernel has a very long command-line length limit and protests if it is
> ARG_MAX, which is much shorter. We were trying to prevent the dwarf2ctf
command line being passed to the shell, but there is no documented way to do so
in GNU Make and clearly simply avoiding shell metacharacters is not always
enough.
So, instead, write out the list of object files to a file in the .ctf directory
and have dwarf2ctf read it in. This takes some trickery in Makefile.modpost to
arrange to invoke a separate shell to add each filename to the filelist, but
it's not too complicated. (To minimize the possibility of disruption, we
duplicate the code already used for reading blacklists in dwarf2ctf. This
should be unified later.)
Orabug: 17363469 Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Kris Van Hees [Wed, 14 Aug 2013 21:58:03 +0000 (17:58 -0400)]
dtrace: Fix for the argument validation code.
The command line argument validation code failed to correctly identify some of
the potential failure cases, and sadly, also one specific valid use case. This
has been corrected.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Orabug: 17313687
Signed-off-by: Jerry Snitselaar <jerry.snitselaar@oracle.com>
Kris Van Hees [Wed, 14 Aug 2013 12:44:01 +0000 (08:44 -0400)]
dtrace: Bug fix for logic to determine the (inode, offset) pair for uprobes.
The logic used to determine the (inode, offset) pair needed by uprobes, and
caculated based on an address in a process memory space. was flawed. This
caused USDT probes in shared libraries to not work correctly.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Nick Alcock [Mon, 29 Jul 2013 14:36:54 +0000 (15:36 +0100)]
dtrace: CONFIG_DTRACE should depend on CONFIG_UPROBES
Since DTrace uses uprobes, it needs to select it, or we end up with most of
uprobes not being compiled in. In this situation, you can still *try* to
register a uprobe, but it will always fail.
Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Nick Alcock [Mon, 22 Jul 2013 18:16:07 +0000 (19:16 +0100)]
wait: fix loss of error code from waitid() when info is provided
One of the review comments on the original waitid patches suggested using the
pattern
ret = __put_user(...);
ret |= __put_user(...);
...
rather than
if (!ret)
ret = __put_user(...);
if (!ret)
ret |= __put_user(...);
This turns out to be a bad idea if ret is used for anything else first, e.g. if
it is used to store errnos from waitid(), since it overwrites any nonzero error
with the return value of __put_user(), even if that is zero.
The solution is to use a temporary error variable instead, and not assign it to
the actual return value if the temporary error variable is still zero after
doing all the __put_user()s (as is the common case).
Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Nick Alcock [Tue, 18 Jun 2013 19:03:08 +0000 (20:03 +0100)]
epoll, wait: introduce poll_wait_fixed(), and use it in waitfds
The poll() machinery expects to be used with files, or things enough like files
that the wake_up key contains an indication as to whether this wakeup
corresponds to a POLLIN / POLLOUT / POLLERR event on this fd. You can override
this in your poll_queue_proc, but the poll() and epoll() queue procs both have
this interpretation.
Unfortunately, it is not true for waitfds, wihch wait on the the wait_chldexit
waitqueue, whose key is a pointer to the task_struct of the task being killed.
We can't do anything with this key, but we certainly don't want the poll
machinery treating it as a bitmask and checking it against poll events!
So we introduce a new poll_wait() analogue, poll_wait_fixed(). This is used for
poll_wait() calls which know they must wait on waitqueues whose keys are not
a typecast representation of poll events, and passes in an extra argument to
the poll_queue_proc, which if nonzero is the event which a wakeup on this
waitqueue should be considered as equivalent to. The poll_queue_proc can then
skip adding entirely if that fixed event is not included in the set to be
caught by this poll().
We also add a new poll_table_entry.fixed_key. The poll_queue_proc can record
the fixed key it is passed in here, and reuse it at wakeup time to track that
a nonzero fixed key was passed in to poll_wait_fixed() and that the key should
be ignored in preference to fixed_key.
With this in place, you can say, e.g. (as waitfd now does)
and the key passed to wakeups on the wait_chldexit waitqueue will be ignored:
the fd will always be treated as having raised POLLIN, waking up poll()s and
epoll()s that have specified that event. (Obviously, a poll function that
calls this should return the same value from the poll function as was passed
to poll_wait_fixed(), or, as usual, zero if this was a spurious wakeup.)
Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Nick Alcock [Thu, 6 Jun 2013 16:56:18 +0000 (17:56 +0100)]
ctf: no longer reference 'ctf.ko.unsigned' in CTF debuginfo stripping machinery
We used to generate .ko.unsigned modules, which were renamed to .ko after
signing: so when stripping the debugging information out of ctf.ko, we had to
consider the possibility that we might have to strip it out of ctf.ko.unsigned
instead. With the new signing machinery, this is no longer the case, and that
hack can be removed.
Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Nick Alcock [Tue, 4 Jun 2013 15:52:46 +0000 (16:52 +0100)]
wait: add waitfd(), and a testcase for it
This syscall, of prototype
int waitfd(int which, pid_t upid, int options, int flags);
yields a pollable file descriptor which yields a 'struct siginfo_t' whenever
waitid() or waitpid() would return (when child processes die or ptrace()d
tracees undergo an appropriate state change).
The which, upid and options arguments are as to waitid(); the flags argument is
fd flags as to open() or fcntl(F_SETFL), to which O_RDWR is automatically added.
WNOHANG in the options is automatically translated into O_NONBLOCK in the flags,
and vice versa.
No compat wrappers are in place for this syscall: 32-bit calls with a 64-bit
kernel will return a 64-bit version of 'struct siginfo'.
Current bugs:
- select/poll/epoll is not waking up the process yet, even when it should.
Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Kris Van Hees [Fri, 31 May 2013 06:48:37 +0000 (02:48 -0400)]
dtrace: ensure that arg6 through arg9 get retrieved correctly for USDT probes
A bug in the implementation of retrieving arguments from the stack caused
bogus values to be returned for arg6 through arg9 on x86_64. This has been
resolved.
This commit also removes various debugging output that is no longer needed.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Kris Van Hees [Thu, 23 May 2013 14:52:00 +0000 (10:52 -0400)]
dtrace: finish the implementation of is-enabled USDT probes
This commit completes the implementation of is-enabled USDT probes, i.e. probes
that when fired cause an execution flow change. This makes it possible (when
using USDT) to encode more complex code sections that are only executed if a
specific USDT probe has been enabled, i.e. when a consumer is listening for
s specific USDT probe. This is most commonly used for cases where a USDT probe
might require additional computation for one or more of its arguments, and so
it would be too expensive to always do that computation, whether the probe is
enabled or not. With is-enabled probes, the overhead when DTrace is not used
is negligible (2 NOPs), and when DTrace is in use but the guarded probe is not
enabled, the cost is a single probe firing (without calling dtrace_probe()).
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Kris Van Hees [Wed, 22 May 2013 23:25:48 +0000 (19:25 -0400)]
dtrace: fixes for tracepoint cleanup
Various fixes to handle tracepoint cleanup. It is important to note that it is
most common that USDT providers will be cleaned up (asynchronously) when the
process/task they relate to is already gone. We therefore cannot use a (pid,
addr) pair to identify the tracepoint for removal. The new implementation
stores the (inode, offset) pair calculated right before registering the uprobe,
so that we can use that same pair again when unregistering.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Kris Van Hees [Tue, 21 May 2013 06:48:39 +0000 (02:48 -0400)]
dtrace: update syscall tracing in view of Linux 3.8 changes
The handling of various stub-based syscalls in Linux 3.8 changed to no longer
use the saved registers directly. This change is now also reflected in the
DTrace overrides for those system calls.
Also reset the compilatio debug settings to all-off (they should only be
turned on in local compilations - never in the repo.)
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Kris Van Hees [Mon, 20 May 2013 20:37:33 +0000 (16:37 -0400)]
dtrace: USDT implementation (phase 2)
This commit contains the 2nd phase of the USDT implementation for DTrace for
Linux. It provides the mechanics of fasttrap probes (enabling, firing, and
disabling). It also contains various debugging statements that will be cleaned
up in a future commit. They exist right now, because this commit represents a
work in progress that is known to contain various bugs and loose ends. The
commit for this code is provided as a "sharing of the pain" , and to ensure
that others can start playing with this code and test the interaction with
userspace.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Nick Alcock [Mon, 29 Apr 2013 12:57:15 +0000 (13:57 +0100)]
dtrace: revamp and split up DTrace headers; add ioctl() debugging machinery
It has always been annoying that we have a duplicate set of DTrace headers
in userspace, and further annoying that the DTrace header we have is such a
monolithic monster.
This fixes both of these, at the cost of a (very) little extra complexity when
maintaining the headers. It also adds automated machinery to verify that each
of the new headers is 'standalone enough'.
What does 'standalone enough' mean? This is the problem that has stopped us
sharing DTrace headers between userspace and kernelspace for a long time: they
depend on types that come from different places and have different definitions
in the kernel and in userspace, and can never be made to come from the same
place.
So we fix this by dictating that the headers are standalone *given* that certain
headers are included first. For userspace, this set is <sys/types.h>,
<ctf/types.h>, and <unistd.h>; for kernelspace, the set is <linux/types.h> and a
newly-introduced header included as <dtrace/types.h>. We avoid exposing this
requirement to header users by arranging for the header included as "dtrace.h"
in kernelspace and as <sys/dtrace.h> in userspace to include the prerequisite
headers, and enough other headers that the users of those headers can keep
using them exactly as they did before. (There is a single exception for
dtrace/ioctl.h: see below.)
Where have the headers gone? They have been split in two directions (and the
Kbuild machinery has been adjusted to have its include paths point at the
appropriate places).
All DTrace headers, even <linux/dtrace_cpu.h> in the global kernel tree, have
had 'defines headers' split out of them, named ${header}_defines.h. These
headers contain all typedefs, enums and #defines which do not depend on
visibility into structure definitions declared in the main non-defines header,
and opaque forwardings for all structure definitions declared in that header.
This means that users can include the defines header if they only want opaque
use of structures and relevant constants. (This has necessitated some
mechanical changes to the DTrace headers to convert uses of foo_t typedefs into
'struct foo' where necessary. Not all uses have been converted: only those that
need to be). A _defines header is always accompanied by a corresponding non
_defines header (even if it is just one #include), but the reverse is not true.
In addition to this split, the core dtrace.h header has been split into three
pieces:
- dtrace/include/uapi/linux/dtrace/*.h contains the majority of the headers,
split into _defines and further by section roughly corresponding with the
comment-delimited sections in the original file. The include paths have been
set up so that these can be used via
#include <linux/dtrace/blah.h>
in both userspace and kernelspace.
#include <linux/include/dtrace.h> includes all the headers in the same order
as they were originally.
These headers are installed in userspace and used by dtrace-util. They
should always contain a CDDL license header, and should not use any
kernel-specific types (modulo those that userspace normally uses, such as
those related to kernel-specific functionality such as ioctl()). If you use
a new kernel-specific type, please add a definition of it to
uts/common/sys/dtrace_types.h in userspace too.
The old dtrace_ioctl.h has been renamed to <linux/dtrace/ioctl.h> and
moved in here too. It has gained some extra machinery to help debug
ioctl() type size conflicts. If you call dtrace_ioctl_sizes(), then
dtrace_size_dbg_print() (not defined here) is repeatedly called with
two parameters, the name of each ioctl() type and the size of that type.
Please keep this list up to date, it is useful!
There is one unfortunate exception to the userspace-types rule here:
ioctl.h needs types from <linux/dtrace_cpu_defines.h>, which is not
even a userspace-installed header. So userspace must provide a copy of
this header with appropriate typedefs as well. (This should probably
be fixed in due course.)
<linux/dtrace/universal.h> defines constants and types used by virtually
everything in any way related to dtrace.
- dtrace/include/dtrace/*.h contains headers that are not shared with
userspace, included as <dtrace/blah.h>:
- <dtrace/types.h>: this contains the kernel-side definitions of types
used in the shared headers. (It has not been 'gardened' in any way,
so probably contains a lot of other types as well). This header is
installed into the same place as the shared userspace headers. This
header needs a bit of care maintaining, as not everything kernel-
side is allowable in it: see below.
- <dtrace/provider.h>: The provider API, and its corresponding
<dtrace/provider_defines.h> defines header. This includes <dtrace/types.h>
itself, so should be standalone -- however, this has not been in any way
tested yet, unlike for the userspace headers. This header is also
installed into the same place as the shared userspace headers.
- <dtrace/dtrace_impl.h> and <dtrace/dtrace_impl_defines.h>.
These headers contain definitions used only by the DTrace core, and are
not installed anywhere.
Note that because of the rules regarding kernel-specific types in the UAPI
DTrace headers, a number of uses of CONFIG_64BIT and CONFIG_BIG_ENDIAN have been
reverted to their Solaris-era-and-userspace _LP64 and _LITTLE_ENDIAN forms;
<dtrace/types.h> translates between the two. (We have also fixed up a
couple of places in core DTrace where the nonexistent _BIG_ENDIAN was used.)
There are several things called dtrace.h now, which might get confusing:
- dtrace.h at the top level is for the DTrace core and included providers
alone. Anything goes in here. It is never installed anywhere, and not even
standalone providers can see it.
- dtrace/include/uapi/linux/dtrace/dtrace.h is shared with userspace and with
standalone providers, and needs to follow the same rules as all such shared
headers.
We have two new packages, dtrace-modules-$kver-headers and
dtrace-modules-$kver-provider-headers; to make it easy for people to Require
them, they provide features named 'dtrace-modules-headers' and
'dtrace-modules-provider-headers' using the same incrementing API version number
as 'dtrace-kernel-interface' (both currently 1). dtrace-modules-headers serves
much the same purpose as dtrace-kernel-interface, tracking changes in the
userspace/kernelspace API: the dtrace-modules-provider-headers version number
tracks changes in the DTrace core/provider API.
The top-level Makefile has acquired two new rules, headers_install and
headers_check. The former is a simple emulation of the top-level
headers_install rule, and is used by the RPM build system. The latter checks to
be sure that the userspace-side headers can be #included on their own
(modulo only <unistd.h> et al, as above), and that dtrace/ioctl.h has all its
types in scope with appropriate sizes, since if they aren't everything will
appear to work until userspace tries to invoke the ioctl() and gets an -ENOTTY
error.
The latter is particularly difficult, since the size-checking machinery only
works for kernelspace builds, and the headers_check build is userspace. So that
machinery hacks up a sort of halfway-house to the kernel environment, enough to
do the ioctl() size checks but not enough to #include arbitrary kernel
headers (among other things, there are no CONFIG constants here). This means
that changes to those kernel-side headers which are included by this
machinery (in particular dtrace/types.h, dtrace_os.h) need to include a
headers_check run to make sure that machinery hasn't broken. In general,
surrounding suspect definitions with an #ifndef HEADERS_CHECK should suffice:
nearly all of dtrace_os.h is so surrounded (and if we ever move dtrace_id_t out
into the shared headers, as perhaps we should, this problem will become less
serious). (Feel free to make the headers_check dtrace/ioctl.h compilation
environment more like that used for the real kernel.)
Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Nick Alcock [Mon, 25 Mar 2013 16:49:10 +0000 (16:49 +0000)]
ctf: blacklist certain structure members entirely
The problem of structures with identical names but conflicting members has
bitten dwarf2ctf before. We defined a deduplication blacklist which prevents
specific modules from participating in deduplication, because they define a
structure with the same name as one in the shared type repository but with
different members. This is, it turns out, not always enough.
Some kernel modules have begun to define structures with conflicting members in
different translation units within the same module. There is no trick we can
use to help dwarf2ctf deal with this: each module gets one CTF file, covering
all that module's translation units, and if types have conflicting definitions
within that one module, there's nothing we can do: we must skip them entirely.
But we can limit the damage somewhat.
This commit adds a new blacklist, the 'member blacklist', stored in
scripts/dwarf2ctf/member.blacklist, which blacklists structure or union members
by name. There are some limitations: only members of named structures and
unions can be blacklisted (not members of typedeffed, unnamed structures or
unions); and you can only blacklist types in the kernel tree, not types in
external modules. Both of these restrictions can be lifted if it ever becomes
necessary, the latter quite easily.
The blacklist is of the form
filename:structure name.member name
The filenames are absolutized and compared with the filenames in the DWARF for
each structure member, both at emission time and when recursing to mark shared
types.
Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Nick Alcock [Thu, 17 Jan 2013 14:25:40 +0000 (14:25 +0000)]
ptrace: Add PTRACE_GETMAPFD.
This request returns (in 'data') the file descriptor backing the mapping that
covers a given 'addr'. This works even if the mapped file is unlinked and not
open anywhere besides this mapping.
New errors:
-BADFD if the address is an anonymous mapping
-EFAULT if the address is not mapped at all
-PERM if the LSM does not permit the receipt of this file descriptor
Note that because the original fd is returned, you can access portions of it
outside the range of the original mapping (the use case for this, involving
acquiring ELF headers for executables and shared libraries that were unlinked
after mapping, relies on this).
This does not introduce a security hole because in order for the ptraced process
to mmap any file in the first place it must have had an fd to it, and the
ptracee could have accessed the outside-original-mapping portions at that point,
or simply forced the ptraced process to send it the fd via a Unix-domain socket
and held on to it. There is no danger that an execute-only process can be read
by this mechanism either, since you cannot PTRACE_ATTACH to such a
process. (Shared libraries cannot be execute-only at all.)
PTRACE_GETMAPFD is provisionally of value 0x42A5, in the architecture-
independent addition range, out-of-the-way so as not to collide with other
additions.
Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Kris Van Hees [Thu, 7 Feb 2013 21:36:26 +0000 (16:36 -0500)]
dtrace: update execve() syscall probe support
The execve syscall stub and entry syscall function changed from 3.6 to 3.7 to
no longer pass a pointer to the registers from the stub to the entry syscall
function. Instead, the entry syscall function now retrieves the registers
using current_pt_regs(), and passes it to the do_execve() function. The DTrace
stub and override function have been updated to use the same mechanism.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Kris Van Hees [Wed, 23 Jan 2013 09:53:14 +0000 (04:53 -0500)]
dtrace: USDT implementation (Phase 1)
This rather large patch provides the implementation for USDT support at the
DTrace kernel core level, and the fasttrap provider level. It ensures that
executables can register their embedded providers (with USDT probes), that
the probes are visible to the dtrace userspace utility, and that probes are
properly removed upon executable completion, execve() invocation, or any
unexpected executable termination.
The following parts are provided by this patch:
- meta-provider support (dtrace_ptofapi)
- helper ioctl interface (dtrace_dev)
- DIF validation for helper objects (dtrace_dif)
- DOF processing for helpers for provider and probe definitions (dtrace_dof)
- fasttrap meta-provider for USDT only (fasttrap*)
The dtrace_helper.c file was removed because this code belongs in dtrace_dof.c
instead.
Minimal changes were made to the core kernel in exec.c, sched.h, exit.c, and
fork.c to add support for process-specific helpers (and those encapsulate
providers and probes).
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Kris Van Hees [Wed, 23 Jan 2013 09:50:06 +0000 (04:50 -0500)]
dtrace: remove incorrect FBT support code
Code that was supporting an early implementation of FBT was still left hanging
in the source code tree. This patch removes it in preparation for a more
generic and above all, correct (and stable) implementation.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Kris Van Hees [Wed, 23 Jan 2013 09:47:21 +0000 (04:47 -0500)]
dtrace: move psinfo to its own header file
The psinfo structure definition and related function prototypes have been moved
to their own header file to avoiding including dtrace_os.h in sched.h. This is
also one step closer to providing the psinfo as a more generic piece of info,
rather than it being dtrace specific.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Nick Alcock [Thu, 22 Nov 2012 09:34:41 +0000 (09:34 +0000)]
ctf: update the shared CTF file right after initialization
If we don't do this, the void and function pointer types are not available for
lookup until something else gets added to the shared type repository and
triggers an update, so insertions of types depending on such types into the
shared type repository will fail until that happens. Since function pointers
are seen a lot in structures in the Linux kernel, such a failure for a member of
a structure means that all later members of the structure are skipped, and since
a major cause of insertion into the shared type repository is recursive
insertion from structure members in headers, this has the effect of losing track
of quite a lot of types first seen in translation units mentioned early on the
dwarf2ctf command line. Fortunately, since they haven't been successfully
inserted, insertion is retried later and succeeds. So this bugfix fixes a
latent bug only.
We would have seen this long ago as a bunch of error output were it not for a
bug in libdtrace-ctf leading to bad ID errors in CTF lookups that recurse to
parents not being emitted anywhere we were looking for them. Fixing that bug
requires us to fix this one, lest we get bombed with error messages
henceforward.
Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Nick Alcock [Wed, 10 Oct 2012 13:23:31 +0000 (14:23 +0100)]
ctf: dwarf2ctf doc revisions
Mostly small rewordings and reshufflings for clarity, and the introduction of a
program-wide flow graph, and a flow graph in each section. (One hopes they
don't get out of date too fast.)
Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
projects / users / jedix / linux-maple.git / log