On 11/21/2018 07:48 PM, Vlad Dumitrescu wrote: > On Wed, Nov 21, 2018 at 5:08 AM Eric Dumazet <eric.duma...@gmail.com> wrote: >> On 11/20/2018 06:40 PM, Alexei Starovoitov wrote: >>> >>> looks good to me. >>> >>> Any particular reason you decided to disable it for cg_skb ? >>> It seems to me the same EDT approach will work from >>> cgroup-bpf skb hooks just as well and then we can have neat >>> way of controlling traffic per-container instead of tc-clsbpf global. >>> If you're already on cgroup v2 it will save you a lot of classifier >>> cycles, since you'd be able to group apps by cgroup >>> instead of relying on ip only. >> >> Vlad first wrote a complete version, but we felt explaining the _why_ >> was probably harder. >> >> No particular reason, other than having to write more tests perhaps. > > This sounds reasonable to me. I can prepare a v2. > > Any concerns regarding capabilities? For example data and data_end are > only available to CAP_SYS_ADMIN. Note that enforcement of this would > be done by a global component later in the pipeline (e.g., FQ qdisc).
cg_skb_is_valid_access() has the CAP_SYS_ADMIN enforcement for direct packet access since cg_skb can also run from unprivileged. Makes sense to do the same for skb->tstamp for the STX_MEM part at least. > Any opinions on sk_filter, lwt, and sk_skb before I send v2? I'd probably leave that out for the time being if there is no concrete use at this point. Thanks, Daniel
