On 29 June 2017 at 16:21, Tom Herbert wrote:
> I think the main part of that discussion was around stream parser
> which is needed for message delineation. For a 1:1 proxy, KCM is
> probably overkill (the whole KCM data path and lock becomes
> superfluous). Also, there's no concept of creating a
Hi Tom
On 29 June 2017 at 11:27, Tom Herbert wrote:
> This is raw, minimally tested, and error hanlding needs work. Posting
> as RFC to get feedback on the design...
>
> Sidecar proxies are becoming quite popular on server as a means to
> perform layer 7 processing on application data as it is se
On 13 December 2016 at 00:41, Stephen Hemminger
wrote:
> I went ahead and fixed these.
Thanks for fixing it up Stephen.
)
> Signed-off-by: Alexei Starovoitov
> Acked-by: Daniel Borkmann
Acked-by: Thomas Graf
Signed-off-by: Thomas Graf
Acked-by: Daniel Borkmann
---
lib/bpf.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/lib/bpf.c b/lib/bpf.c
index 8a5b84b..f3dace2 100644
--- a/lib/bpf.c
+++ b/lib/bpf.c
@@ -912,15 +912,18 @@ bpf_dump_error(struct bpf_elf_ctx *ctx, const
- direct packet read is allowed for LWT_*
- direct packet write for LWT_IN/LWT_OUT is prohibited
- direct packet write for LWT_XMIT is allowed
- access to skb->tc_classid is prohibited for LWT_*
Signed-off-by: Thomas Graf
Acked-by: Daniel Borkmann
---
tools/testing/selftests/
On 12/01/16 at 01:08pm, Daniel Borkmann wrote:
> For the verifier change in may_access_direct_pkt_data(), would be
> great if you could later on follow up with a selftest-suite case,
> one where BPF_PROG_TYPE_LWT_IN/OUT prog tries to write and fails,
> and one where BPF_PROG_TYPE_LWT_IN/OUT prog us
On 12/01/16 at 04:52pm, Hannes Frederic Sowa wrote:
> First of all, this is a rant targeted at XDP and not at eBPF as a whole.
> XDP manipulates packets at free will and thus all security guarantees
> are off as well as in any user space solution.
>
> Secondly user space provides policy, acl, more
On 12/01/16 at 10:11am, Florian Westphal wrote:
> Aside from this, XDP, like DPDK, is a kernel bypass.
> You might say 'Its just stack bypass, not a kernel bypass!'.
> But what does that mean exactly? That packets can still be passed
> onward to normal stack?
> Bypass solutions like netmap can als
r creates circular dst redirection. Also resolves the
issue for ILA.
- Fix to ensure headroom for potential future L2 header is still
guaranteed
Thomas Graf (4):
route: Set orig_output when redirecting to lwt on locally generated
traffic
route: Set lwtstate for local traffic and cac
allocated in the otuput path as well.
Also, if a route is cached in the input path, the allocated dst should
respect lwtunnel configuration on the nexthop as well.
Signed-off-by: Thomas Graf
---
net/ipv4/route.c | 39 ++-
1 file changed, 26 insertions(+), 13
he return codes are binary compatible with their TC_ACT_
relatives to ease compatibility.
Signed-off-by: Thomas Graf
---
include/linux/filter.h| 2 +-
include/uapi/linux/bpf.h | 32 +++-
include/uapi/linux/lwtunnel.h | 23 +++
kernel/bpf/verifier.c | 14 +-
ne
|
4096 -> 8191 : 180 | |
8192 -> 16383: 5578023 |* |
16384 -> 32767: 632099 |*** |
32768 -> 65535: 6575 |
orig_output for IPv4 was only set for dsts which hit an input route.
Set it consistently for locally generated traffic as well to allow
lwt to continue the dst_output() path as configured by the nexthop.
Fixes: 2536862311d ("lwt: Add support to redirect dst.input")
Signed-off-by: T
On 11/29/16 at 11:01pm, Alexei Starovoitov wrote:
> On Wed, Nov 30, 2016 at 07:48:51AM +0100, Thomas Graf wrote:
> > Should we check in __bpf_redirect_common() whether mac_header <
> > nework_header then or add it to lwt-bpf conditional on
> > dev_is_mac_header_xmit()?
&g
On 11/29/16 at 04:17pm, Alexei Starovoitov wrote:
> On Tue, Nov 29, 2016 at 02:21:23PM +0100, Thomas Graf wrote:
> > Adds a series of test to verify the functionality of attaching
> > BPF programs at LWT hooks.
> >
> > Also adds a sample which collects a histogram of
On 11/29/16 at 04:15pm, Alexei Starovoitov wrote:
> On Tue, Nov 29, 2016 at 02:21:22PM +0100, Thomas Graf wrote:
> ...
> > +#define LWT_BPF_MAX_HEADROOM 128
>
> why 128?
> btw I'm thinking for XDP to use 256, so metadata can be stored in there.
It's an a
Hi Hannes,
On 11/29/16 at 03:15pm, Hannes Frederic Sowa wrote:
> Did you look at the cgroup based hooks which were added recently in
> ip_finish_output for cgroup ebpf support and in general the cgroup bpf
> subsystem. Does some of this solve the problem for you already? Would be
> interesting to
orig_output for IPv4 was only set for dsts which hit an input route.
Set it consistently for locally generated traffic as well to allow
lwt to continue the dst_output() path as configured by the nexthop.
Fixes: 2536862311d ("lwt: Add support to redirect dst.input")
Signed-off-by: T
|
4096 -> 8191 : 180 | |
8192 -> 16383: 5578023 |* |
16384 -> 32767: 632099 |*** |
32768 -> 65535: 6575 |
urn codes are binary compatible with their TC_ACT_
relatives to ease compatibility.
Signed-off-by: Thomas Graf
---
include/linux/filter.h| 2 +-
include/uapi/linux/bpf.h | 32 +++-
include/uapi/linux/lwtunnel.h | 23 +++
kernel/bpf/verifier.c | 14 +-
ne
ted by Tom.
- New sample to illustrate rerouting
- New patch 05: Recursion limit for lwtunnel_output for the case
when user creates circular dst redirection. Also resolves the
issue for ILA.
- Fix to ensure headroom for potential future L2 header is still
guaranteed
Thomas Graf (4):
allocated in the otuput path as well.
Also, if a route is cached in the input path, the allocated dst should
respect lwtunnel configuration on the nexthop as well.
Signed-off-by: Thomas Graf
---
net/ipv4/route.c | 39 ++-
1 file changed, 26 insertions(+), 13
On 11/04/16 at 11:29am, David Lebrun wrote:
> +/* insert an SRH within an IPv6 packet, just after the IPv6 header */
> +static int seg6_do_srh_inline(struct sk_buff *skb, struct ipv6_sr_hdr *osrh)
> +{
> + struct ipv6hdr *hdr, *oldhdr;
> + struct ipv6_sr_hdr *isrh;
> + int hdrlen, err;
On 3 November 2016 at 08:52, Hannes Frederic Sowa
wrote:
> On 02.11.2016 23:54, Thomas Graf wrote:
>> Why would I want to accept the overhead if I simply avoid it? Just
>> parsing the header and doing the hash lookup will add cost, cost for
>> each packet.
>
> That i
On 2 November 2016 at 04:48, Hannes Frederic Sowa
wrote:
> On Wed, Nov 2, 2016, at 00:07, Tom Herbert wrote:
>> On the other hand, I'm not really sure how to implement for this level
>> of performance this in LWT+BPF either. It seems like one way to do
>> that would be to create a program each des
On 2 November 2016 at 07:39, Roopa Prabhu wrote:
>> diff --git a/net/core/Makefile b/net/core/Makefile
>> index d6508c2..a675fd3 100644
>> --- a/net/core/Makefile
>> +++ b/net/core/Makefile
>> @@ -23,7 +23,7 @@ obj-$(CONFIG_NETWORK_PHY_TIMESTAMPING) += timestamping.o
>> obj-$(CONFIG_NET_PTP_CLASS
On 1 November 2016 at 17:07, Tom Herbert wrote:
> On the other hand, I'm not really sure how to implement for this level
> of performance this in LWT+BPF either. It seems like one way to do
> that would be to create a program each destination and set it each
> host. As you point out would create a
On 1 November 2016 at 16:12, Hannes Frederic Sowa
wrote:
> On 01.11.2016 21:59, Thomas Graf wrote:
>>> Dumping and verifying which routes get used might actually already be
>>> quite complex on its own. Thus my fear.
>>
>> We even have an API to query which route
On 1 November 2016 at 13:33, Tom Herbert wrote:
> You need to show that is integrity is maintained with these patches.
> Part of this can be done, but part of this needs to be established in
> testing.
>
> I've already given specifics for at least one potential source of
> issues in routing issues
On 1 November 2016 at 13:11, David Ahern wrote:
> On 10/31/16 6:37 PM, Thomas Graf wrote:
>> - Perform simple encapsulation where offload is of no concern.
>>(The existing funtionality to attach a tunnel key to the skb
>> and redirect to a tunnel net_device
On 1 November 2016 at 13:08, Hannes Frederic Sowa
wrote:
> On Tue, Nov 1, 2016, at 19:51, Thomas Graf wrote:
>> If I understand you correctly then a single BPF program would be
>> loaded which then applies to all dst_output() calls? This has a huge
>> drawback, instead
On 1 November 2016 at 12:27, Tom Herbert wrote:
> On Tue, Nov 1, 2016 at 12:11 PM, Thomas Graf wrote:
>> You can do the same with act_pedit or cls_bpf at dev_queue_xmit()
>> before or after you go into the encapsulation device. This is a tool
>> for root, if you install a d
On 1 November 2016 at 11:51, Tom Herbert wrote:
> On Tue, Nov 1, 2016 at 11:20 AM, Thomas Graf wrote:
>> The headers cannot be extended or reduced so the offsets always remain
>> correct. What can happen is that the header contains invalid data.
>>
> If we can't ad
On 1 November 2016 at 03:54, Hannes Frederic Sowa
wrote:
> I do fear the complexity and debugability introduced by this patch set
> quite a bit.
What is the complexity concern? This is pretty straight forward. I
agree on debugability. This is being worked on separately as Alexei
mentioned, to add
On 1 November 2016 at 09:17, Tom Herbert wrote:
> On Mon, Oct 31, 2016 at 5:37 PM, Thomas Graf wrote:
>> {Open question:
>> Tom brought up the question on whether it is safe to modify the packet
>> in artbirary ways before dst_output(). This is the equivalent to a raw
On 11/01/16 at 12:52pm, kbuild test robot wrote:
> Hi Thomas,
>
> [auto build test ERROR on net-next/master]
>
> url:
> https://github.com/0day-ci/linux/commits/Thomas-Graf/bpf-BPF-for-lightweight-tunnel-encapsulation/20161101-084038
> config: arm64-allmodconfig
for lwtunnel_output for the case
when user creates circular dst redirection. Also resolves the
issue for ILA.
- Fix to ensure headroom for potential future L2 header is still
guaranteed
Thomas Graf (5):
route: Set orig_output when redirecting to lwt on locally generated
traffic
route:
rewrite in dst_output()
- L2 MAC header push + redirect in lwt xmit
Signed-off-by: Thomas Graf
---
samples/bpf/bpf_helpers.h | 4 +
samples/bpf/lwt_bpf.c | 235
samples/bpf/test_lwt_bpf.sh | 370
3 files changed, 609
allocated in the otuput path as well.
Also, if a route is cached in the input path, the allocated dst should
respect lwtunnel configuration on the nexthop as well.
Signed-off-by: Thomas Graf
---
net/ipv4/route.c | 39 ++-
1 file changed, 26 insertions(+), 13
Signed-off-by: Thomas Graf
---
net/core/lwtunnel.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/net/core/lwtunnel.c b/net/core/lwtunnel.c
index 554d901..6363d0b 100644
--- a/net/core/lwtunnel.c
+++ b/net/core/lwtunnel.c
@@ -231,6 +231,10 @@ int
funtionality to attach a tunnel key to the skb
and redirect to a tunnel net_device to allow for offload
continues to work obviously).
Signed-off-by: Thomas Graf
---
include/linux/filter.h| 2 +-
include/uapi/linux/bpf.h | 37 +++-
include/uapi/linux/lwtunnel.h | 21
orig_output for IPv4 was only set for dsts which hit an input route.
Set it consistently for locally generated traffic as well to allow
lwt to continue the dst_output() path as configured by the nexthop.
Fixes: 2536862311d ("lwt: Add support to redirect dst.input")
Signed-off-by: T
On 10/31/16 at 12:22pm, John Fastabend wrote:
> On 16-10-31 11:57 AM, David Miller wrote:
> > My understanding is that the eBPF program would be responsible
> > for updating the checksum if it mangles the packet in such a
> > way that such a fixup would be required.
> >
>
> For XDP we will probab
On 10/31/16 at 06:16pm, Daniel Mack wrote:
> On 10/31/2016 06:05 PM, David Ahern wrote:
> > On 10/31/16 11:00 AM, Daniel Mack wrote:
> >> Yeah, I'm confused too. I changed that name in my v7 from
> >> BPF_PROG_TYPE_CGROUP_SOCK to BPF_PROG_TYPE_CGROUP_SKB on David's
> >> (Ahern) request. Why is it
On 10/31/16 at 11:16am, David Ahern wrote:
> On 10/31/16 11:01 AM, David Miller wrote:
> > Also, any reason why you don't allow the cgroup bpf sk filter to return
> > an error code so that the sock creation could be cancelled if the eBPF
> > program desires that? It could be useful, I suppose.
>
On 10/31/16 at 09:07am, Tom Herbert wrote:
> I guess this leads to a more general question I have about the effects
> of allowing userspace to insert code in the kernel that modifies
> packets. If we allow BPF programs to arbitrarily modify packets in
> LWT, how do we ensure that there are no insid
On 10/31/16 at 07:17am, Tom Herbert wrote:
> On Mon, Oct 31, 2016 at 5:59 AM, Thomas Graf wrote:
> > Noticed while implementing this: How does ILA ensure that dst_output()
> > is not invoked in a circular manner?
> >
> > dstA->output() -> dstB->otuput() ->
On 10/30/16 at 06:28pm, Tom Herbert wrote:
> Right, that's why we rely on a dst cache. Any use of LWT that
> encapsulates or tunnels to a fixed destination (ILA, VXLAN, IPIP,
> etc.) would want to use the dst cache optimization to avoid the second
> lookup. The ILA LWT code used to call orig output
On 10/30/16 at 06:28pm, Tom Herbert wrote:
> On Sun, Oct 30, 2016 at 2:47 PM, Thomas Graf wrote:
> > Instead of building complex logic, we can allow the program to return
> > a code to indicate when to perform another route lookup just as we do
> > for the redirect c
On 10/30/16 at 01:34pm, Tom Herbert wrote:
> On Sun, Oct 30, 2016 at 4:58 AM, Thomas Graf wrote:
> > + if (unlikely(!dst->lwtstate->orig_output)) {
> > + WARN_ONCE(1, "orig_output not set on dst for prog %s\n",
> > +
orig_output for IPv4 was only set for dsts which hit an input route.
Set it consistently for locally generated traffic as well to allow
lwt to continue the dst_output() path as configured by the nexthop.
Fixes: 2536862311d ("lwt: Add support to redirect dst.input")
Signed-off-by: T
allocated in the otuput path as well.
Also, if a route is cached in the input path, the allocated dst should
respect lwtunnel configuration on the nexthop as well.
Signed-off-by: Thomas Graf
---
net/ipv4/route.c | 39 ++-
1 file changed, 26 insertions(+), 13
rewrite in dst_output()
- L2 MAC header push + redirect in lwt xmit
Signed-off-by: Thomas Graf
---
samples/bpf/bpf_helpers.h | 4 +
samples/bpf/lwt_bpf.c | 210 +++
samples/bpf/test_lwt_bpf.sh | 337
3 files changed, 551
funtionality to attach a tunnel key to the skb
and redirect to a tunnel net_device to allow for offload
continues to work obviously).
Signed-off-by: Thomas Graf
---
include/linux/filter.h| 2 +-
include/uapi/linux/bpf.h | 31 +++-
include/uapi/linux/lwtunnel.h | 21
routed
in an async manner
- Fast encapsulation + redirect. For now limited to use cases where not
setting inner and outer offset/protocol is OK.
A couple of samples on how to use it can be found in patch 04.
Thomas Graf (4):
route: Set orig_output when redirecting to lwt on locally
On 10/30/16 at 08:44am, Jiri Pirko wrote:
> Sat, Oct 29, 2016 at 06:46:21PM CEST, john.fastab...@gmail.com wrote:
> >On 16-10-29 07:49 AM, Jakub Kicinski wrote:
> >> On Sat, 29 Oct 2016 09:53:28 +0200, Jiri Pirko wrote:
> >>> Hi all.
> >>>
> >>> The network world is divided into 2 general types of
On 10/29/16 at 01:28pm, Jiri Pirko wrote:
> Sat, Oct 29, 2016 at 01:15:48PM CEST, tg...@suug.ch wrote:
> >So given the SKIP_SW flag, the in-kernel compiler is optional anyway.
> >Why even risk including a possibly incomplete compiler? Older kernels
> >must be capable of running along newer hardware
On 10/28/16 at 08:51pm, Shrijeet Mukherjee wrote:
> Generally agree, but SRIOV nics with multiple queues can end up in a bad
> spot if each buffer was 4K right ? I see a specific page pool to be used
> by queues which are enabled for XDP as the easiest to swing solution that
> way the memory overhe
On 10/29/16 at 12:10pm, Jiri Pirko wrote:
> Sat, Oct 29, 2016 at 11:39:05AM CEST, tg...@suug.ch wrote:
> >On 10/29/16 at 09:53am, Jiri Pirko wrote:
> >> 3) Expose the p4ast in-kernel interpreter to userspace
> >>As the easiest way I see in to introduce a new TC classifier cls_p4.
> >>
> >>
On 10/29/16 at 09:53am, Jiri Pirko wrote:
> Hi all.
>
> The network world is divided into 2 general types of hw:
> 1) network ASICs - network specific silicon, containing things like TCAM
>These ASICs are suitable to be programmed by P4.
> 2) network processors - basically a general purpose CP
documentation to a single comment and renames all
helpers names in the list to conform to the bpf_ prefix notation so
they can be greped in the kernel source.
Signed-off-by: Thomas Graf
Acked-by: Daniel Borkmann
Acked-by: Alexei Starovoitov
---
include/uapi/linux/bpf.h | 574
On 10/26/16 at 10:08am, David Ahern wrote:
> On 10/26/16 2:41 AM, Thomas Graf wrote:
> > On 10/25/16 at 03:30pm, David Ahern wrote:
> >> @@ -171,6 +177,9 @@ int __cgroup_bpf_run_filter(struct sock *sk,
> >>case BPF_CGROUP_INET_EGRESS:
On 10/26/16 at 10:59am, Johannes Berg wrote:
>
> > /**
> > + * nla_memdup - duplicate attribute memory (kmemdup)
> > + * @src: netlink attribute to duplicate from
> > + * @gfp: GFP mask
>
> Actually, is there any point in passing a GFP mask? None of the current
> users need it, and it seems fair
On 10/24/16 at 02:11pm, Geert Uytterhoeven wrote:
> Hi Phil,
>
> On m68k/ARAnyM, test_rhashtable fails with:
>
> Test failed: thread 0 returned: -4
>
> (-4 = -EINTR)
The error is returned by kthread_stop(), I suspect we are running into
this:
static int kthread(void *_create)
{
[..
Wrap several common instances of:
kmemdup(nla_data(attr), nla_len(attr), GFP_KERNEL);
Signed-off-by: Thomas Graf
---
include/net/netlink.h | 10 ++
net/sched/act_bpf.c| 4 +---
net/sched/cls_bpf.c| 4 +---
net/wireless/nl80211.c | 3 +--
4 files changed, 13
On 10/25/16 at 03:30pm, David Ahern wrote:
> @@ -171,6 +177,9 @@ int __cgroup_bpf_run_filter(struct sock *sk,
> case BPF_CGROUP_INET_EGRESS:
> ret = __cgroup_bpf_run_filter_skb(skb, prog);
> break;
> + case BPF_CGROUP_INET_SOCK_C
The field is initialized by ILA and MPLS but never used. Remove it.
Signed-off-by: Thomas Graf
---
include/net/lwtunnel.h | 3 +--
net/ipv6/ila/ila_lwt.c | 4 +---
net/mpls/mpls_iptunnel.c | 5 +
3 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/include/net/lwtunnel.h b
On 10/20/16 at 11:20am, David Miller wrote:
> This patch only applies to net-next, so I've applied it there.
>
> Please explain how I should handle 'net' and -stable.
The presence of ila_params_lwtunnel() in 'net' lead me to believe that
'net' is affected as well. It is not. Applying to 'net-next
;
u32 connected : 1;
};
Fixes: 65d7ab8de582 ("net: Identifier Locator Addressing module")
Signed-off-by: Thomas Graf
Acked-by: Daniel Borkmann
---
-stable candidate
net/ipv6/ila/ila_lwt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ila/ila_lwt.c b/ne
On 09/14/16 at 09:23am, Mickaël Salaün wrote:
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 9aa01d9d3d80..36c3e482239c 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -85,6 +85,8 @@ enum bpf_arg_type {
>
> ARG_PTR_TO_CTX, /* pointer to context
On 09/14/16 at 09:23am, Mickaël Salaün wrote:
> This fix a pointer leak when an unprivileged eBPF program read a pointer
> value from the context. Even if is_valid_access() returns a pointer
> type, the eBPF verifier replace it with UNKNOWN_VALUE. The register
> value containing an address is then
On 09/14/16 at 09:23am, Mickaël Salaün wrote:
> @@ -155,6 +163,7 @@ union bpf_attr {
> __u32 log_size; /* size of user buffer */
> __aligned_u64 log_buf;/* user supplied buffer */
> __u32 kern_version; /* checked when
x27;
This commit extends the verifier to keep track of all identical
PTR_TO_MAP_VALUE_OR_NULL registers after a map_elem_lookup() by
assigning them an ID and then marking them all when the conditional
jump is observed.
Signed-off-by: Thomas Graf
Reviewed-by: Josef Bacik
Acked-by: Daniel Borkmann
On 09/22/16 at 11:21am, Pablo Neira Ayuso wrote:
> I have a hard time to buy this new specific hook, I think we should
> shift focus of this debate, this is my proposal to untangle this:
>
> You add a net/netfilter/nft_bpf.c expression that allows you to run
> bpf programs from nf_tables. This exp
On 09/21/16 at 11:50am, Tom Herbert wrote:
> 50 lines in one driver is not a big deal, 50 lines in a hundred
> drivers is! I learned this lesson in BQL which was well abstracted out
> to be minimally invasive but we still saw many issues because of the
> pecularities of different drivers.
You want
On 09/21/16 at 05:45pm, Pablo Neira Ayuso wrote:
> On Tue, Sep 20, 2016 at 06:43:35PM +0200, Daniel Mack wrote:
> > The point is that from an application's perspective, restricting the
> > ability to bind a port and dropping packets that are being sent is a
> > very different thing. Applications wi
On 09/21/16 at 07:19am, Tom Herbert wrote:
> certain design that because of constraints on one kernel interface. As
> a kernel developer I want flexibility on how we design and implement
> things!
Perfectly valid argument. I reviewed your ILA changes and did not
object to them.
> I think there a
On 09/21/16 at 07:53am, Neal Cardwell wrote:
> On Wed, Sep 21, 2016 at 12:44 AM, David Miller wrote:
> > From: Neal Cardwell
> > Date: Mon, 19 Sep 2016 23:39:07 -0400
> >
> >> tcp: BBR congestion control algorithm
> >
> > Series applied, thanks Neal.
>
> Thanks, David!
Let me just say that this
On 09/20/16 at 04:59pm, Tom Herbert wrote:
> Well, need to measure to ascertain the cost. As for complexity, this
> actually reduces complexity needed for XDP in the drivers which is a
> good thing because that's where most of the support and development
> pain will be.
I'm not objecting to anythi
On 09/20/16 at 04:18pm, Tom Herbert wrote:
> This allows other use cases than BPF inserting code into the data
> path. This gives XDP potential more utility and more users so that we
> can motivate more driver implementations. For instance, I thinks it's
> totally reasonable if the nftables guys wa
On 09/20/16 at 03:49pm, Tom Herbert wrote:
> On Tue, Sep 20, 2016 at 3:44 PM, Thomas Graf wrote:
> > On 09/20/16 at 03:00pm, Tom Herbert wrote:
> >> +static inline int __xdp_hook_run(struct list_head *list_head,
> >> + struct xdp_buff *xdp
On 09/20/16 at 03:00pm, Tom Herbert wrote:
> +static inline int __xdp_hook_run(struct list_head *list_head,
> + struct xdp_buff *xdp)
> +{
> + struct xdp_hook_ops *elem;
> + int ret = XDP_PASS;
> +
> + list_for_each_entry(elem, list_head, list) {
> +
On 09/20/16 at 05:36pm, Herbert Xu wrote:
> Tom Herbert wrote:
> > Split out most of rht_key_hashfn which is calculating the hash into
> > its own function. This way the hash function can be called separately to
> > get the hash value.
> >
> > Acked-by: Th
On 09/20/16 at 09:45am, Alexei Starovoitov wrote:
> that's a great idea. Instead of adding aborted, ring_full, blahblah counters
> everywhere that cost performance, let's add tracepoints that are nops
> when not in use.
> And if all drivers call the same tracepoints it will be even better.
> Monito
On 09/20/16 at 04:29pm, Pablo Neira Ayuso wrote:
> On Mon, Sep 19, 2016 at 10:56:14PM +0200, Daniel Mack wrote:
> [...]
> > Why would we artificially limit the use-cases of this implementation if
> > the way it stands, both filtering and introspection are possible?
>
> Why should we place infrastr
On 09/19/16 at 01:13pm, Alexei Starovoitov wrote:
> as far as bpf debuggability/visibility there are various efforts on the way:
> for kernel side:
> - ksym for jit-ed programs
> - hash sum for prog code
> - compact type information for maps and various pretty printers
> - data flow analysis of the
nly potential
> user of it does not need duplicate objects. Should anyone need
> this it shouldn't be too hard to add.
>
> Signed-off-by: Herbert Xu
Nice, I like how this simplifies users! Is this suitable for
ILA as well?
Acked-by: Thomas Graf
On 09/14/16 at 12:30pm, Pablo Neira Ayuso wrote:
> On Tue, Sep 13, 2016 at 09:42:19PM -0700, Alexei Starovoitov wrote:
> [...]
> > For us this cgroup+bpf is _not_ for filterting and _not_ for security.
>
> If your goal is monitoring, then convert these hooks not to allow to
> issue a verdict on th
On 09/09/16 at 04:19pm, Tom Herbert wrote:
> diff --git a/net/core/resolver.c b/net/core/resolver.c
> new file mode 100644
> index 000..61b36c5
> --- /dev/null
> +++ b/net/core/resolver.c
> @@ -0,0 +1,267 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#inclu
locks in the array as well
> as a CPU multiplier to derive the number of spinlocks to allocate.
> The number to allocated is rounded up to a power of two to make
> the array amenable to hash lookup.
>
> Signed-off-by: Tom Herbert
Acked-by: Thomas Graf
On 09/09/16 at 04:19pm, Tom Herbert wrote:
> Split out most of rht_key_hashfn which is calculating the hash into
> its own function. This way the hash function can be called separately to
> get the hash value.
>
> Signed-off-by: Tom Herbert
Acked-by: Thomas Graf
ff-by: Tom Herbert
Acked-by: Thomas Graf
[Sorry for the repost, gmail decided to start sending HTML crap along
overnight for some reason]
On 09/13/16 at 09:42pm, Alexei Starovoitov wrote:
> On Tue, Sep 13, 2016 at 07:24:08PM +0200, Pablo Neira Ayuso wrote:
> > Then you have to explain me how can anyone else than systemd use this
> > inf
Signed-off-by: Thomas Graf
---
ip/iptuntap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ip/iptuntap.c b/ip/iptuntap.c
index 34fb0cf..451f7f0 100644
--- a/ip/iptuntap.c
+++ b/ip/iptuntap.c
@@ -39,7 +39,7 @@ static void usage(void)
{
fprintf(stderr, "Usag
On 08/19/16 at 06:21pm, Pablo Neira Ayuso wrote:
> On Fri, Aug 19, 2016 at 12:35:14PM +0200, Daniel Mack wrote:
> > Also true. A cgroup can currently only hold one bpf program for each
> > direction, and they are supposed to be set from one controlling instance
> > in the system. However, it is pos
On 08/19/16 at 06:31pm, Pablo Neira Ayuso wrote:
> Why do you need global seccomp policies? The process knows better what
> he needs to place in his sandbox, so attaching this from the process
> itself makes more sense to me... Anyway, this reminds me to selinux.
Two different objectives. The poin
On 08/18/16 at 04:48pm, Herbert Xu wrote:
> Dave/Tomas, please keep an eye out for any new patches that try
> to introduce raw table walkers and nack them.
Very nice work Herbert. I think we should move the rht_for_each_* macros
to a private header or lib/rhashtable.c to discourage usage altogethe
On 08/19/16 at 04:21pm, Herbert Xu wrote:
> This patch converts the diag dumping code to use the rhashtable
> walk code instead of going through rhashtable by hand. The lock
> nl_table_lock is now only taken while we process the multicast
> list as it's not needed for the rhashtable walk.
>
> Sig
On 08/18/16 at 04:50pm, Herbert Xu wrote:
> As I'm working actively on rhashtable it helps if people CCed me
> when they work on in.
>
> Signed-off-by: Herbert Xu
Acked-by: Thomas Graf
1 - 100 of 1030 matches
Mail list logo
