please figure out how to get pidns_info w/o calling into getname_kernel().

Hey Yonghong, I have changed getname_kernel interface to specify the allocation type, all previous callers preserve GFP_KERNEL as the allocation type, after this change getname_kernel could be used

<bblanco=gmail.com@...> wrote: Since we have not had any agenda items proposed, the meeting for this week is canceled.

I'm sorry I won't change __getname. Bests

Yonghong, I totally agree with this new approach as it isolates the allocation type per caller.That way we should not have any regressions on existing code, and the only caller using GFP_ATOMIC

<cneirabustos@...> wrote: Maybe the following alternative approach is better to preserve the existing behavior. Change getname_kernel(filename) to getname_kernel(filename, flags) and the *flags*

Hey Yonghong, I also needed to replace the call to __getname as allocations on the slab cache could sleep, that makes getname_kernel the only name cache consumer that does not block. What do you

Hi All, We have the bi-weekly phone conference scheduled for two days from now, does anybody have a discussion topic to add to the agenda? As a reminder, we are planning to hold the meeting only if

Jiri, Thanks for fixing the issue. Could you submit the patch as a pull request? The pull request is the standard bcc review mechanism. Yonghong

Raghavendra Rao reported that memleak does not display proper name of the related kernel module, but just the "kernel" string, like here for xfs module functions: 131072 bytes in 4 allocations from

I agree with that approach then, is easier than mantain and keep in sync more namei functions. Thanks a lot.

I think adding GFP_ATOMIC to function getname_kernel() is reasonable. const size_t size = offsetof(struct filename, iname[1]); struct filename *tmp;

kern_path is the one, should I move this and dependencies to a new file called bfp_namei.c, in there I'll change it to use GFP_ATOMIC or create a new function to replace kern_path. What do you think?

<cneirabustos@...> wrote: Great. Which dentry function are you referring to? dput? kern_path cannot be used as it uses kmalloc without GFP_ATOMIC. See

Hi, Yes, I'm still interested as I need this capability at $WORK, but haven't had the time to re-write the dentry functions we need, as currently they could sleep. I could resume work on this next

Hi, Carlos, Are you still interested in upstreaming this patch? Looks like there still a desire to make bcc work inside the containers. The bpf-next will open next week. If you would like, could you

Hi, Simon, Finally got some time to deep dive into the verifier for this issue. I filed an issue https://github.com/iovisor/bcc/issues/2463 with possible suggestion to add a new checksum calculation

G'Day, Many of you already know (and have been helping, thanks) and we've discussed this on the iovisor call before: my book is finally launched properly. Some

Hi! Are you sure about the problem? Try to log (with bpf_printk for example) the incoming packets in the BPF program to check if the really missing. I also encountered your problem in my experiments,

This is a call for proposals for the BPF micro-conference at this years' Linux Plumbers Conference (LPC) 2019 which will be held in Lisbon, Portugal for September 9-11. The goal of the BPF