* [PATCH v6 3/3] tpm: update PPI documentation to address the location change.
From: Jarkko Sakkinen @ 2015-05-20 13:49 UTC (permalink / raw)
To: tpmdd-devel, linux-kernel
Cc: peterhuewe, gregkh, jgunthorpe, Jarkko Sakkinen,
open list:ABI/API
In-Reply-To: <1432129766-7289-1-git-send-email-jarkko.sakkinen@linux.intel.com>
Updated Documentation/ABI/testing/sysfs-driver-ppi in order to explain
where PPI attributes are located and how backwards compatiblity is
addressed.
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
Documentation/ABI/testing/sysfs-driver-ppi | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-ppi b/Documentation/ABI/testing/sysfs-driver-ppi
index 7d1435b..9921ef2 100644
--- a/Documentation/ABI/testing/sysfs-driver-ppi
+++ b/Documentation/ABI/testing/sysfs-driver-ppi
@@ -1,4 +1,4 @@
-What: /sys/devices/pnp0/<bus-num>/ppi/
+What: /sys/class/tpm/tpmX/ppi/
Date: August 2012
Kernel Version: 3.6
Contact: xiaoyan.zhang@intel.com
@@ -8,9 +8,14 @@ Description:
folder makes sense. The folder path can be got by command
'find /sys/ -name 'pcrs''. For the detail information of PPI,
please refer to the PPI specification from
+
http://www.trustedcomputinggroup.org/
-What: /sys/devices/pnp0/<bus-num>/ppi/version
+ In Linux 4.2 ppi was moved to the character device directory.
+ A symlink from tpmX/device/ppi to tpmX/ppi to provide backwards
+ compatibility.
+
+What: /sys/class/tpm/tpmX/ppi/version
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:
@@ -18,7 +23,7 @@ Description:
platform.
This file is readonly.
-What: /sys/devices/pnp0/<bus-num>/ppi/request
+What: /sys/class/tpm/tpmX/ppi/request
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:
@@ -28,7 +33,7 @@ Description:
integer value range from 1 to 160, and 0 means no request.
This file can be read and written.
-What: /sys/devices/pnp0/00:<bus-num>/ppi/response
+What: /sys/class/tpm/tpmX/ppi/response
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:
@@ -37,7 +42,7 @@ Description:
: <response description>".
This file is readonly.
-What: /sys/devices/pnp0/<bus-num>/ppi/transition_action
+What: /sys/class/tpm/tpmX/ppi/transition_action
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:
@@ -47,7 +52,7 @@ Description:
description>".
This file is readonly.
-What: /sys/devices/pnp0/<bus-num>/ppi/tcg_operations
+What: /sys/class/tpm/tpmX/ppi/tcg_operations
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:
@@ -58,7 +63,7 @@ Description:
This attribute is only supported by PPI version 1.2+.
This file is readonly.
-What: /sys/devices/pnp0/<bus-num>/ppi/vs_operations
+What: /sys/class/tpm/tpmX/ppi/vs_operations
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:
--
2.1.4
^ permalink raw reply related
* [PATCH v6 0/3] Enable PPI sysfs interface for TPM 2.0
From: Jarkko Sakkinen @ 2015-05-20 13:49 UTC (permalink / raw)
To: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: peterhuewe-Mmb7MZpHnFY, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/, Jarkko Sakkinen,
Guenter Roeck, open list:ABI/API, NeilBrown, Simon Wunderlich,
Tejun Heo, Vivien Didelot
Changes since v5:
* Updated documentation.
Changes since v4:
* Removed dangling export of kernfs_remove_by_name_ns() from the sysfs
patch.
Changes since v3:
* Use sysfs_remove_link()
Changes since v2:
* Fixed to_tpm_chip() macro.
* Split into two patches.
* Renamed sysfs_link_group_to_kobj to sysfs_link_entry_to_kobj
* Only create the "backwards compatibility" symlink for TPM 1.x devices.
Jarkko Sakkinen (3):
sysfs: added sysfs_link_entry_to_kobj()
tpm: move the PPI attributes to character device directory.
tpm: update PPI documentation to address the location change.
Documentation/ABI/testing/sysfs-driver-ppi | 19 +++++++++-----
drivers/char/tpm/tpm-chip.c | 24 +++++++++++------
drivers/char/tpm/tpm.h | 17 +++++-------
drivers/char/tpm/tpm_ppi.c | 34 ++++++++----------------
fs/sysfs/group.c | 42 ++++++++++++++++++++++++++++++
include/linux/sysfs.h | 8 ++++++
6 files changed, 95 insertions(+), 49 deletions(-)
--
2.1.4
^ permalink raw reply
* Re: [PATCH 00/23] userfaultfd v4
From: Andrea Arcangeli @ 2015-05-20 13:23 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-mm, qemu-devel, kvm, linux-api,
Pavel Emelyanov, Sanidhya Kashyap, zhang.zhanghailiang,
Linus Torvalds, Kirill A. Shutemov, Andres Lagar-Cavilla,
Dave Hansen, Paolo Bonzini, Rik van Riel, Mel Gorman,
Andy Lutomirski, Hugh Dickins, Peter Feiner,
Dr. David Alan Gilbert, Johannes Weiner, Huangpeng (Peter)
In-Reply-To: <20150519143801.8ba477c3813e93a2637c19cf@linux-foundation.org>
Hi Andrew,
On Tue, May 19, 2015 at 02:38:01PM -0700, Andrew Morton wrote:
> On Thu, 14 May 2015 19:30:57 +0200 Andrea Arcangeli <aarcange@redhat.com> wrote:
>
> > This is the latest userfaultfd patchset against mm-v4.1-rc3
> > 2015-05-14-10:04.
>
> It would be useful to have some userfaultfd testcases in
> tools/testing/selftests/. Partly as an aid to arch maintainers when
> enabling this. And also as a standalone thing to give people a
> practical way of exercising this interface.
Agreed.
I was also thinking about writing a trinity module for it, I wrote it
for an older version but it was much easier to do that back then
before we had ioctls, now it's more tricky because the ioctls requires
the fd open first etc... it's not enough to just call a syscall with a
flood of supervised-random params anymore.
> What are your thoughts on enabling userfaultfd for other architectures,
> btw? Are there good use cases, are people working on it, etc?
powerpc should be enabled and functional already. There's not much
arch dependent code in it, so in theory if the postcopy live migration
patchset is applied to qemu, it should work on powerpc out of the
box. Nobody tested it yet but I don't expect trouble on the kernel side.
Adding support for all other archs is just a few liner patch that
defines the syscall number. I didn't do that out of tree because every
time a new syscall materialized I would get more rejects during
rebase.
> Also, I assume a manpage is in the works? Sooner rather than later
> would be good - Michael's review of proposed kernel interfaces has
> often been valuable.
Yes, the manpage was certainly planned. It would require updates as we
keep adding features (like the wrprotect tracking, the non-cooperative
usage, and extending the availability of the ioctls to tmpfs). We can
definitely write a manpage with the current features.
Ok, so I'll continue working on the testcase and on the manpage.
Thanks!!
Andrea
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2 2/3] fbcon: use the cursor blink interval provided by vt
From: Thierry Reding @ 2015-05-20 12:36 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Kevin Hilman, Scot Doyle, Tomi Valkeinen, Michael Kerrisk,
Jiri Slaby, Jean-Christophe Plagniol-Villard, Pavel Machek,
Geert Uytterhoeven, lkml, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Tyler Baker, Olof Johansson,
Daniel Stone, Arnd Bergmann
In-Reply-To: <20150519234112.GA25218-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 3182 bytes --]
On Tue, May 19, 2015 at 04:41:12PM -0700, Greg Kroah-Hartman wrote:
> On Tue, May 19, 2015 at 11:52:29PM +0200, Thierry Reding wrote:
> > On Tue, May 19, 2015 at 02:45:19PM -0700, Kevin Hilman wrote:
> > > On Tue, May 19, 2015 at 2:40 PM, Thierry Reding
> > > <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote:
> > > >> On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle <lkml14-enLWO88E2pdl57MIdRCFDg@public.gmane.org> wrote:
> > > >> > vt now provides a cursor blink interval via vc_data. Use this
> > > >> > interval instead of the currently hardcoded 200 msecs. Store it in
> > > >> > fbcon_ops to avoid locking the console in cursor_timer_handler().
> > > >> >
> > > >> > Signed-off-by: Scot Doyle <lkml14-enLWO88E2pdl57MIdRCFDg@public.gmane.org>
> > > >> > Acked-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
> > > >>
> > > >> This patch hit next-20150519 in the form of commit 27a4c827c34a
> > > >> (fbcon: use the cursor blink interval provided by vt) and has caused
> > > >> boot failure on a handful of ARM platforms when booting a MMC root
> > > >> filesystem. This error was spotted by the kernelci.org bot on
> > > >> exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
> > > >> some tegra platforms too.
> > > >>
> > > >> Thierry spotted this commit as a potential cause, and both Daniel and
> > > >> I have reverted and boot tested on exynos5 and tegra respectively and
> > > >> the boot panics disappear.
> > > >
> > > > FWIW, if I apply the below on top of next-20150519 things seem to be
> > > > back to normal as well:
> > > >
> > > > diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> > > > index 05b1d1a71ef9..658c34bb9076 100644
> > > > --- a/drivers/video/console/fbcon.c
> > > > +++ b/drivers/video/console/fbcon.c
> > > > @@ -1310,8 +1310,9 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
> > > > return;
> > > >
> > > > ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
> > > > - fbcon_del_cursor_timer(info);
> > > > - if (!(vc->vc_cursor_type & 0x10))
> > > > + if (vc->vc_cursor_type & 0x10)
> > > > + fbcon_del_cursor_timer(info);
> > > > + else
> > > > fbcon_add_cursor_timer(info);
> > > >
> > > > ops->cursor_flash = (mode == CM_ERASE) ? 0 : 1;
> > >
> > > Applying this on next-20150519 makes my exynos board happily boot again as well.
> > >
> > > Tested-by: Kevin Hilman <khilman-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >
> > Excellent. Greg, Scot, any opinions on whether or not this is the right
> > thing to do? It restores a bit that looks suspiciously like it snuck in
> > in the original (at least it isn't documented in the commit message).
> >
> > Greg, feel free to squash this in if everybody agrees this is good to
> > go. If you prefer a patch on top let me know and I'll come up with a
> > proper commit message.
>
> Please send a real patch and I'll apply it on top, as I can't rebase my
> public tree.
Attached.
Thierry
[-- Attachment #1.2: 0001-fbcon-Avoid-deleting-a-timer-in-IRQ-context.patch --]
[-- Type: text/x-diff, Size: 3447 bytes --]
From 4f2f70dbbe9de54c0da9b03a1f384e1464755eab Mon Sep 17 00:00:00 2001
From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Date: Wed, 20 May 2015 13:41:52 +0200
Subject: [PATCH] fbcon: Avoid deleting a timer in IRQ context
Commit 27a4c827c34a ("fbcon: use the cursor blink interval provided by
vt") unconditionally removes the cursor blink timer. Unfortunately that
wreaks havoc under some circumstances. An easily reproducible way is to
use both the framebuffer console and a debug serial port as the console
output for kernel messages (e.g. "console=ttyS0 console=tty1" on the
kernel command-line. Upon boot this triggers a warning from within the
del_timer_sync() function because it is called from IRQ context:
[ 5.070096] ------------[ cut here ]------------
[ 5.070110] WARNING: CPU: 0 PID: 0 at ../kernel/time/timer.c:1098 del_timer_sync+0x4c/0x54()
[ 5.070115] Modules linked in:
[ 5.070120] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.0-rc4-next-20150519 #1
[ 5.070123] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 5.070142] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[ 5.070156] [] (show_stack) from [] (dump_stack+0x70/0xbc)
[ 5.070164] [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0)
[ 5.070169] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24)
[ 5.070174] [] (warn_slowpath_null) from [] (del_timer_sync+0x4c/0x54)
[ 5.070183] [] (del_timer_sync) from [] (fbcon_del_cursor_timer+0x2c/0x40)
[ 5.070190] [] (fbcon_del_cursor_timer) from [] (fbcon_cursor+0x9c/0x180)
[ 5.070198] [] (fbcon_cursor) from [] (hide_cursor+0x30/0x98)
[ 5.070204] [] (hide_cursor) from [] (vt_console_print+0x2a8/0x340)
[ 5.070212] [] (vt_console_print) from [] (call_console_drivers.constprop.23+0xc8/0xec)
[ 5.070218] [] (call_console_drivers.constprop.23) from [] (console_unlock+0x498/0x4f0)
[ 5.070223] [] (console_unlock) from [] (vprintk_emit+0x1f0/0x508)
[ 5.070228] [] (vprintk_emit) from [] (vprintk_default+0x24/0x2c)
[ 5.070234] [] (vprintk_default) from [] (printk+0x70/0x88)
After which the system starts spewing all kinds of weird and seemingly
unrelated error messages.
This commit fixes this by restoring the condition under which the call
to fbcon_del_cursor_timer() happens.
Reported-by: Daniel Stone <daniel-rLtY4a/8tF1rovVCs/uTlw@public.gmane.org>
Reported-by: Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Tested-by: Kevin Hilman <khilman-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Tested-by: Scot Doyle <lkml14-enLWO88E2pdl57MIdRCFDg@public.gmane.org>
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
drivers/video/console/fbcon.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 05b1d1a71ef9..658c34bb9076 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -1310,8 +1310,9 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
return;
ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
- fbcon_del_cursor_timer(info);
- if (!(vc->vc_cursor_type & 0x10))
+ if (vc->vc_cursor_type & 0x10)
+ fbcon_del_cursor_timer(info);
+ else
fbcon_add_cursor_timer(info);
ops->cursor_flash = (mode == CM_ERASE) ? 0 : 1;
--
2.4.1
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* Re: [RFC PATCH v2] perf: Add PERF_EVENT_IOC_FLUSH ioctl
From: Ingo Molnar @ 2015-05-20 12:12 UTC (permalink / raw)
To: Robert Bragg
Cc: intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Daniel Vetter,
Jani Nikula, David Airlie, Peter Zijlstra, Paul Mackerras,
Ingo Molnar, Arnaldo Carvalho de Melo,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-api-u79uwXL29TY76Z2rM5mHXA, Chris Wilson
In-Reply-To: <1431969919-32233-1-git-send-email-robert-St23OQVBDYPNLxjTenLetw@public.gmane.org>
* Robert Bragg <robert-St23OQVBDYPNLxjTenLetw@public.gmane.org> wrote:
> To allow for pmus that may have internal buffering (e.g. the hardware
> itself writes out data to its own circular buffer which is only
> periodically forwarded to userspace via perf) this ioctl enables
> userspace to explicitly ensure it has received all samples before a
> point in time.
>
> v2: return int error status
>
> Signed-off-by: Robert Bragg <robert-St23OQVBDYPNLxjTenLetw@public.gmane.org>
> ---
> include/linux/perf_event.h | 7 +++++++
> include/uapi/linux/perf_event.h | 1 +
> kernel/events/core.c | 5 +++++
> 3 files changed, 13 insertions(+)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index cf1d096..0c591eb 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -305,6 +305,13 @@ struct pmu {
> * Free pmu-private AUX data structures
> */
> void (*free_aux) (void *aux); /* optional */
> +
> + /*
> + * Flush buffered samples (E.g. for pmu hardware that writes samples to
> + * some intermediate buffer) userspace may need to explicitly ensure
> + * such samples have been forwarded to perf.
> + */
> + int (*flush) (struct perf_event *event); /*optional */
> };
>
> /**
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 309211b..cbf1b80 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -389,6 +389,7 @@ struct perf_event_attr {
> #define PERF_EVENT_IOC_SET_FILTER _IOW('$', 6, char *)
> #define PERF_EVENT_IOC_ID _IOR('$', 7, __u64 *)
> #define PERF_EVENT_IOC_SET_BPF _IOW('$', 8, __u32)
> +#define PERF_EVENT_IOC_FLUSH _IO ('$', 9)
>
> enum perf_event_ioc_flags {
> PERF_IOC_FLAG_GROUP = 1U << 0,
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 3fe532a..72daee6 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -4079,6 +4079,11 @@ static long _perf_ioctl(struct perf_event *event, unsigned int cmd, unsigned lon
> case PERF_EVENT_IOC_SET_BPF:
> return perf_event_set_bpf_prog(event, arg);
>
> + case PERF_EVENT_IOC_FLUSH:
> + if (event->pmu->flush)
> + return event->pmu->flush(event);
> + return 0;
> +
> default:
> return -ENOTTY;
> }
So 'struct file_operations' has a callback for:
int (*fsync) (struct file *, loff_t, loff_t, int datasync);
Could we use that perhaps, instead of an ioctl()? Not sure how it all
integrates with the VFS though.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v2 2/3] fbcon: use the cursor blink interval provided by vt
From: Scot Doyle @ 2015-05-20 0:36 UTC (permalink / raw)
To: Thierry Reding
Cc: Kevin Hilman, Scot Doyle, Greg Kroah-Hartman, Tomi Valkeinen,
Michael Kerrisk, Jiri Slaby, Jean-Christophe Plagniol-Villard,
Pavel Machek, Geert Uytterhoeven, lkml, linux-fbdev, linux-man,
linux-api, Tyler Baker, Olof Johansson, Daniel Stone,
Arnd Bergmann
In-Reply-To: <20150519215228.GA27163@ulmo.nvidia.com>
On Tue, 19 May 2015, Thierry Reding wrote:
> On Tue, May 19, 2015 at 02:45:19PM -0700, Kevin Hilman wrote:
> > On Tue, May 19, 2015 at 2:40 PM, Thierry Reding
> > <thierry.reding@gmail.com> wrote:
...
> > >
> > > FWIW, if I apply the below on top of next-20150519 things seem to be
> > > back to normal as well:
> > >
> > > diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> > > index 05b1d1a71ef9..658c34bb9076 100644
> > > --- a/drivers/video/console/fbcon.c
> > > +++ b/drivers/video/console/fbcon.c
> > > @@ -1310,8 +1310,9 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
> > > return;
> > >
> > > ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
> > > - fbcon_del_cursor_timer(info);
> > > - if (!(vc->vc_cursor_type & 0x10))
> > > + if (vc->vc_cursor_type & 0x10)
> > > + fbcon_del_cursor_timer(info);
> > > + else
> > > fbcon_add_cursor_timer(info);
> > >
> > > ops->cursor_flash = (mode == CM_ERASE) ? 0 : 1;
> >
> > Applying this on next-20150519 makes my exynos board happily boot again as well.
> >
> > Tested-by: Kevin Hilman <khilman@linaro.org>
>
> Excellent. Greg, Scot, any opinions on whether or not this is the right
> thing to do? It restores a bit that looks suspiciously like it snuck in
> in the original (at least it isn't documented in the commit message).
>
> Greg, feel free to squash this in if everybody agrees this is good to
> go. If you prefer a patch on top let me know and I'll come up with a
> proper commit message.
>
> Thierry
Hi all, sorry for the trouble.
The timer delete was to prevent blink stutter when updating the interval.
Since the stutter isn't so noticable when changing from the default 200ms,
and since most people seem to prefer leaving the fbcon code alone if
possible, I agree with Thierry's approach.
Tested-by: Scot Doyle <lkml14@scotdoyle.com>
^ permalink raw reply
* Re: [PATCH net-next 1/4] bpf: allow bpf programs to tail-call other bpf programs
From: Alexei Starovoitov @ 2015-05-20 0:18 UTC (permalink / raw)
To: Andy Lutomirski
Cc: David S. Miller, Ingo Molnar, Daniel Borkmann, Michael Holzheu,
Zi Shen Lim, Linux API, Network Development,
linux-kernel@vger.kernel.org
In-Reply-To: <CALCETrVP=7sCM12cCZVZCCMozGcHyqTsOFvjv7cEpc7Frxj4Xg@mail.gmail.com>
On 5/19/15 5:13 PM, Andy Lutomirski wrote:
>
> IMO this is starting to get a bit ugly. Would it be possible to have
> the program dereference the subprogram reference itself from the jump
> table? There would have to be a verifier type that represents a
> reference to a program tail-call entry point, but that seems better
> than having this weird indirection.
Which part? I don't think you've looked at examples yet.
network parser has to call itself. Otherwise we cannot parse 10 mpls
labels or TLVs.
Indirection via jump_table also has to be there.
We need to dynamically add and remove programs form this jump table.
It cannot be all static.
^ permalink raw reply
* Re: [PATCH net-next 2/4] x86: bpf_jit: implement bpf_tail_call() helper
From: Alexei Starovoitov @ 2015-05-20 0:14 UTC (permalink / raw)
To: Andy Lutomirski
Cc: David S. Miller, Ingo Molnar, Daniel Borkmann, Michael Holzheu,
Zi Shen Lim, Linux API, Network Development,
linux-kernel@vger.kernel.org
In-Reply-To: <CALCETrVZyB+m8Oaad1JGwrLx1rTUoL0F6Afrvg_hQWiYyTTang@mail.gmail.com>
On 5/19/15 5:11 PM, Andy Lutomirski wrote:
> On Tue, May 19, 2015 at 4:59 PM, Alexei Starovoitov <ast@plumgrid.com> wrote:
>> bpf_tail_call() arguments:
>> ctx - context pointer
>> jmp_table - one of BPF_MAP_TYPE_PROG_ARRAY maps used as the jump table
>> index - index in the jump table
>>
>> In this implementation x64 JIT bypasses stack unwind and jumps into the
>> callee program after prologue, so the callee program reuses the same stack.
>>
>> The logic can be roughly expressed in C like:
>>
>> u32 tail_call_cnt;
>>
>> void *jumptable[2] = { &&label1, &&label2 };
>>
>> int bpf_prog1(void *ctx)
>> {
>> label1:
>> ...
>> }
>>
>> int bpf_prog2(void *ctx)
>> {
>> label2:
>> ...
>> }
>>
>> int bpf_prog1(void *ctx)
>> {
>> ...
>> if (tail_call_cnt++ < MAX_TAIL_CALL_CNT)
>> goto *jumptable[index]; ... and pass my 'ctx' to callee ...
>>
>> ... fall through if no entry in jumptable ...
>> }
>>
>
> What causes the stack pointer to be right? Is there some reason that
> the stack pointer is the same no matter where you are in the generated
> code?
that's why I said 'it's _roughly_ expressed in C' this way.
Stack pointer doesn't change. It uses the same stack frame.
^ permalink raw reply
* Re: [PATCH net-next 1/4] bpf: allow bpf programs to tail-call other bpf programs
From: Andy Lutomirski @ 2015-05-20 0:13 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Ingo Molnar, Daniel Borkmann, Michael Holzheu,
Zi Shen Lim, Linux API, Network Development,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1432079946-9878-2-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
On Tue, May 19, 2015 at 4:59 PM, Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org> wrote:
> introduce bpf_tail_call(ctx, &jmp_table, index) helper function
> which can be used from BPF programs like:
> int bpf_prog(struct pt_regs *ctx)
> {
> ...
> bpf_tail_call(ctx, &jmp_table, index);
> ...
> }
> that is roughly equivalent to:
> int bpf_prog(struct pt_regs *ctx)
> {
> ...
> if (jmp_table[index])
> return (*jmp_table[index])(ctx);
> ...
> }
> The important detail that it's not a normal call, but a tail call.
> The kernel stack is precious, so this helper reuses the current
> stack frame and jumps into another BPF program without adding
> extra call frame.
> It's trivially done in interpreter and a bit trickier in JITs.
> In case of x64 JIT the bigger part of generated assembler prologue
> is common for all programs, so it is simply skipped while jumping.
> Other JITs can do similar prologue-skipping optimization or
> do stack unwind before jumping into the next program.
>
> bpf_tail_call() arguments:
> ctx - context pointer
> jmp_table - one of BPF_MAP_TYPE_PROG_ARRAY maps used as the jump table
> index - index in the jump table
>
> Since all BPF programs are idenitified by file descriptor, user space
> need to populate the jmp_table with FDs of other BPF programs.
> If jmp_table[index] is empty the bpf_tail_call() doesn't jump anywhere
> and program execution continues as normal.
>
> New BPF_MAP_TYPE_PROG_ARRAY map type is introduced so that user space can
> populate this jmp_table array with FDs of other bpf programs.
> Programs can share the same jmp_table array or use multiple jmp_tables.
>
> The chain of tail calls can form unpredictable dynamic loops therefore
> tail_call_cnt is used to limit the number of calls and currently is set to 32.
IMO this is starting to get a bit ugly. Would it be possible to have
the program dereference the subprogram reference itself from the jump
table? There would have to be a verifier type that represents a
reference to a program tail-call entry point, but that seems better
than having this weird indirection.
--Andy
^ permalink raw reply
* Re: [PATCH net-next 2/4] x86: bpf_jit: implement bpf_tail_call() helper
From: Andy Lutomirski @ 2015-05-20 0:11 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Ingo Molnar, Daniel Borkmann, Michael Holzheu,
Zi Shen Lim, Linux API, Network Development,
linux-kernel@vger.kernel.org
In-Reply-To: <1432079946-9878-3-git-send-email-ast@plumgrid.com>
On Tue, May 19, 2015 at 4:59 PM, Alexei Starovoitov <ast@plumgrid.com> wrote:
> bpf_tail_call() arguments:
> ctx - context pointer
> jmp_table - one of BPF_MAP_TYPE_PROG_ARRAY maps used as the jump table
> index - index in the jump table
>
> In this implementation x64 JIT bypasses stack unwind and jumps into the
> callee program after prologue, so the callee program reuses the same stack.
>
> The logic can be roughly expressed in C like:
>
> u32 tail_call_cnt;
>
> void *jumptable[2] = { &&label1, &&label2 };
>
> int bpf_prog1(void *ctx)
> {
> label1:
> ...
> }
>
> int bpf_prog2(void *ctx)
> {
> label2:
> ...
> }
>
> int bpf_prog1(void *ctx)
> {
> ...
> if (tail_call_cnt++ < MAX_TAIL_CALL_CNT)
> goto *jumptable[index]; ... and pass my 'ctx' to callee ...
>
> ... fall through if no entry in jumptable ...
> }
>
What causes the stack pointer to be right? Is there some reason that
the stack pointer is the same no matter where you are in the generated
code?
--Andy
^ permalink raw reply
* [PATCH net-next 4/4] samples/bpf: bpf_tail_call example for networking
From: Alexei Starovoitov @ 2015-05-19 23:59 UTC (permalink / raw)
To: David S. Miller
Cc: Ingo Molnar, Daniel Borkmann, Michael Holzheu, Zi Shen Lim,
linux-api, netdev, linux-kernel
In-Reply-To: <1432079946-9878-1-git-send-email-ast@plumgrid.com>
Usage:
$ sudo ./sockex3
IP src.port -> dst.port bytes packets
127.0.0.1.42010 -> 127.0.0.1.12865 1568 8
127.0.0.1.59526 -> 127.0.0.1.33778 11422636 173070
127.0.0.1.33778 -> 127.0.0.1.59526 11260224828 341974
127.0.0.1.12865 -> 127.0.0.1.42010 1832 12
IP src.port -> dst.port bytes packets
127.0.0.1.42010 -> 127.0.0.1.12865 1568 8
127.0.0.1.59526 -> 127.0.0.1.33778 23198092 351486
127.0.0.1.33778 -> 127.0.0.1.59526 22972698518 698616
127.0.0.1.12865 -> 127.0.0.1.42010 1832 12
this example is similar to sockex2 in a way that it accumulates per-flow
statistics, but it does packet parsing differently.
sockex2 inlines full packet parser routine into single bpf program.
This sockex3 example have 4 independent programs that parse vlan, mpls, ip, ipv6
and one main program that starts the process.
bpf_tail_call() mechanism allows each program to be small and be called
on demand potentially multiple times, so that many vlan, mpls, ip in ip,
gre encapsulations can be parsed. These and other protocol parsers can
be added or removed at runtime. TLVs can be parsed in similar manner.
Note, tail_call_cnt dynamic check limits the number of tail calls to 32.
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
---
samples/bpf/Makefile | 4 +
samples/bpf/bpf_helpers.h | 2 +
samples/bpf/sockex3_kern.c | 303 ++++++++++++++++++++++++++++++++++++++++++++
samples/bpf/sockex3_user.c | 66 ++++++++++
4 files changed, 375 insertions(+)
create mode 100644 samples/bpf/sockex3_kern.c
create mode 100644 samples/bpf/sockex3_user.c
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index ded10d05617e..46c6a8cf74d3 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -6,6 +6,7 @@ hostprogs-y := test_verifier test_maps
hostprogs-y += sock_example
hostprogs-y += sockex1
hostprogs-y += sockex2
+hostprogs-y += sockex3
hostprogs-y += tracex1
hostprogs-y += tracex2
hostprogs-y += tracex3
@@ -17,6 +18,7 @@ test_maps-objs := test_maps.o libbpf.o
sock_example-objs := sock_example.o libbpf.o
sockex1-objs := bpf_load.o libbpf.o sockex1_user.o
sockex2-objs := bpf_load.o libbpf.o sockex2_user.o
+sockex3-objs := bpf_load.o libbpf.o sockex3_user.o
tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
tracex2-objs := bpf_load.o libbpf.o tracex2_user.o
tracex3-objs := bpf_load.o libbpf.o tracex3_user.o
@@ -27,6 +29,7 @@ tracex5-objs := bpf_load.o libbpf.o tracex5_user.o
always := $(hostprogs-y)
always += sockex1_kern.o
always += sockex2_kern.o
+always += sockex3_kern.o
always += tracex1_kern.o
always += tracex2_kern.o
always += tracex3_kern.o
@@ -39,6 +42,7 @@ HOSTCFLAGS += -I$(objtree)/usr/include
HOSTCFLAGS_bpf_load.o += -I$(objtree)/usr/include -Wno-unused-variable
HOSTLOADLIBES_sockex1 += -lelf
HOSTLOADLIBES_sockex2 += -lelf
+HOSTLOADLIBES_sockex3 += -lelf
HOSTLOADLIBES_tracex1 += -lelf
HOSTLOADLIBES_tracex2 += -lelf
HOSTLOADLIBES_tracex3 += -lelf
diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
index 699ed8dbdd64..f531a0b3282d 100644
--- a/samples/bpf/bpf_helpers.h
+++ b/samples/bpf/bpf_helpers.h
@@ -23,6 +23,8 @@ static int (*bpf_trace_printk)(const char *fmt, int fmt_size, ...) =
(void *) BPF_FUNC_trace_printk;
static void (*bpf_tail_call)(void *ctx, void *map, int index) =
(void *) BPF_FUNC_tail_call;
+static unsigned long long (*bpf_get_smp_processor_id)(void) =
+ (void *) BPF_FUNC_get_smp_processor_id;
/* llvm builtin functions that eBPF C program may use to
* emit BPF_LD_ABS and BPF_LD_IND instructions
diff --git a/samples/bpf/sockex3_kern.c b/samples/bpf/sockex3_kern.c
new file mode 100644
index 000000000000..f1576341daa6
--- /dev/null
+++ b/samples/bpf/sockex3_kern.c
@@ -0,0 +1,303 @@
+/* Copyright (c) 2015 PLUMgrid, http://plumgrid.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include <uapi/linux/bpf.h>
+#include "bpf_helpers.h"
+#include <uapi/linux/in.h>
+#include <uapi/linux/if.h>
+#include <uapi/linux/if_ether.h>
+#include <uapi/linux/ip.h>
+#include <uapi/linux/ipv6.h>
+#include <uapi/linux/if_tunnel.h>
+#include <uapi/linux/mpls.h>
+#define IP_MF 0x2000
+#define IP_OFFSET 0x1FFF
+
+#define PROG(F) SEC("socket/"__stringify(F)) int bpf_func_##F
+
+struct bpf_map_def SEC("maps") jmp_table = {
+ .type = BPF_MAP_TYPE_PROG_ARRAY,
+ .key_size = sizeof(u32),
+ .value_size = sizeof(u32),
+ .max_entries = 8,
+};
+
+#define PARSE_VLAN 1
+#define PARSE_MPLS 2
+#define PARSE_IP 3
+#define PARSE_IPV6 4
+
+/* protocol dispatch routine.
+ * It tail-calls next BPF program depending on eth proto
+ * Note, we could have used:
+ * bpf_tail_call(skb, &jmp_table, proto);
+ * but it would need large prog_array
+ */
+static inline void parse_eth_proto(struct __sk_buff *skb, u32 proto)
+{
+ switch (proto) {
+ case ETH_P_8021Q:
+ case ETH_P_8021AD:
+ bpf_tail_call(skb, &jmp_table, PARSE_VLAN);
+ break;
+ case ETH_P_MPLS_UC:
+ case ETH_P_MPLS_MC:
+ bpf_tail_call(skb, &jmp_table, PARSE_MPLS);
+ break;
+ case ETH_P_IP:
+ bpf_tail_call(skb, &jmp_table, PARSE_IP);
+ break;
+ case ETH_P_IPV6:
+ bpf_tail_call(skb, &jmp_table, PARSE_IPV6);
+ break;
+ }
+}
+
+struct vlan_hdr {
+ __be16 h_vlan_TCI;
+ __be16 h_vlan_encapsulated_proto;
+};
+
+struct flow_keys {
+ __be32 src;
+ __be32 dst;
+ union {
+ __be32 ports;
+ __be16 port16[2];
+ };
+ __u32 ip_proto;
+};
+
+static inline int ip_is_fragment(struct __sk_buff *ctx, __u64 nhoff)
+{
+ return load_half(ctx, nhoff + offsetof(struct iphdr, frag_off))
+ & (IP_MF | IP_OFFSET);
+}
+
+static inline __u32 ipv6_addr_hash(struct __sk_buff *ctx, __u64 off)
+{
+ __u64 w0 = load_word(ctx, off);
+ __u64 w1 = load_word(ctx, off + 4);
+ __u64 w2 = load_word(ctx, off + 8);
+ __u64 w3 = load_word(ctx, off + 12);
+
+ return (__u32)(w0 ^ w1 ^ w2 ^ w3);
+}
+
+struct globals {
+ struct flow_keys flow;
+ __u32 nhoff;
+};
+
+struct bpf_map_def SEC("maps") percpu_map = {
+ .type = BPF_MAP_TYPE_ARRAY,
+ .key_size = sizeof(__u32),
+ .value_size = sizeof(struct globals),
+ .max_entries = 32,
+};
+
+/* user poor man's per_cpu until native support is ready */
+static struct globals *this_cpu_globals(void)
+{
+ u32 key = bpf_get_smp_processor_id();
+
+ return bpf_map_lookup_elem(&percpu_map, &key);
+}
+
+/* some simple stats for user space consumption */
+struct pair {
+ __u64 packets;
+ __u64 bytes;
+};
+
+struct bpf_map_def SEC("maps") hash_map = {
+ .type = BPF_MAP_TYPE_HASH,
+ .key_size = sizeof(struct flow_keys),
+ .value_size = sizeof(struct pair),
+ .max_entries = 1024,
+};
+
+static void update_stats(struct __sk_buff *skb, struct globals *g)
+{
+ struct flow_keys key = g->flow;
+ struct pair *value;
+
+ value = bpf_map_lookup_elem(&hash_map, &key);
+ if (value) {
+ __sync_fetch_and_add(&value->packets, 1);
+ __sync_fetch_and_add(&value->bytes, skb->len);
+ } else {
+ struct pair val = {1, skb->len};
+
+ bpf_map_update_elem(&hash_map, &key, &val, BPF_ANY);
+ }
+}
+
+static __always_inline void parse_ip_proto(struct __sk_buff *skb,
+ struct globals *g, __u32 ip_proto)
+{
+ __u32 nhoff = g->nhoff;
+ int poff;
+
+ switch (ip_proto) {
+ case IPPROTO_GRE: {
+ struct gre_hdr {
+ __be16 flags;
+ __be16 proto;
+ };
+
+ __u32 gre_flags = load_half(skb,
+ nhoff + offsetof(struct gre_hdr, flags));
+ __u32 gre_proto = load_half(skb,
+ nhoff + offsetof(struct gre_hdr, proto));
+
+ if (gre_flags & (GRE_VERSION|GRE_ROUTING))
+ break;
+
+ nhoff += 4;
+ if (gre_flags & GRE_CSUM)
+ nhoff += 4;
+ if (gre_flags & GRE_KEY)
+ nhoff += 4;
+ if (gre_flags & GRE_SEQ)
+ nhoff += 4;
+
+ g->nhoff = nhoff;
+ parse_eth_proto(skb, gre_proto);
+ break;
+ }
+ case IPPROTO_IPIP:
+ parse_eth_proto(skb, ETH_P_IP);
+ break;
+ case IPPROTO_IPV6:
+ parse_eth_proto(skb, ETH_P_IPV6);
+ break;
+ case IPPROTO_TCP:
+ case IPPROTO_UDP:
+ g->flow.ports = load_word(skb, nhoff);
+ case IPPROTO_ICMP:
+ g->flow.ip_proto = ip_proto;
+ update_stats(skb, g);
+ break;
+ default:
+ break;
+ }
+}
+
+PROG(PARSE_IP)(struct __sk_buff *skb)
+{
+ struct globals *g = this_cpu_globals();
+ __u32 nhoff, verlen, ip_proto;
+
+ if (!g)
+ return 0;
+
+ nhoff = g->nhoff;
+
+ if (unlikely(ip_is_fragment(skb, nhoff)))
+ return 0;
+
+ ip_proto = load_byte(skb, nhoff + offsetof(struct iphdr, protocol));
+
+ if (ip_proto != IPPROTO_GRE) {
+ g->flow.src = load_word(skb, nhoff + offsetof(struct iphdr, saddr));
+ g->flow.dst = load_word(skb, nhoff + offsetof(struct iphdr, daddr));
+ }
+
+ verlen = load_byte(skb, nhoff + 0/*offsetof(struct iphdr, ihl)*/);
+ nhoff += (verlen & 0xF) << 2;
+
+ g->nhoff = nhoff;
+ parse_ip_proto(skb, g, ip_proto);
+ return 0;
+}
+
+PROG(PARSE_IPV6)(struct __sk_buff *skb)
+{
+ struct globals *g = this_cpu_globals();
+ __u32 nhoff, ip_proto;
+
+ if (!g)
+ return 0;
+
+ nhoff = g->nhoff;
+
+ ip_proto = load_byte(skb,
+ nhoff + offsetof(struct ipv6hdr, nexthdr));
+ g->flow.src = ipv6_addr_hash(skb,
+ nhoff + offsetof(struct ipv6hdr, saddr));
+ g->flow.dst = ipv6_addr_hash(skb,
+ nhoff + offsetof(struct ipv6hdr, daddr));
+ nhoff += sizeof(struct ipv6hdr);
+
+ g->nhoff = nhoff;
+ parse_ip_proto(skb, g, ip_proto);
+ return 0;
+}
+
+PROG(PARSE_VLAN)(struct __sk_buff *skb)
+{
+ struct globals *g = this_cpu_globals();
+ __u32 nhoff, proto;
+
+ if (!g)
+ return 0;
+
+ nhoff = g->nhoff;
+
+ proto = load_half(skb, nhoff + offsetof(struct vlan_hdr,
+ h_vlan_encapsulated_proto));
+ nhoff += sizeof(struct vlan_hdr);
+ g->nhoff = nhoff;
+
+ parse_eth_proto(skb, proto);
+
+ return 0;
+}
+
+PROG(PARSE_MPLS)(struct __sk_buff *skb)
+{
+ struct globals *g = this_cpu_globals();
+ __u32 nhoff, label;
+
+ if (!g)
+ return 0;
+
+ nhoff = g->nhoff;
+
+ label = load_word(skb, nhoff);
+ nhoff += sizeof(struct mpls_label);
+ g->nhoff = nhoff;
+
+ if (label & MPLS_LS_S_MASK) {
+ __u8 verlen = load_byte(skb, nhoff);
+ if ((verlen & 0xF0) == 4)
+ parse_eth_proto(skb, ETH_P_IP);
+ else
+ parse_eth_proto(skb, ETH_P_IPV6);
+ } else {
+ parse_eth_proto(skb, ETH_P_MPLS_UC);
+ }
+
+ return 0;
+}
+
+SEC("socket/0")
+int main_prog(struct __sk_buff *skb)
+{
+ struct globals *g = this_cpu_globals();
+ __u32 nhoff = ETH_HLEN;
+ __u32 proto = load_half(skb, 12);
+
+ if (!g)
+ return 0;
+
+ g->nhoff = nhoff;
+ parse_eth_proto(skb, proto);
+ return 0;
+}
+
+char _license[] SEC("license") = "GPL";
diff --git a/samples/bpf/sockex3_user.c b/samples/bpf/sockex3_user.c
new file mode 100644
index 000000000000..2617772d060d
--- /dev/null
+++ b/samples/bpf/sockex3_user.c
@@ -0,0 +1,66 @@
+#include <stdio.h>
+#include <assert.h>
+#include <linux/bpf.h>
+#include "libbpf.h"
+#include "bpf_load.h"
+#include <unistd.h>
+#include <arpa/inet.h>
+
+struct flow_keys {
+ __be32 src;
+ __be32 dst;
+ union {
+ __be32 ports;
+ __be16 port16[2];
+ };
+ __u32 ip_proto;
+};
+
+struct pair {
+ __u64 packets;
+ __u64 bytes;
+};
+
+int main(int argc, char **argv)
+{
+ char filename[256];
+ FILE *f;
+ int i, sock;
+
+ snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);
+
+ if (load_bpf_file(filename)) {
+ printf("%s", bpf_log_buf);
+ return 1;
+ }
+
+ sock = open_raw_sock("lo");
+
+ assert(setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, &prog_fd[4],
+ sizeof(__u32)) == 0);
+
+ if (argc > 1)
+ f = popen("ping -c5 localhost", "r");
+ else
+ f = popen("netperf -l 4 localhost", "r");
+ (void) f;
+
+ for (i = 0; i < 5; i++) {
+ struct flow_keys key = {}, next_key;
+ struct pair value;
+
+ sleep(1);
+ printf("IP src.port -> dst.port bytes packets\n");
+ while (bpf_get_next_key(map_fd[2], &key, &next_key) == 0) {
+ bpf_lookup_elem(map_fd[2], &next_key, &value);
+ printf("%s.%05d -> %s.%05d %12lld %12lld\n",
+ inet_ntoa((struct in_addr){htonl(next_key.src)}),
+ next_key.port16[0],
+ inet_ntoa((struct in_addr){htonl(next_key.dst)}),
+ next_key.port16[1],
+ value.bytes, value.packets);
+ key = next_key;
+ }
+ }
+ return 0;
+}
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next 3/4] samples/bpf: bpf_tail_call example for tracing
From: Alexei Starovoitov @ 2015-05-19 23:59 UTC (permalink / raw)
To: David S. Miller
Cc: Ingo Molnar, Daniel Borkmann, Michael Holzheu, Zi Shen Lim,
linux-api, netdev, linux-kernel
In-Reply-To: <1432079946-9878-1-git-send-email-ast@plumgrid.com>
kprobe example that demonstrates how future seccomp programs may look like.
It attaches to seccomp_phase1() function and tail-calls other BPF programs
depending on syscall number.
Existing optimized classic BPF seccomp programs generated by Chrome look like:
if (sd.nr < 121) {
if (sd.nr < 57) {
if (sd.nr < 22) {
if (sd.nr < 7) {
if (sd.nr < 4) {
if (sd.nr < 1) {
check sys_read
} else {
if (sd.nr < 3) {
check sys_write and sys_open
} else {
check sys_close
}
}
} else {
} else {
} else {
} else {
} else {
}
the future seccomp using native eBPF may look like:
bpf_tail_call(&sd, &syscall_jmp_table, sd.nr);
which is simpler, faster and leaves more room for per-syscall checks.
Usage:
$ sudo ./tracex5
<...>-366 [001] d... 4.870033: : read(fd=1, buf=00007f6d5bebf000, size=771)
<...>-369 [003] d... 4.870066: : mmap
<...>-369 [003] d... 4.870077: : syscall=110 (one of get/set uid/pid/gid)
<...>-369 [003] d... 4.870089: : syscall=107 (one of get/set uid/pid/gid)
sh-369 [000] d... 4.891740: : read(fd=0, buf=00000000023d1000, size=512)
sh-369 [000] d... 4.891747: : write(fd=1, buf=00000000023d3000, size=512)
sh-369 [000] d... 4.891747: : read(fd=1, buf=00000000023d3000, size=512)
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
---
samples/bpf/Makefile | 4 +++
samples/bpf/bpf_helpers.h | 2 ++
samples/bpf/bpf_load.c | 57 ++++++++++++++++++++++++++-------
samples/bpf/tracex5_kern.c | 75 ++++++++++++++++++++++++++++++++++++++++++++
samples/bpf/tracex5_user.c | 46 +++++++++++++++++++++++++++
5 files changed, 172 insertions(+), 12 deletions(-)
create mode 100644 samples/bpf/tracex5_kern.c
create mode 100644 samples/bpf/tracex5_user.c
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 8fdbd73429dd..ded10d05617e 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -10,6 +10,7 @@ hostprogs-y += tracex1
hostprogs-y += tracex2
hostprogs-y += tracex3
hostprogs-y += tracex4
+hostprogs-y += tracex5
test_verifier-objs := test_verifier.o libbpf.o
test_maps-objs := test_maps.o libbpf.o
@@ -20,6 +21,7 @@ tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
tracex2-objs := bpf_load.o libbpf.o tracex2_user.o
tracex3-objs := bpf_load.o libbpf.o tracex3_user.o
tracex4-objs := bpf_load.o libbpf.o tracex4_user.o
+tracex5-objs := bpf_load.o libbpf.o tracex5_user.o
# Tell kbuild to always build the programs
always := $(hostprogs-y)
@@ -29,6 +31,7 @@ always += tracex1_kern.o
always += tracex2_kern.o
always += tracex3_kern.o
always += tracex4_kern.o
+always += tracex5_kern.o
always += tcbpf1_kern.o
HOSTCFLAGS += -I$(objtree)/usr/include
@@ -40,6 +43,7 @@ HOSTLOADLIBES_tracex1 += -lelf
HOSTLOADLIBES_tracex2 += -lelf
HOSTLOADLIBES_tracex3 += -lelf
HOSTLOADLIBES_tracex4 += -lelf -lrt
+HOSTLOADLIBES_tracex5 += -lelf
# point this to your LLVM backend with bpf support
LLC=$(srctree)/tools/bpf/llvm/bld/Debug+Asserts/bin/llc
diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
index f960b5fb3ed8..699ed8dbdd64 100644
--- a/samples/bpf/bpf_helpers.h
+++ b/samples/bpf/bpf_helpers.h
@@ -21,6 +21,8 @@ static unsigned long long (*bpf_ktime_get_ns)(void) =
(void *) BPF_FUNC_ktime_get_ns;
static int (*bpf_trace_printk)(const char *fmt, int fmt_size, ...) =
(void *) BPF_FUNC_trace_printk;
+static void (*bpf_tail_call)(void *ctx, void *map, int index) =
+ (void *) BPF_FUNC_tail_call;
/* llvm builtin functions that eBPF C program may use to
* emit BPF_LD_ABS and BPF_LD_IND instructions
diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
index 38dac5a53b51..da86a8e0a95a 100644
--- a/samples/bpf/bpf_load.c
+++ b/samples/bpf/bpf_load.c
@@ -16,6 +16,7 @@
#include <sys/ioctl.h>
#include <sys/mman.h>
#include <poll.h>
+#include <ctype.h>
#include "libbpf.h"
#include "bpf_helpers.h"
#include "bpf_load.h"
@@ -29,6 +30,19 @@ int map_fd[MAX_MAPS];
int prog_fd[MAX_PROGS];
int event_fd[MAX_PROGS];
int prog_cnt;
+int prog_array_fd = -1;
+
+static int populate_prog_array(const char *event, int prog_fd)
+{
+ int ind = atoi(event), err;
+
+ err = bpf_update_elem(prog_array_fd, &ind, &prog_fd, BPF_ANY);
+ if (err < 0) {
+ printf("failed to store prog_fd in prog_array\n");
+ return -1;
+ }
+ return 0;
+}
static int load_and_attach(const char *event, struct bpf_insn *prog, int size)
{
@@ -54,12 +68,40 @@ static int load_and_attach(const char *event, struct bpf_insn *prog, int size)
return -1;
}
+ fd = bpf_prog_load(prog_type, prog, size, license, kern_version);
+ if (fd < 0) {
+ printf("bpf_prog_load() err=%d\n%s", errno, bpf_log_buf);
+ return -1;
+ }
+
+ prog_fd[prog_cnt++] = fd;
+
+ if (is_socket) {
+ event += 6;
+ if (*event != '/')
+ return 0;
+ event++;
+ if (!isdigit(*event)) {
+ printf("invalid prog number\n");
+ return -1;
+ }
+ return populate_prog_array(event, fd);
+ }
+
if (is_kprobe || is_kretprobe) {
if (is_kprobe)
event += 7;
else
event += 10;
+ if (*event == 0) {
+ printf("event name cannot be empty\n");
+ return -1;
+ }
+
+ if (isdigit(*event))
+ return populate_prog_array(event, fd);
+
snprintf(buf, sizeof(buf),
"echo '%c:%s %s' >> /sys/kernel/debug/tracing/kprobe_events",
is_kprobe ? 'p' : 'r', event, event);
@@ -71,18 +113,6 @@ static int load_and_attach(const char *event, struct bpf_insn *prog, int size)
}
}
- fd = bpf_prog_load(prog_type, prog, size, license, kern_version);
-
- if (fd < 0) {
- printf("bpf_prog_load() err=%d\n%s", errno, bpf_log_buf);
- return -1;
- }
-
- prog_fd[prog_cnt++] = fd;
-
- if (is_socket)
- return 0;
-
strcpy(buf, DEBUGFS);
strcat(buf, "events/kprobes/");
strcat(buf, event);
@@ -130,6 +160,9 @@ static int load_maps(struct bpf_map_def *maps, int len)
maps[i].max_entries);
if (map_fd[i] < 0)
return 1;
+
+ if (maps[i].type == BPF_MAP_TYPE_PROG_ARRAY)
+ prog_array_fd = map_fd[i];
}
return 0;
}
diff --git a/samples/bpf/tracex5_kern.c b/samples/bpf/tracex5_kern.c
new file mode 100644
index 000000000000..b71fe07a7a7a
--- /dev/null
+++ b/samples/bpf/tracex5_kern.c
@@ -0,0 +1,75 @@
+/* Copyright (c) 2015 PLUMgrid, http://plumgrid.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include <linux/ptrace.h>
+#include <linux/version.h>
+#include <uapi/linux/bpf.h>
+#include <uapi/linux/seccomp.h>
+#include "bpf_helpers.h"
+
+#define PROG(F) SEC("kprobe/"__stringify(F)) int bpf_func_##F
+
+struct bpf_map_def SEC("maps") progs = {
+ .type = BPF_MAP_TYPE_PROG_ARRAY,
+ .key_size = sizeof(u32),
+ .value_size = sizeof(u32),
+ .max_entries = 1024,
+};
+
+SEC("kprobe/seccomp_phase1")
+int bpf_prog1(struct pt_regs *ctx)
+{
+ struct seccomp_data sd = {};
+
+ bpf_probe_read(&sd, sizeof(sd), (void *)ctx->di);
+
+ /* dispatch into next BPF program depending on syscall number */
+ bpf_tail_call(ctx, &progs, sd.nr);
+
+ /* fall through -> unknown syscall */
+ if (sd.nr >= __NR_getuid && sd.nr <= __NR_getsid) {
+ char fmt[] = "syscall=%d (one of get/set uid/pid/gid)\n";
+ bpf_trace_printk(fmt, sizeof(fmt), sd.nr);
+ }
+ return 0;
+}
+
+/* we jump here when syscall number == __NR_write */
+PROG(__NR_write)(struct pt_regs *ctx)
+{
+ struct seccomp_data sd = {};
+
+ bpf_probe_read(&sd, sizeof(sd), (void *)ctx->di);
+ if (sd.args[2] == 512) {
+ char fmt[] = "write(fd=%d, buf=%p, size=%d)\n";
+ bpf_trace_printk(fmt, sizeof(fmt),
+ sd.args[0], sd.args[1], sd.args[2]);
+ }
+ return 0;
+}
+
+PROG(__NR_read)(struct pt_regs *ctx)
+{
+ struct seccomp_data sd = {};
+
+ bpf_probe_read(&sd, sizeof(sd), (void *)ctx->di);
+ if (sd.args[2] > 128 && sd.args[2] <= 1024) {
+ char fmt[] = "read(fd=%d, buf=%p, size=%d)\n";
+ bpf_trace_printk(fmt, sizeof(fmt),
+ sd.args[0], sd.args[1], sd.args[2]);
+ }
+ return 0;
+}
+
+PROG(__NR_mmap)(struct pt_regs *ctx)
+{
+ char fmt[] = "mmap\n";
+ bpf_trace_printk(fmt, sizeof(fmt));
+ return 0;
+}
+
+char _license[] SEC("license") = "GPL";
+u32 _version SEC("version") = LINUX_VERSION_CODE;
diff --git a/samples/bpf/tracex5_user.c b/samples/bpf/tracex5_user.c
new file mode 100644
index 000000000000..a04dd3cd4358
--- /dev/null
+++ b/samples/bpf/tracex5_user.c
@@ -0,0 +1,46 @@
+#include <stdio.h>
+#include <linux/bpf.h>
+#include <unistd.h>
+#include <linux/filter.h>
+#include <linux/seccomp.h>
+#include <sys/prctl.h>
+#include "libbpf.h"
+#include "bpf_load.h"
+
+/* install fake seccomp program to enable seccomp code path inside the kernel,
+ * so that our kprobe attached to seccomp_phase1() can be triggered
+ */
+static void install_accept_all_seccomp(void)
+{
+ struct sock_filter filter[] = {
+ BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW),
+ };
+ struct sock_fprog prog = {
+ .len = (unsigned short)(sizeof(filter)/sizeof(filter[0])),
+ .filter = filter,
+ };
+ if (prctl(PR_SET_SECCOMP, 2, &prog))
+ perror("prctl");
+}
+
+int main(int ac, char **argv)
+{
+ FILE *f;
+ char filename[256];
+
+ snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);
+
+ if (load_bpf_file(filename)) {
+ printf("%s", bpf_log_buf);
+ return 1;
+ }
+
+ install_accept_all_seccomp();
+
+ f = popen("dd if=/dev/zero of=/dev/null count=5", "r");
+ (void) f;
+
+ read_trace_pipe();
+
+ return 0;
+}
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next 2/4] x86: bpf_jit: implement bpf_tail_call() helper
From: Alexei Starovoitov @ 2015-05-19 23:59 UTC (permalink / raw)
To: David S. Miller
Cc: Ingo Molnar, Daniel Borkmann, Michael Holzheu, Zi Shen Lim,
linux-api, netdev, linux-kernel
In-Reply-To: <1432079946-9878-1-git-send-email-ast@plumgrid.com>
bpf_tail_call() arguments:
ctx - context pointer
jmp_table - one of BPF_MAP_TYPE_PROG_ARRAY maps used as the jump table
index - index in the jump table
In this implementation x64 JIT bypasses stack unwind and jumps into the
callee program after prologue, so the callee program reuses the same stack.
The logic can be roughly expressed in C like:
u32 tail_call_cnt;
void *jumptable[2] = { &&label1, &&label2 };
int bpf_prog1(void *ctx)
{
label1:
...
}
int bpf_prog2(void *ctx)
{
label2:
...
}
int bpf_prog1(void *ctx)
{
...
if (tail_call_cnt++ < MAX_TAIL_CALL_CNT)
goto *jumptable[index]; ... and pass my 'ctx' to callee ...
... fall through if no entry in jumptable ...
}
Note that 'skip current program epilogue and next program prologue' is
an optimization. Other JITs don't have to do it the same way.
>From safety point of view it's valid as well, since programs always
initialize the stack before use, so any residue in the stack left by
the current program is not going be read. The same verifier checks are
done for the calls from the kernel into all bpf programs.
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
---
arch/x86/net/bpf_jit_comp.c | 150 ++++++++++++++++++++++++++++++++++++-------
1 file changed, 126 insertions(+), 24 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 99f76103c6b7..2ca777635d8e 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -12,6 +12,7 @@
#include <linux/filter.h>
#include <linux/if_vlan.h>
#include <asm/cacheflush.h>
+#include <linux/bpf.h>
int bpf_jit_enable __read_mostly;
@@ -37,7 +38,8 @@ static u8 *emit_code(u8 *ptr, u32 bytes, unsigned int len)
return ptr + len;
}
-#define EMIT(bytes, len) do { prog = emit_code(prog, bytes, len); } while (0)
+#define EMIT(bytes, len) \
+ do { prog = emit_code(prog, bytes, len); cnt += len; } while (0)
#define EMIT1(b1) EMIT(b1, 1)
#define EMIT2(b1, b2) EMIT((b1) + ((b2) << 8), 2)
@@ -186,31 +188,31 @@ struct jit_context {
#define BPF_MAX_INSN_SIZE 128
#define BPF_INSN_SAFETY 64
-static int do_jit(struct bpf_prog *bpf_prog, int *addrs, u8 *image,
- int oldproglen, struct jit_context *ctx)
+#define STACKSIZE \
+ (MAX_BPF_STACK + \
+ 32 /* space for rbx, r13, r14, r15 */ + \
+ 8 /* space for skb_copy_bits() buffer */)
+
+#define PROLOGUE_SIZE 51
+
+/* emit x64 prologue code for BPF program and check it's size.
+ * bpf_tail_call helper will skip it while jumping into another program
+ */
+static void emit_prologue(u8 **pprog)
{
- struct bpf_insn *insn = bpf_prog->insnsi;
- int insn_cnt = bpf_prog->len;
- bool seen_ld_abs = ctx->seen_ld_abs | (oldproglen == 0);
- bool seen_exit = false;
- u8 temp[BPF_MAX_INSN_SIZE + BPF_INSN_SAFETY];
- int i;
- int proglen = 0;
- u8 *prog = temp;
- int stacksize = MAX_BPF_STACK +
- 32 /* space for rbx, r13, r14, r15 */ +
- 8 /* space for skb_copy_bits() buffer */;
+ u8 *prog = *pprog;
+ int cnt = 0;
EMIT1(0x55); /* push rbp */
EMIT3(0x48, 0x89, 0xE5); /* mov rbp,rsp */
- /* sub rsp, stacksize */
- EMIT3_off32(0x48, 0x81, 0xEC, stacksize);
+ /* sub rsp, STACKSIZE */
+ EMIT3_off32(0x48, 0x81, 0xEC, STACKSIZE);
/* all classic BPF filters use R6(rbx) save it */
/* mov qword ptr [rbp-X],rbx */
- EMIT3_off32(0x48, 0x89, 0x9D, -stacksize);
+ EMIT3_off32(0x48, 0x89, 0x9D, -STACKSIZE);
/* bpf_convert_filter() maps classic BPF register X to R7 and uses R8
* as temporary, so all tcpdump filters need to spill/fill R7(r13) and
@@ -221,16 +223,112 @@ static int do_jit(struct bpf_prog *bpf_prog, int *addrs, u8 *image,
*/
/* mov qword ptr [rbp-X],r13 */
- EMIT3_off32(0x4C, 0x89, 0xAD, -stacksize + 8);
+ EMIT3_off32(0x4C, 0x89, 0xAD, -STACKSIZE + 8);
/* mov qword ptr [rbp-X],r14 */
- EMIT3_off32(0x4C, 0x89, 0xB5, -stacksize + 16);
+ EMIT3_off32(0x4C, 0x89, 0xB5, -STACKSIZE + 16);
/* mov qword ptr [rbp-X],r15 */
- EMIT3_off32(0x4C, 0x89, 0xBD, -stacksize + 24);
+ EMIT3_off32(0x4C, 0x89, 0xBD, -STACKSIZE + 24);
/* clear A and X registers */
EMIT2(0x31, 0xc0); /* xor eax, eax */
EMIT3(0x4D, 0x31, 0xED); /* xor r13, r13 */
+ /* clear tail_cnt: mov qword ptr [rbp-X], rax */
+ EMIT3_off32(0x48, 0x89, 0x85, -STACKSIZE + 32);
+
+ BUILD_BUG_ON(cnt != PROLOGUE_SIZE);
+ *pprog = prog;
+}
+
+/* generate the following code:
+ * ... bpf_tail_call(void *ctx, struct bpf_array *array, u64 index) ...
+ * if (index >= array->map.max_entries)
+ * goto out;
+ * if (++tail_call_cnt > MAX_TAIL_CALL_CNT)
+ * goto out;
+ * prog = array->prog[index];
+ * if (prog == NULL)
+ * goto out;
+ * goto *(prog->bpf_func + prologue_size);
+ * out:
+ */
+static void emit_bpf_tail_call(u8 **pprog)
+{
+ u8 *prog = *pprog;
+ int label1, label2, label3;
+ int cnt = 0;
+
+ /* rdi - pointer to ctx
+ * rsi - pointer to bpf_array
+ * rdx - index in bpf_array
+ */
+
+ /* if (index >= array->map.max_entries)
+ * goto out;
+ */
+ EMIT4(0x48, 0x8B, 0x46, /* mov rax, qword ptr [rsi + 16] */
+ offsetof(struct bpf_array, map.max_entries));
+ EMIT3(0x48, 0x39, 0xD0); /* cmp rax, rdx */
+#define OFFSET1 44 /* number of bytes to jump */
+ EMIT2(X86_JBE, OFFSET1); /* jbe out */
+ label1 = cnt;
+
+ /* if (tail_call_cnt > MAX_TAIL_CALL_CNT)
+ * goto out;
+ */
+ EMIT2_off32(0x8B, 0x85, -STACKSIZE + 36); /* mov eax, dword ptr [rbp - 516] */
+ EMIT3(0x83, 0xF8, MAX_TAIL_CALL_CNT); /* cmp eax, MAX_TAIL_CALL_CNT */
+#define OFFSET2 33
+ EMIT2(X86_JA, OFFSET2); /* ja out */
+ label2 = cnt;
+ EMIT3(0x83, 0xC0, 0x01); /* add eax, 1 */
+ EMIT2_off32(0x89, 0x85, -STACKSIZE + 36); /* mov dword ptr [rbp - 516], eax */
+
+ /* prog = array->prog[index]; */
+ EMIT4(0x48, 0x8D, 0x44, 0xD6); /* lea rax, [rsi + rdx * 8 + 0x50] */
+ EMIT1(offsetof(struct bpf_array, prog));
+ EMIT3(0x48, 0x8B, 0x00); /* mov rax, qword ptr [rax] */
+
+ /* if (prog == NULL)
+ * goto out;
+ */
+ EMIT4(0x48, 0x83, 0xF8, 0x00); /* cmp rax, 0 */
+#define OFFSET3 10
+ EMIT2(X86_JE, OFFSET3); /* je out */
+ label3 = cnt;
+
+ /* goto *(prog->bpf_func + prologue_size); */
+ EMIT4(0x48, 0x8B, 0x40, /* mov rax, qword ptr [rax + 32] */
+ offsetof(struct bpf_prog, bpf_func));
+ EMIT4(0x48, 0x83, 0xC0, PROLOGUE_SIZE); /* add rax, prologue_size */
+
+ /* now we're ready to jump into next BPF program
+ * rdi == ctx (1st arg)
+ * rax == prog->bpf_func + prologue_size
+ */
+ EMIT2(0xFF, 0xE0); /* jmp rax */
+
+ /* out: */
+ BUILD_BUG_ON(cnt - label1 != OFFSET1);
+ BUILD_BUG_ON(cnt - label2 != OFFSET2);
+ BUILD_BUG_ON(cnt - label3 != OFFSET3);
+ *pprog = prog;
+}
+
+static int do_jit(struct bpf_prog *bpf_prog, int *addrs, u8 *image,
+ int oldproglen, struct jit_context *ctx)
+{
+ struct bpf_insn *insn = bpf_prog->insnsi;
+ int insn_cnt = bpf_prog->len;
+ bool seen_ld_abs = ctx->seen_ld_abs | (oldproglen == 0);
+ bool seen_exit = false;
+ u8 temp[BPF_MAX_INSN_SIZE + BPF_INSN_SAFETY];
+ int i, cnt = 0;
+ int proglen = 0;
+ u8 *prog = temp;
+
+ emit_prologue(&prog);
+
if (seen_ld_abs) {
/* r9d : skb->len - skb->data_len (headlen)
* r10 : skb->data
@@ -739,6 +837,10 @@ xadd: if (is_imm8(insn->off))
}
break;
+ case BPF_JMP | BPF_CALL | BPF_X:
+ emit_bpf_tail_call(&prog);
+ break;
+
/* cond jump */
case BPF_JMP | BPF_JEQ | BPF_X:
case BPF_JMP | BPF_JNE | BPF_X:
@@ -891,13 +993,13 @@ common_load:
/* update cleanup_addr */
ctx->cleanup_addr = proglen;
/* mov rbx, qword ptr [rbp-X] */
- EMIT3_off32(0x48, 0x8B, 0x9D, -stacksize);
+ EMIT3_off32(0x48, 0x8B, 0x9D, -STACKSIZE);
/* mov r13, qword ptr [rbp-X] */
- EMIT3_off32(0x4C, 0x8B, 0xAD, -stacksize + 8);
+ EMIT3_off32(0x4C, 0x8B, 0xAD, -STACKSIZE + 8);
/* mov r14, qword ptr [rbp-X] */
- EMIT3_off32(0x4C, 0x8B, 0xB5, -stacksize + 16);
+ EMIT3_off32(0x4C, 0x8B, 0xB5, -STACKSIZE + 16);
/* mov r15, qword ptr [rbp-X] */
- EMIT3_off32(0x4C, 0x8B, 0xBD, -stacksize + 24);
+ EMIT3_off32(0x4C, 0x8B, 0xBD, -STACKSIZE + 24);
EMIT1(0xC9); /* leave */
EMIT1(0xC3); /* ret */
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next 1/4] bpf: allow bpf programs to tail-call other bpf programs
From: Alexei Starovoitov @ 2015-05-19 23:59 UTC (permalink / raw)
To: David S. Miller
Cc: Ingo Molnar, Daniel Borkmann, Michael Holzheu, Zi Shen Lim,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1432079946-9878-1-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
introduce bpf_tail_call(ctx, &jmp_table, index) helper function
which can be used from BPF programs like:
int bpf_prog(struct pt_regs *ctx)
{
...
bpf_tail_call(ctx, &jmp_table, index);
...
}
that is roughly equivalent to:
int bpf_prog(struct pt_regs *ctx)
{
...
if (jmp_table[index])
return (*jmp_table[index])(ctx);
...
}
The important detail that it's not a normal call, but a tail call.
The kernel stack is precious, so this helper reuses the current
stack frame and jumps into another BPF program without adding
extra call frame.
It's trivially done in interpreter and a bit trickier in JITs.
In case of x64 JIT the bigger part of generated assembler prologue
is common for all programs, so it is simply skipped while jumping.
Other JITs can do similar prologue-skipping optimization or
do stack unwind before jumping into the next program.
bpf_tail_call() arguments:
ctx - context pointer
jmp_table - one of BPF_MAP_TYPE_PROG_ARRAY maps used as the jump table
index - index in the jump table
Since all BPF programs are idenitified by file descriptor, user space
need to populate the jmp_table with FDs of other BPF programs.
If jmp_table[index] is empty the bpf_tail_call() doesn't jump anywhere
and program execution continues as normal.
New BPF_MAP_TYPE_PROG_ARRAY map type is introduced so that user space can
populate this jmp_table array with FDs of other bpf programs.
Programs can share the same jmp_table array or use multiple jmp_tables.
The chain of tail calls can form unpredictable dynamic loops therefore
tail_call_cnt is used to limit the number of calls and currently is set to 32.
Use cases:
==========
- simplify complex programs by splitting them into a sequence of small programs
- dispatch routine
For tracing and future seccomp the program may be triggered on all system
calls, but processing of syscall arguments will be different. It's more
efficient to implement them as:
int syscall_entry(struct seccomp_data *ctx)
{
bpf_tail_call(ctx, &syscall_jmp_table, ctx->nr /* syscall number */);
... default: process unknown syscall ...
}
int sys_write_event(struct seccomp_data *ctx) {...}
int sys_read_event(struct seccomp_data *ctx) {...}
syscall_jmp_table[__NR_write] = sys_write_event;
syscall_jmp_table[__NR_read] = sys_read_event;
For networking the program may call into different parsers depending on
packet format, like:
int packet_parser(struct __sk_buff *skb)
{
... parse L2, L3 here ...
__u8 ipproto = load_byte(skb, ... offsetof(struct iphdr, protocol));
bpf_tail_call(skb, &ipproto_jmp_table, ipproto);
... default: process unknown protocol ...
}
int parse_tcp(struct __sk_buff *skb) {...}
int parse_udp(struct __sk_buff *skb) {...}
ipproto_jmp_table[IPPROTO_TCP] = parse_tcp;
ipproto_jmp_table[IPPROTO_UDP] = parse_udp;
- for TC use case, bpf_tail_call() allows to implement reclassify-like logic
- bpf_map_update_elem/delete calls into BPF_MAP_TYPE_PROG_ARRAY jump table
are atomic, so user space can build chains of BPF programs on the fly
Implementation details:
=======================
- high performance of bpf_tail_call() is the goal.
It could have been implemented without JIT changes as a wrapper on top of
BPF_PROG_RUN() macro, but with two downsides:
. all programs would have to pay performance penalty for this feature and
tail call itself would be slower, since mandatory stack unwind, return,
stack allocate would be done for every tailcall.
. tailcall would be limited to programs running preempt_disabled, since
generic 'void *ctx' doesn't have room for 'tail_call_cnt' and it would
need to be either global per_cpu variable accessed by helper and by wrapper
or global variable protected by locks.
In this implementation x64 JIT bypasses stack unwind and jumps into the
callee program after prologue.
- bpf_prog_array_compatible() ensures that prog_type of callee and caller
are the same and JITed/non-JITed flag is the same, since calling JITed
program from non-JITed is invalid, since stack frames are different.
Similarly calling kprobe type program from socket type program is invalid.
- jump table is implemented as BPF_MAP_TYPE_PROG_ARRAY to reuse 'map'
abstraction, its user space API and all of verifier logic.
It's in the existing arraymap.c file, since several functions are
shared with regular array map.
Signed-off-by: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
---
include/linux/bpf.h | 22 +++++++++
include/linux/filter.h | 2 +-
include/uapi/linux/bpf.h | 10 ++++
kernel/bpf/arraymap.c | 113 +++++++++++++++++++++++++++++++++++++++++++---
kernel/bpf/core.c | 73 +++++++++++++++++++++++++++++-
kernel/bpf/syscall.c | 23 +++++++++-
kernel/bpf/verifier.c | 17 +++++++
kernel/trace/bpf_trace.c | 2 +
net/core/filter.c | 2 +
9 files changed, 255 insertions(+), 9 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index d5cda067115a..8821b9a8689e 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -126,6 +126,27 @@ struct bpf_prog_aux {
struct work_struct work;
};
+struct bpf_array {
+ struct bpf_map map;
+ u32 elem_size;
+ /* 'ownership' of prog_array is claimed by the first program that
+ * is going to use this map or by the first program which FD is stored
+ * in the map to make sure that all callers and callees have the same
+ * prog_type and JITed flag
+ */
+ enum bpf_prog_type owner_prog_type;
+ bool owner_jited;
+ union {
+ char value[0] __aligned(8);
+ struct bpf_prog *prog[0] __aligned(8);
+ };
+};
+#define MAX_TAIL_CALL_CNT 32
+
+u64 bpf_tail_call(u64 ctx, u64 r2, u64 index, u64 r4, u64 r5);
+void bpf_prog_array_map_clear(struct bpf_map *map);
+bool bpf_prog_array_compatible(struct bpf_array *array, const struct bpf_prog *fp);
+
#ifdef CONFIG_BPF_SYSCALL
void bpf_register_prog_type(struct bpf_prog_type_list *tl);
void bpf_register_map_type(struct bpf_map_type_list *tl);
@@ -160,5 +181,6 @@ extern const struct bpf_func_proto bpf_map_delete_elem_proto;
extern const struct bpf_func_proto bpf_get_prandom_u32_proto;
extern const struct bpf_func_proto bpf_get_smp_processor_id_proto;
+extern const struct bpf_func_proto bpf_tail_call_proto;
#endif /* _LINUX_BPF_H */
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 200be4a74a33..17724f6ea983 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -378,7 +378,7 @@ static inline void bpf_prog_unlock_ro(struct bpf_prog *fp)
int sk_filter(struct sock *sk, struct sk_buff *skb);
-void bpf_prog_select_runtime(struct bpf_prog *fp);
+int bpf_prog_select_runtime(struct bpf_prog *fp);
void bpf_prog_free(struct bpf_prog *fp);
struct bpf_prog *bpf_prog_alloc(unsigned int size, gfp_t gfp_extra_flags);
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index a9ebdf5701e8..f0a9af8b4dae 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -113,6 +113,7 @@ enum bpf_map_type {
BPF_MAP_TYPE_UNSPEC,
BPF_MAP_TYPE_HASH,
BPF_MAP_TYPE_ARRAY,
+ BPF_MAP_TYPE_PROG_ARRAY,
};
enum bpf_prog_type {
@@ -210,6 +211,15 @@ enum bpf_func_id {
* Return: 0 on success
*/
BPF_FUNC_l4_csum_replace,
+
+ /**
+ * bpf_tail_call(ctx, prog_array_map, index) - jump into another BPF program
+ * @ctx: context pointer passed to next program
+ * @prog_array_map: pointer to map which type is BPF_MAP_TYPE_PROG_ARRAY
+ * @index: index inside array that selects specific program to run
+ * Return: 0 on success
+ */
+ BPF_FUNC_tail_call,
__BPF_FUNC_MAX_ID,
};
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 8a6616583f38..614bcd4c1d74 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -14,12 +14,7 @@
#include <linux/vmalloc.h>
#include <linux/slab.h>
#include <linux/mm.h>
-
-struct bpf_array {
- struct bpf_map map;
- u32 elem_size;
- char value[0] __aligned(8);
-};
+#include <linux/filter.h>
/* Called from syscall */
static struct bpf_map *array_map_alloc(union bpf_attr *attr)
@@ -154,3 +149,109 @@ static int __init register_array_map(void)
return 0;
}
late_initcall(register_array_map);
+
+static struct bpf_map *prog_array_map_alloc(union bpf_attr *attr)
+{
+ /* only bpf_prog file descriptors can be stored in prog_array map */
+ if (attr->value_size != sizeof(u32))
+ return ERR_PTR(-EINVAL);
+ return array_map_alloc(attr);
+}
+
+static void prog_array_map_free(struct bpf_map *map)
+{
+ struct bpf_array *array = container_of(map, struct bpf_array, map);
+ int i;
+
+ synchronize_rcu();
+
+ /* make sure it's empty */
+ for (i = 0; i < array->map.max_entries; i++)
+ BUG_ON(array->prog[i] != NULL);
+ kvfree(array);
+}
+
+static void *prog_array_map_lookup_elem(struct bpf_map *map, void *key)
+{
+ return NULL;
+}
+
+/* only called from syscall */
+static int prog_array_map_update_elem(struct bpf_map *map, void *key,
+ void *value, u64 map_flags)
+{
+ struct bpf_array *array = container_of(map, struct bpf_array, map);
+ struct bpf_prog *prog, *old_prog;
+ u32 index = *(u32 *)key, ufd;
+
+ if (map_flags != BPF_ANY)
+ return -EINVAL;
+
+ if (index >= array->map.max_entries)
+ return -E2BIG;
+
+ ufd = *(u32 *)value;
+ prog = bpf_prog_get(ufd);
+ if (IS_ERR(prog))
+ return PTR_ERR(prog);
+
+ if (!bpf_prog_array_compatible(array, prog)) {
+ bpf_prog_put(prog);
+ return -EINVAL;
+ }
+
+ old_prog = xchg(array->prog + index, prog);
+ if (old_prog)
+ bpf_prog_put(old_prog);
+
+ return 0;
+}
+
+static int prog_array_map_delete_elem(struct bpf_map *map, void *key)
+{
+ struct bpf_array *array = container_of(map, struct bpf_array, map);
+ struct bpf_prog *old_prog;
+ u32 index = *(u32 *)key;
+
+ if (index >= array->map.max_entries)
+ return -E2BIG;
+
+ old_prog = xchg(array->prog + index, NULL);
+ if (old_prog) {
+ bpf_prog_put(old_prog);
+ return 0;
+ } else {
+ return -ENOENT;
+ }
+}
+
+/* decrement refcnt of all bpf_progs that are stored in this map */
+void bpf_prog_array_map_clear(struct bpf_map *map)
+{
+ struct bpf_array *array = container_of(map, struct bpf_array, map);
+ int i;
+
+ for (i = 0; i < array->map.max_entries; i++)
+ prog_array_map_delete_elem(map, &i);
+}
+
+static const struct bpf_map_ops prog_array_ops = {
+ .map_alloc = prog_array_map_alloc,
+ .map_free = prog_array_map_free,
+ .map_get_next_key = array_map_get_next_key,
+ .map_lookup_elem = prog_array_map_lookup_elem,
+ .map_update_elem = prog_array_map_update_elem,
+ .map_delete_elem = prog_array_map_delete_elem,
+};
+
+static struct bpf_map_type_list prog_array_type __read_mostly = {
+ .ops = &prog_array_ops,
+ .type = BPF_MAP_TYPE_PROG_ARRAY,
+};
+
+static int __init register_prog_array_map(void)
+{
+ bpf_register_map_type(&prog_array_type);
+ return 0;
+}
+late_initcall(register_prog_array_map);
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 54f0e7fcd0e2..d44b25cbe460 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -176,6 +176,15 @@ noinline u64 __bpf_call_base(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
return 0;
}
+const struct bpf_func_proto bpf_tail_call_proto = {
+ .func = NULL,
+ .gpl_only = false,
+ .ret_type = RET_VOID,
+ .arg1_type = ARG_PTR_TO_CTX,
+ .arg2_type = ARG_CONST_MAP_PTR,
+ .arg3_type = ARG_ANYTHING,
+};
+
/**
* __bpf_prog_run - run eBPF program on a given context
* @ctx: is the data we are operating on
@@ -244,6 +253,7 @@ static unsigned int __bpf_prog_run(void *ctx, const struct bpf_insn *insn)
[BPF_ALU64 | BPF_NEG] = &&ALU64_NEG,
/* Call instruction */
[BPF_JMP | BPF_CALL] = &&JMP_CALL,
+ [BPF_JMP | BPF_CALL | BPF_X] = &&JMP_TAIL_CALL,
/* Jumps */
[BPF_JMP | BPF_JA] = &&JMP_JA,
[BPF_JMP | BPF_JEQ | BPF_X] = &&JMP_JEQ_X,
@@ -286,6 +296,7 @@ static unsigned int __bpf_prog_run(void *ctx, const struct bpf_insn *insn)
[BPF_LD | BPF_IND | BPF_B] = &&LD_IND_B,
[BPF_LD | BPF_IMM | BPF_DW] = &&LD_IMM_DW,
};
+ u32 tail_call_cnt = 0;
void *ptr;
int off;
@@ -431,6 +442,30 @@ select_insn:
BPF_R4, BPF_R5);
CONT;
+ JMP_TAIL_CALL: {
+ struct bpf_map *map = (struct bpf_map *) (unsigned long) BPF_R2;
+ struct bpf_array *array = container_of(map, struct bpf_array, map);
+ struct bpf_prog *prog;
+ u64 index = BPF_R3;
+
+ if (unlikely(index >= array->map.max_entries))
+ goto out;
+
+ if (unlikely(tail_call_cnt > MAX_TAIL_CALL_CNT))
+ goto out;
+
+ tail_call_cnt++;
+
+ prog = READ_ONCE(array->prog[index]);
+ if (unlikely(!prog))
+ goto out;
+
+ ARG1 = BPF_R1;
+ insn = prog->insnsi;
+ goto select_insn;
+out:
+ CONT;
+ }
/* JMP */
JMP_JA:
insn += insn->off;
@@ -619,6 +654,40 @@ void __weak bpf_int_jit_compile(struct bpf_prog *prog)
{
}
+bool bpf_prog_array_compatible(struct bpf_array *array, const struct bpf_prog *fp)
+{
+ if (array->owner_prog_type) {
+ if (array->owner_prog_type != fp->type)
+ return false;
+ if (array->owner_jited != fp->jited)
+ return false;
+ } else {
+ array->owner_prog_type = fp->type;
+ array->owner_jited = fp->jited;
+ }
+ return true;
+}
+
+static int check_tail_call(const struct bpf_prog *fp)
+{
+ struct bpf_prog_aux *aux = fp->aux;
+ int i;
+
+ for (i = 0; i < aux->used_map_cnt; i++) {
+ struct bpf_array *array;
+ struct bpf_map *map;
+
+ map = aux->used_maps[i];
+ if (map->map_type != BPF_MAP_TYPE_PROG_ARRAY)
+ continue;
+ array = container_of(map, struct bpf_array, map);
+ if (!bpf_prog_array_compatible(array, fp))
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
/**
* bpf_prog_select_runtime - select execution runtime for BPF program
* @fp: bpf_prog populated with internal BPF program
@@ -626,7 +695,7 @@ void __weak bpf_int_jit_compile(struct bpf_prog *prog)
* try to JIT internal BPF program, if JIT is not available select interpreter
* BPF program will be executed via BPF_PROG_RUN() macro
*/
-void bpf_prog_select_runtime(struct bpf_prog *fp)
+int bpf_prog_select_runtime(struct bpf_prog *fp)
{
fp->bpf_func = (void *) __bpf_prog_run;
@@ -634,6 +703,8 @@ void bpf_prog_select_runtime(struct bpf_prog *fp)
bpf_int_jit_compile(fp);
/* Lock whole bpf_prog as read-only */
bpf_prog_lock_ro(fp);
+
+ return check_tail_call(fp);
}
EXPORT_SYMBOL_GPL(bpf_prog_select_runtime);
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 3bae6c591914..98a69bd83069 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -68,6 +68,12 @@ static int bpf_map_release(struct inode *inode, struct file *filp)
{
struct bpf_map *map = filp->private_data;
+ if (map->map_type == BPF_MAP_TYPE_PROG_ARRAY)
+ /* prog_array stores refcnt-ed bpf_prog pointers
+ * release them all when user space closes prog_array_fd
+ */
+ bpf_prog_array_map_clear(map);
+
bpf_map_put(map);
return 0;
}
@@ -392,6 +398,19 @@ static void fixup_bpf_calls(struct bpf_prog *prog)
*/
BUG_ON(!prog->aux->ops->get_func_proto);
+ if (insn->imm == BPF_FUNC_tail_call) {
+ /* mark bpf_tail_call as different opcode
+ * to avoid conditional branch in
+ * interpeter for every normal call
+ * and to prevent accidental JITing by
+ * JIT compiler that doesn't support
+ * bpf_tail_call yet
+ */
+ insn->imm = 0;
+ insn->code |= BPF_X;
+ continue;
+ }
+
fn = prog->aux->ops->get_func_proto(insn->imm);
/* all functions that have prototype and verifier allowed
* programs to call them, must be real in-kernel functions
@@ -532,7 +551,9 @@ static int bpf_prog_load(union bpf_attr *attr)
fixup_bpf_calls(prog);
/* eBPF program is ready to be JITed */
- bpf_prog_select_runtime(prog);
+ err = bpf_prog_select_runtime(prog);
+ if (err < 0)
+ goto free_used_maps;
err = anon_inode_getfd("bpf-prog", &bpf_prog_fops, prog, O_RDWR | O_CLOEXEC);
if (err < 0)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 47dcd3aa6e23..cfd9a40b9a5a 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -907,6 +907,23 @@ static int check_call(struct verifier_env *env, int func_id)
fn->ret_type, func_id);
return -EINVAL;
}
+
+ if (map && map->map_type == BPF_MAP_TYPE_PROG_ARRAY &&
+ func_id != BPF_FUNC_tail_call)
+ /* prog_array map type needs extra care:
+ * only allow to pass it into bpf_tail_call() for now.
+ * bpf_map_delete_elem() can be allowed in the future,
+ * while bpf_map_update_elem() must only be done via syscall
+ */
+ return -EINVAL;
+
+ if (func_id == BPF_FUNC_tail_call &&
+ map->map_type != BPF_MAP_TYPE_PROG_ARRAY)
+ /* don't allow any other map type to be passed into
+ * bpf_tail_call()
+ */
+ return -EINVAL;
+
return 0;
}
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 2d56ce501632..646445e41bd4 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -172,6 +172,8 @@ static const struct bpf_func_proto *kprobe_prog_func_proto(enum bpf_func_id func
return &bpf_probe_read_proto;
case BPF_FUNC_ktime_get_ns:
return &bpf_ktime_get_ns_proto;
+ case BPF_FUNC_tail_call:
+ return &bpf_tail_call_proto;
case BPF_FUNC_trace_printk:
/*
diff --git a/net/core/filter.c b/net/core/filter.c
index 6805717be614..3adcca6f17a4 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -1421,6 +1421,8 @@ sk_filter_func_proto(enum bpf_func_id func_id)
return &bpf_get_prandom_u32_proto;
case BPF_FUNC_get_smp_processor_id:
return &bpf_get_smp_processor_id_proto;
+ case BPF_FUNC_tail_call:
+ return &bpf_tail_call_proto;
default:
return NULL;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next 0/4] bpf: introduce bpf_tail_call() helper
From: Alexei Starovoitov @ 2015-05-19 23:59 UTC (permalink / raw)
To: David S. Miller
Cc: Ingo Molnar, Daniel Borkmann, Michael Holzheu, Zi Shen Lim,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Hi All,
introduce bpf_tail_call(ctx, &jmp_table, index) helper function
which can be used from BPF programs like:
int bpf_prog(struct pt_regs *ctx)
{
...
bpf_tail_call(ctx, &jmp_table, index);
...
}
that is roughly equivalent to:
int bpf_prog(struct pt_regs *ctx)
{
...
if (jmp_table[index])
return (*jmp_table[index])(ctx);
...
}
The important detail that it's not a normal call, but a tail call.
The kernel stack is precious, so this helper reuses the current
stack frame and jumps into another BPF program without adding
extra call frame.
It's trivially done in interpreter and a bit trickier in JITs.
Use cases:
- simplify complex programs
- dispatch into other programs
(for example: index in jump table can be syscall number or network protocol)
- build dynamic chains of programs
The chain of tail calls can form unpredictable dynamic loops therefore
tail_call_cnt is used to limit the number of calls and currently is set to 32.
patch 1 - support bpf_tail_call() in interpreter
patch 2 - support in x64 JIT
We've discussed what's neccessary to support it in arm64/s390 JITs
and it looks fine.
patch 3 - sample example for tracing
patch 4 - sample example for networking
More details in every patch.
This set went through several iterations of reviews/fixes and older
attempts can be seen:
https://git.kernel.org/cgit/linux/kernel/git/ast/bpf.git/log/?h=tail_call_v[123456]
- tail_call_v1 does it without touching JITs but introduces overhead
for all programs that don't use this helper function.
- tail_call_v2 still has some overhead and x64 JIT does full stack
unwind (prologue skipping optimization wasn't there)
- tail_call_v3 reuses 'call' instruction encoding and has interpreter
overhead for every normal call
- tail_call_v4 fixes above architectural shortcomings and v5,v6 fix few
more bugs
This last tail_call_v6 approach seems to be the best.
Alexei Starovoitov (4):
bpf: allow bpf programs to tail-call other bpf programs
x86: bpf_jit: implement bpf_tail_call() helper
samples/bpf: bpf_tail_call example for tracing
samples/bpf: bpf_tail_call example for networking
arch/x86/net/bpf_jit_comp.c | 150 +++++++++++++++++----
include/linux/bpf.h | 22 ++++
include/linux/filter.h | 2 +-
include/uapi/linux/bpf.h | 10 ++
kernel/bpf/arraymap.c | 113 +++++++++++++++-
kernel/bpf/core.c | 73 ++++++++++-
kernel/bpf/syscall.c | 23 +++-
kernel/bpf/verifier.c | 17 +++
kernel/trace/bpf_trace.c | 2 +
net/core/filter.c | 2 +
samples/bpf/Makefile | 8 ++
samples/bpf/bpf_helpers.h | 4 +
samples/bpf/bpf_load.c | 57 ++++++--
samples/bpf/sockex3_kern.c | 303 +++++++++++++++++++++++++++++++++++++++++++
samples/bpf/sockex3_user.c | 66 ++++++++++
samples/bpf/tracex5_kern.c | 75 +++++++++++
samples/bpf/tracex5_user.c | 46 +++++++
17 files changed, 928 insertions(+), 45 deletions(-)
create mode 100644 samples/bpf/sockex3_kern.c
create mode 100644 samples/bpf/sockex3_user.c
create mode 100644 samples/bpf/tracex5_kern.c
create mode 100644 samples/bpf/tracex5_user.c
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH v2 2/3] fbcon: use the cursor blink interval provided by vt
From: Greg Kroah-Hartman @ 2015-05-19 23:41 UTC (permalink / raw)
To: Thierry Reding
Cc: Kevin Hilman, Scot Doyle, Tomi Valkeinen, Michael Kerrisk,
Jiri Slaby, Jean-Christophe Plagniol-Villard, Pavel Machek,
Geert Uytterhoeven, lkml, linux-fbdev, linux-man, linux-api,
Tyler Baker, Olof Johansson, Daniel Stone, Arnd Bergmann
In-Reply-To: <20150519215228.GA27163@ulmo.nvidia.com>
On Tue, May 19, 2015 at 11:52:29PM +0200, Thierry Reding wrote:
> On Tue, May 19, 2015 at 02:45:19PM -0700, Kevin Hilman wrote:
> > On Tue, May 19, 2015 at 2:40 PM, Thierry Reding
> > <thierry.reding@gmail.com> wrote:
> > > On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote:
> > >> On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle <lkml14@scotdoyle.com> wrote:
> > >> > vt now provides a cursor blink interval via vc_data. Use this
> > >> > interval instead of the currently hardcoded 200 msecs. Store it in
> > >> > fbcon_ops to avoid locking the console in cursor_timer_handler().
> > >> >
> > >> > Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
> > >> > Acked-by: Pavel Machek <pavel@ucw.cz>
> > >>
> > >> This patch hit next-20150519 in the form of commit 27a4c827c34a
> > >> (fbcon: use the cursor blink interval provided by vt) and has caused
> > >> boot failure on a handful of ARM platforms when booting a MMC root
> > >> filesystem. This error was spotted by the kernelci.org bot on
> > >> exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
> > >> some tegra platforms too.
> > >>
> > >> Thierry spotted this commit as a potential cause, and both Daniel and
> > >> I have reverted and boot tested on exynos5 and tegra respectively and
> > >> the boot panics disappear.
> > >
> > > FWIW, if I apply the below on top of next-20150519 things seem to be
> > > back to normal as well:
> > >
> > > diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> > > index 05b1d1a71ef9..658c34bb9076 100644
> > > --- a/drivers/video/console/fbcon.c
> > > +++ b/drivers/video/console/fbcon.c
> > > @@ -1310,8 +1310,9 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
> > > return;
> > >
> > > ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
> > > - fbcon_del_cursor_timer(info);
> > > - if (!(vc->vc_cursor_type & 0x10))
> > > + if (vc->vc_cursor_type & 0x10)
> > > + fbcon_del_cursor_timer(info);
> > > + else
> > > fbcon_add_cursor_timer(info);
> > >
> > > ops->cursor_flash = (mode == CM_ERASE) ? 0 : 1;
> >
> > Applying this on next-20150519 makes my exynos board happily boot again as well.
> >
> > Tested-by: Kevin Hilman <khilman@linaro.org>
>
> Excellent. Greg, Scot, any opinions on whether or not this is the right
> thing to do? It restores a bit that looks suspiciously like it snuck in
> in the original (at least it isn't documented in the commit message).
>
> Greg, feel free to squash this in if everybody agrees this is good to
> go. If you prefer a patch on top let me know and I'll come up with a
> proper commit message.
Please send a real patch and I'll apply it on top, as I can't rebase my
public tree.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 00/23] userfaultfd v4
From: Richard Weinberger @ 2015-05-19 21:59 UTC (permalink / raw)
To: Andrew Morton
Cc: Andrea Arcangeli, LKML, linux-mm@kvack.org, qemu-devel, kvm,
open list:ABI/API, Pavel Emelyanov, Sanidhya Kashyap,
zhang.zhanghailiang, Linus Torvalds, Kirill A. Shutemov,
Andres Lagar-Cavilla, Dave Hansen, Paolo Bonzini, Rik van Riel,
Mel Gorman, Andy Lutomirski, Hugh Dickins, Peter Feiner,
Dr. David Alan Gilbert, Johannes Weiner, Huangpeng (Peter)
In-Reply-To: <20150519143801.8ba477c3813e93a2637c19cf@linux-foundation.org>
On Tue, May 19, 2015 at 11:38 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Thu, 14 May 2015 19:30:57 +0200 Andrea Arcangeli <aarcange@redhat.com> wrote:
>
>> This is the latest userfaultfd patchset against mm-v4.1-rc3
>> 2015-05-14-10:04.
>
> It would be useful to have some userfaultfd testcases in
> tools/testing/selftests/. Partly as an aid to arch maintainers when
> enabling this. And also as a standalone thing to give people a
> practical way of exercising this interface.
>
> What are your thoughts on enabling userfaultfd for other architectures,
> btw? Are there good use cases, are people working on it, etc?
UML is using SIGSEGV for page faults.
i.e. the UML processes receives a SIGSEGV, learns the faulting address
from the mcontext
and resolves the fault by installing a new mapping.
If userfaultfd is faster that the SIGSEGV notification it could speed
up UML a bit.
For UML I'm only interested in the notification, not the resolving
part. The "missing"
data is present, only a new mapping is needed. No copy of data.
Andrea, what do you think?
--
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH v2 2/3] fbcon: use the cursor blink interval provided by vt
From: Thierry Reding @ 2015-05-19 21:52 UTC (permalink / raw)
To: Kevin Hilman, Scot Doyle, Greg Kroah-Hartman
Cc: Tomi Valkeinen, Michael Kerrisk, Jiri Slaby,
Jean-Christophe Plagniol-Villard, Pavel Machek,
Geert Uytterhoeven, lkml, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Tyler Baker, Olof Johansson,
Daniel Stone, Arnd Bergmann
In-Reply-To: <CAMAWPa88E2pfViKLXjxWHuT4ZkVhzYt_BsXGePzc-70ZrEmJFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2722 bytes --]
On Tue, May 19, 2015 at 02:45:19PM -0700, Kevin Hilman wrote:
> On Tue, May 19, 2015 at 2:40 PM, Thierry Reding
> <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote:
> >> On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle <lkml14-enLWO88E2pdl57MIdRCFDg@public.gmane.org> wrote:
> >> > vt now provides a cursor blink interval via vc_data. Use this
> >> > interval instead of the currently hardcoded 200 msecs. Store it in
> >> > fbcon_ops to avoid locking the console in cursor_timer_handler().
> >> >
> >> > Signed-off-by: Scot Doyle <lkml14-enLWO88E2pdl57MIdRCFDg@public.gmane.org>
> >> > Acked-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
> >>
> >> This patch hit next-20150519 in the form of commit 27a4c827c34a
> >> (fbcon: use the cursor blink interval provided by vt) and has caused
> >> boot failure on a handful of ARM platforms when booting a MMC root
> >> filesystem. This error was spotted by the kernelci.org bot on
> >> exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
> >> some tegra platforms too.
> >>
> >> Thierry spotted this commit as a potential cause, and both Daniel and
> >> I have reverted and boot tested on exynos5 and tegra respectively and
> >> the boot panics disappear.
> >
> > FWIW, if I apply the below on top of next-20150519 things seem to be
> > back to normal as well:
> >
> > diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> > index 05b1d1a71ef9..658c34bb9076 100644
> > --- a/drivers/video/console/fbcon.c
> > +++ b/drivers/video/console/fbcon.c
> > @@ -1310,8 +1310,9 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
> > return;
> >
> > ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
> > - fbcon_del_cursor_timer(info);
> > - if (!(vc->vc_cursor_type & 0x10))
> > + if (vc->vc_cursor_type & 0x10)
> > + fbcon_del_cursor_timer(info);
> > + else
> > fbcon_add_cursor_timer(info);
> >
> > ops->cursor_flash = (mode == CM_ERASE) ? 0 : 1;
>
> Applying this on next-20150519 makes my exynos board happily boot again as well.
>
> Tested-by: Kevin Hilman <khilman-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Excellent. Greg, Scot, any opinions on whether or not this is the right
thing to do? It restores a bit that looks suspiciously like it snuck in
in the original (at least it isn't documented in the commit message).
Greg, feel free to squash this in if everybody agrees this is good to
go. If you prefer a patch on top let me know and I'll come up with a
proper commit message.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] fbcon: use the cursor blink interval provided by vt
From: Kevin Hilman @ 2015-05-19 21:45 UTC (permalink / raw)
To: Thierry Reding
Cc: Kevin Hilman, Scot Doyle, Greg Kroah-Hartman, Tomi Valkeinen,
Michael Kerrisk, Jiri Slaby, Jean-Christophe Plagniol-Villard,
Pavel Machek, Geert Uytterhoeven, lkml, linux-fbdev, linux-man,
linux-api, Tyler Baker, Olof Johansson, Daniel Stone,
Arnd Bergmann
In-Reply-To: <20150519214011.GA27047@ulmo.nvidia.com>
On Tue, May 19, 2015 at 2:40 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote:
>> On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle <lkml14@scotdoyle.com> wrote:
>> > vt now provides a cursor blink interval via vc_data. Use this
>> > interval instead of the currently hardcoded 200 msecs. Store it in
>> > fbcon_ops to avoid locking the console in cursor_timer_handler().
>> >
>> > Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
>> > Acked-by: Pavel Machek <pavel@ucw.cz>
>>
>> This patch hit next-20150519 in the form of commit 27a4c827c34a
>> (fbcon: use the cursor blink interval provided by vt) and has caused
>> boot failure on a handful of ARM platforms when booting a MMC root
>> filesystem. This error was spotted by the kernelci.org bot on
>> exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
>> some tegra platforms too.
>>
>> Thierry spotted this commit as a potential cause, and both Daniel and
>> I have reverted and boot tested on exynos5 and tegra respectively and
>> the boot panics disappear.
>
> FWIW, if I apply the below on top of next-20150519 things seem to be
> back to normal as well:
>
> diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> index 05b1d1a71ef9..658c34bb9076 100644
> --- a/drivers/video/console/fbcon.c
> +++ b/drivers/video/console/fbcon.c
> @@ -1310,8 +1310,9 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
> return;
>
> ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
> - fbcon_del_cursor_timer(info);
> - if (!(vc->vc_cursor_type & 0x10))
> + if (vc->vc_cursor_type & 0x10)
> + fbcon_del_cursor_timer(info);
> + else
> fbcon_add_cursor_timer(info);
>
> ops->cursor_flash = (mode == CM_ERASE) ? 0 : 1;
Applying this on next-20150519 makes my exynos board happily boot again as well.
Tested-by: Kevin Hilman <khilman@linaro.org>
Kevin
^ permalink raw reply
* Re: [PATCH v2 2/3] fbcon: use the cursor blink interval provided by vt
From: Thierry Reding @ 2015-05-19 21:40 UTC (permalink / raw)
To: Kevin Hilman
Cc: Scot Doyle, Greg Kroah-Hartman, Tomi Valkeinen, Michael Kerrisk,
Jiri Slaby, Jean-Christophe Plagniol-Villard, Pavel Machek,
Geert Uytterhoeven, lkml, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Tyler Baker, Olof Johansson,
Daniel Stone, Arnd Bergmann
In-Reply-To: <CAMAWPa-6ZbE5cDkEZq0XpYa2pHcnf3qweSSVHAXhfhUAUCbKcA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]
On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote:
> On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle <lkml14-enLWO88E2pdl57MIdRCFDg@public.gmane.org> wrote:
> > vt now provides a cursor blink interval via vc_data. Use this
> > interval instead of the currently hardcoded 200 msecs. Store it in
> > fbcon_ops to avoid locking the console in cursor_timer_handler().
> >
> > Signed-off-by: Scot Doyle <lkml14-enLWO88E2pdl57MIdRCFDg@public.gmane.org>
> > Acked-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
>
> This patch hit next-20150519 in the form of commit 27a4c827c34a
> (fbcon: use the cursor blink interval provided by vt) and has caused
> boot failure on a handful of ARM platforms when booting a MMC root
> filesystem. This error was spotted by the kernelci.org bot on
> exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
> some tegra platforms too.
>
> Thierry spotted this commit as a potential cause, and both Daniel and
> I have reverted and boot tested on exynos5 and tegra respectively and
> the boot panics disappear.
FWIW, if I apply the below on top of next-20150519 things seem to be
back to normal as well:
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 05b1d1a71ef9..658c34bb9076 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -1310,8 +1310,9 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
return;
ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
- fbcon_del_cursor_timer(info);
- if (!(vc->vc_cursor_type & 0x10))
+ if (vc->vc_cursor_type & 0x10)
+ fbcon_del_cursor_timer(info);
+ else
fbcon_add_cursor_timer(info);
ops->cursor_flash = (mode == CM_ERASE) ? 0 : 1;
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* Re: [PATCH 00/23] userfaultfd v4
From: Andrew Morton @ 2015-05-19 21:38 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: linux-kernel, linux-mm, qemu-devel, kvm, linux-api,
Pavel Emelyanov, Sanidhya Kashyap, zhang.zhanghailiang,
Linus Torvalds, Kirill A. Shutemov, Andres Lagar-Cavilla,
Dave Hansen, Paolo Bonzini, Rik van Riel, Mel Gorman,
Andy Lutomirski, Hugh Dickins, Peter Feiner,
Dr. David Alan Gilbert, Johannes Weiner, Huangpeng (Peter)
In-Reply-To: <1431624680-20153-1-git-send-email-aarcange@redhat.com>
On Thu, 14 May 2015 19:30:57 +0200 Andrea Arcangeli <aarcange@redhat.com> wrote:
> This is the latest userfaultfd patchset against mm-v4.1-rc3
> 2015-05-14-10:04.
It would be useful to have some userfaultfd testcases in
tools/testing/selftests/. Partly as an aid to arch maintainers when
enabling this. And also as a standalone thing to give people a
practical way of exercising this interface.
What are your thoughts on enabling userfaultfd for other architectures,
btw? Are there good use cases, are people working on it, etc?
Also, I assume a manpage is in the works? Sooner rather than later
would be good - Michael's review of proposed kernel interfaces has
often been valuable.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2 2/3] fbcon: use the cursor blink interval provided by vt
From: Kevin Hilman @ 2015-05-19 21:15 UTC (permalink / raw)
To: Scot Doyle
Cc: Greg Kroah-Hartman, Tomi Valkeinen, Michael Kerrisk, Jiri Slaby,
Jean-Christophe Plagniol-Villard, Pavel Machek,
Geert Uytterhoeven, lkml, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Tyler Baker, Olof Johansson,
Daniel Stone, Thierry Reding, Arnd Bergmann
In-Reply-To: <alpine.DEB.2.11.1503261354550.2411@local>
On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle <lkml14-enLWO88E2pdl57MIdRCFDg@public.gmane.org> wrote:
> vt now provides a cursor blink interval via vc_data. Use this
> interval instead of the currently hardcoded 200 msecs. Store it in
> fbcon_ops to avoid locking the console in cursor_timer_handler().
>
> Signed-off-by: Scot Doyle <lkml14-enLWO88E2pdl57MIdRCFDg@public.gmane.org>
> Acked-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
This patch hit next-20150519 in the form of commit 27a4c827c34a
(fbcon: use the cursor blink interval provided by vt) and has caused
boot failure on a handful of ARM platforms when booting a MMC root
filesystem. This error was spotted by the kernelci.org bot on
exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
some tegra platforms too.
Thierry spotted this commit as a potential cause, and both Daniel and
I have reverted and boot tested on exynos5 and tegra respectively and
the boot panics disappear.
Kevin
[1] http://storage.kernelci.org/next/next-20150519/arm-exynos_defconfig/lab-khilman/boot-exynos5800-peach-pi_rootfs:mmc.html
^ permalink raw reply
* Re: [PATCH 0/3] Allow user to request memory to be locked on page fault
From: Eric B Munson @ 2015-05-19 20:30 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, Shuah Khan, linux-alpha, linux-kernel, linux-mips,
linux-parisc, linuxppc-dev, sparclinux, linux-xtensa, linux-mm,
linux-arch, linux-api
In-Reply-To: <20150515153550.GA2454@akamai.com>
[-- Attachment #1: Type: text/plain, Size: 4761 bytes --]
On Fri, 15 May 2015, Eric B Munson wrote:
> On Thu, 14 May 2015, Michal Hocko wrote:
>
> > On Wed 13-05-15 11:00:36, Eric B Munson wrote:
> > > On Mon, 11 May 2015, Eric B Munson wrote:
> > >
> > > > On Fri, 08 May 2015, Andrew Morton wrote:
> > > >
> > > > > On Fri, 8 May 2015 15:33:43 -0400 Eric B Munson <emunson@akamai.com> wrote:
> > > > >
> > > > > > mlock() allows a user to control page out of program memory, but this
> > > > > > comes at the cost of faulting in the entire mapping when it is
> > > > > > allocated. For large mappings where the entire area is not necessary
> > > > > > this is not ideal.
> > > > > >
> > > > > > This series introduces new flags for mmap() and mlockall() that allow a
> > > > > > user to specify that the covered are should not be paged out, but only
> > > > > > after the memory has been used the first time.
> > > > >
> > > > > Please tell us much much more about the value of these changes: the use
> > > > > cases, the behavioural improvements and performance results which the
> > > > > patchset brings to those use cases, etc.
> > > > >
> > > >
> > > > To illustrate the proposed use case I wrote a quick program that mmaps
> > > > a 5GB file which is filled with random data and accesses 150,000 pages
> > > > from that mapping. Setup and processing were timed separately to
> > > > illustrate the differences between the three tested approaches. the
> > > > setup portion is simply the call to mmap, the processing is the
> > > > accessing of the various locations in that mapping. The following
> > > > values are in milliseconds and are the averages of 20 runs each with a
> > > > call to echo 3 > /proc/sys/vm/drop_caches between each run.
> > > >
> > > > The first mapping was made with MAP_PRIVATE | MAP_LOCKED as a baseline:
> > > > Startup average: 9476.506
> > > > Processing average: 3.573
> > > >
> > > > The second mapping was simply MAP_PRIVATE but each page was passed to
> > > > mlock() before being read:
> > > > Startup average: 0.051
> > > > Processing average: 721.859
> > > >
> > > > The final mapping was MAP_PRIVATE | MAP_LOCKONFAULT:
> > > > Startup average: 0.084
> > > > Processing average: 42.125
> > > >
> > >
> > > Michal's suggestion of changing protections and locking in a signal
> > > handler was better than the locking as needed, but still significantly
> > > more work required than the LOCKONFAULT case.
> > >
> > > Startup average: 0.047
> > > Processing average: 86.431
> >
> > Have you played with batching? Has it helped? Anyway it is to be
> > expected that the overhead will be higher than a single mmap call. The
> > question is whether you can live with it because adding a new semantic
> > to mlock sounds trickier and MAP_LOCKED is tricky enough already...
> >
>
> I reworked the experiment to better cover the batching solution. The
> same 5GB data file is used, however instead of 150,000 accesses at
> regular intervals, the test program now does 15,000,000 accesses to
> random pages in the mapping. The rest of the setup remains the same.
>
> mmap with MAP_LOCKED:
> Setup avg: 11821.193
> Processing avg: 3404.286
>
> mmap with mlock() before each access:
> Setup avg: 0.054
> Processing avg: 34263.201
>
> mmap with PROT_NONE and signal handler and batch size of 1 page:
> With the default value in max_map_count, this gets ENOMEM as I attempt
> to change the permissions, after upping the sysctl significantly I get:
> Setup avg: 0.050
> Processing avg: 67690.625
>
> mmap with PROT_NONE and signal handler and batch size of 8 pages:
> Setup avg: 0.098
> Processing avg: 37344.197
>
> mmap with PROT_NONE and signal handler and batch size of 16 pages:
> Setup avg: 0.0548
> Processing avg: 29295.669
>
> mmap with MAP_LOCKONFAULT:
> Setup avg: 0.073
> Processing avg: 18392.136
>
> The signal handler in the batch cases faulted in memory in two steps to
> avoid having to know the start and end of the faulting mapping. The
> first step covers the page that caused the fault as we know that it will
> be possible to lock. The second step speculatively tries to mlock and
> mprotect the batch size - 1 pages that follow. There may be a clever
> way to avoid this without having the program track each mapping to be
> covered by this handeler in a globally accessible structure, but I could
> not find it.
>
> These results show that if the developer knows that a majority of the
> mapping will be used, it is better to try and fault it in at once,
> otherwise MAP_LOCKONFAULT is significantly faster.
>
> Eric
Is there anything else I can add to the discussion here?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] capabilities: Ambient capabilities
From: Andy Lutomirski @ 2015-05-19 20:23 UTC (permalink / raw)
To: Aaron Jones
Cc: Christoph Lameter, Jarkko Sakkinen, Ted Ts'o,
Andrew G. Morgan, Andrew Morton, Serge Hallyn, Michael Kerrisk,
Mimi Zohar, Linux API, Austin S Hemmelgarn, linux-security-module,
LKML, Serge Hallyn, Markku Savela, Kees Cook, Jonathan Corbet
In-Reply-To: <555B9B79.9080806@gmail.com>
On Tue, May 19, 2015 at 1:22 PM, Aaron Jones <aaronmdjones@gmail.com> wrote:
> On 19/05/15 20:07, Andy Lutomirski wrote:> It's in the cover letter,
> rather vaguely. I think I want to change
>> the setpriv syntax a bit before sending it upstream, though -- it's
>> sucks that you have to duplicate the option.
>>
>> Perhaps the ambient-caps option should implicitly raise inheritable
>> caps if they're not already raised. Or maybe the absence of an
>> inh-caps rule should cause any requested ambient caps to be made
>> inheritable as well.
>>
>> --Andy
>
> I propose an additional --ambient-inh option to copy everything from
> --inh-caps to the ambient set. Explicit is better than implicit.
Seems reasonable. I'll do something like that for v2.1.
--Andy
^ permalink raw reply
* Re: [PATCH v2 1/2] capabilities: Ambient capabilities
From: Aaron Jones @ 2015-05-19 20:22 UTC (permalink / raw)
To: Andy Lutomirski, Christoph Lameter
Cc: Jarkko Sakkinen, Ted Ts'o, Andrew G. Morgan, Andrew Morton,
Serge Hallyn, Michael Kerrisk, Mimi Zohar, Linux API,
Austin S Hemmelgarn, linux-security-module, LKML, Serge Hallyn,
Markku Savela, Kees Cook, Jonathan Corbet
In-Reply-To: <CALCETrW6DndOnC5ego+R5rwjoXeFo04cSO4Z2qZnhiJpEPBE=Q@mail.gmail.com>
On 19/05/15 20:07, Andy Lutomirski wrote:> It's in the cover letter,
rather vaguely. I think I want to change
> the setpriv syntax a bit before sending it upstream, though -- it's
> sucks that you have to duplicate the option.
>
> Perhaps the ambient-caps option should implicitly raise inheritable
> caps if they're not already raised. Or maybe the absence of an
> inh-caps rule should cause any requested ambient caps to be made
> inheritable as well.
>
> --Andy
I propose an additional --ambient-inh option to copy everything from
--inh-caps to the ambient set. Explicit is better than implicit.
--
Aaron Jones
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox