Hi Yonghong, I had time yesterday to finish the code to avoid using getname_kernel , self-tests run ok with expected results. Here is the current code to avoid the getname_kernel call. diff --git a/ke

Thanks Yonghong!. Yes, I was looking at filename_lookup today on how to do it, I'll work on that. Thank you very much.

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 wi

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 getnam

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 think

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

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?

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 mon

I'm sorry there was an error on the code, the spinlock was never released if kern_path() failed.Here is the fix. diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c index 2de82d14424d..2a83eba631

As a bpf program cannot sleep, I needed to add a spinlock to kern_path, as it calls getname_kernel() which may sleep. The inode is accessed directly, as we are just interested in the inode's s_dev. Le

Hi, Could you give me a hand with a couple of doubts? - What is the reason to not use the current namespace api instead of directly accessing namespaces?. - Regarding bpf programs not being preemptibl

Hi, I have modified this patch following suggestion on bpf-next, let me know if this looks ok. I'm working on testing it on bpf-next current (4.20) but I'm getting -EINVAL in bpf_load when executing a

Yonghong Song, Let me know what you think of this last patch From 49d9dbcbd52c82dc44b6351ac1824538a6db155a Mon Sep 17 00:00:00 2001 From: cneira <cneirabustos@...> Date: Wed, 8 Aug 2018 17:40:54

Quentin, Thanks a lot for your feedback, I think I'm getting closer to finish this one. I have included the changes suggested, let me know if there is anything else that needs to be changed or improve

This helper obtains the active namespace from current and returns pid, tgid, device major/minor and namespace id as seen from that ns, allowing to do pid filtering inside a container. Major and minor

Hi All, I have applied changes to add thenew helper: bpf_get_current_pidns_info using bpf-next branch. Let me know if what you think. From 932f55d885bf34443bb73ec4b24f9dd4b95b64c7 Mon Sep 17 00:00:00

Hi All, Just tested the code last night, and it did not work. Now I have fixed it and tested in a container, it's finally working except for the the device major and minor info. Here is the updated co

Hi, I have resumed work on issue https://github.com/iovisor/bcc/issues/1329. I just added the needed fields in this helper structure and also I updated the bcc code to use this helper, but I have a co

Hi Ryanna, That repository contains changes to add ebpf to the kernel shipped with Rhel 7.3. If you clone branch bpf_3.18_features that will give you a working kernel with ebpf features from kernel ve