lkml | Linux Kernel Mailing List viewer | TCP library

1) The section of the manual you quoted talks about BTS, not LBR: they are not the same thing. Later in that same thread you quoted, Andi Kleen seems to indicate that the LBR snap time is actually the moment of the PMI (the interrupt that runs the handler) and not the PEBS moment. So I think all three stack approaches have the same problem.

2) DWARF stack captures definitely do not correspond exactly to the PEBS entry. The PEBS event is recorded by the hardware at runtime, and then only some time later is the CPU interrupted, at which point the stack is unwound. If the PEBS buffer is configured to hold only a single entry, these two things should at least be close and if you are lucky, the PEBS IP will be in the same function that is still at the top of the stack when the handler runs. In that case, the stack is basically correct. Since perf shows you the actual PEBS IP at the top, plus the frames below that from the capture, this ends up working in that case.

3) If you aren't lucky, the function will have changed between the PEBS capture and the handler running. In this case you get a franken-stack that doesn't make sense: the top function may not be callable from the second-from-the-top function (or something). It is not totally corrupted: it's just that everything except the top frame comes from a point after the PEBS stack was captured, and the top frame comes from PEBS, or something like that. This applies also to --call-graph fp, for the same reasons.

Most likely you never saw an invalid IP because perf shows the IP from the PEBS sample (that's the theme of that whole thread). I think if you look into the raw sample, you can see both the PEBS IP, and the handler IP, and you can see they usually won't match.

Overall, you can trust the backtraces for "time" or "cycle" profiling since they are in some sense an accurate sampling representation of execution time: it's just that they don't correspond to the PEBS moment but some time later (but why is that later time any worse than the PEBS time). Basically for this type of profiling you don't really need PEBS at all.

If you are using a different type of event, and you want fine-grained accounting of where the event took place, that's what PEBS is for. You often don't need a stack trace: just the top frame is enough. If you want stack traces, use them, but know they come from a moment in time a bit later, or use --lbr (if that works).

4000 ms is a quite large advertising interval. Anyway, bluepy uses BlueZ, and when BlueZ connects, it first scans and when it finds the wanted device, it stops scanning and initiates a connection. During this connection attempt, there is a timeout before starting scanning again. It could be that this 4000 ms advertising interval is larger than the timeout. It's commonly 2 seconds I think.

Please start "sudo btmon" on your central device before attempting to connect, let it capture and print the HCI packets and post the output here.

Advertising interval and Connection interval are completely independent.

The article mentioned by sgbj in the comments written by Google's Paul Turner explains the following in much more detail, but I'll give it a shot:

As far as I can piece this together from the limited information at the moment, a retpoline is a return trampoline that uses an infinite loop that is never executed to prevent the CPU from speculating on the target of an indirect jump.

The basic approach can be seen in Andi Kleen's kernel branch addressing this issue:

It introduces the new __x86.indirect_thunk call that loads the call target whose memory address (which I'll call ADDR) is stored on top of the stack and executes the jump using a the RET instruction. The thunk itself is then called using the NOSPEC_JMP/CALL macro, which was used to replace many (if not all) indirect calls and jumps. The macro simply places the call target on the stack and sets the return address correctly, if necessary (note the non-linear control flow):

If you write

For these kind of questions, use the source! Among other interesting comments, there is this text:

EPOLLHUP is UNMASKABLE event (...). It means that after we received EOF, poll always returns immediately, making impossible poll() on write() in state CLOSE_WAIT. One solution is evident --- to set EPOLLHUP if and only if shutdown has been made in both directions.

And then the only code that sets EPOLLHUP:

This one was very interesting to crack, took me a while.

The first real hint was this answer to a different question: https://unix.stackexchange.com/questions/364568/how-to-read-the-proc-pid-fd-directory-of-a-process-which-has-a-linux-capabil - just wanted to give the credit.

The real reason you get "permission denied" there is files under /proc/self/ are owned by root if the process has any capabilities - it's not about CAP_SYS_RESOURCE or about oom_* files specifically. You can verify this by calling stat and using different capabilities. Quoting man 5 proc:

/proc/[pid]

There is a numerical subdirectory for each running process; the subdirectory is named by the process ID.

Each /proc/[pid] subdirectory contains the pseudo-files and directories described below. These files are normally owned by the effective user and effective group ID of the process. However, as a security measure, the ownership is made root:root if the process's "dumpable" attribute is set to a value other than 1. This attribute may change for the following reasons:

• The attribute was explicitly set via the prctl(2) PR_SET_DUMPABLE operation.

• The attribute was reset to the value in the file /proc/sys/fs/suid_dumpable (described below), for the reasons described in prctl(2).

Resetting the "dumpable" attribute to 1 reverts the ownership of the /proc/[pid]/* files to the process's real UID and real GID.

This already hints to the solution, but first let's dig a little deeper and see that man prctl:

PR_SET_DUMPABLE (since Linux 2.3.20)

Set the state of the "dumpable" flag, which determines whether core dumps are produced for the calling process upon delivery of a signal whose default behavior is to produce a core dump.

In kernels up to and including 2.6.12, arg2 must be either 0 (SUID_DUMP_DISABLE, process is not dumpable) or 1 (SUID_DUMP_USER, process is dumpable). Between kernels 2.6.13 and 2.6.17, the value 2 was also permitted, which caused any binary which normally would not be dumped to be dumped readable by root only; for security reasons, this feature has been removed. (See also the description of /proc/sys/fs/suid_dumpable in proc(5).)

Normally, this flag is set to 1. However, it is reset to the current value contained in the file /proc/sys/fs/suid_dumpable (which by default has the value 0), in the following circumstances:

• The process's effective user or group ID is changed.

• The process's filesystem user or group ID is changed (see credentials(7)).

• The process executes (execve(2)) a set-user-ID or set-group-ID program, resulting in a change of either the effective user ID or the effective group ID.

• The process executes (execve(2)) a program that has file capabilities (see capabilities(7)), but only if the permitted capabilities gained exceed those already permitted for the process.

Processes that are not dumpable can not be attached via ptrace(2) PTRACE_ATTACH; see ptrace(2) for further details.

If a process is not dumpable, the ownership of files in the process's /proc/[pid] directory is affected as described in proc(5).

Now it's clear: our process has a capability that the shell used to launch it did not have, thus the dumpable attribute was set to false, thus files under /proc/self/ are owned by root rather than the current user.

The fix is as simple as re-setting that dumpable attribute before trying to open the file. Stick the following or something similar before opening the file:

Use the same idea, where the type of a ?: expression depends on whether an argument is a null pointer constant or an ordinary void *, but detect the type with _Generic:

So let's get through the standard. C11 6.3.2.3p3

1. An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. [...]

In the construct (void*)((x) * 0l), the value is clearly always 0 for any integral value, therefore it always results in a null pointer given any kind of integer value on most platforms, but to a null-pointer constant iff the x is an integer constant expression.

Now, the question is why does x ? (void *)0 : (int *)1 work the same as x ? (int *)1 : (void *)0 when wrapped in sizeof(* (...)). For that we need to read 6.5.11p6:

1. If both the second and third operands are pointers or one is a null pointer constant and the other is a pointer, the result type is a pointer to a type qualified with all the type qualifiers of the types referenced by both operands. Furthermore, if both operands are pointers to compatible types or to differently qualified versions of compatible types, the result type is a pointer to an appropriately qualified version of the composite type; if one operand is a null pointer constant, the result has the type of the other operand; otherwise, one operand is a pointer to void or a qualified version of void, in which case the result type is a pointer to an appropriately qualified version of void.

So if either the 2nd or 3rd expession is a null pointer constant, the result of the conditional operator has the type of the other expression, i.e. both x ? (void *)0 : (int *)1 and x ? (int*)1 : (void *)0 have type int *!

And in other case, i.e. x ? (void *)non_constant : (int *)1 the latter part of the bolded text says that the type of that expression must be void *.

The type is completely decided during the compilation phase, based on the types of the second and the third operands; and the value of the first operand plays no role in it. If this is then used in a sizeof then the entire expression becomes just another integer constant expression.

Then comes the dubious part: sizeof(* ...). The pointer is "dereferenced", and the sizeof of the dereferenced value is used in calculations. ISO C does not allow the evaluation of sizeof(void) -actually, it doesn't even allow the dereference of a void * - but GCC defines it as sizeof(void).

As Linus said: "That is either genius, or a seriously diseased mind. - I can't quite tell which."

By the way, for many similar uses, the GCC builtin __builtin_constant_p would be sufficient - but while it would return 1 for all integer constant expressions, it would return 1 for any other lvalues for which the optimizer can substitute a constant in code; the difference being that only constant integer expressions can be used as for example as non-VLA array dimensions, in static initializers and as bitfield widths.

You could use the get_maintainer.pl script to see who's responsible for the specific file in question. Use it like so from the linux dir:

perl scripts/get_maintainer.pl [OPTIONS] -f

The kernel newbies mailing list can also be a good place to start.