On Tue, Nov 04, 2014 at 12:28:36AM +, Pawel Moll wrote:
> +int sysctl_perf_sample_time_clk_id = CLOCK_MONOTONIC;
const ?
> /*
> * perf samples are done in some very critical code paths (NMIs).
> * If they take too much CPU time, the system can lock up and not
> @@ -324,7 +326,7 @@ exter
Hi Pawel,
On Tue, 4 Nov 2014 00:28:37 +, Pawel Moll wrote:
> + /*
> + * Data in userspace event record is transparent for the kernel
> + *
> + * Userspace perf tool code maintains a list of known types with
> + * reference implementations of parsers for the data field.
the current meaning of BPF_MAP_UPDATE_ELEM syscall command is:
either update existing map element or create a new one.
Initially the plan was to add a new command to handle the case of
'create new element if it didn't exist', but 'flags' style looks
cleaner and overall diff is much smaller (more co
add new map type BPF_MAP_TYPE_HASH and its implementation
- maps are created/destroyed by userspace. Both userspace and eBPF programs
can lookup/update/delete elements from the map
- eBPF programs can be called in_irq(), so use spin_lock_irqsave() mechanism
for concurrent updates
- key/value
add new map type BPF_MAP_TYPE_ARRAY and its implementation
- optimized for fastest possible lookup()
. in the future verifier/JIT may recognize lookup() with constant key
and optimize it into constant pointer. Can optimize non-constant
key into direct pointer arithmetic as well, since po
fix errno of BPF_MAP_LOOKUP_ELEM command as bpf manpage
described it in commit b4fc1a460f30("Merge branch 'bpf-next'"):
-
BPF_MAP_LOOKUP_ELEM
int bpf_lookup_elem(int fd, void *key, void *value)
{
union bpf_attr attr = {
.map_fd = fd,
.key = ptr_to_u64(key
. check error conditions and sanity of hash and array map APIs
. check large maps (that kernel gracefully switches to vmalloc from kmalloc)
. check multi-process parallel access and stress test
Signed-off-by: Alexei Starovoitov
---
Eventually it can be moved tools/testing/selftests/bpf/, but for
proper types and function helpers are ready. Use them in verifier testsuite.
Remove temporary stubs
Signed-off-by: Alexei Starovoitov
---
kernel/bpf/test_stub.c | 56 +++
samples/bpf/test_verifier.c | 14 +--
2 files changed, 16 insertions
expose bpf_map_lookup_elem(), bpf_map_update_elem(), bpf_map_delete_elem()
map accessors to eBPF programs
Signed-off-by: Alexei Starovoitov
---
Note, these helpers are exposed as '.gpl_only = false', so non-GPL eBPF programs
can use them. That was requested by AndyL and DavidL before.
include/l
Hi All,
this set of patches adds implementation of HASH and ARRAY types of eBPF maps
which were described in manpage in commit b4fc1a460f30("Merge branch
'bpf-next'")
The difference vs previous version of these patches from August:
- added 'flags' attribute to BPF_MAP_UPDATE_ELEM
- in HASH type
This patch enables cgroup mounting inside userns when a process
as appropriate privileges. The cgroup filesystem mounted is
rooted at the cgroupns-root. Thus, in a container-setup, only
the hierarchy under the cgroupns-root is exposed inside the container.
This allows container management tools to
Introduce the ability to create new cgroup namespace. The newly created
cgroup namespace remembers the cgroup of the process at the point
of creation of the cgroup namespace (referred as cgroupns-root).
The main purpose of cgroup namespace is to virtualize the contents
of /proc/self/cgroup file.
On Mon, Nov 3, 2014 at 5:11 PM, John Stultz wrote:
> On Mon, Nov 3, 2014 at 4:58 PM, Andy Lutomirski wrote:
>> On Mon, Nov 3, 2014 at 4:28 PM, Pawel Moll wrote:
>>> From: Pawel Moll
>>> Thomas suggested solution which gets down to my original proposal for
>>> sched/monotonic clock correlation -
On Mon, Nov 3, 2014 at 4:58 PM, Andy Lutomirski wrote:
> On Mon, Nov 3, 2014 at 4:28 PM, Pawel Moll wrote:
>> From: Pawel Moll
>> Thomas suggested solution which gets down to my original proposal for
>> sched/monotonic clock correlation - an additional sample type so events
>> can be "double sta
On Mon, Nov 3, 2014 at 4:28 PM, Pawel Moll wrote:
> From: Pawel Moll
> Thomas suggested solution which gets down to my original proposal for
> sched/monotonic clock correlation - an additional sample type so events
> can be "double stamped" using different clock sources providing
> synchronisatio
On Mon, Nov 3, 2014 at 4:17 PM, Andy Lutomirski wrote:
> On Mon, Nov 3, 2014 at 4:12 PM, Aditya Kali wrote:
>> On Mon, Nov 3, 2014 at 3:48 PM, Andy Lutomirski wrote:
>>> On Mon, Nov 3, 2014 at 3:23 PM, Aditya Kali wrote:
On Mon, Nov 3, 2014 at 3:15 PM, Andy Lutomirski
wrote:
> O
From: Pawel Moll
This patch adds an option to sample value of an additional clock with
any perf event, with the the aim of allowing time correlation between
data coming from perf and other sources like hardware trace which is
timestamped with an external clock.
The idea is to generate periodic p
From: Pawel Moll
This patch adds a PR_TASK_PERF_UEVENT prctl call which can be used by
any process to inject custom data into perf data stream as a new
PERF_RECORD_UEVENT record, if such process is being observed or if it
is running on a CPU being observed by the perf framework.
The prctl call t
Until now, perf framework never defined the meaning of the timestampt
captured as PERF_SAMPLE_TIME sample type. The values were obtaining
from local (sched) clock, which is unavailable in userspace. This made
it impossible to correlate perf data with any other events. Other
tracing solutions have t
From: Pawel Moll
Hello again,
Back to the subject, this time with a slightly different angle...
I've organised a session on the subject during the tracing
minisummit at LPC 2014 in Dusseldorf. Notes taken from the discussion
taken by Steven Rostedt (thanks Steve!)
http://www.linuxplumbersconf.
On Mon, Nov 3, 2014 at 4:12 PM, Aditya Kali wrote:
> On Mon, Nov 3, 2014 at 3:48 PM, Andy Lutomirski wrote:
>> On Mon, Nov 3, 2014 at 3:23 PM, Aditya Kali wrote:
>>> On Mon, Nov 3, 2014 at 3:15 PM, Andy Lutomirski wrote:
On Mon, Nov 3, 2014 at 3:12 PM, Aditya Kali wrote:
> On Fri, Oct
On Mon, Nov 3, 2014 at 3:48 PM, Andy Lutomirski wrote:
> On Mon, Nov 3, 2014 at 3:23 PM, Aditya Kali wrote:
>> On Mon, Nov 3, 2014 at 3:15 PM, Andy Lutomirski wrote:
>>> On Mon, Nov 3, 2014 at 3:12 PM, Aditya Kali wrote:
On Fri, Oct 31, 2014 at 5:07 PM, Andy Lutomirski
wrote:
>
On Mon, Nov 3, 2014 at 3:23 PM, Aditya Kali wrote:
> On Mon, Nov 3, 2014 at 3:15 PM, Andy Lutomirski wrote:
>> On Mon, Nov 3, 2014 at 3:12 PM, Aditya Kali wrote:
>>> On Fri, Oct 31, 2014 at 5:07 PM, Andy Lutomirski
>>> wrote:
On Fri, Oct 31, 2014 at 12:19 PM, Aditya Kali
wrote:
>>>
On Fri, Oct 31, 2014 at 5:58 PM, Eric W. Biederman
wrote:
> Andy Lutomirski writes:
>
>> On Fri, Oct 31, 2014 at 12:18 PM, Aditya Kali wrote:
>
>
>
>>> +static void *cgroupns_get(struct task_struct *task)
>>> +{
>>> + struct cgroup_namespace *ns = NULL;
>>> + struct nsproxy *nsproxy
On Fri, Oct 31, 2014 at 5:02 PM, Andy Lutomirski wrote:
> On Fri, Oct 31, 2014 at 12:18 PM, Aditya Kali wrote:
>> Introduce the ability to create new cgroup namespace. The newly created
>> cgroup namespace remembers the cgroup of the process at the point
>> of creation of the cgroup namespace (re
On Mon, Nov 3, 2014 at 3:15 PM, Andy Lutomirski wrote:
> On Mon, Nov 3, 2014 at 3:12 PM, Aditya Kali wrote:
>> On Fri, Oct 31, 2014 at 5:07 PM, Andy Lutomirski wrote:
>>> On Fri, Oct 31, 2014 at 12:19 PM, Aditya Kali wrote:
This patch enables cgroup mounting inside userns when a process
>>
On Mon, Nov 3, 2014 at 3:12 PM, Aditya Kali wrote:
> On Fri, Oct 31, 2014 at 5:07 PM, Andy Lutomirski wrote:
>> On Fri, Oct 31, 2014 at 12:19 PM, Aditya Kali wrote:
>>> This patch enables cgroup mounting inside userns when a process
>>> as appropriate privileges. The cgroup filesystem mounted is
On Fri, Oct 31, 2014 at 5:07 PM, Andy Lutomirski wrote:
> On Fri, Oct 31, 2014 at 12:19 PM, Aditya Kali wrote:
>> This patch enables cgroup mounting inside userns when a process
>> as appropriate privileges. The cgroup filesystem mounted is
>> rooted at the cgroupns-root. Thus, in a container-set
On Mon, Nov 3, 2014 at 2:43 PM, Aditya Kali wrote:
>
>
> On Fri, Oct 31, 2014 at 6:09 PM, Eric W. Biederman
> wrote:
>>
>> Aditya Kali writes:
>>
>> > This patch enables cgroup mounting inside userns when a process
>> > as appropriate privileges. The cgroup filesystem mounted is
>> > rooted at t
(sorry for accidental non-plain-text response earlier).
On Fri, Oct 31, 2014 at 6:09 PM, Eric W. Biederman
wrote:
> Aditya Kali writes:
>
>> This patch enables cgroup mounting inside userns when a process
>> as appropriate privileges. The cgroup filesystem mounted is
>> rooted at the cgroupns-ro
Dear Sir/Madam, Here is a pdf attachment of my proposal to you. Please
read and reply I would be grateful. Peter Hans
reply to E-mail: peterh@aol.com
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majord...@vger.kernel.org
More majordomo in
From: Stephen Hemminger
Date: Mon, 3 Nov 2014 12:42:34 -0800
> The entries in the Kbuild files are incorrectly sorted.
> Matters for aesthetics only.
>
> Signed-off-by: Stephen Hemminger
>
> ---
> Patch against -net tree since that is where my last change was.
As such, I'll apply to this to n
The entries in the Kbuild files are incorrectly sorted.
Matters for aesthetics only.
Signed-off-by: Stephen Hemminger
---
Patch against -net tree since that is where my last change was.
--- a/include/uapi/linux/Kbuild 2014-11-02 11:24:32.304658688 -0800
+++ b/include/uapi/linux/Kbuild 2014-11-0
On Tue, 21 Oct 2014, Shuah Khan wrote:
> Andrew/Ingo/Thomas,
>
> You are all on the signed-off list for rt-tester. I have been poking
> around the source tree looking for existing test and came across rt-tester.
>
> What are your thoughts on rt-tester suitability to reside under
> tools/testing/s
On Mon, Nov 3, 2014 at 10:25 AM, Julien Tinnes wrote:
> On Mon, Nov 3, 2014 at 9:37 AM, David Drysdale wrote:
>>
>> On Mon, Nov 3, 2014 at 3:42 PM, Andy Lutomirski
>> wrote:
>> > On Mon, Nov 3, 2014 at 7:20 AM, Al Viro wrote:
>> >> On Mon, Nov 03, 2014 at 11:48:23AM +, David Drysdale wrote:
On Mon, Nov 3, 2014 at 9:37 AM, David Drysdale wrote:
> On Mon, Nov 3, 2014 at 3:42 PM, Andy Lutomirski wrote:
>> This is extremely useful in conjunction with seccomp.
>
> Yes, that was my understanding of how the Chrome[OS] folk wanted
> to use it.
Yes, exactly. Without this, if we want to give
On Mon, Nov 3, 2014 at 3:42 PM, Andy Lutomirski wrote:
> On Mon, Nov 3, 2014 at 7:20 AM, Al Viro wrote:
>> On Mon, Nov 03, 2014 at 11:48:23AM +, David Drysdale wrote:
>>> Add a new O_BENEATH flag for openat(2) which restricts the
>>> provided path, rejecting (with -EACCES) paths that are not
On November 3, 2014 7:42:58 AM PST, Andy Lutomirski wrote:
>On Mon, Nov 3, 2014 at 7:20 AM, Al Viro
>wrote:
>> On Mon, Nov 03, 2014 at 11:48:23AM +, David Drysdale wrote:
>>> Add a new O_BENEATH flag for openat(2) which restricts the
>>> provided path, rejecting (with -EACCES) paths that ar
On Mon, Nov 3, 2014 at 4:00 AM, Simon McVittie
wrote:
> On 01/11/14 16:19, Andy Lutomirski wrote:
>> You can't justify logging fundamentally unverifiable things like the
>> command line by saying that you want to know if someone tries to play
>> (impossible-to-reliably-detect) games to obscure the
On Mon, Nov 3, 2014 at 7:20 AM, Al Viro wrote:
> On Mon, Nov 03, 2014 at 11:48:23AM +, David Drysdale wrote:
>> Add a new O_BENEATH flag for openat(2) which restricts the
>> provided path, rejecting (with -EACCES) paths that are not beneath
>> the provided dfd. In particular, reject:
>> - pa
On Mon, Nov 03, 2014 at 09:32:23AM -0500, Prarit Bhargava wrote:
[..]
> +
> +static int __init panic_on_warn_setup(char *s)
> +{
> + /* Enabling this on a kdump kernel could cause a bogus panic. */
> + if (!is_kdump_kernel())
> + panic_on_warn = 1;
I think it would be better i
On Mon, Nov 03, 2014 at 11:48:23AM +, David Drysdale wrote:
> Add a new O_BENEATH flag for openat(2) which restricts the
> provided path, rejecting (with -EACCES) paths that are not beneath
> the provided dfd. In particular, reject:
> - paths that contain .. components
> - paths that begin w
On Mon, Nov 03, 2014 at 08:32:42AM -0500, Prarit Bhargava wrote:
>
>
> On 10/30/2014 09:58 PM, Hedi Berriche wrote:
> > On Thu, Oct 30, 2014 at 17:06 Prarit Bhargava wrote:
> > | There have been several times where I have had to rebuild a kernel to
> > | cause a panic when hitting a WARN() in the
On Mon, 2014-11-03 at 14:48 +, Tomeu Vizoso wrote:
> On 29 September 2014 17:53, Pawel Moll wrote:
> > On Mon, 2014-09-29 at 16:32 +0100, Peter Zijlstra wrote:
> >> Also none of the many words above describe
> >> PERF_SAMPLE_USERSPACE_EVENT(), wth is that about?
> >
> > Hopefully description o
On 29 September 2014 17:53, Pawel Moll wrote:
> On Mon, 2014-09-29 at 16:32 +0100, Peter Zijlstra wrote:
>> Also none of the many words above describe
>> PERF_SAMPLE_USERSPACE_EVENT(), wth is that about?
>
> Hopefully description of the v2 makes better job in this:
>
> http://thread.gmane.org/gman
On Sat, 1 Nov 2014 18:21:30 -0700
Greg Kroah-Hartman wrote:
> Here's some reasons why I feel it is better to have kdbus in the kernel
> rather than trying to implement the same thing in a userspace daemon:
No - these are reasons to have *something* in the kernel. I think it
would be far more con
There have been several times where I have had to rebuild a kernel to
cause a panic when hitting a WARN() in the code in order to get a crash
dump from a system. Sometimes this is easy to do, other times (such as
in the case of a remote admin) it is not trivial to send new images to the
user.
A m
On 10/30/2014 08:25 PM, Rusty Russell wrote:
> Prarit Bhargava writes:
>> On 10/22/2014 12:27 AM, Rusty Russell wrote:
>>> Prarit Bhargava writes:
There have been several times where I have had to rebuild a kernel to
cause a panic when hitting a WARN() in the code in order to get a cr
On 10/30/2014 09:58 PM, Hedi Berriche wrote:
> On Thu, Oct 30, 2014 at 17:06 Prarit Bhargava wrote:
> | There have been several times where I have had to rebuild a kernel to
> | cause a panic when hitting a WARN() in the code in order to get a crash
> | dump from a system. Sometimes this is easy
On 01/11/14 16:19, Andy Lutomirski wrote:
> You can't justify logging fundamentally unverifiable things like the
> command line by saying that you want to know if someone tries to play
> (impossible-to-reliably-detect) games to obscure their command line.
I think kdbus might be mixing up two ortho
On 03/11/2014 12:48, David Drysdale wrote:
> +.I pathname
> +is beneath the current working directory (for
> +.BR open (2))
> +or the
> +.I dirfd
> +(for
> +.BR openat (2)).
> +If the
> +.I pathname
> +is absolute or contains a path component of "..", the
> +.BR open ()
> +fails with the error
> +.
This change adds a new O_BENEATH flag for openat(2) which restricts the
provided path, rejecting (with -EACCES) paths that are not beneath
the provided dfd.
This change was previously included as part of a larger patchset
(https://lkml.org/lkml/2014/7/25/426) for Capsicum support; however, it
is p
Add a new O_BENEATH flag for openat(2) which restricts the
provided path, rejecting (with -EACCES) paths that are not beneath
the provided dfd. In particular, reject:
- paths that contain .. components
- paths that begin with /
- symlinks that have paths as above.
Signed-off-by: David Drysdale
Add simple tests of openat(2) variations, including examples that
check the new O_BENEATH flag.
Signed-off-by: David Drysdale
---
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/openat/.gitignore | 4 +
tools/testing/selftests/openat/Makefile | 28 ++
tools/te
Signed-off-by: David Drysdale
---
man2/open.2 | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/man2/open.2 b/man2/open.2
index abc3c35b8b3a..495c7f1e81a4 100644
--- a/man2/open.2
+++ b/man2/open.2
@@ -716,6 +716,31 @@ XFS support was added
.\" c
55 matches
Mail list logo
