All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Dan Siemon <dan@coverfire.com>
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: Bridge zeros out skb->cb in 5.2 (not in 5.1)
Date: Fri, 23 Aug 2019 11:12:37 +0200	[thread overview]
Message-ID: <20190823091237.GK20113@breakpoint.cc> (raw)
In-Reply-To: <CAB2AaTmtwpHKvuOi6a-54SW1JXUxt1N03Lb=GXMVv_-y+zYyEA@mail.gmail.com>

Dan Siemon <dan@coverfire.com> wrote:

[ CCing bpf maling list ]

> Commit f12064d1b402c60c5db9c4b63d5ed6d7facb33f6 zeros out skb->cb in
> br_input.c:
> 
> memset(skb->cb, 0, sizeof(struct br_input_skb_cb));
> 
> https://github.com/torvalds/linux/commit/f12064d1b402c60c5db9c4b63d5ed6d7facb33f6
> 
> Prior to 5.2, it was possible to store information in skb->cb and have it
> pass through the bridge to the output link.

I did not know this was even possible.

Any owner of the skb (bridge, ip stack, etc.) use skb->cb[] as they see fit.

> We leveraged this to have a BPF
> prog that runs on ingress and does custom packet parsing and stores the
> output qdisc:class in skb->cb. This enabled the egress BPF filter to be
> super simple and avoid having to parse the entire packet again.
> 
> Note I haven't built with this patch removed so it's possible this isn't
> the problem but the memset is unconditional...

You're not exactly saying what the problem is, so I have no idea.

> Is this a regression? Is it expected that the bridge would wipe this field
> when just passing frames?

Even if you remove the memset, that commit br_input_skb_cb
has existed, and is used.  Fields were just cleared on-demand rather
than unconditionally at the start.

I think the latter is better practice and also what other owners do.
So please explain what exactly the problem is and/or check that the
cb clearing "is the problem".

If it is, I have no idea how to fix it.

           reply	other threads:[~2019-08-23  9:12 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <CAB2AaTmtwpHKvuOi6a-54SW1JXUxt1N03Lb=GXMVv_-y+zYyEA@mail.gmail.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190823091237.GK20113@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=bpf@vger.kernel.org \
    --cc=dan@coverfire.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.