On Sun, Jun 15, 2025 at 7:00 AM Alexis Lothoré
wrote:
>
> On Sat Jun 14, 2025 at 12:35 AM CEST, Alexei Starovoitov wrote:
> > On Fri, Jun 13, 2025 at 1:59 AM Alexis Lothoré
> > wrote:
> >>
> >> On Fri Jun 13, 2025 at 10:32 AM CEST, Peter Zijlstra wrote:
>
On Fri, Jun 13, 2025 at 1:59 AM Alexis Lothoré
wrote:
>
> On Fri Jun 13, 2025 at 10:32 AM CEST, Peter Zijlstra wrote:
> > On Fri, Jun 13, 2025 at 10:26:37AM +0200, Alexis Lothoré wrote:
> >> Hi Peter,
> >>
> >> On Fri Jun 13, 2025 at 10:11 AM CEST, Peter Zijlstra wrote:
> >> > On Fri, Jun 13, 2025
On Tue, Jun 3, 2025 at 2:32 PM Luis Gerhorst wrote:
>
> ALU sanitization was introduced to ensure that a subsequent ptr access
> can never go OOB, even under speculation. This is required because we
> currently allow speculative scalar confusion. Spec. scalar confusion is
> possible because Spectr
On Fri, May 9, 2025 at 11:39 AM wrote:
>
> Hello:
>
> This series was applied to bpf/bpf-next.git (master)
> by Alexei Starovoitov :
>
> On Thu, 1 May 2025 09:35:51 +0200 you wrote:
> > This improves the expressiveness of unprivileged BPF by inserting
> >
On Wed, Mar 19, 2025 at 2:06 AM Luis Gerhorst wrote:
>
> Thank you very much for having a look. Let me know whether the above
> resolves your concern.
>
> In any case, should I separate patches 1-3 into another series?
Sorry for the delay. lsfmm was followed by the busy merge window.
Please reba
On Thu, Mar 13, 2025 at 10:57 AM Luis Gerhorst wrote:
>
> This trades verification complexity for runtime overheads due to the
> nospec inserted because of the EINVAL.
>
> With increased limits this allows applying mitigations to large BPF
> progs such as the Parca Continuous Profiler's prog. Howe
On Tue, Dec 31, 2024 at 2:30 AM Thomas Weißschuh wrote:
>
> On 2024-12-30 16:50:41-0800, Alexei Starovoitov wrote:
> > On Sat, Dec 28, 2024 at 12:43 AM Thomas Weißschuh
> > wrote:
> > >
> > > Most users use this function through the BIN_ATTR_SIMPLE* macr
On Sat, Dec 28, 2024 at 12:43 AM Thomas Weißschuh wrote:
>
> Most users use this function through the BIN_ATTR_SIMPLE* macros,
> they can handle the switch transparently.
>
> This series is meant to be merged through the driver core tree.
hmm. why?
I'd rather take patches 2 and 3 into bpf-next t
On Tue, Oct 1, 2024 at 12:18 AM Hari Bathini wrote:
>
>
>
> On 30/09/24 6:25 pm, Alexei Starovoitov wrote:
> > On Sun, Sep 29, 2024 at 10:33 PM Hari Bathini
> > wrote:
> >>
> >>
> >>
> >> On 17/09/24 1:20 pm, Alexei Starovoito
On Sun, Sep 29, 2024 at 10:33 PM Hari Bathini wrote:
>
>
>
> On 17/09/24 1:20 pm, Alexei Starovoitov wrote:
> > On Sun, Sep 15, 2024 at 10:58 PM Hari Bathini
> > wrote:
> >>
> >> +
> >> + /*
> >> +* Generated stack
On Sun, Sep 15, 2024 at 10:58 PM Hari Bathini wrote:
>
> +
> + /*
> +* Generated stack layout:
> +*
> +* func prev back chain [ back chain]
> +* [ ]
> +* bpf prog redzone/tailcallcnt [ ...
On Thu, Jan 11, 2024 at 11:40 AM Nathan Chancellor wrote:
>
> Hi Yonghong,
>
> On Wed, Jan 10, 2024 at 08:05:36PM -0800, Yonghong Song wrote:
> >
> > On 1/9/24 2:16 PM, Nathan Chancellor wrote:
> > > reviews.llvm.org was LLVM's Phabricator instances for code review. It
> > > has been abandoned in
On Tue, Sep 12, 2023 at 4:17 PM Puranjay Mohan wrote:
>
> On Wed, Sep 13, 2023 at 1:04 AM Russell King (Oracle)
> wrote:
> >
> > On Tue, Sep 12, 2023 at 10:46:53PM +, Puranjay Mohan wrote:
> > > The JITs should not depend on the verifier for zero extending the upper
> > > 32 bits of the desti
On Tue, Jun 20, 2023 at 7:51 AM Steven Rostedt wrote:
>
> On Mon, 19 Jun 2023 02:43:58 +0200
> Thomas Gleixner wrote:
>
> > Now you might argue that it _is_ a "hotpath" due to the BPF usage, but
> > then even more so as any intermediate wrapper which converts from one
> > data representation to a
On Mon, Jan 30, 2023 at 3:48 PM Shuah Khan wrote:
>
> >>
> >> These will be applied by maintainers to their trees.
> >
> > Not in this form. They break the build.
>
> Mathieu is sending you the patches in the format you requested in
> the thread on this patch.
It's not the format, but the patch i
On Mon, Jan 30, 2023 at 2:46 PM Shuah Khan wrote:
>
> On 1/27/23 06:57, Mathieu Desnoyers wrote:
> > Hi,
> >
> > This series fixes incorrect kernel header search path in kernel
> > selftests.
> >
> > Near the end of the series, a few changes are not tagged as "Fixes"
> > because the current behavi
On Thu, Jul 1, 2021 at 12:32 PM Naveen N. Rao
wrote:
>
> Alexei Starovoitov wrote:
> > On Thu, Jul 1, 2021 at 8:09 AM Naveen N. Rao
> > wrote:
> >>
> >> Commit 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other
> >> atomics in .
On Thu, Jul 1, 2021 at 8:09 AM Naveen N. Rao
wrote:
>
> Commit 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other
> atomics in .imm") converted BPF_XADD to BPF_ATOMIC and added a way to
> distinguish instructions based on the immediate field. Existing JIT
> implementations were upda
On Fri, Jun 4, 2021 at 4:34 PM Paul Moore wrote:
>
> > Again, the problem is not limited to BPF at all. kprobes is doing register-
> > time hooks which are equivalent to the one of BPF. Anything in run-time
> > trying to prevent probe_read_kernel by kprobes or BPF is broken by design.
>
> Not bein
On Sat, Apr 17, 2021 at 1:16 AM Christophe Leroy
wrote:
>
>
>
> Le 16/04/2021 à 01:49, Alexei Starovoitov a écrit :
> > On Thu, Apr 15, 2021 at 8:41 AM Quentin Monnet
> > wrote:
> >>
> >> 2021-04-15 16:37 UTC+0200 ~ Daniel Borkmann
> >>
On Thu, Apr 15, 2021 at 8:41 AM Quentin Monnet wrote:
>
> 2021-04-15 16:37 UTC+0200 ~ Daniel Borkmann
> > On 4/15/21 11:32 AM, Jianlin Lv wrote:
> >> For debugging JITs, dumping the JITed image to kernel log is discouraged,
> >> "bpftool prog dump jited" is much better way to examine JITed dumps.
On Wed, Dec 16, 2020 at 10:07:37AM +, Christophe Leroy wrote:
> Implement Extended Berkeley Packet Filter on Powerpc 32
>
> Test result with test_bpf module:
>
> test_bpf: Summary: 378 PASSED, 0 FAILED, [354/366 JIT'ed]
nice!
> Registers mapping:
>
> [BPF_REG_0] = r11-r12
>
On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
wrote:
>
>
> On 21.01.2020 17:43, Stephen Smalley wrote:
> > On 1/20/20 6:23 AM, Alexey Budankov wrote:
> >>
> >> Introduce CAP_PERFMON capability designed to secure system performance
> >> monitoring and observability operations so that CAP_PERFMON
On Sun, Jan 12, 2020 at 8:33 PM Zong Li wrote:
>
> I'm not quite familiar with btf, so I have no idea why there are two
> weak symbols be added in 8580ac9404f6 ("bpf: Process in-kernel BTF")
I can explain what these weak symbols are for, but that won't change
the fact that compiler or linker are
On Fri, Jan 10, 2020 at 2:28 PM Alexandre Ghiti wrote:
>
> Hi guys,
>
> On 10/27/19 8:02 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > On Fri, 18 Oct 2019 10:56:57 +1100 Stephen Rothwell
> > wrote:
> >> Hi all,
> >>
> >> After merging the bpf-next tree, today's linux-next build (powerpc
> >> p
On Fri, Dec 13, 2019 at 9:02 AM Andrii Nakryiko
wrote:
>
> On Fri, Dec 13, 2019 at 2:11 AM Thadeu Lima de Souza Cascardo
> wrote:
> >
> > Fedora binutils has been patched to show "other info" for a symbol at the
> > end of the line. This was done in order to support unmaintained scripts
> > that
On Fri, Oct 18, 2019 at 10:56:57AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> WARNING: 2 bad relocations
> c1998a48 R_PPC64_ADDR64_binary__btf_vmlinux_bin_start
> c00
On Thu, Dec 06, 2018 at 02:57:01PM +0530, Sandipan Das wrote:
> Now that there are different variants of pt_regs for userspace and
> kernel, the uapi for the BPF_PROG_TYPE_PERF_EVENT program type must
> be changed by exporting the user_pt_regs structure instead of the
> pt_regs structure that is in
On Sat, Nov 10, 2018 at 1:48 PM David Miller wrote:
>
> From: Michał Mirosław
> Date: Sat, 10 Nov 2018 19:58:29 +0100
>
> > Fix BPF code/JITs to allow for separate VLAN_PRESENT flag
> > storage and finally move the flag to separate storage in skbuff.
> >
> > This is final step to make CLAN.CFI tr
On Fri, May 18, 2018 at 5:50 AM, Sandipan Das
wrote:
> Syncing the bpf.h uapi header with tools so that struct
> bpf_prog_info has the two new fields for passing on the
> addresses of the kernel symbols corresponding to each
> function in a JITed program.
>
> Signed-off-by: Sandipan Das
> ---
>
On 3/1/18 12:51 AM, Naveen N. Rao wrote:
Daniel Borkmann wrote:
On 02/27/2018 01:13 PM, Sandipan Das wrote:
With this patch, it will look like this:
0: (85) call pc+2#bpf_prog_8f85936f29a7790a+3
(Note the +2 is the insn->off already.)
1: (b7) r0 = 1
2: (95) exit
3: (b7) r0 = 2
On 2/9/18 8:54 AM, Naveen N. Rao wrote:
Naveen N. Rao wrote:
Alexei Starovoitov wrote:
On 2/8/18 4:03 AM, Sandipan Das wrote:
The imm field of a bpf_insn is a signed 32-bit integer. For
JIT-ed bpf-to-bpf function calls, it stores the offset from
__bpf_call_base to the start of the callee
On 2/8/18 4:03 AM, Sandipan Das wrote:
The imm field of a bpf_insn is a signed 32-bit integer. For
JIT-ed bpf-to-bpf function calls, it stores the offset from
__bpf_call_base to the start of the callee function.
For some architectures, such as powerpc64, it was found that
this offset may be as l
On Wed, Oct 04, 2017 at 08:50:49AM +0200, Laurent Dufour wrote:
> On 25/09/2017 18:27, Alexei Starovoitov wrote:
> > On Mon, Sep 18, 2017 at 12:15 AM, Laurent Dufour
> > wrote:
> >> Despite the unprovable lockdep warning raised by Sergey, I didn't get any
On Mon, Sep 18, 2017 at 12:15 AM, Laurent Dufour
wrote:
> Despite the unprovable lockdep warning raised by Sergey, I didn't get any
> feedback on this series.
>
> Is there a chance to get it moved upstream ?
what is the status ?
We're eagerly looking forward for this set to land,
since we have se
ns after
> the BPF program.
>
> Signed-off-by: Naveen N. Rao
Acked-by: Alexei Starovoitov
hanges for classic BPF JIT]
> Signed-off-by: Naveen N. Rao
Acked-by: Alexei Starovoitov
On Sat, Sep 24, 2016 at 12:33:54AM +0200, Daniel Borkmann wrote:
> On 09/23/2016 10:35 PM, Naveen N. Rao wrote:
> >Tail calls allow JIT'ed eBPF programs to call into other JIT'ed eBPF
> >programs. This can be achieved either by:
> >(1) retaining the stack setup by the first eBPF program and having
On Sat, Sep 24, 2016 at 02:10:05AM +0530, Naveen N. Rao wrote:
> seccomp_phase1() does not exist anymore. Instead, update sample to use
> __seccomp_filter(). While at it, set max locked memory to unlimited.
>
> Signed-off-by: Naveen N. Rao
Acked-by: Alexei Starovoitov
nks for the fix.
Acked-by: Alexei Starovoitov
On 6/21/16 7:47 AM, Thadeu Lima de Souza Cascardo wrote:
The calling convention is different with ABIv2 and so we'll need changes
in bpf_slow_path_common() and sk_negative_common().
How big would those changes be? Do we know?
How come no one reported this was broken previously? This is the fi
.
>
> Cc: Matt Evans
> Cc: Denis Kirjanov
> Cc: Michael Ellerman
> Cc: Paul Mackerras
> Cc: Alexei Starovoitov
> Cc: Daniel Borkmann
> Cc: "David S. Miller"
> Cc: Ananth N Mavinakayanahalli
> Signed-off-by: Naveen N. Rao
> ---
> arch/powerp
ew tests passed with x64 jit?
Acked-by: Alexei Starovoitov
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 4/5/16 3:02 AM, Naveen N. Rao wrote:
BPF_ALU32 and BPF_ALU64 tests for adding two 32-bit values that results in
32-bit overflow.
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: "David S. Miller"
Cc: Ananth N Mavinakayanahalli
Cc: Michael Ellerman
Cc: Paul Mackerras
Signed-off-
On 4/5/16 3:02 AM, Naveen N. Rao wrote:
Unsigned Jump-if-Greater-Than.
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: "David S. Miller"
Cc: Ananth N Mavinakayanahalli
Cc: Michael Ellerman
Cc: Paul Mackerras
Signed-off-by: Naveen N. Rao
I think some of the tests already cov
On 4/5/16 3:02 AM, Naveen N. Rao wrote:
JMP_JSET tests incorrectly used BPF_JNE. Fix the same.
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: "David S. Miller"
Cc: Ananth N Mavinakayanahalli
Cc: Michael Ellerman
Cc: Paul Mackerras
Signed-off-by: Naveen N. Rao
Good ca
REGS_IP() to access the instruction pointer.
>
> Cc: Alexei Starovoitov
> Cc: Daniel Borkmann
> Cc: David S. Miller
> Cc: Ananth N Mavinakayanahalli
> Cc: Michael Ellerman
> Signed-off-by: Naveen N. Rao
Acked-by: Alexei Starovoitov
__
On Mon, Apr 04, 2016 at 10:31:33PM +0530, Naveen N. Rao wrote:
> While at it, remove the generation of .s files and fix some typos in the
> related comment.
>
> Cc: Alexei Starovoitov
> Cc: David S. Miller
> Cc: Daniel Borkmann
> Cc: Ananth N Mavinakayanahalli
> Cc: Mi
implementing BPF tail calls and skb loads.
Cc: Matt Evans
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: Alexei Starovoitov
Cc: "David S. Miller"
Cc: Ananth N Mavinakayanahalli
Signed-off-by: Naveen N. Rao
---
arch/powerpc/include/asm/ppc-opcode.h | 19 +-
arch/powerpc/net/Makefile
On 4/1/16 7:41 AM, Naveen N. Rao wrote:
On 2016/03/31 10:52AM, Alexei Starovoitov wrote:
On 3/31/16 4:25 AM, Naveen N. Rao wrote:
...
+
+#ifdef __powerpc__
+#define BPF_KPROBE_READ_RET_IP(ip, ctx){ (ip) = (ctx)->link; }
+#define BPF_KRETPROBE_READ_RET_IP(ip,
On 4/1/16 7:37 AM, Naveen N. Rao wrote:
On 2016/03/31 08:19PM, Daniel Borkmann wrote:
On 03/31/2016 07:46 PM, Alexei Starovoitov wrote:
On 3/31/16 4:25 AM, Naveen N. Rao wrote:
clang $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) \
-D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused
On 3/31/16 11:51 AM, Naveen N. Rao wrote:
On 2016/03/31 10:49AM, Alexei Starovoitov wrote:
On 3/31/16 4:25 AM, Naveen N. Rao wrote:
Make BPF samples build depend on CONFIG_SAMPLE_BPF. We still don't add a
Kconfig option since that will add a dependency on llvm for allyesconfig
builds whic
On 3/31/16 11:46 AM, Naveen N. Rao wrote:
It's failing this way on powerpc? Odd.
This fails for me on x86_64 too -- RHEL 7.1.
indeed. fails on centos 7.1, whereas centos 6.7 is fine.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https:
On 3/31/16 4:25 AM, Naveen N. Rao wrote:
Make BPF samples build depend on CONFIG_SAMPLE_BPF. We still don't add a
Kconfig option since that will add a dependency on llvm for allyesconfig
builds which may not be desirable.
Those who need to build the BPF samples can now just do:
make CONFIG_SAMP
On 3/31/16 4:25 AM, Naveen N. Rao wrote:
While at it, fix some typos in the comment.
Cc: Alexei Starovoitov
Cc: David S. Miller
Cc: Ananth N Mavinakayanahalli
Cc: Michael Ellerman
Signed-off-by: Naveen N. Rao
---
samples/bpf/Makefile | 11 ---
1 file changed, 4 insertions(+), 7
};
^
Fix this by including the necessary header file.
Cc: Alexei Starovoitov
Cc: David S. Miller
Cc: Ananth N Mavinakayanahalli
Cc: Michael Ellerman
Signed-off-by: Naveen N. Rao
---
samples/bpf/map_perf_test_user.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/samples/bpf
fixed this to work with x86_64 and arm64, but not s390.
Cc: Alexei Starovoitov
Cc: David S. Miller
Cc: Ananth N Mavinakayanahalli
Cc: Michael Ellerman
Signed-off-by: Naveen N. Rao
---
...
+
+#ifdef __powerpc__
+#define BPF_KPROBE_READ_RET_IP(ip, ctx){ (ip) = (ctx)->link; }
> Acked-by: Daniel Borkmann
good catch indeed.
Classic bpf jits didn't have much love. Great to see this work.
Acked-by: Alexei Starovoitov
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Mon, Feb 16, 2015 at 2:13 AM, Denis Kirjanov wrote:
> On 2/15/15, Daniel Borkmann wrote:
>> On 02/15/2015 07:06 PM, Denis Kirjanov wrote:
>>> This patch series enables BPF JIT on ppc32. There are relatevily
>>> few chnages in the code to make it work.
>>>
>>> All test_bpf tests passed both on
struct module *mod, void *module_region)
> +void __weak module_memfree(void *module_region)
> {
> vfree(module_region);
> }
Looks obviously correct.
Acked-by: Alexei Starovoitov
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.o
On Mon, Nov 17, 2014 at 10:58 PM, Denis Kirjanov wrote:
> Hi Michael,
>
> This patch added no new functionality so I haven't put the test
> results (of course I ran the test suite to check the patch).
>
> The output :
> [ 650.198958] test_bpf: Summary: 60 PASSED,
48 48 PASS
>
> After:
> [ 103.053184] test_bpf: #20 LD_HATYPE 7 6 PASS
>
> CC: Alexei Starovoitov
> CC: Daniel Borkmann
> CC: Philippe Bergheaud
> Signed-off-by: Denis Kirjanov
>
> v2: address Alexei's comments
> ---
> arch/powerpc/net/bpf_jit_comp.c | 17
On Wed, Nov 5, 2014 at 10:02 PM, Denis Kirjanov wrote:
> Add BPF extension SKF_AD_HATYPE to ppc JIT to check
> the hw type of the interface
>
> JIT off:
> [ 69.106783] test_bpf: #20 LD_HATYPE 48 48 PASS
> JIT on:
> [ 64.721757] test_bpf: #20 LD_HATYPE 7 6 PASS
>
>
T 86 97 99 PASS
>> [ 88.265740] test_bpf: #12 LD_PKTTYPE 109 107 PASS
>>
>> After:
>> [ 80.605964] test_bpf: #11 LD_IND_NET 44 40 39 PASS
>> [ 80.607370] test_bpf: #12 LD_PKTTYPE 9 9 PASS
>>
>> CC: Alexei Starovoitov
>> CC: Michael Ellerman
>&
On Wed, Oct 29, 2014 at 11:12 PM, Denis Kirjanov wrote:
> Add BPF extension SKF_AD_PKTTYPE to ppc JIT to load
> skb->pkt_type field.
>
> Before:
> [ 88.262622] test_bpf: #11 LD_IND_NET 86 97 99 PASS
> [ 88.265740] test_bpf: #12 LD_PKTTYPE 109 107 PASS
>
> After:
> [ 80.605964] test_bpf: #11
On Wed, Oct 29, 2014 at 2:21 AM, Denis Kirjanov wrote:
> Any feedback from PPC folks?
not a ppc guy, but looks reasonable to me.
What lib/test_bpf says? Like performance difference before/after
for LD_PKTTYPE test...
___
Linuxppc-dev mailing list
Linuxp
On Tue, Jun 24, 2014 at 2:59 AM, Denis Kirjanov wrote:
> Use the proper mask which is 0xefff
sob is missing.
also please expand the commit message a bit, otherwise it's too cryptic for
folks who don't know bpf details.
> ---
> arch/powerpc/net/bpf_jit_comp.c | 2 +-
> 1 file changed, 1 inserti
On Fri, Oct 4, 2013 at 12:51 AM, Ingo Molnar wrote:
>> +static void bpf_jit_free_deferred(struct work_struct *work)
>> +{
>> + struct sk_filter *fp = container_of((void *)work, struct sk_filter,
>> + insns);
>> + unsigned long addr = (unsigned long)f
ss_callbacks+0x202/0x7c0
[ 57.078962] [] __do_softirq+0xf7/0x3f0
[ 57.085373] [] run_ksoftirqd+0x35/0x70
cannot reuse jited filter memory, since it's readonly,
so use original bpf insns memory to hold work_struct
defer kfree of sk_filter until jit completed freeing
tested on x86_64 and i386
S
ss_callbacks+0x202/0x7c0
[ 57.078962] [] __do_softirq+0xf7/0x3f0
[ 57.085373] [] run_ksoftirqd+0x35/0x70
cannot reuse jited filter memory, since it's readonly,
so use original bpf insns memory to hold work_struct
defer kfree of sk_filter until jit completed freeing
tested on x86_64 and i386
S
ss_callbacks+0x202/0x7c0
[ 57.078962] [] __do_softirq+0xf7/0x3f0
[ 57.085373] [] run_ksoftirqd+0x35/0x70
cannot reuse jited filter memory, since it's readonly,
so use original bpf insns memory to hold work_struct
defer kfree of sk_filter until jit completed freeing
tested on x86_64 and i386
S
On Thu, Oct 3, 2013 at 10:16 PM, Eric Dumazet wrote:
> On Thu, 2013-10-03 at 21:11 -0700, Alexei Starovoitov wrote:
>
> -static inline unsigned int sk_filter_len(const struct sk_filter *fp)
> +static inline unsigned int sk_filter_size(const struct s
72 matches
Mail list logo
