lkml.org 
[lkml]   [2017]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Date
    Subject[PATCH 3.16 154/192] net sched filters: fix notification of filter delete with proper handle
    3.16.49-rc1 review patch.  If anyone has any objections, please let me know.

    ------------------

    From: Jamal Hadi Salim <jhs@mojatatu.com>

    [ Upstream commit 9ee7837449b3d6f0fcf9132c6b5e5aaa58cc67d4 ]

    Daniel says:

    While trying out [1][2], I noticed that tc monitor doesn't show the
    correct handle on delete:

    $ tc monitor
    qdisc clsact ffff: dev eno1 parent ffff:fff1
    filter dev eno1 ingress protocol all pref 49152 bpf handle 0x2a [...]
    deleted filter dev eno1 ingress protocol all pref 49152 bpf handle 0xf3be0c80

    some context to explain the above:
    The user identity of any tc filter is represented by a 32-bit
    identifier encoded in tcm->tcm_handle. Example 0x2a in the bpf filter
    above. A user wishing to delete, get or even modify a specific filter
    uses this handle to reference it.
    Every classifier is free to provide its own semantics for the 32 bit handle.
    Example: classifiers like u32 use schemes like 800:1:801 to describe
    the semantics of their filters represented as hash table, bucket and
    node ids etc.
    Classifiers also have internal per-filter representation which is different
    from this externally visible identity. Most classifiers set this
    internal representation to be a pointer address (which allows fast retrieval
    of said filters in their implementations). This internal representation
    is referenced with the "fh" variable in the kernel control code.

    When a user successfuly deletes a specific filter, by specifying the correct
    tcm->tcm_handle, an event is generated to user space which indicates
    which specific filter was deleted.

    Before this patch, the "fh" value was sent to user space as the identity.
    As an example what is shown in the sample bpf filter delete event above
    is 0xf3be0c80. This is infact a 32-bit truncation of 0xffff8807f3be0c80
    which happens to be a 64-bit memory address of the internal filter
    representation (address of the corresponding filter's struct cls_bpf_prog);

    After this patch the appropriate user identifiable handle as encoded
    in the originating request tcm->tcm_handle is generated in the event.
    One of the cardinal rules of netlink rules is to be able to take an
    event (such as a delete in this case) and reflect it back to the
    kernel and successfully delete the filter. This patch achieves that.

    Note, this issue has existed since the original TC action
    infrastructure code patch back in 2004 as found in:
    https://git.kernel.org/cgit/linux/kernel/git/history/history.git/commit/

    [1] http://patchwork.ozlabs.org/patch/682828/
    [2] http://patchwork.ozlabs.org/patch/682829/

    Fixes: 4e54c4816bfe ("[NET]: Add tc extensions infrastructure.")
    Reported-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    ---
    net/sched/cls_api.c | 3 ++-
    1 file changed, 2 insertions(+), 1 deletion(-)

    --- a/net/sched/cls_api.c
    +++ b/net/sched/cls_api.c
    @@ -309,7 +309,8 @@ replay:
    case RTM_DELTFILTER:
    err = tp->ops->delete(tp, fh);
    if (err == 0)
    - tfilter_notify(net, skb, n, tp, fh, RTM_DELTFILTER);
    + tfilter_notify(net, skb, n, tp,
    + t->tcm_handle, RTM_DELTFILTER);
    goto errout;
    case RTM_GETTFILTER:
    err = tfilter_notify(net, skb, n, tp, fh, RTM_NEWTFILTER);
    \
     
     \ /
      Last update: 2017-10-09 15:56    [W:4.123 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site