On Fri, Nov 27, 2020 at 05:57:26PM +, Brendan Jackman wrote:
> +/* Emit the ModR/M byte for addressing *(r1 + off) and r2 */
> +static void emit_modrm_dstoff(u8 **pprog, u32 r1, u32 r2, int off)
same concern as in the another patch. If you could avoid intel's puzzling names
like above it will
On Fri, Nov 27, 2020 at 05:57:27PM +, Brendan Jackman wrote:
> The JIT case for encoding atomic ops is about to get more
> complicated. In order to make the review & resulting code easier,
> let's factor out some shared helpers.
>
> Signed-off-by: Brendan Jackman
> ---
>
On Thu, Nov 26, 2020 at 05:57:47PM +0100, Florent Revest wrote:
> This helper exposes the kallsyms_lookup function to eBPF tracing
> programs. This can be used to retrieve the name of the symbol at an
> address. For example, when hooking into nf_register_net_hook, one can
> audit the name of the
On Wed, Nov 25, 2020 at 6:30 PM Roman Gushchin wrote:
>
> I did consider this option. There are pros and cons. In general we tend to
> charge the cgroup
> which actually allocates the memory, and I decided to stick with this rule. I
> agree, it's fairly
> easy to come with arguments why always
On Fri, Nov 20, 2020 at 01:17:07PM +, KP Singh wrote:
> +
> +static bool bpf_ima_inode_hash_allowed(const struct bpf_prog *prog)
> +{
> + return bpf_lsm_is_sleepable_hook(prog->aux->attach_btf_id);
> +}
> +
> +BTF_ID_LIST_SINGLE(bpf_ima_inode_hash_btf_ids, struct, inode)
> +
> +const
On Thu, Nov 19, 2020 at 09:37:52AM -0800, Roman Gushchin wrote:
> static void bpf_map_put_uref(struct bpf_map *map)
> @@ -619,7 +562,7 @@ static void bpf_map_show_fdinfo(struct seq_file *m,
> struct file *filp)
> "value_size:\t%u\n"
> "max_entries:\t%u\n"
>
On Thu, Nov 19, 2020 at 10:40:21AM -0800, Linus Torvalds wrote:
> On Thu, Nov 19, 2020 at 10:34 AM Alexei Starovoitov
> wrote:
> >
> > ping.
>
> I'm ok with this series that adds explanations for why you care and
> what bpf does that makes it valid.
Great.
> So t
On Tue, Nov 17, 2020 at 12:14 PM Alexei Starovoitov
wrote:
>
> On Tue, Nov 17, 2020 at 12:05 PM Daniel Xu wrote:
> >
> > This commit uses the proper word-at-a-time APIs to avoid overcopying.
>
> that part of the commit log is no longer correct. I can fix it up whil
On Thu, Nov 19, 2020 at 6:59 AM Steven Rostedt wrote:
> Linux obviously
> supports multiple architectures (more than any other OS), but it is pretty
> stuck to gcc as a compiler (with LLVM just starting to work too).
>
> We are fine with being stuck to a compiler if it gives us what we want.
I
On Thu, Nov 19, 2020 at 7:46 AM Jakub Kicinski wrote:
>
> On Wed, 18 Nov 2020 17:26:53 -0800 Guenter Roeck wrote:
> > On Wed, Nov 18, 2020 at 05:01:19PM -0800, Guenter Roeck wrote:
> > > On Wed, Nov 18, 2020 at 03:42:53PM -0800, Tao Ren wrote:
> > > > On Thu, Nov 19, 2020 at 12:27:19AM +0100,
On Wed, Nov 18, 2020 at 6:22 AM Steven Rostedt wrote:
>
> Thus, all functions will be non-variadic in these cases.
That's not the only case where it will blow up.
Try this on sparc:
struct foo {
int a;
};
struct foo foo_struct(void) {
struct foo f = {};
return f;
}
int foo_int(void) {
return 0;
aced by a
> stub that will be ignored in the callback loop, and it will be cleaned up
> on the next modification of the array.
>
> Link: https://lore.kernel.org/r/20201115055256.65625-1-mmull...@mmlx.us
> Link: https://lkml.kernel.org/r/20201116175107.02db3...@gandalf.local.home
>
> Cc: Mathie
On Tue, Nov 10, 2020 at 1:04 AM Xin Yin wrote:
>
> For lru_percpu_map update elem, prealloc_lru_pop() may return
> an unclear elem, if the func called by bpf prog and "onallcpus"
> set to false, it may update an elem whith dirty data.
>
> Clear percpu value of the elem, before use it.
>
>
On Wed, Nov 11, 2020 at 1:31 AM Masami Hiramatsu wrote:
>
> Hi Luo,
>
> On Tue, 10 Nov 2020 16:42:45 +0800
> Luo Meng wrote:
>
> > Fix a mutex_unlock() issue where before copy_from_user() is
> > not called mutex_locked.
>
> Oops, thank you for the fix.
>
> Acked-by: Masami Hiramatsu
Did anyone
On Tue, Nov 17, 2020 at 5:07 PM Roman Gushchin wrote:
>
> On Tue, Nov 17, 2020 at 04:46:34PM -0800, Roman Gushchin wrote:
> > On Wed, Nov 18, 2020 at 01:06:17AM +0100, Daniel Borkmann wrote:
> > > On 11/17/20 4:40 AM, Roman Gushchin wrote:
> > > > In the absolute majority of cases if a process is
On Tue, Nov 17, 2020 at 12:05 PM Daniel Xu wrote:
>
> This commit uses the proper word-at-a-time APIs to avoid overcopying.
that part of the commit log is no longer correct. I can fix it up while applying
if Linus doesn't have an issue with the rest.
On Mon, Nov 16, 2020 at 2:48 PM KP Singh wrote:
>
> [...]
>
> > >
> > > +BPF_CALL_2(bpf_lsm_set_bprm_opts, struct linux_binprm *, bprm, u64,
> > > flags)
> > > +{
> >
> > This should also reject invalid flags. I'd rather change this helper from
> > RET_VOID
> > to RET_INTEGER and throw -EINVAL
On Sat, Nov 14, 2020 at 5:53 AM Florian Lehner wrote:
>
> At the moment it is not possible to attach a bpf handler to a perf event
> of type PERF_TYPE_SOFTWARE with a configuration of PERF_COUNT_SW_DUMMY.
It is possible or it is not possible?
Such "commit log as an abstract statement" patches
On Fri, Nov 13, 2020 at 10:59 PM Andrii Nakryiko
wrote:
>
> On Fri, Nov 13, 2020 at 10:11 AM Alan Maguire wrote:
> >
> > bpf_snprintf_btf and bpf_seq_printf_btf use a "struct btf_ptr *"
> > argument that specifies type information about the type to
> > be displayed. Augment this information to
On Fri, Nov 13, 2020 at 12:10:57PM -0800, Linus Torvalds wrote:
> On Fri, Nov 13, 2020 at 11:17 AM Alexei Starovoitov
> wrote:
> >
> > The v4 approach preserves performance. It wasn't switching to
> > byte_at_a_time:
>
> That v4 looks better, but still pointless.
&
On Fri, Nov 13, 2020 at 10:08:02AM -0800, Linus Torvalds wrote:
> On Fri, Nov 13, 2020 at 9:03 AM Alexei Starovoitov
> wrote:
> >
> > Linus,
> > I think you might have an opinion about it.
> > Please see commit log for the reason we need this fix.
>
> W
On Wed, Nov 11, 2020 at 02:45:54PM -0800, Daniel Xu wrote:
> do_strncpy_from_user() may copy some extra bytes after the NUL
> terminator into the destination buffer. This usually does not matter for
> normal string operations. However, when BPF programs key BPF maps with
> strings, this matters a
On Thu, Nov 12, 2020 at 7:40 PM Andrew Morton wrote:
>
> On Thu, 12 Nov 2020 19:25:48 -0800 Alexei Starovoitov
> wrote:
>
> > On Thu, Nov 12, 2020 at 7:18 PM Andrew Morton
> > wrote:
> > >
> > > On Thu, 12 Nov 2020 19:04:56 -0800 Alexei Starovoitov
On Thu, Nov 12, 2020 at 7:18 PM Andrew Morton wrote:
>
> On Thu, 12 Nov 2020 19:04:56 -0800 Alexei Starovoitov
> wrote:
>
> > On Thu, Nov 12, 2020 at 04:26:10PM -0800, Roman Gushchin wrote:
> > >
> > > These patches are not intended to be merged through t
On Thu, Nov 12, 2020 at 04:26:10PM -0800, Roman Gushchin wrote:
>
> These patches are not intended to be merged through the bpf tree.
> They are included into the patchset to make bpf selftests pass and for
> informational purposes.
> It's written in the cover letter.
...
> Maybe I had to just
ecognize the build id type.
>
> Cc: Alexei Starovoitov
> Cc: Song Liu
> Signed-off-by: Jiri Olsa
> ---
> include/linux/buildid.h | 2 ++
> lib/buildid.c | 31 ---
> 2 files changed, 26 insertions(+), 7 deletions(-)
>
> diff
On Thu, Nov 5, 2020 at 3:06 PM KP Singh wrote:
>
> From: KP Singh
>
> The current logic checks if the name of the BTF type passed in
> attach_btf_id starts with "bpf_lsm_", this is not sufficient as it also
> allows attachment to non-LSM hooks like the very function that performs
> this check,
Daniel,
the kasan complains about the previous version of your patch,
but your v4 version looks equivalent.
Could you try to repro this issue?
The code looks correct, but kasan complain is concerning.
On Thu, Nov 5, 2020 at 5:56 PM kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed the
On Wed, Nov 4, 2020 at 11:11 AM Nick Desaulniers
wrote:
>
> bpftrace parses the kernel headers and uses Clang under the hood. Remove
> the version check when __BPF_TRACING__ is defined (as bpftrace does) so
> that this tool can continue to parse kernel headers, even with older
> clang sources.
>
On Thu, Nov 05, 2020 at 10:58:26PM +, KP Singh wrote:
> +
> + ret = copy_file_range(fd_in, NULL, fd_out, NULL, stat.st_size, 0);
centos7 glibc doesn't have it.
/prog_tests/test_local_storage.c:59:8: warning: implicit declaration of
function ‘copy_file_range’; did you mean
On Tue, Nov 3, 2020 at 5:55 PM KP Singh wrote:
>
> [...]
>
> > >
> > > I saw the docs mention that these are not exposed to tracing programs due
> > > to
> > > insufficient preemption checks. Do you think it would be okay to allow
> > > them
> > > for LSM programs?
> >
> > hmm. Isn't it allowed
On Tue, Nov 3, 2020 at 4:05 PM KP Singh wrote:
>
> On Tue, Nov 3, 2020 at 7:59 PM KP Singh wrote:
> >
> > On Tue, Nov 3, 2020 at 7:47 PM Alexei Starovoitov
> > wrote:
> > >
> > > On Tue, Nov 03, 2020 at 04:31:31PM +0100, KP Singh wrote:
> > &g
On Tue, Nov 03, 2020 at 04:31:31PM +0100, KP Singh wrote:
> +
> +struct storage {
> + void *inode;
> + unsigned int value;
> + /* Lock ensures that spin locked versions of local stoage operations
> + * also work, most operations in this tests are still single threaded
> + */
On Thu, Oct 29, 2020 at 05:28:11PM -0700, Nick Desaulniers wrote:
>
> We already know that -fno-asynchronous-unwind-tables get dropped,
> hence this patch.
On arm64 only. Not on x86
> And we know -fomit-frame-pointer or
> -fno-omit-frame-pointer I guess gets dropped, hence your ask.
yep.
On Wed, Oct 28, 2020 at 09:15:42AM -0400, Steven Rostedt wrote:
>
> This is something I wanted to implement a long time ago, but held off until
> there was a good reason to do so. Now it appears that having access to the
> arguments of the function by default is very useful. As a bonus, because
>
On Tue, Oct 27, 2020 at 09:15:17PM +0100, Ard Biesheuvel wrote:
> On Tue, 27 Oct 2020 at 21:12, Nick Desaulniers
> wrote:
> >
> > On Tue, Oct 27, 2020 at 12:25 PM Geert Uytterhoeven
> > wrote:
> > >
> > > Hi Nick,
> > >
> > > CC Josh
> > >
> > > On Mon, Oct 26, 2020 at 6:49 PM Nick Desaulniers
On Thu, Oct 29, 2020 at 12:10:52AM +0100, Ard Biesheuvel wrote:
> On Wed, 28 Oct 2020 at 23:59, Alexei Starovoitov
> wrote:
> >
> > On Wed, Oct 28, 2020 at 11:15:04PM +0100, Ard Biesheuvel wrote:
> > > On Wed, 28 Oct 2020 at 22:39, Alexei Starovoitov
> > > w
On Wed, Oct 28, 2020 at 06:07:53PM -0400, Steven Rostedt wrote:
> On Wed, 28 Oct 2020 14:33:03 -0700
> Alexei Starovoitov wrote:
>
> > I don't have strong opinion on this feature, but if you want to have it
> > please add a giant disclaimer that this is going to be x86-64 a
On Wed, Oct 28, 2020 at 11:15:04PM +0100, Ard Biesheuvel wrote:
> On Wed, 28 Oct 2020 at 22:39, Alexei Starovoitov
> wrote:
> >
> > On Wed, Oct 28, 2020 at 06:15:05PM +0100, Ard Biesheuvel wrote:
> > > Commit 3193c0836 ("bpf: Disable GCC -fgcse optimi
On Tue, Oct 27, 2020 at 09:37:08AM -0400, Mathieu Desnoyers wrote:
>
> - On Oct 26, 2020, at 6:43 PM, Alexei Starovoitov
> alexei.starovoi...@gmail.com wrote:
>
> > On Fri, Oct 23, 2020 at 03:53:47PM -0400, Michael Jeanson wrote:
> >> -#define __DO_TRACE(tp,
On Wed, Oct 28, 2020 at 06:15:05PM +0100, Ard Biesheuvel wrote:
> Commit 3193c0836 ("bpf: Disable GCC -fgcse optimization for
> ___bpf_prog_run()") introduced a __no_fgcse macro that expands to a
> function scope __attribute__((optimize("-fno-gcse"))), to disable a
> GCC specific optimization that
On Fri, Oct 23, 2020 at 03:53:47PM -0400, Michael Jeanson wrote:
> -#define __DO_TRACE(tp, proto, args, cond, rcuidle) \
> +#define __DO_TRACE(tp, proto, args, cond, rcuidle, tp_flags) \
> do {\
>
On Thu, Oct 15, 2020 at 12:26 PM Jakub Kicinski wrote:
>
> On Thu, 15 Oct 2020 12:03:14 -0700 Alexei Starovoitov wrote:
> > On Thu, Oct 15, 2020 at 11:56 AM Jakub Kicinski wrote:
> > > How so? It's using in-tree headers instead of system ones.
> > > Many samples s
On Thu, Oct 15, 2020 at 11:56 AM Jakub Kicinski wrote:
>
> On Thu, 15 Oct 2020 11:53:08 -0700 Alexei Starovoitov wrote:
> > On Thu, Oct 15, 2020 at 9:37 AM Jakub Kicinski wrote:
> > > On Wed, 14 Oct 2020 17:17:49 +0800 YueHaibing wrote:
> > > > IF CONFIG_BP
On Thu, Oct 15, 2020 at 9:37 AM Jakub Kicinski wrote:
>
> On Wed, 14 Oct 2020 17:17:49 +0800 YueHaibing wrote:
> > IF CONFIG_BPFILTER_UMH is set, building fails:
> >
> > In file included from /usr/include/sys/socket.h:33:0,
> > from net/bpfilter/main.c:6:
> >
On Sat, Oct 10, 2020 at 1:55 AM Xianting Tian wrote:
>
> In architecture like powerpc, we can have cpus without any local memory
> attached to it. In such cases the node does not have real memory.
>
> Use local_memory_node(), which is guaranteed to have memory.
> local_memory_node is a noop in
On Tue, Oct 06, 2020 at 06:23:13PM -0700, Hao Luo wrote:
> Commit 4976b718c355 ("bpf: Introduce pseudo_btf_id") switched
> the order of check_subprogs() and resolve_pseudo_ldimm() in
> the verifier. Now an empty prog expects to see the error "last
> insn is not an the prog of a single invalid
On Tue, Sep 29, 2020 at 4:50 PM Hao Luo wrote:
>
> - ret = replace_map_fd_with_map_ptr(env);
> - if (ret < 0)
> - goto skip_full_check;
> -
> if (bpf_prog_is_dev_bound(env->prog->aux)) {
> ret = bpf_prog_offload_verifier_prep(env->prog);
>
www.spinics.net/lists/dwarves/msg00451.html
>
> On Tue, Sep 29, 2020 at 9:36 PM Alexei Starovoitov
> wrote:
> >
> > On Tue, Sep 29, 2020 at 4:50 PM Hao Luo wrote:
> > >
> > > v3 -> v4:
> > > - Rebasing
> > > - Cast bpf_[per|this]_cpu_p
On Thu, Oct 1, 2020 at 6:30 AM Thomas Gleixner wrote:
>
> On Thu, Oct 01 2020 at 11:13, Thomas Gleixner wrote:
> > Yes, it's ugly and I haven't figured out a proper way to deal with
> > that. There are quite some mbox formats out there and they all are
> > incompatible with each other and all of
On Thu, Oct 1, 2020 at 10:09 AM Andrii Nakryiko
wrote:
>
> On Thu, Oct 1, 2020 at 12:25 AM Alexei Starovoitov
> wrote:
> >
> > On Wed, Sep 30, 2020 at 10:28:33AM +0100, Lorenz Bauer wrote:
> > > On Tue, 29 Sep 2020 at 16:48, A
On Wed, Sep 30, 2020 at 10:28:33AM +0100, Lorenz Bauer wrote:
> On Tue, 29 Sep 2020 at 16:48, Alexei Starovoitov
> wrote:
>
> ...
>
> > There was a warning. I noticed it while applying and fixed it up.
> > Lorenz, please upgrade your compiler. This is not the firs
Hi Thomas,
For the last couple years we've been using mb2q tool to normalize patches
and it worked wonderfully.
Recently we've hit few bugs:
curl -s https://patchwork.kernel.org/patch/11807443/mbox/ >
/tmp/mbox.i; ~/bin/mb2q --mboxout mbox.o /tmp/mbox.i
Drop Message w/o Message-ID: No subject
No
On Tue, Sep 29, 2020 at 4:50 PM Hao Luo wrote:
>
> v3 -> v4:
> - Rebasing
> - Cast bpf_[per|this]_cpu_ptr's parameter to void __percpu * before
>passing into per_cpu_ptr.
Looks good, but doesn't work:
./test_progs -t ksyms_btf
test_ksyms_btf:PASS:kallsyms_fopen 0 nsec
On Mon, Sep 28, 2020 at 10:59 PM Martin KaFai Lau wrote:
> >
> > +static void compare_cookies(struct bpf_map *src, struct bpf_map *dst)
> > +{
> > + __u32 i, max_entries = bpf_map__max_entries(src);
> > + int err, duration, src_fd, dst_fd;
> This should have a compiler warning.
On Mon, Sep 28, 2020 at 10:51:19AM -0700, Andrii Nakryiko wrote:
> On Mon, Sep 28, 2020 at 7:14 AM Alan Maguire wrote:
> >
> >
> >
> > On Thu, 24 Sep 2020, Alexei Starovoitov wrote:
> >
> > > to whatever number, but printing single task_struct needs
On Mon, Sep 28, 2020 at 4:33 AM Alan Maguire wrote:
>
> Default output for an sk_buff looks like this (zeroed fields
> are omitted):
>
> (struct sk_buff){
> .transport_header = (__u16)65535,
> .mac_header = (__u16)65535,
> .end = (sk_buff_data_t)192,
> .head = (unsigned char
On Wed, Sep 23, 2020 at 06:46:28PM +0100, Alan Maguire wrote:
> Add a test verifying iterating over tasks and displaying BTF
> representation of data succeeds. Note here that we do not display
> the task_struct itself, as it will overflow the PAGE_SIZE limit on seq
> data; instead we write
On Wed, Sep 23, 2020 at 06:46:26PM +0100, Alan Maguire wrote:
> +static int __strncmp(const void *m1, const void *m2, size_t len)
> +{
> + const unsigned char *s1 = m1;
> + const unsigned char *s2 = m2;
> + int i, delta = 0;
> +
> +#pragma clang loop unroll(full)
Shouldn't be needed?
On Wed, Sep 23, 2020 at 06:46:25PM +0100, Alan Maguire wrote:
> +
> +static int bpf_btf_printf_prepare(struct btf_ptr *ptr, u32 btf_ptr_size,
> + u64 flags, const struct btf **btf,
> + s32 *btf_id)
> +{
> + u8 btf_kind =
On Wed, Sep 23, 2020 at 06:46:24PM +0100, Alan Maguire wrote:
>
> +/* Chunk size we use in safe copy of data to be shown. */
> +#define BTF_SHOW_OBJ_SAFE_SIZE 256
sizeof(struct btf_show) == 472
It's allocated on stack and called from bpf prog.
It's a leaf function, but it still
On Tue, Sep 22, 2020 at 9:25 AM Paul E. McKenney wrote:
>
> Hello, Alexei,
>
> This pull request contains eight commits that speed up RCU Tasks Trace
> grace periods by a factor of 50, fix a few race conditions exposed
> by this speedup, and clean up a couple of minor issues. These have
> been
dded entries
> > in enum bpf_reg_type get a NULL entry in compatible_reg_types.
> >
> > This is difficult to understand since it requires knowledge of the
> > peculiarities of designated initializers. Use __BPF_ARG_TYPE_MAX to size
> > the array instead.
> >
> >
On Fri, Sep 18, 2020 at 02:10:42PM +0200, Nicolas Rybowski wrote:
> +
> +BPF_CALL_1(bpf_mptcp_sock, struct sock *, sk)
> +{
> + if (sk_fullsock(sk) && sk->sk_protocol == IPPROTO_TCP &&
> sk_is_mptcp(sk)) {
> + struct mptcp_subflow_context *mptcp_sfc = mptcp_subflow_ctx(sk);
Could
On Fri, Sep 18, 2020 at 02:34:34PM +0100, Alan Maguire wrote:
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 9b89b67..c0815f1 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -3614,6 +3614,15 @@ struct bpf_stack_build_id {
> *
On Thu, Sep 17, 2020 at 1:04 AM Mauro Carvalho Chehab
wrote:
>
> Sphinx warns about a broken cross-reference:
>
> Documentation/bpf/ringbuf.rst:194: WARNING: Unknown target name:
> "bench_ringbufs.c".
>
> It seems that the original idea were to add a reference for this file:
>
>
On Thu, Sep 10, 2020 at 1:20 PM wrote:
>
> From: "Paul E. McKenney"
>
> The various RCU tasks flavors currently wait 100 milliseconds between each
> grace period in order to prevent CPU-bound loops and to favor efficiency
> over latency. However, RCU Tasks Trace needs to have a grace-period
>
On Thu, Sep 3, 2020 at 1:36 PM Andrii Nakryiko
wrote:
>
> On Thu, Sep 3, 2020 at 1:06 PM Hao Luo wrote:
> >
> > The returned value of bpf_object__open_file() should be checked with
> > libbpf_get_error() rather than NULL. This fix prevents test_progs from
> > crash when test_global_data.o is not
On Tue, Aug 25, 2020 at 04:19:59PM -0700, Udip Pant wrote:
> This patch series adds changes in verifier to make decisions such as granting
> of read / write access or enforcement of return code status based on
> the program type of the target program while using dynamic program
> extension (of
On Tue, Aug 25, 2020 at 11:55 AM Nicolas Rybowski
wrote:
>
> Hi Alexei,
>
> Thanks for the feedback!
>
> On Tue, Aug 25, 2020 at 12:01 AM Alexei Starovoitov
> wrote:
> >
> > On Fri, Aug 21, 2020 at 05:15:38PM +0200, Nicolas Rybowski wrote:
> > &
On Wed, Aug 26, 2020 at 1:59 AM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake an a check error message. Fix it.
Kinda ironic that you've made a spelling mistake in the commit log
that fixes spelling in the test.
Whatever scripts you use to detect spelling errors,
On Tue, Aug 25, 2020 at 2:10 PM Stephen Rothwell wrote:
>
> Hi Alexei,
>
> On Tue, 25 Aug 2020 07:33:51 -0700 Alexei Starovoitov
> wrote:
> >
> > what do you suggest to use to make it 'manually enabled' ?
> > All I could think of is to add:
> > depends on
On Tue, Aug 25, 2020 at 2:05 PM Alexei Starovoitov
wrote:
>
> On Tue, Aug 25, 2020 at 11:29 AM KP Singh wrote:
> >
> > From: KP Singh
> >
> > # v9 -> v10
> >
> > - Added NULL check for inode_storage_ptr before calling
> > bpf_local
On Tue, Aug 25, 2020 at 11:29 AM KP Singh wrote:
>
> From: KP Singh
>
> # v9 -> v10
>
> - Added NULL check for inode_storage_ptr before calling
> bpf_local_storage_update
> - Removed an extraneous include
> - Rebased and added Acks / Signoff.
Hmm. Though it looks good I cannot apply it,
On Mon, Aug 24, 2020 at 11:50 PM Stephen Rothwell wrote:
>
> Hi Alexei,
>
> On Mon, 24 Aug 2020 20:27:28 -0700 Alexei Starovoitov
> wrote:
> >
> > I didn't receive the first email you've replied to.
> > The build error is:
> > "
> > No libelf f
On Mon, Aug 24, 2020 at 7:20 AM Tobias Klauser wrote:
>
> Commit 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler")
> changed ctl_table.proc_handler to take a kernel pointer. Adjust the
> signature of bpf_stats_handler to match ctl_table.proc_handler which
> fixes the following
On Mon, Aug 24, 2020 at 8:04 PM Stephen Rothwell wrote:
>
> Hi Alexei,
>
> On Mon, 24 Aug 2020 18:25:44 -0700 Alexei Starovoitov
> wrote:
> >
> > On Mon, Aug 24, 2020 at 6:20 PM Stephen Rothwell
> > wrote:
> > >
> > > On Fri, 21 Aug
On Mon, Aug 24, 2020 at 6:20 PM Stephen Rothwell wrote:
>
> Hi all,
>
> On Fri, 21 Aug 2020 11:11:11 +1000 Stephen Rothwell
> wrote:
> >
> > Hi all,
> >
> > After merging the bpf-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > Auto-detecting system
On Fri, Aug 21, 2020 at 05:15:38PM +0200, Nicolas Rybowski wrote:
> Previously it was not possible to make a distinction between plain TCP
> sockets and MPTCP subflow sockets on the BPF_PROG_TYPE_SOCK_OPS hook.
>
> This patch series now enables a fine control of subflow sockets. In its
> current
On Fri, Aug 21, 2020 at 3:02 AM Jakub Sitnicki wrote:
>
> Describe the purpose of BPF sk_lookup program, how it can be attached, when
> it gets invoked, and what information gets passed to it. Point the reader
> to examples and further documentation.
>
> Signed-off-by: Jakub Sitnicki
Applied to
On Thu, Aug 20, 2020 at 11:23 PM Yonghong Song wrote:
>
>
>
> On 8/20/20 10:28 PM, Jianlin Lv wrote:
> > bpf_devel_QA.rst:152 The subject prefix information is not accurate, it
> > should be 'PATCH bpf-next v2'
> >
> > Also update LLVM version info and add information about
> >
On Fri, Aug 21, 2020 at 1:53 PM Yonghong Song wrote:
>
>
>
> On 8/21/20 12:07 PM, Udip Pant wrote:
> >
> >
> > > On 8/20/20, 11:17 PM, "Yonghong Song" wrote:
> >>
> >>
> >>
> >> On 8/20/20 11:13 PM, Yonghong Song wrote:
> >>>
> >>>
> >>> On 8/20/20 5:28 PM, Udip Pant wrote:
> While using
On Fri, Aug 21, 2020 at 08:01:32AM -0700, Roman Gushchin wrote:
>
> diff --git a/tools/testing/selftests/bpf/progs/map_ptr_kern.c
> b/tools/testing/selftests/bpf/progs/map_ptr_kern.c
> index 473665cac67e..49d1dcaf7999 100644
> --- a/tools/testing/selftests/bpf/progs/map_ptr_kern.c
> +++
On Fri, Aug 21, 2020 at 8:26 AM Eric W. Biederman wrote:
>
> Alexei Starovoitov writes:
>
> > On Wed, Aug 19, 2020 at 6:25 AM Eric W. Biederman
> > wrote:
> >>
> >> The bug in the existing code is that bpf_iter does get_file instead
> >> of
On Tue, Aug 18, 2020 at 10:12:05AM +0100, Alan Maguire wrote:
>
> Fair enough. I'm thinking a helper like
>
> long bpf_btf_snprintf(char *str, u32 str_size, struct btf_ptr *ptr,
> u32 ptr_size, u64 flags);
>
> Then the user can choose perf event or ringbuf interfaces
> to
On Wed, Aug 19, 2020 at 03:40:23PM -0700, Hao Luo wrote:
> +
> /* verify BPF_LD_IMM64 instruction */
> static int check_ld_imm(struct bpf_verifier_env *env, struct bpf_insn *insn)
> {
> @@ -7234,6 +7296,9 @@ static int check_ld_imm(struct bpf_verifier_env *env,
> struct bpf_insn *insn)
>
On Tue, Aug 18, 2020 at 7:00 PM Maciej Żenczykowski
wrote:
>
> From: Maciej Żenczykowski
>
> This reduces likelihood of incorrect use.
>
> Test: builds
I kept this in the commit log though it's a pointless comment.
Please reconsider for the future.
If you want to mention how you've tested it,
On Tue, Aug 18, 2020 at 6:07 PM Maciej Żenczykowski
wrote:
>
> From: Maciej Żenczykowski
>
> This reduces likelihood of incorrect use.
>
> Test: builds
> Signed-off-by: Maciej Żenczykowski
Applied. Thanks
On Wed, Aug 19, 2020 at 6:25 AM Eric W. Biederman wrote:
>
> The bug in the existing code is that bpf_iter does get_file instead
> of get_file_rcu. Does anyone have any sense of how to add debugging
> to get_file to notice when it is being called in the wrong context?
That bug is already fixed
On Tue, Aug 18, 2020 at 1:39 AM Maciej Żenczykowski
wrote:
>
> From: Maciej Żenczykowski
>
> Test: builds
> Signed-off-by: Maciej Żenczykowski
I know it's a trivial patch, but please provide a proper commit log and explain
_why_ this type safety is necessary.
Also pls use email subject with
On Tue, Aug 18, 2020 at 8:54 AM Yonghong Song wrote:
>
>
>
> On 8/18/20 12:16 AM, Xu Wang wrote:
> > Replace a comma between expression statements by a semicolon.
> >
> > Signed-off-by: Xu Wang
>
> Acked-by: Yonghong Song
Applied. Thanks
On Mon, Aug 17, 2020 at 8:46 PM Eric W. Biederman wrote:
>
> I am definitely willing to look at it. Do we think there would be enough
> traffic on task_lock from /proc//fd access to make it work doing?
not from /proc, but bpf iterator in kernel/bpf/task_iter.c that is
being modified
in the other
On Fri, Aug 14, 2020 at 02:06:37PM +0100, Alan Maguire wrote:
> On Wed, 12 Aug 2020, Alexei Starovoitov wrote:
>
> > On Thu, Aug 06, 2020 at 03:42:23PM +0100, Alan Maguire wrote:
> > >
> > > The bpf_trace_printk tracepoint is augmented with a "trace_i
On Thu, Aug 06, 2020 at 03:42:23PM +0100, Alan Maguire wrote:
>
> The bpf_trace_printk tracepoint is augmented with a "trace_id"
> field; it is used to allow tracepoint filtering as typed display
> information can easily be interspersed with other tracing data,
> making it hard to read.
On Thu, Aug 6, 2020 at 3:46 AM Jianlin Lv wrote:
>
> Clang compiler version: 12.0.0
> The following warning appears during the selftests/bpf compilation:
>
> prog_tests/send_signal.c:51:3: warning: ignoring return value of ‘write’,
> declared with attribute warn_unused_result [-Wunused-result]
>
On Wed, Aug 05, 2020 at 06:56:26PM +, Song Liu wrote:
>
>
> > On Aug 5, 2020, at 10:16 AM, Alexei Starovoitov
> > wrote:
> >
> > On Wed, Aug 05, 2020 at 04:47:30AM +, Song Liu wrote:
> >>
> >> Being able to trigger BPF program on
On Wed, Aug 05, 2020 at 10:27:28AM -0700, Andrii Nakryiko wrote:
> On Wed, Aug 5, 2020 at 10:16 AM Alexei Starovoitov
> wrote:
> >
> > On Wed, Aug 05, 2020 at 04:47:30AM +, Song Liu wrote:
> > >
> > > Being able to trigger BPF program on a different C
On Wed, Aug 05, 2020 at 04:47:30AM +, Song Liu wrote:
>
> Being able to trigger BPF program on a different CPU could enable many
> use cases and optimizations. The use case I am looking at is to access
> perf_event and percpu maps on the target CPU. For example:
> 0. trigger the program
On Fri, Jul 24, 2020 at 1:08 PM Song Liu wrote:
>
> Architectures like s390, powerpc, arm64, riscv have speical definition of
> bpf_user_pt_regs_t. So we need to cast the pointer before passing it to
> bpf_get_stack(). This is similar to bpf_get_stack_tp().
>
> Fixes: 03d42fd2d83f ("bpf: Separate
On Thu, Jul 23, 2020 at 11:06:48AM -0700, Song Liu wrote:
> + pmu_fd = syscall(__NR_perf_event_open, , -1 /* pid */,
> + 0 /* cpu 0 */, -1 /* group id */,
> + 0 /* flags */);
> + if (pmu_fd < 0 && errno == ENOENT) {
> +
101 - 200 of 4146 matches
Mail list logo
